10 ms·

Arch Linux to migrate to Systemd

120 points by g-garron 14y ago

tungstentim 14y ago
The link is to a proposal, rather than an announcement, but the replies seem very positive, which bodes well.
- vhf 14y ago
  A proposal followed by a discussion without any opposition to the proposal, and then a decision. Announcement will surely be made shortly :)
  - gbraad 14y ago
    Which resulted in a discussion on a different thread? http://mailman.archlinux.org/pipermail/arch-dev-public/2012-August/023386.html http://mailman.archlinux.org/pipermail/arch-dev-public/2012-...
Ralith 14y ago
I've been running systemd on my computers for a few months now, and it's great. Dramatically accelerates my boot times, easy to configure, and easy to use. The only problem I've ever had is when a daemon doesn't include a systemd unit file, and I imagine official migration will include resolving all the remaining cases of that.
- JoshTriplett 14y ago
  systemd supports standard init scripts as well, allowing an incremental migration.
- adestefan 14y ago
  In most cases the needed file is so simple that it's an easy patch to send to the author or package maintainer.
throwaway54-762 14y ago
Here's the (much more readable) mailing list in gmane: http://news.gmane.org/gmane.linux.arch.devel http://news.gmane.org/gmane.linux.arch.devel Currently (Friday 3:48 Pacific time), this thread is at the top. Edit: Lots of +1s in the early thread messages; some elaboration surrounding migration issues in later emails.
cies 14y ago
see here the discussion `systemd vs upstart` (the default on ubuntu): http://unix.stackexchange.com/questions/5877/what-are-the-pros-cons-of-upstart-and-systemd http://unix.stackexchange.com/questions/5877/what-are-the-pr... and here the design docs of systemd: http://0pointer.de/blog/projects/systemd.html http://0pointer.de/blog/projects/systemd.html overall i think systemd is a much better implementation toward the same goal. some distros have already switched from upstart to it, not saying that upstart is not an extremely popular choice as well.
bct 14y ago
It's too bad that opposition to changes like this is often expressed so trollishly. There's a real tradeoff here (of simplicity and of portability) that gets glossed over.
- adestefan 14y ago
  The trade off isn't simplicity it's familiarity. The shell based init system is a stuningly complex series of shell scripts that keep implementing the same basic functionality over and over.
- ajross 14y ago
  It's certainly true that the "minimal summary" of the features of systemd vs. sysvinit (or Busybox, or a BSD init script, which is even simpler) is hugely skewed against systemd. Understanding how systemd's process tracking works requires understanding cgroups, for example. Things that used to be one liners in a script ("mount hugetlbfs -t hugetlbfs /dev/hugepages") suddenly become first class "mount" objects with status. Systemd introduces a bunch of new jargon and new tools. But at the same time systemd really does do much more than a classic "launch some stuff and call wait()" style init. And that stuff is pretty nice -- in a systemd world, no one needs to worry about writing a "daemon" any more. Any program that sits in a loop writing to standard output can be started, stopped and syslog'd. And making this work isn't bad at all. You configure systemd with straightforward .ini file syntax and clear fields (e.g. "ExecStart=/path/to/my/program"). Basically it's complicated in structure (and the task of porting a whole distro to it strikes me as pretty scary) but simple in interface, and that's pretty much the right place to be. Most "systemd is too hard!" rants don't survive long past the initial implementation phase.
  - bct 14y ago
    > Basically it's complicated in structure [...] but simple in interface, and that's pretty much the right place to be. Thanks for posting this, this is a great analysis. It gets right to the heart of many of the disagreements I have with system design orthodoxy. I think it's exactly the wrong place to be.
dredmorbius 14y ago
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 (or, very rarely, to perform a kernel upgrade). On server hardware, I perform boots infrequently, and really, really, really want them to work right. On end-user hardware, I perform boots infrequently, preferring to use suspend/restore to quiesce my systems (suspend to RAM, occasionally suspend to disk). That is a process which I'd like to have very thoroughly debugged and not give me any unhappy surprises (say: crash my video, e.g.: interactive session, lose track of drivers/hardware, especially wireless). Systemd is the wrong answer to the wrong problem. Much written better than I can: http://blog.mywarwithentropy.com/2010/10/upstart-better-init-or-more-painful-one.html http://blog.mywarwithentropy.com/2010/10/upstart-better-init... 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: https://lwn.net/Articles/494711/ https://lwn.net/Articles/494711/ 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) are proponents of this technology (hint: it's not the package format, it's the policy, or lack thereof). And now Arch.
- adestefan 14y ago
  > 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 the system working. Conversely, someone that can't debug when a system can't start that uses systemd has no business administering a server where systemd is an integral part of the system working. If your system uses systemd, then you're going to need to learn a new tool. Get used to it.
