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).

Apparently nobody is using the Linux kernel's drivers for it, these days it's done purely in user-space with no need for kernel drivers.

Even when residential and office/retail type businesses pay flat rate, heavy industrial electricity users pay based on time of day. When there's high demand, they can even be cut off (in exchange for getting lower rates the rest of the time). Being able to buffer electricity use allows them to cut costs.

It's not scifi at all.

They hit the Earth's atmosphere at just below escape velocity (they were going 11.024 km/s, escape velocity is 11.186 km/s). If you do that at an angle that is too shallow, you skip off the atmosphere and enter an elliptical orbit. They intentionally did one skip to bleed off some energy, to give them a more precise entry to the landing zone.

LOL outsource it to the same SpaceX who's repeated failure to meet targets and obligations are the reason Artemis III won't be landing on the Moon? SpaceX was contracted to supply the lander and is so far behind they have no idea when (or if) they will, so NASA has re-opened the competition and is trying to get Blue Origin back in the game.

Well, aside from anything else... coming down way off target wasn't really much of a possibility. They were either going to splash down on/very near target, or not at all. The reentry corridor coming from the Moon is extremely narrow, and missing it long or short would not result in a splashdown (either bounce off the atmosphere or burn up), and similar for heat shield or parachute issues.

Again, it's about power saving. Idle 1000BASE-T draws noticeably more power than idle 100BASE-TX (IIRC the drop from 100BASE-TX to 10BASE-T is not as significant). There are Energy Star ratings and EU rules about how much power an "off" and "standby" device can draw, so dropping to a lower NIC speed helps reach those levels.

There was a proposal for a "low power idle" mode extension of 1000BASE-T, not sure if that went anywhere or got implemented.

My $DAYJOB's data center switch upgrade got switches that have 48x 10G SFP+ ports plus 8x 100G QSFP+ ports. When we installed them, we realized that some really old Dell Poweredge servers try to drop to 100M when using shared DRAC (with the dedicated DRAC port also being 10/100M only), and the switches don't support 100M. We also had to look at a bunch of rack PDUs to find options that were 1G rather than 10/100M.

100M uses less power than 1G, so I guess that's why Dell did that (sounded like a good idea to some engineer), and probably PDUs are using ancient embedded chips that only do 10/100M. Supporting 10/100M adds complexity to the switch port PHY that isn't commonly used in DCs, but it's still an annoyance for us.