One major difference, assuming you've got full platform support(should be the case on any server or workstation that isn't an utter joke; but can be a problem with some desktop boards that 'support' ECC in the sense that AMD didn't laser it off the way Intel does; but don't really care); is that ECC RAM can (and should) report even correctable errors; so you get considerably more warning than you do with non-ECC RAM.

If you pay no attention to error reports ECC or non-ECC are both rolling the dice; though ECC has better odds; but 'proper' ECC and Linux-EDAC support will allow you to keep an eye on worrisome events(normally with something like rasdaemon, not sure what other options and preferences there are in terms of aggregating the kernel-provided data) and, unless the RAM fails particularly dramatically and thoroughly, will give you much better odds of knowing that you have a hardware problem while that problem is still at correctable levels; so you can take appropriate action(either replacement, or on the really fancy server systems, some 'chipkill'-like arrangement where the specific piece of DRAM that is failing gets cut out of use when deeemed unreliable without having to bring the system down.

Sometimes you'd get a BSOD that was a fairly clear call to action; when the error called out something recognizable as the name of part of a driver; but that is mostly just a special case of the "did you change any hardware or update any drivers recently?" troubleshooting steps that people have been doing more or less blind since forever; admittedly slightly more helpful in cases where as far as you know the answer to those questions is 'no'; but windows update did slip you a driver update; or a change in OS behavior means that a driver that used to work is now troublesome.

Realistically, as long as the OS provides suitable support for being configured to collect actual crash dump material if you want it; it's hard to object too strongly to the idea that just rebooting fairly quickly is probably the better choice vs. trying to make the BSOD a genuinely useful debugging resource; especially given how rare it is for the person with useful debugging ability to happen to be at the console at the time of crash(rather than just an end user who is ill equipped to make sense of it; or a system that mostly does server stuff, quite likely not on actual physical hardware, where nobody has even touched the physical console in months or years; and it's more or less entirely useless to display a message there; rather than rebooting and hoping that things come up enough that management software can grab the dump files; or giving up and leaving the system in EMS so that someone can attach to that console.

What seems most depressing about this isn't the fact that the bot is stupid; but that something about 'AI' seems to have caused people who should have known better to just ignore precautions that are old, simple, and relatively obvious.

It remains unclear whether you can solve the bots being stupid problem even in principle; but it's not like computing has never dealt with actors that either need to be saved from themselves or are likely malicious before; and between running more than a few web servers, building a browser, and slapping together an OS it's not like Google doesn't have people who know that stuff on payroll who know about that sort of thing.

In this case, the bot being a moron would have been a non-issue if it had simply been confined to running shell commands inside the project directory(which is presumably under version control, so worst case you just roll back); not above it where it can hose the entire drive.

There just seems to be something cursed about 'AI' products, not sure if it's the rush to market or if mediocre people are most fascinated with the tool, that invites really sloppy, heedless, lazy, failure to care about useful, mature, relatively simple mitigations for the well known(if not particularly well understood) faults of the 'AI' behavior itself.

There's nothing that screams 'trying to con you' quite as hard as a participant in a nominal free-market scenario trying to preserve ignorance and information asymmetry.

What always puzzled me about Intel's...more peripheral...activities is that they seemed to fall into a weird, unhelpful, gap between 'doing some VC with the Xeon money; rather than just parking it in investments one notch riskier than savings accounts' and 'strategic additions to the core product'; which normally meant that the non-core stuff had limited synergies with intel systems; and had the risks associated with being a relatively minor program at a big company with a more profitable division; and thus subject to being coopted or killed at any time.

Seemed to happen both with internal projects and with acquisitions. Intel buys Altera because, um, FPGAs are cool and useful and it will 'accelerate innovation' if Intel is putting the PCIe-connected FPGA on the CPU's PCIe root complex rather than a 3rd party vendor doing it? Or something? Even at the tech demo level I'm not sure we even saw a single instance of an FPGA being put on the same package as a CPU(despite 'foveros' also being the advanced-packaging hotness that Intel assured us would make gluing IP blocks together easy and awesome). They just sort of bought them and churned them without any apparent integration. No 'FPGA with big fuck-off memory controller or PCIe root we borrowed from a xeon' type part. No 'Intel QuickAssist Technology now includes programmable FPGA blocks on select parts' CPUs or NICs. Just sort of Intel sells Altera stuff now.

On the network side, Intel just kind of did nothing with and then killed off both the internal Omni-path(good thing it didn't turn out that having an HPC focused interconnect you could run straight from your compute die would have been handy in the future...luckily NVlink never amounted to much...) and the stuff they bought from Barefoot; and at this point barely seems to ship NICs without fairly serious issues. I'm not even counting Lantiq; which they seem to have basically just spent 5 years passing on to Maxlinear with minimal effect; unless that one was somehow related to that period where they sold cable modem chipsets that really sucked. It's honestly downright weird how bad the news seems to be for anything that intel dabbles in that isn't the core business.

Not delivering on schedule is absolutely a symptom; it's just a somewhat diagnostically tricky one since the failure can come from several directions; and 'success' can be generated by gaming the system in several places, as well as by successful execution.

In the 'ideal' case things mostly happening on schedule is a good sign because it means both that the people doing the doing are productive and reliable and the people trying to plan have a decent sense(whether personally, or by knowing what they don't know and where they can get an honest assessment and doing so) of how long things are going to take; whether there's something useful that can be added or whether forcing some mythical man-month on the people already working on it would just be a burden; keeping an eye on whether there's anything in the critical path that is going to disrupt a bunch of other projects, and so on.

If you start losing your grip on the schedule, that fact alone doesn't tell you whether your execution is dysfunctional or your planners are delusional, or some combination of the two; but it's not a good sign. Unhelpfully, the relationship between how visibly the gantt charts are perturbed and how big a problem there is is non-obvious(a company whose execution is robust but whose planners live in a world of vibes-based theatre and one whose execution is dysfunctional and crumbling and whose planners are reusing estimates from the time before the rot set in might blow a roughly equal number of deadlines; despite one having mostly a fluff problem and one probably being in terminal decline); but it's never a good sign.

It seems reasonable; but also like something that should really spook the customers.

It seems to be generally accepted that junior devs start out as more of an investment than a genuine aid to productivity; so you try to pick the ones that seem sharp and with it, put some time into them, and treat them OK enough that they at least stick around long enough to become valuable and do some work for you.

If that dynamic is now being played out with someone else's bots, you are now making that investment in something that is less likely to leave, whatever as-a-service you are paying for will continue to take your money; but which is much more likely to have a price regularly and aggressively adjusted based on its perceived capabilities; and have whatever it learned from you immediately cloned out to every other customer.

Sort of a hybrid of the 'cloud' we-abstract-the-details arrangement and the 'body shop' we-provision-fungible-labor-units arrangement.

Some customers presumably won't care much; sort of the way people who use Wix because it's more professional than only having your business on Facebook don't exactly consider web design or site reliability to be relevant competencies; their choice is mostly going to be between pure off the shelf software and maybe-the-vibe-coded-stuff-is-good-enough; but if your operation depends in any way on your comparative ability to build software Amazon is basically telling you that any of the commercial offerings are actively process-mining you out of that advantage as fast as the wobbly state of the tech allows.

If the litigation is anything to go by; their "Suicide Solution" nostalgia callback colab with Sony Music Entertainment should be a hit!

From what little we get to see of their books; I full expect them to continue as an aggressively nonprofit org; for a while.

I further expect them to do so in a spirit of arrogant, rapacious, desperation that will just keep getting more intense until that while is up.

So the 'hyperloop' people have a cool website; while the 'train' people are just plain getting on with building stuff; whether conventional or the now-quarter-century-ish old maglev option.

Looks like someone signed up for another round of 'faff with apps vs. offshoring our entire high tech supply chain' and hoped it would work better this time.

And some dumbass 'managing director' is telling us that a gigantic safety-critical vacuum system is 'not effected by strikes'; more or less because he has no idea what the maintenance and operations would involve? Truly a joke telling itself.

They do. Some people don't use them; and (if disciplined) use one or more worksheets to store data and refer to it purely internally and (otherwise) just sort of ad-hoc mix data and formulas.

In some cases a database connection is where the data comes from; but the number of cells grows because it's conceptually easier(and in practice often less opaque, given the ugliness of displaying very large cell contents) to munge on the data step by step rather than trying to ram everything into one transformation.

Coming from the IT side; and having to field questions from the perpetrators of some absolutely hideous excel sheets from time to time(no, I didn't even know that there was a way of creating a type of embedded image that actually quietly triggers the print spooler subsystem to do something that generates a new image based on the contents of another region of the spreadsheet, still don't know how they did that; but it's objectively depraved) I understand the hate; but I do have to admit that spreadsheets are pretty good for napkin-math thinking-it-through type processes.

Like when you work it out on paper; you've got your input, then you have a cell with the contents of the first transformation you wanted to make, then the second, then the third, and so on, and at each step you can think "does this value make sense?"

It rapidly gets out of hand in quantity; but as a rapid sketchpad for thinking something through you could do a whole lot worse. It's also tempting(again, tempting down the path of darkness in quantity) for dealing with jobs that need both a bit of string munging and a pretty-printed output.

You send the intern down to storage with a barcode scanner and have them start snagging SNs and MACs and stuff from the shipment of new gear. Turns out various vendors use different prefixes on different barcode values to inform their own ERP/inventory system/warehouse people which of the 5 closely spaced barcodes their scanner hit. And each vendor uses a different set of conventions, and while obvious enough they aren't documented. Ok, no problem; intern comes back with raw list; all the Lenovo SNs get a 'last x characters' substring; all the Cisco MACs get another transform, whatever.

Obviously if it were your inventory/warehouse system you wouldn't be treating the barcode scanner as a raw HID device and doing ad-hoc transformations, there would be a program that automatically uses the prefixes to populate the correct parts of the form; but you want to stick your head into ERP project hell rather than come up with maybe a dozen lightweight string manipulations? Obviously, you could also do it in your choice of scripting language and iterate through one CSV to create another; but that mostly just conceals what you did from anyone who doesn't use that scripting language; while you can walk basically anyone employable through the logic of the spreadsheet prettifying.

I suspect that it's more symptom than cause, and probably not at the top of the list of causes; but I cannot overstate how much I loathe the hyperbolic use of the term 'unthinkable' in these sorts of situations. Both because it's false; and because it often acquires a sort of implicitly exculpatory implication that is entirely undeserved.

Not only is it 'thinkable'; having something awful happen when you perform a procedure that requires longterm hardcore immunosuppression and then let them follow through the cracks is trivially predictable. It's the expected behavior. Successfully reconnecting a whole ton of little blood vessels and nerves is fairly exotic medicine; predicting that thing will go poorly without substantial follow-up is trivial even by washout premed standards.

This isn't to say that it isn't ghastly, or that I could imagine being in that position; but 'unthinkable' is closer to being a claim of unpredictability or unknowability; which is wholly unwarranted. None of this was unthinkable; but nobody really cared to check or wanted to know all that much.

Especially when basically all methods of sabotaging cables(except possibly very near shore) are 'remote'/disposable; if only at the tech level of 'put anchor on rope because water deep'. Nobody is going to give a damn about losing an inert metal chunk.

Reportedly, none of that is public, the business of tapping a fiber line underwater is considerably more fiddly, and enough mines might make that a hassle; but it would also make install and repair far more expensive and probably just theatre when you consider the risk that someone at the telco isn't updating their ASAs.

I think the parent commenter was proposing an analogy to the various temples-overtaken-by-jungle and cathedrals-and-hovels societies; where the competing c-suites of the magnificent seven and aspirants suck our society dry to propitiate the promised machine god.

I have to say; datacenters will not make for terribly impressive ruins compared to historical theological white elephant projects. Truly, the future archeologists will say, this culture placed great value in cost engineered sheds for the shed god.

At least for new builds/major conversions; it's often a matter of incentives.

There's certainly some room for shenanigans with power prices; but unless it's an outright subsidy in-kind you normally end up paying something resembling the price an industrial customer would. Water prices, though, vary wildly from basically-free/plunder-the-aquifer-and-keep-what-you-find stuff that was probably a bad idea even when they were farming there a century or two ago; to something that might at least resemble a commercial or residential water bill.

If the purpose is cooling you can (fairly) neatly trade off between paying for it in power and paying for it in water; and when the price differs enormously people usually choose accordingly if they can get away with it. In the really smarmy cases they'll even run one of the power-focused datacenter efficiency metrics and pat themselves on the back for their bleeding edge 'power usage effectiveness'(just don't ask about 'water usage effectiveness').

You can run everything closed loop; either dumping to air or to some large or sufficiently fast moving body of water if available; but the electrical costs will be higher; so you typically have to force people to do that; whether by fiat or by ensuring that the price of water is suitable.