Whats curious to me here is that the github repo linked to in the article seems to exactly recreate the "operating system" that is called an "opinion in the wrong layer".<p>Perhaps I am misunderstanding this, but after looking at the code what exactly are we achieving here over other frameworks? The repo is obviously very new (and the author certainly seems busy), so perhaps a better question is what do we aim to achieve? So far it seems like the exact same pattern with some catchy naming.<p>Regardless, I love ambitious projects furiously coded by one crazy person. And I mean "crazy" in the best sense of the word, not as an insult. This is what open source is all about.<p>Please prove us all wrong. If you fail, you'll learn a ton!
I ask this question, but instead: I ask it of Lua.<p>As in, what if there was a Linux distro that focused, primarily, on building a Lua layer on top of everything, system-wise. Just replace all the standard stuff with one single, system-friendly language: Lua. C/C++ everything as it currently is: put Lua on top all the way to the Desktop.<p>It’s only a thought experiment, except there are cases where I can see a way to use it, and in fact have done it, only not to the desktop, such as of course <i>embedded</i>. Realtime data collection, processing and management. In this case, it is superlative to have a single system/app language on top of C/C++.<p>So I think there may be a point in the future where this ‘single language for everything’ becomes a mantra in distro land. I see the immense benefit.<p>Lua table state can be easily transferred, give or take a bit of resource management vis a vis sync’ing state and restoring it appropriately. Lua Bytecode, itself, in a properly defined manner can serve as a perfectly cromulant wire spec. Do it properly and nobody will ever know it isn’t just a plain ol’ C struct on an event handler, one of the fastest, except it’ll be very well abstracted to the application.<p>Oh, and if things are doing bytecode, may as well have playback and transactions intrinsically… it is all, after all, just a stream.<p>App state as gstreamer plugin? Within grasp, imho…
The distributed object fallacy is never going away, is it?<p><a href="https://martinfowler.com/articles/distributed-objects-microservices.html" rel="nofollow">https://martinfowler.com/articles/distributed-objects-micros...</a>
I don't have much experience with this kind of thing, but from here it looks like a program written this way would be nearly impossible to reason about performance when something as simple as a function call in your Python interpreter can have wild fluctuations in predictability just due to underlying network latency, remote host saturation, etc.<p>It seems like you would need an entire observability framework built and instrumented on top of this to ever really be that useful.
cloudpickle serializes code without signatures; which is an RCE vuln.<p>It is much safer to distribute signed code in signed packages out of band and send only non-executable data in messages.<p>It is more safe to store distributed messages in a page with the NX bit flipped.<p>A compromise of any client in this system results in DOS and arbitrary RCE; but that's an issue with most distributed task worker systems.<p>To take a zero trust approach, you can't rely on the shared TLS key or the workers never being compromised.<p>mDNS doesn't scale beyond a broadcast segment without mDNS repeaters (which don't scale) which are on multiple network segments.<p>Something centralized like Dask, for example, can log and track state centrally to handle task retries on network, task, and worker failure.<p>But Dask doesn't satisfy zero trust design guidelines either.<p>How are these systems distinct from botnets with a shared TLS key and no certificate revocation?