Leading items

An uphill battle for LibreOffice

LibreOffice (LO) keeps chugging along, with another bug fix release on May 2. Meanwhile, Apache OpenOffice (AOO) nears its first release and is starting to plan for what comes after AOO 3.4. But a recent blog post by developer Michael Meeks highlights a special challenge faced by LO: making a name for itself.

The OpenOffice "brand" has been a successful one. Many users have heard of it as an alternative to the proprietary office suites (notably Microsoft Office) and that is where they turn when they are looking. But, as Meeks points out, there has been no OpenOffice release in 16 months or so and the features of the suite have been essentially frozen for an additional six months. Largely because of the brand, though, "users are still downloading this increasingly old and creaky release at top speed", Meeks said.

He also put together a feature comparison that, not surprising given the source, shows LO with a substantial feature lead. One would guess that AOO partisans might find things to quibble with in that chart, but it isn't grossly inaccurate by any means. Because LO didn't suffer from some of the impediments that have stood in the way of AOO progress—Oracle's disinterest, followed by the move to Apache which necessitated a lot of changes—it has surged ahead feature-wise, and quite possibly community-wise as well.

One place it hasn't made its mark, however, is in the name recognition arena. Linux users can be forgiven for wondering what the fuss is about given that most distributions switched to LO more or less immediately after it was first released. But, as we are reminded ad nauseam by the media, Linux desktop users make up a tiny fraction of the market. For good or ill, to be a successful player in the free office suite world, Windows (and, increasingly, Mac OS X) is where the battle will be won or lost.

That's not to say that LO needs to "overtake" OpenOffice in order to be successful, but its developers and backers want to see it have a significant presence. That's perfectly understandable, but it will be something of an uphill battle now that there soon will be a viable successor for the OpenOffice brand. In fact, as Meeks notes, it's already been an uphill battle even without a viable competitor.

Brand recognition is a tricky problem to overcome. As we have seen over the years, technical merits are only a limited factor in which brands come out on top and which fall by the wayside. While LO may currently have features that AOO lacks (and vice versa, but the problem is mitigated for LO to some extent by the permissive license on AOO code) that gap may shrink over time. In a year or two, it's possible that there may be two roughly equivalent free software office suites supporting the same data formats and incorporating most of the same features.

Beyond the existing feature sets, many of the differences between LO and AOO are largely invisible to users. Most users don't choose their software based on its license—perhaps unfortunately—even if they did, it's not at all clear whether copyleft or permissive would be more attractive. The code cleanups and other streamlining that LO has done makes the code easier to work with, though that is disputed by some in the AOO camp, but that kind of work doesn't really directly show itself to users. That leaves brand identity as the main distinguishing element.

Now that the vote has passed, AOO 3.4 should be officially released any time now. In addition, AOO mentor Ross Gardler thinks the project is well on its way to graduating from the Apache Incubator to become a full-fledged Apache project. Once that initial, largely procedural hurdle has been cleared, it will be interesting to see where things go.

For one thing, regular AOO updates mean that security updates can be quickly addressed with actual binary packages, rather than by releasing patches that users are expected to build for themselves. The long-awaited code drop of IBM's Symphony fork appears to be imminent as well. That should bring a whole slew of features that will be of interest to users. While some have questioned whether AOO is really a project dominated by one large company, IBM, Gardler does not believe that is the case—which bodes well for the project as a whole.

The Symphony features, as well as the "line caps" and other drawing improvements that come with AOO 3.4, are likely to be incorporated into LO as well. The real question is how much, if any, of the improvements that LO makes can be incorporated into AOO. The Apache license will allow things to flow into LO, but even the dual-licensed (LGPL/MPL) portions of LO may not be acceptable for an Apache project. But, in terms of differentiating itself, LO would do well to come up with its own new features. One "killer feature" might well be enough to start the "brand recognition" ball rolling—adding a few more might go a long way toward erasing AOO's lead.

Beyond that, though, it would seem that LO and the Document Foundation have some work cut out for them just in terms of getting the message out about what Meeks calls "the new, exciting, much more featureful, and fun suite". His post was a clear call for LO fans to assist in the effort to raise the profile of the LO brand. That too will be interesting to watch.

