
System XVI: A replacement for systemd - vmorgulis
https://github.com/ServiceManager/ServiceManager/blob/master/README.md
======
vezzy-fnord
Oh boy. 

Alright, I'm an acquaintance of the author, so let me clear things up. 

SystemXVI only began less than a couple of weeks ago, and is still a very
early stage project.  However, the author (David Mackay) decided to be a bit of
an expedient troll and advertise on /g/, to arouse some controversy.  It ended
up blowing up greater than anticipated, even ending up being mocked on Linux
Unplugged and hitting /r/linux as the project was still a skeleton. 

First thing's first:

This is not a joke project.  Mackay is not some amateur, either.  He's a former
Solaris/illumos committer and most recently was involved in the Tox community. 
He actually wrote a small service manager called Charge last year as an
experiment, and some of the logic is borrowed on to SystemXVI (though the
architecture is different). 

SystemXVI, the design is quite interesting.  The closest equivalent would
probably be Solaris SMF, but it's still different.  init(8) is kept small and
instead SystemXVI is based on the idea of the service repository (inherited
from SMF) and delegated restarters.  The repository is a hash table that stores
instance information and service properties.  It's useful for having a point of
fault recovery and to introspect services in a dynamic, transient manner as
they run. 

The primitive process management is currently in libs16rr, but the actual
supervision strategy is defined in restarters.  Much like Solaris SMF, there is
a master restarter, but certain services (i.e. local socket services) can, for
example, opt to be watched by a delegated inetd-like restarter that uses the
SystemXVI RPC interfaces.  Or let's say you have a Java, Erlang or other
service that needs special behavior, you can write a restarter for it while
reusing SystemXVI's process management. 

TI-RPC/SunRPC plays a big role here.  It's much leaner than D-Bus and at least
nominally capable of network transparency.  Android has a portable
implementation in ~5000 LoC.

Dependencies and ordering is actually calculated by a separate process called
svcorder, influenced by BSD systems' rcorder(8). 

There will be systemd unit file compatibility.  Internally, SystemXVI has
semantics similar to systemd units, but much simplified - no need for
transactions or complicated job modes, since a repository is used instead to
contain state. 

