systemd is obsolete

zirias@

Developer
Ok, this sounds like flamebait. In fact, this is intentional, to draw attention. Sorry for that. In fact, let me start with things this thread should NOT be:
  • Another OS flame. We've seen too much of them, they are boring and people tend to declare others as totally dumb, just because their requirements for an OS differ. No, I do not want THAT in any replies.
  • Discussion on how "Poetterware" in general sucks. This is roughly the same as the first point, but on a different level. I find it equally as boring.
Now, what IS this thread about? I'd just say: technical implications. systemd is the piece of software that brought me to trying out FreeBSD in the first place. Why? Because I feel (as a professional systems architect and software developer) systemd's design is wrong. Most straightforward, it doesn't honour the "separation of concerns" principle. In this thread, I just want to get to know how other people with SOME background in software development / architecture think about systemd. So, please comment :)
 
In May 2014 Poettering himself gave another presentation about systemd: http://0pointer.de/public/gnomeasia2014.pdf.

On page 5 of the above PDF, he answers his own question: "What’s systemd again?"
  1. a system and service manager;
  2. a platform;
  3. the glue between the applications and the kernel.
I guess, this tells it all. People perhaps need/want (1), but get in addition (2) and (3) without being asked for -- (2) and (3), something what nobody needs and perhaps only 50 % of the Linux community wants.

For example, I programmed some tools and daemons and a kernel module for FreeBSD, some of which work on Mac OS X and Linux (RHEL/CentOS 6) with only minor modifications. For me, the platform (2) consists of the system calls and library functions that are provided by the OS, I don't need and want another platform as an additional layer in the middle -- I use some third-party libraries aside. And doing I/O, networking, etc. against the systemd glue (3) instead of directly using the system calls sounds quite funny to me, not to say idiotic.
 
Last edited:
For example, I programmed some tools and daemons and a kernel module for FreeBSD, some of which work on Mac OS X and Linux (RHEL/CentOS 6) with only minor modifications. For me, the platform (2) consists of the system calls and library functions that are provided by the OS, I don't need and want another platform as an additional layer in the middle -- I use some third-party libraries aside. And doing I/O, networking, etc. against the systemd glue (3) instead of directly using the system calls sounds quite funny to me, not to say idiotic.

Wait ... I think the "platform" Poettering is talking about has, of course, a scope! It would be indeed silly using yet another layer for open(2). That's clearly what libc is for. So with platform, he probably refers to the dbus interfaces provided for the functionalities of systemd. So even with (3), he probably refers to features NOT covered by libc, because they are not standard.

This would be ok, the main concern about it being: the scope is just too HUGE. For me, even a "system and service manager" should do its work independent of init. init, as the very first userland process, that's ALWAYS running when the system is up, should be as simple and minimal as possible.


Clicking through this presentation, there are quite mixed feelings:
  • The idea of a centralized notification daemon feels right. This is cool (and: needed) functionality, and it is still following the principle of doing ONE job.
  • The idea of a centralized configuration, using plist, on the other hand -- I think this is completely wrong. Why? Well it's a lot of complexity, many existing software has to be changed, and I just can't see the benefit that's worth the hassle.
  • For the init system, it's probably true there IS nowadays a problem with classical sysvinit. It's just -- the solutions suggested so far do not "nail it", in my point of view.
 
I don't think the Jordan Hubbard video mentions once that FreeBSD is actually getting launchd, he just describes some of the issues they had to solve at Apple. They took a UNIX-like OS, with FreeBSD userland, and managed to make it compete globally with Windows, even on the tricky things like making it run ten hours on a battery. The talk actually gives some clues as to why Linux have gone and replaced the core functions of the OS with a single daemon (not that I'm agreeing that systemd is the best way to do it). It's difficult (if not impossible) for a system to be as efficient as possible when every subsystem is controlled effectively by stand-alone scripts.

The only thing actually being worked on from that talk is the 'lego' idea. There is now a building-blocks project with the intention of making pretty much every non-critical component of the system optional in the build process. Obviously this is good for the reasonably large and growing embedded market, and hopefully shouldn't really make any difference to existing users.

I'm pretty sure all the "it's not UNIX / separation of concerns" complaints are falling on deaf ears with Linux. I don't think the core people behind Linux, and definitely the GUI-first distributions, have any real interest in staying true to UNIX philosophies. It's likely Linux was only UNIX/POSIX compatible in the first place because it wouldn't have been any real use otherwise. It would have made no sense to start a new OS that supported only software designed specifically for it. These days pretty much every third-party *NIX project is developed for Linux first, then ported to others. They are at the point where they can make large architecture changes and the rest of the ecosystem will follow them.

