sgjohnson

Letting the government regulate peering will be the death of the internet as we know it.

I don't believe that there's a single lawmaker, anywhere in the world, who understands anything about the fundamentals of IP transit. But no doubt they have ISP buddies who understand everything about it, and no doubt they'll be the ones actually writing the legislation.

The difference between WhatsApp open API, alternative App Stores and forcing peering is that it costs virtually nothing for WhatsApp to provide an open API, and for Apple to allow alternative App Stores.

Roam-like-at-home is also not a particularly good comparison here, because the the roaming fees were basically a price gouging scheme.

Don't like DTAG? You're free to switch to another ISP.

> Regulating peering within the EU would already be a win.

Regulating peering how? Freedom of commerce is one of the core pillars of the EU. Forcing a company to do business with another company is insanity.

If DTAG doesn't want to peer with CloudFlare, you can't force them.

> ISPs are the worst.

DTAG is not just a run-of-the-mill consumer ISP. They are a global Tier-1 carrier.

Which of course makes their behavior all that much worse.

> For the Telekom case, we would need a different legislation, for example make paid peering agreements between providers illegal or at least regulated, which would then be an incentive to be generally well-connected (free mutual peering is usually considered a win-win scenario unless you are Deutsche Telekom and can use your market power to bully other market participants into another form of rent extraction). And that means that lawmakers and the public need to understand first the specific problem we are fighting.

Realistically not going to happen, as the effort would need to be global. Like, Cogent STILL refuses to transit-free IPv6 peer with HE. https://bgp.tools/kb/partitions.

T1s are very happy where they are, and it's an exclusive club. Any attempts to tame this behavior from DTAG will also face backlash from basically all the other T1s.

> What is subjective about objectively saving time in your workflow?

What part of your workflow requires modifying the system volume on macOS? As a long-time power user of macOS, I don't even need to disable SIP. I've worked my workflow around the limitations.

macOS and Linux power users are two different species. One will work around the restrictions imposed by the overlords, the other will beat the system into submission.

Of course you can also beat macOS into submission, but then you're in for a bad time.

Broken customization is entirely subjective.

As for waste - for the past decade or so, the consumer computing world has been in an almost unanimous consensus that computing power is cheap, and that it's not worth optimizing away a few hundred megabytes of storage or RAM. And macOS is _nowhere_ near being the worst offender here. If you really need to point a finger at waste, look no further than Windows, where just about everything these days is a WebView. Now that's waste.

I'm pretty confident that the taskbar on Windows 11 alone eats up more RAM and CPU time than every single macOS service that's running but not actually being used combined.

Funnily enough, they had no certification and weren’t compliant in 10.0-10.3 days, so what they were doing was trademark infringement, hence the lawsuit from the Open Group. 10.4 was the first compliant version. And oh boy they really milked it for several years afterwards.

https://www.quora.com/What-goes-into-making-an-OS-to-be-Unix...

The bigger problem with disabling SSV and making changes to it is entirely practical - any macOS update will overwrite them.

Which can be worked around by writing a provisioning script, but in either case will be a significant headache if one would come to rely on the modifications they were to make to the volume.

I didn’t claim that eclecticlight writes cheap dunk.

But this article, which starts with

> That’s a question I’m asked repeatedly, which this article tries to answer.

doesn’t actually _try_ to answer the question. It just stops at SSV and draws a meaningless comparision with macOS 9. It also has several factual inaccuracies in there. Notably, the claim that macOS is not UNIX, and the implication that Unix systems must somehow be free and open-source (virtually all Unixes of the day were proprietary & closed source).

That just highlights my point about this article being a cheap dunk?

Because I was very disappointed with it ending at “SSV doesn’t let you”. SSV can be disabled, and the author should have known (almost certainly knows) that.

> Here’s our first problem, as those are located in the Signed System Volume (SSV), so we can’t change them in any way. The same applies to the other 417 LaunchDaemons and 460 LaunchAgents that account for most of the processes listed by Activity Monitor. In the days before the SSV it was possible to edit their property lists to prevent them from being launched, but that isn’t possible any more when running modern macOS.

SSV can be disabled. It would be ill-advised to do so, but Apple intentionally allows you to do that. In fact you can strip away every single security layer of macOS, including allowing unsigned kernel extensions to be loaded. This document is a bit outdated, but it should still be possible to do all of that. https://gist.github.com/macshome/15f995a4e849acd75caf14f2e50...

Feels like the article is just a cheap dunk on macOS. Has Apple perhaps baked in a bit too much into the SSV? Definitely. Even the Chess.app is in there.

Does it really matter? Almost certainly no.

The next sentence is also interesting actually.

> It’s a closed-source proprietary operating system

Most UNIX systems were proprietary & closed source though?

I don’t think OpenAI could be considered a startup anymore.

IPv6? You wouldn’t even need to expose the actual endpoints out on the open internet. DNAT on the edge and point inbound traffic on a VM responsible for cert renewals, then distribute to the LAN devices actually using those addresses.

A lot of applications implement cert pinning for this exact reason

Cloud providers could check the transparency lists, and if there’s a valid cert for the IP, quarantine it until the cert expires. Problem solved.

