aaravchen

Since no one is explaining:

Cleanuparr uses the built-in Sonarr/Radarr blacklist feature, so if you encounter something where there's nothing to import, it will backlist the torrent. You can set it to cover stuck torrents too if you want, so it blacklists the "dead" torrents and will make Sonarr/Radarr move on and search again.

The blacklist feature of Sonarr/Radarr can be hooked into Prowlarr pretty easily so that the torrents get blacklisted all the way back there.

You should definitely add wildcard blocks to your torrent client too though for *.exe and similar so you don't even download them in the first place rather than throwing them away only after downloading.

You might want to combine this with something like Packarr too, unless you just want to blanket blacklist all archives (zip, rar, etc). Packarr will try to (semi-securely) unpack archives after download. If they fail to unpack (e.g. requires a password you haven't supplied, badly formatted, etc), the Cleanuparr will end up marking them as failed import and they'll get blacklisted and removed from disk.

Also, you should generally manually blacklist things in Sonarr/Radarr if you discover it's bad, rather than just deleting it from disk. That will also prevent the same thing from re-downloading.

I would actually argue the exact opposite. All of the Chromium-based forks are a usability disaster. I have to use grid view only to see my tabs? It took them most of a decade to finally get the relatively common place bottom bar, and it still arbitrarily decides to ignore your setting if it thinks your screen is "too big"? It's just failure after failure. I absolutely dread when some shitty site I'm forced to use refuses to load in anything but chrome and I have to open up Vanadium for the first time in forever.

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.