Every so often I wind up reading something that makes me see red.Today's is this piece (seen via Hacker News). So I want to write an open message:

Dear open source people, it is really simple. If someone has a workingsystem at time X, upgrades to your new software, and their system stopsworking, they do not care if their system might work at some undefinedpoint in the future. You broke their system now , and this is whatthey care about. You

Recently I saw a stackoverflow question on why scriptinglanguages aren't suitable as Unix shell scripting languages . My answer is that shellsare strongly optimized for a different use case than programminglanguages, and this has significant effects on the design of thelanguages that they use and their semantics.Above all, shells are optimized for invoking external programs; asuccessful shell has ruthlessly pruned away everything that makesthis awkward. Scripting languages, like other languages, are insteadgenerally optimized for writing expressions, statements, and otherinternal language

A rather long time ago, a commentator on my entry on the practicalitiesof non-GPL'd kernel modules wrote, in part:

ZFS is most beneficial to companies running storage servers. Thesecompanies will only use supported modules [...]

I actually think that this is backwards. Ignoring the various legalissues for the moment, companies building commercial storage serversare exactly the people that I would not be surprised to see using akernel module that was not and could never be in the mainline Linuxkernel.

There is a popular view that use of SSL creates authentication. Ifyou really care seriously about security (and worry a lot aboutinterception), this is not the case. Assuming that all else goes well,a SSL certificate only creates authentication if you (as the user of awebsite) can trust that the certificate actually belongs to the website;otherwise you could be talking to an imposter or someone conducting aman in the middle attack.

(Note that there is a lot that can gowrong before you get

Go has re-popularized the idea of handlingall of your blocking waiting-for-things operations by using CSP -likecommunication channels instead of select() (in Go, using goroutinesand channels). However, it's my firm belief that this isn't good enough;despite what some people think, you cannot replace select() in mostcommon CSP-like implementations.

The crucial ability that select() gives you is the ability to stopwaiting for something in response to some external event

One of the things that has struck me lately is that spam has becomean implicit tax on publicly participating in various open sourceprojects. The mechanisms of this are fairly simple: if you have asufficiently popular open source project, the spammers are sittingthere mining the project mailing lists and their web spinoffs for emailaddresses and then spamming the heck out of them. There's probablyalso spammers mining web-based bug trackers too, where bug trackersexpose this information.

(Actually, this is probably a simplification.

Everyone knows that bug trackers are where bug reports go to die, atleast if your project is at all large or popular. This causes variousproblems, the root cause of all of which can be summarized as that yourbug tracker is lying to people about the true status of nominally activebug reports.

So here is a modest proposal (somewhat in the Swiftian sense) forhow to fix your bug tracker. Simply introduce and automate the followingpolicies:

• close or expire bugs that have received no action in N months

Here is something that I have come to slowly believe about computersecurity:

Users don't care about security.

This goes beyond security being a pain . Security issimply not interesting to most people; it has nothing to do withwhat they actually want to do with their computers (or anything else).Instead security is simply a deadweight overhead, something they dobecause they have to. Well, because they have been scared into doingso.

One consequence of this is that people are not interested in educatingthemselves

As I've noted before , I am sort of ahalf-hearted user of code testing; I like it, but I haven't internalizedit to the degree that I do it all the time, even if it's painful orannoying. Sometimes this bits me on the rear as a learning experience,as happened recently.

I have a Python module for dealing with ranges of IP addresses (oftenin the form of CIDR netblocks); I wrote it at least six years agoand have used