Bedrock Linux – a meta Linux distribution | Hacker News Reader

Bedrock Linux – a meta Linux distribution

bedrocklinux.org

203 pointsrhencke105 comments

Reminder about alternatives:

For the less extreme case, when you want mostly one distro, but also a few packages from another one, there is “alien” [0] which converts between different package formats. It sometimes needs help with system integration or dependencies, but occasionally “just works”

For a more extreme case, there is a schroot (or a docker container) with /home, audio and X mapped in. Works surprisingly well for desktop apps, like those embedded IDEs which require a specific Linux distribution you don’t want to run. You do have manage desktop integration (menu items, file associations) yourself though.

Those solutions are hard to set up than bedrock, but they also do not have special filesystem magic, so I bet they are much easier to debug.

[0] https://manpages.debian.org/unstable/alien/alien.1p.en.html

Another solid alternative is to install the nix package manager[0] and get access to thousands of packages.

I have stopped installing stuff from apt and thankfully my system never breaks now.

[0] https://github.com/NixOS/nixpkgs

I don't understand. I am sure the nix repository is quite large, as are Debian's and Fedora's ones. But how would nix help you mixing packages from different repositories, which is Bedrock Linux use case?

you (rightfully) don't understand because nix doesn't really fit in this discussion. actually, i'd say that nix is off-topic here.

nix is a package manager, that is going to install packages in its own way.

the discussion here is about bedrock linux, that answers a specific question: what if, for any reason, you need packages from two (or more?) specific, very different distros?

what if you need packages from BOTH ubuntu and rhel?

to that question, the answer is not "install nix".

which is really bad because i see the value in nix, it's a very nice system, but nix fanboys are getting really annoying with mentioning nix in any discussion where package management is even tangentially related. it kinda reminds me of that old video about mongodb being webscale.

It solves a specific instance of the problem of needing packages from two distros, which is a common instance of that problem: wanting a stable base set of packages on your system with the ability to use some newer, up to date ones.

Nix is highly relevant because it solves that case: you can run Nix on any stable distribution like Debian, and the Nix package repository contains a very large amount of mostly up-to-date software, similar to the Arch+AUR repositories.

Another problem it solves more generally is getting access to a large repository of maintained packages from a base system that only has a small repository, even if those packages are up-to-date.

Both of these are reasons you might use Bedrock, so it doesn't seem off-topic.

The only reason you would want packages from different distro's is if they have a different version.

With nix you can install packages with different versions, you can also install old packages by going back in nixpkgs history and building the package.

Nix being source based means you can install any software package as long as you have access to it's source.

Ofcourse some of this is possible with other systems too but the nix ecosystem makes it far easier to build packages in different languages.

In short nix can treat the disease (missing different versions of packages in distros) instead of treating the symptoms (installing packages from different distros)

You can install nix on top of any Linux distribution.

have been running debian sid on all my dev machines since ~7 years and not once had an issue. sure sometimes you need to diff a config file during a dist-upgrade but nothing every broke. ymmv. all my WM/DE sway/i3 gui stuff is self-compiled and so I get to see issues, dependencies and problems at compile time on my machine which I report upstream. It forces me in some rare cases dig until I understand and solve the problem. On the upside I know my tools really well down to every log entry that should or should not be there. Solving things becomes muscle memory (works better with a minimalist approach similar to the suckless philosophy). There is also a performance benefit of getting to use better CFLAGS such as `-mtune=native -march=native` or other hardening not available with packages. Once a day there is a cronjob polling git status for changes of relevant packages so I won't run out of date critically unpatched code. (oh and the great thing is by doing this often you also can follow the patches/diffs and quickly understand what is happening)

being lazy I've never considered the NixOS packing. it's a steep learning curve and also "old dog, new tricks". I'm sure it's awesome to use professionally but unless I see a commercial reason to use and apply it on the job, I won't bother (not because of lazy but because of many other competing things I want to do).

I also like junest, which gives a archlinux userspace very easily on any other Linux. Pretty useful when you want the latest GCC, clang, etc.. but don't have an hour to loose to find the right configure flags.

Or just like on mine case - built from source.

Most of time it's 5 commands tar -xf code.tar.gz && cd blah && ./configure && make -j5 && sudo make install

> For a more extreme case, there is a schroot (or a docker container) with /home, audio and X mapped in. Works surprisingly well for desktop apps, like those embedded IDEs which require a specific Linux distribution you don’t want to run. You do have manage desktop integration (menu items, file associations) yourself though.

Very early Bedrock Linux prototypes were exactly this; including the choice of schroot. Bedrock could be correctly described as taking this idea and running with it, trying to stomp out as many of the "you do have to"'s and "except"'s as it can.

> Those solutions are hard to set up than bedrock, but they also do not have special filesystem magic,

