Sorry, the most important thing about a language is readability and maintainability. Also speed writing bug free secure code is next. Speed of execution and sometimes memory use is next.
Not sure I would call Zim bare bones and it does basically most of what your asking. What I like about Zim is it can handle notebooks of many thousands of notes plus it is all just a folder tree in the file system which means you can use standard Linux tools and Python to do stuff if needed. Sadly not markdown.
I agree, Dems have not worked on generational change. Strangely when they put forward a candidate that is a younger generation, they loose to an old oligarch which favors neither the working class or the generational change.
Ironically, the GOP is not and never has been a working class party but a lot of working class people have moved there. What they have been able to do is talk to the working class and have much more folksie candidates. Plus large parts of the US is not ready for anything but a white male president.
I like Zim for large knowledge base collections. It is a desktop wiki. For quick short mobile notes I use Joplin. Never used it but logseq is taked about. It seems more of a Journal.
The site alternativeto.net can help learn more about a piece of software and the alternatives. I have not tried but can you download an extension and run it through VirusTotal? I use that for software all the time.
Like others said, less is more. Also use uBlock Origin to the fullest. It does most of what you need usually. Though it is a pain, I have also started using Noscript again too.
I get it. Credential storage and recovery is a big issue. People vary in skill, ability to keep track of keys or remember how to use them, and they may not have a password manager, safe deposite box, or other locked storage to store them in.
By the way, I would not consider logging in via ssh and running a bash script to be insecure in general.
However taking uncontrolled data from outside of that session and injecting it could well be insecure as the data is probably crossing an important security boundary.
I was more thinking of the CGI script vunerability that showed up a few years ago. In that case data came from the web into the shell environment uncontrolled. So uncontrolled data processing where the input data crosses security boundaries is an issue kind of like a lot of the SQL injection attacks.
Another issue with the shell is that all proccesses on the system typically see all command line arguments. This includes any commands the shell script runs. So never specify things like keys or PII etc as command line arguments.
Then there is the general robustness issue. Shell scripts easy to write to run in a known environment and known inputs. Difficult to make general. So for fixed environment and known and controlled inputs that do not cross security boundaries probaby fine. Not that, probablay a big issue.
Servers are harder and not preconfigued if you want unattended boot. The first key has to come from somewhere typically to unlock the root partition. The other keys can then be stored on that encrypted partition and are typically referenced by crypttab for auto unlock.
The first key can come from anywhere you want such as attached media like a flash drive, a over the network say via ssh, from a key server, or from the TPM. Or you could remotely connect to the console. There are bunch of how tos out there. It amounts to customizing the boot process and the initramfs. It is not simple. What makes sense depends on the threat model.
Disk encryption does not impact file sharing over the network.
Sure if you sharing by a USB portable drive you have to unlock and lock it every time you use it. That is separate thing though.
The bigger issues of encryption are one should have a good backup and recovery plan both for media and for the keys. One has to consider legacy planning too. How do your personal representatives access.
Android uses verified boot then encrypts the various profiles and the new private space seprately. This is how my GrapheneOS phone works.
Linux has a bunch of options. Ubuntu use to suggest per user encryption by ecryptfs but has since gone to partition based encryption via dm-crypt/LUKS. I still use either or both depending though ecryptfs seems depricated/discontinued and on the next upgrade I may discontinue.
Linux can support vaults too. Just locking certain folders. Encfs, and gocryptfs can do this for example. I use encfs though perhaps gocryptfs is a better choice these days. One can also use partition based solutions like dm-crypfs/LUKS or maybe even veracrypt too.
Bash is especially suseptable. Bash was intended to be used only in a secure environment including all the inputs and data that is processed and including all the proccess on the system containing the bash process in question for that matter. Bash and the shell have a large attack surface. This is not true for most other languages. It is also why SUID programs for example should never call the shell. Too many escape options.
Sorry, the most important thing about a language is readability and maintainability. Also speed writing bug free secure code is next. Speed of execution and sometimes memory use is next.
The order may vary depending on project.