Debian Talks About Systemd Once Again

An anonymous reader writes: A couple of months ago the technical committee for Debian decided in favor of systemd. This is now a subject for discussion once again, and Ian Jackson says he wants a general resolution, so every developer within the Debian project can decide. After a short time, the required amount of supporters was reached, and the discussion can start once again.

Comments

Some Sense Restored?

[Anonymous Coward]

Hopefully they'll come to their senses and reject the disease that Pottering has cursed the Linux ecosystem with.

Re:Some Sense Restored?

[TWX]

More to the point, as with the System V vs BSD init debate, this'll further help to separate the UNIX-method distributions from the desktop, automagic ones.

I learned on Slack and at the time just about all of the books that I could find were UNIX admin books, not Linux admin books. With Slackware in the 2.0 kernel days this wasn't a problem; the kernel-specific stuff was really the only differentiator from regular UNIX-style admin.

I expect Desktop-oriented distributions to increasingly obfuscate things from the user, in the manner that MacOSX does. And for most users that'll work fine. For those that want to tinker under the hood, hopefully distributions like Debian will continue to allow for a more UNIX-like method of doing things.

Re:Some Sense Restored?

[FudRucker]

i have to agree, i was running Jessie for a while and systemD is just awful, i rather have the old init system that Debian has used for years, it works and i figure if it isn't broken don't fix it, i have since removed Jessie and switched to Slackware and have made up my mind to stick with Slack and keep my eye out for using only non systemD distros

Re:Some Sense Restored?

[CRCulver]

Debian is a lost cause. From Gnome 3 to Systemd they've lost their independence.

Debian's offering of Gnome 3 and Systemd are not comparable. Gnome 3 is only the default desktop for people who just want to click through the installer. But you can completely avoid Gnome 3, and indeed many people do because they do e.g. headless server installations or choose another GUI. Systemd, however, is spreading through so much of the system that it may not be possible to avoiding installing it. Even if one hangs on to sysvinit as one's init system, programs like Gimp on Debian now end up pulling in systemd libs.

Re:Some Sense Restored?

[mlts]

I personally would like to see it (and its evil compatriot, firewalld) as options.

In RHEL 7 and downstreams, you can choose between LVM2, standard partitioning, or btrfs as ways to carve up your disks. It would be nice to have systemd as an option, so for laptops where parallel starting of daemons makes a nice speed increase, it is useful. For a server where one doesn't want many changes to the underlying OS unless it is something to be tested, it can be an option. If one is using containers, maybe systemd might be useful to have.

There are changes to Linux like SELinux and AppArmor which are must haves. These add significantly to the security of the OS. systemd does add security... but not really that much. One can specify that a program run with ulimits and possibly in a container, but a wrapper can do the same thing, and one thing that I get concerned about is one program having so many moving parts that touch everything on the system, even perhaps the TTY functions.

Re:Some Sense Restored?

[Anonymous Coward]

If the moving "toward the 21st century" means suffering an all-encompassing virus that diverges entirely from the established design philosophy of the context it resides in then get me a ghetto blaster, some jolt cola and my stone washed jeans because I'm living in the 80's forever.

Re:Some Sense Restored?

[petermgreen]

Debian's offering of Gnome 3 and Systemd are not comparable. Gnome 3 is only the default desktop for people who just want to click through the installer.

It's also what everyone previously using gnome2 on squeeze would get on upgrade to wheezy or above.

A fork of gnome 2 did eventually make it back into debian but it wasn't in wheezy and you still have to manually remove all the gnome bits and replace them with their forks.

Even if one hangs on to sysvinit as one's init system, programs like Gimp on Debian now end up pulling in systemd libs.

Pulling in libs related to things you don't use isn't really anything new.

The bigger question IMO is to what extent will systems that don't use systemd as init be supported going forward? Will users of other init systems be treated as second-class citizens. When the technical comitee chose the default init system they refused to rule on this issue and it looks like the current GR is what this is about.

Re:Some Sense Restored?

[csnydermvpsoft]

The problem with supporting multiple init systems is that each package that provides a daemon needs to support all of them. A traditional init script is just a shell script, while upstart and systemd have their own formats. You could write software to convert an upstart or systemd script to a shell script, but there would likely be cases where it wouldn't be easy to translate automatically.

With filesystems, applications don't need to know anything about what's mounted how and where—you could mount /var on a btrfs partition on LVM2, /home over NFS, /tmp on an ext2 ramdisk, /usr on a read-only CD-ROM, /etc on a floppy... and everything would just work (albeit slowly because of some of my hypothetical choices).

Re:Some Sense Restored?

[goulo]

That Gimp (and more and more other programs) require systemd (which is supposedly merely "an init system") is the really evil thing. Poettering & Red hat are explicitly trying to force all Linuxes to have systemd.

I don't trust Poettering & Co's track record, nor competence, nor intentions (e.g. seeing him use sleazy manipulative rhetoric in a conference video where he accused a systemd opponent of not caring about handicapped people), and I sure don't want their unnecessary huge mass of dubious code on my machine. (Though I'm sure the NSA will be happy for the increased opportunities of exploits in such a huge messy mass of code.) And even if this "init system" were somehow really necessary for Gnome, I don't use Gnome.

They have lied, e.g. claiming that systemd is just an init system, or that it is not a big monolithic chunk of code, yet it becomes more and more monolithic. E.g. I just watched a week or two ago as several libsystemd packages in debian became merged into a single package while one user was trying to create a stub for one of them to satisfy some needless systemd dependencies by some applications.

I am becoming increasingly convinced that Ignorant Guru is right, and Linux is being manipulated for corporate interests, not users' interests. http://igurublog.wordpress.com...

Re:Some Sense Restored?

[thrig]

Selinux a must have? Hardly. Look at the security bulletins. Note the stupidly large number of exploits. Tally up how many would be prevented by selinux and where selinux would even be relevant to an attacker (who are your attackers, by the way?). Why not instead dedicate that time to fixing and auditing the code (see e.g. OpenBSD), and then only if there is spare time after all that work, only then consider the dubious benefit of a RBAC system. Consider two companies, 3-tier, sell stuff on the web, blah blah database blah blah email blah. One spends time setting up selinux, the other audits their code. An attacker desires customer data, and breaks into the selinux company via a code flaw (permitted by selinux) and reads the customer data from the database (permitted by selinux) and mails it off somewhere (permitted by selinux). The company that instead audited their code does not have the embarrassing flaw, because they found and fixed it, and were not hacked. Or what if the attacker, again via some local flaw, simply turns off selinux, and then does what they need to do? Again, time would have been better spent auditing and fixing the code, and not pouring manhours into the RBAC system.

