By Jake Edge
July 30, 2008
In the third keynote given at this year's Ottawa Linux Symposium (OLS),
Mark Shuttleworth spoke about "The Joy of Synchronicity". In his speech,
he discussed his idea of synchronizing releases between major
distributions but he also advocated time-based, rather than
feature-based, releases for free software in general. He believes that a
release has
value in and of itself; by doing them on a regular schedule, a project will
get into a kind of cadence that is useful for both developers, testers, and
users.
Before starting, Shuttleworth was subjected to the traditional introduction
by the previous year's keynote speaker—James Bottomley, in this
case. Bottomley looked
at Shuttleworth's postings to newsgroups over the years, noting three
year-long valleys in the graph where there were no postings. It turns out these
corresponded to events in Shuttleworth's life. The first is when he
received a substantial amount for selling Thawte to Verisign: "when
someone is being productive on the mailing list, never give them half a
billion dollars," Bottomley said. For the second, he has a pretty
good excuse as he was not on planet earth; the last corresponds to starting
Ubuntu.
In a nod to Bottomley and the other kernel hackers, Shuttleworth mentioned that
he had been working on his slides up until close to the start of his
speech, while doing some unrelated things in the background—like updating
his system. That picked up a new kernel as well and he did a suspend to RAM
when he was done; only later in the cab ride to the Congress Centre did he
think: "maybe that was a mistake". It turned out to work
just fine, which is a testament to both the kernel and to distribution
update mechanisms.
The alliterative theme of the speech was that free software development
should be guided by "cadence, collaboration, and
customers". The cadence is a regular schedule for releases, similar to
what GNOME—who pioneered this technique, according to
Shuttleworth—and the Linux kernel
do. This gets a project into a rhythm that makes it more predictable,
which enables all interested people to schedule themselves around it. He
compared this to various development methodologies such as "Agile" and "Lean".
Industries are governed by rules, so if you want to change an industry, you
"have to find which rules are only in our heads".
Cross-project collaboration is one of those rules. "Nowhere is it
written that projects can't collaborate." It is harder to do that
if each distribution is working with different versions of the various
base-level tools: the kernel, X.org, GNOME/KDE, OpenOffice.org, Mozilla, and so
on.
Shuttleworth contends that it is releases, rather than features, that bring
attention to Linux. In answer to critics who believe that distributions
should compete with each other, he says that is just "an opportunity
to create friction." Free software companies don't compete on
versions, but rather on philosophies and what things they focus on. He likens
it to food courts or automobile sales malls where there are many choices in
one location which serves to increase the sales of all.
For major transitions, Shuttleworth is a fan of establishing meta-cycles,
the idea that every N releases is a major release, which may result in
breaking some backwards compatibility or introducing completely new
functionality, along the lines of KDE 4 or GNOME 3.0. As an example, he
used a six month release cycle where every fourth or sixth was a major
release. For a distribution, that might be a long-term support release,
rather than a major change.
One of the key requirements that Shuttleworth sees is the need to
"keep the trunk pristine", by doing integration on the trunk
and feature development on branches. Along with this is the need for more
and better tests. While not necessarily believing in test-driven
development, he certainly leans that way. In any case, all the tests
should pass before committing to the trunk.
Many projects do not yet have an extensive test suite, but this needs to
change. He quoted a Chinese proverb that "the best time to plant a
tree is 20 years ago, the second best time is today". He mentioned
that he is working on a robot that controls the trunk of a development
tree. Developers will request it to merge from a branch, so the robot
merges the branch
and runs all the tests. If the tests pass, it commits, otherwise it gets
kicked back to the developer.
He sees distributions as "an effective conduit of upstream to
users," to that end he believes that agreeing on versions of vital
infrastructure can only help. Bugs that users find will be more likely to
be fixed; those versions will also get better testing which will help
developers. It is a conversation that free software should be having
because it is a "very exciting idea" that won't work for every
project but should be attempted and experimented with.
In answer to criticism about Ubuntu not contributing as much as other
distributions would in his proposed synchronized release, Shuttleworth was
adamant that it was not true. He
hates to see the antagonism and vitriol between distributions. "We
have much bigger fish to fry and they are probably not here today."
If all of the distributions were to standardize on a particular version of
some project for their next release, what happens if that project falls
behind? There are risks associated with that, Shuttleworth admits, but if
it were happening, more resources would be available to help the project
catch up. In the worst case, perhaps falling back to the previous version
would have to happen. "Being tightly coupled has risks."
This is clearly an idea that Shuttleworth feels strongly about, not
necessarily that it be adopted fully, but that it be discussed and
considered. Certainly some of his ideas have a great deal of merit. We
will have to wait and see whether the grander vision will ever be
implemented.
Comments (24 posted)
By Jake Edge
July 29, 2008
Hiring a well-known free software advocate to oversee efforts to work with
the community is a good plan for any company, but for a company that has
had rocky community relations, it may be essential. VIA Technologies has
done just that, by contracting with Harald Welte to help guide its
strategy to work more closely—and less contentiously—with the
community. VIA announced a
new effort aimed at cooperation with the free software world last April,
but got off to a slow start that had people wondering about its commitment to
fulfilling that promise. Welte will be well placed to ensure that
community concerns are heard within VIA.
Highly visible in the community for his work on things like
netfilter/iptables and, more recently,
the Openmoko phone, Welte
has the skills to provide VIA with excellent advice. He has also won
several awards for his work on GPL enforcement as founder and driving force
behind the gpl-violations.org project. We
caught up with Welte at this year's Ottawa Linux Symposium to discuss his
new role.
Because of his work on Openmoko, Welte had been traveling frequently
to Taiwan, making a number of industry
contacts amongst the companies located in Taiwan. About nine months ago,
he was "invited to talk to VIA and give them some feedback from the
community". The company, he says, knew from the beginning it needed
community input, but how to get that was not decided until late May or early
June, when they asked Welte provide it on a regular basis.
The push from within VIA came from management, specifically product
management, which is somewhat surprising—in
the US and Europe, at least, it is typically engineering that pushes for better
community relations. "It's a really big opportunity for me being a
representative of the community to talk to a company at this high of a
level. That's what makes me very optimistic."
[PULL QUOTE:
It's a really big opportunity for me being a
representative of the community to talk to a company at this high of a
level. That's what makes me very optimistic.
END QUOTE]
VIA primarily needs to get drivers and other software for their graphics
hardware cleaned up and submitted upstream. It is not just the X.org
drivers for 2D and 3D graphics that need to be mainlined, there are also DRM
and DRI patches that are maintained out-of-tree. He wants to see kernel
patches get moved upstream to kernel.org, while X patches get merged into
X.org code. A free 2D driver supporting most VIA chips, old and new, will be
available soon.
Welte sees his role as "focusing more on the open source strategy inside
VIA". That includes improving the skills of VIA's R&D group so that they
produce drivers that are mainline quality. Various kinds of problems exist
in the drivers, the coding style may not meet the kernel requirements or
they may not use the proper APIs. Currently, drivers exist for new
products that are supposed to ship with mainline drivers available; Welte
will help ensure that happens. "I perceive myself as community person
rather than a VIA person."
He points to Intel as a "shining star" example of supporting free
and open
source software, though "sometimes they might focus a bit too much on
drivers than on open documentation," especially for wireless hardware.
One of the areas that VIA is working on is open documentation for its
hardware, but Welte isn't sure when those will be released—though
some 800 pages were
released this week. Schedules are
largely out of his control, as they are subject to a wide variety of
variables within VIA.
His role with VIA is a chance to "really make a silicon manufacturer
understand how the
open source community works and what the benefits are to working with
it".
He will be traveling back and forth from his home in Berlin quite a bit;
"that's good, I love Taipei". He has also started to learn to
speak
Chinese.
It seems like a great fit that, in some ways, Dave Jones predicted in his
blog posting linked above: "I'm beginning to think the only way VIA will
ever really 'get it together' is if they employed someone from the Linux
community who actually understands how all this works, because it seems
someone in Taiwan isn't getting the memos." Perhaps a little late,
but it
seems that VIA has gotten and understood the memos now.
Comments (5 posted)
July 24, 2008
This article was contributed by Valerie Henson
Kristen Carlson Accardi is a Linux kernel developer for Intel's Open
Source Technology Group. She is the maintainer for the PCIE hot-plug
driver, the SHPC hot-plug driver, and the PCI hot-plug subsystem
in the Linux kernel. She is currently working on SATA
drivers, including implementing power management features.
Kristen is the benevolent dictator for the upcoming Linux Plumbers
Conference. We interviewed her about LPC, why so many Linux
developers live near Portland, Oregon, and life as a kernel developer.
What is Linux Plumbers Conf?
And why the "Plumbers" part?
Linux Plumbers Conference is a conference for developers working on
the low level programming of Linux, including kernel, libraries, and
system applications such as udev, hal, and dbus. We came up with the
name "Plumbers" because we wanted to represent these areas as basic
system infrastructure which has many connections. Plus these programs
are sort of the nasty, grimy, unglamorous underbelly of the system -
not unlike the pipes in your house. Essential - but nobody wants to
know they are there and everyone takes them for granted until they
don't work.
Running a conference is a lot of work in addition to your full time
job as a Linux kernel developer. What made you decide to start Linux
Plumbers Conf?
Actually, it was the idea of a group of people. The Portland Linux
kernel community gets together once a month or so to socialize and
drink beer. At one of these gatherings we had a conversation about
how difficult it was to solve big picture problems that cross multiple
project boundaries. We felt that there are some cases where you
really need to be able to just get everyone in a room and be able hash
things out in person, but there wasn't really a forum for this.
Existing conferences were either too narrow (like Kernel Summit or the
X developers summit) or too broad for our purposes.
Then someone said
something like "Hey, why don't we just make our own conference".
Because we are nothing more than a group of developers with a shared
love of beer, we went to the Linux Foundation and asked them to
collaborate with us, and it's been a wonderful partnership. It's
definitely been a challenge for a bunch of software engineers to try
and organize a conference, but we've leaned heavily on LF for advice
and we've learned a lot in the past year.
Most conferences are centered around talks in which speakers present
their work, but open source developers often skip the talks so they
can discuss ongoing projects face-to-face. How is LPC balancing these
needs?
Our format for the conference is based on the idea that we would have
a bunch of "microconferences". Each microconf is meant to represent
a topic that should be small enough to be able to adequately discuss
in a few hours, and should preferably span multiple project areas.
Each microconf is being organized by a single expert in the area who
dictates the content of the microconf. The microconf runner may
decide to have a couple talks and an hour or so for discussion, or
they may decide to split the group into teams and solve some specific
problems. We are leaving this up to the microconf runner to decide,
although we are recommending that talks be not more than 25 minutes in
length so that there is ample time for discussion and questions.
We also have a general track for presentations that do not fall under
our predefined MC topics. In addition to the rooms for the
microconfs, we have several rooms that are going to be available for
"unconference" style talks. People wishing to get together in smaller
groups will be able to reserve a room at the beginning of the
conference. Our larger rooms will also be available in the afternoon
for working sessions.
For several years, developers have been organizing individual
summits and workshops for particular projects, like networking and
file systems. LPC microconfs are similar, but they're held all in the
same location and time. Why did you want to put the microconfs
together into one conference?
We did this to encourage cross project communication. Individual
summits are great for solving narrow problems, but they tend to
compartmentalize developers from each other.
Who is organizing and sponsoring LPC?
LPC is organized by a group of volunteers from the Portland Linux
development community and is underwritten by the Linux Foundation. We
are a group of developers who just wanted to attend a conference which
didn't happen to exist yet, so we made our own. Because we are all
volunteers, we have very little overhead for this conference, and the
money our sponsors have given up is being used directly on making the
conference as productive and memorable as we can make it, with
hopefully a little left over to start over again next year. Our
Platinum level sponsors are Intel and IBM, with NetApp sponsoring at
the Gold level, and HP, MontaVista, and Google at the Silver. In addition the
Linux Foundation and Portland State University and have given us so
much more than money - they have been true collaborators and we are so
grateful for all their time and effort.
Were there any sponsorships you didn't accept?
Not that I can recall - we actually started fund raising a little late
and missed a lot of people's planning cycles. We were extremely lucky
that there were so many great sponsors like Intel, IBM, NetApp, HP and
Google that believed our conference was valuable enough to find the
money in their budget despite the short notice.
How did you decide on the location of LPC?
Portland State University was always our first choice for LPC. We
wanted a non-corporate, friendly environment that was downtown. It
was very important to us as well to have a "green" conference - hey,
we are Oregonians! We wanted a place were there were
plenty of hotels and restaurants within walking distance so that
people would not have to rent a car. In addition, we didn't want the
more traditional convention center or hotel atmosphere, nor could we
afford it.
Tell us more about LPC as a green conference.
As frequent conference-goers, we are all a little dismayed by the
waste generated from conferences. Disposable drinking cups and
bottled water, flyers and schwag that immediately hits the garbage bin
when you get back to your hotel, and driving around from event to
hotel and back again are just some of the things that we decided we'd
like to not have at our conference. As such, we are not distributing
printed material at the conference. We're also limiting our schwag to
only things we've deemed useful, and we are working with our caterers
to reduce paper waste and provide foods from local, sustainable
sources where possible.
How did you get started in Linux kernel development?
I started using Linux in college back in 1994 or 1995 - I wanted to be
able to work on my homework at home rather than in the lab, and all we
had in those days was a horrendously slow modem connection to the
school. For years afterward, all I wanted to do for a living was to
work on Linux, but it wasn't until around 1999 that I got my first
chance to write some drivers for Linux while working in Intel's
networking division. I had previously written device drivers for
Netware - a job I'd gotten right out of college. After working on
out-of-tree drivers for embedded systems and research projects for
many years, I finally joined Intel's Open Source Technology Center in
2005 and was able to start contributing upstream in a meaningful way.
Portland is home to many top Linux developers, including Linus
Torvalds. Why do you think Portland is so attractive to open source
developers?
Honestly - I have no idea. People ask this question all the time, and
all we can do is speculate. I know why a lot of us live here - it's a
great city to live in. At some point you get enough critical mass of
developers that you start attracting others. It could be any number
of things. Maybe because it's easier to thumb our noses at Redmond
from here?
In your opinion, what are some of the most important technical
trends in Linux kernel development today?
Low power features in hardware is driving a lot of kernel development
these days.
Tell us about some of the places you've traveled for your job.
When you work in open source, you have to travel to meet your
"co-workers". I've had a chance to go to OLS a few times, Sydney for
LCA a couple years ago, and Cambridge last year for Kernel Summit and
LinuxConfEU. Recently I traveled to FISL in Porto Allegre, Brazil.
I've also been to Ireland for Skycon - a fun and interesting
conference. I'm actually looking forward to not having to travel to
attend LPC.
Thanks, Kristen, for taking the time to answer our questions.
Comments (6 posted)
Page editor: Jonathan Corbet
Next page: Security>>