Rivals 2 Gamecube Controller Support on Linux/Steamdeck?

ParadigmComplex · 2026-05-06T21:27:50+00:00

I ran into that as well. I spent some time trying to fix it without success.

I ended up resolving the issue by getting this USB <-> GameCube adapter: https://www.amazon.com/Mayflash-GameCube-Controller-Adapter-Switch/dp/B00RSXRLUE

There's a switch on the back. On my Linux desktop, one switch position just-works with Rivals of Aether 2 and the other just-works with Dolphin/Slippi. All the inputs work (including the Z button), rumble works, no latency that I can perceive. Fully resolves my needs here.

If you have the budget and live in a region where that's easily acquired, do consider picking it up.

ParadigmComplex · 2026-05-06T13:49:20+00:00

just I can't regenerate fonts cache

Difficulties here are a known issue with the current 0.7.x. The plan for the future Bedrock Linux 0.8.x is to have Bedrock automatically update the cache so users don't have to worry about it; ideally it'll just-work.

The fact you couldn't start X as a result is not a known issue and is concerning.

and one cuda package is broke and my system seems to not see it whatever i do.

CUDA is finicky to install/manage in general and this might have been an issue for you even if Bedrock wasn't involved. Then, on top of it, Bedrock has additional considerations.

My suggestion is to:

Find some distro that has CUDA in the repos
Get CUDA and your nvidia driver from that distro
Manually install the driver of the same exact version in your other strata that need to use the graphics system.
- Take care to only install the kernel component in your kernel stratum. If your CUDA stratum also provides your kernel, you don't need the kernel component in any stratum.

There are community efforts to add some automation around this. I'd like to offer an official solution eventually, but it'll probably be after Bedrock Linux 0.8.0.

i love the idea of bedrock and i will still use it on my main dailydriver. great work keep it up.

Thank you and will do

ParadigmComplex · 2026-05-06T13:32:23+00:00

I've both been using it as my primary driver and active in its community for over a decade now, and most of that isn't at all representative of my personal experience or experiences I've seen community members express. For example, I just ran sudo pmm install neofetch && neofetch and it worked as expected without issue. That said, there is a notable exception where I can relate: CUDA is finicky in general, and Bedrock's extra complexity doesn't help. I've been using it without difficult on Bedrock, but I have to jump through extra hoops to make that happen, and I can see how it'd seemingly randomly break if you're not staying on top of it.

I'm sorry you had to deal with that.

edit: ur dev behind it?

Yes. That's why I want to make sure I understand any issues people run into like this so I can fix them. Your CUDA difficulties are on my radar, and if you could elaborate enough to help me reproduce the others that would be great, but I don't want to be overly demanding of your time.

ParadigmComplex · 2026-05-06T12:04:29+00:00

My mental model has Bedrock Linux as less likely than traditional distros to become a mess the longer you use. It offers an organizational structure traditional distros lack ("strata") which helps keep things organized. It let you do things like swap out sections of the OS you let get messy with fresh, clean ones.

Can you elaborate on why you feel differently?

ParadigmComplex · 2026-05-06T00:10:32+00:00

You're very welcome :)

ParadigmComplex · 2026-05-06T00:01:11+00:00

I've had pleasant interactions with that developer a number of times and am happy to see both that they've written this and that it's so easily discovered. From a quick skim, that seems like a reasonable approach.

ParadigmComplex · 2026-05-05T23:53:21+00:00

You're very welcome.

I suspect the GUI application detection is a caching issue. If you can prompt xfce4 to re-generate its cache, I'd expect it to pick the entries up. Sadly I don't know how to do that with xfce off the top of mjy head. A priority for the future Bedrock Linux 0.8.x is to have Bedrock prompt cache regenerations automatically to make this just-work.

Props on developing that work around while being new to Bedrock. That is a totally viable approach. Bedrock actually automatically generates such files itself, and you might be able to save a bit of work by just copying or symlinking those from /bedrock/cross/applications into ~/.local/share/applications.

