Arch Linux Is Switching To Systemd

[Ibidem]

Yes, it's designed to be the core system.

Is there really a good reason to seperate device management from service management.

You mean we should move init into the kernel? Linux isn't a microkernel, after all. :P
A daemon/server is the wrong way to handle hardware events, IMHO. Linux actually provides a much cleaner and simpler approach which udev ignores:
a hotplug "helper" command, set up by (example)

echo /sbin/mdev >/proc/sys/kernel/hotplug

This is what mdev does.

System logger -- curent system loggers don't really log all that well. Improvements can be made. By integraging the interface into the init system, you can verify what process a message is actually from. Rotation is integral rather than an afterthought cron process. Both things are hard to do well unless you have interface built into the init system to do so.

Session manager. Probably extraneous but also modular and optional. I can see the advantage of having the session manager talk to the init. On systems setup for single user or to autologin, having this crosstalk can prioritize services needed to get to a usable session first.

Linux however especially on the desktop is moving away from Unix. The kernel is budding some really cool features, let's make use of them to solve problems traditionally associated with Unix.

From a developers perspective a single unit file is a lot easier to make than a dozen different system V scripts.

I can't speak for "the average developer", but I can write a working init.d script in a few minutes, and have a pretty good expectation of it working right. Also you can do some testing in regular userland, depending on the daemons involved...
No experience with unit files.

In addition some of the most Unix of programs weren't designed that way. Take X for instance. It used to do gpu mode-setting, input handling, graphic memory management and a whole lot of other stuff.. It simply made sense to do it that way as it solved a lot of problems.

Then why is KMS so highly esteemed?
And what's the point of Modular Xorg?

The primary UNIX philosophy is to do what works. You don't necessarily want small programs piped together where the inter-process communication is not linear and unidirectional.

Unix also has several other approaches to IPC (for example, sockets...). Some of those are well-suited to this scenario.