sciurus 14y ago
Allen McRae had an interesting, relvant post recently- "Are We Removing What Defines Arch Linux?" http://allanmcrae.com/2012/08/are-we-removing-what-defines-arch-linux/ http://allanmcrae.com/2012/08/are-we-removing-what-defines-a...
jacques_chester 14y ago
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-reigning-in-chaos/ 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.
- _sh 14y ago
  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 The good ol' fashioned make tool does exactly this and, in the spirit of Unix, pretty much nothing else. The problem is in determining whether the dependencies of a node in the graph are satisfied. Make does this by comparing file times. All the other 'graph resolving systems' you mentioned do something different. Obviously the solution is to abstract the dependency test from the graph itself. Then all these systems become pretty much the same.
  - deleted 14y ago
    [deleted]
  - jacques_chester 14y ago
    > The good ol' fashioned make tool does exactly this and, in the spirit of Unix, pretty much nothing else. Make still requires a manual step. I'm thinking of systems that do this themselves. Active control systems, constantly comparing the state of the world to the reference graph. I don't want the unix tradition. The unix tradition is a pain in the rear end to actually administer. I want a single management framework with a single DSL that does it all.
ominous_prime 14y ago
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.
- dredmorbius 14y ago
  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 form, a few seconds to many minutes or hours (DB init/restore/replication from snapshots/backups/master). Again: the few seconds you're going to save swapping out really stable infrastructure 1) isn't the problem and 2) introduces change and complexity (and hence uncertainty and unreliability) to a very critical system component.
  - reinhardt 14y ago
    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?
    - dredmorbius 14y ago
planckscnst 14y ago
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.
- sprash 14y ago
  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 of computing.
  - planckscnst 14y ago
    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 opposite of "relacement of files with APIs". A program's command-line is an API that you call using a program; that program is being replaced by a file. I don't think you've actually used systemd if you claim that it "sucks the fun out of computing". I find the the "systemd-analyze" and "systemctl dot" tools to be a lot of fun.
stinnyfregs 14y ago
it only works on linux. fuck you.
ijobs-ly 14y ago
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 "public domain" are close to nil. He's got better things to do. BSD's rc system is fine. Sometimes the scripts are too verbose. But the whole idea is the system is simple enough to understand that you can write your own scripts -- more concisely, if you wish. You don't need to read a book (e.g. Linux from Scratch), keep most things disabled by default and let the user turn stuff on as they need it. I recently used Debian's live USB, the rescue version, for a little while and was amazed at how much stuff is turned on by default. I guess if you understand each and every choice that's been made for you it's OK. But if not, that approach is not very conducive to learning. As for Apple, never mind all the XML fluff, good luck trying to understand what's going on behind the scenes with their computers anymore. They can't even manage to let you have an nsswitch.conf or equivalent.
- ciupicri 14y ago
  > And the chances of the author initiating lawsuits (as some Linux foundations are known to do), over something placed in the "public domain" are close to nil. Could you give some examples of those lawsuits?
- dredmorbius 14y ago
  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?).
CrLf 14y ago
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 much for the desktop, but I do care for servers. Boot times on servers are irrelevant. Reducing them brings little benefit. Servers shouldn't have to be rebooted that often for it to matter, and also, servers spend most of their boot time POSTing and initializing firmware for the various cards. In many cases, twice as much as it takes to boot a normal SysV init Linux install. Not only that, but it is much more important to be able to effectively troubleshoot boot problems than to get some dubious features that nobody really felt missing for all these decades. I don't care if Fedora or Arch do this, but I do care if more server-oriented distributions do. I still haven't gotten over the fact that RHEL6 now gives you the option of using NetworkManager (bleh) or configuring interfaces through (badly designed) configuration files. What's wrong with the old system-config-network?
- alexchamberlain 14y ago
  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!
  - Ralith 14y ago
    It's this kind of complaint that suggests all the unease is a result from resistance to learning new systems, rather than any actual flaw in those systems. NetworkManager operates headlessly, and can be manipulated just fine with nmcli.
ari_elle 14y ago
they should just migrate to openrc, i heard debian might actually do that. would be there 2nd nice choice this month after switching to xfce as default de

