codeflo

> our ancestors insisting on eating toxic things like mushrooms and spoiled food

Presumably this didn't happen because are ancestors were dumb, but rather because the ability to process slightly spoiled food is a significant advantage in an environment where fresh food is sometimes scarce?

It's still a wild logical leap to me that we went from this observation, that maybe the bottom half of users never learn how the software works, to the idea that we should build software that is actively learning-hostile. In the old era, we established consistent UI patterns: this kind of button does X, this kind of button behaves like Y, here are the tools to solve your problem. Maybe not everyone learned the patterns, but those that did became wildly productive. Now: who cares if buttons are recognizable as such, your bottom half of users tap all over the place anyway, so design for them exclusively. It's good to enable more people, but we also lost something in the process.

They say it's a modified version Source Sans, but then don't compare it with Source Sans to show the differences. The only comparison is with their previous, unrelated font (Whitney SSm). Why?

> unaware of the bun AI-rewrite-to-rust saga

I seem to be mostly unaware, at least, it's not self-explanatory to me why a Rust rewrite would be that baffling. What's the verdict on the Bun rewrite, and how does that relate to pnpm's decision? Also, wasn't Bun switching from Zig to Rust instead of from TypeScript to Rust like pnpm? I get the impression that many web infrastructure projects have been switching to more native languages.

Thousands of words that boil down to "intmax_t isn't ABI-stable". Who knew? (Everybody.)

I think in the background of article's premises is an argument about classical vs. intuitionistic logic, rather than only about the merits of putting stuff in the kernel vs. outside.

Isabelle seems to use classical logic and set theory. Classical logic is often simpler, but when you do the "hard toil" (as the article puts it) of building recursive functions on set theory, all you've really done is to nonconstructively prove the existence of a set of pairs with certain properties. Good luck evaluating such an abstract "existence" with any concrete argument. Whereas intuitionistic logic as used by Coq is more complicated, but that's in part because its notion of "function" is an actual procedure in your computer that can accept an argument and produce a result.

At least that's to the best of my understanding; it's been a while since I have looked at any of this, so feel free to make corrections.

A light switch not working for 30 seconds, or a door not opening for 30 seconds, even if only sporadically, is a significant loss of life quality, no qualifiers needed.

There's a widespread misconception (not shared by the article author) that floating point arithmetic is "imprecise" in the sense that the result is off by some amount of random noise. On the contrary, IEEE floating point results are precisely specified to produce the closest representable value to the mathematically exact result.

For efficiency reasons, library functions (and sometimes, sadly, hardware implementations) don't always guarantee this (closest representable) exact result. That's fine if the function is then called "approximate_inverse_square_root" or something. Sometimes being off by some epsilon is a good tradeoff for 10x efficiency. I'm unhappy when such a tradeoff is smuggled into my math library without warning.

I checked Rust's source code to confirm the article's claim that it doesn't have a precise log function, and indeed, here's the implementation:

    pub fn log(self, base: f64) -> f64 {
        self.ln() / base.ln()
    }

I'm sure other math libraries aren't better. But this is not a correct implementation of arbitrary-base logarithm. A function like that perhaps shouldn't even be offered in the standard library at all (since it's so trivial to begin with), or at the very least, not with that name. If a programmer wants to opt-in to a fast but slightly wrong value, they should do so explicitly, in my opinion.

It can be useful for pure translation tasks and stuff like that where you explicitly don't want creativity of any kind.

Regardless of what? Programming is solved, I hear, with all the 100x productivity PhD-level automated coding loops they have going. Don't make excuses for them when they disprove their own bullshit.

> These theories are flawed in the sense that they cannot account for subjective experience and agency, amongst other things.

On the contrary, it's precisely this assumption, that there is a "subjective experience" that requires explanation beyond the material, that is axiomatically assumed without evidence. It falls apart quickly, any "subjective experience" is completely tied to neurons, knock out the neurons and the subjective experience disappears, or stimulate the neurons to cause the experience.

It's clear that YouTube doesn't want you to have much influence over your feed. You can't even ban specific channels from being shown to you, which would be the simplest thing to implement, and other knobs that previously existed were silently removed.

Since Google does nothing that isn't based on metrics, we can deduce that they have data to show that giving people settings to focus the recommendations on what they want reduces total watch time. We'll only get an AI filter if it turns out that AI slop offends people so much that they disengage with YouTube altogether, which outside of HN and similar bubbles, I don't yet see happening.

> If AI music allows someone with less formal musical skills to feel like they are joining in and making something, then maybe it has its value.

An emphatic no. What we need to do is to stop comparing every hobby performance, whether it's music or dancing, with the top 10 artists in their field. We need people to learn, and try, and feel safe to be visible and thus vulnerable in group situations without fear of being mocked on social media for eternity. To achieve this, we need to stop filming people, and we need a societal norm that treats a violation of this ban on par with spitting someone in the face. We need to celebrate amateurs that simply try to improve their raw, honest skills.

What we don't need to do is to give everybody a Fisher Price toy with a "make it sound awesome" button. We need human connections.

