It's maddening seeing badly misconfigured linux coming pre-installed when the cost of doing it right would be minimal. My eeePc was like that, they put so much money into design, manufacture, marketing, but shipped a nearly unaltered version of some Debian knock off that was so badly misconfigured it made my teeth cry. It's no wonder it did not sell well, it was junk as shipped. A few hours of work and it was wonderful! Slackware base, a minimal window manager, and virtual memory ON (obviously configured by someone who only knew windows and thought virtual memory==hard drive thrashing) and the thing ran wonderfully. But how many buyers ever saw it properly configured?

And of course their market failure was because linux sucked. NOT because this huge multinational corporation could not be bothered to hire a competent linux guy to spend a week configuring their distribution so it would work acceptably on their hardware, no.

3 members found this post helpful.

I agree. It used to be the hardware was custom designed to do the job at the lowest price but I can see the end of doing it that way. Look at the PRUSS unit in the Cortex A8. It makes it so versatile. You can grab a Beaglebone Black off the shelf for around $50 and use it to replace an industrial computer with a high speed I/O card that would cost a few thousand. And thanks to Linus getting fed up with the constant changes required for ARM devices we now have device tree support in the kernel. As long as 2 boards with completely different I/O use the same processor family you can use the the same linux install. The only thing different are the device tree files.

When I refer to fast boot times, I'm thinking around 1 second or less. You won't get that just by not using an initrd. In an industrial environment a slow bootup makes a noticeable difference. Safety is a big issue these days and a safety system is like Windows - it has to be designed for the dumbest possible user. (which is why I don't agree with people who want to see Linux on every desktop. Let Windows and Android cater for that).
Which means most safety policies require a full lock out of the whole machine. Shut it down, work on it, boot it up and test, shut it down again..... really annoying and costly when boot times are longer than a few seconds.

So for Linux to be a serious contender in the industrial and embedded world, a fast boot time is a requirement.
At the moment systemd is helping provide that but is that what we want to be stuck with? I don't. Lennart's way of doing things doesn't bear well with me.

The problem with init is always going to be time to initialize all the hardware and services correctly. In that you have the dilemma of time versus correctness. In the end regardless of how much speed you try to introduce to shave off time, correctness always has to be a constant variable. Either it's correct or it's inoperable.

No, you do that by replacing the kernels init function with one for the specific application.

1 members found this post helpful.

You guys are seriously still talking about boot times? systemd does so much more than provide a faster boot. It's secondary to what it really aims to provide.

Check out how Pantheon patched Heartbleed for 60,000+ sites. Containers and systemd work very well together - it's no wonder Red Hat is getting involved with Docker.

It is also so much more complicated than what needs to be reliable.

That is why it still hangs somestimes on boot or shutdown, and doesn't do what needs to be done, and forces awkward interdependencies.

2 members found this post helpful.

That is the problem. PID 1 should not do that.

Yeah, that's really part of the problem, as others have indicated. PID1 is not the place to do all the other stuff systemd does. Some of it may well be good stuff to do, just not in the initial process.

The fallacy here is that you need systemd, specifically, to do this. You dont.

Patching a running daemon on running servers is a very old problem and it's almost embarrassing how they seem to be genuinely proud they pulled it off without a reboot. Which brings up a delicate point I hesitate to mention, but so much of what they are doing appears to be NIH syndrome from people whose education focused on Windows rather than Unix. Problems that Unix solved decades ago are perceived as new and unsolved, and the new 'solutions' always seem to involve more than a little "windows does it like this."

Replacing text files that can be manipulated using very robust and mature tools we have all spent a significant portion of our life mastering and replacing them with a binary file only editable using new, immature tools developed and controlled by a central source, hmmm, where have I seen that before?

4 members found this post helpful.

Not that again. Only very few things done by systemd run in PID1.

Can you elaborate on that?

It is a very old solution... its called "mv".

Nearly all the installation tools use it...
1. install new file as file.new
2. rename current file to file.old
3. rename file.new to file.

Or use a hard link (which is actually faster...)

1. install new file
2. remove link.
3. create link to new file.

In the VERY old days you had to use the first method with shared libraries as well. The reason you had to keep the file.old was that current processes might be using it, and if you deleted it then those processes could get a segfault.

Linux filesystems don't actually care - if a process is using a shared library the in-memory inode carries a reference count, removing the link from a directory doesn't delete the file (which only decrements the in memory link count, and removes the name from the directory). The file isn't deleted until the link count goes to zero...

This solution goes back to SunOS 2.xx days, around 1985.

3 members found this post helpful.

I still laugh at how people say BSD/SysVinit is slow to load.

Learn to do dependency based foreground style tree loading of resources, move non-required startups of certain unessential background services like Icon updates to cron-jobs, disable unused daemons, and SysVinit used properly is actually quite fast.

1 members found this post helpful.

Does anyone know about a distro Arch-like but with no systemd?

CRUX.

There is work done by a few guys at archbang to replace systemd with either bootscripts and eudev, runit and eudev or openrc en eudev.
Here is a link to a subforum on that:
http://bbs.archbang.org/viewforum.php?id=26