Linux greybeards release beta of systemd-free Debian fork

http://www.theregister.co.uk/2016/04/29/systemd_free_debian_fork_devuan_reaches_beta/

by based2 • 10 years ago

147 188 10 years ago

theregister.co.uk

CSDude• 10 years ago

Init should be just this: http://git.suckless.org/sinit/tree/sinit.c , systemd incorparates too much funcitonality IMO, I cant get used to it. Well, but its a free world, I have even written a Go init, some guy did Rust based, and upstart is still being used by Ubuntu 14.04, I like choices, and happy to see this alternative as well.

geofft7• 10 years ago

1. If the only thing you needed from init was to reap reparented zombie processes and manage to not die, why have init at all? Why not tell the kernel to skip reparenting processes (and just reap them internally if their parent is dead) and not treat pid 1 as special, allowing it to exit? That's less userspace code and less kernel code.

2. Speaking of kernel code, have you looked at how much stuff is going on in the kernel? Why does pid 1 get this much scrutiny, but the kernel, which definitely can't die, gets a free pass? On my system there are 77 kernel threads. Seventy-seven! What are they all doing??

And there are plenty of alternative kernels you can use. Multiple ones even have Linux binary compatibility.

3. Is the argument for suckless init the same as that for EWONTFIX init (on which it is based)? If so, would a fork of systemd that split it into two processes, PID 1 that reaps reparented zombies and tells PID 2 about it (over a one-way pipe, so PID 1 has no increased attack surface), be an acceptable option?

chris_wot48• 10 years ago

For point 2, I think you can use:

  ps -eLf | grep '\['

I put in a grep root for good measure:

  ps -eLf | grep '\[' | grep root

Incidentally, why would a zombie process need to be reparented? Surely it has just not been removed from the process table and all that needs to occur is to remove it fully... I can understand reparenting an orphan process, but a zombie process?

witty_username• 10 years ago

functionality

That is, actually doing the work of init i.e. spawning daemons and services.

marcosdumay2• 10 years ago

Well, it makes sense that whatever spawns the daemons also keeps track of them, restarts them on failure, controls containers, disposes of zombie processes, and helps debugging init scripts.

It makes no sense for such tool to control network interfaces, logging, device sync, power mode changes, and well... I'm certainly forgetting one or two dozen systemd modules.

JdeBP10• 10 years ago

Ahem!

* https://news.ycombinator.com/item?id=8904429

* http://unix.stackexchange.com/a/197472/5132

chris_wot48• 10 years ago

Those StackExchange answers are awesome.

lottin4• 10 years ago

Nice, but from the users' standpoint it would've been better if they had worked with Debian rather than rolling out their own distro.

etiam• 10 years ago

The problem sort of is that (the rest of) Debian wouldn't work with them on this.

tmptmp3• 10 years ago

You are quite right, as the overall Debian's stance on systemd was far from praiseworthy. They allowed themselves to be pushed around too far by the "end-user" (desktop-users) mentality of the gnome and few such other upstreams.

This is a very good news. Indeed it would have better if the Debian had been a little bit more flexible and sensible on this issue.

Congrats Devuan folks! My heartfelt thanks too.

Edit: added my thanks and clarification for desktop-user.

GFK_of_xmaspast• 10 years ago

I thought the Debian people had a vote and the choice was to go with systemd.

criddell2• 10 years ago

Do users care though? I don't. I select a Linux distro based on how popular it is because frankly they are all pretty excellent these days.

I go for popular distros because it's more likely that bugs are found and community help is available.

I also do very little customization. If the default window system is Gnome, that's what I use. If it's KDE or something else, that's fine too. Again, they are all good enough.

I use Linux, I'm a huge fan of it, but I'm not dogmatic. Using Linux is a way for me to get work done, but it isn't the goal itself.

lawl• 10 years ago

Some care. I don't think it'll ever be "mainstream". But I certainly care. I switched from Arch to Gentoo and systemd was one of the reasons.

And no, I don't really expect Gentoo to be something most people use. But to me that's the beauty of open source. If someone, or a group of people care enough, they can make it happen, if someone else finds it useful too doesn't necessarily matter.

