inejge

> I was careful to say "Good code still has a cost" and "delivering good code remains significantly more expensive than [free]" rather than the more aesthetically pleasing "Good code is expensive.

Which is nuance that will get overlooked or waved away by upper management who see the cost of hiring developers, know that developers "write code", and can compare the developer salary with a Claude/Codex/whatever subscription. If the correction comes, it will be late and at the expense of rank and file, as usual. (And don't be naive: if an LLM subscription can let you employ fewer developers, that subscription plus offshore developers will enable even more cost saving. The name of the game is cost saving, and has been for a long time.)

> we invented this new thing called fire [...] So the tribe leader (who, by the way, gropes your children) proposed a solution: centralize control of all the fire

Of all the things, a "save-the-children prolegomena to the Prometheus myth" certainly wasn't on my bingo card today. So thank you for that, but I'm not aware of any reports of fire-keeping in the way you've described. Societies and religions do have sacred traditions related to fire (like Zoroastrians) but that doesn't come with restrictions on practical use AFAIK.

It's in the library you're using, and you're not using all of it. I've had that exact situation: a dependency was vulnerable in a very specific set of circumstances which never occurred in my usage, but it got flagged by Dependabot and I received a couple of unnecessary issues.

Definitely. [1] (Use reader mode if the page misbehaves.)

[1] https://web.archive.org/web/20260220083443/https://www.theat...

> Yes, you configured an LDAP server using it's own protocol. It was not good.

It's still possible to configure OpenLDAP via the slapd.conf file. The old roadmap called for ditching configuration file support in 2.5 IIRC, but it proved hugely unpopular so the file works to this day. The new configuration style is mainly useful for live updating of access rules and indexing.

> I would expect WD-40 to work fairly well because it cleans the chain and gets the filth out of the links

That it does, but it doesn't leave much lubricant behind, which you need for a properly functioning chain. As you know, you want something that will get between the pins and rollers and stay there, minus the grime that would turn it into grinding paste. Which is probably why some people swear by wax, but that sounds like a giant hassle.

Just like Twitter is now X, full stop? With the difference that the "Office" brand is much older and has much more staying power. Besides, the desktop application suite is still named the same AFAIK.

> It seems massively unlikely.

Why? There were other talented people who produced masterful works at an early age. From the same time as this there's a Dürer self-portrait, also aged 12-13:

https://en.wikipedia.org/wiki/Self-Portrait_at_the_Age_of_13

> We don't have any really reliable records from that time.

Uh, no. There's no documented attribution of that painting to Michelangelo; that doesn't mean that other things weren't reliably recorded.

> But why not have the developer that wrote the code guide the AI to generate the content? They know the code best.

Knowing the code and knowing how to make the code, or the interface to the code, comprehensible to another user, are different things. Just like with UIs, and the fact that an expert is not necessarily the best teacher.

Anyhow, the age of monumental feats of technical writing is past. Too expensive, and the subject is too volatile for the most part. Economics dictate that we'll have to deal with the cheapest possible docs. We already do.

> Privacy concerns notwithstanding, one could argue having LLMs with us every step of the way - coding agents, debugging, devops tools etc.

That might work until an LLM encounters a question it's programmed to regard as suspicious for whatever reason. I recently wanted to exercise an SMTP server I've been configuring, and wanted to do it by an expect script, which I don't do regularly. Instead of digging through the docs, I asked Google's Gemini (whatever's the current free version) to write a bare bones script for an SMTP conversation.

It flatly refused.

The explanation was along the lines "it could be used for spamming, so I can't do that, Dave." I understand the motivation, and can even sympathize a bit, but what are the options for someone who has a legitimate need for an answer? I know how to get one by other means; what's the end game when it's LLMs all the way down? I certainly don't wish to live in such a world.

Two things that have helped me a lot of times:

-L: skip preprocessing the input file. When opening rotated log files with the names like logfile.1, logfile.2... the default preprocessor on some distros will recognize them as man page source and helpfully pipe through nroff. If the file is largish this introduces an annoying pause. Using -L skips all that.

Ctrl-R as the first character of a search string will search for that literal string, not the regular expression. Nice if you have regex metacharacters in the search string and don't want to bother with escaping (and don't need the regex facilities, of course.)

> I feel like Lua is absolutely underrated.

This sounds like an offhand Youtube comment, I'm afraid. Underrated how? Its principal strength, easy embedding with the ability to work as an extension language, is well known in the circles where it matters. The authors never gave an impression that they'd aim to make it a language to bury all other scripting languages, which I find refreshing in the winner-take-all culture of programming language discussion. Lua is modest and works well for what it is. No need to go all grandiose.

> I just wish one of the mainstream browsers actually puts their foot down and starts supporting Lua as scripting language.

I sincerely hope not, that would be a very counterproductive dilution of effort. Browser authors already have their plate full with all other web platform problems.

Because there wasn't that much to save, compared to the sheer size of the budget? Because it's much easier to destroy than to build, generally? Because it's always been more of an ideological exercise and a revenge vehicle than a real cost-saving venture?

I don't know about advantages, but lead times in the chip business are long and you're not turning around on a dime without very pressing reasons. Loongson has probably had many things in the pipeline as RISC-V started gaining steam. Their current processors are more advanced designs than the best known RISC-Vs.

> The names these people come up with are so embarrassing. And I'm not even talking about the meaning of 'snitch'.

They should call it "rat" and be done with it.

Besides, "snitch" works for Little Snitch -- I've always found it somehow endearing, although the bare word is unflattering.

> When an aperture is aligned to the winter solstice, it is also aligned to avoid light the rest of the year. An early attempt at air conditioning?

In the northern latitudes, doubtful. It would be cool enough year round.

> Why don't they use qmail as an example?

Perhaps because qmail is an anomaly, not Android? To remain relatively bug-free, a sizeable C project seems to require a small team and iron discipline. Unix MTAs are actually pretty good examples. With qmail, for a long time, it was just DJB. Postfix has also fared well, and (AFAIK) has a very small team. Both have been architected to religiously check error conditions and avoid the standard library for structure manipulation.

Android is probably more representative of large C (or C++) projects one may encounter in the wild.

> If they block/ban/close/suspend a customer account they must provide habeas corpus.

* evidence

"Habeas corpus" is not a lofty expression for evidence, although people sometimes use it as such. It's a procedure for challenging one's detention before a court.

> Hard forks have traditionally led to massive flame wars.

Provided that the project is popular and has a community, especially a contributor community (the two don't have to go together.) Most projects aren't that prominent.

There are ways in which shielding in space can do harm: really energetic particles get trapped and produce a shower of daughter particles and rays over a greater area. So you'd need even more shielding. Or you accept that such things will happen and use rad-hard parts, redundancy etc. When you have the whole atmosphere above, it's much less of a concern.

Besides, that's even more mass to be lofted. Pushing the economics further into the ludicrous end.

> Capital "i"s without crossbars aren't capital "i"s. They're lower-case Ls. Any font that doesn't recognize this should be rejected.

You have asserted this at least thrice in the past thirty minutes. What makes you feel so strongly about it? "Rejected" for what purpose? Do you understand that you've just trashed Helvetica, to take a famous example?

> The 80287 (AKA 287) and 80387 (AKA 387) floating point microprocessors started to pick up some competition from Weitek 1167 and 4167 chips and Inmos Transputer chips, so Intel integrated the FPU into the CPU with the 80486 processor (I question whether this was a monopoly move on Intel's part).

I don't think it was, transistor density became sufficient to integrate such a hefty chunk of circuitry on-die. Remember that earlier CPUs had even things like MMUs as separate chips, like Motorola 68851.

There's illiteracy, and there's functional illiteracy. They're not the same, and people often confuse the two. A literally illiterate person (ha!) wouldn't make headway with almost any realistic computer interface, icons or not.

The 20% statistic is about people who have great trouble reading and comprehending simple sentences, not discerning individual words. It's tragic and debilitating, but such people could muddle through a simple interface with textual labels. A truly illiterate person couldn't.

It's not remotely the same type of error -- error non-handling is very visible in the Rust code, while the Lua code shows the happy path, with no indication that it could explode at runtime.

Perhaps it's the similar way of not testing the possible error path, which is an organizational problem.

> I think it was Snowden who made TLS the default.

Snowden's revelations were a convincing argument, but I would place more weight on Google in its "we are become Evil" phase (realistically, ever since they attained escape velocity to megacorphood and search monopoly status), who strove to amass all that juicy user data and not let the ISPs or whoever else have a peek, retaining exclusivity. A competition-thwarting move with nice side benefits, that is. That's not to say that ISPs would've known to use that data effectively, but somebody might, and why not eliminate a potential threat systemically if possible?

It will help that side of the process (although, as a sibling has noted, you can CNAME your way into a better-controlled update service), but the challenge of automating cert changes for various non-HTTP services, including various virtual or physical boxes with funky admin interfaces, remains. I don't expect that vendors will do much about that, and it will end up on admins' plates, as usual. There will be much grumbling, but fewer solutions.

"Code frequency" for jxl-rs shows no activity from Aug 2021 to Aug 2024, then steady work with a couple of spurts. That's both a longer hiatus and a longer period of subsequent activity (a year+ ago isn't "recently" in my book.) What data have you based your observation on?

> On the SEU issue I’ll add in that even in LEO you can still get SEUs

As a sibling post noted, SEUs are possible all the way down to sea level. The recent Airbus mass intervention was essentially a fix for a badly handled SEU in a corner case.

Okay now I'm imagining a classical ballet recreation of the "Heeere's Johnny" scene. With firemen.

> What has always baffled me is how CS uses the word "safety" where all other industries use "robustness".

FWIW "safety factors" are an important part of all kinds of engineering. The term is overloaded and more elusive in CS because of the protean qualities of algorithmic constructs, but that's another discussion.