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.
Democracy is for retards.
Government did this. All of this. Government regulated so much that only a rare few can afford to compete.
This is late stage statism. Retard voters are to blame.
Like you.
Co-authored-by: Copilot
"Hey, what's the big deal? We used to append 'P.S. I love you. Get your free email at Hotmail' to every outgoing email way back in the day, and no one ever had a problem with that..."
Welcome to the all-new eStop! We know you have concerns, so let us put them to rest straight away.
The site will not change. We respect the investment you've made in learning and navigating the site. However, if you're feeling curious or adventurous, feel free to check out our [new site design prototype]. (This design will become the default landing page in mid-2027; the old site UI will enter maintenance mode for only the most critical bugs.)
To thwart LLMs and other bots, new default limits on bidding have been imposed. Accounts may only bid on a given item no more frequently than once every 20 minutes. If your circumstances require more frequent bidding, have a look at our [eStop Pro Membership Plan] for only $9.95/month (billed annually; no pro-rated refunds), which will allow unlimited bidding frequency. And for members who want to have more than 20 items on sale simultaneously, take some time to review our [eStop Bulk Vendor Programs], charging only 25% of gross sales, or $3600/year + 20% of gross sales.
And to help with "doomscrolling" for that one specific thing you're looking for, we've also partnered with Anthrop\c and X's Grok to help curate your buying experience, surfacing the items most likely to interest you.
(All terms are subject to change without notice.)
"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.
an amusing example of how training can go wrong
My understanding is that this isn't a consequence of a flawed training algorithm or process; it's instead a consequence of the limitations of LLMs, emergent from their training materials. It closely parallels another example I've seen around the net, that of asking an LLM about getting a car to the mechanic, noting it's a sunny day and the mechanic is just a block away, and having the LLM suggest walking... which is a consequence of the bias in training materials toward walking because lots of people make visible posts about their having done so (because it's looked on favorably), whereas people who drive short distances (of which there are many, probably outnumbering walkers) don't trumpet having done so online, leading LLMs to emit advice about walking when possible (and in the case of the mechanic example, having a lack of comprehension of the pivotal aspect of having the car make it with you to the mechanic's shop).
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).
(a/k/a Innovation Subscribers Don't Need)
It still amazes me that, as late as the 1990's, and well after 56kbit modems were prolific, ISDN was being offered up by the ILECs as "broadband," at metered rates that made Ma Bell's long distance charges look like spare change.
Happily, it wasn't too long before ISDN was put out of everyone's misery when DSL showed up. And now, finally, after fifty years of pissing about, fiber is finally being pulled to the premises.
If you really need ongoing ISDN support, you can pull the source code from an old Git commit and update it. But I feel quite comfortable in opining: ISDN support will not be missed.
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.
The rule on staying alive as a program manager is to give 'em a number or give 'em a date, but never give 'em both at once.