aaravchen

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.

It is just for thier wearables.

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).

One of the peer comments alludes to this and mentions that it's bash only. Doesn't work in zsh by default apparently.

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.

EDIT: typo

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.

Ironically the first implementation of ostree required an HTTPS server to serve the ostree commits, allowing a much smaller subset of what's needed to be transferred. However that became an adoption hurdle since it required unique infrastructure. Ostree switched to using containers because zstd allows compressed chunks now rather than the old all-or-nothing image layers, and the existing widespread container image registry infrastructure could be reused without modification. And both utilize layers for their construction so there were possible benefits there (that never really materialized, but are still available to pursue).

That is pretty obviously how it started, and for the very reasons you describe. But there have been some other benefits that have come out of going down this alternate path as well. In particular, the remote composability and local deployment is extremely useful for "cattle" edge system deployment. Installing a package reacts to what's currently on the system when installing. Even something as simple as the order you install your packages in can affect the result. Not having to run an entirely duplicate "golden" system to generate snapshots on and then push them to the cattle from is a pretty nifty benefit.

CoreOS is in a weird space. It's been desperately playing catch up with it's sibling products for the last few years, but it also is where a lot of the Fedora/RHEL developers in this space are focused primarily.

In fact, if you want to use something like Nix on a UniversalBlue system, you have to spin your own. The "hotfix" and chattr solutions of pre-composefs don't work anymore. Anything that needs to go into a read only location and isn't package as an RPM requires you to "spin your own".

Luckily UniversalBlue makes it incredibly easy, they have a template repo you can use that has all the GitHub action setup included to auto-bills on every change, and directions for how to set it up. It took me about 10 minutes

Basically you need a server, which you host, pay someone else to host for you, or you join am existing server someone else hosts. Then you find a client. There are a ton of clients around, but it's like picking a browser before Chrome ate the world. Tons of options and everyone has thier own opinions and information about them.

I have and it works great.

The developer is very active in updating and maintaining the software (both client and server), and it already supports most of the XEPs.

It's open source and fully supports self-hosted as first class, but if you want to support the developer he offers a cloud hosting paid offering as well. There's a crossover offer with JMP.chat too. If you pay $5 upfront for your first month of JMP.chat, you can get a free cloud hosted Snikket server for it to be setup on. As long as you maintain at least one number with JMP.chat, you keep the server maintained. If you don't, you get a chance to migrate your data. The Snikket cloud server gives you an XMPP server admin account, and you can setup as many accounts as you want. The caveat is that Snikket implementation is optimized for <1000s of user accounts per server.

One statement is not related to the other here.

Getting and maintaining an active phone number privately is indeed quite hard, partially by governmental design.

Signal only requires occasional/rare proof of control of the registered phone number. It also has very little visible data the provider can access on your account, even if they had a reason to assist in breaking your privacy by look it up from the phone number. Without Signal foundation direct support, the phone number linkage to your Signal account is completely opt in by you only.

So in terms of privacy, Signal is actually very good about the phone number and leaves it mostly to you how public you want to be about it. They're primarily using it as a finite controlled resource to limit how easy it is for people to spin up arbitrary new accounts. Other projects might use some cryptocurrency junk that effectively equates to paying for accounts, but Signal uses what you probably already have.

You could have a second actuve eSIM if you have a phone that supports more than one (no phones support more than 2 active simultaneously). Though technically the phone number only needs to be accessible for the initial account setup so I guess you could have a burner phone you switch out eSIMs on. Each Signal application only supports a single account though. So you can have one, and if you have a work profile you're not otherwise using you could have a second account in that instance.With the new Private Spaces you could potentially have a third as well.

So you _may_ be able to have up to 3 simultaneous Signal accounts on the same device.

I'm using my work profile and Private Space for things I can't share a Signal install with though. And I dont want to buy and maintain an extra phone number from a telco just to have another Signal profile.

XMPP has had less allure as "the new thing" since it's been around for a very long time. It was _the_ chat protocol in the 2000s when it started, and all chat apps used it (when AOL Instant Messenger, Trilian, Purple, Yahoo, ICQ, etc all interoperated). Vendor lock in started taking off not long after though, so Facebook Messenger (also originally XMPP) stopped interoperating and went fully closed along with a number of others, and the ones that interoperated didn't shift business models and disappeared. None of that means there's anything wrong with XMPP, it just means it's not in the public mind.

IRC has been getting the retro nostalgia kick start, and it briefly came back to attention when Slack started as "wrapper" of IRC. In my experience IRC channels are used by about 50% of open source projects, even though it's abysmal for access on mobile devices, very unfriendly for users, and extremely limited in functionality. About 50% of those have a bridge to Matrix so the mobile access is at least somewhat solved, and there are some more usable client options.

It seems because you haven't seen people already adopt it, you believe it must not be good. I'd encourage some basic research for your own benefit so you can see how XMPP is way easier to setup and maintain, far more efficient, and more capable than the oddly more commonly used Matrix/Element. In fact, between the organization issues of the last couple years, everyone finally getting fed up with Matrix being brittle, unmaintainable, and extremely inefficient to run on a server, I would expect Matrix support channels to drop off very rapidly over the next few years.

For Matrix clients I'm given to understand the issue is the lack of XEP equivalents. Either your server(s) and clients are all on the latest available version or you're SOL. This makes third party clients effectively impossible since every change is basically a breaking change and the client and server are tightly coupled.

XMPP took it a step further and has feature segmentation by defining XEPs. This is basic minimum for defining an extensible protocol for client-server communication and has been for decades (maybe it was a new idea when XMPP first started). Notably, browsers use this same thing with w3c specs, which is why they keep working too. If you don't have this feature segmentation and negotiation, you don't have a functional open source client-server protocol full-stop (looking at you Matrix).

I think what XMPP has gotten better at is doing like with w3c and setting baseline minimum features, which has allowed more standardization of clients.