I don't really understand the problems these "init" replacements wish to solve. I mean, actual, real-world problems. To me, it's just another instance of the same worrisome trend that brought us NetworkManager and makes everything evolve to integrate with D-Bus: do everything to make desktop-Linux better, even if it negatively impacts the use-cases where Linux is actually successful (everything else). I don't care mu…
I have little experience with servers, but... I must agree with your sentiment. One of the great things about Linux is how simple things are. GUIs are great, but not if I have to start a desktop just to get a network connection!
Arch Linux to migrate to Systemd
121–129 of 129 posts
Re: Arch Linux to migrate to Systemd
#122Earlier quoted context omitted.
1) What's not hackable about C? 2) When was the last time you hacked on an init script? > Ideally an init system would be a lean and smart turing complete scripting language and every feature is implemented on top of it. You would probably really like NCD[1] as an init system. I was considering doing that in an embedded system I make until systemd came around. 1: http://code.google.com/p/badvpn/wiki/NCD
>1) What's not hackable about C? Several tens of thousands of Lines of C code are a lot less hackable than a few lines of shellscript >2)When was the last time you hacked on an init script? A few months ago, writing an intelligent battery monitor for my notebook. NCD looks great btw. but it is not an init system.
Re: Arch Linux to migrate to Systemd
#123Re: Arch Linux to migrate to Systemd
#124Earlier quoted context omitted.
The lack of hackability is not fun. And some strange new programs won't make up for it. Bash might indeed be not the perfect thing for an init system but having no scripting capabilities at all forces systemd to implement everything hard-coded. What if that hard-coded Blob lacks a feature I require? What if that hard-coded blob contains errors? What if that hard-coded Blob contains security risks? systemd opens a lot…
1) What's not hackable about C? 2) When was the last time you hacked on an init script? > Ideally an init system would be a lean and smart turing complete scripting language and every feature is implemented on top of it. You would probably really like NCD[1] as an init system. I was considering doing that in an embedded system I make until systemd came around. 1: http://code.google.com/p/badvpn/wiki/NCD
Re: Arch Linux to migrate to Systemd
#125Earlier quoted context omitted.
I'm a daily laptop linux user, and like you I know how to go a long time between reboots, so I can wait for my computer to start up. But forget about us, we're already converts, we don't matter. My grandfather (93 years old) is also a daily laptop linux user. When he presses that power button, that laptop better be booted and ready /yesterday/. And when he pushes it again, it better be off before he closes the lid. S…
That is really cool, both your grandfather using a Linux laptop and the boot time. Could you name a few components you used?
Honestly, I think the SSD has the most to do with it.
Re: Arch Linux to migrate to Systemd
#126Earlier quoted context omitted.
I'm a daily laptop linux user, and like you I know how to go a long time between reboots, so I can wait for my computer to start up. But forget about us, we're already converts, we don't matter. My grandfather (93 years old) is also a daily laptop linux user. When he presses that power button, that laptop better be booted and ready /yesterday/. And when he pushes it again, it better be off before he closes the lid. S…
The sane thing is to tie power management to the power button. Light press: hybrid suspend suspends to RAM, also saves state to disk -- system spins down quickly and, so long as it's not been hibernating long enough to drain battery, restores in a second or so. Longer and it will do a boot/restore from disk. Long press: powerdown. Many devices have separate "suspend" and "poweroff" hardware (or soft controls) as well…
To the non-enthusiast / casual user, closing the lid, pressing the power button, doing a system shutdown, inactivity sleep timeout, and the battery running out are all the same thing: the computer was "on", now it's "off". Asking someone like this to think about how the reason it came to be "off" affects how fast it will be ready for them later is a fool's errand. It needs to be fast in every circumstance.
Normal people just want to get something done. They judge their computer by how easy it is to use and how fast it responds to what they do. That included cold boots, launching program, and downloading webpages. Even if they're doing something "the wrong way", they will still judge it with the same criteria and the same harshness. I want my grandfather to use linux because I can quickly help him and fix things from afar, and because there are very few ways for him to mess it up. He uses it because he really thinks it's better then windows, and that's purely because it's fast and easy, every way he uses it.
For the record, I set it up so the power button does a shutdown, and everything else results in a hybrid sleep. What he understands that he can shut it down if he wants, otherwise no matter what happens (lid closed or not) everything will be the way he left it, even if he forgets about it for a few days or doesn't charge it.
That kind of simplicity is what allows people to think of linux as something they can use, not just some super complicated tool for "hackers" and "computer geniuses". I'm not saying it should be dumbed down or have options removed, but I am saying that making it enjoyable for everyone results in more people using it, and that benefits us all.
Re: Arch Linux to migrate to Systemd
#127Systemd takes a reliable, known, thoroughly debugged process (init, or various of its tweaks, including Ubuntu's upstart and Debian's insserv ), and converts booting from a deterministic, predictable process to one that's inherently unpredictable . And the stated objective? "To reduce boot times". The best way to reduce boot times is to not boot . The reason I reboot systems is to return them to a known good state (o…
On server hardware, I perform boots infrequently, and really, really, really want them to work right. My philosophy is different. Make a change to a server, reboot. The goal is to eliminate surprises if the server is restarted unexpectedly. I'd rather have them during the maintenance window than at 03:30 after a power outage. Anyway - to systemd. I was appalled when we moved up to Solaris 10 and the SMF facility star…
AT&T ran into a little restart issue, as I recall, in 1990 when a software upgrade gone wrong crashed much of the phone network. Among the problems were that most of the switches had been upgraded in place, many over decades, and there had never been a cold-boot restart. There was some uncertainty as to whether the system would start up properly or not.
While long uptimes are nice, I generally prefer seeing a few reboots annually just to be sure things will come up right. There's a balance between "restart for every change" and "restart regularly enough to not be surprised at 3am".
Re: Arch Linux to migrate to Systemd
#128Systemd takes a reliable, known, thoroughly debugged process (init, or various of its tweaks, including Ubuntu's upstart and Debian's insserv ), and converts booting from a deterministic, predictable process to one that's inherently unpredictable . And the stated objective? "To reduce boot times". The best way to reduce boot times is to not boot . The reason I reboot systems is to return them to a known good state (o…
developers boot more often than normal users
Now it's other stuff. With chef and automated system management, repeat 'apt-get update' runs, which even with local caches and other tricks give about 120-150s per startup.
Re: Arch Linux to migrate to Systemd
#129Systemd takes a reliable, known, thoroughly debugged process (init, or various of its tweaks, including Ubuntu's upstart and Debian's insserv ), and converts booting from a deterministic, predictable process to one that's inherently unpredictable . And the stated objective? "To reduce boot times". The best way to reduce boot times is to not boot . The reason I reboot systems is to return them to a known good state (o…
Except in practise, systemd works fantastically and you're all worried about nothing. Systemd also does much more than that and handles stuff like daemonization and socket creation, so that these things don't need to be re-implemented in every program that requires them. Bash scripts are overly verbose, repetitive, and awkward in comparison to unit files. And you can always use sysvinit if you still aren't convinced,…
Software has bugs.
Core, deep systems software has subtle bugs, or hidden bugs, or emergent bugs, or any of a whole host of things.
If arch and fedora want to ride this tiger, I guess they can.
Again: init is really, really stable stuff.
Add in hooks to journald, d-bus, and the equivalent of an xinetd replacement/upgrade. Too much change.
And a Really Bad Attitude from the developer. My experience (a few decades of beating around on various tech at various scales) says this doesn't bode well.