11 ms·

System XVI: A replacement for systemd

191 points by vmorgulis 11y ago

joelthelion 11y ago
I don't think anyone wants to go through this again.
- esaym 11y ago
  +1 seriously
- pekk 11y ago
  The problem isn't the argument, the problem is systems that aren't really wanted being rammed through by political means.
  - moron4hire 11y ago
    You could always start your own distro.
- vezzy-fnord 11y ago
  Elaborate?
  - bjackman 11y ago
    He's referring to the fact that systemd was (is) very controversial when it was announced as a replacement for SystemV init. There were _lots_ of flamewars and hyperbole and when Debian announced they were making systemd their only init, it sparked a fork: http://debianfork.org/ http://debianfork.org/ It seems like a lot of people are calming down about the issue now.. so lets not do all that again
    - vezzy-fnord 11y ago
      I wasn't born yesterday, I know that. In fact, I helped fan the flames by making uselessd, though not out of any sly intent in the least, but research curiosity. My question was more about the GP elaborating why a new system would be something "[no one] wants to go through this again." (I'd characterize systemd as being a sysvinit replacement to be a great misnomer. It's not. It's an entire framework for providing certain low-level userspace daemons, utilities and auxiliaries meant as a common middleware for GNU/Linux distributions. Even systemd-the-PID1 cannot be called a sysvinit replacement in any integrity.)
      - esaym 11y ago
        >My question was more about the GP elaborating why a new system would be something "[no one] wants to go through this again." Because the migration was terrible that is why. And I still continue to find stuff I hate about systemd. The latest was just yesterday, while troubleshooting some disk issues I wanted to fsck root before rebooting. Which normally means just remount root as read-only. Tried that and it didn't work, "disk was busy". Jumped into runlevel 1, still disk was busy. Rebooted into rescue mode, remount ro, still disk busy. After googling and digging through lsof, I could see it was systemd processes and journal that was holding onto files and preventing a remount. Tried killing systemd, journald, even kill -9, it just restarts it self and holds the disk. Darn. Did the touch /forcefsck trick, rebooted, yet no fsck. Darn again. More googling later, I see you have pass kernel parameters at boot time to force a fsck, and no, you can't select which FS either, it just does all of them. Rebooted again, fsck is running of course. I just wanted root checked but now it is doing all my terabyte partitions as well. Gave up at this point and just left the machine and hoped for the best.
        lisivka 11y ago
        I hate it too, but workaround is not too hard: chmod a-x journald && pkill journald of course, it is bad idea to touch damaged FS before fsck.
        simoncion 11y ago
        Wait. To run an unscheduled fsck of your root fs (and only your root fs), you have to remove the execute bit from a systemd component, kill that component, then remember to reset the bit after you're done? That's nuts.
    - UnoriginalGuy 11y ago
      I think Linus Torvalds coming out in support of systemd helped a lot (or at least confused the UNIX purists enough to calm them down a little). Linus response from [0]: > I have to say, I don't really get the hatred of systemd. I think it improves a lot on the state of init, and no, I don't see myself getting into that whole area. > Yeah, it may have a few odd corners here and there, and I'm sure you'll find things to despise. That happens in every project. I'm not a huge fan of the binary logging, for example. But that's just an example. I much prefer systemd's infrastructure for starting services over traditional init, and I think that's a much bigger design decision. > Yeah, I've had some personality issues with some of the maintainers, but that's about how you handle bug reports and accept blame (or not) for when things go wrong. If people thought that meant that I dislike systemd, I will have to disappoint you guys. [0] http://linux.slashdot.org/story/15/06/30/0058243/interviews-linus-torvalds-answers-your-question http://linux.slashdot.org/story/15/06/30/0058243/interviews-...
      - simoncion 11y ago
        I'm not sure that Torvalds says that he likes systemd. I read the quote as saying: "I don't dislike systemd, and I think that it is better than traditional init.". Almost anything [0] is better than SysV init. shrug [0] Upstart, OpenRC, daemontools...
        JdeBP 11y ago
        Strictly speaking, of those three only upstart is actually a replacement for System 5 init. OpenRC and daemontools run under an init, and by and large replace System 5 rc. There are two toolsets (soon to be three) in the daemontools family that provide a replacement for init: nosh and runit. daemontools itself does not, and has had more than a decade of people adapting it to run under init replacements because the vanilla system only targets late 1990s inits, including under upstart as a matter of fact. * http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/daemontools-family.html http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/da... * http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/inittab-is-history.html http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/in... * http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/system-5-rc-problems.html http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/sy...
