brian will . net

In part 1, I made a negative case against the desktop interface as it currently exists, but I promised to make a positive case for my solutions. Because it would take at least a few weeks to put together a complete presentation, I thought it more timely if I instead present the ideas in installments (and hey, more reddit karma whoring this way). Most of the pushback to part 1 (both constructive and vitriolic) concerned my ideas about lists, so I decided to start there.

Rather than writing this up, I thought a screencast would be more appropriate for presenting these visual ideas. The run time is 37 minutes. (Yes, I know that’s long, and it starts slow, but if I’m not thorough, I just leave myself open to superficial dismissals.)

(I apologize for some parts where my narration gets a bit difficult to follow: I heavily edit the audio and end up removing awkward gaps and pasting together sentences from different takes; this works surprisingly well most of the time, but sometimes the result sounds a bit like Max Headroom.)

In chronological order:

• ATI WinMach64
• ATI Rage II
• Voodoo 1
• Voodoo 3 3000
• Voodoo 5 (yeah, that was a mistake)
• Savage 3D (another mistake; think I returned this one)
• Riva TNT 1
• Matrox G400
• Geforce 2
• Geforce 3
• Geforce 4
• Radeon 9800 Pro
• Radeon X800 XT
• GeForce 6700
• GeForce 6800 (a warranty replacement for the cooked-itself-to-death 6700)
• GeForce 7800
• GeForce 8800
• Radeon 4850

That’s 18 cards in about 15 years. I justified this shameful consumption by usually pawning my current card off on a family member as an excuse to get an upgrade.

The cards that made me the most happy were the Voodoo 1, the TNT, the GeForce 2, the 9800 Pro, and my current 4850. The 4850 actually seems to have cooked away its thermal paste or something and now runs really hot under load—often over 100 degrees Celsius! Shockingly, I haven’t seen any stability or artifact issues despite this, so I’m going to hold off on replacing it until I really have to.

A lot of screencasts suck, and it’s quite apparent why: the typical sucky screencast is thoughtlessly produced in about the same amount of time as it takes to watch it. If you want to produce a decent screencast, you should expect the production-time-to-viewing-time ratio to be more like 20 to 1 rather than 1 to 1. (I arrive at the figure 20 based on the fact that screencasts I’ve produced in the past with a ~10 to 1 ratio still sucked quite badly. I suspect, however, that the correct figure is closer to 30.)

Anyway, to produce decent screencasts, I’ve settled upon a quite involved process:

The content

1. First, create slides. If your screencast really requires full-motion video, we’ll insert that later. For now, just use the slides as a kind of outline or guide, even if they aren’t going to appear on screen in the end. For presentations, I’ve gotten accustomed to PowerPoint 2007, as OpenOffice Impress is just too clumsy, and the presentations that Impress produces are much harder to make look decent.
2. Second, record your narration. If you’ve written out everything, try improvising with the words a bit to help give the illusion that what you’re saying is extemporaneous. If you’re just making it up as you go along, that’s fine and in fact the way I do it, but understand that you should record in short intervals (~15-30 seconds) with as many retakes as it requires to get it right. Do not expect to deliver even just a few minutes of talk off the top of your head in one take. If you’re doing it right, working without a script goes quite slow. Each minute of narration I’ve produced this way has taken about 5 to 10 minutes of recording.
3. Third, edit your narration. If you worked without a script, you’ll likely have many flubs and odd pauses to remove, even if you properly did retakes. You’ll also likely need to add appropriate breathing space between topics. Even if your performance is perfect, you still probably need to normalize and compress to help even out variances in volume, and you may want to try noise reduction (just don’t use too much because you’ll then end up sounding robotic).
4. Fourth, use desktop recording software to record the slides. I’ve found the automatic slide timing in PowerPoint too clumsy to match the slides to the narration, so I just click through the slides myself while listening to the narration. To do this well, I find I need to first listen to the narration and create a list of the times at which I need to click. If you need full-motion clips of your desktop, simply produce them individually to be edited in later.
5. Fifth, use video editing software to put the video and sound together and to compress it all into a deliverable format. If the sound doesn’t match perfectly to the video, try duplicating and remove frames as necessary.

The technical bits

Rather than use a deskstand mic, I use a headset-style mic. Because I find the headphones uncomfortable, I wear them around my neck with the mic bent in place in front of my mouth. Understand that small changes in the mic position relative to your mouth will produce very noticeable changes in the acoustics of your voice, so try to find a single position and head angle to use every time.

To record and edit the audio, I use Audacity. Hit R to record, space to stop. (Be careful because if you hit R and space too quickly after each other, Audacity–on Windows at least–tends to crash. I suggest saving to WAV for every minute you produce.) Unfortunately, Audacity starts a new track every time you hit R, so you’ll have to manually consolidate the tracks, but it’s thankfully not too bothersome to do this: just cut and paste by highlighting with the mouse and using ctrl-x, ctrl-v. (Tip: after consolidating, delete the empty tracks by clicking the small x in the top left of each track.)

While recording, I prefer to start a new WAV file for every 4 or 5 minutes of audio so as to diminish the chance of losing work. I number the tracks like so: blabla-000.wav, blabla-001.wav, blabla-002.wav, blabla-003.wav, etc. (where blabla is the name of the screencast).

