Leading items

Rethinking linux.conf.au

Linux.conf.au has long been one of your editor's favorite events anywhere in the world. It typically features one of the most diverse and interesting programs and is hosted in a different city every year. And the whole thing is fueled by that classic Australian energy and humor — even when it is held in New Zealand. With well over a decade of history, LCA seems like a solid and well established event. So it was a surprise to run across a discussion suggesting that there might be no LCA in 2014. LCA, it seems, has found itself needing to rethink how the conference is organized and run.

Linux Australia council member James Polley started the discussion with a post on the current status of LCA 2014:

James noted that LCA was once the only major community conference in Australia; now, instead, there are several. Perhaps, he surmised, there is no longer a need for LCA? Or, perhaps, it is time to move from volunteer organizers to a professionally-managed event? Or, perhaps, it's time to take a break and see if any interest develops for 2015?

Participants in the discussion raised a lot of concerns that the conference has simply gotten too big and complex. Potential organizers, they say, are being put off by the sheer time commitment required. Some past organizers (such as Russell Stuart, Brisbane 2011) disagreed, saying that the actual time required is not as much as it seems. But there is no denying the fact that LCA organizers tend to look awfully tired and haggard even at the beginning of the event and thoroughly fried by the end. Putting together a conference like LCA is a lot of work.

So it is natural to think about ways to reduce that work. Perhaps LCA should go back to being a smaller event? There were proposals to reduce the number of talk tracks, eliminate various social events, and even to drop the 1-2 days of miniconfs that precede the conference itself. LCA did not originally include miniconfs; they were first added by the Brisbane team in 2002. But the miniconfs have since become an integral part of the conference. Their contents are not under the control of the program committee, with the result that the areas covered — and the quality — vary widely. But the best miniconf talks tend to be quite good indeed, and the miniconfs serve as an important entry path for speakers trying to get into LCA proper. It would be a shame to lose them.

Another idea that came up was to settle down and have the conference in the same city every year. That, in your editor's opinion, would risk repeating the story of the Ottawa Linux Symposium. There is a long list of reasons for that once-dominant conference's decline, but one of them was certainly the organizers' unwillingness to move the event to new locations. Even a city as nice as Ottawa gets a little tiresome after several years in a row. A new location every year helps to keep LCA fresh and interesting.

The volunteer organizer model also helps in this regard. LCA has managed to evolve a mechanism where each year's team is given a great deal of freedom in how it runs the conference. Behind the scenes, though, a "ghosts" committee (made up of prior organizers) oversees the effort, provides advice, and sounds the alarm when it sees something in danger of going wrong. The end result has been a conference that is, in some ways, new every year, but which still runs like a smoothly oiled machine.

A shift to a professionally-organized event might take some strain off the volunteer organizers but it would have to be done carefully if it were not to kill the magic that has made LCA such a good event for so many years. That would not be impossible to do; the Linux Plumbers Conference has thrived with a great deal of organizational help from the Linux Foundation. Such a setup requires professionals that are willing to defer to the "amateurs" for most of the important decisions; it can be done, but it's not something that happens by itself.

Donna Benjamin (Melbourne 2008) thinks that workload issues could be addressed, perhaps with the help of professional organizers and a team that is distributed across the country. But, she says, there is another, more difficult problem: the fact that the organizing team must sign up for a lot of criticism from the community.

This sentiment was echoed by a number of other participants in the discussion. In our community, it seems, no good deed goes unpunished; even an event as well run as LCA is going to draw its share of complainers. When a difficult job starts to appear thankless as well, the number of volunteers is certain to decrease. But potential organizers should also heed the words of Andrew Ruthven (Wellington 2010):

Finally, one could also argue that most conferences have a limited lifetime. Linux Expo and LinuxWorld are long gone. Even the much-respected Linux-Kongress, arguably the first Linux conference, was last held in 2010. LCA, having started as the Conference of Australian Linux Users in 1999, has certainly had a long run. Perhaps LCA, too, is reaching the end of its life span?