markbnj 11y ago
Props to the author for posting the "testimonials." Got a chuckle out of it. Did not look at the code.
- politician 11y ago
  Right, yeah, well, now I'm not sure if this is a joke/troll project.
  - generic_user 11y ago
    Its a real project. And there is a few other projects OpenRC etc. The longevity of Unix over the years has been its highly modular architecture. You can simply rip a daemon out and replace it with a new one. I don't think any attempt to create a monoculture will win favour in the long run. Even if Linux is utterly consumed the result would be a shift to Bsd.
- nkurz 11y ago
  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/app/restartd/unit.c https://github.com/ServiceManager/ServiceManager/blob/master...
  - frozenport 11y ago
    4/10 needs more RAII :P
  - AndyKelley 11y ago
    I agree with the comment about overusing macros though. Instead of: #define DbgEnteringState(x) \ printf ("[%s] Unit entering state %s\n", unit->name, #x); How about: static void dbg_entering_state(unit_t * unit, const char * state_name) { fprintf (stderr, "[%s] Unit entering state %s\n", unit->name, state_name); } Friendlier to humans reading code, IDEs, and debuggers. I went ahead and fixed it writing to the wrong stdio stream too.
lambda 11y ago
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")
- deleted 11y ago
  [deleted]
- vmorgulis 11y ago
  You're right for the name. Thank you.
- anth1y 11y ago
  They could be talking about pid 0 : https://en.wikipedia.org/wiki/Process_identifier https://en.wikipedia.org/wiki/Process_identifier (See swapper or schedule)
- 0x0 11y ago
  No doubt that "System D" (500) is a play on words against "sys V init" (5)... "100 times better"!?
  - Redoubts 11y ago
    I think it's just a system daemon.
    - lcr 11y ago
      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/
generic_user 11y ago
"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 11y ago
  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.
vezzy-fnord 11y ago
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/doc/DESIGN.md https://github.com/ServiceManager/ServiceManager/blob/master... (Flowchart: https://github.com/ServiceManager/ServiceManager/blob/master/doc/s16.png https://github.com/ServiceManager/ServiceManager/blob/master...) 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.
nteon 11y ago
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_.
- vezzy-fnord 11y ago
  /sbin/init shouldn't read files. A dedicated configuration parser should, and so it is done here. SystemXVI will have systemd unit file compatibility. SystemXVI natively uses an INI-like file format itself. SystemXVI uses SunRPC for communication. Writing a systemctl wrapper could be as trivial as a shell script. But until then, the world will continue to run on systemd, because it _works_ The world doesn't run on systemd, and it isn't a "just works" thing in the slightest.
  - keithpeter 11y ago
    "The world doesn't run on systemd, and it isn't a "just works" thing in the slightest." Redhat are betting their particular farm on systemd in RHEL7, and Debian (hence recent Ubuntu releases building to the 16.04 LTS) has adopted the suite. Is the point you are making above based on the percentage of servers running earlier supported Linux implementations or on the existence of alternatives such as the BSDs?
    - weland 11y ago
      > Redhat are betting their particular farm on systemd in RHEL7 It's basically their product, so... > and Debian (hence recent Ubuntu releases building to the 16.04 LTS) has adopted the suite. I think Ubuntu adopting systemd has less to do with Debian doing so and more to do with Gnome becoming increasingly difficult to package without systemd.
    - tw04 11y ago
benwaffle 11y ago
>systemd is tightly integrated in a way that makes pluggable replacements difficult. systemd "aims to unify pointless differences between distributions", so nothing needs replacing
mrmondo 11y ago
I get the feeling that the wheel is being re-invited here again.
- vezzy-fnord 11y ago
  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 11y ago
    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 11y ago
      See Avery Payne's list at https://bitbucket.org/avery_payne/supervision-scripts/wiki/Comparison https://bitbucket.org/avery_payne/supervision-scripts/wiki/C... and https://news.ycombinator.com/item?id=10179308 https://news.ycombinator.com/item?id=10179308
- moron4hire 11y ago
  I can think of at least five times in the 20th century alone that the wheel was successfully and usefully reinvented.
- sparkie 11y ago
  We've also reinvented a car to go with our reinvented wheel, but we've also made is so the car is useless unless you use our wheels, and by virtue of having no other function, the wheel is also pretty useless unless you use it with our car. But don't fret. Our car will provide you with it's own desktop built into the dashboard. Our car can communicate other cars, but only those of the same model, and even if our car doesn't have support for something you need yet, don't worry, as we'll build it directly into your car soon!
X-Istence 11y ago
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 11y ago
  Not being BSD license I would expect it never to get beyond the ports tree.
  - X-Istence 11y ago
    Yup, that is my worry too.
- JdeBP 11y ago
  Both nosh and NextBSD launchd are BSD licensed.
  - X-Istence 11y ago
    I really like that it takes some things from SMF. I honestly don't think that porting all of Mach over just to get launchd is a great idea...
    - Alphasite_ 11y ago
      Its only the IPC layer...
      - JdeBP 11y ago
        ... and it is thus in the same boat as systemd. The IPC layer for getting launchd to work involves amongst other things FreeBSD kernel changes to support the Mach IPC API; similarly to how the systemd people have already achieved (subreapers) and have been pushing for further (kernel Desktop Bus) kernel changes for systemd's benefit; and indeed much like how IBM AIX gained kernel augmentations for supporting the System Resource Controller: the SIGFORCE and SIGNORM signals and the SRC_kex.ext extension. vezzy-fnord is I suspect refraining from pointing to http://blog.darknedgy.net/technology/2015/08/26/0/ http://blog.darknedgy.net/technology/2015/08/26/0/ (https://news.ycombinator.com/item?id=10127120 https://news.ycombinator.com/item?id=10127120). (-:
616c 11y ago
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 11y ago
  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 11y ago
    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/
  - 616c 11y ago
    Well, I look like an idiot. I guess I should moved beyond the landing page (if that is not the wiki index page). Well, either way, I wish you luck. You Github testimonials at the bottom of the SystemXVIREADME were very entertaining. I am glad you have thick skin. You will need it, and I cannot wait to see real competitors in this space beyond SysVinit, runit, and of course the dreaded systemd.
9fb29947 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      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.
Snesker 11y ago
without-systemd.org/wiki/index.php/Arguments_against_systemd obligatory
kazinator 11y ago
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.
retrogradeorbit 11y ago
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

191 points by vmorgulis 11y ago

joelthelion 11y ago

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

esaym 11y ago
+1 seriously
pekk 11y ago
The problem isn't the argument, the problem is systems that aren't really wanted being rammed through by political means.
- moron4hire 11y ago
  You could always start your own distro.