Comments (19 posted)

The plumbing layer as the new kernel

Last week's Unix wars article discussed the long-feared possibility of Linux fragmenting into a number of incompatible—and weaker—systems. Before leaving that subject behind entirely, it is worthwhile to take a look at an effort that is intended to be a unifying force in the Linux community: the growth of a well-defined and actively developed "plumbing layer." By wrapping the kernel in layers of higher-level software, the plumbers hope to create a new core that will function similarly across all distributions. Thus far, we have not seen clear evidence that all distributions want to play along, though.

The kernel has long been the unifying force across Linux distributions. Especially in recent years, as distributors have worked harder to stay close to the mainline, the kernel is one thing that could be counted on to be nearly the same on any system. The layers on top of the kernel can vary widely between distributions, though, with some distributors, such as Android, having replaced almost everything above the kernel with their own code. That creates differences between distributions that can make life harder for users, developers, and for the maintainers of the distributions themselves.

There have been attempts in the past to create a common distribution core at a higher level than the kernel. The Linux Standard Base is one such endeavor, but, despite years of effort and lots of resources poured into it, the LSB has never been hugely helpful. Its lowest-common-denominator focus left much of the system uncovered, and its stated intent of making life easier for distributors of binary software has failed to create excitement in the community. Another effort was the ill-fated United Linux project; it may well have failed in any case, but it was certainly doomed by having the SCO Group as one of its founding members. Since then, there have been few overt efforts to create a common distribution core with the arguable exception of Debian, which has always, to some extent, seen itself as being that core.

What we have seen in recent years has been an effort to bring together and organize developers working in the "plumbing layer" that wraps the kernel. This layer is not precisely defined; it includes the bootstrap and initialization systems, udev, communications mechanisms like D-Bus, and related utilities. Interestingly, the C library—the layer that intermediates most access to the kernel—has typically not been a part of that group; perhaps that situation will change as a result of the more community-oriented focus in the glibc project.

The Linux Plumbers effort was never explicitly envisioned as the creation of a new common distribution core; instead, it was just a way to help developers work together and make the system better. Recently, though, things have started to change; in particular, much of the work on systemd has been justified with the claim that it would work to reduce fragmentation between distributions. Systemd is tightly tied to the Linux kernel—it will not run anywhere else—and is meant to integrate many of the kernel's features into a tighter, well-functioning, and quickly evolving system. That system then becomes the core of a modern, fast-moving distribution.

A number of people have commented on this trend; see this recent remark from Martin Langhoff or this Google+ discussion, for example. There are some clear benefits from moving in this direction, but some challenges as well.

One challenge is ABI stability. Kernel developers try hard to ensure that they do not break applications as the kernel evolves. That policy is unlikely to change anytime soon, but the truth is that there are some in our community who would like to move the stability commitment further out, allowing the ABI between the kernel and the plumbing layer to change in incompatible ways. Such changes should not bother users as long as the kernel and the plumbing layer change at the same time, but they would be bothersome indeed if only one of those components changes, or for anybody who is not using the "standard" plumbing code. The ABI stability requirements have proved frustrating to plumbing-layer developers in the past; one can only expect that to happen again in the future.

The other problem is that there will be disagreements on what the larger core should look like; one need only read the many systemd discussions to get a sense for how deep those disagreements are. Assuming that we have achieved all we can through the reproduction of classic Unix systems, there are no precedents for what the Linux system of the future should look like. There are no POSIX standards to guide development. So developers are breaking new ground, and that will always lead to disagreement and conflict.

Add to this disagreement a certain degree of discomfort among developers who feel that they are losing influence over the direction things are going. Debian developer Marco d'Itri expressed it clearly:

There is no special effort to exclude anybody from the development of the plumbing layer. But the usual rule of free software development holds: those who are doing the work have the biggest say in the directions it takes. For better or for worse, many of the developers doing work at the plumbing level have concentrated into a relatively small number of companies. That leaves a number of distributions out in the cold.

