Leading items

The Grumpy Editor encounters Firebug

Those who have been paying close attention may have noticed a number of changes to the LWN site over the last few weeks. Most of those changes are not visible; our quaint early-90's table-oriented HTML is slowly giving away to a more contemporary design which makes use of the features of cascading style sheets. This sort of work involves a lot of change-and-reload cycles in an effort to figure out why something is not rendering as your editor intended. CSS is a powerful but sometimes obscure technology. One tool your editor wishes he had stumbled across earlier is Firebug, a Firefox extension designed to help with just this sort of work.

Firebug can be thought of as a sort of interactive debugger for HTML and CSS. It is not an authoring tool; it is assumed that content is being created by other means. It is, instead, a way of figuring out why things look the way they do and how to make them come out better.

To that end, Firebug includes an interactive HTML inspector. It's a sort of "view source" window, but done in a much more useful way. By using the "inspect element" option in the Firefox content menu, a web developer can find the HTML for a specific item in a hurry. The display of the document tree is hierarchical, making it easy to see how elements relate to each other. Editing of element attributes is a matter of clicking on them and entering new values; numeric attributes can also be adjusted up and down with the arrow keys. As a result, it is easy to make quick HTML changes and immediately see what the results are.

It is also possible to edit the text contained within the elements, but the interface is somewhat awkward. But this is not a functionality which really matters anyway; Firebug is about markup and rendering, not the content itself.

Positioning the mouse over an element in the HTML inspector highlights the corresponding part of the displayed document. This feature can be useful in correlating the two windows, but it also leads to extensive flashing and blinking as the mouse moves through the window. Something a little less distracting and gaudy would be more to your editor's taste.

The HTML inspector also features a pane which shows the stylesheet entries relevant to the element of interest. The entire cascade is shown, with overridden attributes marked. As a result, it is easy to see where all of the rendering parameters for an element are coming from. Anybody who has worked with CSS for a while knows that the combination of selection rules and cascading can lead to mysterious effects at times. The CSS display removes the mystery, making the source of strange behavior obvious. Once again, CSS parameters can be tweaked on the fly, making it easy to adjust attributes until things fit together just right. One shortcoming here is that adding new attributes does not appear to work in any useful way; it seems that attempts have been made to support this functionality, but your editor was unable to make it work.

There is a separate "layout" display which shows how the various parts of the CSS box model come together in the rendering of a specific element. The values of the margin, border, and padding attributes can all be adjusted on the fly, and a set of rules shows how each plays into the final positioning of the element on the page. Your editor, who has often used the old trick of turning on borders to see how an element has been placed, likes this display better: it separates out the effect of the various attributes and does not, in itself, change the rendering. So questions like "where is that extra white space coming from?" are easily answered. One complaint here is that changing the border parameters is pointless if border style is none (which is the default); it would be nice to be able to play with border styles in the same place.

Finally, there is a mode for playing with stylesheets as a whole. In this mode, the entire stylesheet is available and attributes can be tweaked to see what their effect is on the page as a whole. There is a toggle for every attribute allowing it to be turned off. New attributes can be added - that feature seems to work on this screen. What is missing is any way to save the results of changes.

For those who are concerned with page load times, there is a mode which shows, in bar-graph form, just how long each component of the page took to load. It is possible, in each case, to look at the request and response headers associated with that loading. This feature is probably not one which will be heavily used by most web developers, but it can be useful if a specific page is loading slowly for any reason.

LWN is not a site which makes much use of Javascript, so your editor has not played with the Javascript-specific features of Firebug. Those features look impressive, though. There is a complete interactive debugger, a profiler, a DOM inspector, and more. The HTML inspector, unlike the Firefox "view source" feature, shows what the document's HTML looks like after it has been mangled by Javascript code. All told, it looks like a nice package for those doing that kind of work.

"View source" has always been a fundamental part of how web pages are designed. So it is not surprising that Firebug supports this mode of operation very well. But trying to figure out how a CSS designer got a specific effect from the standard "view source" screens is, with modern pages, often a painful experience. Firebug takes a lot of the pain away by making it easy to look at specific elements and the CSS declarations which affect them. In general, Firebug is a tool which gives a highly useful view into just how the browser is rendering a document. It has become an important part of your editor's toolbox.

Comments (26 posted)

Ruminations on software freedom

The failure of Microsoft's anti-piracy servers over the weekend would seem an easy entree to some Redmond-bashing, but there are far more important issues to consider. It is sometimes easy to forget about the "freedom" in free software, but that is exactly what protects the users of Linux and other free systems from this kind of misfeature. Using proprietary, closed source software with a decidedly one-sided license agreement is not wrong, per se, but should be considered carefully – not just entered into blindly as is often the case.

