5 ms·

I like many things systemd has brought. However, I think the app-ification they are planning to deploy in Linux systems is extremely dangerous. Essentially the

by nextos 12y ago

I like many things systemd has brought. However, I think the app-ification they are planning to deploy in Linux systems is extremely dangerous. Essentially they are implementing app bundles as containers [1]. All good lessons learnt from package managers? Gone. Nix? Forgotten. Imagine a heartbleed like scenario. In a controlled situation with a distro that uses a package manager this is easy to fix. Just upgrade the compromised package. Now think what happens if you have 20 different containers running 20 different userlands... It's really scary. Linux has become such a nice OS partly because many distros created great package management tools. These systemd guys make things terribly complex for no reason. Systemd itself is a monster running as PID 1, which is not very wise from a security perspective either. Pulseaudio is slow and unreliable. Dbus is quite inefficient. Etc. Things are getting ugly. They are messing up with the Linux userland and ignoring core Unix principles. [1] http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html http://0pointer.net/blog/revisiting-how-we-put-together-linu...

snogglethorpe 12y ago
I get the impression, e.g. from Ubuntu's "new package format", that NIH aside (always a big factor with Ubuntu), that many of these efforts are mostly targeting "simple apps", i.e. standalone applications that don't require any kind of complicated wiring into the system. It looks like they'll still need a "real" package format to actually do things like update the system, install kernels, libraries, and dev stuff, etc.
- digi_owl 12y ago
  Anything about libc will apparently be handled by special "library" packages, or bundled with the "apps" themselves. As for kernels and such, at least with Ubuntu Snappy this will be handles in a ChromeOS like fashion. Dump the updated base system into a separate partition, change the Grub config, reboot. If the system fails to boot up it will either instruct the user (i see no admins, nor "power-users" in this scenario) to pick the failsafe/recover option, or do so automatically. Basically you can forget everything you learned about PC or server. The future is all containers and VMs. The computational equivalent of TV dinners or canned goods.
qznc 12y ago
> Systemd itself is a monster running as PID 1 I have yet to see a convincing argument for this. Is the binary bigger than other inits? Does it do that much more? Link please.
- chris_wot 12y ago
  It's not. See https://people.debian.org/~stapelberg/docs/systemd-dependencies.html https://people.debian.org/~stapelberg/docs/systemd-dependenc...
  - vezzy-fnord 12y ago
    Extremely outdated. In the 15 versions since then, systemd has evolved quite tremendously with too many things to list succinctly.
    - chris_wot 12y ago
      Ok, I'll bite. What does systemd itself link to now?
      - chris_wot 12y ago
        0x0000000000000001 (NEEDED) Shared library: [libsystemd-daemon.so.0] 0x0000000000000001 (NEEDED) Shared library: [libudev.so.1] 0x0000000000000001 (NEEDED) Shared library: [libselinux.so.1] 0x0000000000000001 (NEEDED) Shared library: [librt.so.1] 0x0000000000000001 (NEEDED) Shared library: [libwrap.so.0] 0x0000000000000001 (NEEDED) Shared library: [libpam.so.0] 0x0000000000000001 (NEEDED) Shared library: [libaudit.so.1] 0x0000000000000001 (NEEDED) Shared library: [libcap.so.2] 0x0000000000000001 (NEEDED) Shared library: [libkmod.so.2] 0x0000000000000001 (NEEDED) Shared library: [libdbus-1.so.3] 0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x0000000000000001 (NEEDED) Shared library: [ld-linux-x86-64.so.2] They've replaced libattr with librt, otherwise the linked libraries are the same. Also, the package dependencies are the same. What's this about being out of date? Systemd changes very fast, but no additional libraries are linked to and one was changed, and no additional package dependencies required. I'll have a look at interface changes next.
