As a long time Graphene OS user, I can tell you they don't. Almost no banks or credit card companies have a decent website even, let alone one that can replace thier apps.
So far I've yet to encounter any that have passkeys that could speed up the login process, and by using the website you've now fallen back to thier most involved login. You will have to login, then usually answer some security questions or complete a capture, then get the SMS code they sent you. Every time.
For async notifications, some banks support emailing or texting you, but it tends to be poor. Hopefully you don't have one of the credit cards like Citi or Amex, which require you to verify flagged purchases via thier app. Otherwise it's a 10+ minute process to do it via phone call, and you have to guess that's why the transaction didn't go thru, call them yourself, get it approved, and try again. Instead of just clicking "yes, that's me" in the app when they prompt you about fraud. And if you click it fast enough, the original transaction might not even get rejected.
So no, the banking websites are not at all good substitute. And it's especially bad for certain banks.
I find that both fail to find matches on anything long tail, but with Google/Bing/DDG I quickly start getting results that don't follow my search criteria. Probably one of the more useful features I wish all engines did was to acknowledge when they simply don't have results.
I'd say about 1 in 5 searches for me is apparently "long tail" and I've never been more aware of how dead the internet is. I regularly still compare to DDG and Google, and spend about 300% more time on the others trying to find a match and discovering I have more results only because they made my quotes terms optional or ignored my time restrictions.
Also, every company I've ever worked at, including ones producing regulated products like medical or home appliances, uses the beuracracy to take the stance of "Considered Risk". Rather than spending all the tone knowing for sure they comply, they make a "best effort" (the level of which varies a lot by company and industry) and bank on never getting closely questioned about the specifics. Releasing publicly is exactly that "closely questioned about the specifics" though.
BOMs are used when they're legally required or if the company has a sufficiently mature cyber security stance, but those both tend to focus mostly on shipped client code versus server-onlt code. Usually you end up with a highly fragmented set out different "BOMs" that are only present as language-specific lock files for the proteins of code that support it.
Lots of games are written in C++ to this day for example so they can eek out every bit of possible performance no matter the trickery required. I would presume this extends to server side of MMOs etc too. C++ has no standard build system even, it's sort of settled on CMake mostly, which has minimal native (working) support for dependencies even, let alone lock files and/or BOMs.
TPM locking is for ensuring the disk isn't removed from your machine. It's technically possible that someone could tap the hardware while the disk is still in your machine, but otherwise they're stuck contending with whatever other security setup you have on your machine.
The TPM locked disk encryption is more like embedding your safe in concrete with deep foundations. It doesn't affect the thickness or quality of your safe.
I think it basically died for general consumers because of the Canonical-only licensed software lock in, and consequent limited software support.
Snaps are hard coded to only be able to get snaps from the official Canonical-licensed store URL. Especially on Ubuntu Core, where everything can only be a snap. Even the commercial licensed version for embedding in products requires private companies to use a private space on the Canonical Snap store to distribute thier custom/proprietary software.
Absolutely no one is willing to let Canonical become the Apple Store of thier devices, especially given thier even shittier track record.
It's worth noting that at least EU vs US, most the the better quality EVs are not available. Almost all the long range and more efficient EVs are Chinese-made and are not available in the US. My understanding is that the vast majority of EVs in the EU are these Chinese-made ones because of their hugely superior performance.
I don't know if Canada has the same restrictions on EVs, and I definitely can't speak to longevity or quality of the Chinese-made EVs, only to the charging speed and range. BYD for example is one of these Chinese-made brands prohibited in the US but leading the industry in performance.
I try to keep a list somewhere, but I only pick one or two that are likely to be most useful and try to remember them until they're such a normal part of my workflow I don't have to think much about them anymore. Then I go back and pick a couple new ones to add.
The hard part is when you've reached the point where all your common use cases are covered and you're left with only uncommon cases. Then it's extra hard to remember you had a trick for dealing with the uncommon case.
I struggle with this all the time. It's easy to start with some shell commands, and nothing beats the direct terminal running nature of a shell script. But at some point you get to where you need to do things shell isn't good at, and the cost of maintaining that part can put weight the ease of direct terminal access. Especially if you then throw in the need to make your solution runnable on a lot of systems, you now have a problem with compatibility and possibly environment setup. On top of that, if you're really experienced and good with shell, the bar for "this is difficult" in shell gets further and further away, even if it's hard for someone else to maintain.
I've been investigating alternative options with bring-your-own-tool for this situation at $JOB, mostly making use of shebangs to trigger environment setup from self-contained utilities packaged with the scripts, and there are some promising options. Things like `uv` to setup a self-contained one-off python venv automatically so you can write in Python instead, possibly with one of the packages that helps with the many subcommands footguns, or to write `xonsh` if you want something more shell script leaning but with Python power. Or you can alternatively go with a language agnostic solution and use shebang triggered `nix-portable` to construct a whole isolated custom environment automatically from a flake.nix and run whatever tools and mishmash of languages you want.
You can install whatever shell you want on your system, and there are tons of better alternatives out there. Where it's actually sticky is in the lowest-common-denominator cases, when you need to throw together a quick series of commands that need to be run on a semi-arbitrary system. In that case there are VERY few options because you have to use whatever is already on the system. Sometimes you're lucky enough you can safely assume bash is present, but in many cases you have to assume only sh. Unfortunately both are a difficult/footgun enough language that it greatly helps to start out using it daily to get familiar, and that's where most people end up peaking. Additionally you may need to manually jump into that semi-arbitrary system and do things manually. You're limited by the minimal tools already there, so you better be familiar enough with them already. This is the very reason I've learned some basic Vi commands as well, even though I would never even consider using it otherwise.
In my experience Power shell is actually a terrible replacement because you have to learn not only every command, but the structured return and available input formats of every command in order to do anything. The design of almost all shells is specifically to avoid that and reduce to a common universal input/output format. Powershell could certainly be useful as an intermediate choice between a full blown language and shell scripting though, if you needed more power but not so much to make it worth the load of a real language, but would also require it to be ubiquitous already (which it's not).
It depends too on whether you use shellcheck as a primary tool or not. I prefer to have no shellcheck errors/warnings by default so when they do appear it's very obvious. But having a consistent opening block on a bunch of scripts is often more important, so setting a shellcheck disable on that one variable that may or may not be used is a better solution.
If you're using `set -e` you almost always want a trap on ERR to print where you suddenly exited from your program. Otherwise there's no way to tell.
Also worth mentioning, but not including permanently, is `set -x` which will print every command to stderr with a `+ ` prefix before running it.
For `DIR` I usually pick a name less likely to conflict with one randomly selected in my script, like `SCRIPT_DIR`.
You also need to think about symlinks and how you want to handle them. Your current `DIR` resolution gives you the directory name without any symlinks resolved. If you're possibly a script that got symlinked to by someone, this may not be the directory of your actual script anymore, but the directory containing the symlink. As long as you want that it's fine, but a lot of the time you want the script to see it's resolved folder so it can call scripts in the real folder with it instead
For me I find I never have any reason to jump between directories based on frecency. Like ever. If I'm jumping between a few directories they're almost always named very similarly and that causes problems with the frecency ordering, especially when they're deep paths that get truncated.
If I really happen to be jumping back and forth a lot, I use `pushd ...`, and then I can reference my other directory with `~1/` and toggle between the two with a bare `pushd`.
`set -e` is almost never what you want in your scripts. It means "silently exit immediately if there are any u handled non-zero exit codes". The thing that trips most people up on that is subshells when your trying to catch output into a variable, if it gets a non-zero exit code your entire script suddenly exits.
`set -e` really only makes sense if you setup a trap to also print what line you exited on, and even then only for debugging (e g. `trap 'echo "ERROR: Line $LINENO" ERR'`)
Conversely, `set -o pipefail` should be set in every script. It makes scripts with pipelines do what you expect, and the whole string of pipeline commands gets set to an error if any of the commands inside of it exit with an error. Default behavior for historical reasons is still to ignore all exit codes except the last command in a pipeline.
I did the same, starting with Ergo Mode in Emacs many years ago, and ending up today with a programmable split keyboard with those keys as arrows on a layer. For when I'm on a laptop without the keyboard, I have a mishmash of solutions that bind to Alt+{ijkl}
I have to say up front, that I think GrapheneOS in its most locked down mode needs to exist. There are important audiences for which most nation state actors and their related corporate entities are real threats (e.g. journalists). That said, I don't think the majority of users want or need that level of lockdown.
I do agree with the OP somewhat. While GrapheneOS has a hard job with too much to do and too few resources, they also take a very all-or-nothing stance when it comes to real world practicalities for the average user. Specifically: they're all or nothing on app stores and Google.
For some reason some of the key developers seem to constantly bash every "store" except Accrescent, ignoring the fact that Accresent is missing the key feature of telling you what you're even installing (which fails security 101: "you're only secure if you're usable and secure"). It's a very all or nothing viewpoint. No there is no secure app "store". None. Every one of them has security issues in one way or another. But short of an ultra locked down burner device for national secrets (a real use case in fact), users need to be able to get apps. The only "acceptable" solution seems to be to use the (patched) official Google Play Store. Which brings me to the second all-or-nothing area.
Google is the single biggest threat actor for most users. They control the upstream AOSP, so you start with constant attempts to compromise your supply chain in nefarious ways. They're one of the key gateways to the Internet, and they run the world's largest surveillance network (by a factor of many thousands). They're the very reason most users come to GrapheneOS in the first place. Every one of Googles apps is, or can safely be assumed to be, malware to violate your privacy as much as it can, and may incidentally provide some functionality. GrapheneOS has done well to replace many of the OS-baked in functionality that normally uses Google with alternatives, but is very adamant that they will not try to support allowing non-Google-signed apps in place of Google signed ones for any purpose. While I understand it ensures the AOSP feature of verifying against a trusted source, Google itself is not inf act a trusted source. It won't try and mine crypto on your device or use the passwords and wallet keys it steals to drain your accounts or steal your identity, but it will almost always cooperate with authoritarian nation states to install targeted surveillance tools on your devices instead of the "real" apps, and track all data it can possibly get access to. Sandboxing the system apps helps a lot, but as we know from Stock Android devices, that's not sufficient to completely protect systems from known malicious apps.
The counterpoint is always "then don't install any Google apps". Great, I'd love to. But I live in the real world where Google controls most of the electronic world, and everyone else has mandates Google usage. I need to control my level of exposure for my personal usage requirements and threat model, and neither 0 or 100 are feasible options. Just like almost all users.
I definitely understand from a practical sense that GrapheneOS doesn't have the resources to supply de-Googled version of Google Maps (unfortunately the only map navigation that works in most of the US still), or implement and maintain a rework of the binder and intents system to allow custom per-app filtering of all IPC. But I don't hear about the practicalities and maintenance costs (especially for complex drive-by contributions), or risks of accidental misuse causing severely degraded security. I only hear "that's not secure" (which is often incorrect for the actual user's threat model) as the reason something won't be supported, pursued, or allowed to be contributed.
All the immutable system solutions out there pretty much all make your rootfs immutable, but leave your home folder and system config folders (i.e. /var and /etc) as mutable. It's pretty obvious that if you make the config folders and/or home folder immutable it starts causing most people problems, since in the vast majority of cases people just want to be able to persistently change the desktop background color or spaces vs tabs setting in their IDE without having to locate the setting in a full system config, set it, and regenerate.
This does cause some interesting tension in the immutability though. /etc in particular is really a mix of things that a sysadmin should really only be setting, and things a regular user may set indirectly. This usage has grown organically over time with the tools involved in the implementation, so it's not at all consistent which are which. The immutable system solutions recognize this by usually handling the whole /etc folder the same way package managers handle package installs that include /etc file: by doing a 3-way merge between the old provided files, the new provided files, and the current existing files to see if the existing are unchanged from the old provided and can just be directly replaced by the new provided or if a merge conflict needs resolving. Additionally, a separate copy of /etc is maintained associated with each available bootable system version so when you roll back you get the old /etc files you had before. Though this does introduce a system-unique variation since you now have new /etc being affected by the state of /etc when it was forked.
If you want all your home folder and system config to be identical, nix or guix really are your primary way to go, that extra lockdown of the user and system config is exactly what most people don't want for usability reasons.
I personally use nix home-manager on top of Aurora DX from Universal Blue. I have my nix home-manager config setup to manage only the things I want to be locked down in my home config, and to provide some extra tools that are easier to manage/supply via Nix than a system package manager (where I would need to do a whole system update to get the new version). My IDE for example is installed on a specific version via Nix, but I don't have Nix manage the settings of it so I can separately tweak as needed without need a home-manager rebuild.
sysexts are indeed a very interesting feature, though it really only complements some other whole-system solution since it can only affect files under a non-root folder location.
I'm struggling to see how sysupdate is really equivalent to bootc or ostree though. Sysupdate is just the sw-update tool from Yocto that's been around for 10+ years with a little more syntax sugar, which itself was just a common shared implementation of what all embedded systems had been rolling-thier-own of for almost 20 years before that. It says it requires an A/B/.../N partitioning scheme, which is exactly what bootc/ostree/etc is designing to avoid.
If you don't use the whole disks update thing from sysupdate, then instead you're just talking about a transactional package manager that is still in its infancy and hasn't addressed the many gotcha and corner cases that the dozens of more mature package managers have. It's not actually "transactional" in the sense of undo for example, it's "transactional" only in that you won't get partial install, which hasn't been a problem with any existing package managers for almost 40 years. All thier listed things you can list together for a "transaction" association are either things that are already linked via existing package maager packages, or are only useful for embedded systems.
I'm not saying sysupdate isn't useful, upper end of embedded design is pushing into the space where systemd is standard now so it could be useful for those devices, but it's not really equivalent at all to bootc/ostree, and doesn't really have amt applicability outside initial system imaging from a live disk, or embedded devices.
So far I've yet to encounter any that have passkeys that could speed up the login process, and by using the website you've now fallen back to thier most involved login. You will have to login, then usually answer some security questions or complete a capture, then get the SMS code they sent you. Every time. For async notifications, some banks support emailing or texting you, but it tends to be poor. Hopefully you don't have one of the credit cards like Citi or Amex, which require you to verify flagged purchases via thier app. Otherwise it's a 10+ minute process to do it via phone call, and you have to guess that's why the transaction didn't go thru, call them yourself, get it approved, and try again. Instead of just clicking "yes, that's me" in the app when they prompt you about fraud. And if you click it fast enough, the original transaction might not even get rejected.
So no, the banking websites are not at all good substitute. And it's especially bad for certain banks.