Ask Slashdot: Practical Alternatives To Systemd?

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?"

Comments

Accept, don't fight, systemd

[Bryan Ischo]

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:Accept, don't fight, systemd

[Anonymous Coward]

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

[Unknown Lamer]

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

[armanox]

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

[hydrofix]

For that observation to have much any statistical value, you'd had to know over 300 people who used systemd.

Re:Accept, don't fight, systemd

[hydrofix]

I meant, 300 who had an opinion of systemd. So it would mean 3 people actually used it and found bugs (?)

Re:Accept, don't fight, systemd

[Anonymous Coward]

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? They won't listen anyway?

If systemd is so onerous to you that you can't use Linux anymore, then I guess BSD is a possible solution for you.

Too onerous to use, the new standard.

But who knows, maybe BSD will eventually adopt systemd as well?

Then *BSD will cease to be a Unix.

Re:Accept, don't fight, systemd

[Anonymous Coward]

You, sir, can go fuck yourself.

I'll continue to stick with it pinned to oblivion until things break too badly, and then I'll find something which doesn't resemble a giant piece of monolithic horse-shit. OpenBSD is looking awfully attractive these days.

Re:Accept, don't fight, systemd

[Anonymous Coward]

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

[manichawk]

I get the distinct feeling that Oracle and especially the BSD guys don't want anything to do with systemD.

Sun/Oracle effectively replaced init with SMF back in Solaris 10, so while it isn't systemD, it doesn't mean that all UNIX will be keeping SystemV init alive...

Re:Accept, don't fight, systemd

[HiThere]

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

[Rutulian]

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

[Anonymous Coward]

To the point where they aggressively refuse to support anything but glibc - too bad if you want to use uClibc.

Re:Accept, don't fight, systemd

[epyT-R]

"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: Accept, don't fight, systemd

[Rutulian]

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

[Ereth]

SMF didn't replace init. Init is still there. It will still run legacy rc.d scripts, just like always.

SMF incorporated the existing common rc.d scripts and gave them dependencies, so that, say, Apache doesn't start if networking is down. It also gives you the ability to bring up the entire stack by simply starting something at the top, and it's aware of what beneath it needs to be enabled to work. It also gives you a log of everything starting up, so you can track down the problem (though, granted, often the log is not particularly useful - "restarting too often" doesn't tell you as much as I'd like).

I don't know what problems you are having debugging networking problems in Solaris, but I do it all the time, from the command line. I don't know any serious Solaris admins who use that god-awful SMC gui tool. We all use the command line. And Solaris maintains backwards compatibility, so we still have ifconfig, and snoop and all the same tools you've had since Solaris 2.5 available to you.

SMF is all XML, if you want to read the configuration or make your own, you can.

Re:Accept, don't fight, systemd

[Bryan Ischo]

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

[allo]

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...

Re: Accept, don't fight, systemd

[amorsen]

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

[Bryan Ischo]

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 and go play in your own ever shrinking room, or you can try to improve the bed that you are inevitably going to have to sleep in.

My advice was to wake up, wise up, and try to positively affect the ecosystem that you live in, instead of crying and living some kind of pipe dream that you'll be able to use Linux and not have to use systemd.

Also, all you anonymous cowards can kiss my ass.

Re:Accept, don't fight, systemd

[Darinbob]

Maybe the question is why these other packages feel the need to mandate the use of systemd. I haven't done system administration on linux for some time so I don't know, but has it gotten so complex now that it's impossible for packages to remain independent of the system init, or to have an portable interface to the system init?

And is systemd "standard"? There's a lot of linux systems that don't use it, and many non-Linux systems that don't. Forcing one solution is not the Linux way of doing things, and it certainly is not the Unix way of doing things.

Why not change your words slightly so that they say "By hook and by crook, Windows has become the standard way of doing many things in a typical PC system and it's time for all of us to just accept that and make forward progress"?

Re:Accept, don't fight, systemd

[MurukeshM]

Finding "systemctl -xb" you just realise that there actually is something neat about the system being able to understand it's own logs. Finding out that your system is failing to boot because of one directory permission (/var to the wrong user) and that it doesn't start a shell at all or anything you can debug with is just disappointing.

I guess you mean "journalctl -xb". Even so, I had an issue with a mount failing (not a critical one), and systemd dropped me into a what it called a root shell. (See #733232 for a similar situation). Of course, then the system was practically fully up, so the shell was fully functional. However, I refuse to believe that systemd can't start a shell to debug. It might not do so by default, but it can. See http://freedesktop.org/wiki/Software/systemd/Debugging/ (and https://fedoraproject.org/wiki/Systemd_early_debug_shell for what I presume is an older guide).

Re:Accept, don't fight, systemd

[Bryan Ischo]

How long until all of the software packages that BSD wants to use require so much work to retrofit to use a different init mechanism that they just throw in the towl and accept defeat?

Re:Accept, don't fight, systemd

[bsdasym]

A few years ago I would've called this ludicrous. I've been using FreeBSD for almost 20 years now and the idea of something like systemd (and the horrorshow it's become) making it's way into the base system was laughable. These days, I'm not so sure. Every release seems to take the system one step closer to exactly what you describe, with occasional steps the other direction (such as llvm/clang replacing gcc). I doubt FreeBSD will use systemd any time *soon* but one day, it might. By then bsdinstall will probably have been replaced with something even worse as well, and I will have moved on to some other flavor.

Re:Accept, don't fight, systemd

[Wheely]

One thing that made me thump my head against a wall with SMF was when a system booted but I couldnt ssh into it. sshd was not started because utmp was not "enabled" because mounting the filesystems failed because a single file system didnt mount. Ok, its fixable but sshd ran perfectly if started manually and it delayed getting production systems up by a few minutes. We get journalists knocking at the door if our systems are down.

I hate this stuff, none of my admins remember where the damn log files are because they play with it so rarely. A load of scripts run in sequence can easily be followed, however rusty you are.

Re:Accept, don't fight, systemd

[Anne Thwacks]

If they don't provide the functionality that is provided by systemd, then they will become even more irrelevant than they are now.

I don't know what systemd is or does, but init has worked perfectly well for me since 1981,

As for "packages will need systemd!" what for? Surely this is what the install script will fix for <your favorite Un*x system>

Get off my lawn.

Re:Accept, don't fight, systemd

[mmell]

Wasn't there an init method prior to SystemV?

Why assume that SystemV init is the once-and-forever solution to UNIX startup? If systemd represents a superior design it will almost certainly supplant SystemV. If not, there will be some painful moments fixing the damage - but I'd rather adapt and grow with risks than stagnate and age in perfect safety. NOTE: most businesses will disagree vehemently with that assessment, and for good reason. Time for we technical types to either ensure that systemd is up to the task, or to reveal its shortcomings quickly to minimize the pain.

Re:Accept, don't fight, systemd

[Arker]

"Whether you love, hate, or are ambivalent about systemd, I think you have to accept it at this point."

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.

Re:Accept, don't fight, systemd

[Bacon Bits]

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.

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:Accept, don't fight, systemd

[idontgno]

Good Lord. You make it sound like the story icon for Linux here should be Borg Bill Gates. Or maybe Borg Leonnart Poettering.

"Resistance is futile."

Re: Accept, don't fight, systemd

[Rutulian]

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

[Darinbob]

The basic legacy init has been around for decades because it works. It's small, it's simple, and it fits the design concepts of the early Unix systems. If you didn't like the init system then you changed the initial rc script. The various replacements for it over the years have seemed to be just minor tweaks (the directory structure of rc files) or else more major rewrites that never really catch on.

Systemd criticisms seems to be mostly about two things: re-using pid 1 to do more than it was initially intended to do, and too much functionality is included in one daemon (ie it has "mission creep"). The fact that unrelated apps are requiring systemd should be blamed on the apps I think, I don't follow this enough to know if there's any sort of collusion.

And "Oracle" in this context is really a lot of Sun engineers that were inherited by Oracle, so I would give them a lot more credence than I would to legacy Oracle people.

Re: Accept, don't fight, systemd

[Darinbob]

Back when I used Linux a lot you were provided a variety of choices, very little was shoved down your throat.

Re:Accept, don't fight, systemd

[Anonymous Coward]

Wow, you really didn't got, did you?

> If there are things you don't like about systemd, you should write up coherent bug reports or feature requests,

The problem with systemd is that it does waaaaaay too many things, by design. What people want is less features in systemd, not more.

Systemd is a very stupid short-sighted solution to a problem people didn't have, and if not reversed, will be in a few years a huge pain to linux, due to its scope creep and everything-including-thr-kitchen-sink approach to daemons & hardware management...

Re:Accept, don't fight, systemd

[sjames]

So what happened to user choice? I guess you're for it as long as they choose whatever you choose?

There are plenty of people who would rather have nothing to do with systemd. The correct response is "to each his own", not "Deploty the dependency hell!".

If I wanted Windows, I'd use Windows.

If people want systemd, good for them, they can have it. But this extension of entirely unnecessary dependency hell (DLL hell anyone) has got to go.

Re:Accept, don't fight, systemd

[ultranova]

Why hello Mr. Chamberlain, I wondered when you'd show up.

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: Accept, don't fight, systemd

[Anonymous Coward]

Have you ever looked at a systemd unit?

They are basically "key = value", one per line. Why would you want to use something more complex than ini-files for that?

Re: Accept, don't fight, systemd

[sjames]

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:Accept, don't fight, systemd

[sjames]

And look where Solaris is today, a hollow shell of it's former self. Abandoned for Linux.

Re:Accept, don't fight, systemd

[sjames]

You promised personal grief to anyone who doesn't accept systemd:

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.

That's the problem. If systemd would keep it's tentacles to itself and just be an init replacement, nobody would complain.

Re:Accept, don't fight, systemd

[sjames]

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.

Re: Accept, don't fight, systemd

[Rutulian]

I'm not sure if you are arguing it is better for the computer or better for the human reading it. I dunno, I prefer human-readable plain text files over an easily parsable "complex syntax", especially for something as basic as the init system. That's why I (mostly) hate xml as a configuration file format (*cough* launchd *cough cough*). It is good for making guis, but terrible if you ever need to edit the file by hand at a terminal.

Re: Accept, don't fight, systemd

[Rutulian]

Maybe, but I don't know when "back when" was. A distribution has to make some choices about how to package things and that necessarily removes choice from the end user. Most basic example of this, the package manager. You can't really choose which one you want and which format. The distribution chooses the package manager, you choose the distribution. Or better yet, initmodutils, replacing insmod with modprobe. It's funny how users seem to fine with that, but when the distribution makes a decision they don't like, then it is being "shoved down your throat."

Re:Accept, don't fight, systemd

[segedunum]

Linux and open source software in general has always been about survival of the fittest software, not by software being enforced by a company and by a bunch of people who haven't the faintest idea what they are doing. systemd is the total antithesis of the Unix philosophy - do one thing, do it well and have a bunch of focused interconnected system.

The people behind systemd are the same people who Linus Torvalds exposed as morons who kept breaking udev:

http://article.gmane.org/gmane...

Telling everyone to 'just get used to it' is not the way things are done.

Re:Accept, don't fight, systemd

[Bryan Ischo]

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:Accept, don't fight, systemd

[Bryan Ischo]

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

[xiando]

> Whether you love, hate, or are ambivalent about systemd, I think you have to accept it at this point.

No, we do not. The systemd bloatware has infected a huge number of GNU/Linux distributions at this point and it has become integrated with all sorts of things on those distributions. It has become as good as impossible to avoid on the distributions that has adopted it. Luckily you are WRONG, you see resistance is NOT futile. The obvious solution is to NOT use the distributions that have submitted to the systemd world order. Gentoo and Slackware are good alternatives to Fedora, Arch and now sadly even Debian. US Department of Defence subsidiary RedHat can force their NSA-backdoored systemd on some but they can't and won't fool us all.

Re: Accept, don't fight, systemd

[amorsen]

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 format, so if this document and the code disagree, the code is right."

Re:Accept, don't fight, systemd

[t_hunger]

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: Accept, don't fight, systemd

[Rutulian]

Or it could just honor fstab since that has always been the correct way to specify mounting a filesystem.

Not really. If systemd is monitoring the mounts, which it does because executing mount -a at some arbitrary point during the boot process is not the best way to mount the required filesystems during boot, it makes sense for it to give priority to it's own config files. Anyway, I don't know the exact nature of the problem, but I suspect it is because systemd mounts filesystems before /etc/fstab is parsed. If you try to mount an already mounted filesystem, it will just get ignored. This is the default behavior of the mount command and has nothing to do with systemd.

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.

Agreed. It doesn't need to, but the two activities are logically connected. Technically, journald is a separate service from systemd that is designed to work well with systemd, and it collects a lot more information than your basic syslogger. It is not required, though, and you can continue to use syslog if prefer it.

Re: Accept, don't fight, systemd

[segedunum]

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.

You're missing the point here. I'm not troubleshooting that needless complexity on a remote server, and the problem here is needless complexity.

but I can also see how journald is critical for certain enterprise infrastructure.

That is a meaningless statement.

If you don't like journald, you can install syslog-ng. You just have to make sure it doesn't trample on journald...

Great.

Re:Accept, don't fight, systemd

[colinrichardday]

Apache doesn't start if networking is down.

What if just want to run Apache locally (to test web apps)?

Re:Accept, don't fight, systemd

[s.petry]

Like systemd, SMF can do things similar to INIT, still reads INIT directories, and has a set purpose. One of the reasons I didn't mind SMF was that it's hackable. You have to know where to hack things, but outside of locations for scripts it's not that different.

Remember why Sun implemented SMF? The primary driver was that init runs once, and something was needed to actually manage and monitor daemons. I have used various monitoring tools and cron hacks to do similar things over the years, but SMF made this much easier to manage. SMF took away the need for external monitoring and maintenance tasks. (Obviously not completely because things still break, but normal errors or hang ups were easy to resolve.)

Since SMF could still run legacy scripts just like the old init including reading and processing inittab, I honestly fail to see how anyone can claim it's an abomination from a position of knowledge. I have seen plenty of ignorant people make such a claim, nothing new there.

Since systemd is still supporting init scripts and methods I'm not sure why this has become such big deal either. Now if there is no legacy mode, there is a different issue. If you don't want systemd to start your apache, write an init that does and disable the systemd start for the OS released boot script.

Personally, I'm of the opinion that old init is just fine. I worked fine with init for decades, and don't necessarily need a change to be happy. At the same time, I am aware of "why" people want better features than init provided. As long as legacy is supported why would I complain? I can still run boot scripts I wrote in the 80s without any modifications.

Re:Accept, don't fight, systemd

[MikeBabcock]

I've never understood people with this mentality. Why do you believe something inevitable just because it is ubiquitous?

The OSS sound system disappeared in favour of ALSA, XFree86 vs Xorg, the LVM changes come to mind, etc.

Many many things in open source are up for simply flipping because there's a better option. As soon as a better option to systemd is available, I sure hope it gets jumped on because I'm quite sick of systemd already myself.

Re:Accept, don't fight, systemd

[armanox]

Aside from some GNU software (GNOME in particular), what do you think is going to change that much? And BSD doesn't use most of the GNU software anyway.

Re: Accept, don't fight, systemd

[sjames]

If and when failures of mounted filesystems is handled gracefully, monitoring might matter. If this was just a matter of something in fstab already mounted, it wouldn't cause a problem. It shouldn't even be a problem if it's already mounted elsewhere (these days, you can mount a single filesystem more than one place in the tree).

If it's breaking, it's because systemd is going out of it's way to break something. That is not the sort of behavior I want to see in my init system. One of the virtues of Linux is that if you are root, it will do what you say if it is at all possible. It will try even if it isn't possible.

Re: Accept, don't fight, systemd

[sjames]

As for the restarting thing, OI had that working cross platform back in the '90s. Restarter was a simple daemon that would run another process and watch it. If the process failed, it would re-run it and log the event. It integrated cleanly with Solaris, Linux, Irix, *NSD, and even Unicos. No need to trash the whole OS just for that capability.

It could easily be integrated with dbus and listen for events if that was actually desirable. No dependency hell, no turmoil, no "my way or the highway" mentality. Use it or don't.

Re:Accept, don't fight, systemd

[shutdown -p now]

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

[Wdomburg]

It's the init system. It *is* the parent that launches the processes.

Re:Accept, don't fight, systemd

[davecb]

Actually it doesn't scale: if you have strong enough dependencies, A: B, eventually you'll start getting B: A. If either has a bug, they all have a bug. This is one of the things that MVS programs suffered from, as people kept putting stuff into them, typically until they could send mail (;-))

Some chaps at Bell Labs saw the problem and invented pipes, tools and loose coupling.

Re:Accept, don't fight, systemd

[Marsell]

I hate this stuff, none of my admins remember where the damn log files are because they play with it so rarely.

If you use illumos or Solaris 11.2, svcs -L gives you the path to the service log. I use "grep foo `svcs -L bar`" all the time.

I use SMF a lot, and I've rarely had trouble with it. svcs -vx shows you which services are down (as well as the log path, hello), and you take a look at the log to see what your application is complaining about. I have consistently found it easier to use than init scripts, despite me usually having a very conservative OS bent.

The only thing I don't like about SMF is the XML.

Re:Accept, don't fight, systemd

[Marsell]

Solaris was abandoned for reasons completely unrelated to SMF and its various technologies. If anything, Solaris 10 was a decade ahead of its time (DTrace, ZFS, zones, crossbow).

It's just that by the time Solaris was opened, the mindshare and momentum was vastly with Linux. It never stood a chance, completely unrelated to its technical merits, and Oracle closing it again just sealed the deal.

Having said that, illumos (an OSS version of Solaris that forked a few years back) is awesome and actively developed by several companies making money with its technologies.

Re:Accept, don't fight, systemd

[AJWM]

If there are things you don't like about systemd, you should write up coherent bug reports or feature requests,

That doesn't work if it's the whole design philosophy you don't like. Whatever happened to the Unix philosophy that tools should do one thing, and do it well, and be easy to integrate with (not assimilate, borg-like) other components?

Me, I'll keep SysV init. How often do you need to reboot a unix or linux box anyway?

Re: Accept, don't fight, systemd

[Rutulian]

I'm not troubleshooting that needless complexity on a remote server

Actually, you are arbitrarily declaring it "needless complexity," when what you mean is "this is new and I don't understand it, so I hate it." The reality is it is quite a bit simpler in a number of ways. Whether or not it is on a remote server is irrelevant.

but I can also see how journald is critical for certain enterprise infrastructure.

That is a meaningless statement.

Why? That is a meaningless rebuttal.

Re: Accept, don't fight, systemd

[Rutulian]

Like I say, I don't know the details of the original poster's situation. All he said is "breaking silently if there are perfectly valid mounts in there which it happens not to like." What does that mean? My best guess is systemd is mounting something initially first, and then the subsequent mount -a that reads /etc/fstab doesn't do what you expect because mount will not change mount options without special instructions. It is not breaking anything. It is the normal expected behavior of the mount command that has nothing to do with systemd. If you want to override something that systemd is doing, you will naturally have to do it the systemd way. I don't see why that should be surprising or unusual to anybody.

Re: Accept, don't fight, systemd

[Rutulian]

What would have been lost by adding them to /etc/fstab?

Well, then it wouldn't be managing the mounts. It would be just executing mount -a, just like a sysV script. This works fine in some ways, but breaks in other ways. For example, a container that uses an iscsi target as its backing store. There is a complex set of dependencies that involves mounting local filesystems, starting network services, connecting iscsi devices, mounting network filesystems, starting the container. Another example is the udev system, which certain services interact with in different ways. There are a bazillion hacks to deal with these issues with sysV that aren't pretty. Systemd solves all of them.

That way you would be able to tell systemd not to mount them, if need be, or to mount them elsewhere.

You can still do that, you just have to do it the systemd way. I know its frustrating to have to learn a new way, but it is not as bad as you think.
http://www.freedesktop.org/sof...

Said standard being the systemd source code of the day. No external tools can handle the format.

Agreed. A major shortcoming. Hopefully a formal spec will be forthcoming. This will make it easier for external tools to parse the logs.

Re: Accept, don't fight, systemd

[sjames]

Sounds like systemd needs to handle mounting the Unix way.

Re:Accept, don't fight, systemd

[sjames]

Personally, I abandoned Solaris because of it's nasty habit of making simple things complicated and non-standard for little gain.

The over-complexity pervaded it. That's part of why it was being called Slowlaris.

Re: Accept, don't fight, systemd

[Rutulian]

I don't know what you mean by "the unix way" and why you think that would be fundamentally different from what systemd is doing. Do you really believe mount -a is the perfect way to handle every situation where you need to do filesystem mounts?

Re:Accept, don't fight, systemd

[Marsell]

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 Solaris, but we obviously have differing opinions on this.

Re: Accept, don't fight, systemd

[sjames]

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:Accept, don't fight, systemd

[Marsell]

Use apachectl.

Re: Accept, don't fight, systemd

[sjames]

Right, so why is it screwing with the logs to decide if the child went away or not?

Re:Accept, don't fight, systemd

[BiOFH]

Read your post and this really encapsulated it all:
"THIS IS NOT HOW YOU UNIX"
Well said.

Re:Accept, don't fight, systemd

[Anonymous Coward]

if your PID 1 crashes, your kernel panics, which is *much* more likely to happen with a big complex init.

if your init is just a small boot process that starts the process with actual functionality (or a fallback shell if that one doesn't start), there is no fucking need for it to listen or speak any protocol or be remote-controlled. It can stay tiny alright. All that communication can take place between the sub-process(es) you spawned exactly for that.

That said, the actual problem most people seem to have with systemd, and I'm one of them, is not the PID 1 thing. It's the "make everything and more depend on it" approach. If the previous inits had been developped that way, there is no way we could replace them today with systemd. In a few years from now, we will have a big heartbleed-like mess with systemd and there will be no fucking way to get rid of it unless going back to what will then be an old linux distribution from 2014 (or even earlier, depending on your pick).

Not to talk about the "forced down our throat" thing and the way developpers interact with users. The exact same way GNOME 3 developpers have been: poorly and obnoxiously.

Re:Accept, don't fight, systemd

[linuxrocks123]

I don't think you're right about this. One of the nice things about OSS is that you don't have to go with the majority; even a small minority can maintain a usable fork. Slackware has used an unpopular init system for years: it uses BSD init instead of SYSVINIT. I see no reason it shouldn't be able to keep doing that if it wants to, and I don't think Volkerding is enthusiastic about systemd, to say the least. udev doesn't currently depend on systemd, and anyway someone else in this thread said Gentoo already forked it.

By the way, did you know you can run a Linux system, today, without udev? You just create the device files in /dev like you did back in the 90s, and it'll work. That's not to say this is a good idea. But it will work.

Re:Accept, don't fight, systemd

[t_hunger]

So you want to have a tiny init process that spawns a bigger init process that does all the actual work? If the "big init" fails, then your system is hosed. If your "small init" fails, then the system is also hosed. Your proposal gets more code into the critical path, not less.

But then your problem is that other projects start to depend on systemd. What exactly are you objecting to here? That Systemd finally solves real world problems that developers face when implementing their software? Or that developers go ahead and fix the issues that they were unable to fix before? In the end you claim we should keep bugs open because some people on the internet are feeling uneasy.

Yes, there are bugs in systemd, just like there are bugs in sysv init -- even after decades of use. Yes, there will be some exploit sooner or later targetting systemd, just like there will be some for every other piece of software. But that should not stop people from improving the status quo.

Lennert and some other guys wrote a bit of code and went out to talk about it. They got feedback, and improved their code based on that feedback. At some point more people started to care about the code and so they contribute. Much later some other people sit down together and agree that this piece of software addresses problems they have, so they depend on that software -- either as something providing a service to their own software or as a basis for their distribution. At which point in the story does somebody grab you and forces a USB stick down your throat?

Re:Accept, don't fight, systemd

[Ash Vince]

Init works great. It's not broken, dont fix it.

I thought it didn't support loading things concurrently and instead forced this slow, one after the other approach that meant Linux generally took about 10 seconds longer to boot than any other modern OS?

You might not consider a slow boot time broken, but some people do.

Re:Accept, don't fight, systemd

[t_hunger]

Most packages do not depend on systemd being PID1, they depend on other things that found a home in the systemd repository. One big thing is of course udev for things that are close to the hardware. The other big thing is user session management. Basically systemd can replace all the custom start-up-the-desktop-environment code that all the desktops implement to make sure all their services get started and keep running. Then there is logind which manages who is logged in where and who has access to which keyboard/graphics card/mouse/etc. That is pretty essential for any modern desktop environment, too.

Note that all these interesting things are interfaces that can be implemented for other init systems as well. Unfortunately nobody stepped forward to do so yet. The implementations found in systemd are tied to systemd being PID1 (more or less badly), since they e.g. use the systemd interfaces to manipulate cgroups.

Re:Accept, don't fight, systemd

[Bob Uhl]

SMF is all XML, if you want to read the configuration or make your own, you can.

That's a huge problem, though: XML is a markup language, not a configuration language. Although it can be used to represent any data, it is not ideal for representing many kinds of data (in much the same sense that being Turing-complete is hardly sufficient to be a decent programming language).

YAML, s-expressions, traditional Unix line-oriented config filesâ"heck, even Windows-style .ini files are more useful than XML in the common case.

Some people, when they have a data representation problem, think, 'I know, I'll use XML'; now they have two problems.

Re:Accept, don't fight, systemd

[IllusionalForce]

While I do agree that the post was essentially decently-disguised flamebait, there's one point he really does make: "Whether you love, hate, or are ambivalent about systemd, I think you have to accept it at this point."

I see nobody working on an alternative init system. openlaunchd is both dead and limited to FreeBSD, upstart is likely to die with the march of systemd (Which, as you'll need to understand, is not an init system anymore, but literally a system daemon. It owns, controls and plays with your machine at its own volition and there's nothing you can do to stop it.), OpenRC isn't taken seriously because the gentoo folks propose it and now that both Debian and Red Hat, the two major players on the market, have both decided to play along with the systemd game (one of them was more or less forced into it, but no matter), systemd is omnipresent and impossible to stop.

We would've needed to have a concrete, working answer that made systemd pale in performance, code quality AND documentation back in 2012. If Apple had released launchd as open source back when Ubuntu started writing upstart, things might have ended differently. If upstart wasn't pushed too early, things might have ended differently. However, at this point of time, the UNIX way on Linux is dead. Irrecoverably. I wish I didn't have to paint such a black picture, but it's too tightly-coupled with the rest of the Linux ecosystem to ever remove it again.

Re:Accept, don't fight, systemd

[t_hunger]

I'll tell you when: when GNOME developpers took the path of making it all but impossible to have GNOME properly working with other init systems. And that's just the "I've had enough" point in time, not the one and only example.

So the GNOME project making a technical decision that makes their live easier is forcing something down your throat. You are being a bit egocentric, aren't you?

Some decision taken over the past years in various linux distributions have been taken not out of technical merit or discussion, but out of personal interests, or for political reasons. Sometimes it comes discreetly through some clever marketing that everyone swallows and when you notice it, it's already too late (systemd), sometimes through hostile takeovers (yes, Debian, I'm looking at you *cough* libav *cough*) where there is nothing you can do as a user because a few guys in power decide what is good for you.

Do you have prove for any of those claims? Where are the army of developers that do something about the decisions and flock to projects that are not falling for the propaganda? Or are you the only one that understands what is being played here?

Linux used to be about choice, but the list of these non-technically-based decisions that reduce our options is getting longer and longer recently.

This statement does not become true by repeating it.

FLOSS always had a strong "who does the work is right" approach. What the users say has always been secondary.

Whatever will happen, don't tell me that the many voices around objecting to systemd have been listened to or their objections to core-design problems addressed.

There are loud voices speaking out against systemd. Do not mistake that for many voices. In Debian the systemd oponents failed to find five people required to call for a vote to overturn the decision made by the technical committee! And that after all the fuss taht was raised during the discussion process.

systemd may very well be the best init software ever written, but then there is the manner. The way it's currently spreading its arms out of its role as an init system in a non UNIX way for political reasons, acting like a kernel above the kernel, is what most people are complaining about.

Why bother to write something that is as good as what was there before? Systemd tries to do more than init ever did, right. But much of that actually makes sense if you take the time to read up and think about it.

Just read this whole thread, yes there are trolls, but there are sensible people making reasonnable arguments. And what is the answer they're given: "you're holding it wrong".

I have seen very few reasonable argument levered against systemd in this thread. But then what can you expect from a thread that has an april fools joke listed as a fact?

I mostly see misinformed or uninformed posts. What can you tell people that form a strong opinion on something without bothering to learn about it first? "You're holding it wrong" is actually a rather polite way to put it IMHO:-)

Re:Accept, don't fight, systemd

[Fweeky]

Every release seems to take the system one step closer to exactly what you describe

Erm, like what?

Re:Accept, don't fight, systemd

[Bryan Ischo]

No, I don't see it. I was offering an opinion, and used no derogatory terms or insulting language. But then I don't get offended when others offer their opinions, especially when those opinions are explicitly requested.

Re:Accept, don't fight, systemd

[Bryan Ischo]

Wrong again, coward. "I think you have to" is a different way of saying "you should", in this case "you should" being shorthand for "I believe it would be better for you to do this and here are the reasons".

Re: Accept, don't fight, systemd

[Rutulian]

Great, so you have a distro that does what you want. What is the problem then exactly? Not every distro is going to be like Slackware, and it shouldn't have to be.

Re: Accept, don't fight, systemd

[Rutulian]

Does it? There's no reason for "its own" config files,

There is no reason for . Guess what, there is actually, and those reasons are documented on the systemd website.

Re:Accept, don't fight, systemd

[Arker]

"I see nobody working on an alternative init system. "

There are better init systems in use and supported. Slack init has been it's own thing for a very long time, a bit of a cross between BSD and SysV that follows the slackware philosophy. Simple, robust, and easy to work with.

Gentoo still uses their own fork of init with OpenRC. OpenRC, in a nutshell, provides the features of Systemd or Upstart without breaking compatibility.

Systemd (and upstart, since you mentioned it) is not something primarily created to solve a technical problem. They exist primarily for political reasons. They are Red Hat and Canonical's attempts to rip out the guts of *nix and replace it with vendor-specific infrastructure that they can control and direct.

OpenRC isn't taken seriously because the gentoo folks propose it and now that both Debian and Red Hat, the two major players on the market, have both decided to play along with the systemd game (one of them was more or less forced into it, but no matter), systemd is omnipresent and impossible to stop.

"Because gentoo" makes no sense. Regardless, 'omnipresent and impossible to stop' is bullshit. What is unfortunately true is that Red Hat, Ubuntu, and now Debian will be outside the pale of *nix systems. One large *nix* ecosystem has been effectively forked into three systems. Red hat will own one, Canonical will own one, and the remaining *nix systems, including Linux, Gentoo, and *BSD will remain our own ecosystem that no one can own. It's sad that Debian is officially going the other way but hey, best of luck to them in their new role as Red Hat sattellites.

Re: Accept, don't fight, systemd

[Kremmy]

Well, then it wouldn't be managing the mounts. It would be just executing mount -a, just like a sysV script.
Citation Needed. Systemd would in no way be beholden to utilizing 'mount -a' as the manner in which to parse and execute the fstab file.

Systemd solves all of them.
I fear that many of the issues solved by systemd have done so by ignoring standard practice for defining some very basic aspects of the UNIX-like systems. If systemd were being engineered in a manner appropriate for UNIX-like systems, it could very easily parse these files and act on the data within them in a more intelligent manner than the standard methods. It should be able to identify an iscsi mount in fstab and delay the mounting of it until it has properly bootstrapped the network services. The fact that it obfuscates these things is very much a design flaw.

Re: Accept, don't fight, systemd

[Rutulian]

It should be able to identify an iscsi mount in fstab

How would it do that? Have you ever used iscsi? How about multipathing? It is not as simple as you seem to think it is. Autofs is another hack to make mount + /etc/fstab do something that should be pretty simple, but never works properly. Systemd makes network automounting very clean and easy.

If systemd were being engineered in a manner appropriate for UNIX-like systems

The only thing about /etc/fstab that makes it "proper" is that it has always been there as a configuration file for the mount command! That is all. There is nothing more unix-y about it than having a different configuration file in a different place to do the same basic thing.

The fact that it obfuscates these things is very much a design flaw.

Systemd doesn't obfuscate anything. Everything is very clearly documented, logical, and modular.

Re: Accept, don't fight, systemd

[segedunum]

Actually, you are arbitrarily declaring it "needless complexity," when what you mean is "this is new and I don't understand it, so I hate it." The reality is it is quite a bit simpler in a number of ways. Whether or not it is on a remote server is irrelevant.

No, it is needless complexity and it is NOT simpler in a lot of ways - not by a long stretch. systemd incorporates a lot of functions that have long been separate and focused. Troubleshooting this monolithic system, and even reading its logs, is a quantum leap harder to do so do not presume to tell me what the 'reality' is in the manner that its maintainers tend to do. I administrate servers where I require a working init system, that's the reality.

Why? That is a meaningless rebuttal.

Because it's meaningless? You've put the word 'enterprise' in there and expect it to mean something. Sorry, but it doesn't. Logs that I can read at a low level are critical for an 'enterprise' infrastructure. I've been through that with Windows.

Re:Accept, don't fight, systemd

[marcello_dl]

I would object that people who admin linux systems would not readily introduce cruft that makes their system more difficult to maintain.

But we are dealing with rather big companies that make bucks with supporting linux. And GNU/Linux, unfortunately for them, was getting easier to admin. When you used to compile you have packages. Even compiling modules into the kernel is automatic with dkms now.

So the linux support companies find themselves with a problem they share with the hardware companies. GNU/Linux works too well.
One solution is to bring rockstar developers to design the parallel of the windows registry. I say rockstar in an ambivalent way. One with outstanding coding skills but with a reality distortion field so bad that when his debug flag creates problems to the kernel devs he says "fix the kernel not my problem".
WHAT?
RedHat should have told him "Now you take a CS 101 course and relearn about namespaces and about not interfering with other people already established conventions, especially if it's the fucking KERNEL, you NOOB" - of course this would be the official public watered-down response.

So, everybody is happy. Hardware companies, support companies, and the horde of developers that prefer to roll out their own stuff instead to contribute to existing projects so they get fame and maybe a few bucks.
Luckily for the user, if enough clear thinking old school hackers exist, they will modularize or come up with drop in replacement for the systemd monolith. Else, better start exploring a plan b with genode, bsd, slackware, because the windowsification of linux won't stop here.

Re:Accept, don't fight, systemd

[petrus4]

Whether you love, hate, or are ambivalent about >systemd, I think you have to accept it at this point.

There's something called individuality. Some of us have it. If you don't, then that's a shame; but that is not going to prevent us from retaining ours.

We are under no obligation to simply shut up and accept systemd whatsoever. We can go to FreeBSD. We can go to Minix. We have any number of possible alternatives.

Re:Accept, don't fight, systemd

[Rakarra]

I'm not sure if you're trolling, intentionally trying to prove his point, or simply a symptom of the problem.
Well done, regardless.

Re:Accept, don't fight, systemd

[Rakarra]

Bringing up Neville had no purpose other than greatly blow the discussion out of proportion.

Re: Accept, don't fight, systemd

[Wdomburg]

I completely misread your comment. Sorry about that.

Short answer is, it isn't. As parent, it gets the SIGCHLD and can take action based on configuration and exit status. There is also a simple watchdog facility that depends on the application sending a "ping" to systemd within a fixed interval.

The original reason for the journal was to allow recent log data to be easily presented (i.e. without the equivalent of grepping /var/log) when running "systemctrl status ".

Implementation aside, there is significant value to having structured logging. Running a grep is fine for smaller installations, but becomes prohibitive the larger your logs grow (especially when searching through months of logs). Likewise, simple pattern matching works well in the simple case, but can failure spectacularly on unexpected input (e.g. a missing field) or on multi-line log entries (e.g. a stacktrace).

Re: Accept, don't fight, systemd

[sjames]

I can sympathize with wanting to structure log data better, but that doesn't justify tying that into a new init. I have reservations due to accessibility as well. It is dead simple to grep text files, to split off older entries and compress them, etc. Unix has excellent tools for that. If all else fails, you can cat it to the serial port and do the analysis on a machine that isn't broken. There is no reason better structuring can't be applied to those so that they become even easier to manipulate.

One reason the early internet had so many different but compatible client and server implementations was that their protocol was human readable on the wire. You could just look at it and tell if it was correct. If something odd was happening, you could connect with telnet and step the server through the protocol manually to see what happened.

Re: Accept, don't fight, systemd

[BadDreamer]

The problem is that systemd should not do what it does to the startup process. It's taking over *everything*, and the stated reason by the lead developer is to force Linux to behave as he wants it to.

It should not mount. It should not log. It should not handle network connections. It should not automount. Those are not init tasks. Those are specialized tasks which should be performed by specialized tools.

Hmm

[Anrego]

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

[Tester]

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:Hmm

[Anonymous Coward]

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

[serviscope_minor]

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

[strikethree]

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:Hmm

[epyT-R]

just better eh? By what standard? This is the same mentality that's overdoing the plumbing in everything else these days. The results are buggier, slower, harder to use products (phones, cars, hell anything someone's managed to cram a computer into) that cost more than they should. There's something to be said for keep it simple stupid, especially when it comes to basic functionality like init. KISS keeps it easily understood, therefore easily validated for bugs or security, and it just works.

Even with gentoo, which I have been using for many years, the python dependency of portage is strangling the software. It's slow as hell, and if something hoses the system it's likely it won't run because python and its wrappers have many dependencies. A package manager should run as a static binary if at all possible.

Re:Hmm

[Anonymous Coward]

What is, in practice, actually better about it for dat-to day use and administration?

Well for one, if your system won't boot from disk anymore, you can no longer boot from alternate media and simply cat or tail the log files to see why.
The log files are binary now, so just like on Windows, your only option is to send the logs elsewhere to be read and interpreted. But there is no option for you to know what is going on anymore no matter if you would be capable of fixing it or not.

Another improvement is legacy services which will all be disabled in the near future, as Lennart stated he will be doing.
Hope all of your software is still being maintained and was compiled in the past couple months!

Personally if I wanted my system to fight me to keep it running, I would make all the servers Windows. I see no need to take Linux down the closed source "no one but The One maintainer can read your logs" path like the other commercial unixes

Re:Hmm

[Wheely]

I dont have three, I have four but Im very much with you on this.

Linux with systemd is finished for me at home and at work, well thats tough to change but I have started the debate.

Re:Hmm

[dentin]

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:Hmm

[lophophore]

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

[epyT-R]

Yeah I remember looking at that a few years ago when it was announced on the forums.. It was too much in an alpha state to be usable at the time. I'll have another look..

Re:Hmm

[KingKurly]

I have three digits (not that it matters) and I am strongly opposed to systemd as it exists today. With some actual engineering work, it could be good. But today, it is not.

Re:Hmm

[deek]

Well, I'm a few digits off 3, but I've been testing systemd on my laptop, and it seems decent enough. I turn it on, the laptop boots up, I can use it. It seems to have a few neat ideas that I can play around with.

My guess is that the early /. subscribers are old enough to remember when just about anything in Linux was new. Therefore they're not phased when something else changes the landscape. It's a different perspective on things.

Re:Hmm

[phantomfive]

They're coming out in favor (or opposed) because it's something they care about. This is a real story.

Remember when Slashdot wasn't about the latest Dice spam? When it was about Linux? That's where those short-id people come from.

Re:Hmm

[rastos1]

Is it the case that as long as you don't have to deal with it and it works, then it's ok? What happens if you want to modify the service dependencies? Write your own deamon? Add some debug output here and there? Customize startup of some service?

All that currently requires me only to understand the bash syntax. In fact it currently requires only some familiarity with shell variables, "if" and "echo" and works from HP-UX, to FreeBSD, Slackware or Gentoo.

Re:Hmm

[secretagentmoof]

Those low IDs are after post-"whoops, we deleted all the accounts, sorry!" in 1998 or thereabouts. Johnny-come-lately types, really.

Re:Hmm

[deek]

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.

Re:Hmm

[rastos1]

I did not say that the shell scripts are portable. I just said that I can read and easily modify them on any *UX platform.

You don't need to add debug output with systemd, because you don't need to write a script to start a daemon.

You never know what someone needs. If I decide to alter iptables firewall while some VPN daemon is running, or run ftpd only when samba runs, ... my reasons can be anything and obscure. And currently it is just a script away. I have some doubts whether it will be equally easy with systemd.

Re:Hmm

[Chang]

Yes, it's in RHEL7 release candidate (GA should ship next month)

Re:Hmm

[Tester]

systemd's big feature of the alternatives is that is also supervises running deamons after they've been started. OpenRC (and baselayout 1.x, it's predecessor), tried to do it, but in a half-hearted way that never really worked. That why we have the "zap" command to tell the init system "you think this daemon is running, but it's actually not". With systemd, this kind of thing can no happen because it actually uses modern kernel features to keep track.

Re:Hmm

[BadDreamer]

And this is what systemd should be doing. Not running udev on its own, and mounting file systems, and handling network connections, and $DEITY knows what else garbage it's stuffing in its bloated chunk of API rot.

If systemd did init, and did it well, and did nothing else, it would be embraced by pretty much everyone who was sane. What it does now makes me wonder the sanity of anyone who embraces it.

Re:Hmm

[Wolfrider]

--I'm with you 99%. I would personally rather use upstart over systemd(which needs to die.)

Slackware

[Anonymous Coward]

I reckon slackware is going to be the last man standing on this one.

Re:Slackware

[Anonymous Coward]

I'll second Slackware. I'm happy with the direction they've gone in, so I'll be sticking with them.

Re:Slackware

[Noryungi]

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:Slackware

[Noryungi]

Go Slack!

Re:Slackware

[ls671]

"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:Slackware

[ls671]

Damn,

I meant:
I use Slackware since 1995 and I have never viewed it as "alternative" before ;-)

Re:Slackware

[Richy_T]

To be frank, something better needed to come along. I'm not sure if systemd is it or whether it will become just another place to have to look when things go wrong. If a distribution is going to go one way, it should go that way all the way. Cron has become just as bed, I now have to look in three places anytime I want to track down a script if I don't already know where it is.

Re:Slackware

[Arker]

Seconded. Slackware is the best. It's actually a fork from BSD init with a little code added to accommodate stupid applications that expect SysV IIRC. But whatever it is, it works wonderfully, it's simple, robust, and easy to work with. I dont understood why anyone would deliberately use anything else.

Re:Slackware

[Richy_T]

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:Slackware

[Wheely]

Me too, but then I never left :)

Re:Slackware

[Arker]

Indeed, Slackware is the standard by which others are to be judged - and usually found wanting.

Re:Slackware

[epyT-R]

'hating change' is an ad hominem that distorts the issue. Change can bring good, but it can also bring bad. Change for changes sake usually results in the latter.

here are the big ones.
1. totally unnecessary complexity for startup, logs, and other things. This is really the big one. What's next? a registry to track settings?
2. KISS doesn't break and can be validated for security. systemd is like modern cars that dont come with spare tires and have the dealer locked computer between you and everything.. Even if you could replace that alternator yourself and get home, the dealer still needs to unlock it before the car will start again, resulting in a tow anyway. Why? $$$ and control freakery, which is really what this is about for redhat.

Re:Slackware

[Darinbob]

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:Slackware

[Darinbob]

The K.I.S.S. principle?

Re:Slackware

[ls671]

True enough, that's exactly what I realized the other day while searching for documentation and hitting an Ubuntu forum post dating back to 2006 or something...

Re:Slackware

[syzler]

I should have worded that a little better. I meant that Slackware is an alternative to Debian (since the submitter was asking for options other than Debian). I personally and professionally use Slackware with a little FreeBSD.

Re:Slackware

[phantomfive]

Yeah, Slackware, the distro that remembers what Unix is.

Re:Slackware

[rastos1]

If any other distro want's to switch to systemd I could not care less. But the danger is that the software that runs on top will become dependent on systemd. Things like KDE, bind, sshd, samba, pppd, ... And that makes me worried.

Happy Slackware user since ~1995

Re:Slackware

[ray-auch]

Damn,

I meant:
I use Slackware since 1995 and I have never viewed it as "alternative" before ;-)

So young grasshopper, what is SLS then? Slackware was the first alternative Linux distribution.

Torn between saying mod parent up, and pointing out that SLS was actually the alternative to MCC Interim, which itself was the wimpy cop-out alternative to H.J Lu's boot-root from back when men were real men and floppies were actually floppy...

How does it affect me?

[twistedcubic]

How does systems affect me during the minute it takes my computer to boot while I'm making coffee?

Re:How does it affect me?

[Anonymous Coward]

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?

[vadim_t]

PA actually seems to work great lately. At this point Windows has bad support for Bluetooth headphones, while in Linux it works great.

Re: How does it affect me?

[Anonymous Coward]

Off topic, but I'm surprised more people don't complain about this. Whatever they did to Windows sound, they borked it up beyond belief. Headphones accidentally unplugged while playing a game? Most likely, the game has to be restarted. Start up a game, only to find out your headphones weren't actually plugged in? Most likely, the game has to be restarted, if it doesn't crash outright.

Re: How does it affect me?

[Unknown Lamer]

lsb-init gained dependency support like five years ago.

Re: How does it affect me?

[VVelox]

PulseAudio has nothing to do with the Bluetooth audio support. It is just a sound server and relies on either ALSA or OSS to talk to the hardware.

Re: How does it affect me?

[serviscope_minor]

PulseAudio has nothing to do with the Bluetooth audio support. It is just a sound server and relies on either ALSA or OSS to talk to the hardware.

No, but if you hot plug things like headphones such as USB and Bluetooth, despite some of the shortcomings of Pulse, it's a massive faff to not use it. Basically I like it except on the machines where it seems to be buggered.

Re:How does it affect me?

[amorsen]

systemd does FAR more than just boot. If it went away after boot, few would complain, but it would lose most of its reason to exist.

Re: How does it affect me?

[Wheely]

At the same time, not critical devices can't block startup.

But all these systems do exactly that too and its harder to find out why when they do.

Re: How does it affect me?

[sjames]

I have to kill it off in order to get decent latency. I don't mind PA because there is no illness it causes that can't be fixed with kill -9.

Re: How does it affect me?

[brantondaveperson]

I care about getting sound AT ALL.....As for Windows, that stopped impacting my world almost two decades ago. Let. It. Burn.

Slight irony, since sound in Windows works fine... ;-)

Re: How does it affect me?

[raxx7]

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:How does it affect me?

[Ash Vince]

How does systems affect me during the minute it takes my computer to boot while I'm making coffee?

Some people choose to use that minute more constructively while their minions make them coffee :)

OpenBSD

[Anonymous Coward]

I was always an OpenBSD fan from the olden days but used Debian a lot due to it's easy of package install / dependency resolution. But now after the work they've been doing on LibreSSL is really making me want to switch back to OpenBSD and give it another try. If you want a minimalist's attitude, then choose OpenBSD, like me! (Just need pkg mgmt tools for it somehow...)

Re:OpenBSD

[Noryungi]

How right you are: https://www.google-melange.com...

I would trust OpenBSD systemd replacement over the original any day.

SysV is likely to always be supported

[rahvin112]

SysV is likely to always be supported regardless of what you think of improved init systems. Personally I think systemD is a good thing and combined with wayland is going to close some serious gaps Linux has had for ages.

Honestly if sticking with SysV is so important you can either stop upgrading or you can move to a niche Linux distribution or even move to one of the BSD's.

Re:SysV is likely to always be supported

[Anonymous Coward]

I wish people who wanted windows would just stick to windows instead of infecting linux

Re:SysV is likely to always be supported

[Colonel Fahlt]

Actually, most of the major BSDs use the newer rc.d system. FreeBSD, NetBSD, and DragonFly BSD all use rc.d. OpenBSD is the hold-out.

Re:SysV is likely to always be supported

[ThisIsSaei2561]

He said upgrading and not updating, to be pedantic about it.

Re:SysV is likely to always be supported

[rahvin112]

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:SysV is likely to always be supported

[epyT-R]

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

[steelfood]

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

[sjames]

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:SysV is likely to always be supported

[Darinbob]

It's not really recreating Windows. However it is recreating the bloat and interdepency of everything that Windows has. Can you really call modern Linux systems lean and mean anymore?

Re:SysV is likely to always be supported

[thegarbz]

A lot of the people who complain specific changes are bad often do so because they are blinded to the cases where the original system is actually broken and a rewrite from scratch is the best option.

I'm not saying here that systemd is good, I'm saying that the init system is damn broken when it comes to modern use case. It started being broken in the era of hotplugging and when Linux started migrating from the serverroom to the desktop. I'm also reminded of who people complain about PulseAudio and Wayland. Yes they aren't perfect but good luck getting a bluetooth headset to *just work* without PulseAudio, and likewise good luck simply running up to any old projector with your laptop on X11 and expecting it to work magically.

Tools have their place. The classical init system is still a great tool for a server machine and it makes little sense to move from it, likewise so is X11. However as times change and we find derivatives of Linux in small portable devices that need to sleep most of their life and yet be up and interacting at the push of a button, and as such the programming priorities to support those devices change too, i.e. parallel startup of system services in systemd which as far as I can tell the classic init system isn't capable of.

Change can be both good and bad at the same time. I look forward to the classic init system going the way of the dodo, but I'm also thankful it exists the way it does on my server.

Re:SysV is likely to always be supported

[BadDreamer]

And I wish people who think that change is good just because it's change would have to deal with the real world consequences of such a foolish attitude.

I wrote OpenRC

[UberLord]

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

[SocialEngineer]

Glad to see dhcpcd is still being maintained. I rarely use *nix anymore (I do design and audio recording using software that doesn't always play well in Wine; it's easier to just make use of Windows for now, although I may be putting a Linux/BSD distro back on my laptop), but if it weren't for the clean and simple functionality of dhcpcd, I would've had fits doing networking way back when.

Re:I wrote OpenRC

[crow]

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.

Re:I wrote OpenRC

[allo]

oh, conf.d is a openrc thing? I always loved that part about gentoo.

Re:I wrote OpenRC

[Anonymous Coward]

Seconded. I have always found OpenRC to be very elegant and simple, both to use and to write init-scripts for. With parallel dependency loading, my laptop boots in approximately 5 seconds, too.

Re:I wrote OpenRC

[xiando]

Thank you for dhcpcd. I don't really notice that I use it but I'm glad it's there every single time I boot.

Re:I wrote OpenRC

[shutdown -p now]

Can you clarify? Does this mean that you consider NetBSD rc.d superior to OpenRC (much less systemd), or did you switch for some other reason?

Re:I wrote OpenRC

[Anonymous Coward]

The configuration files in /etc/conf.d/ have been part of Gentoo even before OpenRC. I remember the first time I looked at a Debian setup and wondered why it didn't have that directory--the configuration stuff was put confusingly into the /etc/init.d/ scripts. When I compare how nice OpenRC is with Debian's setup, I could understand why they'd cry for something new.

I do wish they had given OpenRC more of a fair shake. Not only is it cleaner than systemd, but the upstream is much more decent.

Too much integration

[Anonymous Coward]

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

[Cramer]

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.)

Re:Too much integration

[allo]

grub 1 was great, you could install it with a few basic commands from the grubshell (which was in the terminal just like during the boot). grub2 needs config generation and actual use of grub-install.
(But it works okay, too)

Re:Too much integration

[whois]

It installed in less than 2 minutes because there is no software, as you stated in your post.

I use debian preseed and install my systems via PXE in 5 minutes. Of course I tell it not to install any software, so that is part of the reason it installs quickly. The other part being that it doesn't have to ask questions. We could get that time down a bunch by throwing away compatibility with 90% of the hardware. Solaris on Sun hardware used to install relatively quickly, and was very reliable (in some ways) because they always knew what hardware was there.

Honestly, on a workstation boot time is 1000% more important to me than install time. If windows 8 takes 45 minutes to install and boots in 3 seconds then fine, I'll accept a windows update if I'm not doing anything at the moment. If Linux can install in 5 minutes but takes 2 minutes to reboot then I don't want to reboot. Which is fine unless I'm using a laptop..

Re:Too much integration

[thegarbz]

Bloat != larger useful feature list.

Citing GRUB as bloat over LILO is a great example of misusing the word. I wouldn't call GRUB bloated, I would call LILO primitive. There are lots of things you can do and many things people want to do that GRUB is capable of but LILO isn't. That isn't bloat. Bloat would be LILO being the same size as GRUB without any added features that people use.

The same really applies to this discussion. People talk about init as if it isn't something that could be vastly improved. It is. The inability to start multiple services at the same time, track dependencies between services, and drive processes through an event screams of 80s era thinking, a time when things were simpler. No hot-pluggable devices, no pesky end users wanting things like a fast responsive machine, just a basic system requiring a beard of wisdom to run. (Even above one of the rebuttals to init's lack of features was that the person clearly doesn't know how to use init). Should we need to?

If you want a lack of bloat then go download RedHat 3 or some other ancient system. But then don't come and expect your Bluetooth headset to seamlessly work when you plug it in. Like it or not, Linux and Unix aren't solely in the domain of the server room any-more. That's not bloat, that's support.

Re:Too much integration

[aNonnyMouseCowered]

"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."

Not surprised. Less software to install = faster time to install.

Re:Too much integration

[Cramer]

Neither does GRUB 1. And in fact, both are usable with any config file. It's just that every distro out there has means for automatic generation of grub.cfg (menu.lst) to support random kernel packages.

No...

[Junta]

There are significant numbers of people who understand it just perfectly and have valid criticisms that are not bugs.

http://ewontfix.com/14/

The systemd team has pissed of Torvalds:
https://lwn.net/Articles/59368...

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:No...

[Anonymous Coward]

The ewontfix.com/14 article is full of factual errors and was rebunked several times by more knowlegable people. And Linus is pretty easy to piss off, what does that prove?

"If you do not like it, fix it" is still valid. Systemd did up the ante, so it is indeed more work to provide a complete replacement of systemd than it was for systemd to replace sysv init. But then systemd would indeed be poor if it did not provide benefits over previous implementations.

What really amazes me is that people ranting about software starting to depend on systemd does so just to annoy them personally. That is completely stupid: 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?

Re:No...

[epyT-R]

Whether it upped the ante or not is a subjective judgment. In this case, 'fixing' would require reengineering it from scratch. Why, when openRC and friends work just fine?

Re:No...

[Anonymous Coward]

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...

[MurukeshM]

Torvalds is pissed off at Kay Sievers, not at systemd and not at the systemd team. He's fine with Greg Kroah-Hartman taking over that mess until Sievers can get his shit together. I went through the original bug report and the kernel mailing list discussion when it first caught the limelight, and I think you're seeing Sievers's actions (condemnable as they are) as representative of the whole systemd team. (They maybe, in which case you need to show more than one lone post as proof.)

Re:No...

[Darinbob]

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:No...

[Arker]

""If you do not like it, fix it" is still valid."

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...

[MurukeshM]

Those interested may look at LWN's report for a saner, more balanced view: http://lwn.net/Articles/593676/

Re:No...

[Arker]

"The author is basically saying: we shouldn't take the risk of writing complex software."

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...

[t_hunger]

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
* the journal instead of a set of randomly formatted text-dumps all over /var/log,
* 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...

[suutar]

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:No...

[rev0lt]

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...

[suutar]

Actually, as I read it, he's saying "do not make pid1 more complex than it has to be. It can invoke as much complexity as you want, but put it in a different pid." Which does not seem unreasonable to me.

Re:No...

[ceztko]

Ok. What if I agree with you? The linux ecosystem is extremely wide and there already mission critical environments that can benefit from reliability enhancements that are now possible with systemd. To stress it again: I'm taking about reliability features, not faster boot or fancy services status report. So yes: init system must be taken seriously, no doubt. And I firmly believe systemd developers are very serious about it. At the same time I conceive appliances where systemd is just not the right choice and something simpler and minimal should be used instead.

Re:No...

[Arker]

"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.

"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:No...

[segedunum]

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't have a ton of unexplainable bugs in all the scenarios such a system finds itself in. I mean, it discards plain text logs for fuck's sake and has its own web server so you can fucking view them. That is retarded. End of story.

Re:No...

[segedunum]

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...

[segedunum]

I think you'll find he's calling into question the quality, or lack of it, of the software that that crew seems to be producing so yes he is.

Re:No...

[segedunum]

....you're seeing Sievers's actions (condemnable as they are) as representative of the whole systemd team. (They maybe, in which case you need to show more than one lone post as proof.)

Oh come on.

Re:No...

[Arker]

"The linux ecosystem is extremely wide and there already mission critical environments that can benefit from reliability enhancements that are now possible with systemd. To stress it again: I'm taking about reliability features, not faster boot or fancy services status report."

I notice you stress it but you cannot actually cite such a feature concretely. I will give you the benefit of the doubt and assume there is something you could legitimately refer to as such - it would have certainly have to be really super to justify breaking all the other reliability features that go in the trash to get it.

"At the same time I conceive appliances where systemd is just not the right choice and something simpler and minimal should be used instead."

Great, you realize it's not always the right solution. Yet by supporting them you are advancing their goal of making themselves indispensable, of getting package after package rewritten to use them specifically so that more and more software becomes unavailable on sane systems. Even if you are ok with that on the desktop, dont you see how that will be biting your ass when you try to do something different?

Re:No...

[segedunum]

ewontfix article has been demystified several times.

I think that sentence adequately sums up the quality of the 'debunking' of that article - non-existent.

It doesn't need demystified, it's crystal clear.

Re:No...

[MikeBabcock]

Nobody had to reboot when they plugged in a USB device -- we had triggered scripts with udev long before systemd came along.

I'd like to point out that I'm quite familiar with issues like adding "service ipsec restart" to /etc/ppp/ip-up.local so that services start when others do; but its not that hard, and certainly didn't require the flaming pile that is systemd.

Re:No...

[segedunum]

The mailing list posts are VERY clear. There is a HUGE problem with the crew and its attitude that writes systemd and no amount of candy coating the issue with massaged 'solutions' will make that go away:

http://lkml.iu.edu//hypermail/... http://lkml.iu.edu//hypermail/...

But at least there's an upside for me: I don't have to deal with the systemd maintainers' excessively passive-aggressive behavior ;-)

There is nothing ambiguous about that.

Re:No...

[t_hunger]

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... , 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...

[RabidReindeer]

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:No...

[segedunum]

It's all very reminiscent of glibc actually.......

Re:No...

[ceztko]

I notice you stress it but you cannot actually cite such a feature concretely.

In my first message I was chatty but I cited some. Anyway: cgroups, reliable mount handling (boot time barrier and during system uptime), socket and filesystem based activation. These features alone remove plenty of race conditions in services life cycle.

Great, you realize it's not always the right solution. Yet by supporting them you are advancing their goal of making themselves indispensable

I support modern and technically superior software. I supported upstart when it was a clear improvements over sysvinit. I stopped supporting it when I understood their were unable to fix their own bugs and rethink wrong design choices.

Re:No...

[t_hunger]

"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 first sysv-init based Linux ever either;-)

I never measured the boot up times, so I am not sure whether systemd is faster or not. I frankly do not care one way or the other.

"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.

At least here systemd has no open ports. Why does it matter whether systemd, upstart, sysv init or openrc started the sshd under attack?

With the options to limit the process that systemd offers I can even severely limit what an attacker can do on my system once a daemon is compromised. Those countermeasures are of course also possible with init-scripts, but they are *way* harder to implement securely. I have not seen many distributions that bothered to add any additional security measures to their init scripts.

A local user is something different, true, but considering that you are referring to sshd that does not seem to be your argument.

"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.

Read a couple of man-pages and see for yourself.

Re:No...

[brantondaveperson]

Can you help me out here? I would love to know what the crux of this little flamewar that's going on around here actually is. Near as I can tell:

1) init is pretty much just a bunch of shell scripts that are used to start & stop services. It, IMHO, qualifies as an unmitigated hack
2) systemd is... what? Something sensible that at least attempts to start & stop services in a standard way?

I mean, forgive me, but it seems that this is a vast improvement. Who wants a system that's basically a collection of scripts? That just seems so fragile and un-documentable.

And then, into this, comments such as yours are thrown:

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.

When I see a statement like that I think to myself - why. What is sacred about PID 1? Why should it do very little? How is this a premise of an init system? And would you be happier if PID1 launched systemd as, I don't know, PID2, and then did very little?

I really seems to me that getting rid of that horrible kludge of shellscripts and moving towards a standardised and sensible startup process is a big step forwards in Linux land.

Re:No...

[lister king of smeg]

Can you not just run the unix kill command as per the first recommendation on the Apache documentation for stopping and restarting Apache?

https://httpd.apache.org/docs/...

Re:No...

[Arker]

"That kill apache, not the crap it started and that forked itself away."

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...

[epyT-R]

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...

[dbIII]

bombing my system back into the 60s

With some of the things systemd has not yet implemented or does not plan to that is what systemd is doing :(
I wonder how upstart and the other less vocal and intrusive projects are going in comparison? Upstart had a very simple approach initially instead of being a large interdependent fragile structure like systemd.

Re:No...

[Anonymous Coward]

I guess you didn't notice
  - the journal doesn't support remote loggings - so you can't get logs anymore that are not spoofed.
- the inconsistant startup of apache that fails.... sometimes.
- an inconsistent boot process that doesn't let you change your swap configuration... and hangs sometimes
- a less secure system because you can't get logs, and lose log information, and can't debug problems due to timing failures caused by the rest of the system
- a lot of inconvenient system config tools that don't always work, or do the wrong thing sometimes. The "do one thing and do it well" tools got replaced by tools that try to do everything, none of them done very well.

Not to mention that a network analysis tool that cannot solve the NP problem that is part of network analysis...

And the constant patching of services because systemd can't properly schedule services...

Just adding a new service to a startup can spawn all kinds of failures due to the inability to handle a specified order...

You people that think systemd is wonderful have never had to debug a complex system. systemd sucks big time - it can't be secured (it does too many things poorly).

Re:No...

[Arker]

In my first message I was chatty but I cited some. Anyway: cgroups, reliable mount handling (boot time barrier and during system uptime), socket and filesystem based activation. These features alone remove plenty of race conditions in services life cycle."

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 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?

These features alone remove plenty of race conditions in services life cycle.

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:No...

[TobiSGD]

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

So please enlighten me: Who the hell told you that mechanisms like cgroups are systemd-only?

Re:No...

[countach74]

No because Apache does an awful job of managing/terminating processes it spawns. FastCGI and other gateways come to mind. As far as I know, though, this is really an issue with Apache, not with older init systems. Systemd may very well have tools to "fix" that problem, but unless I am mistaken, it's really not systemd's problem to fix.

Re:No...

[sylvandb]

If you think sysv init is not broken, then you must not have been using unix systems in earnest.

...

Sheesh:-)

"Sheesh" is right.

Funny how I've been "using unix systems in earnest," and Linux systems in particular for over 20 years, and never needed systemd to solve the problems you point out. That usage includes desktops, servers and laptops so I really don't know what impediment you and lennart suffer from that causes you such problems that you think systemd is the solution.

Re:No...

[sylvandb]

Can you help me out here? I would love to know what the crux of this little flamewar that's going on around here actually is. Near as I can tell:

1) init is pretty much just a bunch of shell scripts that are used to start & stop services. It, IMHO, qualifies as an unmitigated hack
2) systemd is... what? Something sensible that at least attempts to start & stop services in a standard way?

I mean, forgive me, but it seems that this is a vast improvement. Who wants a system that's basically a collection of scripts? That just seems so fragile and un-documentable.

...

I really seems to me that getting rid of that horrible kludge of shellscripts and moving towards a standardised and sensible startup process is a big step forwards in Linux land.

Those who don't know Unix are doomed to re-create it, poorly.

Re:No...

[socode]

> Why would you want to convert rich information into a string and shove it down a pipe before you make use of it?

I think you've lost sight of the purpose of an OS and the purpose of logs. An OS is not running for the sake of running an OS, and logs are not persistent structured application data, but ad-hoc information about the behaviour of the system for human consumption.

They need to be filtered, sliced, and flattened as needed *post-facto* to be of any use. Given that you don't even know what I want to log, from where, how is that going to be normalised in a centralized journal? Will it let me query by anything more than straight filter on app or PID etc - like I can already do?

Re:No...

[socode]

> instead of bombing my system back into the 60s.
Ironically we were going to the Moon in the 60s and had supersonic passenger flight. We don't now.

Re:No...

[jmrcpn]

I strongly disagree Tobias

Systemd is becoming kernel over a kernel.
It is designed with a closed system in mind.

People are telling "wrong/poor design" and answer is "there is still few bug, lets increase dependancies".
I am pretty sure, systemd is wonderfull if your hardware/production is not in trouble, but as soon you have smal problem or your try to implement something a little bit fancy,
you are not in trouble anymore, you are very quickly in very very sour situation.(personall experiences with systemd)
systemd must be very convenient for tablet, I strongly object about systemd for a server or for real hardware.
IMHO systemd and windows are very alike, a black-box.
Keep in mind, Concorde was a very big improvement over Boeing-747, "improving is not always a good move".
From my side: RHEL7 is not a option

Re:No...

[socode]

> I mean, forgive me, but it seems that this is a vast improvement. Who wants a
> system that's basically a collection of scripts? That just seems so fragile and un-documentable.

Did someone tell you "script" is a bad word?

You have a choice to keep this represented in a higher layer (text file scripts laid out sensibly written in a high-level architecture-independent language), or as a set of compiled binaries forming a monolithic Windows-style system with a multiplicity of hidden inference rules.

And the current init files can be improved if you don't like the layout or want to make new facilities available - do you think it's impossible to add dependency graph tracking in a way that is accessible to scripts rather than having a "registry"?

Re:No...

[jmrcpn]

Fully agreed

Re:No...

[rastos1]

So is one of the goals of systemd to fix problems in other programs?

Re: No...

[Anonymous Coward]

Systemd is not the only choice GNU/Linux has. Just because systemd is a Red Hat funded project, and is being adopted by the mainstream distributions, doesn't mean it's the only choice. Small, unfounded, and non-mainstream software also exists that is available but isn't widely used because any number of reasons.

Over at LinuxQuestions several guys have been experimenting with finally getting a full port of Gerrit Pape's Runit init and daemon manager ready for mainstream usage alongside Eudev which they completed work on a while ago, and was actually published in the LFS-Dev book.

These guys are just users and system admins who, from reading their work, are sick of the hype, lies, and misinformation surrounding the fanboyism and propaganda being promoted by the pro-systemd crowd, and honestly, who can blame them? But these guys are making a difference by actually trying something different.

It's sad only three people are even working on the Runit effort for LFS as a complete fully featured and functional alternative and successor to sysvinit. LFS software can be fully transported out into any Linux distribution. Maybe if they had more help, systemd would be just another alternative, but I guess people are willing to drink the koolaid no matter how much poison it contains.

Re:No...

[macro187]

"systemd" and "good open source citizen" in the same sentence? Irony.

Re:No...

[MurukeshM]

The first is Linus's reply in which the very first line is:

And by "their" you mean Kay Sievers.

As for Ingo, for all I know, he may have some beef with the systemd team.

Re:No...

[Anonymous Coward]

... that runs counter to 40 years of unix evolution that has worked quite well.

Except the old init is a big honking pile of annoying patched-up-to-barely-work dirt of complex shell scripting.

Re:No...

[t_hunger]

No it one of systemd's goals to manage a system reliably.

Processes that double fork end up with the init process as its parent in the process tree: That is unix-philosophy at work and apache is not to blame here.

That makes it really hard to manage things like apache without additional concepts like cgroups. Those are actually not complex nor do they require lots of code to be implemented, but they need to be managed in a central place to be useful. So systemd does that right in the init process so that you get maximum benefit from the concept.

Re:No...

[t_hunger]

There are several. https://tim.siosm.fr/blog/2014... is the first one that come up googling for the headline of the ewontfix article.

Re:No...

[rev0lt]

Let's start with a useful format and use lossy conversion methods on that when needed, not the other way around.

I don't get where you think *text* is a lossy format, but ok. Lets add complexity and failure points to something that should be easy.

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?

Apples and oranges. Text is never a lossy format.

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

Well, you do *mention* apache, so the most common approach is to just kill the master process, and all the child processes die. You know, unix systems. In case of apache, you even have an utility for it - apachectl. Other approaches would be 'service apache22 stop', kill -TERM `cat /path_to_apache_pidfile`, and of course, kill -9 $(ps -ef |grep apache2 |grep -v grep| awk '{print $2}') or any other variant (eg. in freebsd you could do a ps ax | grep Ss | grep httpd to determine the master apache process and its pid to kill). On many linux systems, you also have killall and/or pkill, that will achieve the same effect by process name, and easily usable with apache, nginx and the cgi wrappers you may have running.

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.

I did. FreeBSD 9.2. Most of the sleeps are for hardware settling. Replacing a shellscript sleep() with a binary version of it is not a solution anyway. Both rc.d and init.d approaches allows you to prioritize script startup, to achieve that same effect. In FreeBSD, the rcorder (http://www.freebsd.org/cgi/man.cgi?query=rcorder&sektion=8) allows you to quickly visualize service dependencies. In OpenBSD I specify in rc.local the order I want my stuff to start. I'm assuming other systems provide vaguely the same funcionality, its not rocket science. (Again, a solved problem).

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.

I'm not against uniformization. What I don't see is the need for yet another tool that fragments even more the available options. And uniformization is pretty common in other operating systems - check eg. FreeBSD and OpenBSD: they are quite different in terms of setup, but not that different. Its not like it wasn't possible before. That approach exists for decades.

Check out http://www.freedesktop.org/sof... [freedesktop.org] , especially all the options starting with "Private" there.

It sounds like a meta-version of linux containers. Why would I want that implicit on a startup script? Its about doing one task and doing it good.

Yes, I know: Just suggesting to look into systemd is sacrelegious:-) Sorry, I won't do that again.

You did not suggest. You touted it as solution to problems that, frankly, do not exist. It may have features that are very helpful, it may solve a lot of problems, but you mentioned none. Not one valid existing problem.

By then all the hotheads that are running for the BSDs now will be back

Probably not. BSD is not usually appealing to the linux crowd, at least server-wise (the guys that would actually take advantage of some of the features you mentioned). And the ones I know did t

Re:No...

[rev0lt]

With systemd it is just one convenient systemctl stop apache

...Except most of the time you DON'T want to stop everything that apache depends on. Eg. MySQL and Memcache comes to mind. If you DO need this, you can easily do it by an alias (the most easy solution) to something like apachectl stop && service php5-fpm stop. Again, this isn't even a problem.
What you usually want is to start all dependencies of a given program (eg. fpm when you start apache). This is a solved problem.

Re:No...

[t_hunger]

I think you've lost sight of the purpose of an OS and the purpose of logs. An OS is not running for the sake of running an OS, and logs are not persistent structured application data, but ad-hoc information about the behaviour of the system for human consumption.

I am not talking about structured application data, I am talking about facts that go with the actual log message like the timestamp, the PID that the message originated from, the capabilities the process has that originated the message, the full filename of the process running, which cgroup the message originated from, which boot id this message belongs to (really nice if you want to see one boot/run/shutdown cycle only), that kind of data.

Having that information in the journal is really nice. Not having to parse it out of some textfile where some application put it in a more or less randomly selected format is even nicer. Correlating data from different log files written by different applications is a huge pain that is completely gone with journald.

They need to be filtered, sliced, and flattened as needed *post-facto* to be of any use. Given that you don't even know what I want to log, from where, how is that going to be normalised in a centralized journal? Will it let me query by anything more than straight filter on app or PID etc - like I can already do?

Yeap, it does. It makes full use of all the extra data it adds to the log entries and thus allows for way more reliable and powerful filtering, slicing and dicing:-)

Re:No...

[t_hunger]

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.

Considering that reparenting processes that double fork is tried and true unix philosophy: It would be somewhat surprising to see apachectl properly clean up after itself in your so called cleaner system. Maybe you just fail to properly recreate the problems in your trimmed down universe?

And yet this is an argument for introducing yet more excessive complexity to remedy? Doesnt make sense to me.

None of the init systems currently in use is conceptually very complex. In the end sysv init is actually one of the more complex ones. The others are of course different, but I would not actually call them conceptually more complex.

In fact setting up a service and then starting it is significantly simpler with systemd (and upstart and openrc) than it is with sysv init. Give it a try before complaining about it.

Why would I care? I dont use that system and am not affected by their bugs.

Hmmm... why would you? Maybe because these are fundamental issues with how sysv init works?

Re:No...

[Hurga]

You can wire up syslog to the journal.

I don't want to, I don't need to. I just want every bit of information a horribly broken system is still able to tell me about its state. This won't work better is you move away from plain text. - BTW: How do you use remote logging with systemd? Sending and receiving?

So please enlighten me: How do you kill apache with all the php/ruby/whatnot crap it directly or indirectly spawned?

apachectl stop

Yes, really. This is not the most simple setup here (suexec php5/fastcgi), but starting/stopping of the spawned php servers has never been an issue, even without systemd.

Please do not assume that I am too young or too stupid to know the good old ways.

Admittedly, you are making that hard to believe when you even have issues with stopping apache. There is no problem to fix.

Grep for "sleep" in the init scripts of the sysv-init distribution of your choice: You will be surprised.

Not really. A few sleep 1, speech-dispatcher has a sleep 3 and stunnel4 sleep 5. Both at restart. I couldn't care less.

By the way, there are alternatives to sysv init. They work well and don't even break compatibility. They are what systemd needs to be compared to.

Let's just wait a year or two. By then all the hotheads that are running for the BSDs now will be back

Linux and Free Software are about modularity and choice. Large-scale breaking of backward compatibility and user expectations for dubious reasons is not going to play well with the community. Linux is already getting WAY too complex for people concerned with security, and additional complexity in form of enforced blessings by a group of people who comes across as conspirators gives me a very bad feeling. Who profits from intentionally weeding out choice? We'll see, but don't expect me to wait for it.

Re:No...

[discord5]

I was more thinking about starting postgres before the server that uses that DB to store its stuff.

Allow to go off on a tangent here, but most of the setups I deal with keep databases and webservers on separate machines. Today we've got virtual machines coming out of our collective asses so even developers start separating their services from each other. What you're talking about is dependencies and how to deal with failure of a service. That goes far beyond the scope of what systemd can provide, since it's so cheap and easy to run stuff on different (virtual) machines these days. However, I realize that you're using this as an example, so I won't really press on the matter other than that this is the poorest example you can choose.

But it does speak to part of the problem. All I continuously hear about systemd as the greatest advantage is solving the "complex boot order" dependency problem, parallelizing boot scripts and decreasing boot-time. To me, as a sysadmin: I DON'T care. I'm pretty sure that 90% of the servers I have running take a longer time in POST than they do in booting. If I reboot something, I'm taking it OFFLINE. I'm not sitting there crossing my fingers "Please come up quickly", but I've got a failover setup and another machine has taken over before the server is rebooting. And "complex boot order" really? Is that really that big of a concern? I really hope you don't have to manage 500+ servers then, because you'll be in for a surprise on complexity.

This brings me to interesting questions that I hear nobody talk about. If you're doing failover type of things, you're bound to end up with heartbeat/corosync/... + pacemaker & co. As a sysadmin, for me those things are extremely important. Last time I checked (and granted, that was a while ago), none of these actually had a proper way to deal with the impact of systemd. I'm sure that the people behind the various failover solutions are working on it, but last time I checked I saw very little in official documentation, and only the occasional headscratching on mailinglists.

To me, systemd presents quite the challenge, with consequences even outside of the technical side of things. For a while I'm going to end up in a mixed environment, forced to write two sets of operational procedures, disaster recovery scenarios, etc etc. I'm going to have to retrain people on how to read system logs, have to deal with systemd's quircks (no offence, all software has its peculiarities, and so will systemd), and will probably have to completely rethink how we do failover scenarios. And all I gain, what I'm really interested in is... cgroups...

Projectors, usb disks and sticks, whatever ... Those things have no place in a serverroom, and I don't care about it. And let's be frank, nobody in a corporate environment gives a shit about linux on the desktop. The few companies that I've been at that have linux on their desktop are small businesses with a near complete tech workforce.

Why would you want to convert rich information into a string and shove it down a pipe before you make use of it?

I think I know the answer to that question. Some environments need to archive their logs, for a long long time. Some things are more complex than a "simple" local syslog setup, and with that complexity comes a set of tools that often organically grows over the years or follows certain administrative procedures inside a company. In such environments, change is a difficult process, not because of people but because of corporate inertia and red tape bullshit. And it's great that systemd provides a syslog fallback for us text-junkies, at the very least it buys time...

The other side of the medal however is, nobody is really having a problem with text logfiles. The examples I continuously see are so contrived, or focussed on "the linux newbie" that it just reeks of a developer looking for something to do. My biggest frustration with lo

Re:No...

[suutar]

Thanks!

Re:No...

[JD-1027]

You lost the thread man.

We're here to discuss, not win or lose. It was an interesting read for someone who knows very little about init processes!

Re:No...

[Arker]

"We're here to discuss, not win or lose."

I wasnt using lose in that sense. I mean he lost the thread, as in he lost track of who he was talking to.

Re:No...

[segedunum]

If the author find real bugs and truly disruptive design choice in systemd he should do as any good open source citizen: report it. This has already been done recently for the "debug" command line switch controversy.

They have been reported, and in true fashion they are dismissed in that passive aggressive style that has become oh, so familiar. The comments section of that article makes that clear and it makes it clear that those behind systemd have no idea how a Unix style system should work, and why. Hint: Poorly documented, bullshit XML schemas have no place anywhere near there. Linus, Ingo Molnar and Ted Tso have all made their positions crystal clear on the style and maintainership of that piece of software and the people behind it. As Ted Tso put it:

...one of the reasons why this happens is because +Kay Sievers and +Lennart Poettering often have the same response style to criticisms as the +GNOME developers --- go away, you're clueless, we know better than you, and besides, we have commit privs and you don't, so go away.

So, please stop using that pathetic 'Report it' excuse. It will make no difference and we all know it won't.

This has already been done recently for the "debug" command line switch controversy.

You're not honestly trying to suggest that that bug report was solved in anyway approaching a satisfactory manner, are you?

The net effect of this is someone, probably a bunch of kernel developers, are going to have to get hold of this shit and sort it out by writing a proper and sane init system because userspace is getting totally out of hand.

Re:No...

[segedunum]

Put simply, if the systemd people feel they're going to have an argument with kernel developers about how things should work and win, forget it.

Re:No...

[segedunum]

Those who don't know Unix are doomed to re-create it, poorly.

As simple as that, basically.

Re:No...

[segedunum]

When I see a statement like that I think to myself - why.

The fact that you have to even ask that means that you will never get it. When you have an init process that feels the need to do a whole lot more you have several times the bugs, and this is a system you're relying on to boot a system - which you're then going to have to troubleshoot. As a system administrator it fills me with absolute dread.

I really seems to me that getting rid of that horrible kludge of shellscripts and moving towards a standardised and sensible startup process is a big step forwards in Linux land.

Shell scripts are human readable, they work and they stand independently so if something fails, most of the time, it won't affect anything else. In a systemd system you won't have the faintest idea what s going to happen. There is no reason a more sane init system could not be developed that used human readable scripts and logs, and we certainly don't need systemd to get there.

Re:No...

[BadDreamer]

That one does no debunking. Please, link some that does? As it stands I see no reason to discount the ewontfix article as it makes sense, and the link you provided does not.

Re:No...

[MikeBabcock]

For all I know, he's a great developer who expects people to solve real-world problems in a way that makes users' lives better.

Re:No...

[MikeBabcock]

Precisely why some of us run critical services under Daemontools ... simple, clean, and reliable. Its logging concept is a vast improvement over syslog for local logging, and if you're not into it, it doesn't force you to use it at all.

You want to make sure SSH is always running or trying to run? Put it in a /service ... it will start or at least keep trying.

Re:No...

[MikeBabcock]

The author(s) of systemd are even worse than DJB for admitting that flaws are flaws. If we have to wait for the author to accept a flaw as a real problem, we might as well all just give up.

Emacs

[Hugonz]

RMS must be grinning, Linux has finally implementes Emacs as its startup system.

Re:Emacs

[Unknown Lamer]

Not yet, but eventually. Systemd has all of the bloat of emacs, without any of the benefits.

Re:Emacs

[Noryungi]

Hence, the old joke: "Actually, Emacs is a pretty decent operating system. Shame it does not have a good text editor, though".

Re:Emacs

[Tough Love]

Can systemd send email?

Re:Emacs

[t_hunger]

No, but it can start a service for you that can.

Linux no longer wants to even look like Unix

[Anonymous Coward]

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.

Re:Linux no longer wants to even look like Unix

[Darinbob]

Maybe this is a problem inherent in open source? Someone idealistic has an idea and is allowed to run with it, find other likeminded people, and so on. Whereas in the corporate world you often have managers what will try to keep the teams focused and steer them in directions that will improve the products or implement what the customers are actually asking for. I have seen some new hire junior programmers who start off the first week with lots of ideas that they think are awesome ("let's rewrite everything in this new cool language!") but which are impractical or irrelevant to the product lines.

Re:Linux no longer wants to even look like Unix

[Rich0]

Maybe this is a problem inherent in open source? Someone idealistic has an idea and is allowed to run with it, find other likeminded people, and so on.

You do realize that the source to Gnome 2, sysvinit, arts, and the rest are all still available, right? Nothing is stopping anybody from making another Gnome 2 release.

If you want people to write you free software, then you are going to have to be content with what they give you.

Whereas in the corporate world you often have managers what will try to keep the teams focused and steer them in directions that will improve the products or implement what the customers are actually asking for.

Slight correction - they direct people to implement what the customers are actually PAYING for. If you want to change the direction of FOSS, just hire a team of developers to do whatever you want with it, and they'll do whatever you ask them to as long as the paychecks keep coming.

Re:Linux no longer wants to even look like Unix

[pjbgravely]

Someone did restart Gnome 2. It is called mate.

Slackware

[syzler]

Slackware is an alternative mainstream Linux distribution which does not use systemd. Instead of systemd, it uses a combination of custom rc scripts and sysvinit. If Slackware ever adopts systemd as the default system init, they would likely lose most of their user base.

Slackware

[Anonymous Coward]

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.

Confused

[ThisIsSaei2561]

I'm not sure what the issue is here.

If you're looking to avoid using systemd, move to a distro that doesn't use systemd. (I think Mint still uses upstart and Gentoo uses openrc.) Otherwise, do the legwork to support the init system you want to use.

Re:Confused

[epyT-R]

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.

same boat for a lot of Linux users.

[nimbius]

Im currently running Gentoo. it offers systemd as a package and ive even run it a few times with success. What it offers, along with uefi, is a chance to drastically speed up the boot process but at a cost to the Linux ethos of 'do one thing and do it well.' Im just as conflicted, and seeing as i work in a RedHat shop i fear ill have to start using it eventually. TFA from sporkbox in the summary highlights the major pain points of systemd quite nicely but the other problem it poses is the homogenization of linux and what that means to numerous Linux community members personally. Linux used to be about choice, but so many distros are systemd/gnome/networkmangler now that its almost horrifying. I get that a unified platform is the key to a 'year of the linux desktop' but the sense of alienation and loss that systemd imparts is very palpable for many of us.

Back on topic though, Gentoos commitment to choice means you can run OpenRC. Its a fine time-tested alternative to SystemDoEverything and while your coworkers might be confused by it, at least you wont have to hack through binlogs for ages to fix a problem in it. You're best not trying to hack out systemd or any of its dependencies in distros like Fedora or Ubuntu as theyre basically so intrinsic to the OS as to render it useless if removed.

Sorry i cant offer more closure for the issue, I hope someone in the thread can though. For me i worry in another ten years ill be deploying machines that are exclusively systemd, quietly muttering the free software lyric, 'You'll be free, hackers, you'll be free.'

Re:same boat for a lot of Linux users.

[Anonymous Coward]

Using the term "SystemDoEverything" just means you've bought into the hype of the naysayers without actually understanding anything about what systemd does. That's too bad. In reality, systemd completely embraces the time-honored unix concept of "Do one thing, and do it well." If you actually look at systemd, you'll see that there is no One Binary That Does Everything. Systemd is a pretty big collection of binaries, that each do one thing really well.

