Hacker News Reader

The dispute here is philosophical. You want a distribution that follows The Unix Way. Where init does its little job and dbus does its little job and so on. Small, simple tools.

But there is another way. A way that believes that when you unite the core tools into one powerful process you can do cool things. These cool things have been proven, from the basics like faster boot times, to more advanced features like saving/restoring random seeds, automount, SELinix integration, and so on.

You are arguing "this isn't Unix!!!" but that is the whole point. You can win an argument with a mountain climber by pointing out he is going downhill, but not a skier; since for a skier, going downhill is the point. These Linux distributions are not temporarily disoriented mountain climbers accidentally heading away from Mt. Unix. They are deliberately skiing away from it at a high rate of speed. What they will find at the bottom of the slope is an interesting question, but simply pointing out that their strategy is bad for mountain climbing is neither here nor there.

What I am saying is, if you want to run an OS that believes in the Unix Philosophy, the shortest path is to install Unix. You are going to have about as much luck convincing Fedora that they ought to be Unix as you would convincing Redmond.

There's also a huge amount of redundancy inside, and between:

- SysVinit

- xinetd

- atd

- crond

- supervisor

- syslogd

and the other things systemd replaces.

'Small, single purpose tools' is Unix philosophy. But DRY is engineering philosophy. Each repeated piece of logic doubles the scope for errors.

One could also argue that 'doing one thing well' is handling services.

Systemd is controlled by Red Hat in a way in which critical system components including kernel haven't been controlled before. Not by single corporate entity.

That's what we know about this company from an old (2007) article:

> “When we rolled into Baghdad, we did it using open

> source,” General Justice continued. “It may come as a

> surprise to many of you, but the U.S. Army is “the” single

> largest install base for Red Hat Linux. I'm their largest customer.” [1]

It is better to go with a grass-roots solution, even the one technically inferior, that isn't being influenced by one single vendor or government (especially the one that has a tendency to indiscriminately infect other people's systems [2]).

Also, the Interface Stability Promise [3] by systemd team is just a promise, nothing more. Will Red Hat keep it if it is to decide at some point, that it no longer serves it's bottom line? I wonder if it can be considered legally binding.

[1] http://archive09.linux.com/feed/61302

[2] https://www.youtube.com/watch?v=vILAlhwUgIU

[3] http://www.freedesktop.org/wiki/Software/systemd/InterfaceSt...

Originally posted in this thread: https://news.ycombinator.com/item?id=7210064

You do understand that systemd is open source, right? If they decide to leverage their "control" into something the rest of the community doesn't like, we fork it.

> If they decide to leverage their "control" into something the rest of the community doesn't like, we fork it.

I hope so. My concern is that when we'll see systemd grow in size and more and more software depend on it's interfaces and components (as in GNOME with logind) at the certain point it could take an insurmountable amount of resources to maintain the fork. At this point it might be easier to give up on Linux and build around some other kernel and userland, I hope this will never happen, though.

Also, there is a difference between steering the developments in the preferred direction and outright destructive actions. As in https://en.wikipedia.org/wiki/Boiling_frog.

Interesting. Most of my work with Systemd has been via CoreOS, which is linked to GregKH, who was actually a SuSE dude.

> There's also a huge amount of redundancy inside, and between, SysVinit, atd, crond, supervisor, syslogd and the other things systemd replaces.

Such as? I'm pretty sure code shared between these systems lives in (or could easily be moved to) shared libraries, specifically to avoid this problem. But this is orthogonal to the design of the init system.

> But DRY is engineering philosophy. Each repeated piece of logic doubles the scope for errors.

While DRY is a great engineering principle within the scope of a single project, it doesn't justify excluding alternative implementations or entangling unrelated concerns. Specifically, DRY is not an excuse to forbid competing init system implementations, even though having more than one creates code redundancy. Moreover, "doubling the scope for errors" is meaningless from the user's perspective in the context of init systems: if there are X errors in systemd and Y errors in OpenRC, I will not be plagued by X+Y errors because I will only be running one of them at a time.

> One could also argue that 'doing one thing well' is handling services.

Ah, but "handling services" is not a well-defined task. To some, it means doing something like what sysvinit does--reaping orphaned processes and nothing more. To others, it means doing something like what systemd does--not only managing processes, but also managing devices, sessions, storage, power management, cgroups, system IPC, and network interfaces (and possibly more in the future).

