Yes, but until people drop the "pass the buck" attitudes Chris, nothing will help forge alternatives forward while choice is eliminated. People need to help projects move forward by getting involved, and keep good time tested projects going by devoting time to them, even in small quantities.

As long as the options of choice and alternative solutions exist, GNU/Linux, or any operating system, can thrive, but if choice is eliminated we will eventually end up with a stagnated operating system with zero innovation.

There's absolutely no excuse for playing the bystander in the progress of alternative choices. Even something as minor as a bug report can help a project. A bug report recently to the Eudev team at Gentoo is looking into a bug with hald. That may seem insignificant to some people, but hald is still a useful project to some people. That bug report was made by a few people here at LQ.

1 members found this post helpful.

Again most people aren't doing anything just taking pot shots it's become like religion. I like systemd, I like sysvinit I really don't care which is used systemd and Pottering isn't evil just like Volkderding and Slackware isn't the sole possessor of good idea's. People will use what suits them and what gets things done pragmatism will always trump ideology.

Go and fight the good fight, slay your dragons.

1 members found this post helpful.

For a moment I thought you said Pottering isn't as evil as Volkerding. That made me laugh.

I guess nobody could possibly be *that* evil! Behold!

https://plus.google.com/114480574919...ts/FNwaXanrA6p

Comparing software engineering to classical engineering assumes that software
has the ability to wear out. Software typically behaves, or it does not. It
either works, or it does not. Software generally does not degrade, abrade,
stretch, twist, or ablate. To treat it as a physical entity, therefore, is
misapplication of our engineering skills. Classical engineering deals with
the characteristics of hardware; software engineering should deal with the
characteristics of *software*, and not with hardware or management.
-- Dan Klein


