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.

Give it time, he also doesn't watch TV, but only just recently stopped announcing it.

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.

I appreciate your ideas, but this will never work. Executives (and every other sane person at the company) will always be more interested in their own success than in the company's success.

It's actually pretty understandable.

Despite the meme power of a broken login, the bug affects a fallback feature you might well go years without using.

It requires you have PIN/Touch sign in enabled; which if you've enabled that, that means that is how you normally login.
And that works just fine. Nothing is broken there.

What is missing is a "password" icon in the 'fallback' options to "sign in a different way" (using a password, e.g., instead of a PIN or fingerprint.)

So despite being on the login screen, its not actually something you are going to regularly interact with normally, unless you forgot your pin or something. And its hardly something human beta testers are going to think to explicitly test for, every single build. And since the bug is a missing element as opposed to a visibly broken element, well, its easy to fail to notice something you almost never use isn't there.

Meanwhile, clicking where its supposed to be still actually works, so its entirely plausible that you could have automated test scripts that continue to pass if they've been scripted to click at coordinate (X,Y), or to select the password button programmatically by an identifier or something, and then 'expect' something to happen in response, because the button is there and it works just fine, its just missing its texture or something. This would slip past a lot of test frameworks, the button is "in the model", "its active/enabled", "its selectable", "its clickable", and "it fires a click event if you click", "and whatever it is supposed to do happens", and its probably even "visible" (though you can't see it); most likely the icon or texture is missing or unassigned or referencing a transparency by mistake, and its just a "transparent button". So unless you specifically add checks to screen capture and compare a pixel block range to a reference image bitmap or something, you aren't even going to catch it with an automated test.

Tests like THAT do exist and can be written, but its not usually very useful, and the cost to write and maintain such tests with reference images is huge. change an icon or font or background color and a zillion tests need to be updated. Its a difficult balancing act to decide what to test, even for a highly competent QA team.

It's possible it just outright incompetence too... but in this case, for this bug... its pretty understandable.

How should the CEO have addressed that problem?

You mean MS has outsourced QA to AI. I would think volunteers would have found that issue quickly.

Depends on what "preview” means. If it means an alpha build meant to be internal, such a bug is fine. To me this build was meant to be shown and tested by customers and closer to a beta build. Nothing ruins testing like the inability to test anything.

One time my company was asked to test some software for a supplier. The software would not run after install on any of our computers. There were no errors displayed to give us hints about what could be wrong. Despite weeks of correspondence with their development team, we could never get the software to run. After the testing period was over, they sent us a questionnaire. Unfortunately we could not answer most of the questions as we could never get it to run. One final question was about the readiness of the software for production. We said the software was not ready for production.

The development team was not happy about that and emailed asking for reasons why we said that. I assume their supervisors read the questionnaire responses. We told them that any software that would not work after weeks of correspondence and no hint about what to fix was not production ready. They responded they had since fixed all installation issues in the latest version. We answered back that we could only test the version we were given and that version did not work.

I did not say that. The OP specifically said there were no "Unix desktops." Read the thread.

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.

That wasn't *all* I said, but it is apparently as far as you read. But let's stay there for now. You apparently disagree with this, whnich means that you think that LLMs are the only kind of AI that there is, and that language models can be trained to do things like design rocket engines.

I would guess weight is more of a consideration for consumer passenger airplanes than military ones. After all, airlines do not have magazines anymore to save weight.

Well it was a busy holiday season for the US. The rest of the world view Thanksgiving as a Thursday. American carriers were busy for sure.

This article and the data behind it are talking about what is and is not based on the Linux kernel not what the general population defines as Linux. You want everyone to ignore that while making your argument.

Strawman argument. Anyone who knows anything technical about Android knows it is based on the Linux kernel.

Classic whataboutism. You might as well speculated that a meteor will wipe out civilization and no one can update Android anymore. That is equally as relevant as your scenario. Android uses the Linux kernel today. It is considered based on Linux today.

Yes it is a lot of ignorance. As someone who is on slashdot, I assumed you would know better.