> Specifically, DRY is not an excuse to forbid competing init system implementations

No-one is forbidding anything. You can run Debian with any init you choose. All we ("systemd proponents") want is that when upstream software decides to depend on something systemd provides, the debian maintainers don't have to (they can, if they feel like it) bend over backwards to replicate all systemd features for non-systemd platforms. Not demanding unpaid volunteers to do extra work is not the same thing as forbidding other init systems.

> You can run Debian with any init you choose.

When layers above the init system begin to make hard dependencies on it, this will be unavoidable in practice. This is the problem, since it either takes away my choice in init system, or requires unpaid volunteers to work on removing the dependency. Neither is desirable, and the grandparent's argument is that this could all have been avoided if the systemd developers had made better design choices.

Don't get me wrong, I want systemd to be an option. I like the idea of using cgroups to manage services. I do it every day. What I do not want, however, is for systemd to be a requirement for having a working system.

In userspace the Unix way is about disconnected utilities connected by pipes, but that hasn't been uniformly true at more of the "system" level (well, GNU did originally have that philosophy all the way through, even down to the kernel, but most Unixen haven't). The BSDs, for example, generally pride themselves on tighter coupling in the core OS than Linux has traditionally had. You can swap out some components from a default FreeBSD install, mostly more application-level ones (sendmail->postfix, clang->gcc), but the base system is integrated and does things one way, supporting some customization but not every kind of wholesale surgery you might want to do on it. You certainly can't swap out the init system for another one in any kind of supported way. The same is pretty much true of most other Unixen, such as Solaris (which has a pretty integrated init system, too).

I generally like the utilities+pipes model, but for system stuff it's seemed like false advertising to me for a long time anyway: the Linux kernel is monolithic, and many of its features (like cgroups) don't make much sense unless you have some userspace counterpart configuring/arbitrating them and a uniform way of making sure everything gets set up consistently. Traditionally this is handled by a tangle of shell scripts with distribution-specific conventions to make sure they don't step on each other's feet (Debian has piles of this in Debian policy). That's a unified system in practice, because you can't really arbitrarily rewrite the init/configure/reconfigure scripts or swap things out and still have a working system that is Debian-integrated. The scripts are literally separate files on disk, but in practice they're a spaghetti-code implementation of Debian Configuration, a monolithic system that handles initialization and services and package configuration and can't be modified without extreme care if you want things to keep working in the way all the other packages (and apt, dpkg-reconfigure, the diversions system, etc.) expect.

I would generally agree with this.

This philosophy (along with it being Free Software) is why I chose to migrate to Linux in the first place, so long ago: it was Unix. Ya, ya, "Unix-like", technically, due to the trademark on Unix.

That last statement is very strange:

> Fedora that they ought to be Unix

As somebody who wore an authentic Red Hat fedora for many years, this makes no sense. They've certainly called themselves a unix (in the generic, no trademark), and alternative to Unix (tm, aka Solaris, HP-UX, and others derived from Bell Labs IP) http://www.redhat.com/solutions/migration/migrate-from-unix-...

Wikipedia, on fedora: "OS family: Unix-like"

etc

When the term "Linux" is used in general, we mean a unix. The distinction has only ever a trademark thing.

So yes, refugees from Windows coming over to distros that have always been unix(-like) and trying to change them into the some sort of Windows-like junk is a problem. Some of us left that world of bad design little choice a long time ago, and have no intention of returning.

>When the term "Linux" is used in general, we mean a unix. The distinction has only ever a trademark thing.

Not really. The implementation of the kernel, userland features etc are quite different between traditional derived unices and Linux.

But it sure is a full blown POSIX.

Modern Linux distributions don't tend to honor "The UNIX philosophy" is a common theme these days, or so it is said by a vocal group. The GNU tools tend to be more feature rich then many of their counterparts, often with performance advantages and usability but more is more and more code tends to mean more bugs. Fedora is in many ways the leader of this, it and Ubuntu are symbolic to those folks.

The irony here is that they can go fork all of this stuff, it's not like none of it has forked before, if they don't like redhat they can run something else. Getting passed off and forking is also the UNIX way

