4 ms·

Can't expect the time when you won't need libc or a shell, for that matter. Let's delete "bash" and replace it with a built-in do-it-all shell, let's call that

by ddalex 12y ago

Can't expect the time when you won't need libc or a shell, for that matter. Let's delete "bash" and replace it with a built-in do-it-all shell, let's call that "cmd", right ? Configuration should be done in binary-encoded files, with arborescent key-value pairs - I know, let's call that a registry, shall we ? Package management should be done through a central place where application can be vetoed, like an app store, if you will. We could do away with silly editors like VI, we'll embed a powerful office suite right into the system libraries, shall we ? Monolitic software is always better than small separate tools that do only one thing, right ?

srslack 12y ago
>Package management should be done through a central place where application can be vetoed, like an app store. There's no need, https://en.wikipedia.org/wiki/PackageKit https://en.wikipedia.org/wiki/PackageKit exists >Monolithic* software is always better than small separate tools that do only one thing, right? Even in the linked post, it's referencing seperate daemons that "do one thing."
evol262 12y ago
Except systemd isn't monolithic at all. It's 70 bits under one umbrella project, and you only need three of them to replace init. But because it can do something doesn't mean it does that thing out of the box or even in the default configuration. Even on Fedora (or CoreOS), where systemd has the most uptake. Why is it that every systemd critic doesn't know what systemd is or does?
- vezzy-fnord 12y ago
  Monolithic and modular aren't mutually exclusive.
  - evol262 12y ago
    Conflating the aims of everything underneath the systemd umbrella is misleading regardless of whether you think monolithic and modular aren't mutually exclusive (and hey! systemd isn't monolithic or modular -- the additional bits run separately, they don't plug into systemd), akin to lumping everything in coreutils under the same "coreutils is trying to take over Linux!" argument.
    - viraptor 12y ago
      > the additional bits run separately, they don't plug into systemd What's the reason behind ubuntu running its own stub for logind instead of systemd-login? And how would you run systemd-journal without systemd? As far as I'm aware this is not possible and the internet doesn't seem to know anything about running them standalone.
- ddalex 12y ago
  So, please tell me how can I use logind without bringing systemd as a PID 1 process. Or how do I stdin/stdout interface (the basic interface in UNIX, where everything is a file) to the new awesome DNS resolver without having to bring up D-Bus ? Systemd is like a bait-and-switch virus. If you want any piece of it, you have to take it all. It spreads and infects/replaces any other competing piece of software. All seventy bits have tight hierarchical coupling, and while you can run the top of heap independently, you can't run the utilities without bringing in the whole mess. Systemd is valued by those who don't understand the quality of having independent programs that talk via standardized human-readable interfaces.
akerl_ 12y ago
Life must be terrible on that slippery slope you're building your house on. It's been debunked time and time again that systemd is "monolithic", and nobody is forcing you to use any daemons they provide that you don't like. I run syslog-ng and cronie and ntpd and it works just fine. And the jabs about a walled garden app store are totally out of left field. There's plenty of room to have a rational debate about whether the direction systemd is moving is the best, whether it ought to be managed differently, and how to best provide init and process management services to systems. Lets have those debates, they're far more useful.
- vezzy-fnord 12y ago
  Well, "monolithic" isn't very clearly defined, either way. There's multiple interpretations, but systemd does fall under tight coupling. Its modularity is somewhat arbitrary. A lot of auxiliary daemons can be configured out of the build, but some others like generators and most damningly journald, cannot. Yes, you can run regular syslogd and crond implementations beside systemd's journald and timer units. To be honest, it would be pretty ridiculous if you couldn't, and it's not much of a consolation. Although journald can be effectively disabled by forwarding to syslog (however, PID1 itself no longer supports syslog as a target), the systemd developers do want it to be the primary syslog mechanism on a Linux system, and are pushing it as such. Yet due to choosing to use a binary format similar to a RDBMS, but without the transaction consistency of an actual RDBMS, it's prone to unnecessary corruption. This was deemed not to be an issue, apparently: https://bugs.freedesktop.org/show_bug.cgi?id=64116 https://bugs.freedesktop.org/show_bug.cgi?id=64116 Then you have an (optionally network-enabled) system logging service that stays resident without being used, a potential attack vector and really just a huge, completely unnecessary sink to proxy your actual syslogd of choice to.
  - evol262 12y ago
    You're damning journald for things syslogd doesn't do either. Syslog is not reliable. Syslog is incredibly falsifiable (journald is not). Syslog does not handle system crashes well either (pretty much the case where journald gets corrupted). Syslog also doesn't capture application logs. Syslog does not hand over from dracut. Syslog guarantees nothing. Don't present it as a step backwards when it's a step forwards, albeit with some warts. Even in its worst case, journald still provides more functionality and more security than syslog, and you can still use your normal syslogger
