Alas, SeatGuru is yet another site TripAdvisor bought up when it was hot and then eventually basically abandoned. The site has more or less been in maintenance mode for years and is no longer updated. They stopped updating their maps in 2020 (maybe earlier), same time they discontinued their mobile apps and blog section.

These days the most popular still-updated seat map site is arguably Aerolopa. It does lack some of the features SeatGuru had that I really liked--in particular, SG had green/yellow/red tagging on individual seats with pop-up notes for why they're good/caution/bad. Those pop-ups also included details for the seat like if it had in-seat entertainment screens or not, power or not, etc. I also liked the user reviews of individual seats, another thing I wish Aerolopa would add.

However, one thing Aerolopa has that SeatGuru always lacked, is they make an effort to map the actual physical fuselage skin itself, as well as every seat's physical alignment to it. This is specifically so you can see things precisely like what TFS is about: you can see exactly where the windows are located in relation to the seat. This lets you see not only missing windows, but also seats with offset windows that are hard to make use of when sitting in a normal position in the seat. Same for how it tries to show you proper physical layout and positioning of galleys and bathrooms and the like, and exactly where seats are located around them too. Just a much better effort than SeatGuru ever did for showing you a much more precise and accurate physical layout within the map, rather than merely attempting to describe layout issues via text notes the way SeatGuru did.

SeatGuru did have warnings for some of this stuff (especially missing windows), but they were in comments/tags or whatever for red-marked seats, so you had to look a little closer, whereas you can see much of this at a glance on Aerolopa.

Same. Self-hosted, and in fact still using it from standalone git pulls because I do not like nor want to use Docker. Still works fine even if standalone is "unsupported", pfft.

Sad every time a site removes their feed, which I've had several disappear. Even more frustrating when they still have one but yeah, you've got to really go out of your way to hunt for it, a sign that it likely will go away before long. Shockingly one of the things Google can actually be useful for, since a Google search will often have a site's RSS URL indexed, when the site itself makes it next to impossible to find its feed.

Then there's sites like Slashdot, whose feed repeatedly breaks. Just.. stops updating. It did that several times over several days, just a week or two ago. I never have seen any explanation for why that keeps happening, nor indeed any mention of the issue at all. It just silently stops and just as silently eventually resumes.

The Boy King has already noticed, and is now threatening 25% tariffs on India.

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.