zarenki
This argument is even more ridiculous than it seems. During the copyright office hearing for this exemption request (back in April), the people arguing in favor of libraries talked about the measures they have in place. They don't just let people download a ROM to use in any emulator they please. It's not even one of those browser-based emulators where you can pull the ROM data out of your browser cache if you know how. It's a video stream of an emulator running on a server managed by the library, with plenty enough latency to make it very clearly a worse gaming experience.
It's far easier to find ROMs of these games elsewhere than it is to contact a librarian and ask for access to a protected collection, so there'd be no reason to redistribute the files even if they were offered, which they aren't.
On top of that, this exemption request was explicitly limited to old games that have been long unavailable on the market in any form, which seems like an insane limitation to put on libraries, places that have always held collections of books both new and old.
All of that is still not enough to sate the US Copyright Office, the ESA, AACS, or DVD CSS. Those three were the organizations that fought against this.
Newer than C99? Both the Linux kernel and systemd build with gnu11. I'd call those pretty relevant.
C23 is still far too new (still a draft) for any major projects that care about compiler compatibility.
The Y axis here is not an absolute international political compass. It measures which political party each person favors, and judging by that country's local standards categorizes that party as either left or right.
A rising number in the US chart means a larger number of people prefer democrats over republicans. It doesn't mean that people's stances are necessarily moving further left. Similarly, it's no coincidence that the inflection point where UK numbers rise by a lot correspond to Brexit: the party seen as responsible for the unpopular change lost a lot of support, but that doesn't mean the population has so sharply moved drastically more progressive in such a short time.
Anbernic devices in particular are known to ship with an SD card that's preloaded with a fairly large game library. I own a RG351M which did indeed include a cheap card loaded with both the OS and a collection of games by Nintendo, Sega, and many others, plus some strange rom hacks. I immediately swapped that card out for a better one with a better CFW and my own files.
Most other notable names in the emulation handhelds space like Retroid, Ayn, and Ayaneo expect users to be able to provide their own files instead, which I'd say makes more sense.
My best guess: whatever they're filing now was so exhaustively researched that it took months to prepare the strongest case they're able to make, possibly delayed by the lawyers working on several other cases. Plus waiting until sales have dried up can maximize damages.
Another possibility is that Nintendo/TPC is planning to make some big Pokémon announcements soon and wants to target this shortly before their own new games to reduce competition. Palworld might seem like more of a threat to the execs now that Pokémon is nearing a major release than it was in the middle of a long drought for the series.
USB-C video is usually DisplayPort Alt Mode, which uses a completely different data rate and protocol from USB.
Even using old 2016 hardware, a computer and USB-C cable that both only support 5 Gbps USB (such as USB 3.1 Gen 1) can often easily transmit an uncompressed 4K 60Hz video stream over that cable, using about 15.7Gbps of DisplayPort 1.2 bandwidth. Could go far higher than that with DP 2.0.
Some less common video-over-USB devices/docks use DisplayLink instead, which is indeed contained within USB packets and bound by the USB data rate, but it uses lossy compression so those uncompressed numbers aren't directly comparable.
For that portable monitor, you should just need a cable with USB-C plugs on both ends which supports USB 3.0+ (could be branded as SuperSpeed, 5Gbps, etc). Nothing more complicated than that.
The baseline for a cable with USB-C on both ends should be PD up to 60W (3A) and data transfers at USB 2.0 (480Mbps) speeds.
Most cables stick with that baseline because it's enough to charge phones and most people won't use USB-C cables for anything else. Omitting the extra capabilities lets cables be not only cheaper but also longer and thinner.
DisplayPort support uses the same extra data pins that are needed for USB 3.0 data transfers, so in terms of cable support they should be equivalent. There also exist higher-power cables rated for 100W or 240W but there's no way a portable monitor would need that.
A related issue I still see very often, even with files newly created just this year, is when trying to extract zip files on my Linux systems that contain non-ASCII filenames and that were created on Windows systems, especially ones with apparently non-English locales like Japanese. Need to trial and error the locale I give to unzip and sometimes hack together fixed names with iconv until the mojibake seems to fix itself.
The whole point of copyright in the first place, is to encourage creative expression, so we can have human culture and shit.
I feel like that purpose has already been undermined by various changes to copyright law since its inception, such as DMCA and lengthening copyright term from 14 years to 95. Freedom to remix existing works is an important part of creative expression which current law stifles for any original work that releases in one person's lifespan. (Even Disney knew this: the animated Pinocchio movie wouldn't exist if copyright could last more than 56 years then)
Either way, giving bots the 'right' to remix things that were just made less than a year ago while depriving humans the right to release anything too similar to a 94 year old work seems ridiculous on both ends.
a variable-length integer encoding that somewhat resembles what they do in UTF-8. It means for strings < 128 chrs, the length is a single byte. Longer than that and more bytes get used as necessary.
What you used might be similar to unsigned LEB128, which is used in DWARF, Webassembly, Android's DEX format, and protobuf. Essentially encodes 7 bits of the number in each byte, with the high bit being 1 in any byte except the last one representing the number.
Though unlike UTF-8 the number's length isn't encoded in the first byte but instead implied by the final byte. Arguably making the number's encoding similar to a terminated string.
Btrfs doesn't have encryption, so you need to do it with luks to an mdadm raid, and build btrfs on top of that. Luks on mdadm raid is known to be slow, and in general not a great idea.
Why involve mdadm? You can use one btrfs filesystem on a pair of luks volumes with btrfs's "raid1" (or dup) profile. Both volumes can decrypt with the same key.