disclaimer: I haven't actually looked... but...
Historically, it is those large "complete collection" torrents that survive on public trackers... and probably still exist.
Thus, (sorry to be blunt) why I think this project wouldn't really provide a lot of "additional value".
The fundamental problem with using torrents to share small files (which old ROMs are), is that content is only shared while seeding or leeching.
A torrents health works best, when people are actively leeching. You're not going to get that for 1 MB files.
You'll basically need to force people to seed and not just seed two copies (the default), but like 10:1, which means forcing all the users to chance their settings - which I'm doubtful of this happening on a large enough scale.
... and the pdfs proposed solution is:
3.2. The Retro Rush Event Torrents will rely on a community of active players and archivists. To prevent obscure games from having slow download speeds or freezing, a weekly community event will be announced and shown to encourage preservation efforts from the community.
Goal: The community unites to seed their favourite or obscure titles. This creates a predictable time where download speeds skyrocket, ensuring that even the rarest games remain available.
I don't think a rally of specific games is going to be enough to keep these torrents alive.
You'd basically need to run this as a private torrent, with upload/download credits and credit "boosts" for struggling torrents.
Or, as was rejected in the pdf, you use tor and create an "anonymous service" and host these small files, but the pdf is right in that tor is not the best tool for multi-MB files.
Anyway, I share your concern regarding the archiving of old games, but I'm doubtful this will help in a meaningful way.
Interesting, I'll take a look at it. It seems to tick all the same boxes as moonreader, but also works on Linux and Mac.
I was curious if KOreader worked on iPhones (AFAIK, it does not), but a FOSS alternative did, readest. I'll probably take a look at that too.
Moonreader Pro. It's an ebook readers for Android. The Pro/paid version has any feature you could ask for:
Any feature, I wish an ebook reader would have - moon reader delivered (but finding these features is not intuitive).
We are well on our way. The EU is holding the manufacturer liable if a cellphone radio is "modded", thus manufacturers are blocking the ability to unlock bootloaders.
If eventually, that is every phone, then grab a hotspot and get tethering.
I did have a chuckle at the thought of having a cellphone for your (modded) cellphone... but then I thought about it: "meh, yeah... it's not a bad idea. I'd do it."
Speaking of Lineage...
I wonder, how long will it be before you're not "allowed" to install esims on phones with custom firmware?
Either due to the esim application not installing/running on modified firmware, or the phone will just not allow it.
I completely agree with you on the second point. This is a problem for all languages, but maybe we (as a community) need to change the approval, reviewing process for adding new libraries and features to languages.
This isn't going to get any better unless we revert to OS based dependencies which noone wants to do because developers want the latest and greatest.
You're very succinct here: Developer do want the latest and greatest, even if the interface isn't perfect, and they'll need to refactor their code when the next revision comes out.
Languages often have much slower release cycles than 3rd party libraries. Maybe this is what needs to be improved.
There won't be a silver bullet, but I kinda like how kubernetes handles it: release cycles are fixed to a calendar (4 times per year). New features are added and versioned as alpha, beta, release. This gives the feature itself time to evolve and mature, while the rest of the release features are still stable.
If you use an alpha/beta feature, you accept that bugs and interface changes will occur before it reaches a stable release. .. and you get warning and errors, if you're using an alpha feature, but it graduated to beta/release.
Unfortunately, many languages either make this unnatural/difficult (ie: from future import... ) or really only support it if you're using 3rd party libraries (use whatever@v1.2.3-alpha1).
The way I see it, there are two problems with NPM:
The first issue might be solvable with things like WebAssembly. Then it's the developer who gets to decide how far these pm-hooks will reach (both interns of filesystem, network, etc) on a per project basis.
The second will need a shift in community mindset... and all these supply chain attacks are the fuel for that. Unfortunately, it needs to get worse before it'll get better.
If you're referring to Lemmy, this is what I do:
Eventually, you won't need to be adding more communities and you'll still be reaching the "end" of the doom scrolling.
Scott Pilgrim vs. the World has an awesome soundtrack.
The movie itself, has aged towards somewhere between mediocre and good.
I use 1Password at work. It pretty much ticks your boxes. With 1Password, a collection of passwords are referred to as a vault.
As the OP mentioned, it "just works" with everything.
My only gripes with it is that it's a bit cumbersome to log into the website (you basically have two passwords, plus mfa)... but if you've got the browser extension installed, it's painless. The other gripe I have is, it's tricky to have an overview of what passwords/vaults already exist. So, if you have enough people, it's inevitable that passwords will be accidentally duplicated - and no one will have a clear idea what was duplicated and who has access to it (unless you're a member/owner of a vault).
You mentioned you wanted something "hands-off", I think that after the initial setup, you'd get just that.