The 6-month release cycle makes the most sense to me on desktop. Except during the times I choose to tinker with it at my own whim, I want my OS to stay out of my way and not feel like something I have to maintain and keep up with, so rolling (Arch, Tumbleweed) is too often. Wanting to use modern hardware and the current version of my DE makes a 2-year update cycle (Debian, Rocky) feel too slow.

That leaves Ubuntu, Fedora, and derivatives of both. I hate Snap and Ubuntu has been pushing it more and more in recent years, plus having packages that more closely resemble their upstream project is nice, so I use Fedora. I also like the way Fedora has rolling kernel updates but fixed release for most userspace, like the best of both worlds.

I use Debian stable on my home server. Slower update cycle makes a lot more sense there than on desktop.

For work and other purposes, I sometimes touch Ubuntu, RHEL, Arch, Fedora Atomic, and others, but I generally only use each when I need to.

Nintendo has repeatedly done things like this.

The original Wii supports GameCube controllers, the Wii U supports Wii Remotes, Wii U and Switch both support USB GameCube controller adapters, and NES/SNES Classic Edition Mini systems support the Wii Classic Controller. Switch Lite supports pairing Joy-Con too, despite having no rails for them.

Wii U goes so far with Wii Remote support that Nintendo usually treated it as the preferred way for extra players to join local multiplayer, moreso than its own Pro Controller. Wii games were more limited with GC controller but still supported it in a few big titles like Brawl and Mario Kart Wii.

DisplayPort 1.2 and later is very much not an open and free standard. Access to the specification is locked behind an NDA and a VESA membership that costs thousands of dollars annually.

DisplayPort 1.1a is a freely available standard and has enough bandwidth to support a single display at either 1080p/150Hz, 1440p/90Hz, or 4K/30Hz. Any higher than that and it's proprietary. Still, VESA doesn't seem to be as restrictive about its standard as the HDMI Forum, which goes so far as to deliberately prohibit HDMI 2.1 in anything open-source (foss drivers like Nouveau can only work with it if the actual support is handled by closed-source firmware).

VESA's fees are for the membership itself rather than per-device like HDMI's are, but a completely separate organization that's unrelated to the DP standard tries to charge per-device license fees on all DP devices. MPEG LA demands $0.20 per DP device for protection from their patents, which is much higher than the HDMI per-device fee, but the claims that their patents apply at all seems to be disputed.

too long have we accepted 60$ games with 20$ DLC, I'm glad if this means devs can just charge 80$ for a full game.

Breath of the Wild was a $60 game with $20 DLC when it launched in 2017. Eight years later, its Switch 2 Edition is now a $70 game that (seemingly but not yet 100% confirmed) still has the same $20 DLC sold separately. This is a game that already sold enough copies to earn back over 16 times its development cost.

As for Mario Kart World, I'll be surprised if Nintendo doesn't announce DLC plans in its upcoming presentation two weeks from now, but that remains to be seen.

Those two aren't actually considered main series Pokémon games. They're the only side games that can catch and train Pokémon that can be traded into the main series games. Pokémon Stadium is a similar release that's already on the Nintendo Switch Online N64 app.

It remains to be seen whether Pokémon Home gets an update to support these GC games.

I very much doubt the main series games will ever be added to the NSO GB/GBA apps. It seems likely enough that they'll rerelease the classic games in some form on Switch next year for Pokémon's 30th anniversary (similar to how 3DS got the GB ones for the 20th in 2016), but I fully expect that the release will be under The Pokémon Company's terms rather than a part of NSO. Either as part of the Pokémon Home subscription or sold on eShop.

Nintendo has already been selling a small selection of GameCube and Wii games that run emulated on Switch's processor (Tegra X1) in 1080p.

• On the Switch itself: Super Mario 3D All-Stars runs emulators for Mario Sunshine (GC) and Galaxy (Wii)
• On the Nvidia Shield TV, which uses the same processor: Twilight Princess (GC), NSMB Wii, Punch-Out (Wii), Mario Galaxy (Wii), Donkey Kong Country Returns (Wii). Only available on Shield systems sold in China.

The Dolphin emulator can be installed on Nvidia Shield (Android) and, thanks to modding, on exploitable Switch systems as well.