When done editing the audio, I use the compressor effect in Audacity to get consistent volume. I set the threshold to -30db, and if the end result doesn’t look even, I’ll run the compressor again one or two times until it does. Then I find a bit of audio where I’m not talking but which has some noise, select it, click ‘noise removal’, click ‘get noise profile’, then select the whole audio, click ‘noise removal’ again, slide the slider all the way left, then click ‘remove noise’.

Through this whole process, save everything as at least 44.1khz 16-bit stereo in WAV format. If we’re going to degrade, we can do that later.

To capture video of the desktop on Windows, I use CamStudio, an open source tool. Some Vista users will find that the 2.5 beta has fixed sound recording for them, but because we’re not using it to record sound, I recomend just using 2.0. Also be sure to download and install the CamStudio lossless codec (latest is 1.4, at the moment), which I find is the best for pristine full-motion desktop capture. I do my presentations in 16×9, so I set the desktop to 1280×720, run the presentation in full screen, and use CamStudio to record the full screen without any audio. Handily, CamStudio has an option to disable recording of the cursor.

To edit and compress the video, I use VirtualDub. Using the CamStudio codec with VirtualDub requires installing the DirectShow plug-in (which does not work with 64-bit VirtualDub, so be sure to use 32-bit).

Open the video file, then under “Audio”, specify “audio from other file…” to get audio from the appropriate .wav file. You may have to adjust the sync under “interleaving”. Because we’re compressing to mp3, first select “full processing mode”. While your original mic recording in Audacity will be in mono, you at least want it to be mono coming out of all of the listener’s speakers. Otherwise, even a decent narrative will come off as sounding tinny, dull, and lifeless. So under Audio->Conversion, be sure to select stereo. Then under “compression”, I suggest 44100 Hz 128kbps stereo mp3. (Also, stick to CBR as it will further reduce the possibility of sync issues. If you need an mp3 encoding codec, LAME mp3 is the obvious choice.)

Under “Video” select “fast recompress”, then select a compression codec. I recommend x264vfw, an h.264 codec. (VitualDub requires Video For Windows encoding codecs, so if you already have an h.264 codec, you may still need x264vfw.) Experiment with the compression levels until you find something acceptable.

Assuming your video is mostly still images, the video data should run at well under a megabyte per minute such that the audio data will most likely outweigh the video data in the final file. A 10 minute video produced this way takes about 15 megabytes. I’m sure with greater compression expertise, this could be cut substantially, but if your end target is Youtube and other video services, I strongly recommend aiming for quality first and letting them handle any further compression.

How’s this for blogging on the cheap? Below is a paper I wrote for English 101 a while back. I’ve reworked it slightly (removed the silly Chicago citations), but it retains the stilted prose and mechanical structure of any good My First Research Paper. In any case, I’m fond of its clarity. Perhaps in some future post, I’ll follow up with a lengthy discussion of the political and aesthetic obstacles keeping PRT’s from being taken seriously.

In 2002 in the United States, approximately forty-three percent of the oil we consume—making sixteen percent of the total energy we consume—is consumed by personal cars and light trucks. In the same year, cars and light trucks accounted for thirty-three percent of the carbon dioxide, fifty-one percent of the carbon monoxide, and thirty-four percent of the nitric oxides emitted in the United States. Were Personal Rapid Transit (PRT) systems built in America’s large- to medium-sized cities, America could greatly reduce its use of energy for personal transport and reduce its air pollution.

In a Personal Rapid Transit system, vehicles for two-to-four persons travel on a fixed track. The vehicles always travel one way down a particular length of track, only changing course at bifurcations in the track which resemble freeway off-ramps; two pieces of track might merge into one, like a freeway on-ramp. In most PRT designs, the track is elevated off the ground to make traffic interference a non-issue.

At many small stations along the track, passengers pay their fare and enter the first empty vehicle waiting in line; the station track is a detour off the main track to allow traffic to by-pass the station without stopping, just like freeway on-ramps and off-ramps allow traffic to flow uninterrupted. The vehicles are controlled by their own individual computers, using a small command vocabulary: ‘go’, ‘stop’, ‘take the left/right track’; each vehicle receives its macro-level directions from a central network, e.g. ‘go to this station’, but the set of micro-level actions necessary to carry out that directive are left to the individual vehicle. The central system is responsible for distributing unused vehicles to stations where they will most likely be needed based upon projected traffic patterns. PRT designers consider any kind of stoppage or slow-down in the system as a failure and not to be tolerated as part of normal operation; a properly implemented PRT system would never have traffic jams except in isolated cases. At worse, an influx of demand should only result in waits to board vehicles. (Here’s a nice graphic of the whole thing.)

How the vehicles are propelled varies greatly among different PRT designs. In the PRT design of prominent PRT proponent and designer, J. Edward Anderson, an engineer and former professor at the University of Minnesota, a linear induction motor in the vehicle is powered from the track. Some propose supplementing the track’s power supply by having the track double as a place to put solar panels.

The first reason a PRT system would save significant amounts of energy compared to cars is that the vehicles are significantly lighter. Small vehicles don’t need the acceleration of larger ones, and when powered from the track, they aren’t further weighed down by fuel. Similarly, the smaller volume and lower traveling speed of the vehicle reduces the comparative amount of drag.

