The poisoned NUL byte, 2014 edition (Project Zero)

Posted Aug 28, 2014 15:02 UTC (Thu) by skarnet (guest, #98583)
In reply to: The poisoned NUL byte, 2014 edition (Project Zero) by Karellen
Parent article: The poisoned NUL byte, 2014 edition (Project Zero)

I am the author of s6.

s6 is a process supervision system. Its goal is to launch and supervise daemons, and provide a framework to control them, as well as a framework for notification.

s6 is not an init system as most people envision it - not yet. It's definitely one of the main components for a full-featured init system, and I have used s6-svscan as my process 1 for a long time, but it's not a drop-in replacement for an init system as desktop users would define it.

It is an explicit non-goal of s6 to perform dependency management. Dependency management can be performed *on top* of a process supervision system, and I plan to add features to make it easier to use s6 as a backend for dependency management systems such as, for instance, OpenRC. I might design and implement my own dependency management system in the future, but since alternatives exist that people seem happy about, it is not a priority.

The "why" page of the s6 documentation is a bit dated. It was written when Upstart was the big thing, and systemd was added to it as an afterthought. I did not realize at the time how big systemd would become, and it is a critical failure on my part; I am going to address that failure. I fully acknowledge that the "why" page is inaccurate, and I should update it, but I have bigger plans.

In the near future (count, say, two or three months), I will be able to fully focus on developing a complete init system, based on s6, to provide an alternative to systemd - but I want to do it the *right* way, correctly engineered for reliability and smallness and following the Unix philosophy. The first step will be to reach out to users, and ask them what the killer features of systemd are, according to them - why they chose it over, for instance, sysvinit. I will then try to implement those features in a way that does not require you to hand over your machine, and your soul, to me.

There is still a long way to go. Attacking systemd advocates, and bickering in forums, accomplishes nothing: people use systemd because it scratches an itch for them, and that itch must be acknowledged, and addressed. It is definitely possible to do a better job than systemd; I believe s6 already does, on the parts that it's focused on, and I'm committed to keep working on it and eventually make it a serious competitor. But it will take time, dedication, and work. If you (as in everyone reading this) want to help, please stay tuned. I definitely encourage you to take a look at supervision systems in general and s6 in particular, as well as think about what exactly should go into an init system.

Thank you.

s6 response

Posted Aug 28, 2014 15:10 UTC (Thu) by karath (subscriber, #19025) [Link]

Nice update. All the best!

The poisoned NUL byte, 2014 edition (Project Zero)

Posted Aug 28, 2014 21:05 UTC (Thu) by anselm (subscriber, #2796) [Link] (3 responses)

Yours is a very laudable goal, and I wish you all the best in your endeavours.

Unfortunately though, systemd these days is much more than an init system. It offers standardised and generally reasonably well-designed replacements for huge swathes of base functionality which Linux distributions used to have to provide themselves, and which they generally provided in an insular and non-standardised fashion. As such, systemd has the potential to (a) save Linux distributors loads and loads of drudge work and let them concentrate on more interesting and important issues, and (b) make Linux that much easier to understand and deal with for administrators, instructors, and authors of books and training manuals, no matter what distribution they're using. Both of these are great and important benefits.

Anybody who thinks they will be able to supplant systemd by providing (only) a better »init system« will probably find that the major distributions are reluctant to buy into that, because the non-init features of systemd are too compelling to pass over, and are likely to become even more so in the future. This may or may not be an actual problem depending on who the target users of your replacement init are, but it is fairly safe to say that if you want to take over the Linux world it's not going to happen unless you get the mainstream distributions on board, and they won't take you seriously unless you offer something that improves on all of systemd.

The poisoned NUL byte, 2014 edition (Project Zero)

Posted Aug 28, 2014 21:40 UTC (Thu) by skarnet (guest, #98583) [Link] (2 responses)

Yes, I realize that, and it will precisely be a major point of focus in my future efforts. What kind of "base functionality" does systemd provide that distributions rely on ? What are the killer features that were the tipping point for mainstream distributions and made them switch over to systemd ?

Of course the scope of the project goes well beyond an init system. That is exactly the problem with systemd - it aims to do everything, to be all-encompassing, and it is a political issue as well as a technical one. My goal is to provide a piece of software for every useful feature of systemd, every piece being as independent and replaceable as possible - one functionality, one tool. It will require a lot of study and design: I'm confident in my ability to do that.

I don't want to take over the world. I just feel that systemd is doing the right things the wrong way, and I want to provide an alternative. If the alternative is correctly designed, more and more people will choose it, and world domination will happen naturally. ;)

The poisoned NUL byte, 2014 edition (Project Zero)

Posted Aug 29, 2014 3:18 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

Have you seen the list of interfaces systemd uses, provides, and guarantees compatibility for? Could you please adhere to those at least (or work the get the interfaces improved if they are somehow insuffcient)? Even OpenBSD is implementing their own tools which adhere to them (at least timezoned and hostnamed, but there were at least two others in the list).

The poisoned NUL byte, 2014 edition (Project Zero)

Posted Aug 31, 2014 1:36 UTC (Sun) by johannbg (guest, #65743) [Link]

Writing a new init system is one thing, convincing wide variety of upstream maintainers and provide patches to their components is another and getting distribution to default, integrate and use it is the third.

Canonical failed in that aspect in every way with upstart so I somehow doubt that you will succeed in that regard in fact the only init system beside system V to achieve that, out of all the init system in existence out there past and present is systemd.

And despite what you might think that did not happen because of one man. An man that people seem to be blaming and basically hunting like captain Ahab hunts his white whale in Herman Melville's Moby-Dick based on some religious notion and misinterpretation of guidelines Doug McIlroy,Rob Pike,Ken Thompson came up with sometime in the 70's when times and technology where different.

The fact is today there are close to 200 people actively contributing to systemd and of those ca 200 people, 10% - 20% have direct commit access to it's source repository and that's just the people in the systemd's community that commit code, that's not counting the people that reside there and are actually doing all the heavy lifting and integration work outside and within the distribution themselves. The migration,documentation,teaching etc.

Bottom line you cannot achieve this alone and expect about 5+ years of full dedication to your project before it starts taking of and another 5 - 10 years until distribution and upstream will even consider going through the pain point of replacing init system again and upstream to rewrite their code ( under the assumption you manage to build a community surrounding your project ) but good luck we welcome and need the competition to prevent ourselves from stagnating as time change and technology evolves.