georgewsinger

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.

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.

We wrote about our thoughts on Apple's planned VR offering.[1] Their headset looks really cool & polished, but we think people like your friend might not find it as productive as they'd wish since it only supports iOS (iPad/iPhone) applications natively.

[1] https://news.ycombinator.com/item?id=36326677

It's unfortunately an expensive device, but we like to argue that "first in kind" devices are often very expensive[1] before economies of scale and other efficiencies can drive them down. The Apple Vision Pro is set to retail for $3,500 (vs. our base unit at $2,700 right now).

[1] https://simulavr.com/blog/paying-for-productivity/

Technically it's two monitors on your face: one for each eye :)

Nope, you've got it right. We're selling at a loss up until roughly the ~1,000th unit shipped.

More specifically: if we ship 125 units, we lose roughly ~$5K per headset. If we ship 250 units, we lose roughly ~$2K per headset. If we ship 1,250 units, we're operating at a slight profit with a couple of years of runway. If we ship 10,000 units, our margins approach 45% (at least on our pure hardware offering; we'd like to layer in some software offerings as well).

Unfortunately, the most costly part of the project is the very beginning. But we think these sales targets are doable if we're able to get our operation off the ground (with customers able to see shipped units being used to replace laptops in the wild).

Vitalik and Thor were both early preorderers of our headset (we had no connection to them prior). And we didn't have any explicit crypto angle here, but just reached out to them as vetted early enthusiasts, asking if they wanted to help test the headset as users. In a way, there's something pure about getting feedback from people who are interested in the product primarily as users (as opposed to them already being in the industry).

But we actually do have a discussion ongoing with ThrillSeeker about a headset test/video, and we hope it gets made :]

Appreciate your support. From our perspective, the Apple headset is more an "iPad replacement" than a "laptop replacement".[1]

The Vision Pro is based on their iOS (iPad/iPhone) ecosystem for their 2D apps, so you won't be able to use powerhouse office apps. It seems instead more geared towards the passive consumption of information, entertainment, and casual gaming, whereas we're trying to build something that can realistically replace a (Linux) laptop.

I'm not sure what Apple is thinking strategically, but they're structurally incentivized to cannibalize their iPad sales over their macbook sales (since their iPads are their weakest product in their lineup in terms of sales).

[1] https://news.ycombinator.com/item?id=36326677