Another reason a PRT trip consumes less energy than the same trip in an automobile is that PRT’s typically travel at lower cruising speeds, thus requiring less energy to maintain speed. For safety reasons, most PRT designs propose a speed between twenty-five and forty miles-per-hour; while safety at greater speeds is most certainly possible, greater speed is not as desirable as you might think because the lower travel speeds are made up by the vehicles never stopping on route between origin and destination.

That PRT vehicles only accelerate up to speed once per trip is the most important factor in why PRT’s consume less energy. In a typical car trip, the many accelerations from a dead stop account for a disproportionate amount of the energy consumed even though they only account for a small fraction of the time and distance traveled.

Because the vehicles are powered from the electrical grid rather than gasoline or diesel, there is zero local pollution. This does not solve the problems of air pollution—energy is only as clean as its total amount of emissions at the point where it is both generated and emitted, not just where it is emitted—but prospects for producing clean energy at electrical plants are much more promising than the prospects for our automobiles.

Unlike other solutions for reducing the pollution and energy consumption of personal transport, PRT systems don’t gamble upon uncertain future advances in technology. Electric-powered, hydrogen-fueled, and bio-fueled cars—the prospects for making these technologies economical (or, in some cases, work at all) are unknown. The problem is that science is not magic: some of these technologies may simply turn out to be dead-ends. Of course, the PRT idea hasn’t yet proven itself either, but the engineering required to make the system work consists wholly of combining well-understood technologies. For instance, probably the greatest area of uncertainty surrounding PRT’s is how such systems will handle heavy traffic loads. Though Anderson and other researchers have performed statistical analysis, this is the sort of thing where the details can only be worked out given a real-world system.

The closest analog to this kind of work is the writing of a computer operating system: an important component of an operating system is its “scheduler”, the code which allots processing time to the many programs running at one time on your computer; if the scheduling algorithm is not well-designed, human users will feel their system is unresponsive, and time-sensitive tasks (interactive games, audio, video, and so forth) will lag and stutter because their programs aren’t getting processor time often and long enough to do their jobs on time. The academic literature produced in the 1970’s and 1980’s on scheduling algorithms, while hardly worthless, turned out largely to be wrong (or at least inadequate) when multi-processing operating systems finally arrived to the masses in the 1990’s. So too will research on PRT traffic patterns be flawed until we have real-world systems to observe and tinker with. Still, that such kinks in the system can be worked out is a better bet than a “Manhattan Project” for energy, where engineers would be working on the edge of our understanding of how the universe works. Just as faster-than-light travel may simply not be possible, sufficiently efficient and green car motors may not be possible, so it would be foolish to stake our future entirely on the prospect of sufficient advances in automobile tech.

The failure of the United States to successfully adopt mass-transit in most of its cities is widely attributed to Americans’ dislike for riding mass transit. The usual objections to mass transit largely don’t apply to a PRT system, as it offers these advantages over other transit systems like buses and light-rail:

1. Because PRT track is much smaller than light-rail track and PRT stations are much smaller than light-rail stations, the construction of PRT track and stations is much faster and less obtrusive and requires less man-power.
2. PRT stations can economically be placed at short intervals along the track (one at every half-mile in Anderson’s design), meaning a station is much more likely to be within easy walking distance of passengers’ departure points and destinations.
3. The system can operate around the clock, and passengers never need worry about train or bus schedules.
4. More often than not, an empty vehicle will await passengers when they arrive at their departure station; even in peak hours, waits for vehicles should rarely be longer than a few minutes.
5. No driver or other staff need be employed per vehicle, as with buses and trains.
6. PRT’s occupy less land than light-rail systems, and consequently, they are less visually intrusive and free up space for other purposes.
7. The vehicles travel non-stop between origin and destination, never picking up other passengers or requiring passengers to make a transfer.
8. PRT vehicles produce far less noise than cars, let alone buses or trains.
9. Passengers in a PRT have a private car to themselves, so they can relax, read, talk on their phones, use their laptops, or do their makeup while in transit without consideration of other passengers.
10. Despite the lower cruising speed, transit by PRT would be significantly faster than by other mass transit systems because of its (usually) low waiting times, the non-stop travel, and the fact that origin and destination stations are likely closer to passengers’ points of travel.

Even with all these comparative advantages to current mass transit, PRT’s still must compete with Americans’ fondness for cars. Fortunately, transit by PRT is in many ways even more appealing than travel by personal car.

1. Passengers in a PRT don’t have to drive, allowing transit time to be used for entertainment, chatting, or work.
2. Passengers don’t have to find parking or pay for parking at their destinations.
3. In a city with a PRT system that covers a wide enough area, more people can live without the cost and hassle of owning, licensing, insuring, and maintaining a car; at the very least, families could get by with fewer cars.
4. On the whole, PRT’s would be much safer than other forms of transportation, as there are only three plausible safety concerns: malfunctioned vehicles breaking or stopping unexpectedly, vehicles not breaking when entering a station, and collisions at merge points. To mitigate these possibilities, the proposed cruising speed for most PRT’s is below forty miles-per-hour; also, sensors on each car engage the breaks when the car ahead is detected doing something abnormal, removing human delay and error. These factors greatly reduce the frequency and severity of accidents, especially compared to what we tolerate today on our roads.
5. A PRT would increase the mobility of those unable to drive: the young, the elderly, and the handicapped (in Anderson’s design, the vehicles provide easy embarking and disembarking of wheelchairs).
6. PRT’s offer quieter rides for their passengers and create significantly less street noise.
7. Transit by PRT would be faster than car trips for routes with many traffic lights and stop signs along the way.

