Ugh. I know all that and I am still sick of hearing about memory safety. My teammates spend way more time fixing security issues in “safe” languages than C/C++/whatever. It simply doesn’t matter…
It's hard to compare the two. A low-level memory safety issue can intersect with security. So can a flaw in logic that touches on security, but is reproducible and not undefined in any way.
The latter can often be more easily exploited than the former, but the former can remain undetected longer, affect more components and installations, and be harder to reproduce in order to identify and resolve.
As an exmaple of "more easily exploited". Say that you have a web application that generates session cookies that are easy to forge, leading to session hijack. Not much skill is needed to do that, compared to exploiting a memory safety problem (particuarly if the platform has some layers defenses against it: scrambled address space, non-executable stacks, and whatnot).
Perhaps he's talking about risk compensation (https://en.wikipedia.org/wiki/Risk_compensation) --- e.g. maybe safe languages structurally excluding memory corruption and concurrency problems tempts developers to let their guard down with respect to correctness generally and produce security vulnerabilities that wouldn't occur in a language with C's need for rigor.
Doubtlessly, there is some of that going on. I doubt the risk compensation erases the benefit of memory safety, but let's not kid ourselves.
Joy is probably an improvement on slog, but one person's joy is another's hell. I've inherited a lot of joyful projects that were an awful fit for continued maintenance because joyful meant using new, unproven, and unstable technologies.
I have experienced many identical situations. Some people just love to tinker and over-engineer for the sake of stretching a muscle. It's unfortunate when that sneaks into a prod system that has to be maintained by others.
I've never met Raymond but based on his posts, I have a fantasy that Microsoft would make him "Benevolent Dictator For Life" of Windows desktop OS. At this point, it's the only thing that might save Windows 11 as a daily desktop operating system for power users.
I recently learned of him because of a service that he seems to be affiliated with. This is a service that seems to search for webinars or meetings and surreptitiously records them. It is an interesting concept, but it has definitely baffled some Zoom users. This is a Reddit thread I saw where it seems to be him who is responding to some of the comments: https://old.reddit.com/r/Zoom/comments/1lpvv06/webinartv_ste...
Wonderful article! Programming 68000 assembly is a joy. People are quick to dismiss CISC instruction sets because they mostly encounter x64 with its baggage of legacy, but 68k is something else.
I remember reading Lance Levanthal's 68000 book and doing some toy exercises as my first kind of non-uni assy experience; then when I got to college some IBM 360. When I finally saw x86, omg what a nightmare.
I'm familiar with both those tutorials, and indeed have been programming the 6502 for 45 years (and Z80 for 44).
HOW is RV32I more complicated than 6502 or Z80? I sure can't see it, please explain.
There are more registers, but that's not complicated because they all behave exactly the same as each other (with the sole exception of the Zero register always reading as 0) and every register can be used for any operand of any instruction.
reply