Conversation

Notices

1. Embed this notice
   Phantasm (phnt@fluffytail.org)'s status on Tuesday, 13-Oct-2026 09:22:31 JST Phantasm
   I will forever use the pre-slop version of <insert important and large project> is one of the most hypocritical copes ever. Not only will a fraction of the actual people saying that even attempt to do it, but they will inevitably reach the junction of "Do I run an outdated piece of software with a large vulnerability/vulnerabilities, or do I maintain my own patches." At which point the two answers are no and no, so back to running the "slop version" it is.
   
   Have fun applying over a year of security fixes to Linux and core libraries btw. No, even BSDs aren't safe either. :) NetBSD allows LLMs as long as the patch is approved by a core maintainer, OpenBSD already has Claude commits in it via tmux and FreeBSD has an "I don't care" stance.
   • Embed this notice
     pistolero (p@fsebugoutzone.org)'s status on Tuesday, 13-Oct-2026 09:22:30 JST pistolero

     in reply to
     @phnt
     
     > "Do I run an outdated piece of software with a large vulnerability/vulnerabilities, or do I maintain my own patches." At which point the two answers are no and no
     
     :terrylol2: Ahem.
   • Embed this notice
     pistolero (p@fsebugoutzone.org)'s status on Tuesday, 13-Oct-2026 09:24:31 JST pistolero

     in reply to

     • pistolero
     @phnt Slightly less shitposty answer: what if people used systems that weren't bloated monstrosities?
     
     :tonyhoare:
     > This happened just one week after our inquest on the 503 Mark II software project. I gave desperate warnings against the obscurity, the complexity, and overambition of the new design, but my warnings went unheeded. I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.
     > The first method is far more difficult. It demands the same skill, devotion, insight, and even inspiration as the discovery of the simple physical laws which underlie the complex phenomena of nature. It also requires a willingness to accept objectives which are limited by physical, logical, and technological constraints, and to accept a compromise when conflicting objectives cannot be met. No committee will ever do this until it is too late.
     1980--tony_hoare.pdf
   • Embed this notice
     pistolero (p@fsebugoutzone.org)'s status on Tuesday, 13-Oct-2026 09:40:25 JST pistolero

     in reply to

     • pistolero
     @phnt Fuck a damn it, wrong file. That is an interview from 2015. Here, here is the speech from 1980.
     1980--tony_hoare.pdf
   • Embed this notice
     pistolero (p@fsebugoutzone.org)'s status on Tuesday, 13-Oct-2026 09:50:43 JST pistolero

     in reply to
     @phnt
     
     > Bloat reduces the exposure area, yes. But it doesn't eliminate it.
     
     Your floor for what qualifies as bloat must be higher than my ceiling for what qualifies as bloat.
     
     > what you will end up with is something slow people don't want to use.
     
     Sorry, you tryna get funded? You moving from fedi to Twitter? I'm going to assume no, in which case, fuck popularity as a benchmark for anything, it's a terrible reason for anything. How many people do you fucking *need*? Enough to keep your shit running: maintainer cost is proportional to complexity, complexity is superlinear with respect to size.
   • Embed this notice
     Phantasm (phnt@fluffytail.org)'s status on Tuesday, 13-Oct-2026 09:50:44 JST Phantasm

     in reply to

     • pistolero
     @p
     >what if people used systems that weren't bloated monstrosities?
     
     Eliminating bloat reduces the exposure area, yes. But it doesn't eliminate it. At the same time, try making a race-free filesystem API without reinventing it as a DBMS with per-fd views. Even an API that does stat/open/close/read/write and only that has inevitable races and fixing them requires complex monstrosities that guarantee atomicity.
     
     Similarly, you can remove a lot of "bloat" by removing racy async IO in the kernel and do it synchronously, but what you will end up with is something slow people don't want to use.
   • Embed this notice
     pistolero (p@fsebugoutzone.org)'s status on Tuesday, 13-Oct-2026 10:02:57 JST pistolero

     in reply to

     • pistolero
     @phnt (I do get that the "If ChatGPT wins the election, I'm moving to Canada" people are not going to follow through, but I think your "It's never going to happen, no one even *can* do that" is basically as wrong and misguided and demonstrably so.)
   • Embed this notice
     pistolero (p@fsebugoutzone.org)'s status on Tuesday, 13-Oct-2026 10:35:56 JST pistolero

     in reply to
     @phnt
     
     > Popularity is not what I'm taking about. It's usability.
     
     "No one will use it" is popularity. "It will be slower" is a trade-off.
     
     > In my synchronous IO example
     
     I didn't like the example but preferred to address the substance than pick at the example.
     
     > If Linux had that, its server market share would be way lower than what it is now.
     
     This is a popularity thing again.
     
     > You can have simple systems, but simple does not always mean fast enough
     
     Sometimes it means "faster". It's a matter of degree, though: you sit down at a machine and we've written most of the system software in C because it's easier to write a correct C program than the equivalent in assembly, we've separated processes into their own memory space despite this being slower and involving more copies between regions of memory, switching between kernel- and user-space, and then you're talking about virtio, so you're putting things into VMs, and why? Correctness and security and simplicity can be bought by trading speed; sometimes you need the speed and there are lots of ways to buy it back. You gonna disable KASLR? You probably ought to on a server (depending), you probably shouldn't if you're running a browser.
     
     Here we are on the web, in fact, a massive distributed namespace with all of these semantics that cost us speed. We're using JSON typically: a plain-text file format. You're trading speed over and over and over again.
     
     > 9front is small, simple and without bloat. Is it fast? Not really
     
     It is pretty small and simple; it's also pretty fast because there's no horseshit in the way. But speed depends on use: a 747's much slower than an F-35 and a car's much slower than a 747 and a tank is much slower than a car.
     
     At any rate, are you attempting to talk about what you use as your development environment or deployment target or what? I'm talking about what I use, and what I use doesn't typically need to saturate a 40Gbit link of any sort.
     
     > not serving thousands of requests per second
     
     I think FSE's the only instance that has, without resorting to nginx caching, managed to sustain enough traffic on /objects/ to saturate the gigabit pipe and it's a thing I built in my spare time. Do not tut-tut me about scaling, dude, that shit is my day job.
   • Embed this notice
     Phantasm (phnt@fluffytail.org)'s status on Tuesday, 13-Oct-2026 10:35:57 JST Phantasm

     in reply to

     • pistolero
     @p
     >fuck popularity as a benchmark for anything, it's a terrible reason for anything.
     
     Popularity is not what I'm taking about. It's usability. In my synchronous IO example in order to remove complexity, you get a system that is now unusably slow when you do real work with it. An example of that are the giant kernel locks still present in NetBSD and OpenBSD, making it hard to push maybe more than 25 Gbit out of very capable systems. If Linux had that, its server market share would be way lower than what it is now. I couldn't push more than 40Gbit on OpenBSD with virtio drivers which have barely any overhead on 8 cores for example.
     
     You can have simple systems, but simple does not always mean fast enough and sometimes you need a lot of complexity to make something fast or reliable. 9front is small, simple and without bloat. Is it fast? Not really, but its goal is running a small grid and desktop/development use, not serving thousands of requests per second so it does not matter.
   • Embed this notice
     pistolero (p@fsebugoutzone.org)'s status on Tuesday, 13-Oct-2026 11:04:30 JST pistolero

     in reply to
     @phnt
     
     > The amount of people that will do so will be so small that the number of them will be irrelevant.
     
     Most of the people that are moving to Canada have no follow-through, sure.
     
     > And the longer the "out of date" period is, the harder it will be to maintain the patch sets
     
     I think they call it a fork. But a big facet of security is killing things that you don't need. I'm still not certain whether you're talking about workstations or servers or what. FreeDOS started because there still existed DOS applications that people used, and there is still plenty of Linux 2.6 in the wild.
   • Embed this notice
     Phantasm (phnt@fluffytail.org)'s status on Tuesday, 13-Oct-2026 11:04:31 JST Phantasm

     in reply to

     • pistolero
     @p The amount of people that will do so will be so small that the number of them will be irrelevant. And the longer the "out of date" period is, the harder it will be to maintain the patch sets, provided that the upstream patches aren't "tainted" either, which would be debatable as well at that point.
   • Embed this notice
     pistolero (p@fsebugoutzone.org)'s status on Tuesday, 13-Oct-2026 11:06:04 JST pistolero

     in reply to

     • Pawslut420
     @sendpaws @phnt
     
     > obsessed over old software
     
     I thought we were talking about people backporting security fixes, not someone running old shit for no reason.
     
     > and he had to use phpBB
     
     You mean phpCVE?
     Nietzschean Ekko Enjoyer repeated this.
   • Embed this notice
     Pawslut420 (sendpaws@mitra.pawslut.party)'s status on Tuesday, 13-Oct-2026 11:06:05 JST Pawslut420

     in reply to

     • pistolero

     @phnt @p I'm just going to tell people that one story I tell all the damn time. I knew one of those guys, who obsessed over old software and he decided to run Invision Power Boards 1.3 Free for a forum (circa 2004-5ish) in 2009 give or take.

     His forum lasted days before it got utterly exploited and he had to use phpBB like a normal person.

   • Embed this notice
     pistolero (p@fsebugoutzone.org)'s status on Tuesday, 13-Oct-2026 12:13:16 JST pistolero

     in reply to

     • Pawslut420
     @sendpaws @phnt I've seen that exchange, yes.
   • Embed this notice
     Pawslut420 (sendpaws@mitra.pawslut.party)'s status on Tuesday, 13-Oct-2026 12:13:17 JST Pawslut420

     in reply to

     • pistolero

     @p @phnt >running old shit for no reason.
     That's why they have the "last untainted version" so you can free your system from the slop.

   • Embed this notice
     御園はくい (hakui@tuusin.misono-ya.info)'s status on Tuesday, 13-Oct-2026 12:14:05 JST 御園はくい

     in reply to

     • pistolero
     • Pawslut420
     @p @sendpaws @phnt >phpCVE
     you wrote cve twice
     pistolero likes this.
   • Embed this notice
     pistolero (p@fsebugoutzone.org)'s status on Tuesday, 13-Oct-2026 12:14:25 JST pistolero

     in reply to

     • 御園はくい
     • Pawslut420
     @hakui @phnt @sendpaws :brandt:
   • Embed this notice
     Phantasm (phnt@fluffytail.org)'s status on Wednesday, 14-Oct-2026 03:00:54 JST Phantasm

     in reply to

     • pistolero
     @p
     >> Popularity is not what I'm taking about. It's usability.
     >"No one will use it" is popularity.
     
     The two terms are entangled, you can't have a software be popular without it being usable (or having no other competition). By a substantial enough decrease in usability you lose popularity. "No one will use it" is not popularity in the way I meant it, it means as in "No one will use it, because it is unusable."
     
     And to remove ambiguity even more, "no one" is a hyperbole meaning negligible amount to the point of irrelevance. No one daily drives Windows 3.1 in $current_year is a valid statement, despite it being very likely false because at least 1 person on the whole planet probably still uses it every day. And if you think that is not valid, we are arguing whether "No one" or "99.9% of people using computers" is big enough difference to mean something in the statement.
     
     >> If Linux had that, its server market share would be way lower than what it is now.
     >This is a popularity thing again.
     
     Again, an unusable piece of software cannot be popular in a space with competition.
     
     >Sometimes it means "faster". It's a matter of degree, though: you sit down at a machine and we've written most of the system software in C because it's easier to write a correct C program than the equivalent in assembly [...]
     
     Yes, that is the point I was trying to make. That certain compromises have to be made, and at least in the context of OP (Linux) a lot of what can be called "bloat" are tradeoffs of complexity and security surface for making something fast. There's no denying some of it can be removed with little consequences, but a lot of the complex stuff cannot.
     
     Going back to the 9front example, those tradeoffs don't have to be made because it is a project that doesn't necessarily need them. 9front doesn't need shared kernel-userspace ring buffers for async IO (io_uring) to push tens and if not hundreds of gigabytes per second around. Does Linux need them? Debatable.
     pistolero likes this.
   • Embed this notice
     Phantasm (phnt@fluffytail.org)'s status on Wednesday, 14-Oct-2026 03:02:36 JST Phantasm

     in reply to

     • pistolero
     @p
     > I'm still not certain whether you're talking about workstations or servers or what.
     
     Neither. Hypocrisy and difficulties of maintaining patchsets for outdated and complicated pieces of software leading to giving up on doing so.
     pistolero likes this.
   • Embed this notice
     pistolero (p@fsebugoutzone.org)'s status on Wednesday, 14-Oct-2026 03:07:32 JST pistolero

     in reply to
     @phnt
     
     > The two terms are entangled, you can't have a software be popular without it being usable (or having no other competition). By a substantial enough decrease in usability you lose popularity.
     
     No, popularity depends on usability; they're not entangled. There are plenty of really usable things that no one uses. And an abstract general/universal "usability" is a concept designed for mass-market adoption. I say this, people act like it's crazy and don't factor it in, but I'm sure it's obvious: usability varies widely and usability for some groups is mutually exclusive and it even varies by application for a single person. awk is not very usable for a person that does not use the shell, but Excel is not very usable for a person that has a dozen machines with a 20GB TSV on each and they want an answer without copying 240GB across the network and then loading it into RAM. A hacker, a data analyst, a DBA, a bizops drone, a CFO, a small business owner, and a secretary all have very different concerns and they want something different from tabular data. That leads to the next point:
     
     > negligible amount to the point of irrelevance
     
     kdb has fewer users than IE6, but because they are writing the microsecond trading bots, if they write a bug that causes enough bad trades, the market crashes. Nuclear missiles have very, very few users: negligible to the point of irrelevance. Or not all users of a tool are exactly the same.
     
     User count in absolute numbers only means anything if you are pushing a mass-market utility so that your investors can maximize their exit. It does not mean anything here. If I write a script and it never leaves my box, it doesn't matter: the script still fucking works, its existence still makes a difference to me, and I can maintain it myself. There is really zero reason to keep treating user count as significant for anything other than VD.
     
     > we are arguing whether "No one" or "99.9% of people using computers" is big enough difference to mean something in the statement.
     
     No. I am not and have not argued that. We're at cross-purposes if you're reading that into what I'm saying. I am not being overly literal about your use of "no one": I am saying the numbers do not matter.
     
     Software at the threshold that you can maintain it yourself is qualitatively different, and that was entirely the point I was making. "Forget the number of users" turned into you trying to tell me about the number of users and then some point about usability that I think was incorrect, separate discussion: my entire point was that if you can maintain it yourself, you do not have to care, and this makes bloat a serious limiting factor. I'm not going to ever end up maintaining Linux myself; some group might fork it, but they'll have to make some cuts. Look at the people that keep doing "de-Googled" Chromium and "de-Googled" Android forks: without exception, they have had a bug that downloaded binaries from Google and executed them. Microsoft forked Go and got bit by that stupid Go feature that downloads binaries from Google. This means Chrome, Android, and Go are above the level of complexity where a small team can maintain parallel development. (The excessive complexity is a gatekeeping maneuver: your budget must be this tall to become a credible competing browser.)
     
     So there is a complexity threshold for something that needs maintenance: past a certain point, you need a team and a budget. (And I think you need to consider who you're even talking about. Who's buying big-ass servers and then trying to push several thousand reqs/s without a budget? It's not some Mastodon dingus that doesn't wanna update their kernel because they believe in an invisible taint, that's a probably a team. If such a team has a reason to push that much traffic from a single machine then they have a budget to maintain relevant parts of their stack.)
     
     > Again, an unusable piece of software cannot be popular in a space with competition.
     
     Who said otherwise? But you keep treating "usable" and "popular" like you can't have one without the other and like there's a universal metric for the former and like the latter is relevant to the discussion.
     
     > at least in the context of OP (Linux) a lot of what can be called "bloat" are tradeoffs of complexity and security surface for making something fast
     
     Sure. I mean, something like ten years ago Linus said that he didn't have a plan for kernel bloat and that it was past the point where he could review most patches. This is the problem, you know, Linux is bloated. It's not a speed tradeoff; the mechanics of the schedulers are, sure, but if you look at the commit history, most of the schedulers (process, I/O, etc.) have one initial author. Likewise with filesystems. This is because the first version is a design more than it is a wad of code.
     
     > 9front doesn't need shared kernel-userspace ring buffers for async IO (io_uring) to push tens and if not hundreds of gigabytes per second around.
     
     Well, for any given feature, you know. ATA-over-Ethernet came from Plan 9, because Coraid was using Plan 9 and wanted to speed up storage. I don't think they've removed it from 9front but the important thing is that if it's not bloated, you can extend really easily when you need it. CPUs don't push as hard as ASICs or GPUs but they're much more flexible and being general-purpose makes a big difference.
   • Embed this notice
     pistolero (p@fsebugoutzone.org)'s status on Wednesday, 14-Oct-2026 03:09:35 JST pistolero

     in reply to
     @phnt
     
     > Hypocrisy and difficulties of maintaining patchsets for outdated and complicated pieces of software leading to giving up on doing so.
     
     Sure, I think so; the belief in an invisible taint is endemic to some demographics.
   • Embed this notice
     ≠ Brett Stevens ≠ (amerika@fsebugoutzone.org)'s status on Wednesday, 14-Oct-2026 12:13:53 JST ≠ Brett Stevens ≠

     in reply to

     • pistolero
     @p @phnt
     
     That's superstition
     
     Of course Steve Wonder (PBUH) recorded the definitive song on the topic
     pistolero likes this.
   • Embed this notice
     ≠ Brett Stevens ≠ (amerika@fsebugoutzone.org)'s status on Wednesday, 14-Oct-2026 12:15:30 JST ≠ Brett Stevens ≠

     in reply to

     • pistolero
     @p @phnt
     
     Not disagreeing, minor subpoint: usability depends on utility.
     pistolero likes this.
   • Embed this notice
     pistolero (p@fsebugoutzone.org)'s status on Wednesday, 14-Oct-2026 12:15:41 JST pistolero

     in reply to

     • ≠ Brett Stevens ≠
     @amerika @phnt
     
     > That's superstition
     
     Try telling *them* that.
     
     > Steve Wonder
     
     Ray Parker, Jr., being ain't afraid of no ghosts, defeats Stevie Wonder.
     wonderwhite.jpg
   • Embed this notice
     pistolero (p@fsebugoutzone.org)'s status on Wednesday, 14-Oct-2026 12:24:53 JST pistolero

     in reply to

     • ≠ Brett Stevens ≠
     @amerika @phnt It could probably be described as utility divided by pain.
   • Embed this notice
     ≠ Brett Stevens ≠ (amerika@fsebugoutzone.org)'s status on Thursday, 15-Oct-2026 00:02:32 JST ≠ Brett Stevens ≠

     in reply to

     • pistolero
     @p @phnt
     
     Sodomy is the only divine principle of leadership.
     pistolero likes this.
   • Embed this notice
     pistolero (p@fsebugoutzone.org)'s status on Thursday, 15-Oct-2026 00:03:53 JST pistolero

     in reply to

     • ≠ Brett Stevens ≠
     @amerika @phnt The people that believe that allowing a machine to generate code taints it invisibly.
     
     (The real problem is these things do not know how to write anything novel, they just know how to churn out slop at feature factories.)
   • Embed this notice
     ≠ Brett Stevens ≠ (amerika@fsebugoutzone.org)'s status on Thursday, 15-Oct-2026 00:03:54 JST ≠ Brett Stevens ≠

     in reply to

     • pistolero
     @p @phnt
     
     Who is "them" again?
     pistolero likes this.
   • Embed this notice
     pistolero (p@fsebugoutzone.org)'s status on Thursday, 15-Oct-2026 07:47:25 JST pistolero

     in reply to

     • ≠ Brett Stevens ≠
     @amerika @phnt
     
     > AI must be nice for doing stuff like interface code that is blockheaded and brain-numbing.
     
     It's pretty good at doing boilerplate shit that has been done a million times and doing lots of "best practices" bullshit that makes the code impenetrably mind-numbing. It's training data, right, and that's just jithub boshit, so if something has been done a million times and businesses liked it, the clanker will try to go there with it.
   • Embed this notice
     ≠ Brett Stevens ≠ (amerika@fsebugoutzone.org)'s status on Thursday, 15-Oct-2026 07:47:26 JST ≠ Brett Stevens ≠

     in reply to

     • pistolero
     @p @phnt
     
     By "these things" do we mean average developers or AIs?
     
     AI must be nice for doing stuff like interface code that is blockheaded and brain-numbing.
     pistolero likes this.