teideal glic deisbhéalach » hardware

Functional programmers on Twitter

Bryan O'Sullivan — Fri, 05 Dec 2008 19:11:03 +0000

Twitter has become quite the hotbed of chatter about functional programming over the past few months, as a substantial number of pretty well known FP people have either been present all along or have signed up recently and started following each other.

Here is a list of people I know about who tweet about FP on a semi-regular basis, along with what I think are their main interests. If you want to see the list extended or modified, let me know.

Bryan O’Sullivan (bos31337) – Haskell
Chris Smith (aChrisSmith) – F#
Alex Payne (al3x) – Scala
Brandon Allberry (allberry_b) – Haskell
alpheccar – Haskell
Andre Pang (andrepang) – Erlang
Arnar Birgisson (arnarbi) – Haskell
Brad Anderson (boorad) – Erlang
Chris Eidhof (chriseidhof) – Haskell
Conal Elliott (conal) – Haskell
Conrad Parker (conradparker) – Haskell
Dean Wampler (deanwampler) – Scala
Don Stewart (donsbot) – Haskell
Dave Pollak (dpp) – Scala
David MacIver (DRMacIver) – Scala
Eelco Lempsink (eeclo) – Haskell
Bob Ippolito (etrepum) – Erlang
Galois, Inc. (galoisinc) – Haskell
Jake McArthur (geezusfreeek) – Haskell
Pepe Iborra (hate_pick_pick) – Haskell
John Goerzen (jgoerzen) – Haskell
John Kalucki (jkalucki) – Scala
Eugene Kirpichov (jkff) – Haskell
Jorge Ortiz (jorgeortiz85) – Scala
Joseph Holsten (josephholsten) – FP
Justin Sheehy (justinsheehy) – Erlang
Kazuya Sakakihara (kazooya) – Haskell
Kevin Smith (kevsmith) – Erlang
Dave Fayram (kirindave) – Erlang
Edward Kmett (kmett) – Haskell
Kevin Scaldeferri (kscaldef) – Erlang
Matthew Podwysocki (mattpodwysocki) – F#, Haskell
Mark Reid (mdreid) – Haskell
MickaÃ«l RÃ©mond (mickael) – Erlang
Andy Adams-Moran (morabbin) – Haskell
Neil Bartlett (njbartlett) – Haskell
Nick Gerakines (ngerakines) – Erlang
Paul Brown (paulrbrown) – Haskell
Paul Snively (psnively) – OCaml
Rusty Klophaus (rklophaus) – Erlang
Robey Pointer (robey) – Scala
Shae Erisson (shapr) – Haskell
Sigbjorn Finne (sigbjorn_finne) – Haskell
Dan Piponi (sigfpe) – Haskell
Spencer Janssen (spencerjanssen) – Haskell
Steve Jenson (jenson) – Scala

Isaac Jones (SyntaxPolice) – Haskell
Manuel Chakravarty (TacticalGrace) – Haskell
Tom Moertel (tmoertel) – Haskell
Thomas Sutton (thsutton) – Haskell
Joel Reymont (wagerlabs) – Erlang
Creighton Hogg (wchogg) – Haskell
Joe Williams (williamsjoe) – Erlang
Yariv Sadan (yarivs) – Erlang

Fedora 7 on a Thinkpad X60: not so hot

Bryan O'Sullivan — Thu, 21 Jun 2007 06:54:07 +0000

I’ve been running test releases of Fedora 7, and lately the final release, for a number of months on my fairly new Lenovo Thinkpad X60. Here’s a brief summary of my experiences.

I’ve been using Fedora since 0.92 (Taroon), and while I’ve generally been happy with it, F7 is not exactly a model of stability or sleekness. Here’s a list of problems I’ve run into. My biggest problems so far have been with suspend and resume, and network drivers.

Suspend to RAM doesn’t work by default; when I resume, the screen is blank, and can’t be coaxed back to life save through a reboot. This is bug 243759. I came up with a fix (for my hardware, at least) in bug 237849. Richard Hughes’s fabulous HAL quirk site was the key to figuring out that one; thanks, Richard!

