LinuxQuestions.org
LinuxAnswers - the LQ Linux tutorial section.
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-23-2011, 10:34 PM   #31
hutyerah
Member
 
Registered: Dec 2005
Location: Brisbane, Australia
Distribution: Slackware
Posts: 39

Rep: Reputation: 16

Sorry to raise the dead a little... but if the problem with sysvinit-style booting is too many processes, wouldn't it be simpler to modify the interpreter so it doesn't spawn new processes for each script launched? If the problem is interpreted code speed, what about just-in-time compilation?
 
Click here to see the post LQ members have rated as the most helpful post in this thread.
Old 06-24-2011, 12:31 AM   #32
Richard Cranium
Senior Member
 
Registered: Apr 2009
Location: Carrollton, Texas
Distribution: Slackware64 14.1
Posts: 1,428

Rep: Reputation: 407Reputation: 407Reputation: 407Reputation: 407Reputation: 407
Quote:
Originally Posted by abrouwers View Post
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?
What makes you think that distros/sysadmins won't have to manage the systemd unit files?

If I have both fetchmail and getmail installed, which one gets run? How about wicd?

I'll also mention that starting a bunch of subsystems in parallel can (not will) result in some very difficult to nail down timing related issues. Especially if one or more unit files failed to record a dependency; sometimes it works, sometimes it doesn't.

Software engineering is a big game of whack-a-mole; the annoying things that you fixed by implementing feature X tends to pop up new and different annoying things.
 
4 members found this post helpful.
Old 06-24-2011, 04:06 AM   #33
Ivshti
Member
 
Registered: Sep 2008
Distribution: Linvo
Posts: 132

Rep: Reputation: 33
Quote:
Originally Posted by hutyerah View Post
Sorry to raise the dead a little... but if the problem with sysvinit-style booting is too many processes, wouldn't it be simpler to modify the interpreter so it doesn't spawn new processes for each script launched? If the problem is interpreted code speed, what about just-in-time compilation?
If we are going to rewrite code, isn't it more efficient to do a full redesign of the process from scratch according to the modern needs? What you are suggesting will still have the same management flaw we have in the current system - having to maintain a lot of scripts which include a lot of duplicated code.

Quote:
What makes you think that distros/sysadmins won't have to manage the systemd unit files?

If I have both fetchmail and getmail installed, which one gets run? How about wicd?
1. systemd unit files are easier do manage
2. Not true for desktop distributions - almost all daemons included in a standard desktop distribution are either started by D-Bus, or include systemd units already; server (or power-user) distributions can stick with sysvinit since fast boot is not required there

Quote:
I'll also mention that starting a bunch of subsystems in parallel can (not will) result in some very difficult to nail down timing related issues. Especially if one or more unit files failed to record a dependency; sometimes it works, sometimes it doesn't.

Software engineering is a big game of whack-a-mole; the annoying things that you fixed by implementing feature X tends to pop up new and different annoying things.
Well, it is difficult to track down race conditions, but we cannot stick with the same technology forever when we have better things available and we should not be demotivated by such difficulties.
 
Old 06-24-2011, 04:19 AM   #34
sahko
Senior Member
 
Registered: Sep 2008
Distribution: Slackware
Posts: 1,041

Rep: Reputation: Disabled
Does systemd have a reliable configuration utility written in something other than gtk or pygtk? For example something that can be used in the linux console.
 
0 members found this post helpful.
Old 06-24-2011, 07:54 AM   #35
abrouwers
Member
 
Registered: May 2005
Location: Michigan
Distribution: Slackware -current
Posts: 98

Rep: Reputation: 37
Actually, the GTK interface is mostly there as an example - I'm not sure it's even usable! Most of the enabling/disabling is done via. the CLI interface.
 
Old 06-24-2011, 08:06 AM   #36
Richard Cranium
Senior Member
 
Registered: Apr 2009
Location: Carrollton, Texas
Distribution: Slackware64 14.1
Posts: 1,428

Rep: Reputation: 407Reputation: 407Reputation: 407Reputation: 407Reputation: 407
Quote:
Originally Posted by Ivshti View Post
1. systemd unit files are easier do manage
I suspect that they will be easier to manage in some ways than sysvinit and harder to manage in others. I also suspect that individual distros will have to tweak the systemd units to get things to work; the idea of independent software units successfully inserting themselves into a dependency graph is an appealing one, but it will be easy to miss some links in the graph.

Quote:
2. Not true for desktop distributions - almost all daemons included in a standard desktop distribution are either started by D-Bus, or include systemd units already; server (or power-user) distributions can stick with sysvinit since fast boot is not required there
That doesn't make any sense to me. What is the difference between a "desktop" and a "server" distribution in terms of system initialization?

Quote:
Well, it is difficult to track down race conditions, but we cannot stick with the same technology forever when we have better things available and we should not be demotivated by such difficulties.
Wow. That's almost "Shut up and drink the Kool-Aid."