I'm not a Linux user so I can't comment fully on systemd. From the Hubbard talk, I can understand some of the reasons why they'd feel it a benefit to have a single daemon controlling the system although it may have grown a bit too large too quickly. I don't like the idea of binary logs either. There's probably other things I wouldn't like if I looked into it but I haven't really felt the need to.
 
"uses socket and dbus" In the first paragraph of an exceedingly long wiki page, filled with entirely new terminology I at least would be vary wary of ever learning half of. Not to mention every recommending in an email to anyone... "replaces init". Using FreeBSD many years, I've only maybe read the man page for the latter a few times and never actually to my recollection ran the command. The "tips and tricks" page I just read I could not ever imagine replacing FreeBSD's equivalents as something useful, except in a few rare instances, ... ditto for the FAQ at that site...
Worse, the "boot problems" very informative page appears at first glance to require much more expertise and "no guarantee of recovery"... this ignoring all the things that can go wrong with, say, grub upon a kernel upgrade...
Not to mention obsoleting the expertise already present with the equivalents in FreeBSD which would evaporate...
 
I find it more troubling that FreeBSD is getting launchd: http://www.slideshare.net/iXsystems/jordan-hubbard-free-bsd-the-next-10-years and that there are people in the FreeBSD camp who believe that FreeBSD should adopt PLists for configuration files. That is so anti-UNIX.

Linux on the another hand is beyond hope from a UNIX point of view.

That's not a "we are bringing over launchd" presentation. It's a "we need something like launchd" presentation. There are no hard-n-fast promises or even directions in that presentation. There are no plans to replace RCng in FreeBSD at this time.
 
So my "stupid rant" somehow even spawned valuable insight. Okay then, most "technical" people agree that something like a "services manager" for Unix systems would be a good idea. That's probably the point to start thinking about "design goals"? Now we have forks that strip down systemd to a minimum (thinking about uselessd here), distribution fork ideas for Debian that most don't take serious because they look a little like pissed-off kids, and people like me trying to "run away" to another *nix system. What I'd be interested in is: could we, to a certain extent, agree what systemd is doing wrong, and how the need for a "services manager" could be fulfilled in a better way?
 
there are people in the FreeBSD camp who believe that FreeBSD should adopt PLists for configuration files. That is so anti-UNIX.

I agree, if only because they are hard to parse with traditional tools. You need to use Python/Perl/Ruby/etc. and libraries to parse/modify them, which is a lot of programming overhead for system administration.
 
I don't think the Jordan Hubbard video mentions once that FreeBSD is actually getting launchd, he just describes some of the issues.....The only thing actually being worked on from that talk is the 'lego' idea. There is now a building-blocks project with the intention of making pretty much every non-critical component of the system optional in the build process. Obviously this is good for the reasonably large and growing embedded market, and hopefully shouldn't really make any difference to existing users.

That's an important point. I think that if FreeBSD developers stick to that "lego" idea it can't go very far wrong no matter what init and supervision technologies are adopted.

I come from a decade of using Linux and spent a couple of those years building my own variant, attempting to get a system that was capable of building itself up from sources in a bare chroot, and for which the "options" provided by the source code (e.g. the option to support NLS or openSSL, or not) were all exposed to the user and were actually options in the system (i.e. to actually take advantage of having "open source"). In Linux that is a difficult problem. In the Linux ecosystem each "distro" is dependent on almost the totality of itself: you can build new versions of packages only within a running system that has the whole system. The smallest starting point is a pre-existing binary image that contains hundreds or even more than a thousand packages. Even Gentoo now can only be developed by starting with a "Stage 3 tarball" that installs about 500 MB of executables and libraries. In a Linux distro it is difficult to cross-compile the system, and creation of static binaries is not supported. Updating the toolchain can be hazardous. A modern Linux system is like the American electrical grid, the system depends upon _itself_. If it were to "go down" completely no one knows how to bring it back up.

