This doesn't remove the ability to run 32bit processes. It removes the ability for a 32bit process (with 32bit pointers) to pretend it's a 64bit process. Virtually no one used this. x86 != x32. I'll bet you've never come across an x32 ARCH in the wild. No one is removing the x86 ABIs (at least not i686, some of the earlier ones are gone).
This isn't 32bit support as much as it is x64 support for a 32bit application. It has virtually no use case and wasn't really adopted for anything. Anyone wanting to use x64 instructions just compiled x64 binaries. There was a thought that maybe creating 32bit binaries with the ability to access features of x64 CPUs would improve performance, but ultimately it didn't.
Going forward you'll still be able to run 32bit software. i686 != x32 The latter is an ABI no one used and the former isn't being removed.
There's a difference in support for individual hardware, and providing support for a whole ABI. The potential attack surface and the related code is much larger for the latter.
Just like the previous announcement quite a few people focused on the loss of a HAM radio interface card, but buried the lead that the kernel actually removed a whole networking API that this card depended on instead.
Whether the police use facial recognition, or a private member of the public uses facial recognition and hands that data to the police is a distinction without a difference. While it's great that a fugitive was caught, what really needs to happen now is the journalist or rather the facial recognition data source the journalist used need to be dragged through the courts for breaching of privacy laws.
Did the journalist get clear and explicit warning to the guy for the use of facial recognition as required by the GDPR disclosure clauses?
Did the journalist use only their own tech? If not then the "Data Processors" may have something to say about their legal role here.
As far as I can see there's still a terrorist running free... and apparently working for a newspaper.
Yeah I too support anyone who goes and punches people I don't like. They are heros!
Where have I heard this before?... I was going to make a reference to Germany last century but really these days we can just cite America today.
What dork would threaten him for writing code?
I hope on Monday your computer is infected with ransomware. I'm sure you'll roll over and take it like a bitch, because you wouldn't be a "dork who would threaten someone for writing code" right?
without using it for any actual harm.
It actively instructed the AI agent to delete work and attempted to obscure itself as the source of it. It may not cause harm now, but the original act was inexcusable. You are defending actual malware.
You're white-washing a black hat hacker, that isn't a morally high act of rebellion. This act of rebellion had a nefarious outcome which resulted in data deletion. There are other ways to go about this.
Stories like this should make all users of AI thing twice about securing their development environments, rather than blindly surrender to a fad.
I've personally stopped hiring or trusting any people in IT because of stories where administrators get disgruntled and damage company systems. Clearly the problem here isn't AI, it's people, not just those who terrorise (it's not "rebellion" when it causes meaningful damage to an unsuspecting victim), but also those who excuse or dismiss this practice.
I hope someone with good lawyers starts testing how good this guy's lawyers are.
they were poison to some
Sure. If you don't know what the words mean. Wait... are you the Botox woman? I didn't think you were on Slashdot too.
Notably, spike protein or its fragments have been detected in blood and tissues for months after vaccination in a subset of individuals — with reports extending up to 6 months or longer — indicating that expression can persist far beyond initial expectations for this novel mRNA platform.
Wow tell us you don't know the point of vaccinations without telling us.
These findings highlight significant risks inherent to mRNA technologies: unintended organ distribution (particularly cardiovascular)
... you say "unintended", just how did you think "mRNA technologies" work? Whisper sweet nothings into your ear and hope there's no detectable change in cardiovascular systems and COVID just magically ignores you because it thinks you're a cool dude?
There's nothing "unintended" about this.
For criminal negligence by foisting their QA and QC upon their users instead of trained QC/QI/QA personnel.
Without a real ABI-32 Wine will have to use an emulation layer if the processor can't run natively as a 32 bit process.
Now that Linux is getting a growing game player quota, there are gonna destroy a functionality that make that works?
Since Windows never supported this unusual 32/64-bit hybrid, it will have no impact on WINE.
It's actually kind of a cool idea, though. To someone like me who grew up on 8-bit and 16-bit architectures and is regularly taken aback at the size of data structures on 64-bit platforms -- 16 bytes just for a pointer and a length? -- being able to cut those down while still being able to run at full speed [*] on modern hardware sounds really useful.
[*] Assuming it's really full speed. I suspect there's some overhead.
If you want to use this, or 386 builds or whatnot, you can use an old distro. Download them (they're free), and you can keep them forever.
Sure, if you want to run a system with hundreds of known vulnerabilities. Better keep it airgapped.
I checked and, indeed, trying to "move" the "hashmap" generates code to copy enough stuff onto the stack to blow it. I'm going to look into using Pin to let the compiler know that none of that stuff is moveable. Thanks!
Er, actually, the above is incorrect and was a result of my contrived test example. With the real data structures there is no risk of anyone moving them because the code that creates them returns *only* a &'static mut. Effectively, no stack frame ever has ownership of the structures, so there is no risk of them being moved. This is all pretty obvious, actually, and essentially necessary. If there is no heap then everything is either stack-based or something akin to a global.
Yeah, so you apparently missed that I have no heap and the "hashmap" isn't actually a hashmap... and it's actually in the same not-really-moveable space as the data it holds. It would be interesting to look into what would happen if I tried to move it; I think the compiler doesn't actually know that it's not moveable and would generate code to copy it to the stack. That would be more expensive than copying the "contained" data item, since it actually owns its lookup tables by value, rather than holding pointers to heap allocated structure.
As I said, your big-system biased intuitions don't really hold here.
Moving something out of a hashmap and then back into it isn't cheap. I mean, both operations are O(1), but that's amortized and hides significant overhead. I think it's well worth returning a &mut to avoid that, even in the common, std case. In the my noalloc case, it's considerably more complicated than that: The referenced memory isn't really moveable (and it's not really a hashmap). In practice, it would be "copy the data to the stack, leaving the original in-place, then make sure to copy the mutated version back to the original location". The stack consumption of that approach would be worrisome.
This is where the big-system biases of some of the Rust community work against it, and what fuels the certainty of C programmers that C is the right language for tiny devices. In C there would be no question -- you'd just look up the data in the map and return a pointer to it. Very efficient, no needless waste of several hundred bytes of precious stack space or any need to find some other memory region to copy it into. You say that "moves in Rust are cheap" but whether that's true is extremely context-dependent, and it's basically always the case that a pointer is even cheaper.
Unfortunately, the risks of the C approach are very well-understood, and my point in the post with which I entered this discussion was that Rust can be just as good for space and cycle-efficient low-level code as C while also providing significant security and safety benefits. Your arguments would seem to undermine my point about Rust's utility, except that your big-system biases are not, in fact, universal in the Rust ecosystem. There are plenty of people who understand the constraints of writing code on a device with 64K total RAM and a 1K stack who are writing Rust code and ensuring that the language is a good fit.
I came, I saw, I deleted all your files.
