144 karma · joined August 5, 2012
The slow of progress to 0.8.0 is in part because, after 0.7.0's release, the user support load has been very high, because the project community is quite active.
New-feature development is slow, but the project is very much not dead.
In the few months since my comment you've linked, I've put some work into a possible FUSE-less Bedrock implementation. It will likely have some downsides compared to a FUSE-based solution, but the trade-off may be worthwhile for some users. While it's too early to commit to this, I'm hoping to eventually support switching between a FUSE-mode and a non-FUSE-mode with a reboot to allow users to pick the desired trade-off in the desired contexts.
[0] https://bugzilla.kernel.org/show_bug.cgi?id=34932 https://bugzilla.kernel.org/show_bug.cgi?id=198879 https://lists.debian.org/debian-kernel/2011/10/msg00412.html
[1] https://github.com/keybase/client/issues/12458 https://github.com/libfuse/libfuse/issues/248 https://bugs.launchpad.net/ubuntu/+source/sshfs-fuse/+bug/17...
- Ultimately this seems to trace back to a bug in the Linux kernel. Sadly, I don't see any reason to believe it's going to be resolved in the kernel any time soon.
- A potential medium-term fix is for Bedrock to offer the corresponding functionality via a kernel module, and to fall back to a FUSE implementation if the module is unavailable (e.g. if you reboot into a kernel that breaks compatibility with the module). The proper way to do this would be via dkms, but is thus blocked on cross-distro dkms functionality. This is a realistic route, but given limited project resources it's likely quite a ways away.
- The long-term fix is to upstream Bedrock's required functionality into the Linux kernel directly. The main issue here is that we don't know exactly what functionality Bedrock actually needs here; it's often changed quite a bit from release to release. Keeping it out of the kernel tree - and using dkms/FUSE - offers needed flexibility in Bedrock Linux's pre-1.0 period.
- blendOS appears to use a common host-container relationship, with automation to make things in containers transparently accessible in the host. Bedrock does not currently privilege a section of the system like this; everything is "equal." The Bedrock philosophy here is that privileging a section like this is limiting; it essentially defines a section of the system which must come from one distro rather than have the same flexibility as other sections of being able to come from any (supported) distro. The downside to Bedrock's flexibility is that has a higher ceiling on complexity.
- blendOS's documentation refers to getting "apps" from other distributions, where as Bedrock's aim is as much as it can do. My guess is Bedrock lets you integrate more types of things across distro boundaries. Bootloader, kernel, init, desktop environments, fonts, man pages, shell completion, etc. Like the previous bullet point, this can be a mixed bag and result in a higher ceiling on complexity.
- I do not see blendOS mentioning the ability to run systemd services from different distros. However, it seems to be built on distrobox, which does offer such a thing by leveraging systemd's ability to manage services in host-container relationships, and so my guess is blendOS can or easily could/will allow for such functionality. Bedrock does not currently offer this. Bedrock explicitly is not containers, and so it does not support multiple simultaneous init systems like this. Bedrock has an alternative on the roadmap, but it's a very long ways away.
I think a closer alternative to blendOS would be Vanilla OS [0]. Like blendOS, it has an immutable "base", although it is Ubuntu-based rather than Arch-based.
> 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.
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.
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.
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
# e-mail
arch:pacman isync # mbsync
bullseye:apt msmtp
bullseye:apt mutt
bullseye:apt urlview
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
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/
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.
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
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/
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.
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.
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.
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
I'm Bedrock's founder and lead developer. If you have any questions about it I'm happy to answer them.
Note: Main area it is lacking is the "just works without setup"; it does not compete with Ubuntu/Mint/etc on that front.
Full disclosure: I'm the founder and lead developer.
Rather, the idea is that you can install packages from just about any other distribution, including things which are typically seen as mutually exclusive. The majority of the system can be comprised of packages from something known to be stable like Debian or CentOS, while still having easy access to things like packages from Arch (including Arch's AUR), retain extremely good library compatibility with popular Ubuntu for precompiled non-distro-provided things like proprietary software, and still get to leverage the flexibility tools like Gentoo's portage provides.
So, yes, you could use binary packages unless you need to build from source - Bedrock Linux can fit that design if you want it to work that way. That's a perfectly fine way to use it. But I would frame that as one of a number of ways to go about things, as the system is quite flexible.