SSDs and understanding your bottlenecks
In a comment on my entry on five years of PC changes, it was suggested that I should have used a SSD for the system disk. I kind of addressed this in the original entry on my new machine's hardware specifications, but I want to use this to talk about understanding where your bottlenecks are (and aren't).
The simple way of talking about the benefits of SSDs is to say that they accelerate both reads and writes, especially synchronous writes and random IO in general (because SSDs have no seek delays). But phrasing it this way is misleading. What SSDs actually accelerate is real disk IO, which is not the same as either OS-level reads and writes or what you think might produce disk IO. This is fundamentally because every modern system and environment tries to keep as much in memory as possible, because everyone is very aware that disks are really, really slow.
(Even SSDs are slow when compared to RAM.)
Thus when you propose accelerating any disk with a SSD, there are two questions to ask: how much do you use the disk in general and how much actual disk IO is happening. There's also a meta-question, which is how much of this IO is actually causing visible delays; it's quite possible for slow IO to effectively be happening in the background, mostly invisible to you.
Although I haven't measured this, my belief is that system disks on
Unix machines are in many ways a worst case for SSDs. I tend to think
that my desktop environment is relatively typical: I normally use only
a few programs, many of them are started once and then stay running,
and I often already have an already executing instance of many of the
programs I re-run (for example, xterms and shells; a Unix system is
basically guaranteed to always have several instances of
already running). All of these act to limit the amount of OS-level
reading and writing being done and increase the effectiveness of OS
memory reuse and caching. Even on a server, this pattern is likely to
be typical; you need an unusual environment to be really using lots of
/usr/bin and libraries from
/usr/lib and so on, and
doing so more or less at random.
(Also, note that much system disk IO is likely to be sequential IO instead of random IO. Loading programs and reading data files is mostly sequential, for example.)
Given this usage pattern, the operating system almost certainly doesn't need to cache all that much in order to reduce IO on the system disk to almost nothing. How likely it is to be able to do that depends on how much memory the system has and what you're doing with it. Here the details of my hardware matter, specifically that I have 16 GB of RAM and don't run all that much that uses it. Ergo, it is all but certain that my OS will be able to keep enough in memory to reduce system disk IO to almost nothing in normal use. If the system disk is barely being used most of the time, making it an SSD isn't going to do very much most of the time; there just isn't anything there for the SSD to accelerate.
Now, here's something important: saying that an SSD wouldn't make a different most of the time isn't the same thing as saying an SSD would never make a difference. Clearly an SSD would make a difference some of the time, because my system does sometimes do IO to the system disk. Sometimes it does a fair bit of IO, for example when the system boots and I start up my desktop environment. If you gave me an SSD for free, or if 250 GB SSDs were down in the same $50 price range that basic SATA disks currently are, I would use them. But they aren't, not right now, and so my view is that SSDs for system disks are not currently worth it in at least my environment.
(I also feel that they're probably not that compelling for server system disks for the same reasons, assuming that your server disks are not doing things like hosting SQL database storage. They are potentially attractive for being smaller, more mechanically reliable, and drawing less power. I feel that they'll get really popular when small ones reach a dollar per GB, so a 60 GB SSD costs around $60; 60 GB is generally plenty for a server system disk and that price is down around the 'basic SATA drive' level. It's possible that my attitudes on pricing are strongly influenced by the fact that as a university, we mostly don't have any money.)
Note that user data is another thing entirely. In most environments it's going to see the lion's share of disk IO, both reads and writes, much more of it will be random IO than the system disk sees, and a lot of it will be things that people are actually waiting for.
PS: it's possible that the inevitable future day when I switch to SSDs for my system disk(s) will cause me to eat these words. I'm not convinced it's likely, though.
Sidebar: mirroring and SSDs
Some people will say that it's no problem using a single SSD for your system disk because it's only your system disk and SSDs are much more reliable than HDs (after all, SSDs do not have the mechanical failure issues of HDs). I disagree with them. I do not like system downtime, I have (re)installed systems more than enough times already, and I count on my workstations actually working so that I can get real work done.
(If you gave me an SSD for free I would probably use it as an unmirrored but automatically backed up system disk, paired with a HD that I could immediately boot from if the SSD died. But if I'm paying for it, I want my mirrors. And certainly I want them on servers, especially important servers.)
The two sorts of display resolution improvements
Recently I read Matt Simmons' Retina display for Apple: Awesome for everyone, which is roughly about how Apple's increasing use of high resolution 'retina' displays will be good for everyone who isn't happy with garden variety 1080p displays. While I like the general sentiment, I want to sound a quiet note of contrariness because I think that more 'retina' displays will not necessarily do what Matt Simmons wants.
You see (and as Matt knows), there are two sorts of resolution in action here: physical screen size and DPI. Apple's products with retina displays demonstrate this beautifully; they are physically small but have a very high DPI (at least by computer standards; they are low but acceptable by print standards). What most sysadmins want is more physical size with an acceptable resolution; this is the 'more terminal windows' solution. Based on current practice we're okay with relatively low resolutions, on the order of 75 to 95 DPI or so.
(Today I think of 24" 1900x1200 widescreen displays as relatively commodity LCDs and where the starting point for decent sysadmin gear should be; 19" LCDs now strike me as kind of small. This is 95 DPI and also large enough that two side by side horizontally are hard to fit on a desk and expose other issues.)
Increasing DPI without increasing size doesn't really let you get any more windows on the screen; instead it gives you better and smoother rendering of text and other things. This can sometimes make it feasible to use smaller text for windows, but there are strong limits for this (unless you like squinting at tiny text, and trust me, you don't really). Higher DPI plain looks better, though, and Apple's 'retina' displays are up into what used to be the realm of basic laser printing.
There are good reasons for Apple and other makers of small devices to push for high DPI displays. The devices generally can't get physically larger screens (they won't fit the ergonomics), and higher DPI makes small text and non-Latin text much more readable (my impression is that ideogram-based writing systems especially benefit from high DPI). But I'm not at all confident that these high DPI small devices will get makers of conventional displays to do anything to pick up their game, since the environments and the constraints are so different. It probably doesn't help that many people buy regular displays based primarily on price.
(One issue with high DPIs in general is that the sheer pixel counts start getting daunting for decent sized physical displays with high DPIs. My 24" widescreen display at 300 DPI would be around 6000 by 3800 pixels. With 24-bit colour the framebuffer alone is 65 megabytes of RAM, which means 3.8 Gbytes a second of read bandwidth simply to output it at 60 Hz.)