So I guess it’s only an arc and not a full circle, but I had no problem making this curved sanding block in FreeCAD.
So I guess it’s only an arc and not a full circle, but I had no problem making this curved sanding block in FreeCAD.
Well, libraries are collections of APIs and sdks are usually collections of libraries. So they’re unfortunately kind of interchangeable when discussing them. But I agree with you the correct thing would be to say they’re using Nintendo’s proprietary libraries.
Hi, Android dev here. This is a different issue albeit a tangential one. But ultimately it has no bearing on the matter.
The Oracle v Google case revolves around Google’s reimplementation of the Java APIs on the Android platform. This is key. Back when Android started, they used Apache Harmony to provide the Java API set on Android. Harmony was an open source implementation of the Java API set. Sun (the creator of Java) didn’t care, they held the copyright to the Java implementation, but made their money in different ways, so they let the Harmony project live.
Fast forward a decade. The Apache Harmony project is dead. Android is stuck at Java 6 level APIs because of it, Android devs are annoyed they can’t even get Java 8 features. And Oracle bought Sun, and is monetizing the shit out of Java. They started charging money for the official Java SDK. Google didn’t want to pay Oracle, so they started reimplementing the newer Java APIs into Android, to pick up where Harmony had left off. Oracle saw this, found some code in Google’s reimplementation that was similar to the official implementation from Oracle (which is out in the open in the openjdk project) and sued the shit out of them looking for the payday they didn’t get when Google refused to pay Oracle a license.
Ultimately, the SCOTUS ruling says that APIs themselves are not copyrightable (ie you can’t copyright the .toString() function name). But you can copyright the implementation of that function. Ultimately Oracle still won a bit, because they found something like 6 function reimplementations that Google could not successfully defend as clean room implementations.
Why this is irrelevant to the Portal64 issue, is because the dev is not using the open source reimplementation of the Nintendo APIs. He’s literally using the Nintendo owned implementation of the APIs. That’s why he says he needs to switch to open source libraries. Those open source libraries have the same functions within them, but the implementation of said functions aren’t the same as the Nintendo ones (or they are and Nintendo just hasn’t sued the project into oblivion yet, I have no idea about the details).
From what I read, the codebase is using Nintendo proprietary sdk libraries in its codebase. So that is technically Nintendo IP. The fix is to switch to open source implementations of those libraries. But the dev is hesitant to put in that work without Valve’s approval, because if he does that work Valve can still fuck him over for using their Portal IP, and an n64 game isn’t distributable on Steam, so there’s literally nothing in it for Valve to bless/support it. So he’s worried that all that effort would be for naught. And Nintendo already threatened Valve in the past when Dolphin was attempting to distribute on Steam, and Valve backed down. So the theory is that Valve doesn’t want to piss off the big N in any way legally.
Now, we can ask ourselves why almost 30 year old sdks are still valuable to Nintendo, but unfortunately copyright law being what it is, it’s technically illegal to do what the dev did. He should have seen this coming and used the open source libraries instead of the Nintendo proprietary ones. But I say this not knowing how good those open source libraries are, they could have problems, be incomplete, etc., or maybe not exist when he started the project. But either way a dev should have known using Nintendo IP in any form is fraught with peril.
Because rebase is fraught with peril, if you also push rebased branches upstream and someone else works off that branch.
If you stick to the rule of only using rebase on local branches that have never been pushed upstream, it’s an awesome tool. If you don’t, you’re eventually going to cause someone to have a bad day.
I see them in vintage EVA suits from TOS!
When I built my latest Plex server, I chose to put ECC RAM into it. But it was a pain getting all the hardware, due to the silly rules AMD has for ECC support and iGPU support in its chips.
Yeah I'm in the same boat. Watching them blush and be awkward was super cute and now I just want them to figure it out. She's a catch Rutherford, go for it!
Curious why you keep the arrs internal only, when there are things like Authelia that could secure access to them?
Not much to say beyond this episode was amazing. I love how this crew can do it all - lighthearted comedy, to dark, emotional drama. The scars that Ortegas, Chapel, and M’Benga wore in this episode felt real. When Chapel hesitated at knocking the one guy out of the pattern buffer, and M’Benga just cooly smacked the button, it was a clear reminder that war is hell and it breaks people.
First version of my server, I wrote a bunch of custom shell scripts to execute docker run
statements to launch all my containers b/c I didn’t know docker at all and didn’t want to learn compose.
Current version of my server, I use docker compose. But all the containers I use come from linuxserver.io, and they always give examples for both. I use ansible to deploy everything.
I have a feeling you don’t quite understand what Docker is doing for you and how it works. I suggest looking for an intro to Docker and understand the basics around Docker volumes and networking in docker before trying to orchestrate a complex set of software in Docker.
Don’t give up! I was you about 6 years ago. I’m on my 3rd server setup now, and I’ve gone from where you are now, to being able to script my setup using Ansible and having those scripts versioned in Git, so I never have to worry about remembering how it’s all glued together.