This has repeatedly shown to be false. KDE4 may be OK now but there was a very, very significant *decrease* in functionality and productivity when switching from the stable, feature-full KDE3.5 to the brand-new KDE4. Because the top distros don't want to be left behind, they all have to jump at the latest software regardless of whether or not it is actually an improvement. Users did not have a choice in the matter despite ubiquitous complaints.
If the devs deprecate udev and all move to systemd, then the *users* have no choice. When nearly every distro uses systemd, the users have very little choice -- and since there is more to just the init system to think about when choosing a distro, it becomes harder to *not* accept what you're given. I really hate this argument -- the idea that users have any real power is such an idealistic and unrealistic view of the world. We have to accept certain things until a breaking point occurs, and rebellions in an open source community would just lead to developer (or user) exodus.
Source please.
When Pat chose to stop supporting Gnome, I'm sure a significant portion of its users left. The relatively small Slackware community can only take so much bleeding, making political stands a painful ordeal.
Hacks (ie patches) require developers, and because of the low usage such patches would get, they would be less tested. This introduces the possibility of bugs or vulnerabilities. Plus, patching software is a lot of work and more than Slackware can handle. If Arch was on board with systemd protestation then maybe this would be feasible but without external support there is cause for concern.

Maybe software will support both systemd and SysV/udev for the foreseeable future, which would be great. There's just no way to tell right now if that will be the case.

[QUOTE] What about Ubuntu and console kit?

Why don't you think developers will not go an extra mile and make different versions? If there is a significant amount of users using alternative init systems.

Wikipedia. LOL... But I wouldn't be surprised if it was in there with all the b/s I have seen there. But yea, ofcorse that was biased statement . However, Linux users are generally more aware of their systems then MAC OS or Windows users are. Hence they are better judges of changes taking place.

I'm pretty sure more left due to lack of dependency automation.

Well then other then adopting systemd what else choice is there but hacking?... if and only if it becomes the Giant to take over all linux init systems.

Agreed. So our conclusion is the same... let time give us the answers.

Mercury305, the point is that, systemd is not a user-space application that can be discarded or used at will by the end user. In the end, the distribution's choice will be the user's choice.

Therefore, the point about the end user is moot.

systemd appears to make significant changes to the UNIX-like philosophy that has got Linux where it is today.

See how far, alternative non-*nix open sourced OSes have got today. Barring a few, they have essentially remained hobbyist or obscure projects. The fact is, Linux got where it is today by being Unix-like and its reputation for solid stability and reliability is partly a result of the legacy.

Linux has been built on the shoulder of giants and over standards established over decades. This systemd developer appears to completely ridicule this aspect and thinks adopting anything new and shiny, while discarding proven, stable software, is progress.

Because in the end, they determine the development paths. Open source or not, software development is not a democracy. If a developer feels it is inconvenient to support two kinds of init systems, he will drop support for one of them.

3 members found this post helpful.

I'm just gonna step out of this conversation... because I will end up arguing in circles. I never said I was Pro Systemd for number 1.
As far as Unix Simplicity, I think if you compare it to Unix of 1970's the Linux we have today is barely resembling anything of its past. Even the Kernel is 15Million + Lines of Code.
Simplicity is no longer the case here. However, keeping it as simple as possible but not any more is always the best option.
Systemd simplicity is debatable. Like I said you are just talking about how systemd is anti Unix but you have not even used it let alone understand the inner workings of systemd. So why argue over something you have not even tried? At least educate yourself on what it does and read about it before commenting on what it is. I am sure Eric has enough knowledge on it to debase it. But just a few posts ago you asked me if systemd got rid of sys v init which means you lack the understanding of how it works.
Have you even used it? No...
So I am stepping out of this systemd convo especially since I don't know enough to talk about it. I am just keeping my options open.
If it takes over the world, the question is what are you gonna do about it? If it gets discarded and lost in oblivion... then continue and carry on. Right?
Peace

Since that post I have read up on systemd on various technical mailing lists as well as forums.

So while I might not be practically using it, I have a fair idea of its features and functionality. Even from reading the systemd author's own website, it is a fairly complex piece of software that tries to achieve multiple goals and is beyond SysVinit in many aspects. And it has some hard dependencies on certain kernel configuration settings too. Again whether this is good or bad in purely technical terms is another issue, but one thing I said is that it is certainly not UNIX-like in approach and is designed to break the existing solution and cross-platform portability with other UNIX-like systems in order to work.

And exactly that is the problem. You can't.
Before systemd arrived we had a couple of init systems (SystemV, BSD-like, Upstart, ...) and they all lived peacefully together. If a developer thought that BSD-like would be better for his distro than he was free to use it, no one cried. Many distros even have compatibility to other init systems, like Ubuntu's Upstart is compatible to SystemV (and Slackware's BSD approach also). Also, if a open source developer thought that FreeBSD with Gnome would be a better platform for his software than Linux with Gnome he was also free to do it that way.
That is what Linux and open source is all about.