lottin4• 10 years ago

Exactly, I use Debian because it has a large user base and community. But that's precisely why it's important than the mainstream distributions continue to support the traditional Unix init. People don't want to have to switch to some obscure distribution simply to avoid systemd.

mwcampbell• 10 years ago

Counterpoint from a former systemd skeptic who now likes it: http://changelog.complete.org/archives/9655-count-me-as-a-sy...

tyingq• 10 years ago

It's a reasonable counterpoint, but limited to the part of systemd that manages starting and stopping services.

It also takes over virtual terminals, syslog services, login management, network interface configuration, dhcp, system time, udev device management, containers (machined, dbus, cgroups).

That, to me, is where more of the concern lies.

ktRolster2• 10 years ago

Indeed, trying to get a full understanding of systemd is not easy, it's so large. It's like trying to understand a large piece of corporate software.

Nursie• 10 years ago

I like systemd from the perspective of a service-writer/maintainer, the service files are nice and simple and don't have the repeated boilerplate of old init scripts.

However I still dislike its monolithic nature, its folding in of journaling and udev, and all the rest of the creep.

nailer• 10 years ago

Ditto the first part. I have a .service file for haproxy, one for my node app, one for rethinkdb, they generally just work.

I understand people that dislike monoliths, but I also appreciate the DRY nature of systemd - the System V, bash, cron, at, various process monitors, syslog combo was a lot of code with a lot of overlap. I'd expect systemd is actually smaller in LoC that what it replaced.

ausjke• 10 years ago

Glad to see this coming out.

https://www.devuan.org

Downloading via torrent now, it's 10G via torrent? Anyways it seems the file server there is under pressure now.

I for one don't want to deal with systemd from the start. Never liked its intrusive, all-in-one, hard to debug design approach.

jcoffland3• 10 years ago

Yeah, I dislike systemd but I'm not going to abandon the Debian Foundation over it.

stephenr4• 10 years ago

This is the real point. I have my issues with systemd.

For example, I just had an interesting discussion on GH with Varnish packers about changing a daemon arg (in that case, the bind address/port).

The way systemd "recommends" to change the arguments passed to a daemon is to write a drop-in file (i.e. /etc/systemd/system/service-name.service.d/something.conf) that overwrites the ExecStart line. To do so, you have to do:

    [Service]
    ExecStart=
    ExecStart=<original ExecStart line with wanted changes>

For Varnish, this isn't the end of the world - it only needs a few arguments - but it's still a lot less simple than the pre-systemd "standard" for Debian, which is to use a /etc/defaults/<service> file to allow changing daemon args via variables. This method can be still used (via either EnvironmentFile, or via built-in systemd "Environment=" statements) but the former is specifically mentioned as "not recommended" by Lennart, and the use of Environment= in service files seems very much like a feature that no one is keen to acknowledge or make use of, and it has it's own issues, as the way variables, white space, escaping etc are handled is specific to systemd and not immediately intuitive for someone used to a shell environment.

But as you said - those issues, are not enough to give up on the benefits of Debian stable. In theory, all packages in Debian stable that need an init script are supposed to still supply a sysvinit script (I was actually quite surprised by how many packages rely on systemd's ability to load sysvinit scripts and don't ship their own systemd service file) so you could choose to use sysvinit instead of systemd, for now at least.

I do appreciate the theoretical goal - you describe how your daemon should be started, and let pid1 handle the specifics of actually starting it - to me that makes it much easier for a lot more people to create reliable daemon packages.

I just wish the project wasn't taking such a "everything plus the kitchen sink" approach.

cm38• 10 years ago

One major problem with systemd is that beta software is released as stable and incorporated in distros. I've just realized that systemd-coredumpd is used to save crashes in the journal and write the files somewhere to /var.

This has the problem that I have to vacuum or nuke the journal if I want to remove knowledge of past crashes because coredumpctl tool has no delete command. And coredumpctl hard-codes GDB as the debugger.

