5 ms·

It's very interesting how the whole article (and Lennart) shies away from even uttering "package manager" and instead talks about containers. This is fundament

It's very interesting how the whole article (and Lennart) shies away from even uttering "package manager" and instead talks about containers. This is fundamentally an implementation of Lennart's blog post - http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html http://0pointer.net/blog/revisiting-how-we-put-together-linu.... That article used the words "We want an efficient way that allows vendors to package their software " ... which was followed by a storm of angry systemd-is-the-borg-it-needs-to-die tweets and articles. Even on HN - the response to this article seems fairly muted... although it is a bigger political issue than even init systems. I wonder what the response would have been to "systemd introduces new portable packaging format"

oblio 10y ago
If no one will say it, I will: it's stupid that we have multiple package managers and package formats. There's no fundamental technical reason Linux couldn't have just 1 extensible package format and 1 extensible package manager. All the reasons for the split are social ("I like A"), political ("we want to be able to control A") or historical ("A came first, we built our house on A, we can't abandon A").
- qznc 10y ago
  Why do have so many programming languages? Because they fulfill different needs. C and Python are used for different things. Yet, there is overlap, which creates a constant tension. When do you rewrite your Python module into C for better performance? Likewise, different packaging formats exist for different needs. Docker and Ubuntu Snap are for different needs, yet they overlap. Systemd did initially not care about packaging and containers. Yet, there is an overlap, like "How to do logging?". Docker and Systemd both grow and overlap more and more.
  - oblio 10y ago
    We're talking about different things here. deb/rpm serve the same role. yum/apt ditto. We have gratuitous differences which could have been prevented with a better design. See for example even the mess in the rpm world where a SUSE rpm may or may not work on Red Hat.