I think a fair description of the trade-off between Bedrock and the two alternatives you've laid out should mention the breadth of functionality Bedrock offers they do not. This includes but is not limited to:

- Shell tab completion. For example, Debian's zsh can tab-complete Arch Linux's pacman

- Init systems. For example, one could run Void Linux's runit init, install Arch Linux's systemd, and reboot into systemd.

- Kernels. One could run Arch's kernel, install Debian's, update the bootloader configuration, reboot, and select Debian's kernel.

et al.

I expect, if you think about it long enough, you could see some ways schroot with things like /home mapped in could be extended to cover those use cases. If you pursue those, you'd end up recreating Bedrock.

> so I bet they are much easier to debug.

I am doubtful any user which understands setup schroot you described, who also takes the time to familiarize himself or herself with Bedrock, would have comparative difficult debugging a Bedrock system.

This mix and match of assumptions seems like a security nightmare.

My understanding of Bedrock Linux's security concerns are addressed in this FAQ entry [0]. In the decade or so I've been working on Bedrock, I have yet to come across any situations where the differing assumptions between distros results in a security issue. Historically, every time assumptions differed in a way Bedrock did not handle, this resulted in things locking down rather than opening up. For a concrete recent example, Void Linux's build of OpenDoas updated recently [1], which resulted in removing Bedrock entries from the $PATH.

The primary concern I personally hold is in Bedrock's code to bootstrap parts of other distros, which does not currently verify the initial set of files used. I am hoping to address this with Bedrock's next major release (0.8.X) [2].

When Bedrock is far enough along that the architecture/code churn slows, I plan to seriously investigate the possibility of independent security reviews. For the time being, if someone claims heightened security needs, I usually redirect them to Qubes OS [3].

[0] https://bedrocklinux.org/faq.html#security. [1] https://github.com/Duncaen/OpenDoas/releases/tag/v6.8.1 [2] https://github.com/bedrocklinux/bedrocklinux-userland/issues... [3] https://www.qubes-os.org/

Awesome, thanks for the detailed reply!

You are very welcome

Alien just repackages files and doesn't keep important metadata like package dependencies, so it likely won't work at all in most cases.

From my experience alien is not reliable

I prefer Qubes OS, where you run various distributions in VMs. It has a great UI hiding the complexity, still allowing full access to everything.

>schroot

I learned something new. I only knew about chroot. If I'm understanding, schroot is chroot for normal users?

Without something to constrain where it is used, chroot can be theoretically abused as part of an attack. Thus, by default chroot requires root permissions. Part of what schroot does is indeed allow root to approve a list of known-safe locations for a unprivileged users to chroot to. It can do much more, including automate setting up the chroot environment prior to a given user's entry. A more minimal solution that just lets unprivileged users chroot to a given list of directories is capchroot, written by an Arch Linux developer. It used to be hosted here [0] but does not appear to be any longer.

[0] https://dev.archlinux.org/~thomas/capchroot/

I'm the Bedrock Linux founder and lead developer. I'm happy to answer any questions.

You mentioned both Arch and AUR in the target user part, which makes me wonder if you were mainly a Arch user before, and what triggers you do start this project.

As an satisfied Arch user, I always find AUR has already included something I need. Better, sometimes I just found them already in community repo.

> You mentioned both Arch and AUR in the target user part, which makes me wonder if you were mainly a Arch user before,

Before Bedrock Linux I was mainly a Debian user.

I did briefly run Arch Linux before working on Bedrock, but I found the churn bothersome. While I was running Arch, it updated AwesomeWM from 2.X to 3.X, which changed AwesomeWM configuration formats and functionally broke on my system. Arguably, this wasn't a mistake on the part of Arch Linux developers; the expectation is that the user reads about updates before applying them. Had I done this diligence, I could have withheld the AwesomeWM update. However, I didn't feel like I was able to apply this diligence with the expected regularity.

Personally, I prefer Debian's pattern of only releasing security updates with any regularity, only making breaking changes every few years which can be applied when I have time to dedicate to understanding and handling them. Bedrock lets me get _most_ of my system from Debian, but still get newer packages from Arch or rare packages from the AUR when the trade-off of new-ness vs churn is worthwhile for me.

> and what triggers you do start this project.

I didn't actually set out with the goal to combine distros. Rather, initially (circa 2008) I worked on a sandbox technology. My aim was to fluidly transition resources between security contexts, minimizing user friction while maintaining permissions segregation. I realized only afterward that the technology I developed could be used to fluidly combine features from different distros. Once it occurred to me I could do this, I started seeing use cases everywhere, and pivoted direction to what became Bedrock.

> As an satisfied Arch user, I always find AUR has already included something I need. Better, sometimes I just found them already in community repo.

In that case, I fully encourage you to stick with Arch rather than switch to Bedrock.

How did you get so based?

Either stubbornness or perseverance, depending on how charitable one is feeling.

