This very funny ad skewering the Macbook Air actually made me want to buy the Lenovo product — until I saw the price tag.
(via Ed Bott)
Looks like I'll be waiting for that Atom-powered Asus eee after all.
This very funny ad skewering the Macbook Air actually made me want to buy the Lenovo product — until I saw the price tag.
(via Ed Bott)
Looks like I'll be waiting for that Atom-powered Asus eee after all.
Is this the future of car doors? Looks good to me:
It seems that ordinary Western Digital (WD) hard drives have an “advanced” feature that makes them unsuitable for either hardware or software RAID. Since I like to mirror the family's hard drives for security in the event of hard drive failure — we had one fail on my wife's machine last week so this is hardly paranoia — this is something I am glad I found before placing an order.
Western Digital manufactures desktop edition hard drives and RAID Edition hard drives. Each type of hard drive is designed to work specifically in either a desktop computer environment or on RAID controller.
If you install and use a desktop edition hard drive connected to a RAID controller, the drive may not work correctly unless jointly qualified by an enterprise OEM. This is caused by the normal error recovery procedure that a desktop edition hard drive uses.
When an error is found on a desktop edition hard drive, the drive will enter into a deep recovery cycle to attempt to repair the error, recover the data from the problematic area, and then reallocate a dedicated area to replace the problematic area. This process can take up to 2 minutes depending on the severity of the issue. Most RAID controllers allow a very short amount of time for a hard drive to recover from an error. If a hard drive takes too long to complete this process, the drive will be dropped from the RAID array. Most RAID controllers allow from 7 to 15 seconds for error recovery before dropping a hard drive from an array. Western Digital does not recommend installing desktop edition hard drives in an enterprise environment (on a RAID controller).
I think the box should have a warning sticker about this…
Meanwhile, back to the hunt for reliable, very quiet, low-heat-producing, mass storage.
Norbert Wiener Award winner Bruce Schneier points us to a new 117-page paper by Ronald C. Arkin on Governing Lethal Behavior: Embedding Ethics in a Hybrid Deliberative/Reactive Robot Architecture.
Looks like a must read – after I get caught up…
Here's a new twist on an old method of stealing data.
Taipei Times: Portable hard discs sold locally and produced by US disk-drive manufacturer Seagate Technology have been found to carry Trojan horse viruses that automatically upload to Beijing Web sites anything the computer user saves on the hard disc, the Investigation Bureau said.
Around 1,800 of the portable Maxtor hard discs, produced in Thailand, carried two Trojan horse viruses: autorun.inf and ghost.pif, the bureau under the Ministry of Justice said.
The tainted portable hard disc uploads any information saved on the computer automatically and without the owner's knowledge …
The bureau said that the method of attack was unusual, adding that it suspected Chinese authorities were involved.
Of course, in the USA, we use more subtle means to get your data.
Monday was Labor Day, a federal holiday in these United States, making a three-day weekend.
I spent quite a lot of it looking at a computer that kept saying this:
We're sorry; the installer crashed. Please file a new bug report at https://launchpad.net/ubuntu/+source/ubiquity/+filebug (do not attach your details to any existing bug) and a developer will attend to the problem as soon as possible. To help the developers understand what went wrong, include the following detail in your bug report, and attach the files /var/log/syslog and /var/log/partman:
Traceback (most recent call last):
File “/usr/lib/ubiquity/bin/ubiquity”, line 210, in
main()
File “/usr/lib/ubiquity/bin/ubiquity”, line 205, in main
install(args[0])
File “/usr/lib/ubiquity/bin/ubiquity”, line 58, in install
ret = wizard.run()
File “/usr/lib/ubiquity/ubiquity/frontend/gtkui.py”, line 358, in run
File “/usr/lib/ubiquity/ubiquity/frontend/gtkui.py”, line 989, in process_step
File “/usr/lib/ubiquity/ubiquity/frontend/gtkui.py”, line 743, in progress_loop
RuntimeError: Install failed with exit code 139; see /var/log/syslog
Mind you, I was doing something that may be fairly silly:
It was the last step that kept croaking. Even thought the CD I burned passed all integrity checks.
So I filed a bug report. Currently, I'm downloading the alternate Ubuntu installer, and doing a full scan of the (brand new) disk's integrity in case it has some physical fault. Takes a long time to scan half a terrabyte.
Earlier, a similar install using the same model card and a similar SATA disk alone on a similar computer (without the attempt to dual boot on two drives) went swimmingly.
But this one would croak even if I unplugged the ISA drive with windows on it. So There's Something Funny Going On….
Update: disk checks out fine.
Meanwhile, thanks to the Super Grub Disk I managed to rescue Windows from a non-functioning entry I'd put into the MBR. Three cheers for the Super Grub Disk! I'm now back to where I was 40 hours ago!
(Lest anyone feel too sorry for me, this isn't my main machine, and I actually like solving problems like this, even (especially?) if I caused them.)