The Systemd Chronicles(suckless.org)
suckless.org
The Systemd Chronicles
http://suckless.org/sucks/systemd
16 comments
Well the devs has brought that on themselves by naming the init binary and the overall project the same, and then dumping more and more into a singular code repository.
The entire BSD kernel and init system are all in one repository. Are those developers "bringing on" confusion by doing that?
If you want to make a BSD do so, do not turn the whole of Linux into one.
Gah, i keep using source repository when i should be using source tree...
Gah, i keep using source repository when i should be using source tree...
So its the systemd developers' fault that this is not a very good list of issues?
They could have killed the confusion early by either renaming the init (or the project), or keeping the daemons in a different place from the Systemd init code.
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?
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?
[deleted]
Title is incorrect. Should either be 'sucks - systemd' or 'Systemd is the best example of Suck.'
It seems like the argument being made here is that perhaps the systemd developers are afraid / unable to innovate in the kernel, which is in fact the overall system-wide daemon and parent to all processes.
I'm not sure I understand your comment. Are you proposing to move all the systemd features in the kernel? Why do you think it would be a good idea.
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).
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).
Well their way of doing things would not get past Torvalds.
Heck, he has more than once chewed out one of the principal systemd devs (Kay Sievers) for violating central rules of kernel development.
Heck, he has more than once chewed out one of the principal systemd devs (Kay Sievers) for violating central rules of kernel development.
If that were the case, wouldn't the author support the kdbus work? It seems like they're not a fan of that, either, given the (misleading) complaints about systemd's support for kdbus.
Edit: phrasing
Edit: phrasing
People working on systemd have submitted hundreds of kernel patches and implemented features that already are in the mainline kernel.
This article is inflammatory, in bad faith, and in many places blatantly incorrect.
I appreciate a lot of suckless work, but I don't see what this is adding.
I appreciate a lot of suckless work, but I don't see what this is adding.
Just out of curiosity, can you summarize where exactly it is wrong?
The tone is very negative and does not allow that there might actually be legitimate reasons for wanting systemd to do things that it does.
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.
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.
As a systemd committer, I certainly can. I don't have time for all of them, so I'll pull the first couple and a few other egregious ones.
> 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).
> 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).
> systemd was not introduced to decrease boot time
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.
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.
> Might wish to check your history a bit.
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.
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.
>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.
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?
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?
> 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 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.
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.
>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?
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 no different from crontab -e, visudo and other programs that invoke $EDITOR..
> 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
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
Init has no idea of the screen brightness.. that 's just another thing the author pull out from his back-passage. a separate service [email protected](8) saves and restores the backlight state, because firmware does not remember it or if it does, it is buggy.
I think you will find that the brightness stuff is aimed at Wayland, not X11. The latter is something that many wants to see depreciated ASAP.
See my comment.
https://news.ycombinator.com/item?id=9982777
https://news.ycombinator.com/item?id=9982777
In this discussion on HN, I hope that people of both sides will permit everyone to have their own opinion on systemd without becoming as emotional or angry as the last time. Topics about systemd tend to get out of hand way too fast and often. In the past I've been blamed for saying I really dislike systemd but my arguments were not even read. The same thing the other way around: I've seen people who dislike systemd flame the people who do enjoy it. Let's just not repeat that kind of discussion; we can do better.
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.
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.
Some tasteful flaming is healthy in situations like this. Many people consider systemd to be a hijacking of the projects that they base their careers and livelihoods on, and many people see hundreds or thousands of hours of work they've invested being steered in an unsavory direction by a corporation or three.
and many people have been waiting for something like systemd to appear since they started using Linux in the 90s :)
Why haven't them moved to Windows then?
If you prefer Windows ways of doing stuff then use it, instead of changing a perfectly fine but different OS into Windows-bis.
If you prefer Windows ways of doing stuff then use it, instead of changing a perfectly fine but different OS into Windows-bis.
Because Windows sucks, since it doesn't have anything like systemd.
[deleted]
So far the discussion here has been way better than the submission. I'm not a fan of systemd, to understate it, but this article is terrible. I wish it had less content and more accuracy.
Don't count on it: http://uselessd.darknedgy.net/ProSystemdAntiSystemd/
Unfortunately it looks like a lot of the links are broken. At least, I don't see the connection to what the first link about logind has to do with udev.
[deleted]
I have theory in my mind , I hope I can find an answer for it in HN.
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 ?
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 ?
RedHat and Samsung open source contributions aren't really comparable, despite the latter having got much better lately. Despite me being a long time Debian user, I've always appreciated how RedHat employees have always been community members first and RH employees second.
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.
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.
> Note that systemd was not pushed to anything
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/...
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/...
No revisionism here:
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
[1] https://bugs.debian.org/727708
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
[1] https://bugs.debian.org/727708
1) systemd was not pushed at GNOME; the GNOME dependency was the leverage used to push systemd at distributions. This let the systemd cabal look innocent with GNOME getting the blame for any compatibility issues. This is a very common political tactic that is popular because it gives plausible deniability and usually requires more than a sound-bite to refute. Surely you've seen it before.
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.
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.
If you talk about cabals, there's no point in having a sensible discussion. Te existence of secret cabals is a matter of faith, and you cannot really discuss things of faith with reason alone.
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.
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.
I was waiting for someone to reveal their ignorance by calling out "cabal". Why should anybody trust your other comments about the history of systemd when you don't know that "cabal" is Lennart Poettering's term for the systemd core developers?
http://0pointer.net/blog/revisiting-how-we-put-together-linu...
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) ...You either don't know the meaning of the word "irony" or you have some issues with cause→effect relations.
Just going on the record , I am not against systemd or redhat or Samsung . Even though my comment was hypothetically, it is good strategy for software company to hunt projects by recruiting main maintainer of project you can change project direction.
> 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.
> 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.
systemd was certainly pushed to RHEL and Fedora.
Debian lacks strong leadership with vision, and so they simply did what they always do which is to blindly follow RedHat's lead.
Debian lacks strong leadership with vision, and so they simply did what they always do which is to blindly follow RedHat's lead.
> pushed to RHEL and Fedora
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
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
You are giving corporations way too much credit..not sure how you arrived to that conclusion..things do not work that way..companies with financial interest in linux hire people to do what like (or sometimes, it is even better..to do what they passionate about) so these individuals can in some ways have limited influence in the direction of a particular project.
Think it like "hoarding cats" not as "we are all an all powerful entity that can dictate at will".
> 8x ctrl + alt + del
> In systemd you press eight times Ctrl+Alt+Del to trigger reboot.
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).
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).
> Ctrl-Alt-Del still reboots your system.
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
> 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.
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.
> 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.
Systemd is not deleting any groups.
Systemd is not deleting any groups.
AFAIK in SysV ctrl+alt+del would trigger reboot which anyways involves shutdown scripts.
> Actually, it triggers a script. which should "typically" point at the reboot script. It might not, though.
The world might end.
> Actually, it triggers a script. which should "typically" point at the reboot script. It might not, though.
The world might end.
The need to replace sysvinit was/is valid but systemd is truly a horrible piece of software. I would argue that systemd has (greatly) increased overall complexity and simply camouflaged it by moving most of the logic out of init scripts (unit files) and into program logic. And then added an http server and binary logs.
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".
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".
systemd clicked for me when I started realizing that a lot of its decisions mapped directly to Red Hat business decisions in cloud computing and containers, like their backing of Project Atomic. nspawn, the "stateless" system features through dynamic configuration population, GPT partition discovery deprecating fstab(5), having a big centralized blob journal, the embedded network management (which is mostly useful for container deployments rather than desktops) and NSS extensions, the GNOME system upgrade logic and so on.
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).
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).
Of course. Systemd is Red Hat's "embrace, extend, extinguish" strategy. Just as Microsoft were once the plucky upstart who became their rival IBM, so Red Hat are becoming Microsoft.
I don't think Red Hat was the driving force behind systemd's container and VM integration.
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).
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).
Well, Red Hat were quick to adopt CoreOS' appc, before a lot of companies ultimately united under the Open Container Project banner.
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".
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".
> 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.
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.
Really, is it necessary to have another systemd perma-sulk?
> * sysv removed http://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id=2d1...
> 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?
> 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?
Yes..you figured out that you can't win with these people.. whatever you do they are going to complain. They are not interested in any constructive criticism.
https://plus.google.com/+TheodoreTso/posts/4W6rrMMvhWU
Pot, meet kettle...
Pot, meet kettle...
Nope, that's not really the same thing.
[deleted]
The noble knights of UNIX lore and traditions are at it again. Lo and behold! Armed with the arcane power of ancient spaghetti code shell scripts and logical fallacies, they grep their way through enemy lines to banish the dreaded modernity once and for all.
ancient spaghetti code shell scripts and logical fallacies
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.
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.
Yes I'm trolling/mocking you anti-systemd retards. That's what Schopenhauer recommends as a strategy against irrational rhetoric (here of the reactionary kind). I couldn't care less for irrational people's reading recommendations.
P.S.: "Self-projection" is psychobabble grounded in no science.
P.S.: "Self-projection" is psychobabble grounded in no science.
I'm not even anti-systemd, but I can certainly use you as ammunition against systemd proponents if the time ever comes. Thank you kindly for lacking self-control and giving me this opportunity.
No, you just can't recognize that systemd is objectively and clearly superior to every other Linux init system by just about every measure. In fact, systemd is revolutionary in it's own right and that's why it is hated so much. People who actually design operating systems — as opposed to basement-dwelling traditionalists — have expressed admiration for it. Haiku are doing their own systemd inspired init system. And there's been FreeBSD developers talking of doing their own as well. Supposing you're the idiot who wrote that article you linked, the whole "I take no sides" thing is called the middle ground fallacy. Ironic that you should speak of "ape brain" when you either endorse or perhaps wrote such an article.
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?
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?
Actually, Haiku's init is more inspired by launchd than anything, which predates systemd by some 5 years. If you actually read about Haiku's scheme, you'd see the semantics have little in common. FreeBSD is thinking of adopting, again, launchd. So far this is only in experimental feature branches and from my knowledge it will initially be tested on FreeNAS before it makes it to FreeBSD, specifically.
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.
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.
> Führerbunker
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.
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.
For example the line 'pid 1 does DNS' points to a release note about a separate daemon called 'systemd-resolved'.
edit: grammar