I am doing embedded engineering and have implemented systemd across all of my embedded projects now (4 separate projects in total, each massively business critical). I have seen huge improvements in traceability of the boot process, speed, correctness and am overall very pleased. I also appreciate that it is *highly* modular. Anything you don't like, just don't compile it. We now get process monitoring and restart for free (used to be a separate, buggy, daemon).

Overall, when I read any of these threads, I typically just see people repeating the same tired old crap and they have obviously not done any research because most of the main points are simply not true.

Re:same boat for a lot of Linux users.

[Anonymous Coward]

I would be interested to hear more about how the issues listed at ewontfix are incorrect. (Not sarcastic; if they're wrong, I would like to know.)

Re:same boat for a lot of Linux users.

[Wheely]

Are using a UI for "date" as your argument?

Admittedly, setting the timezone is pain these days but thats because of the same thinking i.e make a simple thing as complex as possible.

Re:same boat for a lot of Linux users.

[Anonymous Coward]

OpenRC can do parallel service activation as well, though it's not based on sockets like systemd. Rather, each initscript declares dependencies on specific services like "Service XYZ must be started before this service may start", or on general classes of services, like "I need a syslog logging daemon before I can start".

GNU Is Working on It

[Unknown Lamer]

See Daemon Managing Daemon. 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?). Development on DMD is pretty active now, 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)..

Re:GNU Is Working on It

[epyT-R]

scheme? Why would you write a system init in a functional language? It's ALL about states and dependencies. Your examples would, at best, be managed as dependent what-if events by init.. There's no reason for init to have carnal knowledge of openafs etc.

Don't like it?

[Anonymous Coward]

Write your own. The source code is out there - fix what you don't like.

Re:launchd

[McKing]

And both systemd and launchd are inferior versions of SMF from Solaris.

depinit

[lkcl]

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.

Re:depinit

[ewhac]

written by richard lightman [ ... ] his web site is now offline: you can get a copy of depinit however using archive.org.

Last snapshot I could find on archive.org: http://web.archive.org/web/200...

Re:depinit

[lkcl]

LOL

"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."
you mean like pam_ssh for ssh keys or if you just want it to work with gpg and ssh you could also run the gnome key manager as I do.
True single sign on with all ssh and gpg keys.

no not pam_ssh. not "ask for a 2nd passphrase at a 2nd prompt which is entered into the ssh system to unlock the ssh key" - have ABSOLUTELY NO login credentials AT ALL, and LITERALLY use the success/fail of the ssh passphrase (or gpg passphrase) unlocking *AS* the login. no /etc/shadow, no password field in /etc/passwd - nothing BUT unlock the gpg or ssh key.

Alpine linux

[staalmannen]

I am currently playing around with Alpine linux, musl libc + busybox + openrc. I like it a lot - a binary package management similar to Arch linux.

Re:Alpine linux

[ls671]

Alpine is what I use everyday to send email, very powerful tool:

? HELP-Get help using Alpine
C COMPOSE MESSAGE-Compose and send a message
I MESSAGE INDEX-View messages in current folder
L FOLDER LIST-Select a folder to view
A ADDRESS BOOK-Update address book
S SETUP-Configure Alpine Options
Q QUIT-Leave the Alpine program

Copyright 2006-2008 University of Washington
Copyright 2009-2010 Re-Alpine Project

what's wrong with systemd

[Rutulian]

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

[mr_mischief]

5) fork the distro of your choice and build all packages with smarter dependencies (or to depend on the packages of your choice)

Re:what's wrong with systemd

[Rich0]

5) fork the distro of your choice and build all packages with smarter dependencies (or to depend on the packages of your choice)

Or run Gentoo, which generally does just that. :)

Systemd is becoming more and more mainstream on Gentoo, and I suspect that at some point it will take over as the default. However, I doubt support for openrc is going away anytime soon.

I think OpenRC is about as good as a traditional sysvinit/rc implementation is going to get. It is definitely superior to what most distros were using before upstart and systemd came along. However, I don't really see it keeping pace with systemd at this point.

Re:what's wrong with systemd

[Rich0]

I looked at gentoo last time I decided I hated all linux distros, lost all interest when I saw they still don't have an installer script.

Probably just as well. :) Seriously, Gentoo is not really the best choice for anybody who wants an automated installation, as that is just the start.

Re:what's wrong with systemd

[Arker]

"First, I have to ask, what is wrong with systemd?"

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

[fgodfrey]

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:what's wrong with systemd

[Billly Gates]

So in other words you do not like it because it looks and feels different than what you are used too with old inet.

How is this different than the 50 year old XP users who hate and hop up an down on how bad Windows 7 is because if looks too funny? It is not a bad program.

It is different because event driven is what is needed today. Yes unix users are hardcore and do not like changes to things, but this isn't 1982 anymore where you had maybe 35 shell utils and programs total and you could all neatly manage it all in /etc/init.d like clockwork. Computers did not fall asleep on one network and wake up in another? You did not have to think about usage scenarios where things happened based on a network intrustion or when disk space is near filled. You did not have bloated startup times due to everything trying to load at the same time or things running only sequentially.

Init 3 to run a console, and init 5 for a gui is archaic today, but thought it was cool in 1999. Init itself is very confusing and you needed to be a hacker in the 1980s to understand what was and why. Frankly the only reason it seems so easy to those reading this is because you are familiar with it.

Re:what's wrong with systemd

[Darinbob]

I'm not sure what "keeping pace" means. If openrc does the job, it doesn't need to add features. The issues most people seem to have with systemd is that it keeps adding stuff that is not part of the traditional system init.

Re:what's wrong with systemd

[Rich0]

I'm not sure what "keeping pace" means. If openrc does the job, it doesn't need to add features. The issues most people seem to have with systemd is that it keeps adding stuff that is not part of the traditional system init.

If somebody just wants a traditional init, then they'd be fairly happy with openrc.

Re:what's wrong with systemd

[ls671]

"So in other words you do not like it because it looks and feels different than what you are used too with old inet."

I didn't know systemd also replaced inetd. Is it planned to also replace apache and sshd as well in future releases?

Also, some people are less obsessed by boot time than others.

Re:what's wrong with systemd

[Arker]

"So in other words you do not like it because it looks and feels different than what you are used too with old inet."

No. Let me be very clear here. I dont like it because it is a bad idea. Nothing this complicated should ever be PID1, for starters.

Init could use a redesign, but a good redesign would look to reduce complexity, not increase it. It would give us something simpler and robust at PID1, not something that's larger and more complicated. And it sure as hell would not be something so complicated, over-reaching, and fragile that it brings your system to a halt when you pass 'debug' to the *kernel.*

Linus has been waaaaay too forgiving of this crap.

"Yes unix users are hardcore and do not like changes to things, but this isn't 1982 anymore where you had maybe 35 shell utils and programs total and you could all neatly manage it all in /etc/init.d like clockwork."

Granted init is over-complicated, the point remains that systemd moves in the wrong direction so this is not an argument in its favor.

That said, if you really cannot manage your init.d with just a tiny bit of effort, your system is clearly over-engineered and needs some simplification. A good design isnt done when there is nothing left to add, it's done when there is nothing left to *remove.* And similarly with a linux install - if you do not understand each and every thing that is happening in your startup sequence then it is time to start pruning it until you do.

Re:what's wrong with systemd

[Rutulian]

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 than some of the other fundamental changes to the userspace that have happened over the years.

- Binary Logs: Sorry, but there is no advantage to not being able to easily look at a log file.

Technically, there is an easy way to look at the logs, it just requires a utility that is not cat or grep. But I get your meaning. Binary logs are certainly not my preference, but for tools that need to interact with and parse the logs, it is a necessity. There are ways to get your text logs back, though, and some distributions configure it this way by default.

- Failure to Log to the Console:

It is in the log. With sysV your were dependent on your particular shell script trapping certain errors and writing them to stdout (or not). With systemd, since the daemon follows the process of forking or attaching to dbus at every step, it collects all the debug information it can and sends it to the log. So "journalctl blah blah" is exactly how you get those messages.

- Failure to Drop to a Shell When It Breaks:

Once again, it is in the log. I'm not sure why being dropped to a busybox shell gives you a much better way to debug than just reading the log messages. If you want to test individual systemd services, you can do that with systemctl start/stop/etc.

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.

If that is true, it is a bug.

- Races: I no longer have any idea what order things are starting in.

If a dependency issue is causing your boot to randomly fail, then your systemd configuration is horribly broken. That is exactly the problem that systemd is designed to fix. You don't know what order services are starting in because you shouldn't need to. The only thing your unit should do is specify a preferred ordering. That is it. Systemd handles the rest.

SysV is just shell scripts. I *DO* deal with *those* every day so it's pretty easy to debug.

Have you every really had to deal with the complexities of the sysV init system? It is not pretty. "Jiggling the cord" until it works is about all you can reasonably do with sysV when you have a complex init.

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.

It doesn't "mount filesystems" at a single time during boot the way sysV does. You can move service files to other filesystems, but then you need to tell the service config that you did this so that it can bring up that filesystem before starting the service. This is actually a lot easier to do with systemd than with sysV.

From all outward appearances, the developers have *no* interest in fixing much of any of those complaints.

Well, this is more of a rant than a series of legitimate complaints. You can't expect the systemd people to understand your issues if you haven't even taken the time to learn how systemd works first.

Re:what's wrong with systemd

[fgodfrey]

- Binary Logs: Sorry, but there is no advantage to not being able to easily look at a log file.

Technically, there is an easy way to look at the logs, it just requires a utility that is not cat or grep. But I get your meaning. Binary logs are certainly not my preference, but for tools that need to interact with and parse the logs, it is a necessity. There are ways to get your text logs back, though, and some distributions configure it this way by default.

...which will almost certainly break if the logs get corrupted at all. The great thing about text logs is that my brain can figure out what values are probably garbage and which ones are the remnants of the (now corrupt) log a lot better than a computer can. There are certainly ways of hardening binary logs, but why? syslog is a PITA to parse by machine not because it's text-only, but because the formatting is from the 1960's. I'm not arguing it has to be syslog format, just text.

- Failure to Log to the Console:

It is in the log.

...until you don't GET the log because it wasn't *WRITTEN*, which probably hasn't happened to you because you're probably booting a fairly standard configuration. But it took me 3 f'ing hours to debug the fact that my permissions were wrong on my NFS server when I was net-booting because I got no shell and no log (because the permissions were wrong). That would've take 20 seconds with logging to the console and knowing more about systemd wouldn't have fixed that.

- Failure to Drop to a Shell When It Breaks:

Once again, it is in the log. I'm not sure why being dropped to a busybox shell gives you a much better way to debug than just reading the log messages. If you want to test individual systemd services, you can do that with systemctl start/stop/etc.

Because sometimes it's a lot nicer to try to reproduce the failure right then and not have to reboot the system in order to get to the log. Remember, no shell means you can't read the log *at all* without rebooting.

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.

If that is true, it is a bug.

Maybe, but systemd --test --system prints "Don't run test mode as root" on OpenSuSE 12.3 and Fedora 20.... While trying a few other distro's to post this comment, I ran across "systemd-analyze --order --system plot" (which wasn't in the original distro that I was debugging, but it was ARM so maybe it was weird) which appears to be able to generate a graph in SVG, which, while huge, appears to help me a lot.

- Races: I no longer have any idea what order things are starting in.

If a dependency issue is causing your boot to randomly fail, then your systemd configuration is horribly broken. ... You don't know what order services are starting in because you shouldn't need to. The only thing your unit should do is specify a preferred ordering. ..

...until something doesn't work. Yeah, the config I've got *IS* horribly broken. I'd like there to be some reasonable way for me to figure out how to fix it. And sometimes I don't *PREFER* an order, sometimes I *REQUIRE* an order. On my desktop? Couldn't care less because it "Just Works(tm)' and I rarely change the distribution's defaults. On my servers, it's more complex. Maybe "prefer" in this case means it will always honor that?

Have you every really had to deal with the complexities of the sysV init system? It is not pretty. "Jiggling the cord" until it works is about all you can reasonably do with sysV when you have a complex init.

Yes. I obviously have no idea what your experience is, and maybe you had a

Re:what's wrong with systemd

[rastos1]

If a dependency issue is causing your boot to randomly fail, then your systemd configuration is horribly broken. That is exactly the problem that systemd is designed to fix. You don't know what order services are starting in because you shouldn't need to.

If systemd does badly something it is designed to fix ... that does not leave a good impression ;-) On a serious note: never tell me that I don't need to know how things work. If that was true I would be running Windows and people that don't know how things work would not come to me to fix things for them. "XY failed, contact the system administrator" - yeah, I'm the system administrator. So please tell me more than "cross your fingers and try to reboot". I'm the guy that knows how things work. If I can no longer be that guy I become just next useless idiot.

You can move service files to other filesystems, but then you need to tell the service config that you did this so that it can bring up that filesystem before starting the service. This is actually a lot easier to do with systemd than with sysV.

Correct me if I'm wrong, but if all filesystems are mounted early, then it does not matter where you have moved the service. How can it be easier than that?

Re:what's wrong with systemd

[Ddalex]

You have a pretty good argument about SystemD here, and I want to use it to highlight why I consider systemD especially bad, as software goes.

- It breaks expectations of experienced Unix/Linux users. Where somebody was accustomed to interact with the system a certain way, e.g. having console logging and log files available to cat/grep/etc, systemD changes that. Programs should be designed for human usage - if it breaks already established human interfaces, it drives up the learning curve, and that is bad. We are overstressed with too much information as it is.

- Non-deterministic. If reordering the startup daemons breaks the system, systemD is at fault. You're saying that it's my fault for having broken systemD configuration. I want to remind you that a program should help me out, not raise barriers for me. If I write a configuration, test it, verifies that it works, and then two weeks later it refuses to work, nothing changed, this is horrible design - how was I even supposed to know it will break ? When I test a program, get to run through inputs and verify the results, I don't want unexpected surprises with the program changing behaviour without me telling it to do so.

I'm not going into technical merits here. I am talking as a human interacting with a machine - the behaviour of the systemD-driven machine is horrible.

Would you even drive a car that randomly speeds up a bit before breaking when you hit the breaks, because it thought it would get me a bit faster to my destination ? KISS is a principle because experience shows that simpler things work better.

Re:what's wrong with systemd

[Rutulian]

I'm not arguing it has to be syslog format, just text.

No argument from me there. I don't really understand the rationale of the binary log, so hopefully that will change in the future.

...until you don't GET the log because it wasn't *WRITTEN*,

In these situations you typically redirect the logs to a remote server, something that journald is supposed to be able to do very easily (I've haven't tried to do this yet). But I get your point. The problem with having only the console log, which was the case with most of the init scripts, is that you often don't have a console, or the console output is too long catch the error message. So the permanent log is a better place to put important messages. But I agree it is more convenient to have the console log as well as the permanent log in certain situations. Apparently this can be done with journald. Maybe it's worth a try.
http://log.or.cz/?p=327

Because sometimes it's a lot nicer to try to reproduce the failure right then and not have to reboot the system in order to get to the log.

Agreed. Thankfully this is actually possible with systemd.
http://freedesktop.org/wiki/So...

How easy it is will depend on where the boot process failed, but it is possible to get to an emergency console in nearly every situation without rebooting.

don't *PREFER* an order, sometimes I *REQUIRE* an order.

Yes, you can require an order. But there is a difference between requiring a service (ex: apache requires net and syslog) and requiring an order (ex: net will probably come up first, but apache doesn't strictly require it to). If you do need a specific order, for example a service that requires a network filesystem to be mounted to get its config files, you use the Require combined with the Before or After directives.
http://www.freedesktop.org/sof...

In SysV, almost *nothing* happened before filesystems,

The thing is, not all filesystems can or need to be mounted at the same time, and this is not possible to encode within /etc/fstab. The hack to do this with sysV was to add the _netfs option to your mount to tell the mount command to wait until it thinks the network is up, which only worked maybe 50% of the time. If you think mounting root over nfs is fun, try a service that starts a service that is dependent on the availability of an iscsi target.

I've always hated the "let's make it complicated and blame the user if they can't figure it out" philosophy.

That's the thing, though. It really isn't any more complicated than modprobe.d or pam.d or if-*.d or any of the other config systems that compose a typical modern linux system. It is just new, and will probably require some reading of the docs. But it doesn't take hours. For most, it takes about 10-20 minutes to figure out how to do something you need to do with systemd.

I've gained *no* capability that I didn't already have

I think that's the problem. Too many people have a "works for me" mentality and don't acknowledge the possibly complex needs of other users. Ultimately, linux aspires to be as useful to as many people as possible, not only to the people who have succesfully used it up to now.

Re:what's wrong with systemd

[Rutulian]

If systemd does badly something it is designed to fix

Understand the difference between "doing something badly" and being misconfigured. Nothing can work well if it hasn't been configured properly.

On a serious note: never tell me that I don't need to know how things work.

I didn't say that. You absolutely should know how systemd works. But that doesn't mean you will necessarily know the precise order in which things will start. Systemd has been designed to allow you to specify preferences and requirements, so that you don't have to specify order.

Correct me if I'm wrong, but if all filesystems are mounted early, then it does not matter where you have moved the service. How can it be easier than that?

When you can't mount all filesystems early, this doesn't work.

Re:what's wrong with systemd

[Rutulian]

- It breaks expectations of experienced Unix/Linux users.

I disagree. First of all because there is no reason to disregard something just because it acts a bit differently. Second, it is not as different from standard unix ways as people are determined to think. It is different from sysV, but even sysV was different from other competing systems at the time it was introduced. Not having console logging would be a serious shortcoming if it were true. Thankfully, logging is quite configurable and you can get almost anything you want from journald.

- Non-deterministic.

I would need some more information before I could conclude that it is non-deterministic. The only information I have at this point is "something stopped working." The cause can be any number of things which might be the fault of systemd or might not.

KISS is a principle because experience shows that simpler things work better.

A lot of people have been saying sysV is simpler with pretty much nothing to back it up. Systemd is not that complicated.
http://0pointer.de/blog/projec...

Re:what's wrong with systemd

[Rutulian]

Uh, they did actually. Each of those things was managed by an init script. They didn't just manage themselves.

The old shell scripts never yanked away system logs

This hasn't been done.

stole core dumps from out of your crashed program

This is actually quite useful.

forced system demons to be changed to conform to "the new way of doing things"

System daemons don't have to change, init scripts do.

Nice post. Complete FUD.

Re:what's wrong with systemd

[Rutulian]

Look mate, anything new is going to require some effort to learn how it works. The only point I am trying to make is that it isn't really that hard, and for an app developer it should be trivial. Read the docs, learn how it works. That is all.

just because they're complaints YOU won't ever make (because you're the equivalent to a plumber with years of experience) does not invalidate their legitimacy.

It's funny you say that because I'm not. I'm just a guy who has read the docs and done some googling. To me, systemd is a heck of a lot easier to understand than GNU make.

Re:what's wrong with systemd

[Rutulian]

Being difficult to understand is a definition of complicated.

Before you can claim that something is difficult to understand you first have to make an effort to understand it.

Systemd is openly trying to do pretty much 'everything' at startup instead of having multiple things that do one thing well working together.

It isn't really. Saying that "Systemd is mounting my filesystem, and bringing up the network, and setting my timezone" is functionally no different than saying "My collection of sysV init scripts are mounting my filesystem, bringing up the network, and setting my timezone."

Yes, trading bash scripts for a large blob of binary code that interprets another layer of text scripts is much less complicated, If you're just comparing the bash scripts to the large binary blob's scripts.

Some excellent sophistry there.

Re:what's wrong with systemd

[BadDreamer]

"First of all, each script is code."

That is a feature, not a bug. I *want* my scripts to be code. That is why they are scripts-

"Second, no script is aware of any other scripts presence"

That is a feature, not a bug. The UNIX way is to do one thing, and do it well. That is how the init scripts should be constructed. Anything else is a failure in design.

"Third, a typical shell script is >100 lines of block logic to implement the equivalent of "service start"."

Which is perfectly fine, as the parameters (if any are needed) are gathered at the top, easy to find and commented. But usually none are needed as they are in the config file for the service.

Thus, these arguments are either neutral or work against systemd. None show systemd to be in any way better. It's a monolithic lump which has no place in a UNIX style system.

Re:what's wrong with systemd

[Rutulian]

I *want* my scripts to be code.

Fine, until you want some basic security in your init process.

The UNIX way is to do one thing, and do it well.

If the scripts didn't need to cooperate to accomplish a task, you might have a point. But they do, which is why sysV init is broken.

Which is perfectly fine, as the parameters (if any are needed) are gathered at the top,

Uh, I don't know how you can think that rewriting the same 100 lines of code to do the same basic thing (but a little differently because everybody writes it differently) in 100 different scripts is a good engineering practice.

It's a monolithic lump

It is not, which you would know if you had bothered to gain even the most basic understanding of what systemd is and how it works.

Re:what's wrong with systemd

[BadDreamer]

I have basic security in my init process, and my init scripts work fine on their own and serialized. I reboot a few times a year, so a few seconds saved on parallelizing that (which is the only time they would need to co-operate) is NOT worth throwing a huge API laden lump into my system.

And systemd is a monolithic lump by design. It's a swathe of API's, which is the Windows way and has nothing to do with the UNIX way. It's an abomination which does not belong.

Re:what's wrong with systemd

[BadDreamer]

To further belabor the point, Debian's argumentation for systemd shows exactly what is wrong with systemd and how it is a monolithic lump of functionality which does not belong together.

https://wiki.debian.org/Debate...

Quote:
"Systemd is not just init. It unifies, in fewer lines of code, everything that is related to starting services and managing session groups: user login, cron jobs, network services (inetd), virtual TTY management"

Just because scope creep and feature creep leads to fewer lines of code does not make it good engineering. On the contrary, mashing together functionality leads to hard to detect bugs, race conditions and needless complexity and interdependence.

And that is precisely the problem with the monolithic and API based approach of systemd. It becomes fragile and version dependent, which is not what init should be.

Re: what's wrong with systemd

[Rutulian]

We've really entered bizarro-land in this discussion now that communicating over dbus has been declared wrong because it is the "Windows-way", whatever that means. Dbus is just IPC, that is all.

How about instead of misinterpreting what somebody said on a discussion forum on an unrelated matter, you read what the actual architect of systemd says.

Myth: systemd is monolithic.

If you build systemd with all configuration options enabled you will build 69 individual binaries. These binaries all serve different tasks, and are neatly separated for a number of reasons. For example, we designed systemd with security in mind, hence most daemons run at minimal privileges (using kernel capabilities, for example) and are responsible for very specific tasks only, to minimize their security surface and impact. Also, systemd parallelizes the boot more than any prior solution. This parallization happens by running more processes in parallel. Thus it is essential that systemd is nicely split up into many binaries and thus processes. In fact, many of these binaries[1] are separated out so nicely, that they are very useful outside of systemd, too.

A package involving 69 individual binaries can hardly be called monolithic. What is different from prior solutions however, is that we ship more components in a single tarball, and maintain them upstream in a single repository with a unified release cycle.

Myth: systemd is not modular.

Not true at all. At compile time you have a number of configure switches to select what you want to build, and what not. And we document how you can select in even more detail what you need, going beyond our configure switches.

This modularity is not totally unlike the one of the Linux kernel, where you can select many features individually at compile time. If the kernel is modular enough for you then systemd should be pretty close, too.

There are more of those here,
http://0pointer.de/blog/projec...

Re: what's wrong with systemd

[BadDreamer]

What makes systemd monolithic is not related to the number of binaries it creates, but that it is API based and contains everything but the kitchen sink. It does not do one thing well; it does a little of everything passably.

And the kernel is an excellent example of what systemd is not; the kernel is not an API based block of functionality. That is the core problem with systemd. It is built like Windows is, not like UNIX and POSIX is.

Your quotes reinforce that fact. It is not an assembly of tools which each do one thing well, but a lump of stuff.

And they can't even keep from bragging about boot speed improvements even in this answer. These guys have a huge ego problem.

Re: what's wrong with systemd

[Arker]

I think you two speak past each other several places.

It's not monolithic in the sense you are using it, it is modular in construction. But it's monolithic in the sense that the collection of modules work together more intimately than they should, and in fact *change* together in ways that quite explicitly discard compatibility. The entire design of not just the init system and PID1 but also of an expanding grab-bag of unrelated system components all get redesigned in ways that are not particularly sane.

It's not about parallel process startup - you can easily do that in the existing system, with OpenRC for instance among many options.

It's certainly not about boot times - I can make a system boot in milliseconds if I need to, that's *easy*.

It's about replacing a stable, mature, and robust standardised modular design with a new design that is vendor-specific and can make and break the rules whenever this is thought necessary to the benefit of corporate strategy.

Which, you know, if RedHat guys really think this is the way to make their stock options rise then more power to them. I think they are wrong, and I think Canonical are just as wrong cause their strategy is the same. I think this path will backfire on them and their forks will collapse in time. But they have every right to try it if they disagree.

But why Debian is falling prey to it? That's the part that sucks.

I really don't see what is the problem here

[Anonymous Coward]

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.

Re:I really don't see what is the problem here

[Anonymous Coward]

Oh and I have to add: I'm also saying goodbye to most redhatisms like NetworkManager, *kits, and pulseaudio. Gnome went to the toilet since the gnome3 debacle. The fact that everyone loves to quack insanity shouldn't instill feelings of desperation my friend. Things come and go, including all the sillyness around the linux ecosystem in the last years.

I've been toying with rolling my own distro

[bferrell]

I've also been considered insane from time to time.

What I want:

1.) rpm/zypper/yum based package management. This allows rpm dependency resolution and installed package verification by the package manager.
2.) SysV init. It's clean and it "just" works.

I think those two are a good start. Being able to use an established automated build system is probably a good idea too.

    Any other thoughts?

Re:I've been toying with rolling my own distro

[shutdown -p now]

What's improper about the FreeBSD package manager?

Re:I've been toying with rolling my own distro

[epyT-R]

Might as well use gentoo or slack.

Re:I've been toying with rolling my own distro

[Arker]

"Any other thoughts?"

I think you should set your sights a little higher than that. RPM and SysV init are both overly complicated - what you are saying is that poison is ok with you in principle, just not quite so fast please.

Re:I've been toying with rolling my own distro

[Fweeky]

pkgng's still missing the ability to track certain changes automatically, so you occasionally have to force-remove a package or manually change an origin as per /usr/ports/UPDATING. I think they're expecting to resolve that in 1.3 fairly soon.

I've been using it for about 18 months across a small group of machines with about 1400 packages between them, and it's pretty much entirely demolished any apt-envy I've had.

Re:I've been toying with rolling my own distro

[bferrell]

I started in '93 with Yggdrasil and slack. Ygg was a non-starter. slack is OK, but difficult to deal with even if I do like like and admire Patrick

Re:I've been toying with rolling my own distro

[bferrell]

... and the idea that they are pure poison is why I want away from distro packagers who think that way.

As any decent toxicologist will tell you, the poison is in the dose.

Re:I've been toying with rolling my own distro

[myowntrueself]

I've also been considered insane from time to time.

What I want:

1.) rpm/zypper/yum based package management. This allows rpm dependency resolution and installed package verification by the package manager.
2.) SysV init. It's clean and it "just" works.

I think those two are a good start. Being able to use an established automated build system is probably a good idea too.

    Any other thoughts?

What I want is a distro with the huge array of available packages and well-testedness of Debian but using Yum/RPM instead of apt/deb.

CentOS is not an option due to severely limited availability of packages and, no, the third party repos are not an option as they are nowhere near as rigorously tested as Debian before going into the stable release (of course with the CentOS 3rd party repos (epel, rpmforge etc etc) there is no 'stable' release its just a gigantic mess). But Yum/RPM is just a much better package management system than apt/deb.

This distro would also pledge to stick with sysvinit.

I also want this RPM based distro to support in place release upgrades like Debian is unlike the CentOS philosophy of 'reformat and rebuild with the new release).

Re:I've been toying with rolling my own distro

[Dogers]

Does it have anything along the lines of yum verify (http://bencane.com/2013/12/23/yum-plugins-verifying-packages-and-configurations-with-yum-verify/) or yum history (http://www.cyberciti.biz/faq/yum-history-command/)?

Genuine question! Last time I properly used FreeBSD I don't think pkg_add even existed? Have downloaded the 10-current ISO and will give it a try in a VM over the weekend..

Re:I've been toying with rolling my own distro

[bferrell]

Amen!

zypper and the tumbleweed repository in opensuse offers this, but then I'm stuck with systemd madness

Re:launchd

[nctritech]

And all of them are inferior versions of sysvinit. ;)

Why do distros so often change the way they init?

[ZorinLynx]

It feels like every few years, distros switch to a new way of doing things.

Why not just improve on whatever the current way is, and evolve it into the perfect init, rather than switch to an entirely new system so often? It annoys current sysadmins who have to learn new software for no good reason, it introduces bugs that make systems less stable, and it further breaks/fragments compatibility between distros.

BSDs and systemd

[Anonymous Coward]

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.

None of the BSDs, not even FreeBSD, will use systemd.

FreeBSD has incorporated NetBSD's rc.d system, and they'll be going with that for the forseeable future:

https://www.freebsd.org/doc/en/articles/rc-scripting/index.html

Privilege to start a service

[tepples]

(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 letting the network driver demand-start when a program that uses the network is started? Linus Torvalds wrote in this post: "And today Daniela calls me from school, because she can't add the school printer without the admin password. Whoever moron thought that it's "good security" to require the root password for everyday things like this is mentally diseased."

Re:Privilege to start a service

[Cramer]

Sure, point out a thing that's been auto-loading (kernel modules) much longer than systemD has been dreamed of. Network configuration -- even wireless -- has been user configurable by various packages for ages. (Linus' rant aside.) You'd want the network running LONG before any app is started that needs it, or do you enjoy having a 15s delay before chrome can be used; every time you start chrome? (btw, practically everything uses the network these days.)

Linus was referring to the insanity of "security" today. Anything that can add a driver (eg. in windows or macos, adding a printer will add a driver) is an "unsafe" operation -- and rightly so, as too many bits of crap piggyback their way into systems this way. And no, Linus, adding a printer is not "an everyday task." The last time I added a printer was after re-imaging a workstation for a new hire at work. That was 2 months ago.

Re:Privilege to start a service

[sjames]

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.

Re:Privilege to start a service

[segedunum]

But then you have to provide some way for the system to decide which USER is allowed to "f***ing start" each service.

No I don't, and never have done.

Re:Privilege to start a service

[tepples]

And no, Linus, adding a printer is not "an everyday task."

You don't know college. A student is likely to be close to five different printers in a day.

Re:Privilege to start a service

[Cramer]

This is bullshit. You don't (read: should not have to) add every printer you happen to be standing next to -- which could accumulate to hundreds of printers. There are NUMEROUS technologies to allow printing to locally available printers, through a single system-wide printer. On my previous laptop (granted, that's windows...) I had a single "internet printer" loaded for printing to hotel printers. One system printer, one driver, and I can print to any customer facing printer in any Hilton on the planet. Today, it's called "Cloud Printing".

Re:Privilege to start a service

[fnj]

For workstations, especially portable ones, shorter boot time is a marketing bullet point that differentiates one system producer from another.

Actual "workstations" are never turned off. Therefore elapsed boot time is a complete non issue. Notebooks are another thing entirely. Notebooks are critically wounded computers. Computers with a display that is much too small, a toy keyboard, and a power source that is constantly failing; that has to be watched like a hawk from the moment you turn item on because it runs down like a cheap music box until you wind it up again. OK, they are highly useful, even indispensible, for scenarios when you can't use the real thing, but they should hardly affect the design of an operating system for real computers.

Anyway, notebooks are not so much turned off either as they are suspended or hibernated. Parenthetically that introduces its own set of issues; ones that systemd is arguably very useful in addressing; but that has nothing to do with elapsed boot time.

Finally, elapsed boot time is the LEAST reason to switch to systemd. There are enormously significant ambitious features of systemd that are much more important to a decision whether to use it.

Re:Privilege to start a service

[sylvandb]

And no, Linus, adding a printer is not "an everyday task."

You don't know college. A student is likely to be close to five different printers in a day.

And if you are "close to five different printers in a day" why would you want to add them to your system? There is no need to "add" a printer in order to print to it. The only reason to "add" a printer is if you regularly print to the same one.

Thinking you need to "add" every printer near you is a broken mindset spawned by Windows.

Re:Privilege to start a service

[rastos1]

or do you enjoy having a 15s delay before chrome can be used; every time you start chrome?

Are you running it on Raspberry PI?

Re:Privilege to start a service

[Cramer]

IPv4 DHCP can take from 3 to 15s to setup. And waiting for IPv6 initialization on a network with no IPv6 adds to that. I suppose you've never paid any attention to how long network startup takes from any distro installer -- or during normal boot. If it's not a static configuration, it'll take a real, measurable, annoying amount of time to bring up.

Do you have an android device that turns off the wifi when not "on"? It takes a annoying amount of time for that to setup before any network apps can work. (and then 27 background apps attempt to sync at the same time.)

Re:Privilege to start a service

[tepples]

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.

In theory, that can be done with sudo too. But a lot of distributions have chosen to go with PolicyKit, and the maintainer of PolicyKit has chosen to go with either systemd or consolekit (which has been declared obsolete in favor of part of systemd).

build wrappers

[allo]

stuff like journalctl is just PITA, but there will be convenient wrappers. The best solution at the moment: install rsyslog and it will log stuff from the systemd journal to normal logfiles.

Viper-mode

[tepples]

But that wording of the joke's been obsolete since the introduction of the "viper-mode" editor package for Emacs.

rc.local

[hierofalcon]

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).

Build your own Distro

[allo]

http://rocklinux.net/

Re:Build your own Distro

[bferrell]

