LinuxQuestions.org
View the Most Wanted LQ Wiki articles.
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 05-07-2013, 11:08 PM   #61
Richard Cranium
Senior Member
 
Registered: Apr 2009
Location: Carrollton, Texas
Distribution: Slackware64 14.1
Posts: 1,428

Rep: Reputation: 407Reputation: 407Reputation: 407Reputation: 407Reputation: 407

Ah, yes, the "let's do as much as possible in parallel when we start up" story.

I work in telephony. Did you ever notice that when you take your phone off the cradle that you almost always get a dial tone? In fact, you expect to get a dial tone? Do you remember that scene in one of the Jurassic Park movies where they see a phone in an obviously deserted building and they nonetheless take the receiver off hook because "Hey, it may work."?

My daytime job is to write sh*t that works, no matter what you idiots throw at it. (Yes, we now use SIP, which increases the amount and flavors of cr*p that's thrown at us.)

On one of the projects that I've worked on, we actually attempted to start up various subsystems in parallel while initializing. After all, why not? The arguments to do so are seductive and seemingly without honest rebuttal.

Turns out, there's at least one very good reason not to do it. Is there a chance that whatever it is that you're starting can take a relatively random amount of time to finish? There is? Welcome to the absolute hell of reproducing a problem that your customer has. His/Her setup takes just a little bit longer to finish initializing some init-controlled-thingy than your testing system does. Good luck getting that error just right so you can fix their problem. Good luck keeping them as a customer too.

Being able to consistently reproduce the steps taken by a system during startup is a godsend. Don't throw it away without cause.
 
11 members found this post helpful.
Old 05-07-2013, 11:14 PM   #62
ReaperX7
Senior Member
 
Registered: Jul 2011
Distribution: LFS-SVN, Slackware-14.1, PCBSD-10.0
Posts: 2,862
Blog Entries: 15

Rep: Reputation: 743Reputation: 743Reputation: 743Reputation: 743Reputation: 743Reputation: 743Reputation: 743
Basically, in plain English, your saying Richard that even with a Parallel Loading of system resources, resources still need linear loading of dependency and child processes to work correctly, otherwise nothing works at all and tracking loading of PIDs in linear is superior because it can tell if a system resource fails at the right moment and why, right?

And Jens... currently which program controls cgroup at the moment not counting systemd? The way the document is worded it seems the shell system like Bash currently manages cgroup as a background process.

If that's the case, and the shell system manages it as a background process, why again, do we still need systemd if any at all? Is Bash now broken?

Last edited by ReaperX7; 05-07-2013 at 11:20 PM.
 
Old 05-08-2013, 12:44 AM   #63
Erik_FL
Member
 
Registered: Sep 2005
Location: Boynton Beach, FL
Distribution: Slackware
Posts: 793

Rep: Reputation: 245Reputation: 245Reputation: 245
If I understand Richard's point correctly, it is the unpredictability of the execution order that poses a testing and troubleshooting problem. Each service will be affected differently by small changes in the disk access timing, execution timing and even interrupt latency or ordering. On the same computer, the order will change from one boot to the next, and the order is almost guaranteed to be different between computers.

One way to mitigate that problem is to divide the system start-up into a finite number of phases and only start services in each phase that do not depend on each other. Each phase then waits for start-up (or failure) of all the services in that phase before the system proceeds to the next phase.

Not knowing anything about systemd, I can't comment about how the design deals with the testability and repeatability issue.

I think that the best answer to systemd is to wait and see how well it works in other distros before deciding whether to adopt it in Slackware. By other distros I mean other distros that don't have paid-for support.

Throwing lots of money at something may get it to work on a case-by-case basis. In fact, that's a frequent money making tactic of software vendors. Sell it cheap and charge lots for the support to make it actually work. The worst that happens is some customers walk away in disgust. Hell, you don't even care if someone pirates it because they'll never get it to work on their own.

If you're lucky enough to have something that can be released as "open source" then you can take advantage of other people's solutions to the problems you create. There's nothing to lose, and you can charge for upgrades that are nothing more than re-engineered fixes someone else designed and tested.

Commercial Linux OS customers may want systemd, or at least the features it is supposed to provide. Whether it is practical or appropriate for the non-commercial distros remains to be seen. I'm always a little suspicious when commercial organizations try to promote ideas to non-commercial organizations.
 
2 members found this post helpful.
Old 05-08-2013, 02:22 AM   #64
Didier Spaier
Senior Member
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware{,64}-14.1 on a Lenovo T61 6457-4XG
Posts: 4,017

Rep: Reputation: 962Reputation: 962Reputation: 962Reputation: 962Reputation: 962Reputation: 962Reputation: 962Reputation: 962
On parallelism, see The Problem With Threads from Edward A. Lee.

Last edited by Didier Spaier; 05-08-2013 at 02:29 AM.
 
1 members found this post helpful.
Old 05-08-2013, 06:53 AM   #65
fewt
Fuduntu Team
 
Registered: Dec 2011
Location: Nashville, TN
Distribution: Fuduntu
Posts: 74

Rep: Reputation: Disabled
Quote:
Originally Posted by jens View Post
It can't.
That is, not without insane (make that close to impossible) complexity ... and all on the user side.
see: https://www.kernel.org/doc/Documenta...ps/cgroups.txt

cgroup is an already existing kernel function that isn't used by any traditional init.
This is just not true. It is not insane or close to impossible, I've already proven you wrong with OpenRC which is an evolution of sysvinit.
 
Old 05-08-2013, 09:03 AM   #66
jens
Senior Member
 
Registered: May 2004
Location: Belgium
Distribution: Debian, Slackware, Fedora
Posts: 1,190

Rep: Reputation: 159Reputation: 159
Quote:
Originally Posted by fewt View Post
This is just not true. It is not insane or close to impossible, I've already proven you wrong with OpenRC which is an evolution of sysvinit.
It's no traditional init either.
If you do consider it as a natural evolution from sysvinit (I don't), sure.

Last edited by jens; 05-08-2013 at 09:06 AM.
 
Old 05-08-2013, 09:08 AM   #67
fewt
Fuduntu Team
 
Registered: Dec 2011
Location: Nashville, TN
Distribution: Fuduntu
Posts: 74

Rep: Reputation: Disabled
Quote:
Originally Posted by jens View Post
It's no traditional init either.
If you do consider it as natural evolution (I don't), sure.
I don't think anyone has said we need to stay with traditional sysvinit and never evolve it. We didn't however need to completely re-invent init and alienate a large part of the community just to boot a little faster.

OpenRC solves the few small problems in the "traditional" init, yet it still remains compatible with BSD and isn't proprietary / tied to a single platform.

Last edited by fewt; 05-08-2013 at 10:02 AM.
 
Old 05-08-2013, 12:37 PM   #68
torimus
Member
 
Registered: Apr 2013
Distribution: Slackware
Posts: 81

Rep: Reputation: Disabled
Just a few examples of experience with systemd on my Arch Linux box and why I so "like" it:
  • systemd refuses to run in chrooted environment. After a kernel upgrade I had to rebuild initrd and rerun lilo so the simple procedure of booting from install/rescue CD, mounting linux partiton, chroot to it and update lilo was not possible.
  • There was an issue with console font setting in systemd. Proper setting in /etc/vconsole.conf but ignored by systemd. The standard procedure in BSD/SysV init system is to walk through/trace shell init scripts in /etc/rc.d or /etc/init.d and quickly locate the source of problem. With systemd I've got stuck at binary file /lib/systemd/systemd-vconsole-setup. Now the only way is to track its source C file, study its contents, do changes, recompile and pry. Thats magnitude more difficult in comparison to shell scripts.
  • stale links in /etc/systemd after package removal, systemd throws errors when trying to run a service that no more exists on system. Manual intervention to get rid of such links is required.
  • to reliably run dhcp for just one wireless network device whether it was/was not successfully connected to an AP virtually impossible without a bit of hackery
When it does work, one can enjoy faster boot times but when something gets screwed, you have a much harder time to fix things. Not worth it, if you ask me.
I can also remember, when systemd devs ignored services not related to a concrete process like iptables settings. Just ridiculous.
The unique and limited (in sense and comparison to universall shell code) configuration syntax. If there are special needs systemd devs just ignored, you have to hack your way around.

Hope there always will be the dependency on systemd as optional for upstream sources.

Last edited by torimus; 05-08-2013 at 12:40 PM.
 
10 members found this post helpful.
Old 05-08-2013, 01:06 PM   #69
JWJones
Member
 
Registered: Jun 2009
Location: Cascadia
Distribution: Slackware, LinuxBBQ, OpenBSD, Mac OSX
Posts: 723

Original Poster
Rep: Reputation: 185Reputation: 185
Quote:
Originally Posted by torimus View Post
  • systemd refuses to run in chrooted environment. After a kernel upgrade I had to rebuild initrd and rerun lilo so the simple procedure of booting from install/rescue CD, mounting linux partiton, chroot to it and update lilo was not possible.
  • There was an issue with console font setting in systemd. Proper setting in /etc/vconsole.conf but ignored by systemd. The standard procedure in BSD/SysV init system is to walk through/trace shell init scripts in /etc/rc.d or /etc/init.d and quickly locate the source of problem. With systemd I've got stuck at binary file /lib/systemd/systemd-vconsole-setup. Now the only way is to track its source C file, study its contents, do changes, recompile and pry. Thats magnitude more difficult in comparison to shell scripts.
  • stale links in /etc/systemd after package removal, systemd throws errors when trying to run a service that no more exists on system. Manual intervention to get rid of such links is required.
  • to reliably run dhcp for just one wireless network device whether it was/was not successfully connected to an AP virtually impossible without a bit of hackery
I'd say that's all some very real-world experience as to why systemd sucks, for sure. And why some former Arch users have left for non-systemd pastures:

http://sporkbox.us/blog/?r=page/95
 
1 members found this post helpful.
Old 05-08-2013, 01:09 PM   #70
Erik_FL
Member
 
Registered: Sep 2005
Location: Boynton Beach, FL
Distribution: Slackware
Posts: 793

Rep: Reputation: 245Reputation: 245Reputation: 245
Quote:
Originally Posted by Didier Spaier View Post
On parallelism, see The Problem With Threads from Edward A. Lee.
Thanks for posting the link. That was an interesting article, though some of the math is beyond me.
 
Old 05-08-2013, 08:45 PM   #71
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 ReaperX7 View Post
Basically, in plain English, your saying Richard that even with a Parallel Loading of system resources, resources still need linear loading of dependency and child processes to work correctly, otherwise nothing works at all and tracking loading of PIDs in linear is superior because it can tell if a system resource fails at the right moment and why, right?
Well, not quite.

If you do a topological sort on a directed acyclic graph, you'll find in a lot of cases that there are several sorts that work and some that don't. Those that don't work are due to a missing dependency that wasn't shown in the original graph for whatever reason.

The key here is being able to reproduce the problem. If the problem is due to system X being able to complete a task 3 milliseconds faster than system Y, then I wish you luck in being able to reproduce and solve the underlying problem.

With sysvinit or the BSD init sequence, there are no such timing issues (assuming, of course, that the underlying init scripts do NOT return prior to actually completing their initialization process).

I'm not even assuming incompetence to the people who described the initial dependency. Good Lord, what engineer would choose to mess up? Humans screw up, for whatever reason. If we didn't, we'd be gods.
 
Old 05-08-2013, 08:59 PM   #72
ReaperX7
Senior Member
 
Registered: Jul 2011
Distribution: LFS-SVN, Slackware-14.1, PCBSD-10.0
Posts: 2,862
Blog Entries: 15

Rep: Reputation: 743Reputation: 743Reputation: 743Reputation: 743Reputation: 743Reputation: 743Reputation: 743
I lost confidence in ArchLinux after several crashes and re-installs due to updates from pacman not working right and too much buggy code from the beta package tree spilling into the mainline packages. It WAS a good distribution but the maintainers get very sloppy at times.

The problem with forcing users to use a system they don't want to use, nor care to use, has killed many a Linux project in the past. The again some people just love to cut their own throats to see how long it takes for them to perish, but I digress.

Projects like mdev and eudev could prove to be useful in not only keeping systemd out of Linux distributions, but keeping most distributions adhering to the UNIX Philosophy.

I wonder if Patrick has tinkered with mdev or even eudev yet for Slackware as a replacement for udev-systemd? I know from reading that mdev doesn't support auto loading of modules yet, this could be added eventually with time though, but projects like mdev are a step in the right direction to keep Linux out of the hands of evil programmer who want to do a hostile takeover of the core of Linux and force their will upon others.

Edit: BTW, nobody answered my question regarding what currently controls cgroups outside of systemd. Is cgroups currently controlled by the system shell?

Last edited by ReaperX7; 05-08-2013 at 09:06 PM.
 
Old 05-08-2013, 09:40 PM   #73
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 Didier Spaier View Post
On parallelism, see The Problem With Threads from Edward A. Lee.
Heh. We use the observer pattern a lot at work.

I'll start off by conceding that telephony is a rather unique use case for parallelism. On a given telephone switch, there really are a large set of utterly disjoint state machines running that really couldn't care less about each other. The fact that I'm talking to several people somewhere doesn't have much of an impact on your talking to your best friend somewhere else.

On the other hand, that's the perfect environment for parallelism.

The big deal hits when all the threads need to look at something that they all share. Normally, that's some type of resource; in the telephony world, that would be a database or a trunk or something similar. So, how do you ensure that those threads have a sane view of whatever the *bleep* they are looking at?

One way is to lock the object(s) in question so that nitwit thread A can't change what nitwit thread B is looking at while thread B is reading the shared object. However, if you don't always access the locks in the same order by each thread, you can create a deadlock condition, where two different threads own a lock that the other one wants. Deadlocks are bad. Really, really bad.

Another way is to make the shared object(s) accessible via some type of task and asynchronous messaging framework. That was used by DESQview, which provided stable multitasking on top of Microsoft DOS (of all things). In that case, you are really serializing access to the shared data via a dedicated thread that accepts incoming messages that tell it to perform work. That actually works fairly well.
 
Old 05-09-2013, 01:03 AM   #74
kikinovak
Senior Member
 
Registered: Jun 2011
Location: Montpezat (South France)
Distribution: ElementaryOS, Ubuntu LTS, Slackware
Posts: 1,497

Rep: Reputation: 682Reputation: 682Reputation: 682Reputation: 682Reputation: 682Reputation: 682
Quote:
Originally Posted by ReaperX7 View Post
I lost confidence in ArchLinux after several crashes and re-installs due to updates from pacman not working right and too much buggy code from the beta package tree spilling into the mainline packages. It WAS a good distribution but the maintainers get very sloppy at times.

The problem with forcing users to use a system they don't want to use, nor care to use, has killed many a Linux project in the past. The again some people just love to cut their own throats to see how long it takes for them to perish, but I digress.
I couldn't have said it better. You probably know the greek myth of Sisyphos. You know, the guy condemned to push a rock on a mountain, only to see it roll down on the other side for all eternity. Basically, Sisyphos is a mythical projection for compulsive obsessional behaviour.

In my humble opinion, one of the biggest issues with software development is what one should call the "Sisyphos syndrome", and which could be described as follows. As soon as a piece of software approaches a state of perfect usability (KDE 3.5.10, GNOME 2.32, ALSA and SysV come to mind), the developers let it just roll down the hill, only to start from scratch all over again with something almost unusable: KDE 4.0, GNOME 3.0, Pulseaudio, Systemd, Unity, etc. Rock'n'roll, Lennart!

Last edited by kikinovak; 05-09-2013 at 01:36 AM.
 
3 members found this post helpful.
Old 05-09-2013, 01:17 AM   #75
kite
Member
 
Registered: Aug 2003
Location: Shenzhen, China
Distribution: Slackware
Posts: 300

Rep: Reputation: 47
Angry

Quote:
Originally Posted by kikinovak View Post
I couldn't have said it better. You probably know the greek myth of Sisyphos. You know, the guy condemned to push a rock on a mountain, only to see it roll down on the other side for all eternity. Basically, Sisyphos is a mythical objection for compulsive obsessional behaviour.

In my humble opinion, one of the biggest issues with software development is what one should call the "Sisyphos syndrome", and which could be described as follows. As soon as a piece of software approaches a state of perfect usability (KDE 3.5.10, GNOME 2.32, ALSA and SysV come to mind), the developers let it just roll down the hill, only to start from scratch all over again with something almost unusable: KDE 4.0, GNOME 3.0, Pulseaudio, Systemd, Unity, etc. Rock'n'roll, Lennart!
I totally agree with you... This is a very bad situation for Linux. Developers need to make sure things work and work well instead of changing things so dramatically and frequently.
 
  


Closed Thread

Tags
cgroups


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
LXer: Slackware: Is Systemd Inevitable? LXer Syndicated Linux News 5 07-22-2013 04:54 AM
[SOLVED] slackware and systemd fl0 Slackware 512 08-29-2012 11:07 AM
slackware and systemd (OT) eloi Slackware 44 08-24-2012 04:36 PM
[SOLVED] systemd and Slackware's future kikinovak Slackware 95 07-14-2012 11:40 AM
Boot Delay 30min: systemd-analyze blame systemd-tmpfiles-setup.service BGHolmes Fedora 0 07-27-2011 09:02 AM


All times are GMT -5. The time now is 05:43 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