As pointed out in the other comments here, the EULA definitely allows you to run macOS in Ubuntu if you're using Apple's hardware.

Pretty sure the EULA does not cover copying essentially a DRM key from the SMC and checking it into GitHub, conveniently set up in such a way as the repo does not in fact require Mac hardware

You may find the reasoning here interesting: https://github.com/kholia/OSX-KVM

The "secret" Apple OSK string is widely available on the Internet. It is also included in a public court document available here. I am not a lawyer but it seems that Apple's attempt(s) to get the OSK string treated as a trade secret did not work out. Due to these reasons, the OSK string is freely included in this repository.

That repo has been around for many years.

Every so often I encounter a key in React (Preact, but preserved for compatibility) titled something like PRIVATE_DO_NOT_USE_OR_YOU_WILL_BE_FIRED and I appreciate the cutesy tongue in cheek acknowledgement that it’s not private and will likely be used anyway

As someone not at all familiar with modern JS: why the hell would a UI library have a key of any kind??

It's not a cryptographic key or a secret of any kind. In the case of React (or other JS libraries) export identifiers are chosen to expose private APIs for integration purposes with things like developer tooling and other functionality that isn't part of the publicly documented API.

Instead of choosing something like `__PRIVATE` the React library in particular chose something more eye catching: `__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED`, which is definitely sure to get people's attention when they look into it, but is essentially just a joke.

Because there are some really terrible projects out there made by guys who think that a two week "bootcamp" is enough to make you a competent developer. An SPA needs to access a third party resource of some sort (in my case it was Power BI), and fetching the necessary authentication information from your server with proper authorization is apparently too complicated. I ain't rewriting that shit, I have too much work already.

Not a crypto key (I hope). In JS, objects (dictionaries) are key-value pairs.

Fair enough, and I see how "private" might mean "inaccessible" and not "secret" as I originally assumed. I hope at least...

I meant... a property name. Like `{ [key]: value }`

Yeah, that makes sense. I automatically assumed you were talking about "secret" keys because of the parent post.

> shipping it via Ubuntu's explicitly for-profit app store

Can you clarify "explicitly for-profit"? I don't think that's true: https://en.wikipedia.org/wiki/Snap_(package_manager)

Snap is practically the opposite of that. It's a package manager that is almost entirely out of the hands of Canonical, which was one of the criticisms of apt.

If you mean to criticize that some of Snap is proprietary, that is legitimate, but that doesn't seem to be the aim here.

In theory, I agree. In practice, there doesn't seem to be any other snap store out there?

This is a years old quote from [0], but it doesn't feel like anything changed since.

> If you want to distribute your snaps, your choices are 1) publish it through the Canonical store, entirely under Canonical's control, 2) upload it as a file and tell people to use the CLI to install it, or 3) try to figure out how to reconfigure the snap client to use a different server by reading the source code, then write your own server end from scratch, and tell your users to do that.

[0] https://www.happyassassin.net/posts/2016/06/16/on-snappy-and...

>try to figure out how to reconfigure the snap client to use a different server by reading the source code, then write your own server end from scratch, and tell your users to do that.

You also need to

1) compile and distribute your own version of snapd, since it hardcodes the Canonical snap store.

2) Set the appropriate env variable to prevent snapd from auto-updating itself back to a Canonical version.

Again, this does not address what I took issue with, which is "explicitly for profit". There is no indication that this assertion is even remotely true. I did call out the proprietary nature of some of their server code, but again, that does not yield "explicitly for profit" which nullifies the posters point.

You've also claimed that it's "almost entirely out of the hands of Canonical", which it is not.

I'm with you on the "it's not explicitly-for-profit" point at the moment, but it is set up in a way that it could change at any point. Whether it's set up that way deliberately or not, we can only guess.

Anyway, Ubuntu derivatives are approaching the topic with this in mind. Linux Mint forbids snapd from being installed via apt (https://www.theregister.com/2020/06/02/linux_mint_team_snap/), and elementary OS goes a step further and is working on making its entire app ecosystem flatpak-exclusive (https://blog.elementary.io/elementary-appcenter-flatpak/).

I used the words "almost entirely" which is confusing, I will admit. I don't use snap for the same reasons. That said, what's being postulated by multiple users here is blatantly false.

He refers to the snapcraft, not the snap manager https://snapcraft.io/ , https://snapcraft.io/sosumi

I am still not seeing how snapcraft.io is "explicitly for-profit". eg: https://snapcraft.io/thunderbird

A private company is for-profit by definition. They may not be monetising it now, but that’s because they’re in the growth phase.

You don't get to make assertions based on speculation. Across Linux there have been an infinite number of package managers, sometimes ones that integrate each other's protocols like how the PopOS store integrates flatpak. Is PopOS or the PopStore now explicitly for profit despite the fact that it doesn't sell a single thing?

Except for non-profit companies, which are...

The name reflects this observation: https://en.m.wikipedia.org/wiki/Sosumi

There are fully working osx vagrant images on GitHub, so why should this surprise you?

You good law and order man! Earth is such a nice planet because many of you exist!