4 ms·

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 su

by 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.
        vertex-four 13y ago
        > The systems that do not use systemd can implement their own cgroup managers. [...] Other managers could also reimplement the systemd dbus API for managing the cgroups. True, except that the systemd developers are in charge of defining this API and have no reason to consult with other cgroups manager developers when defining it. This is, to make an analogy, equivalent to allowing Microsoft to unilaterally define all web standards from now on. The competitors are always going to be playing catch-up, and there's going to be tons of edge cases where the competitors don't quite work the same.
dman 13y ago
Could you elaborate a bit more on your hardware setup? How are your hardware devices getting initialized that quick?

by DASD 13y ago

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.
      - vertex-four 13y ago
        > The systems that do not use systemd can implement their own cgroup managers. [...] Other managers could also reimplement the systemd dbus API for managing the cgroups. True, except that the systemd developers are in charge of defining this API and have no reason to consult with other cgroups manager developers when defining it. This is, to make an analogy, equivalent to allowing Microsoft to unilaterally define all web standards from now on. The competitors are always going to be playing catch-up, and there's going to be tons of edge cases where the competitors don't quite work the same.

dman 13y ago

Could you elaborate a bit more on your hardware setup? How are your hardware devices getting initialized that quick?