Ask Slashdot: Practical Alternatives To Systemd? 533
First time accepted submitter systemDead (3645325) writes "I looked mostly with disinterest at Debian's decision last February to switch to
systemd as the default init system for their future operating system releases. The Debian GNU/Linux distribution is, after all, famous for allowing users greater freedom to choose what system components they want to install. This appeared to be the case with the init system, given the presence of packages such as sysvinit-core, upstart, and even openrc as alternatives to systemd.
Unfortunately, while still theoretically possible, installing an alternative init system means doing without a number of useful, even essential system programs. By design, systemd appears to be a full-blown everything-including-the-kitchen-sink solution to the relatively simple problem of starting up a Unix-like system. Systemd, for example, is a hard-coded dependency for installing Network Manager, probably the most user-friendly way for a desktop Linux system to connect to a wireless or wired network. Just this week, I woke up to find out that systemd had become a dependency for running PolicyKit, the suite of programs responsible for user privileges and permissions in a typical Linux desktop.
I was able to replace Network Manager with connman, a lightweight program originally developed for mobile devices. But with systemd infecting even the PolicyKit framework, I find myself faced with a dilemma. Should I just let systemd take over my entire system, or should I retreat to my old terminal-based computing in the hope that the horde of the systemDead don't take over the Linux kernel itself?
What are your plans for working with or working around systemd? Are there any mainstream GNU/Linux distros that haven't adopted and have no plans of migrating to systemd? Or is migrating to one of the bigger BSD systems the better and more future-proof solution?"
Unfortunately, while still theoretically possible, installing an alternative init system means doing without a number of useful, even essential system programs. By design, systemd appears to be a full-blown everything-including-the-kitchen-sink solution to the relatively simple problem of starting up a Unix-like system. Systemd, for example, is a hard-coded dependency for installing Network Manager, probably the most user-friendly way for a desktop Linux system to connect to a wireless or wired network. Just this week, I woke up to find out that systemd had become a dependency for running PolicyKit, the suite of programs responsible for user privileges and permissions in a typical Linux desktop.
I was able to replace Network Manager with connman, a lightweight program originally developed for mobile devices. But with systemd infecting even the PolicyKit framework, I find myself faced with a dilemma. Should I just let systemd take over my entire system, or should I retreat to my old terminal-based computing in the hope that the horde of the systemDead don't take over the Linux kernel itself?
What are your plans for working with or working around systemd? Are there any mainstream GNU/Linux distros that haven't adopted and have no plans of migrating to systemd? Or is migrating to one of the bigger BSD systems the better and more future-proof solution?"
Accept, don't fight, systemd (Score:3, Insightful)
Whether you love, hate, or are ambivalent about systemd, I think you have to accept it at this point. If there are things you don't like about it, trying to use an alternate init mechanism is only going to cause you personal grief that will likely only increase in severity over time as it gets harder and harder to retrofit software packages to use other init systems as systemd further embeds itself into the Linux software world.
If there are things you don't understand about systemd, you should read as much as you can to try to figure it out for yourself, and if you can't, you should write up coherent questions and post them in the appropriate forum for help (what is the appropriate forum? I don't know - someone jump in here and help me out. I personally often have no idea where the best place is to ask questions about things like systemd).
If there are things you don't like about systemd, you should write up coherent bug reports or feature requests, and get them in front of the right people (once gain, someone jump in here and say who these people are and how to get these types of requests out there, I actually don't know). Or better yet, make the improvements to systemd yourself if you are capable of doing so.
Your goal should be to improve both systemd itself and your knowledge of how to use it to the point where it is something you are happy to use, not work around it. By hook and by crook, systemd has become the standard way of doing many things in a typical Linux system and it's time for all of us to just accept that and to make forward progress. It's too late to try to work against systemd; it's time to "embrace and extend".
If systemd is so onerous to you that you can't use Linux anymore, then I guess BSD is a possible solution for you. But who knows, maybe BSD will eventually adopt systemd as well?
Re: (Score:3, Informative)
Don't hold your breath that BSD will adopt systemd. Maybe FreeBSD, but they are basically Linux flavoured BSD anyway. But the _serious_ 4.4BSD based systems just don't see the need, and are happy with the few lines of code that makes up a safe init.
Re:Accept, don't fight, systemd (Score:4, Informative)
Also, Lennart Poettering has noted he doesn't care about support anything !Linux, even if someone else maintains the code.
Re:Accept, don't fight, systemd (Score:5, Insightful)
the systemd init may be brilliant, if it would be isolated. But its mixed up with udev, syslog and even gnome to some extent. This cannot be an good idea, because stuff like init needs to KISS.
http://wizardofbits.tumblr.com... [tumblr.com]
Re:Accept, don't fight, systemd (Score:5, Interesting)
The problem is: A *tiny* init process won't be able to offer the *exactly same* functionality. The functionality has to come from somewhere, it does not fall from the sky: Some code needs to implement it.
If you want to keep PID 1 tiny then you can implement the actual functionality in separate processes. You now have two or more process and now you need code in the tiny init process that makes sure the controlling processes are getting started (and restarted). Remember: Those daemons provide the actual functionality, so PID1 can not depend on that to start those daemons in the first place.
You need code that facilitates a communication channel between the processes. You need code to lock out processes that are not meant to talk to your tiny init process. You need a protocol that the init process speaks and that allows it to be remote-controlled. All of sudden that tiny process is no longer tiny and your architecture is much more complex than it would be otherwise.
That complexity requires you to add more code to mitigate communication failures, to synchronize data structures between all the different processes that need access to them, you need to be careful not to introduce race conditions between those processes. In the end you end up with a pretty big init process and a bunch of big and nearly equally critical daemons surrounding it. I do understand where the systemd guys come from: Keep the architecture simple, and put absolute minimum amount of code into PID1 to provide the functionality they want. That makes the overall system less complex and easier to reason about, which is good for security and robustness.
Read the code, it is actually pretty ok.
Re: We'll keep on trucking without systemd garbage (Score:5, Informative)
Keep in mind that *BSD is not alone. There are other GNU/Linux distributions that avoid it. Gentoo are among the distributions working on things like eudev (so you can keep on using udev without systemd).
Re:Accept, don't fight, systemd (Score:4)
If anything, I'd expect it to be the reverse - large pieces of software that introduce systemd dependencies will lose users (especially when there are other good reasons to migrate away, as is the case with e.g. GNOME), and smaller pieces will simply be replaced.
Re:Accept, don't fight, systemd (Score:5, Insightful)
Wow....someone asks what they can do about having a software package shoved down there throat and your response is just open wide and swallow? I thought this was supposed to be about freedom. Wait, GNU/Linux is about freedom, as long as it's what they want you to do....
On a more serious note, any software that wants UNIX compatibility will keep supporting SystemV/BSD init. I get the distinct feeling that Oracle and especially the BSD guys don't want anything to do with systemD.
Re:Accept, don't fight, systemd (Score:5, Informative)
Solaris has it's own abomination called SMF. Good luck debugging network problems on Solaris without a GUI unless you're experienced with SMF. I use Solaris only to maintain my open source projects (I value portable code), and I _hate_ dealing with the system. So convoluted.
The system with the most straightforward configuration and init system, IMO, is OpenBSD. It's soooooooo nice. The only major change in nearly 15 years has been the move to an rc.d/ (init.d-style) startup script directory. Contrast that with number of convoluted changes in Linux administration over those past 15 years, and it seems like a miracle.
If SMF and launchd (OS X) are any indicator, I'm definitely going to hate working with systemd.
(NOTE: I haven't used Slackware since the 1990s, so maybe it's remained stable all these years, too. For Linux I tend to only use Debian and Ubuntu.)
Re: Accept, don't fight, systemd (Score:5, Informative)
Never used SMF, but systemd is quite a bit better than launchd. The configuration files are all plain text. The major difference from a configuration point of view is that instead of writing a script, you just specify executable information, dependencies, sockets, etc, in a config file. That's it. Doesn't seem like such a big deal to me and in many ways seems quite a bit better than sysV.
Re: Accept, don't fight, systemd (Score:5, Informative)
The configuration system for daemons that systemd has is an enormous leap forward over the old shell scripts. If systemd would stick to be an init system, it would not be such a problem.
When it takes over file system mounting, including hiding most mount points from /etc/fstab and breaking silently if there are perfectly valid mounts in there which it happens not to like, people complain.
When it takes over system logging, previously one of the major advantages of Unix-based systems over Windows, people complain.
And so on and so forth.
Re: Accept, don't fight, systemd (Score:5, Interesting)
When it takes over file system mounting, including hiding most mount points
I can see how this is annoying, especially when you don't know what is going on, but mounting filesystems is an integral part of the startup process and therefore should be managed (in part) by systemd. It was manged using the old sysV scripts too btw, so it is consistent as far as init systems go. The difference with systemd is it actually knows what a filesystem is and that it is different from a service, so it can manage and monitor them accordingly. What this means is that filesystems associated with booting (root, swap, dev, ...) are now systemd entries instead of /etc/fstab entries. Once you realize this, it is not that hard to manage. And /etc/fstab does still work, of course, for filesystems you want to manage yourself. There are reasons you might want to create systemd entries for those too, though. Automounting, for example, is handled much better with systemd than the old autofs route that we had to use before.
and breaking silently if there are perfectly valid mounts in there which it happens not to like
That is either a bug, or possibly a conflict. Again, I can see how it is annoying, but if you have an /etc/fstab entry that wants to steamroll a systemd entry, it is understandable that systemd will try to stop that from happening. The correct fix in that case would be to edit the systemd entry to match the changes you are trying to make with the /etc/fstab entry.
When it takes over system logging
So, systemd doesn't just start/stop services, it also monitors them and can be configured to take certain actions depending on what happens to a particular process. So, needless to say, logging is kind of inherent to the whole thing. Correct me if I'm wrong, but I don't think it "taking over logging" is your real objection, but rather the way in which it does its logging. Instead of splitting things into separate text files that are managed by their respective daemons, systemd collects all this information and stores it in a standardized, indexed way within its own file. This is a design decision, and with all design decisions there are tradeoffs. In this case you are sacrificing the ability to just cat/grep individual text files for the ability to filter and have other processes able to monitor the log files, as well as some benefits for auditing and security. I definitely prefer text files because I don't manage complex scenarios, but I can also see how journald is critical for certain enterprise infrastructure. If you don't like journald, you can install syslog-ng. You just have to make sure it doesn't trample on journald (ie: it has to listen on the journald socket instead of /dev/log). I believe CentOS 6 is configured this way (journald+syslog-ng), so it is not that unusual or hard to do.
Re: Accept, don't fight, systemd (Score:4, Insightful)
Again, I can see how it is annoying, but if you have an /etc/fstab entry that wants to steamroll a systemd entry, it is understandable that systemd will try to stop that from happening.
Or it could just honor fstab since that has always been the correct way to specify mounting a filesystem.
So, systemd doesn't just start/stop services, it also monitors them and can be configured to take certain actions depending on what happens to a particular process.
I see no reason that should need to touch system logging at all other than adding a log entry if it has to take action.
Re: (Score:3)
Sounds like systemd needs to handle mounting the Unix way.
Re: Accept, don't fight, systemd (Score:5, Insightful)
Do one thing well. Build more complex actions by putting smaller parts together. Swiss army knife system utilities need not apply. That is the Unix way.
Mount -a is the perfect way to mount filesystems needed to init the machine. The rest can be mounted by a daemon as they become available. My / filesystem resides on an HDD that is bolted in to the system, if it's not there, there is nothing to boot, so why does it need to be 'monitored'?
Re: (Score:3)
What this means is that filesystems associated with booting (root, swap, dev, ...) are now systemd entries instead of /etc/fstab entries.
What would have been lost by adding them to /etc/fstab? That way you would be able to tell systemd not to mount them, if need be, or to mount them elsewhere.
standardized, indexed way within its own file.
Said standard being the systemd source code of the day. No external tools can handle the format. journalctl performance is a complete joke, and that is in comparison to full-text grep of the text files -- quite an accomplishment actually.
"Note that the actual implementation in the systemd codebase is the only ultimately authoritative description of the
Re:Accept, don't fight, systemd (Score:5, Interesting)
That Oracle dislikes something isn't a condemnation. It's more nearly a recommendation.
That said, I'm dubious about systemd. I almost understand how to use init. OTOH, I prefer the interface of the pre-grub2 grub to the current one. I assume that there must be SOME benefits to the change, but I haven't found any. I expect to end up feeling the same way about systemd.
Re: Accept, don't fight, systemd (Score:5, Insightful)
Hate to break it to you, but when you install a distribution, you have a lot of software "shoved down your throat." It is what a distribution is, after all, and has been the case since forever. The maintainers decide what functionality is in the base system, what packages are installed in meta packages, what versions, what optional features to compile in. The only way around it is to use a source distribution like gentoo.
Re:Accept, don't fight, systemd (Score:4, Insightful)
Specious argument. Nobody said you *have* to accept systemd. I said you *should* accept systemd, and I gave reasons why you should. You still have the freedom to disagree and do your own thing regardless of what I say.
I would have thought that were so obvious that it didn't even necessitate your reply, but since you've been modded "+5 Interesting" I guess lots of people also completely missed the point.
Re:Accept, don't fight, systemd (Score:5, Insightful)
It's a theme on the Internet. If you don't qualify every minor nuance of your statement, or carve out an exception for every conceivable corner case, someone calls you out on it. Nothing can be left as an excercise for the reader, because too many readers are pedantic or intellectually dishonest.
Usually it's intentional equivocation masked as an attempt to sound intelligent or continue the argument when they no longer have a real point. Often they boil down to syntactic or semantic arguments, belaboring point after point until those with solid points are swarmed by nits. Unfortunately, that makes it very difficult to tell when someone is being obtuse versus when they are being curious or have a legitimate point.
Re: (Score:3)
The difference is in "I think you have to" versus "You have to".
Yes, there is a difference. Saying "you have to" is a command, and it does take away freedom when it is spoken by someone with authority to do so.
Saying "I think you have to" is the same as saying "you should". It's not a command, it's a suggestion.
Do you see the difference now?
Re: (Score:3)
It was called Slowlaris in large part because of STREAMS support, which was mandatory in SUS v1 and v2. I find it a bit sad that Solaris historically was ragged upon because it basically tried to follow de jure standards to a T, and backwards-compatibility was a high priority.
But that's a different discussion. Nowadays both Linux and Solaris derivatives have similar computational overheads: sometimes Linux comes out ahead, and sometimes Solaris. I think system administration is completely in favour of Solar
Re: (Score:3, Insightful)
Whether you love, hate, or are ambivalent about systemd, I think you have to accept it at this point.
Why hello Mr. Chamberlain, I wondered when you'd show up.
If there are things you don't understand about systemd, you should read as much as you can to try to figure it out for yourself, and if you can't, you should write up coherent questions and post them in the appropriate forum for help (what is the appropriate forum? I don't know - someone jump in here and help me out.
For such an influential piece of software driven by such high-falutin' names to be so poorly understandable is a bit of a poor show, wouldn't you agree?
By hook and by crook, systemd has become the standard way of doing many things in a typical Linux system and it's time for all of us to just accept that and to make forward progress. It's too late to try to work against systemd; it's time to "embrace and extend".
How... interesting that you're basically declaring systemd to be gospel and everyone's saviour, when it is but the latest take by people who, let's face it, aren't that great with systems design, and aren't all that responsive to critique. Is that why you are advocating no longer offering critique? The
Re: (Score:3, Insightful)
Someone Godwins a discussion about the merits of Linux bootup mechanisms. Someone else mods that Insightful. All that's missing is for someone to compare tmpfs to a death camp... Oops, too late.
And 4chan gets called the Goatse of the Internet.
Re: (Score:3)
"Just accept it. It's inevitable. Just give in. Help make it better instead of fighting it." Yuck. Talk about slimy propaganda. Admittedly, I like the idea of the theoretically better process scheduling using kernel control groups, but the rest is really just overrated.
Re: (Score:3, Insightful)
OK fine then, don't accept it. Waste your time and money fighting the inevitable, just so that you can be "right", when you could have spent less time and money cooperating on fixing the thing so that you can be "right" *AND* have more time and money in the end, and a better outcome all the way around.
Look, I don't love systemd; I quite dislike it in fact. But it should be pretty clear to any moron that it's already become entrenched and it's not going anywhere. So you can cry and try to take your ball a
Re:Accept, don't fight, systemd (Score:4, Interesting)
Your statements are more prescient then I think you realize.
It IS kind of like the Borg; there is kind of like a "hive mind" in open source; whatever the most people think should happen, is what will happen. There is no central authority to dictate that anything other than what the majority wants should happen.
In this case, it's pretty clear that, since all the major distros have accepted systemd, that it's been accepted by the majority of users and become the de facto standard. There seems to be alot of momentum behind it.
I could of course be wrong; maybe it just looks that way, and maybe there is enough of a seething hatred underneath the covers for systemd that it will be ousted soon. But in the meantime, what are you going to do? Just hope, pray, and wait for that to happen? Why not try to improve the thing instead of complaining about it hoping it will go away?
An alternative to my suggestion that people accept systemd and learn to use it, and work to improve it to make it better, is the suggestion that you "take to the streets" and actively fight against systemd rather than accepting it.
You can suggest that to people if you want to; it's just that I don't think it will work and I think those people will waste their time and energy. And I won't suggest to people that they should waste their time and energy on something, especially something that has no moral or ethical implications and is just freaking OPEN SOURCE SOFTWARE that we can all change for the better if we want to.
Re:Accept, don't fight, systemd (Score:4, Interesting)
You are wrong, and fundamentally wrongheaded.
"If there are things you don't like about it, trying to use an alternate init mechanism is only going to cause you personal grief that will likely only increase in severity over time as it gets harder and harder to retrofit software packages to use other init systems as systemd further embeds itself into the Linux software world."
And if we accept your advice we ensure that catastrophe. No thanks.
"If there are things you don't like about systemd, you should write up coherent bug reports or feature requests, and get them in front of the right people (once gain, someone jump in here and say who these people are and how to get these types of requests out there, I actually don't know). Or better yet, make the improvements to systemd yourself if you are capable of doing so."
This advice does not fit the situation at all. Bug reports and feature requests? You do not fix a fundamentally mis-specified and mis-designed program with bug patches and requests for even more misfeatures!
"Your goal should be to improve both systemd itself"
This makes no sense whatsoever. I dont want to 'improve' it I dont want it period. Init works great. It's not broken, dont fix it.
"By hook and by crook, systemd has become the standard way"
Negative. Init is the standard way. What's happened is that the number and visibility of the deviationists has increased. Popularity along is not sufficient to change a standard.
"If systemd is so onerous to you that you can't use Linux anymore"
Huh? Cant use linux? WTF are you talking about?
I am pretty sure that Linus has no plans to integrate this trash into the kernel. And if he did that would just mean it's finally time for a fork.
No... (Score:5, Informative)
There are significant numbers of people who understand it just perfectly and have valid criticisms that are not bugs.
http://ewontfix.com/14/ [ewontfix.com]
The systemd team has pissed of Torvalds:
https://lwn.net/Articles/59368... [lwn.net]
Additionally, they repeatedly deny that anyone should have a text log for any reason, dismissing criticisms as 'just hook in syslog *too* as an *optional* thing'. Basically systemd discards decades of sensibilities ecosystem to 'do it better', while throwing out the baby with the bathwater (ditching modularity and portable log data and such).
It's not just that 'if you don't like it, fix it'. People don't like the very fundamental aspects of the design that the systemd did *on purpose*.
Re: (Score:3)
The attitude however seems to be "if you don't like it, don't use linux". Everything about this goes deeply against the style of linux and unix.
Re: (Score:3, Insightful)
How about if it isnt broken, dont fix it? Isnt that still valid?
BSD init works great. First you want me to replace it with an overengineered monstrosity that offers me no benefit, and then when I refuse, you think *I* should fix it? Why? Why would I bother fixing it when I dont want or need it?
OK, fine, for the sake of argument let's say I should fix it. Easily done. Delete the whole damn tree, and replace it with init. Job done, let's get a beer.
Sheesh.
Re:No... (Score:5, Insightful)
If you think sysv init is not broken, then you must not have been using unix systems in earnest.
It is only simple till you want to have a reliable boot without races... BSD init is way simpler, true, but then that was deemed to be too inflexible already in the golden times of Unix. You really want to go back to that? Seriously?
You are aware that udev is part of that tree you are proposing to delete? With eSATA harddrives coming and going, projectors that get attached at random times, all kinds of gadgets with USB connectors? No thanks, I want something that I do not need to change a the boot script and then reboot when I plug in a mouse.
Let me keep systemd and go straight for a beer instead of bombing my system back into the 60s.
That way I can also update all the software I care about (much of it already depends on systemd or will do so soon), I get /var/log,
* the journal instead of a set of randomly formatted text-dumps all over
* a convenient way to kill apache with all the crap that it started,
* a more robust boot process that is not sprinkled with sleep 5 statements to give daemons enough time to be fully up before bringing up services that depend on them being there.
* a more secure system by being able to isolate daemons from one another and the rest of the system.
* a lot of convenient system config tools that work on (almost) all modern Linux distributions and do so even better that the "do one thing and do it well" tools that got replaced by them
Sheesh:-)
Re:No... (Score:5, Insightful)
BSD init is way simpler, true, but then that was deemed to be too inflexible already in the golden times of Unix
These are the golden times of Unix.
You really want to go back to that? Seriously?
You sound like its a bad thing. Its not.
the journal instead of a set of randomly formatted text-dumps all over /var/log,
I'll take the text-dumps any day, thanks. And since they're usually created via *syslog*, they may not even be stored locally. And they are easy to manipulate with the available shell tools (grep; cat; awk; etc). If you want a database-driven syslog, there are plenty around.
a convenient way to kill apache with all the crap that it started,
It seems you're getting closer to the real problem. Apparently you don't know how to operate a vaguely modern unix system.
a more robust boot process that is not sprinkled with sleep 5 statements to give daemons enough time to be fully up before bringing up services that depend on them being there.
Usually the sleeps are for hardware settling, not for script startup. Eg. when you plug a USB device that may take a couple of seconds to be available after powering on. This will be needed *regardless* of what script is running the show. And dependency management on start scripts is a solved problem. Have a look at FreeBSD/NetBSD rc.d system, or Solaris SMF.
a more secure system by being able to isolate daemons from one another and the rest of the system.
So, its a startup daemon AND a kernel, huh?
a lot of convenient system config tools that work on (almost) all modern Linux distributions and do so even better that the "do one thing and do it well" tools that got replaced by them
Convenient for who? For you, because you cannot be bothered into using the existing tools? You may have some unusual requirements, it doesn't mean everyone else has the same needs. And while I'd applause a sort-of-standard way of bootstrapping Linux distros, adding complexity seems to be a pretty stupid approach.
Re:No... (Score:5, Insightful)
the journal instead of a set of randomly formatted text-dumps all over /var/log,
I'll take the text-dumps any day, thanks. And since they're usually created via *syslog*, they may not even be stored locally. And they are easy to manipulate with the available shell tools (grep; cat; awk; etc). If you want a database-driven syslog, there are plenty around.
You can wire up syslog to the journal. Why would you want to convert rich information into a string and shove it down a pipe before you make use of it? Let's start with a useful format and use lossy conversion methods on that when needed, not the other way around.
You are not ripping your CDs to mp3s either so that you can burn other CDs by converting those mp3 files to WAVs either, do you?
a convenient way to kill apache with all the crap that it started,
It seems you're getting closer to the real problem. Apparently you don't know how to operate a vaguely modern unix system.
So please enlighten me: How do you kill apache with all the php/ruby/whatnot crap it directly or indirectly spawned? With systemd it is just one convenient systemctl stop apache
Please do not assume that I am too young or too stupid to know the good old ways. I have been around for a while, even though I still have not managed to learn not to get into discussions at slashdot that are bound to end up in namecalling.
a more robust boot process that is not sprinkled with sleep 5 statements to give daemons enough time to be fully up before bringing up services that depend on them being there.
Usually the sleeps are for hardware settling, not for script startup. Eg. when you plug a USB device that may take a couple of seconds to be available after powering on. This will be needed *regardless* of what script is running the show. And dependency management on start scripts is a solved problem. Have a look at FreeBSD/NetBSD rc.d system, or Solaris SMF.
I was more thinking about starting postgres before the server that uses that DB to store its stuff. Grep for "sleep" in the init scripts of the sysv-init distribution of your choice: You will be surprised.
a more secure system by being able to isolate daemons from one another and the rest of the system.
So, its a startup daemon AND a kernel, huh?
Check out http://www.freedesktop.org/sof... [freedesktop.org] , especially all the options starting with "Private" there.
a lot of convenient system config tools that work on (almost) all modern Linux distributions and do so even better that the "do one thing and do it well" tools that got replaced by them
Convenient for who? For you, because you cannot be bothered into using the existing tools? You may have some unusual requirements, it doesn't mean everyone else has the same needs. And while I'd applause a sort-of-standard way of bootstrapping Linux distros, adding complexity seems to be a pretty stupid approach.
Convenient for everybody. Just try the things that come with systemd. Most are a real improvement over the existing tools to manage hostname/date/time/timezone/locale/service/network/efi boot loader/virtual machine/whatnot. At the very least they are way more consistent in how they work and they work on all modern Linux distros in the same way. That was never possible before.
Yes, I know: Just suggesting to look into systemd is sacrelegious:-) Sorry, I won't do that again.
Let's just wait a year or two. By then all the hotheads that are running for the BSDs now will be back, everybody will be using systemd (including gentoo and slackware) since it clearly is the best approach available right now. When somebody finally comes along in 10 or 15 years with a good idea to replace systemd she will be yelled at for breaking away from the tried and true systemd that has been good enough for everybody this past decade.
Re:No... (Score:4, Insightful)
"If you think sysv init is not broken, then you must not have been using unix systems in earnest."
SysV is broken, yes, and systemd is worse. I do not use or want either of them.
"BSD init is way simpler, true, but then that was deemed to be too inflexible already in the golden times of Unix. You really want to go back to that? Seriously?"
What go back? Never left. [slackware.com]
"the journal instead of a set of randomly formatted text-dumps all over /var/log,"
A huge regression. Replacing a simple, robust, well supported system with something overly complicated is NOT a gain for me.
"a convenient way to kill apache with all the crap that it started,"
Something wrong with apachectl stop?
"a more robust boot process that is not sprinkled with sleep 5 statements to give daemons enough time to be fully up before bringing up services that depend on them being there."
You're confused, you actually getting a less robust boot process here. But it will be faster!
Well, ok. My computer boots fast enough without it, thanks.
"a more secure system by being able to isolate daemons from one another and the rest of the system."
A far less secure system actually. Without it, the only real attack front is sshd. With it, we suddenly have another front to worry about - and an attack here is likely to be much more damaging.
"a lot of convenient system config tools that work on (almost) all modern Linux distributions and do so even better that the "do one thing and do it well" tools that got replaced by them"
You REALLY seem confused now. You have the players backwards.
"Sheesh:-)"
Exactly.
Re: (Score:3)
"a convenient way to kill apache with all the crap that it started,"
Something wrong with apachectl stop?
That kill apache, not the crap it started and that forked itself away.
"a more robust boot process that is not sprinkled with sleep 5 statements to give daemons enough time to be fully up before bringing up services that depend on them being there."
You're confused, you actually getting a less robust boot process here. But it will be faster!
Well, ok. My computer boots fast enough without it, thanks.
Systemd can set up filesystems without racing, something that is not possible with sysv init. No more races makes for a more robust boot. In fact systemd does address most of the race issues found in the debian init system. Go and check their bug tracker if you do not believe me.
That you were unable to configure your system to make it boot with systemd is anecdotal evidence at best. I bet it did not boot right away when you installed your
Re:No... (Score:4, Insightful)
I cant be completely sure here, but there is a funny pattern I have noticed over the years that may explain your experience. Over and over again, I hear about problems that require these over-engineered solutions from people running over-engineered distros that I just cannot reproduce using my (cleaner) system. So I suspect somewhere in your excessively complex system you have managed to break apache in a way that I cannot reproduce using a simpler system.
And yet this is an argument for introducing yet more excessive complexity to remedy? Doesnt make sense to me.
"Systemd can set up filesystems without racing, something that is not possible with sysv init. No more races makes for a more robust boot. In fact systemd does address most of the race issues found in the debian init system. Go and check their bug tracker if you do not believe me."
Why would I care? I dont use that system and am not affected by their bugs.
"That you were unable to configure your system to make it boot with systemd is anecdotal evidence at best."
It's not anecdotal evidence it's an invention on your part. WTF? You lost the thread man.
Re:No... (Score:5, Insightful)
the journal instead of a set of randomly formatted text-dumps all over /var/log,
Yes, those would be called, errr, yes, LOGS.......
As a sys admin I want something I can read when my system goes wrong and I don't want to have to get a retarded web server up and running to read them.
Seriously, people suggesting this kind of retarded shit don't know Unix, don't know Linux and don't have the faintest idea whatsoever. Go and read a Windows registry file, have fun and knock yourself out but don't bring that retarded crap so an operating system that actually works.
Re:No... (Score:5, Insightful)
I just spent a merry 45 minutes trying to get Fedora 20 back up and running after a reboot. Systemd kept knocking it into Emergency Mode with no indication as to why. I'm still not certain whether it was a failing mount or a video card acting up. Or something else I don't know about yet.
SysV init is unquestionably feeble when it comes to controlling systems with complex daemon interdependencies. But putting stuff into sealed packages with No User Serviceable Parts Inside is not the way to go. I had to deal with that under OS/2 and it's one of the things I hated most about OS/2.
There is a tendency these days to offer a "complete solution" and to sneer at the ungrateful unwashed masses. But complete solutions never turn out to be complete enough. And these "Complete Solutions" are infamous for eliminating popular features that were in their predecessors. The systemctl facility admits that there are certain things that it cannot at present do that the cruder, but more flexible scripts of SystemV supported, and it's far from the worst offender.
Unix was developed on the philosophy that you didn't attempt to make one program do everything, you strung together simpler tools. Likewise, it logged to plain text files, which makes them accessible to a whole raft of text utilities, instead of a handful of specialized log utilities a la IBM. Besides which, a text file has to be seriously mangled before it's totally useless when everything's shot to Hell. Most binary files break far more easily and are far harder to repair.
If we forget where we came from, we're going to end up acquiring many of the same faults as Windows.
Re: (Score:3)
The ewontfix.com/14 article is full of factual errors and was rebunked several times by more knowlegable people.
Interesting. I'd like to see it. Citation?
Re: (Score:3)
The ewontfix.com/14 article is full of factual errors and was rebunked several times by more knowlegable people.
No it hasn't. Process ID 1 should do very little. That has always been the premise of init systems. When you've got something that does the exact opposite then you've got a problem.
And Linus is pretty easy to piss off, what does that prove?
It's not often he calls into question the competence of a bunch of maintainers and effectively labels them as morons.
The software depends on systemd since it solves real problems that software used to be facing. When a wide group of developers sees value in using systemd, then maybe reading up on it (past the point where you go "oh, we never did it like that before") might be warranted?
Open source developers have often linked to bits of software long since discarded as bad ideas through real-world experience. Besides, what 'real world problems'? Linux requires a functioning init system that doesn
Re:No... (Score:4, Informative)
Because openRC is not even in the same league as upstart. And systemd leaves upstart in the dust -- which is why debian went for that instead of upstart. Read the technical comitees findings: Most TC members wrote a summary explaining their decisions and those are really full of good technical information. There is a lot of cruft in between those posts though.
If you do not believe me or think the Debian technical comitee to be biased: Read up on why the people responsible for the software that now moves to depend on systemd do that. Most did provide a solid reasoning for their decision. One argument is that it is available everywhere, but then there is the great cgroup stuff (systemd can reliably stop services incl. all their children -- finally), security features (like private temp dirs for services, etc.) that are really easy to do, simple configuration language for the services (*way* simpler than sysv init scripts), proper logs for everything, simpler debugging of services (the status output of the service contains the last log lines -- you do get used to that really fast!).
Could all that be implemented in a different way? Sure. But nobody did it yet. Maybe openRC will at some point implement all that and be a serious contender? I doubt it, but who knows.
Re:No... (Score:4)
I don't see how systemd could be any better at stopping runaway/zombie'd processes than the kill command. The cgroup stuff is interesting, but not worth the rest of the complexity. I don't think anyone is saying that sysV init is perfect, but that it is good enough to do what needs doing without being over complicated. In terms of 'proper logs', to me a proper log is a text file that can be easily searched without using some fumble fuck interface that reminds me of event viewer in windows or it's horrid powershell command line backend.
Maybe people would be more receptive to systemd if it weren't a huge monolithic solution that runs counter to 40 years of unix evolution that has worked quite well.
Re:No... (Score:5, Informative)
Those interested may look at LWN's report for a saner, more balanced view: http://lwn.net/Articles/593676/ [lwn.net]
Re: (Score:3)
Re:No... (Score:5, Insightful)
No, he's saying you shouldnt write software that is more complex than it needs to be *for a critical system component* - and he's right. Get as complex as you want to be in your application, but things like init systems need to be taken more seriously.
Re:No... (Score:4, Insightful)
I dont see anything there that Slackware has ever given me a problem with. I know it supports cgroups, mount handling? You mean automounting removable drives on insertion? That was working for years before anyone ever heard of systemd.
On the other hand socket activation [0pointer.de] is not to the best of my knowledge supported, but I think that's a good thing. What a horrible hack! They took something very simple, logical, and robust (serial activation of services) and made it orders of magnitude more complicated, doubtless creating bugs that we will be discovering for many years to come in the process, and for what? To shave 5 seconds off a task that that you might need to do once a year? In what twisted alternate reality would this possibly seem like a good idea to anyone?
You know what is even more effective at removing race conditions? Serial activation. And all it costs is a few extra seconds in the rare event of a reboot.
Re:Accept, don't fight, systemd (Score:4, Insightful)
Yes, there was. For a long time, they existed in parallel. Nobody minded because neither tried to make everything under the sun depend on it rather than the other.
In fact, there's no technical reason systemd couldn't peacefully co-exist.
Hmm (Score:5, Insightful)
PolicyKit specifically can be compiled to use consolekit instead of systemd for session tracking (this is actually the default, you have to explicitly compile policykit with systemd support).
Unfortunately this is kind of the downside to binary based package management. Either PolicyKit has to be modified to support both as configurable options, probably involving a maze of symlinks and wrapper scripts, or separate policykit-systemd and policykit-consolekit packages have to be provided.
If Debian has decided to to go with systemd, this is probably going to be a common issue on that distro, as when given the option of compiling something with it, they probably will.
Aside from joining us over on the gentoo side (open-rc is life but using something else is easier as it's just a use flag for most packages), or maintaining your own sizable collection of custom-built packages, don't know what to tell you!
Re:Hmm (Score:5, Interesting)
PolicyKit specifically can be compiled to use consolekit instead of systemd for session tracking.
Except that, last I heard, Lennart is also the maintainer of ConsoleKit, and he has officially declared it dead in favor of systemd-logind. Seriously, the reason everyone choses systemd is because it's just better. And as a former Gentoo dev with a good knowledge of openrc, systemd is one or two levels above.
Re: (Score:3, Insightful)
It being "better" is still open to debate no matter how good your knowledge of openrc is. Extra complexity is extra complexity, and making arbitrary choices just because you feel they are superior doesn't actually make them superior or any less arbitrary. If everyone chose systemd, we wouldn't be regularly having these debates.
Re:Hmm (Score:4, Insightful)
And as a former Gentoo dev with a good knowledge of openrc, systemd is one or two levels above.
How? I'm ont being snide. I have an arch system that went through the upgrade. I don't see much difference. Basically none at all. What is, in practice, actually better about it for dat-to day use and administration?
Re:Hmm (Score:5, Interesting)
I am extremely suspicious of so many folks with 3 digit IDs coming out strongly in favor of the inevitability of systemd.
I strongly dislike systemd and Pottering and I am shocked that Linux is evolving in this way. It seems like a concerted and coordinated effort. It seems like someone is driving a poison dagger deep into the heart of Linux.
I would be interested in hearing why exactly you are in favor of giving up the *nix way? Is "one or two levels above" really worth it when it costs so much more?
Re: (Score:3)
For every complex problem, there is a solution that is simple, easy, and wrong. Bootstrap/init is a complex problem, and systemd covers more of that complexity than previous solutions.
As for the three digit UUID observation, that's because those people where there at the beginning. If they're still active today, of course they would have strong opinions - they have a lot of experience to draw on.
Re: (Score:3)
systemd is best avoided. Avoid! Avoid! Avoid!
(pulseaudio, avahi, systemd. Why are these things all such a f*cking bear to deal with? Why, oh why?)
CentOS might work for you, if you don't feel the need to be completely modern. No systemd in Centos 6. I expect to see in in RHEL 7 / CentOS 7, though.
Re:Hmm (Score:4, Informative)
Yep, it works, I don't get any headaches from running it, so therefore it is OK.
I have started to look into the workings of systemd, and it certainly seems fine for modifying service dependencies, writing my own daemon, and customising the startup (though that is a rather ambiguous phrase). I can even use a sysv init script within a systemd service file, if I wanted to. You don't need to add debug output with systemd, because you don't need to write a script to start a daemon. It just starts the daemon you configure in a service file, and logs any output. That works for me, and to be honest, is actually much simpler.
Understanding bash syntax isn't as useful on HP-UX and FreeBSD. That shell isn't guaranteed to be available. A sysv init script isn't as portable as you make it out to be, because of inconsistencies between the different systems you mentioned. Good luck getting a Slackware init script to run on HP-UX. You _could_ make a portable script, I suppose. So that is an advantage, even if it takes extra work to properly test the script on every type of system you need to run it on. But if you have any Solaris SMF systems, portability goes down the drain.
Systemd is a change in the way thing run. It takes some adjusting and getting used to. If you make the effort, you'll find that you can make it work for what you want. That's an OK in my books.
Privilege to start a service (Score:3)
(not demand start, but that's very UNIX anyway: in UNIX(tm), things start when they're configured to during boot
For workstations, especially portable ones, shorter boot time is a marketing bullet point that differentiates one system producer from another. So as little should "start [...] during boot" as needed.
or when a USER f***ing starts them.)
But then you have to provide some way for the system to decide which USER is allowed to "f***ing start" each service. Or do you really want to have to wait for a member of the wheel group to show up to enter the command and password to "f***ing start" your machine's network driver? How is that better than letti
Re: (Score:3)
A few minutes time is all that is needed to come up with an setuid init.d wrapper that can check a text file to see if you are allowed to start/spot a particular service. No need to rip up the whole system for that.
The network can already demand start/stop without dependency hell. It's been available for a few years now in the form of NetworkManager.
I wrote OpenRC (Score:5, Informative)
And now I use NetBSD.
systemd also has its own NetworkManager wanna be in the making as well. I also dislike this.
For shameless plug I currently maintain dhcpcd which does your DHCP, IPv4LL, IPv6RS and DHCPv6. Other nicities like carrier detection, SSID and ARP profiles, routing preferences all come as standard. All in 155k. For kicks there is even a basic GTK+ system tray notification widget that also talks to wpa supplicant to allow wireless network selection and password entry.
Re:I wrote OpenRC (Score:5, Insightful)
Thanks for OpenRC. I *love* how it works on my Gentoo system. The ability to load custom variables for any script with /etc/conf.d files is wonderful.
I've gone a bit crazy with my /etc/conf.d/net, automatically setting up a ssh tunnel home if it sees that it's on an outside network (and trying several methods to get the tunnel working). If it's on ethernet, it switches the WiFi to being an access point. Lots of fun. I just wish the preup()/postup() functions were part of all the init scripts, not just the net script.
I also make use of /lib/dhcpcd-hooks to clean things up if the local network is unfriendly. If the provided DNS server mangles entries for non-existent domains, and if it doesn't block Google, it switches over transparently in my local script.
The paradigm of letting the user modify the behavior through regular shell scripts is extremely powerful. Thanks for keeping it alive.
Too much integration (Score:3, Informative)
with Gnome and other bits for my liking. This is like PulseAudio. It's not that good and it seems everyone is adopting it. The issue with FOSS is the desire for change that is too quick rather than fixing what works. LILO, for example. While GRUB is great, LILO worked fine for me and in fact, it still used by many distros. FOSS has become bloated like its commercial counterpart.
Recently I installed the still-in-alpha Haiku OS because I miss BeOS (still). The entire OS installed in less than 2 minutes. Talk about *fast*. It it were not for the lack of decent software, I would make the move today. Haikuware does have some great software, though. BeOS was awesome and kept it simple. Written from the ground up to remove the mistakes traditional UNIX and Linux were/are still making.
Re:Too much integration (Score:5, Insightful)
To be fair, LILO is very primitive and sensitive. It doesn't read filesystems; it has an installed map (the result of running lilo) that lists the exact blocks to load for a given entry. You cannot load anything that's not in its map. Touch any of those blocks and it can fall apart. GRUB was a vast improvement, but also adds a great deal of complexity. (GRUB2 even more so.)
Emacs (Score:4, Funny)
Re:Emacs (Score:4, Insightful)
Not yet, but eventually [gnu.org]. Systemd has all of the bloat of emacs, without any of the benefits.
Linux no longer wants to even look like Unix (Score:5, Insightful)
Your immediate recourse is, indeed, to try and sample the *BSD offerings. Their rc.conf approach I find a lot simpler to deal with than sysv's kludgy linkfarming ever was. It works very well without imposing all sorts of requirements on the rest of the system.
But the problem is political, and so the solution isn't technical. On the political side, I'm highly annoyed by the approach that resulted in this damage, but it's actually endemic in the linux world: Identify problem, then go berserk on the over-re-design-engineering like you're deliberately aiming for a strong case of second-system effect. One (and my pet-) example is the "better replacements" to their broken ifconfig, incompatible with everyone else (and three mutually incompatible attempts down the road there's no end in sight), but there are many more. The latest batch just have taken the previous failures to new heights of technically working incompetence.
What is new-ish is that the damage is spreading, in the sense that by design systemd is linux-only yet now various programs that previously worked on Unix in general are starting to depend on it. Apparently a certain bunch of influential people in the linux-sphere want to become their own vendor-lock-in-enabled bubble, to be the next redmond. This is... not good.
There really is very little recourse other than starting your own lobby war to stop the bunch. Because the problem is mostly politican, the technical side is but a symptom, almost a sideshow.
Without political pressure, soon linux will be akin to macosx, except with poorer code quality and less unified design: Technically some Unix-heritage, in practice it's its own thing, incompatible with the world. So if you'd like a Unix, your route is to *BSD. If not, you can stay and put up with the slowly mounting pile of crap of which systemd is but one thing, if possibly a tipping point-inducing thing. The *BSD people will still have to find some sort of answer, and soon, or they'll have to decide that everything depending on systemd+friends will be a lost cause anyhow and find alternative software with similar functionality, for the current crop no longer works outside of this brave new linux.
Slackware (Score:5, Informative)
Re: (Score:3)
Go Slack!
Re: (Score:3)
"Slackware is an alternative mainstream Linux distribution"
Funny that one of the oldest distribution (1993) has become an "alternative" one...
I use Slackware since 1995 and I have viewed it as "alternative" before ;-)
Re: (Score:3)
Re: (Score:3)
I'm actually surprised that so many people readily accept Ubuntu as mainstream, I'm still stuck thinking that it's an upstart newcomer until I look at the calendar.
Re: (Score:3)
Re: (Score:3)
I've been Slackware for a long time. I had been stuck on 12.something for a long time and recently jumped up to 14.1. Very impressed with the changes.
Re: (Score:3)
Me too, but then I never left :)
Slackware (Score:5, Insightful)
If you really must avoid systemd, then Slackware is probably the way to go. Alternatively, FreeBSD/PC-BSD are prettly much safe from ever getting systemd. For now you could stick with Debian Stable or Ubuntu LTS, both of them will run for years on the older init systems. So, really, you are pretty safe from systemd for at least three to five years, even in the Debian/Ubuntu corner of the Linux ecosystem.
But, really, you might ask yourself why go to all the trouble? Is it a philosophy issue? Is it just hating change? Is there something technical causing problems with your computer that is caused by systemd? A lot of people claim to hate it, but rarely give any practical reasons. Sure, there are plenty of philosophical issues with systemd (and lots of personal issues where its developers are concerned), but take a good long look at why you don't like systemd before you try to avoid it.
Comment removed (Score:5, Interesting)
GNU Is Working on It (Score:3)
See Daemon Managing Daemon [gnu.org]. It was written in the early-00s for the Hurd, languished for the better part of a decade, and has been picked up again. It has a model kind of like systemd, only without the Windows braindamage (I mean come on, ini files as a programming language [lwn.net]?). Development on DMD is pretty active now [gnu.org], and it's written in Scheme instead of C so mere mortals can hack on it. The design is pretty interesting, and makes extending things easy. E.g. imagine you run an openafs cell and need a service to grab Kerberos tickets and afs tokens at start. You can just register interest in the service in another service and have it Just Work (tm). From the looks of it, you may even be able to just write a single "Kerberize all the services" service. Better than sysvinit (oh joy, forking an init script) and better than systemd (oh joy, forking an ini-file-pretending-its-not-a-program)..
depinit (Score:5, Informative)
depinit. written by richard lightman because he too did not trust the overcomplexity of sysv initscripts and wanted parallelism, it was adopted by linux from scratch and seriously considered for adoption in gentoo at the time. richard is extremely reclusive and his web site is now offline: you can get a copy of depinit however using archive.org.
using depinit in 2006 i had a boot to X11 on a 1ghz pentium in 17 seconds, and a shutdown time of under three. depinit has two types of services: one is the "legacy" service (supporting old style /etc/init.d/backgrounddaemon) and the other relied on stdin and stdout redirection. in depinit you can not only chain services together for their dependencies but also chain their *stdin and stout* _and_ stderr together.
that has some very interesting implications. for example: rather than have some stupid system which monitors /var/log/apache2/logfile for security alerts or /var/log/auth.log for sshd attacks, what you do is run sshd or apache2 as a *foreground* service outputting log messages to stderr, chained to a "security analysis" service which then chains to a log file service.
the "security analysis" service could then *immediately* check the output looking for unauthorised logins and *immediately* ban repeat offenders by blocking their IP address, rather than having to either poll the files (with associated delays and/or CPU untilisation) or have some insane complex monitoring of inodes which _still_ has associated delays.
also depinit catches *all* signals - not just a few - and allows services to be activated based on those signals. richard also had a break-in on one system, and they deployed the usual fork-and-continue trick, so he wrote some code which allowed the service-stopping code to up the agressiveness on hunting down and killing child processes. this also turned out to be very useful in cases where services went a bit awry.
basically the list of innovations that richard added to depinit is very very long, in what is actually an extremely small amount of code. i simply haven't the space to list them all, and no, richard was not a fan of network-manager either.
btw you might also want to look at the replacement for /bin/login that richard wrote. it was f****g awesome. basically what he did was use gpg key passphrases as the login credentials.... and ran gpg-agent automatically as part of the *login*. i have never even seen a PAM module which does this trick. it would be awesome to do the same trick for ssh as well.
it's fascinating what someone can get up to when they have the programming skill and the logical reasoning abilities to analyse existing systems that everyone else takes for granted, work out that those sytems are actually not up to scratch and can write their *own* replacements. it's just such a pity that nobody seems to have noticed what he achieved.
what's wrong with systemd (Score:3)
First, I have to ask, what is wrong with systemd? It actually works quite well.
That said, even with systemd (and upstart), sysV scripts are supported for backwards compatibility because quite a few system services do not yet have a systemd startup script. I have not looked at the networkmanager or policykit packages, but I am almost certain the dependency is only because of the startup script. If you grab a sysV script, you won't need systemd to install them. This will likely require some voodoo with the package manager, though. My recommendations in order of ease,
1) use --force to ignore the dependency (this might great problems if you ever have to repair the dpkg database, though)
2) grab another package from some other distro and install (with alien if need be)
3) tweak the package yourself to remove the dependency (wouldn't be hard to maintain wrt updates, etc)
4) compile from source and install (create your own package for maintainability)
Re:what's wrong with systemd (Score:5, Insightful)
It's a massive, complicated, and very poorly behaved substitute for a simple, robust, and well behaved program. And it's not just a regular program, it is (if used as intended) a critical system component that will take your entire system down when it goes wrong.
If it were just a bad program, that's no big deal in and of itself, there are plenty, you just avoid them. But these people are not hackers, they have a marketing engine and are aggressively attempting to push themselves into a position where it WILL become impossible to avoid them and still use many new programs. That's beyond offensive. That's an attack on the Free Software ecosystem itself.
Re:what's wrong with systemd (Score:5, Informative)
What's wrong with it? Here's my starting list and I'm sure I'll think of more....
- Binary Logs: Sorry, but there is no advantage to not being able to easily look at a log file.
- Failure to Log to the Console: There is nothing more frustrating than watching 5 screens of "Failed, use journalctl to blah, blah, blah..." come by when you know that your root filesystem isn't mounted read/write. There went *ALL* your debug information.
- Failure to Drop to a Shell When It Breaks: If my boot is broken,I want a shell. Not a hang. There's a way to force it to go to a shell, but that's before it does *anything* so you don't get to debug the failure, you get to guess what the failure might be and see if you can debug *that*.
- No way to see WTF it's doing: There's supposedly a command to make it tell you what order (and presumably what'll happen in parallel) things are going to start in. However, if you use that command as root, it tells you not to run it as root. If you do it as a normal user, it doesn't have permission to read all the files to tell you what it's doing.
- Races: I no longer have any idea what order things are starting in. I've had a cluster where everything worked fine. Until the a week and a few reboots later and then it occasionally failed. Don't even start to tell me that "I must have my dependencies wrong". I *KNOW* they're wrong. But I have no tools to help me figure out what "right" is. Plus, have you looked at how many unit files systemd starts on a normal system? I can't hold that much of a graph in my head. With SysV init, unless I turned on some weird parallel mode, everything starts in the same order every time.
- Complexity: I'm not a professional sysadmin. I'm a developer who has to maintain development systems (as well as personal systems) part time. If I worked with systemd every day, I'd probably be able to figure out ways to make it work for me. But I don't. SysV is just shell scripts. I *DO* deal with *those* every day so it's pretty easy to debug.
- Complexity, Part 2: The previous version of init essentially had no bugs. Ok, I'm sure that's not really true but they sure didn't surface very often. Since the results of your Process #1 dumping core are catastrophic (ie, a kernel panic), ideally that process should do as little as possible. That is *CLEARLY* not the design philosophy of systemd. Further, it consumes a decent amount of RAM and the more RAM you consume, the more likely (statistically) you are of hitting a memory error.
- YACL (Yet Another Config Language): Ok, so this is really a minor complaint but I get to learn yet another way of writing config files.
- Filesystems: SysV init tended to mount local filesystems *very* early in boot (some of that broke when udev got involved, but you could usually hack around that) and network filesystems not long after. I'm not entirely sure where systemd mounts filesystems, but it breaks *HORRIBLY* if you move some of the files needed by a service onto a filesystem that's not a "normal" filesystem. I'm sure there's some way to set all the dependencies to make that work, too, but see above, I have no f'ing way of figuring out what should depend on what.
From all outward appearances, the developers have *no* interest in fixing much of any of those complaints. The whole "debug on the kernel command line" fiasco is a pretty clear indication that they "don't play well with others". In the end, I'll see what Slackware has or maybe move (back) to the BSDs.
Re: (Score:3)
Six of your criticisms amount to "I don't know how systemd works or how to configure it." While I understand the frustration, it is not a shortcoming of systemd. If you didn't know how to write a shell script, or how runlevels worked, or how to handle your distributions special way of dependency orchestration, you would be saying the same thing about sysV. Systemd is a new way of doing things. It requires you to learn new things, but it is not as hard as you think. Certainly it is a lot easier to adapt to t
Re: (Score:3)
Of course, if you have installed a bunch of crap designed with the same philosophy as we see in systemd and let it all run however it want, then yeah, you're misconfigured. Doh.
Quit blaming perfectly good tools for your own incompetence.
I really don't see what is the problem here (Score:4, Interesting)
I've pinned systemd in apt to -1 (so it won't ever install on my machines). So far i didn't have any problem. Debian will continue to support sysv for years and years, and in that timeframe this silly systemd fad will have passed away, and people eventually regain their minds and (hopefully) balls.
This "inevitability" horse shit is that: horse shit. Linux is equally useful without systemd, provided you have a mininum of experience.
rc.local (Score:3)
Disable all services possible so systemd doesn't try to do anything with them. In my case, that means basically everything, including the graphical desktop. In rc.local, add in your own service start calls in the approved order from an old Fedora or CentOS version. Generally, even if you use the service blah start command which does the same calls to systemd core functions that the whole systemd launch should be doing on its own, rather than coding the commands directly, I've found that systemd functions start much better from rc.local than whatever zombified magic it tries to do based on its own dependency tree.
Maybe it doesn't matter so much if you're able to use network manager, or are not starting any outside facing services. If you have a complicated network and are still using the network service because NM hasn't been completed yet, then it is really easy to get into loops as it tries to start things that depend on network when it isn't really there yet.
Yes, these are dependency bugs that should be fixed. If I had time, I'd file some bug reports. But most of my bug reports languish till the Fedora release expires and they can expunge them with won't fix, and pessimist that I am, I assume this will be particularly true with the mess that is systemd. Really, they should just be able to enable all available services on their own and see if the system boots. It shouldn't take any of our time writing bug reports at all. Sure they might have to repeat the tests with each different mail server, web server, and the like, but the fix should be about the same for each.
Just doing the ordering basically myself using old standard Linux order for the services that I need to run gets my boots to be reliable and drops the boot times down by minutes (as most things expire after 5 minutes if there is no network otherwise).
NetworkMangler "user friendly"? (Score:4, Informative)
Uh.
What?
I remember I used to have these horrible connectivity problems with it, which turned out to be a result of a "feature" wherein it couldn't be used with a wifi network with a non-broadcast SSID, because it would scan for broadcast SSIDs, not see the one it was trying to be connected to, and turn the connection off. I spent a month or so trying to get it to use a WPA2 VPN and eventually gave up and went to wicd.
I have never previously heard anyone describe NetworkMangler in any positive terms whatsoever, let alone suggest that it was in some way "friendly".
Easy workaround (Score:3)
Re:SysV is likely to always be supported (Score:5, Insightful)
I wish people who wanted windows would just stick to windows instead of infecting linux
Re:SysV is likely to always be supported (Score:5, Insightful)
And I wish people that want Linux to stay frozen would just stop upgrading or move to a system that sure to stay in 1970.
Re: (Score:3)
You mean like windows 2000 interface to metro? Gnome 2 to Gnome 3? It's change alright, but is it improvement? Change can make things worse too.
Re:SysV is likely to always be supported (Score:5, Insightful)
I like how people automatically assume change == good. Maybe I'm getting old, but it seems to be a young person thing (as is the rewrite everything from scratch mentality).
Change is change. It can be good, it can be bad. I'm not an expert on such things, but from everything I've read, the change to systemd is bad. And it seems to be a bad change in much the same ways the examples of change you gave (Metro, Unity, etc.) have turned out to be bad.
The Unix philosophy has always been to do big things by using little pieces. To violate this philosophy is not necessarily bad, but it would seem like trying to fit a round peg into a square hole. Sure, if you hammer it in hard enough, the thing will fit. But your square hole might have trouble fitting square pegs through afterwards, and your wooden board might crack after you fit more things through the hole irrespective of shape.
I'd have used a car analogy, but the best I could come up with is using the wrong kind of motor oil, which when put that way, doesn't seem quite as severe as the systemd problem.
Re:SysV is likely to always be supported (Score:5, Insightful)
Systemd COULD be a good thing if it would stick to starting up the system. It should START udevd, not BE udevd. It should START dbus, not BE dbus. It should be trivially easy to do any of:
Switch from systemd to SysV, switch from SysV to systemd, use systemd but honor the SysV init scripts. With a bit of work fron the systemd folks, it should even be fairly easy to use SysV and have it start systemd to monitor select daemons.
Do that and every single objection would go away immediately.
Re:How does it affect me? (Score:5, Insightful)
It isn't just the boot. Lennart now calls it "Core OS" and he means it. NetworkManager was crap, admit it. After years it still couldn't do everything the software it replaced did but it no longer matters. Latest systemd now even nukes it and replaces it with a all new Core OS replacement that won't work. Which is part of the pattern of destruction that defines Pottering's way of working. PulseAudio is still mostly broken and that was his first project that got any widespread attention. Guy is leaving a trail of destruction wherever he goes and for some strage reason he being allowed to go everywhere.
Re: How does it affect me? (Score:4, Informative)
PA actually seems to work great lately. At this point Windows has bad support for Bluetooth headphones, while in Linux it works great.
Re: (Score:3)
Wrong.
The Linux Bluetooth stack lives outside the kernel. Bluetooth audio devices are not accessible as OSS or ALSA hardware devices.
There is an alsalib plugin that lets alsa applications talk to Bluetooth audio, but it's got a number of limitations.
PulseAudio provides transparent, robust, behavior for both OSS/ALSA hardware devices and Bluetooth devices (as long as network).
Re: (Score:3)
lsb-init gained dependency support like five years ago.
Re:OpenBSD (Score:4, Insightful)
How right you are: https://www.google-melange.com... [google-melange.com]
I would trust OpenBSD systemd replacement over the original any day.
Re: (Score:3)
It's not that clear cut: while Patrick Volkerding and the rest of the crew are clearly against systemd, they may be forced to adopt it in the future.
Re: (Score:3)
It is not a static situation. There is an overt attempt to force the community to use something that violates a lot of long standing design principles (KISS, readability etc).. Just because they're old doesn't mean they're not still relevant. I happen to think they're the reason unix is a lot more robust than other operating systems.
Re:launchd (Score:4, Informative)
systemd is just an inferior version of launchd [apple.com].
Yes, that's almost a factor of 10.
Re: (Score:3)
I suspect that the people responsible for systemd never even thought to look at already-existing alternatives
Poettering was most definitely aware of launchd. [0pointer.de]