| HN Mirror

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