Aside from direct benefits for passengers, a successful PRT that reduces car traffic would thereby increase quality of life by reducing the amount of noise and air pollution and allow the diversion of resources from road maintenance. After a number of years, cities may even begin reducing the width of existing roads and the size of parking lots, reclaiming space for sidewalks and other purposes. Asphalt surfaces capture heat in hot weather, leading to heavier use of air conditioning; reducing the amount of paved surface in our cities would lead to a surprisingly significant reduction in energy consumption.

Other hidden costs of our roads include traffic cops, traffic courts, traffic accidents, traffic reports, traffic schools, traffic lights, traffic engineers, traffic signage. In particular, there are often over-looked societal and economic costs just associated with parking: parking structures and the extra parking lanes on the sides of streets not only must be built and maintained, they take up prime real-estate. Perhaps least obvious are the psychological tolls, such as the aggravation of finding parking or the danger of cars (even when we’re not in a car ourselves, most of us must be wary of being hit by a car just twenty steps from our doorstep).

Of course, operation of a PRT will introduce many such hidden costs of its own, not all now foreseen, but on the whole, they seem relatively modest. For instance, emergency crews and equipment will be needed to occasionally clear malfunctioned cars and rescue stranded passengers. The track and vehicles themselves, of course, will need upkeep. And so forth.

In the last thirty years, several attempts at constructing PRT systems failed, mostly due to lack of funding and political support and inadequacies of the day’s computer and electric-engine technology. As of yet, there is no PRT success story, and until there is, municipalities and governments won’t take the idea seriously. At the moment, two PRT’s are scheduled to start operation in 2008: the “ULTRa” system at Heathrow Airport in London and another system at the International Finance Center in Dubai. By proving itself in a localized capacity, hopefully the PRT idea will begin to see adoption as a city-wide transit system.

Ubuntu 7.10 (codename “Gutsy Gibbon”), released last month, is for me the first really usable Linux, which is saying a lot considering I’ve made a serious attempt to switch to Linux about once a year for the last six years. The last 3 of those attempts have been with Ubuntu, and while I could always get my system dual-booting into Ubuntu, there was always some essential functionality I couldn’t get working such that, when the GRUB menu came up, I would always choose to boot into Windows. With Gutsy, I can finally say that the only compelling reason I have for booting into Windows is to play games.

What follows is a rundown of various issues hindering Linux desktop adoption, most of which I can happily report are solved–or on their way to being solved–in Ubuntu.

For reference, my desktop specs are:

• MB: Asus P5NSLI (nvidia nforce Intel Sli)
• CPU: Core 2 E6400 (LGA775)
• RAM: 2 gigs
• HD: Western Digital 7200 rpm 250gb SATA
• Sound: Creative Labs X-Fi Gamer and ADI AD1986A onboard audio
• Video: geforce 8800 GTX 768mb
• Monitors: Gateway FPD2485W (24″ 1920×1200) and Samsung 215TW (22″ 1680×1050)

My laptop is a Gateway M-6816, which has Intel PRO/Wireless 3945 and Intel Graphics Media Accelerator X3100 (up to 384MB shared).

Installation media

I start with the issue of installation disc integrity because, in my experience, it is not a rare problem. My first torrent of the Gutsy amd64 DVD was faulty, apparently, and this caused the live CD boot to hang early in its process. I’ve experienced similar problems with previous releases. I suggest always running the media check (an option in the boot CD splash menu) before installation.

386 vs amd64

The 386 DVD version installed without a hitch, but sadly, I’ve yet to get the amd64 version to work. The trouble seems to be graphics related, as the boot CD stops before it gets to the graphical login screen. I successfully installed in text mode, but booting from that install exhibits the same problem.

Partitioner

A non-destructive partitioner is essential for Linux’s success on the desktop because most users coming from Windows wish to dual-boot and don’t want to reinstall Windows or lose any Windows partitions. Also really important is a smart installer that helps users pick the right set of partitions to create for Linux. With previous releases, I’ve had to turn to external solutions, like GParted and the Ultimate Boot CD, to mixed results. With Feisty, Ubuntu started to integrate GParted into the install process, but the result was still sketchy. When installing Gutsy, I already had free space on hand for a new primary partition and so basically by-passed the issue, but I’d be very interested to hear how others fared with setting up partitions for Gutsy where they had to resize NTFS. One thing I’d like is a manual/auto mode so I can have the installer recommend a partition layout but still see what exactly it’s doing and modify its plan.

Reading and writing NTFS

Just as important as easy non-destructive partitioning, users coming from Windows want to read and write their NTFS partitions. (Reading and writing Linux partitions from Windows is less pressing, but can be done with explore2fs.) With Feisty, users had to know they needed to install a package to get NTFS support, and I myself couldn’t get writing to NTFS to work, only reading. With Gutsy, my 3 NTFS partitions are readable and writable out of the box in Nautilus just by double clicking them and entering my password (this just mounts the partition: you must click again to view the root of the partition, a behavior which should be changed or made clearer with user feedback).

