trevor (he/they)

Yeah. I was annoyed by this, but wouldn’t assume bad faith on the part of the Fennec devs.

The owning class is the only minority group that does you any harm.

All those packages, but terrible/lacking documentation and LSP support 😭 And, yes, I’ve tried nixd and nil, and they’re not even close.

I’ve tried to learn Nix multiple times, and even got by okay running NixOS for a year or so, but doing almost anything that isn’t just adding a package to a list in a nix file or flake was like pulling teeth because everything is documented so poorly (or not at all). It would take me hours to do what I could have done in seconds with any other package management tool or configuration management because I’d have to scour hundreds of search results to find someone that did the thing I’m trying to do because there was little-to-no documentation for it.

Nix is a tool with amazing promise that could solve so many problems if they could get their documentation and LSP support up to the standard of something like Rust.

I would say that development is the one thing that can get very annoying on immutable distros.

Flatpaks can only get you so far (as seen by the VS Code Flatpak’s limitations that have to be worked around). I don’t even use VS Code, so I can get around that pretty comfortably, but I have to use Distrobox for a lot of miscellaneous developer tools, and even then, I still run into problems and I can’t install container tools inside of the containers that I’m already working in.

Not to discourage you from trying. I can still get by with some dev work on Bazzite, but it’s waaay easier to do the same dev work on CachyOS (Arch-derivative) because I can just install shit normally and it will work.

Same. If most of my games stopped working, I would be very annoyed, especially because it was entirely preventable.

Thankfully, the Fedora project and community agree.

No. Valve (the biggest offender) will have to make native 64-bit Steam before then, as will the remaining holdouts, so Linux distros will be able to remove 32-bit packages in a timely manner.

Removing then now will break too much to be worth doing.

Nooooo. I have to reduce veganism to a dietary preference instead of a rights movement so it’s easier to dismiss it because a vegan was annoying or whatever one time!

The grown-ups that run Fedora and the community are overwhelmingly against this very bad proposal, so I don’t think the reich-wing creep’s toy project is going to replace the official XServer implementation any time soon.

This probably has a lot to do with the new DOA XServer fork being “anti-DEI” (pro-discrimination). When these slimy shitweasels go out and vice signal about how bigoted they are, they congregate around it and form a new harassment campagin because they have no life.

Sorry you’re getting harassed. I hope you can take solace in the fact that these little pissbabies lead miserable lives.

If you are in the US, ROMs aren’t illegal either. You’re just required to rip them from a cartridge/disc you acquired legally (including second-hand purchases) and you can’t distribute it to others. It’s the latter part that makes it illegal (but not at all immoral). If you wanna do that last part, god bless. Fuck these companies.

I swear “review bombing” has to be an astroturfed term to delegitimize criticism when companies do shitty things.

It shifts the blame from the companies doing a shit thing (lacing their game with DRM/anti-cheat malware, making them run like shit unless you enable AI slop upscaling, shoveling AI “”“art”“” assets, MTX, etc.) to the customers that are rightly mad about the shit thing.

Linux on Apple Silicon is a totally different story than it was for Intel Macs because of the work put in by the Asahi team. It’s actually one of my favorite pieces of hardware to run Linux on. The trackpad works great too, btw.

It’s not for no viable reason. Rust is just safer than C. There absolutely are bugs with GNU coreutils, so it’s not even a hypothetical like you implied. But beyond safety, some of the Rust equivalents are more performant than their C counterparts.

And uutils is already heavily tested against the GNU coreutils. It’s not some fly-by-night rewrite that people aren’t serious about. I don’t know if it’s been formally audited yet, but it absolutely will be when companies like Canonical (and hopefully SUSE and Red Hat, one day) want to start shipping them.

Just adding to this for other people that don’t know: you can also install most* standard Linux applications and tools on SteamOS, as long as it’s available as a Flatpak, or you can install it to your user directory. Technically, you can even bypass that last caveat and install whatever you want, but you’re going to have a bad time if you don’t know what you’re doing.

Alternatively, you can install any Linux distro on your Steam Deck if game dev isn’t a good experience for you on SteamOS. In fact, Bazzite is working on a GDX (Game Developer eXperience) edition, and will likely be a solid choice once it’s ready.

I don’t dislike GNOME (except for their insistence on shirking and breaking standards that everyone else uses), but I’m curious about why you prefer KDE on your laptop, but GNOME on your desktop. If anything, I’d think that GNOME’s larger UI might be easier to use with a less precise pointing device than default KDE.

internationalization

Interesting point. I don’t actually know about that. What can the GNU coreutils do with regard to internationalization? Just the output of commands, or can they also internationalize stuff like command args?

I highly doubt that those “couple dozen” patches are trivial though. Even Pixel devices can’t run the vanilla mainline kernel without a bunch of added code to make it work with the hardware (see: the Greg KH interview I linked).

And abstracting the hardware is what you do when you make drivers, so this is a distinction without a difference.

I mean, Linux is the driver layer, and you mentioned GNU (userspace) / Linux (hardware layer), and the Linux part of that solid base can’t just be the vanilla Linux kernel that you’d run on a computer.

I fully agree with you on the accessibility front. It’s not even good on X11, but it’s unusable on Wayland, from what I understand :( Accessibility on Linux needs a massive funding and development initiative, and it needed to be done a long time ago.

But uutils is pretty solid. I’ve swapped out my GNU coreutils entirely (on Arch, not Ubuntu, because I value my time too much to be troubleshooting broken snaps) and haven’t run into any issues. I think people are underestimating how close the compatibility already is. I’m sure something I use at some point will try to invoke an option that doesn’t exist in the uutils version, but it’s been solid for me so far.

Sort of. Whatever hardware these are intended to run on require something like 3X the driver code (at least in the case of the Android Linux kernel, according to Greg Kroah-Hartman). Phones tend to have more specialized and proprietary hardware, so you can’t just take the standard Linux kernel, use it there, and call it a day.

But I’d be surprised if the people working on this weren’t aware of that fact, and I hope they are working on abstracting the hardware layers more so that every mobile Linux project doesn’t have to start from scratch every time.

Edit: source (YouTube, sorry) for the claim about how much driver code is required for mobile devices.