The existing sequential scripts already background some of the longer running, non critical-path tasks. I'm happy with what we already have - though I dare say it could be optimised further. However, I'd take systemd over some Heath Robinson contraption using while loops like the above

1 members found this post helpful.

for debian there is a Systemd to SysVinit converter in work

http://lists.debian.org/debian-devel.../msg00433.html

I think dismissing systemd is not the way to go but add on to it. What Debian is doing is great.

There is nothing wrong with a faster boot. The problem is complexity. I think as time moves on we will come with a better way offering a simpler way to config and a faster way to boot.

On servers, Debian, CentOS and RHEL are by far the most used distros. Don't know about Slackware, but I guess it has an honorable place. I've done some training in a local company recently, and all their servers were running Slackware. Nice surprise.

I guess Patrick as well as Eric put it eloquently enough. Dismissing systemd is the way to go. And as a side note: I'm usually I nice and peaceful guy, but whenever I happen to read an interview with Lennart Poettering or watch one of his public speeches, my blood pressure rises in a matter of seconds and I get a strong urge of sticking the guy's picture on my punching bag.

Maybe the solution would be to try to hack some NSA servers and then create some false evidence that points to Lennart Poettering, so after the subsequent trial he's not allowed to come near a PC for the next forty years or so?

3 members found this post helpful.

RH have long since forgotten their roots and become the Microsoft of the Linux world. One look at the slogan on their web page is a good indication. This is just more of the same, be it from Redmond or Raleigh.

I have to go with the "if it ain't broke, don't fix it" sentiment. It's like a colleague who recently bought a second SSD so he could put them in RAID 0 for faster boot. He gained about 2 seconds. What was the point? If you're so short on time than 2 seconds is worth all the time/expense, you have serious issues, and they have nothing to do with computers.

Servers require more automation then a workstation.
I find BSD's and their likes great workstations especially for a developer and engineer that likes to get their hands dirty as it is much more flexible. But maintaining a large server or even a cloud stack can be a challenge and requires automation in 1 way or another.

PS: Don't forget about Ubuntu Servers which are more commonly used in USA then Debian or CentOS in large professional settings.

It reminds me the heated discussions around udev/devfs/hoplug and static dev trees. The Lennart of the day was Greg Kroah-Hartman. Many ignored or derided the "interesting" udev rules language.

After some resistance, all distros adopted udev ("First they ignore us, then they laugh at us, then they fight us, then we win").

Obviously (I mean, obviously today), udev was a boon for distro maintainers --especially with the exponentially growing number and complexity of supported devices. It clearly helps Linux running out of the box on so many platforms. We even find it now in Slackware initrd!

I wonder if the same scenario is currently repeating itself with systemd...

Phil

2 members found this post helpful.

I can't give you an answer that would be foolish of me. Only time will tell.
Let's wait and see a few years from now.

The thing is as Eric and 3dfx said it, systemd is a solution looking for a problem. Sysvd (or an expanded sysvinit/bsdinit for that matter to include parallel loading) is a solution solving a problem and maintaining the problem is minimal and self-eradicated by an existing solution.

Systemd isn't like udev. Udev did replace HAL, Hotplug, and devfs which were aging and showing their limitations even on BSD and other UNIX systems with newer hardware. Udev was a dynamic system while hotplug/devfs/HAL was a static system witha dynamic layer, but it didn't always work as anyone wanted to.

Systemd is rewriting how we load an OS. Both sysvinit and bsdinit can be scripted to function exactly like systemd, however, the problem with systemd is Linux only, it's not open-UNIX standard. BSD, Solaris, Illumos, etc... none of them can use systemd which is what Lennart Poettering and Red Hat both want. He wants to help Red Hat eliminate any competition by sidelining and obfuscating and obsoleting any non-Linux OS. His claims that BSD is a toy OS, and that BSD is holding back free software development is a pale ruse.

In fact BSD at times is far more advanced that Linux because BSD, Illumos, and other UNIX systems allow for proprietary code to be included within the kernels, driver modules, and the system itself to increase compatibility.

If systemd become the standard, BSD, Illumos, Solaris, etc. have nothing to compete with other than sysvinit and bsdinit, and just about all ties between Linux and other UNIX systems will be completely severed.

1 members found this post helpful.

While I understand the necessity for exaggeration and agitprop to be able to rally the troops I don't think you have first hand accurate knowledge of Red Hat business strategies. If you don't then should you really comment on it as if you do? I'm not saying it's FUD but some just might read it as such. And while it could do with a technical analysis of what would be necessary (if anything actually would be) IMHO this discussion BTW is already interesting enough without having to resort to showing disrespect for a major Linux and OSS contributor. Please tread carefully.

5 members found this post helpful.

That's fine and all unSpawn, but often some people as myself can see meanings within meanings of motives towards what can be an ulterior motive that may go unnoticed and may send up a red flag. I seriously hope that isn't the case with Lennart and Red Hat, but I would hope it raises some questions by others to say "What is really going on?" and "Should we be worried?".

1 members found this post helpful.

I understand why RedHat distros and derivatives use systemd, being an in-house product. Has anybody interviewed maintainers of other distros why they decided to adopt systemd? In their view, are there technical merits to adoption or is the adoption little more than proverbial lemmings jumping over the cliff?

If you rubbed unSpawn the wrong way... then you definitely have pushed some buttons with those comments.

First of all I am 1 of those people that enjoys CentOS and RHEL. Sure, we are in a "Slackware" forum so all this appears OK to just bash Red Hat. But I have a lot of respect for them. I use Cent OS and I really am happy of it. Its the most Stable and Secure Linux distro out there that I have ever used. Its rock solid. Everything works great and Automation is great. I have never ever had "Dependency Hell" using CentOS. Also RHEL has contributed more to the Kernel then any other distro alone. The Kernel is the most important and significant part in a Linux OS.

So why all this hate? Everybody is just trampling all over RHEL in this forum and I don't like it being a CentOS user.

Have you even used systemd in your init?

I boot my computer with systemd all the time... Never had any problems. Works like a charm and its fast.

My Opinion this thread should be CLOSED (allthough interesting to read).

I don't think Reaper has anything to take back with the post you reference. I didn't read it as anything official - just one person's opinion. However, I do share his concern that Red Hat is not necessarily going to do what is in the best interest of the community all the time. They ship their kernel with backported patches applied, not as upstream source plus separate files. Now this systemd stuff.

Have you seen their latest ad copy?

"When is free more expensive?"

"And what you may not even realize is that pieces of your infrastructure, like community Linux®, are actually making your job more difficult."

I feel the onus is increasingly on Red Hat to prove that they won't bite the hand that feeds them.



http://lwn.net/Articles/430098/
http://www.redhat.com/promo/standard...00000006OsvAAE