Systemd bulletin, 2015

The speed of boottime is a dick-size contest at best. As soon as boot times are below 1 minute, it isn't relevant anymore. The process of typing login and password takes longer.

Systemd Harbinger of the Linux apocalypse By Paul Venezia

Aug 18, 2014 | InfoWorld

While systemd has succeeded in its original goals, it's not stopping there. systemd is becoming the Svchost of Linux -- which I don't think most Linux folks want. You see, systemd is growing, like wildfire, well outside the bounds of enhancing the Linux boot experience. systemd wants to control most, if not all, of the fundamental functional aspects of a Linux system -- from authentication to mounting shares to network configuration to syslog to cron. It wants to do so as essentially a monolithic entity that obscures what's happening behind the scenes.

No matter which side of the argument you're on, this monolithic approach is in violation of the rules of Unix, specifically the rule stating it's best to have small tools that do one job perfectly rather than one large tool that is mediocre at performing many jobs. Prior to this, all the functions subsumed by systemd were accomplished by assembling small tools in such a way that they performed the desired function. These same tools could be used within a variety of other scripts to perform myriad tasks -- there was no singular way to do anything, which allowed for extreme freedom to address and fix problems. It also allowed for poor implementations of some functions, simply because they were poorly assembled. You can't have both, after all.

... ... ...

My take is that systemd is a good idea poorly implemented, developed by people with enormous egos who firmly believe they can do no wrong. As it stands now, both systemd and the developers responsible for it need to change. In the open source world, change is a constant and sometimes violent process, and upheavals around issues such as systemd aren't necessarily bad. That said, these battles cannot be drawn out forever without causing irreparable harm -- and any element as integral to the stability and functionality of Linux as systemd has even less time than most.

>[Nov 28, 2014] Debian Forked Over Systemd

November 28, 2014 | linux.slashdot.org
Soulskill
jaromil writes: The so called "Veteran Unix Admin" collective has announced that the fork of Debian will proceed as a result of the recent systemd controversy. The reasons put forward are not just technical; included is a letter of endorsement by Debian Developer Roger Leigh mentioning that "people rely on Debian for their jobs and businesses, their research and their hobbies. It's not a playground for such radical experimentation." The fork is called "Devuan," pronounced "DevOne." The official website has more information.