Suspend to disk (aka “hibernate”) works, some of the time. But it interacts poorly with the crummy quality of the current e1000 ethernet driver.

The e1000 driver is flaky in F7. If I boot with a live ethernet cable plugged in, it works. But if I plug one in after booting, it fails to detect the carrier signal, and simply never notices the cable. Bug 236956.

There is a workaround, of sorts. If I manually rmmod, then modprobe the driver again, it will detect the carrier signal. Unfortunately, after I do this, the next time that I try to suspend to disk, all of my network-related processes get stuck in an unkillable state, and suspend throws in the towel. Bug 245107.

If I try to use the screen backlight brightness control buttons, the screen goes black instead. Bug 220466.

If I disable the internal modem in the BIOS, sound no longer works. Bug 205603.

The new iwl3945 wireless driver simply falls over after a while, depending on the network configuration it’s talking to. Bug 240826.

By the way, I’m not claiming that these problems are in any way the fault of Dave Jones, Chuck Ebbert, the HAL guys, or other Fedora maintainers. They have a thankless job trying to clean up the endless flood of new bugs in upstream kernels, not to mention cascades of junk hardware and buggy BIOSes from vendors. I’m frankly relieved every time the kernel boots reliably at all.

On top of these stability and reliability problems, performance has taken a bit of a beating. F7 seems to take quite a bit longer than earlier releases to boot, something Dave Jones has quantified. The post-boot bloat also rises: there are more kernel threads and userspace daemons running than ever before.

On the positive side, 3D graphics works quite well. I can actually run OpenGL apps like Google Earth and Second Life without crashes, and get decent frame rates out of them. And of course I can turn on wobbly windows and induce vertigo and nausea within minutes, where previously I had to resort to using Windows to get that sensation.

A quick programmer’s look at NVIDIA’s CUDA

Bryan O'Sullivan — Thu, 22 Feb 2007 08:06:31 +0000

I spent a while this evening reading through the documentation for the beta release of NVIDIA’s CUDA GPGPU system. My motivation for this was that nvcc, the CUDA compiler, is based on a code drop of the EkoPath compiler, which I’ve worked on intermittently over the past few years.