To fix all of this I've overwritten the systctl.d file and made it write somewhere I know and can find without the use of an unfinished tool.

I have also regularly had it happen that bootup would intermittently hang up or shutdown as well. There are also unfixed warnings and errors during shutdown on multiple machines.

My conclusion is that systemd uses the broader population for beta testing, even if you don't follow Fedora Rawhide or Arch rolling.

chris_wot48• 10 years ago

Try setting Storage=external in coredump.conf [1] - you seem to have it set to both, which I have to agree is probably less than ideal.

1. https://www.freedesktop.org/software/systemd/man/coredump.co...

cm38• 10 years ago

Nope. I've scoured previous bug report and discussions and the only sure way was to prevent systemd from swallowing core dumps. It had the nice side effect that I learned the format string and configured it to my personal needs. But having to reverse engineer in order to remove crashes is not stable software and just a tech preview.

If I wanted to be cynical, I'd believe anything coming out of systemd, regardless of quality, is accepted as the new way while discarding existing ways as obsolete.

I should add to my startup hangup remark that I never before had a startup problem that was intermittent with plain old stupid init from 1994 up until systemd became the distro default.

makomk2• 10 years ago

Same thing with Lennart's previous project PulseAudio which also has no real stable releases and basically relies on distros to try and take the beta-quality upstream releases and turn them into something that actually works reliably. (My favorite was the PulseAudio release that shipped with a change that was literally incomplete, changing the interal resampling API without changing all the resamplers affected. Crashing ensued. Was rolled back in the next release, but that came with a whole new set of feature patches with the same level of QA applied.)

It probably doesn't help that they're both heavily developed by Red Hat, who see taking open source software and turning it into something stable and end-user viable as their secret sauce that justifies paying them lots of money.

cm38• 10 years ago

I've been able to avoid Pulseaudio and therefore didn't experience the issues it had in the past but I've heard that the new maintainers fixed stuff and are doing a better job, though I still don't use it and hence don't have first hand experience.

I wouldn't blame Red Hat per se but the GNOME fall back they ship with RHEL is a joke and in no way resembles the old GNOME desktop Pixar was used to.

forgotpwtomain• 10 years ago

It's 2016 and I still have issues with pulseaudio, frankly I was somewhat surprised they let him replace init with systemd - given the terrible mess that pulseaudio has been historically.

rwmj• 10 years ago

I agree with the rest of your post but I can assure you it's not the policy of Red Hat to release unstable upstream software. I am a Red Hat employee and I'm as annoyed as anyone that systemd doesn't have separate upstream development and stable releases.

Also what's with the stupid versioning of systemd/udev? Having a single version number is simply a dumb idea.

INTPenis4• 10 years ago

I can't believe anyone would like to keep using sysvinit-scripts or RC-scripts.

I love bash, I love nitpicking about how to use bash along with the other bash nazis in #bash@freenode. But I would never put myself through sysvinit again. I thoroughly enjoy using distros like CentOS 7, Fedora 23, RHEL7. They're a joy to manage and work with, in part thanks to Systemd.

I never want to debug, troubleshoot, or even look at another sysvinit-script again. :)

lottin4• 10 years ago

I've been using Linux for the last 15 years and I don't remember ever having to fiddle with any init scripts.

chris_wot48• 10 years ago

I used to. It wasn't fun, but it wasn't terrible either. And I probably overused rc.local...

guitarbill• 10 years ago

Until you install something like Gerrit, or GoCD, which have absolutely appalling init scripts. And then you find out that e.g. Gerrit sets some ulimits in the init script. Yuck!

CaptSpify• 10 years ago

If all systemd did was sysvinit-script replacement, I'd be 100% behind it. I agree with you, sysvinit-scripts are terrible. It's all the other stuff, and the lack of modularity, that makes me dislike it.

themartorana• 10 years ago

Agreed. And upstart didn't suck for that.

hiddennetwork3• 10 years ago

BSD handles all of this better than Linux. Text file. Easy. Linux has grown far too "complex". I like how OpenBSD adds modern touches yet keeps the OS free from binary blobs. systemd addresses some issues, but at the cost of complexity. I dislike binary blobs in my systems, hence, my servers run OpenBSD.