A single large program with 5 functions and 5 options per function will have 25 options. The number of ways those can be combined is pretty large (several million if you use up to 10 options). A single binary (in one address space) has potential for various problems that multiple binaries (= multiple address spaces) may not face. So you have a chance of hitting an untested corner case.
If each program uses a defined interface (the point of standardization), you can have ~30 possible combinations of flags per program, giving 160 scenarios to test, as long as each program properly handles the interfaces.(Note: if buffer overflows and such bugs were impossible, the same would be true of a particularly modular single binary. Unfortunately, they aren't impossible.)
If you don't use a defined interface, you're doing something wrong.

Now there are some things systemd is doing right/modularly. But when init might get its own copy of fsck (quote not handy, but ISTR something about plans for that that on Poettering's website), there is something that's _not_ modular. And with 10+ different filesystems on Linux, that's simply a bad idea.
In fact, I consider any project where that could be considered to be too misguided to trust with critical system components.

[elanthis]

Then why is KMS so highly esteemed?

Because the kernel actually needs to control video modes for its own purposes, such as VT switching, early boot up, OOPS messages, debugging, etc.

There's also a reason that only KMS has been moved into the kernel, and all the meat of the video services are still in userland where they belong.

The kernel has no need to play OGGs or such directly itself. Only your applications need that. Hence, there is no need for any portion of the sound server to be in the kernel, aside from the raw hardware interface bits.

[Ancurio]

This is it. I am officially switching back to Yggdrasil.

[WorBlux]

You mean we should move init into the kernel? Linux isn't a microkernel, after all. :P
A daemon/server is the wrong way to handle hardware events, IMHO. Linux actually provides a much cleaner and simpler approach which udev ignores:
a hotplug "helper" command, set up by (example)

echo /sbin/mdev >/proc/sys/kernel/hotplug

This is what mdev does.

Fine for embedded systems with a few known a and tested components. You save resources and overhead, but you can get race conditions and and a lot of process forking. Using a socket to daemon helps guarantee consistency.

Being able to start/stop services based on hardware events seems to be a pretty handy thing. (Why the heck does ubuntu on a desktop still bring up the battery monitoring service? Or bluetooth, when you have no Bluetooth adapters connected?)

Interestingly enough the hotplug executable is considered the child of PID 1 when created.

I can't speak for "the average developer", but I can write a working init.d script in a few minutes, and have a pretty good expectation of it working right. Also you can do some testing in regular userland, depending on the daemons involved...
No experience with unit files.

That works for the quirks of every disto?

Then why is KMS so highly esteemed?
And what's the point of Modular Xorg?

KMS gives you a little more control and handle errors better.
X was modular to maintainability issues, and to make it possible to use some parts of x in an embedded system. No X is being pulled into different projects and slowly being killed. However at the time it make sense to smash as of this common and vital functionality together.

Unix also has several other approaches to IPC (for example, sockets...). Some of those are well-suited to this scenario.

Which systemd does use. It opens up a socket and buffer even before a service is finished initializing.

A single large program with 5 functions and 5 options per function will have 25 options. The number of ways those can be combined is pretty large (several million if you use up to 10 options). A single binary (in one address space) has potential for various problems that multiple binaries (= multiple address spaces) may not face. So you have a chance of hitting an untested corner case.
If each program uses a defined interface (the point of standardization), you can have ~30 possible combinations of flags per program, giving 160 scenarios to test, as long as each program properly handles the interfaces.(Note: if buffer overflows and such bugs were impossible, the same would be true of a particularly modular single binary. Unfortunately, they aren't impossible.)
If you don't use a defined interface, you're doing something wrong.

Now there are some things systemd is doing right/modularly. But when init might get its own copy of fsck (quote not handy, but ISTR something about plans for that that on Poettering's website), there is something that's _not_ modular. And with 10+ different filesystems on Linux, that's simply a bad idea.
In fact, I consider any project where that could be considered to be too misguided to trust with critical system components.

I would like to see the source/quote, google's not finding it for me.

There is an fsck service, which does essentially the same thing as the fsck init script.

If anything I'd imagine if there was it's own copy, it would be a straightfoward fork that could be passed arguments via a socket, rather than needing some sort of shell. I can't imagine why they'd need or want to touch the functional logic of it.

[bwat47]

I fully support this, and am getting pretty sick of all the trolls that popped up after the 'announcement'.

Systemd isn't perfect, yes there will be some teething issues during the adoption, but they will be dealt with.

Switching to systemd as the default should make things much easier for the arch developers:

1. service files are much cleaner and easier to deal with than initscripts. they are also portable and can be included in upstream packages, lessening the amount of work distros have to do to maintain them, as opposed to the convuloted highly distro specific initscripts.

2. this will make it easier for arch to work with upstream, especially as projects like udev and gnome start depending more on systemd. for example, what if gnome starts requiring systemd? arch developers would have to patch gnome packages for sysvinit/initscripts/consolekit compatibility. And on that note, a switch to systemd as default will make it much easier to get rid of the deprecated consolekit in the future.

3. systemd being adopted by multiple distros ensures that it is well tested and robust, and cross distro standardization for an init system is a good thing IMO.

4. systemd does have technical advantages over sysvinit/initscripts. the cleaner easier to maintain service files as mentioned in #1, faster boot (high parallelization), socket activation, integrated logging, session management etc...

Yes, in some ways systemd is more complex, but I think it has enough advantages to warrant a switch to make it the default init in arch.

[makomk]

edit: I should first read the link.

+Alan Cox You know, actually we set SIGPIPE to ignore by default for all services we start. Unless a service explicitly resets SIGPIPE so that it results in process termination what you are describing doesn't exist. I mean, we actually tend to do our homework. And systemd is not hard to debug, just not the same way as sysvinit.

This sounds like a good example of something that's wrong with systemd, actually. The way they're making sure that users of the systemd logging component don't crash with SIGPIPE when it falls over is to effectively disable SIGPIPE for any services launched by systemd. For the entire process. Every single pipe and file descriptor in any systemd-launched process no longer causes SIGPIPE, including ones which are entirely unrelated to systemd and which the process is relying on receiving SIGPIPE for. Now, obviously robust applications which rely on SIGPIPE will re-enable it, at which point they'll also re-enable SIGPIPE for the systemd log socket for themselves and presumably any process they start because it was never actually really disabled for that log socket, systemd just made sure that the resulting SIGPIPE was ignored.

Presumably the official solution to this is not to rely on SIGPIPE for anything. Unfortunately, shell scripting kinda relies on SIGPIPE being there, and in fact Alan Cox guesses that the shell is automatically re-enabling it. No problem - just don't use shell scripting for anything that might be launched by systemd, or be launched by a service launched by systemd, or that might result in something being written to the system log.

With consolekit being dead (www.freedesktop.org/wiki/Software/ConsoleKit/) they don't have much choice.

Yeah, systemd is rapidly killing off any alternatives that don't depend on systemd. At the rate things are going you probably won't even be able to get device nodes created without it in a few years.

[vertexSymphony]

Another thing about systemd is that it uses the Linux kernel more. Other init systems usually only make use of POSIX calls. Linux-exclusive features are not used at all.

Which is AWESOME for portability ;D

[bwat47]

Yeah, systemd is rapidly killing off any alternatives that don't depend on systemd. At the rate things are going you probably won't even be able to get device nodes created without it in a few years.

systemd didn't kidnap the consolekit and udev developers, they made their choices.

[Rallos Zek]

systemd, the GNOME3 of init systems.

That quote says it all!

[ElderSnake]

I just converted my Arch desktop to pure Systemd (not just initscripts compatibility, pure Systemd files. So no more rc.conf etc).

Following the Wiki and being a little careful it's actually pretty damn easy. Now I'm not sure whether my system is ever meant to go bang because of it, but I doubt it, seems to work just fine and all my services and daemons etc are all activated.

Anyway once again that Wiki proves it's worth, it allows just users like me to make a switch like that fast and easy.

Forgive me if this is a stupid question, but if it's this easy to make the conversion, shouldn't the conversion of the distro as a whole (i.e install media etc) be just as easy or is there more to it than that?