The Systemd Chronicles
suckless.org
suckless.org
The original submission title, while editorialized, was pretty apt in my opinion. There really does seem to be a core group of people involved with the GNOME, RedHat, and systemd projects that seem to want to add features just for the sake of adding features, or perhaps so that they have something to claim ownership of. Gnome basically decided that text-basd configuration was too sane and opted for a mix of config files and the Windows Registry (gconf, dconf) which is a hilariously poor design choice. One-size-fits-all doesn't work unless you are Apple and your users will happily swallow your marketing BS and wait in line to buy a new iphone every 2 years.
The startup world is rife with the notions of "out with the old, in with the new" and "change for change's sake" so it's not surprising to me that a great deal of HN readers are Poettering apologists.
But to me, it sure seems like systemd is just a chance for Poettering and some others to pad their resumés, or else perhaps simply an ego trip. I honestly can't find anything about it that makes me go "hmm, that's a good feature that outweighs all the other negative parts".
It's theoretically meant to be general-purpose, but it really shines at virtualized deployments and some desktops because of the multi-seat integration (though logind these days has some power management features that is just as relevant for servers).
systemd-nspawn was created to provide rapid testing of systemd, and it was (and, for now, still is) marked as an experimental utility that isn't for production purposes.
If you look at many of the early blog posts mentioning systemd and containers/VMs, you'll actually see my work and my company (Pantheon) mentioned more than Red Hat. In more recent posts, you'll see lots of CoreOS influence. Project Atomic isn't working with systemd in any direct, significant way; you won't see much coordination other than in some shared philosophy about a stateless base OS, and even that is more attributable to CoreOS's influence than Red Hat's.
I think the influence of Red Hat on systemd is overstated. Of the two perspectives: (1) Red Hat driving everything and (2) Lennart answering mostly to himself, the latter is way more accurate, for better or worse (depending on your opinion of him).
As for:
and it was (and, for now, still is) marked as an experimental utility that isn't for production purposes.
rkt used nspawn for a while, and it's still systemd-based.
The fact that Lennart was giving out presentations about nspawn specifically makes me believe it's very much intended to be used in production, as a "chroot on steroids".
This is a recent development -- and why I put the caveat "for now." systemd-nspawn is probably going to be marked production-ready quite soon, especially because it's the foundation for the CoreOS Rocket container tool.
Like many of the other points, this one is plain incorrect.
> When the user presses Ctrl-Alt-Del more than 7x within 2s an immediate reboot is triggered. This useful if shutdown is hung and is unable to complete, to expedite the operation. Note that this kind of reboot will still unmount all file systems, and hence should not result in fsck being run on next reboot.
Systemd is reboots your system quickly if you press it multiple times. Ctrl-Alt-Del still reboots your system.
> floppy group removed > Because we know what is right to know about groups. This is just one example of the mass of group name dependencies systemd is adding. See sinit for how to not need such dependencies.
WTF? systemd is removing an obsolete group, not adding one.
> systemd-pm > Power management is required on boot up.
You're right in this one and it's a GoodThing(tm). Hopefully we might see better hibernate and sleep support.
> factory reset > Welcome to the Windows OEM world: Factory reset for Linux! Of course it is in your init process.
Yes, all features of Windows are BadThings(tm).
Actually, it triggers a script. which should "typically" point at the reboot script. It might not, though.
So, if you absolutely want to reboot, you have to do the 8x ctl-alt-delete
http://www.freedesktop.org/software/systemd/man/systemd.spec...
ctrl-alt-del.target
systemd starts this target whenever Control+Alt+Del is pressed on the console. Usually this should be aliased (symlinked) to reboot.target.
> WTF? systemd is removing an obsolete group, not adding one.
Deleting groups is a bigger problem than adding groups, since it can cause subtle errors in Linux. Deleting a long existing group can break software which depends on it (rightly or not), and if its GID is re-used for another group, other pieces of software can start quietly doing the wrong thing.
> You're right in this one and it's a GoodThing
The problem is that it's another thing which can break at startup, and is now in the critical path to system stability. Suckless promotes simplicity, this is not simple.
> Yes, all features of Windows are BadThings
When in the critical path for system stability? Yes. I like quite a few different windows functionality points myself, but having those things suddenly moved from a relatively safe "child of PID 1" to the system critical "PID 1", they have to work perfectly, every time. Needless to say, they don't.
Systemd is not deleting any groups.
> Actually, it triggers a script. which should "typically" point at the reboot script. It might not, though.
The world might end.
I appreciate a lot of suckless work, but I don't see what this is adding.
It just reeks of fanboy drivel, not a well-reasoned analysis taking into account multiple viewpoints. This is the type of content I would expect on Reddit or Slashdot, but not HN.
> Systemd was introduced to decrease the boot up time. Now that they do not understand all implications and dependencies, let us add some artifical time we found out might work for the developers laptops. More on this small world hypothesis of the systemd devleopers below.
systemd was not introduced to decrease boot time; it was introduced to properly manage dependencies and parallelism. Such an approach happens to massively improve boot times in many cases, but that's a side-effect. The delay introduced is specifically to account for the slow/unreliable initialization of certain docking station hardware that has no other known reliable method for detection. (This is what happens in Linux with certain reverse-engineered hardware.) Importantly, this delay doesn't impact boot time, only introduces a delay before allowing the system to sleep, so even the (made up) point about systemd being about boot times isn't affected here.
> Screen brightness is something that should crash your boot up when it is not working.
The TODO item is about avoiding restoration of screen brightness at boot to such a low level that some laptops consider it to be a "backlight off" state. Someone may have shut a laptop down (even automatically) with the backlight off, but we think it should probably turn back on on the next boot. Absolutely nothing to do with "crashing" bootup.
> Systemd made kdbus non-optional in its release.
Totally made up. systemd's DBus library provides equivalent support for usermode DBus and kdbus.
> This one is a setback. Why is there no default editor in systemd in case of factory reset?
I'm not sure what this is even claiming. Is this some sort of trolling about complexity the author thinks systemd will eventually add and is some sort of advance critique?
In general, the piece shows disingenuous portrayal of actual issues to the level of clickbait and fails to understand that not everything in systemd's git repository runs as part of PID 1 (like the network management tools, for example, are a totally separate and optional daemon).
Might wish to check your history a bit. From the horse's mouth:
"Unfortunately, the traditional SysV init system was not particularly fast."
In fact, if you read the entire blog post, the biggest gripe Pottering keeps repeating is how slow SysVInit is, and how to address that.
http://0pointer.net/blog/projects/systemd.html
> Totally made up. systemd's DBus library provides equivalent support for usermode DBus and kdbus.
Well, it is no longer optional to compile in systemd; it can still be deactivated at run time, but the code (and checks to see which one should be used) will always be there.
No matter how many complaints you may find about SysV boot time -- or even discussion about how to improve it -- it does not make systemd's primary purpose solving that problem.
How many discussions does OpenStack's development team have about security? Is the primary purpose of OpenStack to provide security?
> Well, it is no longer optional to compile in systemd; it can still be deactivated at run time, but the code (and checks to see which one should be used) will always be there.
But that is not what the article said. It said, "Systemd made kdbus non-optional in its release." That implies that use of it is non-optional, which isn't the case at all. It is like saying Fedora has made Intel graphics non-optional because they ship support for it.
Honest question: Why does an init system need to know anything about screen brightness in the first place?
Shouldn't X11 handle screen brightness?
>I'm not sure what this is even claiming. Is this some sort of trolling about complexity the author thinks systemd will eventually add and is some sort of advance critique?
This is, I think, about the fact that systemctl edit is even a thing that exists. What's the problem with ed, vim, nano, pico, emacs, etc. that necessitates some kind of built-in systemd editor?
I think that's a reasonable question. I am only a regular desktop user of systemd for anything with a display, so I don't have a strong opinion there. All of my advanced systemd work is on server systems; I have more opinions there.
> This is, I think, about the fact that systemctl edit is even a thing that exists. What's the problem with ed, vim, nano, pico, emacs, etc. that necessitates some kind of built-in systemd editor?
There isn't a built-in systemd editor; that's how disingenuous this piece is. Running "systemctl edit <unit-name>" invokes $EDITOR, whatever that is configured to be. Totally normal Unix behavior here.
Well, okay, but the suckless people are about simplicity. Adding systemctl edit seems like a completely unnecessary alias. Another feature for the sake of having another feature.
Why assume the user is too stupid or lazy to manually invoke vim and then systemctl daemon-reload?
This is what it does:
(1) Locates the current unit file, regardless of whether it shipped with a package or is already a custom one in /etc. (2) If there isn't one in /etc, it copies the current one into the correct place. (3) It opens $EDITOR on that file. (4) It runs systemd daemon-reload.
It's really the first two steps that can be annoying because you'd otherwise have to run "systemctl status" to find where it is currently and then copy it over. I guess you could script that, but is it really so terrible to support that in systemctl -- which is just a normal user CLI utility, not anything with advanced privileges or critical impacts on system stability?
Edit: Punctuation
For example the line 'pid 1 does DNS' points to a release note about a separate daemon called 'systemd-resolved'.
edit: grammar
Gah, i keep using source repository when i should be using source tree...
But instead they lump more and more into a single tree.
You can't just grab the Resolved code to look at it, you have to grab the whole Systemd ball and then extract the portion related to Resolved.
And will Resolved even function without Systemd sitting as the init?
> We have won. Now remove all remains of our defeated enemy as fast as we can. As said in the beginning of the systemd crusade against the UNIX infidels: »You can patch it out.« It is no more there.
Are we really complaining that LSB script support has been moved out of PID1 to a separate binary? Wasn't one of the major point for critics that systemd has too much in PID1?
Pot, meet kettle...
I always wondered about how companies like Redhat and Samsung driving open source project . The way they pushed systemd to Linux community . The way Intel developer designed Gnome 3 for touch screen rather than Desktops .Is it true ? for example Company X by recruiting most of lead maintainer of project Y , They almost take control of its direction .
Is this feasible scenario ? Is this is what happened around sysmted controversy ?
Note that systemd was not pushed to anything: several members of the various open source communities appreciated their features and considered it worth to be used and even made the default. Please read the long, technical and detailed discussion Debian had before choosing systemd as their default init system while still providing sysvinit as a supported choice: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708
Also Intel developers didn't design GNOME 3 for touch screens. Sure, Clutter development was at some point carried on by Intel, but most of the GNOME design comes from RedHat and volunteers. That said, it's true that GNOME cares for keyboard, mouse and touch interaction: and I'm very happy that they care about touch, thanks to them using the touchscreen on my new laptop has been a pleasure.
To answer your concerns, both systemd and GNOME see a big investment from RedHat in their development, but the developers are influencing RedHat's choices more than the opposite. Keep also in mind that a huge number of contributions still comes from non-RedHat developers for both systemd and GNOME, at the moment there's no risk that the company will drag these projects where their maintainers don't want to go.
Please stop the revisionist history - it is well documented[1] that Lennart Poettering himself is the one that pushed GNOME to depend strictly on systemd. This was used as leverage against Debian, and became a key reason for several of the votes for systemd in the infamous technical-committee vote.
[1] https://mail.gnome.org/archives/desktop-devel-list/2011-May/...
1) in no possible way "I'd like to propose systemd" can be seen as forcefully "pushing" something
2) please go read (or re-read) the full discussion behind the Debian tech-ctte decision[1] to understand how little the GNOME dependency mattered
2) I read debate on the Debian tech-ctte and surrounding discussion in realtime when it happened. GNOME compatibility was a key concern, and while the idea of dropping GNOME was briefly considered, concerns about supporting GNOME ended up having significant sway and a big reason - though not the only reason - why systemd won the vote.
This would normally be a purely technical decision, but in this case the GNOME->systemd dependence only exists because Lennart Poettering created it.
In any case, both GNOME and Debian willingly adopted systemd. Thinking otherwise implies that GNOME and Debian developers are silly idiots: it that's the case, why bother. If it's not the case, they know what they want and nobody forcecully "pushed" anything.
http://0pointer.net/blog/revisiting-how-we-put-together-linu...
The systemd cabal (Kay Sievers, Harald Hoyer, Daniel Mack,
Tom Gundersen, David Herrmann, and yours truly) ...> and I'm very happy that they care about touch, thanks to them using the touchscreen on my new laptop has been a pleasure.
finally , after some years I met first person who use gnome touch . Honestly do you use it in your production system ? what is your system specification ? Do you encounter any lag when you using it heavily ? (in my spare time I have done android development on gnome 3+ , which was absolute nightmare , 50+ tab in chrome , VM , IDE , almost 6GB of my 8GB was used all the time , in this situation gnome 3 ridiculous _in my opinion_ animations was torture/painful for me. I changed it to xfce .
>at the moment there's no risk that the company will drag these projects where their maintainers don't want to go
This was not my point.
Debian lacks strong leadership with vision, and so they simply did what they always do which is to blindly follow RedHat's lead.
It's more like systemd was developed for Fedora/RHEL, given that a good chunk of its developers are from Red Hat.
Also, I doubt that the Fedora/RHEL maintainers are a bunch of loons easily fooled by systemd developers, so I guess they willing adopted it and nothing has been pushed. If instead they are the loons you seem to imply, I wouldn't care much about their decisions.
> Debian lacks strong leadership with vision, and so they simply did what they always do which is to blindly follow RedHat's lead
Ah ah ah, no. Please go re-read https://bugs.debian.org/727708
Note that one of the stated goals for systemd is to make good use of all the new fancy features are already available in the Linux kernel but not many people use because they are not portable (eg. control groups). Also note that some cool features have already been merged in the Linux the kernel after the systemd developers created them (eg. memfd).
Heck, he has more than once chewed out one of the principal systemd devs (Kay Sievers) for violating central rules of kernel development.
Edit: phrasing
You know that it is these kind of things that makes you look immature and discreditable no matter how valid your arguments are?
Don't get me wrong, I'm not judging. I understand that this is a certain kind of humor, but there are many who don't and who will judge you for it.
Getting emotional about something is not always a bad thing, IMO. But let's just respect that different people hold different opinions, especially with something as controversial as systemd. Let's just aim at being constructive here.
If you prefer Windows ways of doing stuff then use it, instead of changing a perfectly fine but different OS into Windows-bis.
Sounds like self-projection. Read this: http://uselessd.darknedgy.net/ProSystemdAntiSystemd/
Then again the fact that you're harping on SysV initscripts when alternatives have been around for ages makes me strongly believe you're trolling.
P.S.: "Self-projection" is psychobabble grounded in no science.
https://en.wikipedia.org/wiki/Argument_to_moderation
Oh, and speaking of self-control, aren't you the idiot who couldn't resist replying to my obviously satyrical comment in the first place?
systemd has plenty of good ideas. None are novel, and it is not "revolutionary". Making exaggerations like this only furthers the perception of your incredulity. Preopening sockets is an old idea, having centralized service management for Unix was first done by IBM AIX in 1993 and everything else is exploiting kernel subsystems, which again, are not novel. cgroups were first done as Solaris contracts, for instance. In fact, Solaris SMF and systemd are quite similar. The former even has sophisticated hardware fault detection.
No argument to moderation was ever made. Your reading comprehension is not in good shape. "People who actually design operating systems" are not some hivemind, and you're far too historically and technically illiterate to make any value judgment on that front, either way.
obviously satyrical comment
Ah yes, the old "Joke's on you, I was only pretending to be an idiot!" defense. Always useful for backpedaling.
Satyrical [sic], indeed.
That's all from me. I might quote you in the future as an example of a cautionary tale.