Now let's say there is selinux AND the attacker cannot simply bypass selinux AND there is some customer data that selinux would prevent access to—say by not allowing a shell to run. This could be implemented in other ways (isolation of that customer data, so that even if they get a shell on some front-end machine, the critical data is simply not available there) that benefit the setup regardless of whether selinux is around. Oh but defense in depth, come the cries? Well, if you think you need a Maginot line off in the Pacific, or have some Potemkin policy that requires it, have fun!

Re:Some Sense Restored?

[sjames]

The funny part is that systemd has nothing to do with making a good desktop system with things papered over. Once the whole cgroups kernel interface will be stabilized, I would expect any number of improvements on the SysV init to take place.

Start with the parallel init already available in Wheezy and add a simple daemon manager called in the init scripts to stick a system daemon in a cgroup and manage it and you have every advantage systemd offered and none of the drawbacks.

If desired, that manager could support the "I'm ready" callback through a passed FD (a pipe endpoint). For non-Linux systems, the wrapper can support the callback and skip cgroups.

My big concern over systemd hasn't been that SysV would go away, but that a mediocre at best replacement would wedge itself in through crazy dependencies and prevent the better solution from even starting.

Re:Some Sense Restored?

[mlts]

At this rate, lets just check systemd into the Linux kernel tree itself and call it done.

Re:Some Sense Restored?

[mfwitten]

Compared to what Arch used to be, it is indeed worthy of the epithet "automagic".

Then again, I've always had the impression that Arch maintainers tend to confuse "Keep it Simple" with "Keep it Simplistic".

Re: Some Sense Restored?

[substance2003]

Why wouldn't it be different? Most of the open source projects where there was a major disagreement ended up with a fork.
Just think of the Open Office when Oracle was just letting it die. People just went and did Libre Office when they were ignored.
There's no reason to think that the folks over at Debian couldn't just create their own fork if they felt they were being ignored.
If that were to happen, it would then all come down to how many Debian users move over vs who stays.
That being said, I'd rather they all come to a consensus that everyone could be happy with.

Re:Some Sense Restored?

[tajribah]

A traditional init script is just a shell script, including almost invariably a couple of nasty race conditions and other subtle bugs. Starting and stopping a daemon safely is close to impossible in shell. I am not a huge fan of systemd, but init scripts written in shell are a nightmare.

Re:Some Sense Restored?

[devman]

Its actually one of the big reasons systemd is popular with distros/package maintainers. Unit-files are maintained by the upstream and not customizing initscripts with lots of boilerplate saves package maintainers time. Daemon configuration being declarative has been a long time coming.

Re:Some Sense Restored?

[geminidomino]

Unless, of course, you have a database backend for anything on your web server. If the apache daemon can access it, so can the asshat who exploited it for a shell.

Re:Some Sense Restored?

[TWX]

Yes. I look at systemd as being the opposite in what I want; I deal with mostly daemon-serving boxes that do special purpose tasks. Those boxes don't need GUIs, and outside of storage don't really even need plug-and-play. They need to be repairable on the console without ever gaining physical access to the box, and everything needs to be crystal-clear with the configurations.

Re:Some Sense Restored?

[mrchaotica]

Yes, new packages will need to support both for a while, but this is a tiny fraction of the work to create and maintain a new service. It is a very small price to pay in order to get some breathing room and a graceful transition period.

See, the problem here is that your whole concept of the issue is mistaken. You're talking about supporting both "for a while" during a "graceful transition period" when the issue is that people don't ever want to switch. Not now, not after a "transition period," not 1000 years from now -- never. The issue is that lots of people see SystemD as fundamentally wrong, bad, incorrect, doubleplusungood, and anathema to the "Unix nature." A "graceful transition period" will not and can not fix that!

Re:Some Sense Restored?

[sjames]

Why would a developer maintain a unit file suitable only for Linux when they also support *BSD which can never go to systemd?

Re:Some Sense Restored?

[gweihir]

Actually, there is no problem with systemd as long as you can avoid it easily.The fanbois shall have their toy, I have no issue with that. But forcing it on everybody, even those that actually have a clue about good and reliable system design, is just wrong.

Re:Some Sense Restored?

[TangoMargarine]

Remiiiiind you of anything??

*cough*beta*cough* Still interested to see how long they wait in the hopes we cool down before they roll it out anyway.

Re:Some Sense Restored?

[gweihir]

Well, obviously "moving to the 21th century" means being ignorant about things that work. New is not equal to "better" in any way. Maybe they could put a Farcebook client into systemd as well, that would show the quality level of the design of this thing clearly.

Re:Some Sense Restored?

[gweihir]

Systemd does not add security. It removes security y being complex enough that it must introduce new vulnerabilities. There is no way around that, the human race does not know how to write complex software from scratch without vulnerabilities. Certainly, the systemd team has proven that they cannot even manage reliable software.

Re:Some Sense Restored?

[gerddie]

This vote is not about whether systemd will be the default init system for jessie, it is about whether to ensure that other software packages are kept independent from the init system that is installed, because currently it seems that more an more software packages pull systemd in, even though they are not directly related to the init system.

Re:Some Sense Restored?

[thegarbz]

That people think GIMP and GNOME require systemd is outright absurd. They both depend on a single feature exposed by the kernel which have nothing to do with the init system. It just so happens that the most prevalent API available for this is currently the logind component of systemd.

Rather than bitch and moan about them tying the two together, why not start / sponsor the start / donate to an alternative API that's not part of systemd which GNOME / GIMP can depend on for the functionality they need.

As for Poettering's track record. His software is released early in it's infancy, that and that alone (in my minority opinion) is his big problem. All of his previous projects have resulted from a very real need to clean up some of Linux's most stupid (again in my opinion) design features. People like talking about the disaster of pulse-audio, but those same people have never had the fun of attempting to plugin a USB headset to take a call or transfer audio to another device currently playing, or never had to try and get bluetooth audio work. For all it's complaints pulse-audio is now mature and (in my opinion) works rather well.

