5 ms·

Your system now has millions of more lines of code that few people understand which are vulnerable to privilege escalation, unfortunately. :/ I mean, you could

Your system now has millions of more lines of code that few people understand which are vulnerable to privilege escalation, unfortunately. :/ I mean, you could just use Heroku, for free, most likely, to host what you are doing. Should all UNIX become Heroku? What happens if your blog starts doing a billion page views a day? When one of the systemd processes is taking up 95% CPU, what do you do? I'm not saying it's bad, I'm saying these are the type of concerns its' critics have. I am a fan of a lot of the ideas. I have downgraded several Linux systems which I needed To Work(tm) because of systemd being completely half-assed, and there are some great audits of its' code which make it appear to have been written by kindergarten students.

deleted 11y ago
[deleted]
nailer 11y ago
I'd take systemd over sysv init, atd, crond, three or four watcher daemons, syslog, various other semi-maintained tools that replicate each other's functionality, and around 30x 50-line shell scripts.
- vezzy-fnord 11y ago
  There we go with the false dichotomy that just won't die again. It's pretty obvious you're not actually acquainted with the problem domain. Keep using whatever makes you feel comfortable, though.
  - deleted 11y ago
    [deleted]
    - vezzy-fnord 11y ago
      Anyone who brings up sysvinit and the "30x 50-line shell scripts" is clearly one whose perception is limited to the ad-hoc LSB-based sysvinit setups that once permeated GNU/Linux, but which have always been merely one relatively inefficient approach. Even back when Debian first introduced their sysv-rc, we already had IBM SRC, daemontools, simpleinit and NetBSD rc.d which showed different solutions. EDIT: Let me join in on the moaning about downvotes. Not that I understand why.
      - nailer 11y ago
        SysVinit is systemd's predecessor, and thus the logical comparison. Upstart would also be a relevant, if anyone had ever adopted it properly, unfortunately it never got past being a SysVinit wrapper. I've used minimal shell based systems on BSD, Solaris SMF, and launchd, as well as Windows services, and maintain the successor to the now-unmaintained Unix Rosetta Stone. However a minimal shell-script based init is not something anyone on Linux is seriously considering, so I'm not going to debate it with you - that would be a waste of both our time. But please, feel free to tell me about my own experiences. Since you're new here, have you read https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html yet?
  - bkor 11y ago
    Ehr, that's exactly how it used to be. Various sysvinit scripts that all differed across distributions. It's pretty appalling the way you respond though, just dismissing instead of trying to educate. I'm reading along and I have no clue what you're on about. Maybe you mean that there was other stuff out there? I care about what is on a distribution. E.g. RHEL had upstart, but in practice it was lots of large sysvinit scripts.
- simoncion 11y ago
  Serious questions: Have you taken the time to examine how a Linux system that uses a replacement for sysvrc written in the last ten years actually handles startup? Or what services people who aren't running a RedHat distro actually run on their Linux servers? Or have you simply either taken the systemd folks at their word about the "sorry state" of sysvrc replacements, or -perhaps- glanced at a >10 line startup script and recoiled in horror?
  - nailer 11y ago
    1. Yes. 2. Yes. Folks who aren't running 'RedHat' (sic) use systemd, sysvinit, or pretend to use upstart but as a thin wrapper to sysvinit. 3. No, I don't generally listen to Linux advocates as a way of evaluating something.
    - simoncion 11y ago
      > 1. Yes. 2. Yes. ... 3. No... Good. Far too many people in these conversations have poorly-informed opinions. > Folks who aren't running 'RedHat' (sic) use systemd, sysvinit, or ... upstart [sic] ... These are init and RC systems, not services. :) > ...or pretend to use upstart but as a thin wrapper to sysvinit. I dunno. The Upstart project page says: "Upstart is an event-based replacement for the /sbin/init daemon which handles starting of tasks and services during boot, stopping them during shutdown and supervising them while the system is running. It was originally developed for the Ubuntu distribution, but is intended to be suitable for deployment in all Linux distributions as a replacement for the venerable System-V init." If I look at the file list for the upstart package, [1] I see that upstart provides its own /sbin/init, /sbin/halt, and -it seems- just about everything that's provided by the sys-apps/sysvinit package on my Gentoo system. Also, sysvinit and sysvrc aren't the same thing. OpenRC -the default Gentoo RC system- is a sysvrc replacement. [2] It relies on sysvinit (or similar) to get its work done, and is an obvious improvement over sysvrc. If you were aware of the distinction, and have the time, would you be so kind as to mention the top N worst things about sysvinit? If you weren't aware, and have the time, would you care to learn the distinction, and then bounce on back and answer the query? Thanks in advance. :) [0] http://upstart.ubuntu.com/ http://upstart.ubuntu.com/ [1] https://packages.debian.org/jessie/amd64/upstart/filelist https://packages.debian.org/jessie/amd64/upstart/filelist [2] If I'm reading this right, Debian even maintains a sysvrc package: https://packages.debian.org/jessie/sysv-rc https://packages.debian.org/jessie/sysv-rc
