Yes. The construction jobs are very short-term, and once built the data centers bring huge costs (financial and otherwise) while contributing only a handful of permanent jobs. Remember, these are lights-out hands-off facilities. They'll employ a handful of security guards and maintenance workers, the rest will all be handled remotely from Malaysia or the like.

True up to a point, and governments are past that point. They can in fact tell companies what formats the government will accept and generate and companies can't afford to just ignore that. And that's actually the first step towards sovereignty: dictate formats that aren't controlled by hostile entities. So, start by declaring the ODF formats the official government standard formats. You'll accept documents in other formats, but you can't guarantee they'll be correctly rendered on your end and you won't put any effort into trying to clean up Word and other non-standard format documents. If they're bad or unreadable or whatever, they'll be rejected and it's on the sender to fix the problem. When you send documents you'll only send them in ODF format, no others, and it's on the receiver to be able to read them.

Internally you standardize on something like LibreOffice that natively handles ODF formats. Anyone else can use anything they want as long as it can handle ODF. Word, BTW, actually does a decent job of handling ODF. Inertia may be a thing, but remember that governments have a lot more mass behind them than private companies. If the government insists and won't budge, any company that needs to do business with the government will slowly come around.

I'm guessing gift cards were handier for unbanked and underbanked people, such as teens who earn a cash allowance or earn cash from yard work for neighbors but aren't old enough to have a bank account in their own name.

So now NHS has nearly half a million headaches. I'm not sure this is an improvement.

Several people are already demoing mobile charging trucks. Pretty soon the AAA will just arrive and plug you in for a quick boost, the same way they'd give you a few gallons of gas.

Since when are the rich important...

I am keeping a list of articles that show a number of European countries (not just EU ones) moving to increase their digital sovereignty. Given the behaviour of the American administration and the behaviour of American tech companies, this is hardly surprising.

Use BlastEm, a Mega Drive/Genesis emulator by Michael Pavone whose nightly builds recently grew support for 32X, an accessory that bolts two SH-2 CPUs onto the Genesis.

Please, no. Often when writing code I need the API reference and only the API reference. I know what I want to do and how to do it, I just need a quick check of the exact order of arguments or exact symbol names. I don't need to try to sift that out of commentary. Likewise when I'm learning how to use the library I'm more interested in the overall view. I don't need to know the exact names of the options for a call, only what the options are for. I expect the code in the user's guide to be accurate, but I don't want the same things out of it that I want out of the API reference.

Except for the bit where it does that caching for a loop where each lookup only occurs once. Because everybody caches lookups, so that must be the right thing to do (it's the most likely thing to happen) in a case where the cache is never used. Riiiiight...

Something critical to note: intent is the most important thing to document when it comes to software. You can see what it does by reading the code, that's straightforward. What I need to know most, both when writing software and maintaining it later, is why it's doing that. What's it supposed to be doing? Why is it doing it in that way? What were the alternatives and why weren't they chosen? How is it supposed to be used by code that calls it? An LLM can't generate any of that just from the code.

This is why traditionally software libraries have had two separate pieces of documentation: an API reference that details every call and it's arguments and results, and a user's guide that lays out how and why to use the library.

This has been typical behavior for large companies when dealing with vulnerability reports for decades. Report one, they treat you as the problem. They'll try to ignore it, consider it "not exploitable", delay and deflect as long as they can get away with it, anything but address the vulnerability. And they'll never tell anyone the vulnerability exists. This only changes when they have no choice but to admit to the problem and fix it, usually when the vulnerability is being publicly exploited. They push "responsible disclosure" because it includes the reporter not making the vulnerability public until the company has a fix, which allows them to stall disclosure as long as they want.

It used to be enough to just include a reasonable deadline when reporting it, after which the reporter would make it public if the company hadn't taken some action on it. Then companies started threatening and then taking legal action against the reporter as soon as they reported the problem, playing the deadline up as "blackmail".

So, what do you do when faced with this? The only reasonable response is to skip the company entirely and make the details public immediately. You're going to be facing retaliation from the company either way, this way the public isn't vulnerable for an extended time. And yes you include details on how to exploit the vulnerability, ideally via working code, so researchers other than the company can confirm it's a real vulnerability that's actually exploitable without having to take your word for it. No, that doesn't give the bad guys anything because remember the working assumption for vulnerabilities: if a good guy has found it, the bad guys already know about it and are using it. Remember that when the company whines.

If your web browser didn't store a session identifier in a small file called a cookie, how would Slashdot's server know that you're logged in as ArchieBunker (132337)? Otherwise, I'm not sure where you've mentally drawn a line between cookie storage and "a filesystem" proper.

Before Rust can save Linux from AI, wouldn't someone need to save Rust from AI first? The Open Slopware page claims that LLVM's LLM policy requiring a human in the loop is overly permissive.

Absolutely, much better for everyone if they just got rid of the peasants