An alterate pattern for polymorphism in C
As I mentioned in yesterday's entry , CPython(the C-based main implementation of Python) uses an interesting varianton struct -at-start based polymorphism. To put it simply, it uses #define s instead of a struct . This probably sounds odd, so let meshow you the slightly simplified CPython 2.7.x code:
#define PyObject_HEAD \ Py_ssize_t ob_refcnt; \ struct _typeobject *ob_type;#define PyObject_VAR_HEAD
Some patterns for polymorphism in C
As I've written about before , C programmers tendto (re)invent certain parts of OO programming on their own as thenatural easiest way to write code. In that entry Imentioned that one thing C programs tend to have is a polymorphic objectsystem. As it happens, I've seen several different ways of doing this inC (and I'm sure there are others, C programmers are inventive).
In theory the simplest way of doing polymorphism in C is just to startall of
How our fileserver infrastructure is a commodity setup (and inexpensive)
Our fileserver environment may soundluxurious and expensive (after all it involves Solaris, ZFS, and iSCSI,all things that often mean lots of money), but it isn't really. I'vementioned (in comments) a couple of times that it's essentially commodity hardwareand that I don't think we could do it particularly less expensivelywithout fundamentally changing what it is, but I've never really explainedthat in one place.
The fundamental architecture is a number of Solaris fileservers which get
GNU sort's -h option
I only recently became aware ofGNU sort's -h option, which strikes me as a beautiful encapsulation ofeverything (both good and bad) that people attribute to GNU programs andtheir profusion of options.
GNU sort's -h is like -n (sort numerically) except that it sortsnumerically for GNU's 'humane' numbers, as produced by (for example) GNUdu's -h option. This leads naturally to a variant of a little scriptthat I've already talked
What I'd have liked to hear about Python 3 from the developers
I mentioned in my earlier entry that a different way offraming the Python 3 announcement would have made a big difference in myreactions to Python 3. For peculiar reasons, I think it's worth beingexplicit about what that would be.
Put simply, my major bad reaction to Python 3 stems from peopleapparently being expected to port their existing code to Python 3 inorder to keep it operational. So for me, the way to make a betterannouncement about Python 3 is to make it explicit that the developers
Why I think that stupid spamming is actively wasteful
In reaction to my last entry , a commentatorwrote:
You assume it's more cost efficient for the spammer to fix his systemrather than just have a slightly higher percentage of broken addressesin his list than otherwise. I'd guess the broken addresses cost thespammer virtually nothing in resources or time.
I used to feel this way, that spamming was basically free, but I'veshifted my views over time. My current belief is that in today'sInternet environment, sending spam to addresses is
A spammer that is not the brightest light in the box
I'm fond of saying that spammers are generally not stupid; they do whatworks and they're quite good at figuring out what that is. However,every so often a spammer comes along who quite clearly challenges oroutright breaks this view.
Here's a snippet from a recent SMTP conversation that one of mymachines logged:
remote from [208.86.167.19]HELO postoffice.wieck.com250 Hello postoffice.wieck.comMAIL FROM
Why I somewhat irrationally have a distrust of ZFS on Linux
By now there are a number of ways to run ZFS on Linux (for example here as a native kernel module and here as a user-level component connected to the kernelwith FUSE ). All such efforts areseparate projects with no prospect of that ever changing because ZFS'sCDDL license is fundamentally incompatible with the Linux kernel's GPLv2licensing.
(Theoretically Oracle could decide to relicense ZFS. The odds of thathappening appear to be very low.)
I'm not really interested in running important
Does Python 2 need to evolve?
Here's a question, somewhat motivated by my entry about my anger atPython 3 (in a way that I'll have to explain later): doesPython 2.7.x particularly need to evolve, either in the language or inits standard library?
(By 'evolve' here I do not mean 'turn into Python 3'; I mean 'keepbeing developed in a way that maintains Python 2 compatibility'.)
There are certainly a number of things that would be nice to have
A confession: Python 3 has always made me kind of angry
I have a confession. Although I've written about how various aspects ofPython 3 irritate me, I've never come out to admit something: Python 3makes me kind of angry. Well, okay, let me hastily clarify that. Whatmakes me angry is not so much Python 3 by itself (although various ofits defects irritate me) but the apparent views of the Python developersabout the relationship between Python 2 and Python 3 that were putforward when Python 3 was released.
(Now, there