other then security issues, there is no reason to say something like "deprecated is useless"
unless the software depends on a crappy API from some crappy framework/daemon (then again i don't want it if it does)

PS all software sucks

This is just pure FUD. I don't know how you can come up with these arguments. You do realize that systemd is the most advanced, featureful, and innovative init system available to Linux distributions, right? And you know that Red Had very much NEEDS its OS to be innovative, right? You know, the innovation that their billion dollar business relies on.

I find it hard to believe that you aren't just an elaborate troll.

You do realize that systemd is the most intrusive, failure prone, and unfixable init system available to Linux... And it has taken quite a few years to get mostly working? From Fedora 14 (where it was supposed to be available) Fedora 15 (where it was supposed to be optional, but isn't), Fedora 16 where it still wasn't reliable, and still undergoing major modifications in 17, 18, 19, 20... and still having failures show up.

There is a difference between "innovative", and "correct" right? One big problem with systemd is that it lacks reproducibility. A failure that occurs once doesn't necessarily occur the next time... and adding one additional service can cause a cascade of failures due to the random scheduling of startup processes totally unrelated to the new service, and without the debug messages to figure out WHY it failed...

5 members found this post helpful.

So by your estimates we should eliminate all choice and alternative projects, all fall in line with one singular project, allow no outside projects to be better or innovative, and just accept what Red Hat wants.

And you dare to class me as a troll?

Wow.. If you love Red Hat so much, please go to them if you feel they are so innovative by all means.

And no systemd is NOT the most advanced init system. Its the most invasive, overrated, and overbloated init there is.

Innovative inits are s6, Runit, and OpenRC. Heck even BSDinit is more innovative.

1 members found this post helpful.

What supposedly makes those init systems "innovative"?

Watch out, I might say something horribly innacurate (lack of technical knowledge) but, in all honesty, I have to disagree with you on this one, Reaper. The inits you mentioned are following the same path as sysvinit did. I don't really like systemd either but I must say that, on this regard, systemd is more innovative because: a) it is following a different path, going in another direction 2) it has fast development. However, I must say that "being innovative" is not necessarily a good thing (not judgind systemd).

Actually no... they are very innovative in many ways.

Runit and s6 both draw upon the concepts of using linear core loading of the system while using parallel loading as designed by D. J. Bernstein's daemontools. By this you have a flexible init system that's not only fully backwards compatible with sysvinit scripting, but allows for expanding the init system into other fields. Heck you can even use daemontools, runit, s6, and perp to perform the same functions if you script correctly with sysvinit as a minimized base unit.

Is linear loading of some services bad? No, and in fact it's recommended for many of the lowest level components. In fact systemd does exactly this but on a broader scale of approach, but the approach isn't new. Parallel hand-off service loading has been around for the better part of a decade thanks to daemontools http://cr.yp.to/daemontools.html, but few people have attempted to utilize it. The last release of daemontools was well over 12 years ago. http://en.wikipedia.org/wiki/Daemontools So this concept is not new by any means.

Add to the fact bsdinit relegates a more human level approach to init by simplifying the init tree path, and you have not only flexibility, but a deeper level of innovation.

You can use the old, the new, or both simultaneously without penalty.

Go read up on s6's approach to init at http://skarnet.org/software/s6/s6-svscan-1.html if you think otherwise. Skarnet's approach is dead on correct that:

Simplified down, this means basically that init can hand off during stage 2 once all the one-shot service loads are performed. While I do differ in opinion over the stage 1 and stage 3 courses of designing init per unit, and we have done so with Runit, the init process can be heavily generalized down to being useful in a variety of systems if told to do so to service all possible systems with the one-shot approach. It's all in the scripting techniques you use. Taking the Slackware approach to scripting you perform a check for the executable, if executable is present and executable by permission, it runs the program. On LFS if alsactl is present, and executable it runs the command and binary, if not, it moves on to the next step.

Skarnet even gives the option of using standardized shell scripting or his execline scripting method. While on Runit we use standard shell scripting, but only because we know it works, and we know that that's all Runit uses, but again... options and alternatives.

OpenRC is pretty much the same, though is has several tie ins with the system and kernel, but again it takes the familiar of sysvinit, transforms it, and reworks it to work not just more effectively, but efficiently.

To really say it, you could humanize/simplify sysvinit with bsdinit, then enhance it with a service manager like perp, s6, Runit, OpenRC, etc. or see if you could go without sysvinit entirely and use the init system of choice's native tools.

The point is, you have options, alternatives, and choices that are in various combinations. That's not just innovation, that's brilliance, and that's the best possible choice to have.

Download the s6 package and look at the example of a sample of s6 as init. It's a very unique approach by all possible standards and reasoning, and somewhat the same as much different from our Runit work.

1 members found this post helpful.

Just a technical detail here. I don't know what Slackware and LFS do exactly, but there is a very common mistake that's being made often, and even in the glibc internals: checking that a command is present and executable, then executing it. It is wrong because:
- there is a race condition. The state of the command might change between the state and the actual execution.
- it is redundant. The kernel will refuse to execute a program if it's absent (duh) or the user doesn't have permission to.
The right way to run a command if present and executable is to actually execve() it. If the execve() fails, errno will tell why, and the program can react accordingly.

3 members found this post helpful.

I think not...

Checking for existence and proper permissions before attempting to execute it does not throw the error during normal circumstances. So an error is an error is an error, and not "normal".

If the state changes between the test and the execution, and execution subsequently fails - that is an error condition and should be reported. If the state changes in the opposite direction there is no race as there is no execution.

Relying on error trapping in this manner to control normal execution flow... is not a good programming method. Kind of like relying on bouncing off of guard rails to control your path around a curve.

1 members found this post helpful.

Define "normal".
A change in state in the system is normal to me. Is it abnormal that you install new binaries ? Remove old ones ? chown and chmod ?

Poor users who will get an obnoxious error message for no reason at all when they try to run something at the same time the package manager is updating it. Please, this is the Microsoft way, not the Unix way.

It's not error trapping. It's error checking, and it's a much better programming method than gratuitously introducing race conditions and useless checks. System calls return an error code for a reason, and it's a "normal" case, not an "exceptional" case, whatever that means.
I will probably not be able to convince you, so this will be my last post on the subject.

2 members found this post helpful.

If you look at our LFS bootscripts for stage-1 in Runit, you can see what we did for the one-shot services. We did this purposely to create a "needs of the many" stage-1 script rather than a script customized for a single person's system. It's rough, but it works very well, and was developed as such. Runit technically is designed around script it to your needs, not script it to everyone's needs.

Actually both skarnet and astrogeek are correct in their own ways. Welcome to democracy if you didn't see it. Technically speaking, stage-1 in both Runit and s6, allows for a lot of flexibility, but it allows for a unique situation that sysvinit can not duplicate. Do I script for the person or the masses? Sysvinit was designed around the masses only. Only s6 and Runit allow for a such an instance where you can pick how you want to script it out. Regardless if you use a UNIX method, a Microsoft-like method, a BSD method, or a Linux method, you always arrive at stage-1 for either the few or the many.

However one thing puzzles me, if we had daemontools available for so long now, how come the major distributions wanting all this boot speed and daemon management never once attempted to use daemontools in any way?

1 members found this post helpful.