vezzy-fnord 11y ago
Elaborate?
- bjackman 11y ago
  He's referring to the fact that systemd was (is) very controversial when it was announced as a replacement for SystemV init. There were _lots_ of flamewars and hyperbole and when Debian announced they were making systemd their only init, it sparked a fork: http://debianfork.org/ http://debianfork.org/ It seems like a lot of people are calming down about the issue now.. so lets not do all that again
  - vezzy-fnord 11y ago
    I wasn't born yesterday, I know that. In fact, I helped fan the flames by making uselessd, though not out of any sly intent in the least, but research curiosity. My question was more about the GP elaborating why a new system would be something "[no one] wants to go through this again." (I'd characterize systemd as being a sysvinit replacement to be a great misnomer. It's not. It's an entire framework for providing certain low-level userspace daemons, utilities and auxiliaries meant as a common middleware for GNU/Linux distributions. Even systemd-the-PID1 cannot be called a sysvinit replacement in any integrity.)
    - esaym 11y ago
      >My question was more about the GP elaborating why a new system would be something "[no one] wants to go through this again." Because the migration was terrible that is why. And I still continue to find stuff I hate about systemd. The latest was just yesterday, while troubleshooting some disk issues I wanted to fsck root before rebooting. Which normally means just remount root as read-only. Tried that and it didn't work, "disk was busy". Jumped into runlevel 1, still disk was busy. Rebooted into rescue mode, remount ro, still disk busy. After googling and digging through lsof, I could see it was systemd processes and journal that was holding onto files and preventing a remount. Tried killing systemd, journald, even kill -9, it just restarts it self and holds the disk. Darn. Did the touch /forcefsck trick, rebooted, yet no fsck. Darn again. More googling later, I see you have pass kernel parameters at boot time to force a fsck, and no, you can't select which FS either, it just does all of them. Rebooted again, fsck is running of course. I just wanted root checked but now it is doing all my terabyte partitions as well. Gave up at this point and just left the machine and hoped for the best.
      - lisivka 11y ago
        I hate it too, but workaround is not too hard: chmod a-x journald && pkill journald of course, it is bad idea to touch damaged FS before fsck.
        simoncion 11y ago
        Wait. To run an unscheduled fsck of your root fs (and only your root fs), you have to remove the execute bit from a systemd component, kill that component, then remember to reset the bit after you're done? That's nuts.
  - UnoriginalGuy 11y ago
    I think Linus Torvalds coming out in support of systemd helped a lot (or at least confused the UNIX purists enough to calm them down a little). Linus response from [0]: > I have to say, I don't really get the hatred of systemd. I think it improves a lot on the state of init, and no, I don't see myself getting into that whole area. > Yeah, it may have a few odd corners here and there, and I'm sure you'll find things to despise. That happens in every project. I'm not a huge fan of the binary logging, for example. But that's just an example. I much prefer systemd's infrastructure for starting services over traditional init, and I think that's a much bigger design decision. > Yeah, I've had some personality issues with some of the maintainers, but that's about how you handle bug reports and accept blame (or not) for when things go wrong. If people thought that meant that I dislike systemd, I will have to disappoint you guys. [0] http://linux.slashdot.org/story/15/06/30/0058243/interviews-linus-torvalds-answers-your-question http://linux.slashdot.org/story/15/06/30/0058243/interviews-...
    - simoncion 11y ago
      I'm not sure that Torvalds says that he likes systemd. I read the quote as saying: "I don't dislike systemd, and I think that it is better than traditional init.". Almost anything [0] is better than SysV init. shrug [0] Upstart, OpenRC, daemontools...
      - JdeBP 11y ago
        Strictly speaking, of those three only upstart is actually a replacement for System 5 init. OpenRC and daemontools run under an init, and by and large replace System 5 rc. There are two toolsets (soon to be three) in the daemontools family that provide a replacement for init: nosh and runit. daemontools itself does not, and has had more than a decade of people adapting it to run under init replacements because the vanilla system only targets late 1990s inits, including under upstart as a matter of fact. * http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/daemontools-family.html http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/da... * http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/inittab-is-history.html http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/in... * http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/system-5-rc-problems.html http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/sy...

markbnj 11y ago

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

politician 11y ago
Right, yeah, well, now I'm not sure if this is a joke/troll project.
- generic_user 11y ago
  Its a real project. And there is a few other projects OpenRC etc. The longevity of Unix over the years has been its highly modular architecture. You can simply rip a daemon out and replace it with a new one. I don't think any attempt to create a monoculture will win favour in the long run. Even if Linux is utterly consumed the result would be a shift to Bsd.
nkurz 11y ago
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/app/restartd/unit.c https://github.com/ServiceManager/ServiceManager/blob/master...
- frozenport 11y ago
  4/10 needs more RAII :P
- AndyKelley 11y ago
  I agree with the comment about overusing macros though. Instead of: #define DbgEnteringState(x) \ printf ("[%s] Unit entering state %s\n", unit->name, #x); How about: static void dbg_entering_state(unit_t * unit, const char * state_name) { fprintf (stderr, "[%s] Unit entering state %s\n", unit->name, state_name); } Friendlier to humans reading code, IDEs, and debuggers. I went ahead and fixed it writing to the wrong stdio stream too.

lambda 11y ago

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")

deleted 11y ago
[deleted]
vmorgulis 11y ago
You're right for the name. Thank you.
anth1y 11y ago
They could be talking about pid 0 : https://en.wikipedia.org/wiki/Process_identifier https://en.wikipedia.org/wiki/Process_identifier (See swapper or schedule)
0x0 11y ago
No doubt that "System D" (500) is a play on words against "sys V init" (5)... "100 times better"!?
- Redoubts 11y ago
  I think it's just a system daemon.
  - lcr 11y ago
    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/

generic_user 11y ago

"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 11y ago
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.

vezzy-fnord 11y ago

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/doc/DESIGN.md https://github.com/ServiceManager/ServiceManager/blob/master... (Flowchart: https://github.com/ServiceManager/ServiceManager/blob/master/doc/s16.png https://github.com/ServiceManager/ServiceManager/blob/master...) 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.

