TIL my thesis could have been easier if Typst would have been available years earlier.

One example for self documenting code is typing. If you use a language which enforces (or at least allows, as in Python 3.8+) strong typing and you use types pro actively, this is better than documentation, because it can be read and worked with by the compiler or interpreter. In contrast to documenting types, the compiler (or interpreter) will enforce that code meaning and type specification will not diverge. This includes explicitly marking parameters/arguments and return types as optional if they are.

I think no reasonable software developer should work without enforced type safety unless working with pure assembler languages. Any (higher) language which does not allow enforcing strong typing is terrible.

I have worked on larger older projects. The more comments you have, the larger the chance that code and comment diverge. Often, code is being changed/adapted/fixed, but the comments are not. If you read the comments then, your understanding of what the code does or should do gets wrong, leading you on a wrong path. This is why I prefer to have rather less comments. Most of the code is self a explanatory, if you properly name your variables, functions and whatever else you are working with.

Same question on reddit a while ago

As suggested there, I recommend to use a multimeter to identify the power socket pins. Roughly half of them should be ground. Most or all of them should correspond and be connected to the SATA power connector pins on the other side.

+1 on that. The User’s guide of a similar device (source) mentions a 10-pin CPLD connector Reserved for IBM use

Maybe scrcpy is the tool for you then.

There is scrcpy for that and you can launch arbitrary commands from KDE Connect too.

I recommend “dnf automatic” to fetch the latest package index in background

Except if you ran the update from within a graphical session and your session crashed, as this will kill DNF, making the update incomplete and potentially corrupting files. I recommend you either:

• use the graphical updaters
• run dnf from a TTY
• or use some of the atomic spins, having atomic updates on btrfs subvolumes

You can do that, but it is not necessary.

Syncthing on Android has an option to only sync when on AC battery. The PC client might have a similar option. If not, you could probably configure something similar via systemd or udev under Linux.

I don’t think syncthing has proper means to synchronize contacts or anything else that’s not file-based though.

I use syncthing and prefer it for synchronizing files between my devices.

If you put microphones into the table, the audio will be horrible, catching up any surface acoustic waves from any noise on the table. Like if someone touches the table anywhere, this will be caught by the microphone. If someone puts down a hard item to the table anywhere (e.g. a pen, fingertips with fingernails, smartphone) you won’t be able to hear anyone in the room through microphones due to the transient noise.

More “conservative” in terms of preserving the planet’s resources.

You don’t need Gigabytes of RAM for almost any consumer application, as long as the programming team was interested/incentivized to write quality software.

Innovation is orthogonal to code size. None of the software most modern computers are running cannot be solved on 10 year old computers. It’s just the question whether the team creating your software is plugging together gigantic pieces of bloatware or whether they actually develop a solution to a real problem.