Notices by Kornel (kornel@mastodon.social)

I'm not saying that would be a good thing, but the imbalance between the volume of code LLMs can generate vs code that people can maintain is so massive that I can't imagine things staying the way they are.

It makes better-than-LLM quality expensive and bottlenecked in comparison. This creates incentives to shift to quantity over quality, and to find ways to make do with buggy code.

LLMs can spit code-alike outputs 24/7, faster than humans can read it. This is a DoS attack on open source.

A maintainer can't trust that the person submitting a PR has properly reviewed the code, so they have to do all the review work anyway. There's zero benefit. If the maintainer wanted LLM-generated code, they could ask an LLM themselves, and skip the trust issues and slowness of dealing with a random middleman submitting it.

Something's gonna break.

#Code reviews seem to be the biggest bottleneck in software development right now.

Open source package ecosystems are victims of their own success. There's a long tail of iffy packages that nobody has reviewed, and nobody wants to.

For the top projects, maintenance is tough. Stakes are high. Reviews are hard. Contributions are meh quality (even before LLMs). It's not just code, but a people problem too. GitHub's primitive workflow wastes everyone's time.

Something's gonna break.

Our model of software is still like manufactured goods: there's one product released, and everyone gets an identical copy.

I think LLMs will turn software into #houseplants - every user will have a slightly different clone, grow it, kill it, start a new one.

Maintainers don't want LLM code. Too much to review, too little value, merge headache. For users incentive to submit is also low: very slow process, with low chance of success. But an LLM can keep reimplementing their pet feature.

Google lawyers navigating European anti-monopoly laws: oh noes, too complex! can't innovate! reset plz?

Google lawyers navigating European tax laws: Double Irish with Dutch Sandwitch.

@harrysintonen A platform that needs to run dev tools itself (rather than being a compilation target), but isn't supported by LLVM seems to be a niche of niches.

@chainq There's definitely a mismatch of values, and Rust is future-looking rather than backwards-looking.

Rust is 10 years past 1.0 release. The implementation is quite mature in what it targets.

Lack of obscure/legacy things is immaturity only if you assume having them is a goal, but Rust prioritized other things, like safe multithreading, early WASM support, modules, error handling, metaprogramming, UB prevention/detection. From Rust's perspective these are woefully immature hacks in C.

@AnachronistJohn it's cool that it's possible, and I don't have anything against it. But if I'm forced to choose between writing software that might run on SuperH (but probably won't due to speed & RAM requirements) vs being able to write more reliable software that runs better on still-manufactured CPUs, I choose the latter. I also gain access to thousands of new libraries, with better interfaces, and painless support for Windows. I can do more things in practice, and find them more valuable.

@gianni Great project! I hoped someone would implement this :)

A big quality limitation of WebP is forced chroma subsampling. Have you done something in this area specifically?
Have you controlled for subsampling and luma vs chroma bitrates in your benchmarks?

@soviut only ~half of TLDs tho. It rejects 773 valid TLDs.

As the owner of goof@img.horse, I'm outraged.

SIGBOIVK 2025 [PDF, p170]: https://sigbovik.org/2025/proceedings.pdf

`ccdoom` is a standards-compliant C23 C compiler that has "program-agnostic compilation model" and "advanced whole-program dead-code elimination" that always outputs doom.exe.

> ccdoom adopts a more user-centric approach to safety: the output contains significantly more monsters than the output of most C compilers, but the user is provided sufficient ammunition to defeat them.

@amszmidt Really? I did not expect them to do worse than C64.

Anyway, my point was that CPU clock speeds used to be close to DRAM speeds. Until mid 80s CPUs didn't even need to have caches.

@artemissian LISP is pointer-heavy. When LISP and LISP machines were hot, RAM access took exactly 1 CPU cycle. Now it takes ~300 cycles. Maybe some purely-functional flavor could be made to work, but that's beyond my imagination.

The current state favors data-centric embarrassingly parallel programs with minimal pointer indirections.

What if C isn't portable, only non-C-compatible architectures went extinct?

I'm half joking, but:

VLIW/EPIC architectures are dead, despite CPUs desperately needing instruction-level parallelism.
Instead of SIMT we have hyperthreading at home, and bug-prone threads with context switching in software.
Instead of hierarchical memory, we waste 8 bytes on all pointers & emulate thread-local memory in software. Larabee was DOA & SIMD barely exists. MOS6502-style stack+registers are only on GPUs.

In 2003, Apple released a 64-bit dual-core 1.8Ghz system: Power Mac G5.

In 2023, Apple released a 64-bit dual-core 1.8Ghz system: Apple Watch Series 9.

The Watch is faster and has more RAM.

The G5 was too hot to put in a laptop. It'd use up S9's battery in under 2 minutes.

@mattly @stonebear I'm just talking about 2FA. It's perfectly reasonable to require 2FA on all accounts. It's safer to err on the side of requiring unimportant accounts to have 2FA, than risking an important user to have an account compromised.

That is entirely orthogonal to the funding structure. The risk and responsibility exists due to code sharing and trust structures, regardless whether people are paid for it or not.

On Star Trek they'd require you to have 2FA too.

@stonebear @mattly To me account security in shared environments is like hygiene. When one person's security stinks, it affects others. To me the real rudeness is in doubling down on bad hygiene when told that your security stinks.

Supply chain security in OSS is already a hot mess, and doesn't need even more worrying about impersonation just because someone *wants* to have poorer security to show a computer who's the boss.

@mattly I know the point – you don't think your account is important & don't want an automated check to tell you what to do.
I just think you're a crybaby about it.

GitHub accounts are used for lots of things, also outside of GH (oauth). GH has no way of knowing how much damage takeover of your account could do (including social engineering if you're a trusted person).

It makes sense for the entire OSS ecosystem for GH to be 2FA-only. It's already a house of cards and doesn't need weak links.

@mattly Get a Yubikey (U2F/Webauthn). It's super convenient to use: makes 2FA a quick tap. It's worth getting one anyway for all your accounts, as it's automatically phishing-proof. Instead of being contrarian you can solve the problem well.

For a programming language that is definitely not a religion, this looks suspiciously like a church:

#rustconf #rustlang