Whatever it is, thanks!

Edit: and don't burn out.

I wish I could run bedrock linux like homebrew or nixpkgs - just as an alternative packaging system independent of my distro.

Is this possible ?

It depends on exactly what you mean. While you may not have intended it to be, this question is more philosophical than technical. Extended conversations I've had on this topic eventually drift toward subjects like the Ship of Theseus [0] and essential vs accidental properties [1]. For the sake of conversation, lets say your preferred distro is Fedora. If you replace Fedora's web browser with one from Arch, are you still running Fedora? What if you replace the kernel with one from another distro? And the init? Are you still running Fedora if you swap out every single file that is unique to Fedora?

Bedrock does not currently support being "uninstalled"; it has to be formatted over, like traditional distros. This is for two reasons: (1) I currently have no way of ensuring any one slice of the system is functionally complete such that removing the rest of the system would leave something bootable. (2) I don't want to advertise support for something active Bedrock users do not themselves regularly exercise, and by its very definition active Bedrock users won't uninstall Bedrock. In theory with enough effort Bedrock could be made uninstal-able, but I don't plan on investing effort there. If a user is interested in testing Bedrock out, I recommend using a VM or spare machine.

In every other workflow I can think of, Bedrock can functionally mimic being an alternative packaging system on top of whatever it supports. You can get most of your system - including the install process - from some distro, then use Bedrock to get features from other distros in a way that "feels" like it is "on top" of your original distro. Whether it is "on top" is a matter of semantics rather than practice.

With the next major release (0.8) I plan on supporting running Bedrock in something akin to a container. This would let users uninstall it and be less ambiguously "on top" of a traditional distro, but come at the expense of not integrating with the host environment.

[0] https://en.wikipedia.org/wiki/Ship_of_Theseus [1] https://plato.stanford.edu/entries/essential-accidental/

I mean something akin to a container but still integrated the way flatpak is; I don't want it to touch my base system, except for a few symlinks, being able to selectively expose directories to specific roots, allowing roots to call commands in other roots and things like exposing dbus endpoints.

I currently run a number of different chrooted installs of other distros using bubblewrap to selectively expose directories and flatpak-spawn in bash wrappers to run commands in other roots.

It works okay but I have looked at bedrock as a possible improvement, however I don't want to use it as my distro.

Bedrock Linux is a system to integrate things from different distros. The desire to use it while avoiding integration with a "base system" seems mutually exclusive to me. I think one of us is failing to model the other properly.

Can you elaborate on:

- Why your existing bubblewrap/flatpak-spawn/bash-wrapper works only okay, and why Bedrock might be a possible improvement? From where I'm sitting the limitation with the system you've described is that it does not integrate well with the rest of the system; however, you explicitly don't want it to.

- Why you don't want to use Bedrock Linux as your distro? On the one hand, this might just be a matter of definition; if you define Bedrock as something other than a distro, would it then meet your needs? It certainly isn't a distro in the traditional sense; Bedrock's documentation refers to it as a "meta distribution" for this reason [0]. On the other hand, if it's due to some concrete failing on Bedrock's part - it certainly isn't perfect - it's not clear to me how using as an alternative packaging system independent of your distro would alleviate that failing.

[0] https://bedrocklinux.org/faq.html#what-is-meta

> Why your existing bubblewrap/flatpak-spawn/bash-wrapper works only okay, and why Bedrock might be a possible improvement?

One thing is managing all the /bin links and taking care of all the directory mappings that are needed. Say env-A calls gcc which is installed in env-B: First, env-A needs a wrapper for all gcc packaged binaries - and those wrappers need to ensure the current directory stays the current directory, /bin and /lib become merges of env-A/env-B, etc. It gets hairy and I'm not sure what's even needed - I haven't done something this complex.

I think I read bedrock has fuse for managing links which seems like the level of complexity that's needed.

Also managing fonts is something I haven't looked at. And I'm sure there are more things.

- Why you don't want to use Bedrock Linux as your distro?

Because it makes things more complex. I expect things will break and reasoning about security will be more difficult.

My ideal setup is a base system which is fairly minimal, but handles boot, init and kernels for sure. And then isolated packages on top (docker, flatpak, nix, homebrew, distro-chroots) which do integrate with each other when needed.

I really do wish I could help, but I don't know how to reconcile what I'm reading as a mutually exclusive desire. If I'm interpreting you correctly, it sounds like you recognize what you're after requires complexity, and that Bedrock appears to be a potential solution because it offers the requisite level of complexity, but you don't want to use Bedrock because of its complexity. I don't think anything can be complex enough to meet your needs, while also not being complex enough to meet your needs.

> One thing is managing all the /bin links and taking care of all the directory mappings that are needed. Say env-A calls gcc which is installed in env-B: First, env-A needs a wrapper for all gcc packaged binaries - and those wrappers need to ensure the current directory stays the current directory, /bin and /lib become merges of env-A/env-B, etc. It gets hairy and I'm not sure what's even needed - I haven't done something this complex.

Early Bedrock releases, circa 0.1, had a utility that walked through the $PATH for binaries for each environment and generated wrapper scripts for binaries which cross the environment boundaries. It dumped these scripts in the $PATH after the environment's native binaries would be picked up, if they exist. While I don't remember if I ever did it, the re-running the utility could be automated with either package manager hooks or an inotify-based daemon. The main problem with this workflow was the time to wait for the utility to re-run whenever the collection of wrappers was problematically out of date. Things like having Arch's bash run `apt install htop && htop` wouldn't work due to the utility's runtime delay.

Code is generally easier to write than read. If your complexity concerns would be alleviated by having written something yourself - so that you know you understand it - you could try to mimic this approach.

> I think I read bedrock has fuse for managing links which seems like the level of complexity that's needed.

Yes, Bedrock has a FUSE filesystem which does the equivalent of generating the bash wrappers for binaries on-the-fly. It also handles translations needed for other resources; things like altering the `Exec=` lines in `.desktop` files for application menus. Other files it just forwards unchanged, like man pages. A long term goal is for it to support translating service manager configurations, so that one distro's init can run another's services without any manual intervention needed.

> My ideal setup is a base system which is fairly minimal, but handles boot, init and kernels for sure. And then isolated packages on top (docker, flatpak, nix, homebrew, distro-chroots) which do integrate with each other when needed.

While I don't intend to push you to Bedrock - I fully agree it's more complex than a traditional distro and at this point you've well established the fact you find that off-putting - this description does sound a lot like Bedrock to my ears. The only differences I see are (1) Bedrock's optional ability to let those "on top" "packages" provide the bootloader, init, and kernel and (2) the term "distro-chroots" instead of Bedrock's term "strata."

-----

When the next major release of Bedrock, 0.8, is released; you could certainly try out the official container-like solution for it and see if that meets your needs. This should be adequately segregated from the host environment while still internally integrated. Absent that, my suspicion is that you'd be happier having written your own solution here. This way you'd understand the capability-complexity trade offs and made exactly the balance you find best. You also wouldn't have to worry about the possibility there's some corner of the system you don't understand. It might not be as capable as Bedrock - I've got quite a head start on this - but it sounds like you don't need it to be.

Yeah I think I agree; though I haven't tried Bedrock, I have done a shallow evaluation.

The main thing I don't like is it requires being the main distro and I don't see why this is necessary. I don't think I'll like the container solution because I don't want (all other containers, ... | bedrock(X, Y, Z)), I want (flatpak-A, bedrock-X, ...). I want a bedrock-like package to be a top-level package.

I'm not against needed-complexity, I'm against the complexity being in the base OS. I should be able to have bedrock-like solutions alongside bedrock and not entwined with it.

Hi and thanks for reaching out to the community here.

As a poweruser. What are the benefits of this best of all worlds approach, and when might I need them?

I genuinely am curious and considering trying Bedrock out. I just can't see what workloads I need it for.

> Hi and thanks for reaching out to the community here.

You're welcome :)

> As a poweruser. What are the benefits of this best of all worlds approach, and when might I need them?

If you run into a situation where:

- The distro that best fits your use case is lacking some functionality you desire

- Other distros provide that functionality

- The alternatives proposed in this HN thread (compiling from source, alien, chroots/containers/etc, third-party package managers) are insufficient. Compiling from source (`./configure && make && sudo make install`) also means manually maintaining the package for things like security updates, which can be tedious; chroots/containers/etc don't integrate with the rest of the system very cleanly; third-party package managers have limited package coverage (compared to the breadth of the repos of the many distros Bedrock supports); etc

Bedrock might be a worthwhile solution. Some concrete real-world examples I've personally run into:

- I generally prefer "stable" distros like Debian or CentOS, in contrast to the churn cutting-edge rolling-release distros like Arch and Void are built around. However, when I get new hardware, I usually need a newer component from another distro, which I usually get from Arch or Void. When I purchased a new printer, I need a new cupsd; when I purchased an AMD Zen 2 CPU and was interested in temperature data, I needed a new kernel; etc.

- Of the major init systems maintained by a notable distro, I prefer Void Linux's runit. However, as previously mentioned, I prefer non-rolling workflows, which limits my interest in Void. Bedrock lets me easily get init related things from Void and get other things from Debian et al.

- Some years back I attended a LUG meeting which had lightning talks on X11 window managers. Newly purchased laptop in hand, I volunteered to present compiz. I found - with only minutes until my time slot - that Debian's Xorg stack was too old to work on the new laptop, but Arch's compiz was apparently broken. Had I run either Debian or Arch, I wouldn't have been able to present compiz during my time slot. Since I ran Bedrock, I simply installed Arch's Xorg stack and Debian's compiz.

