4 ms·

Linux hasn't been just a kernel for a while; it's a kernel with some associated userland utilities that are developed together and normally expected to be prese

Linux hasn't been just a kernel for a while; it's a kernel with some associated userland utilities that are developed together and normally expected to be present. That's been the case in the filesystem part for a long time; the userland fs-related binaries are developed in sync with the kernel side. Systemd is doing something similar with e.g. cgroups. Linux develops fewer things this way than the BSDs typically do, outsourcing a lot of userland to other projects like GNU, but it doesn't literally develop only kernelspace code. Imo it's generally an improvement; the situation with trying to get things like cgroups to work together with process management previously was terrible.

jacquesm 12y ago
This is absolutely true, which is why linux is as large as it is and why you need certain stuff in order to bring up a functioning linux system. As for the filesystems they are modules plugged into the kernel (linked directly so you can boot our kernel straightaway or through a ram disk kludge as modules in linux, not the most elegant solution because technically that duplicates a buch of stuff but nobody seems to care too much) and a bunch of supporting programs, this has been the unix way since time immemorial, I think even the first unix I ever used had fsck. The reason those have to be kept in sync is simply because you don't want to run fsck on a filesystem that was built with a newer kernel that possibly has datastructures that your fsck (or other filesystem aware utility) accesses directly without going through the kernel. Essentially such programs re-implement a bunch of kernel functionality because they access file systems that are not currently mounted. Systemd on the other hand (in the case at hand) replicates the functionality of another user process that we already have, know how to use and have hardened over many millions of hours of use. That seems folly to me, it duplicates functionality, makes troubleshooting harder and increases the size of the codebase without actually improving anything. What's next? The framebuffer? Keyboard interface? TCP stack? There are no really hard reasons why those could not be user programs. It's fine with me if we make linux a micro kernel but let's do that in a way that we do not need to revisit the last decade or so of security issues and ill thought out interfaces. Once we start to need things like DBUS and X in order to bring up a server we've really lost the plot.
- rwmj 12y ago
  > What's next? Keyboard interface? I'm afraid so: http://lists.freedesktop.org/archives/systemd-devel/2013-November/014808.html http://lists.freedesktop.org/archives/systemd-devel/2013-Nov...
  - jacquesm 12y ago
    No way. That was meant as a joke. This is really bad.
    - angersock 12y ago
      All hail our new systemd overlords. Get with the program, citizen.
    - vezzy-fnord 12y ago
      Not as much as you'd think, actually. The CONFIG_VT subsystem has been a bane on the Linux developers for a long time. A userspace replacement entitled kmscon has already been around since 2012, by David Herrmann. It's a totally separate project. consoled is a minimalistic fallback done by the same person. I'm not sure if it really needs to exist, but replacing CONFIG_VT in of itself isn't bad. Most people will probably still have kmscon primarily.
      - JdeBP 12y ago
        I strongly suspect that at this point most people will in fact have one of the several tools that preceded kmscon by some years and are still around: zhcon (http://zhcon.sourceforge.net/ http://zhcon.sourceforge.net/), jfbterm (http://jfbterm.sourceforge.jp/ http://jfbterm.sourceforge.jp/), fbterm (https://code.google.com/p/fbterm/ https://code.google.com/p/fbterm/), yaft (https://github.com/uobikiemukot/yaft https://github.com/uobikiemukot/yaft), fbpad (http://repo.or.cz/w/fbpad.git http://repo.or.cz/w/fbpad.git), and so forth.

jacquesm 12y ago

This is absolutely true, which is why linux is as large as it is and why you need certain stuff in order to bring up a functioning linux system. As for the filesystems they are modules plugged into the kernel (linked directly so you can boot our kernel straightaway or through a ram disk kludge as modules in linux, not the most elegant solution because technically that duplicates a buch of stuff but nobody seems to care too much) and a bunch of supporting programs, this has been the unix way since time immemorial, I think even the first unix I ever used had fsck. The reason those have to be kept in sync is simply because you don't want to run fsck on a filesystem that was built with a newer kernel that possibly has datastructures that your fsck (or other filesystem aware utility) accesses directly without going through the kernel. Essentially such programs re-implement a bunch of kernel functionality because they access file systems that are not currently mounted. Systemd on the other hand (in the case at hand) replicates the functionality of another user process that we already have, know how to use and have hardened over many millions of hours of use. That seems folly to me, it duplicates functionality, makes troubleshooting harder and increases the size of the codebase without actually improving anything. What's next? The framebuffer? Keyboard interface? TCP stack? There are no really hard reasons why those could not be user programs. It's fine with me if we make linux a micro kernel but let's do that in a way that we do not need to revisit the last decade or so of security issues and ill thought out interfaces. Once we start to need things like DBUS and X in order to bring up a server we've really lost the plot.

rwmj 12y ago
> What's next? Keyboard interface? I'm afraid so: http://lists.freedesktop.org/archives/systemd-devel/2013-November/014808.html http://lists.freedesktop.org/archives/systemd-devel/2013-Nov...
- jacquesm 12y ago
  No way. That was meant as a joke. This is really bad.
  - angersock 12y ago
    All hail our new systemd overlords. Get with the program, citizen.
  - vezzy-fnord 12y ago
    Not as much as you'd think, actually. The CONFIG_VT subsystem has been a bane on the Linux developers for a long time. A userspace replacement entitled kmscon has already been around since 2012, by David Herrmann. It's a totally separate project. consoled is a minimalistic fallback done by the same person. I'm not sure if it really needs to exist, but replacing CONFIG_VT in of itself isn't bad. Most people will probably still have kmscon primarily.
    - JdeBP 12y ago
      I strongly suspect that at this point most people will in fact have one of the several tools that preceded kmscon by some years and are still around: zhcon (http://zhcon.sourceforge.net/ http://zhcon.sourceforge.net/), jfbterm (http://jfbterm.sourceforge.jp/ http://jfbterm.sourceforge.jp/), fbterm (https://code.google.com/p/fbterm/ https://code.google.com/p/fbterm/), yaft (https://github.com/uobikiemukot/yaft https://github.com/uobikiemukot/yaft), fbpad (http://repo.or.cz/w/fbpad.git http://repo.or.cz/w/fbpad.git), and so forth.