Your editor does not believe that to be the case. We are not witnessing a conference heading into senescence; instead, it is a middle-age crisis at worst. There is too much that is valuable and unique worldwide in LCA, and the people who attend the conference every year clearly appreciate it. LCA can be seen as a sort of free software project that, after years of success, needs to reevaluate its processes and governance. Once that task is done, LCA is likely to be stronger and more vital than ever.

For 2014, the deadline for bids has been extended for a few weeks, so there is still a chance for interested groups to sign up for a chance to host the event. There is talk of putting together a distributed team that, most likely, would propose to return LCA to Sydney. One expects that somebody will step up to the plate and make the event happen; who knows, perhaps 2014 will be the year that LCA finally is held in Broome.

Comments (11 posted)

PowerTOP tops up to 2.1

You may run free software, but electricity still isn't free. Until it is, monitoring and minimizing power consumption is a necessary evil. Intel released version 2.1 of its power-consumption utility PowerTOP on August 15. PowerTOP has been around since 2007, but the 2.0 release from May 2012 heralded a major rewrite of the code and a shift for the project itself. 2.1 builds on the new design, adding a handful of new features, but if it has been a while since you examined PowerTOP, you may be surprised at how much it has grown.

The new and improved

As the name suggests, PowerTOP monitors system power consumption and reports its statistics to you in a top-like summary. It also makes suggestions for system tweaks that could improve the power usage profile of your system, including everything from peripheral device options down to processor performance states and scheduler settings. In PowerTOP's early days, most of these recommendations were tweaks that the user or system administrator would need to manually apply. Over time, however, the various Linux distributions began to use PowerTOP as a profiling tool to automatically track down optimal settings, which would become the out-of-the-box defaults. This shift in usage patterns was one of the reasons maintainer Arjan van de Ven cited for the rewrite that became 2.0.

Two other factors Van de Ven cited were the unstructured way in which more and more features had been bolted on to the code base, and that PowerTOP is increasingly used as a diagnostic tool to track down specific power consumption problems — such as an errant application or driver — rather than profiling an entire system. As a result, the 2.0 rewrite refactors the code with an eye toward making subsequent extensions easier to add, and it provides a report-generation facility that can output CSV or HTML diagnostic reports suitable for later study.

The 2.x series also utilizes the kernel's perf events subsystem to gather processor-related data, which leads to more accurate numbers. The project has been steadily adding support for additional power-management features in hardware; the supported list includes CPUs, GPUs, storage devices, and an extensive collection of peripherals (network controllers, audio chips, USB adapters, and so on). The 2.1 release itself adds support for monitoring processor cores without performance states (a.k.a. P-states, which correspond to different clock frequencies). This is primarily useful for GPUs, which do have power states (or C-states, which allow the system to put the processor to sleep in stages), allowing inactive cores to be powered-down, but do not have the frequency scaling features now common in CPUs.

In addition to the technical changes, the 2.x series saw the project move away from its original home at lesswatts.org and into Intel's new open source project warehouse at 01.org. The new site hosts news updates, downloads, and a new mailing list. Unfortunately this change meant cutting off the site from several years' worth of mailing list archives and existing online documentation at the old site — although for the time being lesswatts.org remains online. In other changes, the source code is now hosted at GitHub, and the project is using Transifex for UI string translation. The 2.1 announcement advertises nine languages at present, which is not many in the grand scheme of things, but signals an improvement. Compiling PowerTOP is a simple affair; it uses autotools and has few dependencies. The main issue to consider is the kernel version of the machine you wish to profile: 2.6.36 is required for perf support, and newer kernels add additional measurement tools.

Usage

PowerTOP has two major operating modes: interactive monitoring and report generation. Running powertop (as root) launches the interactive mode, which provides a five-tab ncurses monitor. The overview tab sports a summary line displaying the current number of wakeups-per-second, GPU operations-per-second, virtual filesystem (VFS) operations-per-second, and CPU activity. Beneath this line is a list of power-consumption events of various types (for example, network activity, active processes, and interrupts). CPU information is split into two tabs: Idle Stats and Frequency Stats. The former shows C-state information as an activity percentage for the processor package and for each core; the latter reports the same information labeled with the actual clock frequencies rather than the C-state level.

The fourth tab, Device Stats, contains power usage information from the other hardware devices on the system: the battery (where applicable), screen, GPU(s), networking hardware, and everything else. For laptops, PowerTOP reports the battery's discharge rate, and estimates the discharge rate of the other components. For an accurate report, however, you should first run the calibration routine with powertop --calibrate. This will cycle through the hardware options (e.g., the supported backlight levels) and log the power consumption characteristics. PowerTOP supports even more accurate measurement with a USB-attached power analyzer tool from Extech, although considering the four-digit suggested retail price of said instruments, you would need to tweak quite a few machines to recoup the investment in electricity bills.

The fifth tab, Tunables, lists system settings that can affect power consumption performance. Highlighting an individual entry allows you to toggle the setting on or off with the Return key, so that you can quickly assess its impact. Most of the controls are sysfs parameters (such as SATA link power management or USB device auto-suspend), but others involve separate interfaces (such as wake-on-LAN status for Ethernet adapters). The tab sorts the list into "Good" and "Bad" states, with the Bad listed first, so you can quickly work your way through the list and see if you notice a difference.

PowerTOP's other mode is report generation, which you can invoke by running either sudo powertop --html or sudo powertop --csv. The CSV output is essentially the same information as that presented in the first four tabs of the interactive mode, with header information demarked by asterisks. The "Tunables" information is listed as well, but the commands required to alter each setting are not supplied. The HTML output presents the same information in a nicely CSS-styled HTML file, complete with element classes on each table cell that might allow further customization or processing.

A bit more interesting, however, is the HTML output's Tuning tab, which includes the command necessary to change each "Bad" setting — for example:

    echo 'min_power' > '/sys/class/scsi_host/host0/link_power_management_policy'

This is particularly helpful for bus devices whose specific address would be hard to guess at otherwise, such as /sys/bus/pci/devices/0000:00:1f.2/power/control or /sys/bus/usb/devices/3-2/power/control. One of the lingering gripes many end users have about the program is that the changes they make to device settings do not persist after reboot. PowerTOP's stance is that it does not want to be in the business of writing permanent or semi-permanent changes to the system configuration — for a number of reasons, including the fact that such changes can introduce performance or even stability problems. But having the correct commands at the ready allows the user to assemble a start-up script with little hassle, whether the machine in question is an old netbook with battery trouble or an expensive server.

In addition to the broader changes discussed above, each release of PowerTOP tracks new features available in updated processor and device architectures. The latest releases, for example, have improved support for ARM power management features and for Intel graphics adapters. But even if your processor is already well-supported, the project has made impressive improvements in data collection and in presenting its findings is human-consumable terms. I last looked at PowerTOP in late 2008, so by comparison the advancement of the feature set seems dramatic. But the more important factor is that it has proven itself to be a useful diagnostic tool, and it allows even novice users to instantly apply and test power management options — which could at least de-mystify the world of power-saving, one system at a time.

Comments (24 posted)

Look and feel lawsuits, the second time around

The thicket of lawsuits surrounding the mobile industry has grown to the point that it is hard for any individual action to stand out. If any case has managed to make itself visible in that crowd anyway, it is the battle between Apple and Samsung currently being fought in the US. The first stage of that battle has just been resolved, heavily in Apple's favor. It will be some time before this story truly reaches its end, but some of the more interesting implications for the industry, and for free software, can already be seen.

