Patience. Same things will work differently than you’re used to, and that can be frustrating.

Also be really sure to help true beginners understand software centers and package managers. I’ve been helping a lot of young people use Linux for the first time this year. Even though I mentioned it the first day and remind them frequently, if for example I ask them to install Java, half of them will download installers from Oracle’s website or wherever.

In 2025, the package manager and frequency of updates are the only real differences between most distributions. I’ve been enjoying Flatpak for years now and hope it continues to build momentum. It offers the possibility of shared effort between distributions who depend on legions of volunteers constantly updating debs/rpms/whatever.

It feels like one of the last hurdles to eliminate so much of the duplicated effort associated with all these distributions.

I started using Linux right in the late 90’s. The small things I recall that might be amusing.

1. The installation process was easier than installing Arch (before Arch got an installer)
2. I don’t recall doing any regular updates after things were working except for when a new major release came out.
3. You needed to buy a modem to get online since none of the “winmodems” ever worked.
4. Dependency hell was real. When you were trying to install an RPM from Fresh Meat and then it would fail with all the missing libraries.
5. GNOME and KDE felt sincerely bloated. They seemed to always run painfully slow on modern computers. Moving a lot of people to Window Managers.
6. it was hard to have a good web browser. Before Firefox came out you struggled along with Netscape. I recall having to use a statically compiled ancient (even for the time) version of Netscape as that was the only thing available at the time for OpenBSD.
7. Configuring XFree86 (pre-cursor to X.org) was excruciating. I think I still have an old book that cautioned if you configured your refresh rates and monitor settings incorrectly your monitor could catch on fire.
8. As a follow on to the last statement. I once went about 6 months without any sort of GUI because I couldn’t get X working correctly.
9. Before PulseAudio you’d have to go into every application that used sound and pick from a giant drop down list of your current sound card drivers (ALSA and OSS) combined with whatever mixer you were using. You’d hope the combo you were using was supported.
10. Everyone cheered when you no longer had to fight to get flash working to get a decent web browsing experience.

I really don’t agree with choosing to release with the UEFI bug they found. They describe it as cosmetic but those entries can last the lifetime of your computer, even if you wipe your hard drive. It’s bound to cause some confusion for years to come for Linux tinkerers.

You mean like Wacom tablets? I’m curious to know what’s missing. I’ve been using one of those XP Pen tablets on GNOME and Wayland without much issue. I’m using it for writing more than drawing though.

I used to have a Shield. I donated it to GoodWill when Nvidia updated their UI to start showing ads on the Home Screen. I switched to Apple TV and not only does it not force me to watch ads, it’s actually just been a better overall. I haven’t had a single issue streaming anything from Plex to my Apple TV, where sometimes the Shield would struggle with high fidelity audio tracks.

I’ve been really enjoying Cockpit as well.

From what I recall the completely fair scheduler (CFS) used by default on most Linux systems has a lower average latency than the RT kernel. The RT kernel just gives you more consistency, hence the CFS having lower latency “on average”

So honestly for opening Firefox it’ll probably depends more on your SSD data rate, but in theory it’ll open faster on a “regular” distribution most of the time.

Real time is good for things like audio processing where having better guarantees that a process will get its share of the CPU is a benefit.

Hey man, I don’t want to discourage you, but this is one of those things where if you have to ask how to do something you’re probably not experienced enough to do it. That being said, as a learning opportunity even if you don’t make it far you’ll still learn a lot about how GPUs work.

I’d start by looking at any existing drivers you can find and see if you can document or find documentation for the commands fed to the GPU. From there you can look at the Mesa project for examples of converting Vulkan to instructions for specific processors and see if you can get it to all fit together for your project.