- Sanddancer 11y ago
  Let's pull the last one from the list, because not only is it the most important, but it's the one which best demonstrates the attitude the systemd maintainers have towards interoperability, standards, and security. Can systemd's logger send to redis stores for aggregation? Can it email if there's an issue? Can I pull windows events into the same aggregation systems? Is there an RFC for syslog's file and network format? These are all flaws in systemd with just one of those daemons you mentioned. Were I to get into init, I'd ask you about BSD-style rc files, which are tiny and very readable, as well as being shell scripts, so you can run more pre-execution tests to ensure your job will run correctly. With BSD atd and crond, I'd discuss how atd functionality has been merged in as a cron job. There are a lot of other solutions to sysv init than systemd. Unfortunately, the Linux monoculture sees bash as the only shell, sysv init as the only pre-systemd init, and the poorly configured rsyslogd distros ship with as the only syslog.
  - deleted 11y ago
    [deleted]
  - simoncion 11y ago
    > Unfortunately, the Linux monoculture sees bash as the only shell, sysv init as the only pre-systemd init, and the poorly configured rsyslogd distros ship with as the only syslog. People like to make fun of Gentoo, but it does many things right. ;) OpenRC and netifrc are sane and flexible. syslog-ng is the "default" syslog and comes with a reasonable default config file. Use of logrotate is strongly recommended, etc, etc, etc.
  - JdeBP 11y ago
    > ... BSD-style rc files, which are tiny and very readable ... As someone who has an on-going project to replace 157 rc.d scripts from FreeBSD 9/10, I can report that the generalizations about the Mewburn rc.d system that are often made, in order to contrast it with the egregious mess that one can find in the System V rc clone on Linux operating systems, are not in fact strictly accurate. Yes, most of the rc.d scripts are small. Yes, the Mewburn rc.d system did almost 16 years ago what people are erroneously characterizing as novel to systemd: namely taking all of the common management code out of the individual service definitions, leaving just a few parameterizations in some cases. Yes, there is a definite common coding style that is a breath of fresh air when coming from the Linux world. But no, the scripts are not universally tiny. One problematic example currently of interest is /etc/rc.d/bluetooth, weighing in at over 360 lines. Others include the subsystems that are split across multiple scripts, such as /etc/rc.d/atm1, /etc/rc.d/atm2, and /etc/rc.d/atm3. Nor are they universally consistent, /etc/rc.d/serial being an example of one with quite different configuration semantics to the key=value-in-rc.conf{,.local} norm. And whilst one might rail against the problems of having a common script for SuSE Linux, Debian Linux, and RedHat Linux, all of which have different sets of init.d script helper tools (resulting in "portable" init.d scripts ending up being a case "$distribution" in...esac statement for pretty much every step), one can equally point to the fact that OpenBSD's rc.d system (https://news.ycombinator.com/item?id=8506460 https://news.ycombinator.com/item?id=8506460) has entirely different function and parameter names to the NetBSD one (as adopted by FreeBSD/PC-BSD and DragonFly BSD) as well as different rules about rc.conf and different variable naming conventions. Be very careful about attempting to claim some kind of moral high ground on interoperability and standards. (-: Also be very careful about notions that the Linux world sees the Bourne Again shell as the only shell, some rather silly statements by some people who should know better notwithstanding. The adoption of the (Debian-modified) Almquist shell as /bin/sh by Debian and Ubuntu, and its significant effect on bootstrap speed, is quite famous. And my experience is that the Z Shell is quite popular, for starters.

