Live data from Hacker News

Bedrock Linux – a meta Linux distribution

bedrocklinux.org

71–80 of 111 posts

Re: Bedrock Linux – a meta Linux distribution

#71
post #64

Earlier quoted context omitted.

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.

Re: Bedrock Linux – a meta Linux distribution

#72
post #70

Earlier quoted context omitted.

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.

Re: Bedrock Linux – a meta Linux distribution

#73

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

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) ?

Re: Bedrock Linux – a meta Linux distribution

#74
post #2

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…

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.

Re: Bedrock Linux – a meta Linux distribution

#75
post #2

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…

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.

Re: Bedrock Linux – a meta Linux distribution

#76

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

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.

Re: Bedrock Linux – a meta Linux distribution

#77

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

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?

Re: Bedrock Linux – a meta Linux distribution

#78

Earlier quoted context omitted.

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.

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

Re: Bedrock Linux – a meta Linux distribution

#79
post #52

Earlier quoted context omitted.

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 ub…

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.

Re: Bedrock Linux – a meta Linux distribution

#80
post #20

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.

Post reply on HN