Systemd redux: The end of Linux - <AUTHOR> http://blog.lusis.org/blog/2014/11/20/systemd-redux/ <comment><USER2> Perhaps this is a controversial idea, but is this not just someone finally taking the tried and true Open Source "advice" to heart?

That is, every time I've reported something is broken, wonky, doesn't work reliably, et cetera, I've been told, "Submit a patch.", "Write some code.", or worse, "Implement it yourself."

Someone finally got fed up with the haphazard state of affairs in Linux-land. Fed up with the fragmented and sometimes many places you have to look for error logs. Fed up with the many files you have to edit to configure the network correctly (different on every major distribution). Fed up with the half dozen ways to configure X, where X is a common function to every modern operating system.

It seems Lennart has taken the advice and followed through, and distribution maintainers liked it. They liked the idea that someone was taking all this complicated work - this dirty, boring to write and maintain code - and making their lives easier. Why else would nearly every distribution be on board?

Systemd is offering a more compelling solution than anyone else, and if you don't like it, well, you should submit a patch, write some code, or implement it yourself.

<comment><USER3> I had no opinion on systemd until yesterday. In fact I had a glace or two at the code and it's pretty clean and I liked the rough objectives laid out.

I installed CentOS 7 on a machine last night that we're replacing CentOS 6 on and was poked in the face with timedatectl and dbus problems for an entire hour, some of which were intermittent. Debugging these issues is a horrific pain. I lost 4 hours on it. I've never lost that much time on a system function before. This is not what I expected and there is no way I could possibly introduce that to our production environment.

I think that might why people are slightly sensitive to it.

Yes you're exactly right, but replacing something with something less stable, more complicated and more difficult to debug isn't a rational or good engineering. I'm sure many people will be fed up with systemd much quicker than what was already there.

Not impressed with a community which pushes this as stable, quality software. Voting with my feet: FreeBSD is being trialled instead. WhatsApp throwing a million dollars at it draws a lot of valuable attention and puts it in the business's mindset.

Choice is as much of a valuable aspect of open source too...

<comment><USER4> You know this is funny, I remember reading comments EXACTLY like this about 3-4 years ago but with pulseaudio in place of systemd.

Pulseaudio was Lennart's previous project. It broke everything in linux sound for a while, everybody moaned and hated it and said it was the worst thing since the crucifixion of Christ.

Yet, name one problem you had with sound on linux in the past year? There are very few. Pulseaudio now just works(tm) and is a unseed, unheard of part of the plumbing.

If you remember what is was like messing with ALSA and (shudders) OSS before pulseaudio came along you will agree that the current state of affairs is a million miles better. It used to be really difficult to get more than one application to be able to play sound at a time. I remember compiling sound drivers from source just to get them working. Configuring ALSA config files to get surround sound working was practically a black art. Creating manual scripts that unmute the sound card on every boot because the driver didn't initialize it properly.

With pulseaudio, I never have to worry about any of that and configuring surround sound takes me two clicks of the mouse.

Lennart did a fantastic job with pulseaudio, he took on a dirty problem that nobody else dared to touch and went through years of criticism to produce a really high quality solution that solved the linux audio problem so well that you don't hear complaints about it anymore.

In light of that, I trust him to do a good job with systemd. It'll be a couple of years of everyone moaning and bitching and whining about it, then one day it will have become a seamless part of the plumbing, everyone will take it for granted and wonder how they ever managed fighting with shell scripts and fragmented init systems before systemd came along.

It's ironic that Lennart Poettering is probably the most abused developer in the entire OSS ecosystem, yet he is one of the people contributing most to it. For our sake, I'm glad he has such a thick skin. If I was him I'd have quit this game long ago.

<comment><USER5> > Yet, name one problem you had with sound on linux in the past year?

That's just it. Linux sound worked fine for me before Pulseaudio, and FreeBSD sound has always worked perfectly fine for me. In fact, FreeBSD solved sound mixing sooner via /dev/pcm virtualization (while Linux chose to create the Linux-only ALSA instead), and has always had lower observed latency.

Pulseaudio screwed up my audio so badly that for a year I was running the closed source OSSv4 binaries and manually recompiling all the audio libraries to use OSS instead of ALSA/Pulse.

It is not fantastic to push horribly broken code onto the entire Linux userbase while others frantically jump in to help patch and fix the trainwreck.

And we're doing the same thing again with systemd. Instead of having a few years where users can choose between systemd, sysvinit, openrc or upstart, while all of the major bugs are worked out, we're being forced immediately from sysvinit (Wheezy) to systemd (Jessie). I was on Lennart's treadmill with Pulse, I'm not getting on it again with systemd.

<comment><USER6> WAIT you NEVER had an audio problem in Linux before PulseAudio? I would have said the weakest link in Linux on desktop WAS audio.

Now PulseAudio was released into the wild too soon by too many distros BUT it has fundamentally fixed what was HORRIBLE in Linux. (Previously a Sound Engineer and Record Studio owner)

BUT I would say that Systemd is extremely stable and not broken. What people are complaining about is the philosophy aspect.

<comment><USER5> > WAIT you NEVER had an audio problem in Linux before PulseAudio?

To be fair, I didn't say I _never_ had Linux audio issues prior to Pulseaudio (whereas I did say that about FreeBSD.)

Back in '98, my SB16 ISA card would only output sound at 8-bit monaural under mikmod, and I could only play CD-audio with that passthrough cable between the CD-ROM drive and the sound card. Once I was able to get sound working well enough, the only way I was able to play MIDIs was through Timidity and Soundfont emulation. And until ALSA, there was obviously pain whenever two things would want to play sound at the same time. This of course was due to the OSSv3 author changing the license before introducing his own audio mixing, and all of those awful sound server daemons (esd et al) never really worked, since there were multiple daemons and each application wanted different daemons or just wanted to stab right at the OSSv3 ioctl's.

But once ALSA was established and working, yes. Audio under Linux at that point worked just fine for me. Pulseaudio was a solution looking for a problem.

> (Previously a Sound Engineer and Record Studio owner)

I won't claim to be either of these. I like to listen to music while I write code, I'll occasionally watch some movies or play some games, and I want Pidgin to make a chime when someone sends me a message.

In particular, I'm very sensitive to latency in gaming (emulation), but that's about the extent of what I need speaker sound output for.

> What people are complaining about is the philosophy aspect.

To me, the worst part is the backroom politics, the complete disregard for portability, and the lock-in effects of consuming other daemons and services, and making software dependent upon it.

However, I do also object to the design itself, as well as to the developers responsible for working on the project, and the attitude of disdain they present to the community at large.

<comment><USER6> The thing is that we HAD TO HAVE JACK to over come latency in Linux and MAN that was HARD and once it worked DON'T mess with it or else 3 hours later you had a broken keyboard, mouse and monitor.