nteon 11y ago

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_.

vezzy-fnord 11y ago
/sbin/init shouldn't read files. A dedicated configuration parser should, and so it is done here. SystemXVI will have systemd unit file compatibility. SystemXVI natively uses an INI-like file format itself. SystemXVI uses SunRPC for communication. Writing a systemctl wrapper could be as trivial as a shell script. But until then, the world will continue to run on systemd, because it _works_ The world doesn't run on systemd, and it isn't a "just works" thing in the slightest.
- keithpeter 11y ago
  "The world doesn't run on systemd, and it isn't a "just works" thing in the slightest." Redhat are betting their particular farm on systemd in RHEL7, and Debian (hence recent Ubuntu releases building to the 16.04 LTS) has adopted the suite. Is the point you are making above based on the percentage of servers running earlier supported Linux implementations or on the existence of alternatives such as the BSDs?
  - weland 11y ago
    > Redhat are betting their particular farm on systemd in RHEL7 It's basically their product, so... > and Debian (hence recent Ubuntu releases building to the 16.04 LTS) has adopted the suite. I think Ubuntu adopting systemd has less to do with Debian doing so and more to do with Gnome becoming increasingly difficult to package without systemd.
  - tw04 11y ago

benwaffle 11y ago

>systemd is tightly integrated in a way that makes pluggable replacements difficult. systemd "aims to unify pointless differences between distributions", so nothing needs replacing

mrmondo 11y ago

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

vezzy-fnord 11y ago
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 11y ago
  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 11y ago
    See Avery Payne's list at https://bitbucket.org/avery_payne/supervision-scripts/wiki/Comparison https://bitbucket.org/avery_payne/supervision-scripts/wiki/C... and https://news.ycombinator.com/item?id=10179308 https://news.ycombinator.com/item?id=10179308
moron4hire 11y ago
I can think of at least five times in the 20th century alone that the wheel was successfully and usefully reinvented.
sparkie 11y ago
We've also reinvented a car to go with our reinvented wheel, but we've also made is so the car is useless unless you use our wheels, and by virtue of having no other function, the wheel is also pretty useless unless you use it with our car. But don't fret. Our car will provide you with it's own desktop built into the dashboard. Our car can communicate other cars, but only those of the same model, and even if our car doesn't have support for something you need yet, don't worry, as we'll build it directly into your car soon!

X-Istence 11y ago

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 11y ago
Not being BSD license I would expect it never to get beyond the ports tree.
- X-Istence 11y ago
  Yup, that is my worry too.
JdeBP 11y ago
Both nosh and NextBSD launchd are BSD licensed.
- X-Istence 11y ago
  I really like that it takes some things from SMF. I honestly don't think that porting all of Mach over just to get launchd is a great idea...
  - Alphasite_ 11y ago
    Its only the IPC layer...
    - JdeBP 11y ago
      ... and it is thus in the same boat as systemd. The IPC layer for getting launchd to work involves amongst other things FreeBSD kernel changes to support the Mach IPC API; similarly to how the systemd people have already achieved (subreapers) and have been pushing for further (kernel Desktop Bus) kernel changes for systemd's benefit; and indeed much like how IBM AIX gained kernel augmentations for supporting the System Resource Controller: the SIGFORCE and SIGNORM signals and the SRC_kex.ext extension. vezzy-fnord is I suspect refraining from pointing to http://blog.darknedgy.net/technology/2015/08/26/0/ http://blog.darknedgy.net/technology/2015/08/26/0/ (https://news.ycombinator.com/item?id=10127120 https://news.ycombinator.com/item?id=10127120). (-:

616c 11y ago

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 11y ago
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 11y ago
  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/
- 616c 11y ago
  Well, I look like an idiot. I guess I should moved beyond the landing page (if that is not the wiki index page). Well, either way, I wish you luck. You Github testimonials at the bottom of the SystemXVIREADME were very entertaining. I am glad you have thick skin. You will need it, and I cannot wait to see real competitors in this space beyond SysVinit, runit, and of course the dreaded systemd.

9fb29947 11y ago

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 11y ago
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 11y ago
  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 11y ago
    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.

Snesker 11y ago

without-systemd.org/wiki/index.php/Arguments_against_systemd obligatory

kazinator 11y ago

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.

retrogradeorbit 11y ago

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