It's not a bloody small change in syntax. It's a fundamental design change on the way linux processes and logins work. This breaks a lot of stuff and should have a massive red warning on it. It should be a major release and not an incremental change (if it were even a good idea, which it's not).
There is no change in how systemd handles either processes or logins with this change except that it purges processes that aren't explicitly allowed to continue to run. This is conceptually very similar to how things always have worked, It is simply the way to explicitly tell the system a process is allowed to survive that have changed.
So please name me just one example of breakage or non-contrived stuff that are no longer possible to do with the new systemd settings?
There are several benefits from the new way of doing things too, like being able to use some of systemd's extensive resource management options.
"screen" will work exactly as it always have, even with the new defaults.
Except that the way you describe is not the way that screen has always worked. Instead of the straightforward invocation screen on the command line, now it has to be prefixed with all kinds of systemd-specific stuff that wasn't there before.
Its functionality is the same. Really, just use an alias if typing is hard for you to do. Or even better. Start screen automatically at boot by running it as a.service. See the Arch wiki for how.
As you can see, even with the new defaults, it is trivial to make GNU screen or tmux keep running, even after logout, even with the new defaults settings. You just start them with "systemd-run --user --scope screen" and everything works as before (just a little better).
A multi-user system shouldn't allow unpriviledged users from consuming resources indefinitely
Crippling the service is not a good way to protect the server.
There are other ways to protect system from users to consume all the resources. Admin can and should setup the server the way it is protected from incompetent/malicious users.
If you make this protection by killing processes after logout, you are actually removing functionality from it. And for me, it's a step backward.
A good thing that you are misunderstanding what is happening then; Even with the new settings, no user process will be killed on exit/logout if the user have told the system not to. Instead of starting the program with with "nohup" you start it with "systemd-run" instead. This is how you start "screen" so it will survive logout: "systemd-run --user --scope".
That systemd is able to kill the remaining processes on logout is not an issue. What is an issue is that it does this _by default_.
Why is that an issue? Even the old SysVinit distros did the same (albeit not very well). If you are thinking about the user wanting to run certain processes after logout, then that isn't a problem at all; just tell the system so. You do that by starting the process in its own scope with "systemd-run --user --scope `program` ". It really is that simple.
So, "screen" has always been a good way to ensure that processes don't get killed randomly by disconnections, logout or X crashes. Then comes systemd and kills all your processes at logout, even when launched with screen.
"screen" will work exactly as it always have, even with the new defaults. You just start screen, either as a proper.service or as a transient service in its own scope using : "systemd-run --user -scope screen". This will make screen run in its own scope so it won't be destroyed when the users scope is purged at logout.
All programs started from "screen" will run in this scope and will therefore remain after logout too.
Use "systemd-cgls" to get an overview of where the new scope is attached.
The functionality remains the same, even with the new systemd defaults. But instead of using "nohup/program/ &" you use "systemd-run --user -scope/program/".
So a slight change in syntax, not a big deal IMHO.
The conclusion is bullshit. Free will isn't an illusion and life isn't a game that plays us. (Anyone catch the reference there?)
On short time scales, reaction time is probably faster if the brain does some processing in advance.
Yes, you are absolutely right about this. The brain/nervous system "pre-charge" before an expected performance. That pre-charge shows up on the instruments before the action is taken, but isn't a sign that free will doesn't exist, just that the brain prepares for a decision or action. This has been known for decades.
The people behind Devuan aren't "veteran unix administrators". They are a bunch of unemployed or under-employed Italians. They also run "https://www.dyne.org/" . Think beggars with a GPL sign in hand; wherever the Dyne/Devuan folks are, the "please donate" sign is near by.
The first time your system goes down hard and you need to login to the systemd emergency console, run the command to review the binary-logs, and then set the system default to boot again, you'll hate systemd too.
The command to review the logs is called "journalctl" and it works perfectly from the emergency console or initrd. That means you have access to powerful log querying with systemd, even in a limited environment. So full service management and log querying even from the emergency console with systemd, which is much better than SysVinit/OpenRC based systems that just give you "cat" and a neutered version of "vi" to work with and often doesn't even have syslog in the initrd, but rely on the binary logging in the kernel ring-buffer (dmesg).
If it's a remote system, you won't even know it's systemd that you hate.
It is trivial to make systemd launch Dropbear (SSH) from initrd if the rootfs doesn't mount: that way you can ssh into the remote system to deal with the problem.
If that system is your only internet access, you may not know what you have to type to bring it back to life (it's not informative).
systemd is one of the best documented projects I know; there are man pages for everything and reverse indexes for every CLI option or config file option. Try "man systemd.index" and "man systemd.directives". Superior in every way to SysVinit etc. based systems by a long shot.
Really, systemd is the best thing that happened to Linux since package-management.
The problem with systemd is that it doesn't want to coexist peacefully. It wants to own everything. Not just resource control, but logging and other things as well.
I don't think you have actually studied the design of systemd; it is exactly designed to co-exist peacefully with other components. It is a major reason why it was adopted so successfully and fast: You can use any syslog daemon like Rsyslog or syslog-ng with systemd's journald. You can use you own homegrown resource manager using cgroups instead of systemd's. systemd uses cgroups for two things; tracking and grouping services, and resource control. But the latter use is entirely optional and you can compile systemd without such support.
Really, people are so misinformed about systemd. It is like they never even read a systemd man-page, but just uncritically iterate whatever some random blog guy once wrote.
Systemd scripts and other init scripts can coexist peacefully in the same package, so I don't see why maintainers can't work together. If there is a willing team of people who want to maintain these scripts I see no reason why the Debian team should stop them.
The problem isn't the init-scripts, the problem is supporting two different init-systems at the same time, including replicating and fixing bugs. That is why Devuan is removing systemd from their Debian fork, even though Debian Jessie at present can support both SysVinit and systemd.
Unless you can convert your binary to a stream of text, forget grepping it or doing any of the transformations everybody with a modicum of experience of *nix is very familiar with.
Well there are many ways to do that with systemd, including various language bindings to eg. Python, allowing you to directly query the journal.
It would also be trivial to tech "grep" etc to learn to read the journal, just like "zgrep" can read binary files. There is no point to that however, since the concept of piping works so well: All the standard text tools like grep, awk, tee, wc etc. works with the systemd journal through piping.
On the commandline, binary files are going to require a custom built interface for that specific type of binary. That custom built interface needs to have all the features you want for easy searching etc.: no regular expression search built-in? Then forget about it. If you're lucky, there is another tool that understands your specific binary flavour which may or may not do what you want.
No, that is wrong. Through the Unix concept of piping all standard text tools work with systemd's binary journal, so you can use any grep regex on the journal.
A text file does not have those problems because it can be interpreted using a standard that is ridiculously simple, old as dirt and supported by and ingrained in pretty much fucking everything that displays letters.
I'm not saying a binary format cannot have its advantages (databases obviously have many), but to dismiss the difference between binaries and text files with 'you still need a tool to read them' is absolutely fucking idiotic.
I think you make text files much simpler than they really are; multi-language files, UTF vs ASCII, Unicode and even simple CRLF vs LF can make dealing with text files a major hassle. People are often surprised by the Posix definition of a text file (which causes eg. grep to treat "text" files as binary data.
Anyway, having worked with systemd's journal for quite some time I can only say it is major benefit to use and that practically all concerns I have seen raised against it seems to be based on wrong and often contrived speculations. Stuff like "journalctl -b -1 -p err" and "journalctl --since -10m" is just great. And I really like that even log-entries can be tab-completed, so you just type "jou(tab) -u sma(tab)" to type "journalctl -u smartd.service"
> Maybe. But my initial reaction was "binary logs?!? on a *nix system? WTF?"
Besides the POSIX utmp and wtmp binary logs, there is also the Kernel ring-buffer on Linux; Without the ring-buffer collecting and storing messages from/dev/ksmg there would be no boot-logs at all, or even any logs until the rootfs has been mounted and the syslog daemon started. systemd's "journald" service is the Kernel ring-buffer equivalent, and "dmesg" similar to systemd's "journalctl" tool; they both extract binary log-info and convert it to text.
Also, consider that log collectors and analyzers like "Splunk" etc all does exactly the same thing as "journald", namely hammering the log-info into a binary structure with an index. systemd's format is Free software with a stable and documented API and format (so eg. Rsyslog can read it natively), while many other log-analyzers are close source with proprietary formats.
If you remember when Rsyslog was started a decade ago, you should remember that one of its main goals was to overcome the many inherent limitations of flat file text logs; it's solution was to place the logs in a DB (binary format). systemd's binary format is much, much simpler than running a full DB, while getting access to many of the advantages of having an indexed log.
dhcpcd (which also works on BSD) has had support for this (RFC7217) for almost a year now, but it's now news when NetworkManager (Linux only) get's it?
RFC7217 has been in NM for some time. The news regarding this is that it now is upstream default for IPv6 connections when using NM 1.2.
The other feature, that is the real news, is a kind of MAC randomization feature that uses the real HW MAC for connection, but "fake" MAC's for scanning for AP's. This is also default now.
NM can also randomize and spoof MAC's like the decade old GNU MAC Changer, but it isn't default since that may give problems with connecting to certain devices and services.
Forgive me for asking but, what is systemd's main benefit? If i don't mind that my system boots up slower and in a sequential order, how does that affect the systemd's benefits for other users?
The primary benefit of systemd is that it is init done right. That means you no longer need to use executable shell scripts in order to run daemons, but can use simple text config files. SysVinit shell scripts are hard to parse for both humans and machines, while systemd.service text config files are easy to parse for both machines and people.
Integrated service management: Want to restart and important service if it crashed, but only if it crash with an abnormal exit code and hasn't been re-started the last 5 minutes. That stuff is trivial to do in systemd with only changing a simple config line in a text file. With OpenRC/SysVinite etc. , it requires endless hacking to make something similar work.
Reliable killing a process and all its sub-processes. systemd can do that because it tracks every process with cgroups, non-systemd distros can't.
Security: If SysVinit had stepped up and taken responsibility for handing out low port numbers to services so they didn't need privilege dropping code like systemd does, we could have avoided two decades of remote exploits of Linux because of wrong use of setuid in daemons. It is better to have one secure implementation of privilege dropping code made by security experts instead of letting each and every daemon try to do it.
Security: systemd can "jail"/"contain" all running services since it provides an easy to use "API" for several low level kernel security features like "Capabilities" and "Namespaces". So the service developers, the distro-maintainers, or even the system administrator can add "NoNewPrivileges" to a service config file. That means, that even if the service is exploited, the attacker can't get escalate privileges by then exploiting another service (A typical pattern).
Extremely easy resource management like limiting a service to only X amount of memory, or CPU resources, or bandwith etc. It can do that because of cgroups integration. A single; "MemoryLimit=1G" or similar added to the service file will make things work.
There are even more good reasons. I recommend the systemd homepage, especially the "The systemd for Administrators Blog Series" for and end users perspective.
In short, for me systemd is the best thing that have happened to Linux since package management. I really like it, Good stuff that makes Linux more secure and easier to use, for both newbies and experienced admins. It also has the best man page documentation and CLI tools I have seen for many, many years. Take fx. "man systemd.index" ; that will give you an overview of each and every "man-page" related to systemd. Very nice.
I don't understand this. If systemd is so backwards compatible with the traditional way of doing stuff, why don't distros enable that? Half the systemd hate would probably dissappear just like that.
Because almost all systemd haters don't have any actual systemd experience, nor have they even read a couple of systemd man pages. And perhaps not so few aren't actual Linux users either.
This is the modern world where some hearsay on a blog becomes a "truth" by endless repeating. I can't think of a single enterprise distro like RH/CentOS/Suse that doesn't have text-logs as default.
Outside the tiny 0.00001% of Linux users who can actually use regex, I fail to see the attraction of text logs after having been spoiled by actually using the systemd journal.
What are the "non-systemd distros" that are crumbling?
I hoped the context could have clarified what I meant about "crumbling". But let me sum up; there is a whole lot of software that the non-systemd distros need to maintain in order not to lose features. They have basically all ignored this fact for years, despite upstream projects like KDE and Gnome have pleaded for this to happen.
Now years of neglect is catching up with non-systemd distros. And it will gets worse in the future. OS containers, Wayland, the new cgroups API; how does the non-systemd think any of this new technology will work on their distros if they aren't actively working on them? I mean, the entire OS container industry are now getting behind systemd.
I'm not sure it will be actually possible because, you see, I'm facing the reality, that systemd alternative right now is another systemd. Hence today topic.
Lets ignore that the technical whine behind that story was wrong. Your point still stands. My point is, that that reality is solely caused by the non-systemd distros failing to keep up with development.
I had hopes that Devuan could be enough. Now, after one year, I'm suspecting it could not. Not because of the "non-systemd distros" people, as you name it. But because if the game is rigged. "In many cases [systemd] allows us to throw away large amounts of code whilst at the same time providing a better user experience. Adding it [systemd] as an optional extra defeats the main benefit": it says it all. Thrown away code, no benefit if optional. It is pretty clear what it implies.
Isn't that quote just the usual Devuan rhetoric where they try to hide the hypocrisy about first bleating about "init-freedom" and "choice in init", and then later remove any trace of init-freedom?
They lied about being "Veteran Unix Admins" too, so what do you expect of a bunch of rather shady unemployed Italians trying to use GPL software as a bait for their constantly outreached begging bowl? Looking at their cash withdraws from the collected Devuan money they seem to already have their snouts in the money trough.
I don't care if you think MS products are better for you, hey if it works for you why should I disagree about your choice. You probably never really cared about Linux and Open Source in the first place, so systemd is probably a great excuse for no longer using Linux.
I think you missed out on why code is fixed. 25 years ago and today, only code that is useful and therefore can attract developers can survive in the FOSS world.
The lack of development among the non-systemd distros are caused by the fact that they are a tiny minority and that almost all developers have left their ever decreasing circle. Without developers, no code. It is as simple as that.
The systemd-opponents should probably have reflected over what they did wrong a couple of years ago.
>I had a quick look at the ConsoleKit2's git repo. I guess by "years" you mean 5 months.
Nope. CK is still dead and has been for almost 4 years. While CK2 is a fork, it has dropped the old CK API (and code) in favor of the systemd-login API, just like systemBSD. That means you can't use CK2 as a direct replacement for CK. The old upstream code in the DE's simply don't work.
While CK was dead, there where of course still lots of development going in the DE's, but since only systemd-login was actually maintained, they could only add support for that in the new code.
And the KDE and Gnome developers never got any help for the hard work they are doing with supporting basically un-supportable distros that ignore each and every request they have. Not even a "thank you" are they getting. Instead they are getting shit kicked in their faces by fanatic systemd-haters.
Yeah, Microsoft knows Unix(tm). They where once a major Unix(tm) vendor with their MicroSoft Xenix. They later sold it to SCO Unix. Charming fellahs all around I am sure.
Slashdot Mirror
If I have to know that a particular system is using systemd in order to invoke "screen" correctly, somebody's design is totally broken.
That is just silly. I suppose you would have fiercely resisted when Telnet was kicked out in favor of ssh too since it had new syntax.
Change is just part of tech. Get used to it.
It's not a bloody small change in syntax. It's a fundamental design change on the way linux processes and logins work. This breaks a lot of stuff and should have a massive red warning on it. It should be a major release and not an incremental change (if it were even a good idea, which it's not).
There is no change in how systemd handles either processes or logins with this change except that it purges processes that aren't explicitly allowed to continue to run. This is conceptually very similar to how things always have worked, It is simply the way to explicitly tell the system a process is allowed to survive that have changed.
So please name me just one example of breakage or non-contrived stuff that are no longer possible to do with the new systemd settings?
There are several benefits from the new way of doing things too, like being able to use some of systemd's extensive resource management options.
Except that the way you describe is not the way that screen has always worked. Instead of the straightforward invocation screen on the command line, now it has to be prefixed with all kinds of systemd-specific stuff that wasn't there before.
Its functionality is the same. Really, just use an alias if typing is hard for you to do. Or even better. Start screen automatically at boot by running it as a .service. See the Arch wiki for how.
Fear not, people of Slashdot, because there is an option to maintain background processes, even after user disconnection.
But this option is not "on" by default. So, yeah, screen and tmux all of a sudden become useless, unless you fiddle with the knobs.
You are of course wrong. Probably because you never read the technical documentation on this but just relied on wrong hearsay.
Here is the relevant man-page:
https://www.freedesktop.org/so...
As you can see, even with the new defaults, it is trivial to make GNU screen or tmux keep running, even after logout, even with the new defaults settings. You just start them with "systemd-run --user --scope screen" and everything works as before (just a little better).
A multi-user system shouldn't allow unpriviledged users from consuming resources indefinitely
Crippling the service is not a good way to protect the server.
There are other ways to protect system from users to consume all the resources. Admin can and should setup the server the way it is protected from incompetent/malicious users.
If you make this protection by killing processes after logout, you are actually removing functionality from it. And for me, it's a step backward.
A good thing that you are misunderstanding what is happening then; Even with the new settings, no user process will be killed on exit/logout if the user have told the system not to.
Instead of starting the program with with "nohup" you start it with "systemd-run" instead.
This is how you start "screen" so it will survive logout: "systemd-run --user --scope".
That systemd is able to kill the remaining processes on logout is not an issue. What is an issue is that it does this _by default_.
Why is that an issue? Even the old SysVinit distros did the same (albeit not very well). If you are thinking about the user wanting to run certain processes after logout, then that isn't a problem at all; just tell the system so. You do that by starting the process in its own scope with "systemd-run --user --scope `program` ". It really is that simple.
So, "screen" has always been a good way to ensure that processes don't get killed randomly by disconnections, logout or X crashes.
Then comes systemd and kills all your processes at logout, even when launched with screen.
"screen" will work exactly as it always have, even with the new defaults. You just start screen, either as a proper .service or as a transient service in its own scope using : "systemd-run --user -scope screen". This will make screen run in its own scope so it won't be destroyed when the users scope is purged at logout.
All programs started from "screen" will run in this scope and will therefore remain after logout too.
Use "systemd-cgls" to get an overview of where the new scope is attached.
The man-page is good to read if you want to understand how things work : https://www.freedesktop.org/so...
In short, don't go on hearsay but read the technical documentation.
The functionality remains the same, even with the new systemd defaults. But instead of using "nohup /program/ &" you use "systemd-run --user -scope /program/".
So a slight change in syntax, not a big deal IMHO.
The conclusion is bullshit. Free will isn't an illusion and life isn't a game that plays us. (Anyone catch the reference there?)
On short time scales, reaction time is probably faster if the brain does some processing in advance.
Yes, you are absolutely right about this. The brain/nervous system "pre-charge" before an expected performance. That pre-charge shows up on the instruments before the action is taken, but isn't a sign that free will doesn't exist, just that the brain prepares for a decision or action. This has been known for decades.
I thought this whole Linux thing was all about freedom to choose?
Not when it comes to Devuan; they won't let you choose systemd as init. No "init-freedom" there.
What a joke, "veteran unix administrators",
The people behind Devuan aren't "veteran unix administrators". They are a bunch of unemployed or under-employed Italians. They also run "https://www.dyne.org/" . Think beggars with a GPL sign in hand; wherever the Dyne/Devuan folks are, the "please donate" sign is near by.
The first time your system goes down hard and you need to login to the systemd emergency console, run the command to review the binary-logs, and then set the system default to boot again, you'll hate systemd too.
The command to review the logs is called "journalctl" and it works perfectly from the emergency console or initrd. That means you have access to powerful log querying with systemd, even in a limited environment. So full service management and log querying even from the emergency console with systemd, which is much better than SysVinit/OpenRC based systems that just give you "cat" and a neutered version of "vi" to work with and often doesn't even have syslog in the initrd, but rely on the binary logging in the kernel ring-buffer (dmesg).
If it's a remote system, you won't even know it's systemd that you hate.
It is trivial to make systemd launch Dropbear (SSH) from initrd if the rootfs doesn't mount: that way you can ssh into the remote system to deal with the problem.
If that system is your only internet access, you may not know what you have to type to bring it back to life (it's not informative).
systemd is one of the best documented projects I know; there are man pages for everything and reverse indexes for every CLI option or config file option. Try "man systemd.index" and "man systemd.directives". Superior in every way to SysVinit etc. based systems by a long shot.
Really, systemd is the best thing that happened to Linux since package-management.
The problem with systemd is that it doesn't want to coexist peacefully. It wants to own everything. Not just resource control, but logging and other things as well.
I don't think you have actually studied the design of systemd; it is exactly designed to co-exist peacefully with other components. It is a major reason why it was adopted so successfully and fast:
You can use any syslog daemon like Rsyslog or syslog-ng with systemd's journald.
You can use you own homegrown resource manager using cgroups instead of systemd's. systemd uses cgroups for two things; tracking and grouping services, and resource control. But the latter use is entirely optional and you can compile systemd without such support.
Really, people are so misinformed about systemd. It is like they never even read a systemd man-page, but just uncritically iterate whatever some random blog guy once wrote.
Systemd scripts and other init scripts can coexist peacefully in the same package, so I don't see why maintainers can't work together. If there is a willing team of people who want to maintain these scripts I see no reason why the Debian team should stop them.
The problem isn't the init-scripts, the problem is supporting two different init-systems at the same time, including replicating and fixing bugs.
That is why Devuan is removing systemd from their Debian fork, even though Debian Jessie at present can support both SysVinit and systemd.
Unless you can convert your binary to a stream of text, forget grepping it or doing any of the transformations everybody with a modicum of experience of *nix is very familiar with.
Well there are many ways to do that with systemd, including various language bindings to eg. Python, allowing you to directly query the journal.
It would also be trivial to tech "grep" etc to learn to read the journal, just like "zgrep" can read binary files. There is no point to that however, since the concept of piping works so well: All the standard text tools like grep, awk, tee, wc etc. works with the systemd journal through piping.
On the commandline, binary files are going to require a custom built interface for that specific type of binary. That custom built interface needs to have all the features you want for easy searching etc.: no regular expression search built-in? Then forget about it. If you're lucky, there is another tool that understands your specific binary flavour which may or may not do what you want.
No, that is wrong. Through the Unix concept of piping all standard text tools work with systemd's binary journal, so you can use any grep regex on the journal.
A text file does not have those problems because it can be interpreted using a standard that is ridiculously simple, old as dirt and supported by and ingrained in pretty much fucking everything that displays letters.
I'm not saying a binary format cannot have its advantages (databases obviously have many), but to dismiss the difference between binaries and text files with 'you still need a tool to read them' is absolutely fucking idiotic.
I think you make text files much simpler than they really are; multi-language files, UTF vs ASCII, Unicode and even simple CRLF vs LF can make dealing with text files a major hassle.
People are often surprised by the Posix definition of a text file (which causes eg. grep to treat "text" files as binary data.
Anyway, having worked with systemd's journal for quite some time I can only say it is major benefit to use and that practically all concerns I have seen raised against it seems to be based on wrong and often contrived speculations.
Stuff like "journalctl -b -1 -p err" and "journalctl --since -10m" is just great. And I really like that even log-entries can be tab-completed, so you just type "jou(tab) -u sma(tab)" to type "journalctl -u smartd.service"
> Maybe. But my initial reaction was "binary logs?!? on a *nix system? WTF?"
Besides the POSIX utmp and wtmp binary logs, there is also the Kernel ring-buffer on Linux; Without the ring-buffer collecting and storing messages from /dev/ksmg there would be no boot-logs at all, or even any logs until the rootfs has been mounted and the syslog daemon started.
systemd's "journald" service is the Kernel ring-buffer equivalent, and "dmesg" similar to systemd's "journalctl" tool; they both extract binary log-info and convert it to text.
Also, consider that log collectors and analyzers like "Splunk" etc all does exactly the same thing as "journald", namely hammering the log-info into a binary structure with an index.
systemd's format is Free software with a stable and documented API and format (so eg. Rsyslog can read it natively), while many other log-analyzers are close source with proprietary formats.
If you remember when Rsyslog was started a decade ago, you should remember that one of its main goals was to overcome the many inherent limitations of flat file text logs; it's solution was to place the logs in a DB (binary format).
systemd's binary format is much, much simpler than running a full DB, while getting access to many of the advantages of having an indexed log.
dhcpcd (which also works on BSD) has had support for this (RFC7217) for almost a year now, but it's now news when NetworkManager (Linux only) get's it?
RFC7217 has been in NM for some time. The news regarding this is that it now is upstream default for IPv6 connections when using NM 1.2.
The other feature, that is the real news, is a kind of MAC randomization feature that uses the real HW MAC for connection, but "fake" MAC's for scanning for AP's. This is also default now.
NM can also randomize and spoof MAC's like the decade old GNU MAC Changer, but it isn't default since that may give problems with connecting to certain devices and services.
Forgive me for asking but, what is systemd's main benefit? If i don't mind that my system boots up slower and in a sequential order, how does that affect the systemd's benefits for other users?
The primary benefit of systemd is that it is init done right. That means you no longer need to use executable shell scripts in order to run daemons, but can use simple text config files. SysVinit shell scripts are hard to parse for both humans and machines, while systemd .service text config files are easy to parse for both machines and people.
Integrated service management: Want to restart and important service if it crashed, but only if it crash with an abnormal exit code and hasn't been re-started the last 5 minutes. That stuff is trivial to do in systemd with only changing a simple config line in a text file. With OpenRC/SysVinite etc. , it requires endless hacking to make something similar work.
Reliable killing a process and all its sub-processes. systemd can do that because it tracks every process with cgroups, non-systemd distros can't.
Security: If SysVinit had stepped up and taken responsibility for handing out low port numbers to services so they didn't need privilege dropping code like systemd does, we could have avoided two decades of remote exploits of Linux because of wrong use of setuid in daemons. It is better to have one secure implementation of privilege dropping code made by security experts instead of letting each and every daemon try to do it.
Security: systemd can "jail"/"contain" all running services since it provides an easy to use "API" for several low level kernel security features like "Capabilities" and "Namespaces".
So the service developers, the distro-maintainers, or even the system administrator can add "NoNewPrivileges" to a service config file. That means, that even if the service is exploited, the attacker can't get escalate privileges by then exploiting another service (A typical pattern).
Extremely easy resource management like limiting a service to only X amount of memory, or CPU resources, or bandwith etc. It can do that because of cgroups integration. A single; "MemoryLimit=1G" or similar added to the service file will make things work.
There are even more good reasons. I recommend the systemd homepage, especially the "The systemd for Administrators Blog Series" for and end users perspective.
http://www.freedesktop.org/wik...
In short, for me systemd is the best thing that have happened to Linux since package management. I really like it, Good stuff that makes Linux more secure and easier to use, for both newbies and experienced admins. It also has the best man page documentation and CLI tools I have seen for many, many years. Take fx. "man systemd.index" ; that will give you an overview of each and every "man-page" related to systemd. Very nice.
I don't understand this. If systemd is so backwards compatible with the traditional way of doing stuff, why don't distros enable that? Half the systemd hate would probably dissappear just like that.
Because almost all systemd haters don't have any actual systemd experience, nor have they even read a couple of systemd man pages. And perhaps not so few aren't actual Linux users either.
This is the modern world where some hearsay on a blog becomes a "truth" by endless repeating. I can't think of a single enterprise distro like RH/CentOS/Suse that doesn't have text-logs as default.
Outside the tiny 0.00001% of Linux users who can actually use regex, I fail to see the attraction of text logs after having been spoiled by actually using the systemd journal.
What are the "non-systemd distros" that are crumbling?
I hoped the context could have clarified what I meant about "crumbling".
But let me sum up; there is a whole lot of software that the non-systemd distros need to maintain in order not to lose features. They have basically all ignored this fact for years, despite upstream projects like KDE and Gnome have pleaded for this to happen.
Now years of neglect is catching up with non-systemd distros. And it will gets worse in the future. OS containers, Wayland, the new cgroups API; how does the non-systemd think any of this new technology will work on their distros if they aren't actively working on them? I mean, the entire OS container industry are now getting behind systemd.
I'm not sure it will be actually possible because, you see, I'm facing the reality, that systemd alternative right now is another systemd. Hence today topic.
Lets ignore that the technical whine behind that story was wrong. Your point still stands. My point is, that that reality is solely caused by the non-systemd distros failing to keep up with development.
I had hopes that Devuan could be enough. Now, after one year, I'm suspecting it could not. Not because of the "non-systemd distros" people, as you name it. But because if the game is rigged. "In many cases [systemd] allows us to throw away large amounts of code whilst at the same time providing a better user experience. Adding it [systemd] as an optional extra defeats the main benefit": it says it all. Thrown away code, no benefit if optional. It is pretty clear what it implies.
Isn't that quote just the usual Devuan rhetoric where they try to hide the hypocrisy about first bleating about "init-freedom" and "choice in init", and then later remove any trace of init-freedom?
They lied about being "Veteran Unix Admins" too, so what do you expect of a bunch of rather shady unemployed Italians trying to use GPL software as a bait for their constantly outreached begging bowl? Looking at their cash withdraws from the collected Devuan money they seem to already have their snouts in the money trough.
I don't care if you think MS products are better for you, hey if it works for you why should I disagree about your choice. You probably never really cared about Linux and Open Source in the first place, so systemd is probably a great excuse for no longer using Linux.
I think you missed out on why code is fixed. 25 years ago and today, only code that is useful and therefore can attract developers can survive in the FOSS world.
The lack of development among the non-systemd distros are caused by the fact that they are a tiny minority and that almost all developers have left their ever decreasing circle.
Without developers, no code. It is as simple as that.
The systemd-opponents should probably have reflected over what they did wrong a couple of years ago.
>I had a quick look at the ConsoleKit2's git repo. I guess by "years" you mean 5 months.
Nope. CK is still dead and has been for almost 4 years. While CK2 is a fork, it has dropped the old CK API (and code) in favor of the systemd-login API, just like systemBSD. That means you can't use CK2 as a direct replacement for CK. The old upstream code in the DE's simply don't work.
While CK was dead, there where of course still lots of development going in the DE's, but since only systemd-login was actually maintained, they could only add support for that in the new code.
And the KDE and Gnome developers never got any help for the hard work they are doing with supporting basically un-supportable distros that ignore each and every request they have. Not even a "thank you" are they getting. Instead they are getting shit kicked in their faces by fanatic systemd-haters.
Yeah, Microsoft knows Unix(tm). They where once a major Unix(tm) vendor with their MicroSoft Xenix. They later sold it to SCO Unix. Charming fellahs all around I am sure.
>I chose. I went back to windows.
Yes, because MS Windows is totally "Unix Philosophy" and is all about choice and modularity.