- While developing Bedrock's 0.7.0 release, I found libfuse 3.0 switched from a make-based build system to meson. Debian's meson was too old ("Meson version is 0.37.1 but project requires >= 0.38."), and Arch's meson 0.44 was too new and included a bug [0] that kept it from sufficing for libfuse. Since I was running Bedrock, it was easy for me to find a goldilocks (0.42.1) version from Debian Testing.

- For both school and work, I've been required to run software which assumes a RHEL-like environment. These had things like `#!/bin/sh` scripts that use bash-isms, which don't work on distros like Debian that do not symlink /bin/sh to bash. Bedrock easily lets me run this software against CentOS/RHEL while still letting me easily get the rest of the system from other distros.

- I have personal patches against some packages, such as mupdf. Gentoo makes maintaining these packages with my patches trivial, as portage dutifully applies them when updating packages. However, I don't have the patience for Gentoo to compile the bulk of my system.

[0] https://github.com/mesonbuild/meson/issues/2761

> I genuinely am curious and considering trying Bedrock out. I just can't see what workloads I need it for.

My recommendation is to simply keep Bedrock in the back of your mind as a possible solution to issues you run into going forward. If you end up stumbling upon enough uses cases, consider it. If you don't, you might very well be better off with some other OS. Most distros exist as they do for good reason, and they suffice for most users. Bedrock targets a fairly niche audience.

If/when you do try it, I recommend trying it out in a VM or spare machine before using it in production, to make sure it does what you expect it to do.

What are the main downsides to using Bedrock?

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?

> What are the main downsides to using Bedrock?

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

Thanks for coming on here.

What do you think about Nix and Guix way of managing packages and is there a chance of incorporating similar features into Bedrock (like reproducible builds) ?

> Thanks for coming on here.

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

For a sense of why I get what from where:

- 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

If curious see also

2013 https://news.ycombinator.com/item?id=6504878 (big)

2012 https://news.ycombinator.com/item?id=4966445 (small)

I think they should just say "An easy way to get Linux without systemd" and they would drive a lot of adoption. :-)

What are the top 3 alternative ways to do GNU/Linux without systemd?

Genuinely curious, for both casual and advanced users, what *major* reasons are there for not using systemd?

I've used systemd for years bug-free

My POV: SystemD is a software driven not really by technical, but political reasons by RedHat, to put the most important parts of a GNU/Linux system under their control. (Appart from the kernel of course). It is modular, but also dependant as a whole, so in the end, it spreads almost like an invasion, slowly leaving the admins not other option than accepting it. That's quite off from the Unix philosophy (do one thing, do it well, be really modular)... so my conclusion going back to the beggining, that didn't happen by mistake, but is a deliberate design choice, with shaddy political reasons behind it, so I reject it. And then we could talk about the convenience or not of putting such amount of tools and complexity under PID 1, the crazy binary logs, the weird behavior of the service utilities, and the possibility of being able to modify/add services using regular scripts instead of binary excutables...

> My POV: SystemD is a software driven not really by technical, but political reasons by RedHat, to put the most important parts of a GNU/Linux system under their control.

it's really a dumb POV to have, given that systemd is FOSS (licensed LGPLv2.1+) like most of the software that red hat produces.

as a sysadmin, systemd is a godsend. really, it brings uniformity and waaay better debuggability/predictability and tooling in system startup and configuration and troubleshooting.

and, again, systemd is foss so red hat hasn't really that much control over other distros (and each distro had its own internal discussion and choose freely to adopt it).

on another side, red hat took the time and spent the money to bring that improvement to the world. other people just complain under the shield of a throwaway hn account.

I think people's beef with it is that it's hard to understand when things go wrong, Lennart's projects don't leave the best initial impression, and it's had significant scope creep since it was initially introduced.

well in fairness systemd's task (managing the system) is fairly complex as well.

I am not surprised I had to actually sit down and go through a short course on systemd and read some of the manpages to understand it enough and profit off its presence.

And that's the rub - it was initially advertised as a quick way to start the system, which is a simple enough concept to understand, then changed its scope to manage the entire system/service land.

It also ended up being tightly coupled, with poorly documented APIs and major bugs, which drew the ire of some longer-term professionals.

I don't think the idea systemd shim layer of services is necessarily bad, but I do think that having its design and implementation centralized within Red Hat isn't the best ; it would be nice if there was a complement to the Linux foundation doing its development, as having the process be managed by someone as competent as respected as Linus would go a long way into quieting the storm around it.

> but I do think that having its design and implementation centralized within Red Hat

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?

PS. I was expecting the kind of answers I received... as the whole subject stinks, talking about it stinks even more. What I wasn't waiting is to see people, in another time caring and loving this OS quietly yielding about such a big insanity. Thinking right now specially about Debian and ArchLinux mantainers.