However, this newly announced library of GameCube games is only for Switch 2, which has drastically more powerful hardware than the 8-year-old original Switch.

Just go through F-Droid or Flathub and look at the long list of apps that haven’t been updated in years.

"not updated in years" didn't used to be considered a bad thing. Why is it one now?

If something works well for me as it is and runs locally in a way that doesn't open itself up to remote exploits, I don't necessarily need it to keep changing all the time. Even if it would be nice if it had more features, the software works fine for me as it is. I don't need those updates now or this year.

The only true "need" is that it doesn't stop working for me when the various platforms or compilers change. I used to use a Python2 program, and I could keep using it for about a decade after its last update, but eventually I did need to move past it because Python3 had long since replaced it and distros stopped shipping Python2. A year or two of no updates it's nothing.

If the only problem is that you can't use dynamic linking (or otherwise make relinking possible), you still can legally use LGPL libraries. As long as you license the project using that library as GPL or LGPL as well.

However, those platforms tend to be a problem for GPL in other ways. GPL has long been known to conflict with Apple's App Store and similar services, for example, because the GPL forbids imposing extra limits that restrict user freedom and those stores have a terms of service that does exactly that.

Of all possible names, they're really using "Core 2 Duo"? I feel like anyone who has been following tech long enough would immediately think of the Intel processor when hearing that name.

If it was a community addition why would it matter? And why would they remove the codecs.

You don't have to be a corporation to be held liable for legal issues with hosting codecs. Just need to be big enough for lawyers to see you as an attractive target and in a country where codec patent issues apply. There's a very good reason why the servers for deb-multimedia (Debian's multimedia repo), RPM Fusion (Fedora's multimedia repo), VLC's site, and others are all hosted in France and do not offer US-based mirrors. France is a safe haven for foss media codecs because its law does not consider software patentable, unlike the US and even most other EU nations.

Fedora's main repos are hosted in the US. Even if they weren't, the ability for any normal user around the world to host and use mirrors is a very important part of an open community-friendly distro, and the existence of patented codecs in that repo would open any mirrors up to liability. Debian has the same exact issue, and both distros settled on the same solution: point users to a separate repo that is hosted in France which contains extra packages for patent-encumbered codecs.

I stopped using Arch a long time ago for this same reason. Either Fedora (or derivatives like Nobara) or an atomic/immutable distro (like Bazzite, Silverblue, Kinoite) is probably the way to go.

I used to feel like Ubuntu was a good option for this, but it no longer is: too often they try to push undesirable changes that need manual tweaking to fix after release upgrades. Debian Stable is generally good for low-maintenance use but doesn't keep up as well with newer hardware or newer updates to video drivers and mesa, which makes it suboptimal for typical gaming use. Debian Testing can be prone to break things in updates (in my experience, worse than Arch does).

I saw another comment recommend Rocky/RHEL, but note that their kernel doesn't support btrfs. Since you mentioned a root snapshot, I expect you probably use it.

I was only talking about high core count and high (relatively speaking) single-core performance. The DeepComputing Framework board is neither. Its JH7110 is only 4 cores and a rather old processor, which seems like an odd choice for a product releasing in 2025. At least the software support is great since distros have been working with VisionFive 2 and Milk-V Mars for years.

It's also the only currently-available Framework 13 board with fewer than 6 cores, though core count isn't remotely comparable between architectures. At this price ($209 for lone board with 8GB RAM, $799 for full laptop) I'd prefer to see something at the very least comparable to SpacemiT K1, which has 8 cores and vector support, and is on the Banana Pi BPI-F3 (8GB version is $95).

I'm only aware of one RISC-V system where I can say the core count is there: the Milk-V Pioneer board and its 64-core SG2042 processor from two years ago. It's comparable in price to a 64-core ARM Ampere CPU+motherboard (USD$1500 for the board), which seems somewhat reasonable when not considering the performance of each core. Hopefully the C930 core described in this article leads to more systems that aim for multi-core performance.

Most RISC-V development boards are only 4 cores or fewer, with just a few popping up in the last year with 8 cores and nothing higher besides the SG2042. The best single-core RISC-V performance so far is on the SiFive P550 but it's only 4 cores and comes on a development board that costs USD$500 (plus another $150 for tariffs if shipping to the US). You could easily get a 12-core AMD CPU and motherboard combo for less than that.

