In a comment on my entry on the problem of stability and maintenance (which talks about how this is a problemeven in commercial software), Christopher Barts wrote in part:

It's an argument for subscription-based software, if anything: If theonly guaranteed revenue stream for a piece of software is selling newversions, the software will never be done. If people pay simply to usethe software, the software can be done when it's done, and the companyisn't losing anything.

Unix shells have been doing basic file-based autocompletion fordecades, but of course basic filename and command completion isn'tenough. Modern Unix shells increasingly come with support forintelligent autocompletion that gets programmed to be command andcontext sensitive for various commands. A modern shell will notjust complete filenames for less , it will (perhaps) completehostnames for ssh commands, automatically know what argumentssome command options take, and so on. The degree that it can dothis is limited only by the ingenuity and diligence of

Adrian Colyer's Twice the bits, twice the trouble: vulnerabilitiesinduced by migrating to 64-bit platforms ( via ) is a veryreadable and very interesting summary of an ultimately depressingacademic paper on the security vulnerabilities that get induced inC code simply by migrating from 32-bit platforms to 64-bit platforms.

In theory I sort of knew about all of this, but it's one thing tovaguely have heard about it and another thing to see handy comparisoncharts and examples and so

I was recently talking on Twitter with someone who was consideringdoing their website in Django as a learning project, because theyreally like Python. I had some tangled reactions to this and todayI want to write them down in a better format than Twitter.

Simplified, I feel that basic use of Django is fairly detached fromany particularly deep immersion into Python as a programming languagein its own right. You certainly will write some Python as part ofcreating a basic Django web app, but you'll also write a

Go famously makes plain numeric constantsin source code be untyped and arbitrary-precision (per the languagespecification ). This extendsto constant expressions , which are evaluatedin theoretically arbitrary precision (and in practice precisionmuch larger than that directly supported by the actual machines Gois likely to be running on). All of this is really convenient invarious ways, especially since arbitrary-precision arithmetic isusually what we pretend we're getting in general with computers.

It recently struck me that these arbitrary precision constants andconstant

One of the things that people using open source often wish loudlyfor ( via )is software that's stable and only gets bug fixes, including securityupdates, with no other changes at all. Oh, and they want this for freeas part of an open source project.

As you may have guessed, there is a fundamental problem with this.Indeed it is a classical fundamental problem in software developmentin general, namely that doing only maintenance is boring and veryfew people want to do it (especially for

You can't and shouldn't make a shell script setuid, but there aretimes when you can want to deliberately run a shell script fromwithin a seteuid context, especially a seteuid root one. One casefor this is if you want to kick off a script from PAM module thatmay be run for, eg, password changes.

I will cut to the chase: you probably don't want to do this today,because modern Unixes or more exactly modern shells on Unixes aremaking this harder and

Recently I was reading Eric Elliot's Native Apps are Doomed ( via lobste.rs ),which puts forward the premise that most native apps on phones andtablets are going to be replaced by progressive web apps. I disagreewith the article, but not for the reasons you might expect. In fact,I think the reason why progressive web apps are not going to replacenative apps is summarized quite neatly by another recent web relatedstory, of Firefox removing the Battery Status API .Firefox hasn't taken this

This topic came up in comments on yesterday's entry about YahooGroups not accepting bounces of their email ,so I'm going to make it an entry and elaborate on my views here.

My views on accepting bounces are pretty simple: if you send outemail using anything but the SMTP null sender, you have a responsibilityto accept bounces of it back. In fact, not just bounces alone;bounces and replies, because some of the recipients will haveout-of-office and other auto-responders