It's fine when it works, but it's very hard to solve problems when they happen as it's so complex, and doing stuff outside of "the standard thing" can be difficult.

I once had "systemctl restart unbound" reset my volume, consistently. How do you even start debugging something like that without a deep dive in systemd? This particular issue turned out to be a systemd bug, and that such a bug can exist in the first place didn't exactly increase my confidence in the system.

In another case I couldn't get my NFS to work at all, and it turned out that rpcbind.service somehow went missing. Not sure how that happened and it's a simple enough problem, but it was really non-obvious because systemd doesn't issue clear errors on this and the system is so complex it's not easy to spot either.

> I once had "systemctl restart unbound" reset my volume

That's fascinating, do you have more information on this particular bug?

Bug report and commit that fixed it:

https://bugs.freedesktop.org/show_bug.cgi?id=88401

https://cgit.freedesktop.org/systemd/systemd/commit/?id=6e39...

You should know that this is a religious topic like vim vs emacs, but worse: vim and emacs users don't feel that the other side is a threat to allowing them to continue using the software they prefer.

Also kind of like religious syncretism, bridging the emac vs vim divide, there is evil mode.

Something I can't accept is the use of binary logs and the requirement for programs to access the contents of the logs.

Yes, most distros will put compatibility layers in place and create text "logs" in parallel. But if everyone is doing that maybe systemd's paradigm isn't right for the desktop even if it's great for servers.

Binary logs sound like a good thing to me since in most cases I want to just ship them off, and if I don't, a local consumer that can parse is just fine.

Is there something I'm missing?

Yes. The ability to use the giant ecosystem of text processing and piping infrastructure that underlies the entire idea of the unix philosophy. That something besides eyes is required to parse the logs is absurd and unacceptable. And no one on desktop is shipping off logs to somewhere else. That's cargo cult behavior.

How do you "ship off" .journal files? Whenever I do it either the timestamps are off or you can't read the file at all. I resort to `journalctl xyz.journal > xyz.log` and send the resulting text file to outside the system.

It isn't right for server either. I want my server logs to be files in filesystem and readable with standard tools.

> what major reasons are there for not using systemd?

    ps aux | wc -l

I don't get it.

Probably too many useless systemd-related processes.

I imagine that the respective user wouldn't want to see the number of background processes for all the other modern OSes, in this case :-)

Alpine Linux boots with a fairly clean process table.

Of course, this is the internet... Someone is going to point out exceptions.

I was talking about Windows, MacOS, Android, iOS, all mainstream Linux distros.

What you did was like seeing someone talk about family cars and interjecting: yeah, but they're slower than my motorbike. It's not the same thing, is it?

You said

> all the other modern OSes

Alpine is a modern OS; I've been quite happy running on my desktop. I would argue that you're moving the goalposts because I pointed out an example that disagrees with you.

https://tirania.org/blog/archive/2011/Feb-17.html

Void Linux uses its own init system and it's pretty nice and familiar. The distribution has gotten a lot better over the years.

https://voidlinux.org

The most common for me are Void, Alpine, and Artix.

For most people you could probably sub Devuan for Artix though.

I tried Gentoo and Artix, both being a very good experience. Some minor issues with laptop suspension and lightdm session handling in Artix tho. Flawless behavior with Gentoo, pity that an update broke my system a while ago.

Slackware.

I was going to mention the debian distro. I've got a 'cleanse' script that has grown over time for Ubuntu installs that I first install stock Ubuntu, then cleanse it of snap, systemd, modem-manager, and a couple of other things. And then add the packages that I like. But every release it gets more onerous to do this.

You can also try Artix(arch minus systemd).

answering my own question:

> Devuan is a fork of Debian that uses sysvinit or OpenRC instead of systemd.

> Void uses the runit(8) supervision suite to run system services and daemons.

> Alpine Linux uses OpenRC for its init system.

https://www.devuan.org/

I think those of us who don’t use Linux as a daily driver forget how completely incompatible different distros are. I made the mistake of trying to provision Amazon Linux desktops to users via Workspaces, and quickly realised I was going to need to build almost everything I wanted from source.

Even those of us who do use Linux as a daily driver can forget sometimes ;) I spend my days in Arch and occasionally interact with Debian-based servers but never have to consider the cross-compatibility (or otherwise) of other distros.

Yeah, as someone who theoretically would love to be using an open OS and has been waiting for Linux Desktop to become a tolerable experience for about 20 years now, application installation is by far my biggest gripe with it and it not only remains a huge problem in 2021, it remains a problem the community doesn't even seem to want to fix.

What do you find problematic about app installation on Linux? The poster you replied to was talking about mixing packages from different distros, not about installing apps in general.

Installing packages on your distro is very easy, either via a simple command like `apt install <package>` 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.

