I just went to an annoying amount of work to send out some email withan alternate and expendable address here in such a way that it wascarefully scrubbed of all traces of my real email address (no Sender: ,no envelope origin address, no nothing), but I also put my name on themessage.

(The annoying amount of effort required is another rant.)

On the one hand, I'm a paranoid about giving people my email address,or when I have to give them an email

I know, the Illumos people are busy. Butit still makes me grumpy that it is a several-step process (which sortof requires JavaScript) to get from their web page to find out where theIllumos equivalent of the OpenSolaris source repository (theoretically)is.

(I say theoretically because it is not responding for me right now.)

This process might go faster if you are already immersed in the arcanaof OpenSolaris development, but I wasn't. Since I was looking at thesource code for

Over time, I've come to the opinion that some programming tricks are more damaging to your code'sreadability than others. I think that there are at least two sorts ofcoding tricks, which I will call opaque tricks and impossible tricks,and impossible tricks are more damaging than opaque tricks.

An opaque trick is one where the reader stares at the code and has noidea what it does. Either they don't understand the operations, orthey don't understand what the results of doing the

From the reddit discussion and also the comments of my previous entry on import ,I learned that people both do ' import os.path ' and then useos.whatever without explicitly importing os , and do ' import os 'and then just use os.path.whatever without explicitly importing os.path .

First off, I don't think that you should do either of these even if(and when) they work, for os or any other module. This is a stylisticthing, but when doing

From Nate Lawson's most recent entry :

Most public key systems fail catastrophically if you ignore any oftheir requirements. You can decrypt RSA messages if the padding is notrandom ,for example. With DSA, many implementation mistakes expose thesigner's private key.

(emphasis mine.)

Even small implementation mistakes are dangerous to crypto systems,but there are degrees of danger. Most of the time, 'all' that happensis that a bad implementation doesn't deliver either the encryption orthe endpoint authentication

Something that I've been thinking about recently is when we need tostart thinking about turning over our fileserver infrastructure , or in the alternate way of thinkingabout it, how long we can make the infrastructure last. Since thiscould get very theoretical, I'm going to nail down a specific question:is it reasonable to assume our current infrastructure will last at leastfive years from our initial deployment? We don't seem likely to runinto capacity limits , so one major aspect isthe issue of how

Like a number of other security protocols, TLS (aka SSL) comesin several generations and offers a large selection of potentialciphers. Many of these options are actually a bad idea from a securityperspective; the ciphers are weak or use things that have been broken,and older versions of SSL have known weaknesses. By default, Apache'smod_ssl enables them all and even sometimes defaults to (very) badchoices, all in the vague name of accommodating some export version of abrowser from 19

I hate the modern Gnome file chooser dialog. Fortunately its problemsmake a great illustration of the perils of falling victim to a goodidea.

The good idea that infected the modern Gnome file chooser dialog isshowing a preview of the file you've selected (provided that it is apreview'able media type, such as a picture). This would be a great ideaif it worked instantaneously, and perhaps it does on some people'smachines. But on slow machines it is most of a usability disaster

Right now, I'm feeling enthused about the idea of writing some thingsin one of the interesting new languages and environments, such asGo or node.js. But here's where things collide with my problemswith learning languages ; if I'm going to writeany significant amount of code in these new languages, it has to dosomething real. And most of the real things that I have to do arenot personal projects but software that I would want to use in ourenvironment here.

Which