It seems like I simply misunderstood the point of the "game of telephone" metaphor. To be honest, even with your added explanation, I don't fully get why you express it that way. But I think we're in agreement on the substance, and I shouldn't have worded my response so harshly.

> You can't load an integer from an unaligned address.

You can, and the results are machine specific, clearly defined and well-documented. Ancient ARM raises an exception, modern ARM and x86 can do it with a performance penalty. It's only the C or C++ layer that is allowed to translate the code into arbitrary garbage, not the CPU.

> The compiler, and really the underlying hardware too, is playing a game of telephone with your UB intentions.

The part about hardware is wrong BTW. In all the cases about null pointers and out-of-bounds access and integer overflow and whatnot, the hardware semantics are clearly defined, and the assembler code does exactly what is written. The way modern compilers act on your code makes C less safe than assembler in that sense.

I don't get that impression at all. LLMs would have avoided the stylistic repetition of "live". Asking an LLM to reformulate the sentences you quoted yields this slop:

> There are a lot of people who go through life by vibing. And honestly: that’s not automatically “bad.” Sometimes it’s even the only workable way to get through things. The issue is that “vibe-first” people tend to have a pretty loose relationship with truth, rigor, and being pinned down by specifics. They’ll confidently move forward on what sounds right instead of what they can verify.

I'll finish this post with a sentence containing an em-dash -- just to confuse people -- and by remarking on how sad I find it that people latch onto dashes and complete sentences as the signifiers of LLM use, instead of the inconsistent logic and general sloppiness that's the actual problem.

Last I checked, one kidney might not even suffice to pay for 256GB anymore.

I don't disagree with that, but that's not what was discussed. The person I was replying to was asserting that the Soviet union couldn't have developed semiconductors because unlike the US, it didn't have "a vast civilian customer base that let it recoup R&D expenses". My argument is that "recouping" anything doesn't matter in a planned economy.

Of course in any economy, there are scarce resources, and skilled labor is certainly one of them. What I'm specifically arguing against is the assertion that in a planned economy, the existence or lack of a customer base would in any real way impact the allocation of those resources. That's not a helpful way to analyze the decisions of the communist planning committee.

Cost can't be the true reason. In a planned economy, the customer base doesn't matter. If the state wants to allocate X number of engineers to do Y, it simply does, at the expense of whatever other project is considered politically less important.

The fact that the customers' demands have no influence on resource allocation, except to the extent that bureaucrats decide it's politically convenient to address them, is in fact precisely why life under communism is so shitty.

Nothing recent made me feel quite as old and out of the loop more as the slowness with which I realized that this is about x.com (Twitter), not x.org (the windowing system).

> My solution was to kexec into a new kernel+initramfs which has a DHCP client and cURL in it - that effectively stops any filesystem access while the image is being written over the disk, then to just reboot.

That's what I was expecting from the article.

Update: It's not obvious, but it turns out that this is a multipart article, and kexec is reserved for part 3: https://astrid.tech/2026/03/24/2/how-to-pass-secrets-between...

I know the argument I'm going to make is not original, but with every passing week, it's becoming more obvious that if the productivity claims were even half true, those "1000x" LLM shamans would have toppled the economy by now. Were are the slop-coded billion dollar IPOs? We should have one every other week.

> Also, lines of code is not completely meaningless metric.

Comparing lines of code can be meaningful, mostly if you can keep a lot of other things constant, like coding style, developer experience, domain, tech stack. There are many style differences between LLM and human generated code, so that I expect 1000 lines of LLM code do a lot less than 1000 lines of human code, even in the exact same codebase.

>> the architect → developer → reviewer pipeline actually produces better results than just... talking to one strong model in one session?

> There's a 63 page paper with mathematical proof if you really into this.

> https://arxiv.org/html/2601.03220v1

I'm confused. The linked paper is not primarily a mathematics paper, and to the extent that it is, proves nothing remotely like the question that was asked.

> Or am I reduced to buying an Apple TV device and unplugging the TV from the internet entirely ?

At least until TV makers wise up to that strategy and build a TV that requires internet access to unlock the HDMI port, that's the way to go.

It's likely that "knows" has no separate definition, but is used in some definition of "operator". If so, then "operator" should probably connect to "know", and "knows" shouldn't appear in the graph at all. But calling that edge case "broken" is a bit harsh, I think.

All of the examples on the linked page seem to be "good" outputs. Attribution sounds most useful to me in cases where an LLM produces the typical kind of garbage response: wrong information in the training data, hallucinations, sycophancy, over-eagerly pattern matching to unasked but similar, well-known questions. Can you give an example of a bad output, and show what the attribution tells us?

Then what precisely is the definition of complex? If "complex" just means "not designed", then the original quote that complex systems can't be designed is true but circular.

If the definition of "complex" is instead something more like "a system of services that interact", "prone to multiple, coincidental failures", then I don't think it's impossible to design them. It's just very hard. Manufacturing lines would be examples, they are certainly designed.