SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
Well, the problem with using shell scripts in the boot process is that it goes through a lot of PIDs, and it would be "less ugly" to arrive at a usable machine state with a PID in the hundreds, or lower. If everything has to break in order to achieve that, it seems like a good trade. Eventually all the broken stuff will be fixed, right?
I think that's the basic rationale. And maybe shave a few more seconds off boot time, but who boots much (or cares)? My servers and desktops remain on, and my laptops are usually on, suspended, or hibernated. I would prefer a reliable and well-understood boot system like the one we have.
My primary concern is that the systemd cabal is going to be pushing it as a dependency wherever possible, but we'll deal with that if it happens. But if any major distributions do actually release using systemd, the world will be stuck with it forever. If that's the case, I hope it turns out to be a good idea...
Quote:
Originally Posted by imitheos
+1
Systemd doesn't seem to provide the advantages necessary to justify the change (at least yet). I don't get the obsession of some people with boot times and why some major distributions change vital system components so easily without good reason. What's even worse is that these components become "standard" and then other distributions are forced to use them too.
I don't say that nothing should ever be changed. Progress is good and changes are required from time to time, but not change things just to change them.
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)
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.
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.
*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.
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.
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
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 :-)
Quote:
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.
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..
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.
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.
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.
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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.