HN user

roca

5,598 karma

Robert O'Callahan. Christian. PhD from CMU (2001) in static program analysis. Former Mozilla Distinguished Engineer. Primarily worked on Gecko layout and rendering. Started https://rr-project.org and currently maintaining it. Cofounder of https://pernos.co, an omniscient debugger that people actually use. Google.

Posts7
Comments1,527
View on HN

Record-and-replay debuggers like rr and UndoDB are designed for exactly this scenario. In fact it's way better than logging; with logging, in practice, you usually don't have the logs you need the first time, so you have to iterate "add logs, rerun 600 times" several times. With rr and UndoDB you just have to reproduce once and then you'll be able to figure it out.

You are correct. I worked on this for years at Mozilla. See https://robert.ocallahan.org/2007/02/units-patch-landed_07.h... and https://robert.ocallahan.org/2014/11/relax-scaling-user-inte... for example. Some of the problems were pretty hard but the Web ended up in a pretty good place --- Web developers pretty much don't think about whether scaling factors are fractional or not, and things just work... well enough that some people don't even know the Web is "free-scaling UI"!

Huh. I would pull out my phone, hold down the power button, and talk to Gemini Live. That's shipping today.

Altman apparently doesn't know what he's competing against. Not a good sign.

AI 2027 1 year ago

The least plausible part of this is the idea that the Trump administration might tax American AI companies to provide UBI to the whole world.

But in an AGI world natural resources become even more important, so countries with those still have a chance.

I don't know where that ranking comes from. It also matters that attackers adapt: UAF exploitation is harder than out of bounds, but it is well understood, and attackers can switch to it, so shutting off one source of UB isn't as effective in practice as you might expect.

Writing new graphics drivers in Rust will definitely be helpful, and is starting to happen.

The safety of LLVM and GCC need not be a priority... they're not normally exposed to untrusted input. Also, it's a particularly hard area because the safety of generated code matters just as much as the safety of the compiler itself. However Cranelift is an interesting option.

No silver bullet here unfortunately... but writing new infrastructure in C or C++ should mostly be illegal.

There isn't anything new here to defend against lifetime-related UB. For that it simply references https://arxiv.org/pdf/2503.21145, which is just a summary of existing dynamic mitigations --- which don't fix UB at the language level, impose performance tradeoffs, and in the case of pointer integrity, require hardware support that excludes e.g. x86.

Look at it this way --- mature products like Chrome are already doing all of that wherever they can. If it was enough, they wouldn't worry about C++ UB anymore. But they do.

Musk's rightward lurch will be good for the electric car transition. His ideological opponents are just switching to other EV vendors. His ideological friends would normally not have considered buying an electric car, because anthropogenic climate change is a socialist hoax or something, but Trump is instructing them to buy Teslas as a sign of solidarity.

Discworld Rules 1 year ago

But what if Putin thinks that unless he takes Ukraine, Russia will cease to exist (or Putin will cease to exist). In that scenario, taking Ukraine is an existential goal for Russa, and he will blow up the world unless he wins.

Russia's nuclear arsenal is a perfectly adequate guarantee of Russia's security. Putin knows this, which is why he's happy to leave Russia's western border with NATO practically undefended while he pursues Ukraine. (This also disproves the "Putin invaded Ukraine because he's afraid of NATO" lie.)

It's more plausible that Putin's survival depends on the outcome of the Ukraine war. But "mad Putin blows up the world" is as much a problem for the Russians as anyone else.

A kernel maintainer can completely ignore any submission with no repercussions even in principle. And they often do.

In Firefox, in my era at least, a reviewer who simply ignores a review request indefinitely was not doing their job and would get yelled at by someone --- me, if it came to my attention.

This part of the reply exemplifies one of the big problems in the kernel community:

You think you know better. But the current process works.

Regardless of how badly broken the kernel development process is, Linus and others observe that Linux continues to dominate and conclude that therefore the development process "works". Success in the market blinds the successful vendor to their defects. Sound familiar?

If Linux carries on down this path then eventually something else that has been subject to more evolutionary pressure will displace Linux, and we'll all be telling stories about how Linux got complacent and how it was obvious to everyone they were heading for a fall.

And honestly, with maintainers like Hellwig maybe that's what needs to happen.

It's way more painful to contribute to the kernel than contribute to Firefox, at least, unless things have changed since I was involved with Firefox.

Suppose you find a bug in the kernel and come up with a patch. You email the patch to some kernel mailing list and ask for feedback. Typically, you will receive no response whatsoever, because no-one is responsible for responding. You can try emailing random developers and eventually maybe one of them will have mercy on you.

In Firefox and I think Chromium, you can file a bug, attach your patch, request review from someone (the UI will help you choose a suitable person), and it's their job to respond.

Refactoring can be painful in Rust when it involves very low-level changes in semantics

I don't know what this is about. In my experience, refactorings that change the semantics of APIs are much easier in Rust than in C. E.g., change assumptions about the lifetimes of pointers passed into APIs: the Rust compiler will tell you where you need to change anything; the C compiler will happily compile your code and you'll corrupt memory at runtime.

It doesn't motivate me any more.

I find it hard to understand how $60K means no motivation but $100K would be highly motivating.

I'd like to put more money towards things I care about.

You said later that you care about the public health system and helping the elderly. That's where a large percentage of our taxes go.

Huh? Dividends are income. Or are you talking about the non-monetary rewards of owning a business?

No, I'm talking about selling all or part of the business. I agree with you that it's a problem our businesses often sell out to overseas interests who hollow out the company. But the general pattern of making most of your money by selling shares in the business is completely normal worldwide.

I'm also on the 39% marginal income tax rate in New Zealand. That income tax rate isn't the problem. Keeping $60K out of every $100K extra salary I make is plenty of motivation to work harder to make the extra $100K... especially because the taxes paid aren't burned, they mostly go to things I care about.

The income tax rate isn't all that relevant to the costs and benefits of starting a company, so I don't understand that part of your story. The rewards for founding a successful company mostly aren't subject to income tax, and NZ has a very light capital gains regime.

I have started my own company and I do agree that there are some issues that could be addressed. For example, it would be fairer if the years I worked for no income created tax-deductible losses against future income.

But NZ's tax rates are lower than Australia and the USA and most comparable nations, and NZers start a lot of businesses, so I don't think that is one of our major problems at the moment.