chris_wot48• 10 years ago

What binary blobs are you referring to? Aside from the, uh, binaries that run systemd, systemd services, and systemd utilities, the only other thing that is binary that I'm aware of is the binary log file, which can be reconfigured to revert to text if you so desire.

Sanddancer2• 10 years ago

I'd argue that one of the biggest things that made sysvinit so ugly was that distro maintainers didn't enforce any type of startup script hygiene. Take a look at BSD-style init scripts some time. They're beautiful in their simplicity and readability. They source a common set of functions, have well-defined variables to control execution, and end up with a length about that of systemd units, without sacrificing the power of shell scripting. Systemd threw the baby out with the bathwater, and just makes diagnosing boot problems all that more difficult when you have to start tracing through magic symlinks.

alwaysdownvoted• 10 years ago

You nailed it.

I rarely make use of the BSD scripts provided but I like them as simple examples of how various services are intended to be run.

I find there is a certain amount of uniformity and consistency and arguably coherence to the rc.d system.

INTPenis4• 10 years ago

I actually came from FreeBSD to Debian 8 years ago and the funny thing is that I don't remember editing rc scripts anywhere near as often as I edited sysvinit scripts on Debian.

But that could easily be explained by the average complexity of services increasing along with my career path into Linux and Devops.

I don't remember any clear differences between sysvinit and rc, the scripting is still left up to the user which means code style can diverge from whatever the maintainers had in mind.

Systemd, albeit a binary blob, at least eliminates that from the equation and breaks down services into a limited number of types that it handles equally every time.

I actually liked upstart too. :) I might sound mad for saying that but as a user of Linux upstart gave me just what I wanted.

Bottom line is that I think discussions about scripting style have no place in the context of service management. Services should be dealt with in a simple way like upstart or systemd. If you want to add more complexity you can write a start script for the service but that should not be the norm.

Freaky• 10 years ago

The Design and Implementation of the NetBSD rc.d system - http://www.mewburn.net/luke/talks/auug-2003/

vidarh3• 10 years ago

Why in the world would you need to "start tracing through magic symlinks" with Systemd?

If you mean to figure out what was actually executed for a unit "systemctl cat [service name]" will tell you the full path of each file systemd processed for that service and what content was pulled from it.

pdkl953• 10 years ago

sysvinit-script

OpenRC fixes a lot of that, without adding the giant pile of dependencies that systemd imposes. As someone who is already comfortable with bash, OpenRC scripts should be easy.

I can't believe anyone would like to keep using sysvinit-scripts or RC-scripts.

There are more options than sticking with Debian's ancient scripts.

The larger problem is that init is only a tiny part of systemd. Systemd's mandatory link-time dependencies and tightly-coupled (monolithic) features are trying to be an entire wrapper around important parts of the kernel. Even if you like the init features of systemd, you should be looking at all the changes; do you really want to depend on all of systemd's features in the future? Do you enjoy depending on a moving target that changes at the whim of the systemd cabal and their reputation for WONTFIXing anything that they don't understand or haven't considered as a use case?

chris_wot48• 10 years ago

"Systemd's mandatory link-time dependencies and tightly-coupled (monolithic) features are trying to be an entire wrapper around important parts of the kernel."

What parts of the kernel are you referring to? Genuinely interested...

vidarh3• 10 years ago

The larger problem is that init is only a tiny part of systemd.

That's because you can't reasonably fix the many problems with sysvinit (or OpenRC) without also providing a proper process manager, and dependency system that does far more than just trigger scripts in the right order.

The biggest problem with init is that it's just init.

Do you enjoy depending on a moving target that changes at the whim of the systemd cabal and their reputation for WONTFIXing anything that they don't understand or haven't considered as a use case?

I don't enjoy that, but the alternative of relying on sysvinit or OpenRC is so many times worse.

Give me a better alternative, and I'll throw Systemd out of the window immediately. But to be better it will need to at a minimum:

