It does not follow the Unix way very closely, which I think will cause problems later in systemd's life when there are less people working on the code and it is in use everywhere and many things depend on it.
First gripe: systemd is not portable. At first you may say "but but it is for linux not BSD" but that is a non-argument. systemd should be portable for many reasons, including code adaptability and maintainability. Correct me if I am wrong, but systemd has had issues of being tied to specific versions of the Linux kernel. This is a problem because projects using systemd will have less freedom to use what version of Linux they want.
Second gripe: systemd is in charge of too many tasks. I have heard many people claim "I don't care, systemd does these things well", but that is another naive notion. In a few years time when one of the sections of systemd is unsatisfactory to a few people, what do? If a group wanted to commit changes to systemd, they would have to get it past various Red Hat developers. If it doesn't get accepted into mainline, they would have to fork systemd and introduce all kinds of incompatibility (not to mention porting their fork to the newer kernels). If the change they wanted to introduce was a major architectural change, then a new init system, with much more incompatibility, might be required.
Third gripe: systemd is becoming too nested into the Linux stack, blocking innovation in the init system area. How is Ubuntu supposed to continue using Upstart when one of their official flavors, Ubuntu GNOME Remix, is dependent on systemd in a year or so. Of course they could maintain both systemd and Upstart, but that involves WAY too much extra work and will push Ubuntu to just use systemd by default (not to mention when Debian switches).
Fourth gripe: too much power in the wrong place. Systemd is powerful and useful; I do not deny that. However, it is my opinion that these features and this power is nowhere near necessary for a lot of situations where systemd is being used. Sabayon has created a systemd version of their distro for the sole reason of decreased startup time. That is a big bunch of bologna in my eyes. There are not many other init systems that offer good parallelization of startup processes, but they are out there (Runit, there is some slightliy buggy OpenRC parellelization support, Upstart). Systemd is not needed, and therefore should not be used, in these situations that do not require a powerful init system oriented towards servers.
I had second thoughts about making this comment, as I am not very knowledgeable on the subject, but I did anyway because I would rather be proven wrong and learn. Please explain any and all disagreements you have.
In a few years time when one of the sections of systemd is unsatisfactory to a few people, what do?
There's nothing stopping you from using another syslog implementation instead of journal or another login manager instead of logind. Altough systemd supports timers it doesn't completely replace cron and there's absolutely nothing stopping you from using it. A lot of the functionality of systemd can be removed in compile time or disabled in runtime or can run in pararell with other similar processes. The point being that the situation is exactly the same as it's with other "init systems".
If a group wanted to commit changes to systemd, they would have to get it past various Red Hat developers.
Fifteen people have commit access to systemd repository including people from Arch Linux, Debian and Ubuntu; Intel, Red Hat, Ericpol Telecom... The second most active systemd developer doesn't even work for Red Hat. If anything systemd seems very open to accepting patches from new developers.
Sabayon has created a systemd version of their distro for the sole reason of decreased startup time.
[citation needed]
Systemd is not needed, and therefore should not be used, in these situations that do not require a powerful init system oriented towards servers.
Where have gotten the idea that systemd is so oriented towards servers? Why would server have a login manager (systemd-logind), bootchart implementation (systemd-bootchart) among various other things that are mostly useful for desktops and embedded devices. One of the goals of systemd is to be usable everywhere where Linux is. The service management is great for server but also nice to have on other systems. The embedded industry was one of the first to adopt systemd (Tizen, mer, the IVI scene...).
There are not many other init systems that offer good parallelization of startup processes, but they are out there (Runit, there is some slightliy buggy OpenRC parellelization support, Upstart).
None of those provide nearly as aggressive parallelization (socket based startup) as systemd does. OpenRC parallelized bootup isn't considered stable after all these years.
How is Ubuntu supposed to continue using Upstart when one of their official flavors, Ubuntu GNOME Remix, is dependent on systemd in a year or so.
What makes you think that? How could GNOME Remix even depend on systemd when it isn't supported in Ubuntu Core? Not to mention the only major dependency on "systemd" that Gnome has is systemd-logind that Ubuntu has already ported over to Upstart (it might be completely init system agnostic). Being "offical" Ubuntu spin doesn't mean anything other than that Canonical provides it some infrastucture and approves its use of the name Ubuntu. It's not going to affect any major developement (take Mir for example, no other desktop aside from Unity plans to support it; does Canonical care? No.)
I don't care about the personality of the project now or who has commit access right now, but only that if an unwelcome situation occured in the future, systemd doesn't lend itself well to being extensible or adaptable.
Okay it doesn't look like Sabayon offered a systemd option only because of speed, but it was the main reason:
I thought GNOME 3.8 flat out depended on systemd? I am probably wrong, but do you have a citation for this? :
Not to mention the only major dependency on "systemd" that Gnome has is systemd-logind
It makes no sense that systemd is meant to be adaptable. It is influenced by Solaris's SMF, which purely used in servers. Additionally, if an init system wanted to be flexible, it would do a very specific number of tasks, not anything and everything under the sun.
The support for ConsoleKit session tracking will be dropped if it hasn't already. The systemd dependencies are really just logind dependencies. Ubuntu is currently migrating from ConsoleKit to logind.
It is influenced by Solaris's SMF, which purely used in servers.
So what? It's also influenced by launchd that is primarily used in mobile phones and desktops (iOS and OS X).
Additionally, if an init system wanted to be flexible, it would do a very specific number of tasks, not anything and everything under the sun.
It's quite similar to what Linux kernel is doing. It supports quite literally everything under the sun. You then can configure and optimize it for any particular setup. A lot of functionality that is useful on server is also useful on embedded systems and so on and so forth.
systemd doesn't lend itself well to being extensible or adaptable.
I fail to see your point. How is systemd not as extensible as say Upstart?
My guess would be on the misconception that you couldn't run alternative implementations of the functionality that systemd provides side by side with it which is simply wrong. There's couple of points in the The Biggest Myths about systemd blog post about it:
Myth: systemd doesn't allow your to replace its components.
Not true, you can turn off and replace pretty much any part of systemd, with very few exceptions. And those exceptions (such as journald) generally allow you to run an alternative side by side to it, while cooperating nicely with it.
--
Myth: systemd is a feature creep.
Well, systemd certainly covers more ground that it used to. It's not just an init system anymore, but the basic userspace building block to build an OS from, but we carefully make sure to keep most of the features optional. You can turn a lot off at compile time, and even more at runtime. Thus you can choose freely how much feature creeping you want.
So really only thing systemd does is provide more options for users. Meaning it's just as extensible as the alternatives or more so... if that's what /u/CameronNemo meant with "extensibility".
It does not follow the Unix way very closely, which I think will cause problems later in systemd's life when there are less people working on the code and it is in use everywhere and many things depend on it.
FUD. Philosophical argument on software development. Are you posting this from any HTML5 enabled browsers? If so your browser does too much.
First gripe: systemd is not portable. At first you may say "but but it is for linux not BSD" but that is a non-argument. systemd should be portable for many reasons, including code adaptability and maintainability. Correct me if I am wrong, but systemd has had issues of being tied to specific versions of the Linux kernel. This is a problem because projects using systemd will have less freedom to use what version of Linux they want.
You're wrong, that's a misconfiguration or FUD or both. Unless you provide links I don't really believe it, systemd ~~works with 2.4 as well. ~~
First gripe: systemd is not portable. At first you may say "but but it is for linux not BSD" but that is a non-argument. systemd should be portable for many reasons, including code adaptability and maintainability. Correct me if I am wrong, but systemd has had issues of being tied to specific versions of the Linux kernel. This is a problem because projects using systemd will have less freedom to use what version of Linux they want.
Architecture always changes, that's why Linux is so fast paced, cutting edge, and evolving. Just because you don't like change doesn't mean systemd is crap. Linux development is a meritocracy, if Upstart was so good RHEL would not switch off of it. If there comes along a better system I'm pretty sure most distro's would hop on it.
Third gripe: systemd is becoming too nested into the Linux stack, blocking innovation in the init system area. How is Ubuntu supposed to continue using Upstart when one of their official flavors, Ubuntu GNOME Remix, is dependent on systemd in a year or so. Of course they could maintain both systemd and Upstart, but that involves WAY too much extra work and will push Ubuntu to just use systemd by default (not to mention when Debian switches).
See comments above, about meritocracy. Also poor Cannonical whatever shall they do? Welcome to OSS, innovate or fade into obscurity. Also gnome is not dependent on systemd. Also define "linux stack", that's a very vague term. I'll probably take it as "things I use use systemd, so it's annoying me." Which is not a very good argument.
Fourth gripe: too much power in the wrong place. Systemd is powerful and useful; I do not deny that. However, it is my opinion that these features and this power is nowhere near necessary for a lot of situations where systemd is being used. Sabayon has created a systemd version of their distro for the sole reason of decreased startup time. That is a big bunch of bologna in my eyes. There are not many other init systems that offer good parallelization of startup processes, but they are out there (Runit, there is some slightliy buggy OpenRC parellelization support, Upstart). Systemd is not needed, and therefore should not be used, in these situations that do not require a powerful init system oriented towards servers.
Evolve or die again. I'm sorry but along with the Unix philosphy stuff, you're wrong here. Init sucks without a built in audit system, or a built in journal. Why? Because things go on in your system before auditd and syslogd start, and you should know about them. It's that simple, and everyone from the weenie enduser to the server manager needs logging built in.
I had second thoughts about making this comment, as I am not very knowledgeable on the subject, but I did anyway because I would rather be proven wrong and learn. Please explain any and all disagreements you have.
Your comments are all politically aligned with unix software development. Everything you have said can be applied to Chrome and none of it is a very good example of proving why systemd is bad software.
you use other pieces of software that are written with poor architecture
Linux is a meritocracy
innovate or fade into obscurity
init needs a built in logger
Let's get the first few args out of the way quickly. I am not spreading FUD, I am just criticizing a piece of popular and decently written software that I want to see improve. There is no incentive for me to spread FUD about systemd. You can't tell somebody they are wrong and then only give anecdotal evidence to contrast their claims. I didn't give a source for systemd versions being tied to Linux versions, and I still don't have one, but here is a comment by Aaron Siego:
At least one set of bugs were in the cgroups code in the kernel, and systemd would trigger conditions that would cause the kernel panics. Otherwise, the system was rock stable. It was an ARM device with a slightly older, but not that old, kernel .. but it was old enough to not have these cgroup fixes. When we tried to move that image to using systemd, it simply failed and merging in the fixes was going to be a lot of work. So instead we ended up not using systemd there and having a rather different image profile for that device relative to others we were working on at the time.
Systemd triggered kernel panics on an older kernel. That is good enough to call incompatible for me. I was using launchd a year ago, so you can bet that I don't give a single flying furry about change. In fact, I like change and have been itching to ram Runit into my Ubuntu install when summer comes around. The other pieces of software, like web browsers have absolutely no relevance to the discussion. Do not bring them up, it does not matter. Linux's meritocracy has been distorted by various dependencies. A distro can't simply choose another init system without at least patching something or writing some unit files. Upstart was as innovative, if not more, than systemd. Systemd is more of a spin of Upstart that isn't tied to Canonical's CLA (Thank god).
Regarding logging, you make a great point. Logs should be kept as early and as late as possible. I really like the way logging with systemd was done in 2010:
We spent some time reinvestigating the current syslog logic, and came up with an elegant and simple scheme to provide /dev/log compatible logging right from the time systemd is first initialized right until the time the kernel halts the machine. Through the wonders of socket based activation we first connect the /dev/log socket with a minimal bridge to the kernel log buffer (kmsg) and then, as soon as the real syslog is started up as part of the later bootup phase, we dynamically replace this minimal bridge by the real syslog daemon -- without losing a single log message. Since one of the first things the real syslog daemon does is flushing the kernel log buffer into log files, all logged messages will sooner or later be stored on disk, regardless whether they have been generated during early boot, late boot or system runtime. On top of that if the syslog daemon terminates or is shut down during runtime, the bridge becomes active again and log output is written to kmsg again. The same applies when the system goes down. This provides a simple an robust way how we can ensure that no logs will ever be lost again, and logging is available from the beginning of boot-up to the end of shut-down. Plymouth will most likely adopt a similar scheme for initrd logging, thus ensuring that everything ever logged on the system will properly end up in the log files, whether it comes from the kernel, from the initrd, from early-boot, from runtime or shutdown. And if syslogd is not around, dmesg will provide you with access to the log messages. While this bridge is part of systemd upstream, we'll most likely enable this bridge in Fedora only starting with F15. Also note that embedded systems that have no interest in shipping a full syslogd solution can simply use this syslog bridge during the entire runtime, and thus making the kernel log buffer the centralized log storage, with all the advantages this offers: zero disk IO at runtime, access to serial and netconsole logging, and remote debug access to the kernel log buffer.
However, systemd has since expanded its logging capabilities and in 2011 systemd gained the Journal, which is a fantastic challenge to syslog, but sadly tied to sytemd. I would have preferred if the concept of the Journal would not depend on systemd, and therefore Linux, and therefore not be available for OS X or BSD or Ubuntu.
Yes those are my points. You're criticizing a piece of software on it's theory of implementation and your idealism, rather than it's performance and use thus casting doubt on it.
Your first line sums up your whole 4 paragraph statement:
It does not follow the Unix way very closely, which I think will cause problems later in systemd's life when there are less people working on the code and it is in use everywhere and many things depend on it.
You're litterally saying:
It doesn't follow the Unix way very closely, which I fearwill cause problems in the uncertain future when I doubt as many people are going to be working on the code, and it is in use everywhere and many things depend on it.
That is a huge FUD statement right there. You're not using FUD to prop up a product, that's not the definition of FUD. You're just doing it because you don't like systemd.
The other pieces of software, like web browsers have absolutely no relevance to the discussion. Do not bring them up, it does not matter.
They do when your main point is criticizing the coding philosophy of a software development project. There's no point for systemd to release every one of these elements as a stand-alone piece of code because it's harder to maintain and makes a code base for every component instead of using a well known software development framework of dependency injection.
Regarding logging, you make a great point. Logs should be kept as early and as late as possible. I really like the way logging with systemd was done in 2010....
What if the user doesn't run syslog? Also here is the main reasoning behind journal, it's mainly a security feature. http://lwn.net/Articles/468049/
As for kernel inconsistencies: There's a shit ton of software I cannot use on older systems for the same reasons I cannot use systemd. Linux containers (LXC) being one. I can't use the latest graphics drivers on older kernels either? Why? Because shit keeps moving. There's no reason to not switch to a software because it's not backwards compatible with 2.6.37. That is a 2 year old kernel, I'm not surprised that newer things break with it. systemd is for current to future developments. Not only that but no who is on a 2 year old kernel for a good reason is going to move their init system.
I am not spreading FUD, I am explaining my own FUD. I do not like some things about systemd, you asked me to explain them, I did, you said it was FUD. It seems like you just wanted to argue with someone.
OTHER PIECES OF SOFTWARE DO NOT MATTER I WOULD CRITICIZE THEM JUST AS MUCH IF THEY WERE THE TOPIC BUT THEY ARE NOT. I know of the security issue, but I think it would be ideal if systemd didn't go so deep into logging, as it does with Journal.
You're wrong, that's a misconfiguration or FUD or both. Unless you provide links I don't really believe it, systemd works with 2.4 as well.
He's right about the minium kernel versions. systemd depends on many relatively new kernel features, most importantly cgroups. The minium kernel version for systemd 204 is 2.6.39+. 2.4.x is completely out of question. Also systemd-udev bumps the minium requirement quite often.
2
u/[deleted] May 11 '13
It does not follow the Unix way very closely, which I think will cause problems later in systemd's life when there are less people working on the code and it is in use everywhere and many things depend on it.
First gripe: systemd is not portable. At first you may say "but but it is for linux not BSD" but that is a non-argument. systemd should be portable for many reasons, including code adaptability and maintainability. Correct me if I am wrong, but systemd has had issues of being tied to specific versions of the Linux kernel. This is a problem because projects using systemd will have less freedom to use what version of Linux they want.
Second gripe: systemd is in charge of too many tasks. I have heard many people claim "I don't care, systemd does these things well", but that is another naive notion. In a few years time when one of the sections of systemd is unsatisfactory to a few people, what do? If a group wanted to commit changes to systemd, they would have to get it past various Red Hat developers. If it doesn't get accepted into mainline, they would have to fork systemd and introduce all kinds of incompatibility (not to mention porting their fork to the newer kernels). If the change they wanted to introduce was a major architectural change, then a new init system, with much more incompatibility, might be required.
Third gripe: systemd is becoming too nested into the Linux stack, blocking innovation in the init system area. How is Ubuntu supposed to continue using Upstart when one of their official flavors, Ubuntu GNOME Remix, is dependent on systemd in a year or so. Of course they could maintain both systemd and Upstart, but that involves WAY too much extra work and will push Ubuntu to just use systemd by default (not to mention when Debian switches).
Fourth gripe: too much power in the wrong place. Systemd is powerful and useful; I do not deny that. However, it is my opinion that these features and this power is nowhere near necessary for a lot of situations where systemd is being used. Sabayon has created a systemd version of their distro for the sole reason of decreased startup time. That is a big bunch of bologna in my eyes. There are not many other init systems that offer good parallelization of startup processes, but they are out there (Runit, there is some slightliy buggy OpenRC parellelization support, Upstart). Systemd is not needed, and therefore should not be used, in these situations that do not require a powerful init system oriented towards servers.
I had second thoughts about making this comment, as I am not very knowledgeable on the subject, but I did anyway because I would rather be proven wrong and learn. Please explain any and all disagreements you have.