This really came home to me when I tried to develop tools and a process for building a rather standard Linux distro (Archlinux) starting with just a basic toolchain (a libc, binutils, a compiler). It was very difficult because the core of a Linux distro is rife with cyclic dependencies. They don't bother to address those cyclic dependencies as layering violations nor do they develop a build process for working around them. So even though a LInux distro is Just a Pile of Packages and a Kernel, thousands of independently developed packages cobbled together by the "distro", the user/developer can't treat them as independent. (For example, you can't build and install packages without a package manager but the package manager generally depends on much higher levels than just the toolchain. In Gentoo portage depends on python, amongst other high level things, and in Arch pacman depends on gpgme/gnupg etc.. It's hard to bootstrap such a system. It's hard to make fundamental changes.)

When I threw systemd into the mix the layering violations became much worse (e.g. systemd pulls in dbus, which depends on systemd). Actually I hit a brick wall in trying to build a modern Linux system, with a package manager, starting from the toolchain and c library. Of course it is possible to build a small specialized or even embedded linux system that does build static toolchains and can be built from the ground up, e.g. Sabotage Linux that uses a homebrew package manager that requires only the toolchain, and can build static binaries. Such Linux projects are very marginal, generally die after a short time, and are not where Linux is heading.

After a decade I came back to BSD. As I did a decade ago, I was able to "svn checkout" the latest FreeBSD src and ports and build my complete system from source code with options needed for my goal, only this time with a very nice ZFS mirror filesystem. Here I have the advantage that the system, even if distributed as a complete graphical system by PCBSD folks, is always built from the toolchain up, the build process automatically builds the intermediate cross-tools (in /src/obj) and allows complete freedom to take advantage of the source code, and without layering violations. Here it is a natural result of the process that options in the source code can be given "knobs" so that the optional features are exposed and the "lego" nature of the architecture makes evolution always possible. In other words, it still seems to have the advantage of being Unix and I hope that evolution of FreeBSD will continue to have that building block nature. It seems to me that systemd is NOT a building block; it is intent on being The System, as if it were invented by a corporation whose main source of income were the U.S. Navy and the NSA.
 
Hi All,

Thank you for this informed discussion on FreeBSD and systemd.

Mea Culpa:
I stopped using FreeBSD at 4.11 because of the SMP war and Linux support for SMP. At the time I was doing small scale "High Performance Computing" and I needed to move to linux for desktop support for things like X, and OpenOffice (StarOffice 5). These tools were critical for my daily work in real world work environments where everyone was sending Word(tm) documents, Excel(tm) etc. I'm not actually a fan of that approach - but it is the cold hard reality of paid scientific work - another reality was that I simply would not use MS windows, Ever... That was 2005.

Now, at the end of 2016, I have been working on "Embedded Computing" and using some realtime features and have found that Linux systems have so much nonsense going on in the background that it acts like windows with drags and hangs while GBs of wired RAM flops in and out of swap with mountains of layered, wrapped, virtualized function calls ala Windows(tm). It is absurd how large these systems have become. Modern chips have monster bandwidth - but I can literally type faster than an xterm can follow the keyboard. This is insane. (Note: I'm working with CPUs in the 2Core/1GHz/1GB class)

The flack over systemd and the binary config system has convinced me that the direction of Linux is just what LINUX stands for: "Linux Is Not UniX" - I am convinced that this is a fact. Linux is just a kernel, there never has been an actual Linux OS, not even DebIan can claim that title.

I've had enough Linux/systemd/binary-config
 
There's nothing wrong with database configuration, AIX is a testament to that, but it's pretty clear that systemd is behind the times.

Svchost, on Windows, can survive being killed, in fact it has several processes running at once.

Systemd assumes that it's code is perfect and that exploits to the PID 1 binary, that is init and process manager, are impossible. This is bad design 101. No matter how much you bury it under mandatory access controls, namespaces, privilege separation, and other security systems you can't ignore the problems this oversight could present.
 
Personally I wouldn't mind an improved start up process, as long as it keeps the old approach in mind and remains backwards compatible. A bit comparable to what Sun did with Solaris 10's service manager. Although it used a complete hierarchy where each process was configured in an XML based manifest it still remained backwards compatible by allowing use of the regular startup scripts (/etc/rc.d if I recall correctly, it's been 4 - 5 years or so since I last worked on Solaris).

And there are definitely some positive things to mention about using a service manager. For example the way it can monitor services and act whenever one gets stopped unexpectedly.
 
I l
Ok, this sounds like flamebait. In fact, this is intentional, to draw attention. Sorry for that. In fact, let me start with things this thread should NOT be:
  • Another OS flame. We've seen too much of them, they are boring and people tend to declare others as totally dumb, just because their requirements for an OS differ. No, I do not want THAT in any replies.
  • Discussion on how "Poetterware" in general sucks. This is roughly the same as the first point, but on a different level. I find it equally as boring.
Now, what IS this thread about? I'd just say: technical implications. systemd is the piece of software that brought me to trying out FreeBSD in the first place. Why? Because I feel (as a professional systems architect and software developer) systemd's design is wrong. Most straightforward, it doesn't honour the "separation of concerns" principle. In this thread, I just want to get to know how other people with SOME background in software development / architecture think about systemd. So, please comment :)

I left linux exactly because of systemd so....
 
ath0, very interesting, thank you. The more I read about this particular pice of software, the more I am loosing interest in Linux as a system. The kernel may be good, no doubt. But the userland is what I meant with the kindergarten development model. I am waiting for the next big ooopsie from that crowd.

BTW, reading other posts on that blog makes for more enlightment and smiles. Bookmarked.
 
Back
Top