08:15
-One
week left until the to-production deadline on the new book. Today, I'm
making a second pass through the chapters, incorporating comments from
our technical reviewers. That'll probably take a couple of days, which
leaves the rest of the week for any final cleanup, rewriting the
Preface, and so on. So I won't be posting much here until I'm finished
with the book.
Our friends Mary and Paul came over for pizza last night. We spent the
evening out on the deck. The weather was pleasant, and we enjoyed just
sitting around relaxing and talking. Except, of course, when
a branch plummeted 25 feet or so from the large tree that
overhangs the deck. We had the deck chairs arranged in a conversation
circle, and the branch fell right in the middle of it, fortunately
missing everyone. It was large enough that it could have done some real
damage if it had hit one of us.
Things are never boring around here. We invite friends over for dinner and our tree tries to assassinate them.
I had to burn a bunch of data to DVDs on Saturday, so I decided to see
what difference recording speed made to disc quality. I used Verbatim
16X DVD+R (MCC004) discs for all tests. The discs were burned on my
primary desktop system, running Linux and K3b, with a Plextor PX-740A
burner. They were scanned on another system with Plextools V2.32a in a
Plextor PX-716A burner. The data sets were not identical, but close
enough to get a reasonably good idea of burn quality. All of the data
sets were about 4 GB, and so nearly filled a DVD+R disc.
Writing the 16X discs at 16X, I got excellent burn quality, as shown in
the first graph. (Note that these are scaled to 100 maximum errors,
rather than the 500 that I used a month or two ago when I was testing
some inferior discs.) The burn quality declines slightly toward the end
of the burn, but this is still an excellent disc. The parentheses at
the end of the graph label enclose the average/maximum/total PI Errors.
Verbatim 16X DVD+R (MCC004) disc written at 16X (PIE 1.53/22/27,294)
It's often said that for best burn quality you should burn at less
than the maximum rated speed of the discs. The next graph shows the
results of scanning a 16X disc written at 12X. The burn quality this
time is superb, very close to perfect. There are a third as many PI
Errors in the 12X burn as in the 16X burn. (Even 27,294 PIEs is a great
burn, but a third of that is better still.)
Verbatim 16X DVD+R (MCC004) disc written at 12X (PIE 0.54/8/9,070)
Dropping the burn speed to 8X shows a very small improvement in burn
quality. (There are only 8240 PIEs versus 9070, but the 8X burn was
only 3.9 GB versus 4.2 GB for the 12X burn, so PIEs aren't directly
comparable.) For all intents and purposes, these discs are nearly equal
in burn quality, so it seems pointless to burn at 8X rather than 12X.
Verbatim 16X DVD+R (MCC004) disc written at 8X (PIE 0.52/8/8,240)
The 8X burn was the best so far, so I decided to try a 4X burn. The
next graph shows the results of scanning the disc burned at 4X. This is
actually a pretty good scan, a lot better than you'd ever get with most
disc brands, but the first GB still looks pretty ugly. PIEs peak at 59
Max, which is only 21% of the 280 Max generally considered acceptable,
but this disc was bad enough that I discarded it and reburned the data
at 12X.
Verbatim 16X DVD+R (MCC004) disc written at 4X (PIE 4.32/59/73,892)
Just for giggles, I decided to try burning a 16X disc at 2.4X, which is
the slowest speed supported by the Plextor PX-740A burner. The results
of the scan, shown in the next graph, are truly hideous. There aren't
any POEs or POFs, which means the disc may be readable, but, at more
than 9 million, the number of PIEs is about three orders of magnitude
greater than we consider desirable. Even expanding the scale from 100
to 500 isn't enough to show all of the PIEs on a disc burned at 2.4X.
Verbatim 16X DVD+R (MCC004) disc written at 2.4X (PIE 517.7/763/9,227,442)
The moral is, don't assume that a slower burn speed is always better. Test with your own drive and your own discs.
09:44
- The updated chapters of Building the Perfect PC/2E
are now posted on the subscribers' page. These versions incorporate
comments made by our technical reviewers, Brian Bilbrey, Jim Cooley,
and Ron Morse. Except for one chapter, they don't yet incorporate
comments by our editor at O'Reilly, Brian Jepson. We still have to
update the Preface, but other than that it's ready to go to production
once we get Brian Jepson's comments incorporated.
During free moments this week, I'll be working on a draft proposal
for a new book project, which I hope may actually turn out to be a
series of books, one that would keep us occupied for the next several
years, if not indefinitely. (And, no, it's not Astrology Hacks or Intelligent Design in a Nutshell, both of which some people have suggested. You know who you are...)
Understandably, Barbara is loathe to go near the yellow jacket nest in
our back yard. After Mary and Paul left Sunday evening, I went down and
sprayed most of a can of Hotshot on the small hole under the edge of
the landscape timber where the yellow jackets had built their nest.
I was shocked when I went out early yesterday morning to examine the
area. The hole was much, much larger than it had been, and there were
fragments of honeycomb scattered around the area, some as much as a
meter away from the hole. I saw only one yellow jacket flying around in
the vincinity of the nest. I kept checking back throughout the morning,
and never saw another yellow jacket. In late morning, I took out the
can of Hotshot and sprayed the remaining third or so that was left
directly down into the hole and onto the nest, which was visible in the
enlarged hole. I also sprayed a bit on the fragments of honeycomb lying
around the hole.
As far as I can tell, the nest is dead, but I'm not taking any chance.
Today, I may accidentally spill a liter of gasoline down the hole.
Meanwhile, the dogs aren't having much outside time. I didn't want to
take them down into the backyard, just in case the yellow jackets were
still around. And I can't take them for a walk on the street because
it's being repaved and I don't want to risk the dogs getting tar on
their paws. They city crew had scarified the street about ten days
ago, and yesterday the paver finally showed up. They laid down and
rolled a layer of what looks like tarmacadam, gravel bound with a
little tar. (There's little enough tar that a vehicle driving down the
street raises a large cloud of dust.) But that layer is only in the
center of the street, and doesn't come all the way to the edges.
They're out there now preparing to put down a finish layer, or so I
assume.
When I was in college, I worked summers for the Pennsylvania Department
of Transportation. We did a fair amount of paving, and I don't remember
doing anything like what they're doing on our street. We used to
scarify the old pavement and then put down one 2" to 4" layer of hotmix
and roll it. We used tar-and-chip, but only on the shoulders, not on
the roadway proper. I don't know if what they're doing now is an
improved method or just a cheaper method. The latter, I suspect, given
the price of oil.
Wednesday, 16 August 2006
09:40
-
I was right about the paving. I spoke to the guy running the roller.
They indeed put down only a 1" skim coat of hotmix atop the base they'd
laid previously. With the price of oil, I suspect the city can't afford
to repave using a full thickness of hotmix, so they're depending on a
thin top coat to seal the underlayment. Of course, that means the new
surface will degrade faster and they'll probably end up having to
repave in ten years or so.
I'm out of things to do on the new edition of Building the Perfect PC
until I get back the final pass from my editor. I'm doing fill-in and
catch-up stuff today, working on administrative stuff I deferred,
getting a proposal for a new book roughed out, and so on. I also need
to do some physical cleanup. The kitchen and dining room are packed
with PCs and components that I need to get organized and moved out.
Most of the new systems are actually in pieces, which may seem odd, but
is just an artifact of writing the book and shooting (and re-shooting)
images. The Gaming system, for example, is missing its video adapter,
which I grabbed to install in my main office system when its video card
started acting up. That system (an Athlon 64 X2 4200+ in an Antec P150
case) is destined to be Barbara's new main office system, once I have
time to get it rebuilt, get Xandros 4 installed on it, and get her data
migrated over from her old system. The Budget system is sitting on my
desk, where it's been my only Windows system since we built it. The SFF
and Mainstream systems are sitting on my second desk, not doing much of
anything at the moment. The SOHO server is sitting in the dining room,
and the Media Center system is still on the kitchen table.
As usual after completing a book, we have an embarrassment of riches.
As time allows, we'll replace our current systems with the new models.
Then we'll clean up the old systems, install K/Ubuntu Linux on them,
and give them to people who need them. It's been a while since I gave
any systems to Senior Services, and I suspect they'd welcome some
reasonably current replacements for some of their old stuff.
08:53
-
With only 750 GB of disk space, my main office system was beginning to
feel a little cramped. I can't believe I just wrote a sentence
with the phrase "only 750 GB of disk space". Well, it's true. As I work
more with camcorder video at about 4 minutes per GB, what I consider
"enough disk space" has increased by an order of magnitude. Just one
60-minute MiniDV tape requires nearly 15 GB of disk space.
So I decided to turn my main mini-tower system into a pocket
battleship. I pulled the 250 GB drive, which is too small to deserve a
drive bay, and installed two 750 GB drives. With the 500 GB system
drive, that gives me 2 TB of disk space, which should hold me for a
while. Also, since I had the cover open, I figured I might as well
boost the memory from 2 GB to 4 GB. With a Pentium D 940 dual-core
processor and an nVIDIA 6800 Ultra video adapter, this system now has
enough horsepower, graphics, memory, and disk space to do the job for
some time to come.
I did run into one head-scratcher, though. After I installed the first
drive and used fdisk to create a primary partition on it, I used
Ubuntu's Disks Manager to format and enable the drive. Everything
appeared to work properly, and the new drive showed up in the Nautilus
File Manager. The only problem was that I couldn't write to it because
the device /dev/sdb and the partition /dev/sdb1 were owned by root.
Okay, no problem, I thought. I fired up a console session and used sudo chown
to take ownership of the partition. I then went back to Disks
Manager, which still listed root as the owner. Hmmm. I exited Disks
Manager and restarted it. It still listed the owner as root. I rebooted
the system, and fired up Disks Manager again. It still showed root as
the owner. Hmmmm. Thinking that somehow the ownership had been reset to
root, I fired up a console again and checked at the command line, which
listed thompson as owner. Double Hmmmm.
To make a long story short, it appears that Nautilus in general and
Disks Manager in particular keeps its own set of permissions, unrelated
to the real system permissions. The solution was easy, once I figured
it out. Clicking the Browse button in Disks Manager displays a Nautilus
File Manager directory listing of the device as root. At that point, I
just right-clicked, chose Properties, clicked the Permissions tab, and
changed the permissions to 777.
I write all this here so that I can find it again next time. Obviously,
I must have gone through this procedure when I installed the 250 GB
drive. I vaguely remember going through hoops that time as well. I
obviously figured it out the first time, but I had to figure it out
again this time. Next time, maybe I'll search these pages and save
myself some aggravation. At any rate, I got both 750 GB drives
installed and accessible and the 250 GB drive removed. (Ubuntu reports
capacities in binary gibibytes, versus the decimal gigabytes used by
disk makers, so the 750 GB drives are reported as 698.64 GiB, the 500
GB drive as 465.76 GiB, and the 250 GB drive as 233.76 GiB.)
Backing up isn't the problem it might seem at first glance. Most of the
data on this system is already backed up, either on the original MiniDV
tape or on optical discs. The system files and general working data
sets are backed up as they always have been, to other network volumes,
writable DVDs, and external hard drives.
I really need to upgrade our network, though. We're running 100BaseT,
even though nearly all the PCs on the network have gigabit adapters.
The switch is a 100BaseT model, but that would be easy enough to
replace. The real problem is the cabling, which is all Cat5 with even
some Cat3 (100BaseT works fine on Cat3 over short runs). I think what
I'll do is upgrade my office to Cat6e throughout, and not worry about
the runs to the den, Barbara's office, and elsewhere. 100BaseT is fine
for those systems, as long as I can run gigabit within my office.
The speed of 100BaseT, or lack thereof, has become obvious as I've
started transferring larger files. At 100% efficiency, 100BaseT would
transfer 12.5 MB/s. Real world, because of overhead and collisions, it
does more like 8 MB/sec, which means it takes 8 to 10 minutes to
transfer a 4 GB file. 1000BaseT would boost those transfer rates
dramatically, although probably not by an order of magnitude. Still,
for the relatively small cost of a 1000BaseT switch and a few Cat6e
drop cables, it's a worthwhile upgrade.
11:20 - Another nail in the coffin of Microsoft.
Microsoft will of course claim that having 24 Indiana high schools with
22,000 students switch from Windows to Linux is insignificant, and that
the loss of 22,000 desktops to Linux is a drop in the bucket. They're
whistling past the graveyard. As the article points out, Indiana has
about a million students, each of whom will apparently have a dedicated
desktop system. Paying Microsoft $100 per desktop per year amounts to
$100 million per year, versus about $5 million per year for Linux and
OSS. (And even that is much more than Indiana really needs to spend on
OSS.)
Indiana plans to expand the program to 80 schools this, year,
presumably with about 80,000 students. Eventually, no doubt, that
program will extend to all students throughout the state, as well as to
other states, many of which are already running classroom Linux in
pilot programs. Linux also runs on millions of business and personal
desktop systems already, and its momentum is unstoppable. There used to
be trade journal articles every year announcing that the next year
would be "The Year of the Linux Desktop". I have news for them. The
Linux Desktop has arrived. They just haven't noticed.
Linux continues to chip away at Microsoft's competitive advantages.
With each passing month, Linux looks better and better, and Windows
looks worse and worse. Major manufacturers are beginning to realize
that Linux is a force to be reckoned with, and incorporating Linux in
their strategies. (Witness Intel's decision earlier this week to
open-source their graphics drivers.) Credible alternatives to Exchange
Server are beginning to appear, and Office, the keystone of Microsoft's
monopoly, faces serious competition from OpenOffice.org and the Open
Document formats. Vista and Office 2007 will be stillborn as far as
corporations are concerned. If Microsoft continues on its present
course, it's doomed. Not next year, nor even in five years, perhaps,
but ten years from now the computing landscape will look dramatically
different than it does now, with Microsoft at best a minor player.
08:47
- It looks like things are on track for the new edition of Building the Perfect PC
to go to production next week. I'll probably do one final pass to
incorporate any comments I get from my editor, but after that the book
is pretty much out of our hands. It'll go through the usual copy
editing and layout/design phases. We'll probably get the copy edited
manuscript before the production folks flow the text and images into
final form. At that point, we'll get PDF galley proofs and make a one-
or two-day blast through them to make any final tweaks. Then O'Reilly
produces the final camera-ready copy, and it's off to the printers.
Some time around late November or early December, it'll show up in the
bookstores.
By about that time, we hope to have finished the astronomy book we put
on hold to get this book finished. The astronomy book should end up in
the bookstores as a spring title. In December/January, we hope to start
work on the book that I'm drafting a proposal for right now. As Jerry
Pournelle often says, it's a great life if you don't weaken.
11:10 -
Barbara carries her MuVo MP3 player to the gym. A couple weeks ago, she
told me she'd like me to refill it with some new music. I'd have done
that, except back when my main system died I'd forgotten to transfer
the limited MP3 collection I'd ripped to the new drive, so I had
nothing to give her.
Yesterday, I decided to get serious and start re-ripping her CD
collection. She has hundreds of audio CDs, so I wanted to make the
right choices from the beginning. Her MuVo supports MP3 and WMA
formats. She doesn't really care about sound quality for her portable
player, so I decided that for maximum compatibility with her current
player and anything she gets in the future I'd use MP3 format. At 128
Kb/s, MP3 quality is noticeably inferior to the original music, at
least on classical music with decent headphones. I figured that 160
Kb/s would be about right. I didn't mess with VBR because frankly I
wasn't sure if her MuVo supported it, and 160 Kb/s files sound good
enough to both of us.
Under Xandros 3, my choices for ripping, encoding, and managing CDs
were quite limited. I really wanted to use KAudioCreator, but that
wasn't available in the Xandros 3 repositories, and I couldn't get the
Debian version working properly. With Ubuntu, it was very
straightforward. I installed KAudioCreator, stuck in a CD, chose LAME
as the encoder (it was already set by default the way I wanted it; 160
Kb/s and so on) and started ripping. KAudioCreator looks up the disc in
FreeDB, rips it to .WAV files, encodes the .WAV files to 160 Kb/s
MP3's, and spits out the disc. It organizes the tracks in the MP3
directory with the artist/group name as the first level subdirectory
and creates subdirectories for each album. Ripping, encoding, and
organizing Barbara's music collection is literally a matter of feeding
a new disc into the drive every time it spits one out.
For managing music on her PC, she'll use amaroK, or more precisely the
Xandros-modified version of amaroK that comes with Xandros 4. The
standard version of amaroK is very slick; the Xandros-modified version
even more so. Once we get Barbara's new system built and Xandros 4
installed on it, she'll be able to transfer music to her MuVo herself.
00:00
-
Copyright
© 1998,
1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006 by Robert Bruce
Thompson. All
Rights Reserved.
