jm + migration   7

Climate Change Could Force Millions of Americans to Flee the Coast. AI Predicts Where They'll Go
By the end of the century, sea level rise could force 13 million people to move away from the U.S. coasts. But it’s not just the coasts that will be affected—so will the places where those migrants end up.

In a study published last week in PLOS One, researchers used artificial intelligence to predict where those places are. The findings could have huge value to people not only living on the coast, but the communities that may deal with an influx of climate refugees inland over the coming century.

“Our findings indicate that everybody should care about sea-level rise, whether they live on the coast or not,” Bistra Dilkina, a Computer Science Assistant Professor at the University of Southern California who led the study, said in a statement.


no shit, Sherlock -- and this will be dwarfed by levels of international migration....
climate-change  migration  papers  climate  ai  future  refugees 
29 days ago by jm
Excellent twitter thread on the "threat" of a "flood" of refugees post-climate-disaster
Once the middle latitudes become effectively uninhabitable, there will be increased migration towards the poles. This thread is an excellent discussion of this issue from a left-wing, pro-migrant standpoint, and how to avoid falling into a racist trap of talking about a "flood of refugees swamping Ireland/UK".
racism  fascism  climate-change  extinction  earth  climate-breakdown  migration  refugees  walls  borders  future 
april 2019 by jm
How Irish Navy’s expertise saved 367 from 30-second sinking in Mediterranean
War-game exercises saved the day:
As the Ribs made their assessment of the situation and began reassuring those on board that help was at hand, the hopelessly overloaded vessel suddenly listed and sank. The sinking took just over 30 seconds. In those 30 seconds, the Captain of the LE Niamh took a number of instant command decisions that saved hundreds of lives. Most of the refugees cannot swim. Their life expectancy in the water would be measured in seconds.
The crew of the Ribs immediately began throwing orange lifejackets into the water – encouraging the now frenzied and milling survivors to cling to them. Individuals, then groups clung to the lifejackets – and one another – as the Ribs rallied around trying to keep the floating human mass from dispersal into wider waters and almost certain death.
In the meantime, the commander of the LE Niamh managed to manoeuvre close in to the survivors where spare life-rafts were launched into the water. These 25-man inflatable life-rafts were specifically ordered and kept on board the LE Niamh following a “war-gaming” exercise, where the officers and crew envisaged such a nightmare scenario. Had this forward planning not taken place – there would have been no such extra inflatable lifeboats on board.
war-gaming  planning  navy  ireland  mediterranean  sea  boats  refugees  migration  drowning  liferafts 
august 2015 by jm
Taming Complexity with Reversibility
This is a great post from Kent Beck, putting a lot of recent deployment/rollout patterns in a clear context -- that of supporting "reversibility":
Development servers. Each engineer has their own copy of the entire site. Engineers can make a change, see the consequences, and reverse the change in seconds without affecting anyone else.
Code review. Engineers can propose a change, get feedback, and improve or abandon it in minutes or hours, all before affecting any people using Facebook.
Internal usage. Engineers can make a change, get feedback from thousands of employees using the change, and roll it back in an hour.
Staged rollout. We can begin deploying a change to a billion people and, if the metrics tank, take it back before problems affect most people using Facebook.
Dynamic configuration. If an engineer has planned for it in the code, we can turn off an offending feature in production in seconds. Alternatively, we can dial features up and down in tiny increments (i.e. only 0.1% of people see the feature) to discover and avoid non-linear effects.
Correlation. Our correlation tools let us easily see the unexpected consequences of features so we know to turn them off even when those consequences aren't obvious.
IRC. We can roll out features potentially affecting our ability to communicate internally via Facebook because we have uncorrelated communication channels like IRC and phones.
Right hand side units. We can add a little bit of functionality to the website and turn it on and off in seconds, all without interfering with people's primary interaction with NewsFeed.
Shadow production. We can experiment with new services under real load, from a tiny trickle to the whole flood, without affecting production.
Frequent pushes. Reversing some changes require a code change. On the website we never more than eight hours from the next schedule code push (minutes if a fix is urgent and you are willing to compensate Release Engineering). The time frame for code reversibility on the mobile applications is longer, but the downward trend is clear from six weeks to four to (currently) two.
Data-informed decisions. (Thanks to Dave Cleal) Data-informed decisions are inherently reversible (with the exceptions noted below). "We expect this feature to affect this metric. If it doesn't, it's gone."
Advance countries. We can roll a feature out to a whole country, generate accurate feedback, and roll it back without affecting most of the people using Facebook.
Soft launches. When we roll out a feature or application with a minimum of fanfare it can be pulled back with a minimum of public attention.
Double write/bulk migrate/double read. Even as fundamental a decision as storage format is reversible if we follow this format: start writing all new data to the new data store, migrate all the old data, then start reading from the new data store in parallel with the old.


We do a bunch of these in work, and the rest are on the to-do list. +1 to these!
software  deployment  complexity  systems  facebook  reversibility  dark-releases  releases  ops  cd  migration 
july 2015 by jm
Migration to, Expectations, and Advanced Tuning of G1GC
Bookmarking for future reference. recommended by one of the GC experts, I can't recall exactly who ;)
gc  g1gc  jvm  java  tuning  performance  ops  migration 
may 2015 by jm
I was a Lampedusa refugee. Here’s my story of fleeing Libya – and surviving
'The boy next to me fell to the floor and for a moment I didn’t know if he had fainted or was dead – then I saw that he was covering his eyes so he didn’t have to see the waves any more. A pregnant woman vomited and started screaming. Below deck, people were shouting that they couldn’t breathe, so the men in charge of the boat went down and started beating them. By the time we saw a rescue helicopter, two days after our boat had left Libya with 250 passengers on board, some people were already dead – flung into the sea by the waves, or suffocated downstairs in the dark.'
lampedusa  migration  asylum  europe  fortress-europe  italy  politics  immigration  libya  refugees 
april 2015 by jm
How to make breaking changes and not break all the things
Well-written description of the "several backward-compatible changes" approach to breaking-change schema migration (via Marc)
databases  coding  compatibility  migration  schemas  sql  continuous-deployment 
june 2014 by jm

Copy this bookmark:



description:


tags: