Will they have the same attitude as the ConsoleKit/PolicyKit/_Kit people have when someone says, "I need to do something different, but this service is preventing me from doing it?" As an example, I want to set up my system so that one user can play audio even when a different user is "active," yet after hours reading through bug reports about that and mailing list archives, all I could find where these responses:
* "Not our fault, it's that other service."
* "We are never going to support that. You don't want it anyway."
* "Well that will be fixed with systemd"
* "You can add the user to the audio group, but that's wrong and you should not do it. You should instead do that thing that the other guys are telling you not to do and that they will never support."
* "This will be fixed with systemd!"
So, I guess now the question is, when someone comes along and says, "I need to do X, I used to be able to do X before systemd was in use and now systemd is stopping me, how can I fixed that?" will systemd maintainers respond with things like the above? Will there be useful and thorough documentation, so that users can fix things without having to bug the maintainers?
> systemd being Linux-only is not nice to the BSDs.
>Completely wrong. The BSD folks are pretty much uninterested in systemd. If systemd was portable, this would change nothing, they still wouldn't adopt it
systemd is not portable, it wasn't made to be portable, it relies on far too many linuxisms. Therefore the BSD's don't care about it. It is not 'the BSD's don't care about it so we didn't make it portable.'
The BSD folks may not be interested in systemd itself, we are still interested in running various bits and pieces of software on top of the platform. When software starts requiring systemd just to run we have no chance what so ever at porting that software.
The same is true for a lot of Linuxisms. I have spent an awful lot of time getting software that states on the tin it is written for POSIX to run on BSD because its source code uses all kinds of Linuxisms.
The same holds true for people assuming that /bin/sh is bash, which may be true on certain Linux distributions but isn't so most other systems. I've started noticing the same issues with other things as well, such as the symlink from /bin to /usr/bin, /sbin to /usr/bin ... whereby software believes all software lives in /usr/bin when in reality that isn't the case for the BSD's.
I disagree, I think that Lennart is right. Nobody really cares if systemd is not portable. Upstart was not portable to BSDs, and nobody cared. The traditional sysvinit system was, AFAIK, not portable until the debian/freebsd people bothered about it. Heck, the init scripts in Linux used to be not portable even between different Linux distros.
launchd (OS X) and SMF (solaris) weren't portable, either.
By the way, when was the last time a BSD operating system cared about making their init system portable to Linux?
I'm not sure why systemd not being portable to other operating systems is suddenly a big deal.
You can write software ignoring how it will be started and you (or others) can write init scripts for various traditional systems. This is way harder if you use systemd; suddenly you need to care about the init system, and you might sacrifice init independence for pragmatic reasons (I want to support systemd, but I don't want to write this yet-another-abstract-wrapper-layer so that someone else might use it with other type of init system).
You always had to care about the init-system: There are some differences between e.g. debian and redhat (start-stop-daemon only on debian, tools for creating the symlinks to install a service), then there's upstart with a different shell-script-esque syntax.
To support systemd, the number of configs you provide will go from maybe 4 to 5, not from 1 to 2! And, looking at the examples provided by ArchLinux, the systemd services look as if they are a lot less boiler-plate than the typical debian init-script.
No, generally you didn't have to care about the init-system unless you wanted to provide an init script. But it didn't matter how your daemon was/is started. With systemd that is no longer the case, you can use certain systemd only features thereby locking out people that want to use your service/daemon without systemd.
Why would systemd suddenly change this? It is one of the init systems with best backwards compatibility with sysvinit. And writing a systemd init configuration for your daemon is trivial and it is also easy to maintain.
> Because software being written that has systemd as a dependency will be Linux only software.
And this is news, and suddenly it's systemd's fault?
If you hate Linux-only software, software that depends on systemd is the last of your problems. Software that depends on glibc and the Linux kernel are probable the main offenders.
There are currently 23946[1] FreeBSD ports. Nothing I ever needed in the last 15 years of using FreeBSD was missing. Yes, dependency on glibc and the Linux kernel is sometimes annoying, but in practice it is not an insurmountable problem. Dependency on the Linux kernel is rare and dependency on glibc can usually be easily fixed and upstream is usually happy to accept patches. Systemd is different because there is a lot of software that might decide to use it and you can't just work around it.
Generally when software relies on glibc or the Linux kernel it can be patched so that it works on the BSD's. In my time of porting to OS X for example I haven't had anyone not take my patch to fix a problem an upstream it with a "thanks!". This becomes more problematic with systemd, whereby we can't port systemd, and since the software depends on systemd (most likely for some reason or another the software developer thought it was a good idea) we can't easily replace/rip out those parts of the code and make it run on the BSD's.
Benefits to me as a desktop and laptop user of systemd.
1) Speed does matter. Fast boots are good.
2) The new journal is just better. Finding something in the logs is easier.
3) Service files are easier to write than init scripts and one can have more confidence they will work as intended as you need write very little configuration oneself.
4) Knowledge of dependencies means I never have to worry about starting dbus before gdm. It just does what is necessary to do the correct thing.
I personally want all of those things. I am really happy they came to Arch and Fedora. They both feel much more modern for it. Working on systems that use older init systems now feels archaic.
Let's move with the times. I remember the same set of complaints when we got NetworkManager. I remember the same complaints with PulseAudio.
Guess what? I now have systems with excellent networking and excellent sound.
NetworkManager is still popularly referred to as "NetworkMangler", and for good reason. I had serious problems with NetworkMangler on two completely different distributions over a period of two years. I finally solved the NetworkMangler issues by switching to Wicd; its interface is crude and ugly, but it damn well works. I haven't had to restart my laptop to get a working network connection since.
If NetworkManager is an example of how great systemd can be, then I just became vehemently opposed to it.
And this is perfectly the reason number two why i won't switch to systemd (reason number one is there is no need for it). PulseAudio does not work. It sucks. The irc channel is full of clueless (but trying to be helpfull) people. And nobody cares. I want my Alsa back. But now it's too late, i hope systemd will either be better (doubt it) or never be this popular.
And, I cannot lie, I don't want it because I don't want another dbus. freedesktop, stop turning my linux into a single user os. Next thing is they want to abolish x11. Sure it's about time for x12, but wayland? I just don't understand the community that surrounds Linux anymore.
PulseAudio works perfectly fine for me. It did have issues in the beginning, but for many years I didn't have a problem. You said elsewhere that you had issues, but that you still have issues I can see. Others, could be, no idea.
But I don't have any issues. I don't have high CPU usage. It just plain works since various years.
Given the title, I'll allow that most of these points are defensive and brusque. Unfortunately, this tends to be par for the course for the developer, and I think that turns people off.
Fundamentally, systemd tried solving too many problems at once, in a ways that inadvertently annoyed people. It replaced so much of the core infrastructure that upgrading systems resulted in an admin experience that feels alien. Giving people new tools to deal with things like binary logging != instantly changing every admin's CLI muscle memory.
I'm not saying that systemd doesn't solve valid problems (the issues it addresses are truly quite important) - it just goes about it in a dramatically jarring way.
The myths are a mix of those that are correct but often misunderstood and those who just are plain wrong. Those which are plain wrong cannot be responded to with "This is right, but ...".
Downvoting this post is unwarranted. Everything that Lennart Poettering has ever done was an unreliable clusterfuck[1] astray from the Unix philosphy. There's nothing that he has ever done that is considered "good" by a majority of Unix-derivative users.
I remember watching this video and Poettering's argument were very sound and he has managed to repel most (if not all) Draxinger's points.
The problem with "it's not the UNIX way" argument is that a lot of people don't care about UNIX that much, they just want a good system. Poettering mentions in that video that all his, and his colleagues' work (pulseaudio, consolekit, udev into udisks/upower) has been done because there was an actual demand for those features. There is a reason why most distributions use their work even as people complain about them.
I'm not going to watch this cringeworthy thing again, but i can remember than he insisted that dbus was useful and that we need a gnome session in our login manager. That would be enough to proof the point.
And the point is that the arguments he made about why dbus is useful (a lightweight IPC mechanism with use cases not covered by UNIX sockets or TCP sockets, doing much more) and why do we need a gnome session on the gdm (to get i18n, network and accessibility features you need most if not all of the session) are well reasoned and make sense to us out of the loop.
Yes. dbus effectively breaks network transparency of x11 apps and turns Linux into a Desktop-Single-User OS. While I'm not regually writing desktop applications i have never ever missed dbus. And ipc mechanisms have a tendency to become unpleasant (Corba, SOAP).
I don't have a gnome session in my login manager because I don't need i18n for the words "login" and "password". (although that would be totally possible without a whole gnome session). I don't have a braille line so i can't say anything about accessibility, but that should be (in a ideal unix world) a single printf to /dev/braille. Also the feedback is audible and visual, this seems to be no issue to me.
Accessibility is actually a requirement in many countries (per law). Obviously not everyone needs it, but just that you do not need it doesn't negate that others do.
Edit: Plus saying X breaks Y so X is not needed is not a good argument. Because you have not addressed if X is needed or not, only said that Y breaks.
I have no idear how "accessibility" is defined. I'd say getty is quite accessible, but well, I don't know, I never relied on it. But yet, that is no excuse to start a hole desktop. Just like a program can use gtk (theoretically) without a gnome desktop it should be able to do the same with for a braille display.
I think I can safely say that if X breaks Y, and I need Y than X sucks. Especially if it worked before X came. X made things worse.
/edit:
I think that's why Poettering is hated so much. There was community on the Nixes, with their own ecosystem and their own way to do stuff. It's wasn't always beautiful or nice, but their had their way to solve stuff so it would a kind of blend in with the rest. And then Poettering wants to turn it into MacOS X or Windows and adds stuff new users probably appreciate, but the old users never misses. There is a cultural shock. And then it breaks backwards compatibility. It shouldn't suprise anybody that this product should rather be superb and not just medicore to accepted.
First, he denies that this is something people need. Then, when he is told that people need it, he says that they are just doing things the wrong way. Then, when people point out that this is neither unusual nor the wrong thing to want to do, he just repeats that this is not what was intended so too bad. He offers no advice on how to do things the right way despite being the only person who seems to think that everyone else is wrong.
I also find it telling how he closes the ticket asking everyone to go upstream and use PulseAudio's ticket system (http://www.pulseaudio.org/ticket/606), which gives me this error:
-------------------------------
Internal Server Error
TracError: IOError: [Errno 2] No such file or directory: '/home/lennart/svn/trac/pulseaudio/VERSION'
So what is the homedir for? "Home directories for users". See 'man
hier'. This to me means it is not a directory for services.
This doesn't answer your question of course. There is still the 'why' of it.
Why has this become the standard?
The homedir is a volatile place. Where users reside often. And make changes
often. Any place humans change things is a place where stuff breaks easily and
on a regular basis. What if Lennard calls 'rm' with a wrong switch? Or chown?
Or chmod? The service receives pain.
Or he could decide that he no longer wants his homedir to be
readable/executable by everyone on the system, so he chmod 0700 his homedir.
Forgetting that this will render his trac instance unavailable.
Or what about sharing some responsibility? How is Lennard ever going to share
the maintenance of the ticketing system with anyone else? What impact will that
have on the ticketing system? Will it have to be migrated anyway to /srv or
/usr/local or /opt? What configs will that affect? What about the webserver
configs? What about file permissions, uids, gids?
What about backups? Are they configured for this specific service? If it is
ever migrated to another location, do they have to be reconfigured? Or will
/home/lennard just be backed up as before and no one will remember that trac is
now in /srv/trac, making a restore improbable.
What about a reboot? Will the service come back up? What if you have to
re-implement this service on another machine after this one explodes? Are you
sure you did not forget to point /etc/rc.local (or some other hack) to your new
machine?
These are only the reasons I could think of off the top of my head. And most of
these are actual examples from the field.
A standard is a standard, because it works for more people than just you. The
question you, and lennard, should be asking yourself is: How can these
standards work for me as well?
(As you can probably tell, I grew up in Ops, not Dev. I have seen the pain of
the 'works-for-me'-mentality.)
Also, cnvogel is obviously more consise than me. :-)
I think a lot of the benefits you get by running services on separated paths, as special-purpose users, ... is that you minimize side-effects provoked by work on other parts of the system.
For data shared by sevaral users, I very much prefer some separate /data/service/instance/... structure. Also much easier to allocate sane directory permissions.
One reason is that pulseaudio broke audio for many Linux users (including me). Linux audio has long been problematic but had reached a point of stability when pulseaudio was adopted by some of the major distributions. I have no idea if the problem was that pulseaudio was broken, with distributors messing up, or with Linux audio drivers.
When a problem is easily solved by just an "apt-get remove X" it is easy to start hating the piece of software. No matter who was actually at fault.
The thing is that this is a really dated opinion. While I realise that it was really painful for those months, the end result is that audio on Linux seems to work a hell of a lot better these days.
By making Linux audio temporarily problematic Linux audio became a solved problem (at least in my mind, and the minds of many users of the major distributions that use it)
Except its not dated at all. I have constant issues with PA randomly failing to do basic things like mixing, or outputting any sound at all on newest code releases. This is still a real problem for people, pretending it isnt and everything is solved and working because it works for you is an incredibly shitty attitude.
I receive all the bugs for Mageia. I don't notice bugreports for PulseAudio like what you describe. Seems very aggressive to suggest that someone has a "incredibly shitty attitude" just because someone has a different perception.
It does not seem that dated to me. Last time pulseaudio broke the sound at my computer was in two weeks ago on Debian Squeeze. Could have been a Debian fuckup, could be my hardware but whatever it was it was fixed with sudo apt-get remove pulseaudio.
I realize that is all anecdotal and I could be one of the few people in the world who still have problems with it.
Well, all software has problems. I just doubt that if problems were as prevalent as the vocal minority make out that PA would remain in the major distributions.
Not everyone has time to contribute to every project that may be useful in some way.
If something else works the way one wants, there's no call to put time and energy into a competing project.
You seem to be implicitly claiming that one only earns a right to critique the usability of a given piece of software if one is also capable of debugging and enhancing that software. Do you really believe that?
I don't like the taste of the food because I don't like the cook. Is that what are you defending? Secondly, you have to be an expert or at least knowledgeable to certain extent to talk about ingredients and style of cooking. Throwing 15 ingredients in a heated pan doesn't make you an excellent cook. Just because you can taste something delicious doesn't mean you will know everything about the that food.
This premise is flawed. There are certain ingredients that one just doesn't enjoy. If a dish is cooked with those ingredients, you won't like it regardless of the quality.
That's pretty much where my analogy falls apart, so I'm ditching it.
Whether I'm capable of contributing to a project that does not, in its current state, suit my needs has nothing to do with whether I'm in a position to contribute to that project.
This is especially true when there is an alternative that I'm already accustomed to using.
The intensity of people's hate for this guy is mind-boggling. Most of the stuff he made is really nice, proven by the fact that it's being used widely without issues.
Even without such an impressive track-record, people should at least give him the benefit of the doubt.
Even a cursory look into systemd design debunks most of the "criticism" people have against it.
"Most of the stuff he made is really nice, proven by the fact that it's being used widely without issues."
Without issues? PulseAudio is loaded with issues. The only time PA works correctly is when you are doing things the way Lennart thinks you should do them -- which is basically the way desktop Windows and Mac OS X users are expected to do things. Another way to put things is this: Lennart's software designs dictate how users should use their computer, to the exclusion of all other use-cases. Doing something cool or unusual with PulseAudio is like pulling teeth.
Pulse Audio is not perfect but what before was. People were bitching about PA and wanted OSS back. I seriously doubt that many of those actually do anything reasonable with audio.
The thing is, I am not any better off today than I was when I was using ALSA. None of the problems I had with ALSA were solved by PA; ConsoleKit/PolicyKit came closer to solving those problems, and even then, new problems were introduced. The excruciating transition to PA put a bad taste in everyone's mouth, and now we are all sitting here asking ourselves, "Why did we even bother?"
So in a sense, you are right: PA is not perfect, and neither were ALSA, OSS, and other earlier approaches. That is not the issue; the issue is, is PA actually better? Are we actually able to do things now that we were having trouble with before? From where I sit, PA makes it easier to use things like D-BUS and various "Kit" systems to duplicate the desktop user paradigm you see in Windows or Mac OS X, and nothing more (and that does nothing for me, but certainly gets in my way when I try to do things like multiseat setups).
I remember trying to get bluetooth audio working in the alsa-only days. Or network sound with esd/ssh. Or figuring out how to route audio nicely apps. Or saving my laptop battery. Or many other features that were simply damn difficult to pull off.
People don't seem to remember how crappy the audio situation used to be, for users and for ISVs. I respect Lennart and the current PA maintainers a lot for tackling the problem head on – even if they didn't or couldn't do it perfectly – instead of just complaining about the sad state of Linux audio, especially in the face of all the criticism they got over it.
Pulseaudio plus blueman does solve the bluetooth problem quite nicely. It's the main reason why I use pulseaudio.
In exchange for that I put up with confusing audio dialog boxes, high audio latency, high cpu usage when playing audio, skips and crackles when playing games, arcane commands to enable loopback, and the occasional necessary restart of the pulseaudio daemon when sound stops altogether. I guess that's a reasonable trade.
You're stating it as if it were a shortcoming of PulseAudio. PA is inadequate for most audio work, because the latency is too high -- which is a feature.
Latency vs. CPU usage is always a compromise. To achieve low latency, you need very small buffers for "rendered" audio, and lots of well-timed copy operations to the audio hardware. To just play some audio files efficiently, you want large buffers, because then fewer copy operations are necessary.
I don't see how high latency in pulseaudio is a feature. Pulseaudio has both high latency and high cpu usage. I've seen cpu usage by the pulseaudio daemon as high as 20% when playing audio.
> 13. Myth: systemd being Linux-only is not nice to the BSDs.
> Completely wrong. The BSD folks are pretty much uninterested in systemd. If systemd was portable, this would change nothing, they still wouldn't adopt it.
> 15. Myth: systemd could be ported to other kernels if its maintainers just wanted to.
> That is simply not true. Porting systemd to other kernel is not feasible. We just use too many Linux-specific interfaces.
So what happens to software written for Linux that can be (and currently is) ported to BSD when it starts to require systemd?
If it starts to rely on systemd, the question you should be asking, is: why does this program want to depend on systemd?
It's to interact with the lower plumbing - ie. set up hostname, locale, timedate, multi-seat etc.
If these interfaces are missing, the software should still work minus a few missing features. Applications could still #ifdef all they want to make things work on BSDs, no change there either.
Honestly, it's about time we standardize and stop wasting time on these low-level things. I'd rather work on software higher up in the stack, than wasting my time working around trivial differences between the Linux distros (bonus points if they get adopted on other the BSDs too). But that's just me.
3. I don't understand the desire to trim seconds off of boot-up time (even assuming that systemd does this; it didn't for me). The goal should be to restart less often, not to restart more quickly.
5. The systemd documentation is indeed very good, and that's probably one of the biggest drivers behind its adoption. However, it is also difficult. A big part of the pushback from people over systemd is that it also replaced syslog, and did so with its own custom binary log format. To quote from a forum thread I started shortly after updating my old system to systemd, "Getting smbd/nmbd to work again was a real adventure. Like other users reported, it would just silently fail when starting it from systemd. No error message when issuing the start command, and only a vague "failed" in status. I ended up having to track down Lennart's blog post on "systemd for administrators" to figure out how in blazes to extract anything useful from that cussed binary log system he invented. My first half-dozen or so attempts to get anything useful out of the log journal got exactly zero results; I finally got lucky on another approach..." (I ended up abandoning that distribution altogether after that and a number of other frustrations, and the response from the forums.)
13. The problem for BSDs isn't so much that systemd is or isn't portable to them; it's that some upstream software is beginning to require systemd, making that software difficult (or impossible) to port to BSD.
14. It seems weird to me to hear someone else decide for other people what is or isn't a "negligible" amount of work.
15. So ... systemd is in fact Linux-only by design. How does that jive with 13 again?
19. systemd may not "force" you to do anything, up until your distribution adopts it, pushes it as an update, and then you find yourself spending hours trying to figure out how to troubleshoot a problem that didn't exist before the update. Then it certainly is forcing you to do something.
Here's the problem in a nut shell as I see it: if systemd had been the default in Linux for the last ten years, probably the tool chain around it would be mature enough to meet everyone's needs, we would all be accustomed to the specific commands needed to control and interact with and debug systemd stuff, and if someone came along and proposed replacing everything with a syslog daemon and a pile of init scripts, there'd be rage and outcry. That is to say, I don't see anything inherently bad about systemd.
But, what is enormously frustrating is to have something that works, and be well adapted to it, so that if something breaks I know exactly where to look, and then have all of that be replaced by a foreign system that breaks old things in new ways and requires hours spent trying to figure out what the hell happened.
If the replacement system offers serious benefits over the old system, that offsets the pain slightly. In this case, I've yet to see what the actual benefits are; I have no idea what problems systemd is attempting to solve which are so severe, so immediate, so intractable that they require a jarring change to some of the fundamental parts of the operating system.
Regarding your last point, the main thing that systemd excels at is managing the mishmash of power events, other ACPI events, service management and integration with DBus (which everything seems to require these days).
However, I run Linux in three locations and here's where systemd fits for me:
1. Servers. No use whatsoever. There are two power states: off and on. None of this is really an improvement over SVR4 init. It's just another damn tool to learn.
2. Desktops: No use whatsoever. I run mine like servers simply because if I need remote access, trusting stuff like WOL and ACPI is just silly on Linux.
3. Laptops: No use whatsoever. This is simply down to the fact that the power management on Linux i.e. hibernate/sleep support is a bag of shit. I run mine as power states off and on, much as 1 and 2.
Regarding boot speed - my laptop boots in about 14 seconds (SSD). Who cares about making it faster?
I find that a shell script is far more useful i.e. it doesn't enforce constraints on you which have to then be added as features to systemd. Plus shell scripts are generic tools i.e. learning how to write them will be of more use globally than learning systemd guts.
So basically, screw it.
The problem that this outlines is that Linux's power management, event and ACPI state management is crappy. We don't need another layer of crap over the top of it to make it work properly.
Regarding (1), I'll echo everything meaty said, and add that basic shell scripting is a valuable and generally useful tool to have anyway, so I'm skeptical of the benefits of replacing them with another, slightly different configuration file format.
For example: we use backuppc for automated network and remote server backups. The backuppc data volume is a TrueCrypt-encrypted drive. Creating an init script that checked to make sure that the volume was present and mounted before launching the backup daemon was fairly straightforward. I understand that I could still do this in systemd, but the catch is that I would have to do it with a shell script -- the same way I am now, except for a different, alien interface -- because the native system doesn't have support for things like that. (This is assuming that some combination of unit config parameters couldn't do it; the commands for finding the drive and checking its status were a little fiddly, and I honestly haven't tried to do this the systemd way. Still though: once you understand shell scripting, you can do anything on Linux.)
1. Not really. Most sysadmins have a decent template init file sitting around or you just steal another one on the machine and modify it. They are also more flexible as some startup processes aren't quite as simple as systemd thinks (consider lockfiles, temp data purging, permissions etc).
2. ulimit / selinux - per process. cgroup whilst funky looking is YET ANOTHER disposable mechanism which will no doubt get canned in 5 years like ipchains ipfwadm etc.
3. service --status-all
4. Concurrent startup yes. That really doesn't make much difference on a server with large IO and CPU capacity.
1. I personally do not like copy pasting templates. Especially when it turns out there was a bug in the copy pasted template. So maybe this is just a question of personal preferences.
2. cgroups can do way more things than ulimit.
3. True
4. Have not used enoug containers to know how much it matters in practice.
The first one gives you a list of all systemd services/sockets currently running, the second one gives you a list of all systemd services, both running and exited. Or you can use
I'm not linux admin anymore, but I when I was, I used various service status software thingies only to find out whether the system thinks the service is running, because they tend to be wrong, and just annoy you (not starting crashed server because it "is already running" or something similar). I think debian doesn't even track service states, but I'm not sure.
> The goal should be to restart less often, not to restart more quickly.
No! These are not mutually exclusive. The goal should be to restart less ofter, but restart faster when it is necessary. Systems have to restart. Well run/maintained/designed systems may not need to restart ofter, but they do need to restart.
Consider: Many moons ago I was responsible for (among other things) the company's CRM systems. These were a couple of mid-range Suns that were extremely reliable. On an anual basis, the business operations department issues downdown cost estimates for business critical systems (these were used to develop inter-departmental SLAs), and estimated that the CRM database server cost the company about $250K per hour of down time, or, almost $4200 per minute. Or read another way: a 10 seat license for our software in a saturated (niche) market.
The point is, outages happen (no you can not account for all possible failure scenarios), and startup times matter.
While start up time is critical, how much time is being lost by imposing complexity on the humans? At least in my opinion that bit about binary logs makes the entire thing a no go. The absolute last thing I want in any sort of time critical situation is to complicate the process of reading logs.
Very true, and, to be honest, I'm not advocating for systemd. Though according to the original article this isn't quite the issue that it's claimed to be (I'm not actually familiar enough with systemd to be able to have an opinion on it), see point 20.
My assessment on the systemd debate, though, is that it feels a bit like neophobia and the technical justifications (against systemd) are a bit on the weak side.
You're right, it is mostly neophobia. I sort of tried to say that in my top comment; I don't think that systemd is technically inferior, I just can't yet justify switching to it.
But, I've been meaning to write about this for a while: I think neophobia is starting to become an unnecessarily religious article of faith in the technical community. I run a small consulting shop, we support (or try to support) just about everything under the sun. What this means is that every single time there's a significant hardware change, my hardware guy has to be on top of it; every time there's a new mobile device UI change, or platform, or service or software, he has to get to know it right away; every time PHP or MySQL or Linode or any of a number of aspects of Linux changes, I have to be on top it; every time a new operating system version is released, we have to be familiar with it.
And every single one of those little ecosystems assumes that you have the time to sit down and read and digest their documentation or play with their new way of doing things. And, if you don't, or if you miss something, you're chastised by the community (or, worse, by your customers).
It is exactly like being in college and having every one of your professors assign 3 hours' work each night and then wonder why you're making a big deal of it.
To make things worse, when something goes wrong, you know as well as I do that you rely heavily on familiarity. You don't want to be looking things up in a man page trying to remember the specific incantation for a particular thing while your budget shrinks by the second. I was lucky that the smbd/nmbd fault happened on my personal system; if it had happened to one of our clients, who has everyone using a centralized smbd share, then smbd failing to start would have stopped work for the entire company.
So, yes, it's true that I am not a fan of change for change's sake. Lennart argues that that's not what's happening with systemd. Maybe he's right. But, it is still another massive change in something that I use and support on a daily basis, that is going to irretrievably consume a little bit more time out of my limited life, that is going to force me to throw out all of the old familiar tactics ("hmm ... new client, their MySQL isn't starting, dunno where MySQL logs are on this system, let's start with `grep -R mysql /var/log/∗` ... oh wait, this is a systemd system, that doesn't work").
From that standpoint, I feel like the technical justifications in favor of systemd are a bit on the weak side.
Systemd is actually way better at logging why a service did not start. With sysvinit I often had to figure out the exact command the shell script would start the daemon with to see the stderr output. Systemd just logs this by itself and you can see this output in e.g. systemctl. This saves loads of time.
Sure, but given that developer time is a bounded resource, we can't really expect to get both fewer restarts and faster restarts. I sympathize with your example, but I would expect that you had already seriously optimized your startup process, and since systemd doesn't make services start more quickly (it only does a better job of parallelizing them), I doubt that it would have made a huge difference in your case. Assuming even a very generous 5-second startup difference, that would have only made a $350 difference per incident.
> but given that developer time is a bounded resource, we can't really expect to get both fewer restarts and faster restarts.
Your're going to have to clarify, as this statement doesn't make any sense.
You're right though. In this instance, system startup was already highly optimized. In fact, the order of startup was shifted around to get Oracle (the DB in this example) up and operational as early as possible.
On the other hand, with the introduction of SMF, that "need to optimise" largely went away. Sure, SMF didn't make much a difference in this particular instance, but parallelisation does make a difference when you're talking about total system (not service) startup time. Further it can make a difference on system that run multiple services. If 5 services have the same dependency set, then a parallel startup means that services 2-5 become available earlier versus a linear startup.
Finally, shaving 5 seconds off of service startup _does_ make a difference. While the above example means $350, there's a few things to consider.
1) a $350 loss is stil a loss. From a business perspective, a loss, no matter how small, is still to be avoided. There's other considerations as well, such as the impact of the extra 5 seconds on my budget (the SLAs mean that the loss comes out of my budget).
2) In the realm of big enterprise, this is a relatively small outage cost. In fact, I've managed system with an order of magnitude larger failure cost (SLAs are bitch).
3) It's difficult to factor soft costs. Things such as customer confidence, indirect productivity loss, etc. 5 seconds, again, means services are available sooner, lessening the impact of these soft, and difficult to quantify, costs.
I've always architected systems such that restart time didn't matter - the systems were able to fail over. However, in flight operations would fail, which meant that a restart would, in fact, cost >$50k - regardless of the length of time it took for that machine to come back.
Faster restart time is irrelevant to me. I'm already designed to deal with outages. Reducing the impact of a restart is extremely important (making them fewer in number, smaller in scope).
This usually depends on how business critical it is. If some service is not very business critical, then how do you justify (or get budget for) the extra resources you need to make it way more reliable?
But even when not business critical, it is nice that you can bring it up quickly.
As someone who's administered Solaris machines rather extensively, I find the SMF (the init system on Solaris which, in part, inspired systemd) to be much easier to manage than sysvinit. Specifically, it makes it easier to add new services than either writing new shell scripts or adapting old ones. It makes it easier to make services which depend on one-another. And it makes it easier to know which services are running and what state they are in.
I see other developers/sysadmins here saying that sysadmins usually have a template initscript which they can use to author new ones, but that's really still a lot of work if you want to do anything not covered by the template and it leads to duplicate code. (It's literal cut-n-paste programming.) Initscripts expose a lot of implementation details. Even worse, they're different for every Linux distro so the initscript for your application has to be different for every distro you want to be on.
I think the most telling thing here is, that the distro maintainers, who are the ones who write the bulk of the initscripts for Linux systems, are the ones pushing for the adoption. It's making their lives easier.
> "The problem for BSDs isn't so much that systemd is or isn't portable to them; it's that some upstream software is beginning to require systemd"
See, to me this is just a "shit barometer". If upstream software requires systemd, then almost without fail it is shit and, at least outside the linux ecosystem, I am better off not using it.
Regarding your response to 3: I agree that system stability is a very important goal. However, there are also plenty of use cases for faster boot times, so it shouldn't be disregarded as a valid pursuit in system engineering.
It's not assumption by implication, it's due to omission. I cannot assume a feature exists in your software, you must tell me it exists. As a contrived example, why would I expect your To Do List app to manage recipes?
And ad-pulseaudionem is just like a ad-networkmanagerem or a ad-dbusiem: If your software design sucks and it does not work good enough that you don't have to care about this you will be told it sucks. And to me it seems that systemd is written in the spirit of dbus and nm.
* "Not our fault, it's that other service."
* "We are never going to support that. You don't want it anyway."
* "Well that will be fixed with systemd"
* "You can add the user to the audio group, but that's wrong and you should not do it. You should instead do that thing that the other guys are telling you not to do and that they will never support."
* "This will be fixed with systemd!"
So, I guess now the question is, when someone comes along and says, "I need to do X, I used to be able to do X before systemd was in use and now systemd is stopping me, how can I fixed that?" will systemd maintainers respond with things like the above? Will there be useful and thorough documentation, so that users can fix things without having to bug the maintainers?