LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Closed Thread
 
Search this Thread
Old 06-09-2011, 11:05 AM   #16
Beelzebud
Member
 
Registered: Oct 2010
Distribution: Arch & Slackware
Posts: 95

Rep: Reputation: 22

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.
 
2 members found this post helpful.
Click here to see the post LQ members have rated as the most helpful post in this thread.
Old 06-09-2011, 12:24 PM   #17
fl0
Member
 
Registered: May 2010
Location: Germany
Distribution: Slackware
Posts: 105

Original Poster
Rep: Reputation: 34
Quote:
Originally Posted by volkerdi View Post
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 View Post
+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)

Last edited by fl0; 06-09-2011 at 12:25 PM.
 
1 members found this post helpful.
Old 06-09-2011, 02:21 PM   #18
Didier Spaier
Senior Member
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware{,64}-{14.1,current} on a Lenovo Thinkpad T61 6457-4XG
Posts: 4,244

Rep: Reputation: 1044Reputation: 1044Reputation: 1044Reputation: 1044Reputation: 1044Reputation: 1044Reputation: 1044Reputation: 1044
PAM in Slackware

<posted in wrong thread, sorry>

Last edited by Didier Spaier; 06-09-2011 at 02:35 PM.
 
Old 06-10-2011, 09:40 AM   #19
abrouwers
Member
 
Registered: May 2005
Location: Michigan
Distribution: Slackware -current
Posts: 98

Rep: Reputation: 37
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.
Old 06-10-2011, 10:57 AM   #20
neymac
Member
 
Registered: May 2009
Distribution: Slackware64-14.0
Posts: 117

Rep: Reputation: 13
Quote:
Originally Posted by abrouwers View Post
For what it's worth, I actually got systemd working nicely on my slackware lappy...
.
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?

Last edited by neymac; 06-10-2011 at 02:58 PM.
 
Old 06-13-2011, 09:22 PM   #21
Ivshti
Member
 
Registered: Sep 2008
Distribution: Linvo
Posts: 132

Rep: Reputation: 33
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.
Old 06-15-2011, 10:48 PM   #22
55020
Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 366
Blog Entries: 4

Rep: Reputation: 330Reputation: 330Reputation: 330Reputation: 330
http://zaitcev.livejournal.com/209321.html
 
1 members found this post helpful.
Old 06-16-2011, 03:11 AM   #23
gnashley
Amigo developer
 
Registered: Dec 2003
Location: Germany
Distribution: Slackware
Posts: 4,755

Rep: Reputation: 466Reputation: 466Reputation: 466Reputation: 466Reputation: 466
abrouwers, can you explain what you did to get it working?
 
Old 06-16-2011, 06:52 AM   #24
abrouwers
Member
 
Registered: May 2005
Location: Michigan
Distribution: Slackware -current
Posts: 98

Rep: Reputation: 37
Quote:
Originally Posted by gnashley View Post
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.
Old 06-16-2011, 07:24 AM   #25
abrouwers
Member
 
Registered: May 2005
Location: Michigan
Distribution: Slackware -current
Posts: 98

Rep: Reputation: 37
Quote:
Originally Posted by 55020 View Post
*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.
Old 06-16-2011, 09:34 AM   #26
55020
Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 366
Blog Entries: 4

Rep: Reputation: 330Reputation: 330Reputation: 330Reputation: 330
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.
Old 06-16-2011, 09:48 AM   #27
abrouwers
Member
 
Registered: May 2005
Location: Michigan
Distribution: Slackware -current
Posts: 98

Rep: Reputation: 37
Quote:
Originally Posted by 55020 View Post
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..
 
1 members found this post helpful.
Old 06-16-2011, 11:13 AM   #28
55020
Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 366
Blog Entries: 4

Rep: Reputation: 330Reputation: 330Reputation: 330Reputation: 330
Quote:
Originally Posted by abrouwers View Post
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.
 
1 members found this post helpful.
Old 06-16-2011, 11:37 AM   #29
abrouwers
Member
 
Registered: May 2005
Location: Michigan
Distribution: Slackware -current
Posts: 98

Rep: Reputation: 37
Quote:
Originally Posted by 55020 View Post
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.
 
2 members found this post helpful.
Old 06-16-2011, 02:46 PM   #30
Phorize
Member
 
Registered: Sep 2005
Location: UK
Distribution: Slackware
Posts: 217

Rep: Reputation: 23
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.
 
  


Closed Thread


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Informaton on systemd init system? arashi256 Linux - Newbie 1 06-04-2011 07:06 PM
LXer: openSUSE 11.4 M6 Kills HAL, Brings WebYaST, Avoids SystemD LXer Syndicated Linux News 0 01-28-2011 11:50 PM
LXer: This week at LWN: Systemd and Fedora 14 LXer Syndicated Linux News 0 09-07-2010 01:00 AM
LXer: Systemd Test Day on Tuesday 2010/09/07 LXer Syndicated Linux News 5 09-06-2010 10:52 AM
About Slackware 9.1 boot disk?? ftp://ftp.kpn.be/pub/linux/slackware/slackware-9.1-is AL3OMDAH Slackware 4 04-18-2007 09:54 AM


All times are GMT -5. The time now is 09:01 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration