The Fediverse by design prevents this, while the internet of the old age had little if any guardrails against this specially since the platforms never really federated with another.

I see someone is too young to remember USENET.

The Fediverse is a bit more like the old USENET days in some regards, but ultimately if it ever becomes more popular the same assholes that ruin other online experiences will also wind up here.

What made the Internet more exciting 30 years ago was that it was mostly comprised of the well educated and dedicated hobbyists, who had it in their best interest to generally keep things decent. We didn’t have the uber-lock-in of a handful of massive companies running everything.

It’s all Eternal September. There’s no going back at this point — any new medium that becomes popular will attract the same forces making the current Internet worse.

Depends on what you mean by “back in the day”. So far as I know you could be ~30, and “back in the day” for you is the 2005 era.

For some of us “back in the day” is more like the early 90’s (and even earlier than that if we want to include other online services, like BBS’s) — and the difference since Eternal September is pretty stark (in both good and bad ways).

There are a lot of manufacturer-agnostic smart home devices out there, and with just a tiny bit of research online it’s not difficult to avoid anything that is overly tied to a cloud service. Z-wave, ZigBee, Thread/Matter devices are all locally controlled and don’t require a specific companies app or environment — it’s only really the cheapest, bottom-of-the-barrel WiFi based devices that rely on cloud services that you have to be careful of. As with anything, you get what you pay for.

Even if the Internet were destroyed tomorrow, my smart door locks would continue to function — not only are they Z-wave based (so local control using a documented protocol which has Open Source drivers available), but they work even if not “connected”. I can even add new door codes via the touchscreen interface if I wanted to.

The garage door scenario can be a bit more tricky, as there aren’t a lot of good “open” options out there. However, AFAIK all of them continue to work as a traditional garage door opener if the online service becomes unavailable. I have a smart Liftmaster garage door opener (which came with the house when we bought it), and while it’s manufacturer has done some shenanigans in regards to their API to force everyone to use their app (which doesn’t integrate with anything), it still works as a traditional non-smart garage door opener. The button in the garage still works, as does the remote on the outside of the garage, the remotes it came with, and the Homelink integration in both of our vehicles.

With my IONIQ 5, the online features while nice are mostly just a bonus. The car still drives without them, the climate control still works without being online — most of what I lose are “nice-to-have” features like remote door lock/unlock, live weather forecasts, calendar integration, and remote climate control. But it isn’t as if the car stops being drivable if the online service goes down. And besides which, so long as CarPlay and Android Auto are supported, I can always rely on them instead for many of the same functions.

Some cars have much more integration than mine — and the loss of those services may be more annoying.

…until the CrowdStrike agent updated, and you wind up dead in the water again.

The whole point of CrowdStrike is to be able to detect and prevent security vulnerabilities, including zero-days. As such, they can release updates multiple times per day. Rebooting in a known-safe state is great, but unless you follow that up with disabling the agent from redownloading the sensor configuration update again, you’re just going to wing up in a BSOD loop.

A better architectural solution like would have been to have Windows drivers run in Ring 1, giving the kernel the ability to isolate those that are misbehaving. But that risks a small decrease in performance, and Microsoft didn’t want that, so we’re stuck with a Ring 0/Ring 3 only architecture in Windows that can cause issues like this.

That company had the power to destroy our businesses, cripple travel and medicine and our courts, and delay daily work that could include some timely and critical tasks.

Unless you have the ability and capacity to develop your own ISA/CPU architecture, firmware, OS, and every tool you use from the ground up, you will always be, at some point, “relying on others stuff” which can break on you at a moments notice.

That could be Intel, or Microsoft, or OpenSSH, or CrowdStrike^0. Very, very, very few organizations can exist in the modern computing world without relying on others code/hardware (with the main two that could that come to mind outside smaller embedded systems being IBM and Apple).

I do wish that consumers had held Microsoft more to account over the last few decades to properly use the Intel Protection Rings (if the CrowdStrike driver were able to run in Ring 1, then it’s possible the OS could have isolated it and prevented a BSOD, but instead it runs in Ring 0 with the kernel and has access to damage anything and everything) — but that horse appears to be long out of the gate (enough so that X86S proposes only having Ring 0 and Ring 3 for future processors).

But back to my basic thesis: saying “it’s your fault for relying on other peoples code” is unhelpful and overly reductive, as in the modern day it’s virtually impossible to do so. Even fully auditing your stacks is prohibitive. There is a good argument to be made about not living in a compute monoculture^1; and lots of good arguments against ever using Windows^2 (especially in the cloud) — but those aren’t the arguments you’re making. Saying “this is your fault for relying on other peoples stuff” is unhelpful — and I somehow doubt you designed your own ISA, CPU architecture, firmware, OS, network stack, and application code to post your comment.

——- ^0 — Indeed, all four of these organizations/projects have let us down like this; Intel with Spectre/Meltdown, Microsoft with the 28 day 32-bit Windows reboot bug, and OpenSSH just announced regreSSHion.
^1 — My organization was hit by the Falcon Sensor outage — our app tier layers running on Linux and developer machines running on macOS were unaffected, but our DBMS is still a legacy MS SQL box, so the outage hammered our stack pretty badly. We’ve fortunately been well funded to remove our dependency on MS SQL (and Windows in general), but that’s a multi-year effort that won’t pay off for some time yet.
^2 — my Windows hate is well documented elsewhere.

Honestly, I hate these memes. As an old school hacker/programmer who has been doing this for many decades, I can usually just start thinking in code and start dumping out everything I need from my brain through my fingers to the keyboard. I never copy-and-paste code from online for something I’m coding (I don’t count something like copying a script to do a quick shell task of some-sort; for something like Amazon’s directions for installing Corretto I’m not going to type all that out manually; and I don’t really consider that “programming”).

But as a tech manager (and former University comp.sci instructor), I know this happens more often than I’d prefer. But some of the worst code I’ve had to review has been copy-and-paste jobs where the developer didn’t understand the task correctly and jammed in something they found online as a quick solution. I get that I started in a generation where you had to understand the problem and code the solution from scratch (because the Internet crutch wasn’t what it is today) — but the fact that so many younger developers revel in the fact they copy-and-paste code on the regular makes me sad.

You can learn a ton installing your own OS, even if you don’t get things working in the end. Especially back in the 90’s when things weren’t quite as plug-and-play and hardware auto-detection was immature. So even if your RedHat experiment failed, good on you for attempting it anyway!

It was quite the interesting thing to run back then — it was all very “Wild West” of software, and a LOT of stuff didn’t work well.

It wasn’t my daily driver; it really wasn’t ready for most workloads back then. But it was nearly free, and we shared around the CD-ROM amongst hacker friends interested in giving it a try.

Yggdrasil LGX, back in ‘93.

Arbitrarily and suddenly destroying all apps built with a certain tech stack…

Except they aren’t. Sure, PWAs may be slightly more disadvantaged on iOS/iPadOS than they are now, but they haven’t been “destroyed”. And they continue to work exactly as they did with the prior iOS/iPadOS release in all the rest of the world.

Everyone seems to think Apple is playing some sort of 4D Chess to kill off PWAs — but if Apple wanted to kill off PWAs they could just disable the functionality completely globally tomorrow, and they’d likely face no repercussions for doing so. They don’t even need an excuse to do so.

I’m not claiming that Apple is acting honourably here; merely that if they actually wanted to kill PWAs it wouldn’t require some sort of Rube Goldberg machine-style planning to do it. There is no conspiracy here.

The title appears to be quite the reach. If Apple wanted to kill PWA’s, they would have done so worldwide. There is absolutely nothing preventing them from disabling them in the US and Canada (and much of the rest of the world) today, but they haven’t — they’re only disabling them in the EU.

DNS for internal site resources can use ULA just fine, unless you absolutely need reverse DNS. For resources needing exposure externally, I’m not sure if this plan accommodates that.

Split-horizon DNS is a thing that exists. This part is a solved problem.

To be clear, the issue with IPv4 being preferred over ULA is only an issue with calls to things like getaddrinfo which can return multiple results for a single host/domain name query.

The solution to this is easy — either don’t put your IPv4 addresses for hosts in your DNS, or give them a different name. I.e.: maybe you’re using hostname.domainname.xyz for your IPv6 addresses, and hostname.ipv4.domainname.xyz for your IPv4 addresses. Lookups against hostname.domainname.xyz will return ULAs in this case, as there is no A record for the same domain name.

People (many who should know better) act like machine A can somehow magically determine that machine B has an IPv4 address and just start using it instead of ULAs — but the precedence rules only apply to a DNS query the returns both an IPv4 and a ULA. Design your DNS so that this isn’t the case, and you won’t have to worry about it.