mercurial 12y ago
> Systemd itself is a monster running as PID 1, which is not very wise from a security perspective either. No. Only a small part of systemd runs as PID 1. Systemd is not a monolith, it is a bunch of various utilities. > However, I think the app-ification they are planning to deploy in Linux systems is extremely dangerous. I agree. This sounds scary. However, it does not mean that distros will hurry to adopt this kind of system. I also get the impression that it is targeted more toward special use cases than intended to replace traditional package managers. > Pulseaudio is slow and unreliable. While anecdote is not data, I never had any issue with it. > Dbus is quite inefficient. They did not invent Dbus, and using the foremost userland IPC mechanism to communicate is not unreasonable (since, as mentioned above, systemd is a bunch of utilities, they do need some form of IPC). I don't think it has an impact in practice.
- pdkl95 12y ago
  > Only a small part of systemd runs as PID 1. Systemd is not a monolith, it is a bunch of various utilities. Ahh, there's the talking point I mentioned in my earlier post[1]. What you're not understanding is that when we describe something as "monolithic" (or "modular") we're talking about if the design[2], not the number of binaries it happens to compile into. This is about minimizing complexity, and the way to do that is to break the problem into small pieces, while clearly and rigorously defining the interconnections between those pieces (an area that necessarily involves higher complexity). As an example in the opposite direction, consider busybox. While it compiles into a single binary, the features provided by busybox are very modular. You could remove any of the utilities it can emulate without that change cascading into lots of other unrelated features (with build system support), and I could replace any of the utilities with something else (i.e. the standard non-busybox version) by simply removing a symlink. Systemd is designed in the opposite manner, on purpose. They put every but of code the project absorbs into the same repository, claiming it makes development easier. Of course it does... initially; you get to skip the all those clearly and rigorously defined interfaces. They can seem like unnecessary work in the beginning, but it is going to be hell maintaining that mess of code in the long run. [1] https://news.ycombinator.com/item?id=9515413 https://news.ycombinator.com/item?id=9515413 [2] See the "Rule of Modularity": http://www.catb.org/esr/writings/taoup/html/ch01s06.html#id2877537 http://www.catb.org/esr/writings/taoup/html/ch01s06.html#id2...
nl 12y ago
Just upgrade the compromised package. Now think what happens if you have 20 different containers running 20 different userlands... This is exactly the same as the virtualization scenario, where you might have hundreds of possibly vulnerable virtual-machines running under the same virtualization platform (which maybe Linux). Or lots of Docker containers, some of which may have vulnerable software. App-containerization is usually seen as having security benefits, as it promotes isolation. Yes, package management tools are great. Containers are also great. I can imagine a future world in which package management tools understood containers, and could choose how to apply updates (or not!) to nested containers.
- glandium 12y ago
  > I can imagine a future world in which package management tools understood containers Solaris has had this with zones since, IIRC, before Oracle bought Sun.
  - nl 12y ago
    Oh god no! Zones are cool, but package management on Solaris is pretty bad. It has improved since they built something similar to Apt, but AFAIK it doesn't have the deep understanding of Zones that I'm suggesting is desirable.
    - the_why_of_y 12y ago
      On Solaris 10 package management was generally a pain, but there was a "sparse root" kind of zone that shares /usr with the global zone, so these get the updates automatically. http://solaris.reys.net/zones-in-solaris-10-part-three-sparse-root-and-whole-root/ http://solaris.reys.net/zones-in-solaris-10-part-three-spars... For OpenSolaris derived products with ipkg, the documentation says that "pkg update" in the global zone will update not only the global zone but all non-global zones as well. https://docs.oracle.com/cd/E26502_01/html/E28984/gmhaa.html https://docs.oracle.com/cd/E26502_01/html/E28984/gmhaa.html

by nextos 12y ago

snogglethorpe 12y ago

I get the impression, e.g. from Ubuntu's "new package format", that NIH aside (always a big factor with Ubuntu), that many of these efforts are mostly targeting "simple apps", i.e. standalone applications that don't require any kind of complicated wiring into the system. It looks like they'll still need a "real" package format to actually do things like update the system, install kernels, libraries, and dev stuff, etc.

digi_owl 12y ago
Anything about libc will apparently be handled by special "library" packages, or bundled with the "apps" themselves. As for kernels and such, at least with Ubuntu Snappy this will be handles in a ChromeOS like fashion. Dump the updated base system into a separate partition, change the Grub config, reboot. If the system fails to boot up it will either instruct the user (i see no admins, nor "power-users" in this scenario) to pick the failsafe/recover option, or do so automatically. Basically you can forget everything you learned about PC or server. The future is all containers and VMs. The computational equivalent of TV dinners or canned goods.

qznc 12y ago

> Systemd itself is a monster running as PID 1 I have yet to see a convincing argument for this. Is the binary bigger than other inits? Does it do that much more? Link please.

