Futures of distributions
joeyh.name
joeyh.name
Yet, it’s pretty obvious that today, traditional distros can no longer pretend to provide every single free software package that’s out there—let alone providing them with the level of QA and polishing that Debian, Fedora, Guix, and others provide.
In Guix we currently semi-automatically import package definitions from third-party repos like Hackage, PyPI, and the likes, for which we do some additional QA: https://gnu.org/s/guix/manual/html_node/Invoking-guix-import... .
One idea we discussed would be to offer as an option the ability to to “live imports”: users could install packages imported on the fly from these repos, while still taking advantage of the Guix user interface, transactional upgrades and rollback, and other goodies.
That could be a way to address user needs without throwing the baby with the water. There are technical challenges before we can get there, though…
I'm going to install GuixSD one of these days to try it out. Installing directly from third-party repos is something I don't remember seeing in NixOS when I tried it a year ago. I'm interested to see what other differences in design choices have been made.
As for GuixSD, you are right that the Shepherd, for instance, is not as mature as systemd (it’s also much simpler though). My comment was referring to packaging QA.
I do think that the ability to statically check a number of properties on a GuixSD config before it’s even instantiated (something that using a general purpose language buys us) helps a lot, though.
In a security focused world we should be trying to minimise the privileges needed to do anything - and in that should gain a lot of portability.
I want to apt-get my desktop environment into my home directory, and then be able to migrate system to system by rsyncing that bundle and I want user namespaces to enforce security within that space.
It's also distribution agnostic. It even works on Darwin (macOS). Although under its own distribution, NixOS, there are some extra advantages.
As much as I like Debian, I think switching the whole distribution to a package manager like Nix would simplify and speed things up greatly. The whole package tree would not need to be in sync, and different releases would become just package channels. Besides, brittle dist-upgrades would disappear.
Actually whole Linux distros could become just Nix configuration expressions...
Nix on the other hand will install each package under it's own version- or build-specific directory under /nix. ~/.nix-profile will be a symlink pointing to your profile under /nix, and ~/.nix-profile/bin will contain the executables of what you installed with nix.
This isn't just a question of putting files under something other than /. pacman (and maybe apt, too) has a way of installing packages under different directories, but the files in the packages themselves will typically have references to the libraries, executables and other files they depend on assuming they've been installed under /. So, in order to use those installed packages, you'd have to chroot into the directory you've selected to act as root, so the references will work right. Nix, on the other hand, made sure to edit the references each package has to their dependencies so you can simply execute something in ~/.nix-profile/bin and each successive dependency will resolve its dependencies to build-specific directories under /nix.
You can use nix with pacman or apt-get or yum or any traditional package manager you'd like and they won't conflict. This is what is meant by being distribution agnostic.
Nix is cross-distro in the ordinary sense you describe, of course. It is also more deeply cross-distro in that: • if you are trying to package for Nix in a normal way (the tools make it easy to do things this way and hard to do things otherwise by their nature), _all_ package collections for Nix will be cross-distro in this way • The Nix community has a collection of thousands of cross-distro packages you can already use right now
`pkgsrc` is similar in this respect, and takes a more conventional approach, like the one you describe in this comment. I think that's a meaningful sense in which it is cross-distro.
Another way to think of this is that tools like `rpm` and `dpkg` or `dnf` and `apt` are portable between distros _as far as distro developers are concerned_, whereas package managers/package collections like Nixpkgs and pkgsrc meet the portability needs of users of _existing distros_.
It's like there are different ways to optimize/reduce areas of complexity, and if you focus on one you trade off another.
Very interesting idea though of basically having logical "stacks" of applications/libs/configs for your home directory / personal preferences.
- One could compose together (arbitrary) combinations of a kernel of choice and userspace of choice?
- In "userspace" one could cobble together dependencies as needed for any project, and run sandboxed applications, which can only share information through common parent packages.
- No single package version for the "system". (This is already being done, in many examples)
- Maybe the kernel is just another package to be managed. Just something that starts when the computer boots, and lets you invoke the package manager to change state.
- Distributions would then just become snapshots of how different pieces are combined together. Sort of like what Docker images are created from dockerfiles today.
It would be enlightening to understand which aspects are possible today or in the foreseeable future, and what are the impediments to doing this. Or reasons why one might not actually want such a structure.
Making it work together is a lot of work, testing, and tweaking.
this is only relevant for core utilities though. It does not mean anything for my mail client to work "together" with my music production application. Apps in appstores do not work "together" yet they are wildly successful.
The distributions themselves are also a source of binary incompatibility. For example, one distribution may use symbol versioning while another may not, and this means users cannot download a random binary meant for one distribution and expect it to run on another one even if the versions of dependencies are the same. Compiling from source ensures the resulting software is binary compatible but the source is not guaranteed to be available since programs may be proprietary.
Correct, but they both might use pulseaudio, xorg, desktop notifications and much more. A lot of stuff is "core".
> Apps in appstores do not work "together" yet they are wildly successful
Only because of the ubiquitous hardware. appstores did not invent anything new.
Isn't this already so in most Linux distributions like Debian and its derivatives, RHEL and its derivatives, etc.?
https://blog.liw.fi/posts/2018/02/17/what_is_debian_all_abou...
For these things.. they want that control. But the allure of distributions is for all of the other things that you don't care about, e.g. I just want to use this command line tool, you can just install the package and have it work. And also know you can uninstall it, in many cases receive security updates, etc.
That is primarily where the two worlds collide.
With multiple versions (and pinning) available, developers stop doing the required work to keep forward/backward compatibility.
As the number of versions piles up, the amount of work required to patch vulnerabilities and backport those patches becomes unbearable. And distributions care about security.
* the producers of the package could produce a universal container that would run on all distributions.
* the distributions would only need to be sure they properly included a suitable container runtime. After all, Microsoft doesn't worry about packaging every third party software.
* the registry of software packages would need to include the software package
* this would work regardless of the technology a particular software package uses. (eg, whether it's written in C, Java, Python, .NET, etc) The package would pull in the dependencies.
* another thing that would be really nice, that I wanted since 1999, is that when you install a package it doesn't vomit files all over the filesystem.
* it might even be possible to install multiple versions of the same package (eg, Gimp 2.6, Gimp 2.8, etc)
Aren't Snap and Flatpack somewhat like this?
What I am describing may work great for end user software applications -- like Gimp, Inkscape, Audacity, Eclipse, etc. It might not work so well for languages, eg Python 2.7 vs Python 3.6.
* buildFHSUserEnv for those few heathen programs that need it
* nixpkgs
* nixpkgs again
* Nix
* Nix again
You want to check out Nix: http://nixos.org/nixpkgs/manual/