Proposal for a improved software distribution using BTRFS

[Teunis]

N and being freshly un-married

Fathers and mothers, lock up your daughters!

[claydoh]

Not knocking the concept, as it is interesting, to say the least.

1) All developers only release stable, quality, working, and useful software every time, all the time.
1b) support and bugs: a distro takes all these disparate bits and molds things into a more solid bit. So now the upstream has to do that (this could be a plus or a minus)
2) What will the 249958837 respins that mainly change wallpaper and font do
2a) heck, what will this do to the concept of a distro in general?
2b) This raises the bar of entry for those looking to be able to contribute to a project (ie how many coders got their feet wet via packaging and other distro-related tasks)
4) how the heck does does the end user deal with all this? Because you know any ui for this will be terrible





Sorry (NOT!) for being snarky lately, this busted wrist and being freshly un-married have unbalanced by something or another

[Feathers McGraw]

Are you going to be able to gain access to the source code of any open source application using this system of installing?

Good question, from what I understand the answer is yes. In the article he says that this method would not completely replace package managers etc, which would still be used by developers when generating snapshots. All of the packaging tools would still be there, so you could still do apt-get source foo or whatever.

If this system becomes the default system for installing applications that means everyone will have to install and use BTRFS, but what if you don't want to use or have any need to use that file system?
...
With this system it sounds like no more freedom of choice.

Well, developers would still produce tarballs of source or use git or whatever during development, I think what pottering is getting at is that they could also generate BTRFS snapshots built against a known set of libraries if they wanted more control over the environment their software was designed to run in. This doesn't make it more difficult for distribution maintainers to generate packages if they want to, since at present they still have to do all the work of generating .rpm or .deb files from tarballs! Instead, they have the option of using the developer's snapshot directly, without having to re-package everything each time.

Even if some distros didn't offer .debs, I'm sure there would still be a few distros who made it their thing to use the old way (like Devuan did with systemD); as you say Linux is nothing if not diverse!

I reckon a lot of people who just want to install applications quickly and easily would just stick with whatever the distro default is - if your distro used this method of software distribution then you would have a use for BTRFS - you'd be gaining the stability that comes with the extra testing the upstream devs have been able to do, so your software should be less buggy (in theory! Whether it would work in practice is another thing entirely...).

Turning the question on its head, what are the advantages of, say, EXT4 over BTRFS to the average user? I love to tinker, but I've not seen the need to change the filesystem yet, EXT4 works fine and I cba to change it. Using BTRFS for backups is the only reason I can think of to switch filesystems, and that's an argument for BTRFS over EXT4, not the other way around! Can you think of any?

I think the biggest reason people would resist this is that you'd be getting stuff signed by a huge number of different devs (since the installed files would come directly from developers), instead of everything being uploaded to a build-farm as a source package and turned into a .deb signed by Canonical or Debian. Pottering doesn't think people would care about this:

The classic Linux distribution scheme is frequently not what end users want, either. Many users are used to app markets like Android, Windows or iOS/Mac have. Markets are a platform that doesn't package, build or maintain software like distributions do, but simply allows users to quickly find and download the software they need, with the app vendor responsible for keeping the app updated, secured, and all that on the vendor's release cycle. Users tend to be impatient. They want their software quickly, and the fine distinction between trusting a single distribution or a myriad of app developers individually is usually not important for them.

...but I think he's wrong. Plenty of Linux users think this is important, and it would likely cause a huge stink (but doesn't every project of his? lol.)

It might sound good in principle but, I have a few questions:

1. Are you going to be able to gain access to the source code of any open source application using this system of installing?
One of the best things about open source is that anyone can obtain the source code and scrutinise it for any malicious code or to fix bugs.

2. If this system becomes the default system for installing applications that means everyone will have to install and use BTRFS, but what if you don't want to use or have any need to use that file system?
GNU OS (more commonly known as Linux) has always been about freedom to choose what you want to have installed and the freedom to run apps as you want to use them. With this system it sounds like no more freedom of choice.

[Feathers McGraw]

BTRFS fanboys might love this..

Lennart Pottering, systemD developer, has a proposal for distributing system images using BTRFS:

http://0pointer.net/blog/revisiting-...x-systems.html

It's an interesting read. Key points:

• aims to replace the need for end users to use packaging tools
• core OS, root filesystem, desktop environments, and development tools can be distributed separately as different BTRFS snapshots
• apps can be built to run against a specific snapshot containing a known set of libraries instead of having a package with a huge list of dependencies. Since the versions of each library are known, the upstream developer is able to do much more targeted testing instead of leaving this to distributors.
• multiple versoned snapshots would be installed at once, allowing the system to select the most appropriate snapshot to execute an application with
• not as wasteful as it sounds, because BTRFS has a diff tool so duplicate files aren't stored on disk
• allows end users to get the most up to date versions of a developer's software with minimal fuss

I'm still mulling it over, but I think it sounds like there could be some big advantages to doing things this way, mainly in terms of reducing the huge amount of effort that goes into maintaining all of the different Linux distributions - this makes installing a new distro as simple as swapping out one of the snapshots for another!

It's worth noting that this isn't ready yet, it's just an aspiration. What do you think?