- legulere 10y ago
  Even with the same package managers, packages are still incompatible from different repositories because of differing assumptions about the underlying system and differing packages for the dependencies. Converting between the differing package formats is actually relatively easy and tools like `alien` exist, that do that.
  - oblio 10y ago
    I know about that, I actually hate those "underlying system" differences even more. With a bit of forethought we could have covered all the use cases and not have silly things such as /etc/redhat-release vs /etc/debian_version.[1] There's no reason we couldn't have had a "/etc/distro-info" with a standardized format for writing down the distro name, the platform and the full distro version (branch/release, minor release, revision, build number, etc.). And there's thousands of these differences. As I said: social/political/historical reasons bringing us down. [1] I know about lsb_release, but that's an example of an afterthought, not a part of the initial design.
    - vamega 10y ago
      "/etc/os-release" is present in most newer releases. Sounds exactly what you want from "/etc/distro-info"
      - oblio 10y ago
        Whaddayaknow, I missed that file. Apparently it's a Freedesktop standard (https://www.freedesktop.org/software/systemd/man/os-release.html https://www.freedesktop.org/software/systemd/man/os-release....). My point still stands, something like this should have been included from the first releases of Linux distros, 20 years ago. And that was just a random example I came up with after 2 minutes of trying to prove a point. There's many, many more like it. Also, just for kicks I took at look at the spec and... 1. ANSI_COLOR is funny: > A suggested presentation color when showing the OS name on the console. This should be specified as string suitable for inclusion in the ESC [ m ANSI/ECMA-48 escape code for setting graphical rendition. This field is optional. Example: "ANSI_COLOR="0;31"" for red, or "ANSI_COLOR="1;34"" for light blue. 2. And some parts are scary: > parameters may be set using os-release Oh-oh! Everything is optional! That's really bad for a RFC.
- majewsky 10y ago
  The historical argument might be the biggest one, from my own experience with the steaming pile of shit that is RPM: https://blog.bethselamin.de/posts/argh-pm.html https://blog.bethselamin.de/posts/argh-pm.html
  - oblio 10y ago
    I actually recently took a much shallower dive through RPM than yours (http://blog.oblio360.com/2016/08/23/rpm-install/ http://blog.oblio360.com/2016/08/23/rpm-install/). I knew that RPM was not that loved as a format, but what you've described there truly is "insane" (I know that you used that word many times in the article, but it fits the situation).
  - digi_owl 10y ago
    Really makes one wonder why RH is still allowed to set the direction of Linux as a whole. Oh wait, money...
qznc 10y ago
I like the vision Lennart describes. My hope for systemd is that it unifies the Linux Desktop universe. The Free Desktop movement has stopped doing that. There is a time for exploding into lots of variants and a time for unifying. Remember the time, when git came up? There was an explosion of DVCSs (Monotone, Darcs, Bazaar, and more). For now, the world has mostly settled on git with Mercurial as a secondary.
- pmlnr 10y ago
  Because unification kills diversity, which kinda kills progress and new ideas, which kills free. ( Free != free ).
  - rantanplan 10y ago
    Even evolution, after it tries multiple possible routes, it chooses one and goes with it. We experimented enough and we now know how to provide solutions to very common problems. Case in point, having a gazillion package managers is not diversity, but technological masturbation, however you spin it. BTW I'm telling this after ~20 years experience with Unix/Linux systems. I'm really getting tired of the "diversity" argument.
tech2 10y ago
This (packaging/installation/management) seems to be a solved problem for those who've used Nix. Does it need solving again in a Lennart-specific way?
- digi_owl 10y ago
  Poettering have a bad habit of not looking before coding (or blogging). That said, i think that blog predates Nix, but it sure as hell do not predate Gobolinux. And Gobolinux does its thing using mostly shell script (with the odd Python or binary for performance reasons).
  - chriswarbo 10y ago
    > i think that blog predates Nix, but it sure as hell do not predate Gobolinux The blog post is dated September 2014. Nix had been around for at least a decade by then (e.g. see https://nixos.org/docs/papers.html https://nixos.org/docs/papers.html ). Wikipedia says Gobolinux is about the same age as Nix.
- chriswarbo 10y ago
  I primarily think of Nix as being a build tool akin to Make rather than a package manager. It's almost as if the flakiness of Make made us think that building applications or libraries was somehow a different thing to building an OS, so we invented a separate thing called a package manager. Then Nix came along and showed that a single build tool can be used for something as simple as a preprocessor (Nix's string quasiquotation is very nice), through to compiling applications, bundling applications into a coherent OS, and even orchestrating clusters of real & virtual machines. I wonder if this proposed system would be as amenable to handling such a wide variety of software (e.g. https://nixos.org/nixpkgs/manual/#chap-language-support https://nixos.org/nixpkgs/manual/#chap-language-support ) on such a wide variety of platforms (e.g. https://github.com/NixOS/nixpkgs/tree/master/pkgs/os-specific https://github.com/NixOS/nixpkgs/tree/master/pkgs/os-specifi... ).
wmf 10y ago
In Linux, the term "package manager" is loaded with baggage like twisty mazes of dependencies and kitchen-sink repositories. This proposal doesn't have those.

oblio 10y ago

If no one will say it, I will: it's stupid that we have multiple package managers and package formats. There's no fundamental technical reason Linux couldn't have just 1 extensible package format and 1 extensible package manager. All the reasons for the split are social ("I like A"), political ("we want to be able to control A") or historical ("A came first, we built our house on A, we can't abandon A").

qznc 10y ago
Why do have so many programming languages? Because they fulfill different needs. C and Python are used for different things. Yet, there is overlap, which creates a constant tension. When do you rewrite your Python module into C for better performance? Likewise, different packaging formats exist for different needs. Docker and Ubuntu Snap are for different needs, yet they overlap. Systemd did initially not care about packaging and containers. Yet, there is an overlap, like "How to do logging?". Docker and Systemd both grow and overlap more and more.
- oblio 10y ago
  We're talking about different things here. deb/rpm serve the same role. yum/apt ditto. We have gratuitous differences which could have been prevented with a better design. See for example even the mess in the rpm world where a SUSE rpm may or may not work on Red Hat.
legulere 10y ago
Even with the same package managers, packages are still incompatible from different repositories because of differing assumptions about the underlying system and differing packages for the dependencies. Converting between the differing package formats is actually relatively easy and tools like `alien` exist, that do that.
- oblio 10y ago
  I know about that, I actually hate those "underlying system" differences even more. With a bit of forethought we could have covered all the use cases and not have silly things such as /etc/redhat-release vs /etc/debian_version.[1] There's no reason we couldn't have had a "/etc/distro-info" with a standardized format for writing down the distro name, the platform and the full distro version (branch/release, minor release, revision, build number, etc.). And there's thousands of these differences. As I said: social/political/historical reasons bringing us down. [1] I know about lsb_release, but that's an example of an afterthought, not a part of the initial design.
  - vamega 10y ago
    "/etc/os-release" is present in most newer releases. Sounds exactly what you want from "/etc/distro-info"
    - oblio 10y ago
      Whaddayaknow, I missed that file. Apparently it's a Freedesktop standard (https://www.freedesktop.org/software/systemd/man/os-release.html https://www.freedesktop.org/software/systemd/man/os-release....). My point still stands, something like this should have been included from the first releases of Linux distros, 20 years ago. And that was just a random example I came up with after 2 minutes of trying to prove a point. There's many, many more like it. Also, just for kicks I took at look at the spec and... 1. ANSI_COLOR is funny: > A suggested presentation color when showing the OS name on the console. This should be specified as string suitable for inclusion in the ESC [ m ANSI/ECMA-48 escape code for setting graphical rendition. This field is optional. Example: "ANSI_COLOR="0;31"" for red, or "ANSI_COLOR="1;34"" for light blue. 2. And some parts are scary: > parameters may be set using os-release Oh-oh! Everything is optional! That's really bad for a RFC.
majewsky 10y ago
The historical argument might be the biggest one, from my own experience with the steaming pile of shit that is RPM: https://blog.bethselamin.de/posts/argh-pm.html https://blog.bethselamin.de/posts/argh-pm.html
- oblio 10y ago
  I actually recently took a much shallower dive through RPM than yours (http://blog.oblio360.com/2016/08/23/rpm-install/ http://blog.oblio360.com/2016/08/23/rpm-install/). I knew that RPM was not that loved as a format, but what you've described there truly is "insane" (I know that you used that word many times in the article, but it fits the situation).
- digi_owl 10y ago
  Really makes one wonder why RH is still allowed to set the direction of Linux as a whole. Oh wait, money...

qznc 10y ago

I like the vision Lennart describes. My hope for systemd is that it unifies the Linux Desktop universe. The Free Desktop movement has stopped doing that. There is a time for exploding into lots of variants and a time for unifying. Remember the time, when git came up? There was an explosion of DVCSs (Monotone, Darcs, Bazaar, and more). For now, the world has mostly settled on git with Mercurial as a secondary.

pmlnr 10y ago
Because unification kills diversity, which kinda kills progress and new ideas, which kills free. ( Free != free ).
- rantanplan 10y ago
  Even evolution, after it tries multiple possible routes, it chooses one and goes with it. We experimented enough and we now know how to provide solutions to very common problems. Case in point, having a gazillion package managers is not diversity, but technological masturbation, however you spin it. BTW I'm telling this after ~20 years experience with Unix/Linux systems. I'm really getting tired of the "diversity" argument.

tech2 10y ago

This (packaging/installation/management) seems to be a solved problem for those who've used Nix. Does it need solving again in a Lennart-specific way?

digi_owl 10y ago
Poettering have a bad habit of not looking before coding (or blogging). That said, i think that blog predates Nix, but it sure as hell do not predate Gobolinux. And Gobolinux does its thing using mostly shell script (with the odd Python or binary for performance reasons).
- chriswarbo 10y ago
  > i think that blog predates Nix, but it sure as hell do not predate Gobolinux The blog post is dated September 2014. Nix had been around for at least a decade by then (e.g. see https://nixos.org/docs/papers.html https://nixos.org/docs/papers.html ). Wikipedia says Gobolinux is about the same age as Nix.
chriswarbo 10y ago
I primarily think of Nix as being a build tool akin to Make rather than a package manager. It's almost as if the flakiness of Make made us think that building applications or libraries was somehow a different thing to building an OS, so we invented a separate thing called a package manager. Then Nix came along and showed that a single build tool can be used for something as simple as a preprocessor (Nix's string quasiquotation is very nice), through to compiling applications, bundling applications into a coherent OS, and even orchestrating clusters of real & virtual machines. I wonder if this proposed system would be as amenable to handling such a wide variety of software (e.g. https://nixos.org/nixpkgs/manual/#chap-language-support https://nixos.org/nixpkgs/manual/#chap-language-support ) on such a wide variety of platforms (e.g. https://github.com/NixOS/nixpkgs/tree/master/pkgs/os-specific https://github.com/NixOS/nixpkgs/tree/master/pkgs/os-specifi... ).

wmf 10y ago

In Linux, the term "package manager" is loaded with baggage like twisty mazes of dependencies and kitchen-sink repositories. This proposal doesn't have those.