3 ms·

In general, this is not about the merits of systemd as a program. GNU/Linux represents choice and freedom. The abundance of distros is proof of that. You can

by e7620 12y ago

In general, this is not about the merits of systemd as a program. GNU/Linux represents choice and freedom. The abundance of distros is proof of that. You can choose your preferred init system, system logger, cron daemon, desktop environment, browser, etc. Now, systemd is being forcefully pushed to all distros. For instance, by merging udev (a part of the Linux kernel) with systemd. We can't even build a distro anymore without downloading systemd. User choice is under threat. In this situation, some people align with the forceful approach of systemd. Some prefer to choose what goes into their computers. This is similar to the inclusion of DRM in Firefox, there's no middle ground. So the debate is really about competitition vs a walled garden provided by systemd.

icebraining 12y ago
udev (a part of the Linux kernel) I thought one of the advantages of udev (vs devfs) was that it was completely in userspace?
- e7620 12y ago
  You're correct, but that's not the point. Some device drivers run in userspace, even the Linux kernel itself can run in userspace!
  - icebraining 12y ago
    How is it not the point? You said "we can't even build a distro anymore without downloading systemd," due to the implication that udev was embedded in the kernel, but that's not true. You can build a distro - just don't use udev.
    - e7620 12y ago
      udev is a necessary component of Linux. You could say just use a fork like eudev. Fine (for the time being). But the thing is, you can't remove udev from the Linux kernel if you want to keep it calling Linux, as it'd be a fork.
      - icebraining 12y ago
        udev is a necessary component of Linux. Why do you say that? That's what I don't understand. As far as I know, that's not true. You can run a Linux system without the udev daemon, or with one written by you. But the thing is, you can't remove udev from the Linux kernel if you want to keep it calling Linux, as it'd be a fork. But udev isn't in the Linux kernel! How can I remove it from there?!
        e7620 12y ago
        > You can run a Linux system without the udev daemon, or with one written by you. A GNU/Linux system consists of several components. http://www.gnu.org/gnu/linux-and-gnu.html http://www.gnu.org/gnu/linux-and-gnu.html shows some examples. If you remove udev from Linux, I see at least two problems. One of them is technical: programmers expect Linux to have udev, because that's what the Linux authors advertise. The other is legal: Linux is a trademark, and if you replace something and introduce some incompatibility, it's a bad idea to keep calling it Linux. > But udev isn't in the Linux kernel! How can I remove it from there?! I think here lies the misunderstanding, udev was previously in the kernel repository, now it isn't. Fair enough. But consider that GNU is also separated in a different repository, but it still comprises the GNU/Linux system as a whole. Imagine we could only download GCC (necessary to compile Linux) as part of Adobe Flash, don't you think I could say the same? That "we can't even build a distro anymore without downloading Adobe Flash"?
        icebraining 12y ago
        But consider that GNU is also separated in a different repository, but it still comprises the GNU/Linux system as a whole. Yes, and udev would compose an hypothetical "Udev/Linux system". But Linux itself doesn't need udev. GNU / GCC is different because you literally can't compile Linux without it. But if and when LLVMLinux succeeds, I don't think you could say the same.
        e7620 12y ago
        > But Linux itself doesn't need udev. Would it really work? I think you'd have to rewrite some parts of the kernel, but I may be wrong now, in the past or the future. Anyways, we're arguing semantics here, it'd be better for all to separate udev from systemd. It's like Windows installers usually bundling the program with some crap, and I know most people don't appreciate that.
- vezzy-fnord 12y ago
  The codebase was part of the Linux kernel for a long time, however. That's what the OP probably meant.
kazinator 12y ago
For me, it is about the merits too, or lack thereof. The internals of systemd consists of reams of repetitive string processing that should not even have been written in C, and lots of indirection which obscures control flow paths through the program. The behavior of systemd is only completely specified only by its obtuse implementation, which was developed by some people who have no clue how to design that kind of thing (or to specify and document it). Why I even know this is because I had to switch to source level debugging to figure out why systemd is or isn't doing something, and how to change it. Background: I worked on substantial improvements of Linux's ability to support serial consoles on a USB-serial device. This required interaction with systemd. Part of the functionality is that you can plug a console in before booting or after, and get a prompt. Moreover, you can unplug a device with one kind of USB-serial chip, and plug in a different kind that uses a different driver, yet completely recover your existing session, which could be in the middle of a vi edit or whatever). To get the behavior completely polished, I had to wrestle with systemd, which was killing the sessions in an obscurely mysterious way that made the USB-serial/TTY/console code in the kernel look like a walk in the park. I think it took me several days to figure out, after poring over the systemd source code. First I discovered it was systemd doing the killing by putting some printk's in the kernel. Reading systemd documentation was useless, so I had to crack open the source code and start instrumenting that. I think it took the better part of a week to finally get the behaviors ironed out.
- e7620 12y ago
  I feel your pain. I expect the badly-documented bug-and-vulnerability-ridden unmantainable mess aka systemd to collapse as abandonware in the future. That's what happened with similar projects before. I used systemd last year to see if it was any good, and it's terrible. Specially journald, well it uses a binary format, I see this file, about 250KB, I wanted to decompress it as a text file to use my tools. OK, I had a brand-new very powerful computer. After 1 HOUR, I see a 5GB file, the decompression still running! Another bug, I needed to power off with (unix sysadmins will laugh at this): sync; sync; shutdown -h now otherwise systemd (systemctl poweroff) would randomly delete files in my home dir! So yes systemd is also technically bad. That's why *BSD, GNU Guix and other alternatives are gaining momentum.

