lambdaone

Enforcing memory safety is good thing, even if it's not perfect; it's the first stage in the long-needed move from throw-it-in-a-bucket-and-hope-it-works "software engineering" toward proper formal-methods-driven actual software engineering.

I feel complaining about it as insufficient is not the ideal way to push things forward. Instead, let's treat the progress on memory safety policy as a first victory in that process, and build on it.

"Undefined behavior" in general is a nightmare. After memory safety, the next target should be the enforcement of underflow/overflow trapping. With the exception of the intentional use to implement modular arithmetic, underflow/overflow should always be an error condition.

It may not be much at the moment, but the thing that I find encouraging is that there seems to be very little pushback against it; the sanity of the Rust approach is very much accepted now.

As other commenters have said, you can do it a bit at a time, converting non-core kernel code to Rust at the edges. Another route to memory (and other) safety would be the C -> WASM -> C route that effectively rewrites/transpiles code to operate within its own sandbox, which also has the advantage that it could at some later date support modules written in languages other than C.

Indeed. People who don't do these kinds of activity wildly overestimate their physical capabilities.

Part of the reason for this, I think, is that Hollywood and TV depicts ludicrous levels of acrobatic and athletic capability as the norm; apparently normal people in movies are depicted catching falling people one-handed, outrunning explosions, and so on.

Climbing, even at an enthusiastic amateur level, is much harder than non-climbers believe, and I think your suggestion that readers try top-roping a 5.9/5.10 to get some idea of even beginning climbing difficulty is an excellent idea.

I cannot even imagine the level of dedication and expertise it takes to do this sort of feat.

What makes Rust great is that its design drew upon decades of understanding of programming language theory and practice, and the designers took bold decisions based on that understanding to avoid the mistakes of other programming languages.

The problem with async Rust is that the async idiom is new, and its interactions with the rest of the software ecosystem not particularly well understood. This makes async support glaringly different from the rest of the language.

I'm glad the designers seem to be taking a step back and reconsidering how everything fits together.

Given that an estimated 70% of security vulnerabilities are currently memory safety errors, I think that justifies the use of Rust all by itself.

But a far greater gain is that Rust is designed right from the start with tighter semantics which make it more suitable static analysis, and that it is, unlike C/C++, largely free of undefined behaviour.

This is good work, and I'm not quite sure why people are complaining about it; there clearly won't be any replacement of the traditional C sudo by this unless it's driven by distros and the community making it happen.

Multiple implementations make it much easier to do fuzzing and generate automatic test suites that may be used to improve all the versions of this critical utility.

In an ideal world, yes, they would by shut down in seconds. Yet BGP hijacks still occur in the real world; here's one from last month: https://slowmist.medium.com/analysis-of-balancer-bgp-hijacki...

And you're certainly right about government-mandated traffic hijacking.

Cool. Domain-limited CAs are a really good idea, and they don't need anything like dynamic downloading of CAA records.

No, that's not needed at all. If the malicious actor can man-in-the-middle traffic to victimsite.com (say using a BGP hijack), they can serve HTTPS traffic to the end user from their MITM server, secured with a certificate issued to "victimsite.com" that is issued by their own CA, and the MITM can then in turn communicate to the real victimsite.com using HTTPS secured by the real site's certificate, signed by its own CA.

Now, there are CAA DNS records, which serve the purpose of restricting the CAs that can sign a particular domain, which would of course be ignored by the malicious actor, but _could_ be checked by the end user's browser. But to the best of my knowledge, no browser does that.

What a terrible logo design, and semingly no real buy-in from any major organization. I'm not surprised this doesn't have any traction.

I think an IPv6-compliance logo scheme would be a good idea, but it should be driven by major commercial vendors like Apple, Microsoft, Google etc on the software side, and supported by industry forums like the WiFi Alliance and the GSM Association on the hardware side. I would love to be able to ditch IPv4 entirely for running large production networks.

I think Apple have already started to enforce IPv6 support on iOS apps. It would also be interesting to audit open source projects for IPv6 support; just the presence of the appropriate API calls would probably be sufficient for a first hack to tell the difference between IPv6-compliant and non-IPv6 compliant applications. This would allow influential distros like Debian to start the process of deprecating old software which is incapable of working properly with modern networks.

Wikipedia policies explicity forbid using Wikipedia itself as a source for Wikipedia articles. See https://en.wikipedia.org/w/index.php?title=Wikipedia:RSPRIMA...

Knowing some people who have done similar things, it's perfectly plausible, and doesn't read like fantasy to me. You're getting a glimpse into a niche subculture, like skydiving or rock climbing.