deleted 11y ago

[deleted]

nailer 11y ago

I'd take systemd over sysv init, atd, crond, three or four watcher daemons, syslog, various other semi-maintained tools that replicate each other's functionality, and around 30x 50-line shell scripts.

vezzy-fnord 11y ago
There we go with the false dichotomy that just won't die again. It's pretty obvious you're not actually acquainted with the problem domain. Keep using whatever makes you feel comfortable, though.
- deleted 11y ago
  [deleted]
  - vezzy-fnord 11y ago
    Anyone who brings up sysvinit and the "30x 50-line shell scripts" is clearly one whose perception is limited to the ad-hoc LSB-based sysvinit setups that once permeated GNU/Linux, but which have always been merely one relatively inefficient approach. Even back when Debian first introduced their sysv-rc, we already had IBM SRC, daemontools, simpleinit and NetBSD rc.d which showed different solutions. EDIT: Let me join in on the moaning about downvotes. Not that I understand why.
    - nailer 11y ago
      SysVinit is systemd's predecessor, and thus the logical comparison. Upstart would also be a relevant, if anyone had ever adopted it properly, unfortunately it never got past being a SysVinit wrapper. I've used minimal shell based systems on BSD, Solaris SMF, and launchd, as well as Windows services, and maintain the successor to the now-unmaintained Unix Rosetta Stone. However a minimal shell-script based init is not something anyone on Linux is seriously considering, so I'm not going to debate it with you - that would be a waste of both our time. But please, feel free to tell me about my own experiences. Since you're new here, have you read https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html yet?
- bkor 11y ago
  Ehr, that's exactly how it used to be. Various sysvinit scripts that all differed across distributions. It's pretty appalling the way you respond though, just dismissing instead of trying to educate. I'm reading along and I have no clue what you're on about. Maybe you mean that there was other stuff out there? I care about what is on a distribution. E.g. RHEL had upstart, but in practice it was lots of large sysvinit scripts.
simoncion 11y ago
Serious questions: Have you taken the time to examine how a Linux system that uses a replacement for sysvrc written in the last ten years actually handles startup? Or what services people who aren't running a RedHat distro actually run on their Linux servers? Or have you simply either taken the systemd folks at their word about the "sorry state" of sysvrc replacements, or -perhaps- glanced at a >10 line startup script and recoiled in horror?
- nailer 11y ago
  1. Yes. 2. Yes. Folks who aren't running 'RedHat' (sic) use systemd, sysvinit, or pretend to use upstart but as a thin wrapper to sysvinit. 3. No, I don't generally listen to Linux advocates as a way of evaluating something.
  - simoncion 11y ago
    > 1. Yes. 2. Yes. ... 3. No... Good. Far too many people in these conversations have poorly-informed opinions. > Folks who aren't running 'RedHat' (sic) use systemd, sysvinit, or ... upstart [sic] ... These are init and RC systems, not services. :) > ...or pretend to use upstart but as a thin wrapper to sysvinit. I dunno. The Upstart project page says: "Upstart is an event-based replacement for the /sbin/init daemon which handles starting of tasks and services during boot, stopping them during shutdown and supervising them while the system is running. It was originally developed for the Ubuntu distribution, but is intended to be suitable for deployment in all Linux distributions as a replacement for the venerable System-V init." If I look at the file list for the upstart package, [1] I see that upstart provides its own /sbin/init, /sbin/halt, and -it seems- just about everything that's provided by the sys-apps/sysvinit package on my Gentoo system. Also, sysvinit and sysvrc aren't the same thing. OpenRC -the default Gentoo RC system- is a sysvrc replacement. [2] It relies on sysvinit (or similar) to get its work done, and is an obvious improvement over sysvrc. If you were aware of the distinction, and have the time, would you be so kind as to mention the top N worst things about sysvinit? If you weren't aware, and have the time, would you care to learn the distinction, and then bounce on back and answer the query? Thanks in advance. :) [0] http://upstart.ubuntu.com/ http://upstart.ubuntu.com/ [1] https://packages.debian.org/jessie/amd64/upstart/filelist https://packages.debian.org/jessie/amd64/upstart/filelist [2] If I'm reading this right, Debian even maintains a sysvrc package: https://packages.debian.org/jessie/sysv-rc https://packages.debian.org/jessie/sysv-rc
