This is especially fun for closed systems, ones that do not have Internet connectivity. Virtually everything these days assumes an online presence, even third-party patch management systems, so it's becoming harder and harder to actually keep a closed system patched. There's continuing erosion of support for loading patch bundles into the management system via sneaker-net.

And I say "closed", not "offline" or "air-gapped". In my case, I manage a utility control system that does not connect to the Internet (as we often say for various Slashdot stories, "do not connect important shit to the Internet"), but it does need to monitor the grid. Closed, company self-built private network to all the substations we own, all over the state. While there's no Internet connectivity, obviously in such a design it still has ingress attack points, even if it requires an attacker to break into a substation and gain access to locked down networking equipment. Anything's possible. So you don't want to make it any easier for them by having glaring, known flaws hanging out there in your system.

Further in our case, our utility is under NERC CIP federal regulations (not all utilities are under the strictest levels of CIP, which is why you hear about utilities with Internet connections and unpatched systems and such). CIP compliance has the force of law behind it. Thus, under CIP, patching isn't just a good idea, it's required by federal law. We MUST patch our systems. So then shit like this comes along "Oh use the cloud!" and the system we are ACTUALLY TRYING to keep secure either loses a critical piece of the patch puzzle, or we have to start giving it limited Internet access, either way lowering our security posture.

Fucking short-sighted everywhere. And yes, yes, before anyone points it out, I'm aware "don't use Windows if you want to be secure". Fuck off. Even with things like CIP we still have to deal with the realities of non-technical upper management and accounting. They know Windows. They want to buy Windows. Doesn't mean we're happy about it. Though I will admit one silver living of these all-cloud pushes: it starts making it easier to convince those non-tech C-suites to not buy Windows.

Though even fleet-level Linux patch management solutions are also starting to see some of this cloud creep, or at least "Internet connectivity expected", rather than easily allowing bundles to be loaded from an offline transfer/sneaker-net.

As you point out with the weather, also vastly easier to jam or otherwise interfere with. ANY kind of open-air comms, even tight-beam laser transmission, will always be physically significantly more vulnerable than closed cable comm.

The linked article is pretty poor and light on details, yeah. The Register has a better article up now, which gives more details on the accusations.

Though it does still boil down to Apple is supposedly giving its own apps preferential treatment compared to third-party apps. Nonetheless The Reg's article at least has more info on what Apple is accused of actually doing with the data, and why it's supposedly unfair.

Me personally, I'm still of the "fuck all trackers and advertisers" mind, so I hope Apple prevails on this.

Add small town Texas too. A company I'd never even heard of, Pavlov Media, has been running fiber through various small communities all around Texas. They apparently are from Illinois and have a lot of service dotted all over that state, but are just now making in-roads into other states. Their pricing is better than TFS's list of GFiber pricing, though whether they stay that way or it's just a foot-in-the-door price, I don't know.

I just got a notice today that service is now enabled in my area (they dug the fiber a couple months ago). Maybe I'll contact them. At a minimum I'd sure appreciate a symmetrical connection. My current 300/20 cable just ain't cutting it for upstream. The downstream meets my needs well enough, but hey, now apparently I can get 1000/1000 for less than the price I'm currently paying for cable.

Ironically, my cable ISP (Grande) actually does FttH themselves, but they only ran it in places where Google Fiber, U-Verse, or Fios operated. They didn't bother anywhere else, despite actually running fiber back-haul everywhere (i.e., my neighborhood's head-end is connected via fiber, but they ran coax from it to the individual houses and have never changed that in the 20 years they've served us). It was obvious they only cared to offer better service in places where competition made them do so. Typical "we don't care; we don't have to" mentality, and I suspect Pavlov is going to cost them a lot of customers (like me) because of it. They have no one to blame but themselves.

Not even well-informed on the names of cities either, since more specifically the article and summary say "...the Army base in Fort Hood, Texas..." which is not and was never correct. Even back when the base was called Fort Hood, it was "the Army base in KILLEEN, Texas". Which the city still is, regardless of the base's change in name.

Or, from your own link, ask Democrat senator Chris Coons who is the bill's co-sponsor.

Fucking everyone over for fun and profit is one of the few things that pretty reliably receives bipartisan support.

At my workplace, which would probably be classed small to maybe medium-ish (around 50-60 VMs and a user count in the mere hundreds), we use SCALE Computing's HyperCore product. It is KVM-based, though pretty customized by SCALE. We previously used VMware but were already moving onto SCALE well before the buyout, and at this point we are 100% SCALE.

