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.

"I don't love AI slop myself" says the biggest contributor to the generation of AI slop.

It sounds great, but the primary benefit is quickly providing open space. However, work done in space isn't done in open space, but with equipment. So now instead of having the bulk of the equipment mounted inside a module on the ground (where it's usually much easier to handle, with lots of lifting equipment and people and tools), you've got to do it in zero-G.

You still have to launch the entire mass (possibly more if there's extra tools and packing) and much of the volume, you've just significantly expanded the amount of on-orbit construction, which also means you're using very expensive labor to do it.

It may eventually even out, but I don't think the economics work today. It would only make sense if you had a specific need that required a larger-volume module than can be launched on a vehicle today, and I don't think anybody's had such a requirement.