6 of the top 10 are verified or playable or 43% of the top 1000 games. But verified and playable is only a subset of the games that work, quite a few unsupported games do as well. If you go by medals the 7 of the top 10 are silver ranked or better (minor issues but generally playable) and 88% of the top 1000. So there are a lot of games that are playable that are still listed as unsupported on the deck.
You can see the numbers for various different things at www.protondb.com as well as different reports for all the games (including some tips on how to get things to work or work better).
Most done with the latter. But the nice thing is once you have done it once it is much easier to keep things up to date and in sync from then on words. You can also peace meal it - setup one application at a time and migrate things one by one over to it.
painstakingly manually code every unique facet
That makes it sound a lot worst then it actually it. It is only a bit more effort then setting something up for the first time manually. And pays its self back many times over when you next need to reinstall or install a new system. Assuming you keep up with making changes to the code and not directly to your system each time.
I have done something similar following this post - loads of others have created similar scripted installers for Arch for their specific use cases and this guide takes it one step further with custom arch meta packages that hold deps and system wide config.
You can also do similar things with tools like ansible or saltstack or similar tools. Though these all take the approach of define your configs and system to automate the setting up of a system approach rather than the backup or clone an existing system. So are more effort initially but are able to keep multiple system in sync with system configs with far less effort then trying to create a backup/restore system for organically created configs.
that wouldn’t work (I think) because my laptop has vastly different hardware
Should not matter, you can install all the packages all your system need - such as both nvidia, amd and intel graphics drivers and the kernel will only load the ones for the hardware you have booted with. Or if you really need different configs or packages for different systems the various approaches have ways to do that.
You dont even need a separate partition, just dont format and dont delete the /home folder. You can even keep the /etc folder as well to keep system wide settings.
There was no option per say, at least on the ubuntu installed I tried many years ago. Just a popup that happened sometime before the install but after the manual partitioning if the root partition had folders like /etc /usr /var etc that were needed by the installer. Not sure if all installers do this - but I would suspect if they didnt you can just delete the folders manually before you enter the installer and pick manual partitioning option and opt to not format any partitions.
I set it up this way so that if I need to reinstall Linux, I can just overwrite / while preserving /home and just keep working after a new install with very few hiccups.
Even with a single partition for / and /home you can keep the contents of /home during a reinstall by simple not formatting the partitions again. I know when I tried years ago with Ubuntu years ago the installed asked if I wanted to remove the system folders for you. But even if the installer does not you can delete them manually before hand. Installers wont touch /home contents if you don’t format the drive (or any files outside the system folders they care about).
Though I would still backup everything inside /home before any attempt at a reinstall as mistakes do happen no matter what process you decide to go with.
UI for non trivial conflict resolution? Definitely.
I dont know about that… Never found they help that much in conflict resolution. They give you some nice buttons for accept their or accept our changes but really I find more often than not those are what breaks code as you often want a mash-up of both sides - which needs to be manually done even in UIs.
Otherwise it is just find the marked sections in the file, and make it look like what you want it to after the merge/rebase. And that is the hardest part - figuring out what it should look like. Which is made easier if you only ever have small commits and merge back to master frequently minimizing the amount your branches drift from each other.
Software that controls your body should always respect your freedom
FTFY
But it is extremely worrying that so many devices that people require for their health and have no alternative for are so invasive and can be turned off without any warning.
IMO trying to write everything out in psudo code first is way slower. You are writing things out twice and you are not able to run things quickly. You just have to hope you got things right on the first pass and cannot quickly adjust things when you don’t.
I prefer constant feedback from my editor, compiler and test framework to write things quickly and make sure I am not doing something that is fundamentally flawed. There is nothing worst than writing a whole program without running it only to run it and realise nothing is working how you thought it should.
8,000 characters in five hours is 1,600 characters per hour, or 27 characters per minute.
This is irrelevant. Typing when coding is not evenly spaced out over those 5 hours. It is sporadic with most of the time thinking or reading documentation or reading source code and trying to figure out what you want to type. No good conclusions can be drawn from this logic and makes that whole part of the argument irrelevant.
If I were typing that slowly I would quickly forget what the hell I was even trying to do in the first place. Which is the bigger part - when you do need to type you want to quickly get the ideas you have down as fast as you can think them. Going too slow can cause your mind to wander and that can really hamper your productivity.
There is also the cost of context switching. And it is a context switch to go from writing ideas down to making sure I have all the boiler plate and syntax correct. The less of the need for doing that the better IMO.
And TBH I don’t really understand the rest of their arguments. They introduce two bits of code, one very short simple class then one with lots of helper methods to set various things while creating a new object. And then concludes with a short paragraph on some real benefits without really explaining why. With the whole paragraph being more of an argument about immutable code being better rather than longer vs shorter code. Then follows up with an entire section on why his code increases maintenance as refactoring requires more points to update with his immutable code and thus prefers languages like F# where the immutable version is a one liner… Which defeats the whole argument that typing is not the bottleneck? I really don’t follow his logic here.
Apparently, it has to be explicitly stated: Programmer productivity has nothing to do with typing speed.
I feel they have completely failed to convince me of this fact. Despite me already thinking it is not one of the more important factors of productivity and there are better things to optimise around.
My opinion is that code length is not that important a factor, but you should not go hog while and write the longest things you can either. Every extra bit of code should add some value somewhere. Like taking his examples, spending a bit of time writing the immutable version here lets you reduce the amount you need to write when using that code. Which is a trade-off that can be worthwhile - increasing typing now for reducing typing later. But also the reduced typing makes the where the code is used easier to read and clearer as to what is happening, get a copy of the object with one field updated. That is a nice concept to have and read. Without the need to refer to all the fields every time you want a copy.