The issue was ALSA was HUGE latency to use for anything in recording was just not doable! I had to buy a closed source solution under Windows. Today I could easily do it in Linux.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> Really bored of this nonsense at this point. Take this for example:

 _If you absolutely MUST run Linux, my recommendation is to minimize the interaction with the base distro as much as possible. CoreOS (when it's finally baked and production ready) can bring you an LXC based ecosystem_

Systemd is absolutely key to how CoreOS works. It's the basis for the distributed init system it provides — a major selling point.

Taking any of this blog's advice would be harmful. I'd suggest a better approach would be to accept that the majority of distributions have settled on systemd and that generally this decision has not been made by idiots. So it would be worth either understanding what their pain points are and how they can be solved with an alternative to Systemd, or to help solve the issues that are apparently in Systemd yourself.

<comment><USER3> Many large decisions have been made by idiots, badly. Blindly accepting consensus as a rational choice without a counterpoint had caused many years of suffering for the human race from wars to bad science to bad medicine.

Whilst I agree that the blog is probably hocum, there's nothing wrong with critical thinking.

<comment><USER7> I completely agree – but critical thinking involves something along the lines of "here are the things that I think are wrong, this is why I think they're wrong, this is how I think they could be solved."

The answer "let's throw everything out" isn't that useful; likewise, dismissing the considered opinion of lots of people who have been doing this sort of thing for a while needs to be done with some rationality. An empty, bandwagon-jumping appeal like this adds little value and just helps spread more misinformation.

<comment><USER3> Actually the answer is to be slightly more conservative with the approach. No one has to pick up systemd now for example. Leave it a year and see where it is. The technical merits will be obvious and the technical problems will also be.

Moving all the chess pieces at once, which is what is happening is not productive, professional or a sign of experience.

<comment><USER7> That's not the case though – systemd has been enabled by default by Fedora for three and a half years or so, and has been steadily adopted since then by most other major distros. Not everybody is moving at once, so why would waiting a year make any difference?

<comment><USER3> This bugzilla query against RHEL 7.0 systemd says otherwise:

[https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_s...](https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=POST&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=RELEASE_PENDING&classification=Red%20Hat&component=systemd&product=Red%20Hat%20Enterprise%20Linux%207&query_format=advanced)

A lot of the bug descriptions are quite scarily bad when you consider them in context such as "various loginctl commands not working" etc.

<comment><USER7> So what you mean is "Systemd still has serious bugs," which is nothing to do with whether or not everybody is moving at once.

That's the point – if systemd has important bugs _they should be fixed_. Clearly, the groups responsible for the decision have concluded that the tradeoff is worth it, and have accepted that a large, fundamental change will have issues. That's fine – there are a bunch of other distress you can use that have not adopted systemd, which you can use in the meantime if you disagree.

<comment><USER3> The two are related.

People are shipping production operating systems with systemd that is chock full of bugs.

An all consuming tentacle monster like systemd is fine if you want to dogfood it but to throw at paying customers and/or supporters of your distribution is a little off key.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> One thing I've realized about the Linux community through all this systemd flame warring is how unbelievably conservative a large subsection of it is. There's this huge so-called "neckbeard" continent that views anything architecturally beyond the 1980s as a huge affront to Unix.

IMHO I kind of shrug at this, since Unix was never really all that great to begin with. Unix won because the only _commercially viable and well supported_ alternative was Windows, an OS that was (and in many ways still is) significantly worse especially for server and embedded applications. Everyone rallied around Unix and especially free/open Unix as an alternative, and so here we are.

It's also tough to compete with free, and Unix OSes got a huge boost from both Linux and the various free flavors of BSD. Yet that boost came at the expense of things like BeOS, Plan9, original NeXT, and the OS I still feel is hiding behind the JVM ... which for their day represented fresh ideas that might have gone somewhere.

Ultimately I think the existing Unix paradigm is going to be killed by Docker and mobile OSes that containerize in similar ways, and I'm not sure this is a step forward. It escapes much of the ugliness and the poor permission model of Unix, but it does so by handing virtually everything to the app. Docker containers (and mobile apps) can be thought of as something almost akin to giant statically linked binaries. We're getting more monolithic and coarse- grained.

<comment><USER9> People who aren't extremely familiar with how the Linux init system works and whose job doesn't include keeping the servers stable don't see why the neckbeards are up in arms about systemd, but there's good reason. Many peoples' jobs depends on making sure the servers are working, and knowing how the servers work is a big part of their job (and sanity). In its current incarnation, systemd changes the fundamentals of how servers work without much increase in features - large risk and little reward.

<comment><USER10> Server admins have so much new technology to learn and play with to stay relevant. If they feel like learning systemd is a chore, they might be in the wrong business.

<comment><USER11> All the more reason to be judicious in what new technologies are introduced.

One of the huge benefits of the Unix/Linux, CLI, and Free Software traditions is that they tend to be _very strongly preserving of established knowledge_. Changes are incremental, usually additive, a reliance on scripting means that interfaces are unlikely to change, and new tools are very frequently drop-in replacements for old.

As specific examples:

I first learned editing under BSD vi in the mid 1980s. In the time since I've learned and used on various PCs (and a few other systems): WordPerfect, WordStar, MacWrite, AmiPro, several iterations of MS Word, the EDT and EVE editors under VAX, the TSO-ISPF editor, and a few others under Unix: emacs, ae, nano, nedit, Abiword, Lyx, and various iterations of what's now LibreOffice. _Most of that skill-acquisition is now dead to me -- the tools simply aren 't available or aren't useful._

I'm no longer using vi, but vim (adopted in the mid 1990s as I switched to Linux), but the basic muscle-memory is the same. And its an editor I can utilize across a huge number of systems (though I do admit to finding traditional vi / nvi painful).

Similarly, the bash shell is an iteration on the basic Bourne and Korn shells.

ssh is a drop-in replacement for rsh, to the extent that /usr/bin/rsh is typically a symlink to ssh. While the dynamic is _slightly_ different from telnet, it's still pretty similar with a few exceptions.

The rare occasions in which a utility changes its commandline options you'll virtually _always_ hear about it. The fact that it's so painful (and tends to break decades-old scripts) means its generally avoided. Authors who make a point of doing this tend to find that people avoid their tools.

A bigger point is that _forgetting_ stuff is often much harder (and more important) than _learning_ stuff. And when you're invalidating long- established patterns, that's really painful.

There's also the fact that we manage technology by managing complexity, and most of us in the field work at the limits of our ability to manage the complexity we're faced with: the basic OS, shells and interpreters, hardware, vendors, hosting providers, management tools, employers, clients, customers, co-workers, engineering and development teams, services, abuse and security concerns. It's a really complex and dynamic field.

Linux has done quite well (with a few notable exceptions) of maintaining a balance between capabilities provided and complexity imposed. One problem is that as systems become more complex, the additional benefits of yet more complexity are lower, and the costs are higher (this is a very general rule, not just specific to Linux, operating systems, or computers).

The question of _how to introduce radical change_ is a key one. I've seen a number of failed attempts to drastically revise existing systems in place -- this almost always fails. Linux itself wasn't introduced in this way -- it emerged _as an alternative_ to both "traditional" proprietary Unices, to Big Iron (mainframes, VAX), and Microsoft's then-new WinNT. Linux ended up dominating virtually all of these categories, but it did so by incrementally beating out the competitors through replacement.

An interesting space where a lot of this comes to a head specifically is in the graphical user interface field. I've noted several times that Apple, notable for a great deal of success in this area, has been _exceptionally_ conservative in its GUI development. It's effectively had two GUIs, the initial Mac System interface, and Aqua. Each has had a roughly 15 year lifespan, and yes, there was incremental improvement over the span of both, but the essential base remained the same.

Since the early 1990s, I've watched Unix/Linux go from twm to fvwm, Motif/mwm, VUE/CUE (a "corporate" standard based on Motif plus a desktop), Enlightenment, GNOME, and KDE, and now alternatives such as xfce4 and ... oh, that funky graphics thing Suse's got, as the "primary" desktops. GNOME and KDE themselves have gone through about three major revisions. And there are a number of other "lesser" more minimal desktops as well -- I use one of these, WindowMaker, which is actually based in a late 1980s ancestor of the Aqua interface now used by Apple.

Microsoft's experienced some similar recent tribulations. As has pretty much every online site ever that's done a site redesign.

As jwz has observed: changes to GUIs _just don 't offer that much win_. They're highly disruptive, they're possible because the interfaces generally _aren 't_ scripted (other than via automated QA testing systems, but that's another story), but more importantly: the productivity benefits granted users really aren't that significant, especially regards the cost.

Worse: changing an _existing_ interface leaves users in a no-recourse situation, _especially_ in the case of SAAS. For Linux and systemd, the options are slightly more open in that (for now) it's possible to disable or block systemd from installing in at least some cases. But over the long run, it may be that the only options are voice and exit, as opposed to loyalty (a reference to the book and concept of _Voice, Exit, and Loyalty_ , which I recommend looking up).

So yes: those of us with numerous decades of experience in the field often _do_ have an extremely jaundiced view toward radical change. And with very good reason.

But your comment is really unwarranted.

<comment><USER12> Exactly that. You know what's insanely great? When you watch this presentation video of 1978 at AT&T where Ken Thomson explains Unix and type some commands on his VT-52 and you think: all of this is still current knowledge, and all of his explanations still hold true. Just like celestial mechanics or Pythagorean theorems. We are heirs of this ancient wisdom and this is _friggin good_ , this is _culture_.

<comment><USER13> And systemd is changing precisely none of that.

Nothing about systemd removes the basic unix command line. Because he's most definitely not explaining the init system, which wouldn't have been the same from year to year then, or even similar decade to decade.

<comment><USER11> Systemd _does_ touch numerous parts of Unix as it existed in 1978: logging, authentication, and devices come to mind. But much of what it's interacting with came along afterward: networking, far more services than existed at the time, a much more complex security scope, and more.

But that's _still_ a good 25-30 years of work, experience, practices, and smoothing out the rough edges that will be shot down the drains.

Systemd _also_ fundamentally changes the control locus of key features within Linux and how applications, the kernel, and OS as a whole are constructed and constrained. Putting all of that under the control of a small group with highly evident disdain for any "outside" concerns (in quotes as these are of the larger Linux community, and the concerns are most decidedly inside that group), contempt, and plays-poorly-with-others attitudes.

I'm not impressed.

Nor with your comment, FWIW.

<comment><USER13> Authentication is done with PAM and Kerberos these days - Kerberos is late 1980s, PAM came along in the 90s. Unix evolves and had continued to do so since its inception. udev certainly changed how we do devices.

The rest of your comment is fear mongering which could be applied to any group of core devs on any OSS project in existence. After all who controls Debian and security defaults? Do YOU trust them?

<comment><USER11> You're missing the point: there _was no networking_ (outside of UUCP and dial- up connnections) in 1978 Unix, so there were large classes of functionality since added which _simply didn 't exist_.

What 1978 Unix _did_ have was security and authentication. The OS was multi- user from the very beginning -- hence the pun in the name: uniplexing operating system (Dennis and Ken created a two-user OS to play Space Traveller).

As Bruce Perens recently discussed in a set of comments at LWN, the first thing he did as DPL of Debian was decentralize the management of Debian packaging. He recommends a very similar process for Systemd. The Systemd proponents in that discussion aren't particularly taken with the idea.

[http://lwn.net/Articles/621022/](http://lwn.net/Articles/621022/)

It's not a matter of fear mongering when the stated goals and practices of Systemd are to intentionally break compatibility with other Unixen, to reject compatibility patches, and to provide "choice" in the form of allowing users the option of any Linux distro on which they can run systemd:

[http://imgur.com/r/linux/Is9vjRJ](http://imgur.com/r/linux/Is9vjRJ)

As Jon Corbet noted at LWN in his Grumpy Editor post on the topic, it would greatly behoove systemd leadership and proponents to demonstrate a modicum of gracious victory.

As for Debian's governance, _that_ process has been more than slightly troubled of late, with at least four key departures (Joey Hess, Ian Jackson, Russ Allbery, and Tollef Fog Heen), only in the past couple of weeks. The cabal question was raised by former DPL Bruce Perens in the LWN post linked above. And, frankly, no, I haven't been happy with the recent directions of Debian's Technical Committee of late. Joey Hess's resignation (as well as those of Ian and Russ) calls into question more than just the specific decisions, but the _process_ as a whole.

Your attempts to smear my own comments which are based on actual events, facts, and highly considered views of those with deep and broad experience in the field is, I'm _really_ sorry to say, far too typical of what I see from systemd proponents (the attacks on Perens in the LWN thread strike a pretty similar tenor).

Something is sick in this process. That more than anything is what's bothering me about it, though I've also grave doubts over the technical direction.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> >single parent hierarchy for namespaces

Predictably, all the blame is laid at systemd's feet.

The current churn is happening, because all of Linux's core developers (kernel and user space) are wanting that change...to push the envelope.

For example, the current change in CGroup's namespaces are because kernel is mandating that the current cgroup access mechanism be deprecated. They want a single writer to Cgroups. Systemd is in the unfortunate position of complying with that request. Guess what? Soon enough, so will Upstart.

Again with kdbus, the person who made the push is not "evil" Lennart, but Kay Sievers - a long time maintainer of udev.

Systemd is nice. Don't be afraid.

Http://www.lambdacurry.com/systemd-nice-dont-afraid/

<comment><USER15> You mean this Kay Sievers? [http://www.theregister.co.uk/2014/04/05/torvalds_sievers_dus...](http://www.theregister.co.uk/2014/04/05/torvalds_sievers_dust_up/) \- It's basically the buddy of Lennart at Red Hat - at least that is my impression from far away..

systemd may be nice but it's coming from Redhat and cgroups are changed due to because systemd folks wanted it that way as far as I followed that debate...

<comment><USER14> Yes, we are veering dangerously close to Godwin's Law : not only is Lennart and systemd evil, but everyone who agreed or contributed to it.

<comment><USER16> Sievers appears to be an unreasonable dick. Gunderson announces to the world that systemd's DHCP client is pretty damn cool. In the same post, he puts out a call for interested volunteers.

Ted Lemon (the author and maintainer of ISC DHCP from its inception to 2003 [0]) asks for the location of the project's source repo. Sievers replies with a LMGTFY link that doesn't even answer Lemon's question. Lemon politely criticizes Sievers for his rude and unhelpful answer. Sievers fails to even apologize.[1]

Both Sievers and Poettering have pretty serious attitude issues. It's one thing to lambast a peer who frequently fails to meet the potential that they've demonstrated in the past. It's entirely another thing to try to score social points with your callous indifference and blinkered bullheadedness.

[0] [https://www.isc.org/downloads/dhcp/](https://www.isc.org/downloads/dhcp/)

[1] Check the first few comments of: [https://plus.google.com/+TomGundersen/posts/eztZWbwmxM8](https://plus.google.com/+TomGundersen/posts/eztZWbwmxM8)

<comment><USER17> What you've just mentioned here is what scares me most about systemd. Not its tight coupling, not its bugs, not its philosophy - all of these things are arguable and in most cases fixable.

The project being run by people who hold unreasonable and downright odious views who act like, frankly, _utter asshats_ , is a much more serious problem.

The Kay/Linus debacle is something you can expect to see more of from these fine folks going forward. Mark my words. Ask yourself if you want software developed this way running your OS.

<comment><USER18> I am not sure if you're referring to this, but I have seen so many instances where an individual joins a community and then systematically tears it apart by calmly and coolly promoting ideas that ~51% kind of like and ~49% absolutely hate, through a combination of personality cult and back-room coalition building. I have seen this happen in forums, IRC channels, RPG groups, businesses. It is a particularly insidious type of toxic personality because you can't fix the problem by excising them without alienating and losing a large chunk of your community.

<comment><USER17> Been there and done that.. what's a community to do in such a case?

</comment></comment></comment></comment></comment></comment></comment><comment><USER19> I'm quite happy to be a part of the development team for GNU Guix, a distro that is _not_ using systemd. I'm not a systemd hater, but it's definitely not for me and I'm not thrilled with the direction that development is going. It's a shame that sysvinit and friends are so bad that using systemd is the best option we have right now. Maybe GNU dmd will be able to stand up to it someday.

<comment><USER20> Thank you for doing this.

That being said, it's a little too esoteric for my tastes (among other things: "if you are looking for a stable production system that respects your freedom as a computer user, a good solution at this point is to consider one of more established GNU/Linux distributions.").

Do you know of any Linux distros that a) don't use systemd, b) are vaguely active / supported, and c) run on UEFI? (My current laptop, unfortunately, has UEFI. It's a royal pain, but oh well.)

<comment><USER19> >it's a little too esoteric for my tastes

Yes, we're still in alpha. Not ready for prime time yet.

>Do you know of any Linux distros that a) don't use systemd, b) are vaguely active / supported, and c) run on UEFI?

Gentoo? I use Debian most of the time, which of course uses systemd now.

<comment><USER20> > Gentoo doesn't officially support UEFI

<comment><USER19> Ah, didn't know that. Thanks!

</comment></comment></comment></comment></comment><comment><USER21> I have mixed feelings about systemd: like many others, I've spent a lot of time with traditional Unix systems (25 years) and like the simplicity and stability commonly associated with them and familiar tools/conventions. On the other hand, OS X showed what a modern system built on Unix should feel and look like, while Linux never got anywhere near (not only on the GUI layer). If it takes unreasonable people to make progress (like in the famous G.B. Shaw quote), then let's sit back and see what happens. Perhaps Linux will shed more cruft and become simpler to develop for rather than harder.

Of course, I'm in the favourable position of not having to maintain/administer a bunch of Linux boxes for a living. I can fully understand the frustration of people who built and shipped custom solutions on top of SysV init.

The end of Linux? No, it's the end of Linux as a traditional Unix with lots of arbitrary optional features on top perhaps. We'll get used to it, or switch to something better.

<comment><USER22> _On the other hand, OS X showed what a modern system built on Unix should feel and look like, while Linux never got anywhere near (not only on the GUI layer)._

This feels like a non-sequitur. The nice GUI of Mac OS X has nothing to do with launchd (which is the systemd-like portion of Mac OS X).

<comment><USER23> Are you kidding me? Launchd helps coordinate a massive selection of on-demand GUI-related services and their prerequisites. (254 services on my Mavericks install as of writing)

SysV init is ill-suited to that sort of complex event-oriented management, which (for example) is exactly why Canonical developed Upstart in the first place.

</comment></comment></comment><comment><USER24> The ignorance in this post runs _deep_.

For example:

 _Speaking of zones and Solaris, if that's an option for you it's probably the best of breed stack right now._

Does the author have no idea what's going on with Solaris? Hint: Nothing. Nothing is going on with Solaris, because Oracle doesn't care about Solaris. They closed the source, and now push out the occasional minor update from on high for their enterprise customers. Anyone who is suggesting Solaris as an alternative to Linux at this point in history is simply not credible.

<comment><AUTHOR> He's actually suggesting SmartOS[1][2] and OmniOS[3], which are both illumos distros that are very much alive, having forked from OpenSolaris over four years ago.[4]

[1] [https://smartos.org/](https://smartos.org/)

[2] [https://news.ycombinator.com/item?id=8571961](https://news.ycombinator.com/item?id=8571961)

[3] [http://omnios.omniti.com/](http://omnios.omniti.com/)

[4] [https://www.youtube.com/watch?v=-zRN7XLCRhc](https://www.youtube.com/watch?v=-zRN7XLCRhc)

<comment><USER24> That's probably a wrong choice, too, for most Linux users (though there _are_ some reasons a reasonable, and technically competent, person might choose an Illumos system, if you're doing it because a random crank on the Internet tells you to, you probably don't know enough to understand those reasons and the quite large tradeoffs you'd be making).

Regardless, it's one example of many where the author exhibits a very poor grasp of...well, everything he talks about. Dunning-Kruger effect is funny that way.

<comment><AUTHOR> You realize that you're just talking in _ad hominem_ circles? You acknowledge that there are reasons that a "reasonable and technically competent person might choose an illumos system"; is it as least possible that someone advocating that choice might not be merely "a random crank on the Internet"? And given that this is potentially a reasonable choice, how does advocating it represent "a very poor grasp of [...] everything"? If there are specific technical arguments to make here, please make them; the repeated personal attack is unwarranted -- and unpersuasive.

<comment><USER24> Yes, I find the whole article so full of wrong that I didn't think it needed more than simply calling it "wrong". Though seeing how many upvotes it now has, I guess _I_ was wrong.

But, if you insist, let's break it down a bit:

 _"...FreeBSD...also ships with ZFS as part of the kernel and has a jails which is a much more baked technology and implementation than LXC."_

Which is an assertion that would require significant citation and specification about the ways in which the author believes jails to be superior in order to be a useful claim. I believe it is an assertion based on ignorance of either Jails or LXC, or the ways those technologies have been used historically and are being used today. For most of the uses I see talked about on HN, LXC is the "more baked" implementation. While Jails has existed for a _long_ time, it was not intended for the purposes we're using LXC for today in Docker and similar deployments. The tools exist, the resource management exists, for LXC and they don't, or are quite rudimentary for jails. To suggest someone choose jails where they are currently using Docker and LXC is to suggest they live with a large variety of limitations and pain points, and in a lot of cases to simply not do what they are currently doing, or to do it in wildly different ways. All to avoid the minor pain that is represented by SystemD for most users.

In short: Jails are not (currently) a reasonable alternative to LXC in that context, and it exhibits some kind of ignorance to suggest them.

Continuing on, despite your suggestion that he is talking about SmartOS or OmniOS, he quite clearly is not. He specifically mentions Solaris while mentioning the others as other options:

 _" Speaking of zones and Solaris, if that's an option for you it's probably the best of breed stack right now. Rich mature OS-level virtualization. SmartOS brings along KVM support for when you HAVE to run Linux but backed by Solaris tech under the hood. There's also OmniOS as a variant as well."_

That paragraph clearly _is_ recommending Solaris, specifically. If you'd like to argue that Solaris is a reasonable alternative for most Linux users, it's a conversation I'm going to opt out of. I'm pretty sure we'd be speaking completely different languages.

 _" If you absolutely MUST run Linux, my recommendation is to minimize the interaction with the base distro as much as possible. CoreOS (when it's finally baked and production ready) can bring you an LXC based ecosystem."_

So, CoreOS is the Linux option he recommends? The same CoreOS that uses SystemD? Indeed, was among the first distros to embrace SystemD with gusto. CoreOS, that is _remarkably_ different than all other Linux distros. All because "Linux is becoming something different than it was"? So, in response to Linux becoming something different, he recommends people switch to something that is utterly different, like an entirely different operating system (FreeBSD, Solaris(!), etc.) or a Linux distribution that rethinks everything, not just the init system (CoreOS).

All to avoid something being different. It absolutely boggles my mind, and I have hard time responding with anything other than derision; for that, I apologize.

You're right that I haven't been particularly persuasive, and have been quite abrasive. This article just really rubbed me the wrong way.

<comment><USER25> "That paragraph clearly is recommending Solaris, specifically."

He says, as he quotes a paragraph that specifically calls out SmartOS and OmniOS -- both of which are under the IllumOS branch of OpenSolaris.

"So, CoreOS is the Linux option he recommends? The same CoreOS that uses SystemD?"

The problem he's raising isn't that linux is going to be different, and if you think it is you need to re-read. Try doing it with your --with-reading- comprehension switch. It being different is just a statement of fact, the problem statement was separate.

CoreOS is not a distribution in the classic sense. It is a platform for deploying containers, and in the use-case they've setup the author clearly believes it will allow you to still be successful _in spite of_ systemd.

</comment></comment></comment></comment></comment></comment><comment><USER26> I think the article got one thing wrong: That sooner or later every GNU/Linux distro will switch to systemd. I can think of three that most likely will not: Slackware, Crux, and Gentoo. Granted, the more that systemd binds itself to formerly modular userspace utilities and apps, the more pressure on those distros to make the switch, or else either fork every systemd userspace app at the risk of being left behind. But I have a feeling there will be a schism in Debian, resulting in a fork or (less likely) dropping systemd altogether, before too much longer. That might just be the catalyst to move away from it in other major distros.

Then again, I could be completely wrong, and systemd will end up in every single surviving distro by default, turning GNU/Linux into systemd/Linux. That's when we'll see a true exodus of those opposed to it to other OSes.

<comment><USER27> I'm also interested to see how things play out with OpenWRT. High-end home routers are starting to get a lot more powerful with the transition to ARM SoCs and NAND flash, but they won't be able to run any software that depends on the systemd ecosystem while OpenWRT is still supporting the massive install base of hardware that systemd can't fit on.

<comment><USER26> Ditto for small ARM devices like the Raspberry Pi. When the RPi version of Arch Linux went to systemd, the system actually got slower in my experience. On such an already limited device, it was a quantifiable difference; before systemd, Arch was the fastest GNU/Linux distro for the Pi by leaps and bounds. After systemd, even Raspbian feels faster than Arch, and now Slackware is the reigning king of speed for it (again, among Linux distros).

Unfortunately Slackware is still a bugaboo when it comes to installing it on the Pi, but once you've got it on there you can image your SD card and have a ready-to-roll distro that's lean and mean.

</comment></comment></comment><comment><USER28> Can someone put in Layman's terms what the change entails and why it would be the end of Linux?

<comment><USER29> It's not the end of Linux. It's the final death of the idea that Linux should just idly continue to act like a clone of some vague Unix of old because it was better when men were men and their computers had obscure RISC processors with billions of registers.

Linux hasn't really been that way for an incredibly long time, but a large proportion of the userbase still cling to this notion, some for ideological reasons, and some out of sentimentality.

<comment><USER30> Systemd is most problematic because of its own-everything monolithic nature, and the changing of kernel interfaces to match. The vast majority of Linux systems are not desktops, and probably not servers either. The kernel and the core utilities around it (like init) should be designed with multiple implementations and all machine types in mind. This means phones, set top boxes, TVs, routers, automation hardware, supercomputers, and more.

If the core utilities around the kernel and the interfaces they use are well- documented, designed, and modular, then different machine types can pick and choose the components they need, and easily write their own by opening a well- defined API on something in /dev. If systemd continues to take over and alternatives smothered, very quickly the kernel will become useless to any system where systemd makes no sense, especially non-desktop embedded systems.

<comment><USER31> Your comment is the very definition of FUD. You have nonfacts just baseless fear.

<comment><USER30> I developed and marketed my own embedded Linux products. It would have been difficult to do some of the customizations I did if the kernel, DHCP server, logging system, HAL/udev, etc. were all adapted to the one systemd way of doing things with dbus.

</comment></comment></comment></comment></comment><comment><USER32> we've already upgraded to RHEL7 here. ppl didnt know systemd too well but it works (im the only guy who knew systemd. heck ppl didnt even know of journald).

Now im not saying that i like systemd in general - for the reasons the author explains I don't really like it. Systemd could have been way better if it wasnt for the political shit and attempts to take control over distros, kernel, etc.

That said it has some features I do like. Likewise for kdbus. This is like Chrome vs Firefox. People would like to support Firefox better. But Chrome and Google apps do enough of what they want _right now_ to go with the solution they don't really approve of - I'll say it again: it works.

</comment><comment><USER33> It has been said before, but it deserves mention, there are alternatives to Systemd out there, like OpenRC which has been around for a while, and other, newer projects like Uselessd.

Of course, whether those other options will be as well supported and developed as systemd remains to be seen.

<comment><USER34> I am no expert on this but apparently when Gentoo developers tried integrating OpenRC they ran into too many bugs.

[http://blogs.gnome.org/ovitters/2013/09/25/gnome-and- loginds...](http://blogs.gnome.org/ovitters/2013/09/25/gnome-and- logindsystemd-thoughts/)

<comment><USER16> > ...apparently when Gentoo developers tried integrating OpenRC they ran into > too many bugs.

You are certainly no expert on this.

I've been using Gentoo since 1.4... back in 2003, maybe 2004. I vaguely remember when _Stable Gentoo_ was switched to OpenRC, which happened in mid _2011_. Unstable Gentoo (which I ran -and still run- on my laptop) switched to OpenRC much earlier [but that date I cannot remember].

What the first topic in the blog post that you linked to is _really_ saying is:

"We Gnome developers _still_ claim that recent Gnomes don't require systemd. We stand by this assertion. Recent Gnomes only require init and system management daemons that behave exactly like systemd in pretty much every aspect; they don't actually require you to have systemd installed.

It's a pity that developers don't want to spend time re-working their init and system management software to be systemd clones. If they did, then the world would _finally_ understand why we Gnome developers continue to assert that Gnome doesn't require systemd."

<comment> jude- That's the fundamental problem with DBus-exposed interfaces: they're APIs that get marketed as abstractions. APIs don't leave much room for different interpretations, meaning you'll end up rewriting the component you're trying to avoid using in the first place.

<comment><USER16> I'm not sure what you're saying here. If you want to avoid using a particular piece of software, but need to adhere to its API, you're _going_ to either reimplement parts of it, or use someone else's reimplementation. There's really no way around that. It's a fundamental problem shared by all software.

<comment> jude- Exactly. I'm (obliquely) affirming your argument that the commonly thrown- around excuse of "you don't need systemd, you just need something that implements its DBus interfaces" is a distinction without a difference.

<comment><USER35> Is a system running Linux + Wine no different than Windows, just because it implements the same Win32 API? Is FreeBSD the same as Linux, since they both implement POSIX?

There are many ways to implement the same APIs.

<comment><USER36> Wine is not reliable enough for mission-critical software. Nor is running a nominally POSIX-compliant program that hasn't been tested on FreeBSD. If a project claims not to hard-depend on systemd, I would not trust that unless it's actually, y'know, tested on something that isn't systemd.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER37> Two distros that don't use systemd:

[http://www.voidlinux.eu/](http://www.voidlinux.eu/)

[http://crux.nu/](http://crux.nu/)

Void linux is a rolling release, has binary packages, uses a very good package manager (even better than pacman) and the community is small but very friendly.

Crux is very minimal, and you have to compile your packages.

I use Void Linux, and am very happy with it.

<comment><USER38> Thanks for that information.

I am using Arch at the moment but I spent the last 45 minutes trying to fix a network problem which involved fighting with journalctl to see what was actually happening.

Void linux looks like a great alternative.

<comment><USER37> I assure you void is a great aternative to Arch. I was with arch until systemd, and it feels like home, only smaller, with Arch.

</comment></comment></comment><comment><USER39> Wow. The UNIX-haters are out in force. Apparently proven, real-world tested code is no longer a relevant feature to a lot of people. Well, "Those who do not understand Unix are condemned to reinvent it, poorly."

But enough about the technical distractions. Why is systemd so important? It's certainly not technical quality or design (even if some of the ideas are useful, the implementation is junk). There is a far more important reason, that some of you have noticed parts of, at least tangentially.

From this very thread: "systemd makes a lot of sense for embedded systems". Yes, it does, andor, and it's all because of this: "kdbus: efficient IPC". The thing is, kdbus/dbus isn't really that great for a lot of things - you have to bounce through the kernel at a minimum, and there is and encode/decode steps that add some overhead. It might be useful for some types of _IPC_ , but it is replacing what should be a fast and simple _library call_ in many places.

Now, here's where a lot of you are going to start calling me crazy or "obviously wrong", both without actually addressing the key claim, which was is probably better explained by stevel over in the Gentoo forums[1]. I encourage reading that post.

The goal with all of this is not technology related at all: 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.

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 coopyleft requirements. If this was proprietary software, you would call that kind of behavior "stealing".

(seriously, the linked comment below does a much better job of explaining this)

[1] [http://forums.gentoo.org/viewtopic-p-7645524.html#7645524](http://forums.gentoo.org/viewtopic-p-7645524.html#7645524)

<comment><USER40> Where do you get UNIX-haters? I read systemd haters which begets Linux haters but UNIX? No.

Besides, Linux is no longer a UNIX-like system. Linux is now only Linux unto itself with UNIX-similarities.

<comment><USER39> Just look at this very thread - there are numerous posts trashing the "old ways" of UNIX.

It has been a common thread throughout the systemd mess. Lennart himself is _very_ strongly outspoken against any use of shell scripting (not just in init).

<comment><USER41> Sigh. Obligatory reference to [http://0pointer.de/blog/projects/the-biggest- myths.html](http://0pointer.de/blog/projects/the-biggest-myths.html):

"Myth: systemd is incompatible with shell scripts. This is entirely bogus. We just don't use them for the boot process, because we believe they aren't the best tool for that specific purpose, but that doesn't mean systemd was incompatible with them. You can easily run shell scripts as systemd services, heck, you can run scripts written in any language as systemd services, systemd doesn't care the slightest bit what's inside your executable. Moreover, we heavily use shell scripts for our own purposes, for installing, building, testing systemd. And you can stick your scripts in the early boot process, use them for normal services, you can run them at latest shutdown, there are practically no limits."

<comment> vezzy-fnord Note that your quote doesn't contradict pdkl95's statement. Nowhere did they say that systemd _prevents_ you from starting shell scripts, but that the developers have a (strong?) revulsion towards them.

</comment></comment></comment></comment></comment><comment><USER42> The real reason people are pissed about systemd is it's intentionally designed to take over the entire system. Conveniently is also maintained by RedHat. So yes, it is a hostile takeover of Linux.

</comment><comment><USER43> Are there any reliable VPS providers that offer FreeBSD?

<comment><USER44> There are quite a few. Some decent ones I have heard good things about:

* rootbsd.net * arp networks * vultr

There are quite a few cheap-ish dedicated server vendors out there that can either be ordered with FreeBSD or provide some means to install it yourself.

<comment><USER45> I have had good luck with arpnetworks. So far only noticed one outage in three years of use. Have had good network and CPU performance. They don't do tech support for things inside your operating system, but they are always helpful when I ask them to do things on their end.

</comment></comment></comment><comment><USER46> The description of systemd - monolithic, taking on function of other things - sounds like the X server. Look what's happening now with Wayland, and look at how hard it's been to get there (hint Wayland is only possible as a result of all the driver architecture changes over the last 5-8 years). It's hard to undo this kind of thing once it's entrenched, but it can be done.

<comment><USER47> Look how many platforms X supports, how many paradigm shifts has survived. systemd already has a less flexible architecture _by design_ that an ancient system, so in the future it'll be difficult to untangle.

</comment></comment><comment><USER48> Does systemd increase the security of the OS or reduce it? For example, does it allow currently-separated processes to dip into each others' memory space? I would appreciate a birds-eye view from someone familiar with the security ramifications of systemd.

Would not the incorporation of many loosely-coupled but individually secure mechanisms into a single monolithic mechanism be useful to an entity whose purpose was to monitor communications, view/modify systems unbeknownst to sysadmins and users, etc.? Yes, I'm talking about the NSA et al. I reference the following which also brings up Red Hat's control of Linux:

"Julian Assange: Debian Is Owned By The NSA"

[http://igurublog.wordpress.com/2014/04/08/julian-assange- deb...](http://igurublog.wordpress.com/2014/04/08/julian-assange-debian-is- owned-by-the-nsa/)

</comment><comment><USER49> He rants about systemd, then talks about liking CoreOS, which uses systemd for everything. He is contradicting himself, but I'm genuinely not sure of why.

<comment><USER50> Read it again:

Author is saying that CoreOS is a good solution _because you use it with heavily isolated containers_. Thus, any use of systemd is unable to screw up hosted applications. For that use case, it makes sense, whereas in more general use, systemd wants to get all up in everything.

<comment><USER51> He responds to that here as well: [http://blog.lusis.org/blog/2014/11/21/a-few- things/](http://blog.lusis.org/blog/2014/11/21/a-few-things/)

</comment></comment></comment><comment><USER52> I think that SystemD is an attempt to put Linux on par with Mac OSX and Windows 8.X, and attempts to do that haven't worked in the past.

Like Canonical changing Ubuntu to use Unity and Mir, so that it was easier to use on tablets and modern PCs. It just doesn't seem to work and it drove me to Lubuntu and use LDXE with an XP like Start Menu UI.

Ubuntu doesn't use SystemD yet, but I got a feeling it will.

I am downloading Fedora 20 because it has SystemD in it, so I get some idea what it is like.

But I think every Linux company wants to become another Apple for some reason. They saw how *BSD Unix went into making Mac OSX, and they want to try and copy that with their Linux distro and right now this SystemD seems like a path to that.

It is like a change from free and open source to commercial Linux. We all saw how Lindows/Linspire tried that and failed.

I might go to ReactOS, HaikuOS, AROS when one of them gets finished to the right level that it is ready for prime time. All they need to do is port Apache2, PHP, MySQL and other stuff to those operating systems to be used in VPS hosts so they can be used as alternative to Linux with SystemD if it ever breaks things.

<comment><USER53> Which Ubuntu release did you find to be using Mir as a default?

<comment><USER52> I think it was on a tablet, not on the desktop by default yet.

It is kind of confusing.

</comment></comment></comment><comment><USER54> New to this entire brouhaha, but I'm concerned because my entire production stack runs on Linux. At some point devops is not going to be able to do things the old way.

Is there a link where one can read about the rationale of why systemd was needed? Perhaps by the person who started off the initial project?

<comment><USER55> is this a joke? \- "my entire production..." you're a devops engineer? \- "link where one can read about the rational.." with good grammar? \- "why systemd was needed... " ok you lost me there \- "the person who started off the initial project?" and you've been hidden under a rock for the past 10 years??

[http://0pointer.net/blog/](http://0pointer.net/blog/) \- is his blog

are you seriously trying to tell me that someone is going to have to explain what a "container" is by comparing with chroots? :D how have you been running your production stack all these years if you didn't have an internet connection under your rock :)

</comment></comment><comment><USER56> As a rule of thumb, it's good to distrust products when you know that the politics behind have been loud enough to be heard widely. But the sharp razor which will decide if systemd is better is simplicity. Those who have switched, is systemd _simpler_ than sysvInit?

<comment><USER57> Simplicity is not necessarily a good measure of suitability. See this: [http://mjg59.dreamwidth.org/2414.html](http://mjg59.dreamwidth.org/2414.html)

There are some aspects of systemd that are simpler than sysvinit. The mess of double-forking and PID files goes away, and process management is much more reliable. Setting up containers for services is much simpler. Unit files are generally much simpler than a given init script.

I think more useful adages ("boned wisdom for weak teeth" \- AB) would be, "Everything should be as simple as possible, but no simpler," and "Simple things should be simple, complex things should be possible." There is an enormous amount of complexity inherent in the problem of initializing and monitoring a modern OS. If your solution to this is actually simple, it is probably wrong or incomplete. How you manage that complexity and what your abstraction layers are are the vital questions.

</comment></comment><comment><USER58> [https://news.ycombinator.com/item?id=8641839](https://news.ycombinator.com/item?id=8641839) is a much needed response to this discussion.

</comment><comment><USER59> It seems like most systemd problems boil down to: shit this will take more than half an hour to understand, I'm a lazy admin and don't feel like learning something new.

</comment><comment><USER51> The author responds to a number of the comments here: [http://blog.lusis.org/blog/2014/11/21/a-few- things/](http://blog.lusis.org/blog/2014/11/21/a-few-things/)

</comment><comment><USER60> You know the blog is just a clickbait when it capitalizes the name of the project wrong.

(on the wiki, the big Spelling header could not be more explicit)

</comment><comment><USER61> > Freebsd has jails which is a much more baked technology and implementation > than LXC

Disagree!

1\. FreeBSD has nothing like cgroups or namespaces. You can't apply cpu or memory limits to a whole jail, only individual processes in that jail.

2\. it is early days for virtual network cards and ethernet bridging and jails: you have to recompile kernel to add VIMAGE.

<comment><USER62> You've been able to apply cpu and memory limits to entire jails since 10.0 was released through the rctl mechanism.

<comment><USER61> Thanks. I don't think it changes my point - various attempts were made to implement this feature since Freebsd 6 - almost 9 years ago, for some reason these were incomplete or ignored.

FreeBSD 10 was released only this year. For reference, Heroku began in 2007, using resource limits with LXC... a whopping 7 years ago.

</comment></comment></comment><comment><USER63> Going against the "divide et impera" principle, "do just one thing, and do it well", "everything is a text file" (configurations and logs) and "pipes" which are very natural idiom, _in a UNIX-like system which has been built upon these principles_ , is just bad engineering, shallow understanding and, perhaps, too high ambitions of knowing better how to fix what isn't broken.

The question _why_ do we have this project and why there is such a buzz is more interesting.

But the answers doesn't belong to realms of system design or engineering, they are in more obscure notions of "business strategies" and "sales techniques".

It is a text-book example how to sell - "show them that they have a problem they didn't realize before, and give them the one and only fix". Fine. Except that the problem doesn't exist outside discussions of "why this product is good - it solves this and that".

Another thing is that it is an excellent strategy to "create a niche for oneself". Look, we are the ones who give you a solution (to a problem which doesn't exist). We are "world leader" \- look, we have lots of experts, web- presence, lines of code.

There are so many examples in "parallel worlds", beginning with _eco_ products or "fair-trade" coffee, you name it.

But you see, lots of people don't need an _eco_ or _environmental-friendly_ daemon which does everything "the right way". No, thank you.

Another thing, back to system design. If Windows has "registry" and there are millions copies of Windows everywhere, or Mac has that settings daemon (from which GNOME Gsettings has been copied) it doesn't mean that these design decisions are superior to plain old text configs. You could compile them and have an "intermediate storage" to gain a 5% more efficiency for application startup times, but this is, again, not a fundamental problem. Being able to use regular expressions on configuration and logs without any restriction are much more fundamental. And memorizig all the details of all these xxxxctl insted of saying something like

       $ grep -R ^sysctl /etc

or whatever I need, is just an additional unnecessary burden.

Most of the problems systemd is trying to "solve" does not exist. At least not BSD, AIX, Solaris, you name it. And, of course, there never been any problem with syslog, init or cron. They were *good-enough".

<comment><USER64> If the problems with sysvinit are all imaginary then why has every other UNIX replaced it?

Mac OS X has launchd for 10 years now.

Solaris 10 replaced sysvinit with SMF.

Don't have any experience with AIX but the documentation says it has a "System Resource Controller" with a "srcmstr" daemon to manage services; though it looks like it runs on top of something sysvinit-like:

[http://www-01.ibm.com/support/knowledgecenter/ssw_aix_61/com...](http://www-01.ibm.com/support/knowledgecenter/ssw_aix_61/com.ibm.aix.osdevice/sysrescon.htm?lang=en)

BSDs have generally never used sysvinit, although they do have shell-based service management.

So actually none of the particular examples you cite use purely sysvinit to manage services.

And it's also quite obvious that there are use-cases where reliable and fast service management are very important on servers.

One is containers, where you may run 10000 of them on a single host, and you have to reboot the host some time too, so you don't want to delay the start up of all those containers by loads of slow and racy shell scripts. Or even better, you want to have socket activated containers that don't actually start until they are needed.

[https://www.getpantheon.com/blog/pantheon-running- over-50000...](https://www.getpantheon.com/blog/pantheon-running- over-500000-systemd-units)

Another is hyperscale servers: There are now really small ARM and x86 based servers and you can put 4-500 of those in a single rack. That means a lot more individual servers to admin, and failure modes that are relatively rare in current server rooms will become an order of magnitude less rare, so more robust OS level service management is helpful.

<comment><USER65> Problem 0: Yes sysinit has problems but systemd brings even more problems (journalctl, PID 1, dependancy Hell ++, undeterministic bootup process)

Systemd is a broken silver bullet for handling the decrease in quality of packaging.

There are problems with sysinit: the first one is the missing link between devs and syadmins in companies: people known as packagers.

For a sysinit to work well shell scripts, permissions, where resources are located, the dependency management has to be done with art and expertise. It is a human job with human which are:

1) a very skilled rare resource, 2) not identified has needed by companies, 3) company's software QA is shitty (it has barely the level it works for me (tm) of quality

Talking about debian, which is considered the distribution with the most talented packagers debian has 2 flows in this domain:

* too rigid: projects goes for logical units of packaging that are consistent and organization of assets in packages that can ease maintaining. Debian has its guideline that makes them «fix» poorly packaged softwares like lateX, python, ruby: cutting language distro in at least runtime, dev, extra. Debian packagers are often debian experts, not upstream software package experts and they first break some stuffs (latex is so poorly packaged on debian it can be considered broken), AND it adds more works

* too much features typical linux distro compared to BSD are pacakging fucking more packages in their core resulting in more work; less attentions to the details and conflicts of functionality/overlaps. This result in more resource drained from the packagers. Like we have 4 shells considered OK for writing shell related stuff, when they have only one: «sh».

The problem of linux vs BSD is symbolized by the systemd vs sysinit: linux is an OS of devops that are super devops, poor coders and sysadmins, BSD is an OS of sysadmins and devs that are good sysadmins and devs, but no devops.

And we still lack in 2014 of maintainer, sysadmins and coders of quality.

Linux/Gnome ... FSF projects are not sustainable in these conditions. They think of free software has an infinite resource of benevolence. And they exponentially overblow the works required for maintaining, deploying ... thus they are mathematically doomed to die under their own weight.

I see BSD as a calvinist boring protestant community turned towards humility doing what is right and linuces as catholic exhuberant rockstars over spending the good will of developers without thinking of the future.

Being lutherian, I still dream of THE right OS that would less terse than BSD.

</comment></comment></comment><comment><USER66> Everything I read about SystemD is negative. Negative on the technology, negative on the people who created it. Nothing positive.

How is it that SystemD is about to dominate the market? Who is driving SystemD adoption, and why?

<comment><USER67> It's so terrible (literally the devil incarnate, sacrifice your offspring now) that it's already been adopted by:

\- Arch Linux

\- Fedora/RHEL

\- openSUSE/SLES

\- Mageia

\- NixOS

\- CoreOS

\- Sabayon

\- Debian and Ubuntu in the near future

> Everything I read about SystemD is negative. Negative on the technology, > negative on the people who created it. Nothing positive.

There's a vocal group that seem to think it's some Red Hat conspiracy to destroy Linux and take over the world. You don't hear the positives because people either don't care about init systems (as long as their distro continues to work) and happy programmers are generally silent on the issue.

The fact that the article says that Solaris is the 'best of breed stack right now' and also suggests CoreOS (apparently not knowing they use Systemd) should speak volumes...

<comment><USER68> Well, in fairness, I did have a RH chap tell me to my face several weeks ago that Linux needs to replicate the Windows registry model and stop using the /etc text file approach. So I have a certain sympathy for the idea of Red Hat conspiracy (what is a company anyway but a conspiracy to produce work & products for hire?).

<comment><USER69> ROFLMAO... more and more applications in Windows are moving _AWAY_ from the registry.. other than install/uninstall notations created by the installer, very few recent apps use the registry. Most use the global ProgramData or user's AppData paths for configuration. It simply works.

I don't hate the registry... I'm just not in a hurry to see Linux adopt it. What's so bad about /etc/app/config or ~/.config/app/config? It works in pretty much every platform (though the paths may be slightly different). Windows does have both roaming and local data directories, which can be pretty nice (if you don't bloat them).

</comment></comment></comment></comment><comment><USER40> I've been saying some of these things since systemd came out and typically get downvoted into oblivion so here this article makes HN's front page.

His implication about switching to FreeBSD is a good one and I notice a decent influx of Linux admins switching to FreeBSD showing up on every forum I visit.

</comment><comment><USER70> I used Gentoo for 10 years, and I can't figure out how to get a Systemd configuration working with XFCE. Indeed, most of the existing documentation has greatly slowed me down.

<comment><USER31> Fwiw, my friend runs Ubuntu for 10 years and he cannot understand gentoo for the life of him. He thinks it is absurd people want to keep recompiling stuff.

<comment><USER71> People don't want to recompile stuff, they want to configure the software to their liking. Basically it's very enjoyable if you're a developer.

And FWIW with Gentoo/Portage you can create and install binary packages.

</comment></comment></comment><comment><USER72> for me it seems that most people complaining/crying out loud come from a system admin perspective.

For example the author of this blog article does not seem to have contribute a lot of code to any project and is more "just" an admin and not a dev.

for me it looks like they don't like new stuff love the linux world how they knew it and don't want things to get easier or even change.

<comment><USER73> >for me it seems that most people complaining/crying out loud come from a system admin perspective.

Sysadmins complaining about it is pretty important, as at the end of the day _they_ are the ones who are maintaining the systems.

Personally, I have a strong dislike for Systemd. I don't believe it's the right replacement for sysvinit however it's not going away so we'll have to try and work around its warts. Also, currently it's buggy as hell so I will use Centos 6/Ubuntu 14.04 for a few more years to see if the many problems are sorted by then.

<comment><USER31> That's exactly as intended. People who want to help out systemd will use latestbsoftware, report bugs and fix it because you know thats how free software works.

People who don't want to help out use the most recent stable and have nothing to worry about.

<comment><USER73> TBH with the current direction systemd is going in I'll probably end up using one of the BSDs. However, I doubt I'd be able to use a *BSD in a production environment as I am a contractor and all of my clients only want Linux.</comment></comment></comment></comment>


If Your Job's Just a Job - <AUTHOR> http://www.tbray.org/ongoing/When/200x/2009/06/14/The-4-Hour-Workweek

<comment><USER2> If anyone who read Four Hour Work Week came away feeling slightly dirty about Ferriss's route to success, I'd recommend reading "The Art of Learning" by Josh Waitzkin. Josh is the chess prodigy featured in the movie "Searching for Bobby Fischer" and later became a world champion in Tai Chi/Push Hands.

Where Ferriss finds ways to quickly exploit weaknesses in the system to win, Waitzkin wins by constantly analyzing _himself_ to find weaknesses and improving until he is truly the best at what he does.

Both books were good, and both strategies have their time and place, but "The Art of Learning" resonated with me a little more, and I suspect it might do the same with other folks here. It feels a little more "noble".

On a side note, I think "resourcefulness", the desirable trait in a startup founder, is probably a 50/50 split between the two: recognizing and exploiting weakness/opportunity, backed up by substance and hard work.

<comment><USER3> The best players play to win. <http://www.sirlin.net/articles/playing-to-win- part-1.html>

<comment><USER4> That's exactly what I thought of when I read that. However, it's possible to find your own satisfaction in less ruthless codes... as long as you accept that others may do whatever the letter of the rules allows.

For instance, I play Gen, but accept that I must fight a lot of Ryus and Sagats.

</comment></comment></comment><comment><USER5> _If you're not happy with your job, instead of re-organizing your life so you can be a vagabond, consider looking for a more interesting line of work._

Why? This statement makes the fallacy that happiness comes from the _type_ and _duration_ of labor, rather the overall _fruits_ of any labor you choose to do. If being a "vagabond" (in the Tim Ferriss sense) results in more net happiness than that attained by someone who loves their "interesting line of work" then being a vagabond is still advantageous.

 _I also have grave doubts that there are that many business models out their that will support this sort of hands-off management._

The most popular business models clearly do. The majority of large and mid- sized companies - as well as many small ones - operate with "hands-off management" from the people who take most of the profits. Shareholders do little work for the corporations in which they hold shares but still, often, collect the largest profits. Even ignoring shareholders, well structured companies over a certain size are not reliant on _obligatory_ day-to-day management by a single person. That's what tiers of management and boards are for. If Steve Ballmer chose to run away to Thailand for a few months to go kick boxing, Microsoft isn't going to stop producing a tubload of cash each month.

 _Among other things, the people doing the actual real work may become disgruntled at the absentee landlord. But hey, if it works for you..._

Why? There's almost no precedent for this except in situations where the workers are being mistreated or underpaid. Larry Ellison spends lots of time on his yacht, flying planes, and whatever, but are Oracle employees generally "disgruntled" by this? If so, what rationale would they have unless they believed Ellison's permanent presence were to have a significant effect on their paychecks or job security?

<comment><USER6> How can you be sure that you will _love_ some kinda work, I mean, can't there be people who may not love any kinda work. Why is it a given that there is some work/profession which has been ordained for you !

</comment></comment><comment><USER7> I haven't read the 4 hour workweek book, but the two pieces of advice 1) Money is a means not an end 2) Doing less e-mail, are good bits. But I'm not sure why this is worthy of repeating. Doesn't everyone know this? Personally I'm way more interested in how people discovered their passions. I love reading biographies of people on Wikipedia that shows chronologically how they came to realize or produce something great. What was it that led them to their ideas? How did they become so productive? Did they meet someone, read something, or had some other type of epiphany? If you love your job and want to do more, then I doubt money and e-mail are the things that hold you back. If you love your job you will be in the office everyday because it is an essential part that brings you happiness.

<comment><USER8> > I'm way more interested in how people discovered their passions.

I found mine between the couch cushions.

> But I'm not sure why this is worthy of repeating.

I think that this piece is basically a dig at the book, with a few nice things being said to make a small effort at "balance".

</comment></comment><comment><USER9> > He accomplished this by gaming the weigh-in rules to compete in a division > two below his actual weight, and gaming the scoring rules to win by pushing > lighter opponents out of the ring.

Heh, someone has never played competitive sports with weight classes before.

I find this (very short) review comes off more or less that the author wasn't comfortable with Ferris himself and the manner he 'plays the game' so to speak, therefore making the book itself of little value.

<comment><USER10> _Heh, someone has never played competitive sports with weight classes before._

He wasn't referring to the standard process of cutting weight and rehydrating after the weigh-in - he was referring to the fact that Ferriss won a kickboxing championship without actually doing any kickboxing, but rather exploiting a bit of a loophole in the rules that said your opponents forfeit if they fall out of the ring.

The way he won it is tainted with significant doucheitude, and I cannot imagine anyone I respect doing it. On top of that, how could you feel any pride whatsoever having won the title in such a way?

It seems like everything the guy writes should be suffixed with "but not really": "How to Gain 30lbs of muscle in a month (but not really)", "How to Learn a Language in 3 Weeks (but not really)", "How to Win the Chinese Kickboxing Championship (but not really)."

<comment><USER11> That's ridiculous! You can't claim that someone isn't "playing fair" if they are playing by the rules! If you don't like the rules, then either change them or don't play the game.

In Kendo (japanese swordfighting) I was taught that if for any reason my opponent was able to knock my weapon out of my hands, I should immediately body-check him so he couldn't use his sword and try to force him outside the combat area. It's a fighting technique: you do what you need to do (within the rules if it's a game) to win!

<comment><USER10> _That's ridiculous! You can't claim that someone isn't "playing fair" if they are playing by the rules!_

I didn't claim he wasn't "playing by the rules"; I claimed he was "playing like a douche."

</comment></comment></comment></comment><comment><USER12> I think the post is just a cheap shot based on the title of the book.

We all have to do things that we don't like as part of our jobs. The point of the book is that by becoming more efficient and effective at what you _don't like_ you can spend more time doing what you _do like_. If you classify what you like as "work", that's fine, do more of the work you like. I doubt the book author would have a problem with that.

</comment><comment><USER13> If the only two things the author got out of the 4HWW was (1) money is a means not an end, and (2) do less emailing, then the author should try actually reading the book instead of skimming it.

You can't "review" a book you haven't read.

<comment><USER14> ... but you can "comment" on an article you haven't read.

</comment></comment><comment><USER15> This seems to be a sort of afterthought from his "On Carving Your Initials" speech: [http://www.tbray.org/ongoing/When/200x/2009/06/12/Convocatio...](http://www.tbray.org/ongoing/When/200x/2009/06/12/Convocation)

</comment><comment><USER16> One way to have a 4 hour work week is to sell a self help book like 4 hour work week and watching the suckers dig in while you reap the benefits.

Success! At least one person has done it so you know it works.

As a criticism I've seen at least one person who got to the top by being honest. Just don't follow every rule to the letter till it gives you a dissadvantage.</comment>


Ask HN: What Are Your Top Five Predictions for 2020-2030? - <AUTHOR> Please limit your predictions to five, thanks. <comment><AUTHOR> Mine are :- 1\. More Video. Also, A Real Youtube Competitor will Emerge. 2\. Rise of a Big Robotics Company. 3\. More Extreme Weather Events. 4\. US vs. China Trade War Intensifies. 5\. More Nationalism</comment>


Really interesting use of Augmented Reality - <AUTHOR> http://videogamesrepublic.com/?p=5128

<comment><USER2> An implementation of "Godzilla" would be great. You'd have a much larger game mat that you'd spread out on the living room floor. You'd need to have goggles and some way of registering foot and hand positions. You'd try to stomp as many humans and their forces before they lower your health.

A "record movie" feature in the game would have a lot of entertainment value. People could watch their monster-avatar selves demolish the city of their choice.

Natal would be a great interface for this.

</comment><comment><USER3> This could go over well with existing tabletops like Warhammer. It might be neat to have a handheld device that could overlay stats on the units that are in play. Maybe even synchronize some sound effects and overlay some visual effects as well.

<comment><USER4> Or MTG - have it show 3D models of creatures, etc, and when you tap them they actually attack. Cast a spell, and you get to see its effects.

</comment></comment><comment><USER5> It won't be long till AR is used for porn.</comment>


Show HN: Playbook - Share your hookups with your bros (at PennApps) - <AUTHOR> http://theplaybookapp.com/ <comment><USER2> Is this a fucking joke? Who needs this? This is not only classless, but from a purely objective standpoint, who would actually use this thing? With your target demographic in mind, it seems to me like it will turn into the greasiest, skeeziest, cesspool on the entire internet in no time.

<comment><AUTHOR> Just broke 100 signups.

<comment><USER2> You may eventually realize that not all publicity is good publicity.

...bro.

</comment></comment></comment><comment><USER3> I think if you have something that is "Show HN" there should be more to see than just a landing page. I'd like to see how you built it, what it looks like, something more than just "enter your email address and we'll notify you when it's available."

<comment><AUTHOR> we have to wait for the app to be published :/

</comment></comment><comment><USER4> This is extremely disrespectful to women. They aren't objects.

<comment><AUTHOR> Guys are already talking to each other about the girls they hookup with -- we just made the process more digital and secure.

<comment><USER5> Just because people are already doing some sort of negative and disrespectful thing, that doesn't make it alright to build a tool to actively encourage people to continue doing it.

<comment><AUTHOR> Are you saying that talking with your closest friends about the girls you've been with is negative and disrespectful?

<comment><USER6> To put it succinctly: a gentleman doesn't kiss and tell.

It's disrespectful of the trust that your partner places in you by engaging in what is fundamentally a private interaction to share it publicly without their permission.

</comment></comment></comment></comment></comment><comment><USER7> This is satire of how misogynistic geek culture can be, right? Because this couldn't possibly be serious?

right?

<comment><USER8> I'm dreadfully worried that this is NOT satire.

tisk tisk pennApps...

</comment></comment><comment><USER9> This is the most disgusting, gratuitous display of misogyny I have ever seen.

<comment><USER7> Gailees lists his facebook on his profile: <https://www.facebook.com/davefontenot>

Let me just say, David, that you're a cretin. You're why my female friends don't want shit to do with geek culture. You're poison in the well.

<comment><USER10> Do NOT make this community about persecution -- I see no reason to list his Facebook profile in this thread other than to harass -- even if he has it listed in his profile.

</comment></comment></comment><comment><USER11> Signed up. I want to see this train wreck first-hand.

</comment><comment><USER12> Well.. you got the comments section stirred up with just a landing page and an idea. Good job.

Ignoring the moral issue of this.. can't this be replicated by making a private group on Facebook? Your friends are already on Facebook.. and the girls probably are too!

</comment><comment><USER13> If my girlfriend ever found out I was using this she would literally kill me.

<comment><USER14> It that is true, you are in an abusive relationship.

Leave.

<comment><AUTHOR> I think that the US is just really afraid to talk openly about our relationships with other people.

<comment><USER5> I agree with you completely. The problem is that I don't think the behavior you're encouraging solves that.

Talking about hookups is almost always about objectification: it's encouraging people to talk openly about relationships, yes, but relationships between people and objects of sexual gratification rather than between actual mature adults.

<comment><USER14> I always find it fascinating how the prevailing christian attitudes about sex have spread so well to the entire population, even as that same population is less and less christian.

In this case, you are implying that mature adults sex lives should not include one night stands with people they have no emotional attachment to. Why?

<comment><USER15> You miss the point, deliberately and repeatedly. This is glorifying the treating of women as objects, and bragging about having done so.

</comment></comment></comment></comment></comment></comment><comment><USER16> How will you monetize this??

<comment><AUTHOR> This one is an app at this point; not a business, but we will be looking at doing different things. Currently, instead of liking a friend's "play" or hookup, you can buy them a beer from a local microbrewery to get delivered to their door!

</comment></comment><comment><USER17> How secure is this!?

<comment><AUTHOR> As secure as your best friends that you choose to add on the app are. You choose who has access to your stream of "plays."

</comment></comment><comment><USER18> girls are going to love this

<comment><AUTHOR> We are looking into making it gender-neutral, because outside of it being targeted at guys, we totally think this is something girls would love to use too!

<comment><USER19> Even with the background picture of the woman?

<comment><AUTHOR> Before we publish to the App Store, we will be finding a more gender-neutral but still eye-catching background image for the launch page :)</comment></comment></comment></comment>


Svsh: process supervision shell - <AUTHOR> https://ido50.github.io/Svsh

<comment><USER2> Looks neat, but I'm a little confused at what it's goal is. How is this different from, for example, supervisord?

<comment><USER3> I'm not 100% sure cause the details are a little weirdly worded. But I believe this is for monitoring already running tools like supervisord.

<comment><AUTHOR> I guess I could try to post a better description of it on the website. The text basically assumes the reader is familiar with the supported supervisors, and that's probably not the best assumption.</comment></comment></comment>


Do you understand the difference between retained and shallow heap in Java? - <AUTHOR> http://plumbr.eu/blog/how-much-memory-what-is-retained-heap

<comment><USER2> So, I thought the whole point of managed languages was to abstract this stuff away from the programmer. If I have to have a deep understanding of the JVM's implementation details to do anything non-trivial I may as well just stick with C. At least C makes it very clear as to what is going on.

<comment><USER3> > I thought the whole point of managed languages was to abstract this stuff > away from the programmer.

It's a leaky abstraction.

<comment><USER2> Yeah, I know... I'm just ranting I suppose.</comment></comment></comment>


Callbacks in C++ using template functors (1994) - <AUTHOR> http://www.tutok.sk/fastgl/callback.html <comment><USER2> Classic from Rich Hickey. I remember mugging this up for a C++ interview in late 96. It was state of the art then.

</comment><comment><USER3> Holyshit I wrote something almost identical to this for an embedded C++ project in around 2010.</comment>