I don't have that, but maybe because my utility is a municipal-owned company. They changed billing systems last year, which did result in one new line, the fuel charge for electricity. The utility's electricity rate is set (changes have to be approved by the city council), but they buy their electricity from TVA, which charges a fuel fee that can fluctuate from month to month. In the past this wasn't visible, but now it is.

This is a case of an external cost outside their control, and IMHO is reasonable to display for clarity.

For most businesses, they have to price all their products and services to include all their costs. For some reason, telecom companies get away with taking on "cost of us doing business" fees like crazy. For your grocery comparison, it'd be like picking up a $5 box of cookies, and getting a $1.27 "accounting fee" and $0.69 "stocking fee".

The ever-popular "regulatory recovery fee" is just a "you paid most of our employees through the service price, but we're going to hide paying our accountants". It's absurd; the price of the service should cover ALL of the service. Showing taxes and external fees is okay (although they need to be clearly presented with the price); that's how most US retail works already.

Even if repairing the damaged A380 is not feasible, but an A380 is still desirable for the route, there are dozens of A380s that have been retired or are in long-term storage (a couple of dozen more have been scrapped already). I expect any of the owners of those planes would be happy to get them off their hands (assuming that none of them are already owned by the affected carriers).

I expect plant construction (especially lots of concrete) is a much bigger emission concern than mining the fuel (a little fuel goes a long way, although it takes a fair amount of mining and refining to get that little bit of fuel). The further down the stack you go, NOTHING is absolutely carbon-neutral (solar and wind construction require raw materials too, as does all distribution no matter the generation source), but it's a matter of scale vs. return.

At this point, it's not clear that the construction emissions of big nuclear makes it a net win over its expected lifetime when compared to solar/wind. And small nuclear is still mostly vapor, and not clear that it's actually solved the scaling costs that made huge nuclear attractive in the first place. Continuing to operate the nuclear that's already been constructed for a long time probably makes it a reasonable win (of course, if we ever get a more reasonable way to deal with the waste).

As for the water... big plants are typically built directly at water sources and manage it directly, so they aren't really "consuming" it in the way datacenters do (where they just want to hook up to municipal water sources and outsource the management costs). Plants are restricted in output water temperature so as not to cause harm to animal/plant life downstream, and while some (depending on design) do evaporate a bunch, it's still right there where it came from. So I don't _think_ they have a significant impact in the way datacenters do.

The problem with the simple bits is that many services aren't that simple anymore. There was no way to express dependencies, so ordering could be annoying. There was also not consistency between distros on the helper bits, so cross-distro startup scripts got pretty gross.

I've been around Linux long enough to remember when people STARTED using Miquel van Smoorenburg's sysvinit (I chose it when I built a system from scratch, at the time there was also an older-style init included IIRC util-linux, think that's been gone for many a year). It had a good run! But as systems got more complicated, I think a more managed approach was needed, rather than init being super minimal.

So systemd-the-init-system is that. Arguably having straight-forward config files rather than wildly-varying shell scripts for startup is much cleaner. For example, since systemd can handle non-daemonizing programs cleanly, it makes throwing together a script to do something much easier (no daemonization necessary, can just run, if it fails for some reason systemd can automatically restart it if configured, etc.).

systemd-the-project is bloated in all the things they've added, but systemd-the-init-system is IMHO a good replacement for the classic SysV and older BSD rc (I'm really out of date with BSD so don't know what they do now) styles of init. I feel that "PID 1 is dumb about what's running" turned out to not be the best idea, that's why we got things like djb's daemontools and such, but trying to be init without being PID 1 has it's own issues.

https://www.youtube.com/watch?v=pG8RAbWs1yo

Did they actually test the memory to see if it was encrypted? How do they know there wasn't an AGESA bug that set the flag in cases where the CPU didn't actually support the feature?

From the outside, Red Hat operates as a largely independent subsidiary of IBM. I think it's only in the last year or two that they've even been merging the "business operations" parts like HR.

In some ways, it feels like IBM buying Red Hat was as much about keeping anybody else from buying them (and changing them). Since Red Hat was a public company, anybody with enough cash/stock could have tried to take them over (and it sounds like there were some other interested parties), so IBM making a good offer kept them operating as Red Hat. Imagine for example if Oracle had bought them instead... things would be quite different.

something they have no authority to forbid!

There is absolutely no way the FCC (or any government agency) has legal power to block firmware updates on already-purchased hardware.

When you install software, you can see how big it is, in some OSes/installers you are prompted if that's okay, if you want to enable/disable optional bits, etc. When you install Chrome, it's a certain size to get a web browser.

However, at some indeterminate point later, when you RUN Chrome, it downloads a chunk of data (that's not a browser) that's as big as (or bigger than) the initial browser install. It does this per user on a multi-user system. It does it with no prompting or notification. For a home user, this could be annoying (I discovered this right when it started last fall because it exploded my backups); for a corporate (or especially government) environment, this is unacceptable behavior.

This would be like installing Solitaire, and while you're playing it installs Excel in the background.

Also the high-density LLM racks each can use more power than a typical home has available. My house has 200A 240V split-phase power, which is fairly typical - that's a theoretical max of 48kW. Just one nVidia rack can draw 120kW.

IIRC my typical home usage peak is around 12kW (I am in the southeastern US and have a heat pump, so the day or two every year or two it gets really cold I'll get resistive heating). So let's say I have 36kW "excess" (and assume the utility could deliver that to every house); that's one rack for every 3.3 houses. Now you have to build out the high-speed networking (we have FTTH but it's also not built with 100G in mind) and management for like 3-4 racks on my block.

This is the stupidest of the stupid.

Co-authored-by: Copilot

"should" is doing some heavy lifting there.

But if you're concerned about a cPanel server where you have a site, you could just exploit the hole to gain admin access and then apply the update.

iBCS support in the Linux kernel was removed in January 2008, and it was already unusable at that point (so wasn't deprecated, just removed).