With a name that seems like the straight line of a joke, Windows Genuine Advantage (WGA) is the "service" that Microsoft uses to attempt to detect and semi-disable copies of Windows that it concludes have been illegally installed. Each copy checks in with a remote server, sending over some hardware and software profile information to determine if it is properly licensed. Any number of things could happen to a "pirated" copy, but currently XP users get a popup that alerts them to their piracy, while Vista users get some – supposedly non-critical – features disabled. All of which might be reasonable for a truly pirated copy, but for users who are properly licensed, it is annoying, at best, to be treated as a criminal.

For approximately 19 hours starting on Friday 24 August, the WGA servers were not working correctly; some 12,000 machines that checked in with them during that time were marked, incorrectly in the vast majority of cases, as pirated. The first responses from Microsoft technical support indicated that it might be several days before the service was back: "kindly try to validate again on Tuesday 28 Aug 2007." In fact, the WGA team identified and fixed the problem in less than a day, but it highlights that the default or failsafe condition for WGA is "pirated." Vista users were particularly incensed as they had to endure reduced functionality of their fully legal copies of the software.

The reactions of some users to the WGA blog posting announcing the fix were rather telling. Thanking Microsoft for fixing the problem – which they, of course, created – so quickly and over a weekend, while writing off any angry users as cranks, makes it seem that everyone should be thankful that they have any software at all. Many users are willing to cede control of their software to the vendor.

Microsoft is not alone in the practice of software and hardware validation, many copy protection and license key schemes depend on some kind of matching between the key and the hardware it is licensed for. Other vendors snoop on their users, in the interests of cheating prevention in games for example, and report back to central servers. Skype was recently found to root around in Firefox profiles for unknown (possibly benign) reasons. It comes down to a question of who controls the system, both hardware and software, that one has purchased.

The control issue comes in other forms as well. Proprietary data formats are one of the current battlefields. It is rather amazing that folks will pay lots of money to lock up their data in a format that they will probably be unable to read in ten years time; unless they periodically convert it to use the latest format. So-called Digital Rights Management (DRM) is yet another control scheme that imposes restrictions, determined by the vendor, on books, videos, music, and the like. These restrictions are not arbitrary, the sellers try to optimize their income by imposing constraints that won't chase away the majority of their customers.

There are tradeoffs here, folks are generally willing to trade their freedom for the latest whiz-bang software feature or a copy of the latest movie. They rarely think of it in those terms, however. The copyright owners may be within their rights to try to get buyers to agree to their terms; so far, they have largely been successful. There are hopeful signs that people are waking up, recognizing these schemes – DRM, proprietary formats, anti-piracy authentication, etc. – for what they are, an unabashed attempt to control as much as they can get away with.

It will be very interesting to watch how the "iPod generation" reacts when the iPod is no longer the music player of choice. All of the music that they "bought" from iTunes will not play elsewhere. Apple will, in all likelihood, make it as hard as possible to migrate to another player, even if their market dominance in digital music players has passed. Users will be left with no choice but to "buy" the music again, which is great for the record companies, but not so much for the users.

Google Video users ran into the same problem recently, their DRM-infected videos were to stop playing after 15 August. After initially mishandling the revocation, along with a poorly received refund plan, Google has since relented, offering a full refund and extending the life of the videos until February 2008. With luck, users who have been bitten by these schemes will demand DRM-free versions when they make their second purchase.

Users of free software and open formats are largely immune to this kind of silliness. There is no "Linux Genuine Advantage" server running in Linus Torvalds' basement, checking to make sure we are properly licensed. Even the commercial Linux vendors, whose livelihood depends on support subscriptions, cannot get away with enforcing WGA-like schemes; free software can be rewritten, legally, to avoid them. Red Hat, Novell or others cannot reduce your functionality or hold your data hostage, there is no lock-in.

Free software and open formats provide freedom, which is easy to overlook when using them on a day-to-day basis. One can feel very secure that a file created using OpenOffice.org or Gimp today will be readable by something – those applications may be long gone – in 50 or 100 years. Assuming that the data stored on our backup media today can be retrieved in the distant future (and that may be a big assumption), the documents, music, pictures, etc. that were stored there will undoubtedly be retrievable. If someone can find compatible hardware, distribution Live CDs will boot and run, without authenticating anywhere. Proprietary and closed format users have no such assurance.

Comments (21 posted)

A first look at the OpenMoko Neo 1973

