> Programs just have to be compiled relocatable.

Yes, and with unrestricted memory access, one program can crash the entire system.

> You know, like what happens with shared libraries: which are written in C, and get loaded at different addresses in the same space, yet access their own functions and variables just fine.

That is except when one piece manipulates global state in a way with which another piece can't cope, and at best the whole thing crashes. Dynamic linking in UNIX is so bad some believe it can't work, and instead use static linking exclusively.

It is because UNIX is written in the C language that there are even multiple flat address spaces instead of segments or a single address space systemwide. The fact that the kernel exists at all is also due to this. It has everything to do with the implementation language.

> Languages "such as Lisp" will have the exact same problem, for the same reason.

Under UNIX, yes.

> Collecting all of the "components" of the connection and sending them to a different host won't make the other host start sending packets to the new recipient, or replay the in-flight packets (which is state on intermediate routers, different computers than the connected ones entirely), or fix the ARP tables on the neighbouring hosts. None of that is available, and certainly isn't writeable, to the host doing the serialising.

It may very well require some specialized machinery, but not nearly so much as one may think to be necessary.

> To play some silly semantics games, this isn't so much about _serialising_ a connection as it is about _deserialising_ the connection and having it work afterwards.

That's implicit. I needn't write of deserializing when writing of serializing, as one is worthless without the other, at least in most cases.

> That act has literally nothing to do with programming language.

Look at what Lisp and Smalltalk systems could do before UNIX existed and tell me that again.

So, my point is the ability to take running state, serialize it, and reinstate it elsewhere is only impressive to those who have misused computers for so long that they don't understand this was something basic in 1970 at the latest.

> It is natural to want those connections to follow the container to its new host, preferably without the remote end even noticing that something has changed, but the Linux networking stack was not written with this kind of move in mind.

Yes, it was written in the C language.

At least read my website before calling me unhinged.

It then puts the result into a form that can be used programmatically by the local shell.

That does sound better than returns one octet with two well-defined values, sure.

And already the expert. Impressive.

I know UNIX is shit with a legion of cultists.

Hey, if we live in the best of all possible worlds, explain the market dominance of Windows. Did MicroSoft give Windows away for nothing, to poor unsuspecting university students who decided to hack on it instead of learn what a real computer is, until none remained?

Educate me.

It's much more meaningful and useful than "something simple" "running little functions floating in the void" which just sounds like some vapid marketing pitch.

That was a quick response to what I thought would be better than administrating a UNIX system on an Amazon machine. Don't be an ass. I've no experience with the real distributed computing systems created before UNIX.

The great thing about Linux as the base layer is that it allows a commodity common ground with a very capable system that also facilitates more specialized layers to be implemented on top of it.

No, that's the vapid marketing pitch. The Linux kernel randomly kills processes when it starts exhausting memory. It's garbage.

Hey, Brainfuck also facilitates more specialized layers to be implemented on top of it. Now, what's stupid about doing that, however?

I well remember my disgust when I learned AWS was just using UNIX virtual machines or whatever, rather than something simple, such as allowing people to run little functions floating in the void. I know nothing about AWS, but I've not been mistaken, right?

Right, but the problem is – as Peter Harkins mentions here – that programmers have this tendency to, once they master something hard (often pointlessly hard), rather than then making it easy they feel proud of themselves for having done it and just perpetuate the hard nonsense.

Yes, see the entire history of UNIX. I convinced someone programming was a bad choice for his major because of this stupid attitude.

I'm still reading, but I like how he takes issue with what currently passes for machine text. Some of my work covers the same problem. I should send him an e-mail.

The C language makes it unreasonably difficult to write anything, even before proving it to be correct.

I don't use Github, but fuckers upload my code there anyway.

Copyright is evil, but only large corporations having copyright, even more than they already do, is even worse.