Hacker Newsnew | past | comments | ask | show | jobs | submit | sfink's commentslogin

Considering how prolific anba is, the only way we know he isn't an LLM is because he'd have to be several generations more advanced than the current SOTA. (It is possible that he might be an LLM from a few decades in the future, considering the connection to Temporal.)

anba implemented all of Temporal single-handedly, plus fixed up numerous places in the spec, plus migrated the implementation over some massive changes after other implementers discovered what a monster it all is. The original version of the spec kind of forced two separate internal implementation paths for everything, one for custom calendars and one for the built-in stuff, just to make the built-in one reasonably performant. That was a lot of work to implement, and a lot of work to remove. (I think ptomato shepherded the spec side of that?)

Fortunately, anba knows how to take a break, relaxing occasionally with minor tasks like rewriting large swathes of the JIT code generator to optimize the support on various platforms. He also gets plenty of nutrition, by ingesting entire specs and mind-melding with them.


I feel like those not involved in this space might not realize so much stuff that benefits the entire web/world comes from volunteers like anba and companies outside the usual browser vendors. Whether you’re an individual contributor or you want to push your employer to contribute or let you contribute, the best time to get involved is always now. We owe anba a big one. Thank you!!

True, creating value isn't sufficient. But if you're creating value, you don't need that community; that community needs you. That doesn't mean it'll be easy to leave nor that you won't lose a lot by doing so, but it's better than being a leech. Leeches can only survive by finding another victim to suck blood from, and at some point that merry-go-round is going to run out of horsies. Pardon the mixed metaphors.

Philosophically, I agree, but in reality there are so many leeches, who take take take, their whole life, and in the end they are often better off, materialistically than the people, who provided the actual value.

Ah but of course leeches are better off materialistically than the people who provide value! It's almost a tautology. But do you think they're happier?

For example geohot could be vastly richer than he is if he wanted to. He wisely chooses not to, and advises others to do the same.


In general, it's kind of the difference between having a sharp axe vs a dull axe.

Though in the particular case of the MacBook Neo, I'm not sure whether we're talking about sharper or duller. Depends on the metric you're using, I guess.


It doesn't cut a cake nearly as well as the old Macbook Air so obviously duller.

All of those are only zero-sum if you pick a conserved metric. Land ownership is zero-sum if measured in square meters. But say someone buys up land that is parched, dead, and empty. They use it by planting moisture-retaining crops and windbreaks and growing food, or running a business of benefit to the community. Now overall everyone is a little better off, despite 0 square meters being created.

Influence is even more so -- it's common to have situations where nobody is truly paying attention to anyone else. The people with good ideas can't get any traction, and the whole organization just spins in circles, lurching from one externally-imposed crisis to the next. If the people who gain influence use that influence to promote others who are worth paying attention to (and thus they gain influence), everyone benefits. But if you measure that in terms of how many minutes each person gets to speak at the All Hands, it's zero-sum.


Yes, although we do measure it in square meters (or acres, or tatami mats).

Is there such a thing as "partially zero-sum"? I mean, to express how, unless you get really creative in difficult ways, the supply of land is under pressure due to other people taking all the currently useful parts of it, such as the parts on your island and not underwater.


Careful. Describing depression as "negative emotions" suggests you aren't familiar with the experience.

Negative emotions are the opposite of depression, just as much as positive emotions are. Depression is the lack of affect.

Whether it's a good idea to treat that with meds, or whether meds will do anything, is a whole other topic that neither of us is qualified to address.


I played trombone in high school, never very well, but I definitely adjusted like this. Actually, although it was a slide trombone, I'm talking about adjusting automatically with embouchure. Someone would play the reference note, I'd match (in 1st position) but bend my pitch to match. The band teacher once complimented me on the adjustment. Which was stupid, because (1) I wasn't doing it intentionally, and (2) the adjustment only lasted during tuning; as soon as we started playing, I was right back out of tune. I never did learn to suppress the adjustment so I could actually fix the tuning.

But with the way I played, I'm not even sure how much it mattered. The best tool for enhancing my playing would've been a mute. (And it would have been most effective lodged in my windpipe.)


