Bash. By default it might seem less featureful than zsh… but bash is a lot more powerful and extensible than some give it credit for. It might be more complex to set it up the way you like it, but once you do it, that configuration can be ported over wherever bash exists (ie. almost everywhere).

On Android 12 or later, apps will be autoupdated after the first install or first update, no root, no unlocking, no PrivExt needed. Older apps that can’t be updated will feature a banner explaining why.

Most old versions of the apps are not build to support that, and you’ll have to manually update each of those apps at least once (after they have been built with support for it). When checking most apps at the moment a banner appears showing how the app does not support automatic updates (yet?)

It’s changing by having a library like wlroots do most of the work.

When you consider the overall picture, “wlroots + compositor” is actually less complex than “X11 + window manager” because you no longer need to consider the insanely high requirements of having to have a team maintaining the spaghetti mess of X11 code.

Wayland-based dwl has roughly the same line count as X11-based dwm (about 2.2k), without having to depend on a whole separate service as big as X11.

But of course, it being a completely different approach, it’s likely that for most smaller projects (ie. not Gnome or KDE) it’s easier to start a new project than creating a layer to maintain two different parallel implementations.

If you want something that’s more or less compatible with openbox, there seems to be this project, labwc, which claims to be inspired by openbox and compatible with its config/themes… though I haven’t personally tried it.

Also keep in mind that openbox (and I expect labwc too) doesn’t include any “panels” / “taskbars” or anything like that… and it’s likely your X11 panels might not work well if they do not explicitly support Wayland (but I believe that, for example, xfce-panel now supports both).

espeak default voice backend is synthesized without using actually real voice samples. So it doesn’t require downloading a huge package for each language, which is convenient in some cases, but the outcome is extremely robotic.

You can use MBROLA as backend for espeak so that it uses some voice samples and the result should be less jarring (it’d still be easy to tell it’s not natural voice, but at least you’d be able to understand it better). There’s a tutorial on this here: https://github.com/espeak-ng/espeak-ng/blob/master/docs/mbrola.md

Or you can try piper (https://github.com/rhasspy/piper) it’s one of the most natural-sounding TTS (here are some samples).

I think part of the reason why the long extension is often preferred is because it’s much clearer and it’s guaranteed to be supported and decompressed by the respective tools. Even when they don’t suppot tar archives, they’ll just give you the uncompressed tar in that case.

It’s also very common to do that with other extensions (not just .tar) when compressing big files. For example, when archiving logs they’ll often be stored as .log.gz, which makes it automatically clear that it’s a log file directly compressed with gzip and meant to be examined with tools like zcat and zless to view it.

And in cases like that you really need it to be clear on what data does the gzip stores, since it does not keep metadata about the file so you might not be able to get back the original name/extension of the file if you rename the gz file.

If they were complaining about cronjobs being created (like the post says), then they must have known what cron is.