systemd is not just an init system. The only people who claim that are those that haven't understood what Poettering is making. It's a complete system management platform. I have no opinion on if it will be good or bad to go this route, but it does look like it will solve some very real gripes that I and others have with the current Linux setups, which includes the arcane task of digging through log files. (Ok I have an opinion that binary logs aren't the way to go, but the old system was just screwed).

Re:Some Sense Restored?

[styrotech]

but if Debian drops systemd, what will "automagic" Ubuntu do, seeing as its very much based on Debian?

Go back to Upstart? And carry on just like it is still 2012.

You're forgetting that Ubuntu wasn't really a big fan of systemd, and it was only Debians decision that caused them to reluctantly switch anyway.

Re:Some Sense Restored?

[CRCulver]

You know what's funny, you blast systemd as insecure yet it is every init based system with Bash installed (most of them, though certainly not all)

Debian (you know, the topic of this discussion) and its many derived distros like Ubuntu had for many years used dash as their /bin/sh. Init wasn't passing anything to bash. Indeed, the switch was made because dash offered faster boot times for a script-based init system than bash.

Re:Some Sense Restored?

[Anonymous Coward]

That people think GIMP and GNOME require systemd is outright absurd. They both depend on a single feature exposed by the kernel which have nothing to do with the init system.

Caveat: I'm a part-time distro constibutor, and you're incorrect here.

I can't speak to GIMP, but Gnome most *definitely does* depend upon systemd -- the Gentoo distro just went through this, and it's documented in their bug tracker that systemd was now mandated via upstream. eg, Gnome3 depends upon logind which depends upon systemd. GDM now depends upon systemd. etc. etc. etc. This all really started happening around 3.8-3.12.

This left gentoo devs in the position where they could patch Gnome3 to not require logind, but then suspend/restore doesn't work unless they revert and patch upower, and on and on on.

Re: Some Sense Restored?

[rastos1]

What services does your daemon provide?

?? Does it matter? It answers queries received over the network.

Will it rebind to network interfaces if they change?

Hmm. Can you be more specific? I have problem coming up with scenario where replacing of NIC or changing of MAC/IP address could be handled transparently to the clients.

Does it need to write to disk?

Yes.

Does it need syslog to do logging output?

Does it matter? The typical configuration is to use direct logging to file. Without syslog. On Linux syslog may be used to log startup/shutdown of the daemon. Most likely using logger(1). On other platforms some native solution would be used.

If it crashes, should someone be notified? How? When? How often? Who?

If it crashes, people will notice because they don't get a service the daemon is providing. Immediately. They will notify the administrator and require the service to be restored. The administrator will capture the current logs and storage for investigation and restart the service. For HA systems, there will be failover system.

Re:Some Sense Restored?

[jbolden]

You are making a good point. I wish you would get an account.

And absolutely you are correct. Systemd is taking functions that were part of the PaaS and driving them into individual nodes which means the PaaS needs to be redesigned for systemd. The PaaS people all think this is a plus, the lower level hooks are an advantage.

Projects that want to work flawlessly on both xBSD, solaris, and Linux

That's a pretty obscure use case a cross platform daemon, running in a cluster (i.e. not virtualized hardware), that can't just use a low level daemon for Linux / systemd support. I'm going to assume systembsd or something similar is going to exist for BSD long term, but right now it does. So yes short term those projects get hurt by systemd. Either they are going to only work on obscure distributions or the are going to have to do some engineering. They are an obscure corner case that is going to get hit, but even then it doesn't sound too bad for them.

The benefits of the small lean pid 1 system that have been the norm for unix like system. are that they allow for a lot more local customization then a huge monolithic pid 1

I'm not sure that's quite true. It certainly isn't true for Digital Unix, HPUX, AIX. It was true for IRIX, SunOS.Solaris is a middle case on big hardware it wasn't true as well. It isn't true for OSX either on which systemd is based. But it certainly was true for Linux. And yes it is likely that as systemd becomes the norm people who want to customize are going to have to use more specialized distributions and lose access. OTOH systemd is very configurable so there isn't much reason to just not run the functionality of a component via configuration. The argument is not that systemd has 0 disadvantages but rather that on the whole the advantages so far outweigh the disadvantages that it was safe to just standardize.

Linux does have a healthy distribution ecosystem that allows for non-standard choices.

Hope!

[Anrego]

A very well written proposal that outlines many of the concerns I (as a non-Debian user) and I suspect most have about systemd. It’s worming it’s way into everything for the sake of better integration, which it may deliver on, but this goes against much of the traditional Linux spirit of small self-contained bits that can be swapped out at will.

In my mind, this comes down to whether we want a better functioning OS or an OS that adheres to the mindset that I think attracted many of us to Linux in the first place. Personally I want a hackers OS that I can play with and tweak as I feel like, but I accept that many people basically want open source windows or even just zero cost windows (i.e. free as in my wallet).

I hope Debian rolls back on their decision. I doubt this will happen, but at least we’ll get some more discussion in a somewhat visible forum. I may not agree with a lot of the Debian mentality, but they are very good at thinking about and discussing things, so I think this will be good overall.

And before someone says "just use gentoo", I do, and have for almost a decade (I started using it fairly soon after it came out). The problem is that systemd, being basically a virus at this point, is causing exactly the kind of problems mentioned in the proposal. I've had to use the blacklist for the first time in a while because *McBane voice* the use flags, they do nothing!

Re:Hope!

[FudRucker]

maybe systemD will cause a Fork in the Debian distro,

i like Slackware too, maybe Slackian_Debware

Gentoo users will make a Debtoo

Re:Hope!

[rjmx]

> In my mind, this comes down to whether we want a better functioning OS or an OS that adheres to the mindset that I think attracted many of us to Linux in the first place.

I'm not even convinced that it makes for a better-functioning OS. I've been a Debian user for 12 years, mostly running 'testing' distributions. When systemd first turned up, I let it run for a couple of weeks, but switched back to sysV after half of my startup daemons didn't. Tried it again a month or two later, but when it had trouble stopping Samba (and, worse, claiming that it would wait *five* *minutes* before killing the processes, I decided enough was enough, and now I'm in the process of switching all five of my Debian boxes to Gentoo. Now, granted, the testing distribution is for just that purpose -- testing -- but if I'm dealing with the kind of idiot that would claim that systemd results in faster startups, but thinks that a five-minute wait to shut down a process is acceptable, then I want no part of it.

Debian should listen to what its users want, rather than just its developers. We're not all technically ignorant.

Re:Hope!

[MightyMartian]

Binary logs are anti-*nix. Rebut that.

Re:Hope!

[Sarten-X]

this goes against much of the traditional Linux spirit of small self-contained bits that can be swapped out at will.

In my mind, this comes down to whether we want a better functioning OS or an OS that adheres to the mindset that I think attracted many of us to Linux in the first place.

Personally, that principle of having many swappable self-contained bits is one of the worst qualities on UNIX.

I've been using GNU/Linux for over a decade. I know my way around most distros, and I can usually figure out what I need to do to accomplish any task... usually. The biggest problem I face now is that distros have so many small components doing their small tasks that figuring out exactly which component is responsible for a given task is no small feat.

I understand and appreciate the programming simplicity that a small component brings, but from a user's (or admin's) perspective, the operating environment is now more cluttered. As distros pick and choose their preferred swappable components, the view gets worse. Sure, I know exactly what the "finger" command does, but it's not obvious that "pinky" is an alternative, because having a lightweight finger command is apparently an important thing. Some distros will even create symlinks or scripts to provide alternative common names for their chosen packages, but there's seldom a guarantee that the input or output will be the same. This is why the first step of many build processes is to examine the environment and figure out exactly what is available on the system, often using methods that uncomfortably remind me of browser-detecting JavaScript.

