What is the "it" that the GPL prevents? What source would need shared, and who is preventing that?
For one, I have no idea what you are even referring to. What's it take to boot Linux on Apple silicone? It was working before.
For two, whose license is the problem? You're claiming the license at the heart of the problem is the GPL. I'd claim there is no license problem, but if there was, why wouldn't the problem be the proprietary license that prevents the code from being shared (IE: Apple's license). You say you're in neither's camp, but you're blatantly picking a camp.

FWIW, API's generally don't fall under the GPL, and declaring or implementing functional software APIs falls under "fair use" (see Google LLC v. Oracle America, Inc.). Using system calls like exec or fork doesn't trigger anything - proprietary can exec a GPL binary and vice-versa. Booting some other OS is even more low level than that.

In other words, you were mistaken to say, "(Asahi) can't sign an agreement with Apple as Microsoft did," because Microsoft has no such agreement that allows them to boot directly on Apple arm hardware.

That's not the way that works. AFAICT, there is zero confirmation that this was intentional, and we don't know if it's an exclude, let alone a targeted one, let alone an NDA at its roots.

You claimed to know exactly what the real roadblock is; I think it's a wild ass guess with no evidence, and it's likely wrong.

This may be getting a big pedantic, but you had just said:

Why associate negative with GPL? You could have just as easily said it's a negative side effect of their own licensing choices, or more fairly said it was a licensing conflict between the two. I also don't see how that has anything to do with this problem, or how Microsoft's situation is somehow special/different.

AFAIK, an arm based Mac can't boot directly to Windows either.

If Apple and Microsoft had made a special agreement so that Apple's hardware could easily dual boot into Windows, but they also made a point to ensure Linux and other OS's were excluded, that would be wrong.
Apple not facilitating the boot and install of other OS's is unfortunate, but I wouldn't say it was wrong unless the exclusion was the point.
If Apple's arm hardware had previously facilitated boot and install of alternative OS's, and then they added stuff to blacklist Linux, then I'd still consider it wrong (especially so for pulling the rug out on existing users), but potentially justifiable.

I'm still waiting on that answer :-)

This is why I suggested just pushing it through a proxy. Then they can pick a proxy provider for their kids - full block, whitelisted minimal sites, teen friendly, whatever... but no need to burden the OS or apps much.

That assumes there is fault and that it is wrong. Your point stands though - I don't want to make that call.
Is your kid allowed to get pics from social sites? If so, they might get a pic of something you disagree with. Block it or tough titties.
Asking a global provider to provide filtering that walks the fine line between those for every person in every situation in every (under)age bracket is ridiculous.

100% I read that as, "While running macOS 27 beta, it is capable of booting directly into Asahi Linux."

I guess that depends on your definition of "wrong". IMO, you just provided a perfect description of something wrong, then said neither is doing any thing wrong.

Another option: Route all data through a network proxy owned by the UK gov... unless you verify your age.

Personally, I'm sick of governments forcing ambiguous and near impossible requirements on other companies without providing any actual options that would satisfy those requirements. How can one say they'll do this when "this" isn't actually defined?

Starting with your (anonymouscoward52236) idea: ban children from using phones
Then default the phone settings to proxy all traffic through some service - that would need to be defined, but you could leave it up in the air while developing and require the UK to provide such services, or you just forward it all the PM's or King's site or https://theukdomain.uk/
When buying a phone, the carrier can unlock it when the user verifies their age. ALT: only give the gov the ability to age verify and unlock, so people overwhelm that system and demand change, or it stays an obvious shitshow.

If someone wants a bunch of filtering, make them do the heavy lifting (the filtering), but facilitate it.

To put this another way, what if it was {China / Insert regime here} requiring filtering of any text, image, or videos, including those sent and received, that include content that is critical of {China / Insert regime here}? In the case of China, we already know - force users through the great firewall. You can't expect every phone and app out there to implement its own content filters that all work effectively enough to qualify - that's insane.

Sad. Really thought that'd be a Vimeo version of: https://www.youtube.com/watch?...

Gee, why did you choose to remove the phase you wrote that I replied to? This:

For the DAC, we're talking 2x2x1mm up to 5x5x1mm... or 4mm2 to 25mm2. And that's only if it's a specialized one, like the CS43131. Most phones use the DAC that is integrated into the Qualcomm Snapdragon SoC, so it's zero extra space.

Let's look at a typical phone size - iPhone 17 is 149.6 x 71.5 x 7.95mm.
If we add just 1/2mm in thickness, and we're very conservative about the length and width: 120 x 60 x 0.5 = 3600mm2

So, if you want more battery, adding a sliver to the thickness would do WAY WAY more for you than removing the DAC.

And what about that 3.5mm port? Here's a fairly giant one for reference: https://www.ebay.com/itm/30556...
It's 5 x 11 x 12mm = 660mm2.

Can one fit anything useful where it was? Sure.
Would I rather have any of those options or less size? No.
Can your pocket afford to have that much more space used? Yes.
Why do you hate allowing others the option of using bog standard wired headphones?

