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

101–110 of 129 posts

Re: Arch Linux to migrate to Systemd

#101

Post by planckscnst »

sparkie wrote: post #93
ElliotH wrote: post #92

Earlier quoted context omitted.

This takes away no choice, I'm sure if you want to use old style init that'll be available too, you'll just sacrifice easier config, faster boot, better diagnostics, logging and profiling of boot.

The old init will still be available, but the point is that anything built to run on systemd only, will not be easy to use with older systems without effort to backport them. This isn't much of a problem if you do choose to use systemd though, because it's backward compatible with older scripts.

It would be awfully hard to make a service that didn't work without systemd. Your software shouldn't depend on systemd, just as it shouldn't depend on init.d, rc.d, or anything else unless it's a tool specifically for working with that (like chkconfig or update-rc.d).

Re: Arch Linux to migrate to Systemd

#102

Post by sprash »

planckscnst wrote: post #88
sprash wrote: post #86

Earlier quoted context omitted.

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…

Technically, init is also a program that launches other programs with its own special config file; it's just so much more limited than systemd that it has to hand startup over to scripts. You don't need a special program to read logs; you can use whatever syslog daemon you want; you just don't have to. I really enjoy journal's ability to filter the logs precicely by all sorts of fields. Actually, it's just the opposi…

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 of doors for potential new Errors. I agree sysvinit sucks but worse is better in this case. Ideally an init system would be a lean and smart turing complete scripting language and every feature is implemented on top of it.

Re: Arch Linux to migrate to Systemd

#103

Post by sp332 »

nodata wrote: post #83
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'm also not much surprised that Red Hat, who've had such a historic problem with consistency and reliable dependency management within their packaging system (as compared to Debian/Ubuntu) Yawn this again. Give an example please.

I think "historic" is important here. RPMs were still hard to use (mainly dependency hell) for a while after .debs were easy. This hasn't been true for years though.

Re: Arch Linux to migrate to Systemd

#104

Post by gillianseed »

pjmlp wrote: post #90
bkor wrote: post #81

Earlier quoted context omitted.

I fail to see the problem. Either something is portable, or something is not. It is basically up to the developer. If not being portable means way less time spent on development, then some people might choose that. Good for them.

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?

Re: Arch Linux to migrate to Systemd

#105

Post by nodata »

sp332 wrote: post #103
nodata wrote: post #83

Earlier quoted context omitted.

> I'm also not much surprised that Red Hat, who've had such a historic problem with consistency and reliable dependency management within their packaging system (as compared to Debian/Ubuntu) Yawn this again. Give an example please.

I think "historic" is important here. RPMs were still hard to use (mainly dependency hell) for a while after .debs were easy. This hasn't been true for years though.

I don't think it's relevant at all.

Re: Arch Linux to migrate to Systemd

#106

Post by papsosouid »

comex wrote: post #51
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…

As an OS X, and thus launchd user... I think you guys are crazy! :) For launchd, the service description is a few declarative entries: on OS X, ssh.plist is 37 lines, but only because XML plists are really verbose; it could be half that in a saner format. On my Debian system, /etc/init.d/ssh is 167 lines of almost entirely boilerplate shell script that has to be maintained separately for each service (and that isn't…

>On my Debian system, /etc/init.d/ssh is 167 lines of almost entirely boilerplate shell script that has to be maintained separately for each service

That's a failure on debian's part, not a fundamental flaw of init. Guess what the equivalent looks like on openbsd?

    daemon="/usr/sbin/sshd" 
                        
    . /etc/rc.d/rc.subr     
                        
    rc_cmd $1

Re: Arch Linux to migrate to Systemd

#107

Post by jeltz »

ominous_prime wrote: post #33

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…

I agree, systemd seems to be awesome for embedded computers and servers while just a minor improvement for the desktop. I could care less about simplifying process management for my desktop. I do not manage the processes on my desktop, and do not write my own init scripts there either.

I believe though that systemd is actually targeted at the desktop. :)

Re: Arch Linux to migrate to Systemd

#108

Post by bdunbar »

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…

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 started to replace init scripts. It felt wrong.

I adapted. It's not wrong, it's just different. Better in some respects: you can still use bash scripts, but you have better control over them, a standardized way of managing things.

Now we're abandoning Solaris for Linux and ... I'm appalled that 'linux' default method is still .. init scripts. And a hodge-podge of stuff like djb, systemd, etc, all with competing fan boys and advocates.

Re: Arch Linux to migrate to Systemd

#109

Post by planckscnst »

sprash wrote: post #102
planckscnst wrote: post #88

Earlier quoted context omitted.

Technically, init is also a program that launches other programs with its own special config file; it's just so much more limited than systemd that it has to hand startup over to scripts. You don't need a special program to read logs; you can use whatever syslog daemon you want; you just don't have to. I really enjoy journal's ability to filter the logs precicely by all sorts of fields. Actually, it's just the opposi…

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

#110

Post by dredmorbius »

reinhardt wrote: post #68
dredmorbius wrote: post #62

Earlier quoted context omitted.

On every server I've seen, firmware initialization, generally networking and storage controllers, takes far more time than the OS boot sequence. To the tune of 4-5 minutes for hardware vs. ~1-2 minutes (or less) from kernel boot to console login. At which point actual workload stack initialization (webserver, application server, database, caches) generally takes additional time. Depending on where you're starting for…

Did you actually read the comment you replied to or you keep copying and pasting blindly your strawman argument in this thread? If you did read it, which part of "The process management is the big win, and boot time is just a bonus" was unclear?

1: boot time is Poettering's own argument in favor: http://0pointer.de/blog/projects/systemd.html

If the systemd team wants to drag goalposts all across the field, that's fine. I'm just going to note their original location.

If you want to build a better xinetd, or better SysV init based dependency system (insserv), or alternative (upstart), then do it. OK, upstart also fucks with init, but with a lot less whack then systemd.

As to the "I've seen poorly written init scripts": on my distro of choice (Debian), package maintainers do a very good job of providing sane scripts (which are a lot easier to follow than RH scripts, something I noticed when first cutting over to Debian), in part because the distro provides a solid, 18-years of evolution, SysV init based process, and a policy that tends to iron out occasional bouts of dumpth.

Post reply on HN