I'm not saying that systemd is the solution we need, or even that it is a solution. I've just dealt with far too many poorly-named packages to have excessive reverence for this archaic principle.

We should also keep in mind that Linux itself, as a monolithic kernel, defies the concept. By design, the kernel's one job is to interface with every piece of hardware on the machine. Is it really so far out of line to define systemd's one job as interfacing with every service provider in the OS?

Re:Hope!

[Anonymous Coward]

They both suck.

Re:Hope!

[Anrego]

I've used gentoo for a long damn time, so my ability to objectively gauge it's difficulty is probably long gone.

That said, I for one think gentoo has gotten far easier to install and especially maintain. The default profiles are no longer the joke they once were, and most packages are using more generic high-level use flags so you have one --with-feature-x instead of the old --with-compat-mode-z --with-doublefork --with-some-other-unrelated-but-required-flag type stuff you had years ago, which translates into much simpler USE flags. You can actually leave make.conf relatively untouched and still end up with a decently functional system, especially if you want a desktop and go for one of the desktop profiles.

Portage is also a lot smarter these days, being able to resolve many issues that it previously would have died on. When it does run into problems, the descriptions these days are much nicer than before!

I'm being completely honest when I say that systemd has been the first major gentoo headache I've had in a while. Everything was just dandy then suddenly I'm having to switch packages around (udev being the big one), and having to blacklist udev and systemd because so much random shit pulls them in (and a -systemd use flag isn't enough), and then uninstalling a bunch of random packages (like some power management widget that got pulled in by god knows what for some reason).

I know you've probably written off gentoo at this point, here's a completely random bit of usage advice:

- Set use flags as you need them, even if this means re-installing the same thing multiple times. This avoids big important packages being pulled in as mere dependencies (though you can add them to the world list afterwards) and more importantly lets you set up and configure everything one at a time and makes it more likely that you'll notice error messages.
- Don't be afraid of package.keywords, especially for very specific use flags.
- Avoid gnome if possible. I don't know wtf it is with gnome, but it seems to be the poster child for weird and hard to diagnose issues as well as crazy dependency trees.
- Pay attention to what virtual packages are doing. Usually they are in your best interest, but not always.
- Don't bother using ebuilds for web apps

Re:Hope!

[Palinchron]

In my mind, this comes down to whether we want a better functioning OS or an OS that adheres to the mindset that I think attracted many of us to Linux in the first place.

In my mind, it comes down to streamlining the common use cases for a given system, while throwing under the bus everyone who wants to do something with their system that Lennart didn't think of or doesn't care to support.

Re:Hope!

[Anonymous Coward]

Simple. She wants the D and is willing to use the System to get it.

Re:Hope!

[Princeofcups]

Personally I want a hackers OS that I can play with and tweak as I feel like, but I accept that many people basically want open source windows or even just zero cost windows (i.e. free as in my wallet).

How about neither? I want a rock solid OS that can scale to N processors, allows hot swapping of hardware, allows the admin to spin up CPUs and memory on a live system, and has drivers that can be added and removed on the fly. That is, all the things that any enterprise level server OS has.

Re:Hope!

[TheCarp]

utmp.

I agree its bad, and its something the unix community has moved away from and avoided, but its not so much "anti-unix" as "What unix did when it was a teenager and would rather we didn't talk about in public, especially not in front of its kids"

And...that is where binary logging should stay, until it can be eliminated entirely.

binary logging is bad mm'kay.

Re:Hope!

[bill_mcgonigle]

And...that is where binary logging should stay, until it can be eliminated entirely.

I don't even know why I'd care if systemd uses a binary representation internally, as long as it can give me human-readable logs with only text tools.

Only showing binary logs with systemd tools is a misfeature of the type "exposing the implementation". Userland requires a UI, and it's bad UI, and frankly bad Unix.

Now then, I hear you can somehow configure systemd to echo a copy of its logs to rsyslog. But, and maybe I'm just a fool with poor GoogleFu, but I tried for a couple hours to get this working and only found company for misery on the mailing lists.

If any systemd fans can point us to a quick-n-easy HOWTO on getting text [r]syslog working under systemd, then by all means shut a few of us up. Tell us how there's plenty of documentation too, we'll all hang our heads and wander away.

Re:Hope!

[Synonymous Homonym]

We should also keep in mind that Linux itself, as a monolithic kernel, defies the concept.

It does not. Not only is the Linux kernel itself customizable at compile time to fit the needs of globally distributed supercomputers as well as wrist watches.
In Debian you have the choice between Linux kernels, a FreeBSD kernel, and the Hurd. (Unless your software requires systemd.)

Is it really so far out of line to define systemd's one job as interfacing with every service provider in the OS?

No, and if that was all systemd was doing, there wouldn't be a problem.

Re:Hope!

[Anonymous Coward]

And yet all the complaints ignore the fact that systemd is a diverse modular set of tools, and not a monolithic blop, that can work perfectly well with other tools (like the usual system log).

Consisting of a boatload of different programs which are all required to work with each other and may not be switched out is not modular; it is, in fact, nearly the very definition of monolithic as applied to software.

And that not much code actually runs in PID 1.

Define not that much? How much is too much if the design and implementation are deeply flawed?

And that the TC found in its favor.

Railroaded by Red Hat, as anyone who actually followed the process knows.

And that before systemd there was a default init system that everyone used as well.

Because everyone was able to agree that that one worked in the way it should.

I'm not qualified to judge the technical merits of the case...

And yet you do.

...but the people that are overwhelmingly came down in favor of systemd.