> They've certainly called themselves a unix (in the generic, no trademark),

At one point, they probably were a Unix. But Unix as a place and Unix as a goal are two very different things. Both skiers and mountainclimbers find themselves at the tops of mountains.

> When the term "Linux" is used in general, we mean a unix.

You mean a Unix. I mean Linux. There is no "we".

> So yes, refugees from Windows coming over to distros that have always been unix(-like) and trying to change them into the some sort of Windows-like junk is a problem.

I don't believe you. Where are these vanguard Unix-style Linux distros? RHEL? Adopting systemd. Debian? Adopting systemd. SUSE? Adopting systemd. These are distributions from the days of old. They have formed a consensus that systemd-style Linux is the future.

I mean I think it is fair to say that the Linux community is divided on this issue. But characterizing the systemd/dbus/ufs folks as "Windows refugees" is totally inaccurate. Systemd has the backing of important community members of the Linux community.

>You are arguing "this isn't Unix!!!" but that is the whole point. You can win an argument with a mountain climber by pointing out he is going downhill, but not a skier; since for a skier, going downhill is the point.

Besides Linux is not UNIX either. And it's 2014 already, we found that some UNIX choices (like "don't dictate policy" in X Server were bad) and others led to underpowered tools.

It's not like we're still on text terminals, running 2-3 daemons at most, each with simple needs, and most of our work is constrained in the textual domain.

You just described both my development environment, and my production environment. Neither needs an overly complicated init system to work.

Really. You develop on the equivalent of a VT100 terminal? You don't use a web browser, or Xwindows, just a tty? Are you sure about that?

"The Unix Philosophy" is what everyone outside of Unix calls good software design. Using modular, decoupled components is standard industry practice for most developers with just a few years of experience, and these practices have evolved from half a century of engineering experience, such that we know how not to do things, even if there's no right way.

You wouldn't make a "god object" in C++ or Java for example, and nor would you tightly couple every class in your OOP system by refusing to provide abstraction boundaries. Well, you might do if you're strapped for time, but you would probably consider it a "hack" that needs amending.

That's how some people see systemd, as a hack. It's tightly coupled to the kernel it sits on, and it's a leaky abstraction that exposes much of that to userland processes that depend on the systemd api. In turn, those applications are (or will be) tightly coupled to linux.

> This accusation presupposes that a change was necessary or desired in the first place. Sorry, no, some of these things should not be tied together. Without that tying, we already have (known, tested) tools that cover most of these features.

This is the argument we've heard over and over again.

The problem with traditional unix init scripts, together with cron, acpid, inetd, etc is that you need a big brittle mess of shell scripts to tie it all together to form a system that actually works.

While the traditional approach may work alright for a static setup like a server that is booted once and stays on forever, it's not good enough for a desktop, laptop or mobile device. There may be changes in power (mains/battery/low power), network connectivity (ethernet, wifi, mobile) and connecting peripherals (including external disks) and lots of other things which need starting/stopping services or mounting/unmounting partitions. The amount of shell script glue to make these things work is unwieldy and doesn't really work that well.

And distribution maintainers have to make a choice, supporting more than one init system is going to be a burden that will hurt end users in the long run.

Finally, no one is forcing you to use a systemd based distribution. If OpenRC solves your problems, do go ahead and use Gentoo or another OpenRC based system.

You're forgetting the traction that OpenRC has gained in the past year, they have already implemented cgroup support and experimental process tracking and it's moving beyond simple shell scripts.

It doesn't have feature parity with systemd, but it has portability and it's more permissively licensed, and factoring the speed of development I anticipate that it has a bright future ahead of it.

Not to devalue systemd, but I suspect that a lot of Unix problems could be solved if Unix offered a better general-purpose solution for gluing things together other than "big brittle masses of shell scripts". In particular, shell itself is an ugly mess of weird syntax, gotchas, and corner cases.

Granted, init-related scripts have become complex along the years, but we may argue that happened because of the same type of reasoning that's now justifying the move to systemd: the need to do everything in one place and automagically.

You know, even if I would agree with you that "shell itself is an ugly mess of weird syntax, gotchas, and corner cases" that doesn't preclude init scripts from being redone in something other than shell.

"People who don't understand unix are bound to reinvent it, badly."

