Poettering: Factory Reset, Stateless Systems, Reproducible Systems & Verifiable Systems [LWN.net]

Poettering: Factory Reset, Stateless Systems, Reproducible Systems & Verifiable Systems

Posted Jun 18, 2014 1:42 UTC (Wed) by sjj (guest, #2020)
In reply to: Poettering: Factory Reset, Stateless Systems, Reproducible Systems & Verifiable Systems by jspaleta
Parent article: Poettering: Factory Reset, Stateless Systems, Reproducible Systems & Verifiable Systems

Thanks for that historical link. I for one welcome our new stateless overlords!

We've certainly moved a lot closer to stateless, in a kind of ad hoc way. Only some greybeards remember manual mknod in /dev, and even hand editing stuff in /etc on a modern linux laptop is becoming a lost art due to sensible defaults and autoconfiguration.

User data is scattered around the world, in islands in the cloud. Enterprises haven't bothered backing up user machines in years - they give you a network share or a Box account and it's your responsibility to copy stuff you want to keep. I would love a distributed filesystem I could use on a laptop though - connect to network and let it sync, detach and go.

Sysadmins who ssh to servers and edit files locally are going to find themselves unemployed. If it ain't in git, it might as well not exist. Server applications need to start looking for some service discovery mechanism for configuration.

Exciting times, and I'm glad there are people willing to push the envelope against the always-somewhat-surprising conservatism of some techies.

to post comments

Poettering: Factory Reset, Stateless Systems, Reproducible Systems & Verifiable Systems

Posted Jun 18, 2014 4:23 UTC (Wed) by jspaleta (subscriber, #50639) [Link] (1 responses)

I actually don't think this is ad-hoc. I think historically 2004 was sort of a watershed year for really really thinking hard about the state of things and picking a direction and a set of goals to shoot for.

We have Havoc's whitepaper on stateless _and_ 2004 was also the year we saw people band together and form up Project Utopia and start really addressing the need for dynamic hardware management.

I think systemd (and even upstart may it rest in peace) is actually part of an... intelligent design (NOT natural evolution! HA!)... of code implementations around some fundamental goals generated in the 2004 timeframe. No not ad-hoc at all... but a systematic and cyclical process implementation, refinement and eventually replacement with better implementations to better meet the goals as laid out way back in 2004.

I really don't see the container or visualization as being anything really new as a use case that wasn't provided for by the goals of Stateless Linux and Project Utopia together in 2004. Containers are an interesting use case only because its clearly becoming a dominant use case now, very quickly, and a usecase that benefits greatly from stateless. Whereas previously the uses cases that could really benefit from stateless were more niche.... well manicured thin client islands among a wild sea of fat clients in 2004.

But it does beg the question, is work towards "Stateless Utopia" a positive feedback loop? Sorry here comes the run on sentence that will bake your noodle...

As the people working towards a Utopic Stateless Utopia, got better at meeting the goals with newer code implementations, did their work make it easier for admins to move their workloads to configurations that depended on aspects of Stateless Utopia, in turn raising demand (and therefore the value) for even better Stateless Uptopia implementations?

I think perhaps that's what's happening. We've sort of hit the tipping point now in the last couple of years in terms of real world installs that benefit. And we've gotten here only because of the persistent development in the intervening years to just part of the way, dragging some of us kicking and screaming by our beards into the future.

-jef

Poettering: Factory Reset, Stateless Systems, Reproducible Systems & Verifiable Systems

Posted Jun 18, 2014 22:40 UTC (Wed) by sjj (guest, #2020) [Link]

Yeah, I think you're probably right - it all just feels adhoccy from the sidelines since there is no Central Linux Planning Office with five-year plans, rather than diverse groups and individuals exploring solutions. Also, future history might value the invention and adoption of git as high as linux itself. No closed source company can match a loose collection of geeks with github accounts, filled with laziness, impatience, and hubris, bent on reinventing the wheel.

And some kind of tipping point is almost here. It's fascinating how we seem to be converging on a Linux From The Future (Project Atomic, CoreOS) with containers and service discovery tools.

If there are any anthropology grad students around, a dissertation on the design evolution of this part of the FLOSS world would be interesting to read!

/blowiating