What you can (probably) count on for concurrency in Python
A comment on the previous entry about how builtins are atomic asked a really good question:
Is there actually a guarantee in CPython that they're atomic,or is that a side-effect of implementation?
There are two answers, at least in my opinion. The legalistic answeris that there is no guarantee at all, because there's nothing inthe documentation. But this is because the CPython documentationdoesn't talk about concurrency issues at all; even the thread moduledocumentation doesn't really say anything
The yum versionlock problem
Update : I'm wrong about this. See the comments for more details.
Since I alluded to this issue recently , hereis the problematic interaction between yum's versionlock plugin, whichis used to 'pin' a particular version of a package so that it won't getupgraded, and yum's installonly feature, which is used by Red Hat andFedora to keep only some number of kernels (by default 2).
Here is the problem sequence:
- you are running version X of the kernel
dict.setdefault() as a concurrency primitive
One of the things I do in the back of my mind is to keep my eyes openfor Python things that could be useful for concurrency (especiallysince I still have a concurrency problem that Ihave to solve one of these days). Because of what the GIL protects , one of the useful things to look for isinteresting operations on builtin types.
All of which is a roundabout way of saying that it recently struckme that dict.setdefault() is a limited test-and-set operation .All
How packaging systems should handle kernel updates
As a system administrator, I have some relatively strong opinions on howLinux distributions and packaging systems should handle kernel updates.Since I have just gone through the experience of yet another mass kernelupdate of our servers, I feel like writing them up:
- you should be able to have multiple kernels installed at once.
- it should be easy to tell which package's kernel you are running,and thus whether or not you are running the most current kernel.
- installing a kernel update should never overwrite an existingkernel image;
One thing that I dislike about typical debuggers
One of the things that I hate about typical debuggers is that they wantme to hold their hand all the time. Okay, this is not entirely fair;they default to having me hold their hand, and generally don't do areally good job of supporting hands-off operation.
This is not really their fault, because debuggers have a differentview of how they're going to be used than I do. A classical debugger(like gdb ) expects to be used by people who are carefully narrowing
Retracting blog entries in the face of syndication feeds
Suppose that you have accidentally published a blog entry that you really didn't want to and now want to retract, unpublish, disappear, or the synonym ofyour choice the entry. You could just delete the entry, but thishas a problem: your syndication feeds (RSS, Atom, et al).
Specifically, removing an entry from your blog and thus your feeddoesn't remove it for people who've already fetched a version of yourfeed that included the entry. Feed readers keep their own
Two different usage patterns
Recently, for my version of recently, a shell history meme has beengoing around various places .Thinking about the meme and what it would look like for me has ledme to thinking about two different usage patterns in Unix graphicalenvironments; I will call these persistent and disposable.
People who follow the persistent pattern like long-lived, multi-purposecontexts; for example, they are inclined to leave a terminal window or ashell session active for a long time, and over its lifetime such a shellwill wind
Why I'm mostly out of the email (anti-)spam game
I was once fairly interested in and involved in anti-spam stuff; I spenta bunch of time on anti-spam precautions here, followed news sources,and so on. These days, I find myself much less involved, and althoughI still care about various spam issues, I don't spend very much timeinvolved with the whole field.
What happened is simple: somewhat to my surprise, the spam problemhere was pretty much solved when we deployed a commercial anti-spamsolution in combination with greylisting
Thinking about uses for (system) activity tracers
System activity tracers are a hot topic, with the best known one beingSun's DTrace. In thinking about this issue recently, I believe thatthere are three sorts of questions that they can be used to answer,or at least that I'm interested in having answered:
- what is my system doing?
Performance related tracing is one obvious subset of this, both inthe 'what is taking all the time' sense and in the 'how long doessome operation take' sense.
- why is my system
One consequence of Linux's dynamic network device naming
I knew that Linux did dynamic network device naming , but one consequence of that only really sunkin recently. Dynamic naming is relatively predictable for interfacesthat are always on (especially when various distributions work hard to make them verypersistent), but where it can really surprise you (and your software)is when the interfaces are dynamic. Like, say, PPP interfaces.
Just like Ethernet interfaces, the first active PPP connection gets ppp0 , the second one gets ppp1 , and so on. But unlike Ethernets