Comments attempting to support systemd always seem to trot out this little chestnut, despite the fact that there is no evidence whatsoever to support it. It's almost like there's a playbook somewhere telling you all what to say.

The criticisms on philosophical grounds were rebuted and the rebutals stand unopposed.

Rebuttal: You keep using that word. I do not think it means what you think it means.

Instead the same questionable objections are raised again and again....

Which in most sane groups would indicate that the objections are perhaps not so questionable. Nice editorializing, though.

Re:Hope!

[BellyJelly]

FYI the Funtoo flavour of Gentoo avoids systemd completely, even with the lastest Gnome 3.

Re:Hope!

[sjames]

The existance of the GR and how quickly it collected seconds puts the lie to your claim that systemd has 'overwhelming' support.

As for being a big blob, no, it isn't a monolithic binary, rather it is a hairball of dependencies welded on to a bit that can't be moved from PID 1 (even when containerized in a sandbox like docker).

The GR is all about not letting the hairball expand for any reason. No more making unrelated things like the window manager depend on systemd.That way, when a superior init comes along it will still be practical to drop it in.

Re:Hope!

[Anonymous Coward]

"vim /var/log/auth.log.2.gz"...

You call yourself a *nix user?

Re:Hope!

[Peter H.S.]

Binary logs are anti-*nix. Rebut that.

That is of course wrong. If you have a POSIX compliant system, you have binary logs in /var/log. On Linux they are usually called "utmp" and "wtmp" and they keep track of logins and logoffs. You use the "last" tool to read these binary logfiles. utmpx is actually a formal part of Unix.

Re:Hope!

[danomac]

- Don't be afraid of package.keywords, especially for very specific use flags.

Another long-time gentoo user here - the above file is used for mixing stable and unstable/testing packages. I'm sure the parent meant package.use.

Another thing to note is portage has a built-in way to deal with patches that happen outside of ebuilds, you simply create a directory specific to the package that needs patching and drop the patches in it, and portage will automatically use the patches. This is extremely handy for a system maintainer as you don't need to edit ebuilds.

Re:Hope!

[donaldm]

Binary logs are anti-*nix. Rebut that.

No problem, every heard of "wtmp" or " "utmp" which have been in Unix for over 30 years. How about the "sar" logs which also came from Unix (Solaris) but are available on pretty much all Unix/Linux platforms.

You could also look at AIX which maybe a big shock to you since many system administration logs and configuration files are binary. The thing is AIX is Unix but that is IBM's way of doing things. :)

Re:Hope!

[AntiSol]

It sounds more to me like he was running a distribution which had a track record of being fairly stable despite being declared inherently unstable, and that one particular piece of software broke things fairly substantially for him on more than one occasion, so he decided to avoid that piece of software, even if it meant changing distros.

Seems sensible enough to me.

Remove It

[Anonymous Coward]

Debian is by far the most stable of the Linux distros. systemd does not lend itself to this stability. Nothing wrong with the old init system. We all know it and its quirlks. I fell in love with UNIX because of editable text config files. Every aspect of the system needs to be editable by an admin. Linux is losing morally to OpenBSD because OpenBSD does not allow binary blobs in the system. Ever. Debian should be the same. No binary blobs of any kind. If it's not text, it doesn't belong.

Re:Remove It

[Anonymous Coward]

systemd using binary logging, not text. Everything is a UNIX-like system was designed to be text based. binary format makes log files corruptible. systemd is huge. It has too many hooks into too much userland stuff. This should never be. The old way, while nowhere near perfect was better. Better what you know... systemd is not really progress. It's complicated and huge. Binary for logfiles is a no-no for old-school UNIX guys like me. systemd violates the tenets of the UNIX philosophy in many ways, not the least of which is the aforementioned binary logfiles. No. Just no.

Re:Remove It

[rubycodez]

Not FUD, if something wrong you'll never get to the part where you forward to syslog. Logs should be simple text files, that can be read even without the OS. ASCII text is viewable on just about anything

Re:Remove It

[Anonymous Coward]

Systemd represents the ongoing Redhatification of Gnu/Linux. Wonder why all those stupid complex looking projects come from Red Hat ? Although they cannot claim ownership of Linux, they can make it so that most Linux components are guided by Red Hat. Which is the next best thing as far as they're concerned. As for Linux users ? Who the fuck cares about them.

Re:Remove It

[MightyMartian]

Binary logs are also far more secure, but I guess that doesn't matter to you.

That has to be most bizarre justification I've yet read. How exactly is a binary log more secure?

*nix systems have had permissions systems for the better part of half a century. If you don't want someone looking at a file, don't give them permissions, but if they do have permissions, the mere fact that a file is binary isn't an obstacle save to the technically illiterate (who wouldn't likely be looking at a log file anyways).

Re:Remove It

[Anonymous Coward]

Binary logs are also far more secure, but I guess that doesn't matter to you.

Oh horseshit, what you speak of is security by obscurity. By the same token you could say gzipped logs are more secure than non-compressed logs. When reading a binary format is well understood it's not an increase in security it's merely pig-headed obfuscation for the sake of itself, a sentence that describes the intentions and outcome of the entire systemd project perfectly.

Re:Remove It

[Anonymous Coward]

I think in your rush to tell people they've missed the point completely, you've missed it yourself.

If you're reliant on trusting the logs of a system that you think might have been compromised you're already shafted. If an intruder can edit your plain text logs then they can edit everything else on the system as well, including binary ones; hacking is generally more sophisticated than vim /var/log/daemon.log dd dd dd :wq. There's nothing inherently unhackable about binary logs and if your box is rooted your only real option is to burn the hard drives to the ground and reinstall.

"Just add some hashes! Then the hash won't match and the log will reveal itself as being tampered with" comes the chorus. Nope. If you've already got the ability to rewrite the logs then recalculating the hashes so they match the massaged data is trivial.

The only remotely secure way to record logs is to write them off to a seperate log server (firewalled off, no remote access, managed by a completely different team, barbed wire, attack dogs, Slim Whitman, yadda yadda) the second they're generated - although by all means keep a local copy if you feel like it.

Windows has the whole binary logging thing, and goes to great pains to make them as hard to access as possible (which of course makes viewing them a pain as well). But anyone with admin access can clear the logs or delete whatever entries they like with winzapper or a few lines of code. Windows in secure environments uses... wait for it... a remote log server.

Long and the short of it is binary logs don't get you any extra security and, especially in the nix world where there are many and varied tools for examining plaintext logs, constitute a colossal loss of readability.

