Live data from Hacker News

Bedrock Linux – a meta Linux distribution

bedrocklinux.org

101–110 of 111 posts

Re: Bedrock Linux – a meta Linux distribution

#101

Earlier quoted context omitted.

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

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.

Re: Bedrock Linux – a meta Linux distribution

#102

Earlier quoted context omitted.

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

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…

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.

Re: Bedrock Linux – a meta Linux distribution

#103
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?

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/

Re: Bedrock Linux – a meta Linux distribution

#104

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.

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.

Re: Bedrock Linux – a meta Linux distribution

#105
post #51
post #47

Earlier quoted context omitted.

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

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

Re: Bedrock Linux – a meta Linux distribution

#106

Earlier quoted context omitted.

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

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.

Re: Bedrock Linux – a meta Linux distribution

#107
post #48

Earlier quoted context omitted.

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

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.

Re: Bedrock Linux – a meta Linux distribution

#108

Earlier quoted context omitted.

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…

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.

Re: Bedrock Linux – a meta Linux distribution

#109

Earlier quoted context omitted.

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

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.

Re: Bedrock Linux – a meta Linux distribution

#110
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…

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)

Post reply on HN