99% agree, but there's also a reasonable chance it's a neg negative overall.

I suspect there's a lot of "hindsight is 20/20" to this. The implementation likely solved their problems, and did so quite well for the time, and continues to solve very real problems for developers (ex. being able to spin something up in a virtual root with all deps pulled in according to your spec, all without disturbing your base system). Traditional packages can still be made, but lots of stuff just moved to recommending install via NPM. IMO, someone should be building those and then distributing the result via a normal package management system for users to use.

Updates that otherwise wouldn't happen... I certainly saw this often when installing Perl packages from CPAN and similar, cause it'd also pull in the latest (or whatever the package said to pull in), and they'd only get updated if/when you updated them or something was installed that required a later version. I think that's the model from which they were moving, and it was a good change for devs and those of us used to installing from source. But those updates WOULD happen, if all the libraries were separate packages in the system package manager (yum/apt/etc..), and that should also prevent such worms from making it out into the wild (an attacker would need to compromise the NPM version as well as getting it past the distribution packager). Using the system package manager also means that fixes could be pushed out the security channel and auto-applied, versus NMP where you're not getting an update until you reinstall or update each node app.

IMHO, this is why the industry moved to vendor maintained software repositories with signed code and such - rpm/yum, deb/apt, etc..

The central place does the vetting, and you get the latest stable version. Something needs a hot fix? They push it out, and you install on your own security updates schedule. And it should be ensuring they maintain backward compatible API's / ABI's, pushing major version changes to new packages if needed (ex. keepass / keepass2).

Requiring everyone that (builds and) installs your node based app to pull down all the libraries from NPM bypasses the package management provided by the system and vendor. You are instead trusting the myriad of NPM devs to all maintain security and trust. In addition, they often install to virtual roots, so you wind up with a bunch of the same code installed in numerous places with various versions in each - how is that easier to maintain (outside of development)?

RE: devslash0's suggestion to pin all dependencies... that's distributing the hard part to the endpoints (us people). It _IS_ a solution to the current NPM setup, but it just highlights how bad it is.

The other replies already addressed this, but I'll reiterate because one was an AC...

You said this was wrong:

But you're only looking at it from a SaaS perspective. For such SaaS offerings, anyone, including the EU, can fork the code and run it themselves (if they're running all open source stuff). Being open source, there will likely be data import/export/migration stuff built in already, but even if the vendor locked that down in their implementation, you can still move to the exact same software run elsewhere.

For more traditional software, the matter is even more clear. If it's not open source, the vendor can pull the rug out in various ways. If it is open source, you can move to the main distro or fork it. IE: it doesn't matter where a company files its papers when it's distributing open source software.

The world can share and benefit from open source code. If every country/block-of-choice develops their own proprietary solution, it'd be a heck of a mess and a loads more duplication of effort than we already see.

If AI reaches the point where one can tell it in simple terms what program they want, and it will create a bespoke version on the fly, then ... I don't think much changes. I'm pretty sure that will still be the edge case and not the norm. Maybe you'd get your social network app from a friend you did it, but that's much more like the open source model than single distributor for 80% of all office software in use.

I'm curious... why are stories such as this much more common for NPM than other such systems?

Supply chain attacks can happen in many places. But the way this happens AND spreads when in NPM seems to be special. It definitely seems related to the deployment process:
* staging server pulls your code
* ... looks as dependencies
* ... pulls those down according to the dependency specs (which are likely something like "ModuleX >= v0.123.4566", or just "ModuleX: latest")
* ... pushes all that out to prod.

It's not the only thing that works that way. However, when I was managing deployments of a GIANT perl codebase (~1 million LoC), though we could have used CPAN to do similar magic, we instead used system packages and built many of our own when needed. That way, the code that was verified to work and not have such issues was the same code that got deployed. Updating any given library didn't mean redeploying the codebase or updating project deps; we'd just push our an updated package to our locally maintained repository.

Are the benefits of using tools like composer worth these risks? Why is that still the norm, rather than the exception?

Oh, you're absolutely right. They're definitely advocating in their own self interests, and just saying the EU shouldn't worry about the very same problems it's trying to address.

They're right that where a company files its papers doesn't matter... but that's only if the software is Open Source.

I question your idea of "a lot of space". Do you think 2mm x 2mm is a lot? Or maybe you feel those are not big but they're low quality?

If it's the latter (small ones aren't enough for you), then why does the 3.5mm port bother you at all when there is also USB-C available? You're free to use whatever external USB-C thing with a DAC you want, just as you would have to use if it lacked the 3.5mm port, and the rest of us just making calls and such on our phones can use the 3.5mm port and it's more than sufficient for that use.

If the evaporated water isn't collected again, such as how CPU heat pipe coolers work, then it's not a closed loop[^1]!

[^1] ... or the loop that is closed included the greater environment, and we really need to work on our communication skills cause that's not what the general understanding would be.