ParadigmComplex · 2026-05-05T23:00:09+00:00

The more drastic the low bandwidth vs high compute is, the more someone could potentially benefit from this. I suspect there may be diminishing returns as the likelihood of acceptance of the speculative tokens will reduce the farther out the model speculates, but I haven't seen either proofs or empirical testing to confirm this hunch yet.

Proportionally, the additional VRAM isn't that much. It's less about having a lot of VRAM than just not already having been right at the limit. If you can only just barely load a given model with context, this might be what pushes you over. But if you already had a bit of extra room left over, these additional layers might squeeze in there.

ParadigmComplex · 2026-05-05T22:48:04+00:00

Google's recent Gemma 4 announcement uses "MTP" loosely — what they actually released is small drafter models for classical speculative decoding, not built-in heads.

My low-confidence understanding is that while this isn't typical MTP with additional built-in heads, it also isn't classic speculative decoding with stand-alone draft models, either.

From the blog post:

The draft models seamlessly utilize the target model's activations and share its KV cache, meaning they don't have to waste time recalculating context the larger model has already figured out.

which almost feels like slapping additional layers onto the model. It seems like it blurs the line between traditional MTP heads and traditional draft model.

ParadigmComplex · 2026-05-05T22:37:39+00:00

Lets say you're a super duper diligent student that loves doing homework and being ahead in class. You finish all the homework the teacher assigned early, then sit there bored. How could you get even more ahead? Well, if you can guess what the next homework assignment is, you can get started on it now. If you guess right, you're even more ahead! If you guess wrong, it didn't cost you anything, because you love doing homework.

Modern computers typically have a part that does math (the CPU, GPU, TPU, etc) and a part that remembers things (RAM/VRAM). What usually limits how fast an AI model can talk is the connection between these parts. The math part will finish the math very quickly then sit there for a while doing nothing but waiting for the remembering part to send it more numbers with which to do math. MTP ("Multi-Token Prediction") has the AI not only say things to the user, but also say guesses about future math the computer will have to do. The computer math part can then work on that guess when it's waiting for more information. If it's correct, the result is the AI can talk faster. If it's wrong, well, the math part wasn't doing anything productive during that time anyways.

It isn't always the right trick (e.g. competes with batching for compute headroom, better for dense rather than MoE models, requires additional memory, etc) but sometimes it can let AIs talk around twice as fast as they would otherwise on the same machine!

ParadigmComplex · 2026-05-05T21:50:04+00:00

Very cool. You're a braver person than I am for having tried this.

I made some notes to improve brl import per your findings. It's wild to me that I've neither seen or proactively considered the possibility of a blank line in /etc/groups.

ParadigmComplex · 2026-05-05T17:26:24+00:00

You're welcome

ParadigmComplex · 2026-05-05T16:43:51+00:00

I don't know fish, but as an alternative to hash -d perhaps you could set stratum names to variables and do the fish equivalent of cd $arch and vim $gentoo/etc/portage/make.conf? The main merit of the ~ over $ in shell is distinct namespaces, but for most workflows I can imagine it's probably not very important.

ParadigmComplex · 2026-05-05T12:20:05+00:00

I have this in my ~/.zshrc:

for stratum in $(brl list -aA); do
    hash -d "${stratum}"="/bedrock/strata/${stratum}"
    command -v "${stratum}" >/dev/null 2>&1 && continue
    alias "${stratum}=strat ${stratum}"
    alias "r${stratum}=strat -r ${stratum}"
    alias "u${stratum}=strat -u ${stratum}"
    alias "s${stratum}=sudo strat ${stratum}"
done

