Bedrock Linux – a meta Linux distribution

Installing packages on your distro is very easy, either via a simple command like `apt install ` or via a graphical appstore-like interface to the same thing. All major distro package managers are very mature and reliable.

Distributing software through those repos as a developer is not very easy, but it's not required either. If you want to distribute your app to all Linux distros without worrying about compatibility, and without requiring your customers to use the command line, you can use something like [App Image](https://appimage.org/), which is basically the same concept as [App Bundles](https://developer.apple.com/library/archive/documentation/Co...) on Macs.

There are also a lot of (less good) alternatives to App Images, like [Flatpack](https://flatpak.org/) and [Snap](https://snapcraft.io/).

If you want something fancier, you could go with something like [Guix](https://guix.gnu.org/) or [Nix](https://nixos.org/explore.html) if your customers are developers or otherwise technical.

If you want to get less fancy, you could distribute your binaries with an install script that detects the current distro/version and downloads dependencies using the installed package manager.

And if you're a user who just wants to download stuff on their computer, you just need to follow the instructions from the provider. It usually involves one of the methods above.

I address them in this FAQ entry [0]. In my experience providing support for Bedrock Linux users for over a decade, the most notable downside is the resulting complexity. This is a fundamental result of what Bedrock is trying to do. There is more to learn, more that could go wrong, and more to wrestle with if something does go wrong. It's perfectly manageable for adequately experienced Linux users, but not necessarily for everyone.

> I'm an avid NixOS user, and tend to supply PRs every now and then if I run into problems. If I hit a problem in Bedrock, can I easily do the same?

I see two ways to interpret this question:

If you are asking whether Bedrock is open to PRs, it certainly is. Bedrock is a _lot_ of work, and I'm always grateful for assistance. Historically, the PRs I've shot down have primarily either been attempts to pull the project in another direction, or ones which break existing functionality. Those which broaden the list of features [1] or distros [2] Bedrock supports, if clean enough, are usually accepted.

If you are asking whether Bedrock plays nicely with NixOS, sadly it does not currently do so [2]. I know at least one blocker for Bedrock with NixOS that I plan to resolve in the next major Bedrock release (0.8.0). However, I expect there to be many more. Once I have completed more pressing tasks - sadly, likely years from now - I plan to deep dive into how NixOS works with the aim of getting Bedrock to play more nicely with it. If any of the many apparently large number of NixOS users here find this problem space interesting and would like to work on it before I get to it, I would be delighted.

[0] https://bedrocklinux.org/faq.html#why-not-use-bedrock [1] https://bedrocklinux.org/0.7/feature-compatibility.html [2] https://bedrocklinux.org/0.7/distro-compatibility.html

oh don't be silly.

systemd's development is not centralized at all.

it's LGPL licensed and its developent happens on github at https://github.com/systemd/systemd -- anybody is free to fork it off to another project -- yet pretty much nobody does, how comes that?

That's the thing, I very frequently have to install applications that are not in the repo for any given distribution I'm using. Either this is because of the version I require, or the application is somewhat niche, or there's a special build, etc.

Usually my options in these cases are to adapt a package from another distro, or compile from source like it's still 1970. This is not a problem on other Desktop OSs because they never got into this pm/repo/distro model in the first place.

> Installing packages on your distro is very easy, either via a simple command like `apt install ` or via a graphical appstore-like interface to the same thing. All major distro package managers are very mature and reliable.

I have been using Linux for 20 years.

> Distributing software through those repos as a developer is not very easy, but it's not required either. If you want to distribute your app to all Linux distros without worrying about compatibility, and without requiring your customers to use the command line, you can use something like [App Image](https://appimage.org/), which is basically the same concept as [App Bundles](https://developer.apple.com/library/archive/documentation/Co...) on Macs.

Yeah, thanks, I'm aware. As a user that only works if someone bothered to make an AppImage, which many Linux developers don't bother to do.

> If you want something fancier, you could go with something like [Guix](https://guix.gnu.org/) or [Nix](https://nixos.org/explore.html) if your customers are developers or otherwise technical.

No thanks. I'd rather not have to learn an entirely new language just to do things like distribute and install applications.

> If you want to get less fancy, you could distribute your binaries with an install script that detects the current distro/version and downloads dependencies using the installed package manager.

Probably the worst option anyone has ever come up with. All the problems of package management plus all the problems of installers rolled into one.

> And if you're a user who just wants to download stuff on their computer, you just need to follow the instructions from the provider. It usually involves one of the methods above.

Usually those instructions consist of "install from your package manager" or "build it from source", see above.

Your post illustrates my point nicely: you guys don't even seem to think this is a problem.

You're welcome :)

> What do you think about Nix and Guix way of managing packages

I have not used either in adequate depth to make strong statements about them. That having been said, I find the idea so far as I understand it obviously desirable, and I would love to see more of the Linux ecosystem move in this direction. Where NixOS and GuixSD is the comparatively limited breadth and depth of packages. There was a point some years back where, upon recognizing the size and scope of Bedrock, I considered instead using the time to package what I find missing from NixOS. After serious investigation, I concluded both that this would be more work in total (Bedrock is, fundamentally, about leveraging work done by other distro maintainers so I don't have to do it [0]) and less interesting work (I find rote packaging tedious, but researching challenging problems enjoyable).

> is there a chance of incorporating similar features into Bedrock (like reproducible builds)

Given the fact a Bedrock system is mostly features from other distros, this would require making those other distros reproducible. Wrestling other distros into playing with each other is difficult enough; getting them to do that _and_ making other distros reproducible is beyond what is feasible with the resources I have at hand.

That having been said, I do take steps in that direction where feasible. Bedrock includes a Package Manager Manager utility, pmm, for cross-distro and multi-distro package management workflows. It supports interacting with a configuration file that lists which packages should be installed from which distros. Mine includes this representative but incomplete section:

    # desktop environment
    arch:pacman    gtk-engines # needed for gtk theme
    arch:pacman    terminus-font
    arch:yay       terminus-font-ttf # aur
    gentoo:portage x11-misc/dwmstatus
    gentoo:portage x11-misc/slock
    gentoo:portage x11-misc/dmenu
    gentoo:portage x11-wm/dwm
    debian:apt     dunst
    debian:apt     gcalcli

- I prefer Debian and its lack of churn by default.

- Gentoo makes maintaining things I compile myself very easy. I have patches for the items I am getting from Gentoo, which Gentoo dutifully applies on updates.

- My preferred font is Terminus, which is normally a bitmap font and inaccessible to TTF-only programs. Arch's Arch User Repository provides a TTF version.

- Bedrock does not make gtk2 engines, which are *.so shared library files, work cross-distro; this needs to be redundantly installed for each distro that provides gtk2 programs.

pmm will add or remove packages from the available package managers as needed to match the configuration file. I track this file with git and use it both to reproduce my system upon new Bedrock installs and to synchronize setup across my fleet. However, this is very limited compared to Nix and Guix. It cannot express, for example, the need to lock a given Arch Linux package to a given version, or to setup a third party repository before attempting to install packages from that repository. I am slowly working towards making more and more things reproducible from simple text configuration, but I do not expect to ever get all of the features Bedrock supports from all of the distros Bedrock supports to be as reproducible as something like NixOS or GuixSD.

It should probably also be noted that:

- I would eventually like Bedrock to interact nicely with NixOS and GuixSD. Ideally, this would allow at least those slices of the system to be reproducible. Users who value reproducibility could then continue to benefit from them where the available, but still have the option to get bits from non-reproducible distros when the trade-off is worthwhile.

- As far as I know, Nix and Guix as stand-alone package managers do work on Bedrock just as they do on other distros. The limitation above is for NixOS and GuixSD only.

[0] https://bedrocklinux.org/introduction.html#purpose