Disclaimer: I work in computer forensics. Most hacks are done by people who haven't even thought of covering their tracks and you'll have nice local log entries that tally up with those on the remote server that scream out "Look, here's me hacking teh gibson!". Advanced hacks are almost impossible to spot without a) a good IDS b) examining the discs offline.

Re:Remove It

[Lord Apathy]

Oh horse shit! Binary logs are the biggest crock of shit to blow out someones ass since Windows ME. Pure text log files can be parsed with the same system tools that come with all linux distributions. I'm talking grep, awk, and sed. An you really adventurous, perl.

All the excuses that I've seen for keeping this foul system are bullshit!

Re:Remove It

[swilly]

I don't know about journald, but on Solaris the binary logging works using digital signatures. Each log message (and the prior log messages signature) is signed to ensure that the log message hasn't been tampered with, and that log messages haven't been removed. In the event of tampering, the log messages can still be read, but are flagged as untrustworthy. I understand that administrators prefer text messages (which is why our Solaris systems also logged to syslog), but for security auditors digitally signed binary logs are a godsend.

Re:Remove It

[Lord Apathy]

Exactly. Text log files allow you to pull them off the damaged system and examine them on another system. Many times the system that you have to examine them on won't be a linux system. The other day I had to examine a log file that my co worker sent to me on my phone.

If it had been a binary log file, I would have had to get off the toilet, get dress, and find a compatible system to decode the log files on. Maybe even spin up a VM to do it in.

I was able to tell her the boot params to boot up the box with out leaving my seat. Fuck binary log files.

Re:Remove It

[RavenLrD20k]

On my servers, the current business week is in plain text and not compressed and archived until 11pm Sunday night for the next week. I keep a month's worth of archived logs. Now here's why: If a system goes down for some reason, the only logs that are going to have anything immediately useful are going to be the uncompressed ones that can easily be cat dumped or vi'd for initial troubleshooting. You're most likely going to need only the last few lines of the log just to find out what went wrong. If troubleshooting is greater than that and you find a longer history of problems that culminated in the panic, any liveCD distro will have the tools necessary to crack open your archives.

Binary log systems are a Disaster Recovery nightmare. The only reason you have a log system is that something went wrong and you need to do some form of troubleshooting/recovery. If your core system is still working fine and the native systemd is able to read the binary, great. What happens when a system partition crashes and won't boot back up? Please enlighten me on how a binary log file can be read on a system that won't boot itself? Can any liveCD using a systemd based distro read the binary file and translate it to a human readable format? Also, it's been said that using a config file, the journal system of systemd can write to a plaintext file. Please explain how that works? Using the config file, does the journal system completely turn off and each component individually writes to syslog, generating their own log file or adding to one of the already created pertinent log files, as it does with System V? Or, does each program send it's message to the journal system and it's this system that sends a message to syslog to write? If it's this latter case, what happens if during a system panic the journal system corrupts the data being written? What if the journal system itself craps out in a failure?

These are all questions that I legitimately do not have an answer to yet, and I haven't had time to research into it. Before I consider updating my systems to a systemd based distribution these questions MUST be answered satisfactorily, and it will be as I draw closer to that point that I will be making time to research it. I don't have time for FUD, fanboyisms, or anything else as such from either side. I have specific requirements that must be completely answered. If the answers are not forthcoming, I, and many many many sysadmins like me, will be keeping System V init systems on my servers by whatever means necessary.

Re:Remove It

[devman]

You can use a journalctl (see the --root or --file options) from a rescue disk or simply lift the logs and move them to another system. I'm not sure why people think that binary logs can only be read by the system that generated them.

Re:Remove It

[Lord Apathy]

yes, so export the binary file to text files.. not difficult

A completely unnecessary step.

An one that might be impossible if the server has promptly stuck its thumb up its ass and won't boot. Then add that you are a junior system admin that doesnt' know how to do that. But you know enough to boot the system with a rescue disk so you can mount the drive and then ftp the log files some place where you can mail them to your boss at 2 am. Who might just reach through the network and strangle you because you took down his porn server anyway.

Not everything speaks binary log files, but just about everything speaks ascii. Log files are in ascii on purpose. So you can read them with the minimal tools and not have to fight the system to get to them.

Just because you can do something, doesn't mean you should. That applies to binary log files.

Re:Remove It

[gweihir]

Indeed, well said. Now, I have no problem with systemd being there as an alternate init system for the fanbois that confuse "new" and "good". But it has no business being the default. And if the embrace-and-extend move being tried by the systemd-team with udev is not countered soon, they will get way to much power. True, it will require work, but Gentoo has laid a foundation with eudev, and that should be kept a viable alternative.

Re:Remove It

[rahvin112]

Yes text log files are very handy, and just like with SysV you can run syslog on top of systemd just like you did before when you ran syslog on top of SysV. Amazing isn't it!

Re:Remove It

[Peter H.S.]

If you're reliant on trusting the logs of a system that you think might have been compromised you're already shafted. If an intruder can edit your plain text logs then they can edit everything else on the system as well, including binary ones; hacking is generally more sophisticated than vim /var/log/daemon.log dd dd dd :wq. There's nothing inherently unhackable about binary logs and if your box is rooted your only real option is to burn the hard drives to the ground and reinstall.

That simply isn't true. If a hacker gets access to gpg encrypted mails, he can't read or alter them undetected if he doesn't have the key. Same with systemd journal logs with "Forward secure sealing". This isn't hash'es but strong crypto security like gpg. The concept is quite old in the crypto world:
Here is an introduction to FSS:
http://lwn.net/Articles/512895...

Re:Remove It

[Peter H.S.]

Binary logs are also far more secure, but I guess that doesn't matter to you.

Oh horseshit, what you speak of is security by obscurity. By the same token you could say gzipped logs are more secure than non-compressed logs. When reading a binary format is well understood it's not an increase in security it's merely pig-headed obfuscation for the sake of itself, a sentence that describes the intentions and outcome of the entire systemd project perfectly.

You seems to misunderstand how the signed logs works in systemd: the logs are perfectly readable by anyone with the right permissions. There is no encryption going on, only secure signing. (striclty speaking it isn't signing, or hash' chaining)

There is no signing key on the computer that can be extracted. The key is only used once to sign the first log segment, then removed from the system, the next signing key is generated on the basis of the first and so on. systemd makes cryptographically secure sealing called "Forward secure sealing". The concept is old in the crypto world, here is an introduction to how it is done:
http://lwn.net/Articles/512895...

Please Debian

[Anonymous Coward]