The hubbub over the iPhone is old news now, unlocking it from AT&T is the big story these days. Another phone – one which may actually deliver what many were hoping for with the iPhone – arrived in the LWN laboratories a few weeks ago: an OpenMoko Neo 1973. The phone, pictured at right (Apple's large handed model was not available), is compact and reasonably light; it looks very different from other cell phones. The hardware seems to be working fairly well at this point, but the software is lagging, which is likely to delay the consumer launch, currently slated for October.

This device is the first to run the OpenMoko software platform. Because it is the first, it is being called the "OpenMoko phone," but the company, OpenMoko, Inc., is clearly hoping to have other manufacturers use the software platform on their own hardware. Their business model is quite different from most in the consumer electronics world as they are very open about their hardware specs as well as their product roadmap. An unlocked phone running free software is obviously their goal; no doubt they would like theirs to be successful, but they are doing everything they can to see that the overall goal is reached.

The Neo hardware is fairly powerful, a 266MHz ARM processor with 128M of RAM and 64M of flash for running Linux and the applications. For additional storage, it has a Micro SD slot, tucked underneath the Subscriber Identity Module (SIM) slot; both live underneath the standard Nokia battery. The back plate is rather easy to remove to get to the battery compartment, though it seems unlikely to pop open unexpectedly; the hardware design seems quite well thought out.

There are several connectivity options, starting with the quad-band GSM radio, which allows it to use cellular networks throughout most of the world. The radio also supports General Packet Radio Service (GPRS) for (slow) data connections, as long as the carrier and contract support it. Bluetooth 2.0 and USB 1.1 round out the communications choices. For the development hardware, there is no charger, USB from a host provides the battery recharging.

There is a GPS receiver in the phone, unfortunately one with a closed-source driver that is not distributed with the phone. There are efforts underway to reverse-engineer the binary driver and produce a free alternative. Once that is done, GPS applications can be written to take advantage of the device.

The touchscreen display is a sharp, 2.8-inch diagonal active matrix at 480x640 resolution which is reasonably easy to see in full sunlight (as long as you tilt it out of the glare). The Neo comes with a combination pen, mini-flashlight and laser pointer to be used as the stylus, which is a useful combination, though leaving ink behind on the screen seems a bit worrisome. There are only two buttons on the phone, one for power and one auxiliary (AUX), both flush with the case to prevent accidental button hits.

Software is going to make or break any phone project and OpenMoko seems a bit behind in that area. They just announced a complete overhaul of the user interface to be easier to use with fingers, rather than a stylus, and to incorporate what has been learned while using the real Neo hardware. Much of the software was written using emulators; what is easy on a monitor with a mouse is not necessarily so easy on a touchscreen using fingers, particularly when the screen is recessed, making the edges harder to use. The older startup screen is shown on the left, the newer to the right.

Some of the major applications (dialer, contacts, calendar, etc.) have been ported to the new interface (called 2007.2), but there is still a lot of work to do. Both old and new interfaces suffered from poor response and some application and UI crashes. The applications themselves are very rudimentary, probably too simple for what cell phone users expect, but they are a good start.

Actually connecting and registering with a cellular network was a manual process in the most recent build. Once some fiddling was out of the way, though, the phone could make and receive calls. Audio quality was mediocre and there seems to be some kind of echo cancellation problem for the audio at the other end. Those kinds of problems need to be high on the developers' priority list, without rock-solid basic phone functionality, consumers will be uninterested.

For a Linux user, it is unarguably cool to be able to ssh into your phone and poke around in the guts of the system. By using USB networking, a simple ifconfig on the host allows connections to the phone. Logging in as root puts you into a shell with BusyBox installed for many of the standard Linux utilities. By configuring the host as a gateway, the phone can access the internet (presumably via GPRS as well). This allows the use of Ipkg to update the phone software in the same way that apt-get and friends are used. There is also a terminal application, shown at right, which provides a root prompt on the screen, though making it bring up an on-screen keyboard was not obvious.

This phone clearly has a lot of potential, but it also has a long way to go to reach the polish that the iPhone is rumored to have. Its strongest feature, though, that it is not tied to any particular carrier, might be enough to carry it in the early going. In addition, carriers will not be able to lock out "foreign" ringtones or only allow their games and applications to be installed. OpenMoko, both the company and the software, are truly trying to live up to their Matrix-inspired slogan: "Free your phone".

Hopefully, the OpenMoko company has the resources to carry it through for a while, until the software catches up with the hardware. If not, though, the software is free, some other company could pick up where they left off. That would be unfortunate, as we look forward to following the development closely; we don't want to wait another year or more for a free (as in freedom) phone. We will keep you updated as things progress.

Comments (54 posted)

Page editor: Jonathan Corbet
Next page: Security>>