Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Arch Linux to migrate to Systemd

mailman.archlinux.org

Post reply on HN
Print view View original

111–120 of 129 posts

Re: Arch Linux to migrate to Systemd

#111

Post by dredmorbius »

jwcacces wrote: post #50
thaumaturgy wrote: post #29

Earlier quoted context omitted.

I'm a daily laptop linux user, specifically Chakra Linux, http://chakra-linux.org/ . My wish list goes something like this: better wireless drivers, improved sleep/suspend/hibernate/resume, better power management, a better package manager, more up-to-date applications ... At the very, very bottom of that list -- the very last item, so far at the bottom of the list that it's in danger of falling off entirely -- is "f…

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.

The OS and tools do all the magic bits.

Re: Arch Linux to migrate to Systemd

#112

Post by dredmorbius »

bkor wrote: post #80
dredmorbius wrote: post #66

Earlier quoted context omitted.

I mention boot time because it's what's pointed at specifically by Poettering in his arguments for systemd as its core benefit: http://0pointer.de/blog/projects/systemd.html The other functionality may be nice, but 1) it's got no place in init and 2) really complicates a key piece of system infrastructure. Complexity and change are the two dual enemies of stability. As an old-fart ops type, with scars on my hide and…

One great benefit to stability is the amount of users. Sysvinit was different in every distribution. With systemd, almost everything is shared. This results in way more users and developers looking at systemd. As a result, less bugs.

http://xkcd.com/927/

Re: Arch Linux to migrate to Systemd

#113

Post by dredmorbius »

gillianseed wrote: post #104
pjmlp wrote: post #90

Earlier quoted context omitted.

Yeah, but then when developers in other OS besides GNU/Linux take the same attitude, they get bashed to death for not caring about portable software.

do they? do you have any examples?

Microsoft.

Apple.

IBM.

DEC. Oh, wait, that didn't work out so well, now did it?

Re: Arch Linux to migrate to Systemd

#114

Post by dredmorbius »

CJefferson wrote: post #73
dredmorbius wrote: post #11

Systemd 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…

While I understand why you don't want to boot all the time, some of us do. Here are some reasons: * Despite years of work on it, I find sleeping on laptops on linux is still flakey. My Thinkpad T420s failed to wake up about once a week (on Ubuntu), so I tend to shut down. * I like having a clean desktop when I start on a morning. If I keep sleeping my machine, I just tend to gather up programs. Of course, you could a…

1: File a bug report. As I said: if you want faster boots, boot less. We should be fixing problems (like hibernate/restore flakiness) that cause people to reboot. Or long-term power draw that requires embedded devices to require poweroff. Or flash read/write duty cycle limitations that limit the ability of embedded devices to save state / the rate at which they can save/restore data. Etc.

2. You can bounce your X session. No need to reboot the full box (me? I prefer saved state).

3. My servers may be anywhere from several feet from me (stuffed into a closet with limited access and a crap POS keyboard and monitor) to tens to thousands of miles away. With varying values of ILOM / remote hands / virtual media support. "Reinstall" isn't generally a highly tenable operation. Being able to handle issues without having to dedicate one or more staff days to travel and unavailability for other tasks really sucks productivity down.

Re: Arch Linux to migrate to Systemd

#115

Post by dredmorbius »

throwaway54-762 wrote: post #19
dredmorbius wrote: post #11

Systemd 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…

Your "much written better than I can" article is about Upstart, not Systemd. They're unrelated init daemons, and it seems like many of the complaints in the article relate specifically to upstart (event-triggered services with no dependencies, minimal scripting support, killing daemons, not all daemons managable by upstart) but do NOT apply to systemd. Systemd has service dependencies, support for old-style init scri…

And the article I had in mind to post:

Juliusz Chroboczek: A few observations about systemd http://lwn.net/Articles/453004/

Editorial / discussion at LWN: http://lwn.net/Articles/452865/

And for the record: I'm not particularly much a fan of upstart, but it annoys me somewhat less than systemd.

Re: Arch Linux to migrate to Systemd

#116

Post by dredmorbius »

sprash wrote: post #86
planckscnst wrote: post #37

systemd is so obviously better than anything out there, I'm surprised there is any controversy. I've yet to see a valid complaint. "Poettoering sucks! PulseAudio!" That's not much of a technical argument against systemd, now is it? Pretty much everyone who complains about PulseAudio doesn't even know what it is; they just blame it when their audio doesn't work (usually for some unrelated reason). "It's not determinis…

It doesn't matter if systemd is written by Poettering or somebody else and it also doesn't mater that we don't have shellscripts any more. The real reason systemd should never be accepted is that I need programs to configure or talk to other programs. I even need a special program to read logs. This is the replacement of files with APIs. It feels like an enterprise class product which means it sucks all the fun out o…

Oh yeah. I'd totally managed to repress my memories of the systemd journal:

http://linuxkommando.com/2011/11/systemd-journal-will-revolu...

#whatcouldpossiblygowrong?

Re: Arch Linux to migrate to Systemd

#117

Post by dredmorbius »

planckscnst wrote: post #109
sprash wrote: post #102

Earlier 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

I've got bash (erm, POSIX shell) interpreter on ALL my POSIX systems. I can guarantee you that.

C compiler? Not so much. Servers (security risk, more moving parts), embedded (space/power requirements).

Re: Arch Linux to migrate to Systemd

#118

Post by dredmorbius »

ijobs-ly wrote: post #82

In my biased opinion, once you have gotten over the learning curve, nothing beats daemontools for running services. It is a fantastic set of tools. Why some OS doesn't just embrace djbware I'll never understand. It compiles, smoothly, in seconds. (There's no need for distributing binaries.) And the chances of the author initiating lawsuits (as some Linux foundations are known to do), over something placed in the "pub…

Debian (and other apt-based systems) are the Lego blocks systems of the Linux world. If you install a service, the assumption is that you want it to run (if you don't want it to run, you can either uninstall it or deactivate it). Bootable / live versions tend to have more comprehensive lists of installed packages to allow for greater utility/flexibility -- though some (Knoppix) actually allow you to install additional packages (yes, booted RAM-only) into the booted system.

The is not the case on BSD systems (generally an integrated whole, though they've got package management) or RPM (poorer package management leading very frequently to a "kitchen sink" installation paradigm).

Yeah. RHEL's even got a package you can install to enable/disable postfix vs ... oh, whatever the default MTA is, I can't keep track (smail still? I know they've moved off of sendmail, right? Right?).

Re: Arch Linux to migrate to Systemd

#119

Post by sprash »

planckscnst wrote: post #109
sprash wrote: post #102

Earlier 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

>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

#120

Post by Ralith »

alrs wrote: post #55
FooBarWidget wrote: post #16

Earlier quoted context omitted.

I'm sorry, but shell scripts suck as a language for booting the system. You need to fork() and exec() for almost anything non-trivial, wasting precious CPU cycles in the progress. It looks like every Linux distro has its own way to manage boot scripts. And when they fail, you have no idea what happened. More importantly, init only handles starting and stopping of services. They don't manage services, like restarting…

I have a Debian laptop. ls -alh | wc -l returns 89. I can subtract "..", ".", and the "totals" lines, so that's 86 init scripts. Big O for 86 scripts is 86 * n, which simplifies to "n". I'm not concerned.

"Oh, and because each script runs in less than an hour, we can just say n = 1 hour, and that's a constant, so it simplifies down to instant!"

Yeah, that's not how computational complexity works.

Post reply on HN