Systemd is not portable and what this means for our ports

Not to get too side-tracked, but Unix-like kernels aren't very Unix-y. They're big monolithic beasts that are difficult to configure and impossible to modify on-the-fly, save for the few modules that can be unloaded, recompiled, re-inserted and configured. In general it was thought of as bad design, and still is by many "experts".

I'm not sure why our system management tools/frameworks have historically been interpreted scripts. It could be due to the low barrier to entry. Or the dynamic way it can be modified - even on embedded systems - without any tools other than a text editor. Perhaps relying on the infinite possible combinations of simple tools just gave us more power than we could ever get from trying to make libraries for every possible need. Or maybe it was just way simpler to manage.

I'm not anti-systemd, mainly because I haven't used it. But any time someone says "let's replace the old system wholesale" without really REALLY good reasons, I suspect it's premature. It seems really useful for tightly integrated embedded systems, but hell for general admin use.

Is a modern browser necessary for browsing HTML5 websites, or can you just write your own parsing / rendering / interaction engines in IE5-compatible javascript?

systemd also logs stderr + stdout, so if some daemon fails to start up, you can easily see it in 'service $SERVICE status'.

A lot of things could theoretically be done by putting that all in a sysvinit script. That means duplicating that in every sysvinit script. Bugs galore :P

Shell scripts are a terrible language for any kind of event handling. Consider that:

- You're probably going to be starting a new process for handling each event.

- You'll be using the filesystem to store state between events.

- You'll be using helper programs to access various kernel resources.

- To keep such resources around, you'll have to keep the helpers running during events.

Compared to implementing whatever you're doing in a single process with an event-driven design, or in multiple processes with their responsibilities split well, the shell script approach will be orders of magnitude slower and less reliable (the latter due to lots of race conditions).

Usually when you kill a service, it's because it's not working properly. If a service is in a broken state, it's not the job of the service to try and cleanly shut itself down; it's the job of the service manager.

Try doing that reliably with loads of workers and cgi scripts. Maybe possible at one point, but systemd does that reliably by default.

What about it? If my CGI scripts are Python scripts, how do I kill the CGI processes that Apache launched without killing any that lighttpd launched, or some silly script I wrote to monitor something else?

To me the new hairball does seem much cleaner and better thought out. Sysvinit scripts are copy/paste programming at its worst, every one doing a half-assed, buggy reimplementation of an init system copy/pasted from another package and then tweaked until it sort of worked.

There's value in declaring hairball bankruptcy, though. The world changes. Complexity can grow non-linearly, and assumptions valid in one context can rapidly change.

I believe he meant "more standardized". I find that working with systemd is more predictable than with sysvinit and things that I expect to be able to do work as I expect them to work.

Ah, yeah, sorry, that totally wasn't clear. Perhaps a better word would have been "consistent".

/usr should be mounted at the start since there's various things that are necessary during bootup, like udev rules.

See http://freedesktop.org/wiki/Software/systemd/separate-usr-is... for a more complete explanation.

There's no equivalent for /usr/share, which some programs depend on. You could make /share, or you could just use /usr for everything and have it available at early boot. Putting everything "system" in /usr/ also lets you make backups more efficiently instead of having to blacklist /home/, /sys/, /proc/, etc.

The initd needs to depend on the kernel. POSIX semantics aren't enough. Even Upstart and SysV init change their behavior based on the kernel.

Furthermore, it makes sense for the responsibility of services to be delegated to one place, otherwise you end up in this situation where programs are started differently from cron than they are from /usr/bin/service than they are from init. It makes sense to delegate all the complex service management and watchdog stuff to one location, and that requires kernel-level semantics. For instance, systemd's use of cgroups allows CGI that it forks off to be killed when it tries to stop Apache.

I may be misreading you, but I think you're trying to ask why the survey was making technical decision justifications based on purely subjective opinions rather than a survey based on objective facts, balancing the cost to humanity of the few remaining /usr splitters having to reconfigure, vs the slightly increased effort of the very small number of people who write initscripts having to continue to use the old system plus or minus the increased effort by the existing stock of programmers having to learn systemd which the other distros having switched has been forced on everyone anyway. I think both sides of the balance have pretty small numbers.

A la the famous Landley rant from about 4 years ago, I had a NFS mounted /usr... back in 97 as an experiment which I rapidly terminated. Shared and RO /usr is an interesting hack, but probably not worth holding init development back, especially since so many other boot time things demand /usr anyway now (like the pulseaudio, like the networkmanager thing)

If you were aiming more at why systemd needs different stuff, you can google for Landley's email around 2010 on the topic and on the other side google for read only /usr and NFS /usr. Also google for cgroups, especially systemd and cgroups.

systemd does NOT require /usr to be mounted at start. That is just a myth.

http://freedesktop.org/wiki/Software/systemd/separate-usr-is...

Oh, I definitely wasn't singing their praises even if ALSA was a step up from OSS, PulseAudio was just a new low for me in sound systems. My biggest frustration with it was the tendency it's always had on my systems to simply stop producing sound with no obvious cause and when it was working block anything that didn't use it from producing sound. Sometimes a random process had either accidentally muted everything or triggered a bug that did so, other times audio would get sent off to some completely useless sink, occasionally there were no noticeable causes and you just had to kill and restart the daemon (if you were lucky). On top of that a lot of choices were made that tended to bind it to one console, so switching to another would cut out all sound.

I guess my core complaint is that ALSA could be a pain to get working properly on a new system, but once it was working it didn't usually spontaneously break on me. PulseAudio was only slightly more likely to work out of the box, but was much more likely to break without my making any changes. I guess it's partially a sysadmin mindset, but I usually come down on the side of preferring up-front pain to long term unreliability. Perhaps I didn't use as wide a set of audio programs as you did, I didn't tend to run as many of them at once, or my hardware just had better drivers. For streaming sound (I didn't care about video) I usually stuck to network servers that could shove audio down a Shoutcast or http stream and listening with something like Amarok or MPD, I'm sure PA was nicer if you were trying to relay what your HTPC was playing back.

[ETA: I use linux consoles very heavily when I'm coding on a linux machine, I know this isn't exactly the most common behavior among more recent unix users.]

It's the difference between a sound server and having kernel audio device APIs. Pulseaudio is an actual daemon running that is sinking audio and managing it in realtime - ALSA (sans dmix, and piling other alsa plugins on top of that) was just an API into the kernel audio interface.

Sound servers are a modern, I'd argue, necessary convenience for the average joe. API wise, pulse is much nicer to use than alsa (pcm_sink_thing_getbuffer_readhardware_processpcm() x50. I've debugged the sdl implementations of alsa and pulse, and pulseaudio literally takes a tenth the code to use).