This is still a problem. There are a lot of, eg, realtek chipsets that don't work well or simply don't work on Linux.
Another issue is they advertise "Linux support," which actually translates to: minimally working driver source available for very out-of-date kernel. Good luck if you want to rely on upstreamed drivers or even run a recent kernel.
On the bright side, hopefully rising memory prices will give Microsoft and its ilk the kick up the pants they need to reduce memory usage in Windows et al
P10 primera (1st gen infinity G20, for the Americans) was a great handling car... I think the front suspension was a very similar setup to the 300zx. Bit hard to find parts for these days unfortunately.
Currently I drive an 8th gen civic which I'd rate on par handling wise and is much more safer and modern...
What I am uncomfortable with is the inability to run Wayland on older video hardware. X11 will happily run with Vesa driver on older hardware which no longer has functional 3D accelerated drivers.
What is the way forward for the retro community to run a modern Wayland system on older hardware?
Hopefully someone more knowledgeable can chime in or correct me
If your Linux distribution is handling Mesa packages correctly, you will never lack OpenGL/Vulkan drivers.
The reason is that Mesa includes "software rendering" drivers for both OpenGL ("llvmpipe") and Vulkan ("lavapipe").
As the name(s) might suggest, they use LLVM to JIT shaders for your CPU (supporting SIMD up to AVX2, last I checked - although typical compositing shaders tend to get pattern-matched and replaced with plain `memcpy`s etc.).
So you should always be able to run a fully-featured Wayland desktop (albeit limited in performance by your CPU), on any unaccelerated framebuffer, nowadays (and I remember doing this even before Plasma 6 launched, it may be older than usable Wayland desktops tbh - the Mesa code sure is, but maybe distros hadn't always built those drivers?).
Software OpenGL rendering technically works, but is IME unusably slow for compositing. What does work okay is direct software rendering. It might work to configure OpenGL to hit all the fast paths in the software backend (which you might need to add first), but I'm really not sure if you can do it without at least some unnecessary data copying.
Software compositing is possible. Wayland doesn't strictly require hardware acceleration or operations that are hopelessly slow without hardware acceleration.
>What is the way forward for the retro community to run a modern Wayland system on older hardware?
I'm curious why that's something that should happen. Shouldn't the 'retro community' be happy with retro software and not expect cutting edge software to work on their hardware?
I also seem to remember reading retention is proportional to temperature at time of write. Ie, best case scenario = write data when drive is hot, and store in freezer. Would be happy if someone can confirm or deny this.
I know we're talking theoretical optimums here, but: don't put your SSDs in the freezer. Water ingress because of condensation will kill your data much quicker than NAND bit rot at room temperature.
I'm interested in why SSDs would struggle with condensation. What aspect of the design is prone to issues? I routinely repair old computer boards, replace leaky capacitors, that sort of thing, and have cleaned boards with IPA and rinsed in tap water without any issues to anything for many years.
Sure. Just make sure the drive is warm before you take it out of the container - because this is when the critical condensation happens: you take out a cold drive an expose it to humid room temperature air. Then water condenses on (and in) the cold drive.
Re-freezing is also critical, the container should contain no humid air when it goes into the freezer, because the water will condense and freeze as the container cools. A tightly wrapped bag, desiccant and/or purging the container with dry gas would prevent that.
reply