This has become the tag line for Linux, and unfortunately is starting to reach the previously sacred grounds of basic (server) infrastructure.

The problem is not that they're shell scripts. The problem is that they are not constrained in a way that makes it possible to parse them easily and know what the state of the system is expected to be before and after processing.

Instead you're forced to blindly execute them, and hope the script handles all the appropriate corner cases. In 20 years of maintaining Linux servers, it rarely goes more than days between situations where I come across init scripts that fails to account for some situation in ways that causes me aggravation.

It's not uncommon to come across init scripts that regularly fails to stop a service because it has no proper way of determining which pid the process has, for example.

Just the other day I had to deal with a server where the init scripts happily let 3 instances of a server process trying to operate on the same dataset; thankfully the app locked the files in questions and were just screeming bloody murder in its logs, but they were also all three competing for various resources. The init system of course had absolutely no way of telling that something had gone wrong.

The only solution to have a sane server setup with SysV-init is to not use it for anything but the basic tasks and to start a proper process monitor. Then I'd rather just get rid of init entirely, since you're pulling in a bunch of other code that can do almost all of init's tasks anyway.

I argue that shell scripts became more complicated because of quite the opposite of what you're claiming. The original Bourne shell already supported, piping, control structures, etc. So people thought, hey, why design a new init system that does everything properly when we can just push all this logic to shell scripts and have them act as glue?

It's the perfect example of "worse is better". They chose to keep the core init system simple, but as a result everything else became a complicated mess that doesn't handle corner cases properly. vidarh's comment is spot on.

Towards the idea that you can write them in another language, we in the Perl community ended up developing something of that nature[1]. It was originally intended to make writing daemons in Perl easier by pulling out common functionality (double fork and such), and giving a consistent clean interface. One of the bigger requested things was the ability to use it as basically the entire init script ([2] for an example).

[1] https://metacpan.org/pod/Daemon::Control [2] http://hashbang.ca/2012/04/16/wherein-i-realize-the-bliss-of...

> In particular, shell itself is an ugly mess of weird syntax, gotchas, and corner cases.

Just like C! (syntax is mostly OK though).

This is not coincidence.

If your modus operandi is "works 95% of the time" then you end up with C, shell and sysvinit collectively known as Unix.