It also leaves them with a choice: sign on to this new, unofficial core distribution, or continue to go it alone without. There are plenty of examples of distributions that have followed their own path for many years; see Slackware as the classic example. Gentoo is another distribution that has built much of its own core infrastructure, including its own init system that few people have heard of. It can be done, but there is a real cost in the form of duplicated effort and an inability to benefit from the work done by others.

Predicting how this situation will turn out is not easy. This is a time of rapid change in both the community and the wider industry; it's not clear what is going to work in the long run. But the vision of a more tightly coupled system that can enable Linux distributions to evolve more quickly has some appeal. If these developers can pull it off, they may help to ensure that a unified Linux plays a major role for years to come.

Comments (48 posted)

A report from the Linux Audio Conference

[ Author's note: In contrast to my usual style, the following article is a largely non-technical account. Future articles will focus on the configuration and use of particular pieces from the Linux audio applications stack. Meanwhile I hope you enjoy this report, my first for LWN.net. ]

My jet lag is gone, I've finally come back to ground, and at last I can start to sort out my experiences at the 10th annual Linux Audio Conference, held this year at CCRMA, the Center For Computer Research In Music And Acoustics at Stanford University in Palo Alto, California USA. It was the first time the event had been held in the States, and the organizers obviously intended to make a good impression. I'll cut to the spoiler right now to let you know that they succeeded, with honors.

Day 1 Thursday April 12

On the first day I suffered from the predictable problems with coordinating my train schedules, but I arrived in time to hear the latter half of Harry van Haaren's presentation of his on-going development of Luppp, his very cool looping sequencer. One year ago I watched Harry demonstrate his prototype at 3AM in a Maynooth hotel room, but what a difference a year has made. Luppp is rapidly becoming *the* loop sequencer to watch, and Harry has big plans for it. We may even see it evolve into a plugin (LV2 maybe?) or perhaps it will become a part of Rui Nuno Capela's QTractor. If Harry's current rate of progress continues Luppp will be a much-enhanced program a year from now. But right now you can pick up the code, check it out, and let Harry know what you'd like to see in it. You need only ask nicely.

Alas, I missed IOhannes zmölnig's presentation on the IEM Demosuite [PDF] - a large-scale "jukebox" for a concert venue - and Flavio Schiavoni's paper on the Medusa [PDF] network music distribution system. That's pretty much the way of things at this conference - it's simply impossible to take in everything, even when time permits. Nevertheless, I was able to attend most of the presentations I especially wanted to see. And I did finally get to chat with IOhannes, a major developer in the world of Pure Data and its GEM graphics library.

My timing was more fortunate in the afternoon sessions. I caught the tail end of Joachim Heintz's presentation on Csound as a realtime application, and I was able to sit in on most of Steven Yi's report on developing Csound for the Android mobile device. Both presentations were particularly timely - both Csound and development for mobiles were well-represented throughout the conference, indicating the great importance of Csound in the Linux audio world and the rapidly increasing attention given to general audio development on the new devices. As Steven emphasized, the Android OS has some problematic features at this time - its inherent audio latency is perhaps best termed "abysmal" - but the market has spoken and it wants cool audio apps on its devices. Given enough pressure from users (hint, hint), the latency issue can be resolved. Meanwhile, interested programmers should not hesitate to begin their projects for such platforms.

In the first of the final afternoon sessions Robin Gareus presented an update of his work with integrating a video timeline into the Ardour3 digital audio workstation. I've followed Robin's work with his xjadeo video monitor, and I've built Ardour with his timeline patches. His software works, and it is an exciting experience to see a synchronized video timeline in Ardour. However, users should not expect an early delivery date for an official integration. Paul Davis, Ardour's chief designer, has stated that while he favors Robin's patches the stabilization of Ardour3 must come first. Meanwhile, we are free to apply Robin's patches to the Ardour codebase ourselves. Just remember to report your experience back to Robin.

I was eager to hear Yann Orlary's presentation on INScore, "an environment for the design of live music scores". This project has great potential - it allows realtime permutation of a running score, and it can utilize a variety of filetypes as source material (i.e. soundfiles, images, text) as score elements. INScore is rather hard to define until you've seen it in action, and I hoped to watch Yann thrill me with his typical professional report. Alas, his efforts were foiled by not one but two uncooperative machines. However, Yann is a seasoned presenter, and we still got some notion of INScore's possibilities from his excellent verbals.

The final session of the day was presented remotely by Ivica Ico Bukvic via a Skype audio/video connection. Ico reported on his work and experience with L2Ork, his laptop orchestra at Virginia Tech. I've seen and heard his groups in person, and I can testify to the enormous efforts that have gone into their development. The L2Ork group has been performing and touring extensively during the past year, giving Ico a rich source of experience and ideas for improving his own groups and the general model of the laptop orchestra.

Incidentally, I must mention that Ico's remote session was flawlessly transmitted and received, thanks to the terrific work by the conference's audio/video crew headed by Jörn Nettingsmeier and Robin Gareus. Jörn is an experienced veteran of previous conferences, a consummate professional who insists on high standards in audio and video representation. The entire conference was videotaped - the LAC2012 site has announced that recordings and pictures are on-line now - and all sessions were available for remote viewers in realtime video feeds and over IRC.

Day 2 Friday April 13

Oh no, Friday the 13th ! As far as I could tell, nothing out of the ordinary happened, but then the conference was populated by folks already a little out of the ordinary. The day's presentation schedule was organized neatly, starting with a series of reports on Linux in the deployment of multichannel/multispeaker systems, with an emphasis on the use and development of Ambisonics. Following those reports Lawrence Fyfe presented his team's work on JunctionBox [PDF], a very cool toolkit for designing control interfaces for Android devices. Next up, Edgar Berdahl and Julius Smith introduced their Synth-O-Modeler [PDF], a compiler "for open-source sound synthesis using physical models". Alas, I had to miss these last two presentations while I conducted a workshop on the use of Jean-Pierre Lemoine's AVSynthesis, an environment for combining sound and music composition with 3D graphics processing. My presentation focused on using the program's powerful audio capabilities provided by the Csound API. The final partition of the day included a series of reports on projects built around the FAUST DSP programming environment (more about FAUST later), two audio spatialization demonstrations in CCRMA's Listening Room, and Andrew Allen's workshop on his GRE [video] (Graduate Rhythmic Examination) - which can be described as both software and composition.

Day 3 Saturday April 14

Saturday's schedule began with Jörn Nettingsmeier's excellent report on with-height surround sound production with the Ambisonics system. I expect such a presentation to be detailed with considerable mathematics that usually leave me mentally stunned, but Jörn is a most engaging speaker who illustrates theory with real-world practice. Such a presentation method gets more practical information across to the interested composer and musician - e.g. myself - who wants to advance to multichannel/multispeaker output and arrangement. You can check out Jörn's presentation yourself, and I think you'll agree when I say "Jörn, write a book!".

Next up, my keynote address. I had been asked to summarize my experience in Linux audio and to comment on events I considered to be of outstanding importance to that world. I've been using Linux since 1995, with particular emphasis on its use in music and sound composition, though at that time only a few applications were mature enough to compete with similar offerings on other platforms. Without going into the details here - you can view the keynote speech on-line - it's sufficient to say that a lot has changed, in both the quantity and quality of the base sound system and the Linux audio applications stack. However, I refused to make predictions - one simply never knows what might happen - and instead I focused on the understanding and generosity I experienced from so many amazing people as I made my way into the vast world of Linux/UNIX. I was truly ignorant of the simplest things, but I was willing to learn and to put time into basic research before asking basic questions. The willingness paid off, and eventually I was able to make some minor contributions of my own. That history culminated in a book (The Book Of Linux Music And Sound) and a career as a specialized journalist, which then launched my life on to a new path that has led me to that keynote address (and a new gig with LWN!). But as I said, you can follow the entire address on-line. Now, on to the next presentations.

Conference organizer Fernando Lopez-Lezcano reported on a unique project that uses JACK with UDP to send audio as packets over a standard packet-switching network. This project has significance for audio professionals, and a hardware solution was demonstrated that could effectively replace bulky "snakes", i.e. bundles of audio lines connecting stage-located devices to an off-stage mixing desk. Fernando's presentation was followed by a remote transmission from Fons Adriaensen on a method of "controlling adaptive resampling", but alas, another commitment took me away from Fons's talk only a few minutes after he started.

I was able to attend all three of the final presentations for Day 3. These reports included an update in DSP libraries for FAUST, a demonstration of the use of the Pure-Data-based PCSlib in a touch-sensitive UI for music, and an analysis of methods used in one of the compositions performed in the evening concert. All the presentations were interesting to me, but Julius Smith's work with FAUST was truly inspiring. FAUST has great potential for anyone who would like to learn about DSP programming, with the added performance benefit of multiple output targets such as LADSPA (the Linux Audio Developers Simple Plugin API), LV2, and VST plugin formats. I don't claim that anyone can be a DSP wizard just by using it - you'll get more out of it if you know how to put more into it - but FAUST does provide a new-user-friendly entry into a programming domain often equated with a requirement for deep math skills. The third and final presentation of the day was from composer Krzysztof Gawlas, and although it was equally inspiring I'm going to reserve further comment on Krzysztof's work until my report on the conference concert series (see below).

Day 4 Sunday April 15

Sunday's schedule included presentations on the use of C++ in the development of multichannel audio applications and the use of the BeagleBoard hardware as an audio processor. The Minivosc "virtual oscillator driver for ALSA" was also introduced, while Joachim Heintz conducted a workshop on using Csound in live performance. I missed all of those events, but I had a good excuse. I had received a message from Bill Schottstaedt to let me know that he'd be at the Sunday coffee starter. I hoped to meet Bill in person - at one time I worked a lot on the GUI code for his SND audio editor/processor, and Bill's assistance was indispensable. My LISP skills - well, Guile skills, to be accurate - were about non-existent, but Bill must have figured that if I was willing to learn what to do then he'd be willing to help me learn it. I did some neat things with SND, and I acquired a deep respect for LISP and its progeny. I simply wouldn't have got far at all without Bill's help.

So, the opportunity to meet him got me from Oakland to Palo Alto in time for the morning meet-up, where at last I was introduced to the man himself. For the benefit of readers who may not know about Bill Schottstaedt, a brief summary of his contributions to the development of music made with computers would include numerous compositions written for the combination of the KL10 computer and the Samson Box synthesizer; a collection of open-source music and sound software that includes CLM (Common LISP Music), CMN (Common Music Notation), and the SND environment for audio processing and composition, all currently maintained and in daily use around the world; and a variety of seminal articles published in MIT's Computer Music Journal (among others). Bill has a long and productive association with CCRMA, and I was interested in his accounts of his experiences there. As our time passed, we settled in a lounge at CCRMA where we were joined by more conference members, including Dr. John Chowning, the chief designer of FM synthesis (who also happens to be the founder of CCRMA). The conversation was much enriched with anecdotes and stories of the Center's history and the various amazing personalities that have populated - and continue to populate - its hallways and classrooms. Alas, the afternoon passed too quickly, but when the group finally dispersed I think we were all a bit "intoxicated by reason of fascinating discussion".

As the group disbanded I had the further pleasure of a conversation with Oscar Pablo di Liscia and Juan Reyes. I was familiar with Oscar's excellent book Generacion y procesamiento de sonido i musica a traves del programa Csound, but I was nicely surprised when he presented me with a copy of his latest publication Musica y Espacio: Ciencia, tecnologia, y estetica, a collection of articles and essays on the musical aspects of space and the spatial aspects of music. The gift was most timely after a discussion with Aaron Heller regarding an Ambisonics installation for my studio. Composer/researcher Juan Reyes is another one of those remarkable persons CCRMA seems to attract. I knew him only by name until this conference - now I've had the pleasure of his conversation and his music, good ways to get to know good people.

Something must have been in the water bottle in that lounge area, because later another random group gathered there. This group included conference Tonmeister Jörn Nettingsmeier and CCRMA DSP wizard Julius O. Smith, but the mood now had definitely turned towards the musical. Julius found his well-worn Ramirez classical guitar, Jörn pounded out rhythms on an empty water jug, I sang, and everyone else grabbed what they could find to beat, pluck, or breathe into. Given that this lounge is in a building dedicated to research into music and acoustics, it didn't take long for everyone to be playing on some kind of instrument or something that resembled some kind of instrument. It suffices to say that hilarity ensued until we all left for the after-conference dinner/celebration for even more talk and a last good time to bring this wonderful event to its conclusion.

LAC2012: The Music

If I counted correctly, four distinct music venues were organized for the conference. The venues included a concert series spanning three evenings, a continuous cycle of various pieces played in the Listening Room, two audio/video installations, and the hallowed Linux Sound Night. I was able to attend all the concerts, I got to hear some of the pieces played in the Listening Room, and I had to miss the Sound Night. I can attest to the musical value of the concert series - the level of professionalism was high, and it was certainly obvious that Linux can be used to make music these days. More proof could be found in the pieces played in the Listening Room, and if you still need convincing, check out the Linux Sound Night videos recorded by Rui Capela. While it's true that we don't have Lady Gaga in our camp, we do have Deb & Duff, aka Juliana Snapper and Miller Puckette. Yes, the same Miller Puckette of Max/MSP and Pure Data fame. Frankly, all props to Lady G, but I think we got the better bargain.

I mentioned earlier that I had some comments to make regarding Krzysztof Gawlas's report on the making of his piece Rite Of The Earth [PDF]. His presentation focused on the various methods used to create his sonic resources, which was indeed all very interesting, but it did not prepare us for the beauty of his composition. Rite Of The Earth is not solely a Linux-based production, but free and open-source software figured significantly in the making of this music, and I don't hesitate to recommend the piece to my readers.

Incidentally, I should point out that there was wide variance in the represented musical styles. Everything from severely atonal composition to basic rock and dub - and even blues and country music - was represented, and I felt strongly that Linux audio software has definitely come of age. Again I say that the music was wholly engaging - which strikes me as kind of the point of the whole thing - and I can only wait to hear what wonders what will be produced by our talented Linux-based musicians over the next year.

Closing Remarks

So give three cheers and one cheer more for conference organizers Fernando Lopez-Lezcano and Bruno Ruviaro. The entire event was one smooth-running machine from start to finish (though the ever-mobile organizers might not have seen it that way), and I think all the attendees were happy and content by the time it closed. That smooth surface hid the details of what must have been an enormous effort, and I can only say "Thanks again!" to Nando and Bruno for their dedication to making LAC2012 a valuable and memorable experience.

The conference had a few topical biases, especially with regard to Csound, mobile devices, FAUST, Pure Data (Pd), and Ambisonics. That is not a complaint, merely an observation that such topics are timely and of importance to the advance of Linux audio development. Would I have liked to have seen coverage of other major topics? Of course, but there's only so much time, and the organizers must have had some rare fun juggling so many schedules and appointments.

As always, I'm revived and revivified after such an incredible meeting. LAC2012 was further proof of the viability of Linux audio development - the presence of many younger developers was most heartening, especially since they will define the future of the domain. I saw and heard much interest and open-mindedness towards all aspects of audio development, and if I may allow myself a single prediction I'll claim that Linux sound and music software will continue to thrive and will grow in its appeal to new and not-so-new users. We have commercial interest from prestigious developers such as Loomer Productions, Harrison Consoles, Pianoteq, and the Guitar Pro group, and I expect we'll see a few more significant commercial entries arrive later this year. Of course free and open-source development will continue to drive this trend and others. For my part, I am most excited to see what's coming down the road. Whatever it is, it's sounding pretty good from here.

The 11th annual Linux audio conference will be hosted by IEM in Graz, Austria. We hope to see you there.

Comments (7 posted)

Page editor: Jonathan Corbet
Next page: Security>>