dcsommer

What is the binary size comparison including wasm + js?

https://www.memorysafety.org/docs/memory-safety/

Codecs are difficult and expensive to develop. Therefore they get reused in many contexts, including security critical ones. Sandboxing is shown over and over to not be a great security solution, so what this means in practice is that security-critical software that needs software decoding get pwned because software engineers don't care to prioritize it in the first place.

Why shouldn't safety be the default? If you really want to, it wouldn't be too hard to maintain a patch on top of rustc to drop the bounds checks if you want to compile object files without them.

Software decoding has a safety culture problem, and we need to talk about it.

Performance should not be priority #1. Security should be. Why do we slow down all CPUs to prevent SPECTRE attacks yet continue to write in C? As rav1d shows, the perf loss is far less to migrate from C to Rust than it is to apply SPECTRE mitigations, and adding a sandbox around a memory-unsafe codec is going to be way more expensive again than using Rust code to start.

How is this POV compatible with the exploitable vulnerabilities, caused by memory safety, found in openh264, x264, dav1d, and practically every video decoder out there?

We must not continue to develop media codecs in memory unsafe languages. Small, auditable sections can opt-out perhaps, but choosing default-unsafe for this type of software is close to professional negligence.

I think GP is simply identifying a potential popular niche that could be satisfied in a future city builder game, which seems quite on topic.

Just for reference, Wamedia ships on the major Meta apps and on iOS, Android, Desktop, and Web platforms.

We invested a lot into build system optimizations to bring this number down over time, although we did accept on the order of 200 KiB size overhead initially for the stdlib. We initially launched using a Gradle + CMake + Cargo with static linking of the stdlib and some basic linker optimizations. Transitioning WhatsApp Android to Buck2 has helped tremendously to bring the size down, for instance by improving LTO and getting the latest clang toolchain optimizations. Buck2 also hugely improved build times.

Great reading to see beyond the clichéd, sanitized retellings of that era. It really makes you consider the prices paid for what some call progress.

Great work by the MS team. It is great progress to shift OOB access into a controlled crash. These kinds of panic bugs are then easy to remediate, with clear stack traces, as we see in the turn around time from the report.

basically fine

How many type confusion 0 days and memory safety issues have we had in dynamic language engines again? I've really lost count.

Is there a straightforward path to building Zig with polyglot build systems like Bazel and Buck2? I'm worried Zig's reliance on Turing complete build scripts will make building (and caching) such code difficult in those deterministic systems. In Rust, libraries that eschew build.rs are far preferable for this reason. Do Zig libraries typically have a lot of custom build setup?

It would be cool to build a "library clout" measure for all open source software. First collect for all deployed software systems measures of usage per platform and along other interesting dimensions like how that system relates to others (is it a common dependency or platform for other deployed software). Use this to generate "clout" at a deployed software unit level. Then detect all open source libraries compiled in it by binary signature matching or through the software's own build system if it is open. Then a library's "clout" is built from the clout of the projects that use it.

This clout score might be used to guide investments in a non-profit for funding critical OSS. Data collection would be challenging though, as would callibrating need.

Basically make a rigorous score to track some of the intuition from https://xkcd.com/2347/

This is interesting if true, but without data I can't take this claim at face value.

Neither are high and low surrogates - those are big ranges of code points that are illegal except for one specific (and not recommended) encoding (utf-16). Yet, there they will remain in Unicode.

Digits definitely are a form of text though. Unicode is for writing systems, which definitely includes writing numbers

Seems more proper to call it a `ProbabilityDistribution` type. It's a more general and intuitive way to handle the concept.

Enforcement needs to be on the sales side, as enforcement at the consumer level is obviously impossible to scale. Also, class 2 (and 3) should not be allowed in bike lanes. If you have a throttle, you're not a bike; you're a motorcycle or moped. I see a clear difference in awareness and safety between pedal and throttle usage.

Unsafety in a language is fine as long as it is clearly demarcated. The problem with Go's approach is there no clear demarcation of the unsafety, making reasoning about it much more difficult.

"Strongly typed" is stretching it. Type checking is bolted on and not part of `erlc`. Typing is quite unergonomic in Erlang/Elixir (similar to Typescript bolted onto JS).

The type system is one of the weakest parts of the beam ecosystem.

40% of Americans believe that God created the earth in the last 10,000 years.

Citation needed. That claim is not compatible with Pew research findings which put only 18% of Americans as not believing in any form of human evolution.

https://www.pewresearch.org/religion/2019/02/06/the-evolutio...

Have there been any studies or economists predicting macro-level benefits to the US economy with the tariffs? I'm not aware of any (much the opposite), but I'm interested if they exist.

Yet I feel that AI gives such instant gratification that the boredom and struggle required for imagination is short-circuited and atrophies.

For what languages would removing 'std::' realistically cause ambiguity for practicioners?

If the goal is brevity, the rules could first replace 'std::' with nothing.

It preserves a left to right reading of the code. You don't have to jump visually elsewhere.

I think Rust could use some syntax improvements for pointer manipulation. It has suffix .await, so maybe the community is ready for suffix .* for dereference now too. Visually scanning left and right, along with the extra parentheses, makes pointer-based code in Rust worse than C++ almost. A fully left-to-right syntax would be amazing. EDIT: found https://github.com/rust-lang/rust/issues/10011 and https://github.com/rust-lang/rfcs/pull/3577

CWE Top 25: https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html

Out of bounds write and read are more prevalent then UAF. There are multiple types of bugs that can produce OOB read or write though.

Zig brings developer velocity benefits over C, but developer velocity is not the reason R4L exists. Until Zig has an easily segmented part that is memory safe, there is no demand for its potential benefits in Linux. Memory safety is the only reason a new language was considered within Linux.

Thank you for your educational service. I hope we can streamline money to teachers better as a country so we don't keep losing institutional knowledge and experience like yours.