Let's take a moment to look briefly at the history of the industry, because this is not Apple's first attempt to eliminate competitors with litigation. Back in 1988, Apple sued Microsoft for the crime of offering a system that placed icons and overlapping windows on the screen. Apple didn't invent the graphical display, of course, but it still asserted the right to be the only company offering such displays in the market. At that time, the Free Software Foundation announced a boycott; none of its software would be ported to A/UX and purchase of Apple products would be discouraged. Chances are that an FSF boycott in 1989 failed to make Apple's executives reconsider their business practices in any serious way, but it did convey a loud and clear point. The boycott was maintained until after Apple finally lost the suit and gave up.

Apple is currently engaged in a second round of look-and-feel lawsuits; the big difference is that, this time, they appear to be winning and there is little response from the community. Indeed, we enthusiastically buy their hardware and port our systems to it. Perhaps, soon, we'll have rather fewer alternatives.

This time around, Apple accused Samsung of violating three utility patents: 7,469,381 (bouncy scrolling), 7,844,915 (pinch-to-zoom), and 7,864,163 (tap-to-zoom on a web page). Samsung was also accused of infringing four design patents: D504,889 (rectangular electronic device), D593,087 (ditto), D618,677 (ditto again), and D604,305 (iconic application directory with a dock at the bottom). The jury concluded that Samsung had indeed violated all of those patents with the exception of 504,889, the most tablet-like of the design patents. Apple has been awarded a bit over $1 billion, and there will soon be discussions regarding blocking various Samsung products from the US market. Samsung's countersuit, which involved some patent infringement claims of its own, lost out entirely.

Amusingly, some commentators have begun to say that this outcome is, in fact, a significant win for Samsung. For a mere $1 billion, the company was able to break into the smartphone market in a big way; that looks cheap when compared to how much some other companies have spent. Meanwhile, Apple can be said to have proved, in a court of law, that Samsung's products are just as good as its own; maybe that will translate into more Apple customers being willing to check out iStuff alternatives. These ideas seem a little far fetched, but one never knows.

Victory or not, this ruling will certainly be appealed. There are various allegations that the jury, in a rush to protect a US company from a foreign competitor, disregarded the instructions it had been given and did not even consider many of Samsung's claims. But, even without the possibility of invalidating the jury's ruling, an appeal would make sense: it will keep the matter open long enough for most of the products involved to reach the end of their normal commercial lives, and large monetary awards are often reduced on appeal. So expect this story to play out for a while yet.

It's worth pointing out another reason for this story to be a long one: this is not a USA-only fight. Apple and Samsung are fighting the same battle in several countries around the world; one amusing result is that products from both companies have been banned in South Korea. Samsung has been struggling in Germany as well; other countries could well join the list. Software patents may be mostly a problem in the US, but design patents are much more widely recognized.

One good thing about design patents, though, is that they are usually relatively easy to work around. Indeed, Samsung is already doing so; for details, see The Samsung Galaxy S III: The First Smartphone Designed Entirely By Lawyers on the Android Police site. The device in question (The Galaxy S III) is not quite rectangular, uses a different rounding radius on the top and bottom corners, is not black, etc. Only one of the workarounds requires software changes: the dock disappears when the application directory is brought up. Mostly trivial stuff; one may argue that giving Apple a monopoly on black rectangles with rounded corners is unfair, but it also does not make things that much harder for competitors.

The utility patents are another story, of course. Arguably the most significant problem in this particular set of patents is the concept of zooming the display with a two-finger gesture. That gesture has become sufficiently universal that a device lacking it will feel decidedly inferior. As numerous commentators have noted, it is somewhat like giving one automobile manufacturer exclusive rights to a circular steering wheel.

But the real problem is that things won't stop there. Every company involved in this market will continue to bulk up on these patents, and they will continue to assert them against each other. Many of these patents will come closer to what we do in the free software community. It will become increasingly hard for anybody to field a mobile product until somebody, somehow, cuts through the thicket. What is really needed is some sort of reform of the patent regime. Perhaps this very case, should it make it to the US Supreme Court, could play a role in that reform. Failing that, we're left depending on politicians to fix the problem; that, unfortunately, seems like a long shot indeed.

Comments (163 posted)

Page editor: Jonathan Corbet
Next page: Security>>