I've been a Debian user for 14 years now, please do the right thing and get rid of systemD.

I've been trying systemD on another machine for about a month now, it's not terrible but it's not all it's cracked up to be either.

The part that I don't like (besides it going against the unix philosophy) is how fast it's taking over before the majority of the Linux community even had a chance to have their say. And what really gets me is, if systemd was just an init system, fine. But at the rate they are going there is going to be a systemd everything.

Re:Please Debian

[BlackPignouf]

And what really gets me is, if systemd was just an init system, fine. But at the rate they are going there is going to be a systemd everything.

I hope you're not using Emacs ;)

Good to hear

[CRCulver]

I was really unhappy with Debian's move to systemd, and the fact that once systemd is running as one's init system through a general upgrade, one cannot even go back to sysvinit..

Having heard that Slackware was resistant to systemd, I installed the latest version of Slackware on a netbook I have lying around, and while it's a fine project that clearly has its fans, it seems to require a lot of retraining for someone coming from Debian. I'd love to be able to stay on the venerable old Linux distro I have so many years of experience in.

Completely wrong

[Anonymous Coward]

The summary is completely wrong. They are not discussing systemd, just whether packages can depend on a specific init system. I thought there was some kind of moderation here?

Re:Completely wrong

[Anonymous Coward]

A key point is the systemd approach to things seems to directly contradict this goal. It's seems almost by design to be getting hooks into as much as it possibly can to make removal very difficult. It's the lamprey eel of init systems.

In a world where GIMP, a graphics editing tool, has a dependency on a specific init system, it's hard not to discuss whether this was a good idea in the first place when discussing the replacability of that init system.

I'm hoping this is the path these discussions go down. Continuing to support systemd is going to lead to a two tiered Linux where not using systemd excludes you from a tonne of software, and this is about as anti-Linux as you can get.

make it option for aunt minnie

[rubycodez]

I could see why a desktop user might want to have such a thing as systemd (not me though), or someone with no admin skills having a canned all-in-one solution for their little business or hobby website.

But for where Linux dominates, server and embedded systems, I don't believe it fits into the Unix way of doing things and makes admin harder.

One of the worst points about systemd

[NotInHere]

is for me that it isn't interoperable. Please correct me when I'm wrong, but AFAIK systemd never did anything to create standards their new functionality is compatible with. Instead they only support linux APIs. I recognize that their needs exceed POSIX, but their current approach "lets make everything a hard dependency" is -to be polite- hacky. It doesn't have to be an official ISO standard, a simple document that ensures exchangeability of components inside systemd, and perhaps even makes systemd cross-platform.

Re:One of the worst points about systemd

[Anonymous Coward]

This is one of my major gripes as well. I think if we're going to start rewriting/updating software to the spec of a better init system, it needs to be a universal specification that many (perhaps systemd-like, perhaps not) alternative init systems of the future can adhere to, include those on other *BSDs and *nixes and operating systems we haven't even dreamed of yet.

