Boosted by @trending@homestead.social
It looks like Omarchy is as much about Linux as GamerGate was about journalism.
Remote
Kornel
@kornel@mastodon.social
mastodon 4.8.0-nightly.2026-10-06I compress pixels (https://ImageOptim.com https://pngquant.org https://gif.ski).
Web Standards & #RustLang
3845 Followers
1128 Following
27 Posts
Joined November 01, 2016
my homepage last updated in 2003:
tootfinder:
searchable
USA revolving around several trillion-dollar companies, and EU having hardly any, is supposed to imply economic superiority, but to me it sounds "if you're so good at growing, why don't you have more tumours?"
Boosted by @ferrix@mastodon.online
Replying to
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.
#Rust being a modern language is not enough, you need postmodern: https://lib.rs/crates/slopc
Autocorrect changed "abstraction layer" to "obstruction layer". It has a point. I need to start using this term.
Replying to
Maybe High-Fructose Corn Syrup would be a good analogy for #LLM code? It's a crap nobody would want, except that abundance of subsidized corn creates an incentive to stuff it into everything.
Replying to
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.
Replying to
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.
I'm switching from #macOS to Linux. So far keyboard shortcuts are the hardest obstacle. Muscle memory refuses to change, so I work like I've seen a keyboard for the first time yesterday.
Lack of separate Ctrl & Cmd seems like a deeper problem than just doing things differently. It halves available keyboard combos. It turns out I've been using lots more than just Cmd+C vs Ctrl+C.
Replying to
@pid_eins Rust's std::fs and std::io were an MVP for the 1.0 release, and unfortunately mostly stayed like that.
Back then Rust still had to prove that the memory safety and data-race guarantees could even work, that it could be stable and backwards-compatible language, while having even bigger unfinished gaps in the language and libstd.
Now std::fs sticks out as the weak point, but Rust couldn't take moonshots in every aspect all at once. It would never ship.
Boosted by @GroupNebula563@mastodon.social
The Bun's #Zig to #Rust rewrite is an advertisement for Anthropic, at the cost of hurting both languages.
It already made a stink for Zig. Now, when this mountain of unstable, auto-converted LGTM'd code is going to have embarrassing bugs, it's going to make a stink for Rust: "see, Rust adoption was pointless, it's still buggy!"
Replying to
@Ambraven@social.mochi.academy if … { f } else { &A::new() } used to be impossible, but recent Rust versions actually allow that.
It automagically makes a variable in the outer scope of the if. It's supported only in certain syntactically-simple cases.
Replying to
Visual Basic's On Error Resume Next can be galaxy-brained to On Error LLM("rewrite the program to stop doing that")
Replying to
@blp inherent methods on some `Type` may not be using the `T` specifically (e.g. `Vec::len`), and self.foo() and foo(self) are equivalent-ish in Rust, so a function with unused generics must exist as a thing.
tbh, unused T on a standalone function is as rare and suspicious as in a struct, so the inconsistency in enforcement could be just a historical accident.
Replying to
Copyright has always been a tricky balance. Trying to distinguish between inspiration and a ripoff. Let authors make a living, but not put the entire shared culture behind a paywall. Allow education, parody, commentary without creating loopholes for freeloaders (with lots of grey areas, flaws, gaps, and abuses in practice).
If copyright didn't exist, we'd have even more paranoid DRM used to defend commercial interests. If copyright was harsher, we'd get more walled gardens and DMCA-silencing.
Replying to
@drdrang but if I debug my HomeKit daily, I won't have to adjust the timer twice a year.
Replying to
@weiznich Unfortunately the Path API has a no-alloc conversion from &str, so there's no room for a new field. Adding fd there would require stuffing it into the path, which seems hacky and could backfire.
The Path isn't good anyway. Can't even store \0 for C APIs nor UCS-2 for Windows. Useless for browser FileSystem APIs (WASM).
Replying to
@happyborg@fosstodon.org It's not entirely the same problem as earlier attempts at making natural-language compilers.
The "large" part of LLM gives it more context and a bit of "common sense". It's still a guess, but drawn from a more likely distribution.
The learned context is so strong they can sometimes surprise Babbage and give right answers to wrong questions.
Yeah, they routinely fail at software engineering we have today, but I wonder how much the world will adapt to "cheap but inaccurate" code.
Replying to
@pointlessone@status.pointless.one that's true. I'm speculating that high-enough quality may be way more difficult to achieve than scaling meh-quality to high volume, and people will adapt and run with whatever is more available. Vibe coding tools may be designed to generate hundreds or thousands versions of a program to brute-force solutions.
Dunno what it means for really big and complex projects. They'll stay as-is? Get sidelined by a flood of smaller buggier ones?
@deshipu@fosstodon.org That's the core of the problem: the existing law doesn't clearly codify the difference between GenAI (ab)uses and benign uses of ML.
Setting a precedent that models are infringing derived work could be abused, e.g. spammers could make a case that antispam filters are illegal, because model weights were derived from their precious copyrighted spam emails. These obviously aren't the same thing, but the laws we have predate GenAI and weren't written to make it legally clearly different.
Replying to
@marshray@infosec.exchange I've had Caps Lock = Control on Mac. It's easy to set it to Control on Linux too, but then what do I do about the physical control key? I'd have to remap every shortcut in every app?
Replying to
@iainvdw@mastodon.social Yeah, no idea. I guess the real source will move to a higher level, like a human-language requirements spec. I wouldn't be surprised if coding-oriented design specs were also auto-generated from even higher-level spec/prompt.
What's striking to me is that GitHub stops making sense in such world. It'll be easier than ever to fork and modify projects and even merge different forks, but also futile to do it on a shared codebase. It's disposable single-use code.
Replying to
@iainvdw@mastodon.social @happyborg@fosstodon.org Currently we think before writing code, because writing it and changing it takes effort (and even for LLM-generated slop code it takes time, and burns money and rainforests, so it's better to get the spec right first)
But the thing I've been wondering about is that if generation speed improves significantly, it will change the problem from "should we write it like this?" to "I've written it. Is this what you wanted? How about this? Or that? Here's 10 more with benchmarks"