What are /r/bedrocklinux's favorite Products & Services?

From 3.5 billion Reddit comments

First of all, you should probably not use yaourt; It has been unmaintained since quite a while. You may want to use a newer wrapper like yay.
And don't worry about yay/yaourt not recognizing bedrock, it really doesn't need to do that. They work just fine in their Arch strata on their own without doing anything special.
If you want to compile yay then just go ahead and do it, but don't forget to use "strat -r" for building software.

Also a little tip for experimenting with new stuff. If you're uncomfortable with doing something because it could negatively affect your system, why not copy the existing strata and try the change there first. If something goes wrong you can simply delete this strata and try again. One of the many lovely features of bedrock Linux.

ls logs: https://hastebin.com/simulobuqa.shell

I'll try keeping that debug setting on for a little while and see if it happens again (if it doesn't bog down my system). It was a seemingly random occurrence so who knows.

Arch recently updated its package format compression from xz to zstd: https://www.archlinux.org/news/required-update-to-recent-libarchive/

At the time of writing, brl fetch isn't aware of this and tries incorrectly to decompress all Arch packages with xz. I have a local fix ready and will push an update in the near future. Probably tomorrow, absent some surprise.

If you can't wait for the update, open up /bedrock/libexec/brl-fetch and change these lines:

unxz <"${file}" | tar -xf - -C "${dir}" echo "X"

to

if echo "${file}" | grep "[.]xz"; then unxz <"${file}" | tar -xf - -C "${dir}" elif echo "${file}" | grep "[.]zst"; then /bedrock/libexec/zstd -d <"${file}" | tar -xf - -C "${dir}" else abort "Unrecognized file extension: ${file}" fi

I think cross compiling will work, It just needs some additional setup most likely. This void Linux post caught my eye yesterday. They suggested using qemu to cross compile some of their packages, basically using qemu-arm-static to run the build commands (without starting up a full vm). If regualr cross compiling doesn't work, you could try that as well.

Don't install the drivers on the client systems, they won't see the kernel. Compile the firmware into the kernel as per http://www.gentoo.org/doc/en/xorg-config.xml and then install the xf86-video-ati drivers on both the host system. The client xorgs should be able to see it through bindings.

I'm generally happy to help people with Bedrock issues, but I need much more information than you're providing here.

> The fast filtering doesn’t work for some reason

I know it fails in qemu due to a lack of ICMP support, but I've never heard of it failing elsewhere. Any chance you have some weird networking setup that blocks ICMP?

> and every mirror I’ve tried fails as it can’t find the extra.db file

> Edit: I waited for the slow mirror section to go through and it worked, however the mirror it selected was insanely slow. (15 KiB/s) :) going to try what your comment said, apparently in the morning when my 500 MB update installs

The idea that the automatic mirror detection doesn't come up with great results is sadly understandable, but I'm surprised you couldn't manually find a good one. You should be able to just feed any of the URLs from Arch's package mirror listhttps://www.archlinux.org/mirrorlist/all/) into brl fetch; I'd expect the majority to work (although those in different regions from you to be slow).

> Edit 2 electric boogaloo: got it installed and did what you said, but still doesn’t work.. I’m going to see what I can do to switch the kernel

What happened? "Didn't work" is extremely vague. "Still" makes it sound like you tried this before and had trouble then as well.

> Edit 3: definitely can’t figure out how to install the kernel, as I can’t get anything more than the initramfs file. No vmlinuz from arch, and can’t figure out how

How did you install Arch's kernel? What did you try? Did you select mkinitcpio or dracut?

> Say I converted Arch to Bedrock and installed an Ubuntu 19.04 stratum. How would I update that stratum to 20.20?

For most distros, one can just do the same thing one would do with the traditional distro. Off the top of my head for Ubuntu, I'd change the /etc/apt/sources.list release names then apt update && apt dist-upgrade. Although it's probably a good idea to read the distro's documentation.

That having been said, Bedrock also supports additional workflow options on top of just upgrading the distro as one would normally do:

• Clone the stratum then do the release upgrade. If anything goes wrong, you can trivially just go back to using the previous one until you figure it out.
• brl fetch or otherwise acquire a new copy of the distro that's already upgraded to the target release, then move functionality over. This is nice as there's very little down time; if you have a daemon running from the old release, you can keep it running right until the moment you kick off the new release's copy. If anything goes wrong, again, you still have the old one on disk ready to go.

Once you've confirmed the new release is what you want, you can remove the old release.

These are useful for any risk operation, not just release upgrades. I did the clone strategy for Arch's <code>usr</code> move years ago.

> And does it change at all if I used Ubuntu as the base stratum?

Bedrock doesn't have a concept of a "base" stratum other than the Bedrock stratum (which is where the name "Bedrock" comes from). You're certainly welcome to get most things from one stratum if you prefer, but from Bedrock's point of view that's an arbitrary choice. Bedrock "thinks" more about which stratum provides individual features - an init stratum, a kernel stratum, an Xorg stratum, etc. Any workflow specific to a feature provider would be along those lines than a "base" stratum.