Sanddancer 11y ago
Let's pull the last one from the list, because not only is it the most important, but it's the one which best demonstrates the attitude the systemd maintainers have towards interoperability, standards, and security. Can systemd's logger send to redis stores for aggregation? Can it email if there's an issue? Can I pull windows events into the same aggregation systems? Is there an RFC for syslog's file and network format? These are all flaws in systemd with just one of those daemons you mentioned. Were I to get into init, I'd ask you about BSD-style rc files, which are tiny and very readable, as well as being shell scripts, so you can run more pre-execution tests to ensure your job will run correctly. With BSD atd and crond, I'd discuss how atd functionality has been merged in as a cron job. There are a lot of other solutions to sysv init than systemd. Unfortunately, the Linux monoculture sees bash as the only shell, sysv init as the only pre-systemd init, and the poorly configured rsyslogd distros ship with as the only syslog.
- deleted 11y ago
  [deleted]
- simoncion 11y ago
  > Unfortunately, the Linux monoculture sees bash as the only shell, sysv init as the only pre-systemd init, and the poorly configured rsyslogd distros ship with as the only syslog. People like to make fun of Gentoo, but it does many things right. ;) OpenRC and netifrc are sane and flexible. syslog-ng is the "default" syslog and comes with a reasonable default config file. Use of logrotate is strongly recommended, etc, etc, etc.
- JdeBP 11y ago
  > ... BSD-style rc files, which are tiny and very readable ... As someone who has an on-going project to replace 157 rc.d scripts from FreeBSD 9/10, I can report that the generalizations about the Mewburn rc.d system that are often made, in order to contrast it with the egregious mess that one can find in the System V rc clone on Linux operating systems, are not in fact strictly accurate. Yes, most of the rc.d scripts are small. Yes, the Mewburn rc.d system did almost 16 years ago what people are erroneously characterizing as novel to systemd: namely taking all of the common management code out of the individual service definitions, leaving just a few parameterizations in some cases. Yes, there is a definite common coding style that is a breath of fresh air when coming from the Linux world. But no, the scripts are not universally tiny. One problematic example currently of interest is /etc/rc.d/bluetooth, weighing in at over 360 lines. Others include the subsystems that are split across multiple scripts, such as /etc/rc.d/atm1, /etc/rc.d/atm2, and /etc/rc.d/atm3. Nor are they universally consistent, /etc/rc.d/serial being an example of one with quite different configuration semantics to the key=value-in-rc.conf{,.local} norm. And whilst one might rail against the problems of having a common script for SuSE Linux, Debian Linux, and RedHat Linux, all of which have different sets of init.d script helper tools (resulting in "portable" init.d scripts ending up being a case "$distribution" in...esac statement for pretty much every step), one can equally point to the fact that OpenBSD's rc.d system (https://news.ycombinator.com/item?id=8506460 https://news.ycombinator.com/item?id=8506460) has entirely different function and parameter names to the NetBSD one (as adopted by FreeBSD/PC-BSD and DragonFly BSD) as well as different rules about rc.conf and different variable naming conventions. Be very careful about attempting to claim some kind of moral high ground on interoperability and standards. (-: Also be very careful about notions that the Linux world sees the Bourne Again shell as the only shell, some rather silly statements by some people who should know better notwithstanding. The adoption of the (Debian-modified) Almquist shell as /bin/sh by Debian and Ubuntu, and its significant effect on bootstrap speed, is quite famous. And my experience is that the Z Shell is quite popular, for starters.