On Friday afternoon I'll be arriving in Oldenburg, Germany, for the
eleventh annual
Linux developers' conference. Historically, this conference has had a
strong focus on non-x86 ports of the Linux kernel, boot loader development,
the GNU toolchain, and so forth.
At long last, it looks like this may be my opportunity to get my
Macintosh Quadra 840AV out of mothballs and back into commission, thanks to
Wouter Verhelst. I should be able to fit it into my luggage if I don't
bring many clothes...
:-)
This year, however, in addition to that, a couple of mini-conferences
are being piggybacked onto the Oldenburg meeting. These include the
GNU Classpath and Debian
Java DevJam and the
Debian Security
Summit.
The Java programming language is a divisive issue in the Free
Software community, and has a degree of controversy that sets it apart from
the usual language wars. The dominant factor in this controversy stems
from what Richard Stallman refers to as the
Java trap; with the
specifications controlled, and the reference implementation kept
unavailable on DFSG-free terms by, an
industry consortium
dominated by large corporations, a Free Software hacker might fear that
using Java will consign them to either having to compromise their
principles by using non-free class libraries (for example), or being doomed
to chase the taillights of standards that could conceivably be tailored to
disadvantage competitors. (Java is not alone in this respect; many people
fear that Microsoft's .NET, despite being openly standardized through
ISO/IEC, will in actuality be completely controlled by Microsoft.)
Despite this peril, Java is attractive to GNU/Linux-using organizations.
The
Free Standards Group,
developers of the
Linux Standard
Base, has received inquiries about a Free Java standard and
implementation from organizations already committed to GNU/Linux. In my
job, I've encountered an interest in Java from several customers and
prospects. Intriguingly, these institutions are, by and large, very much
aware of the Java Trap. They like the language, and are not strong
advocates of Free Software, but they too are worried about vendor lock-in.
They've seen the success of community-driven development as GNU/Linux moves
from strength to strength, claiming territory formerly held by Microsoft
and proprietary versions of Unix. Even if I can't persuade a customer to
adopt a Free Java stack, I can exhort them to only code against Java
standards that have seen a free implementation. That way, their
development bets are hedged against any "madman theory" of the controlling
vendor. Furthermore, this way they only code to standards that are seeing
independent implementations, and they leave their engineers free to switch
between varieties of development kit. Engineers like flexibility because
it enables them to work more efficiently; sales people, marketing
personnel, and strategists like efficient engineers because they make a
firm more nimble.
That's where the GNU Classpath and Debian Java DevJam comes in.
Free Software Java enthusiasts want
to see their implementations fully mature, and are working hard to make it
so. The Free Software community has the opportunity to make its Java
implementation not just an
available alternative, but a
compelling alternative to the proprietary ones on technical as
well as licensing grounds. The recent
release
of GNU Classpath 0.18 shows just how vigorously this opportunity is
being seized. Having mature software is only half the battle, however;
that software has to be coherently put together and easy for the user and
developer to manipulate. For many of these folks, it's not enough just to
have good, Free Java virtual machines (like
Kaffe and
SableVM), class libraries (
GNU Classpath), compilers
and interpreters (
gcj and
gij, respectively, from
the
GNU Compiler Collection), and
application servers (
Jakarta
Tomcat,
JBoss, and
JOnAS, among others). They also
want these technologies to be mutually integrated and easy to install and
use. Good software and good packaging complement each other to drive
adoption of the technology, and that's what the DevJam is all about. I'm
glad to see that representatives of Debian's Java packaging team will be
joining not just upstream authors, but their counterparts at Fedora,
Ubuntu, and Gentoo in furtherance of this goal.
I've approved a budget of EUR 2000, which Petter Reinholdtsen will
administrate, to support the expenses of Debian's participation in the
DevJam. We've received 1500 USD in sponsorship of this event from a
corporate sponsor that chooses to remain anonymous.
The other mini-conference I'll be attending is the Debian Security
Summit. We're bringing together the heads of our Stable Security and
Testing Security teams — the two Joeys, Joey Schulze and Joey Hess,
as well as a bevy of other security-minded people, with the goal of
revitalizing and streamlining our security processes. Several members of
the Stable Security Team have gone dormant over the past several months (or
longer), leaving an increasingly small number people to handle, as of
Sarge's release, not one but
two stable releases. This is because
we do not terminate security support for our previous stable release (in
this case, Woody), until some time has passed.
We've had other challenges on the security front. We had what amounted
to a security support hiatus for about three weeks in June, which caused
much consternation. More recently,
klecker.debian.org, which
provides the
security.debian.org has suffered some occasional
availability problems, and it hasn't always been clear what's caused
them. It's my understanding that we have new hardware in place that can
serve in a backup, supplemental, or failover capacity.
The general feeling at DebConf 5 was that our security apparatus was in
need of attention to make sure it keep pace with the demands being placed
on it. I've been in fruitful contact with Joey Schulze, Steve Kemp, and
others over the past several weeks, and I look forward to a productive few
days.