Jerboa has the same lead developers and is part of the same GitHub organization as the Lemmy server and web UI.

The logo for Lemmy itself is the head of a rodent, supposedly a lemming. Most instances use that logo or a variation of it in their web UI. Jerboa and other apps in turn tend to use a rodent in the logo.

If you have a rooted Android device or a jailbroken Kindle device, yes, you can still use Calibre DeDRM and KFX Input plugins on the kindle ebooks downloaded on them. It just takes a bit more setup with getting the key you need.

Unfortunately, DMCA takes an extreme stance when it comes to anti-circumvention. Even personal backup doesn't have a strong legitimacy case under it, especially not when it comes to the tools that enable it.

Very related to this, LockpickRCM is a tool whose entire purpose is to extract your own Switch keys for the titles you own, and in turn is far more useful for people who want personal backups than those who are pirating the games. Still got a DMCA takedown two years ago, and though it never went to court it's extremely unlikely any court would have ruled in their favor if it did.

2026 is the 30th anniversary of the Pokémon series. They've always done new generations on the big anniversaries: Diamond/Pearl (gen4) for the 10th in 2006 (in Japan) and Sun/Moon (gen7) for the 20th in 2016. It would likewise be fitting to release the next generation in 2026 rather than this year.

I also believe we would have already seen a Z-A reveal trailer before the end of the 2024 if it was truly slated for a date as early as spring or early summer. Holding off on showing or saying absolutely anything since the teaser last February seemingly implies it's Game Freak's one big title for the year that'll be the main focus this time.

I have not once ever seen anyone shorten the name of a Debian release like that and I've been following/using Debian things for two decades.

Squeeze, Wheezy, Jessie, Stretch, Buster, Bullseye, Bookworm, and Trixie aren't "ds", "dw", "dj", "ds" again, "db", "db" again, "db" for a third time in a row, or "dt". Both stable and sid are "s" too.

For what it's worth, the "Download & transfer via USB" feature was applying DRM locked to the key of the specific Kindle device you select, giving you a file that's incompatible with other devices even if they're kindles linked to the same Amazon account. For many publishers it also gives files with drastically lower image quality than the Kindle app: about one-fourth to one-third the file size. For a couple examples, a 368MB KFX manga volume has a 125MB AZW3 file and an 8.0MB KFX light novel has a 2.2MB AZW3 file. Those smaller AZW3 files are also similar in size to DRMed EPUB files of the same books from other markets like Kobo and Google Play, so I expect it's a deliberate choice to limit the quality of formats that are more trivial to strip DRM from.

The best way I've found to make personal backups of owned Kindle content is to use a rooted Android device to download everything through the Kindle app, copy the KFX files to a computer, extract the key in a root shell, and then use DeDRM tools on those files with that key.

A quick and dirty shell command I've used for that purpose is egrep -ao 'dsn[0-9a-f]{32}' /data/data/com.amazon.kindle/databases/map_data_storage.db. The key is 32 hex characters.

Having a rooted Android device in the first place is the biggest hurdle for being able to do that. This new jailbreak should make it possible to do something similar with e-ink kindles instead.

Don't assume Qualcomm's general hostility to user control and freedom is representative of all non-x86 systems.

This system isn't like that at all. It's usable with mainline Linux and mainline U-Boot and has no proprietary driver blobs. Granted, RISC-V has some more progress to make in terms of boot image standardization, and this board in particular uses an old SoC from three years ago (JH7110) which predates a lot of improvements that have been happening to various intercompatibility-focused RISC-V standards.

For some of the most recent ARM systems (notably excluding Qualcomm junk), I can write a single installation image for a Linux distro of my choice to a USB drive and then boot that single USB drive through UEFI on several completely different systems by completely different vendors. Ampere, Nvidia, and more. ARM's SystemReady spec results in exactly the same user-friendly process you're used to on x86.

The RISC-V ecosystem isn't there yet though its very recent RISC-V BRS (Boot and Runtime Services) spec promises to bring that for near-future hardware. But this DeepComputing board doesn't have that and doesn't have some other features (vector instructions, RVA22/23, etc) that are very likely to become the minimum requirements for several RISC-V Linux distros in the not too distant future.