- Be able to sanely handle service restarts, including configurable behaviour on failure.

- Be able to ensure service output is sanely logged.

- Be able to reliably keep track of processes belonging to a service even if they double fork or the prent process dies.

- Have a dependency system that allows starting and stopping services automatically depending on the status of other services, the availability of a directory or file.

- Be able to schedule execution (like cron) but still subject them to the process management and dependency rules.

.. to mention some.

bitwize2• 10 years ago

Sysvinit scripts were shit. But as the AVGN might say, systemd took that shit sandwich and served it up with a side of buffalo vomit. It doesn't solve the "rat's nest of dependencies" problem, it makes it worse. Because now you have more moving parts which hard-depend on each other in various intricate ways and introduce unreliability into a formerly reliable startup process, combining the worst aspects of monolithic software with the worst aspects of modular software. Because development of components of systemd takes place in a bubble, there's not much room for feedback -- like is this a sane way to do system logging, network discovery, process group management, etc. That's easy to integrate with other pieces of software from the community? The systemd way to solve the integration issues is "pressure the major distros to adopt systemd. Then they'll HAVE to integrate with us!"

It's possible to run sysvinit sanely, by having a few startup scripts that source in the appropriate boilerplate. Slackware's startup for instance has always been manageable.

kinkdr• 10 years ago

I am with you. I think it was long time for sysvinit scrips to die. But that doesn't mean that it should be replaced by systemd.

Systemd, like a lot of things coming out of redhat these days (firewalld), feels like bloatware to me.

Systemd, Firewalld, D-Bus, etc.. have no place in a server IMHO.

bpchaps2• 10 years ago

You must have a machine built for it, since I've had tons and tons of niggling little issues with systemd. Random, unnamed services sometimes fail to start or shutdown. One of systemd's big claim to awesomeness is that the start scripts run simultaneously, yet that's all thrown out the window when "Attempting to start, attempt 55 1m30s remaining" bullshit happens constantly and randomly, without enough information to debug properly.

The troubleshooting is ridiculous, too, because of the ridiculousness that comes with journald. Why does it feel the need to make me run an awfully formatted, and potentially complex set of parameters to print that? Especially considering that 9/10 times, the error message from journald is vague, ungreppable without -A or -B, and is often significantly shorter than the "use journald to print the error" output. So frustrating. I don't know how people deal with it.

That said, I'm not a fan of sysvinit, either, but I don't have to deal with as much smoke and mirror behavior with it.

chris_wot48• 10 years ago

Try installing syslogd then in journald.conf you just change storage to 1 and ForwardToSyslog to 1. That should hopefully get your old text based logs back.

itomato• 10 years ago

Lean unit syntax is not the defining feature of "System 500".

jcoffland3• 10 years ago

One giant program to rule them all was never the Unix way. System's monolithic architecture will be its downfall. Rather than stabilize I predict that systemd will get more and more complicated and eventualy fall due to unwieldy maintenance problems at which point someone will come up with a better more modular system.

userbinator• 10 years ago

It's ironic that one of the design goals (or was that just the marketing blurb) of systemd was "modularity".

mhurron2• 10 years ago

Systemds molecularity is 'we'll write a systemd module to handle that.'

geofft7• 10 years ago

Wasn't it? Multics was the modular system, Unix was the one where they said "That's silly, let's stick everything in a single kernel and not bother with all the flexibility because we don't need it."

People seem to ignore the kernel for some reason, but it is literally one giant program to rule them all, and it works very well. There have been many efforts to modularize it and move most of the complexity into independent units, and none have particularly worked out.

cfallin2• 10 years ago

The thing is that the kernel, while large, has one defined purpose -- to provide abstractions of hardware resources and arbitrate those resources between programs -- and thus conceptual simplicity, even if the source tree is huge. The POSIX syscall API is simple and the rest is just implementation.

