Text makes sense. I mostly read it as “Terminal” and do not know what the original meaning is with a certainty. Looking at Wikipedia, the source of truth, it’s https://en.wikipedia.org/wiki/Text-based_user_interface . You probably right about it.

VIM - use Neovim instead

(just a joke)

Why? Can you give an example?

Yes. Think of any terminal application with an interactive user interface, that mimics a GUI. Something that is not just controlled by commandline options like grep and sed in example.

Hurd is even older and no one even makes jokes about it. At least with Linux there is a real chance this joke could become reality.

TUI: Terminal Text User Interface, something like htop in example. CLI: Command Line Interface, something like grep in example.

Edit: “Text” is probably the correct word, not “Terminal”.

You can also filter windows out of a screencast by choosing a special option from the pop-up menu that appears when right-clicking a window’s title bar:

An option to hide windows from Spectacle, when recording a screencast. Admittedly I am not much of a screencast person, but its good to know in case I need it as I have some future plans. So I could have some notes or the web browser open in same virtual desktop I am recording from.

• Snap - bad idea

Because Fedora likes to adapt the newest stuff very early. While it’s not like “very early” for BTRFS anymore, its still exceptional unusual to have it as the default in a mainstream distribution. And they want to benefit from the feature set of BTRFS, so it makes sense to use it as the default. Why shouldn’t the mainstream benefit from quick snapshots and backups? I don’t see the argument “are catering to mainstream audience” as to not use BTRFS?

I would say, if you want benefit from the features of BTRFS, then go for it. But you have to read a bit what it can do, and use tools and set it up to get the most out of it I think. EXT4 on the other hand is proven and is a setup and forget experience. I chose EXT4 when installing EndeavourOS, because I read a few things about BTRFS that made me think twice and also I don’t need the features too. So, if you don’t know and have to ask the community, then the best would be to us EXT4, unless you know why you want to have BTRFS features.

Or a rewrite in Rust.

What does perfect hello world even mean? It can be realized in many ways and none is the best way.

I don’t think such thing as perfect software exist, only abandoned software. If the environment changes, then the software needs changes too.

Ah I see, that makes it clear. I guess it is a “good enough” solution where it doesn’t matter in real world.

I assume they did that for performance reasons, because removing entries is slow probably? From user perspective, it would have made it more sense to remove the key instead defining it as nil and then expecting the user to handle the nil. The key does not stop existing, right? I don’t program in Lua.

For good reason.

I do not want to think about every possible error that can happen. I do not want to study every program I call to look for any possible errors. Only errors that are important to my task.

As I said, there are reasons to use this option when the script MUST fail on error.And its helpful for creating the script. I just don’t like generalizations to always enable this option.

Bash and the commandline are designed to work after an error. I don’t want it to fail after an error. It depends on the error though, and how critical it is. And this option makes no distinction. There are lot of commands where a fail is part of normal execution. As I said before, this option can be helpful when developing, but I do not want it in production. Often “silent” fails are a good thing (but as said, it depends on the type). The entire language is designed to sometimes fail and keep working as intended.

You really can’t compare Bash to a normal programming language, because the language is contained and developed in itself. While Bash relies on random and unrelated applications. That’s why I do not like comparisons like that.

Edit: I do do not want to exit the script on random error codes, but maybe handle the error. With that option in place, I have to make sure an error never happens. Which is not what I want.

In my experience this option is too risky. Making simple changes to the script without scientifically proofing and testing it works under all cases becomes impossible (depending on how complex the script and task itself is). It has a bit of the energy of “well you have to make no errors in C, then you can write good code and it never fails”.

This option is good if the script MUST fail under any circumstances, if any error return of a program occurs. Which is usually not the case for most scripts. It’s also useful in testing when debugging or when developing. Also useful if you purposefully enable and disable the option on the fly for sensitive segments of the script. I do not like this option as a default.

BTW here is an interesting discussion on Github about this topic: bash_strict_mode.md