Posts Tagged ‘lca2010’
This will be the end of the series, as I’m leaving for the airport this afternoon.
Rusty Russell: FOSS fun with a Wiimote
Rusty told an entertaining story about his journey to produce geeky toys for his daughter, who is too young to use a keyboard or other standard human-computer interface. I always enjoy hearing about the intermediate steps of invention, and this was no exception. After five design iterations and several long distractions, Rusty produced a couple of working applications using Python and libcwiid, and demonstrated one of them.
Ariel Waldman: Space hacks
Ariel’s talk explained the (surprisingly numerous) ways in which geeks can get actively involved in advancing space science and exploration. With budgets of zero, hundreds or thousands of USD, there are projects which are accessible to individuals and schools which offer not only fun and education opportunities, but actually contribute something to the human study of outer space.
I didn’t note them down, so please watch the talk if you’re interested.
Andrew Tridgell: Patent defence for free software
I missed the start of this talk, but when I arrived, Andrew was explaining how to read and interpret patent claims. This is even less obvious than one might suppose. He offered advice on which parts to read first, and which could be disregarded or referred to only as needed.
Invalidating a patent entirely is difficult, but because patents are interpreted very narrowly, inventions can often be shown to be “different enough” from the patented one.
Where “workarounds” are found, which enable free software to interoperate or solve a problem in a different way than described in a patent, Andrew says it is important to publish them far and wide. This helps to discourage patent holders from attacking free software, because the discovery and publication of a workaround could lead to them losing all of their revenue from the patent (as their licensees could adopt that instead and stop paying for licenses).
Michael Koziarski: Lessons learned from a growing project
Michael, a member of the Rails core team, introduced himself as a pragmatist who is not interested in the principles of free software, only in working with the best tools he can find (many of which are actually proprietary). He gave an overview of what Rails is and where it came from, and a list of lessons he learned from its history.
Michael says that users make the best contributors, because they work to address user needs (which they understand first-hand). He contrasted this with developers who join the project to experiment with the latest technology or rewrite code without good reason. Therefore, in order to gain more contributors, it is important to market the project and attract more users.
He downplayed the conventional wisdom of “release early and often”, recommending a release early enough that there is plenty of incomplete work which contributors can help with, but not so early that the software is useless. In other words, release early, but not too early, and often, but not too often.
As is becoming thematic for the free software community, he recognized the necessity of dealing appropriately with people who do not advance the aims of the project. His example was people who don’t really want to use the software, because there is something about it they don’t like. Unless this one thing is changed, they say, it is of no interest to them. They may imply, or even state outright, that if the project changed in some way, they would join enthusiastically. Michael says that this is often untrue, and that even if they get the feature they want, they will not become valuable contributors. He also spoke of addressing trolls, not just the obvious ones, but more respectable-looking pundits as well.
Rails attracted many users early on because of its upstart status, and Michael pointed out that these people later left the project as it became more mainstream. The same was true of contributors, who left for other projects for their own reasons, to learn new things or explore a different direction.
Over time, the number of willing volunteers in the Rails community was much greater than the corresponding stack of “work to do”. Contributors became furious because their contributions were neglected; they threatened to fork the project and left the community. He stressed the importance of avoiding this scenario by tending to these contributors and their contributions.
He advised (mostly) ignoring your project’s competitors as a means of staying focused on the project’s core vision. In particular, he says that projects which define themselves in terms of their competition (“foo is like Rails, but…”) are not worth paying attention to.
He praised Rails’ use of a more permissive (non-copyleft) license, because it encouraged the growth of an ecosystem of hosting providers and tools. I didn’t quite follow his argument as to why this was.
Some of Michael’s lessons resonated with my experience of Ubuntu’s growth, while others did not. Regardless, it was useful to hear his perspective, and the differences may highlight the differing characters of the two projects.
Lindsay Holmwood: Flapjack
Lindsay introduced Flapjack, which is a monitoring system designed to meet the scalability and extensibility requirements of cloud deployments. It shares the Nagios plugin interface, and so can use the same checks. It uses beanstalkd as a central message queue to coordinate the work of executing checks, recording results and making the appropriate notifications. Each of its components (worker, notifier, database) can be extended or replaced using an API, providing a great deal of flexibility.
Jeremy Allison: Microsoft and Free Software
Jeremy took us through Microsoft’s recognition of, and response to, the threat of free software to their monopoly position. After reviewing the major legal battles of this ongoing war (and the metaphor is apt), he says that Microsoft is turning to patents in an attempt to split the free software community and to earn revenue from the use of free software. Jeremy predicts that the outcome will be a never-ending conflict.
The key conflicts are likely to be around netbooks, mobile phones and appliances. How should the free software community respond?
We could ignore it, and keep making free software under copyleft licenses. Jeremy points out that this is perhaps our most effective strategy in the long run, to stay focused on the vision of a free software world.
We can continue to pressure governments and corporations to adopt truly open standards, and to investigate and challenge monopolies. Transparency is key to these efforts, as “elephants like to work in the dark” (Microsoft being “the elephant in the room”).
By lobbying against software patents, we can hope to contain the US software patent system from the rest of the world. Otherwise, the rapidly accumulating software patents in the US can suddenly and dramatically spread.
We might even convince the likes of Microsoft that patents, and patent trolls, represent a greater harm than good.
In response to direct patent attacks, we should search for prior art and attempt to undermine unjust patents. He also suggests calling out Microsoft employees on the company’s actions, to promote awareness particularly in the context of free software conferences.
He closed with a hope that Microsoft could change, citing IBM as having been “as feared and hated as Microsoft is today”.
Neil Brown:Digging for Design Patterns
Neil explored various design patterns in the kernel in order to illustrate how they are discovered, what their important attributes are, and how to use them effectively.
His examples were a binary search, “goto err”, accessor functions and kref. Naming patterns is important, especially getting that name into the code itself, so that it helps to cross-reference use, implementation and documentation of the pattern (e.g. uses of the kref pattern are sprinkled with the word “kref”). A successful pattern can both help to find bugs (this binary search doesn’t look the same as that one…why?) and to avoid bugs (by getting it right the first time).
Benjamin Mako Hill: Antifeatures (keynote)
Mako delivered an entertaining and inspirational talk on antifeatures, those oddities which intentionally make technology less useful to its consumers (think DRM, though he provided a wide range of examples). Mako explained the main reasons why antifeatures exist, and how they are endemic to the business of proprietary software.
Mako offered a potential upside to antifeatures, which is that they can help the free software community to focus on fundamental concerns like autonomy, rather than (for example) the mechanics of licensing. Antifeatures can be used to explain to the uninitiated why software freedom is important to everyday folks, not just hackers.
Denise Paolucci and Mark Smith: Build Your Own Contributors, One Part At A Time
Denise and Mark provided a practical list of “dos” and “don’ts” for building a successful community based on respect, empowerment and collaboration. Much of this was elementary from an Ubuntu perspective, but they offered a variety of examples from Dreamwidth which were illustrative.
Their list of “three things to start right now”:
- appoint a “welcomer” and laud newcomers’ first contributions
- stop timing out on communication when people need responses from you
- Have words with “that person” and let them know their behavior is not okay
Chris Double: Implementing HTML5 video in Firefox
The initial implementation used the xiph.org reference libraries (libogg, libtheora, libvorbis) and PortAudio, but had some problems, including poor A/V synchronization. The second iteration used higher level libraries liboggz, libfishsound, liboggplay and libsydneyaudio, and was included in Firefox 3.1 alpha and beta, but some limitations in liboggplay (a/v sync, chained oggs, etc.) led to difficulty. There were also proof of concept implementations which used GStreamer on Linux, DirectShow on Windows, and QuickTime on MacOS, but these were hampered by codec plugin complications. In the end, they’ve gone back to using the xiph.org reference libraries (but with libsydneyaudio), though the GStreamer backend is still actively developed. Chris has published a series of articles on his blog on reading, decoding and synchronizing A/V streams using various libraries.
There are still some kinks to work out: the lack of indexes and the like in Ogg complicates seeking, calculating duration and so on, and there is no satisfactory solution for cross-platform audio. Rendering is not hardware accelerated yet because the video element is part of the HTML rendering pipeline.
It will be very powerful when it’s ready, though. Theora playback is supported in Chrome, Firefox and Opera today, and Daily Motion, Wikipedia and Archive.org are using it. I can’t wait to see the full API working well on a massive scale.
James Westby: Ubuntu Distributed Development
James gave a great overview of the Ubuntu distributed development project, which has the ambitious goal of providing a homogeneous view of all of the source code for Ubuntu packages using Launchpad and Bazaar. This includes modeling the relationships between the versions of the code in Debian and further upstream, which is complicated by the use of different revision control systems, patch systems, and so on.
At this stage, most of the source code for Ubuntu and Debian is available through the system, and developers can freely branch from it and request merges. It works the same way for all packages, so developers only need to learn one toolset and workflow. We hope that this will lower the barrier to entry for contributing to Ubuntu, as well as make it easier to share patches between Ubuntu, Debian and upstream.
Timo Hoenig: Extending the scope of mobile devices
Timo reviewed how mobile devices have evolved over the past 40 years, citing dramatic improvements in compute power, memory, bandwidth and so on, but comparatively small improvement in battery life (several orders of magnitude less). Thus, he sees power management and related technologies as important to the further advancement of the category. He specifically identified network links as a key consideration, as they consume a great deal of power, and have continued to do so with newer generations of technology. Local power management, he says, is not sufficient, and we need to take a network-aware view.
He introduced the concept of an “early bird” connector, which acts as a supervisor for a mobile device. It communicates with remote network nodes on its behalf, and takes decisions about when and whether to wake up the mobile device. He estimated a 12% power savings by offloading processing to such a device, using a simple model of power consumption. The early bird would run on another system on the network, presumably without the same power constraints (like a proxy server).
Sam Vilain: Linux Containers
Sam detailed the LXC implementation of containers for Linux. In contrast with vserver, it seems to offer a much simpler interface. Because of this, it has been comparatively straightforward to merge into the Linux kernel mainline.
LXC uses existing Linux kernel facilities to group processes within containers into control groups, which can then be used to control access and scheduling of resources (network, CPU, storage, etc.). Each resource type has a namespace similar in principle to what chroot() provides for filesystems. Since all of the hardware is visible to a single kernel, there can be a great deal of flexibility in how resources are allocated. For example, a given network device and CPU can be dedicated to a container.
Usefully for system administration and diagnostics, all of these resources can be directly accessed from the host without stopping or shutting down guests.
Julius Roberts: ZFS
This talk was a tour through the main features of the ZFS filesystem, showing how to work with storage pools and snapshots. It was useful to see the example commands and behavior in the context of a live command line session, as I haven’t got around to playing with it in an OpenSolaris VM yet.
Mark Atwood: memcached
I ended up in this talk in between other sessions I was attending. It outlined the sorts of places where memcached can be useful in applications. Beyond the obvious caching scenarios, Mark suggested using it to store an application’s working set (key/value dictionaries), user sessions and distributed rate limiting scoreboards.
Josh Berkus: Relational vs. Non-relational
I’ve followed with interest the NOSQL movement, and was interested to hear from Josh (of PostgreSQL Experts Inc.) what I expected would be a “relationalist” point of view.
He began by addressing some database myths. He stated that the “revolutionary new database designs” lauded by the non-relationalists are actually just new implementations of old ideas (e.g. CouchDB vs. Pick). He dismissed the “NoSQL” moniker as the wrong distinction to make: there are much more important and basic differences between database implementations than whether or not they use SQL. He explained that the relational model is orthogonal to support for ACID transactions, though I didn’t realize that was an active misconception. He also reminded us that we do not need to choose a single database for all of our possible needs, and should focus on choosing the system which fits our current application goals, or choosing multiple databases (e.g. MySQL and memcached, or [interestingly] PostgreSQL and CouchDB).
Relational OLTP databases tend to have more mature implementations of transactions, the ability to enforce data constraints and consistency, support complex reporting, and vertical scaling (but not horizontal).
SQL itself doesn’t map very well to many programming languages, but promotes application portability and enables the management of schema changes over time. “No-SQL” provides a more natural mapping, and allows programmers to act as DBAs.
His main reason to use an SQL-RDBMS was when the data will outlive current application implementations, because having a looser coupling between the database and application helps support a migration to a new implementation.
He compared the applicability of embedded key-value, distributed key-value, flat file, object, and document databases but I wasn’t able to take notes quickly enough through this segment.
His conclusion was to reiterate that “relational vs. non-relational” is the wrong way to look at the problem, and that we should instead choose the right tool for the job.
Sometimes, when I have a conflict like this, I try to attend the talk whose material is less familiar to me (in this case, probably the SVG/Flash one). However, since the talks are being recorded and made available on the Internet, this changes the dynamic a bit. I don’t have to miss out on watching anything, as I can download it later. So, it makes more sense for me to go where I can best participate, taking advantage of my presence at the conference.
Distro summit: Package management
So, I chose to attend the package management talk, as I might have something to contribute. It was about how to harmonize general distribution packaging mechanisms (dpkg, RPM, etc.) with special-purpose ones like those used by Ruby (gems), Lua (rocks), Perl (CPAN modules) and so on. The solution described employed a set of wrapper scripts to provide a standard API to these systems, so that they could be used by the distribution package manager to resolve dependencies.
Due up next was Scott James Remnant’s talk on booting faster, but due to travel difficulties, he hadn’t arrived yet. Instead, we had a free-form discussion on various other challenges in the area of package management.
I took the opportunity to put forward an idea I had been thinking about for some time, which is that we may need to move beyond a “one size fits all” or “everything is a package” approach to package management. Modern package management systems are very capable, and solve a range of difficult problems with a high degree of reliability. The cost of all of this functionality is complexity: making packages is difficult. The system can be made to work for a wide range of software, but the simple case is often not very simple.
I also made the point that there are non-technical challenges as well: it is difficult for developers and ISVs to understand the ecosystem of distributions, and even more difficult to succeed in making their software available in “the right way” to Linux users. The obstacles range from procedural to cultural, and if we only approach this as a technical problem, we risk adding more complexity and making the situation worse.
The opportunity to have this kind of participatory discussion really validated my decision about how to choose which talk to attend.
Liz Henry: Code of our Own
Back in the Haecksen/LinuxChix miniconf, Liz Henry presented an action plan
for increasing the involvement of women in open source, with many well-considered “dos” and “don’ts” based on observations of what has and has not worked for open source communities.
It was the first opportunity I’ve had to attend a free software conference session which went beyond the typical “yes, this is important” and “yes, there really is a problem here” content which is unfortunately as necessary as it is commonplace.
I won’t attempt to summarize it here, but I can definitely recommend Liz’ presentation to anyone who is looking for concrete, actionable methods to promote gender diversity in their technical communities.
Lucas Nussbaum: The Relationship between Debian and Ubuntu
Historically, in Lucas’ assessment, many Debian developers have been unhappy with Ubuntu, feeling that it had “stolen” from Debian, and was not “giving back”. He said that bad experiences with certain people associated with Canonical and Ubuntu reflected on the project as a whole.
However, he says, things have improved considerably, and today, most Debian developers see some good points in Ubuntu: it brings new users to free software and Debian technology, it provides a system which “just works” for their (less technical) friends and family, and brings new developers to the Debian community.
There are still some obstacles, though. Lucas says that many bugfix patches in Ubuntu are just workarounds, and so are not very helpful to Debian. He gave the example of a patch which disabled the test suite for a package because of a failure, rather than fixing the failure.
He felt that Canonical offered few “free gifts” to Debian, citing as the only example the website banner on ubuntu.com which was displayed for Debian’s 15th anniversary. I felt this was a bit unfair, as Canonical has done more than this over the years, including sponsoring DebConf every year since Canonical was founded.
It occurred to me that the distinctions between Canonical and Ubuntu are still not clear, even within the core free software community. For example, the “main” package repository for Ubuntu is often seen to be associated exclusively with Canonical, while “universe” is the opposite. In reality, Canonical works on whatever is most important to the company, and volunteers do the same. These interests often overlap, particularly in “main” (where the most essential and popular components are).
Lucas speculated that more mission-critical servers run Debian pre-releases (especially testing) than Ubuntu pre-releases. It would be interesting to test this, as it’s rare to get sufficient real-world testing for server software prior to an Ubuntu release.
Lucas presented a wishlist for Ubuntu:
- more technical discussions between Ubuntu and Debian (particularly on the
ubuntu-develdebian-devel mailing list
- easier access to Launchpad data
- Launchpad PPAs for Debian
The prominence of Launchpad in these discussions spawned a number of tangential discussions about Launchpad, which were eventually deferred to tomorrow’s Launchpad mini-conf. One audience member asked whether Debian would ever adopt Launchpad. The answer from Lucas and Martin Krafft was that it would definitely not adopt the Canonical instance, but that a separate, interoperating instance might eventually be palatable.
I made the point that there is no single Debian/Ubuntu “relationship”, but a large number of distinct relationships between individuals and smaller groups. Instead of focusing on large-scale questions like infrastructure, I think there would be more mileage in working to build relationships between people around their common work.