Now come Red Hat/Poettering/systemd/GNOME and say: We don't like it that way. Use systemd or die. We don't care if you want to use Gnome on BSD (in that case they really should put out the G of their name). Our software is the best and if you don't use it your distro is irrelevant and should fade away. If you don't want to fade away bow to us and use our software.
They are actively and intentionally destroying the choice, acting directly against Unix and open source philosophy.
And they are acting against the KISS philosophy, one of the main principles of Slackware and Arch. IMHO, Arch should delete being KISS from their agenda when switching to systemd.

This may be exaggerated, but I think you got my point.

7 members found this post helpful.

But in the end the most used distro "Ubuntu" decided to stick to upstart and not adopt systemd. So even if they plan on "forcing" systemd on everybody as you can see not everyone agrees with them. lets see what happens.
Example: Ubuntu chose to use Unity instead of Gnome 3 as well. Even with all that money you can't just force people to use software unless there is a valid reasoning behind it. Like I was saying look at the closed source monopolies. People are switching to open source for a good reason no matter how hard they try.
Ubuntu is taking what works and discarding what it doesn't like. (or imo is not letting Red Hat Monopolize on its software). It adopted pulse audio but it is saying no to systemd.
Slackware is the same it only adopts what the maintainer believes is good for Slackware. As long as Ubuntu stays systemd free I doubt systemd will end up being a threat. Look at Lennart's posts about Ubuntu. He is not happy about ubuntu at all.
As for Arch, I have never tried it. I just find the whole "rolling release" thing extremely unpractical and more dangerous then yum or apt-get. I much prefer Slackware stability over it. But I do admit they have some great Community Wiki and is a great distro to learn. But so is Slackware and I will prefer its stability over Arch even with its lack of docs and dep resolver. Never tried Arch but I just can't think of a rolling release possibly being more stable then a much more complex automated system as even an Ubuntu or Fedora.
I dropped out Fedora because of its "child locks" not allowing me to even do a
"iw set reg" for my wireless really pissed me off. Along with some printer configuration they overly complicated. Linux is supposed to be flexible.. wtf they make these stupid child locks for? The one thing I hate most in distros is child locks. I guess systemd may also have childlocks in it. I never read the whole 100+ pages of man to try to understand it I just skimmed over it. I don't take systemd serious enough to read all that crap. I will definitely agree and prefer a slower boot over more "Child Locks". But I don't know if it adds more locks or not. I am going with slackware again because I want a practical and flexible distro. Child locks and using a distro that uses its users as a lab rat is not the distro I want to use. So I am dumping Fedora. I'll try out Ubuntu or even Mint instead (which also have child locks! But maybe less.). Looks like I will end up with Slackware and to a lesser extent centOS with its old kernel again. Hopefully Slackware with its new kernel will work fine with my other Acer Laptop so that I can have it running on my laptop as well with ATI Catalyst. FTW!
In the end even Ubuntu will go down if they continue with all this childlocks and games... Trust me... People will find out other more flexible distros like Slackware and switch to it. Its not as easy to push b.s. software in an "open source" community. There is too many nerds ready to stand up to coding issues in systemd and systemd still has yet to evolve. Its a brand new init bugs/problems are expected and will be fixed if fixible. And if people don't like the final product (as Ubuntu has) then it will be discarded. If Bill Gates can't force MS Windows down peoples throats anymore I am pretty confident Lennart can't either.

I find that Slackware has a Comparative Advantage over RHEL as it is not focused on Profit. This way it can focus on making Slackware actually work then to bring up new technologies in order to fight competition as Red Hat or Ubuntu does. And with more users... the money will come as well.

While these big distros fight each other Slackware will have time to focus on itself and Grow even more. I see systemd as an opportunity for slackware not a downfall. Slackware should not worry about these other distros and just be aware of things and move accordingly silently and advance.

I will not be surprised if 5 years from now Slackware ends up as the most Popular Linux Distro if it keeps this up. Attracting Nerds is a great way to attract good developers to its team. Targeting nerds is a good thing rather then targeting masses like Ubuntu does. Practical will become Popular.

There is a fundamental way systemd could be completely obfuscated and deemed unnecessary, even deprecated, but without a complete development team to grab the project and run with it, there's no way to do it. However here's the idea in a nutshell.

1. fork the sysvinit code and begin work adding linear/parallel mixed loading of system resources. Unlike systemd which is complete parallel loading, sysvinit could offer a mixed solution loading batches of resources through scripted dependency resolution and speed up booting the system without sacrificing the stability of loading with a linear design. However, allow within the code to load with a compatibility mode that loads the system with the older Linear method. Beneficial to servers and desktops alike. Plus the existing debugging abilities of sysvinit could be carried into the new project dubbed something like SysVd. Make it portable to non-Linux also.

2. fork udev out completely from systemd and work on it as udev2.

There's always a way for the open source community to fight back against bad software and bad ideas. Build something better, more open system, and within the standards of not just the K.I.S.S. principles, but with the UNIX Philosophy in mind also.

1 members found this post helpful.

If this is systemd's claim to fame (which is the only thing I hear going for it), then it's the lamest problem to solve. I hardly ever boot, so any perceived advantage for this almost certainly goes away. My boot time is about 10 seconds, and if parallelization made it 10% faster, and if I actually booted once every month, I maybe saved 12 seconds. At that rate, if I could tackle not sneezing one less a month, I might actually make a comparable increase of productivity.

This one makes sense if there is going to be any choice of a fully functional linux system without systemd in not too long.

I know people, who would leave FOSS operating systems completely, if systemd becomes TINA.

The idea of sysvd is to do just as it says. Upgrade sysvinit enough to perform the same functions of systemd while remaining open-platform in design, except for one thing systemd lacks. Compatibility.

By using parallel loading however with some linear aspects to create a loading tree rather than a straight up parallel load sysvinit can achieve some significant boot time reduction and buy back some of what systemd doesn't offer... yet again a compatibility to go back to normal linear loading.

The parallel loading idea is founded and sane, but systemd doesn't offer control of that. It's just chaos. My proposal would be to not replace sysvinit, but to extend it in functionality to say, "we can do what you do systemd, but we can do it better, and we can do not just new stuff but old stuff also" By offering a hybrid parallel + linear mixed loading method you can load things like the branches of a tree without sacrificing stable loading of system services that may require a dependency that might not get loaded in parallel correctly.

The trunk of the tree would load linear by design, while the branches load parallel.

Basically... (example)

Core/Main Services - kernel, modules, networking services
Extended Services - framebuffer services, disk services, things like pcmcia, samba, cups, etc.
Optional services - x11 services, audio services, and other misc stuff.

It sounds a bit garble but if you take time and read it some it starts making sense.

there u go... i agree with you. Thats the way to deal with this. Instead of bashing systemd make something better to make it obsolete.

Actually no. You are optimizing something that rarely occurs. And it does not need to be solved by adding another fragile auto-magic service. It should be solved by the distribution or the system integrator.

To do sysvd, someone will have to sit down, create all the rules of interaction, and do a reasonable amount of testing to make the "distro" work. The assumption of dependencies between services gives you your speed. All is well until you insert/change program X that breaks the assumptions and you might as well throw it all out. Sounds alot like package dependencies, except this one can more easily break your system booting, as evidence by Alan Cox's issue. All to save a mere seconds of time.

Systemd is an over-engineered answer in search of a problem. There is no reason to give more credence to its existence by trying to compete by doing the same thing. I think the better, open solution is to allow the distributions pick the services and how to optimize them. In that, I think it is totally possible to kick the pants on systemd on parallalization with little effort using good old init if we are just allowed to pick a solution for ourselves. There is no need to change how it works. I already get 10 seconds to boot with stock slackware, and I never need to boot again, so how is parallalization useful?

2 members found this post helpful.

It seems like there's a simpler, more transparent solution to increasing startup parallelism.

If you have a "prc" bash script for every service which needs starting, start them all in parallel, but with all of them satisfying the following constraints:

• Whenever the script needs another service to be started before continuing, wait on the file associated with that service, a la something like:
  Code:

  while [ ! -e "$SYNCDIR/nfsd" ] ; do sleep 1 ; done

• Whenever a service has been started successfully, create the file associated with that service, as in:
  Code:

  touch "$SYNCDIR/nfsd"

rc.M could rm -rf and mkdir the $SYNCDIR directory before launching the other scripts in parallel, to guarantee a clean slate.

A nice thing about this approach is that it's resilient in the face of failures, especially when a human can step in and fix the failure. If nfsd fails to start, any services waiting for $SYNCDIR/nfsd will continue to wait indefinitely. If an admin notices things are stopped waiting for nfsd, they can fix whatever was keeping nfsd from starting, re-run the prc.nfsd script, and when it comes up all those waiting scripts will continue running as they should.

So, /etc/rc.d/prc.httpd might look something like this:
Waiting on the dependencies in reverse order like this helps assure that the script will only sleep once (since mysqld would only start after nfsd and inet2, and maybe or maybe not after saslauthd).

The "touch" command in the if clause is for other services having a hard dependency; the "touch" command after the if clause is for soft dependencies.

If the system was running a web service which required both httpd and mysqld to be running, they might make prc.httpd dependent on "$SYNCDIR/mysqld.started", for instance.

1 members found this post helpful.

Ah! Now we're thinking outside the box. Excellent.

So basically, even with any init style loading system all we need to do is script in parallel loading? Utterly brilliant. If an init system could be setup for parallel loading like this, could this be beneficial to Slackware, and more importantly could it be deployed and useful in the long term?