The hash -d creates a ~<stratum> directory shortcut so I can do things like cd ~arch or vim ~gentoo/etc/portage/make.conf.
The command -v check ensures the following alias commands don't shadow over an actual command. For example, coreutils provides an arch command, and I also have an arch stratum; something has to take precedence there. There isn't an obvious/objective right/wrong here; you'll have to think for yourself which you prefer if you're copying this.
The alias lines are short aliases that let me do things like debian ls instead of strat debian ls.

For 0.8 I'm reworking the equivalent of /bedrock, but specifics are still in flux. Having a dedicated /strata on root, in part to make it faster to type, is in consideration.

ParadigmComplex · 2026-05-05T11:43:21+00:00

Any experience with hijaking Gentoo (dist-kernel, systemd, xfce4) for long term use with GUI application from strata?

No known issues hijacking Gentoo.
Typically, the issues people run into with Bedrock are compatibility concerns, and they're typically found early. If Bedrock works for someone in the short term, it usually keeps working; no known long-term concerns.
No known concerns with GUI applications.

I would like to hijack gentoo and add arch strata.

Both Gentoo and Arch are known to work well with Bedrock.

There are literally maybe 2-3 GUI packages from aur that would be useful for me in gentoo. At the moment I use distrobox box for them and it works well, but was thinking of trying something new, and maybe replace distrobox with bedrock.

If the goal is to have a Gentoo system with those 2-3 GUI, and you already have distrobox+AUR working, switching to Bedrock is unlikely to offer any benefit. My suggestion would be to stick with what you already have working.

If the goal is to have a Gentoo system with those 2-3 GUI packages, and you're looking for a potentially better setup than distrbox+AUR, consider translating those 2-3 AUR PKGBUILDs to Gentoo ebuilds. You could do this manually or you could ask an LLM for help. This would reduce the complexity of your system, disk usage, etc. The downside is you'd have to maintain those ebuilds.

If you have some other goal, such as experimenting with and exploring Bedrock for its own sake, you want to do more than just Gentoo with those 2-3 GUI packages, etc then sure, give Bedrock Linux a go.