Now to dig in!

Re:Build your own Distro

[dbc]

ummm. really? From the looks of the datestamps on their web pages, it hasn't been touched in years.

Re:Build your own Distro

[allo]

its opensource, and i guess the tools are okay. You will need to update it for newer package versions.

Re:Why do distros so often change the way they ini

[amorsen]

You cannot really make a system that consists of a bunch of shell scripts and have it work for a modern laptop where devices and network connections come and go, and you really want different things to run depending on whether you are at home or on the unencrypted airport wifi.

SysV init needed replacing. It is just unfortunate that the replacement is systemd.

Anyway, I should really stop complaining about systemd, I gave up Linux on the laptop last year and now I am on OS X.

Re:gummiboot

[Richy_T]

I have an EFI system and I'm thinking of moving back to LILO. It's not the fault of the boot managers, it's that if I happen to try and boot without the hard-drive plugged in, the motherboard forgets the hard drive from whatever table it's in and it will no longer boot (though the hard-drive itself is detected fine). This is with a fairly modern motherboard. Back to legacy boot until it matures a little, I guess.

Slowly building up to Finit

[troglobit]

A couple of years back I adopted http://troglobit.com/finit.htm... for our embedded software at Work. I've since expanded upon it quite a bit and slowly made it a viable alternative. It's very small, boots quickly without sacrificing dependencys, but currently not really something that can compete with the functionality that systemd aspires to or upstart tried to be, but with the Debian vote I'm seriously starting to consider expanding upon it and adding all the missing features to be able to use it on my desktops and servers as well. After all, despite PID 0 being black magic, it's really not that difficult.

Do we need to change the name?

[Anonymous Coward]

Should we now start calling the operating system GNU/systemd/Linux?

Practical alternatives

[rl117]

I've moved most of my systems to FreeBSD. And no-so-coincidental to this post, today I set up my first Debian GNU/kFreeBSD jail system. Works perfectly. Install debootstrap from ports, create ZFS volume, debootstrap onto the volume, configure and start jail. Done. (Works fine on the bare metal, too.)

(Sad to say this since I've been a Debian developer for over a decade, but I doubt I'll be using jessie in any serious capacity except perhaps for kFreeBSD if they don't manage to screw it over as well. I despair at what's happened to the major Linux distributions over the last few years. No longer feels like home, and the years of pushy passive-aggressive behaviour and acrimony which led to it being adopted completely killed my last bit of enthusiasm. I spend all my free time working on Debian.... for this? Giving the BSDs a try for the first time in a long long time, was like a breath of fresh air.)

Re:Practical alternatives

[Arker]

You might should look at Slackware, you could get the best features of the BSDs and Linux combined. And it would be a real shame for an experienced developer to give up at this point - we need you!

NetworkMangler "user friendly"?

[seebs]

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".

Re: We'll keep on trucking without systemd garbage

[xiando]

> How long until all of the software packages that BSD wants to use require so much work to retrofit to use a different init mechanism that they just throw in the towl and accept defeat?

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: Yep, Gentoo IS superiour

[xiando]

And this is why we love Gentoo. Also, it does not use systemd. :)

Re:Why do distros so often change the way they ini

[Billly Gates]

It feels like every few years, distros switch to a new way of doing things.

Why not just improve on whatever the current way is, and evolve it into the perfect init, rather than switch to an entirely new system so often? It annoys current sysadmins who have to learn new software for no good reason, it introduces bugs that make systems less stable, and it further breaks/fragments compatibility between distros.

Because things have changed since the early 1980s. Example lets say you have at work on a network. You close the lid and travel overseas and open it again on the hotels network when it wakes up. How do you write an inet to deal with dynamic changes like this?

Also in the early 80's you only had 25 text based utilities and apps on a unix server. It was not complicated to do things. A modern linux distro has how many apps, daemons, dependencies, etc. Now image the above scenario with a laptop waking up on a different network thinking of all the complexities of a modern distro?

An event driven system makes sense. You can program your system to make changes based on conditions and scenarios that pop up. Network trunk gets hit high? No problem I can setup the event driven systemd to page me and run some packet shaping. Hacking attempt? No problem send an alert and sandbox processes etc.

Sun and Apple have all moved away from inet to event based systems as well.

Re:launchd

[Guy Harris]

systemd is just an inferior version of launchd.

.c and .h files in top-of-trunk systemd as of a "git pull" done a minute or so ago:

$ find . -name '*.[ch]' -print | xargs wc -l | tail -1
252223 total

.c and .h files in launchd-842.90.1, which opensource.apple.com claims is what's in OS X 10.9.2 (did they just release 10.9.2?):

$ find . -name '*.[ch]' -print | xargs wc -l | tail -1
26790 total

Yes, that's almost a factor of 10.

Re:launchd

[Guy Harris]

I suspect that the people responsible for systemd never even thought to look at already-existing alternatives

Poettering was most definitely aware of launchd.

Re:launchd

[ls671]

And... What is your point?

Re:launchd

[Guy Harris]

And... What is your point?

To ask what benefits the additional almost-9x code brings (especially if the result is deemed inferior)?

Easy workaround

[manu0601]

I was using NetBSD, which has no plan to import systemd, I will carry on.

Remember Linus' explosion

[PJAJr]

Now wait, didn't Linus himself refuse to let systemd become a kernel dependency? I think the poster has a point. I've used systemd on Arch linux and there's a lot not to like about it and not that much to like about it. I'm a linux newbie as well, so I don't have any particular previous init experience. And doesn't kernel modesetting sort of obviate the need for a complex init?

Re:Remember Linus' explosion

[Arker]

Yes, linus shot that down for now although I would have been happier if he had done it earlier and more strongly. And yes, despite all the fanbois that are absolutely convinced they NEED misfeatures like socket activation, Slackware and Gentoo both have much better systems in place that seem to work just fine as far as I can tell.

Re:"With SysV init, unless I turned on some weird

[gonnagetya]

Bullshit. Sometimes you need to restart servers, and occasionally there's an issue during regular use that will require a restart to clear out. I would argue that servers would have a greater need than most of having rapid boot times to ensure that any unexpected downtime is as short as possible. But I guess I'm the lone voice of reason here.

Condemned.

[AJWM]

As the legendary Henry Spencer said, "Those who do not understand Unix are condemned to reinvent it, poorly."

Clearly the folks behind systemd do not understand Unix.

Re:Plenty

[Arker]

Linux is just fine actually, it's only certain distros are continuing to break themselves.

Re:Why do distros so often change the way they ini

[Arker]

"You cannot really make a system that consists of a bunch of shell scripts and have it work for a modern laptop where devices and network connections come and go, and you really want different things to run depending on whether you are at home or on the unencrypted airport wifi."

Sure you can. Try slackware ffs.

"SysV init needed replacing. It is just unfortunate that the replacement is systemd."

SysV init was a step in the wrong direction, systemd is a giant leap further down that road. But there are plenty of other good init systems. Slackware and Gentoo work just fine without either of them, and so do the BSDs.

Re:"With SysV init, unless I turned on some weird

[Arker]

Bullshit yourself. The ONLY reason a properly configured production linux box being competently administered is going to reboot is a critical kernel patch or hardware failure. Period, end of story.

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.

Re:launchd

[Arker]

"To ask what benefits the additional almost-9x code brings (especially if the result is deemed inferior)?"

Guess what? A larger program is not necessarily better. The opposite is more likely to be true, in fact. A good designer knows that the job isnt finished when there is nothing left to add, it's finished when there is nothing left to remove.

Unfortunately we live in a world filled with so many poor designers that it's easy to forget that a good design is even possible. :(

Re:launchd

[Arker]

From your link:

"As mentioned, the central responsibility of an init system is to bring up userspace. And a good init system does that fast. Unfortunately, the traditional SysV init system was not particularly fast."

This is the false postulate on which the entire thing is built. This guy thinks that the most important thing about an init system is how quickly it executes, and that is so fundamentally wrong I find myself wondering how the hell the author got himself a job he is clearly completely unqualified for. Does he imagine that all we linux users do with our systems is sit there with a stopwatch rebooting? Was he dropped on his head as a child? Inquiring minds want to know.

The most important things about an init system are that it accomplishes its task correctly, and that the configuration is human readable and easily edited with the most basic tools. The speed of startup is literally the least important thing about it - just one step up from does not matter at all. If you could speed my boot up to the point it was instantaneous, but the cost is a marginally less reliable system, it would be a very poor trade.

On a server your mean time between reboots should be around a year, but on a personal system you might shut down each night and restart in the morning, so let's assume that case, the best possible case for systemd. You will save, what, 5 seconds? Maybe 7 seconds if you are very very lucky. It takes me longer than that to walk to the fridge, get a drink, and walk back to my desk, which time I will be taking whether the system is ready more quickly or not. So it represents literally 0 possible advantage.

Re:Yes there is.

[sjames]

And yet, it has been working for decades without systemd.

Just poll/wait for the needed conditions when necessary and kindly keep your grubby fingers out of my pie.

Then what happens if I choose something other than systemd? It all just works anyway, that's what. If I wanted dependency hell, I'd install Windows 95 and have fun with DLLs again.

Re: We'll keep on trucking without systemd garbage

[systemDead]

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).

But besides Gentoo, are there any other major GNU/Linux distros not planning to adopt systemd? From what I've read, Slackware is just holding out until the last minute. Among the BSDs, FreeBSD has the greatest number of packages. The only thing I don't like is the fiendish mascot.

Re:launchd

[systemDead]

I suspect that the people responsible for systemd never even thought to look at already-existing alternatives

Poettering was most definitely aware of launchd.

Is this really Lennart Poettering's blog? I find the part where he describes the Solaris init quite ironic.

There are other init systems besides sysvinit, Upstart and launchd. Most of them offer little substantial more than Upstart or sysvinit. The most interesting other contender is Solaris SMF, which supports proper dependencies between services. However, in many ways it is overly complex and, let's say, a bit academic with its excessive use of XML and new terminology for known things. It is also closely bound to Solaris specific features such as the contract system.

Just change Solaris to Linux and "in many ways it is overly complex" and "closely bound to Solaris specific features" sounds like an apt description of systemd.

Re:"With SysV init, unless I turned on some weird

[fgodfrey]

Partially guilty. I certainly believe that a 2 minute boot time is acceptable *to me*, but I'm not irritated by people who want fast boot. I'm irritated that their zeal for fast boot resulted in an extremely poorly engineered piece of software that breaks the ability of some of my machines to boot *at all*.

Re:"With SysV init, unless I turned on some weird

[fgodfrey]

What server do you have that makes it through the BIOS so fast that the difference between systemd and SysV is meaningful?

And if your server is so critical that the ~2 minute difference (on a good day) in boot times is a serious business issue, you should really consider running redundant servers anyway since there are a variety of other failures that a fast boot time isn't going to help....

This is a thing on linux in general

[Anonymous Coward]

I have noticed something about linux in general. You know how when you first started using linux, and all the old guys insisted that you call it GNU/Linux, and you thought "yeah, I don't f*ing care?" Well it turns out that they had a point, although it was somewhat obscure. Linux, more than any other unix (well, many of them), leans VERY heavily on it's userland. Try to build Linux without gcc. It's not possible, even though in most areas LLVM/clang is ahead of gcc, gcc is ingrown, and linux depends on nonstandard gcc extensions. There's other examples. Some graphical programs expect an xterm, even though xterm is horribly broken and screwed, because xterm is the standard, so they don't support REAL standards, they support xterm. I think kernel mode setting, though it should actually be a good thing for linux graphics is a fairly major change in X11 which again distances the BSDs. systemd is just the latest and the worst of a long line of insults that linux has been hurling at unix (the idea, not any particular OS).

Now that my whiny little rant is done, I will go ahead and mention the following distros as high quality/minimalist:
slackware
crux

For good ideas on what makes good/bad software check out suckless.org and harmful.cat-v.com (I am in no way affiliated with them, and admit that in many cases they overstate the case. But when you're the minority, you'll ally with anyone.).

In my totally elitist opinion, the problem with software these days is complexity. Anything that you can do to boil software down into a simpler, more logical system is an improvement, if you're not a passive user checking your email and playing flash games.

I am well aware that my opinions are totally unpopular and that most people would rather use systemd as "good enough," or even "better." I don't care if you use systemd, but please do not force your crap on the rest of us. That is not what open source is about. I can and will find a way to circumvent your trash.

EUDEV!

Re:Why do distros so often change the way they ini

[sylvandb]

Billy, three suggestions:

Quit calling it "inet" when you mean "init".

None of what you mention has anything to do with inet or init and so my laptops have done very well in your scenarios using the traditional sysvinit and now with upstart.

If you want to sell systemd, figure out what it does that was not done before, not just what was not done before by init.

Re: We'll keep on trucking without systemd garbage

[linuxrocks123]

Where have you read that Slackware is going with systemd? If they do, I may switch to Gentoo. My previous experience with Gentoo was less than positive, but, then, I was using SPARC...

Migrate to BSD

[Anonymous Coward]

After being left unimpressed with how systemd has been forced upon us by all the major distros, I've now migrated to FreeBSD and loving it. I don't know why I didn't switch years ago! :-)

The choice of installing stuff via binary packages with "pkg" or building via the extensive "ports" collection is refreshing!

Pulse audio has some serious issues...

[bwalzer]

I love PA. I have been using it for network audio since it was called Polypro audio. Having said that, it still isn't finished and maintenance has more or less been abandoned. I recently gave up trying to use it for my media computer. I got tired of living with a 5 year old bug.

I think the problem with Pulseaudio is that it is too monolithic. There is just too much logic stuffed into one place for a good long term open source project. Once the original people lost interest it became too hard to understand for those that just wanted to fix bugs. At this point someone is going to have to devote a significant hunk of their life if the hard bugs are ever to be fixed. Pulseaudio should of stuck to what it did best: network audio...

Re:launchd

[Guy Harris]

Fine, less code, less bugs... +1 for launchd

Yes, that was precisely my point - does all the extra code make systemd almost 10x better than launchd, or is it better but not by as much, or is it no better or even worse?

Get off of my lawn!

[chuckw]

Every new thing will have a group of people who insist that it is the devil. Maybe it is, and good for them for saying something. Too bad no one is listening to them.

But then again, maybe some people just hate change...

Systemd was built for a reason, maybe a bad one, but a line of thinking went into it. Booting is not a simple thing, despite what you would like to think, and it could be made better.

One thing is for sure though, OSS is not going to stand still, and IMHO, that is a damn good thing...

Hostfiles have their place.

[mmell]

I see you've actually written quite a bit of software, some of it quite good. Too bad you're suffering schizophrenia. Are you this guy? The Start64 malware site shows the following:

Company: Panisz Peter

Address: Kossuth Lajos u. 51 Dunabogdany 2023 HU

Phone: +36.203367173

Fax: +36.203367173

But I think he's living at his mother Jan Kowalski's basement at:

Alexander Peter Kowalski

903 East Division Street

Syracuse, N.Y. 13208

Apartment #1, Lower Level

At least, that's where he wants users of his hostfile manager to send him money.

Re: We'll keep on trucking without systemd garbage

[Arker]

"From what I've read, Slackware is just holding out until the last minute. "

Pure FUD. Slackware does not ship PAM, it does not ship GNOME, it uses EUDEV, if anything it's even less likely than Gentoo to adopt systemd since it's already an option for the tuners that sit there with a stop watch rebooting and compiling all day.

But Slack Gentoo and OpenBSD, at the least, are going to continue doing what they have done so far. Implementing specific features that turn out to be useful enough to start being adopted by useful programs, but individually and without unnecessary breakage to the *nix design.

Re: PolicyKit

[BobbyWang]

It would be very easy to modify PolicyKit to automatically choose between systemd and ConsoleKit at runtime (of course I read the source to draw that conclusion). The reason PolicyKit needs systemd or ConsoleKit, by the way, is simply to find out if a (logged in) user is local and active (the default policy is to only let local active users mount an USB-drive for example). If someone invents another way to find out if a user is local and active, support for that could be added to PolicyKit as well.

Re: PolicyKit

[Anrego]

I'll admit I have not looked at the code, but the problem I would anticipate is needing both as a dependency at compile time, unless it can be dynamically loaded or is all done via external calls.

Re: PolicyKit

[BobbyWang]

ConsoleKit is no compile time dependency (it's interface is DBus and a bunch of files in /var). The systemd library in question (libsystemd-login) would be required even at runtime (but not require systemd to actually run), at least with the current implementation. (Perhaps the library is just a wrapper around a DBus interface, I haven't looked into that.) Another, slightly more complicated, way of doing it would be to have loadable modules for PolicyKit. I would love to see the javascript-part go into a kind add on loadable module since it's adds a lot of overhead and isn't even needed at all in the common case (it's only for "System Administrators [and] Special-purpose Operating Systems / Environments and those audiences only" according to the documentation). But I wouldn't be surprised if PolicyKit gets moved into systemd instead (the way it's written it would be an easy thing do do).

Re:launchd

[BadDreamer]

And that is exactly the problem with systemd, and why it is an inferior version of launchd.