Hacker News Reader

Comment by mverwijs | Hacker News Reader

I still do not understand what problem upstart or systemd are trying to solve. Slow boot times? Have you ever even booted an HP DL360? Or any server? Of the entire 8 minute or so process, sysv init only takes up 10 seconds. So what is the problem?

Containers of Debian 7 (openvz) start in seconds, with sysv init. My laptop dito.

What am I missing? Android? That takes forever to boot and I have no idea why. Could be that systemd fixes that problem.

To me, Systemd and upstart come across as modern-for-the-sake-of-being-modern.

View on HN

* Sh is a terrible language to build any non-trivial functionality. * System initialization has become more complex. * Currently, managing daemons has a lot boilerplate code. * That code is sub-optimal and fragile.

Personally, I don't want to know anything about the timing on which each device is available, to figure out manually the right order to start the services. That's the kind of job a program can and should do. I didn't like when I have to set IRQs manually too, or when X asked me about the data of the video chip that was connected to its bus.

Back to the init scripts. How do those scripts know if a daemon is still running? One mechanism is to check the existence of a file with the daemon's pid! IMO the current system is an anti-aesthetic patch. Only inertia keeps it alive.

This is what I would like to see in a linux system:

* A common config language for the basic services. Something like the defunct [elektra initiative](http://freedesktop.org/wiki/Software/Elektra/) * An automate mechanism to orderly start the system. * Something like Dan Berstein's daemontool to handle the daemons, plus the cron jobs. * For Ritchie's sake, keep logs as text files!

daemontools has the best philosophy for this in my opinion: just start the service. If the prerequisites are unavailable, the service will just terminate. If that happens, wait one second, then try start again.

It's perfect. No stupid 5 minute timeout like sysvinit, no stupid dependency management like systemd/upstart, very little to consider when adding new services.

If you want to use it as your init.. just look into 'runit-init'. I've been using this for 4+ years, and it's fantastic.

My LG G2, running android 4.2.2 with a 3.2.0 kernel, boots in about eight seconds from cold. It also has the best battery life of any smartphone I've ever seen (24+ hours, of which 8+ with screen on and doing things is normal on any day that I don't play 3D games.) SysVinit.

My boring house server, AMD FX4130, boots from a small Intel SSD in forty seconds from power to 0 load. Debian stable, sysVinit.

I understand sysVinit. I can debug it. When things go wrong, I can stop it, figure it out, fix it and start it again.

Being able to figure things out and fix them is the heart of UNIX. I'm not against progress, I'm against screwing things up in the name of progress.

OpenRC looks interesting.

My android (Huawei G500-0100) boots in 1.5 minutes. Does that mean that we have to ditch OpenRC or whatever init system it has?

You LG2 has probably optimized, vendor/hardware specific scripts, SysVinit does not achieve the same perfs on my high-end laptop.

You may want to have a look at this short conference from linux.conf.au, about systemd from the point of view of a sysadmin: http://www.youtube.com/watch?v=-97qqUHwzGM

My midrange old laptop (Intel Core2Duo, 1.4GHz, Intel SSD) boots in about thirty seconds from cold to X login with sysVinit. Again, Debian Stable, nothing odd going on.

There are tools to look at what your laptop is doing during boot time.

I've seen the systemd and upstart propaganda, and find it unconvincing.

Propaganda? Jeez.

sysvinit is long overdue retirement - I've worked with it for many years can't wait for it to die.

It can't handle power management, it calls out to a multitude of scripts/external applications just to stop start and restart (oh, and which command options are the correct ones to support?), it can't manage processes through their lifecycle.

People constantly trot out that it's not the unix way... Linux is not unix. X is going away next, are you going to fight to keep that all the way too?

Also, why use external tools to analyse the bootup? $ systemd-analyze Startup finished in 785ms (kernel) + 395ms (initrd) + 2.184s (userspace) = 3.366s $ systemd-analyze plot > file.svg

> I understand sysVinit. I can debug it. When things go wrong, I can stop it, figure it out, fix it and start it again.

"I don't want to learn new things. I labour under the delusion that tens of thousands of lines of shell code is a clean solution" is all I hear.

Then you did not read or failed to understand the line that came after the one you quoted.

The post linked describes quite well an example situation systemd solves, and why something like systemd is needed. Perhaps you should look at it.

Isn't that an implementation detail though? sysvinit is just a series of scripts that are grouped by runlevel. It says nothing about what those scripts must do; it could very well be that a better implementation of the mounting scripts fixes the problem without having to throw out the baby with the bathwater.

OpenRC is exactly that.

Devices come and go. This is explained in the linked article…

As far as I know, it's just features, features, features: http://0pointer.de/blog/projects/why.html

Have you watched this video? http://www.youtube.com/watch?v=-97qqUHwzGM

It's a good introduction to the things systemd brings to the table and why it's worthwhile.

Server hardware init is also a problem, the Coreboot project started because of that (IIRC one admin mentioned something in ~hour for a cluster).

Android does not use sysv init, it uses its own init program (keeping the name, but completely different).

>I still do not understand what problem upstart or systemd are trying to solve

Linux systems are still too much like unix. There are still some simple components that do a single, simple task, and can be easily debugged. This is clearly not acceptable, and does not fit with the rest of a modern linux distro. It needs to do more things, be less reliable, and be harder to figure out when something has gone wrong. Systemd and upstart both solve these problems nicely.

Well.. Lennart points this out, then walks right past it. The problem isn't the init, or the boot process, or any of that. The problem is the reliance on 'fstab'.

This is where Lennart/Freedesktop kill me; rather than notice that the underlying mechanism should be replaced, they figure they should just build a better mousetrap on top of it.

If you want to make linux more "desktopy" without screwing around too much with stupid initd decisions, then fix some of these broken underlying mechanisms.

Unless he's really suggesting that my big problem is that my /usr partition might be on a removable device.

Reply on news.ycombinator.com