6 ms·

It's monolithic because you can't pick and choose the components. You have to use all of systemd, or none of it. You can't replace bits of it, or use just par

by Tobu 13y ago

It's monolithic because you can't pick and choose the components. You have to use all of systemd, or none of it. You can't replace bits of it, or use just parts of it.

FooBarWidget 13y ago
And how exactly does Xorg allow you to use parts of it? More importantly, what parts of systemd do you not want to use or do you want to replace, and why? EDIT: what you're saying appears to be untrue. According to http://0pointer.de/blog/projects/the-biggest-myths.html http://0pointer.de/blog/projects/the-biggest-myths.html, they provide configure switches for enabling or disabling many things, not unlike how the Linux kernel allows you to enable or disable features. You know, there are so many people here bashing on Lennart, I'm wondering whether any of you have done your homework at all or because you just bash Lennart for the sake of it. I'm not even using systemd and I found these things in 5 minutes.
- DASD 13y ago
  I'd like to not use udev. I have a custom Linux that runs both on standardized(internally defined) servers and also virtualized(known hardware) servers. As such, I'm well under 900ms boot times that systemd mentions by using SysV init. But the systemd project does not accept patches (http://freedesktop.org/wiki/Software/systemd/MinimalBuilds/ http://freedesktop.org/wiki/Software/systemd/MinimalBuilds/) to disable what is considered a core component.
  - FooBarWidget 13y ago
    Alright, point taken. Then systemd is not for you. However I want to argue that not all software should cater to everybody. While modularity (which in this discussion is apparently defined as "the ability to disable or swap components") is often seen as a good thing, there are quite a lot of downsides as well: - Certain guarantees and consistencies disappear. Instead of having a system that you know you can rely on, it suddenly becomes entirely dependent on the configuration options. While it sounds nice if any part can be enabled, disabled, moved or swapped, then the system's predictability goes down. Furthermore, some combinations may be incompatible because abstractions are inherently leaky. Good luck finding out whether you're suffering from a compatibility problem or not. You can compare this to the many complaints about Android fragmentation. Because everybody can customize Android, writing an app that works on all Android devices becomes extremely difficult. - Installation complexity goes way up. It's much easier to install a system if it states "I need this, this and this", instead of "I can use this, or this, or this, if it's configured in X, Y and Z way". - Certain features cannot be implemented in a simple manner because you have to cater to the lowest common denominator. XFree86 was like that. Because it had to be portable, it cannot assume any kernel capabilities. And as a result XFree86 came with its own mode setting code, its own ELF binary loader, had to run as root, etc etc.
    - vertex-four 13y ago
      > However I want to argue that not all software should cater to everybody. The issue here is that the Linux kernel developers are starting to make decisions that assume systemd is being used. For example, the (proposed?) new cgroups API is being built with the idea that systemd will manage it, and anything else that wants to interact with it will go through systemd.
      - FooBarWidget 13y ago
        That isn't what I read at all. The cgroups maintainer wants a flat cgroups list so that the code is easier to maintain, but Lennart said he must have hierarchical tree so that systemd can take full control over at least a part of the tree. That's hardly "being built with the idea that systemd will manage it".
        vertex-four 13y ago
        You've read wrong, unfortunately. http://lwn.net/Articles/557082/ http://lwn.net/Articles/557082/ describes that: > Unprivileged access to the cgroup hierarchy will be strongly discouraged; the hope is to have a single, privileged process handling all of the cgroup management tasks. That process will, in turn, provide some sort of higher-level interface to the rest of the system. and that: > This hierarchy becomes private property of systemd. systemd will set it up. Systemd will maintain it. Systemd will rearrange it. Other software that wants to make use of cgroups can do so only through systemd's APIs. That is, systemd will implement a manager on top of the new cgroups API, and all cgroups users will be assumed to go through systemd.
        teho 13y ago
        systemd manages cgroups on systemd based system. The systems that do not use systemd can implement their own cgroup managers. The kernel makes no assumptions on what manager you use on userspace. Other managers could also reimplement the systemd dbus API for managing the cgroups.
  - dman 13y ago
    Could you elaborate a bit more on your hardware setup? How are your hardware devices getting initialized that quick?
- Tobu 13y ago
  I can't disable the journal, for example. If I run something more full-featured, I'll still be streaming things through the journal. It's not at all like the kernel does it. With Linux, there are multiple competing implementations of most features, pushed by people with competing interests. There is a lot more room for debate and experimentation.
  - FooBarWidget 13y ago
    According to 'man journald.conf', you can set "Storage=none". If by "monolithic" you mean the lack of multiple competing implementations, then lots and lots of things are monolithic. Apache and Nginx would be monolithic by your definition.
    - zanny 13y ago
      I love systemd, but from a lot of experience with it over 3 years now, that doesn't disable the journal daemon, it only prevents output piping to its binary logs. You can still poll the journal daemon for events and output it elsewhere (ex, syslog).
      - FooBarWidget 13y ago
        Does journald impose a sufficient performance penalty that you want to remove it entirely?
    - Tobu 13y ago
      (Storage=none is streaming things through the journal, which I have no use for) Apache2 and Nginx are modular. Let me tell you the story of a small web application. Once upon a time, requests were hitting an Apache server, dispatched to mod_python, and an embedded interpreter was keeping itself warm running Python code to answer the requests. As the site grew, and the state of the art evolved, a programmer wrapped the application in a wsgi container, and gave it to a mod_wsgi container so that it would run at its own pace. One day, the programmer brought home an nginx server it had found freezing in the tundra, and gave it a job serving static content in front of Apache. Nginx brought his uwsgi friend and they took turns running the site, nginx serving images and scripts, uwsgi replacing mod_wsgi. This is what a competitive space looks like. Apache has competing modules, there are http servers and wsgi servers, some of them embedded, some of them external, http servers can collaborate or replace each other when a better thing comes along. You don't see an http server deciding it will be the sole http server on the system, swallowing a wsgi server and waging war to all others.
zanny 13y ago
Ubuntu just started using logind in 13.04, but haven't adopted the rest of systemd. Some parts (journal, systemd core, udev) can't be detached, but a lot of the peripheral software outside the init -> maintain services -> log events process are optional.
- Tobu 13y ago
  Ubuntu is splitting logind from systemd with no help from the systemd maintainers, because some gnome projects have started requiring logind. That effort is spent undoing Lennart's work swallowing most of the consolekit code base into systemd. The systemd maintainers won't accept patches that make logind a separate project again.
  - teho 13y ago
    systemd-logind doesn't use code from consolekit. It has been written from scratch. ConsoleKit itself has been unmaintained for a long time.
teho 13y ago
>You can't replace bits of it, or use just parts of it. You can replace pretty much everything. You need only systemd, systemd-udev and systemd-journald. Virtually everything else is optional. It also allows you to use syslog with journald. It allows you use use crond instead of the timer units. You could use ConsoleKit instead of systemd-logind as session manager... and so on and so forth.

by Tobu 13y ago

It's monolithic because you can't pick and choose the components. You have to use all of systemd, or none of it. You can't replace bits of it, or use just parts of it.

FooBarWidget 13y ago

And how exactly does Xorg allow you to use parts of it? More importantly, what parts of systemd do you not want to use or do you want to replace, and why? EDIT: what you're saying appears to be untrue. According to http://0pointer.de/blog/projects/the-biggest-myths.html http://0pointer.de/blog/projects/the-biggest-myths.html, they provide configure switches for enabling or disabling many things, not unlike how the Linux kernel allows you to enable or disable features. You know, there are so many people here bashing on Lennart, I'm wondering whether any of you have done your homework at all or because you just bash Lennart for the sake of it. I'm not even using systemd and I found these things in 5 minutes.

DASD 13y ago
I'd like to not use udev. I have a custom Linux that runs both on standardized(internally defined) servers and also virtualized(known hardware) servers. As such, I'm well under 900ms boot times that systemd mentions by using SysV init. But the systemd project does not accept patches (http://freedesktop.org/wiki/Software/systemd/MinimalBuilds/ http://freedesktop.org/wiki/Software/systemd/MinimalBuilds/) to disable what is considered a core component.
- FooBarWidget 13y ago
  Alright, point taken. Then systemd is not for you. However I want to argue that not all software should cater to everybody. While modularity (which in this discussion is apparently defined as "the ability to disable or swap components") is often seen as a good thing, there are quite a lot of downsides as well: - Certain guarantees and consistencies disappear. Instead of having a system that you know you can rely on, it suddenly becomes entirely dependent on the configuration options. While it sounds nice if any part can be enabled, disabled, moved or swapped, then the system's predictability goes down. Furthermore, some combinations may be incompatible because abstractions are inherently leaky. Good luck finding out whether you're suffering from a compatibility problem or not. You can compare this to the many complaints about Android fragmentation. Because everybody can customize Android, writing an app that works on all Android devices becomes extremely difficult. - Installation complexity goes way up. It's much easier to install a system if it states "I need this, this and this", instead of "I can use this, or this, or this, if it's configured in X, Y and Z way". - Certain features cannot be implemented in a simple manner because you have to cater to the lowest common denominator. XFree86 was like that. Because it had to be portable, it cannot assume any kernel capabilities. And as a result XFree86 came with its own mode setting code, its own ELF binary loader, had to run as root, etc etc.
  - vertex-four 13y ago
    > However I want to argue that not all software should cater to everybody. The issue here is that the Linux kernel developers are starting to make decisions that assume systemd is being used. For example, the (proposed?) new cgroups API is being built with the idea that systemd will manage it, and anything else that wants to interact with it will go through systemd.
    - FooBarWidget 13y ago
      That isn't what I read at all. The cgroups maintainer wants a flat cgroups list so that the code is easier to maintain, but Lennart said he must have hierarchical tree so that systemd can take full control over at least a part of the tree. That's hardly "being built with the idea that systemd will manage it".
      - vertex-four 13y ago
        You've read wrong, unfortunately. http://lwn.net/Articles/557082/ http://lwn.net/Articles/557082/ describes that: > Unprivileged access to the cgroup hierarchy will be strongly discouraged; the hope is to have a single, privileged process handling all of the cgroup management tasks. That process will, in turn, provide some sort of higher-level interface to the rest of the system. and that: > This hierarchy becomes private property of systemd. systemd will set it up. Systemd will maintain it. Systemd will rearrange it. Other software that wants to make use of cgroups can do so only through systemd's APIs. That is, systemd will implement a manager on top of the new cgroups API, and all cgroups users will be assumed to go through systemd.
        teho 13y ago
        systemd manages cgroups on systemd based system. The systems that do not use systemd can implement their own cgroup managers. The kernel makes no assumptions on what manager you use on userspace. Other managers could also reimplement the systemd dbus API for managing the cgroups.
- dman 13y ago
  Could you elaborate a bit more on your hardware setup? How are your hardware devices getting initialized that quick?
Tobu 13y ago
I can't disable the journal, for example. If I run something more full-featured, I'll still be streaming things through the journal. It's not at all like the kernel does it. With Linux, there are multiple competing implementations of most features, pushed by people with competing interests. There is a lot more room for debate and experimentation.
- FooBarWidget 13y ago
  According to 'man journald.conf', you can set "Storage=none". If by "monolithic" you mean the lack of multiple competing implementations, then lots and lots of things are monolithic. Apache and Nginx would be monolithic by your definition.
  - zanny 13y ago
    I love systemd, but from a lot of experience with it over 3 years now, that doesn't disable the journal daemon, it only prevents output piping to its binary logs. You can still poll the journal daemon for events and output it elsewhere (ex, syslog).
    - FooBarWidget 13y ago
      Does journald impose a sufficient performance penalty that you want to remove it entirely?
  - Tobu 13y ago
    (Storage=none is streaming things through the journal, which I have no use for) Apache2 and Nginx are modular. Let me tell you the story of a small web application. Once upon a time, requests were hitting an Apache server, dispatched to mod_python, and an embedded interpreter was keeping itself warm running Python code to answer the requests. As the site grew, and the state of the art evolved, a programmer wrapped the application in a wsgi container, and gave it to a mod_wsgi container so that it would run at its own pace. One day, the programmer brought home an nginx server it had found freezing in the tundra, and gave it a job serving static content in front of Apache. Nginx brought his uwsgi friend and they took turns running the site, nginx serving images and scripts, uwsgi replacing mod_wsgi. This is what a competitive space looks like. Apache has competing modules, there are http servers and wsgi servers, some of them embedded, some of them external, http servers can collaborate or replace each other when a better thing comes along. You don't see an http server deciding it will be the sole http server on the system, swallowing a wsgi server and waging war to all others.

zanny 13y ago

Ubuntu just started using logind in 13.04, but haven't adopted the rest of systemd. Some parts (journal, systemd core, udev) can't be detached, but a lot of the peripheral software outside the init -> maintain services -> log events process are optional.

Tobu 13y ago
Ubuntu is splitting logind from systemd with no help from the systemd maintainers, because some gnome projects have started requiring logind. That effort is spent undoing Lennart's work swallowing most of the consolekit code base into systemd. The systemd maintainers won't accept patches that make logind a separate project again.
- teho 13y ago
  systemd-logind doesn't use code from consolekit. It has been written from scratch. ConsoleKit itself has been unmaintained for a long time.

teho 13y ago

>You can't replace bits of it, or use just parts of it. You can replace pretty much everything. You need only systemd, systemd-udev and systemd-journald. Virtually everything else is optional. It also allows you to use syslog with journald. It allows you use use crond instead of the timer units. You could use ConsoleKit instead of systemd-logind as session manager... and so on and so forth.