I write at https://entropicthoughts.com
My inbox is hn[at]xkqr.org
- No, an entry is a key-and-value pair. Are you deriously suggesting it is possible to add only keys without corresponding values, or vice versa?
- In contrast to many others, I did not find this particularly interesting.
- The comic on is oddly cropped and contains speech attribution errors.
- It calls me an "extremist" regarding the wrong thing (I am many kinds of extremist, but certainly not Haskell).
- It claims I believe "any software failure is merely a design error" which is a complete misunderstanding of the ideas I presented.
- It says things like "the geometric mean of the snack bowl" which doesn't have meaning in English.
I feel like it has picked up on certain keywords and then just rolled with its own stereotypes of what those keywords represent, rather than actually taking a good look at what I think. A roast works because the roaster has clearly spent time and effort and care understanding the person roasted. This is way too shallow for that.
The 2026 and 2035 predictions (with a few exceptions) don't make sense at all, and the jokes in them fall completely flat. They're not good anti-jokes either. If someone said something like it in a social situation it would be followed by an awkward silence.
The vibe check and the time spent were really cool though. Super interesting. I would have loved to see those expanded.
I don't mean to be negative. The project is cool. I just wish it would put its focus on the valuable parts, rather than the things it is weak at. I guess this is my 45 % pedantic, 25 % contrarian, 20 % analytical self speaking.
- The hard drives are either master or slave. A hard drive is not a master-and-slave.
- All of your slash examples represent either–or situations. A swich turns it on or off, the situation is a win in the first outcome or a win in the second outcome, etc.
It's true that key–value store shouldn't be written with a hyphen. It should be written with an en dash, which is used "to contrast values or illustrate a relationship between two things [... e.g.] Mother–daughter relationship"
https://en.wikipedia.org/wiki/Dash#En_dash
I just didn't want to bother with typography at that level of pedanticism.
- I have a draft doing this with text adventures: https://entropicthoughts.com/updated-llm-benchmark
- Yes, but recognising that is only the first step. Quantifying the variance is the next step which I miss in the article.
- It would unfortunately also need several runs of each to be reliable. There's nothing in TFA to indicate the results shown aren't to a large degree affected by random chance!
(I do think from personal benchmarks that Gemini 3 is better for the reasons stated by the author, but a single run from each is not strong evidence.)
- > Generally referred to
Sure, people may sloppily call it a failure, but then they miss out on a useful distinction which would help them create more robust software.
A bolt being under-engineered for its intended usage is a design error. When it breaks, that's a predictable (but unfortunate) mode of operation of the design, not a failure. (It has inadvertently been designed to act as a frangible link.)
The reason it's important to distinguish between the two cases is that we use different methods to deal with them.
- In this case I'm asking specifically about the C200 this article is about. Sorry for not being more clear. From what I understand the C200 does not boot from SD card.
- It's not a store of "keys or values", no. It's a store of key-value pairs.
- I'd love to but... how? One alternative seems to be a programmer chip that must be puchased and then modified to not fry the camera with 5V. Another is maybe stripping a USB cable and soldering it to the wifi pads on the camera chip?
Neither of these seem like good ideas for someone like me, who is relatively hardware naïve and has small children running around making it hard to concetrate for more than 30 minutes at a time.
The question is genuine. I want to do this but don't actually know by which method.
- But then how does one distinguish between letters? Something like "ETA" would be difficult to tell apart from "II".
- It's still a thing and they even have world championships in it. Everyone always draws because it's basically just Stockfish vs. Stockfish. (Okay in the most recent one there were actually a shared first place, a shared second place, and one person in third place. The latter died during the tournament, and whether the others ended up in first or second place depended on whether they had drawn with third place before he died or if they won on time.)
- Did they somehow find a way to make a long tap (e.g. slide something against the radiator for a continuous signal) or did they agree on two different kinds of short taps? (Or do the pipes resonate for long but can be dampened by hand to produce a short tap?)
- Agreed, which is why what GP suggests is much more sensible: it's venturing into known territory, except only one party of the conversation knows it, and the other literally cannot know it. It would be a fantastic way to earn fast intuition for what LLMs are capable of and not.
- > They used the same routines they wrote for their day jobs at Softdisk in the Keen code. [...] Most of the IDLIB.C code must have come directly from the PC version of Dangerous Dave. [...] there is some extremely strong evidence showing that the id founders used Softdisk's code in their own game. Sure, it's not the code responsible for the smooth scrolling, but it is code they probably didn't have the rights to use.
Huh, this is interesting. Is someone able to provide more detail?
The pace at which Id produced games has always been an inspiration for me. Large amounts of code reuse seems like an important clue as to how they were able to do that.[1] But how were they able to reuse code effectively to such a degree?
[1]: The other clues I have so far are Romero's legendary tool-making abilities, and Carmack's tendency to produce code that gets computers to do things they couldn't before.
- The problem of focusing on failures is that such analysis misses all the losses that occur even when everything works as designed. Analysis has to focus on all losses -- both failures (often the trivial case) and non-failures (design errors, often trickier to find.)
- It sounds like our main disagreement lies around whether to call it "design error" or "build error" but I do not believe this erases the useful distinction between "error present in the thing from day one" and "unpredictable failure of component suddenly no longer doing what it used to do".
- The first three are hardware failures, not software failures. The latter would be a design error, not a failure.
The software may need to handle hardware failures, but software that doesn't do that also doesn't fail -- it's inadequately designed.
Separating them does also create some incidental complexity (permutations of configurations, feature flag management) but in my experience that complexity is easier to analyse and deal with. (Dealing with feature flag complexity involves retiring them promptly, differentiating between feature flags and kill switches, etc.)
Of course, TFA knows this. They've moved the goalposts by making an extreme claim ("every" change behind a flag) and then argued against it.