"Ultra" isn't even binned - it's just 2x "Max" chips connected together.

Otherwise, yes, if a chip doesn't make M4 Max, it can make M4 Pro. If not, M4. If not, A18 Pro. If not that, A18.

And even all of the above mentioned marketing names come in different core configurations. M4 Max can be 14 CPU Cores / 32 GPU cores, and it can also be 16 CPU cores and 40 GPU cores.

So yeah, I'd agree that Apple has _extreme_ binning flexibility. It's likely also the reason why we got A19 / A19 Pro / M5 first, and we still don't have M5 Pro or M5 Max yet. Yields not high enough for M5 Max yet.

Unfortunately I don't think they bin down even lower (say, to S chips used in Apple Watches), but maybe in the future they will.

In retrospect, Apple ditching Intel was truly a gamechanging move. They didn't even have to troll everyone by putting an Intel i9 into a chassis that couldn't even cool an i7 to boost the comparison figures, but I guess they had to hedge their bet.

I’m pretty confident that the US SIGINT agencies wouldn’t manipulate BGP to redirect traffic somewhere, as such a hijack will ALWAYS leave traces that would be observable by anyone impacted, downstream or upstream.

US SIGINT agencies? They’d just pwn the routers they are interested in. And almost certainly they’ve already done it. Like 10+ years ago.

BGP hijacks are really low-tech and trivial to detect. And competent intelligence agencies don’t do either, unless it comes with enough plausible deniability that it would even be insane to suggest foul play.

I operate a small BGP hobbynet under 2 different AS numbers, and even I keep logs about path changes. Not for any practical purpose, just sheer curiosity.

BGP is a globally distributed and decentralized system. The messages (announcements) propogate virtually across the entire internet. If someone hijacked a route to a prefix that I’ve received, and the path I’ve received is the hijacked one, I’d get that information.

So yes, if that happened, I’d totally expect CloudFlare to publish it, unless they got a NSL. Which they most probably wouldn’t get, as NOTHING about the event would be secret—-it would be out in the open for everyone to see the instant it would happen. There are also tools like https://bgp.tools which operate public route collectors, with the data being publicly available. RIPE has one too.

What do you mean? The internet is virtually entirely decentralized. There is no one central BGP router.

If you don’t want to put Cloudflare in front of it, you can dual-stack the edge and run your own NAT46 gateway, while still keeping the internal network v6 only.

If you have a /48 assigned, you’ll burn the prefix in your brain. Leaves 16 bits for the network address.

e.g. you’ll get 2a06:a003:1234::/48 from the ISP - what you’ll really need to remember is the 2a06:a003:1234:xxxx::/64 part. And I use the VLAN id for the xxxx part. Trivial.

Cloudflare proxy automatically creates A and AAAA records. And you can’t even disable AAAA ones, except in the Enterprise plan. So if you use Cloudflare, your website simply is going to be accessible over both protocols, irrespective of the one you actually choose. Unless you’re on Enterprise and go out of your way to disable it.

> We are still decades away from it being viable for servers to run IPv6 first.

Just put Cloudflare in front of it. You don’t need to use IPv4 on servers AT ALL. Only on the edge. You can easily run IPv6-only internally. It’s definitely not an afterthought for any new deployments. In fact there’s even a US gov’t mandate to go IPv6-first.

It’s the eyeballs that need IPv4. It’s a complete non-issue for servers.

RFC 1631 is a memo, not a standard.

Actually, my bad. NAT was NEVER standardized. Not only NAT was never standardized, it’s never even been on standards track. RFC 3022 is also just “Informational”

Plus, RFC 1918 doesn’t even mention NAT

So yes, NAT is a bug in history that has no right to exist. The people who invented it clearly never stopped to think on whether they should, so here we are 30 years later.

Not just the edge router. Every router between the ISP edge and the destination edge.

And since the goal is “backwards-compatability”, you’d always need to poll, because a “legacy” IPv4 client would also be unable to send packets to the IPv4+ destination. Or receive packets with an IPv4+ source address.

And it would be an absolute nightmare to maintain. CGNAT + a quasi backwards-compatible protocol where the backwards-compatability wouldn’t work in practice.

So you would have exactly the same problem as IPv6. I can say the same about v4 and v6 today. You could just turn off IPv4 on the internet, and we’d only need to do translation on the edge for the legacy clients that would still use IPv4. You can even put IPv4 addresses in IPv6 packets!

that exists - ::ffff:0:0/96 space. It even supports dots.

::ffff:192.168.1.1 == 192.168.1.1 (as far as the linux kernel is concerned, in most contexts)

Obviously they are. Most people use the equipment provided by their ISP without ever changing any settings.

If the ISP is IPv6-first, you bet that their customers are using it in their home WiFi.

> Basing your IP address on your Mac address doesn't help in that regard either.

This hasn’t been the case for 20 years. Privacy Extensions solved that, and every SLAAC implementation supports them.

Yes, the only key difference is that NAT is gone.

Also a nitpick: switching is irrelevant here, that’s L2. L2 doesn’t even know what’s an IP address :)

There was some dude on YouTube that resurrected the first Ethernet bridge (which was built for thicknet) - I recall even that worked with IPv6.