rektide 12y ago
Go back to GNU/Hurd please, with your "monolithic kernels are always worse than small separate interoperating pieces" noise. :p
blahbl4hblah 12y ago
Its open source. In the end, you can make it do whatever you get off your lazy ass and make it do. Or you can quit bitching at the people who make the software you use.

by ddalex 12y ago

srslack 12y ago

>Package management should be done through a central place where application can be vetoed, like an app store. There's no need, https://en.wikipedia.org/wiki/PackageKit https://en.wikipedia.org/wiki/PackageKit exists >Monolithic* software is always better than small separate tools that do only one thing, right? Even in the linked post, it's referencing seperate daemons that "do one thing."

evol262 12y ago

Except systemd isn't monolithic at all. It's 70 bits under one umbrella project, and you only need three of them to replace init. But because it can do something doesn't mean it does that thing out of the box or even in the default configuration. Even on Fedora (or CoreOS), where systemd has the most uptake. Why is it that every systemd critic doesn't know what systemd is or does?

vezzy-fnord 12y ago
Monolithic and modular aren't mutually exclusive.
- evol262 12y ago
  Conflating the aims of everything underneath the systemd umbrella is misleading regardless of whether you think monolithic and modular aren't mutually exclusive (and hey! systemd isn't monolithic or modular -- the additional bits run separately, they don't plug into systemd), akin to lumping everything in coreutils under the same "coreutils is trying to take over Linux!" argument.
  - viraptor 12y ago
    > the additional bits run separately, they don't plug into systemd What's the reason behind ubuntu running its own stub for logind instead of systemd-login? And how would you run systemd-journal without systemd? As far as I'm aware this is not possible and the internet doesn't seem to know anything about running them standalone.
ddalex 12y ago
So, please tell me how can I use logind without bringing systemd as a PID 1 process. Or how do I stdin/stdout interface (the basic interface in UNIX, where everything is a file) to the new awesome DNS resolver without having to bring up D-Bus ? Systemd is like a bait-and-switch virus. If you want any piece of it, you have to take it all. It spreads and infects/replaces any other competing piece of software. All seventy bits have tight hierarchical coupling, and while you can run the top of heap independently, you can't run the utilities without bringing in the whole mess. Systemd is valued by those who don't understand the quality of having independent programs that talk via standardized human-readable interfaces.

akerl_ 12y ago

Life must be terrible on that slippery slope you're building your house on. It's been debunked time and time again that systemd is "monolithic", and nobody is forcing you to use any daemons they provide that you don't like. I run syslog-ng and cronie and ntpd and it works just fine. And the jabs about a walled garden app store are totally out of left field. There's plenty of room to have a rational debate about whether the direction systemd is moving is the best, whether it ought to be managed differently, and how to best provide init and process management services to systems. Lets have those debates, they're far more useful.

vezzy-fnord 12y ago
Well, "monolithic" isn't very clearly defined, either way. There's multiple interpretations, but systemd does fall under tight coupling. Its modularity is somewhat arbitrary. A lot of auxiliary daemons can be configured out of the build, but some others like generators and most damningly journald, cannot. Yes, you can run regular syslogd and crond implementations beside systemd's journald and timer units. To be honest, it would be pretty ridiculous if you couldn't, and it's not much of a consolation. Although journald can be effectively disabled by forwarding to syslog (however, PID1 itself no longer supports syslog as a target), the systemd developers do want it to be the primary syslog mechanism on a Linux system, and are pushing it as such. Yet due to choosing to use a binary format similar to a RDBMS, but without the transaction consistency of an actual RDBMS, it's prone to unnecessary corruption. This was deemed not to be an issue, apparently: https://bugs.freedesktop.org/show_bug.cgi?id=64116 https://bugs.freedesktop.org/show_bug.cgi?id=64116 Then you have an (optionally network-enabled) system logging service that stays resident without being used, a potential attack vector and really just a huge, completely unnecessary sink to proxy your actual syslogd of choice to.
- evol262 12y ago
  You're damning journald for things syslogd doesn't do either. Syslog is not reliable. Syslog is incredibly falsifiable (journald is not). Syslog does not handle system crashes well either (pretty much the case where journald gets corrupted). Syslog also doesn't capture application logs. Syslog does not hand over from dracut. Syslog guarantees nothing. Don't present it as a step backwards when it's a step forwards, albeit with some warts. Even in its worst case, journald still provides more functionality and more security than syslog, and you can still use your normal syslogger

rektide 12y ago

Go back to GNU/Hurd please, with your "monolithic kernels are always worse than small separate interoperating pieces" noise. :p

blahbl4hblah 12y ago

Its open source. In the end, you can make it do whatever you get off your lazy ass and make it do. Or you can quit bitching at the people who make the software you use.