Whenever people start talking about things called "the rise of fascism in the US" as if its a foregone fact rather than a highly fringe opinion, it's unfortunately rather easy to assume that the person doesn't have a good ability to tell fact from "story they heard online from a web post".
It's fine if you want to argue that there is a rise in fascism in the US, but you need to actually pose that argument, not just talk about it as if its true and that everyone agrees with you.
Also, there is not currently any martial law in South Korea. That was a brief event that lasted a matter of hours from when it was announced and when it was repealed. It's an open question if any actions were actually performed under the guises of it.
The POTUS is calling for his political enemies to be executed. He has sent soldiers - illegally - into “Democrat cities”. He is using what is left of the DOJ to prosecute political enemies. The dismissal rate in the DC circuit is at 20% due to all the baseless vindictive prosecutions. The FCC is cancelling shows critical of the POTUS. SCOTUS is allowing racial profiling. ICE has committed a half dozen high profile cases of political violence against protestors - several in direct violation of a federal judges orders.
But yes, you are its hysterical fringe voices calling this the “rise of fascism in the US”.
The source I linked is written by a historian[0] - a guy who actually studied how this kind of stuff happens. You'll also notice that his post uses a fairly high standard of proof - using 2 different definitions of fascism and using only the wannabe-dictator's own statements to show he satisfies all points.
There's also a YouTube video and a YouTube video. Here's an actual lawyer talking about the legality of the proto-dictator's actions: https://www.youtube.com/watch?v=hybL-GJov7M
Otherwise there's the question of where exactly the API boundaries are. In the most general case, your unsafe boundary is going to be the module boundary; as long as what you publicly expose is safe modulo bugs, you're good. In this case the fix was in a crate-internal function, so I suppose one could argue that the public API was/is fine.
That being said, I'm not super-familiar with the code in question so I can't definitively say that there's no way to make internal changes to reduce the risk of similar errors.
Ultimately all software has to touch hardware somewhere. There is no way to verify that the hardware always does what it is supposed to be because reality is not a computer. At the bottom of every dependency tree in any Rust code there always has to be unsafe code. But because Rust is the way it is those interfaces are the only places you need to check for incorrectly written code. Everywhere else that is just using safe code is automatically correct as long as the unsafe code was correct.
This made me quite curious, is there a list somewhere of what bad APIs have been removed/improved and/or technical debt that's been addressed? Or if not a list, some notable examples?
I don't know that there's a list, but cases come to mind because they've been controversial.
(Not a Linux hacker, so apologies if I get this wrong)
The filesystem APIs were quite arcane, and in particular whether or not you were allowed to call a C function at a certain point wasn't documented, and relied on experience to know already.
In trying to write idiomatic Rust bindings, the Rust for Linux group asked the filesystems maintainer if they could document these requirements, so that the Rust bindings could enforce as much of them as they could.
I have. I personally really enjoy the recent crop of UI frameworks built for the web. Tools like Solidjs or Svelte.
Whatever your thoughts are about react, the JavaScript community that has been the tip of the spear for experimenting with new ways to program user interfaces. They’ve been at it for decades - ever since jQuery. The rest of the programming world are playing catchup. For example, SwiftUI.
VSCode is also a wonderful little IDE. Somehow much faster and more stable than XCode, despite being built on electron.
Great points! I think your point about the JS community is often overlooked. Electron et al have made desktop UI/UX considerations more salient in the JS world. Desktop-like experiences in the browser can be great.
The toughest thing to realize is that it is not obvious. Other posters here say it's a human, which was my assumption. But I wouldn't bet my savings either way anymore.
reply