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

31–40 of 129 posts

Re: Arch Linux to migrate to Systemd

#31

Post by jacques_chester »

There's a whole bunch of tools groping awkardly in a single direction here:

1. Give a graph to the computer

2. The computer makes the graph a reality

http://chester.id.au/2012/06/27/a-not-sobrief-aside-on-reign...

Puppet, Chef, Cfengine come at it from an on-disk direction.

Upstart, SMF, systemd, launchd come at it from a runtime direction.

They're still talking past each other. And it's annoying.

What I would really like is a system that does both as first-class citizens. I may be waiting a while.

Re: Arch Linux to migrate to Systemd

#32

Post by dredmorbius »

dfc wrote: post #30
dredmorbius wrote: post #17

Earlier quoted context omitted.

If they can't debug it, they can find someone who can, and that skillset is, I can guarantee you, going to be far more widely available than Systemd debugging fu. On which point, specifically: when Debian breaks during initrd execution, the system is dumped to a shell, "dash", a POSIX-compliant shell. It doesn't have all the niceties of bash, but it's usable. When a Red Hat system breaks during initrd execution, the…

If you want bash instead of dash: dpkg-reconfigure -p low dash Its that easy to get bash back...

I can live with dash. It's living without terminal IO that sort of puts a damper on things.

Re: Arch Linux to migrate to Systemd

#33

Post by ominous_prime »

The opposition that is seen from some people to moving away from SysV style init is amazing to me. I don't have much experience with systemd, but upstart has been a refreshing change from the old shell scripts.

Having been both on the packaging side, as well as the admin side, I can't imagine not abandoning the daemonize and PID file paradigm. The number of package I've seen that have init scripts that don't properly stop or start the daemon, or don't check the pid file and or subsys lock file; or daemons that don't properly chdir, or don't release an errant file descriptor, make me want to scream. Not to mention the process monitoring and full lifecycle management, it just seems like a no-brainer decision.

There's a lot of noise coming from people saying that their laptop doesn't need it, booting isn't that slow, etc; the driving force isn't targeting laptops/desktop, it's targeting the largest use of Linux -- servers. The process management is the big win, and boot time is just a bonus.

Re: Arch Linux to migrate to Systemd

#34

Post by dredmorbius »

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.

Any reason you can't just sleep/suspend your system at ignition-off? I can see that there might be times when the system does go down hard and you've got no option but to reboot, but still, that should be rare.

I work with a fair number of embedded systems myself. Most avoid full boots where possible.

Re: Arch Linux to migrate to Systemd

#35

Post by jlgreco »

thaumaturgy wrote: post #29
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'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 am not sure I understand how systemd's development inhibits progress of any of the things on your wish-list.

Re: Arch Linux to migrate to Systemd

#36

Post by ansible »

dredmorbius wrote: post #34
zik wrote: post #26

Earlier quoted context omitted.

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.

Any reason you can't just sleep/suspend your system at ignition-off? I can see that there might be times when the system does go down hard and you've got no option but to reboot, but still, that should be rare. I work with a fair number of embedded systems myself. Most avoid full boots where possible.

Depending on the app, sleep may be possible. But for some apps, like automotive, it is not surprising to see requirements like current draw being less than one milliamp in the sleep state.

I haven't seen or heard of any embedded apps which hibernate to flash. That would not be terribly fast, and would wear out the flash quickly.

Re: Arch Linux to migrate to Systemd

#37

Post by planckscnst »

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 deterministic!" You're probably talking abot the socket activation. That part is pletny deterministic - a message comes in for a service, that service gets started. Are the messages coming in not deterministic enough for you? You can add your own unit files that starts the service at boot, and you can even control what starts before and after the service.

"Shell scripts are so simple!" You know what's simpler than a shell script? A unit file. They are also more consistent. The various shell scripts are all written by different package maintainers and are rediculously diverse. Some are full-featured init scripts that can send signals to the service to make it do stuff; others can't even restart the service. Unit files are so simple that it's pretty hard for any different styles to really matter.

Also, the method for enabling a service is different in all the distributions with shell scripts. Debian is update-rc.d; Red Hat is chkconfig; Arch is vi /etc/rc.conf. With everything moving to systemd, we finally have one way: systemctl.

Re: Arch Linux to migrate to Systemd

#38

Post by hollerith »

dredmorbius wrote: post #27
sciurus wrote: post #21

Earlier quoted context omitted.

You're going to bash systemd but give a pass to upstart? Give me a break. Upstart is just as radical a departure from SysV init as systemd is, but the documentation (and IMHO, features) is much poorer. As far as I can see your arguments are 1) you boot your systems infrequently, so any work in that area isn't valuable 2) socket-based activation is somehow not predictable 3) you're familiar with shell scripting, so a…

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 am "far-sighted" -- much prefer my girlfriend's 32-inch TV to any laptop display.)

But since the Mac mini does not have a battery, S3 sleep mode does not survive unplugging the device. And since suspend-to-disk is not supported by the OS I run, shutting down is the only option.

P.S., I would have preferred something like a Mac mini, but with a small battery that powers S3 sleep mode. Sadly, I could not find anything like that on the market.

P.P.S., I run OS X on it. If I were to switch to Linux, would suspend-to-disk work reliably?

Re: Arch Linux to migrate to Systemd

#39

Post by Nelson69 »

dredmorbius wrote: post #27
sciurus wrote: post #21

Earlier quoted context omitted.

You're going to bash systemd but give a pass to upstart? Give me a break. Upstart is just as radical a departure from SysV init as systemd is, but the documentation (and IMHO, features) is much poorer. As far as I can see your arguments are 1) you boot your systems infrequently, so any work in that area isn't valuable 2) socket-based activation is somehow not predictable 3) you're familiar with shell scripting, so a…

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

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 what's needed.

Much much much more straight forward to have some specially formatted comments (?!hahaha, that's the UNIX spirit!) to determine the boot priority and then source some files to read some arbitrary variables and construct the command line that you're interested in running with complete abstraction.

Post reply on HN