More here:
[https://github.com/ServiceManager/ServiceManager/blob/master...](https://github.com/ServiceManager/ServiceManager/blob/master/doc/DESIGN.md)
(Flowchart:
[https://github.com/ServiceManager/ServiceManager/blob/master...](https://github.com/ServiceManager/ServiceManager/blob/master/doc/s16.png))

It's a refined SMF-like system with influences from daemontools and BSD rc.d. 
Very microkernel-ish, it's meant to have strong module/communication
boundaries and have its components be easily hotswapped or rewritten per a
stable RPC interface. 

It's very early and the project really shouldn't be getting such publicity,
but a pre-alpha might be out soon, and it's a project well worth watching.  I
have confidence it will turn out well. 

~~~
weland
> even ending up being mocked on Linux Unplugged and hitting /r/linux as the
> project was still a skeleton. 

To be entirely fair, I think there are few communities that can claim the
honour of being worse and more amateurish than /r/Linux.  It's incredible how
many Linux experts who have used nothing but Arch Linux for about an year can
gather in one single place.  Every once in a while there's an OK post, but it's
downvoted. 

I hope your friend didn't take them too seriously. 

~~~
embik
/r/linux is schizophrenic.  On the one hand, posts about new game releases for
Steam are voted up and (Steam) gaming posts are quite active.  On the other
hand, they're badgering every single FOSS project which is trying to make
money without begging their users for it (see the recent posts about Firefox). 
It's crazy. 

~~~
digi_owl
Demonstrating the influx of web/devops, and how they are generally more
interested in social media. 

~~~
weland
Someone had to say it :-). 

~~~
digi_owl
Frankly i feel like a salty old git, even though i am of the same age as, say,
Poettering. 

------
markbnj
Props to the author for posting the "testimonials."  Got a chuckle out of it. 
Did not look at the code. 

~~~
nkurz
At a glance, the code is clean and idiomatic C written by an experienced
professional programmer.  Comments are sparse and describe intent.  Variable and
function names are consistent and well chosen. 

I'd be happy giving it to a new programmer to use as a style guide.  I have no
idea if the architecture is suitable for the purpose, but anyone who is
dismissing this based on code quality should be ignored. 

Representative Sample:
[https://github.com/ServiceManager/ServiceManager/blob/master...](https://github.com/ServiceManager/ServiceManager/blob/master/app/restartd/unit.c)

~~~
cremno
1\. naming conventions are unusual and inconsistent (List_destroy but then
there's destroy_svcs_list)

2\. the return value of malloc() et al.  isn't checked
([http://www.etalabs.net/overcommit.html](http://www.etalabs.net/overcommit.html))

3\. the register storage-class specifier is used multiple times (mainly
lib/s16db/translate.c)

4\. function declarations are missing a prototype (() instead of (void))

~~~
nkurz
I'm not claiming the code is perfect.  I'm claiming that at a glance it looks
like professional code of a quality similar that of other high quality C
codebases: Linux, Python, Perl, Apache, sqlite, etc.  One can always do better. 

I (and likely the author) disagree with you on the importance of checking the
return value of malloc().  Because of overcommit (as you point out), a non-null
value returned from malloc() does not mean that you will not crash when you
access the pointer.  If the pointer is used directly, crash on NULL might a
reasonable approach.  It's when NULL is retained and then used as the base of
an array that it may become a security problem.  Configuring malloc() to
abort() on failure would be probably my preferred solution. 

I agree with the last point, but think it's a minor one.  While I'd like C to
treat () in a function definition as equivalent to (void), for historical
reasons it does not.  The author trades off the visual noise of the word 'void'
for better error reporting.  But depending on your compiler, you may still get
a warning.  On the computer I just tried, 'icc' and 'clang' gave clear warnings
but 'gcc' did not. 

    
    
      nate@ubuntu:~/C$ cat void.c
      #include <stdio.h>
      int empty() {  return 3; }
      int main(void) { printf("%d\n", empty(4)); return 0; }
    
      nate@ubuntu:~/C$ icc -Wall -o void void.c
      void.c(3): warning #140: too many arguments in function call
        int main(void) { printf("%d\n", empty(4)); return 0; }
                                              ^
      nate@ubuntu:~/C$ clang -Wall -o void void.c
      void.c:3:40: warning: too many arguments in call to 'empty'
      int main(void) { printf("%d\n", empty(4)); return 0; }
                                      ~~~~~  ^

~~~
AndyKelley
Not all systems have overcommit enabled.  Notably, as the article linked above
points out, _robust_ systems do not have overcommit enabled.  The OOM killer is
heuristics based and cannot be relied on in robust systems.  This means that
libraries and applications that want to be viable on such platforms have to
recognize that malloc may return NULL and respond accordingly. 

~~~
EmanueleAina
Very true for low-level system libraries, but applications should really not
waste energy on trying to be OOM-safe: it's hard to understand which actions
are safe when you no longer can allocate memory (releasing resources often
requires allocating memory temporarily), and it just adds complexity which
basically will never get tested, thus getting broken quickly and gaining
nothing over just crashing on a NULL dereference. 

See the experience of the D-Bus (which tries hard to be OOM-safe) on this
topic: [http://blog.ometer.com/2008/02/04/out-of-memory-handling-
d-b...](http://blog.ometer.com/2008/02/04/out-of-memory-handling-d-bus-
experience/)

------
nteon
A 'replacement' for systemd should be designed to be drop-in: /sbin/init
should read unit files (which in general are much nicer than init scripts),
should provide systemctl with the same options, and if dbus is also
undesirable (which most people who burn with fire-y rage for systemd do),
should replace the communication between processes like systemctl and
/sbin/init with something else, like a Fuse or 9p filesystem. 

That would be pretty neat.  But until then, the world will continue to run on
systemd, because it _works_. 

~~~
asveikau
> the world will continue to run on systemd, because it _works_. 

Does it? 

When Debian switched to systemd my system stopped booting.  When I managed to
"fix" it, it worked superficially but displayed "Segmentation fault" at every
boot [it still does that on another one of my machines, which in fairness
never "broke".].  This in addition to boot-time fsck breaking and my bluetooth
audio and keyboard setup no longer working.  Based on this I am not inclined to
think of Mr. Poettering as an "it just works" kinda guy.  On a related note I
have never successfully gotten pulse audio to perform its intended function of
playing audio samples. 

After ~15 years of mostly tracking Debian sid on my personal machine, I
switched to FreeBSD on my laptop when seeing these issues.  No major issues
since. 

~~~
mikekchar
Are you sure these are systemd problems?  I'm not a huge fan of systemd, but I
haven't actually had any problems with it (apart from not liking how it works
;-) ).  For example, bluez breaks in every update in my experience.  I've found
a dance containing magical incantations that will usually keep it up for a few
hours, but I still hold on to 2 or 3 old versions of the software just in case
the new version is completely broken (which has happened to me on more than
one occasion). 

I moved from Debian based distros to Arch a few years ago and found that my
machines are a lot more stable.  Because it you do the configuration yourself
(rather than the configuration being in the package a la Debian), you are a
lot more free to jettison dependencies of questionable quality.  Though, I had
a lot of trepidation when Arch switched to systemd, it has not yet broken my
system in any way. 

Still, there's nothing wrong with FreeBSD, so if it's working for you, might
as will stay with it. 

~~~
simoncion
I'm running Gentoo Linux and haven't had issues with bluez. _ shrug_

~~~
mikekchar
My bluez problem may be related to using a Microsoft Sculpt keyboard.  Was
running Gentoo for many years on one of my boxes with the same bluetooth
issues.  Mainly bluez works fine if the device doesn't shut down for power
saving.  If it does, then bluez will often refuse to reconnect to it.  I've
tried to debug it but the code is not the most friendly ;-) It seems that the
agent gets in a bad state where it thinks the device is both simultaneously
connected and not connected.  The easiest way to solve the problem is to
restart the bluetooth service, reinitialize the agent and then hit a key on
the keyboard.  Doing _anything_ else will cause it to get in the same bad state
again.  Occasionally you have to remove the device and re-pair. 

Every third update it will just start working and I'll think "Oh they fixed
the bug".  Then the next update breaks it again.  I don't doubt that bluez
_must_ work well for some hardware, but for mine it is practically black magic
to get it working. 

My only point in fingering bluez is to say that bluetooth going down is not a
surprising event on my machine and isn't related to systemd at all.  I suspect
the same is true of the OP's box.  It was probably just a coincidence that
bluetooth died at the same time that systemd was installed. 

~~~
digi_owl
I am guessing the bluetooth radio was connected via USB.  Thing about USB is
that the Linux drivers were built around a misunderstanding regarding the
sleep/suspend of USB devices. 

While the Linux code assumed the hardware was required to be up and ready in 2
minutes or less, the 2 minutes mentioned in the spec was just a suggested
minimum wait time.  Thus it would give up on devices that was still in the
process of powering back on. 

That not to say that bluez have been in great shape in recent years.  But then
it is also a complicated concept for *nix, as it straddles root and user.  You
have their whole pairing interface on the user side, and then all the device
nodes (HID, Audio, etc) on the root side. 

------
generic_user
"System XVI has received unexpected publicity.  Several commentators have
written these glowing endorsements of System XVI:

This is probably the best example I've seen on how NOT to program in C.
Unneeded typedefs, random macros for simple logic.  Do not use." 

Its nice to see a sense of humor and some humility.  There is a healthy
ecosystem of Linux distributions that do not use systemd and have no intention
of doing so.  Slackware, Void, Puppy, Crux and many others. 

~~~
m_mueller
How can people be that dismissive of typedefs and macros in C?  IMO it simply
follows the DRY rule to use these techniques wherever a certain structure is
reused significantly. 

------
X-Istence
It'd be awesome if this was BSD licensed, so that in the future when it is
stable it could appear in FreeBSD as the replacement to it's current initd. 

~~~
fullwedgewhale
Not being BSD license I would expect it never to get beyond the ports tree. 

~~~
X-Istence
Yup, that is my worry too. 

------
616c
It will be interesting to see which takes off, a totally different style, or a
reductionist fork? 

[http://uselessd.darknedgy.net/](http://uselessd.darknedgy.net/)

I am a systemd user and Arch Linux fan (but definitely wanted to get to Gentoo
to have the most choice), but I have been hoping to see news of uselessd pop-
up again. 

I think the reaction to systemd is quite upsetting, for its tone and not its
message about choice which is core to our support of open source values, but I
welcome the alternative solutions and approaches and I am very curious to see
what percolates to the top. 

Personally, as a budding Lisp geek, I wait for dmd. 

[https://www.gnu.org/software/dmd/](https://www.gnu.org/software/dmd/)

Although, and I know I have seen him post here before, the vitriolic systemd
hate on one of his blog posts make me worry about reactionary development,
just like this and other projects. 

I have heard a lot of good about SMF though, so I will need to follow all of
them now. 

~~~
vezzy-fnord
I'm the uselessd author.  It's dead, as I made clear at the top of the wiki
index. 

There will be a successor, though I wasn't expecting SystemXVI to arrive.  I
might just rethink it to be a layer on top of SystemXVI RPC, I don't know yet. 

~~~
wicket
I'm curious to know what it is that you prefer about the design of System XVI
over other alternative init/service management systems.  In particular,
compared to s6 [1], which has similar design goals to System XVI but appears
to be much closer to completion. 

[1] [http://www.skarnet.org/software/s6/](http://www.skarnet.org/software/s6/)

------
lambda
It's systemd, not SystemD.

Also, this is not yet a replacement for systemd:

    
    
      #include <stdio.h>
      
      int main (int argc, char * argv[])
      {
          printf ("defer work on the pid 0 until we have a functioning "
                  "service manager\n");
          return 0;
      }
    

(I think they mean "pid 1")

~~~
0x0
No doubt that "System D" (500) is a play on words against "sys V init" (5)...
"100 times better"!? 

~~~
Redoubts
I think it's just a system daemon. 

~~~
lcr
He might be referencing systemd's site [1]:

>But then again, if all that appears too simple to you, call it (but never
spell it!)  System Five Hundred since D is the roman numeral for 500 (this also
clarifies the relation to System V, right?) 

[1]
[http://www.freedesktop.org/wiki/Software/systemd/](http://www.freedesktop.org/wiki/Software/systemd/)

------
9fb29947
Can we please stop making Linux as a thing about choice[1] and stop
fragmenting the community in the name of following a UNIX philosophy, the rule
of KISS or some other nonsense?  Are we really going to spend lots of energy
the next n years discussing the best init system?  Isn't this a pretty simple
and solved problem by now? 

[1] [http://islinuxaboutchoice.com/](http://islinuxaboutchoice.com/)

~~~
vezzy-fnord
_UNIX philosophy, the rule of KISS or some other nonsense_

How are those things nonsense? 

 _Are we really going to spend lots of energy the next n years discussing the
best init system?_ 

Why the hell shouldn't we? 

 _Isn 't this a pretty simple and solved problem by now?_ 

Nope.  It's actually a very hard problem with little in the way of complete
solutions.  Take your ignorant trolling elsewhere, please. 

~~~
phatfish
It seems to me there only needs to be one init system, otherwise it is a
fragmented mess.  Windows is gaining fast on Linux in the cloud/server space
(SSH support, docker/container support, "Nano Server", more open source
components). 

Windows has no fragmentation issues in the core system. 

Whether it is Systemd or System XVI im not really that bothered.  Something
needs to be decided fast however, and Systemd has a big head start. 

I just hope it dosen't end up like the KDE/Gnome mess. 

One kernel.  One init.  One desktop. 

~~~
vezzy-fnord
The mere _existence_ of alternatives doesn't suddenly transform you from
"unified utopia" to "fragmented dystopian hellhole". 

Windows isn't gaining anything on the demographics that use GNU/Linux for
cloud deployments.  You're reading too many articles on HN and extrapolating
that Windows must be curb stomping its competition because of some smart
business decisions on part of Nadella and co. You're further making the
assumption that Linux _needs_ to compete with Windows.  It doesn't. 

It's not that there is fragmentation, so much as the problem space is quite
open-ended and there are multiple solutions.  Forcing a square peg into a round
hole (systemd ueber alles) is a recipe for impedance mismatch and stagnation,
not unification. 

 _One kernel.  One init.  One desktop._ 

Ein Volk.  Ein Reich.  Ein Fuehrer. 

------
joelthelion
I don't think anyone wants to go through this again. 

~~~
pekk
The problem isn't the argument, the problem is systems that aren't really
wanted being rammed through by political means. 

~~~
moron4hire
You could always start your own distro. 

------
retrogradeorbit
I found this the funniest part:

\-----

/u/TheReverend403, reddit. [...]  the world doesn't like goto.  First of all, it
can cause all kinds of memory leaks. 

Your program is simply an attacker's target. 

As soon as a distro maintainer sees that goto, it'll be rejected. 

\-----

Clearly, TheReverend403 hasn't read any systemd source code. 

systemd$ rgrep goto .  | wc -l

2690

------
kazinator
Nothing written in C, or at least entirely in C, is a viable replacement for
systemd. 

One big problem with systemd is the internals: all the stinky "char *" string
processing which is repeated all over the place and the badly greenspunned OO
programming system that it contains and so forth. 

The kinds of things that systemd does are best written in a high level
language (of course, with suitable bindings for the system calls required). 

Old SysVInit gets away with being written in C because it's small and simple
and just handles the /etc/inittab, which has a simple format.  Anything
complicated is farmed out startup, shutdown and runlevel scripts. 

The way to proceed was to add an extension language to init so that actions
can be written in that language to do more kinds of things. 

Perhaps the executable which runs as PID 1 can be a very tiny "init kernel"
written in C, which intrisically does some of the things that only it can
(like reap processes parented to PID 1), and farms out everything else to a
larger daemon.  This would be for the sake of fault isolation; we don't want
PID 1 to crash.  The risk of that is high if you make it a large and
complicated program, with a large and complicated run-time infrastructure. 

------
mrmondo
I get the feeling that the wheel is being re-invited here again. 

~~~
vezzy-fnord
It really isn't.  SystemXVI is relatively novel as far as init system designs
go.  It's a more modular and pluggable Solaris SMF-like design (no XML
configuration, don't panic), designed for portability at that. 

~~~
mrmondo
Point taken, it would be nice if someone could start a comparison table
between the different init systems, perhaps on Wikipedia? 
[https://en.m.wikipedia.org/wiki/Init](https://en.m.wikipedia.org/wiki/Init)

~~~
JdeBP
See Avery Payne's list at [https://bitbucket.org/avery_payne/supervision-
scripts/wiki/C...](https://bitbucket.org/avery_payne/supervision-
scripts/wiki/Comparison) and
[https://news.ycombinator.com/item?id=10179308](https://news.ycombinator.com/item?id=10179308)

------
benwaffle
>systemd is tightly integrated in a way that makes pluggable replacements
difficult. 

systemd "aims to unify pointless differences between distributions", so
nothing needs replacing