Boot loader

On the laptop I bought a few months ago, the first thing I did was make room for Linux by clean re-installing Vista from the included install disc into a smaller partition. Gutsy installed with no hassle, and GRUB allowed me to boot into Vista. On my desktop with XP and Vista already installed, installing Gutsy replaced the XP loader with GRUB, but strangely this left XP bootable from GRUB but not Vista. My guess is that GRUB tried starting Vista as if it were XP because that’s how it listed the partition in the menu; this may have arose from the unusual case of a Vista partition existing on a drive with the XP loader installed (it got that way because I installed XP after Vista). Only after reinstalling Vista and then a second install of Gutsy (amd64) could I boot into any OS from GRUB (even though, as mentioned, Gutsy amd64 won’t boot). Hopefully my unusual case will be accounted for in future releases.

GRUB could stand a few basic improvements. First, the default names given to the Ubuntu boot options should be simplified, as they are currently quite scary. Second, there should be an obvious GUI way to edit the boot menu, especially for changing the default partition.

Boot time

From hitting the power button, it takes Windows XP 60 seconds before the desktop appears. From that point, it takes another 90 seconds before Firefox will open and I can interact with it.

On the same machine, booting Gutsy cold also takes 60 second before I see the desktop. However, at that point, it only takes 5-7 seconds to fully load Firefox.

(I’m sure a few programs I have installed on XP hinder it compared to a clean XP install’s baseline performance, but I don’t have anything that major loading with XP; the only significant startup daemons I have are nvidia’s ntune panel, dtools daemon, and Valve’s Steam.)

Ethernet and Internet connectivity

In previous Ubuntu’s, I had issues getting wired and wireless internet connectivity, and I don’t think I have to tell you how useless a system without an internet connection is. Thankfully with Gutsy, I haven’t had one problem whether wired or wireless. I’ve yet to try networking to other Ubuntu installs or to Windows, so I can’t speak to those issues.

Pointer feel

If your mouse doesn’t feel right, your whole user experience is severely degraded. For instance, I probably wouldn’t dislike Macs so much if it weren’t for the fact that every time I’ve ever used one, the mouse motion was way off (and lets not even mention Apple’s “innovations” in mouse body shape and clicking mechanisms). Even when configuring my MacMini (the first and last Mac I’ll ever own) with mice of my own choosing, I’ve never gotten close at all to the quick, accurate control I’m used to in Windows, where I have a high DPI mouse (the Logitech G3) set to high sensitivity and low acceleration with “enhanced mouse precision” enabled. (Jeff Atwood ellaborates on mouse acceleration in Windows vs. Mac.)

The mousing in previous Ubuntu releases was similarly unsatisfying (though Kubuntu was considerably better). Compounding the problem in Ubuntu, the sliders for acceleration and sensitivity in the Gnome mouse control panel never seemed to do anything, as if they were just included for placebo effect. Well, in Gutsy, I still can’t tell if the sliders are doing anything, but happily the mousing feel out of the box is nearly up to par with Windows. My laptop’s touchpad is similarly satisfactory. While still not perfect, the mousing in Ubuntu is sufficiently good I rarely notice it (unlike in OS X). Still, the fact that the motion adjustments don’t seem to work worries me: I could have just gotten lucky this time with my choice of hardware while other people might not be so lucky.

