The dumps are just that: Dumps; 1:1 copies.
The tools don't decrypt anything; that happens within Yuzu. Why else would users need to provide the prod keys to Yuzu?
It’s illegal to circumvent copy protection under the DMCA (something I wholeheartedly disagree with), but it’s not illegal to make something that can be used to circumvent copy protection.
It is explicitly illegal to produce any thing whose purpose it is to circumvent DRM:
(1) No person shall manufacture, import, offer to the public, provide, or otherwise traffic in any technology, product, service, device, component, or part thereof, that—
(A) is primarily designed or produced for the purpose of circumventing protection afforded by a technological measure that effectively protects a right of a copyright owner under this title in a work or a portion thereof;
I'm telling you, that law is mental.
In fact, there are exemptions to that provision and one of them states that circumventing copy protection in order to play a video game using assistive technologies is legal.
Could you point that specific exception in the law? I can't find it.
Link for convenience: https://www.govinfo.gov/content/pkg/PLAW-105publ304/pdf/PLAW-105publ304.pdf
I really appreciate its existence but I wish the fediverse search was more than just a filter. It's not really representative of how the Fediverse works in that the top level results are instances with posts from entirely different communities beneath them.
I'd rather it grouped posts by community, no matter what instance they originated from.
It also returns a lot of unrelated posts IME; a lot more noise than i.e. Reddit and it doesn't appear well indexed.
They’re using the DMCA to say that because Yuzu lets someone circumvent their encryption (which is illegal, but shouldn’t be), that’s the same as Yuzu circumventing their encryption.
Yes, yes they are. That's how the DMCA works. It's mental.
That's rather clear evidence that they dumped their own ROM and distributed that. Since they own the rights to that ROM, they're not distributing it illegally though. They can dump and distribute their ROMs all they want; they own the rights to them.
Yuzu doesn’t include any form of tooling that breaks encryption
You cannot state that with certainty. That's the problem.
Yuzu does indeed include a method to use the Switch's production keys (which you must dump yourself) to decrypt the games. Whether this constitutes effective DRM is not a question that can easily be answered and must be decided by a court on a case-by-case basis.
This will be what the case will hinge on: Is Ninty's scheme effective DRM?
I would say no because symmetric encryption with a publicly known key may aswell be no encryption at all but that's not my decision to make.
They aren’t facilitating it, the user has to provide all of that chain of the emulation on their own.
Um, no. The emulator is doing the decryption on its own. All the user does is provide the prod keys and unmodified ROM.
“copied the game ROMs into Yuzu” Yuzu is not a VM or other container and the ROMs are simply stored on disk in their original dumped form… Yuzu doesn’t “store” or “contain” any games.
ROMs are indeed copied "into Yuzu". They must be loaded into Yuzu's memory in order for Yuzu to execute their code or render their assets. In copyright law, even loading something to memory constitutes a "copy".
Also, almost every emulator is a VM; do you think those ARM instructions are running on your x86 processor and its desktop OS kernel natively?
USB is not really a reliable connector for storage purposes. I'd highly recommend against USB.
I tried signing my own keys. I replaced them in the bootloader, but when I do the final step to lock them down, the TPM chip flushes the new keys and reissues fresh keys again
It may just be that the firmware of your particular board is buggy to the point of being broken.
You could try updating it but sometimes it's futile and the firmware is just the biggest pile of crap.
Indeed there are many times I “need my hand held” in order to take my first steps into a subject. I need an intellectually-intuitive foundation that is stable and I can build upon.
Absolutely reasonable expectation. I wish we had that.
why a user owned directory in root is needed
I initially glossed over the fact that you said "user-owned" here. It still shouldn't affect anything because nothing uses /nix for anything security-critical at any point but it'd certainly be smelly.
User-owned /nix is only the case in single-user installs which I believe have been deprecated for a while and certainly aren't the way to go anymore.
These days the preferred and default method is a multi-user install where /nix is owned by root there and exclusively managed by the privileged nix-daemon.
What it means for NIX in reference to configuration files, dot files, and my mental model of mess that belongs in /home/$user. While unfounded, I immediately worry root will somehow get cluttered with junk too. It is probably wrong, but I think of $user being largely sandboxed in /home/$user/
Nix (the package manager) itself does have some limited local state (cache, current profile link) that is put into the appropriate XDG user dirs. It will never touch anything outside of those specific state dirs, the TMPDIR and /nix.
Nix is designed to be fully contained in /nix. This property enables you to even wipe their entire root on every boot under NixOS.
Apps installed via Nix behave as they always do w.r.t. cluttering directories. openssh will still create and manage its ~/.ssh directory for instance, just like on other distros. If you ran some daemon that you installed via Nix with sufficient privileges, it may try to create its state directory in /var or whatever; just like the same daemon from any other distro's package would.
That is all to say: Nix does not do anything special here. Its packages largely behave the same as they do on any other distro and that behaviour includes state directory cluttering behaviour at runtime.
I don’t know what the SELinux context is for NIX, but I only have a limited grasp of SELinux from hacking around on Android to add things like busybox, and I know it is permissive but enabled in Fedora.
No SELinux support whatsoever.
There is somewhat explicit non-support even as Nix' model of files and directories does not include xattrs; you cannot produce a Nix store path that has special xattrs for SELinux purposes.
Metadata like permissions, dates and owner information are all normalised in the Nix store. The only permitted metadata apart from the file name is whether regular files can be executed.
If your system uses SELinux, you must add an explicit exception for the Nix store. (Installers may do that automatically these days, I haven't kept up with that.)
question how anything placed directly in the root directory of another distro will impact future updates from the packagers of the distro.
Other distros simply do not touch /nix; it's not their domain.
FHS distros control FHS directories such as /usr or /bin depending on what individual packages contain but no sane package of an FHS distro will try to control /nix/store/hugehash-whatever/.
Isn’t this against the Unix framework to place something directly in root?
Nix does many things that go against original design principles of Unix and that's a good thing. It's not the 70s anymore and some aspects of Unix have not aged well.
https://economicsfromthetopdown.com/2024/02/17/nixing-technological-lock-in/
trouble with Nvidia with a mainline kernel and kobold.
Using Nix for applications that have userspace driver dependencies on non-NixOS requires a hack unfortunately: https://github.com/nix-community/nixGL
I'd absolutely buy switch ROMs, even for 60€. Just gimme a damn download link.
Seeing Tears of the Kingdom actually run in 60 fps on the steamdeck
Uhh, you did not see that. It doesn't even get to 30 in most cases sadly.
The actual text for reference:
That explicitly only applies to physically disabled people. Yuzu is not specifically targetted at providing a different input method (at all) and certainly not solely for the physically disabled.
That exception is not relevant to this case.