Look, "better" depends upon what criteria you weigh more than others. From a support perspective, being able to reproduce a problem so that you can fix it is pretty important. Shaving a small amount of time off the boot process doesn't weigh a lot in my view of the word. Your mileage may vary.
 
3 members found this post helpful.
Old 06-24-2011, 09:17 AM   #37
abrouwers
Member
 
Registered: May 2005
Location: Michigan
Distribution: Slackware -current
Posts: 98

Rep: Reputation: 37
Quote:
Originally Posted by Richard Cranium View Post
I suspect that they will be easier to manage in some ways than sysvinit and harder to manage in others. I also suspect that individual distros will have to tweak the systemd units to get things to work; the idea of independent software units successfully inserting themselves into a dependency graph is an appealing one, but it will be easy to miss some links in the graph.
Maybe. I would say for the most part, starting the daemons is really simple. Systemd takes care of managing it it all, so no need to handle the shutdown, restart, etc. stuff any longer. That makes these files /really/ simple. Check out dbus, for example

http://cgit.freedesktop.org/dbus/dbu...bus.service.in


Quote:
Look, "better" depends upon what criteria you weigh more than others. From a support perspective, being able to reproduce a problem so that you can fix it is pretty important. Shaving a small amount of time off the boot process doesn't weigh a lot in my view of the word. Your mileage may vary.
I guess I see systemd providing alot of improvements, but not many cons yet. I would argue that the current init system is not flexible at all. I mean, to prevent cron from starting on my slackware box, I have to manually edit rc.M. To start non-included daemons, I have to edit rc.local (and hope that I don't need it sooner in the boot process).

Alot of people seem to be against it mostly out of the sake of change - or, do you have technical disadvantages to using a quicker, more intelligent init system?
 
Old 06-24-2011, 12:36 PM   #38
Ivshti
Member
 
Registered: Sep 2008
Distribution: Linvo
Posts: 132

Rep: Reputation: 33
Code:
That doesn't make any sense to me. What is the difference between a "desktop" and a "server" distribution in terms of system initialization?
Well, for instance, you've got more daemons starting on a server/power user distribution. While recently, distributions like Ubuntu cut down the daemons they have to initially start to a very small count - sometimes only udev, dbus, NetworkManager, gdm need to be started initially and then the other services/daemons would be started by dbus on the fly.

The sad part is that when systemd came, it received a big amount of attention, while nobody ever cared that much about initng. Initng (despite being unmaintained) is a great dep-based init daemon which uses simple configuration files. Also, another big strength of it is the fact that it comes with pre-made configuration files which automatically integrate for your distribution upon install. That makes maintenance of init scripts (in this case, configuration files) pretty unnecessary. The distribution I maintain is using initng and the time from the start of initng to gdm is never more than 4 seconds.

Last edited by Ivshti; 06-24-2011 at 12:45 PM.
 
Old 06-25-2011, 06:06 AM   #39
cathectic
Member
 
Registered: Sep 2004
Location: UK, Europe
Distribution: Slackware64
Posts: 761

Rep: Reputation: 34
Quote:
Originally Posted by Ivshti View Post
The sad part is that when systemd came, it received a big amount of attention, while nobody ever cared that much about initng. Initng (despite being unmaintained) is a great dep-based init daemon which uses simple configuration files. Also, another big strength of it is the fact that it comes with pre-made configuration files which automatically integrate for your distribution upon install. That makes maintenance of init scripts (in this case, configuration files) pretty unnecessary.
And the difference with all the previous attempts, including initng, is that you have to explicitly declare said dependencies in the configuration files, so there is a requirement to keep always them up-to-date as dependencies change. The really nice thing about systemd is that you generally don't with socket based activation.
 
Old 06-25-2011, 06:27 AM   #40
Ivshti
Member
 
Registered: Sep 2008
Distribution: Linvo
Posts: 132

Rep: Reputation: 33
This is entirely true. Systemd also has many advantages over initng. The thing is, some of the previous attempts, although being worse than systemd, were better than sysvinit.
 
Old 07-31-2011, 06:00 AM   #41
KnutBluetooth
LQ Newbie
 
Registered: Jul 2011
Posts: 21

Rep: Reputation: Disabled
Maybe this ought to be read before ignorantly bashing systemd :

http://0pointer.de/blog/projects/why.html


Quote:
systemd is also a big opportunity for Linux standardization. Since it standardizes many interfaces of the system that previously have been differing on every distribution, on every implementation, adopting it helps to work against the balkanization of the Linux interfaces. Choosing systemd means redefining more closely what the Linux platform is about. This improves the lifes of programmers, users and administrators alike.
Additional advantages :

* Writing a shell boot script requires many redundant, error-prone lines of shell code. Making a systemd unit is 4-5 lines of configuration. So it's actually more KISS.

* One other (big) advantage is that most of the maintenance required would be done upstream. Freeing time to do something else instead of reinventing the wheel with custom error-prone shell scripts.

* It replaces/deprecates ConsoleKit which "works" in a hackish way on Slackware.

* It supports many of the newer linux kernel features.

* Someone already did the work to get systemd working on Slackware.

That said, it might be still a little too early yet to adopt it. But it's definitely something to consider very seriously.
 
Old 07-31-2011, 06:41 AM   #42
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 5,189

Rep: Reputation: Disabled
I would not consider systemd for this reason only: it is being written specifically to work only on the Linux platform.
I am very much an advocate of cross-platform development, UNIX is bigger than Linux alone. Systemd is expected to be used by "userland" programs like KDE and Gnome. However these are also used on BSD, Solaris, HP UNIX etcetera. It is as if Poettering expects that the userland programmers (KDE/Gnome and other desktop environments) and distributors of UNIXes should deal with the incompatibilities and patch their code to make it work on non-Linux OS-es where systemd will be unavailable.
Code that shows this amount of contempt for anything that is not Linux, should be buried without ceremony.

Poettering also said his code is "more efficient" because he does not stick to POSIX compliant programming. The programming shortcuts he takes are non-portable.
I think "more efficient" and "cross-platform" should not be mutually exclusive. Taking shortcuts to make your program do fancy stuff is an immature coding style and better suited for the demo scene. You can optimize code and still keep it cross-platform, there is a lot of software that proves this - look at the multimedia applications that use platform-specific assembler code to squeeze all the available performance out of a computer. Still those applications compile cleanly and can be used on Linux, UNIX, and on several hardware platforms. It takes effort to make software portable and you have to be willing to spend that time - you do it for the users of your software.
Poettering defends his systemd with vigor, but his comments reflect his contempt for any other way of thinking. One of his typical statements is that all his critics are "amazingly badly informed". You can not go into a dialogue with the guy, he just won't listen to your arguments.

So, what are the advantages of systemd? Using "error-prone shell code" instead of systemd is bullshit - it's not as if we have to write new init scripts every week. Replaces consolekit? Poettering and Zeuthen are two Redhat employees who infest computers with half-assed software that they deprecate faster than distros can adopt it. Does it make your computer boot faster? Well wow... how many seconds of productive time do you gain per day?.

It is not worth the hassle.

Eric
 
13 members found this post helpful.
Old 07-31-2011, 07:00 AM   #43
KnutBluetooth
LQ Newbie
 
Registered: Jul 2011
Posts: 21

Rep: Reputation: Disabled
OS portability is highly overrated *yawn* It's been keeping Linux back for years waiting for others to catch up.

Last edited by KnutBluetooth; 07-31-2011 at 07:02 AM.
 
0 members found this post helpful.
Old 07-31-2011, 07:41 AM   #44
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 5,189

Rep: Reputation: Disabled
You could have anticipated my reply, judging by your introductory message on LQ:
Code:
I really dislike the "developer knows best" policy of Slackware
It's good that the Slackware developer created a distro that is easily customizable. You can add systemd yourself if you want.

Eric
 
1 members found this post helpful.
Old 07-31-2011, 08:22 AM   #45
KnutBluetooth
LQ Newbie
 
Registered: Jul 2011
Posts: 21

Rep: Reputation: Disabled
Quote:
Originally Posted by Alien Bob View Post
You could have anticipated my reply, judging by your introductory message on LQ:
Code:
I really dislike the "developer knows best" policy of Slackware
Developers always think they're right but they more than often see things only through the limited perspective of their own software. Not the big picture of a system as a coherent whole. And so the system ends up to be an inconsistent mess. Haven't the people who vaunt OS portability as the holy grail also mentioned anything about the concept of spaghetti code ? And that's a bloody shame because the Linux kernel is superior to everything else out there as far as kernels in the UNIX world and pretty much also beyond it. Lennart Poettering and RedHat are pushing for more coherence and simplicity. And that's good news except for people whose hobby is to do system administration.

Quote:
Originally Posted by Alien Bob View Post
It's good that the Slackware developer created a distro that is easily customizable. You can add systemd yourself if you want.

Eric
It's customizable not because any effort was put into that. But because (contrarily to Debian and Fedora) it's one of the rare distros that does have a sane policy of not including everything and the kitchen sink. It makes choices instead of allowing every esoteric possibility. That's what makes it easily customizable. And it has to be this way. If not, one person wouldn't be enough to keep it updated. But the best would be a distro that would make choices, that doesn't include everything and the kitchen sink, but which would also strive to be consistent so as to put some order into the chaos of the bazaar. There's no reason why one can't have the best of both worlds.
 
1 members found this post helpful.
  


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 11:05 AM.

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