georgewsinger

If you're interested in running full Linux Desktop apps instead of Android apps, Simula is getting closer to releasing VR/AR compatible compute packs with laptop competitive specs: https://simulavr.com/blog/compute-pack-progress/

I'm surprised the author didn't mention the other argument for paraxanthine being less addictive than caffeine: it has a less acute/peaky curve of adenosine blocking.

I'm not a biologist, but I'm under the impression that your body uses the heuristic of "the more acutely a neurotransmitter is suddenly flooded into our system, the more of a homeostatic counter-response we're going to launch in the form of things like dopamine downregulation (etc, depending upon what neurutransmitter we're talking about)".

I'm not entirely sure this is true, but it seems to be corroborated by other researchers (e.g. Anna Lembke in her book Dopamine Nation, which isn't about caffeine though).

This is why substances like theacrine claim to offer even less tolerance than paraxanthine: it has a super gradual adenosine-blocking curve, with super long half-life (like 12-16 hours, IIRC). So when you take one theacrine, you won't notice it for hours, but its effects will last longer than one day (though I forget what its interaction with sleep is supposed to be?).

Some explanations considered in this video:

1. Software engineering isn't "real" engineering.

2. Nobody cares about bugs when they write software in the first place.

3. Software is hard.

4. Software is early.

If you like reasoning about a program in terms of expression trees/graphs, I recently discovered that Wolfram Language has built-ins for this:

https://reference.wolfram.com/language/ref/ExpressionTree.ht...

This was such a great story.

Steve was a mischievous person himself, so surely a part of him respected this.

This is so cool. Real-time accent feedback is something language learners have never had throughout all of human history, until now.

Along similar lines, it would be useful to map a speaker's vowels in vowel-space (and likewise for consonants?) to compare native to non-native speakers.

I can't wait until something like this is available for Japanese.

What kinds of speed can be achieved, in terms of words per per minute?

Is this really how SOTA LLMs parse our queries? To what extent is this a simplified representation of what they really "see"?

Does anyone know if NOVAMIN based toothpastes (e.g. Sensodyne) have been tested?

The author should make a meta-entry about how he makes the (insanely beautiful) diagrams in the book (ideally walking through the process).

Insane that people would downvote a totally reasonable comment offering a competing alternative. HN is supposed to be a community of tech builders.

Somehow completely missed that, thanks!

I think reading this makes it even clearer that the 70.3% score should just be discarded from the benchmarks. "I got a 7%-8% higher SWE benchmark score by doing a bunch of extra work and sampling a ton of answers" is not something a typical user is going to have already set up when logging onto Claude and asking it a SWE style question.

Personally, it seems like an illegitimate way to juice the numbers to me (though Claude was transparent with what they did so it's all good, and it's not uninteresting to know you can boost your score by 8% with the right tooling).

Yes, however Claude advertised 70.3%[1] on SWE bench verified when using the following scaffolding:

> For Claude 3.7 Sonnet and Claude 3.5 Sonnet (new), we use a much simpler approach with minimal scaffolding, where the model decides which commands to run and files to edit in a single session. Our main “no extended thinking” pass@1 result simply equips the model with the two tools described here—a bash tool, and a file editing tool that operates via string replacements—as well as the “planning tool” mentioned above in our TAU-bench results.

Arguably this shouldn't be counted though?

[1] https://www.anthropic.com/_next/image?url=https%3A%2F%2Fwww-...

Very impressive! But under arguably the most important benchmark -- SWE-bench verified for real-world coding tasks -- Claude 3.7 still remains the champion.[1]

Incredible how resilient Claude models have been for best-in-coding class.

[1] But by only about 1%, and inclusive of Claude's "custom scaffold" augmentation (which in practice I assume almost no one uses?). The new OpenAI models might still be effectively best in class now (or likely beating Claude with similar augmentation?).

SimulaVR[1][2] is releasing our standalone (belt-strappable) compute packs this year, which will (ii) come pre-installed with our FOSS Linux VR Desktop compositor and (ii) work with AR headsets like the Rokid Max series (and potentially the XReal headsets). So basically: you'll get full Linux Desktop apps in AR (not just Android ones) with actual VR window management (not just "dumb monitor mode").

[1] I know we're taking forever D: But we intend for this to be a way to release an intermediate product (which we've been making anyway for our full headsets).

[2] Our next blog update will be about this. Here's a video video preview: https://youtube.com/shorts/Y67D8DkqScU?si=LpdSpjmfGn2k2rxP

Still waiting for rr to work more transparently/easily with Haskell.

This is such an insightful comment. Now that I see it, I can't see unsee it.

Makes sense. Thanks for the correction.

Did anyone else notice that o3-mini's SWE bench dropped from 61% in the leaked System Card earlier today to 49.3% in this blog post, which puts o3-mini back in line with Claude on real-world coding tasks?

Am I missing something?

=======Technical Summary========

Here's a problem with NixOS:

1. Suppose we have a `./nixos_binary_program_with_glibc-newer` compiled on a NixOS machine against bleeding edge `glibc-newer`.

2. `./nixos_binary_program_with_glibc-newer` will have `/nix/store/glibc-newer/linux-ld.so` path hardcoded into its ELF header which will be used when the program launches to find all of the program's shared libraries, and so forth. (And this is a fact that `ldd` will obfuscate!).

3. When `./nixos_binary_program_with_glibc-newer` is distributed to machines which use `glibc-older` instead of `glibc-newer`, the hardcoded `linux-ld.so` from (2) will fail to be found, leading to a launch error.

4. (3) will also happen on machines which don't use nix in the first place.

=======Will's Solution========

1. Use `patchelf` to hardcode a standard FHS `ld-linux.so` location into `nixos_binary_program_with_glibc-newer`'s ELF header (using e.g. `/lib64/ld-linux-x86-64.so.2` as the path)

2. Use a metaloader to launch `nixos_binary_program_with_glibc-newer` with an augmented `RPATH` which has a bunch of different `/nix/store/glibc-newer` paths, so that nix machines can find a suitable `ld-linux.so` to launch the program with.

This will make `nixos_binary_program_with_glibc-newer` work on any machine, including both non-nix machines and nix machines (which might be running older versions of glibc by default)!

That's because it is!

This was an interesting post. It's a shame it somehow lost its front-page status.

Do you have any sense as to whether Tengwar is any more or less compact/concise than Shavian?

I live near Texas. I just filled my car's entire tank of gas (1990 Miata) for ~$22.

How are gas prices in Europe these days?

This is a good way to put it.

I suspect the reason might be related to Apple not wanting to cannibalize their MacBook revenue (which historically is almost always higher than their iPad revenue).

So they've opted to create an iPad replacement instead of a laptop replacement, which is still a step up (and very cool), but not ultimately what consumers can get the most utility out of, from our point of view.

Understood. We opted to make tradeoffs that optimize for VR pixel density over headset lightness (since we think pixel density/text readability is ultimately a bigger barrier for long sessions than weight).

With that said, our compute pack itself is detachable, so it can be offloaded from the head.