The comment is referring to finding something to replace the Haber-Bosch Process, which is mostly fossil fuel driven, which makes most of our food itself dependent on fossil fuels.
Unrelated to the above, except in the mix of sustainability and agriculture - there are a bunch of companies working on bacteria to fix nitrogen for crops without requiring separate fertilizer similar to how legumes do it. I think Pivot Bio is the furthest along in the space - they’ve got a commercially available product - but it’s an active area of development in the industry right now.
> Unrelated to the above, except in the mix of sustainability and agriculture - there are a bunch of companies working on bacteria to fix nitrogen for crops without requiring separate fertilizer similar to how legumes do it.
Nitrogen fixation is energy-intensive, so something has to provide energy. Additionally, nitrogen fixation has to happen in anaerobic conditions, oxygen kills the enzymes responsible for nitrogen fixation. In legumes, the oxygen is carried away by hemoglobin (the same one used in "artificial meat"), but engineering these conditions for free-living bacteria is likely going to be problematic.
I'm personally hoping for a catalyst that can work in mild conditions.
There’s been some success here already - as mentioned, there’s some commercial products on the market already that do some amount of nitrogen fixation for at least corn and I believe wheat as well, so it’s not unsolvable.
Where is the security problem? All code commits and builds can still be signed. All of this is just a more efficient way of deploying changes without dropping existing connections.
Are you suggesting that hot code replacement is somehow a attack vector?
Ericsson has been using this method for decades on critical infrastructure to patch switches without dropping live calls/connections it works.
My interpretation of the GP was that a code change in one node can be automagically propagated out to a cluster of participating Erlang nodes.
As a security person, this seems inherently dangerous. I asked why it is safe, because I presumed I’m missing something due to the lack of ever hearing about exploitation in the wild.
An Erlang dist cluster has no barriers between connected nodes. But a multithreaded application has no barriers between its threads either.
If someone can exploit one Erlang node, they can easily take over the cluster. But in a more typical horizontally scaled system, usually if they can get into one node, they can get into all the other nodes running the same software the same way.
Security wise, I think of the whole cluster as one unit. There's no meaningful way to separate it, so it's just one thing. Best not to let anyone in who can't be trusted, because either they have access or they don't; there's no limited access.
But given that, may as well push code updates over dist in a straight forward way, because it's possible, so it may as well be straight forward.
If someone were to exploit a running Erlang process, the description of this feature sounds to me like they would have access to code paths that allow pushing new code to other Erlang processes on cooperating nodes.
Yeah -- and a some constraints. We don't want to spend any more than $10 per user per month and must support SSO for our Google workspace accounts. Other than that it's pretty much standard project management stuff for managing Sprints and hosting some docs.
