One of the things that the situation with security fixes and the Linuxkernel changelogs illustrates isthe difference between programs and products. With a program, what youget is the program; with a product, what you get is the program and awhole ecology of things surrounding it, ranging from documentation tobackporting security fixes into older versions.

(This is why it takes a significant amount of effortto turn a program into a product, as Fred Brooks and others have noted. Icredit Fred Brooks because I believe The

Here is a Python question I have been mulling over since a commenton a previous entry : does codeportability across different Python implementations matter verymuch at the moment?

My suspicion is that the answer is 'not really in practice', becauseI don't see much motivation for moving code between the differentimplementations:

• the three leading implementations ('CPython' (the normal Python),Jython, and IronPython) exist in significantly different environments;you cannot really drop in one as a replacement for another, so

Probably like many places, we weigh the potential or actual disruptionof things like kernel updates against the risks of not updating whendeciding how urgent applying them is. As part of this, I have developeda personal way of sorting security issues into different categories thatI care about, with an end result ranging from not so bad to really bad(and if we are lucky, 'no impact, we can ignore').

For various reasons I feel like writing out the things I care aboutand look at today