brl fetch just grabs a minimal set of a given distro's files; enough for the package manager to bootstrap whatever else is desired. For Arch, it just grabs base.

From your description, my guess is the AUR items you grabbed both have a missing dependency specification. Presumably the people who made those packages didn't test it on such a minimal Arch install.

You can run:

$ sudo pacman -Fy

to update pacman's list of which packages provide which files, then run

$ pacman -Fo /usr/lib/libatk-bridge-2.0.so.0 usr/lib/libatk-bridge-2.0.so.0 is owned by extra/at-spi2-atk 2.34.0-1

to query for which package provides the library it looks like you're missing. In this case it appears to be at-spi2-atk. I expect if you install that package:

$ sudo pacman -S at-spi2-atk

the error message you described will disappear. Hopefully the programs will then work for you. However, you might get another message about a missing dependency if the AUR package maintainers missed other items as well. If so, just repeat the -Fo search and -S installation to remedy those problems as well.

If this ends up fixing your issue, it might be worth contacting the AUR maintainers and asking them to add the missing dependencies.

brl fetch just grabs a minimal set of a given distro's files; enough for the package manager to bootstrap whatever else is desired. For Arch, it just grabs base.

From your description, my guess is the AUR items you grabbed both have a missing dependency specification. Presumably the people who made those packages didn't test it on such a minimal Arch install.

You can run:

$ sudo pacman -Fy

to update pacman's list of which packages provide which files, then run

$ pacman -Fo /usr/lib/libatk-bridge-2.0.so.0 usr/lib/libatk-bridge-2.0.so.0 is owned by extra/at-spi2-atk 2.34.0-1

to query for which package provides the library it looks like you're missing. In this case it appears to be at-spi2-atk. I expect if you install that package:

$ sudo pacman -S at-spi2-atk

the error message you described will disappear. Hopefully the programs will then work for you. However, you might get another message about a missing dependency if the AUR package maintainers missed other items as well. If so, just repeat the -Fo search and -S installation to remedy those problems as well.

If this ends up fixing your issue, it might be worth contacting the AUR maintainers and asking them to add the missing dependencies.

Very cool to see Bedrock getting attention across multiple languages! Sadly my Spanish is very weak and I wasn't able to follow most of this, but it seemed like a nice tour of the notable features.

brl fetch normally uses ICMP to find a good mirror. However, it looks like you ran Bedrock in qemu, which doesn't support ICMP. brl fetch had to fall back to using a slower system to find a good mirror than it would otherwise have to, which is why it took so long. If you run it outside of a VM, or in other VM software which supports ICMP, it should find a mirror much faster. You can also manually find a Debian package mirror and either use brl fetch's -m flag to tell brl fetch which mirror to use or configure preferred mirrors in bedrock.conf.

The only thing Bedrock does which I can see that's likely to be relevant is its handling of /etc/resolv.conf. Different distros/networking stacks have different expectations around what the file contains and could break if they see the /etc/resolv.conf created by another distro/networking stack. Bedrock resolves this by deleting /etc/resolv.conf at boot with the expectation that the networking stack re-creates it per its preferences. Some don't automatically create it by default, and so additionally Bedrock also configures them to do so.

Try comparing /etc/resolv.conf from a working ExpressVPN connection setup (e.g. pre-hijack) to what you're seeing on Bedrock. Note the file contents (but don't necessarily share them here; some people consider that private). Additionally, note whether it's a normal file or if it's a symlink and, if it's a symlink, where it points (this information should be fine to share).

My naive expectation would be that, upon establishing a connection, ExpressVPN would overwrite /etc/resolv.conf with its own content. Maybe it's manipulating a file expecting /etc/resolv.conf to be a symlink to that file, but due to Bedrock's /etc/resolv.conf manipulation it's not pointing to the place ExpressVPN expects?

Ah ok, Strange that your hosting service would go down randomly like that.

If the site is all static content you could probably get away with hosting it all via github. Just saying, you could bring down your costs that way since hosting via github seems to be free.

https://pages.github.com/

Switching to cloudflare for DNS would decrease cost as well since they provide DNS hosting for free, migrating your domain name entirely to cloudflare would almost certainly decrease your domain renewal costs.

At that point you'd only be paying for domain renewals and your site would pretty much never go down.

While it's certainly subjective, I think "very hard" is a bit much, at least for the more experienced audiences. Grabbing a package from some website and installing it locally with your package manager, or adding new repos, or grabbing a tarball and untaring it and running it, or ./configure && make && sudo make install, are all reasonably doable for experienced users. Tedious, most definitely (especially with regards to maintaining the out-of-repo packages). Difficult for new users, sure.