Years passed and we discovered a bunch of things. Everyone agree that Bash syntax could be better, and C is not perfect either (that's why new languages like Rust are being developed). We didn't reach perfection a couple decades ago, so if someone want to try and replace the good old tools, I say "go on!": it would be exciting to see something better.

"While the traditional approach may work alright for a static setup like a server that is booted once and stays on forever, it's not good enough for a desktop, laptop or mobile device."

Sorry for sounding like a troll, but what you're saying is that the traditional approach works alright for setups where unix is actually good, and doesn't for setups where unix is actually crap.

Lets exclude mobile devices from this picture (because those don't use general purpose Linux distributions and arguably don't use unix at all, but a unix-kernel with specialized - non-unix - userspace) and concentrate on servers and desktops/laptops...

This systemd rage shows exactly why it's 2014 and while Linux is extensively used and trusted on the server side, it continues to limp along on peoples' desktops: it constantly reinvents the wheel (badly) with monolithic pieces of bloatware that are usually throw away tried-and-true solutions for unproven experiments. It throws away the old way of doing one thing and do it well in favor of components that do too much and become so complex that troubleshooting is a nightmare, exactly the kind of complaints we have about non-unix systems...

Need an example? Where are the people that used to criticize the Windows registry now? I just recently almost(1) had to throw away my entire home dir on Ubuntu just to try and reset Kontact, because in this day and age the configuration structure of this stuff is far worse, and it's almost impossible to separate one component's configuration files and folders from everything else. And I'm not even going to start ranting about how in the name of $DEITY a mail/calendar application needs MySQL running in the background and about there is not a single decent mail client for Linux right now. Mail... a decades-old problem!

I don't object to systemd itself, but I do object to systemd invading my servers that work just fine without it.

(1) "Almost" because I just learned to live with the occasional crashes and misbehavior caused by some pieces of old configuration still lingering somewhere.

> I don't object to systemd itself, but I do object to systemd invading my servers that work just fine without it.

I think the Lennart and the Red Hat engineering team have more important things to do than covertly install systemd on your server. Please quit with the hyperbole.

And there you exactly pinpoint the problem. The FLOSS movement used to be about caring about other people and projects. RedHat* and its employees only give a damn about their use-cases and the rest of the "community" can go to hell.

Which, of course is a logical stance to take for any corporation, however how easily everyone goes along with it is just appalling.

*this, of course, goes for every corporate entity, though some work with the community better than others.

How have I pinpointed the problem? I'm sorry - are you arguing that the RH guys should be covertly installing systemd in the parent posts servers?

Everyone "goes along with it" because they've evaluated it and decided it fits their uses cases too.

Redhat does not have the power to force anyone to adopt systemd.

And yet they do. They pay enough developers working on enough big projects to have the power to force adoption (not to mention the sponsoring of various other things, like infrastructure). By making it a hard dependency of Gnome for example (which in itself has turned into a 3rd-party developer hostile project, but that is another discussion entirely, but if you care, go read IgnorantGuru's bloggins)

So they're using end-user pressure (no systemd = no Gnome) to force adoption.

> The FLOSS movement used to be about caring about other people and projects.

Was it? I thought the primary driver was "I had a problem, this is the fix for my problem, maybe it helps you. I share this solution, you share yours.". Which basically holds true nowadays: Systemd solves Redhats problems. If it solves enough problems for enough people then it will prevail and other people might enhance it to fix their problems as well if they deem it a viable foundation. If it doesn't, then systemd will remain a niche solution that fixes redhats problems - which would totally be fine with me.

Given that we have the discussion on the debian list I'm inclined to believe that at least enough people think systemd is it to give it a push. If you don't like it stick with what you like or roll your own, but don't bitch and moan about redhat building a software that suits their use-case primarily and giving it away for free.

It would be nice if that held true. The problem isn't that RedHat developed a solution for their own problem, it's that their crowd are incredibly vocal about other people adopting it, even to the point of verbal attacks and attempted character assassinations against people who disagree with their stated aims. And of course, they will never admit publicly that systemd is developed to solve RedHat's problems, but will try to convince people that they have more noble aims, to solve the problems of the wider community. It's rhetoric. If they just dumped the software and let it's technical qualities speak for themselves, there wouldn't be so much drama.

As someone responsible for dozens of servers and 100+ vm's: The "tried-and-true" init solution is utter shit. It's duct-tape and band aid.

The current init solution does too much. Not in initd, but in the massive mess of scripts piled on top of it to get a working system.

You might want to take a look at FreeBSD's init and process management stuff. It's very clean, tidy, well engineered and doesn't involve sysvinit.

Or I just use systemd. My interest in getting rid of sysv init is less work, not having to to spend time dealing with an init system not supported by the Linux distro's we depend on.

Doesn't matter if FreeBSD's solution is better or cleaner or both, I'm afraid.

I think he was suggesting you try out FreeBSD, which I also recommend.

It's a solid server environment.

I have, but I have no reasons whatsoever to consider a switch - the potential upside is way too small to be worthwhile.

Why?

Because the potential upside is tiny. There's nothing in FreeBSD that I can't get in Linux that I have any particular need for. I'm sure there are features that are important and valuable to other people, but that doesn't help me.

That leaves near 0 benefit, and some unknown non-zero cost and risk associated with reduced experience with it, potential application incompatibilities and other unknowns, as well as a time cost of re-imaging servers and re-deploying vm's that would put tens of thousands on the cost side.

That's not exactly a cost-benefit situation that justifies spending time considering it.

If the FreeBSD guys develop something so amazingly much better than Linux that we could save lots of money by switching, that could change. I don't see that as very likely, though.

As it is, FreeBSD vs Linux is a bit like Coke vs Pepsi: If you have a preference, and its available, pick it, but it makes very little sense to expend lots of effort to replace one with the other.

In FreeBSD land, nobody wastes eons of time hacking out bad code experiments like systemd and then arguing between themselves on whether to distribute them.

It's a stable system you can rely on, year by year. That's not a small upside for a server platform.

This is precisely why I recently trashed my last few Linux machines and moved them over to FreeBSD. Well to be honest it was because it's absolutely tiresome not having a cohesive well documented system to rely on without the politics and collection of dickhead advocates and pseudo-religious leaders around my ass like mosquitos. Oh and ZFS, MAC, audit, decent ACL support, binary upgrades etc.

However I agree that there is little motivation to move if what you have works. I did mine during a hardware refresh.

> While the traditional approach may work alright for a static setup like a server that is booted once and stays on forever,

Actually, it's not. Unless the server also has no dynamic resources and nothing in userland ever changes.

I am not seeing any justification for why these tools HAVE to be a single, monolithic tool.

> script glue

That's what shell scripts[1] are FOR - they are the minimal glue that binds the large applications together. Besides, "big brittle mess" is a matter of opinion. Are you trying to tell me that this OpenRC script is a "mess" that needs to be replaced, taken from /etc/init.d/cupsd my current desktop:

    #!/sbin/runscript
    depend() {
        use net
        need dbus
        before nfs
        after logger
    }
    start() {
        ebegin "Starting cupsd"
        checkpath -q -d -m 0755 -o root:lp /run/cups
        checkpath -q -d -m 0511 -o lp:lpadmin /run/cups/certs
        start-stop-daemon --start --quiet --exec /usr/sbin/cupsd
        eend $?
    }
    stop() {
        ebegin "Stopping cupsd"
        start-stop-daemon --stop --quiet --exec /usr/sbin/cupsd
        eend $?
    }

Yes, some scripts get much longer, because they have more complicated needs. Even in an alternate environment such as systemd, those will always be complicated.

Things like changes in power or network addresses have been handled by OpenRC just fine (note: that was opinion, and systemd is better in some cases). More important,y those requirements do not suggest a need to bind tools together into one package, thoug; instead, they suggest a well-defined API* (or ABI) is needed. In OpenRC, that is simply another runlevel that you trigger on power-plug changes, etc.

Your argument seems to be that the using many tools is too complex (even though each tool in isolation is much simpler, reduced in scope, and is likely to have fewer bugs), while tying that functionality together is faster to develop (despite makng the problems into a complex, interdependent mess). Despite being labeled an "april fools joke", RFC 1925 [2] has important wisdom. In particular, there seem to be a lot of people ignoring Truth #5:

    It is always possible to agglutinate multiple separate problems
    into a single complex interdependent solution. In most cases
    this is a bad idea.

This is really a restatement of the UNIX design philosophy. Or maybe you're prefer this version, written by some old hackers you may have heard of[3]

    Even though the UNIX system introduces a number of innovative programs and
    techniques, no single program or idea makes it work well. Instead, what makes
    it effective is the approach to programming, a philosophy of using the computer.
    Although that philosophy can't be written down in a single sentence, at its heart
    is the idea that the power of a system comes more from the relationships among
    programs than from the programs themselves. Many UNIX programs do quite trivial
    things in isolation, but, combined with other programs, become general and useful
    tools.

This idea about keeping problems separated was true when those guys wrote UNIX in the first place, it was true wen Dijkstra suggested structured programming instead of "goto", it was true when Alan Kay suggested sending Messages between Objects for yet more encapsulation, and countless other examples throughout the history of software. It is still true now.

If you're having a hard time seeing this, I suggest you re-examine the problem and ask if an API could tie the pieces together, because it probably already exist in an unspecified form.

> Finally, no one is forcing you to use a systemd based distribution.

Of course not, but the monopolistic tactics being used to vertically integrate systemd IS forcing a problem - on purpose - with various other tools such as udev and gnome.

I'm obviously going to stick to Gentoo for desktop use, but even there, the disruption caused by systemd has caused a significant mess by breaking previously-working software on purpose.

--

1: If this is merely a hatred of BourneShell/BASH, I would actually understand that as it certainly has its layers of cruft and gotcha/wtf behavior. A new Little Language[4] with special support so the standard "init script" support to make the scripts trivially small in general case could be really nice.

2: http://www.ietf.org/rfc/rfc3439.txt

3: Brian W. Kernighan, Rob Pike, "The UNIX Programming Environment"

4: http://c2.com/cgi/wiki?LittleLanguage

To your openrc example: How do you statically determine what state the system is meant to be in this moment? Without doing that, you are unable to determine whether the system is in that state, and so unable to take corrective actions.

Furthermore, how do you even determine whether or not a service is still running? Init can not sanely do that for anything but the simplest cases, and a non-pid-1 process can not do that without the risk of losing the capability when that process dies (it's when, not if when you run more than a handful of servers or vms - when you have aggregate uptimes across a system measured in centuries and individual uptimes on most servers measured in years, it does not matter how robust a component has been written - you will see them fail, not necessarily of their own doing).

And a "new litle language" would not solve the issue unless it is purely declarative. A large part of the point is to be able to reason about system state, in part by being able to tell what the state should be, in part by being able to verify what the state actually is and operate on it (start/stop etc.). The former requires you to be able to statically determine the current intended state; the latter requires you to be able to accurately track which processes forms part of a service, even if the parent daemon dies and orphans a bunch of stuff (and in that case it is not helpful if the process trying to do this can die and orphan everything and lose the state information).

I'm pretty sure openrc uses (or has the option to use) cgroups for dealing with just this. Containerizing services isn't a new idea--Solaris and FreeBSD can do this already, for example.

Regardless of the init system, we've had the ability to control daemons with cgroups already for some time (cgexec and friends). Even in humble sysvinit, I can edit an initscript and ensure that the service it starts runs in a cgroup. Hypothetically, I could even do this inside of start-stop-daemon.

So my cups.service is:

  [Unit]
  Description=CUPS Printing Service


  [Service]
  ExecStart=/usr/sbin/cupsd -f
  PrivateTmp=true
  
  [Install]
  Also=cups.socket cups.path
  WantedBy=printer.target

It requires no extra things - Your cups script depends on checkpath and start-stop-daemon. More executables, more dependencies so yeah, I'd argue it suffers coupling and is a mess. You say that systemd makes things a "complex, interdependent mess" but it's better than the brittle dependent mess of the status quo. The usage of start-stop-daemon doesn't even ensure that the app was killed - it acts just as a killall <servicename>. It doesn't catch a process in a Disk Wait state or even if the process has trapped the SIGTERM - It's not just useless, it's deceptive as to its functionality.

People continually spew the line about the UNIX philosophy. If you want to use Unix, use Unix.

Linux is [becoming] better than Unix.

The other super awesome thing about systemd is: all errors and output from this service is captured by journald with 'cupsd' as the source.

Compare this to SysV init, where you have to manually wrap stuff in syslog calls (and the facility names are 'uucp' and 'news' rather than anything meaningful). <3

> Why do the anti-choice people refuse to recognize that other people might have different requirements.

Go build your own LFS systems if you want ultimate choice. You don't get to force upstream authors (who like systemd) and distribution developers (who like systemd) to do what you want.

> I'm sticking with what already works.

sysvinit works only if you combine incredibly low expectations with a bad case of Stockholm syndrome.

But you get to force upstream authors and distribution developers who would like to be able to use something else? Sure.

That is not a real argument on the merits of permitting this choice. It is just saying "nyah nyah I have the power and you do not."

Where did he indicate he wanted to force anyone?

Upstream authors are free to use whatever they like. It may impact which distributions wants to include their applications the more repackaging the distribution needs to do to include it, as a resource availability issue, but that's it.

Distribution developers already often substantially rework or write init scripts from scratch anyway, and that is exactly one of the reasons systemd is attractive:

It drastically cuts down the scripting boilerplate that otherwise has to be done or adapted to their distro for huge numbers of packages. It also contains most of the distro specific stuff outside of init.d, opening the door for lots more reuse.

But if you're an upstream developer and wants to ship sys-v init scripts, nobody has the power to stop you. Downstream will either simply write a systemd init file, or you might choose to add one if you like, or if you put LSB comments in your sys-v init file downstream might opt to use that with Systemd if they want to.

How exactly is upstream being forced to do anything?

How exactly are distribution developers being forced? If they are against their distributions decision, then they have the choice to package something else anyway and either ship it separately or fork the distro.

> But you get to force upstream authors and distribution developers who would like to be able to use something else? Sure.

How is any upstream developer forced to rely on systemd?

How is any distribution developer forced to rely on systemd?

The only people who are forced to use it are people (like me) who aren't prepared to put in the work of doing something else.

systemd runs as pid 0 so that it can relaunch processes when they die. If it were not pid 0, something would have to be managing it, which just leads to a "turtles all the way down" scenario. I'm not sure what you mean by "disconnecting from dbus," but I do know that some services require the d-bus service to be started before they run. A good init system must handle that. Similarly, a good init system needs to handle logging. It's frustrating to try to start a service and be unable to, and not know why because a message dumped to stderr went to /dev/null. I've been in this boat before and it's not fun.

Smart people at Red Hat spent a long time thinking about the problems faced by a modern init system. They looked at what had already been done, including the Mac init system, upstart, and the Solaris init system, and came up with something cool for Linux. I think it's sad that so many people are attacking this.

Anyway, nobody is forcing you to use anything. You can use Slackware or even one of the BSDs if you don't want systemd.

> I'm not sure what you mean by "disconnecting from dbus,"

dbus is a dependency of systemd itself, not just of the services that require it.

With kdbus (dbus in the kernel) on its way it is largely moot anyway.

"Disconnecting from dbus" at that point will not be very meaningful.

Moot? Putting dbus in the kernel is demented. Creating a hard dependency between it and a monolithic set of interdependent systemd code is even more demented.

It's like the Linux folks looked at Mac OS X and learned nothing.

Hint: Mac OS X handles more that systemd does, and still does it in a way that maintains separation of concerns between service management, configuration management, logging, and IPC.

There is no "turtles" issue here. Pid 1 is special - if it dies, the system panics. It is good design to keep pid 1 as simple as possible and put the complex job logic in a sub-process. There are only two things on unix which init must do: reap any children it inherits, and start something else to do the heavy lifting.

Even sysV init works this way. The current sysV init is very simple -- the invocation complexity lives in /etc/rc and the related rc.d scripts which operate as subprocesses.

"Smart people" is a silly thing to say. We're all smart people and sometimes smart people make poor technical decisions. Let the matter lay upon its technical merit, not upon empty platitudes.

You're really good at copying-and-pasting canned responses from previous comments... throwawayhugerandomnumber

> There is no "turtles" issue here. Pid 1 is special - if it dies, the system panics. It is good design to keep pid 1 as simple as possible and put the complex job logic in a sub-process. There are only two things on unix which init must do: reap any children it inherits, and start something else to do the heavy lifting.

If the kernel fucks up the system dies and the kernel is much larger than systemd. Either way most of systemd's functionality is in other subprocesses.

I take issue with the "nobody is forcing you" part. If you want to use Linux, and there are good reasons for it, it will likely be increasingly difficult to avoid systemd. You can argue whether that's "forcing" or just "applying pressure", but it's real.

That said, your other comments resonated with me. I used to fear systemd, and worried that losing the ability to hack on init guts shell scripts meant loosing the power to make my system work for me. I've since discovered that with systemd I don't feel the need to hack on init guts shell scripts like I used to, because it actually manages services intelligently on its own.

If a process dies I would rather it stay dead. Can systemd monitoring and auto-restart be globally disabled?

It's disabled by default, you need to enable it on a per-service basis.

Since there's different needs (I ansolutely really want my bind, httpd, crond and others to restart when they die - I have no desire to log in and do that manually), you just opt in to the auto restarting in the .service file - systemd does not restart anything by default.

The main issue is like it ever was with the UNIX wars, now Linux wars.

Cloning UNIX was not enough, now each distribution wants to "improve" UNIX on its own way.

Not sure how you see progress and innovation otherwise. Much of what is good in Linux comes from experimentation and people/distros 'doing their own thing' which sometime improved the ecosystem, and sometimes resulted in abandoned projects. But things have not stagnated.

As for UNIX, perhaps you're familiar with Plan 9? Some of the principal UNIX designers were unhappy with the result, so they went and worked on improving it. Nothing is good enough the first time around.

I lived through the UNIX wars, where POSIX doesn't mean a thing because each UNIX has its own version of standard and most complex applications still required OS specific APIs anyway.

None of the current UNIX descendants are all that similar to the original UNIX in the first place. Every single one have tried to improve on UNIX.

Hence the UNIX wars.

If anything, systemd may help rein some of that in but making service files a bit more common across the distros than the various special snowflakisms of each lot of init scripts. Or so we may hope.

If you have a system made up of small and simple tools, it can only so small and simple things. Imagine designing an airplane this way. It would never get off the ground.