Linux desktops and pre-packaged machines from big vendors
Today, I tweeted:
I wonder if Dell or any of the big vendors makes reasonably-priced (mid-)tower systems with 4 3.5" drive bays and 32 GB of RAM.
There is a story behind this tweet, and it's in part a story of how far Linux has come over the time I've been using it.
For a long time, the only way to get a decent Linux (desktop) machine was to specify it from parts yourself. If you were so foolish as to buy a pre-packaged desktop from a major desktop vendor like Dell, HP, or IBM, you might well wind up with hardware that Linux didn't support or only supported badly. So this is what we routinely did at work and what I did for my home machine. My previous generation work machine here back in 2006 was a specified-from-scratch machine, and so is my current office workstation. But, well, Linux has come a long way since 2006, or even 2011. These days it's pretty mainstream and widely supported, at least on most of the kind of plain vanilla hardware that you find on ordinary desktops. Certainly my co-workers have gotten Dell desktops as their new desktop machines at least once and had no problems running modern Linuxes on them.
Which gets me around to the subject of my current office workstation, which has the same hardware as my current home machine and is roughly as old as that machine, which means that it is a bit over five years old. It still runs perfectly fine and performs well enough for the work that I do, but I need to face reality; just as hard disks wear out eventually, so do things like CPU and case fans, power supplies, and eventually motherboards and CPUs and so on. My office machine is going to die from hardware failure at some point, the only question is when. I would like to replace it with fresh hardware before then, and after five years of life seems like a good time to at least start thinking about it (and to get the gears turning, because around here they move slowly for this kind of thing).
When I started thinking about this, my first instinct was to once again specify a machine from scratch (even though I'm not sure who we'd get to build it for us any more). But, well, do I still have to do that these days? In fact, does it even make sense to do that? I don't necessarily have demanding needs, Linux is likely to run on everyone's pre-packaged desktops, and it really should be the case that Dell et al can build machines cheaper than we can, since Dell is doing it in bulk (although with less volume than in the past, given the general decline of the PC market). And buying a Dell is probably much easier to get through the university purchasing process than a custom-built machine from some small place.
(Or we could buy parts and I could have the fun adventure of assembling my new work machine myself. I'm sure it would be educational and people assure me it's not too hard, but it's probably at least an inefficient use of my work time. Not that universities necessarily care about that.)
Having looked at this a bit, I suspect that my needs are sufficiently esoteric that they push me into the area where Dell and company start selling us excessively expensive 'workstation' machines. This may well make 'specify from parts' the least expensive option, but this time around, unlike in the past, it seems worthwhile to at least check. And I can imagine being perfectly happy with a Dell or the like assuming that it has the basic features I need.
It makes me quietly happy for Linux that what once was an esoteric option that required careful hardware curation has moved to being something where I can generally assume it just works, on both servers and even desktops.
(I'm sure there's some hardware that doesn't quite work great, especially if you're right at the edge of newly released stuff, and of course graphics cards are their own sad story of closed source drivers. But my impression is that running into such hardware is now either uncommon or outright rare.)
Sidebar: What I need in an office workstation
My needs almost fit in a tweet: four or more 3.5" drive bays (five would be great), 32 GB of RAM, a processor at least as modern as the i5-2500 I currently have, an onboard Ethernet port and onboard sound (almost sure to be on anything), and either onboard graphics that can drive two displays at 1920x1200 at 60 Hz or a slot for a graphics card so I can drop my current card in (I'd prefer to use onboard graphics). It would be ideal if there was either a second Ethernet port or a PCI(E) card slot I could put an additional network card into.
(And of course a bunch of USB ports, including at least a few USB 3.0 ports. But everything has those.)
I wouldn't mind an optical drive, but I'm not going to turn down a vendor pre-packaged desktop if it lacks one. I simply don't burn or read discs at work very much these days, and we're looking to move even further away from them if possible. USB memory sticks are (or would be) just so much more convenient for installing machines and so on.
(This isn't what I'd like in a theoretical new machine, but work is unlikely to buy me things like the latest top-end i7 CPU even if I try to make rational arguments about how it has an expected lifetime of at least five years so it totally makes sense.)
My still-mixed feelings about Python's docstrings
I've written before
about why I'm not really fond of docstrings in Python. I continue
to feel that way, but at the same time I have to acknowledge that
the Python world has made its decision; although
help() et al
have some heroic hacks to deal with documentation comments, the only fully supported in-Python way to document
your module for other people is with docstrings.
This doesn't mean that docstrings are the best way to document your
modules. Python's own module documentation, for example for the
os module, is much
more extensive than what '
help()' on the module will give you.
The in-Python version is basically a moderate summary of the full
documentation. But writing this sort of documentation is a lot of
work, and if you're only going to write documentation for a public
module in one place and once, it's clear that it has to be docstrings.
I tend to write docstring based documentation only erratically for non-public code. Documentation in comments simply looks better and 'more right' to me (and I find it less distracting when it's placed before a declaration, instead of between a declaration and the code as a docstring needs to be). I assume that anyone who needs to work with the code is going to have to read it, at which point they're going to see the comments. However this is partly because we don't have a stand-alone collection of Python modules that are reused across disparate programs, which means that I'm basically never in a situation where I just want to know what a module does so I can use it in a new program.
I definitely have mixed feelings about how Python has chosen to
explicitly expose docstrings as attributes on functions, classes,
and so on. On the one hand, it makes the simple version of
be pretty straightforward and non-magical; you basically combine
dir() and looking at everything's
__doc__. On the other hand,
__doc__ is exposed to Python code has tempted me into
abusing it for passing around other function-related information
that I wanted my code to have access to. And of course the real
help() is rather more complicated.
(In theory this also decouples where docstrings live from
implementation. For example, Python 3.x could decide to turn
properly formatted comments that are right before declarations into
docstrings if the declaration didn't itself already have a docstring.)
My aesthetic feelings about how docstrings look are probably significantly cultural, in that most of the programming languages I've used and been exposed to used explicit comments and not docstrings and so I'm not used to them. I don't know if docstrings read more naturally to people who 'grew up' in Python and similar languages, but I suspect that they may well do so. Perhaps I should make an effort to write more docstrings in future Python code, instead of reflexively documenting everything in comments.
(Not that I write much Python code these days. But my most recent Python code was once again all comments and no docstrings, although it's a program and not a module.)