Poettering: Revisiting How We Put Together Linux Systems
Linux - NewsThis forum is for original Linux News. If you'd like to write content for LQ, feel free to contact us.
All threads in the forum need to be approved before they will appear.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Distribution: Debian, Red Hat, Slackware, Fedora, Ubuntu
Posts: 13,602
Rep:
Poettering: Revisiting How We Put Together Linux Systems
Quote:
In a previous blog story I discussed Factory Reset, Stateless Systems, Reproducible Systems & Verifiable Systems, I now want to take the opportunity to explain a bit where we want to take this with systemd in the longer run, and what we want to build out of it. This is going to be a longer story, so better grab a cold bottle of Club Mate before you start reading.
Traditional Linux distributions are built around packaging systems like RPM or dpkg, and an organization model where upstream developers and downstream packagers are relatively clearly separated: an upstream developer writes code, and puts it somewhere online, in a tarball. A packager than grabs it and turns it into RPMs/DEBs. The user then grabs these RPMs/DEBs and installs them locally on the system. For a variety of uses this is a fantastic scheme: users have a large selection of readily packaged software available, in mostly uniform packaging, from a single source they can trust. In this scheme the distribution vets all software it packages, and as long as the user trusts the distribution all should be good. The distribution takes the responsibility of ensuring the software is not malicious, of timely fixing security problems and helping the user if something is wrong.
However, this scheme also has a number of problems, and doesn't fit many use-cases of our software particularly well. Let's have a look at the problems of this scheme for many upstreams:
Lets say that this thing gets implemented, and someone brings out their own distro independent 'runtime' bundle, lets call it systemd-common-runtime for the sake or argument, and app bundles start being built against it. All of a sudden distro maintainers have no say about the libraries on their distro and are cut out of the loop.
Embrace, extend, extinguish: I think we're approaching stage 3.
Well, I made it through the whole post. That is one of the worst OS designs I have ever seen. If you want to remove a package (not an 'app' which has some form of artificial distinction from the rest of the software on the usr sub-volume) from your distro you have to create your own usr sub-volume as if you are forking the distro. To remove one package. Am I reading this wrong or...?
And what makes an 'app' vs. part of the core OS (on usr)? And what if an 'app' relies on some part of the 'usr' sub-volume (eg. running awk)? If one distro chooses to install this package in usr, but another doesn't, then the 'app' needs to include that as a 'runtime' dependency to make sure it is available. But then the distro WITH the software in usr will have to have an additional 'runtime' for that because the upstream 'app' requires it. So unless all 'usr' partitions (ie. all distros) are the same I don't see how this won't result in massive 'app' dependency trees which duplicate data. Or, at the very least, it would require separate packaging from each distro to only specify the 'real' dependencies, which effectively makes the whole design moot since that was the problem it is trying to solve. (And if anyone deviates from the norm by removing a package from 'usr', they will have to add that as a 'runtime' dependency to any apps that need it; they effectively become in charge of all packaging themselves.)
It is entirely possible I am not understanding this in full but turning a distro into firmware with a VCS is not exactly what I'm after. Maybe great for router companies?
PotteringOS has arrived. Neat. But sometimes I feel like he fans the flames to get more exposure.
Anyway - nothing new that I can see,. (sounds like what Slax does without brtfs),. packaging has always been a major discussion. That's why there is 20 different ways to do it.
It is entirely possible I am not understanding this in full but turning a distro into firmware with a VCS is not exactly what I'm after. Maybe great for router companies?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.