by e7620 12y ago

icebraining 12y ago

udev (a part of the Linux kernel) I thought one of the advantages of udev (vs devfs) was that it was completely in userspace?

e7620 12y ago
You're correct, but that's not the point. Some device drivers run in userspace, even the Linux kernel itself can run in userspace!
- icebraining 12y ago
  How is it not the point? You said "we can't even build a distro anymore without downloading systemd," due to the implication that udev was embedded in the kernel, but that's not true. You can build a distro - just don't use udev.
  - e7620 12y ago
    udev is a necessary component of Linux. You could say just use a fork like eudev. Fine (for the time being). But the thing is, you can't remove udev from the Linux kernel if you want to keep it calling Linux, as it'd be a fork.
    - icebraining 12y ago
      udev is a necessary component of Linux. Why do you say that? That's what I don't understand. As far as I know, that's not true. You can run a Linux system without the udev daemon, or with one written by you. But the thing is, you can't remove udev from the Linux kernel if you want to keep it calling Linux, as it'd be a fork. But udev isn't in the Linux kernel! How can I remove it from there?!
      - e7620 12y ago
        > You can run a Linux system without the udev daemon, or with one written by you. A GNU/Linux system consists of several components. http://www.gnu.org/gnu/linux-and-gnu.html http://www.gnu.org/gnu/linux-and-gnu.html shows some examples. If you remove udev from Linux, I see at least two problems. One of them is technical: programmers expect Linux to have udev, because that's what the Linux authors advertise. The other is legal: Linux is a trademark, and if you replace something and introduce some incompatibility, it's a bad idea to keep calling it Linux. > But udev isn't in the Linux kernel! How can I remove it from there?! I think here lies the misunderstanding, udev was previously in the kernel repository, now it isn't. Fair enough. But consider that GNU is also separated in a different repository, but it still comprises the GNU/Linux system as a whole. Imagine we could only download GCC (necessary to compile Linux) as part of Adobe Flash, don't you think I could say the same? That "we can't even build a distro anymore without downloading Adobe Flash"?
        icebraining 12y ago
        But consider that GNU is also separated in a different repository, but it still comprises the GNU/Linux system as a whole. Yes, and udev would compose an hypothetical "Udev/Linux system". But Linux itself doesn't need udev. GNU / GCC is different because you literally can't compile Linux without it. But if and when LLVMLinux succeeds, I don't think you could say the same.
        e7620 12y ago
        > But Linux itself doesn't need udev. Would it really work? I think you'd have to rewrite some parts of the kernel, but I may be wrong now, in the past or the future. Anyways, we're arguing semantics here, it'd be better for all to separate udev from systemd. It's like Windows installers usually bundling the program with some crap, and I know most people don't appreciate that.
vezzy-fnord 12y ago
The codebase was part of the Linux kernel for a long time, however. That's what the OP probably meant.

kazinator 12y ago

For me, it is about the merits too, or lack thereof. The internals of systemd consists of reams of repetitive string processing that should not even have been written in C, and lots of indirection which obscures control flow paths through the program. The behavior of systemd is only completely specified only by its obtuse implementation, which was developed by some people who have no clue how to design that kind of thing (or to specify and document it). Why I even know this is because I had to switch to source level debugging to figure out why systemd is or isn't doing something, and how to change it. Background: I worked on substantial improvements of Linux's ability to support serial consoles on a USB-serial device. This required interaction with systemd. Part of the functionality is that you can plug a console in before booting or after, and get a prompt. Moreover, you can unplug a device with one kind of USB-serial chip, and plug in a different kind that uses a different driver, yet completely recover your existing session, which could be in the middle of a vi edit or whatever). To get the behavior completely polished, I had to wrestle with systemd, which was killing the sessions in an obscurely mysterious way that made the USB-serial/TTY/console code in the kernel look like a walk in the park. I think it took me several days to figure out, after poring over the systemd source code. First I discovered it was systemd doing the killing by putting some printk's in the kernel. Reading systemd documentation was useless, so I had to crack open the source code and start instrumenting that. I think it took the better part of a week to finally get the behaviors ironed out.

e7620 12y ago
I feel your pain. I expect the badly-documented bug-and-vulnerability-ridden unmantainable mess aka systemd to collapse as abandonware in the future. That's what happened with similar projects before. I used systemd last year to see if it was any good, and it's terrible. Specially journald, well it uses a binary format, I see this file, about 250KB, I wanted to decompress it as a text file to use my tools. OK, I had a brand-new very powerful computer. After 1 HOUR, I see a 5GB file, the decompression still running! Another bug, I needed to power off with (unix sysadmins will laugh at this): sync; sync; shutdown -h now otherwise systemd (systemctl poweroff) would randomly delete files in my home dir! So yes systemd is also technically bad. That's why *BSD, GNU Guix and other alternatives are gaining momentum.