I guess for me it's a matter of this old saying: "Don't fix something that isn't broken"

When Pulse came out, it literally ruined the sound stack on every machine I tried it on. To this day, I still can't get reliable performance from it. Now I just avoid it. SystemD seems very much like Pulse. A solution in search of a problem.

3 members found this post helpful.

Whats with the start on demand thing? The Startup time dosn't really matter, but start services only when needed is the big thing in my opinion. (yes inetd do something similar, but not for system services). I don't say sysemd is ready or perfect, but the idea behind is good. (Solaris has similar tools and Mac OSX also)

1 members found this post helpful.

<posted in wrong thread, sorry>

For what it's worth, I actually got systemd working nicely on my slackware lappy. I am hardly an expert, nor fully understand the complete power that systemd offers, but it was surprisingly simple to do. There are a few gotchas involved (like the use of sysklogd still ), but once installed, most things simply worked well.

I agree that it's new and shiny, and could probably mature a bit, but I dislike the general "avoid it because it's new" mentality :-) It has a lot of really cool features, and the nice side-benefit of speed (my slackware lappy boots in 10 seconds, using a slow 5400rpm drive). I also really like the idea of distros not needing to manage init scripts and longer; while it doesn't affect me too much personally, of course, it's a neat idea in general. Many upstream software even ship systemd unit files now, completely eliminating the need to create and maintain them to start daemons - how cool is that?

As mentioned above, it really doesn't matter much to me, as long as the system boots nicely. But if that can be done with less maintenance on Pat, with the benefit of being quicker and more intelligent too, then maybe it's not a terrible thought.

2 members found this post helpful.

Could you please post the steps to get it working on Slackware-current?
I would like to try it on my lappy too.
What changes in Grub2 config files?

The primary reason sysvinit is so reliable is not it's long life. Sure, this is a reason, but the primary one is that it's utterly simple. Think about it - what is the "init" process actually. It reads an inittab, configures a couple of numbered runlevels, associates a script with them and when requested, runs a shell with the script. There is nothing simpler than that in an init daemon.

Looking only at the init process, it really follows the KISS philosophy. But now look at the big picture. The boot process has changed a ton since this technology (sysvinit) was introduced. What happens is we get a ton of scripts which do a lot of operations, start a lot of daemons and so on. Some distributions use straight-forwards scripts (which are still big in volume and not elegant) called BSD-style, and other use a little more complex system of scripts called SysV-style - in both cases you have a lot of duplicate code in the scripts, inefficiency and general ugliness.

Modern init systems really got a point there - it's much more elegant and generally simpler if you use a simple system to manage daemons built into PID 1, because this is not a job to do with shell scripts. For example, when you use a shell script, you have to implement the following stuff into it >
1. Parse parameters ("restart", "start", "stop")
2. Check if the daemon is already running
3. Create a PID file
4. Start the daemon, writing it's pid into the file
5. if requested to stop the daemon, send SIGINT to the process with that PID

If that happens in the init daemon, you just have to write a configuration file for that daemon specifying the path to it's executable file and probably some parameters. And you repeat that with all the other daemons/services. Simple and elegant.

Another strong point in favor to systemd is paralellism - practically, there is a potential of starting all daemons at once and using the maximum potential of your hardware on boot. If possible, why not do it? It won't be so complex to rework the boot process (seriously, it's not rocket science) and there are enough people to test this stuff and make them rock-stable.

1 members found this post helpful.

http://zaitcev.livejournal.com/209321.html

1 members found this post helpful.

abrouwers, can you explain what you did to get it working?

I suppose, but it comes with the caveat that I probably can't/won't support it :-)

http://www.slackadelic.com/~thrice/systemd/README

3 members found this post helpful.

*cough*
"Why doesn't syslog work?"
"Did you enable it?"
"No"

Sorry; you can knock systemd for a few things, but documentation is not one of them. Their docs are really, really good, and even fedora wrote up some really good stuff to accommodate its release.

http://fedoraproject.org/wiki/Systemd

1 members found this post helpful.

Well, I didn't intend to get into an argument [1], but Mr Zaitcev made multiple points, including (but not limited to):

* systemd's resident set size is 22 Mb (init is 1.3 Mb), mapped size is 54 Mb (init is 19 Mb)
* everything you thought you knew about booting has to be relearned, which has costs in retraining, mistakes and downtime
* it could be considered iffy to promote consultancy when you created the need for that consultancy in the first place

The misconfiguration (reported to be an error in F16 Rawhide) doesn't invalidate any of those points. In fact, it considerably *reinforces* the point about relearning and costs. Indeed, if Fedora, the spiritual home of systemd expertise, has this sort of breakage, then the rest of us are in for a world of pain.

[1] may contain traces of lie

1 members found this post helpful.

Well, the memory thing is related to selinux usage - I'm sure that will be commented on at some point.

As shown in the wiki, fedora even forwarded their existing method of enabling/disabling daemons to work with systemd, without any modification. Try reading the wiki page :-)

Yeah, sure. I guess to me, if a daemon isn't loading, I try to enable it. Sounds logical anyway. If I don't know how, I read the project documentation. Or the distribution documentation.

I agree completely that changing something, indeed, means that things change. Fedora is hardly 'the spiritual home of systemd,' just the first distribution to ship it by default. If you take a bug in their development branch as an indication of systemd being unworthy for the the 'rest of us,' well..

1 members found this post helpful.

Thanks for the thought, but if a daemon isn't loading, the problem isn't necessarily that it isn't enabled; I only have to cite the recent thread here about gpsd hotplug for evidence. That's why the whole boot system needs to be grokable and hackable. Old init/sysvint can be grokked and hacked by a moron in a hurry, whereas in http://0pointer.de/public/systemd-man/ there are 46 different man pages. They might be good enough to enlighten even a moron, but he'd better not be in a hurry.

1 members found this post helpful.

OK, so now the docs are TOO good?

Keep in mind your link contains systemd specific docs. Are you suggesting that there is a manpage I can view on my slackware machine, provided from sysvinit, that will show me how to enable a daemon on my slackware box? As a novice user, who may not even understand permissions, one could argue /etc/rc.d/ is not so intuitive, especially if I was in hurry.

Anyway, it's just an argument now, so I'm going to bow out. Cheers.

2 members found this post helpful.

Don't get me wrong, I have nothing against change, or systemd, or even fast boot times, I just don't have any probelms that systemd solves. I'll get worried when fluxbox needs it as an external dep.

Oh yes, and plain ol' alsa is still good enough for me.

---------- Post added 06-16-11 at 08:47 PM ----------

Don't get me wrong, I have nothing against change, or systemd, or even fast boot times, I just don't have any probelms that systemd solves. I'll get worried when fluxbox needs it as an external dep.

Oh yes, and plain ol' alsa is still good enough for me.