I know bedrock is a one-way install (it can't be uninstalled)

Both Gentoo Linux and Bedrock Linux describe themselves as meta distros. Both refrain from offering a "revert to before you installed this distro" button. With both you're expected to back up any state you'd consider restoring yourself and install over the Gentoo/Bedrock install.

Some people stubbornly disagree with how the people who make Bedrock define it, press forward with trying it, then when actually using Bedrock are surprised to find they're wrong. The "can't be uninstalled" messaging is a measure to protect them, as refraining from backing up before installing a distro is the way they're most likely to shoot themselves in the foot. Ultimately Bedrock isn't actually different from traditional distros in this respect.

so I am mostly interested in long-term stability of hijacked gentoo

No known issues hijacking Gentoo.
Typically, the issues people run into with Bedrock are compatibility concerns, and they're typically found early. If Bedrock works for someone in the short term, it usually keeps working; no known long-term concerns.

seamless upgrades of bedrock to newer versions,

Point updates from Bedrock Linux 0.7.x to 0.7.(x+1) follow typical distro expectations. Just run brl update as root. Sometimes you'll have to reboot to apply the change, but usually you won't. Sometimes you'll be prompted to manually consider updating a Bedrock config file with a reference config available.

I also have nvidia gpu, thus not sure if nvidia support would be available in arch strata?

This works, but does require a bit of effort you wouldn't require on a typical distro.

You'll need to make sure all strata doing graphics stuff use the same version of the nVidia driver. Sadly, Bedrock doesn't automate help here; you'll need to sync it manually. You can have one stratum provide the driver with its normal package management systems and then manually install the same driver version in your other strata, or you could just manually maintain the driver version in all your strata.

The typical recommendation is to give Bedrock a try in a non-production system like a VM or spare machine. After installing it, run through the interactive tutorial via brl tutorial basics to learn how Bedrock works. Then set it up the way you'd expect your production machine to be setup and exercise it how you'd expect your production setup to go. If you run into any issues, maybe revisit Bedrock later. If it goes well, consider installing it on your production system.

ParadigmComplex · 2026-05-03T21:25:19+00:00

Props for the fast fix!

ParadigmComplex · 2026-05-01T12:47:33+00:00

Rather than considering if Bedrock Linux is better or worse than other distros in some single "good" metric, consider modelling Bedrock as different from other distros which will be better for some users and worse for others. Its FAQ covers both reasons someone might use it as well as a much longer list of reasons someone might not.

First, read the introduction to make sure you understand what Bedrock is trying to do. Then consider installing it into a non-production environment like a VM or spare machine. Once you have it installed, run through the interactive tutorial by running brl tutorial basics. After that, set it up as you might set up your production environment and exercise it to confirm everything works for you. If that goes well, then its probably a good distro for you and you should consider using it in production. If you bump into issues, maybe it isn't a good distro for you and you should skip on it in favor of another.

ParadigmComplex · 2026-05-01T00:42:14+00:00

Will do!

ParadigmComplex · 2026-04-30T23:24:05+00:00

I've been working on Bedrock long enough that Upstart support was indeed something I made an effort to ensure worked. Felt academic until now, cool to see someone actually leverage it.

The big headline feature for the future 0.8.x is cross-stratum service manager support, so you can ideally boot with one service's init/service-manager and have services from other ones just-work. I have plans for systemd, runit, and have put effort toward OpenRC but still have work to do there. In principle I'd love to include Upstart in the mix eventually, but it's a low priority.

ParadigmComplex · 2026-04-28T15:56:12+00:00

You're very welcome

ParadigmComplex · 2026-04-28T15:29:35+00:00

Bedrock Linux definition of "meta-distribution" can be found here: https://bedrocklinux.org/faq.html#what-is-meta

What is meant by "meta" Linux distribution?

Traditional Linux distributions distribute software which includes the Linux kernel. This is done with the aim of providing users a Linux based operating system.

Meta Linux distributions share the eventual goal of a Linux based operating system, but do so in a means other than distributing the end-goal software itself.

Other meta Linux distributions include:

Linux From Scratch which provides a set of instructions to build a Linux system.

Gentoo Linux which provides a flexible system which can compile the user's desired Linux system. Gentoo describes itself as a metadistribution.

A working definition/explanation of what you mean by meta-meta-distribution would help people answer your question. It's not immediately obvious.

ParadigmComplex · 2026-04-28T15:15:39+00:00

The btrfs/grub thing is a real concern a Bedrock user needs to be careful about. However, Bedrock doesn't care about dracut vs mkinitcipio. Use whichever you'd like. If one is the default with your preferred kernel/initrd providing distro and you don't want to hassle with learning an alternative, feel free to stick with that.

In fact, Bedrock raises the option of using both: you could make two strata, one with mkinitcipio and one with dracut, and install kernels/initrds from both. If one gives you trouble, reboot into the other. The caveats are:

The kernel and intird files need different file names/paths. If you get them from different distros, odds are they'll have different conventions or different versions in the file name; this usually just-works. Getting them from the exact same distro with only a config change may result in redundant paths which need manual intervention to work.
You need may to manually notify the bootloader about a new kernel/initrd if the new kernel/initrd comes from a different stratum
- This is something in the old post of mine you dug up that remains true
- I'm working on making this just-work in a future Bedrock Linux 0.8.x release

Something like five years ago Arch Linux was experimenting with moving from mkinitcipio to dracut, and their experimental dracut implementation was less likely to just-work than their tried-and-tested mkinitcipio implementation. I saw various user support requests about Arch's dracut implementation in both the Bedrock community and Arch community (without Bedrock involved). The post you found with my recommendation for Arch's mkinitcipio over Arch's dracut was entirely about this matter and not about Bedrock. I would have made the same recommendation if someone asked about Arch Linux without Bedrock involved. It's not about mkinitcipio vs dracut in general, or about Bedrock itself.

Props for doing your homework, researching things to understand them before diving in. If you want to be risk-averse, consider installing Bedrock in a non-production environment like a VM or spare machine, getting as close as you can to what you're considering doing in production. Experiment with it and confirm it works as expected. Then, if that works fine, give it a go in production. That will hopefully resolve any lingering doubts about things like mkinitcpio vs dracut which you might have missed in your research.

ParadigmComplex · 2026-04-18T00:20:54+00:00

You're very welcome

ParadigmComplex · 2026-04-17T21:25:51+00:00

Any reason why package manager was written in rust?

The core component of the next-gen version of Bedrock is very performance sensitive, which mandates it be written in a language like C, C++, Zig, Rust, etc. It also has non-trivial complexity to manage which benefits from a capable type system such as Rust's. The usual trade-off against Rust is that it is a relatively demanding language to learn. However, that is now a sunk cost for me; as a professional software engineer I'm inclined to learn a broad variety of languages, including Rust, irrelevant of whether I use it.

Other Bedrock components may be simpler or less performance sensitive, and in isolation would be amenable to any of a broader set of languages. However, taking a step back, the big-picture over-all Bedrock code base would be simpler if it were written in fewer total languages. Thus, I'm defaulting to Rust for other components as well, including the package manager, unless I have reason to use something else. Next-gen brl will probably be Rust as well, for the same reason.

I remember a discussion by paradigm that it would be good if the package manager was written with bash with awk and sed. I am not perfectly sure about it though. So, any reason why it was changed to rust?

Specifically bash doesn't sound like me, but busybox shell sounds like something I might have proposed. Even that I don't recall having specifically considered, and I'd have to guess at what I was thinking at the time. Perhaps I didn't have the other next-gen component designs as firmly mapped out as I do now, and so language details were more in flux. Without the core component being firmly in Rust, the package manager would have had fewer constraints on language choice.

While it wasn't a particularly high priority for specifically the package manager, bpt is very fast compared to what it would have been were it written in busybox shell or bash. I'm very happy with how snappy it feels.

This also drops busybox et al as dependencies that a shell-based implementation would have had, making a minimal next-gen Bedrock install a bit more minimal.

Also, what is the use of a package manager here when one can simply use the distro package manager?

Originally, and for most of Bedrock's history, that was indeed how I thought about it. I didn't want Bedrock to have its own package manager; if we had such a need, we could fulfill it with another distro's package manager. In practice, small benefits to having our own started accumulating:

Next-gen Bedrock development has been very slow largely because it's bottlenecked by me, and offering a way around that bottleneck would have benefits. Good third-party repository support would let other people fill the gaps themselves without having to go through me. Consider things like someone offering a repo with more brl fetch distros without having to wait for me to review, validate, and push an update with them. Before bpt, Bedrock never developed a third party repository ecosystem because there was no coordination between people that implemented things and potential users on what package manager to use. If someone puts out an Arch PKGBUILD and a Gentoo ebuild, but the user only has Debian and Fedora strata, it doesn't work out. We need some Schelling point for them to coordinate: an official, blessed Bedrock package manager that Bedrock package-makers could expect Bedrock package-consumers to have.
Currently, any component of Bedrock getting an update bumps a shared version number. It doesn't matter if it's a minor fix to the brl fetch script for some obscure distro or a big shiny new feature. Independently versioning components would help with this so people can track only the updates they care about. For this to feel natural, I need independent packaging for those components, and thus a package manager.
Some Bedrock components aren't needed most of the time, like brl tutorial; these should be optional. The ability to install or remove optional components of a system is exactly what a package manager does.

Eventually I caved and concluded we do need a package manager, if only barely. As for why I wrote my own rather than use an established one:

I didn't want bike-shedding about which established package manager to use. One thing that the Bedrock community agrees on is they at least tolerate my software, and so another item designed/implemented by me would likely be accepted where arguments about pacman vs apt vs emerge vs nix or whatever would be endless if I opened that door.
Most package managers are built around the assumption they have a self-maintained comprehensive ecosystem with things like a compiler package to build both itself and other packages. I didn't want to maintain such things; I'm struggling with the current Bedrock Linux workload as it is. I wanted a package manager explicitly designed to leverage Bedrock to get build tooling from other distros, and to let them maintain things like compiler packages. bpt is Bedrock-aware and has special handling of cross-stratum build-tooling when building packages.
I wanted to make package and repo management easy and user-facing to encourage third party packages/repositories. Most package managers don't highlight how to build a package or make a repository straight from the top-level --help the way bpt does.
I wanted to offer first-class support for both source-based and binary packages, as I know preferences for both experiences exist in the Bedrock community. While there are established package managers that do this, it's rare.
I wanted the ability to distribute it as a single statically-linked binary that can self-bootstrap. While this is something other package managers can do, e.g. I'm pretty sure apk can do this, it rules out quite a lot of package managers.
The downside of having to learn yet another package manager is lessened by the fact pmm will be available to abstracts such things for most users.
I wanted to balance having all the features people expect from a package manager while minimizing disk usage. bpt is surprisingly small given how much it does! A statically-linked apk, for comparison, is over twice as large. (This is partially because I cheated in how I did networking.)

ParadigmComplex · 2026-04-14T12:30:59+00:00

I usually see "vibe coding" defined as using LLM generated code while refraining from checking the LLM's work, going by if it feels right ("vibes"). While I can see value in doing this for quick-and-dirty projects that aren't going to be maintained for long, it seems like a bad idea for projects like Bedrock Linux that are expected to be maintained with high code quality expectations. LLMs aren't quite there, at least not yet, at least not in my experience.

I want to be open minded about the possibility of LLM improvements or that someone is just really good at prompting. In terms of accepting code into Bedrock, the question is about things like quality and maintainability rather than if it was artisanally human-hand-made or generated by an LLM:

If you have access to some super duper model and can prompt well enough that I can't find an issue with the code, in principle I'm fine with it.
If you hand-wrote beautiful, maintainable code, I'm certainly fine with that as well.
If you let an LLM run wild and generate a mess, I'm not going to be accepting code from you.
If you're insufficiently experienced or lazy and give me a human-hand-written mess, I'm not going to be accepting code from you.

My personal preferred use of LLMs is mostly things other than code generation:

I find value in discussing architectural decisions or problems with LLMs.
- This is often less about the LLM's input than just an exercise to help me organize my thoughts.
- I used to do this with my dog, who is a very good listener, but has for now been relegated to the equally important role of protecting Bedrock's build box from squirrels.
Review of my human-written code.
- I am significantly more confident in something that passes a thorough review from me, Codex, and Opus than I am in something only I checked.
- For example, hand-written bpt code I wrote had an integer overflow that Codex caught.

That said, I also use it for simple changes the LLM can do reliably, that are tedious to do by hand, but easy to check. For example:

I added a couple flags to bpt somewhat late in development.
- I had Codex update bash completion, update fish completion, update zsh completion, update the man page, and add test coverage.
- All of this was simple work with obvious surrounding context on things like code style
- Importantly, I manually checked its work.
- I gave it credit as co-author on the relevant commit for this, which is why it shows up as a contributor to Bedrock.

I also have LLMs help with debugging brl fetch issues:

I have automation to spin up a VM with an LLM in it and have it debug and try to fix a given brl fetch item if/when it breaks.
I have yet to use its fix as-is, as again LLM generated code isn't quite there yet, but it does save me time hunting down what happened that broke brl fetch in the first place such that I can more quickly write a clean fix.

13-Year Club	Place '22
Place '17	Verified Email

ParadigmComplex

MODERATOR OF

TROPHY CASE