[To be fair, after a few minutes spent playing with a new model iMac, I must confess the mousing was quite good, even with the gimicky mouse (the fact that I was using a fast, responsive system rather than the under-powered MacMini probably made the difference here). Also, Apple's new ultra-thin keyboards work surprisingly well considering they appear horridly anti-functional.]

Graphics driver, 3D acceleration, and multi-monitor

Unlike in previous Ubuntu’s, installing working 3D drivers in Gutsy for my latest and greatest nvidia card was effortless. On the downside, the “new” nvidia driver is proprietary, but I’m OK with this, as I don’t think the strategy of boycotting proprietary hardware will pressure the graphics chip makers to release open specs or drivers. Features like Compiz need to get in front of users for proper attention to be paid to 3D among the develeper community, let alone the chip makers, and as long as no one is actually using 3D hardware on Linux, nvidia, ati, and intel will feel little pressure to advance the platform. Hopefully, ati will fulfill their promises of open source drivers and specs for R500 and later hardware, and hopefully success there will prompt nvidia to do the same. (Like with Samba and proprietary multimedia codecs, the basic strategy here needs to be the FOSS version of “embrace and extend”: supporting proprietary technologies gets Linux out of the gutter while interoperability increases use of free technologies. FOSS needs market power first before it can make demands. But that’s a whole post unto itself.)

Getting my second display configured was frustrating at first, but running ‘nvidia-settings’ got everything in order (run it as root so that it can overwrite xorg.conf). The Linux multi-monitor situation is a bit confused at the moment because of limitations in the underlying X window system that have yet to be corrected or worked around. This results in some unsatisfactory behavior: currently, my desktop is a 3600×1200 virtual desktop such that it extends off the top and bottom of my 1680×1050 display; while maximization on that display thankfully works correctly, some oddities occur, such as desktop icons hiding off screen.

Sound

My Audigy X-Fi is not supported in Linux except by proprietary beta drivers from Creative Labs for 64-bit Linux only. As I have yet to get 64-bit Gutsy working, I can’t report on that support. Rather than swap back in my Audigy 2 ZS, I turned on the onboard audio in my bios. This got sound working, though I did have to fiddle a bit in the sound panel. Also, I can’t get anything beyond 2-channel sound to work, likely because the onboard audio’s jack sensing is not supported by the drivers, so the 3 jacks from my motherboard are stuck as line-in, line-out, and microphone (hmm, except then you would think I could get sound to record, though I can’t).

These driver issues are understandable considering I’m using a relatively new proprietary sound card and a not-so-common generic onboard solution. Really though, the biggest failing of Linux sound-wise at this point is not any lack of hardware or lack of auto-configuration but simply that the sound situation is so damn confusing. In trying (and failing) to get 6-channel sound working and in (successfully) fixing the lack of sound in Flash on my father’s system, I was confronted with a mess of OSS, ALSA, ESD, OpenAL, PulseAudio, and a whole array of opaque options I didn’t understand. Hopefully these projects will coalesce or at least learn to better exist side-by-side so they can be configured to work simultaneously on the same system. The situation feels like GNOME vs. KDE of several years ago when getting KDE apps to work in GNOME and vice versa was tricky.

Font rendering

In previous releases, smoothed font-rendering was tricky to get working, but now it is turned on in GNOME by default. You can even select between “best shape rendering” (OS X -like rendering) and “subpixel rendering” (Windows-like rendering). (Here’s the difference between the two.)

On the downside, the selection of fonts out of the box is a bit lacking: too many almost identical sans fonts, not enough quality serifs, not enough monospaced fonts. On the upside, most of the included fonts are quite good, especially the great Monospace, which is very similar to Microsoft’s new Consolas font but with a few changes that make code even more readable.

Multimedia codecs

On all Windows installs, I install mplayer, vlc, and the K-lite mega pack because doing all that seems to cover all bases, codecs-wise. In previous Ubuntu releases, I’ve been lucky to get MP3 support working, but in Gutsy, I finally don’t have to worry about codecs. I simply open any media file in mplayer or vlc, and GStreamer detects which codec I need and downloads it, and then the file plays (though sometimes only after restarting the player). Dubious legality aside (OK, not so dubious illegality—I’m in the US, and it definitely ain’t legal), the only way for codecs to work better is to simply have the whole lot installed by default.

Portable music players

My Creative Labs Zen Microphoto (8gb) used to work fine on Windows XP before Creative discontinued its original drivers (which they pig-headedly don’t offer for download) and upgraded its firmware to use Media Transfer Protocol. Now, Zen users on XP must use Media Player 10 to interface with their device, but it’s never worked for me. Since then, I have had to use my laptop to charge and interface with the device.

In Linux, applications can use libmtp to interface with MTP devices. Ubuntu installs by default Rythmbox, a stripped-down but slick iTunes-like player, which supports libmtp via a plug-in. I just wish it were clearer that you must enable the MTP plug-in (in the plug-in preferences) before your device will be recognized, as it was days before I noticed the option.

So here’s a case where something works for me in Linux but not Windows (XP).

(I should also remark how much I like Rythmbox, which is surprising considering I dislike iTunes. The key thing that makes Rythmbox acceptable to me is that it keeps your music files in place rather than presumptuously duplicating and re-encoding your entire media collection the way iTunes is wont to do.)

Package management and application installation

In the previous Ubuntu, I had trouble with Apt (the package manager) getting buggered right out of the box such that its database got locked, causing Apt and Synaptic (the GUI front-end) not to work at all because they couldn’t access the database. This happened consistently immediately after a clean install, rendering Ubuntu basically unusable.

It’s annoying that many packages in the repository are for old versions, even for major programs, like Eclipse and Azureus. Azureus, for instance, wouldn’t work for the version I got from Apt; only the latest version, gotten manually from the Azureus site worked. So there are many cases where you must go fetch a lot of apps by means other than Apt.

Java

Now that Java is free, I assumed it would be included by default, but that didn’t seem to be the case (or at least, I had to manually install Sun’s Java 6 to get Eclipse and Azureus working). It’ll be nice when this situation gets resolved so users can simply have Java apps working out of the box.

Web browsing

Firefox in Ubuntu is much slower at rendering than in Windows. In Windows, my habit is to ctrl-mousewheel to change font size, and Firefox resizes in real-time as I scroll the wheel with all but the most complex pages. In Ubuntu, even simple pages can take a moment to resize the text, so I had to train myself not to reflexively resize pages. You can also see Firefox’s slow rendering in pages like Google Maps, where dragging the map is far from smooth. It’s likely this slow rendering is tied to inefficiencies in GNOME, X, or maybe the new font rendering, as I can’t imagine that Firefox’s rendering path changes much between Linux and Windows. It’s possible the new font rendering is causing this slow down, ormaybe something similar is the culprit, but I see the problem on all machines I’ve installed Gutsy. Hopefully Firefox 3’s new rendering engine (with a Cairo backend) will bring this back up to par.

(Sadly, my favorite Compiz plugin, Enhanced Zoom, causes animated cursors to disappear after the first time you zoom in, and this is most aggravating in Firefox, where the cursor animates as pages load; the only fix is to restart X (by ctrl-alt-backspace), but this closes all your programs, so the only real solution for now is to just disable Enhanced Zoom.)

User switching

A panel widget included by default is “fast user switching”. I’ve experienced debilitating bugs with this widget, so I suggest you not use it.

Gnome desktop

Finally, I have some assorted thoughts on GNOME:

Thankfully, the application menu has been cleaned up since Ubuntu’s last release: rather than listing apps by their project names—names which are meaningless to most people—most apps now are just given simple descriptive names that reflect their functionality. The menu editor, however, could stand some more work, as it’s a bit hard to discover and awkward to use.

In previous GNOME’s, the icons ranged from acceptable to ugly turd. Now, the default set of icons in the menus and file browser not only do not look like crap, they are actually very attractive and exemplary models of clean design, better even than many icons seen in OS X. And speaking of bling, I do wish there were more color themes and bundled wallpapers with the stock system in the vain of Windows. It would be neat if they included some of the great photos from Wikipedia’s photo of the day, which includes some very neat panorama shots.

The default panel config of Gnome is a silly attempt to split the difference between the Windows / Mac desktop, and too many unnecessary panel widgets are included by default. At the very least, a quick panel config wizard should allow me to choose the standard Windows taskbar layout.

Unfortunately, my biggest irritations with GNOME can’t be fixed with a lick of paint. First, windows with scroll panes inside open too small to see the content of the scroll pane, forcing me to resize or maximize these windows to properly see this scrolled content. This problem is exasperated by my other grievance: grabbing window corners is too tricky, and I often accidentally click with the horizontal or vertical resize cursor when I wanted the 2-axis resize cursor.

Jeff Atwood discusses the way Mac OS X windows don’t really have ‘maximize’ buttons, and he comes to the right conclusion: better to have overly large windows than to make users futz with the dimensions of their windows. He says:

…Apple’s method of forcing users to deal with more windows by preventing maximization is not good user interface design. It is fundamentally and deeply flawed. Users don’t want to deal with the mental overhead of juggling multiple windows, and I can’t blame them: neither do I. Designers should be coming up with alternative user interfaces that minimize windowing, instead of forcing enforcing arbitrary window size limits on the user for their own good.

As it happens, minimizing the hassle of windows—both main application menus and pop-up dialogues—is the major design goal of my desktop UI design, which I’m calling ‘Portals’. Back in this post in March, I promised to present the Portals design, but I never quite finished the mockup demos in Javascript. Still, there’s enough there to convey the biggest ideas. Eventually I’ll fill in the notes and the rest of these demos and perhaps also finish the screencast about Portals which I started.

The mockups come with lots of (rambling) notes, but one thing they oddly fail to make clear is that Portals has no desktop, i.e. no flat empty surface on which to dump icons and files.

In response to a challenge by Aza Raskin to come up with a better way of tabbing in Firefox—in particular a solution that scales better the more tabs you have—I produced this mockup in Javascript. Be clear that, because of the way the tab previews are done, the performance is creaky and not representative of what a proper implementation would be like. Please, use your imagination and pretend the previews pop-up instantly. Also understand, it ONLY WORKS IN FIREFOX. (While it won’t work at all in IE, it should mostly work in other non-Firefox browsers, though I haven’t tested any).

The rationalization is given on the page, so I’ll simply discuss here why I rejected some ideas proposed by others and also consider some variants on my design which might be even better.

In the comments of Aza’s post, a number of people expressed a desire to introduce alternative ways of conceptually ordering the tabs other than the default order in which you opened them, e.g. some wished to be able to group their tabs (which you can kind of do already by reordering), some wished to see their tabs listed by chronology of the pages (as opposed to of the tabs), and some wished to see their tabs in a web displaying heritage (which page was opened from which other page). While there might be something to these ideas, I avoided them as there seemed to be easier gains to be made that didn’t involve conceptual changes for the user. I wanted to improve the tactile experience of dealing with many tabs.

Others have proposed some kind of zooming UI. Again, there may be something to this idea, but until hardware support can be implemented consistently across platforms, I don’t see this happening. Besides, it’s a tricky thing to get right, as many users are easily disoriented.

Others mention multiple tab rows. This idea is problematic for the same reasons displaying any one-dimensional information in rows is problematic: things move around in unexpected ways when the bounds gets resized and tabs are added and removed, messing with the users spatial memory of where their tabs are. (Of course, text has the same problem, but text has paragraph breaks that help a large section of text mostly retain some recognizable shape as it is edited and its bounds resized.)

As for variants on my design:

A major flaw of the current Firefox tabbing which my design doesn’t really conquer is that I find myself often confronted with having to do multiple searches to find a tab: by reflex, I first search through those tabs I can see, then I’ll mousewheel back and forth, then occasionally I’ll go into the full list on the right if I still haven’t found the tab. The problem here is that the worst-case scenario searches are very expensive and distracting, but they wouldn’t be if I simply went to the full list to begin with. As nearly good would be if I couldn’t scroll the tab bar at all, forcing me to go into the full list of tabs sooner; in this scenario, we’re actually better off keeping the number of tabs visible in the main bar rather low, say 7-9 at most.

If we embrace the idea that the full tab list should be used more often, it then makes sense to better purpose the main bar. Rather than show tabs which occur consecutively in the full tab list, the main tab bar could display the last viewed tabs in the order they were viewed. In this design, you actually wouldn’t ever see the current tab in the main tab bar as you don’t need to click on it, but you’d still find it in its proper place in the full tab list.

If this is too confusing, perhaps get rid of the main tab bar altogether and have the full tab list button sit by itself to the right of the search box.

I’ve also considered simply having a single vertical sidebar for tabs. This would be like having the full tab list always open. While you might object to the loss of screen space, I’m not sure it would be so bad, especially for wide screen users, who often have to artificially make their Firefox windows narrower for reading, anyway. The Vertigo extension already offers Firefox users vertical tabs, but it could be improved:

• The tabs bar should not be as wide as the history and bookmarks sidebars are by default, not really for functional reasons (at least on big widescreen monitors) but rather aesthetic ones.
• Each tab should be two lines high for easier clicking and so that titles can wrap onto two lines if needed.
• Hovering over a tab should display a preview (as in the demo) and any part of the title cut off should appear extending out of the tab bar into the page. (In fact, I’m thinking that hovering over the vertical tab bar should make all cut off titles appear in this manner; even with the titles extending out of the sidebar, you would still be able to see where the sidebar ends, so when you mouse out of the sidebar, the titles would all go back to normal.)

Raganwald argues that link-voting sites (Digg, reddit, et. al.) hurt the web by locking comment threads into proprietary databases, depriving the web of some of its vital webness. I would agree, except:

1. I’ve always found Digg and reddit comment threads function as contests to see who makes the best joke, and this they do well enough. For serious discussion, they are almost always useless, so I turn to the source’s comments.
2. Slashdot is a pretty strong counterexample. Whereas Digg and reddit comments are largely dominated by immature people, the Slashdot community is dominated by knowledgeable and insightful immature people. The only thing I really dislike about Slashdot threads are all the people complaining about Slashdot dupes, Slashdot story quality, the Slashdot moderation system, and Slashdot comment threads.
3. Many links don’t point to blogs but rather to ‘heavier’ sites, like newspapers. I never read nor contribute to the comment threads of such sites: if it isn’t a WordPress blog or something near like, I ain’t going to bother with your crappy commenting registration process and interface. So in those cases, Slashdot, Digg, and reddit provide a forum that in my mind wouldn’t otherwise really exist.

Now as it happens, I’ve had an idea of late of how to create a decentralized Digg-like system using RSS feeds. I leave it as an exercise to you to imagine how this would work (hint: there are no centralized feeds; everyone sees their own personalized collation of received items; while not exactly the same thing as Digg, I believe this actually has some important advantages for the user). Oh, and I call the system Panoptikon (with a ‘k’ because the closest domain I could get was panoptikon.org)*.

* If you’re that one crazy person who actually follows my blog, you remember ‘Panopticon’ is the name I gave to another proposed idea. Yes, I’m re-purposing the name, as I believe it fits this idea better.

More bullshit performance claims from Apple?

So Apple, out of nowhere, has released Safari for Windows. Among the reactions today, Joel Spolsky jumped the gun, complaining about how Apple Safari for Windows loads very slowly, only later to retract—apparently, Safari for Windows stopped loading slowly for Joel after the first couple times he launched it. Still, I understand Joel’s lack of faith, given Apple’s history of dubious performance claims (e.g. ‘PowerPc’s are super computers’) and the multimedia shit-fest they inflict upon Windows users just seeking Quicktime playback and control over their iPods.

I decided to try Safari myself, and while I never saw anything but zippy load times, the rendering and Javascript performance didn’t impress me. Surely rendering and Javascript engines claiming a 1.6x speed advantage over those in Firefox should translate into more responsive dynamic reflows or at least some kind of visible benefit, yes? Well, in casual browsing, I couldn’t see any difference. Then I tried the only Javascript speed test that really matters: dragging in Google Maps.

The verdict in purely subjective testing: dragging the map in Safari, compared to in IE, is a noticeable improvement, but is crap compared to Firefox (even with 7 plug-ins running, including Firebug, which has some bug/feature that eats your memory as you drag the map).

So even if Apple truly conducted its benchmarks honestly and with an inquisitive bent towards finding the user-subjective truth, they’re simply wrong: Safari is not The World’s Fastest Browser (TM).

UPDATE:

The experience I reported was when dragging a Google map with a large display area, but the difference between the browsers becomes less pronounced for a smaller area map (though Safari always seems to have annoying brief stutters).

When it comes to adding and removing many markers from a Google map, Safari does far better than Firefox: adding ~60 markers to the view took almost 10 seconds in Firefox but only 2 seconds in Safari. The problem is that, once you have that many markers on your map, it can be dragged with usable smoothness in Firefox but not at all in Safari (you can still click-and-drag, but the map won’t move until you release, at which point it will warp to its destination).

In a post on user search behaviors, Jeff Atwood links to this report on how quick users are to judge websites. Ironically, upon viewing that report, a full minute passed before I noticed the left column did not consist of Google ads but rather of intra-site links, and in fact, there are no ads on the page at all. I guess the lesson is that, while some sites deliberately blur the visual distinctions between their ads and content, other sites—even those without ads—should be careful not to do the same accidentally.