- 0 Posts
- 49 Comments
In a single one-off program or something that’s already fast enough to not take more than a few seconds—yeah, the time is spent better elsewhere.
I did mention for a compiler, specifically, though. They’re CPU bottlenecked with a huge number of people or CI build agents waiting for it to run, which makes it a good candidate for squeezing extra performance out in places where it doesn’t impact maintainability. 0.02% here, 0.15% there, etc etc, and even a 1% total improvement is still a couple extra seconds of not sitting around and waiting per Jenkins build.
Also keep in mind that adding features or making large changes to a compiler is likely bottlenecked by bureaucracy and committee, so there’s not much else to do.
Not necessarily. It depends on what you’re optimizing, the impact of the optimizations, the code complexity tradeoffs, and what your goal is.
Optimizing many tiny pieces of a compiler by 0.02% each? It adds up.
Optimizing a function called in an O(n2) algorithm by 0.02%? That will be a lot more beneficial than optimizing a function called only once.
Optimizing some high-level function by dropping into hand-written assembly? No. Just no.
To offer a differing opinion, why is null helpful at all?
If you have data that may be empty, it’s better to explicitly represent that possibility with an Optional<T> generic type. This makes the API more clear, and if implicit null isn’t allowed by the language, prevents someone from passing null where a value is expected.
Or if it’s uninitialized, the data can be stored as Partial<T>, where all the fields are Optional<U>. If the type system was nominal, it would ensure that the uninitialized or partially-initialized type can’t be accidentally used where T is expected since Partial<T> != T. When the object is finally ready, have a function to convert it from Partial<T> into T.
To be fair to PDFs, they can contain JavaScript. Blame Adobe for that and their originally-exclusive-to-Acrobat extension for that.
If he had said “LaTeX” or “roff”, that might have been a good example of something that blurs the line between the two. They aren’t specifically intended to be programming languages, but with a powerful enough macro system, a markup or typesetting language can be used in the same way as something like Brainfuck.
It also helps to outwardly state your country of residence in a public forum.
Yeah… I looked at the project’s subreddit, and I don’t expect it to last long. The creator’s idea of avoiding Nintendo’s legal team boils down to “assert emulation is legal and condemn piracy within our dev team and community.”
I don’t mean to be a dick, but I don’t think the guy knows what he’s doing. The only way an actively-maintained fork is going to avoid the same fate is if they either give up before Nintendo cares, or:
- Stripped out the code that gave Nintendo’s argument validity in the first place;
- Did not make money off the project; and
- Stayed far the hell away from retail game emulation, focusing on perfect compatibility for homebrew entirely.
Even then, there’s a good chance they’re screwed either way. The original Yuzu devs agreed to Nintendo’s terms of explicitly naming Yuzu as a circumvention tool. Settlements don’t serve as precedent, but I suspect it’s going to be extremely hard to argue that a minimal derivative of a circumvention tool is not still a circumvention tool when the original creators stated they designed it as such.
I also have a post going on !technology@lemmy.world about this: https://lemmy.world/post/12728165
Almost. The technical stuff is going to be a bit butched, but I’ll drop the legal speak and be more human for a minute:
What makes this unique isn’t that Nintendo is going after them for providing the keys, but for actually using them. Yuzu asks the user to dump or acquire prod.keys on their own, and then it uses that to read encrypted data. The fact that it does that, regardless of whether the keys were obtained legitimately or not, is where the argument that it’s a DRM circumvention tool lays. Yuzu itself is supposedly “circumventing” Nintendo’s DRM process by using the keys in a way that bypasses all of the protections that Nintendo put into place to prevent the games from being loaded on non-Switch hardware.
The Yuzu devs’ willingness to have FAQs and a quick start guide explaining the requirements and steps to emulate commercial games on Yuzu is definitely going to bite them and undermine any defense they had for not knowingly marketing it as a circumvention tool. Another criterion is that Yuzu has to have some commercial significance if it were to lose its ability to circumvent DRM. And, as we know, it’s an emulator…
The best chances they have is to convince the judge that Yuzu isn’t primarily designed as a circumvention tool (which, once again, isn’t helped by their guide on how to run commercial games) or that it falls under the accessibility exemption added recently.
Unfortunately, Nintendo has some decent counterarguments for those defenses.
-
17 USC §1201 (a)(2)(B) can be left up for interpretation around its phrasing. If you interpret the condition to meet the criteria being Yuzu must not serve a commercially significant purpose other than to facilitate circumvention of DRM, that actually works against Yuzu. The emulator itself serves no commercial purpose, which suggests it has no reason to exist other than to circumvent technological measures.
-
For as much as Nintendo hates third-party, unlicensed peripherals, they could point to the 8bitdo adapter and plethora of disability-friendly Xbox/PS5 controllers to weaken that argument. If the primary purpose of Yuzu was to fill a gap in accessibility, Nintendo could argue that Yuzu would have stopped development once other options became available.
-
17 USC §1201 (f)(1) only applies to (a)(1)(A). That protects the developers in creating the emulator, but Nintendo’s lawyers would remind the court that they’re suing under (a)(2), which also includes distribution of circumvention tools.
It gets even more bleak.
-
Nintendo could demonstrate Yuzu fulfills (a)(2)©—the marketing of the product with the knowledge that it’s used for circumvention—by referring to Yuzu’s own documentation on its wiki and setup guide instructing users that they will need to dump and use
prod.keysto play games. -
The last criterion needed is (a)(2)(A)—which is that Yuzu was primarily produced to circumvent DRM. Yuzu’s documentation and guide do not work in its favor, and the preservation/interoperability argument is weakened by the fact that the console is still readily available in retail. There’s a good chance they can’t even successfully argue it was created for development purposes. They would need to have a stronger argument than Nintendo’s lawyers, and it’s going to be really difficult to claim it was made to make Switch development/debugging more accessible than Nintendo’s official devkit when they’ve never (for obvious reasons) had access to the official devkit or went through the process of applying for one.
If it goes to court, Yuzu would need some really deep pockets, good lawyers, and a technologically competent judge. I hate to say it, but the most likely outcome, in my opinion, is a settlement giving Nintendo exactly what they want.
I would love to see the EFF or some philanthropic multimillionaires bankroll Yuzu throughout this and set a precedent in their favor, but like you said, it seems way less realistic.
Nintendo’s argument in the filing is that Yuzu is designed primarily for circumventing the Switch’s encryption (a.k.a. copyright protection measures). Their justification is that Yuzu uses prod.keys to decrypt various things like the ROM filesystems and the system firmware*. Ryujinx also uses prod.keys, so they would be just as legitimate of a target for that argument as Yuzu is.
Personally, I think they chose to go after Yuzu first because it’s more popular and runs at playable framerates on modern Android devices. If the lawsuit goes in Nintendo’s favor, I guarantee they’ll immediately use that precident to make the same argument against and swiftly kill Ryujinx.
*This is actually a valid argument that is not affected by past suits like Bleem v. Sony.
Unfortunately, it’s more of a gray area than most people think.
17 USC §1201 (f)(1)
Notwithstanding the provisions of subsection (a)(1)(A), a person who has lawfully obtained the right to use a copy of a computer program may circumvent a technological measure that effectively controls access to a particular portion of that program for the sole purpose of identifying and analyzing those elements of the program that are necessary to achieve interoperability of an independently created computer program with other programs, and that have not previously been readily available to the person engaging in the circumvention, to the extent any such acts of identification and analysis do not constitute infringement under this title.
Ok, and that applies to…
17 USC §1201 (a)(1)(A)
No person shall circumvent a technological measure that effectively controls access to a work protected under this title.
And a technological measure is:
17 USC §1201 (a)(3)
to “circumvent a technological measure” means to descramble a scrambled work, to decrypt an encrypted work, or otherwise to avoid, bypass, remove, deactivate, or impair a technological measure, without the authority of the copyright owner; and
Perfect! Right?
17 USC §1201 (a)(2)
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 a technological measure that effectively controls access to a work protected under this title;
(B) has only limited commercially significant purpose or use other than to circumvent a technological measure that effectively controls access to a work protected under this title; or
© is marketed by that person or another acting in concert with that person with that person’s knowledge for use in circumventing a technological measure that effectively controls access to a work protected under this title.
And unfortunately, Yuzu is capable of and needs console keys to decrypt games and system firmware files.
The reverse engineering for interoperability exception, (f)(1), only explicitly exempts (a)(1)(A) for research purposes. If Yuzu—as a software product—is found to have the primary purpose of circumventing Nintendo’s DRM, it will be in violation of (a)(2) and the developers are not protected.
This is something that will need to be tested in court, but the only way they would be entirely in the clear is if they stripped out all encryption/decryption code and forced users to use some other tool to fully decrypt the firmware, NAND filesystem, and game image filesystems during dumping. They’ll likely argue that the primary purpose is preservation, and Nintendo will use the fact that the Switch is still sold in retail as a counterargument to suggest that their development of the emulator was unnecessary and not in good faith. If they instead argue that it was created as a development or debugging tool, Nintendo could point to their low barrier of entry for developers to obtain a devkit (as evidenced by the crapton of shovelware and asset flips in the E-Shop).
If they don’t settle, it’s going to be an expensive mess to sort out.
Nintendo give an example in their complaint with The Legend of Zelda: Tears of the Kingdom saying that it was “unlawfully distributed a week and a half before its release by Nintendo” and that copies of it were “successfully downloaded from pirate websites over one million times before the game was published and made available for lawful purchase by Nintendo”.
Back when I was on that shithole other link aggregation website, I said this would happen because people couldn’t wait 7 more days for the public release before bragging about emulating TotK and sharing a clearly-not-legally-dumped ROM around.
I don’t care what people do in their free time as long as it doesn’t affect anyone else negatively, but it was hard not to see this coming because people couldn’t keep their mouths shut and just enjoy the game. Now, we all might lose future updates to Yuzu if they settle or Nintendo wins the suit…
I don’t remember what it said exactly, but here’s a rough description:
Image Description
It’s the King of the Hill if those kids could read they’d be very upset meme, with the piece of paper saying “JPEG XL memes” and the kids in the classroom being labeled “Android users”.
As an Android user, OP’s image was accurate.
- My Lemmy app couldn’t open it.
- Chromium showed the broken image icon.
- Firefox said it was broken.
- Firefox Beta with the about:config flag for enabling JXL still said it was broken.
- Gallery apps couldn’t open it.
- Renaming it to
.jxlstill didn’t help.
I gave up and grabbed a JPEG XL viewer/converter just to see it.
Here at Company Inc, we continue to send our thoughts and prayers to the 38 interns who perished in the office fire of ‘07. Sixteen years later, we still mourn the loss caused by this unpredictable, unpreventable, and unlitigatable accident. We hope that, in time, the grieving families of those interns are eventually able to move on with both their hearts and their loved ones’ funeral expense debts.
If he meant exactly what you said, I agree. But, there is an alternate interpretation of what the guy was saying:
You tend to get different kinds of customers with different price ranges. The ones who can afford to spend money generally don’t give a crap about what you’re billing them for, and they just want the work done properly.
The ones who aim to get a “good deal” tend to be less hands-off and more critical about the work done/supplies used and billed for. Frugal customers take extra time and sanity to field questions/suggestions, and sometimes, it’s just not worth dealing with.
If raising his fee filters out the latter category, it’s hard to blame him. I wouldn’t want to deal with penny-pinchers either, and simply being more expensive than the competition is an effective deterrent.
Haha, what is this, the 90s?
Assembled instructions aren’t even the lowest non-hardware stage in instruction execution. There’s proprietary microcode sitting a level below your typical x86 ISA.
And even then, what if—God forbid—the hardware has errata. A line has to be drawn somewhere between trusting that what you write is logically correct at all stages below it. If someone is unable to trust that the environment they wrote code for works, they better start learning how to create PCBs and writing for FPGAs.
Maybe for a Haskell programmer, divide-and-conquer algorithms, or walking trees. But for everything else, I’m skeptical of it being easier to understand than a stack data structure and a loop.