I mostly use proton. Even if they kill off my account, I still have offline backups. I also own my email domain, so I won't lose my email address either, unless my registrar decides to do something they're not legally allowed to do.

Do you pay? Yeah. You pay with Google and Apple too, whether you realize it or not. But unlike them, proton gives you an honest price, and you, not them, hold all of the keys. Literally.

I dunno, Apple thinks they have enough clout to blatantly lie to a federal judge and ignore an injunction without consequence. What chance do you think this guy has?

Aside from the choice screens, you can already do all of this on Android. Why does anybody buy anything that doesn't give you these options to begin with? That's just asking to be enshitified at some point. Safari is already enshitified.

Though maybe I'm not the typical iphone demographic. I don't use stupid apps. Basically everything I do is in Firefox. With extensions to disenshitify websites. Maybe what separates me from iOS users is when Reddit says "time to sign in with a shitty app" I say "fuck you, reddit" and disable that crap with ublock if I really need it that bad. Whereas ArchieBunker says "oh yay! a new app! There's an app for that!" and then proceeds to hum the apple ad piano melody.

I don't see any pointer semantics in that. Am I missing something?

Which part of it? The exploit itself? Should be pretty easy, just inject a nop sled til you are memory aligned after the final byte of the unchecked buffer. That's nothing more than pure data; an ordinary vec![0u8; N] will do. Or do you mean the first stage? If so, then anything other than handcrafted machine code is doing it wrong. Which is also just data. Or do you mean any later stages? If so, then you're on crack.

Why bother when you've got slices and iterators? Show me a case where unsafe rust gives you a way of doing this that's even more lazy than safe rust.

It occurs when you need to read or write into a data structure from one ABI into another ABI. Which can be a thing even within the same language.

Socialism will need a wall any time any two economies aren't being run by the same dictator. That's why anybody traveling from the USSR to Yugoslavia required extra-special permission and a KGB chaperone.

Oh one thing I should also add, in case you mean e.g. multithreaded handoff:

Very few reference types aren't Send, namely Cell, RefCell, or Rc. Naturally, if your structs use any of these, they aren't Send either.

Having said that, &T is always Send (and Sync) provided T is Sync. IOW, outside only a handful of cases, you can freely pass ordinary references to other threads. &mut T is a different story, and there are easy and not so easy ways of handling it, depending on how performant you need your code to be. For example, if you aren't picky about locking behavior, you can always simply stick T into e.g. an Arc<RwLock<T>> and literally pass it wherever the hell you want with minimal fuss. This is something you should be doing in *ANY* language, by the way. Golang, Java, etc, won't save you from data races even though they're theoretically memory safe, but safe rust DOES, so languages like those can intermittently crash while multithreading, where safe rust will not (though it can hang/deadlock.)

Not sure what you're referring to. I remember when I first started using rust, you couldn't pass variable of a mutable reference to a function and then use an immutable reference later without the borrow checker complaining. Not sure if this is what you mean? Either way, now you don't need to do anything special for it (e.g. no need to manually drop the variable first) as long as you don't try to reuse the variable again.

For me, at least, it's mostly to the point that you don't even think about it.

How the fuck did you reach that conclusion? Do tell.

Right off the bat I can think of several ways to do not only this but even mutate multiple references. In safe rust.
Like for example https://doc.rust-lang.org/stab...
And of course there's https://doc.rust-lang.org/stab...
And if that's not enough, try from multiple threads too https://doc.rust-lang.org/stab...

Or there's always just...you know...an ordinary reference. Not a raw pointer, like just an ordinary fucking reference. &T is copy. Did I also mention that many of these smart pointers literally compile to just an ordinary pointer? And you still get to keep the safety guarantees.

There are plenty of crates that let you do this in a number of other ways, like interning and garbage collection.

So I'd really like to hear your explanation for why you feel you can't have multiple references to the same location in rust.

This is totally false. Unsafe rust, contrary to common belief by those who haven't used the language, doesn't turn off "all the memory safety" as you just claimed. As noted in one of the links in TFS, the type system continues to be enforced, which also means that pointer lifetimes are enforced by the borrow checker as well. That alone maintains both type safety and temporal safety. Of course, you can defeat temporal safety guarantees with some indirection, but not only is that going to be dead obvious, it's also going to make you look incredibly stupid to every kernel developer. That is to say, for once Linus won't be the only person scolding you about how stupid you are, how shitty your code is, etc. You can defeat type safety with std::mem::transmute, but the same caveat applies.

Data race safety also remains intact unless you explicitly implement the Sync or Send marker traits on your data types, and doing so is going to invite even more scrutiny over your code (it's also something you just plain don't need to do unless you're trying to do some sort of arcane parallel access optimization.) Plenty other forms of safety remain intact as well, such as bounds checks (you can't implicitly skip these) variable initialization, no frees or double-frees, no dirty cows, null pointer safety, and a lot more I'm not thinking of right now.

Which is without a doubt contributing to the fact that exploiting this CVE will only yield a crash rather than anything serious like arbitrary code execution, data disclosure, or fault injection.

Name some specific examples.

That kind of defeats the point of what C is intended to do. C is intended as a more of portable assembly. Abstract concepts like references are too much of an abstraction for that. Though C does carry with it some unnecessary and sometimes nasty footguns, like a = b returning the value of b, which some developers do some nutty things with, like the infamous 'if (a = b) {..}' being an intended feature of C. And some developers insist that such footguns are useful and shouldn't ever be removed.

I've heard zig is like C but it takes away some footguns and adds a safety to others, with the caveat being that even with a safety, they're still footguns.

This is incorrect, unsafe rust doesn't allow you to simply ignore the borrow checker. This is a very common myth, usually stated by C++ developers who already love footguns and poo-poo the language despite never having used it. In rust, ownership rules are ALWAYS enforced no matter what you do. In fact, there are exactly 5 things that unsafe allows:

https://doc.rust-lang.org/book...

You can, in principle, circumvent the borrow checker by converting a normal pointer into a raw pointer and later dereferencing it, which is just adding indirection. But in practice, there's no good reason to do this, and there's likely already an easier way to do what you might be wanting to do with it that doesn't require unsafe. Raw pointers are generally only really useful for FFI, which is already inherently unsafe in any language.

You'd only have a point if the RTO decision came from pressure from politicians, as in the case of San Francisco. I don't know what tells you that the executives of these companies want to pay building lease fees if they don't need to.

Even the British agree that the word "leftenant" doesn't make any fucking sense.

Its just American spelling with a lot of A's added.

Then surely you can provide examples.