Ynot_82 (1023749) on Friday November 28, 2014 @03:31PM (#48480815)

Wow... (Score:4, Insightful)

...a fork of Debian,
Such a thing is unheard of in Debian's 20-odd year history.
I wonder what the impact of this fork will be on Debian-proper.

walterbyrd (182728) on Friday November 28, 2014 @03:36PM (#48480847)

Re:Wow... (Score:4, Interesting)

I think it's fair to say that this fork is far more significant.

I certainly wish them luck, but I am concerned that they may not be able to get the resources needed to successfully compete against the Redhat/Debian agenda.

swillden (191260) <[email protected]> on Friday November 28, 2014 @05:04PM (#48481403) Homepage Journal

Re:Wow... (Score:4, Interesting)

I think it's fair to say that this fork is far more significant.

I think this fork will be fairly insignificant, and, further, that it will increasingly run into problems as desktops and other packages depend more and more on systemd components (that trend was one of the major factors in the Debian decision to adopt it).

I actually wish the Devuan guys all the best; I'd love to see another solid server-focused distro (server focus may help them avoid the issues with DEs). But I'm really glad to hear about this fork because the systemd debate has been a huge distraction to Debian. Hopefully this will finally put it to bed as all of the systemd opponents leave Debian for Devuan. I think that will be a net win for Debian because most of the vocal opponents don't contribute much code anyway.

Personally, the more I learn about systemd, the more I like the ideas behind it, and both code and documentation seem to be of high quality (documentation in particular is much better than is typical of open source projects). I'll be sticking with Debian.

linuxrocks123 (905424) on Friday November 28, 2014 @06:45PM (#48482031) Homepage Journal

Re:Wow... (Score:2)

I think this fork will be fairly insignificant, and, further, that it will increasingly run into problems as desktops and other packages depend more and more on systemd components (that trend was one of the major factors in the Debian decision to adopt it).

Right! Lord knows open source software is known for its hard dependencies on system-specific interfaces, and for its contempt for cross-platform standards such as POSIX.

I mean, if you're on Windows, you're totally SOL [cygwin.org] if you want to use anything from Linux-land. Likewise, Mac users [finkproject.org] are totally f*ed if they want to make use of their OS's Unix roots to run Linux-oriented software.

Oh, and BSD users who want to run anything outside the system core? Out of luck. [freebsd.org] No one's going to bother taking all that Linux-specific code, which never pays attention to POSIX and uses syscall() into the Linux kernel everywhere, for such a fringe distro!

I guess we'll just stay in the world we are now, where everything on SourceForge is hooked directly into the Linux kernel, and the de-jure standards like POSIX and de-facto ones like GLIB are used as toilet paper for the Linux devs' asses.

Everyone knows almost all OSS software only runs on Linux right now anyway. Now it'll just be more of the same, but with SystemD dependencies built in, too! ...

Hmm, I think the LSD has worn off now. Ok, I have another opinion:

OSS software tends to follow portability best practices, where hard dependencies are eschewed when possible. A few corrupt, blinkered projects such as GNOME might decide to build in hard dependencies to SystemD. Most other software won't, because they'd lose portability to every platform other than Linux with SystemD. And most OSS software cares about that.

HAND.

dbc (135354) on Friday November 28, 2014 @05:18PM (#48481483)

Re:Wow... (Score:5, Insightful)

You comment is well put. A distro that is "Debian without systemd dependencies" has a very large built-in audience right out of the gate.

And that audience is technically sophisticated, with the ability to contribute. Regardless of whether or not you consider that audience a herd of Luddites (which I do not) it has both critical mass and sufficient know-how and motivation to give Devuan a fast ramp, which is the key to survival in today's crowded distro world.

quantaman (517394) on Friday November 28, 2014 @06:18PM (#48481847)

Re:Wow... (Score:2)

Of all Linux distributions, Debian was *the* first choice for running servers, but since they decided to force systemd down users throats they have lost a lot of credibility in the BOFH world.

A sysadmins first concern is reliability of its systems and this was also Debian's for a very long time. Clearly the adoption of systemd is not going in this direction. It seems to me that Devuan people understood that and want to take the now deserted land of server oriented distros. Of course the meaning for Debian is they will now have a hard time to compete with the whole lot of very good desktop distributions if they don't want to lose most of their users.

Then why aren't you hearing anything from the Red Hat customer base? If anyone wants reliability it's the enterprise which is Red Hat's entire market. The fact that nothing is coming from that side tells me that this is about something else entirely where people are more concerned about the political process and symbolism than the technical merits.

Maybe there is a big demand for a very stripped down low feature server distro, but I suspect this isn't going do become a big player.

raxx7 (205260) on Friday November 28, 2014 @06:12PM (#48481809) Homepage

Re:All right, allow me to expose my ignorance (Score:5, Informative)

systemd is, first, a new init system for Linux, to replace sysv init.

Additionally, it brings a host of companion daemons: logging (journald), a session manager (logind) and a bunch of others.

systemd and it's companions offer a host of functionality and a number of software pieces are becoming to depend on it, to the point you "can't" run a fully functional Gnome3 without using systemd as init (it needs the session management functionally of logind, for example).
The major distributions have adopted systemd as default init system: Fedora, RHEL, SuSE, Debian and Arch. Ubuntu hasn't changed yet but they have announced they will follow Debian in the future.

There is a number of people who dislike it for many reasons, which are hard to summarize because many of the people dislike it for false reasons and only some actually make valid and constructive critiques.

Eg, many people claim it's monolithic. In fact, it's made of ~100 daemons and applications and the init process isn't that big. Much much smaller than the Linux kernel itself, which a big monolithic kernel.

Many people dislike being "forced" to use because the major distributions are adopting it and major projects like Gnome are becoming dependent (with KDE talking about it too).

I use "" in "can't" and "forced" because it's not strictly true. While a lot of people whine and hate in slashdot, a small number of people have been putting their code where their mouth is and working on alternatives.

Eg, there's a systemd-shim package in Debian which actually allows you to run Gnome3 very nicely without using systemd as init, by providing the necessary systemd features.

hum (Score:5, Insightful)

Endymion (12816) <<slashdot.org> <at> <thoughtnoise.net>> on Friday November 28, 2014 @04:57PM (#48481353) Homepage Journal

Ahh, the usual misrepresentation of why we oppose systemd that always shows up. Calling us haters while trying to reframe the discussion away from the real issues isn't convincing - it just adds evidence that systemd gains position by propagand and politics instead of design and implementation quality. No, you are not going to scare us away form linux. Some may retreat to FreeBSD, which is fine (it's a good OS). The rest of us are going to stay with linux, even if it large parts of linux leave and become part of the systemd monoculture. We've been here before, after all, over a decade ago.

The varied technical issues with systemd are bad enough, but they have already been discussed, and are a central reason why the sysadmins ae forking Debian. Many systemd advocates try and steer discussions back to these technical issues - while denying that systemd doesn't actually work for everybody - to avoids talking about the fundamental design problems and philosophical changes that systemd forces on Linux.

While it is currently popular to "move fast and break things", those of us with more experience understand the value in not breaking everything. None of this means that those that are better served by systemd should stop using it! We're only angry about the attempts to force a monoculture by breaking compatibility for political reasons, when there as no technical need. You know, like Microsoft does with their "not invented here" attitude.

Still, those are philosophical issues about the software itself. That is not the primary problem some of us have with systemd, which is not about technical problems, but is instead an attack on our preferred method of licensing. The systemd takeover is an attempt to separate Linux and many userspace tools from the GPL, so that software can be used under the LGPL terms instead.

What is the big difference between GPL and LGPL? Linkage. Linking to a GPL library requires you to follow certain requirements if you link against it, while the LGPL specifically allows taht usage. (k)dbus provides the workaround, by replacing what would be a normal function call into a library with a "IPC". It's slower, but so what, computers are way faster than needed. In the end, while you can still choose to release your code as GPL, if you have to use an IPC mechanism to do anything useful the license requirements that will actually apply ends up being being more like the LGPL. For a better explanation, see this post by stevel [gentoo.org] in the Gentoo forums.

Well, if I wanted to release under the LGPL, I would. What I'm not going to do is undermine my choice of license just because a bunch of embedded developers (and others) want to use what were traditionally GPL projects without having to be bound by the copyleft requirements. If this was proprietary software, you would call that kind of behavior "stealing" or "piracy".

So don't bother with claims about "faster desktops" or "easier programming". When your solution also bundles a forced monoculture ("unifying the difference between distributions") and contains a loophole around the licence some of us chose it is simply not an option for those of us that place "freedom" as the most important feature. /how much does JTRIG (or their equivalent) pay for these propaganda attempts, anyway? //It's a waste of money regardless, given how transparent these comments are ///some of this post is reused from a post I made on HN

Uecker (1842596) on Friday November 28, 2014 @06:50PM (#48482059)

Re:hum (Score:2)

Interesting. I have to say I am also worried about software freedom, but not so much because of licensing.

I am worried because loosly coupled systems based on well defined interfaces are replaced by deeply integrated systems.

This means that you cannot easily replace one part you do not like with another anymore. This is not only bad engineering, it also limits your freedom in a very real sense. This is the real problem with systemd - and not only with systemd

[Nov 21, 2014] Debian Votes Against Mandating Non-systemd Compatibility

Posted by Soulskill on Wednesday November 19, 2014 @08:16AM
from the there-will-be-peace-in-our-time dept.
paskie writes:

Voting on a Debian General Resolution that would require packagers to maintain support even for systems not running systemd ended tonight with the resolution failing to gather enough support.

This means that some Debian packages could require users to run systemd on their systems in theory - however, in practice Debian still works fine without systemd (even with e.g. GNOME) and this will certainly stay the case at least for the next stable release Jessie.

However, the controversial general resolution proposed late in the development cycle opened many wounds in the community, prompting some prominent developers to resign or leave altogether, stirring strong emotions - not due to adoption of systemd per se, but because of the emotional burn-out and shortcomings in the decision processes apparent in the wake of the systemd controversy.

Nevertheless, work on the next stable release is well underway and some developers are already trying to mend the community and soothe the wounds.

Tollef Fog Heen

tfheen Sun, 16 Nov 2014 - Resigning as a Debian systemd maintainer

Apparently, people care when you, as privileged person (white, male, long-time Debian Developer) throw in the towel because the amount of crap thrown your way just becomes too much. I guess that's good, both because it gives me a soap box for a short while, but also because if enough people talk about how poisonous the well that Debian is has become, we can fix it.

This morning, I resigned as a member of the systemd maintainer team. I then proceeded to leave the relevant IRC channels and announced this on twitter. The responses I've gotten have been almost all been heartwarming. People have generally been offering hugs, saying thanks for the work put into systemd in Debian and so on. I've greatly appreciated those (and I've been getting those before I resigned too, so this isn't just a response to that). I feel bad about leaving the rest of the team, they're a great bunch: competent, caring, funny, wonderful people. On the other hand, at some point I had to draw a line and say "no further".

Debian and its various maintainer teams are a bunch of tribes (with possibly Debian itself being a supertribe). Unlike many other situations, you can be part of multiple tribes. I'm still a member of the DSA tribe for instance. Leaving pkg-systemd means leaving one of my tribes. That hurts. It hurts even more because it feels like a forced exit rather than because I've lost interest or been distracted by other shiny things for long enough that you don't really feel like part of a tribe. That happened with me with debian-installer. It was my baby for a while (with a then quite small team), then a bunch of real life thing interfered and other people picked it up and ran with it and made it greater and more fantastic than before. I kinda lost touch, and while it's still dear to me, I no longer identify as part of the debian-boot tribe.

Now, how did I, standing stout and tall, get forced out of my tribe? I've been a DD for almost 14 years, I should be able to weather any storm, shouldn't I? It turns out that no, the mountain does get worn down by the rain. It's not a single hurtful comment here and there. There's a constant drum about this all being some sort of conspiracy and there are sometimes flares where people wish people involved in systemd would be run over by a bus or just accusations of incompetence.

Our code of conduct says, "assume good faith". If you ever find yourself not doing that, step back, breathe. See if there's a reasonable explanation for why somebody is saying something or behaving in a way that doesn't make sense to you. It might be as simple as your native tongue being English and their being something else.

If you do genuinely disagree with somebody (something which is entirely fine), try not to escalate, even if the stakes are high. Examples from the last year include talking about this as a war and talking about "increasingly bitter rear-guard battles". By using and accepting this terminology, we, as a project, poison ourselves. Sam Hartman puts this better than me:

I'm hoping that we can all take a few minutes to gain empathy for those who disagree with us. Then I'm hoping we can use that understanding to reassure them that they are valued and respected and their concerns considered even when we end up strongly disagreeing with them or valuing different things.

I'd be lying if I said I didn't ever feel the urge to demonise my opponents in discussions. That they're worse, as people, than I am. However, it is imperative to never give in to this, since doing that will diminish us as humans and make the entire project poorer. Civil disagreements with reasonable discussions lead to better technical outcomes, happier humans and a healthier projects.

[Oct 31, 2014 ] Meet systemd, the controversial project taking over a Linux distro near you by Chris Hoffman

Oct 31, 2014 | pcworld.com

Systemd is one of the most controversial projects in Linux-land right now. How controversial? So controversial that Lennart Poettering, one of systemd's developers, even claims that horrible people have been pooling Bitcoins to hire a hitman on him. On a more reasonable level, there's a Boycott systemd website that argues for a boycott of this software on various technical merits.

All this backlash is a reaction to systemd's success. It has been-or is being-adopted by Linux distributions from Fedora and OpenSuSE to Ubuntu, Debian, and even Arch Linux. GNOME is becoming more dependent on it over time-one of Debian's stated reasons for switching back to GNOME was because of its systemd integration. It's everywhere.

So what's all the hub-bub-and the fierce backlash-about? Let's look a bit closer at this raging battle.

Systemd is a new init system

At its core, systemd is a replacement for the old SysV init system. The init system is the software that initializes your system. When you boot up, init is responsible for loading the appropriate drivers, activating your network connection, launching various system services, and finally bringing up the graphical login screen where you log in. SysV init is an old system that basically just runs scripts located under /etc/init.d.

At its core, systemd is a modern replacement for the old and crufty SysV init. It can also launch services in response to events; for example, when you plug in a USB printer, it could launch the printing service in response to the device being plugged in. When it receives a connection on a specific network port, it could launch a network service configured to listen on that port and pass the connection along.

For more technical information about SysV init vs. systemd, read Jorgen Schäfer's "Why systemd?"

But systemd is more than that

Even systemd's detractors largely agree that SysV is old and needs to be replaced. But critics correctly note that systemd is in fact more than that. It's a large project containing many other bits of functionality. It's a software suite, not just an init system.

... ... ...

Chris Hoffman is a tech geek who's been writing about everything technology-related for years. When he's not writing about gadgets and software, he's probably using them in his spare time.

[Sep. 02, 2014 ] Systemd Controversy Not Going Away Quietly by Susan Linton

Sep. 02, 2014 | ostatic.com

stuxIf you thought the systemd argument was settled, I'm not sure you'd be correct. Paul Venezia is back on the case today saying folks are continuing to blog, thread, mailing list, and forum about their problems with systemd. Katherine Noyes noted the trend in her Blog Safari today as well. Her first example says Linux is being turned into "OS X or even Windows."

Paul Venezia said today that although the systemd controversy seems to be settled, "the exceedingly loud protests on message boards, forums, and the posts I wrote over the past two weeks would indicate otherwise." systemd has been a part of popular distros for a couple of years now and users complained to deaf ears about the lack of control and usable logs. But Venezia says it's still "not too late to speak out." He noticed some saying that "BSD is looking better and better." But he hit upon the wide-reaching trend that's been disturbing most old-school Linux users:

A larger trend toward users who appear to believe that reading manuals and learning OS internals is bad, and we should plaster over all of that mumbo-jumbo with a nice, sleek -- and completely opaque -- management layer. This "learning is hard" mentality is very damaging for Linux as a service platform.

Venezia is primarily concerned with the server side of Linux, but many desktop users would have never left Windows if Linux had just been a different horse of the same color. He says developers are trying to "reinvent Windows" and concludes, "It's not pretty."

Katherine Noyes set out on a similar course recently and found not just server users having issues with systemd. She said one blogger says he feels "stuck" and he doesn't like feeling "stuck" with Linux. That was the whole point of moving to Linux for many of us. Another said, "I really like the idea of text file configurations, of simple tools that do one thing well and can be combined. And binary blobs? Seriously?" Another blogger Noyes quotes said, "Ultimately it throws away everything that worked and offers very little in return." He added, "When something goes wrong, it is far harder to troubleshoot."

[Mar 24, 2012] Monday's security updates

March 19, 2012 | LWN.net

Mandriva has updated systemd (removal of arbitrary system files) and firefox (multiple vulnerabilities).

openSUSE has updated systemd (removal of arbitrary system files).

[Mar 11, 2012] Petition Lennart Poettering Stop writing useless programs - systemd, Journal Change.org

Why This Is Important

1. We have already working and well-tested solutions
2. These solutions have all advanced features: e.g. network support, which missing in your programs
3. Features you want - you can implement by extending sysinit, syslog, etc.

Eugene Yunak

please, STOP. you are killing Linux

Andrew Rabusov:

Binary syslog is absolutely evil.

Yury Bokhonkovich:

I do not like idea of binary logs at all.

Wolfgang Draxinger:

All your software is centered around glib, GNOME, various *Kits (which don't work, properly). Your software locks Linux systems into a certain system model, forcing policy over method, which goes against the Unix (and Linux) principle of method over policy. Each program should implement only a very small, managable set of feature, whereas your projects are usually bloated with functionality, just to cover the cases it may be put into you thought of (missing the one corner case somebody else requires, but your stuff doesn't cover). If somebody points out problems in your programs design or implementation, you're deaf for critics and instead of provide clear reasoning you argue with self proclaimed dogmas. FYI: I'm now running my Linux systems without DBus, without ConsoleKit, without PolicyKit, without PulseAudio and without systemd, and ever since I got rid of the *Kits and GNOME insanity at the core all the pain in using them I had in recent years went away.

Vladimir Pokvalitov :

Lennart, your crappy systemd killed the possibility to have a separate /usr volume. A binary log can't be processed by classic text-processing Unix utilities. Your works kill the Unix-way, so please stop your harmful activity.

Thorsten Glaser:

PulseAudio may be nice, but with systemd and other unportable software you're harming the whole Open Source ecosystem by limiting things to Linux/x86 only, which itself, in the long term, will be (too) limited. Your /usr move is even WORSE than what the Hurd people do, AND breaks traditional Unix assumptions (the current model with /bin may not be the best, but it works in more cases than your Linux/x86 stuff – think of Debian/m68k which boots withOUT an initrd).

So please STFU.

Marc Espie:

Just because you can mark your territory in Linux land by pissing all over existing code doesn't mean it's a good idea. We already have DJB as the wacky uncle who does thing differently. How about you start writing useful code that solves actual programs instead of trying to reinvent Unix your way.

You're not Ritchie, you're not Thomson, you're not Linus either. Stop pretending you're a genius and start acting like one.

Paul Filo:

Lennart steals my ".local" domain with avahi.

[Dec 12, 2011] init - What are the pros-cons of Upstart and systemd

Stack Exchange

Saw systemd mentioned on Arch General ML today. So read up on it. The H Online as ever is a great source for Linux Technology and is where I found my place to start researching Systemd as SysV Init and Upstart alternative. However the H Online article (in this case) isn't a very useful read, the real use behind it is it gives links to the useful reads.

The real answer is in the announcement of systemd. Which gives some crucial points of what's wrong with SysV initd, and what new systems need to do

To start less.

And to start more in parallel.

It's major plan to do this seems to be to start services only as they're needed, and to start a socket for that service, so that the service that needs it can connect to the created socket long before the daemon is fully online. Apparently a socket will retain a small amount of buffered data meaning that no data will be lost during the lag, it will be handled as soon as the daemon is online.

Another part of the plan seems to be to not serialize filesystems, but instead mount those on demand as well, that way you're not waiting on your /home/, etc (not to be confused with /etc) to mount, and/or fsck when you could be starting daemons as / and /var/ etc, are already mounted. It said it was going to use autofs to this end.

It also has the goal of creating .desktop style init descriptors as a replacement for scripts. This will prevent tons of slow sh processes and even more forks of processes from things like sed and grep that are often used in shell scripts.

They also plan not to start some services until they are asked for, and perhaps even shut them off if they are no longer needed, bluetooth module, and daemon are only needed when you're using a bluetooth device for example. Another example given is the ssh daemon. This is the kind of thing that inetd is capable of. Personally I'm not sure I like this, as it might mean latency when I do need them, and in the case of ssh I think it means a possible security vulnerability, if my inetd were compromised the whole system would be. However, I've been informed that using this to breach this system is infeasible and that if I want to I can disable this feature per service and in other ways.

Another feature is apparently going to be the capability to start based on time events, either at a regularly scheduled interval or at a certain time. This is similar to what crond and atd do now. Though I was told it will not support user "cron". Personally this sounds like the most pointless thing. I think this was written/thought up by people who don't work in multiuser environments, there isn't much purpose to user cron if you're the only user on the system, other than not running as root. I work on multiuser systems daily, and the rule is always run user scripts as the user. But maybe I don't have the foresight they do, and it will in no way make it so that I can't run crond or atd, so it doesn't hurt anyone but the developers I suppose.

The big disadvantage of systemd is that some daemons will have to be modified in order to take full advantage of it. They'll work now, but they'd work better if they were written specifically for its socket model.

It seems for the most part the systemd's peoples problem with upstart is the event system, and that they believe it to not make sense or be unnecessary. Perhaps their words put it best.

Or to put it simpler: the fact that the user just started D-Bus is in no way an indication that NetworkManager should be started too (but this is what Upstart would do). It's right the other way round: when the user asks for NetworkManager, that is definitely an indication that D-Bus should be started too (which is certainly what most users would expect, right?).

A good init system should start only what is needed, and that on-demand. Either lazily or parallelized and in advance. However it should not start more than necessary, particularly not everything installed that could use that service.

As I've already said this is discussed much more comprehensively in the announcement of systemd.
enaut
Well one thing most of you forgot is the organisation of processes in cgroups. [this requires the kernel to have the cgroup stuff enabled -- NNB]
So if Systemd started a thing it will put this thing in its own cgroup and there is no (unpriviledged) mean for the process to escape that cgroup. This has several things as consequence:

An Administator of a big System with many users has efficient new ways to identify malicious users/processes.

The the priorities for Cpu-sheduling can be determined better as done by the "Wonder autocgroup patch".

[Dec 11, 2011] A Saturated Grey

Posted by Horst H. von Brand at Tue May 3 21:28:32 2011
@Y.Nemo: Benefit is that systemd is much more transparent, and easier to tweak (yes, "we all read shell scripts", but just look at the difference in having to read and understand 986 lines of shell to start up crond (854 in /etc/rc.d/init.d/functions, 132 in /etc/rc.d/init.d/crond proper) vs 11 lines in /lib/systemd/system/sshd.service (plus 19 in /lib/systemd/ssytem/syslog.target, which is referenced by the above, for the terminally paranoid).
And tweaking anything in some of the init scripts is something I've learned to never do, and that the hard way. Most of the intricacies in the functions is just abstracted away and handled by systemd itself, really handles dependencies (not just "(try to) start/stop stuff in this magically divined order on runlevel change" and leaves you helpless when starting/stopping stuff by hand) plus it groups the processes into groups for managing automatically among other goodies.

It's vastly less complex to manage and can do things SysVinit can't even dream of, but also very different from what you (or I, for that matter) have ingrained.

Posted by Chris Cox at Wed May 4 00:46:25 2011
There are clearly pros and cons between sysvinit and newbies like upstart and systemd.

To me this isn't different from tar-balls vs. rpm vs. dpkg.

Is systemd a full on replacement of sysvinit ? Clearly no... but arguably yes if it allows fallback to sysvinit scripts. It's different. I view it like KDE4 vs. KDE3. Not a direct replacement of form and function, but rather something different.

The pains... the pain of change, especially something that branches out a bit from the scope of what sysvinit covered is that ISVs will have to update their installation documentation. Some things will become easier and some things will be more difficult.

systemd tries to solve a lot of age old problems... but you know, since they are "age old" people are used to working around those problems or have dealt with them long ago even with sysvinit.

There are advantages to arbitrary shell based scripting systems.... and it does afford the experienced end user the opportunity to "hack" a server back to health. While there are nice hooks for systemd, I do believe there will be unexpected quirks due to the added feature complexity. There's a REASON why openSUSE 11.4 does NOT use systemd by default... you can read their page about the items that FALL OUT (no easy answer) when switching to systemd.

So... YMMV. I think for simple things, systemd will work just fine. For software unknown to systemd, there could be problems.... but maybe not... just requires more effort to figure out how to implement the pieces missing/ignored/altered inside of systemd.

For those needing the additional features of systemd (with regards to service protection, reliability, etc.)... of course, systemd brings a LOT of good stuff to the table. The question is: How big of a problem was/is that? Or have we just been "dealing" with sysvinit and accepted its limitations? Are we truly happy with sysvinit? Or does it really frustrate us? IMHO, there's NOT a lot of sysvinit frustration out there. So... finding the TRUE benefits of systemd and SELLING everyone is the key. Showing people how the whole world will become much, much, much better with systemd. Right now... I'm not seeing it.

Make the sale. Decreased startup times... yes... we know that item... need more talking points, you know.. REAL life scenarios. We can say, "it'll restart your services"... but frankly, my servers never go down.... and I don't think I'm alone. In fact, if a service does crash out, do we REALLY want it to restart? Need to show a tangible REAL and wide spread benefit.... perhaps something that everyone will WANT/NEED that sysvinit simply CANNOT do... and then maybe you can make the sale.

Otherwise, we're replacing something well understood with something new just because we wanted to do that.

Posted by oiaohm at Wed May 4 08:54:37 2011
Fall out in OpenSuse 11.4 is really not having transition interface processing working. Not failures in systemd itself. Big one is chkconfig status for active service not matching systemd status for active service. Transition issue. Not unsolvable. http://en.opensuse.org/openSUSE:Systemd_status Yes I have been through the page.
Really most of the time people I find calling for system v to init remain. Don't understand how many failures it is causing and how much its pissing off ISV's.

The dbus item that is complained about a lot I look forward to as a ISV.

Currently each distribution does there own tweaks on the system v init system to try to fix up limitations and issues it has. So as a ISV if I need to change a global setting simple as turning a service on. Ok what directory do I need to put that in. /etc/rc2.d or is that /etc/rc3.d or is that /etc/rc4.d or is that /etc/rc5.d Ok bugger do the lot. Now what services should be before the service I need to run. Bugger again. because I got to know a magic number. That is not the same between distributions. That magic number says where in the boot my stuff starts. So now I ship with everything including httpd server so I know I have everything starting the right way for me. But now we have issues.

Basically for a ISV system v init is complete trash. The little bit of overhead to support systemd I really don't care about. Systemd I simple run if my thing trys to access something that is not started yet it sorts it out.

Really why does each distribution have to have its own management system for init with its own unque naming and bents. Systemd will bring more commonality than us ISV's have ever had. So maybe at long last we can use the host distribution provided httpd servers and other items instead of our own copies.

A project after this should be to make ISV live simple between distributions. I have a php with mysql/postgresql website I want to run on a Linux distribution. If everything is nice this should be a walk in park. To get the php in the webserver get the database loaded and setup. Currently its a complete trip through hell with variations for different distributions so it works. Some of those variations is in the system v init system. dbus does make it simpler for a installer to find out if a service is installed and if it is running. Because dbus if its not their my installer does not die.

Configuration of services option is another major area that needs a proper common solution to make ISV developers live simpler.

Shell script hacking is something ISV's don't want happening either. Since its makes more files that have to be checked for errors and can get screwed up by updates. Its been a really good thing systemd does splitting executable and control data. Doing this in shell script is kinda impossible.

Allowing system v init scripts is about allowing transitional.

One of the big things is that systemd here as a ISV will give me some secuirty options that are generic independent to what LSM distribution is using. Cgroup interfaces as a ISV I could not depend on being able to alter as a ISV either.

Basically system v init needs a 40 foot hole dug and all records if its existence burnt and put in the hole filled in and no clue to its existence left. Something that works for ISV without distribution knolledge putting in its place. systemd at this stage ticks what use ISV's want.

And if distributions can when doing systemd please get your heads together can come up with common service naming. So appache is not appache on one distribution appache2 on another httpd on another. What are you trying todo here. Be confusing so ISV have to have complex processing scripts to generically install from a LSB rpm.

NunnaBizness at Tue Jul 19 09:46:00 2011

Quoting Lennart's own words from this blog as of 19-July-2011 (just in case he edits it to cover his tracks):

"Technical arguments matter. Not FUD."

Lennart, your tables look like FUD produced by any major commercial software company. Oh, I forgot. You work for one don't you?

I poke at you because you have not provided the technical arguments to support your claims yet you demand it of others entering comments here.

How many claims do you make in these tables about systemd? 50? 100? More? Whatever it is I would like, no DEMAND, that you follow your own words and provide technical arguments for every claim you make about systemd where it is given a "yes".

To argue back without providing proof only shows that you are a hypocrite with an ego larger than the entire universe.

systemd – a Replacement for init etc

Posted on May 16, 2010 by etbe

Emil says:
May 16, 2010 at 6:53 pm SMF is incredibly slow, especially on first boot. This makes debugging/building a jumpstart config really painful. It's also a mishmash of XML, SQLite, and crazy in-database snapshots of prior configurations which just rub me wrong as a UNIX minimalist. (this may be a failing on my part rather than SMF's)
For the record, I'm a huge fan of Luke Mewburn's rc.d design, which is what FreeBSD has used since 5.x (imported from NetBSD?)
gebi says:
May 17, 2010 at 10:49 am
SMF imports all manifests on first boot, so this takes some time, yes.

For me SMF is the only usable init system today with nicely integrated config management and forward/backward dependencies.

Especially the state of current init systems on linux is a joke, though not a really good one (not counting systemd here)!
Adam Watkins says:
May 17, 2010 at 8:47 pm
It seems odd not to mention launchd in this article, as Lennart does in introducing systemd. It's certainly an interesting comparison point with SMF, but as Lennart notes, it's perhaps insufficiently flexible and backwards compatible for use in Linux distributions.
etbe says:
May 17, 2010 at 10:18 pm
Emil: Complexity really isn't what you want in the most important process on your system!

Adam: Anyone who follows the link to the systemd post will see the references to launchd. Personally I don't like Apples, don't want to use them, and as their code isn't under the GPL it's of little interest to me. Systemd is the Linux program inspired by launchd and is the one for us to consider. If I had mentioned launchd then I would have had to mention the Solaris thing, etc. This is one of my shorter posts, I'm just covering the basic issue with a focus on Linux specific stuff and more importantly stuff that I will end up personally working on.

But please feel free to write a detailed post about launchd on your own blog and put the link in a comment here. I'm sure that some readers will be interested. If you don't have a blog then I might publish a guest post you write about this topic – NB I'm not going to promise anything at this time, I'd have to see what you write first.
Lennart says:
May 17, 2010 at 11:55 pm
Yes, systemd currently does not fiddle with SELinux at all. However we are very interested to add support for it (after all I am a RH guy), including in the initrd-less mode that Debian currently uses. In fact I'd appreciate a patch adding Debian-style SELinux support via some selinux-setup.c code in systemd, given that my own SELinux-fu right now is rather limited. This should be similar to how we already have infrastructure that sets up other basic facilities during bootup from within systemd, such as hostname, loopback, api mounts. (tbh though I wished we could do without the self-execution that is in the sysvinit patch Debian uses. Not sure though if that is possible in SELinux).
Baptiste says:
May 18, 2010 at 8:05 pm
Do you win anything by mixing inetd into init? Otherwise, what's the benefit compared to simply using inetd to reduce the number of daemons to launch?
etbe says:
June 28, 2010 at 9:09 pm
http://marc.info/?l=selinux&m=127688991821846&w=1

systemd has been discussed on the SE Linux list. It seems that systemd will be used in Fedora soon.

It seems that I won't need to do any coding for this either, they already have a design and some sample code.

2011-09-24 21:20:08

Re: systemd: Yet Another Init Replacement
ataraxia wrote:

- When I want to modify a (normal) service unit, I copy it to /etc/systemd/system/multi-user.target.wants/ instead of just symlinking, and change the contents. Why can't I do the same with socket units by copying them to /etc/systemd/system/sockets.target.wants/? If I do that, systemd continues to use the version under /lib/systemd/system/ instead of my modified file (even after reboot). I have to actually rename the socket unit (and the associated service unit) for the contents to be respected.

I figured out what causes this strange behavior. Rather than placing my modified (and brand new) units in /etc/systemd/system/, and then linking them into multi-user.target.wants (or another appropriate target), I was creating those unit files directly under the *.target.wants directories. This seems to set up an unpredictable situation, such that which version of the unit systemd loads depends on why it was loaded: if it was only enabled because that target wanted it, my version was used, but if some earlier dependency needed it first, the original was loaded, and mine ignored.

The solution, of course, is not to do that. systemd, as with most software, works much better when it's used properly.

#983 2011-10-01 23:29:33

check

Re: systemd: Yet Another Init Replacement
Since gnome 3.2 i not get a fallback mode when i start with systemd, now my question: How can i start lighttpd from booting?
Offline

#984 2011-10-01 23:47:45

WorMzy
Re: systemd: Yet Another Init Replacement
I don't use it, but I don't see how systemd would prevent you from having a fallback mode for gnome 3.2. Maybe they removed it?
As for lighthttpd, you'll need to create a .service file for it.

I'm rather lazy, so I just whipped up this one:
 [Unit]
Description=Lighttpd web server

[Service]
Type=forking
ExecStart=/etc/rc.d/lighttpd start
ExecStop=/etc/rc.d/lighttpd stop
ExecReload=/etc/rc.d/lighttpd reload
Restart=always

[Install]
WantedBy=multi-user.target 
It seems to do the trick. Just save it to /etc/systemd/system, and then "systemctl enable" it.

Systemd seems to be severely lacking in web-related service files, I must say. Unfortunately, I don't know who should be held responsible for that. The systemd devs should be focusing on developing systemd, but the mysql/httpd/lightttpd devs should be focusing on their respective projects too. Maybe systemd isn't big enough for these groups to consider making systemd service/socket/etc files?

Last edited by WorMzy (2011-10-01 23:48:03)

Sakura:-
Mobo: nVidia nForce 680i SLI // Processor: Intel Core2Duo 3.16GHz E8500 // GFX: nVidia GeForce 8800 GTX // RAM: 4GB (2x 2GB) Corsair DDR2 (@ 800MHz) // Storage: 3x 1TB Samsung SATAII (7200rpm), 1x 250GB Generic SATAII

Response to "Why systemd" " jcm's blog

So I read Lennart's blog post entitled Why systemd?. In it, he makes a number of comparisons between systemd and the two other Linux init systems that are still in widespread use (this being the third init system some distributions have adopted within the last few years). Overall, he makes a good argument that systemd has many nice and exciting features, and I'm sure they are of interest to various people who want their init system to be SYSV on steroids. Here are some of them:

Interfacing via D-BUS

Shell-free bootup

Modular C coded early boot services included

Socket-based Activation

Socket-based Activation: inetd compatibility

Mount handling

fsck handling

Quota handling

Automount handling

Swap handling

Encrypted hard disk handling (LUKS)

Infrastructure for creating, removing, cleaning up of temporary and volatile files

Save/restore random seed

Static loading of kernel modules

These are all things I don't want built into my init system. To me, there are many good reasons that they have been traditionally handled using simple, easy to edit and modify scripts, and that's where I personally feel they should belong. In my mind, some don't even make sense to build directly into the init system itself, such as automounting and the like (that belongs in autofs and friends). There's more, but the main point I want to make here is that when you come up with a list of comparisons, that list should not really be an inverted list of features of the replacement (which obviously may not be in what is being replaced). A better comparison would be user experience. If I'm an admin, all of the new features are nice, but do I need to change my workflow for the new tool? And at the end of the day, what am I winning overall in terms of experience?

I'm not one of those who actually wanted YAIS (Yet Another Init System). No offence particularly to systemd, but I preferred good old fashioned sysvinit. It worked for longer time than many people have been using Linux (or UNIX), it was well understood, and well documented. It was far from perfect, but it got system services started. I can't remember ever yelling at SYSV init and saying "wow, if only you weren't so crappy, if only you started every service when I connected to it". In fact, it was a mature tool that did everything I needed it to. It took a little longer to boot my system than it might, but then like most real users, I use suspend and other features that mean I boot from scratch infrequently, or I run servers where I really don't care at all. I wouldn't have cared if it took 10 minutes to boot my laptop, or an hour to boot my server…well, I exaggerate, but you get the point. And inetd? Or xinetd? Automount? Good enough for my uses as separate tools.

Jon.

This entry was posted on Friday, April 29th, 2011 at 1:37 am and is filed under Fedora, General. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

7 Responses to "Response to "Why systemd?""

jrdls says:
2011/04/30 at 1:50 am

I think you should read the rest of lennart's blog posts. He raises valid points about what's wrong within sysvinit (for instance it doesn't kill services the right way) and he has written I believe 5 blog posts relevant for sysadmins.

Lennart says:
2011/04/30 at 10:01 am

Oh man.

I am sure you are happy to learn that 8 of the items you list are not done in PID 1, but just in small services shipped along with systemd.

I like your wise comments on systemd, without actually having had a close look. That's uninformed FUDing.

"simple, easy to edit" scripts? Really? You must be running a different Fedora or RHEL than I am running.

Michael says:
2011/04/30 at 11:43 am

Well, while sysv work fine since a long time, so would we say about Windows. On a engineering point of view, replacing initscript by something simpler to administer ( systemd unit are cleaner and easier to read/write ) is a big advantage. I remember yelling at the initscripts system because it was so much composed of cut and paste everywhere, because people had varying degree of understanding of the shell scripting, etc. I also often found that having to kill process by hand was rather unsatisfying and fragile.

Maybe systemd do too much. But I think there is a logical reason to unify the boot process like systemd does.

Bender says:
2011/04/30 at 3:53 pm

Oh yes, we can't blame sysv very much because it doesn't do much at all, all we can blame is a badly written script. But the best part in systemd is that it makes it possible to standardize all distros which in many cases modify their scripts etc.

As is the case with hal, systemd uses all best stuff linux has, there is no point in being generic and crappy but work everywhere. Systemd might ease a lot of administration leaving more for proper coding

oiaohm says:
2011/04/30 at 11:16 pm

Everyone want to forget the init process itself is a block of C code even with system V. It is in charge of shutting the system down. That init command you run to change run levels under system V sends a message to process 1 on the system. dbus is just a different way and more friendly way todo IPC messages. Interfacing by dbus nothing different really.

"Modular C coded early boot services included." Did you not read this.
Systemd main source codes include the features todo Mount handling down. But big but these are independent modules. So can be replaced or removed.

Merging in of inetd kinda came a requirement due to how systemd operates.

xinetd/inetd was the first Socket-based Activation system. systemd is the next generation with many improvements so every service can take advantage of xinetd/inetd activation on demand idea even if they are not designed to be xinetd/inetd compatible with systemd. This is why xinetd/inetd cannot mix with systemd. They both will want to be monitoring the same things.

mount handling also falls into mount based Activation. Service has started up it goes to use a partition that is not mounted yet. So systemd suspends it until that is mounted.

The deeper you dig systemd is an Activation based system. Something completely different in a lot of ways to sys v init system. It is basically impossible todo a full activation based system inside the system v model. Also none of the YAIS (Yet Another Init System) ever has been a fully activation based system. Systemd closest living relation is launchd from OS X. Launchd is only partly in the direction of Activation based system.

Activation based system is not an Init system really either. Activation based systems keep on working away after the system has started up.

Encrypted hard disk handling (LUKS) is a good example of this in systemd it handles encrypted harddrives on startup also if you plug them in while the system is running. If harddrive requires password drive may wait until have the machine is booted and dbus sends a message asking for password.

Also due to it being an activation based system not a init based system. It does house keeping on temp directories and the like.

Biggest change is cgroup wrapping of every service so you know what started what. Doing this also would have required a complete rewrite of the shell scripts.

Of course I am not going to say for one moment there are not areas in systemd that cannot be refined. Like possibly making units for mount handling and so on run as independent processes so more tolerant to failures.

Systemd is the first of its kind of system on Linux other than xinetd and inetd. This is important to remember every other init system that has ever been on linux is a rework of the sys v design one way or another. So perfectly fair to call the others YAIS. If systemd is yet another something. Its Yet Another Inetd. Just inetd on serious booster drugs so it can boot the complete system just compatible services. Yes systemd behavior is more like a inetd than a system v init.

A revamp of this size is a chance to fix a lot of historic mistakes and make a few new ones.

foo says:
2011/05/01 at 7:21 am

sysvinit is unreliable in the case of services depending on each other. You have to manually reorder stuff, or automatically reorder stuff based on dependencies encoded in LSB headers. Automatically reordering stuff is hard, especially on custom setups. With systemd that goes away and the kernel does it automatically. Much nicer than sysvinit.

Server boot time matters too.

With sysvinit you lose packets when restarting services, not so with systemd.

Tomasz says:
2011/05/02 at 5:50 pm

Changing the workflow isn't necessary a bad thing. Sure, it can be an annoyance. But often specific workflow is a result of working around limtations and bad design decisions in tools. Learning new workflow can let you utilize the power of new tool. Only after you acknowledge that some canonical things can be done different and better you appreciate the new design.

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to to buy a cup of coffee for authors of this site

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March, 05, 2020

Softpanorama May the source be with you, but remember the KISS principle ;-)	Home	Switchboard	Unix Administration	Red Hat	TCP/IP Networks	Neoliberalism	Toxic Managers
	(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix

Top Visited <p>Your browser does not support iframes.</p>					Switchboard
					Latest
					Past week
					Past month

Systemd bulletin, 2015

Old News ;-)

[Dec 12, 2015] How to install and configure ZFS on Linux using Debian Jessie 8.1

[Sep 02, 2015] Is systemd as bad as boycott systemd is trying to make it

October 26, 2014 | LinuxBSDos.com

[Aug 30, 2015] This article [with the critique of systemd] is more full of bullshit than a bull stable .... with shit in it

Notable quotes:

"... the comments from Microsoft fans/paid-for-shills in other forums. They tend to attack anyone not accepting things imposed on them. ..."

Aug 30, 2015 | blog.erratasec.com

[Apr 15, 2015] Colourful ! systemd vs sysVinit Linux Cheatsheet

Does not prints well in Adobe reader. But is usable as image.

[Apr 15, 2015] Without Systemd

[Apr 15, 2015] Is Modern Linux Becoming Too Complex

Feb 11, 2015 | Slashdot

As to rsyslog, you really are utterly stupid: Failing disks or filesystems are detected rightfully by the kernel, nothing else has any business doing so. Different from systemd "logging", rsyslog will not make the log problem worse by using a binary format and a broken flush strategy...

I am not especially well versed in the systemd vs sysinit issues. However, it is my understanding from reading other posts and articles on the issue is that those who are complaining about systemd are concerned unhappy with the non-linuxy way systemd approaches system process management.

March 06, 2015 | slashdot.org

Systemd Harbinger of the Linux apocalypse By Paul Venezia

Aug 18, 2014 | InfoWorld

November 28, 2014 | linux.slashdot.org

[Nov 21, 2014] Debian Votes Against Mandating Non-systemd Compatibility

[Oct 31, 2014 ] Meet systemd, the controversial project taking over a Linux distro near you by Chris Hoffman

Oct 31, 2014 | pcworld.com

[Sep. 02, 2014 ] Systemd Controversy Not Going Away Quietly by Susan Linton

Sep. 02, 2014 | ostatic.com

[Mar 24, 2012] Monday's security updates

March 19, 2012 | LWN.net

[Mar 11, 2012] Petition Lennart Poettering Stop writing useless programs - systemd, Journal Change.org

Why This Is Important

[Dec 12, 2011] init - What are the pros-cons of Upstart and systemd

[Dec 11, 2011] A Saturated Grey

systemd – a Replacement for init etc

7 Responses to "Response to "Why systemd?""

Google matched content

Softpanorama Recommended

[Oct 15, 2018] Systemd as doord interface for cars ;-) by Nico Schottelius

[Oct 14, 2018] In essence, Red Hat is attempting to out-MS MS by polluting and warping Linux needlessly but surely

[Oct 12, 2018] To change the systemd log level change the ' LogLevel ' parameter in /etc/systemd/system.conf

[Jan 29, 2019] RHEL7 is a fine OS, the only thing it s missing is a really good init system.