The Debian init system general resolution returns
lwn.net
lwn.net
That said, we still keep saying the same shoddy sentiments from systemd proponents. "Can't we just move on?" "systemd hasn't had any problems for me. Don't like it? Leave it!", "This must be Canonical.", so on and so forth.
The /r/linux thread is a depressing clusterfuck of uninformed proponents, as always.
To take an analogy, plenty of Debian packages depend on libselinux1, because they feature optional selinux functionality, and not depending on libselinux1 would result in broken symbol tables. But most of these packages work perfectly fine without SELinux configured (as you might guess, since very few people actually have SELinux configured). Having libselinux1 on your system does not require you to use SELinux, and imo it would be unreasonable to complain that your system is now "infected" by SELinux because you can't uninstall libselinux1. It's just a library, like many others, and having it on your system doesn't impose policy requirements on you as administrator or user. Yet people are making exactly that argument with systemd, complaining that some systemd library or another is on their system and thereby "infecting" it. Rather than focusing on the more legitimate issue of which packages actually require systemd daemons to be configured/running.
Best i can tell everything happens via dbus (to be replaced with kdbus), and that again requires that systemd is running as pid 1 (as it will refuse to run as anything else, unless it is inside a namespace governed by another systemd as pid 1).
As an example, GNOME upstream requires logind if you don't want to rely on the bug-ridden and unmaintained ConsoleKit.
AFAIK the Debian GNOME team does not wish to enable the ConsoleKit backend on Linux due to not having enough resources to test it and nobody stepped up to maintain it. While they initially represented this fact with a dependency on systemd, but ultimately said dependency is now on libpam-systemd, which depends on systemd or systemd-shim.
So it's not like Debian teams are against what the GR proposes, but it's easy to see the GR as a way to force them to do work that they don't have the resources to do.
I wonder, how much difference does it make either way? What packages which only support systemd are we actually talking about, and how much work would it be to untie them?
Gnome, Wayland, KDE
> how much work would it be to untie them?
a lot
That's what I've found at least, their rc system is dead simple, like Arch used to be before they started making changes to allow for systemd. I miss the day's of arch's rc.conf.
No need to be quite so weaselly: 'Many disagree...' is something I'm pretty sure you could provide references for if pressed.
Also, what's so bad about coredumps? You can disable storing them in the journal, discarding them or saving them in a separate location (which is the default). Where coredumps are rare (which I guess it's the case in most of the deployments) it seem nice having a clean, standardized way to manage them.
This is the same thing I see about HTTP/2. It's good to finally remove a huge number of parsing errors and inefficiencies!
I've been solving this problem by writing a non-pretty printed JSON blob to one line in a log file. Structured, but still text and very easy to stream. I build a separate binary index that gives more efficient time based lookups, but it isn't needed to understand and process the log file.
systemd is the launchd for Linux I've been wanting for years.
systemd may or may not suck and I'm not discussing that aspect in this post. What definitely horribly sucks is product tying a desktop environment (you know, cut and paste, drag and drop, background images, window animations) deeply in with the earliest intricacies of the boot process.
Farther than that, I bet. It's pretty safe to assume that all of those things are already written on a few informal systemd roadmaps.
GNOME and KDE did work just fine without systemd until they didn't. udev did as well. Samba, PAM, OpenSSH, and most of the rest of the services on my system, work just fine without it. I rather doubt that'll be the case five years down the line.
Done many times.
...Oh, wait.
You mean to tell me that systemd isn't just an init system? And that it includes, but is not limited to, and I quote [1]:
"init system, journal logging, login management, device management, temporary and volatile file management, binary format registration, backlight save/restore, rfkill save/restore, bootchart, readahead, encrypted storage setup, EFI/GPT partition discovery, virtual machine/container registration, minimal container management, hostname management, locale management, time management, random seed management, sysctl variable management, console managment, . . ."
They are working on:
"network management, Local DNS cache, mDNS responder, LLMNR responder, DNSSEC verification, IPC in the kernel, time synchronisation with NTP, stateless systems, factory reset, OS/container/app image format, sandboxing of services and apps..."
[1] http://0pointer.de/public/gnomeasia2014.pdf
So what people really mean by "Write a better init system." is "Write a second, competing hulking mammoth like systemd."
Also consider that until now many of the things you listed were done by shell scripts that every distro reimplemented differently, so if you're happy with such ugliness you can pick it up as-is. ;)
The latter is the easier approach. However, it's still hard. The major problem is logind, and no-one has yet tackled writing a logind that layers on top of Debian-without-systemd. See: http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/de...
And that is exactly what I think is the most irritating thing about it. I just want it to init my system. I'll do the rest, or decide which piece of software should. NOT the systemd developers.
Doesn't this becomes more difficult though, when things people are used to like KDE/Gnome are depending on systemd?
What happens if more tools start depending on systemd? Will people just have to keep finding alternatives?
Linux becomes the new OSX (Slick, integrated, everything works great as long as you are doing the things that the system designers expect you to do); FreeBSD becomes the new Linux (Weird and confusing out of the box, but can be customised however you want it)
I think that is the reason so many people dislike it.
Replacing init - and nothing else - is something many of those people would be totally fine with. Starting services in parallel, and watching them when running, restarting them if they crash, that is something a lot of people would like very much, I am certain.
But the systemd developers did not stop there and are trying - it seems - to have systemd replace everything but the proverbial kitchen sink. I am not even saying that this is a bad (or a good idea). But doing so just rubs many people the wrong way, if only because it means the systemd people are attempting to change an important aspect of the architecture of the system without having a proper discussion about it first.
Desktop environments now have an actively-maintained cross-distro interface that they can target to simplify their life (from setting the hostname to secure multi-seat handling), so it's not a surprise that they make use of it.
For example policykit was broken and things like mounting USB devices or managing VPN connections didn't work. That is finally fixed and with latest cgmanager from unstable, and policykit-1 from experimental those things work again.
The only noticable loss compared to systemd is the lack of 'Suspend/Hibernate' in the KDE menu, but you can still use 'pm-suspend' from the cmdline, or even with 'qdbus' and the systemd specific dbus API, so in the end this should be fixable too.
So I wouldn't put KDE into the same bucket as Gnome, its dependencies on systemd seem to be mostly indirect:
* policykit, which started to depend on systemd-logind instead of consolekit. Works with cgmanager+systemd-shim as replacement
* upowerd doesn't support suspend/hibernate anymore but apparently, so apparently systemd specific dbus methods have to be used now.
Also Gnome3 works under OpenBSD (with consolekit?), and there is definitely no systemd there, although it might not be the latest version: http://callfortesting.org/gnome3/
I'm having a similar experience with systemd. I had problems with USB storage (seems fixed now) and I'm still having problems with networking. DBus went haywire, not sure if it's in a sensible state yet or not. I haven't been using VPN connections or suspend.
This isn't exactly a nightmare scenario. Most of the evident problems with systemd seem to be fixable. I can't say I'm impressed. I'm also having a hard time remembering why it was so important to move away from sysv init in the first place.
I think that is a sensible requirement as upgrading from sysvinit-core to systemd-sysv was quite problematic (wouldn't boot if you had some entires in ftab, etc.), and some may want to stay on sysv at least for an initial reboot.
Oh, it's an amazing idea. So I assume you candidate to be a fulltime maintainer of the whole software stack and packages, right? Why don't we support OSS4 too, while we're at it! After all, support for everything is just free of man hours!
systemd by all means is still new, how can you convince all of us that it is _the_ init system all of a sudden?
It's good to have options, for each apps(email,web server,database,you name it) in Linux there are normally a few options too, why is systemd that different?
That might still be worth doing but this is a lot more than saying “Oh, if you don't like vim don't install it”. All of that will require time, effort and be a source of bugs / UI clunkiness which no other operating system has to deal with – I'd much prefer that people pick 1 system and spend time getting closer to the “it just works” level which OS X and Windows have been at for years rather than maintaining a stable of patches and extra code.
I have experienced issues with launchd which do not exist in the components that it replaced (e.g. cron, init, etc).
For example, try setting a cronjob that runs every minute in launchd (e.g. running fetchmail). launchd says, "process exited too quickly" and disables the entry. [I'll note that this was an old example. Hopefully it's been fixed, but it's been far from "just works".]
In this specific case, launchd is designed as an init replacement which keeps processes running. The restart throttle is designed to prevent crash loops which are horrible for battery life and tends to fill up logfiles, so it expects the process to run for at least 10 seconds. The easiest way to solve that would be to use it as intended and run fetchmail -d rather than spending the extra overhead restarting fetchmail all of the time.
If you have a professional sysadmin monitoring things, this gets fixed.
If you're the average Mac user, you tell all of your friends that the last OS X release sucks and made your Mac slow and eventually go to the Apple store when your hard drive fills up.
fetchmail is also intended to run as a system daemon as part of a full-fledged mail system. This isn't always the case.
Also, launchd not just initd, but crond per Apple's consolidation of system daemons. That is a use-case for crond. If Apple wants to replace crond, then they should make sure that the replacement works. I'm sure that I could find other programs that might exit in under 60 seconds that don't have a daemon mode[1].
[1] To be clear it wasn't the 'run every minute' that was causing issues, but the 'exits less than 60 seconds after it starts' that was tripping it up. I could run fetchmail every 10 minutes, but when it is able to connect/verify that there isn't new mail in under 60 seconds, then the whole process gets disabled. Oops!
If you don't want flexibility but instead want a single ascended choice system like on OS X or Windows, use RHEL or one of the forks of it instead. Debian may simply not be the system for you.
That's really a fundamental misrepresentation of Debian. As a Debian user since around 1997 or so, the value has always been that you get solid, tested packages which work out of the box – almost everything you need is an apt-get away and it's consistent across all of the systems with the same packages installed. When I was responsible for somewhat over a hundred systems (servers & desktops) that was invaluable for delivering a consistent user experience.
Maximum flexibility would be something more like Gentoo where you can play around with config options and rebuild software with arcane flags, with the expectation that you're comfortable spending time diagnosing anything which breaks if you hit a combination which hasn't been well tested by anyone else.
This is highly relevant to the discussion above because consistency starts becoming a LOT more work when you start needing to coordinate between multiple major projects. If you want, e.g., Firefox or Chrome to be able to use a webcam just after it's plugged in that requires communication a bunch of large code-bases (kernel, GNOME, audio daemon, browser, probably some sort of permission system which may or may not be in one or more of these, etc.) and all of that is either going to be harder or slower if you have to support a bunch of different systems with differing designs, bugs and it's a tax which people who don't support Debian won't have to pay.
Remembering the era where people just accepted that things like audio or video wouldn't work on Linux because it was too much hassle, I appreciate the value of a single target.
Like hell. Anything beyond the most basic tasks on a server (and even the most basic tasks, sometimes) requires configuration, and often that configuration ranges between "nonintuitive" and "actively spiteful." If a service crashes and the pid file doesn't get handled properly, you've got to go in there and fix it. And god forbid you have to touch SELinux for anything. "Just works." I want what you're smoking.
* someone adds a storage device. Now your server can't boot because what used to be /dev/sda1 is now /dev/sdc1. Yes, UUIDs partially address that but unless you were defining "decades" as "within the last year or so" you can't assume that they were used.
* init script starts something, which crashes / is killed by OOM / etc. and you'd like it to be restarted. Note that this is still unsolved with upstart if the process crashes for more than your respawn limit, as is common with e.g. networking-related startup failures but, hey, it's the same braintrust which required multiple major releases to accept that sysadmins need logging and daemons to be started as users other than root or that "hang forever" is not a valid error handling strategy.
And in the rare case where automatic restart is a good idea, I wrap that script in a supervisor, like monit, as god intended.
If a process is crashing for more than the supervisor's respawn limit, then you have a problem that computers can't solve. Not sure how you thought that could be resolved automatically.
It's not especially common, particularly if you don't work with large servers or tons of local storage. Here are three variations on this theme which I had to deal with:
* The Linux kernel changed the order of device enumeration in a point release (early 2.6, if memory serves). This caused some of our servers to start enumeration the on-board IDE CD-ROM ahead of the SCSI drives and on the next reboot the ones which had been setup before Debian started using UUIDs in /etc/fstab failed because /dev/sda was now the CD drive.
* A very similar problem happened involving USB mass storage, which was a problem because our remote administration tools could forward a local drive or ISO image to the remote server as a USB device. This was particularly annoying on one early KVM system which only forwarded the device when you were connected so the logical device ordering changed if you rebooted it while connected to the console.
* If you have multiple controllers in a system, the drives are enumerated in order per-controller. If the bays were not fully populated when the system was first setup, a new drive added to controller 1 will be enumerated ahead of the drives from controller 2 and all of the subsequent device names will be shifted by one.
All of these are why it's now routine to use UUIDs to identify drives. It's a solvable problem but hasn't been so for even a single decade.
> And in the rare case where automatic restart is a good idea, I wrap that script in a supervisor, like monit, as god intended.
Uptime and resilience are baseline requirements for what I work on, not "rare cases". I've used external supervisors but that's introducing a third-party tool with its own bugs and means that you can't assume that another sysadmin is familiar with it. If you're the monit person in a supervisord shop (or vice versa) you'll probably have something take longer to debug or break at some point because of a subtlety in the differences between the two.
This is such a common case that it makes sense to solve it once at the system level, particularly since that allows me to e.g. not have to code an extra bit in my daemon that knows how to ask arbitrary third-party supervisors about a different process.
> If a process is crashing for more than the supervisor's respawn limit, then you have a problem that computers can't solve. Not sure how you thought that could be resolved automatically.
That's a fine approach if the failures are caused by something like a broken config file but it doesn't handle environmental failures gracefully. For example, consider a daemon which fails if it can't resolve a hostname or connect to a server (e.g. a database) or which exits if it can't write to disk. In either case, you're going to have downtime if the server / data-center drops offline or a partition fills up.
The question is whether the service comes back quickly after the underlying problem is fixed or requires someone to localize it and restart the process. If you have one server and you happen to be on-duty, this isn't a big deal but for anyone with many servers running different apps it can be a headache after a network partition or power failure (oops, web servers all came online well before the database server finished checking its RAID array).
In the case of upstart, the default respawn limit is only 10 times within 5 seconds after which it will stop the job until you manually restart it. Since they didn't add throttling or delays, there's no way to deal with this within upstart without either increasing downtime for every error (e.g. adding "|| sleep 10" to every script) or wasting more CPU restarting jobs as quickly as possible until you hit a larger limit.
Again, not an unsolvable problem but had they not ignored a huge amount of prior art and perhaps even consulted with actual sysadmins there would be things like a respawn delay and backoff so you could say things like "restart this no more than n times per minute". Instead, most places either convert everything to use a different supervisor or support an external monitor which requests restarts for services periodically, both of which add maintenance overhead and risk for what is a standard feature on other systems.
Why have they gotten to this point? Because the people working on desktop have generally been the D-team. The A-team is working on kernels and infrastructure, the B-team turns out packaging, and the D-team has been coming up with hair-raising stuff like gnome, 'desktop bus', pulseaudio, enlightenment.
So this weird little monoculture has emerged in which no other concern matters except that they get rescued from drowning -- that their boot times (!?!?) go to 5 seconds from 10, that hot-plugging USB drives (!?!?!?!) be wrapped in with the init system if it helps at all, that DHCP (!!??!?!?!?!!) and core files (!!!!!!!!) and all logging (!!!!?!?!?!?!?!?!) be taken over in the name of helping even 1% on the core experience.
But at the same time, two basic axioms of reality still bear:
1. Linux on the desktop is irrelevant and will never win, both in terms of the Linux story and in absolute terms; and every scrap of effort that goes into it has been objectively wasted for two decades and will continue to be wasted.
2. Linux everywhere else has been working fine for longer than most of the desktop people have been alive.
following from (2), the people who run servers recognize that although systemd has some good ideas, it forcibly bundles together a grip of super bad ones too, and is clearly implemented by people who don't understand systems outside of the desktop.
The attempt to turn Debian back into a distribution for everyone, rather than a small collection of desktop people, is completely valid and sensible. That said, it's totally clear why the desktop people want it this way, and why they have such a misguided emotional investment in their terrible new windows emulator.
To be fair, some of the ideas behind pulseaudio are good:
- Unify all of the different audio systems that existed: OSS, ALSA, esound daemon, etc...
- Network accessible sound. Years ago I was able to setup pulseaudio to stream audio from my HTPC to my laptop where I had headphones plugged in. The process to do this wasn't entirely user-friendly, but prior to pulseaudio, people would setup yet another audio subsytem that every app would then need to support on a case-by-case basis.
Thas said, while I may agree with the spirit of the GR, like I may agree with the existence of the Hurd and kFreeBSD ports, I wonder who will do the work needed to patch and support other init systems, given that up to now no-one bothered putting some actual work instead of pretending others should do it.
At least the Hurd and kFreeBSD porters were kind enough of carrying out most of the effort themselves, even if unfortunately I don't think it was sufficient.
(And no, please, systemd has nothing to do with Windows, please avoid such baseless comments which only manage to start useless flames)
Does Linux have to stay at software from the sixties forever? Can't we just move on to systemd and wayland and whatever fits better into the 21st century?!
I really feel this is all too political and FUD after months and months of senseless complaining about systemd and particularly far too personal regarding Lennart Poettering. If people like SysV init so much there will always be alternatives but this shouldn't hinder the majority of users to move forward with systems that just work with systemd (e.g. Debian+Linux). Nobody really uses Debian/kFreeBSD anyway, for example. Yet, it's a common statement that is brought up.
I would gladly switch back to Debian if I could swap systemd out for something else.
Have you tried a distribution which already comes with systemd preconfigured, such as Fedora, Suse or CentOS?
EDIT: I should probably also say, my desktop GUI setup is rather sparse. I usually run a debian server edition with SLiM & XMonad, which starts up ridiculously fast no matter which init system I am using. So, systemd seems a bit like overkill for my usecase.
What about service isolation & monitoring and the unified journal? IMO those are huge improvements to the status quo.
But more importantly [ed:than what is good for just Debian], a Linux monoculture would be a bad thing. We need (open)solaris, openbsd, freebsd, netbsd and OS X - which means any Linux-only, not-very-portable solution to these things just should not be mainstream. Consider that jails on freebsd works with, but do not demand, zfs. Even if arguably zfs solved a lot more real nuisances and problems than systemd does.
Last time systemd was mentioned, I addressed the issue of the journal, and how it being prone to corruption on bad crashes didn't really help its utility. There's room for improvement in init handling (see eg daemontools/runit) - and there may be a case to replace init. But so far I've yet to see any compelling arguments for systemd that have much to do with systemd. And their stance on portability, and complexity demonstrate to me an absolute ignorence of risk: portability, simplicity and small components are effective tools to mitigate risk.
Probably the most compelling argument is that simple services can now have simple config files rather than complex redundant shell init scripts - but it must surely be possible to take a simple config and generate a correct script for most of those services that really benefit from simple configs (iow those that have pretty straightforward demands).
The nosh init system[0] supports exactly this, although it outputs nosh scripts rather than shell scripts. nosh is an execline-style interpreter and set of commands for that interpreter that implements a simple init system where almost no code is run unless you explicitly ask for it to be run. It also supports configurable logging, socket activation, and some compatibility with other init systems - it could be a significant part of an alternative to systemd.
[0] http://homepage.ntlworld.com/jonathan.deboynepollard/Softwar...
[0] http://undeadly.org/cgi?action=article&sid=20140915064856
I've also noticed that the unit ordering and dependency chains can be quite flimsy and slow, occasionally freezing entirely before the display manager is started.
- Binary log files, which are also prone to corruption and crashes
- Unnecessarily complicated and unfamiliar init script structure. I feel like I went from one that was arguably too verbose to one which is too vague.
- The need for unnecessary things like dbus to be run at startup
- Complication of some simple configuration tasks (in my experience on Arch at least, network configuration was a bitch)
- udev has apparently been hijacked and may cause issues for those who don't want systemd
All in all, it feels like change for the sake of change to me, I see no advantages which I desire, and several minor to moderate disadvantages, but learning and using it is pushed on me for no reason. Personally, I've moved to running FreeBSD, it's simple and stable, though I've been considering Debian/kFreeBSD, I'd be sad to see it go. But it's the farthest of the issues with systemd IMO.
As far as your boot time improvement goes, that's great, but modernly, my systems are either always online or suspended to RAM or disk, rarely rebooted.
Yes, sometimes we need to embrace new things and learn new things. That doesn't mean they are bad.
And sorry, but i don't see how 99,9999% of Debian users should stay on sysv init just because you might or might not use Debian/kFreeBSD at some point in the future (instead of FreeBSD in the first place).
If i remember correctly kFreeBSD even is in such a bad unmaintained state the the discontinuation of it is discussed. Yet, you bring it up as an argument against systemd.
(FYI: As of February 2014, popcon registered 130 kFreeBSD, compared to 32 HURD users, and 165,821 Linux users. )
P.S.: I reboot my laptop everyday, i don't suspend.
I'm more than willing to accept change if that change is at all beneficial. Systemd simply fails to offer any beneficial changes to me and several harmful ones. You're right, they're not so much technical issues or bugs as usability and system philosophy issues. But issues which should not be simply dismissed nonetheless.
So, please, tell me, why should I accept change just for the sake of change? Especially when those changes seem to be against the philosophy of a simple, easy to understand system.
EDIT: thought I should note this too
> And sorry, but i don't see how 99,9999% of Debian users should stay on sysv init
I'm not suggesting that they do. By all means, change the default if most users desire it. This post is simply about allowing for flexibility of init system. I don't see why you have such a problem with that.
It's not, that was a lie. You're free to join #debian-kbsd on OFTC to see that development is ongoing and active, and that there's more than just one maintainer. They've switched to the 10.1 kernel and they frequently commit to Git.
No one is asking anyone to stay on a particular init system. They are asking for choice, and systemd has some "features" that restrict choice.
Unfamiliar, yes. Complicated? You have to be kidding me. systemd "scripts" remove the crud and hacks that the old init system built up over years.
Run a cron job on systemd; create two files: one timer unit (about 5-7 lines) and one service unit (about 5-7 lines) that you have to name identically (minus the extension) with the timer unit.
systemd can launch a cron daemon which itself can run cron jobs.
in addition, systemd can also execute timer units periodically. This is functionality that sysv init lacks.
If you select the same cron daemon, the configuration of cron jobs may be performed in an identical manner, regardless of which init system has launched that daemon.
Are you complaining that the optional systemd timer functionality is difficult to use and that you would prefer to run cron jobs via a dedicated cron daemon? That may be a valid criticism, but I am a systemd user and I have never tried this functionality, so I cannot comment on it. I personally continue to use a cron daemon since this is what I am familiar with.
Do you have a philosophical objection to the init system providing such capabilities? Maybe there is a valid reason to have such an objection, but I do not hold this perspective personally.
Regardless, your comparison here is not valid, since you are comparing the process of configuring optional functionality in systemd (which has no equivalent with sysv) to the process of configuring a cron daemon (which you could just as easily be using with either init system).
https://wiki.archlinux.org/index.php/Network_configuration#P...
You present this as if this makes sysvinit somehow lesser because of it lacks the ability to execute timer units. Sysvinit doesn't have that because that capability is completely unrelated to what sysvinit does. Although one could argue that the system as a whole provides that functionality through cron anyway, so there'd be no need to have sysvinit do it.
What exactly about this was hard?
I have one config file - /etc/wpa_supplicant/wpa_supplicant-wlan0.conf - which you can add to simply with wpa_passphrase "MySSID" "MyKey" > /etc/wpa_supplicant/wpa_supplicant-wlan0.conf
Then I ran a couple commands once:
systemctl enable wpa_supplicant@wlan0
systemctl enable dhcpcd@wlan0
And now it happily connects to any of the wireless networks I've set up in the config file.
If I want to control it or switch networks or reload my config, I can use wpa_cli to do this easily.
Totally minimal, no need for NetworkManager or netctl or anything, and works flawlessly.
Obviously if your net setup is more complex, this could require a better tool, but most of weird stuff would be done with iproute2 or whatever.
Now compare with FreeBSD, just add 1 single line to /etc/rc.conf and I'm done, 2 if I want a default gateway too.
Here's a link to what I was dealing with:
https://wiki.archlinux.org/index.php/Network_configuration#P...
20+ lines vs 2. You tell me which is simpler.
Also, our of curiosity, do you know what systemctl enable does? What files does it modify and how would you do it on a remote system (ie: one you'd mounted)? Would you need to chroot?
systemctl actually tells you what it does as output. It symlinks a service file from one directory to another. You can always do that by hand.
Why are they more prone to corruption? Software bugs aside they should actually be less prone to corruption, because they allow you to verify if corruption has happened. syslog has no such mechanism.
> Unnecessarily complicated and unfamiliar init script structure. I feel like I went from one that was arguably too verbose to one which is too vague.
Yeah, right...
> The need for unnecessary things like dbus to be run at startup
Why is dbus unnecessary? It’s a great way to do IPC. So great that it will be implemented in the kernel as kdbus.
> Complication of some simple configuration tasks (in my experience on Arch at least, network configuration was a bitch)
The init system was never responsible for setting up your network. Even before systemd, Arch recommended netcfg/netctl instead of setting it up in /etc/rc.conf.
Sure it may work for you but if N machines have state A and P machines have state B then getting all N and P machines to state B is incredibly difficult. It looks easy until you do it. That's probably one of the largest and most common things we do when deploying more than a trivial single machine.
To put it into perspective, everything becomes as much of a PITA as RPM packages without yum.
That was immediately obvious to me when I installed CentOS 7 on a couple of test machines to replace our costly Riverbed appliances and timedatectl threw "failed to issue RPC" on one machine but not the other. Same steps to install.
That's where we don't want to go.
We are now running FreeBSD and nginx on a HyperV cluster.
There are scripts with metadata attached (rc.d items) which may be ambiguous but that is no different from a shared library containing an export table or a set of runtime linker dependencies.
You're making a semantic argument, not a technical one. Why is it a good thing that your init system consist entirely of executable scripts? Because to me that sort of arbitrary executable code would be something to minimize: abstract out common functionality, DRY, and have each component do as little as necessary. If you believe otherwise, please support that idea.
But I have a question: where is this coming from? What makes you think it's "a cause for deep concern?" I would agree it's overkill for most software, but an init system for an operating system like Linux (or configurations for most of the kinds of software mentioned above) is never going to be simple.
The truth is that the West has moved on from Linux - Apple has won. Linux is most relevant in Asia, where we want to run it on cheap, locally assembled desktops. SystemD is bringing so much to improve the state of desktop linux - it is enabling fundamental security like XWindows-without-root[1], service dependency management ,etc.
there is a lot of fud around binary logs (which incidentally are append only and have a grep like interface built around it) and hard dependencies on systemd for any cgroup access. The second is actually kernel mandated - all cgroups have to have a single arbitrator for external applications. Direct access to cgroups will be dropped in the future. AFAIK, as on today systemd is the ONLY arbitrator that complies with the kernel-dev requirements.
I'm keen to see where desktop Linux can go to - I believe that it is going to be transformative for India. I strongly believe desktop Linux initiatives like SystemD and Mir/Wayland is going to take us there
That said, if you have worked with Docker - I find myself wishing very frequently for SystemD as pid 1. Right now I use supervisord as PID 1 (for a multiprocess container) and it is definitely more difficult to use than SystemD. Plus the ease of imposing resource limits (using systemd.resource-control) is simply unparalleled [1] http://fedoraproject.org/wiki/Changes/XorgWithoutRootRights
For my, it is the only big issue that I see for my personal usage.
Imagine being able to build your own private DigitalOcean and able to have pristine machines for a new fleet deployment (possibly even avoiding the stale confidential data issues plaguing DigitalOcean).
Support for stateless has existed in RedHat based distributions since at least 2003-2004. I, in fact, used it to run a ~50 seat callcenter using read-only NFS root systems, with a dynamically populated /etc, a decade ago.
Systemd is not innovating on ideas, but on implementation. How do you make things like service dependencies, stateless systems, etc consistently possible.
It is bringing something which was possible only for a person of your skill level, down to mine.
I would say it is the same difference between Ubuntu and Arch - idiotproofing the Linux ecosystem.
And it's written "systemd", not so camel-case monstrosity.