Poettering: Revisiting How We Put Together Linux Systems

jeremy · 09-01-2014, 10:56 AM

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:

More at 0pointer...

Any thoughts on this?

--jeremy

dugan · 09-01-2014, 11:03 AM

Impression from skimming:

I hate to be the person who's scared of change, but these are scary changes.

brianL · 09-01-2014, 11:27 AM

Why don't they create their OS from scratch, and leave Linux in peace?

GazL · 09-01-2014, 01:31 PM

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.

Germany_chris · 09-10-2014, 11:40 AM

My thoughts are:

I'm fine with systemd as it stands

I'm fine with Pulse

I'm good with the idea of using butter as default and using COW for purposes other than COW

I'm not fine with futzing with the package managers nor do I think that he'll get buy in if he does.

T3slider · 10-28-2014, 03:46 PM

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?

szboardstretcher · 10-28-2014, 03:55 PM

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.

Here is a good list of some of the discussions: http://www.reddit.com/r/linux/commen...linux_systems/

ReaperX7 · 10-28-2014, 04:38 PM

PoeterringOS... you mean Lennartix? Oh God, I just threw up in my mouth...

Tinkster · 10-29-2014, 09:55 PM

Quote:

Originally Posted by T3slider

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?

Reinventing a micro-vax?