As someone who saw a bunch of these bugs come in (and fixed a few), I'd say that Anthropic's associated writeup at https://www.anthropic.com/news/mozilla-firefox-security undersells it a bit. They list the primary benefits as:

    1. Accompanying minimal test cases
    2. Detailed proofs-of-concept
    3. Candidate patches
This is most similar to fuzzing, and in fact could be considered another variant of fuzzing, so I'll compare to that. Good fuzzing also provides minimal test cases. The Anthropic ones were not only minimal but well-commented with a description of what it was up to and why. The detailed descriptions of what it thought the bug was were useful even though they were the typical AI-generated descriptions that were 80% right and 20% totally off base but plausible-sounding. Normally I don't pay a lot of attention to a bug filer's speculations as to what is going wrong, since they rarely have the context to make a good guess, but Claude's were useful and served as a better starting point than my usual "run it under a debugger and trace out what's happening" approach. As usual with AI, you have to be skeptical and not get suckered in by things that sound right but aren't, but that's not hard when you have a reproducible test case provided and you yourself can compare Claude's explanations with reality.

The candidate patches were kind of nice. I suspect they were more useful for validating and improving the bug reports (and these were very nice bug reports). As in, if you're making a patch based on the description of what's going wrong, then that description can't be too far off base if the patch fixes the observed problem. They didn't attempt to be any wider in scope than they needed to be for the reported bug, so I ended up writing my own. But I'd rather them not guess what the "right" fix was; that's just another place to go wrong.

I think the "proofs-of-concept" were the attempts to use the test case to get as close to an actual exploit as possible? I think those would be more useful to an organization that is doubtful of the importance of bugs. Particularly in SpiderMonkey, we take any crash or assertion failure very seriously, and we're all pretty experienced in seeing how seemingly innocuous problems can be exploited in mind-numbingly complicated ways.

The Anthropic bug reports were excellent, better even than our usual internal and external fuzzing bugs and those are already very good. I don't have a good sense for how much juice is left to squeeze -- any new fuzzer or static analysis starts out finding a pile of new bugs, but most tail off pretty quickly. Also, I highly doubt that you could easily achieve this level of quality by asking Claude "hey, go find some security bugs in Firefox". You'd likely just get AI slop bugs out of that. Claude is a powerful tool, but the Anthropic team also knew how to wield it well. (They're not the only ones, mind.)


> For the JS shell, similar to fuzzing, a small fraction of these bugs were bugs in the shell itself (i.e. testing only)

There's some nuance here. I fixed a couple of shell-only Anthropic issues. At least mine were cases where the shell-only testing functions created situations that are impossible to create in the browser. Or at least, after spending several days trying, I managed to prove to myself that it was just barely impossible. (And it had been possible until recently.)

We do still consider those bugs and fix them one way or the other -- if the bug really is unreachable, then the testing function can be weakened (and assertions added to make sure it doesn't become reachable in the future). For the actual cases here, it was easier and better to fix the bug and leave the testing function in place.

We love fuzz bugs, so we try to structure things to make invalid states as brittle as possible so the fuzzers can find them. Assertions are good for this, as are testing functions that expose complex or "dangerous" configurations that would otherwise be hard to set up just by spewing out bizarre JS code or whatever. It causes some level of false positives, but it greatly helps the fuzzers find not only the bugs that are there, but also the ones that will be there in the future.

(Apologies for amusing myself with the "not only X, but also Y" writing pattern.)


It is.

If a tree falls in the forest with nobody around to hear it, does it make a sound?

If a computer flips bits while it's not doing anything with that memory, does it have bad RAM?

A fair number of people pretty much only use their computers as web browsers.

QED


I think the firefox crash reporter does now? It does a limited memory scan and reports problems it finds. No privacy violations required.

That's different from what you're suggesting, because you're right that the crash reports are analyzed with heuristics to guess at memory corruption. Aside from the privacy implications, though, I think that would have too many false alarms. A single bit flip is usually going to be an out of bounds write, not bad RAM.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: