I’m not super familiar with MacOS, but do you know if Gatekeeper or XProtect run at ring 0?

Gatekeeper does mainly signature checking. XProtect does signature checking on an applications first launch. Both of those things would be pretty stupid to implement in ring 0, so I'm pretty sure they are not.

If they do run at ring 0, would you consider that anticompetitive?

No, as they're not doing any active monitoring. They're pretty much the "you downloaded this file from the internet, do you really want to run it?" of MacOS.

I’m almost certain Apple will move or did move to depreciate kernel extensions. Which means it would be the same situation Microsoft wanted to force as you described.

That is indeed the case, but I'm not aware of any Apple products relying on being a kernel extension. Apple is facing action from the EU for locking down devices from device owners, though - mainly applying to phones/tablets. On Macs you can turn pretty much everything off and do whatever you want.

The other argument with Defender is you could at least have a choice to use it or not.

Without providing a proper API Defender (both the free one, and the paid one offering more features) would be able to provide more features than 3rd parties. Microsoft also wouldn't have an incentive to fix the APIs, as bugs don't impact them.

The correct way forward here is introducing an API, and moving Defender to it as well - and recent comments from Microsoft point in that direction. If they don't they'll probably be forced by the EU in the long run - back then it was just a decision on fair competition, without looking at the technical details: Typically those rulings are just "look, you need to give everybody the same access you have, but we'll leave it up to you how to do it". Now we have a lot of damage, so now another department will get active and say "you've proven that you can't make the correct technical decision, so we'll make it for you".

A recent precedent for that would be the USB-C charger cable mandate - originally this was "guys, agree on something, we don't care what", which mostly worked - we first had pretty much everything micro USB, and then everything USB-C. But as Apple refused the EU went "look, you had a decade to sort it out, so now we're just telling you that you have to use USB-C"

It's already in the name - XDG stands for X Desktop Group (nowadays freedesktop), which works on interoperability for desktop environments. In a pure shell environment (or even if you're not running a full desktop) none of the XDG variables are defined, and especially in shell environments the default fallbacks specified by XDG are not necessarily what the operator would expect.

Probably half the entries in that list are not GUI apps, and XDG doesn't apply (though some still support it). For some others there (like emacs) XDG is used if it exists.

Admittedly I'm just toying around for entertainment purposes - but I didn't really have any problems of getting anything I wanted to try out with rocm support. Bigger annoyance was different projects targetting specific distributions or specific software versions (mostly ancient python), but as I'm doing everything in containers anyway that also was manageable.

Microsoft is trying the same - but royally screwing up how they deal with hardware partners. Performance wise the snapdragons they use are roughly a decade behind what Apple is doing - I have both systems for work projects.

The x86 emulation in Windows is imo better solved than rosetta - but the rest of the stack is a mess. For example, the deployment tools only got arm support a few months ago.

And Linux support on those things sucks - while using it on the M1 is great.

After reading about it - true. Disadvantage of doing this stuff for a long time - you miss new developments. Only reason I'm aware of testdisk is that I lost the sources of my own superblock search tool, my old binaries broke with a newer glibc, and before reimplementing it I checked if sombody else had done that in a more usable form in the meantime.

POE also is point to point, and currently tops out at 30W per link. You could split it off in a socket - but that reduces the available power per device even more.

Or we could use the current AC cabling where we use a single wire over multiple sockets and get a combined 3600W over a standard 16A fuse over 1.5mm2 wire - which with ground and neutral is about the same thickness as a shielded ethernet cable.

Interesting, I never encountered that - though that also fits the "2.5 decades" timeframe.

It still shows the author of the error message has no idea about networking: even if we assume network classes apply to RfC 1918 addresses (which they don't) the majority of those addresses are class A or class B networks.

And looking at it the other way round (using "class C" synonymous with "private addresses) doesn't work - the majority of addresses in class C space are public addresses.

And I thought that'll be about Patrick Stewart.

But will that kind of person really carry trash until a resting place, or maybe just dispose of it where they open stuff?

I personally always found trash cans in areas not commly frequented by cars rather odd - I got tought in the 80s and 90s that we are careful how we pack things we take with us when hiking, and take everything back.

It is a conecpt a 3 year old can understand (I see that now with my own kids), so you'd expect an adult not to have a hard time with that.

I relatively recently switched from ion3 to hyprland - not having a predefined layout with rules where windows go was a bit weird at first, but got used to it pretty quickly. I have a bunch of rules about which desktop specific applications should go, but other than that just use dynamic splits at the cursor location, and then move windows around as needed.

If you look at price per TB 4TB drives are a bad choice.