You are getting this from Xwayland, so you’re running a rootless X server in the background. It’s nice that it works seamlessly, but it’s not really Wayland doing anything but managing the X window.

I don’t have experience with MSI recently, but I’d be really surprised if you couldn’t flash a new BIOS off the system partition or FAT32 USB. You may not be able to update from Linux directly, but almost all motherboards I’ve seen support doing it from the BIOS interface.

Intel has been struggling overall, and lately has been letting some of its Linux engineers go. Nothing absolutely fundamental has been affected yet (AFAICT) but I guess Clear Linux didn’t make the cut.

It would allow SSH if the desktop is locked, they’re separate. If you can get in via SSH then you can poke around logs like dmesg and see what’s up. There will probably be some messages to give you something more specific to search with.

I agree. I have become more amenable to things like Flatpak or Podman/Docker to keep the base system from being cluttered up with weird dependencies, but for the most part it doesn’t seem like there’s a huge upside to going full atomic if you’re already comfortable.

I used mutt back in the day, opening vim for message editing.

I wouldn’t do a mailing list these days, but as someone who spent the early part of my career interacting with devs that preferred this method, it’s actually pretty ergonomic by a 2005 standard. A message thread aware, text based email client that can turn messages into patches in a keystroke makes it actually pretty comparable to modern code review…

I think it’s hard for younger devs to get this because they’re used to email being stuck in a crappy, unthreaded browser interface or Outlook etc. (which are terrible for mailing lists) and most collaboration taking place in code review and chat platforms like Teams/Slack but for decades before these were feasible, email was the way…

GNOME 3 introduced the current shell paradigm where you don’t really have a start menu but a variety of searches, integrated indicators, per-app desktops with a dock etc.

Before, it was far more conventional experience like Plasma/Windows/Cinnamon are now. GNOME 2 was forked to be the MATE desktop if you want to check it out.

I have a couple of very minor commits in Linux and, in the 3.0 era, had my name at the top of a source file for a platform that never saw the light of day and was later removed wholesale.

Still feel that invisible feather in my cap.

Basically just start with what you’re aiming to enable and work backwards (as you’ve started to do). With judicious use of grep find out where that symbol is defined. If it’s in arch configs for other arches but not your own, it’s probably that.

There may be better tools out there to do this, but in my experience just sleuthing it out a bit will answer your question. The Kconfig system can be complex, but the files are pretty readable.

It’s possible that it’s not supported on your arch.

So you’re right that this is a bit arbitrary because the line between the standard lib and the language is blurry, but someone writing Rust is going to expect Vec to work, it doesn’t even require an extra “use” to get it.

Perhaps a better core example would be operator overloading (or really any place using traits). When looking at “a + b” in Rust you have to be aware that, depending on the types involved, that could mean anything.

Anyway, I love Rust, it just doesn’t have the 1:1 relationship with the assembly output that C basically still has.

Huh weird, these pull requests just magically accepted themselves

Rust can create native binaries but I wouldn’t call it close to the metal like C. It’s certainly possible to bootstrap from assembly to Rust but, unlike C, every operation doesn’t have a direct analog to an assembly operation. For example Rust needs to be able to dynamically allocate memory for all of its syntax to be intact.

This better not awaken anything in me…

John Carmack, author of the Doom engine, is a long time Linux user and for a while the policy was to open source the idTech engines once they had moved on.

However, Doom was hugely popular on its own before this, and was actually more pivotal for making Windows a gaming platform (over DOS).

The reason it runs everywhere is a combination of it’s huge popularity, it’s (now) open source and it’s generally low system requirements.

Honestly, with Flatpak and immutable base systems this is a place Linux is really excelling now too. Being able to show a novice user a shared package manager with a search and a bunch of common apps and them actually install/remove them in a safe manner with a high likelihood they’ll work out of the box (since they come with all their deps in sync independent from distro) is kinda huge.

For kernel dev it would be a disaster, there’s too much implicit action, and abstractions that have unknown runtime cost. The classic answer is that everyone uses 10% of its features over C, but nobody can agree on which 10%.

As someone forced to get up to date with C++ recently, at this point it’s a language in full identity crisis. It wants so badly to be Rust, but it’s got decades of baggage it’s dragging along.

In a world where Valve controls 90% of what is running on a device with immutable / containerized images, yeah I think Arch makes a lot more sense. A distro focused on rolling release is a lot less likely to hang you up when you choose to update.

Debian is great, but depending on where you are in the release cycle it can be a pain in the ass to stay up to date and, frankly, the last time I ran it, shit like apt/dpkg configuration and so many /etc files and structures just felt like mis-features or too complex for their own good.

That’s an interesting thought. I’ve wondered this about Chrome’s market share in browsers too. How much of it is just that so much traffic is now from phones where, even if you have another browser installed, apps open links in embedded Chrome web views.