Distributions quote of the week [LWN.net]

Writing meaningless slop requires no creativity; writing really bad code requires human ingenuity.

procmail is still in the archive, for heaven's sake. [1]

I too am concerned about the potential degradation in quality of free software given the *volume* of bad code that people can generate using LLM agents, but the objectively worst software in the archive is the product of human ingenuity and I am dubious that's going to change.

Making rules that require us to make all sorts of guesswork judgments and that are effectively unenforceable in practice (no one is required to inform us if they use LLMs) strikes me as a recipe for endless future arguments, which doesn't seem very likely to improve the average quality of Debian packages. Or the experience of being a Debian Developer.

If we think software is bad, we should remove the software because it's bad. I am quite dubious that investigations into the software development tools used by upstream are going to give us much additional information on top of the sorts of metrics we already have readily available (bug rates, CVEs, user complaints, unexplained behavior changes between releases, regressions, lack of necessary feature development, etc.).

[1] For those who don't know the reference, this is not intended as a slam against procmail's functionality or against the people who have worked to keep it viable all these years, but is a reference to procmail's notoriously, uh, unique coding style and carefully (?) hand-coded security-critical string manipulation in C.

— Russ Allbery

to post comments

Procmail coding style

Posted Mar 5, 2026 12:43 UTC (Thu) by mhaggag (subscriber, #48159) [Link] (18 responses)

The mention of unique coding style got me curious, so I took a look. I don't know what I expected, but certainly not this hilarity.

Procmail coding style

Posted Mar 5, 2026 13:29 UTC (Thu) by hmh (subscriber, #3838) [Link] (17 responses)

Thanks for that head's up! I also took a look, and I have that bookmarked now that as the best example of why the ancient "80-columns rule" is nowadays an Extremely Bad Idea, and has been so for at least 35 years.

Especially when it also comes with a 25 or so lines per view-port assumption, which seems likely to have happened when someone came up with that procmail coding style...

I won't comment on the C source itself.

Procmail coding style

Posted Mar 6, 2026 15:56 UTC (Fri) by Wol (subscriber, #4433) [Link] (8 responses)

Well, I still think the *idea* behind those rules is good. I would never enforce them blindly, but I would expect you to have a good reason for breaking them...

Long lines? How do you know your fellow contributors can even DISPLAY that line in its entirety? Or where it'll break on their screen?

25 lines? That's your old fashioned CRT. I find it a convenient size to say that a single block of code (plus explanatory comments) should fit neatly in this. Any more than that, and you're pushing the ability of human comprehension.

I've also got another limit - 66 lines (possibly 132) for a function or subroutine - that'll fit on one or two sheets of line printer output. Same reason as above - it's a convenient limit to make sure that things are in chunk sizes that are easily comprehensible.

Much over those limits and you rapidly find yourself struggling to retain context, so what should be a simple task suddenly takes four, ten, a hundred times longer as you find yourself checking and rechecking stuff you can't retain in your working memory.

Cheers,
Wol

Procmail coding style

Posted Mar 6, 2026 16:21 UTC (Fri) by adobriyan (subscriber, #30858) [Link] (7 responses)

Any rule which enforces precise number of lines/columns should be discarded unless the enforcer can explain the number from the first principles. Your function line limit rule is easily attacked -- nobody is printing code to understand it, why 66 and not 67? does it depend on the problem domain, does it depend on programming language and so on...

Ideally, editors/IDEs would reflow code according to programmer personal preferences bypassing the issues entirely and
put it back when committing to source control.

Procmail coding style

Posted Mar 7, 2026 0:22 UTC (Sat) by Wol (subscriber, #4433) [Link]

Notice I said I would *never* enforce it blindly. But all those limits come from the physical limits of the devices of the 70s and 80s.

Your screen was 24x80.

Your printer was 132x66.

All *comfortable* sizes to work with at certain levels.

And certainly, I find that if I break those rules, the cost of breaking them is high in that the code becomes exponentially harder to understand. Because I can no longer keep context in working memory.

Cheers,
Wol

Procmail coding style

Posted Mar 7, 2026 22:32 UTC (Sat) by cesarb (subscriber, #6266) [Link] (5 responses)

> nobody is printing code to understand it

I actually had to do that once, at a former company. There was one piece of code that was so large and complicated (IIRC, it was the main initialization function for their software), that the best way to understand it was to print it out and spread the pages over the conference room table, to be able to see the whole function at once (and pencil notes on the margins and blank spaces).

Procmail coding style

Posted Mar 8, 2026 9:16 UTC (Sun) by Wol (subscriber, #4433) [Link] (4 responses)

> I actually had to do that once, at a former company.

Not only HAD to do it, is STILL doing it!

One of my first tasks as a junior programmer was to print out a large program written in FORTRAN (probably II :-) and reverse engineer it - don't ask why :-)

My boss, as his first task at the company, had to write a program while he waited six months for the computer to arrive!

And I still find that working from a printout is the most efficient way to code. Yes I have assorted IDE features available nowadays, but lacking the useful unix features like being able to display one file in three or four windows, having a hard copy I can spread out with highlighters etc makes it MUCH easier to jump around and check context without losing my place where I'm actually working!

If I'm forced to work solely on screen, by the time I've checked context I've forgotten why I needed it ... IDE's are like AI - they make you feel more productive while slowing you down :-)

Cheers,
Wol

Procmail coding style

Posted Mar 8, 2026 10:03 UTC (Sun) by mb (subscriber, #50428) [Link] (3 responses)

>IDE's are like AI - they make you feel more productive while slowing you down :-)

I'm just wondering when was the last time you tried to used a code development AI tool?
I think this was true a year ago, but not necessarily today.

Procmail coding style

Posted Mar 8, 2026 16:44 UTC (Sun) by Wol (subscriber, #4433) [Link] (1 responses)

> I'm just wondering when was the last time you tried to used a code development AI tool?

I'm a dinosaur who tries to avoid them.

That said, every time they've tried to persuade me of their worth, they really don't have a clue.

About the only useful example I've seen was somebody asking "why doesn't my code work?". The answer? "You're trying to compare a timestamp to a date string. Do you want me to fix it?". I'd much rather use a system where these problems can't happen.

Cheers,
Wol

Procmail coding style

Posted Mar 8, 2026 17:16 UTC (Sun) by mb (subscriber, #50428) [Link]

About a year ago I wrote in a comment here on LWN that AI doesn't work for code review and barely works for tracking down bugs. At the time this was true.

But today I frequently use these tools for quite complex code review and bug hunting.
Not saying that it's perfect. There are many false positives and nonsense answers to be filtered out.
But for me it certainly went over the threshold where it becomes usable. The signal to noise ratio is good enough to save more time than it would take to do these things fully manually.

Today's large models are pretty good at "understanding" system behavior and finding non-local bugs.

>I'd much rather use a system where these problems can't happen.

Sure. I fully agree.
But there are many orthogonal problems that AI can address.
It's not good compiler/linter tools *or* AI.

Procmail coding style

Posted Mar 9, 2026 8:57 UTC (Mon) by taladar (subscriber, #68407) [Link]

In my experience they actually worked better six months ago than they do now.

Procmail coding style

Posted Mar 6, 2026 16:33 UTC (Fri) by paulj (subscriber, #341) [Link] (7 responses)

I think a limit on width is a good thing. It is easier to read narrower columns of text than wide ones. E.g., look at books and newspapers. They are narrow in the horizontal (as you hold and see it) dimension and long in the vertical. I assume there is some physiological reason for this (eyes being aligned horizontally, so the focus area perhaps is horizontally elongated (?) - plus vertical sweep of vertical columns of text doesn't overscan, as a horizontal sweep of breadth-wise horizontal columns would).

Given there should be /some/ limit on width, the best thing to do is to optimise for the common one we already have - 80 chars (which itself probably was selected based on at least a modicum of attention to reading ergonomics). I use 80x50+ terminals for coding, it's great.

People who code with wide terminals tend to produce overly nested code too. 80 chars stops you doing that kind of thing.

Procmail coding style

Posted Mar 6, 2026 17:12 UTC (Fri) by farnz (subscriber, #17727) [Link] (5 responses)

The 80 column standard for terminals was inherited from punched cards (the IBM card was 80 columns x 12 rows), which wasn't set for readability, but because it was what fitted onto a 7⅜ x 3¼ inch card, and that was the size of "Large Size" US banknotes, so the card could reuse existing storage and handling equipment intended for cash.

Print media aims for around 40 to 70 characters per line in a variable width font (about 40 to 60 in a fixed-width font), because that makes each line readable - and you also have rules about how much of a change in indentation you can have between neighbouring lines (which vary with the amount of vertical white space).

If you're transposing common print media rules to text editors on computers, you end up with something along the lines of "indentation is 4 spaces, no more than 60 characters from the first non-whitespace to the end of the line, no more than ±1 indentation change between neighbouring lines". You're allowed to have lines that are 200 characters long under those rules, as long as the first 140 characters are 35 indentation stops (all white space), and as long as the previous line and the next line are indented by either 34, 35 or 36 indentation stops.

That then allows deep nesting - but you can't do the thing some aficionados of deep nesting do of ending 35 units of indentation with a single line containing }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}, but instead have to have 35 lines each containing a single }. In Python, where you end a block with a blank line, you'd have to have one blank line per block you're closing - and would not be permitted to collapse that down to a single blank line.

Procmail coding style

Posted Mar 6, 2026 17:22 UTC (Fri) by paulj (subscriber, #341) [Link] (2 responses)

Why would DEC text based VTs or LPs have needed to be compatible with IBM punch cards? Not doubting you completely, but... not completely sure the ancestry of Unix 80-char programming is entirely down to IBM.

Procmail coding style

Posted Mar 6, 2026 17:44 UTC (Fri) by mjg59 (subscriber, #23239) [Link]

It makes sense that printers would end up able to represent a card per line, and from there it makes sense that a paper teletype would end up being 80 characters per line, and then you end up with glass teletypes mimicking that?

Procmail coding style

Posted Mar 6, 2026 17:44 UTC (Fri) by farnz (subscriber, #17727) [Link]

DEC terminals weren't 80 characters wide in the early days - the VT05 (for example) was 72 (which was a common width for typewriters and thus TTYs, as was 74 characters).

The 80 character width thing came from wanting to be able to replace a punched card reader and card punch with a terminal for one-offs - everyone had pretty much settled on the IBM card standard by the 1950s, and so there was demand for 80-wide terminals to replace a punched card reader + automated card punch (for all sorts of devices, not just IBM mainframes). And while IBM did have wider terminals (120 and 132 column), as did DEC, keeping the price down drove people to the narrowest mass-market terminal, which ended up being 80 columns to match punched cards.

Procmail coding style

Posted Mar 12, 2026 15:11 UTC (Thu) by sinuhe (guest, #68638) [Link] (1 responses)

There were different dumb terminal sizes making inconsistent requirements for terminal width (and length). Same goes for punch cards. What convinced me to return to 80 character width (78 or 79 based on newline) was the occasional Linux terminal fail over with SVGA. Though email RFCs now allow longer line lengths for SMTP, the display for reading can still default to the old RFC requirements. It's a reason that Linux, GNU, and other coding standards still insist on 80 characters, (even with Torvald's arguing that text terminal only users are living in the past).

Perhaps we'll fully shed these old standards, but it hasn't fully happened yet. Context is important here as to what matters. Wrapping your code thinking around these old requirements *is* living in the past, but those derived principles also aren't entirely wrong, so much as good principles with out-of-date context.

Procmail coding style

Posted Mar 20, 2026 8:54 UTC (Fri) by daenzer (subscriber, #7050) [Link]

> It's a reason that Linux, GNU, and other coding standards still insist on 80 characters, [...]

FWIW, the Linux kernel coding style hasn't really "insisted" on 80 characters for almost 6 years, since https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/... .

Procmail coding style

Posted Mar 12, 2026 21:33 UTC (Thu) by Wol (subscriber, #4433) [Link]

> I assume there is some physiological reason for this (eyes being aligned horizontally, so the focus area perhaps is horizontally elongated (?) - plus vertical sweep of vertical columns of text doesn't overscan, as a horizontal sweep of breadth-wise horizontal columns would).

The longer the line, the harder it is to jump from the end of one line to the beginning of the next.

One of the strengths of lilypond is that it tries - even with repeating identical lines - to make them all subtly different, when your reading speed is being driven by circumstances outside your control (the conductor's baton), you REALLY don't want to find yourself thinking "which line am I on?".

And the same with text, the harder it is to find the start of the next line, the harder it is to understand the text you are reading.

Cheers,
Wol