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

71–80 of 129 posts

Re: Arch Linux to migrate to Systemd

#71

Post by aerique »

hollerith wrote: post #38
dredmorbius wrote: post #27

Earlier quoted context omitted.

How often do you reboot your systems? What is giving rise to the need to reboot them when you do?

My computer changes location at least twice a week as I commute between my place and my girlfriend's place. A Mac mini serves my needs very well because (including AC adapter) it weighs only 2.7 pounds, and I really appreciate having more ports than most laptops have and not having to pay for and carry around a bad keyboard and a laptop display. (I consider all laptop keyboards bad keyboards, and -- maybe because I a…

Have you tried Deep Sleep for hibernating your Mac?

http://deepsleep.free.fr/

Re: Arch Linux to migrate to Systemd

#72

Post by solenskiner »

dredmorbius wrote: post #18
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…

Exactly how precious are those CPU cycles? I mean, really. Can you put a dollar figure on them? And then contrast that with the dollar figure for consultant / employee / remote hands time to figure out WTF went wrong? There are numerous systems for managing services: monit is the best known, mon and several proprietary systems also exist. Nagios can tell you if the service is running or not (though it doesn't handle…

>Ubuntu's boot time is already down to 8.6 seconds

Well, ubuntu doesnt use sysvinit either.

Re: Arch Linux to migrate to Systemd

#73

Post by CJefferson »

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 argue I should get more sorted, but I don't really want to.

* One other problem you have is to do with Linux being used on both servers and desktops. I can see your problem. Personally, if my machine ever got in such a mess that they couldn't boot, I'd just reinstall, regardless of what had broken. I suspect most people are the same. However, I can understand if you want to be able to edit how your machine starts up, and fix it when it brakes.

Re: Arch Linux to migrate to Systemd

#74

Post by mseepgood »

ori_b wrote: post #14
adestefan wrote: post #13

Earlier quoted context omitted.

> Systemd loses the huge transitivity of shell scripting, and puts you in the position of needing to acquire a novel skill at the one time you least need to be learning and most need to be applying: when your systems won't boot straight: What about those that can't debug when a shell script breaks? Your answer is going to be that they have no business administering a server where a shell script is an integral part of…

> What about those that can't debug when a shell script breaks? Are they more able to debug when a systemd setup breaks? If not, it seems like a moot point to bring up. They're hosed either way. Although I do have to say, I like the systemd model. The use of sockets to do process activation and thus doing away with almost all of the need for dependency management is pretty cool. I haven't used it enough to pass judge…

> Are they more able to debug when a systemd setup breaks?

Yes, because no programming skills are necessary for editing systemd unit files.

Re: Arch Linux to migrate to Systemd

#75

Post by lmm »

jpiasetz wrote: post #54
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…

Is any of this really an argument against Arch adopting it? Arch and Gentoo and all the other rolling distros are the cowboy distros (I run Arch on my laptop). Literally anything can break with an update on Arch. Is Arch not the best place to try new ideas and see if they work out with a bunch of fairly technical users? I'm not about to switch all my servers to it but I'm more then willing to play around with it on m…

Just for the record, if you leave keywords at its default setting rather than ~arch you can run a perfectly stable system under Gentoo.

Re: Arch Linux to migrate to Systemd

#76

Post by lmm »

zik wrote: post #26
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…

I work on embedded linux boxes in vehicles and boot times are hugely important to us. The time from when someone turns on their car ignition to the time when our box is usable is critical. I understand that this feature isn't important to dredmorbius, but to some of us this type of improvement is fantastic.

You wouldn't run Arch on an embedded system though. At least, I hope you wouldn't.

Re: Arch Linux to migrate to Systemd

#77

Post by bkor »

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…

Dependency problems on Red Hat? News to me, and I admin various RHEL servers.

I do know that there were issues maybe 10+ years ago. Bringing things up that were solved 10+ years ago is a bit pointless.

Also regarding your systemd summary is inaccurate. You give the impression you just don't like Red Hat, because you don't really say anything concrete about systemd aside from some very generic remarks.

Re: Arch Linux to migrate to Systemd

#78

Post by bkor »

dredmorbius wrote: post #59
rogerbinns wrote: post #42

Earlier quoted context omitted.

Note that a better way of saying things is that systemd deals with state changes a lot better. Booting is one big state change, but when you have a laptop you go through a heck of a lot of other state changes (suspend, hibernate, resume), docking, connectivity changes (eg wifi coming and going), storage added and removed etc. You may let other people use your system (more state changes). systemd can also ensure that…

You can add state-change management to your system without mucking with really solid, stable, low-level, critical code like init. There's already hotplug support, xinetd, ifupdown's pre/post up/down stanzas, and the like (though networkmanager's screwing that bit up wonderfully). Chroot jails too. I'm not saying that these are perfect (and some are a very pale shadow of perfect indeed), but they're independent of ini…

Systemd on opensuse as well as Mageia is pretty damn reliable. It is not 'test bed'. Various distributions have been using this.

As a result, there are way less differences now between distributions. Which means configuration becomes easier.

In any case, if you really care about things not changing, then I assume you're using a distribution which doesn't change this suddenly. So I don't see why your so awfully negative.

Re: Arch Linux to migrate to Systemd

#79

Post by yew »

caf wrote: post #43
antihero wrote: post #23

Earlier quoted context omitted.

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

...except that those things do still need to be re-implemented in every program that requires them, since most POSIXy programs are portable to more than just systems using systemd.

This being my primary problem with the current upheaval in Linux system organization. Its instigators have mostly made it clear that they consider everything not Linux (or possibly preferably not their favorite flavor thereof) to be obsolete - throwing portability out the window.

Frankly, it's getting old.

Re: Arch Linux to migrate to Systemd

#80

Post by bkor »

dredmorbius wrote: post #66
Nelson69 wrote: post #39

Earlier quoted context omitted.

Boot times is one thing. Upstart and systemd provide tons and tons of other features though. Restarting of crashed processes, dependencies, etc.. They also generally have much more simple config files instead of start up scripts. I don't know how many crappy startup scripts I've seen over the years, when in practice: set these environment variables, execute this program as this user with these arguments is 95+% of wh…

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.

Post reply on HN