120 points by g-garron 14y ago

tungstentim 14y ago

The link is to a proposal, rather than an announcement, but the replies seem very positive, which bodes well.

vhf 14y ago
A proposal followed by a discussion without any opposition to the proposal, and then a decision. Announcement will surely be made shortly :)
- gbraad 14y ago
  Which resulted in a discussion on a different thread? http://mailman.archlinux.org/pipermail/arch-dev-public/2012-August/023386.html http://mailman.archlinux.org/pipermail/arch-dev-public/2012-...

Ralith 14y ago

I've been running systemd on my computers for a few months now, and it's great. Dramatically accelerates my boot times, easy to configure, and easy to use. The only problem I've ever had is when a daemon doesn't include a systemd unit file, and I imagine official migration will include resolving all the remaining cases of that.

JoshTriplett 14y ago
systemd supports standard init scripts as well, allowing an incremental migration.
adestefan 14y ago
In most cases the needed file is so simple that it's an easy patch to send to the author or package maintainer.

throwaway54-762 14y ago

Here's the (much more readable) mailing list in gmane: http://news.gmane.org/gmane.linux.arch.devel http://news.gmane.org/gmane.linux.arch.devel Currently (Friday 3:48 Pacific time), this thread is at the top. Edit: Lots of +1s in the early thread messages; some elaboration surrounding migration issues in later emails.

cies 14y ago

see here the discussion `systemd vs upstart` (the default on ubuntu): http://unix.stackexchange.com/questions/5877/what-are-the-pros-cons-of-upstart-and-systemd http://unix.stackexchange.com/questions/5877/what-are-the-pr... and here the design docs of systemd: http://0pointer.de/blog/projects/systemd.html http://0pointer.de/blog/projects/systemd.html overall i think systemd is a much better implementation toward the same goal. some distros have already switched from upstart to it, not saying that upstart is not an extremely popular choice as well.

bct 14y ago

It's too bad that opposition to changes like this is often expressed so trollishly. There's a real tradeoff here (of simplicity and of portability) that gets glossed over.

adestefan 14y ago
The trade off isn't simplicity it's familiarity. The shell based init system is a stuningly complex series of shell scripts that keep implementing the same basic functionality over and over.
ajross 14y ago
It's certainly true that the "minimal summary" of the features of systemd vs. sysvinit (or Busybox, or a BSD init script, which is even simpler) is hugely skewed against systemd. Understanding how systemd's process tracking works requires understanding cgroups, for example. Things that used to be one liners in a script ("mount hugetlbfs -t hugetlbfs /dev/hugepages") suddenly become first class "mount" objects with status. Systemd introduces a bunch of new jargon and new tools. But at the same time systemd really does do much more than a classic "launch some stuff and call wait()" style init. And that stuff is pretty nice -- in a systemd world, no one needs to worry about writing a "daemon" any more. Any program that sits in a loop writing to standard output can be started, stopped and syslog'd. And making this work isn't bad at all. You configure systemd with straightforward .ini file syntax and clear fields (e.g. "ExecStart=/path/to/my/program"). Basically it's complicated in structure (and the task of porting a whole distro to it strikes me as pretty scary) but simple in interface, and that's pretty much the right place to be. Most "systemd is too hard!" rants don't survive long past the initial implementation phase.
- bct 14y ago
  > Basically it's complicated in structure [...] but simple in interface, and that's pretty much the right place to be. Thanks for posting this, this is a great analysis. It gets right to the heart of many of the disagreements I have with system design orthodoxy. I think it's exactly the wrong place to be.

dredmorbius 14y ago

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 (or, very rarely, to perform a kernel upgrade). On server hardware, I perform boots infrequently, and really, really, really want them to work right. On end-user hardware, I perform boots infrequently, preferring to use suspend/restore to quiesce my systems (suspend to RAM, occasionally suspend to disk). That is a process which I'd like to have very thoroughly debugged and not give me any unhappy surprises (say: crash my video, e.g.: interactive session, lose track of drivers/hardware, especially wireless). Systemd is the wrong answer to the wrong problem. Much written better than I can: http://blog.mywarwithentropy.com/2010/10/upstart-better-init-or-more-painful-one.html http://blog.mywarwithentropy.com/2010/10/upstart-better-init... 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: https://lwn.net/Articles/494711/ https://lwn.net/Articles/494711/ 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) are proponents of this technology (hint: it's not the package format, it's the policy, or lack thereof). And now Arch.