I really dread a future in which, due to current Linux dominance and all distros going systemd, all of the major software packages start depending on systemd's APIs and behaviors, and then the software packages become very hard to port sideways or forwards to other platforms. Don't get me wrong, I love Linux. However, what I love more is the idea and culture behind Linux and all *nix/*BSD. I want there to be alternatives, and I want there to be future upstarts that disrupt Linux and give us something even better.

The reason the culture of all of this was so disrupt-able in the first place, leading to all the greatness we have today, is because we had *standards*, and new implementations could adhere to those standards and all the other software could quickly be ported over to them.

Aside from technological gripes about how systemd operates and/or is implemented, the key failing of systemd is failing to specify a standard for authors of everyday runtime software and daemons, so that those other authors can conform to that standard, and then the *BSDs and whoever else in the world can implement that newer, better standard independently of systemd.

Systemd is like an anti-standard. They seem to have never even *thought* about it from a standards perspective. They think only in a functional perspective, and the only function that seems to matter to them is "Today's current iteration of Desktop Linux systems". Arguably even within that limited realm systemd has standards issues. They make incompatible changes from release to release and hardly even mention them in their changelogs, much less provide backwards compatibility or a path for sane future feature changes.

Re:One of the worst points about systemd

[Peter H.S.]

is for me that it isn't interoperable. Please correct me when I'm wrong, but AFAIK systemd never did anything to create standards their new functionality is compatible with. Instead they only support linux APIs. I recognize that their needs exceed POSIX, but their current approach "lets make everything a hard dependency" is -to be polite- hacky. It doesn't have to be an official ISO standard, a simple document that ensures exchangeability of components inside systemd, and perhaps even makes systemd cross-platform.

The systemd developer have explained, and explained why they did what they did; they have made stable interfaces;
http://www.freedesktop.org/wik...

They have explained what interfaces that can easily be made on non-systemd distros or even other OS's:
http://www.freedesktop.org/wik...

There are systemd libraries and what not, and lots of documentation.

That systemd is a Linux only thing, is because it uses kernel features that are only available to Linux like cgroups, "namespaces" and "kernel capabilities" and soon, kdbus. If eg. Hurd or OpenBSD or Mac OSX implemented such features, systemd could be ported. Of course, *BSD would never allow LGPL licensed software to become a critical part of their core OS, so the point is rather moot though.

Seriously, what do people want? That nothing must be using Linux specific kernel features ever, because that is unfair to other OS's?

Re:One of the worst points about systemd

[laffer1]

> Seriously, what do people want? That nothing must be using Linux specific kernel features ever, because that is unfair to other OS's?

No, what we want is for systemd to not be forced on us as a way to destroy any chance of running a graphical environment in the future. Wayland compositors, GNOME and various other things are starting to require systemd. That is why everyone is upset. Linux users may also not like systemd and that is another issue.

The forced nature of systemd means that every linux distro must switch and that *BSD people may have to fork X or wayland (if it takes off) in the future in order to have a damn GUI.

OpenRC

[Anonymous Coward]

Seriously, why not OpenRC?

It solves all the deficiencies with classic init, but at the same time it doesn't have the interoperability problems and un-Unix-like feel of systemd.

Systemd seems fine to me at this stage

[rongten]

Hello,

  I have deployed some fedora 20 machines in the last 3-4 months, and so far I did not see anything that led me to cry foul against systemd.

  Actually, the handling of the user sessions for house-keeping purposes seems much simpler now.

  So I don't get all this hate. Maybe I did not look deep enough, time will tell.

  Cheers

FORK DEBIAN!

[slashdice]

good call. Then, instead of one distro that's 5 years out of date, we can have two distros that are ten years out of date.

But seriously, systemd sucks. I don't understand why people would take a good operating system (and this has happened with Windows (vista and 8), OSX (Yosemite), and GNU/Linux (gnome, systemd)) and ruin it for the sake of ruining it.

Maybe it's just time for RedHat ReactOS

[morgauxo]

Maybe Potering and his other buddies at RedHat are great, the best thing since sliced bread.... but... they are working on the wrong OS. These guys don't belong in Linux. They belong working on ReactOS! Imagine ReactOS with all of RedHat's resources behind it. It could quickly be a better Windows than Microsoft's! Meanwhile those of us who like Linux as Unix and aren't in the market for "Free Windows" can go on enjoying a better Unix than Unix. We could all be happy!

Opposition was suppressed.

[Anonymous Coward]

Anyone who talked against systemd in the debian IRC channel(s) was banned.
Anyone who talked forcefully against systemd on the debian mailing list was silently banned.
Eventually Anyone who wrote out "systemd" in a mail to the mailing list had their mails silently dropped, delayed, filtered.
(People started calling it killer rabbit)

Thank Don Armstrong (mailing list president for life) and the systemd cabal within debian.
(8 men plus all of debian-women)
.

All's I know...

[MouseTheLuckyDog]

The #2 developer of systemd has been banned from contributing to the kernel.
The #1 developer of systemd was the main developer of PulseAudio-- does generate much confidence.
He has also just given the finger to the OSS community--makes me wonder why he doesn't do Macs or Windows.
It is being given control over critical services such as TTY and networking.
It is hard for the average techie to audit it, given it's nature. Little access to a lot of tools: valgrind, strace, ftrace.

This does not make me feel very good about systemd.

Re:All's I know...

[grcumb]

Remember this before ranting too much on Lennart. He is not in any position to force any distribution to do anything. Distributions choose to use his software because it actually is better than the stuff that came before it.

Yes, of course Lennart's just a developer with a better idea. He's never seen software development as a means to a larger political end.

Except when he has:

Getting a clear message out what Linux is supposed to be is definitely a social issue, but to make that happen the Linux platform needs to be streamlined first, and that's a technical task, and not done yet.

All of these disingenuous statements that there's no other agenda in place are just bullshit. They're simply and self-evidently not true, because you can't do system design without some kind of vision of what you want. And you don't change the system design unless you don't like the one you've got. Lennart's vision, as he says, is a 'streamlined' Linux, which is to say catholic, not agnostic, unified rather than pluralistic, with fewer options rather than more. And when you cut away all the cruft, it's his stuff that remains.

Poettering and his acolytes can argue all they like that their vision is simply better. I disagree, but I accept that this is always an argument worth having. But when you start arguing that POSIX is a constraint and that Linux should be 'leading' the way (and that POSIX can just catch up, thank you), you're taking a stance that is not simply in opposition to others, it cannot coexist with the others because the alternatives have become mutually exclusive within a particular space.

POSIX is a limiting factor. That's true. Its limitation is that we've all agreed on a basic subset of behaviours in order that we all have enough in common to interact. So when you discard POSIX, you have effectively announced that you do not see the value of playing nicely with the other children. From that moment, your 'better idea' is being implemented at the expense of interoperability.

Which is a really fucking bad idea.

(The quote above is from an interview with Lennart, linked from his Wikipedia page.)

Lastly, to respond directly to the assertion that he is not in a position to force any distro to do anything. The tight web of dependencies, his position at RedHat and the support and assistance provided on the corporate level is perhaps not sufficient literally to force a distro to use his software, but it's enough to raise the question that undue influence is being brought to bear and that rather questionable tactics are being indulged in expressly because Lennart and his cohorts think that doing the right thing does not imply contributing in an open[*] and inclusive way.

-----------------
[*] Lennart's idea of openness is allowing others to interact with his software, but fuck you if you want him to take a second look at your requirements. And then, of course, to act shocked (shocked!) when others get upset.

Ian Jackson

[inhuman_4]

For those who don't know, Ian Jackson was the most vocal anti-systemd proponent on the committee. Considering that last time systemd was up for vote he tried: strategic voting, usurping the committee chairman, and finally throwing a temper-tantrum and refusing to talk to anyone for a few days. When it was all over he promised to try and reverse the committees decision with a General Resolution.

And now having failed to win on technical merits, he is back at it again trying to kill systemd via 'loose coupling'. Something that the committee declined to rule on.

Re:FORK DEBIAN!

[JohnFen]

It isn't developers or distro maintainers who hate systemd

I'm a developer and I hate systemd.

Re:Init is broken

[Anonymous Coward]

It can't do event driven launches and yes it does impact desktop users. Example, your on your corporate network on a laptop and you close the lid and take a plane to somewhere else and the laptop wakes up. How can Init handle something like this and know to configure it to a new network?

This is why Sun, Apple, and Ubuntu developed their own event driven systems. System D is not good. But event driven systems can respond to events like a hack attack, excess load, and other things for servers.

Init was made for stationary mini computers with only 20 text based commands and apps. It's not designed for the hacks we use to get it to work today on modern systems

So why would/should that be a function of an init system, and not a function of, say, an event driven network daemon that gets started by init on bootup - and receives event notifications on you opening/closing the laptop lid (suspend/resume)? Why should that need an entirely re-written init system when it could easily be done in just a (rewritten) network daemon using the existing init system?

Sounds to me more like entirely missing the point of what the init system is supposed to do... which is *not* reconfiguring NICs, etc (those are functions of the scripts/daemons it starts).

Cgroups

[Tenebrousedge]

The reason why systemd exists, and the reason why it isn't portable, are the same reason: it depends on a feature specific to the Linux kernel.

It's not up to the systemd developers to write kernel features for other OSes. If there's an "anti-standard" it's the kernel, not systemd. If the rest of the Unix world wants to implement something similar then I am sure it could be made part of a standard eventually. Until then, you've wasted space typing.

Re:The gradual middle road

[raxx7]

systemd-journald has long been capable of forwarding the logs to rsyslogd.
And systemd-journald can even be configured to keep it's binary log in /var/run/journal, which gets deleted at each reboot.
And Debian uses this configuration for default.

Unfortunately, if they acknowledged this, systemd haters would be left with one less thing to hate.

Other functions provided by the systemd package (eg, session managment by systemd-logind) are just a lot of work to implement, specially if you try to go for a more decoupled architecture.
Not that people aren't working on it though.