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.

Do these people really think they're hiding Directive 4 from us?

We are only a year out from the murder of a health-insurance executive, so the police are more on edge than usual.

Then we need to threaten such things much more often, so that the cops will eventually get used to it, and relax. ;-)

Debian never tried to kill me through my computer. I'd appreciate it if my car manufacturer made their car as safe as my computer.

Fuck it, I just want a Debian car. Then I won't need to extract bloody vengeance from beyond the grave, as my zombie revenant tracks down the CEO of Subaru, and the rotting flesh of my hands tightens around his throat as payment for the time a popup distracted me.

Some people are busting out "definitions" of "End to End Encryption" but people were already using that as in informal descriptive term long before your formalized technical jargon was made up. Nobody should be surprised if there are mismatches. Have faith in our faithlessness.

I personally view the term as an attempt to call semi-bullshit on SMTP and IMAP over SSL/TLS. In the "old" (though not very old) days, if you sent a plaintext email (no PGP!), some people would say "oh, it's encrypted anyway, because the connection is encrypted between your workstation and the SMTP server, the connection from there to some SMTP relay is encrypted, the connection from there to the final SMTP server is encrypted, and the recipient's connection to the IMAP server is encrypted."

To which plenty of people, like me, complained "But it's still plaintext at every stop where it's stored along the way! You should use PGP, because then, regardless of the connection security, or lack of security on all the connections, it is encrypted end to end. Never trust the network, baby!"

Keep in mind that even when I say that, this is without any regard for key security! When I say E2E encrypted, it is implied that the key exchange may have been done poorly/incorrectly, mainly because few people really get to be sure they're not being MitMed when they use PGP. You can exchange keys correctly, but it's enough of a PITA that, in the wild, you rarely get to. You usually just look up their key on some keyserver and hope for the best. Ahem. And I say "usually" as if even that happens often. [eyeroll]

Indeed, every time I hear about some new secure messaging app/protocol, the first thing I wonder is "how do they do key exchange?" and I'm generally mistrusting of it, by default. And sometimes, I'm unpleasantly unsurprised, err I mean, cynically confirmed.

But anyway, if my E2E definition matches yours, great! And if it doesn't, well, that's ok and it's why we descend into the dorky details, so that we can be sure we're both talking about the same thing.

How many hours of an Asian font designer'(s) time can you buy for $20k? It'd be funny, if it turns out that firing the font company pays off in less than a year.

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 is zero value in some big scary climate risk number also being disclosed, because A that risk accounted for if you are studying the details anyway and does not help you make a rational decision, because it literally does not affect you beyond the places where it is already baked into the numbers.

If you don't care why the insurance is so expensive or unavailable (e.g. high risk of flooding) then maybe you also don't care about why the house's price is so high (e.g. nice location, good construction, etc). No need to even look at the house. Just treat the whole damn thing as an abstract exercise in numbers.

OTOH, some people might actually care about details. Maybe because they're considering living there?

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.

Once again, Open Source is embarrassed and left behind.

mplayer and mpv still, after all these years, don't have a way to prevent things from working if the content origin happens to be Netflix. It just plays on, stupidly Just Working, instead of breaking the way that Netflix realized their users want it to break.

To be fair your link does say "designed to bypass internet filtering mechanisms or content restrictions", so it sounds like SSH, work VPNs, banking etc. don't count because they aren't designed to get around the porn filters.

You make sense, but there is nothing that is "designed to bypass internet filtering mechanisms or content restrictions" more than SSH and VPNs bypass internet filtering mechanisms or content restrictions, is there? Why would anyone ever design a tool to get around filtering and restrictions, when they can already do that with established mainstream tools such as SSH or VPNs?

I can't believe the bill is intended to never be applied to anything. If we do think it's written in such a way that it never applies, I don't think it'll be litigated that way. Once it's enacted, they're going to say it applies to something, and that something is going to be anything that is secure.

You didn't read the bill very closely.

I think I read it much more closely than you did.

Sec 2(a):

"Circumvention tools" means any software, hardware, or service designed to bypass internet filtering mechanisms or content restrictions including virtual private networks, proxy servers, and encrypted tunneling methods to evade content restrictions.

This is either intended to apply to something or never apply to anything. Do we agree that the text is intended to do something, to somehow cover some possible situation which might realistically come up? You don't think they just put this in there, but with the begrudging admission that it could not ever possibly apply, do you?

Assuming you're still with me there, please give an example of what kind of tool this defines as a circumvention tool. Surely you have something in mind.

The bill is about outlawing the distribution of p0rn, and a VPN is merely listed as an unlawful circumvention tool.

That might have possibly been the original intent several years of editing ago, but I do not see anything in the definition of "circumvention tools" which even tangentially relates to porn. Do you? I think porn is 100% irrelevant in this discussion.

What I'm getting at, is that there isn't a "porn version" of Wireguard or SSH or HTTPS. They're all the same, content-neutral. The bill either bans them all, or doesn't ban anything. If you take my above bolded challenge to name a circumvention tool that this bill does address, I'm going to take all of your arguments that you give for why the law does apply to your circumvention tool example, and I am going to successfully apply them to SSH and HTTPS. And I'll be exactly as correct as you.

The only way this bill doesn't restrict SSH and HTTPS, is if it doesn't restrict anything at all. Don't agree? Then name something it does restrict.

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.