chris_wot 12y ago
It's not. See https://people.debian.org/~stapelberg/docs/systemd-dependencies.html https://people.debian.org/~stapelberg/docs/systemd-dependenc...
- vezzy-fnord 12y ago
  Extremely outdated. In the 15 versions since then, systemd has evolved quite tremendously with too many things to list succinctly.
  - chris_wot 12y ago
    Ok, I'll bite. What does systemd itself link to now?
    - chris_wot 12y ago
      0x0000000000000001 (NEEDED) Shared library: [libsystemd-daemon.so.0] 0x0000000000000001 (NEEDED) Shared library: [libudev.so.1] 0x0000000000000001 (NEEDED) Shared library: [libselinux.so.1] 0x0000000000000001 (NEEDED) Shared library: [librt.so.1] 0x0000000000000001 (NEEDED) Shared library: [libwrap.so.0] 0x0000000000000001 (NEEDED) Shared library: [libpam.so.0] 0x0000000000000001 (NEEDED) Shared library: [libaudit.so.1] 0x0000000000000001 (NEEDED) Shared library: [libcap.so.2] 0x0000000000000001 (NEEDED) Shared library: [libkmod.so.2] 0x0000000000000001 (NEEDED) Shared library: [libdbus-1.so.3] 0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x0000000000000001 (NEEDED) Shared library: [ld-linux-x86-64.so.2] They've replaced libattr with librt, otherwise the linked libraries are the same. Also, the package dependencies are the same. What's this about being out of date? Systemd changes very fast, but no additional libraries are linked to and one was changed, and no additional package dependencies required. I'll have a look at interface changes next.

mercurial 12y ago

> Systemd itself is a monster running as PID 1, which is not very wise from a security perspective either. No. Only a small part of systemd runs as PID 1. Systemd is not a monolith, it is a bunch of various utilities. > However, I think the app-ification they are planning to deploy in Linux systems is extremely dangerous. I agree. This sounds scary. However, it does not mean that distros will hurry to adopt this kind of system. I also get the impression that it is targeted more toward special use cases than intended to replace traditional package managers. > Pulseaudio is slow and unreliable. While anecdote is not data, I never had any issue with it. > Dbus is quite inefficient. They did not invent Dbus, and using the foremost userland IPC mechanism to communicate is not unreasonable (since, as mentioned above, systemd is a bunch of utilities, they do need some form of IPC). I don't think it has an impact in practice.

pdkl95 12y ago
> Only a small part of systemd runs as PID 1. Systemd is not a monolith, it is a bunch of various utilities. Ahh, there's the talking point I mentioned in my earlier post[1]. What you're not understanding is that when we describe something as "monolithic" (or "modular") we're talking about if the design[2], not the number of binaries it happens to compile into. This is about minimizing complexity, and the way to do that is to break the problem into small pieces, while clearly and rigorously defining the interconnections between those pieces (an area that necessarily involves higher complexity). As an example in the opposite direction, consider busybox. While it compiles into a single binary, the features provided by busybox are very modular. You could remove any of the utilities it can emulate without that change cascading into lots of other unrelated features (with build system support), and I could replace any of the utilities with something else (i.e. the standard non-busybox version) by simply removing a symlink. Systemd is designed in the opposite manner, on purpose. They put every but of code the project absorbs into the same repository, claiming it makes development easier. Of course it does... initially; you get to skip the all those clearly and rigorously defined interfaces. They can seem like unnecessary work in the beginning, but it is going to be hell maintaining that mess of code in the long run. [1] https://news.ycombinator.com/item?id=9515413 https://news.ycombinator.com/item?id=9515413 [2] See the "Rule of Modularity": http://www.catb.org/esr/writings/taoup/html/ch01s06.html#id2877537 http://www.catb.org/esr/writings/taoup/html/ch01s06.html#id2...

nl 12y ago

Just upgrade the compromised package. Now think what happens if you have 20 different containers running 20 different userlands... This is exactly the same as the virtualization scenario, where you might have hundreds of possibly vulnerable virtual-machines running under the same virtualization platform (which maybe Linux). Or lots of Docker containers, some of which may have vulnerable software. App-containerization is usually seen as having security benefits, as it promotes isolation. Yes, package management tools are great. Containers are also great. I can imagine a future world in which package management tools understood containers, and could choose how to apply updates (or not!) to nested containers.

glandium 12y ago
> I can imagine a future world in which package management tools understood containers Solaris has had this with zones since, IIRC, before Oracle bought Sun.
- nl 12y ago
  Oh god no! Zones are cool, but package management on Solaris is pretty bad. It has improved since they built something similar to Apt, but AFAIK it doesn't have the deep understanding of Zones that I'm suggesting is desirable.
  - the_why_of_y 12y ago
    On Solaris 10 package management was generally a pain, but there was a "sparse root" kind of zone that shares /usr with the global zone, so these get the updates automatically. http://solaris.reys.net/zones-in-solaris-10-part-three-sparse-root-and-whole-root/ http://solaris.reys.net/zones-in-solaris-10-part-three-spars... For OpenSolaris derived products with ipkg, the documentation says that "pkg update" in the global zone will update not only the global zone but all non-global zones as well. https://docs.oracle.com/cd/E26502_01/html/E28984/gmhaa.html https://docs.oracle.com/cd/E26502_01/html/E28984/gmhaa.html