The boys from Intel boot linux in 5 seconds using init and readahead
https://lwn.net/Articles/299483/

So I guess they used a stock eeePC from 2008? It doesn't say they changed the SSD out. That machine is nothing special. I know because I have one. I guess my machine might be a model newer. I have been running slackware 14 and just this last week I booted it, and it was done, and it felt very fast. I guess I never thought about it before. And I don't do anything special with my machines either.

Although I am really trying to rethink my userspace. Slack 13.2 & 13.37 were pretty good. Moving to 14, I'm finding that I am simply just dropping things that I find don't matter. Right now I have no upower, udisks, polkit, or consolekit. I haven't lost out on much. I have been thinking about dropping udev, what that would do. My goal isn't faster boot, but taking back control of things that I already know how I want it. It isn't that unfathomable, as we used to not have these things, and I remember what was done then. But today the kernel is nicer, and /sys is a way to get at alot of what that stuff was doing.

But anyway, so while my goal is not booting faster (on my machines, I rarely boot so it don't matter), but I can see how the mess of daemons that we got going might actually get to become more detrimental to the boot process. And while some people keep working out complex solutions to get to keep it all and the kitchen sink to boot fast, it is obvious that init wasn't the problem, but turned into the scapegoat--because who wants to hack on a bunch of shell scripts anyway, right?

I remember reading the article when it came out, but this particular part caught my eye this time:
"udev is used only to support devices that might be added later—the system has a persistent, old-school /dev directory so that boot doesn't depend on udev."

This is funny, because there are certain people now trying to push udev up earlier in the chain of initialization to solve some order dependency thing to boot faster. But LPC/intel found their solution was they didn't actually need it for anything during boot, it's only nice to have after the user gets control. It's a nice supplement to a recent udev discussion that I recently saw over the stuff that people are trying to push on us now.

Did not realize this was an old article.
My attention was attracted by the same paragraph. Seems maybe the old way is better
John

EDIT read September 22.
went back and read the rest '2008'

Isn't this the original drafts of tests the usage of SysVInit parallelization scripting techniques that were to make systemd unnecessary?

They were only able to do that because they set up the system with *known* hardware and boot-method, or by including all the possible needed device nodes. Still, the linux kernel can now set up the first few basic devices nodes, but I'm not sure it can create any and all of the possibly-needed ones for you.
The 'moving ahead' of udev has to do with its' inclusion in systemd. Since systemd is started as process 1 and depends on libudev, that means that udev would be loaded and available at the same time as systemd.

If it seems I'm defending systemd, don't be fooled. I use sysvinit with a 'boosted' init system which boots(to CLI login) in around 6 seconds, and to GUI login in 10 seconds -without having to patch Xorg and so many other things as was done for the system in the article.