A little while ago, someone on Slashdot pointed me at the Sale of Goods Act in relation to purchased electronics. The act, for those unfamiliar with it, requires that goods be 'suitable for the purpose for which sold.' This is a fairly broad term, but it basically means that they must be able to do anything that the seller claims that they can do. Under this law, you have 6 years from the date of purchase to file a lawsuit if the item does not match the claims.
This was relevant to me because my MacBook Pro is now out of warranty and the battery is dying. Looking in the System Profiler, its full charge capacity was showing up as 1476mAh after 56 charges. When new, it was 5500mAh. These numbers don't mean anything by themselves, but Apple claims that their batteries retain 80% of their full charge capacity after 300 charge cycles. Claiming this means that a battery that does not retain 4400mAh after 300 charge cycles is not suitable for the purpose for which sold, and they are legally required to refund or replace it (irrespective of the time that has elapsed, although I can only sue them if they don't within 6 years of the time of sale).
I called their support line and was put through to an Indian woman, who explained that the warranty had expired. I quoted the relevant parts of law to her, and (after being kept on hold for a bit), was transferred to someone senior. He very quickly agreed to send out a replacement battery.
Interestingly, he did not ask that the original battery be sent out, nor that I provide a credit card number where I would be billed if the battery turned out not to be defective. I've had two batteries replaced in warranty, and this was standard procedure then, so apparently I get better service out of warranty. I don't have a great deal of use for a battery that only lasts about 35 minutes on a full charge, but I'll probably keep it as a spare.
As always, it pays to know the law. It's a shame that Apple, which claims to be a customer-focussed company, doesn't educate its support team about this though. Possibly the Indian call centre deals with people from everywhere English speaking, while the Irish one only deals with people in the UK and Ireland, so the people there are more familiar with British law, but if I had not quoted the relevant act then I would have been charged £99 for a battery, on top of the £1.50 it cost to call their support line for half an hour.
It's what we were all hoping for, and I'm pleased that it's come to pass. It's not perfect, and I don't agree with all of their decisions. However, even an imperfect alternative to the current H.264 situation is a massive improvement. I'm pleased they've gone for a full stack solution of not only VP8 but also Matroska(-ish) and Vorbis, too. If nothing else, it's likely to mean that a) Vorbis will be shipped by default on most platforms[1], and b) hardware support for both VP8 and Vorbis should be widespread in the very near future. Further, there's a commitment to transcode all of the existing videos on YouTube. That's a massive endorsement. Of course, the risk with that is the reduced quality that will come from three or more lossy transforms, but given that they've announced it, they're clearly not too concerned about that. The future's looking very bright indeed.
[1] Or will it? I've yet to see any official response from Microsoft or Apple on this. But it's going to be hard for them to ship something that won't play YouTube videos by default. Of course, in the short and probably medium term, YouTube will continue to offer videos in other formats as well. But we'll see how it plays out in the long term.
Also interesting to see the stats on when their systems were delivered to McLaren and Brawn, and where the performance of those cars was afterwards. I know there's more to F1 than CFD, but it certainly plays a large part these days.
Some time around 2005, Slashdot ran an article about a new hosting company, MacMiniColo that was taking advantage of the new machines that Apple had just released to offer cheap hosting. I got in contact with them, and a little while later, I had a Mac Mini, sitting in a rack somewhere, running OpenBSD and acting as my dedicated server. A 1.42GHz G4 CPU, 512MB of RAM, and an 80GB disk was (and still is) more than adequate for my needs. The biggest load on it is eJabberd, and even that only used under 1% of the CPU.
I had really great service from these people. The hard drive failed a little under a year after I bought the Mini, and Apple refused to honour the warranty because they couldn't find the records of the sale (then, a few weeks later, they could, but by then it was out of the warranty period). MacMiniColo replaced the disk for me at their own expense.
After five years with them, however, I had a little look around and noticed that VPS hosting has gone down in price a lot. I've written a book on Xen, so I thought I might try a Xen-based VPS now that FreeBSD has Xen support.
GigaTux only claims to offer Linux, but I dropped them an email and they were happy to install FreeBSD for me. I still haven't tried the Xen-enabled kernel yet; they installed the stock x86-64 kernel in an HVM domain for me and performance has been fantastic.
I'm sharing a server with 64 other guests and in spite of that performance tends to be better than my ageing Mac Mini. I was getting 1000IOPS while untaring the ports tree, which is far more than the Mini's old 2.5" laptop drive could handle, and is amazing considering that it's going via the slow, QEMU-derived, emulated device, rather than the fast PV driver. I've been installing software from ports, so everything is compiled on the machine, and even that has been fast.
And my Mini? They found someone else who wants it, and offered me about a third of what I paid for it originally - not bad depreciation after five years of constant use. Shipping it back to the UK would have cost almost as much as buying one on eBay, so I sold it on. Hopefully someone else will get some good use out of it.
As an aside, I've been really impressed by how well OpenBSD works on Mac/PowerPC hardware. If you've got an old Mac Mini lying around, chuck OpenBSD on it and you've got a reasonable low-volume server. The newer ones, of course, are x86 hardware, so will run just about anything.
There are two reasons why I don't use GNU/Linux: One is GNU, the other is Linux. Of these, the larger reason is GNU, and specifically the glibc part. The most recent reinforcement of this is Ulrich Drepper's inability to read the C specification.
For those not familiar with the C specification, all identifiers that start with an underscore are reserved for the implementation (see section 17.4.3.1.2). You should never use them in your own code, because your compiler is completely free to do whatever it wants with them. By convention, single underscores are used for global non-standard libc extensions and double underscores are used for compiler builtins.
You can find a number of these in existing compiler. Microsoft exposes SEH with keywords like __try. GCC provides __asm for inline assembly, ICC uses __cpuid for accessing the CPUID instruction, and so on. Clang added __block as a type specifier for their variables that are copied to the heap for use by blocks (closures).
Unfortunately, it turns out that the glibc headers use __block as a parameter name. There are several things wrong with this. One is that they use double underscores at all. By convention, these are reserved for the compiler, while single underscores are reserved for the libc. The second is that they used underscores at all in a parameter. Parameter names are not in the global scope, so they can be anything to prevent name clashes.
The result of this is that, if you use glibc, you can't also use blocks. This is a shame, because we (Etoile) were shipping a working blocks implementation six months before Apple. Well, working on *BSD and Solaris (and probably Windows, QNX and Symbian with PIPS, but not tested there). This problem means that it doesn't work on GNU/Linux.
No problem for me. I only use platforms with libc implementations written by people who can read specs. It may be a problem for some of you, if you use a broken platform with a libc maintained by someone who'd rather salvage his ego than fix a problem, and if it is then I'm sorry for you. My suggestion is that you remember that there are other options.
building file list
... done
rsync: delete_file: unlink "/backup/local/shared/camera/2009-08-24--foq/img_0507.jpg" failed: Read-only file system (30)
rsync: delete_file: unlink "/backup/local/shared/camera/2009-08-24--foq/.xvpics/img_0507.jpg" failed: Read-only file system (30)
That's never a good sign. Looking through the logs, I see a number of ATA errors, starting with a timeout, a device error, and a bunch of HSM violations. A few examples:
Mar 22 07:56:03 riva kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Mar 22 07:56:03 riva kernel: ata2.00: cmd 25/00:00:87:d1:86/00:02:03:00:00/e0 tag 0 dma 262144 in
Mar 22 07:56:03 riva kernel: res 40/00:00:00:00:00/ff:ff:ff:ff:ff/00 Emask 0x4 (timeout)
Mar 22 07:56:03 riva kernel: ata2.00: status: { DRDY }
Mar 22 07:56:03 riva kernel: ata2: hard resetting link
Mar 22 07:56:03 riva kernel: ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
Mar 22 07:56:03 riva kernel: ata2.00: configured for UDMA/33
Mar 22 07:56:03 riva kernel: ata2: EH complete
Mar 22 07:56:03 riva kernel: SCSI device sdb: 1465149168 512-byte hdwr sectors (750156 MB)
Mar 22 07:56:03 riva kernel: sdb: Write Protect is off
Mar 22 07:56:03 riva kernel: SCSI device sdb: drive cache: write back
Mar 22 07:59:05 riva kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Mar 22 07:59:05 riva kernel: ata2.00: BMDMA2 stat 0x6d0009
Mar 22 07:59:05 riva kernel: ata2.00: cmd 25/00:00:df:ce:87/00:02:03:00:00/e0 tag 0 dma 262144 in
Mar 22 07:59:05 riva kernel: res 51/04:80:5f:cf:87/00:01:03:00:00/e0 Emask 0x1 (device error)
Mar 22 07:59:05 riva kernel: ata2.00: status: { DRDY ERR }
Mar 22 07:59:05 riva kernel: ata2.00: error: { ABRT }
Mar 22 07:59:05 riva kernel: ata2.00: configured for UDMA/33
Mar 22 07:59:05 riva kernel: ata2: EH complete
Mar 22 07:59:05 riva kernel: SCSI device sdb: 1465149168 512-byte hdwr sectors (750156 MB)
Mar 22 07:59:05 riva kernel: sdb: Write Protect is off
Mar 22 07:59:05 riva kernel: SCSI device sdb: drive cache: write back
Mar 22 08:01:15 riva kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Mar 22 08:01:15 riva kernel: ata2.00: cmd 25/00:00:ff:1e:88/00:02:03:00:00/e0 tag 0 dma 262144 in
Mar 22 08:01:15 riva kernel: res ff/ff:ff:ff:ff:ff/ff:ff:ff:ff:ff/ff Emask 0x2 (HSM violation)
Mar 22 08:01:15 riva kernel: ata2.00: status: { Busy }
Mar 22 08:01:15 riva kernel: ata2.00: error: { ICRC UNC IDNF ABRT }
Mar 22 08:01:15 riva kernel: ata2: hard resetting link
Mar 22 08:01:15 riva kernel: ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
Mar 22 08:01:15 riva kernel: ata2.00: configured for UDMA/33
Mar 22 08:01:15 riva kernel: ata2: EH complete
Mar 22 08:01:15 riva kernel: SCSI device sdb: 1465149168 512-byte hdwr sectors (750156 MB)
Mar 22 08:01:15 riva kernel: sdb: Write Protect is off
Mar 22 08:01:15 riva kernel: SCSI device sdb: drive cache: write back
SMART doesn't seem to be much help here, with the device refusing to run anything but the mandatory offline test:
riva:~# smartctl --test=offline
/dev/sdb
smartctl version 5.36 [i686-redhat-linux-gnu] Copyright (C) 2002-6 Bruce Allen
Home page is http://smartmontools.sourceforge.net/
Default Self Test Successful
riva:~# smartctl --test=short/dev/sdb
smartctl version 5.36 [i686-redhat-linux-gnu] Copyright (C) 2002-6 Bruce Allen
Home page is http://smartmontools.sourceforge.net/
Short offline self test failed [unsupported field in scsi command]
riva:~# smartctl --test=long/dev/sdb
smartctl version 5.36 [i686-redhat-linux-gnu] Copyright (C) 2002-6 Bruce Allen
Home page is http://smartmontools.sourceforge.net/
Long (extended) offline self test failed [unsupported field in scsi command]
It's a Seagate drive:
Host: scsi1 Channel: 00 Id: 00 Lun: 00
Vendor: ATA Model: ST3750528AS Rev: CC38
Type: Direct-Access ANSI SCSI revision: 05
I'm running 2.6.18-128.4.1.el5 on CentOS 5.
Any ideas? Does anyone know enough about the ATA spec to tell me what these errors actually mean? Is this a genuine hardware failure? If so, where's it likely to be? Drive? Controller? Cable? The drive is only a few weeks old, so while sometimes shit happens, I want to investigate the (probably more likely) alternatives as well.
And why oh why doesn't <tbody> nest? I want to refer to part of a table and manipulate it with some Javascript (mostly just to show or hide it in response to user actions). But I can't just stick the relevant bits in a <tbody> and select by that because the table already contains several tbodies. Thus I'm once again stuck in workaround hell, trying to tag each tbody with an appropriate class, so I can iterate over them and check if I'm interested in each one. Further, because I'm dynamically adding and removing parts of the table, I need to check at the time I add to the table whether the bit I'm adding should be visible or not. Life would be so much easier if I could just stick it in an appropriate <tbody> further up the hierarchy, and then mark the whole lot visible or otherwise. But I guess that would be far too easy
Any CPU will be more than sufficient for my needs. The screen needs to be at least 17", and not gloss (which sadly seems to rule out the otherwise promising models from Samsung). I need 2GB RAM, and I don't want to be paying more than £500. A bit of digging reveals that all of the major players have models that meet those requirements. But I still have the nagging feeling that I'm missing out of the "right" model simply because I don't know about it. Where should I be looking?
Oh, and it won't have an Apple badge, so don't even consider suggesting that...
[1] And 512Kb/s up, FWIW. The A in ADSL usually means you get much better bandwidth down than up. Not so here, it seems...
With your bare hands?!?