Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bedrock Linux – a meta Linux distribution

bedrocklinux.org

Post reply on HN
Print view View original

91–100 of 111 posts

Re: Bedrock Linux – a meta Linux distribution

#91

Post by ParadigmComplex »

swsieber wrote: post #75
soraminazuki wrote: post #74

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.

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

Re: Bedrock Linux – a meta Linux distribution

#92

Post by ParadigmComplex »

soraminazuki wrote: post #78
swsieber wrote: post #75

Earlier quoted context omitted.

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.

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.

Re: Bedrock Linux – a meta Linux distribution

#93

Post by ParadigmComplex »

myWindoonn wrote: post #88
ParadigmComplex wrote: post #67

Earlier quoted context omitted.

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

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.

Re: Bedrock Linux – a meta Linux distribution

#94

Post by akvadrako »

ParadigmComplex wrote: post #90
akvadrako wrote: post #32

Earlier quoted context omitted.

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

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.

Re: Bedrock Linux – a meta Linux distribution

#95

Post by ParadigmComplex »

akvadrako wrote: post #94
ParadigmComplex wrote: post #90

Earlier quoted context omitted.

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

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

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

Re: Bedrock Linux – a meta Linux distribution

#96

Post by superkuh »

staticassertion wrote: post #36
superkuh wrote: post #31

Earlier quoted context omitted.

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.

Re: Bedrock Linux – a meta Linux distribution

#97

Post by MuffinFlavored »

MuffinFlavored wrote: post #21
ChuckMcM wrote: post #5

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?

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.

Re: Bedrock Linux – a meta Linux distribution

#98

Post by akvadrako »

ParadigmComplex wrote: post #95
akvadrako wrote: post #94

Earlier quoted context omitted.

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

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

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

Re: Bedrock Linux – a meta Linux distribution

#99

Post by oblio »

yjftsjthsd-h wrote: post #72
oblio wrote: post #70

Earlier quoted context omitted.

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

Re: Bedrock Linux – a meta Linux distribution

#100

Post by swirepe »

theamk wrote: post #19

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

>schroot

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

Post reply on HN