> What do you find problematic about app installation on Linux? The poster you replied to was talking about mixing packages from different distros, not about installing apps in general.

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 <package>` 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.

>> 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.

Common misunderstanding, but you don't need to know Guile or the Nix language to use either of these systems.

"guix install foo", "guix pack -f docker bar", etc.

Guix also has package transformation options ("build with this patch", "build with these sources instead", "replace foo with bar in the package graph") that are exposed to the command line and also don't require you learn any Scheme.

How can this possibly work with incompatable libraries?

It says that Bedrock provides the glue to make it work, but it does not come with specifics on how it has solved what seems to be a rather hard problem to solve.

Judging by their "How does Bedrock Linux Work?" section[0], exactly how they fix this hard problem is via an ever-evolving plethora of specific per-system fixes, which they're trying to stabilise enough to document before their 1.0 release, but is likely to continue changing as needs arise. Sounds challenging.

[0] https://bedrocklinux.org/faq.html#how-work

It is like overlay of many chroots / containers with some logic to preset unified view of all installed apps and to transparently switch between them.

So for example typing “mplayer” runs it in Ubuntu container, and typing “vlc” runs it in Arch container. And each container has is own libraries.

Pretty cool, but requires many rules about shared / unshared dirs. Like, home is shared but fontcache isn’t... Their release page has a long list of compatible subsystems.

I have never used bedrock linux in anger, but it fascinates me. I'm glad it finally made it to the front page.

Edit: I've been fiddling with NixOS and reading up on pros/cons vs scripting everything and having a good repo with all the necessary stuff. It seems like Bedrock could provide a good foundation for making it safe and easy to rollback with said scripts, or maybe even divide the scrip up into pre Bedrock and post bedrock with easy rollback capabilities.

>I have never used bedrock linux in anger,

But you have used it in joy? Or what does this mean?

And as for rollback capabilities, wouldn't snapshots just work far easier than any of your other ideas? Not only can you easily rollback, everything about the failure is still accessible.

It comes from the expression "fired in anger," which meant using a weapon in the heat of battle, i.e., that the weapon was battle tested.

I’ve seen people (entirely in computing contexts) say “used in anger” but never knew the derivation.

See eg https://en.m.wiktionary.org/wiki/fire_in_anger#Verb

Ahh, I thought they harbored some ill will towards the project. Thanks.

Rollbacks are only going to work reliably if packages are immutable, isolated, and its dependencies deterministic. I don't see Bedrock Linux as a particularly better target for supporting rollbacks compared to other distros as it doesn't satisfy any of those properties.

Not saying that it's a bad thing, but it just doesn't seem what Bedrock Linux is designed to be good at.

Ah, when I say rollbacks, I mean when you go to upgrade, you duplicate the strata (OS install), and the do everything in the new strata. Then if anything went wrong, delete the new strata and switch back to the one you branched from.

Bedrock does support exactly this workflow. I do something along these lines, with the nuanced difference that I have a period of overlap where I'm using both the old and new strata around at once.

When a new major release of a non-rolling distro (e.g. Debian) is out, I make a new stratum for the corresponding release. I slowly migrate things over, a few packages at a time. If anything doesn't just-work with the new release, I can easily revert to getting the given functionality from the old one until I've made the necessary adjustments. Once I have everything working confidently with the new release, I can remove the old one.

Bedrock offers a configuration file that declares which packages should come from which stratum [0]. A section of it might look something like this:

    # e-mail
    arch:pacman isync # mbsync
    buster:apt  msmtp
    buster:apt  mutt
    buster:apt  urlview

When Debian 11 Bullseye is released, I can `s/buster/bullseye/`:

    # e-mail
    arch:pacman isync # mbsync
    bullseye:apt  msmtp
    bullseye:apt  mutt
    bullseye:apt  urlview

then try out my e-mail setup. If it works, I'm good; if not, I can revert. Once I have it working, I can move on to the next stanza in the described configuration file.

That having been said, I don't think this compares favorably to NixOS's much stronger rollback system here. It's a nice bonus for people who otherwise are interested in Bedrock.

[0] https://bedrocklinux.org/0.7/commands.html#pmm-world-file

You are describing one of the main reasons people use CoW filesystem's like ZFS. Snapshots make this a trivial thing you can do hundreds of times per day if for some reason you needed to.

In that case, I wonder how much effort does Bedrock Linux put into isolating runtime state from individual stratas.

I'm likely equipped to answer your question if you elaborate a bit on what you mean by runtime state. Could you provide concrete examples of things you are curious about?

The general pattern, in case it covers what you are looking for:

- By default, files/filepaths are isolated, similar to chroots/containers. Features the Bedrock Linux development team haven't taken time to work on yet usually work as they would in their native distro, but are not integrated with the rest of the system. This notably includes most things that package managers touch to keep them from fighting each other.

- Bedrock actively integrates a supported list of files/filepaths which are needed to ensure features from different distros interact transparently. The specifics here vary depending on the given feature. Over time, the Bedrock team expands the list of files/filepaths that do something to integrate across strata as solutions are found to do so without introducing conflicts.

- Bedrock purposefully eschews isolating things like processes and network namespaces. Running `htop` shows all processes from all distros. In the worst case scenario, the user can only get the given feature from one distro at a time. The most notable example here is systemd, which requires being run as PID 1; the lack of PID namespacing means a Bedrock system only has one PID 1 at a time. Switching between different distro inits usually requires a reboot.

- A stratum can be "disabled," which both kills all of the associated process and removes the runtime integration with other strata. Once this is done, it can be copied (backed up) or removed safely. The stratum providing PID 1 cannot be disabled, as Linux is not designed to run without a PID 1; to remove the PID 1-providing stratum, a user must first reboot and select another init. The `bedrock` stratum cannot be disabled, mostly because the Bedrock developers didn't put time and effort into supporting that workflow.

I was referring to files created by various software at runtime, usually in /var. I'm assuming that rollbacks for a package management system would want to only roll back package-provided files and have the rest left alone.

Ah, I now see what you mean. With the exceptions of /var/lib/dbus/machine-id and /var/run, which need to be shared for certain bits of software to communicate properly, /var is currently isolated by default. If a website is hosted at /var/www or e-mail contents stored at /var/spool/mail, a naive implementation of the rollback system swsieber described would roll back the website and e-mail as well. Bedrock can be easily configured to make such directories shared across the system and exempted from such a rollback system; hopefully any user who attempts such a workflow would catch this issue and change Bedrock configuration accordingly. I should probably investigate making such configuration default.

It's pretty cool that this can host other distros, but is that the only advantage over NixOS? I don't know if I would enjoy crossing distro boundaries constantly just for a small handful of desired packages, and I'm not sure what other use cases this might have.

Does anybody have experience deploying Bedrock in production? What are some pros and cons?

> It's pretty cool that this can host other distros, but is that the only advantage over NixOS?

The ability to transparently get features from other distros is Bedrock Linux's defining characteristic. It's not trying to do anything more than that.

Ideally the contrast wouldn't be Bedrock _or_ NixOS, but rather NixOS alone or Bedrock with NixOS. Bedrock's goal of getting features from other distros includes distros like NixOS. Sadly, there's still R&D work to be done there: while Bedrock supports a large number of distros, NixOS isn't yet one of them.

> I don't know if I would enjoy crossing distro boundaries constantly just for a small handful of desired packages, and I'm not sure what other use cases this might have.

I think trying to find use cases other than getting features from multiple distros is driving you in the wrong direction for modelling Bedrock. Most Linux users - quite likely including yourself - are happy with what one distro provides them. Others, however, find it limiting. Bedrock targets the latter group. Try thinking of scenarios where a user has competing pressures for different distros:

- A user may require RHEL for work, but miss the large package selection offered by Debian.

- A user may like Void Linux's init, but miss Arch's AUR.

- A user may like Gentoo's ability to customize packages, but only want to compile about half the system.

> Does anybody have experience deploying Bedrock in production? What are some pros and cons?

You might be looking for these FAQ entries [0] [1].

[0] https://bedrocklinux.org/faq.html#why-use-bedrock [1] https://bedrocklinux.org/faq.html#why-not-use-bedrock

Sure. But if the choice is NixOS alone or NixOS hosted by Bedrock, then NixOS has a pile of advantages which Bedrock would nullify, chief among them being the ability to atomically upgrade and rollback the entire userland, service configuration, and kernel. These are non-trivial goals of NixOS.

It is not clear to me why you feel this way. Everyone I've spoken with who has put effort toward making Bedrock play nicely NixOS has done so with the aim of retaining that list of NixOS's strengths in the NixOS slice of the system. Let Bedrock proper fade to the background: for a user who is NixOS-oriented, such a system could be NixOS, with all of NixOS's strengths, with the ability to add or swap out (non-atomic upgrade/rollback) parts from other distros.

I feel this way chiefly because I actually do use the features of NixOS to atomically rollback entire machines in production, and to atomically upgrade my development workstation. Having to manage an additional piece which is beyond Nix, whether that's EFI configuration or virtualization or Bedrock, is acceptable but very irritating.

Apologies, I misinterpreted your concern to be a matter of losing the entirety of Nix's atomic features entirely rather than concern over even limited escapes from its Nix's scope. In this case it does sound like Bedrock's trade-offs won't be worthwhile for you even in the hypothetical future where it plays nicely with NixOS but retains the non-atomic nature of components from other distros.

I’m considering proposing this just to watch my security friends’ heads explode.

Reply on news.ycombinator.com