In contrast, systemd is conceptually complex -- its scope continues to expand to manage every little nook and cranny and configurable tidbit in the system. (I'm not arguing one way or another, just pointing out that the type of complexity is different.)

marcosdumay2• 10 years ago

Modules worked. Fuse worked. DRI worked.

In kernel space, the global lock is gone, there is a central API that everybody else uses with code that mostly don't touch each other.

Linux is very modular. It is just not a microkernel, and that is probably more due to historical performance bottlenecks than to architectural concerns.

rubiquity• 10 years ago

The Linux kernel itself is a a monolithic kernel and it beat out Hurd which was a micro kernel. I would say Linux has a history of certain programs being monolithic being a good thing.

jcoffland3• 10 years ago

Hurd has failed after many years to produce a kernel even nearly as complete as Linux.

cyphar2• 10 years ago

Linux is a kernel. Monolithic and micro kernel architectures are a different problem to the Unix philosophy which specifically concerns design of userspace programs. I don't see how having pipes between kernel components would be a useful feature for a user.

Also, the userspace of GNU/Linux isn't called Linux. Linux isn't an operating system.

maaku• 10 years ago

Hurd was never a viable alternative for reasons that have nothing to do with the mono/micro distinction.

chris_wot48• 10 years ago

systemd has neither a monolithic architecture, nor does the systemd process itself do anything other than the following:

"[systemd] provides a system and service manager that runs as PID 1 and starts the rest of the system. systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux control groups, supports snapshotting and restoring of the system state, maintains mount and automount points and implements an elaborate transactional dependency-based service control logic." [1]

It comes with a set of utilities that do a lot of things. But that doesn't make it monolithic. In fact, systemd is actually extremely modular.

Ironically, systemd has not gotten any harder to use since it was introduced, at least IMHO, but I guess as with anything YMMV.

But this myth about systemd being monolithic, it really needs to stop because it's not correct.

1. https://freedesktop.org/wiki/Software/systemd/

pdkl953• 10 years ago

Systemd is the very definition of monolithic.

It comes with a set of utilities that do a lot of things

"monolithic" vs "modular" has isn't about the number of binaries you build. This is about coupling. Replacing systemd itself is the modularity we're talking about, which becomes harder to replace (less modular) every time systemd annexes another set of features.

Do those utilities use only well-defined, simple interfaces both to the system and between utilities? Can I replace one or more of those utilities with something else that implements those simple, stable, and well-defined interfaces? This what we mean by modularity; each piece of the complex system can be considered in isolation, with only minimal dependencies.

When I can remove systemd-PID-1, OR keep using systemd-PID-1 but replace those utilities with other tools, only then will systemd be a "modular" set of tools. If I have to recompile daemons to remove systemd dependencies (libsystemd-journal0, libsystemd-login0), those daemons are now part of the systemd monolith.

needs to stop

The only things that should stop are these attempts at changing word definitions.

cisstrd2• 10 years ago

No point in discussing systemd anymore quite frankly, it won, doubt that it's good it did, doubt the methods by which it won - I do both - but it won. Many of the major distributions are not really following the Unix philosophy anymore, heck, some stopped quite a long time ago to do so.

I run sever operating systems because I like to have the control, the minimalism, the elegance, the security. By trying to be more of a desktop orientated system, Linux actually looses what attracts people like myself to using it. I doubt they care, I don't think they have to, just as I don't have to use it.

"This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface."[1]

"Much of the power of the UNIX operating system comes from a style of program design that makes programs easy to use and, more important, easy to combine with other programs. This style has been called the use of software tools , and depends more on how the programs fit into the programming environment - how they can be used with other programs - than on how they are designed internally. But as the system has become commercially successful and has spread widely, this style has often been compromised, to the detriment of all users. Old programs have become encrusted with dubious features. Newer programs are not always written with attention to proper separation of function and design for interconnection. [...]

This style was based on the use of tools : using programs separately or in combination to get a job done, rather than doing it by hand, by monolithic self-sufficient subsystems, or by special-purpose, one-time programs. [...]

One thing that UNIX does not need is more features. It is successful in part because it has a small number of good ideas that work well together. Merely adding features does not make it easier for users to do things - it just makes the manual thicker. The right solution in the right place is always more effective than haphazard hacking."[2]

Still reading at this point? Great systemd free Linux distributions: Gentoo, Funtoo, Void Linux, among many others and there is also something called BSD (FreeBSD, OpenBSD, DragonflyBSD)... you should check it out. Also see www.suckless.org

[1] http://www.amazon.com/Quarter-Century-UNIX-Peter-Salus/dp/02...

[2] http://harmful.cat-v.org/cat-v/unix_prog_design.pdf

geofft7• 10 years ago

The "Unix philosophy" of text streams hasn't worked, and arguably never worked. BSD sockets aren't quite text streams. Terminals aren't quite text streams. Shellshock existed because someone decided that serializing functions via text streams was a good idea.

And if you look at the things you care about when running a daemon process -- sessions, controlling terminals, reliable restarts (without killing the wrong process), logging, starting dependencies in the right order, dropping privileges reliably etc. -- none of those things are good ideas that work well together. You can clearly see that things like double-forking and detaching from controlling terminals and syslog were all bolted on later, because the original system didn't work well, and the hacks don't work well either.

I run servers, and I'm excited about systemd because it makes all these things actually work. The Unix philosophy gave me tools that do one thing and kinda sorta do them okay, if you're lucky. systemd does multiple things, and it does them all well. Back when we ran FreeBSD, we had hard-coded sleeps to wait for the network and NFS to come up before we continued with boot, and we had regular problems with being too aggressive with those sorts of hacks and having machines that would get stuck before launching sshd. That is straight-up not a problem with systemd.

liveoneggs• 10 years ago

that's funny since mountcritremote and friends have been around sine, at least, 2000.

chris_wot48• 10 years ago

I'm a tad confused... you cite that famous Unix philosophy quote "This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together"... but I don't see how that doesn't apply to systemd?

Could you clarify?

michael_h• 10 years ago

I would imagine people have a hard time lumping: service management, logging, login, network management, etc together as 'one thing'. As a CentOS 7 user, I certainly wouldn't describe it as 'doing it well'.

I think people initially were pretty stoked for the revamped init process, and then it started heaping on a lot more stuff. Poettering's communication style and other history didn't help either.

khedoros• 10 years ago

"Systemd" isn't really a single program, it's a collection of 69 binaries, that together handle a number of functions that were traditionally handled by separately-developed pieces of software. It handles init, user logins, the console, system event logging, network interface configuration, time+date settings, and device management (udev was merged into Systemd in 2012, apparently).

A lot of those components have interdependencies (so they can't all be replaced piecemeal), and some userspace things like Gnome have come to have dependencies on things provided by parts of Systemd.

This has benefits: Things tied tighter together know more about the states of other parts, and that enables various optimizations. This has issues: Replacing individual components (if you don't like their behavior) becomes more difficult. Whether it's worth it or not seems like a philosophical debate.

cisstrd2• 10 years ago

The way systemd is structured it's next to impossible to use any parts of it outside of systemd, nomenclature is ridiculous (system daemon, what's that even supposed to mean?), it suffers greatly from feature creep, took over logging using a binary format, gained basic firewall controls , assimilated udev, incorporated a bootloader, ... and some additional things people took/take offence with: introduced to quickly, criticism was shut out instead of being debated, promises were broken, main developers behind it are quite arrogant and often ignorant when dealing with complaints/bugs... et cetera

there is a reason why Lennart is good in stirring up controversy, and it's not because everyone is just against him for no reason.

some further reading/links that might interest you:

https://lkml.org/lkml/2014/8/12/459

http://without-systemd.org/wiki/index.php/Arguments_against_...

http://www.infoworld.com/article/2608798/data-center/systemd...

http://www.infoworld.com/article/2608864/data-center/choose-...

http://www.infoworld.com/article/2608870/linux/you-have-your...

http://blog.darknedgy.net/technology/2015/10/11/0//

http://suckless.org/sucks/systemd

edit: systemd might be perfect for you or other people, I don't doubt that, it might make things easier for some, in some respects in might do some things better, but if the debate (as it is now) is whether it follows the unix philosophy or not, I don't think one can reasonably make the case that it does

eb0la• 10 years ago

I understand this because I can't get used to systemd. The learning curve should be better than rc.local for my taste.

Problem is systemd helps you booting fast and this is important both in the cloud (where every minute is a billed), and in telecom (where you have a stringent SLA to cover).

chris_wot48• 10 years ago

I would have thought a fast boot would be important to pretty much everyone...

gkya4• 10 years ago

Why? When I used Arch Linux I did not ever turn off my laptop, but hibernate it. I only ever booted it when I stupidly forgot to plug it in before the battery runs out. And 10-20 seconds spend on a sequential boot every 10-20 days is just no time. We spend at least 100x that time in the toilet every day.

meddlepal• 10 years ago

Meh. Systemd is pretty great. The *Nix purists hate it, but it solves a lot of problems and does it fairly consistently. I love using it in Fedora now where journald has basically replaced syslog completely.

ferrari86082• 10 years ago

Honestly journald is probably the only thing I don't really like about systemd and not for the reason you might think I'm about to say. I just rarely need to use it, because everything pretty much just works 99% of the time. So I end up forgetting how to use journalctl by the time I need it again and have to Google/man. Yeah I know, that's my own problem.

phantom_oracle• 10 years ago

Everybody mentions the Unix philosophy and that is a very valid point, but I would like to mention the freedom philosophy that open-source/Linux gives (or used to).

These guys who wanted systemd muscled their way in to get this software into the Debian system. They also adopted an "all or nothing" approach, depriving the greater community of something bigger than "do 1 thing and do it well", which is "freedom to do as you wish and choose".

Debian wouldn't have split had they maintained they made systemd opt-in or Poettering and co. maintained their own Debian-systemd version. That didn't gel well with Redhats version of what Open Source is, and so many were deprived of their freedom to NOT CHOOSE systemd BUT still use Debian.

For all the talk of how good/bad systemd is, the proponents for systemd should remember how they deprived others with the freedom to choose, no matter how "ignorant" or "backwards" the detractors are (or how "shit" sysvinit is).

the_why_of_y• 10 years ago

https://lists.debian.org/debian-devel-announce/2014/08/msg00...

d02• 10 years ago

It is amusing and unsurprising that, in 91 comments, the word Devuan is used a total of 2 times.

JdeBP10• 10 years ago

I've just mentioned it. So it's 3 now. (-:

What you observe is emblematic of the problem with Devuan, and a few of the Devuan people themselves acknowledge it. So much of the discussion centres upon "how to remove evil libsystemd0" and suchlike that what is lost is the supposedly intentional focus of the Devuan project on init freedom. That surely means the freedom to run systemd as well as to not run it.

* https://lists.dyne.org/lurker/message/20150208.110824.579d17...

And as you can see, that bleeds over into the press coverage seeking headline material.

lucideer• 10 years ago

Given the popularity of systemd as a discussion topic on HN, I'm surprised there isn't much about OpenRC[0].

Does anyone know if Devuan have given it any consideration?

[0] https://lwn.net/Articles/512719/

SwellJoe3• 10 years ago

Don't fork in anger.

There's such a long history of projects starting out of a desire to not change, and so many of them (most, I would wager) fizzle out soon after. Being against some specific feature or architectural change is not the same as having a future vision that can drive a person to work on something, for no pay, for years or decades. Anger fades...the people you're angry at ignore the new project, making it unsatisfying in terms of vengeance. And, again, it just doesn't stick with you the way a desire to do something new and better does.

I'm not even saying systemd is great (it's good and bad in all sorts of novel ways), I'm just saying that the people who are just reacting against it, when the industry and community has been so clear about it being the future they are passionate about, are unlikely to do anything more than spin their wheels for a few months, and then fade away (as a project, I hope they all stick around as contributors to OSS things).

JdeBP10• 10 years ago

This is press coverage. The actual announcement page is discussed at https://news.ycombinator.com/item?id=11593674 .

Linux greybeards release beta of systemd-free Debian fork

Related Stories