Hardware Engineer's Conference) Taipei was held June 10 and 11
in, unsurprisingly, Taipei, Taiwan. The event, sponsored by the
governmental Institute for Information Industry, followed the huge Computex
conference in the hope of attracting hardware developers who are interested
in supporting Linux. Your editor, who had the honor of being invited to
speak at FreedomHEC Taipei, would assert that the goal was achieved; over
200 developers showed up for two days of technical talk about the Linux
kernel and the best ways to contribute to it.
Your editor arrived prepared with the talks which have become his stock in
trade in recent years. Of the two talks, the most fun was certainly had on
the second day, when the topic was how to work with the kernel development
process. Anybody who has given talks in eastern Asia knows that getting
audience members to participate and ask questions is not an easy task. But
the FreedomHEC audience was (after just a bit of encouragement) full of
questions and interested in having a
discussion which could have extended far beyond the allotted time. There
was, beyond doubt, a great deal of interest in working more closely with
the wider development community. Your
editor offers his apologies to Greg Kroah-Hartman, who had to wait rather
longer than was proper for the lectern to become free.
Greg's talks were quite well received; his 2.5-hour tutorial on writing a
device driver had the undivided attention of the full audience at the end
of a long day. Peter Stuge gave a talk on CoreBoot (once known as
LinuxBIOS). Harald Welte's talk on GPL compliance was also well received;
the audience seemed much more interested in how to work with the GPL than
how to get around it.
FreedomHEC was not dominated by outside speakers, though. Developers Jim
Huang and Matt Hsu from 0xlab,
who were clearly
having a great time, discussed their work with the Qi bootloader. Fred Chien
covered a number of hacks ("dirty" and otherwise) to make Linux boot more
quickly. Joseph Chan of VIA discussed the various challenges he
encountered while working to merge a driver into the mainline. They all
appeared to be interesting talks; unfortunately for LWN readers, they were
also all in Chinese, so your editor's reporting is necessarily spotty.
The Chinese-language talk which looked like the most fun was a high-energy
session led by Chen Ing
Hau, perhaps best known as the (since repentant) author of the
Chernobyl worm. CIH (as he was referred to there) went deeply into the
process of reverse engineering the appropriate register settings to drive a
wireless network adapter. The talk proceeded with all the ups and downs of
a good detective story, with the culprit, naturally, being caught at the
There is a certain missionary aspect to attending this kind of
event. Harald Welte described
it this way:
In about 8 hours I'll depart for FreedomHEC Taipei 2009, an event
where members of the Linux development community try to help
Taiwanese hardware vendors understand the Linux development model.
I personally believe this kind of event could not be any more
important. The traditional PC and embedded hardware industry still
has a very, very limited understanding when it comes to properly
supporting Linux, aiming at the universal solution for best
end-user experience. In order to achieve this, the FOSS development
model needs to be understood, as well as the value of going
mainline with the drivers/ports.
The group of industries often referred to as "Taiwan, Inc." has often shown
a lack of understanding of how our community operates and, seemingly, a
lack of interest in being a part of it. So FreedomHEC looks like an
attempt to bring the Good Word to that part of the world. Certainly some
people need to hear it.
But your editor is not sure that those people were at this conference.
What went down at FreedomHEC was hackers talking to other hackers, and they
were having quite a good time in the process. It looked an awful lot like
a Linux-oriented development conference.
Your editor has spoken in
parts of the world where people seem to view software development as just
another job, and not a particularly inspiring one at that. But Taiwan was
not one of them. There are a lot of people
working on interesting projects, and they show that excited, creative spark
that suggests good things are on the way. They look like they want to be a
bigger part of our community.
To that end, events which present information on how to work with the
global community are helpful. But one thing is worth pondering on. When
asked if they felt that their managers understood the importance of and
value in working with the free software community, very few members of the
audience raised their hands. Taiwanese developers, it seems, don't need
much help in this area, but their bosses do. This is natural; why should
Taiwanese managers be more enlightened than their counterparts elsewhere in
the world? To solve this problem, we are going to have to engage in
education at higher corporate levels. Management can be won over with
sufficient persistence and energy - most of the time.
Events like FreedomHEC are helpful in this regard; they can give the local
development community encouragement and the tools needed to carry the
message to their companies. And there is always value in gatherings where
developers can meet and talk about things over beer. FreedomHEC Taipei
2009 was an exemplary event of its kind; its organizers (led by Chao Lung
Huang) deserve strong congratulations. Your jet-lagged editor is happy to
Comments (6 posted)
On June 4th, the Python developers removed a recently-added module,
ipaddr.py, from the upcoming Python 3.1 release. At the time 3.1 was
still in release candidate status — rc1 had been released on May 30th
— and the usual policy for Python's release candidates is that only
bug fixes are permitted. Adding or removing an entire feature is
normally forbidden. Why did the Python developers change their minds?
The story behind the decision shows a possible communication problem
as projects grow and the number of available channels increases.
The story begins in September 2008 with Issue 3959 being filed in
Python's bug tracker by Guido van Rossum, recording a suggestion that
ipaddr.py be added to the standard library. After the issue was
created a few messages were exchanged discussing the
authors' willingness to move the master copy into Python's SVN
repository, and then the issue fell silent. (The Python developers
were probably distracted by preparations for the final release of
Python 2.6 that occurred a week later.)
ipaddr.py parses IPv4 numeric addresses such as 172.16.40.35 and
address ranges such as 192.168.0.0/16, as well as the corresponding
IPv6 formats. Users can create IPv4 and IPv6 address ranges, remove a
subset of addresses from a range, check whether a given address is
included in a range, and compare addresses and networks for
equivalence. The module had been used internally at Google for some
time and bears a copyright statement dated 2007; the first open-source
release was in September 2008 as the ipaddr-py project on
After the initial messages, it was some months before discussion
revived. Some commenters noted similar libraries such as netaddr and IPy. After some
further discussion, in February 2009 Martin von Löwis wrote "Yes,
I think it can be integrated now.". There was another delay of a few
months before the code was actually committed, but on May 1st Gregory
P. Smith committed ipaddr.py to the Python 2.7 branch in SVN revision
72173, also merging the change to the Python 3.1 branch.
But, in June Clay McClure argued against the
inclusion of ipaddr.py on the bug tracker:
When looking for an IP address library for use
in a network scanning and discovery application I wrote last year, I
decided against ipaddr because of its conflation of address and
network -- it seems strange to me to have one class modeling both
After reading the technical discussion on the ipaddr and netaddr
lists, it is clear to me that ipaddr's designers have a somewhat
limited understanding of IP addressing, and have not designed an API
that articulates IP concepts particularly well.
McClure's objection stems from ipaddr.py using the same class to
represent both individual IP addresses and network address ranges.
Network ranges are usually represented as a starting address and the
number of bits that are the fixed portion of addresses within the
range. 192.168.0.0/16 is an IPv4 range, for example; the first 16
bits of the address (the 192.168. portion) are fixed and the remaining
bits can vary. ipaddr.py represents
a IPv4 host's address, which is a specific 32-bit value, as the address plus a
/32 value. Treating addresses in this way lets a single class be used to
represent either a single address or a range.
(IPv6 uses 128-bit addresses and hex notation, but the principles are the same.)
The debate is about whether this representation is reasonable.
>>> from ipaddr import *
>>> a1 = IPv4('127.0.0.1')
>>> a2 = IPv4('127.0.0.1/32')
>>> a1 == a2
Core contributor Raymond Hettinger
brought the discussion to the attention of the python-dev mailing list:
Clay McClure is raising some objections to the new ipaddr.py module.
JP Calderone shares his concerns. I think they were the only
commenters not directly affiliated with one of the competing projects.
The issues they've raised seem serious, but I don't know enough about
the subject to make a meaningful comment.
Does anyone here know if Clay's concern about subnets vs netmasks in accurate and whether it affects the usability of the module?
van Rossum initially thought
the reported flaws were not so significant:
I haven't read the bug, but given the extensive real-life use that
ipaddr.py has seen at Google before inclusion into the stdlib, I think
"deep conceptual flaws" must be an overstatement. There may be real
differences of opinion about the politically correct way to view
subnets and netmasks, but I don't doubt that the module as it stands
is usable enough to keep it in the stdlib. Nothing's perfect.
The resulting discussion thread received dozens of messages, and a
consensus formed that the module's interface needed some reworking.
Eventually van Rossum agreed it
should just be removed from 3.1:
I'm disappointed in the process -- it's as if nobody really reviewed
the API until it was released with rc1, and this despite there being a
significant discussion about its inclusion and alternatives months
ago. (Don't look at me -- I wouldn't recognize a netmask if it bit me
in the behind, and I can honestly say that I don't know whether /8
means to look only at the first 8 bits or whether it means to mask off
the last 8 bits.)
To a first approximation, this is just business as usual for any
project: a feature was proposed, the code got committed, but later the
developers collectively changed their minds and backed out the change
from the 3.1 branch. The impact is minimal, because the code was only
in one release tarball, a short-lived 3.1rc1 release candidate that
was replaced two weeks later by 3.1rc2. The module remains in the 2.7
branch for now, but 2.7's release is months away, leaving plenty of
time to remove the module or to rework the module's API and include it
in Python 3.2. A Python Enhancement Proposal may be written
defining an IP-address module.
However, the incident brought some process issues to attention,
and the discussion divided into three major strands.
Mailing list vs. bug tracker
Part of the reason for the late reversal was that objections were
being made through commenting on a particular issue in the bug
tracker. A January
thread on python-dev didn't cause much discussion, and the
disagreement on the issue wasn't noticed by 3.1 release manager
Glyph Lefkowitz of the Twisted project detailed
the procedures for the Twisted project, where all discussions are
in the bug tracker:
The way Twisted dealt with this particular issue was to move *all*
discussions relevant to a particular feature into the ticket for that
feature. If discussion starts up on the mailing list, within a few
messages of it starting, someone on the dev team will pipe up and say
"Hey, here's the ticket for this, could you add a link to this
discussion and a summary".
Bug trackers encourage focused conversations between people with an
interest in a bug or patch, preventing an unmanageably busy mailing
list. But there's a cost; this increased focus makes it harder to
obtain a general view, or to notice that one issue is particularly
serious or important. One suggested improvement was adding the
python-dev mailing list to the Roundup bug tracker as a user. Roundup
creates a 'nosy list' for each issue; users on the nosy list receive
e-mail notifications of new comments or modifications to the issue.
If python-dev existed as a Roundup user, adding python-dev to the nosy
list for an issue would send a clear signal to other core developers.
The developers of Apache have a formal voting
process that's specified in careful detail. Python follows some
of Apache's conventions, such as using +1 and -1 to indicate support
or opposition, but these aren't votes, merely polls showing general
opinions. For example, under Apache's rules a -1
vote is a veto and must be accompanied by a technical justification,
but many changes to Python have received -1 votes and still been
In Lefkowitz's posting cited earlier, he also noted that
there is a vocabulary for describing the next action
to take on a patch:
Once on a ticket, the phraseology and typesetting used by our core team
has reached a very precise consensus. Like the feature? "Merge this
patch" or "Land this branch". Don't like it? "Thanks for your patch,
but:", followed by a list of enumerated feedback. The required
reactions to such feedback are equally well understood. Even if a
comment isn't a full, formal code review, it still follows a similar
This system is possibly too simplistic for the more wide-ranging
development of Python; although Twisted has its share of enthusiastic
discussions, there is rarely the level of controversy I see here on
python-dev, so I can't recommend it as such. I can say that keeping
ticket discussions on tickets is generally a good idea, though,
especially in a system like roundup or trac where it's easy to say "see
message 7" rather than repeating yourself.
Selecting additions to the standard library
A number of different modules for representing IP addresses have
been written, including ipaddr.py. David P. D. Moss, author of the
netaddr module, drew up a
list of IP-address modules that contains 12 projects, the oldest
dating back to 2000. ipaddr.py is comparatively new, having been
publicly released in September 2008; so why was it chosen?
To some degree it's just a question of luck and timing: the
suggestion to add ipaddr.py was just the first one to be recorded in
the bug tracker, but a policy of "whoever asks first" does not ensure
that the best module is chosen for addition.
What selection process would work better? Barry Warsaw thought
usage information from the package index could be helpful, suggesting
"It would be really nice if say the Cheeseshop had a voting
feature". The Cheeseshop is another name for Python's package index.
Neil Schemenauer further noted
Debian's popularity-contest script, which reports the
packages installed on a system to a central server.
van Rossum didn't like the idea at all, saying "Whoa. Are
you all suddenly trying to turn Python into a democracy? I'm outta
here if that ever happens (even if I were voted BDFL by a majority
But van Rossum had previously noted that he wasn't a likely user of the
module and could not really assess the suitability of the module's
interface. In the absence of a strong opinion based on technical
grounds, how should such decisions be made? Going by popularity seems
to be as reasonable a way to choose as any other. Of course, the
sheer number of modules may imply that this is an area where people
are finicky about the approach taken, and perhaps the standard library
needn't take a position on it.
In order to make progress, open-source projects, like people, must
continuously decide which action to take next. Much has been
written about personal time management, including books such as
Stephen R. Covey's 7 Habits of Effective People and David Allen's
Getting Things Done. Often the key to improvement is taking a
careful inventory of tasks and organizing this inventory to minimize
effort spent figuring out what to do and maximize effort spent
actually implementing or fixing.
As free software projects spread out across multiple communication
channels — a set of mailing lists, the
bug tracker, SourceForge forums, personal weblogs, IRC conversations,
Twitter, and soon enough new technologies such as Google Wave —
their developers will face many of the same issues at a collective level.
Taking inventory is relatively easy because there are many tools
for doing so:
version-control systems, bug trackers, and mailing list archives. But how
do you ensure that the right people are paying attention?
Comments (10 posted)
In the past, only Novell employees could contribute code to Factory, the development version
of openSUSE. However, this policy has started to change in the last few
weeks, ever since openSUSE board member Henne Vogelsang announced sweeping
changes to how Factory
operates. These changes include a reorganization of Factory into
specialized teams, and permitting community members to contribute code
directly — a move that has the distribution rethinking its security
measures as well.
The opening of the distribution to community contributions is only one
of the changes to the distribution in recent years to make it more open
(and, perhaps, to silence accusations that openSUSE is controlled entirely
by Novell). These changes have included the appointment of a community
manager, the transition to an elected board, and increasing access to the
project through such features as openFATE, the feature-tracking
service, and the openSUSE Build
Joe "Zonker" Brockmeier, openSUSE community manager, explained that the
changes were made "to continue enabling the contributor community
outside of Novell and make it easier for people who are doing work on
openSUSE to participate directly. We want to enable and encourage
contributions from outside of Novell, and continue to make openSUSE a more
Similarly, Vogelsang said that most of the requirements for open
contribution have been gradually coming into place over the last year or
so, but "What we did not have was the possibility to take
responsibility. That's why we changed our policies now so people can not
only contribute but also take responsibility."
Vogelsang is referring to the division of Factory into working teams
for patches and packaging. To a limited extent, this division already
exists. Informally, teams for major areas such as GNOME, KDE, and Education already have
their own web pages and ways of working, and exist semi-autonomously within
The difference now, as Vogelsang said in his initial announcement is
that "What we want now is to use this model for every aspect of the
distribution, not only the big parts where this comes naturally."
To this end, Vogelsang and the current package maintainers have
developed a preliminary list
of over 85 possible teams. These teams are listed as having responsibility
for maintaining packages and reviewing contributions for as few as three or
four packages, or for dozens, depending on the area that they cover.
In the announcement, Vogelsang wrote that, "As our goal is to
make it possible for everybody to work on the distribution, we will simply
allow the topic groups to organize themselves. We think that there is not
the one and only way such a group of maintainers can work together, but it
depends on the involved people and also on the topic . . . . So to
transition we will throw together the people that are currently maintainers
of packages and help them work out how to best collaborate with each other
and [with] new people."
What is not immediately clear (at least, not without a lot of web
searches) is which of the proposed teams are active and which are still
largely hypothetical. But, for now, the distribution will be working with
existing maintainers, and adding Novell employees to fill in where
volunteers are lacking.
Policy vs. procedure
A particular area of concern is security, as Marcus Meissner pointed
out. As Meissner explained, "Every single package can disturb /
destroy the integrity of the whole openSUSE distribution (As in 'install
trojans, rootkits, etc.')." Even if a package is not installed by
default, Meissner warned, it could still be installed by the automatic
resolution of dependencies.
Under these circumstances, Meissner stresses that the role of packagers
needs to change along with openSUSE's policies. In particular, packagers
will need to review all submissions with extreme caution, checking for
malicious code and maintaining a workable set of project and package
submission. They will need to decide how much they trust each contributor,
and, at the same time, watch for email addresses that spoof those of
trusted contributors, or cracked openSUSE accounts.
"Always keep such a thing in the back of your head and watch for
behavioural changes," Meissner advised. "Trust your gut feeling and check
twice if in doubt!"
Meissner's warning sparked a brief discussion on how the submission
process could be made more secure. Karsten König suggested
that the use of MD5 of SHA-1 hashes become mandatory in all submitted
tarballs and within package scripts, so that reviewing the integrity of
submissions would become easier. König also proposed
that all hashes for packages be available on a web interface. Such
changes in procedure would probably be resisted by some maintainers, but
Vincent Untz wrote
that they might be accepted more easily if they were made voluntary for one
release cycle, then mandatory for the next.
Allowing community changes is a reversal of existing policy that can
only add to the credibility of openSUSE as a free software
project. However, as the security issue shows, changes in policy can
require rethinking of procedures as well. While no final decision has been
announced about how to handle the security issues created by the policy
change, the need for some guidelines is inevitable. Nor are policies for
acceptable structures or standards likely to be far behind, as other
community distributions have discovered in the past. The devil, openSUSE is
finding out, is not in the policies so much as in thrashing out the
Comments (none posted)
Page editor: Jake Edge
Next page: Security>>