The question of whether to rewrite an old but working service
So, we have this service. It is a web application (and some associatedbits and pieces) to let our users manage some server-side anti-spamsettings, things like what level of (server-side) spam filtering theywant, whether they'll accept greylisting (although we don't call itthat), and so on. It works, it's been there for years, and it has oneproblem: for reasons beyond the scope of this entry, it's a
Our approach to configuration management
A commentator on yesterday's entry suggestedthat we're already using automated configuration management, just ahome-grown version of it. To explain why I mostly disagree I need torun down the different sorts of configuration management as I see them:
- No configuration management: you edit configuration files in place oneach individual machine with no version control. Your best guess atwhat changed recently is with '
ls -l' and your only way back toan older configuration file is system backups. - Individualized configuration management:
What's in the way of us using automated configuration management
Every so often I poke at Puppet or Chef or one of the other automationsystems and consider if we could really use it. And every time I do Ifind it a hard sell, even to myself (much less hypothetically to myco-workers). Today I've decided to try to write down my collection oftechnical reasons (to go with other reasons ):
- We already have a scripted install process and build instructionsfor all of our machines, and also more or less scripted packageupdates.
- We
My job versus my career: some thoughts
One of the things I've said to people in the past is that while I havea job I didn't really have a career. Not in the sense that my jobis unstable or unsettled (it's actually been rock-solid) but in thesense that I had no idea of where I wanted to go, no particular visionof my future. With no real view of what I wanted I've never had anystrong basis to do things like evaluate my current situation, considerother
Python 3 has very little benefit for ordinary Python programmers
Sometimes an incompatible transition is strongly justified. In somecases the old code and the old ways were actively dangerous to peoplebecause they were too easy to misuse (or were actually basicallyimpossible to use safely); in other cases the baggage of the old wasmaking it essentially impossible to add important new features thatpeople actively wanted.
The Python 3 transition is not one of these. It was almost entirelyabout removing warts in the language, and here is the thing: ordinaryprogrammers don't really care about language
I'm considering building a custom laptop environment
Back in this entry I talked about how my worklaptop was still running Fedora 14 and going to stick there, andthat what was important about my Fedora 14 Gnome 2 environment was sshmenu plus my customizationsfor the Gnome 'Command Line' applet . This isall well and good and my logic is still impeccable, but the wholeFedora 14 situation is becoming less and less tenable. It's notjust the lack of security updates or even updates for Firefox andChrome updates; it's also
The core issue in the Python 3 transition (from my view)
In response to my entry about how Python 3 has always made me kindof angry , a commentator asked an interesting question:
You're right. Python developers aren't the first people to deprecatea heavily-used product. Is there anyone who has made an incompatibletransition like this whom you can point to as a good example tofollow?
[...]
So, what do you do as a developer? What's a better way to shed thecruft of some bad choices while not making
I don't usually think about IO transfer times
All of this started when I was thinking about the differences betweeniSCSI disk IO and normal disk IO to regular disks. In light of ourexperiences I wound up thinking 'well,one of them is that iSCSI disk IO takes appreciable time to actuallytransfer between the 'disk' that is the iSCSI target and the host thatuses it'. After all, a 128 Kbyte iSCSI IO will take around a millisecondjust to get between the target and the initiator (in the best case).Then some
UI details that you don't expect to can matter a lot
Today I got a sharp and pointed lesson in the importance of UI detailsthat you don't really think about due to a simple event: my Twitterclient stopped working (because it hadn'tbeen updated to the v1.1 Twitter API, and Twitter just turned off theolder API).
When I got on Twitter a year and a half or so ago Ididn't spend much time or effort on picking out a client; instead Isettled on the first client I found that supported multiple
The good and bad of IPS (as I see it)
IPS (the 'Image Packaging System') is the new packaging system used inSolaris 11 and (more importantly) many Illumos-derived distributions; itreplaces Solaris 10 packages and patches. I have previously described IPS as being more or less like git ; it puts allfiles together in a hash-based content store and then has 'packages'that are basically just indexes into the store. This contrasts with thetraditional Linux approach to packaging where each package is an archiveof some sort that contains all