roca

The two approaches are completely different. gdb singlesteps the program and, before each instruction, records the state of registers and memory that will be changed by that instruction --- an undo log. Then you can reverse-execute an instruction by restoring the state from the undo log. This is incredibly slow because singlestepping requires a full context switch for each instruction executed.

rr, on the other hand, intercepts all system calls and other sources of nondeterminism but regular CPU instructions execute normally with no overhead. The details about rr are here: https://arxiv.org/abs/1705.05937

https://pernos.co/about/javascript/ is somewhat like that.

One option would be to combine chaos mode with a dynamic race detector to try to focus chaos mode on specific fine-grained races. Someone should try that as a research project. Not really the same thing as rr + TSAN.

There's still the fundamental limitation that rr won't help you with weak memory orderings.

Actually the gdb implementation predates rr, but (as an rr maintainer) I have to say that it is vastly inferior to rr. It's about 1000x slower than rr, and can't record across system calls or multiple threads or processes. It's so limited it's really a different feature.

rr supports Aarch64 pretty well now.

It's far easier to hide malicious code in C or C++: just write some subtle undefined behavior that you can write an exploit against. Developers do that all the time even when they're not trying to be malicious. In Rust you'd have to wrap it in "unsafe" which draws attention.

What I'm curious about: other than checkbox compliance, how does Crowdstrike convince companies to buy their product? Do they present evidence that their product is effective at protecting customers? Because certainly Crowdstrike customers still get hacked.

Sort of. They need to be sued into bankruptcy. Current shareholders get completely zeroed out; the company still exists, but is sold to the highest bidder with the proceeds paid out to affected customers.

We need this so that every company board is always asking "are we investing enough to make sure this never happens to us?"

Crowdstrike was hacked by Russians?

It is nothing like FLoC.

Yeah, I thought exactly the same thing. If you didn't know what kind of person Elon is after the Thai cave diver incident in 2019, you weren't paying much attention.

They mean something like the minmax algorithm used in game engines.

And yet a few people are doing it. So yeah, it's advice to insane people.

Those are interesting points, but disabling the JIT doesn't really change anything unless it means you can forgo site isolation, and that would be a very risky bet.

It may be that disabling the JIT is fine for users most of the time. However, that is also a tough call --- so easy for your competitors to beat you up with benchmarks, and there will be real use-cases (e.g. emulators) where it matters to some users.

And of course there's a lot more to perf than just the JIT. I barely mentioned JIT in my blog post.

I could be wrong but AFAIK Safari still doesn't have site isolation, so security-wise it's considerably weaker.

Indeed you can incrementally improve existing engines, and certainly that's what you would try to do if you wanted one of those specific features. But I didn't write the post because I want those features, I wrote it in the hope that it might be helpful to people who are already planning to write a competitive browser engine from scratch.

Yes, for almost every conceivable features you'd be much better off adding it to an existing engine. Maybe you won't get buy-in from the core maintainers, so you'll have to maintain an out-of-tree branch, but that's still going to be much less work than doing your own engine.

I guess one of my points is that layout algorithms are not really part of the "most basic" decisions anymore. Replacing layout algorithms is actually a lot less disruptive to the engine architecture than switching to site isolation, say.

I was inspired to write it by reading about Ladybird, so I wrote it for Andreas Kling basically :-). But there is also Flow: https://www.ekioh.com/flow-browser/ and Servo. Maybe in the future someone else will try. Also I think it's fun to think about these things even if you're not building a browser engine. It only took about 90 minutes to write.

I think sooner or later you're going to want to load lower-trust content --- IFRAMEs of third-party Web content, or sandboxed extensions, or something like that. Building your entire architecture on the assumption you'll never have to do that is very risky.

Any kind of regulated doping has the same problems as the current anti-doping regimes. Whatever regulations you have, some people are going to try to get an advantage by breaking them. You need to catch some of those people or you don't really have regulations.

The goal becomes "dope the athlete the exact amount to win the final and drop dead immediately afterwards".

malloc() returning NULL isn't that helpful. Most applications just react to that by aborting, and most applications that don't abort take poorly-tested error-handling paths that often don't work. I don't remember ever seeing an application that reacted by trying the allocation again but requesting less memory.

I have seen applications react by pausing and trying the allocation again a few seconds later --- this can be shockingly effective! https://hacks.mozilla.org/2022/11/improving-firefox-stabilit...

In my Rust projects (including Pernosco, 200K lines), less than 0.1% of code directly uses "unsafe". It's a long way from there to 20%.

A tax on empty properties can't be passed onto renters.

What if Settlers had simultaneous time-limited turns? With a simple app assistant and a few rule tweaks, you can play six-player Cities And Knights in 45 minutes.

It's an impressive project. One of the key problems for any safe language interoperating with C++ (even a safe C++ subset) is that you really want to be able to interact with C++ standard library types (string, vector etc) safely because they will appear at interface boundaries. Circle introduces its own safe standard library so I don't see how Circle fares here.

Rust's affine types and borrow checking give safe Rust a lot more power than the safe subset of Ada95. A trivial getter method that returns a reference (i.e. pointer) to a field of its object is safe in Rust, but in Ada95 (and C++ and most other non-GC languages) in general you can't ensure the object outlives the reference.

It is true that Ada has a safe suitable-for-systems-programming subset that's much better than most languages. I think when people say "Rust is the first safe systems programming language" they implicitly mean "that is expressive enough for me to replace C++ with".

How does "redo the call with a smaller size" possibly help you? If you could get by with less memory, you should have asked for less memory in the first place.

The claim that Rust makes the safety of 20% of code worse requires some justification. It is utterly contradictory to my experience. Having to do a dynamic check (an array bounds check, or `Option::unwrap`) does not make code "less safe".

I'm not in the US. You can do the same thing without physical documents, just convert the PDF to JPEGs and submit those to the model.