While I agree it's unreasonable, it's also kind of a chicken and an egg thing. These things won't change until Linux becomes big enough to ignore. I'm not sure what the solution is though, as I don't think it's realistic to make people give up what they enjoy to get there. That's not gonna happen. But Valve has at least made a dent with the Steamdeck and Proton in general, and maybe more with the upcoming Steam Machine. Devs actively target the Steamdeck nowadays for games where it makes sense, so it is taken into consideration at a whole new level compared to years past.
Getting the community to respect that people have those needs would go a long way to stopping people from feeling alienated, even if the solutions aren’t there yet.
There have certainly been issues (I've been on Linux with mostly nvidia GPUs since 2004) but it's
almost always been caused by the module being outside the kernel, and a kernel update breaking compatibility sometimes, understandably. This has always been fixed quickly on nvidias end though. And early Wayland issues and the current DX12 -> Vulkan translation performance issues in more recent times.
But overall I've also had a mostly stable experience during that time. New hardware is supported mostly at release. Not always supporting all the latest features straight away mind you, but still. Meanwhile I seem to hear about issues with support for Intel and AMD cards at release frequently in comparison.
Technically PS5 and I think Switch 2 is based on the BSD kernel probably because of the license. Xbox is not exactly Windows but it's using an NT kernel.
Playstation is FreeBSD, yeah, but the Switch runs a completely bespoke microkernel. Nintendo did borrow the BSD networking stack, which led some to infer from the license disclosure that it runs a BSD, but it's been extensively reverse engineered now and it doesn't even vaguely resemble Unix.
The fun thing about it being a true microkernel is that although there's zero official public information about it, it was small enough to fully reverse engineer and more or less reconstitute the original source code. You can see it here, it's tiny:https://github.com/Atmosphere-NX/Atmosphere/tree/master/meso...
I’ve been trying to train a model to do this kind of work. Take a black box and try to reverse engineer its functions back into something usable (not necessarily identical). Obviously on things that are out of copyright or copyleft.
With the Nextcloud app I remember having to enable full file permissions to preserve the GPS data of auto-uploaded photos a couple of years ago. Which I only discovered some months after these security changes went into effect on my phone. That was fun. I think Android 10 or 11 introduced it.
Looking now I can't even find that setting anymore on my current phone. But the photos still does have the GPS data intact.
Would it be technically possible for these anti-cheat companies to make third party proprietary kernel modules I wonder, a bit like Nvidia does with their driver for example, and then require that to be installed and loaded to play? Although with the user able to make custom kernels that'd be a bit of a nightmare. Probably would have to be only supported with specific distro's kernels or something.
I agree with you and I wouldn't want to install that myself but just something I've thought about.
The general performance loss with the DX12 -> Vulkan translation on Linux especially with Nvidia hardware recently had the cause identified and will hopefully get solved in the near future. It has to do with descriptors and how Nvidia handles it is the general gist of it. A new Vulkan extension will be developed that more closely resembles how DX12 does things as I understand it, and then Nvidia and others can use that to hopefully solve this once and for all.
Here[1] is the full presentation and the slides[2] from it.
It means that at the very least the Nvidia specific performance loss of 10-20% will disappear. That is already not an issue with AMD cards as I understand it.
If it'll further increase performance beyond that remains to be seen. I suspect there will always be some amount of overhead, although at least with earlier versions of DirectX it is quite minimal already.
That's a fair criticism, although once you learn how to access the documentation and where to look for/expext it I find that most things, including add-on packages and whatnot, can be learned from within Emacs itself just fine. But it does take some knowledge to get to that point in the first place for sure.
One thing that greatly helped this in the DOS / early Windows era was standardizing on F1 being the key for "online help" (meaning, usually, a hyperlinked document that shipped with the product). That was basically the only thing you had to know to start learning any app.
I think is not fair at all, as a default installation has a menu bar, and you can save a file in file->save. While doing so it will tell you the shortcut.
You can only "pause" your watch history, as they call it, for some reason. And I keep having mine become unpaused constantly which I find interesting. I'm not sure if it's one of my clients doing it automatically or if Google just reenables the setting from time to time.
My watch history has been off for almost a decade now.
They may weasel you into activating it via some other route that states in the fine print that they need to activate your watch history to provide [random almost unrelated feature].
Also interested in this. I've been running photoprism for several years now using their docker image and don't really have much to complain about but always open to other alternatives.
One thing Immich supports which Photoprism doesn't is multiple user accounts. That doesn't really bother me too much but it's a pretty big advantage.
Edit: Actually one thing I can complain a bit about is the object recognition accuracy. Face recognition I think works decently enough but objects are frequently not identified in my photos. How's Immich in this regard?
> Sounds similar to Donkey Kong 64 (1999) that had an arcade machine inside a level that let you play the original Donkey Kong (1981)
Interesting tidbit about that is that it was carefully recreated from scratch by Rare, rather than being emulated, because Nintendo doesn't have/own the rights to the original source code. They originally had Ikegami Tsushinki do the programming for the arcade version, who later claimed ownership of the source code and eventually won the lawsuit.
Nintendo and Ikegami settled out of court. I'm assuming Nintendo got the rights to the arcade version as part of the settlement, as the arcade version of Donkey Kong got a release on Switch as part of Arcade Archives. https://www.nintendo.com/us/store/products/arcade-archives-d...
reply