It depends. If it’s under your control with your own keys then it can be beneficial. If it’s under someone else’s control (as it is for most people) then it’s a step towards the walled garden.

I am only guessing and extrapolating based on how this usually goes:

• It’s probably possible to get it to run but would take a lot of work
• It’s probably much easier to just run the windows version under Wine

While the Linux kernel usually maintains long term backward compatibility very well unfortunately the userspace (libraries) is a different story.

Looking at the game’s faq the main dependency seems to be SDL. There is no OpenGL or other 3D library requirement. It might also depend on which version was shipped on the CD according to the faq there was an earlier statically linked version (which I am guessing might be easier to get to run) and a later dynamically linked one.

Sales numbers ($) by platform would be interesting to see too.

Correct, that’s what I meant to imply in the first part of my comment. When I research new games I do that from a web browser and that’s when I care about Proton status the most so this works great for that. It does not help when using the Steam client.

I tend to do my Steam shopping in the browser and I use the ProtonDB-Peek userscript. This gives a ProtonDB status badge in the right column under the review links.

In the subject you wrote “successful full sys update” but the script and the other suggestions I see so far don’t actually handle the “successful” part.

The log message only tells you that the update was started and the db mtime only indicates that the db was touched without saying anything about success.

I’d go about this by always performing the updates through a wrapper script that could check the exit status of the pacman or yay command and record a timestamp accordingly.

This hasn’t been true for years, see the relevent Arch wiki page for example.

The Internet was already a teenager by then. It hooked up with Hypertext and the result was this brat called WWW.

My first WWW experience was trying Mosaic on a computer without an Internet connection. I knew what the Internet was, we had access through an X.25 PAD (kind of like a dial-up shell session, no direct TCP/IP) so I’d already used IRC, Usenet, FTP, Archie, Gopher etc. I also knew what hypertext was from various local help and document browser programs. So I figured out that Mosaic can display HTML documents but of course without Internet connectivity just showing some local demo pages didn’t seem all that special. But I figured it out later on…

I like my 8bitdo controller but I have an older model so can’t speak for the more recent ones.

Mesa 25.0.0 Release Notes / 2025-02-19

[ 5067.696] (II) Applying OutputClass “AMDgpu” to /dev/dri/card1

Make sure that you actually have permission to that /dev/dri/card1 device. This may be arranged by udev or “video” group membership.

Regarding AMD vs Nvidia, unless you need CUDA you probably made the right choice. This sounds like a config issue and you’d probably be dealing with the same thing with Nvidia too.

• Termux (or equivalent) has always been the primary mobile phone use case for me. Access to my main computing platforms from my pocket.
• Antennapod
• Fedilab (Mastodon)
• Fennec - Can’t deal with the web without uBo and other extensions.

To be fair the “no USB support” window was quite short. USB started becoming available to consumers around 1998-1999 and there was some level of USB support in the Linux kernel within a few months. I remember using an early USB stack written by someone else that Linus didn’t like so he rewrote it from scratch. Even the new Linus stack was in place by 1999. We got USB-2 and 3 support pretty quickly too.

I’d start by comparing the following in the working vs non-working cases:

1. Is there a corresponding /dev/input/js* device?
2. If it’s there in both cases, any difference in permissions? Check both regular Unix perms using ls -l or stat and ACLs using getfacl

1. The basics: high quality terminal emulation with utf-8 and directcolor support
2. Customization is by simple git friendly text config. Build time config (ala st) is acceptable if done in a reasonable way.
3. A way to pipe panes into external commands to allow for customized url and other other data extraction. Built-in regexs are not always enough and doing it on the tmux side is not always ideal.
4. Control over key bindings and mouse behavior
5. Small, very fast, instantaneous startup
6. Very predictable behavior, no surprises
7. Minimal dependencies (including build time) are a plus. Definitely no 100MB+ electron beasts.
8. Support X11 since I am sticking with that for now
9. A codebase I can understand in case I need to change it. Simple and fast build. For core tools like terminal emulators I must be able to build or modify them without much trouble.
10. Not too much extra junk. I don’t use menus, tabs, scrollbars etc so I don’t want the terminal to be huge or slow to support every feature others might want. I will put up with some extras if they can be completely disabled and don’t significantly affect performance or startup time or code complexity.
11. Absolutely no network service integration, no matter how well intended. The only acceptable network activity is talking to the X11 socket.
12. Longevity. I like to use my tools for years and years. I am interested in new tech of course but I don’t hop from one hype train to the next.

I know this is not everyone’s cup of tea but you asked what I want. And nowadays it’s at least as much about do not wants as wants.

I briefly tried ghostty when it was going around earlier. Slow startup time (~250ms if I remember right), the gtk-4 dependency and some weird defaults like the client side decoration (which I gather can be turned off in config) made me pass on it for now but might take another look in a few months. It didn’t seem particularly revolutionary to me either but there are plenty of much worse options out there too.

Looks great! I used Twire in the past but this is a lot more polished and doesn’t require using an account.

Ugh, that’s a pretty insane default. Thanks for the heads-up.

I had similar worries about the AMD driver stability before I switched from NV about 5 years ago. But my experience has been great even back then and things have only improved since.

One data point to consider is that Valve is shipping the Steam Deck with an AMD AMU and stability and compatibility is paramount for that use case.

Any naming convention is fine as long as it’s meaningful to you. But it’s a good idea to keep your own repos separate from the random ones you clone from the internet.