The programming model that these GPUs enforce is incredibly complex. It’s more than a little reminiscent of the Connection Machine (for a blast from the past, see a collection of scanned CM-5 documentation.

The idea is that the GPU executes a “kernel” of compute-intensive, highly parallelisable, code on behalf of the CPU. Data is transferred to the GPU when a kernel starts to execute, and back to the host when it completes. The GPU may execute multiple kernels simultaneously, if it is capable of it.

A kernel is executed as a collection of threads, with threads organised into “blocks”. The blocks are further organised into “grids”. Each thread has thread-local storage, and a block of threads shares a chunk read-write memory. This is how they communicate and synchronise with each other. Threads can also access the GPU’s global memory, although blocks of threads cannot synchronise with each other via global memory.

Global memory has a pile of constraints. There’s not one single kind of global memory; instead, there are three. Unlike the thread-local and block-shared memories, global memories can be accessed by the host (although accesses are expensive).

Plain old read-write memory. Accesses to this memory are not cached. When a thread block is scheduled to execute, and accesses global memory, its performance is heavily penalised if threads don’t access global memory in a suitable pattern (see section 6.1.2.1 of the Programming Guide).
“Constant” memory is read-only, and reads are cached. Again, there are restrictions on access patterns to constant memory that affect performance.
“Texture” memory is also read-only, and cached. Cached texture data is laid out to give best performance for 2D access patterns.

Block-shared memory isn’t immune to peculiar performance constraints, either. It’s organised into “banks”, to allow parallel access to multiple banks in a single operation. In other words, n threads can access n banks in one cycle. However, concurrent accesses to a single bank are forcibly serialised, so n threads hitting a single bank will take n cycles.

So at every level of the GPU memory hierarchy, there are multiple factors that you have to keep in mind if you want to achieve good performance.

The extensions that NVIDIA has made to the C language are fairly minimal. There are some new keywords to control layout of data, to determine where variables should live in the memory hierarchy. Not surprisingly, there are new vector types that look very much like OpenGL vector types.

A few similar keywords control function layout. Functions can be marked as device accessible only, resident on the device but called from the host (i.e. a kernel), or host-only. A weird piece of syntax `<<< Dg, Db, Ns >>>’ is required when calling a kernel, to control the execution parameters for the kernel: grid size, block size (and number of threads), and memory allocation.

With hardware of this complexity, a good optimising compiler can make a substantial difference to application performance. The heritage of NVCC is unimpeachable. It’s based on the EkoPath compiler, which has been the most frequent compiler used for SPEC benchmark submissions by AMD64 hardware vendors for several years. The EkoPath compiler was in turn based on Open64, a compiler that SGI GPLed when it dropped out of the compiler business.

Among the memory hierarchy related optimisations in the Open64 compiler family that are available to NVCC are the following (this is just a short list of highlights; the real number is big). I don’t know how many of these are enabled in NVCC, nor do I know enough about individual cache sizes or miss penalties to have a clue as to which ones are likely to be effective.

Loop nest optimisation. For a set of nested loops, this can change the order in which the inner and outer loops are executed, to improve the pattern of access to memory.
Vectorised intrinsics. If application code is, for example, computing sin(x[i]) for all i in a vector, the compiler can replace this with a single call to a highly optimised sin specialised for vectors.
Cache blocking. Replace a single loop over a large vector with smaller loops that operate on cache-sized chunks of the vector.

Given the degree of manual control over variable placement that NVIDIA’s C extensions seem to enforce, it’s not clear to me that their compiler team has had a chance to automate any of the transfer of data between levels of the memory hierarchy yet.

I also find it telling that the programmer’s guide includes specific guidelines on how to avoid bank conflicts in block-shared memory, where in at least some of these cases it’s clear that the compiler could be automating the job.

It’s worth reading the programmer’s guide in its entirety to get a sense of just how complex CUDA is, and how many different constraints the determined application programmer will have to keep in mind at a time. There’s not a lot of abstraction going on here (vendor-provided BLAS and FFT libraries notwithstanding).

We have plenty of previous examples of hardware that failed to live up to their early marketing promise, from the i860 to the PS3. CUDA looks set to follow in their footsteps: I expect that it will take vast amounts of work for programmers to get halfway decent performance out of a CUDA application, and that few will achieve more than 10% of theoretical peak performance.

People with the expertise, persistence, and bloody-mindedness to keep slogging away will undoubtedly see phenomenal speedups for some application kernels. I’m sure that the DOE and NSA, in particular, are drooling over this stuff, as are the quants on Wall Street. But those groups have a tolerance for pain that is fairly unique. This technology is a long way from anything like true accessibility, even to those already versed with parallel programming using environments like MPI or OpenMP. Still, it’s a great first step.

“Now, imagine a Beowulf cluster of these!”

Sony Ericsson Z520a phone review

Bryan O'Sullivan — Fri, 22 Dec 2006 20:05:25 +0000

I’ve had a Sony Ericsson Z520a phone for a little under a year now, and as it’s still widely available through cellular carriers, I thought I’d write up my experiences with it. I’m writing in part as a reaction to the weakness of phone review web sites, which tend to publish reviews from people who’ve had their phones for somewhere between an hour and a month. The reviews thus rarely shed any light on the medium- to long-term issues of using the phones they cover, instead clustering around the same few obviously good or bad points that immediately come to light. Case in point: CNET’s review of the Z520a, which cites the crummy picture quality, but doesn’t note much else, and gives the phone a “very good” rating. First, a few positive observations. Call quality is generally decent, and I’ve had fewer problems with dropout than with my previous phone. Battery life is impressive, at about five days, and it hasn’t diminished noticeably over the year I’ve been using the phone. The phone’s user interface is only indifferently responsive. It takes a perceptible fraction of a second to respond to keypresses. The lag isn’t enough to be a serious problem; it’s more of a peeve. The Z520a is a clamshell phone, and it’s surprisingly difficult to open with one hand. This is due to two design flaws. The grooves in the fold of the phone are small enough to require both precision and force to insert the inside of a thumb to start the opening process. Once you’ve cracked the shell open, the mechanism is unsprung, and requires constant application of force to open it fully. This makes the phones much more difficult to open than similar models from other manufacturers, such as Motorola. What drives me absolutely crazy, though, are the side operation buttons. Thanks to Sony Ericsson’s fine design, I take upwards of half a dozen photos of the inside of my pocket every day. As if that weren’t insult enough, the volume control rocker button can’t take the abuse of sitting in a pocket, and my “increase volume” button no longer works at all. I somehow managed to avoid fat-fingering the “decrease volume” side of the rocker for about a month after this happened, but the inevitable eventually occurred, and my phone is now stuck permanently at minimum talk volume. And the only way I can even monkey with the volume is to use those buttons during a call (they do nothing useful when the phone is in standby mode); there’s no redundancy in the design, and I have to use up my miserly supply of minutes to even try. I also have some sour words for AT&T’s mangling of the user interface. At every level of menu hierarchy, the first option I’m presented with is to visit AT&T’s mobile web site to buy ringtones, pictures (who the hell buys pictures from their cellular provider?), and other stuff I don’t want. And accidentally fat-fingering such a menu item means that I’m paying for the data transfer involved. Bah. Really, though, all other opinions I have of the phone are overshadowed by its fragility, the result of which is that I can no longer hear anything during a call unless I’m in an empty, silent room. If it weren’t for the side controls, I’d actually call it a reasonably decent phone, but it snatches defeat from the jaws of victory to get a default score of “crap” instead.

Refilling a missed TLB entry, now with special sauce

Bryan O'Sullivan — Fri, 22 Dec 2006 17:53:45 +0000

Jeremy and Muli remind me that x86-class CPUs refill a missed TLB entry in hardware. That’s what I get for rambling at midnight! On these CPUs, the hardware walks the page tables directly when a miss occurs. The operating system still gets involved during context switches, to keep the page tables and TLB consistent; and it also shoots down individual TLB entries when messing with memory mappings. In my puny and lame defence, most RISC CPUs (you know, the ones that nobody uses any more) trap to the operating system when a TLB miss occurs, and do the refilling in software. (A few, like SPARC, have an auxiliary cache that’s bigger than the TLB, to speed up software reloads.) Jeremy also asked if a TLB lookup and L1 cache lookup can happen in parallel. As he points out, they can’t if the L1 cache contains physical addresses (which is called physical indexing). L1 caches that are virtually indexed do show up, though, because they allow the TLB lookup to occur in parallel with the L1 cache lookup. The machinery is more complicated due to the need to account for a single physical address having multiple virtual addresses mapping to it. As far as I know, only the HP PA and AMD Athlon, both of which are defunct, have virtually indexed caches.

The translation lookaside buffer

Bryan O'Sullivan — Fri, 22 Dec 2006 06:43:22 +0000

In an earlier post, I briefly discussed the oprofile system profiler. I was going somewhere with that; here’s another step along the path. Modern CPUs that use virtual memory have to be able to turn virtual addresses into physical addresses efficiently. While a userspace process operates on virtual addresses, accessing any part of the memory hierarchy requires physical addresses. This means that when your CPU goes to touch even the first-level (L1) cache, it must do this virtual-to-physical translation. The CPU does this efficiently using a tiny cache called the translation lookaside buffer, or TLB. Each entry in the TLB maps a virtual page to a physical page, where a page is a range of consecutive addresses. A typical TLB has between 32 and 2048 entries, and a CPU will have a hierarchy of TLBs to go along with its hierarchy of caches. For example, an AMD Opteron has a 32-entry first-level TLB, and a 512-entry second-level TLB. (In fact, it has separate TLBs for handling instruction and data addresses; these are called the iTLB and dTLB.) The number of pages that a TLB can translate at once is called its range. With a 4KB page size and 512 entries, a TLB has a range of 2MB. The 2MB doesn’t have to be contiguous; I just mean that such a TLB can translate 2MB of virtual addresses to physical addresses at one time. If the CPU needs to translate a virtual address that is not currently covered by a TLB entry, this is called a TLB miss. (If there is an entry in the TLB, a successful lookup is called a hit.) Because TLB lookup time is critical to the performance of the CPU, the normal case (of lookups resulting in hits) is handled entirely in hardware. In fact, a TLB lookup is performed in parallel with an L1 cache lookup, so that both can be done in a single cycle. But when a TLB miss occurs, the hardware throws up its hands and causes a trap. This suspends normal execution of the CPU so that the operating system can load a new value into the TLB entry where the miss occurred. The component of the kernel that handles this step is called the TLB miss handler, and it’s critical to performance, too. Since PC-class systems running Linux always use a 4KB page size, the reach of the TLB is tiny compared to the size of physical memory. For example, my desktop system has 2GB of RAM, and 1024 TLB entries; this gives its TLB a reach of only 4MB, or 0.2% of RAM. I’ll return to the subjects of TLB size, page size, and oprofile soon.

Make Linux happy with a modern laptop’s CD/DVD drive

Bryan O'Sullivan — Wed, 13 Dec 2006 00:39:37 +0000

If you’re using a fairly modern laptop with an Intel chipset, the chances are that it has an Intel ICH7 I/O controller hub:

$ lspci | grep -i ide

00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial ATA Storage Controller IDE (rev 01)

This usually means that your internal hard disk and CD-ROM/DVD drive (if you have one) are wired using Serial ATA (SATA), not the obsolete Parallel ATA standard. However, while the Linux SATA driver will happily take control of your hard disk, for some reason the older IDE driver will often capture the CD-ROM drive. You can tell by looking at /dev/cdrom:

$ ls -l /dev/cdrom

lrwxrwxrwx 1 root root 4 Dec 12 13:23 /dev/cdrom -> hdc

If the text after the “->” arrow starts with “hd” as above, the IDE controller owns your CD-ROM/DVD drive. Everything might initially look okay, because the CD-ROM/DVD drive will appear to work normally, but performance will turn out to be awful: try to play a CD or DVD, and you’ll see your notionally speedy laptop crawl nearly to a halt. If you’ve used Linux on previous generations of laptops, you’ll know enough to check the output of the hdparm command, to see if the kernel has DMA enabled on the CD-ROM/DVD drive. It will say no, whereupon you might try to force the kernel to use DMA, and be stumped when it refuses. The reason this doesn’t work is that the ICH7 hub is emulating an IDE device, and the Linux IDE driver doesn’t know how to configure it to use DMA. Never fear; you don’t need to do this at all. Instead, configure your kernel to use the newer libata driver to control the CD-ROM/DVD drive. To do this, you’ll need to modify the kernel’s boot command line. On Fedora systems, edit /etc/grub.conf (this file will have a different name under other Linux distros), and look for the first line that starts with bit of white space, followed by the word “kernel“. Append the following string to it: “combined_mode=libata“. That line of your grub config file will now look more like this (for god’s sake, don’t make a literal copy of my kernel command line; it won’t work for you!):

kernel /vmlinuz-2.6.18-1.2849.fc6 ro root=LABEL=/ rhgb quiet combined_mode=libata

Reboot your laptop, and you should find that /dev/cdrom no longer points at something starting with “hd“:

$ ls -l /dev/cdrom

lrwxrwxrwx 1 root root 4 Dec 12 16:10 /dev/cdrom -> scd0

The “scd0” string means that libata is now managing the CD-ROM/DVD drive. You should now get great performance for CD and DVD playing, without it dragging down the interactive performance of your laptop.

Linux on the Dell XPS M1210

Bryan O'Sullivan — Thu, 19 Oct 2006 02:43:42 +0000

Since 2003, I’d been using a Thinkpad X31 for much of my work; it was the best laptop I’d ever owned, and was really the only one I used heavily over a long period of time. It had an irresistible combination of small size, light weight, good performance (for its time), and excellent support from Linux. A few months ago, I dropped my formerly dependable workhorse on its head. It didn’t quite die, but it became increasingly erratic. It was clear that I’d jarred loose some power-related connection, because it would rarely survive a suspend-to-RAM long enough to actually resume. The last straw came when it ploughed an unexpected furrow in its root filesystem. Since I use distributed development tools, I lost maybe an hour of work in total, but I was now nervous. I couldn’t rely on it any longer. Since my employers recently got bought out, and our new corporate IT standards almost mandate the purchase of Dell hardware, I looked through Dell’s laptop line for a suitable replacement. In my ideal world, I’d have preferred a Thinkpad X60 to any Dell, but I wasn’t inclined to try to wrestle with the purchasing policies of an unfamiliar IT department so soon after a buyout. I wanted an ultraportable (i.e. small and light) dual-core system, but the closest approximation in Dell’s current product lineup is the XPS M1210. It’s too big and heavy to fit in the ultraportable category, but at 2kg (4.4lb), it will do fine. The system I ended up getting came packed with a surprise or two. It was outfitted with a GeForce Go 7400 GPU, which I had asked not to get. I had been hoping to use as many completely open device drivers as possible (the Linux drivers that NVIDIA provides are very fast, but proprietary), and I figured that the Intel 915 integrated graphics that were my other option would surely have better heat and power consumption characteristics. In spite of this preference, once the system arrived with the unexpected â€œbonus GPUâ€, I felt disinclined to kibitz with my IT department or Dell and go without a reliable laptop for an additional few weeks. I initially installed Fedora Core 5 on the laptop, as I’ve used Fedora for a long time, and like it. Although the install went without a hitch, I found that I could not suspend to memory or disk. Otherwise, the machine seemed to work well. The Intel 3945 driver worked without a problem, although it has a clumsy installation mechanism and nobody has volunteered to package it for the livna package repository yet. Indeed, the 3945 seems to have several better characteristics than the Atheros wifi hardware I’d used in the X31 (and which is still used in more recent Thinkpad laptops). With the 3945, I can associate quickly and reliably to every wireless network I’ve tried, using NetworkManager. The Atheros chip wouldn’t talk to encrypted wifi networks at all. Also, NetworkManager-on-Atheros took about 40 seconds to associate to unencrypted networks, and would drop an association every so often for no apparent reason. Ugh. Finally, the 3945 reports sane signal strengths, while Atheros seems to be measuring some other strange characteristic of a signal that never goes above 50%, even if you’re sitting two feet from an access point. From the perspective of wanting open drivers, neither wireless chipset is ideal. Much of the madwifi driver is proprietary, even though it lives in the kernel, while the 3945 requires both a binary firmware blob and a proprietary userspace daemon that enforces airwave regulation compliance. Out of curiosity, I installed the proprietary NVIDIA drivers, and whatever power and thermal management they perform improved my battery life from about five hours to over six. This impressed me. Unfortunately, there was little I could do about the lack of suspend support in FC5. At least part of the problem is that stock kernels don’t power-manage the Intel SATA controller, so it is guaranteed to die during suspend or resume. Just as I was rolling up my sleeves to install a custom patched kernel and debug it, I noticed that recent Fedora rawhide (testing) kernels incorporate exactly the patch I needed. I upgraded to Fedora Core 6 test 1 without a hitch, using yum; installed a rawhide kernel; rebooted; and I could suspend, both to RAM and to disk! And all without having to do any â€œreal workâ€. The only downside to the upgrade has been that NVIDIA hasn’t updated its proprietary drivers to handle the newest X.org ABI or kernel build infrastructure, so they don’t work with fc6t1; another good reason to prefer not to use proprietary drivers. For now, at least, I’m back to running the open nv driver for graphics. I can’t discern a speed difference for the kind of stuff I do (lots of terminals, Emacs, and Firefox), and it’s nice to be running with a free driver, but I miss that extra 20% of battery life. Anyway, after all that blather, what are the actual specs of the machine?

2.16GHz Intel Core Duo CPU
2GB RAM
120GB SATA hard disk
GeForce 7400 Go GPU
1280×800 gloss-finish display
Intel HG audio chipset
Synaptics touchpad
Intel 3945 A/B/G wireless mini-PCIE card
CD-RW/DVD-ROM
1 Firewire port, Ricoh chipset
4 USB 2.0 ports
Built-in Bluetooth
xD card interface (Ricoh again), hidden under the DVD drive
Broadcom 100Mbit Ethernet chip (Linux b44 driver)

I was surprised that such an otherwise high-spec machine wouldn’t have gigabit Ethernet support. As a practical matter, this doesn’t really affect me; I mostly use the wireless connection anyway (perhaps that’s what Dell was counting on). As far as I can tell, all of the hardware works well under Fedora. For example, even the non-X.org Synaptics touchpad driver was configured automatically during the install, and works perfectly. There’s often a considerable lag between a laptop appearing and its congeries of hardware actually working under Linux. Since the M1210 is such a new-to-the-market system, I was astounded that all I needed was a recent stock userspace and kernel, and the ipw3945 driver from sourceforget, to get everything that I care about to work well enough for heavy daily abuse. I have a few physical quibbles with the machine. I have to hit the keys quite hard, or they tend to bounce and give repeats (e.g. I type â€œhâ€ and get â€œhhâ€). The display is crisp, uniformly bright, has vibrant colours, and is a pleasure to work with. I don’t like the glossy finish, though; it reflects too much, particularly if I’m running on batteries and have the screen brightness turned down a bit. If corporate purchasing policies were a non-issue, I’d probably still prefer a Thinkpad X60 due to its comparable specs and lighter weight, but I am surprised and very pleased by how well the Dell XPS M1210 is working for me. It’s exceptionally fast, and has been rock solid so far.

The $10,000 laptop … almost

Bryan O'Sullivan — Thu, 07 Sep 2006 14:59:55 +0000

I read in Bill Bumgarner’s blog that Dell has released a new model in its XPS line, the M2010. It’s not somethhing one could plausibly refer to as a laptop, due to its weight of 18.3lbs (8.3kg!) and 20“ screen.

Being a curious sort, and owning the M2010′s tiny cousin, the M1210 (the weight of which is a feathery 23% that of the M2010), I visited Dell’s web site to try to configure a system and see what it would cost.

Holy flaming battery packs; that is one expensive toy. I failed in my attempt to configure it to a price of $10,000, but I got astoundingly close, at $9,564.

That is simply obscene.

Hitachi redux

Bryan O'Sullivan — Tue, 22 Feb 2005 12:45:01 +0000

I should have known better, but when I was incarnating the current noisy boat anchor that sits on my desk at home, I put a Hitachi hard disk in it. Not specifically one of the notorious IBM-era eat-your-data models, but something much more recent.

It made it to about six months of age before developing a perforated filesystem ulcer and bleeding out at about 4am on Saturday morning. I didn’t even notice until Sunday night, whereupon I booted into a rescue environment and attempted a fsck. The fsck yielded many, many short reads, which I interpret as the hard disk telling me “I’ve run out of bad blocks to silently remap, so now I’m going to cack on your data in a way you can’t ignore“. My root filesystem was almost completely trashed, leaving almost 4,000 entries in lost+found.

Through sheer luck, one of the only directories to survive the experience was the only one that would have been a pain to replace. It got moved to lost+found, but I was able to recognise it by its contents almost immediately.

So it’s off to Fry’s tomorrow, to buy a new SATA hard disk, one specifically not touched by the evil of Hitachi Global Storage Destruction Technologies. I’ve been wanting to wean myself off PATA for a while (my motherboard goes gimpy if I run the PATA drive with DMA turned on after a cold boot), so now I have an excuse, albeit more catastrophic than I wanted.