adestefan 14y ago
> 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 the system working. Conversely, someone that can't debug when a system can't start that uses systemd has no business administering a server where systemd is an integral part of the system working. If your system uses systemd, then you're going to need to learn a new tool. Get used to it.

sciurus 14y ago

Allen McRae had an interesting, relvant post recently- "Are We Removing What Defines Arch Linux?" http://allanmcrae.com/2012/08/are-we-removing-what-defines-arch-linux/ http://allanmcrae.com/2012/08/are-we-removing-what-defines-a...

jacques_chester 14y ago

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-reigning-in-chaos/ 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.

_sh 14y ago
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 The good ol' fashioned make tool does exactly this and, in the spirit of Unix, pretty much nothing else. The problem is in determining whether the dependencies of a node in the graph are satisfied. Make does this by comparing file times. All the other 'graph resolving systems' you mentioned do something different. Obviously the solution is to abstract the dependency test from the graph itself. Then all these systems become pretty much the same.
- deleted 14y ago
  [deleted]
- jacques_chester 14y ago
  > The good ol' fashioned make tool does exactly this and, in the spirit of Unix, pretty much nothing else. Make still requires a manual step. I'm thinking of systems that do this themselves. Active control systems, constantly comparing the state of the world to the reference graph. I don't want the unix tradition. The unix tradition is a pain in the rear end to actually administer. I want a single management framework with a single DSL that does it all.

ominous_prime 14y ago

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.

dredmorbius 14y ago
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 form, a few seconds to many minutes or hours (DB init/restore/replication from snapshots/backups/master). Again: the few seconds you're going to save swapping out really stable infrastructure 1) isn't the problem and 2) introduces change and complexity (and hence uncertainty and unreliability) to a very critical system component.
- reinhardt 14y ago
  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?
  - dredmorbius 14y ago

planckscnst 14y ago

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.

sprash 14y ago
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 of computing.
- planckscnst 14y ago
  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 opposite of "relacement of files with APIs". A program's command-line is an API that you call using a program; that program is being replaced by a file. I don't think you've actually used systemd if you claim that it "sucks the fun out of computing". I find the the "systemd-analyze" and "systemctl dot" tools to be a lot of fun.

stinnyfregs 14y ago

it only works on linux. fuck you.

ijobs-ly 14y ago

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 "public domain" are close to nil. He's got better things to do. BSD's rc system is fine. Sometimes the scripts are too verbose. But the whole idea is the system is simple enough to understand that you can write your own scripts -- more concisely, if you wish. You don't need to read a book (e.g. Linux from Scratch), keep most things disabled by default and let the user turn stuff on as they need it. I recently used Debian's live USB, the rescue version, for a little while and was amazed at how much stuff is turned on by default. I guess if you understand each and every choice that's been made for you it's OK. But if not, that approach is not very conducive to learning. As for Apple, never mind all the XML fluff, good luck trying to understand what's going on behind the scenes with their computers anymore. They can't even manage to let you have an nsswitch.conf or equivalent.

ciupicri 14y ago
> And the chances of the author initiating lawsuits (as some Linux foundations are known to do), over something placed in the "public domain" are close to nil. Could you give some examples of those lawsuits?
dredmorbius 14y ago
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?).

CrLf 14y ago

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 much for the desktop, but I do care for servers. Boot times on servers are irrelevant. Reducing them brings little benefit. Servers shouldn't have to be rebooted that often for it to matter, and also, servers spend most of their boot time POSTing and initializing firmware for the various cards. In many cases, twice as much as it takes to boot a normal SysV init Linux install. Not only that, but it is much more important to be able to effectively troubleshoot boot problems than to get some dubious features that nobody really felt missing for all these decades. I don't care if Fedora or Arch do this, but I do care if more server-oriented distributions do. I still haven't gotten over the fact that RHEL6 now gives you the option of using NetworkManager (bleh) or configuring interfaces through (badly designed) configuration files. What's wrong with the old system-config-network?

alexchamberlain 14y ago
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!
- Ralith 14y ago
  It's this kind of complaint that suggests all the unease is a result from resistance to learning new systems, rather than any actual flaw in those systems. NetworkManager operates headlessly, and can be manipulated just fine with nmcli.

ari_elle 14y ago

they should just migrate to openrc, i heard debian might actually do that. would be there 2nd nice choice this month after switching to xfce as default de