While it certainly has its limitations (in particular no hardware passthru, so you're not getting any virtual USB or serial devices), it has worked well for our needs, even supporting a few more advanced features like hypervisor clusters. The management interface is a bit basic and could use some more advanced and/or granular controls, but for the most part the product has done its job pretty solidly for us, and at very considerably better pricing.

Worth pointing out though, like other companies that have also been mentioned in this thread, SCALE generally aims to be integrated vertically, so they have their own server hardware products to run their hypervisor on. I don't know if that's required though.

Huh, I did not know that about SLAAC. Yeah, that does seem like a particularly stupid design decision since subnets smaller than /64 are perfectly valid otherwise. Hell, given the shear size of the address space within just a single /64, an end-user further sub-dividing that one /64 for their use makes very logical sense to me, vis a vis my previous post above. Rather idiotic not to have made such obvious use cases simple to implement by design.

Forgive my ignorance; I am no expert on IPv6 so maybe there's some fundamental detail I'm missing. I'm legit curious though: a /64 can be divided into sixteen /68 subnets, with each one of those having over 1.1 quintillion usable addresses available within them. How in the world is having "only" a /64 from your ISP a deal killer in your configuration?

That is unfortunately basically what they did, and quite deliberately. There's a Bugzilla entry specifically regarding this change where they explicitly note "advanced users" can still use userChrome.css, but everyone else can get fucked (they don't add the last part but I feel it's implied).

And yeah, I have a suspicion even userChrome.css is on the chopping block sooner or later. After all, as that Reddit post points out, first you have to hit about:config and turn on toolkit.legacyUserProfileCustomizations.stylesheets before actually editing the userChrome.css file. The name of that setting is in itself a warning.

What's particularly sad is they don't even follow standard UI practices in regards to timing. While I immediately disabled thumbnail views, I actually like the look of the hoverPreview, the text. However, the pop-up is INSTANT upon mouseover, rather than waiting the customary ~1 second before pop-up occurs. The classic info pop-up (what FF does when hoverPreview.enabled is turned off) actually follows this convention of short delay, so Mozilla is inconsistent in implementation even within this single function.

The lack of delay made me turn off hoverPreview, because it kept getting in the way every time I just wanted to straight click on a tab (already knowing which one I wanted, not needing any pop-up info) and make it active. The instant pop-up would get in the way of the click, slowing the whole action down.

No, Intel gave up on the endevour entirely. They quite famously sold the majority of their modem division to Apple.

The DMA also required Apple to allow other browser engines, a feature that was implemented with the release of iOS 17.4 earlier this year so it is available now. However, none of the major players have taken up the challenge because of the way Apple implemented the change, so currently Firefox and Chrome on iOS (and several other smaller browsers too) remain WebKit skins even though they have the option of implementing their own engine.

Both Google and Mozilla have made public complaints over the issues involved in taking advantage of this new functionality. Namely: because Apple is implementing it EU-only, they'd have to maintain separate codebases/applications for the EU and non-EU iOS versions of their browsers, "a burden Apple's Safari does not have to bear" as they say.

I believe at this point both companies have filed official complaints with the EU governing body, seeking to have Apple's petulance ruled as non-compliance with the law.

Apple's NFC is already open for non-payment things, and there are already cars that use iPhones as digital keys. Some cars to require their specific app, some don't (after initial setup that is; in those cases the key is stored in Wallet after being set up). Non-payment NFC usage on iPhone has been open for a while.

This new event is specifically using NFC for payments, which Apple had kept closed and only able to be used with Apple Pay.

Rather than cars, I think this will be the double-edged sword with opening NFC for other payment processes. While yes I do agree that sealing it away solely for Apple Pay is possibly anti-competitive, I expect competitors to be just as dickish likewise. If a bank doesn't HAVE to participate in Apple Pay (which does admittedly require them a give up a sliver of the transaction fee to Apple) to facilitate mobile payments, that bank likely won't because profits over everything. Instead, you'll have to open the bank's app. Or Venmo's app, or Zelle's, or everything else. Everyone will lock "their" NFC payments and "their" credit cards and stuff behind "their" app, and it will no longer be a simple, streamlined, single interface like having and using Apple Pay-enabled cards in Wallet is.

Sure, that's a doom and gloom scenario and maybe, maybe it won't come to pass, but I'm not going to hold my fucking breath.

The whole thread on LWN about this is really just a wonderful glimpse into this asshole's Pottering Protege mindset. His first response was to even question whether it happened at all, implying he couldn't even be bothered to just fucking test it.

He also explained farther down the same thing the summary and Reg article mention, that tmpfiles hasn't been for temporary files for a very long time. It just maintains an "unfortunate legacy name" because changing that name would "break a lot of scripts". When directly asked why they don't change the package name and then simply provide a compatibility alias until scripts and such can be fully converted to the new name (you know, a bog standard thing that not only Linux distros, but even Windows and macOS do as a standard practice)?

"That would result in a ton of bikeshedding, so can't be bothered honestly"

And that, really, tells you all you need to know about this twat.