Making it easier to create packages certainly wouldn't exacerbate the inter-distro compatibility issues Bedrock Linux is attacking, but I'm doubtful it'd help to a significant degree. Many proprietary/binary-only things for Linux target only a few distros not (only) because it's too much work to make packages for other distros, but also because it's too much work to QA the product on those platforms. Debian Stable doesn't fail to provide cutting-edge packages due to the work to create such packages - they have the packages already in Debian Sid - but due to the stability of the platform as a whole and the filesystem layout limitations. Arch doesn't fail to provide portage-esque customization because it's to hard to make portage packages, but because Arch strives to be simple and portage's options can be overwhelming.

An edge case, when I run pmm in eshell:

λ$ sudo pmm-install -Su * strat -r void xbps-install -Su sh: 1: strat: not found ERROR: void:xbps returned 127

Although running strat -r void xbps-install -Su in eshell directly works:

λ$ sudo strat -r void xbps-install -Su [*] Updating `https://alpha.de.repo.voidlinux.org/current/x86_64-repodata' ...

> the sudo password is requested right after pmm runs doas -u bedrock strat -r artix yay -Sy

yay is hard-coded to use sudo. This aspect has nothing to do with pmm or Bedrock.

Due to yay's... interesting privilege management, pmm has to do privilege changes of its own to support yay. Given a request to use yay, pmm can usually safely assume (1) the system has sudo installed (since it's a dependency of <code>yay</code>) and (2) the user is okay with sudo usage (since if he/she wasn't, he/she wouldn't request yay).

I know there is interest in adding <code>doas</code> support to <code>yay</code>, but it's not there yet. Given this, there was some investigation into generalizing pmm's handling of these things so things are ready on pmm's end once yay's doas support lands. However, it was found to be non-trivial and delayed until Naga, when pmm is likely to be substantially reworked anyways.

In principle both NixOS and Clear are fine with me. Both have their own repos, which checks off the first box, and if you are active in maintaining them the second is also resolved.

Bedrock has existing brl fetch clear support. However, Clear Linux seems to have a number of issues interacting with Bedrock discussed here, presumably both from a hijacked Clear Linux system and fetched. If you have the background to figure out and cleanly fix those I'd be delighted.

A number of people, including myself, made some failed attempts to get brl fetch nixos going. The nix folks provide a relatively portable stand-alone package manager that I think you can use bootstrap NixOS. They provide a script to install the portable package manager here. I attempted to port it to the brl fetch framework, translating things like curl to wget, then using the resulting system to bootstrap NixOS with something like nixos-install --root /target-root --no-root-passwd --no-bootloader. I think the issue I ran into was that NixOS builds software in a sandbox, and something about their sandbox software did not like the Bedrock environment. I ran out of time going down that avenue before I figured out the specifics. I'd love to see brl fetch nixos working, if you can figure it out. It's probably also worth experimenting with hijacking a NixOS install and ensuring that works, if you have the time and interest.

> If you're asking about how the backend would work, I have no idea; it was just a random thought. If you're asking for examples from the user's perspective, then strat -something void ls /etc/pacman.d should work from an Arch shell, or perhaps strat -something arch void ls /etc/pacman.d.

• If I just look at system calls, there's no way to figure out which is supposed to be redirected to Arch and which are supposed to be redirected to Void.
• Pre-parsing the parameters works in absolutely trivial cases but falls apart in anything more complicated.
• I don't see how this is meaningfully advantageous over the existing system of strat void ls /bedrock/strata/arch/etc/pacman.d.

If the issue here is that /bedrock/strata/<stratum> is too much typing, there are ways you can shorten it. For example, if you're running zsh, you can throw something like this into your .zshrc:

for stratum in $(brl list -aA) do hash -d "${stratum}"="/bedrock/strata/${stratum}" done

which will then let you run things like strat void ls ~arch/etc/pacman.d, including tab completion.

> Anyway, going back on topic, the biggest obstacle for NixOS now is probably bootstrapping it from brl-bootstrap; the installation script seems to be horribly written and requires curl

Looking at https://nixos.org/nix/install it doesn't seem like they really need specifically curl rather than the also common wget. We could try to upstream a patch to have it conditionally use either curl or wget. They already support a conditional dependency on different tools to verify sha256.

Bedrock works by translating files that wouldn't normally work across distro boundaries so that they do work with other distros. This translation adds some overhead when accessing certain classes of files. Most of the time this is not noticeable, but it can be if some programs reads those files excessively.

Application launchers like dmenu and rofi read the list of available programs across all the distros Bedrock is making available. Depending on they're implemented, they can run into this translation overhead for every single application they're presenting as an option, which adds up.

One solution to this is for the application launchers to cache the list built. dmenu_run normally does this kind of caching, and in my experience it has no noticeable overhead on Bedrock vs off.

Poking around, it looks rofi added an optional cache. If you can figure out how to enable that, it might resolve performance concerns there for you.

I don't know why a terminal would be noticeably slower.

neofetch is a program which shows a brief overview of your system. It's popular on, for example, /r/unixporn.

Usually it just shows one distro and one system package manager. On Arch Linux, for example, it'll show the Arch logo and pacman packages.

This shows multiple distros being detected on the same system, which is not something one normally sees outside of Bedrock.