[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[Debconf-team] late talks, please insert for rating

these late talk submissions could still be included in the
rating. 

Gunnar, could you please feed them to the system and ask
the submitters to fill in their lacking personal data, if they
did not register yet?

I myself am very interested in the talk by greg about legal
basics. I think most/some debian developers overrate their
competence and lack a basic understanding of the subject. The
rest might be just very interested in this topic. i would expect
it to be one of the best talks with most puropse we have at
present.

Keiths would be both very interesting and entertaining. Do we
have a fireplace? or a camp fire? i think he does not need to be
in the main talk tracks but would be very effective in a
non-formal setting.
--- Begin Message ---

Attachment: pgpZ4lmTkJkH2.pgp
Description: PGP message


--- End Message ---
--- Begin Message --- 
Hi, I notice that I just missed the deadline for papers to Debconf6.

Having just arranged that I am now coming I would like to submit something -
hoping that it being a day or so late, and not via comas will not cause too
much trouble.

There are two talks I could do, and if one or other would fit the schedule
better than I am happy to do either variant.

The two options are: 
1) The Arm port 
   A general overview of the current state of the port. It's genesis and
   history, peculiar status as underused yet very important port, recent
   problems, new variants and future challenges.
 
2) The ARM abi transition

   Discussion of proposed new ABI for ARM - the practical effects this has
   on toolchain, kernel, libraries and applications. Pros and cons of Debian
   using the new ABI (for big and/or little-endian arm). How such a
   transition can be best managed within the Debian infrastructure. Also a
   covering the interaction between Debian and the commercial interest
   of ARM.

2 is topical (and will be more so during debconf) as a new ABI arch will be
in active development.

1 provides a useful overview of the life of a sub-arch for those who do not
know that much about life outside x86/amd64. It is also a useful chance to
explore the relationship between mainstream Debian and it minor
architectures.

Abstract for 2 below. Get back to me for an abstract on 1 if you prefer that
angle.

I am qualified to speak on these subjects as someone who has been involved
with the arm port since I joined Debian in 2001, and who has recently taken
a more active role as others have moved on. I think the fact that arm is the
most popular arch in the world for embedded systems now, yet the Debian port
struggles to have sufficient manpower is a subject worth discussing.

For 2 I am finalising a contract with ARM Ltd to produce a new-abi port of
Debian over the next year. ARM want to promote this architecture. Debian and
its users do not necessarily have aligned interests with ARM Ltd, but we
should consider the pros and cons of the new scheme on its technical merits.

Abstract: 

The existing ARM linux ABI was formed during the original arm kernel port in
~1997, from the existing gcc support and ideas taken from RISCOS and
modified for efficiency with the then-current ARM2/3 architecture.  The use
of hard-float was also reasonable given the existence of the FPA chip and
the ARM 7500. However since then no arm CPUs have been produced with FPU
units implementing the ARM instruction set, and trapping and emulating the
instructions is very slow. Also the harvard architecture has become
standard, making the syscall interface now somewhat anachronistic.

Both of these changes, as well as other considerations, mean that the new
ABI proposed by ARM Ltd is attractive to anyone building modern binaries.
Having a common ABI across different OSes is also potentially useful,
although largely to proprietary software producers, rather than Debian.

TO use the new ABI, changes are needed in the toolchain, kernel, glibc and
any applications which handle floating point numbers directly, or use
ioctls, and a few other circumstance, such as code caught by the changes in
enum packing.

The new and old ABIs are incompatible, and attempting a smooth transition
from one to the other is probably not feasible - it may not even be
possible, so a new architecture has been created to prove the new ABI, and
iron out problems. 

This talk will look at the changes between the two ABIs, the affected
software, the pros and cons of the new ABI for Debian, and the mechanisms
for transitioning Debian from the old to the new ABI. 

Wookey
-- 
Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK  Tel +44 (0) 1223 811679
work: http://www.aleph1.co.uk/     play: http://www.chaos.org.uk/~wookey/

--- End Message ---
--- Begin Message --- 
Here's what I wanted to post to the debconf queue, and attempted to
deliver at 23:41 or so. I was a bit hurried when writing, so it's rather
long, but I haven't edited it again as I feel like I'm cheating the
system already by resending this after the deadline.

If I could add anything, it would be to finish with a call to action for
debian desktop users and developers to join the X.org foundation and
help finish fixing that organization by voting free software advocates
to the X.org board.

Thanks so much for offering to insert it into the submission queue.

-keith



		The X Community -- History and Directions
		 	    Keith Packard
		      X Window System Architect
		          keithp@debian.org

This talk will present a social and political history of the X window
system community and match that with contemporaneous technical changes
to argue the thesis that the structure of free software governance
is a key driver of the software development itself.

Early X window system development, in the mid 1980's was run as a
small software project at the MIT Laboratory of Computer Science. As
with many university projects, the X project involved collaborations
with other schools. Corporate involvement was limited to employees
involved in university affiliated projects. Involvement from outside
of the university environment was almost non existent.

At the time of X version 10, the Unix technical workstation market was
led by Sun Microsystems. As there was no freely available window
system at the time, Sun had developed a proprietary window system
called SunView and independent software vendors were starting to write
software for it.

The other Unix workstation vendors, still smarting from the success
Sun had in pushing NFS in the Unix market, were not looking forward to
being forced to adopt the SunView window system. A few people at these
companies saw in the X window system and opportunity to break open the
workstation market and force Sun to play by new rules.

A group of Digital Equipment employees convinced their management that
by taking an improved version of the X window system and publishing it
with a liberal license, they could appear to be setting a new shared standard
for Unix window systems that would enable software developers to write
applications that could be distributed on all Unix systems, rather
than being limited to only Sun machines.

X version 10 was not ready to assume this role. Instead of small
incremental changes as had been the prior practice, a completely new
version of the protocol would be designed that would solve known
issues and prepare the X window system for future technical
challenges. As with any second-system, several large new features were
added without having any real-world experience -- external window
management, synchronized event processing and the X selection
mechanism to name a few.

The work to build version 11 was distributed with the existing
collaborators, at MIT and elsewhere, working with a newly-formed team
of Digital engineers in Palo Alto. While internet-based collaborative
development seems natural for us now, at the time it was somewhat
novel.

At the same time Version 11 development was going on, the limits of
the original BSD TCP implementation were being amply demonstrated on
the nascent internet. The BSD TCP implementation responded to network
overload by transmitting more packets. The effect on the internet at
that time was to render it nearly inoperable for many months. As a
result, the X window system developers took to late-night FTP sessions
and eventually Fed-Ex packages full of mag tapes, which dramatically
slowed down development.

The pain of a broken internet was felt deeply by the developers, and
instead of acknowledging that the internet was now a critical
development resource that just needed fixing, instead it was decided
that distributed development was unworkable and that a centralized
organization was needed where developers could work together.

Starting with the assumption that centralized development was
necessary, the Unix vendors constructed a new corporate consortium,
housed at MIT and lead by the original X window system architect, Bob
Schiefler. This consortium would hire engineers to work at MIT on the
X window system and thus eliminate the internet as a limiting resource
on progress. At its peak, the MIT X Consortium had 8 or 10 staff
members, and an annual budget well in excess of a million dollars.

To feed this appetite, the X consortium sold memberships to major
corporations who would pay for the privilege of controlling X window
system development. An unanticipated consequence of this was that
non-corporate involvement in the X window system was effectively
cut-off. Projects at Stanford and CMU which had been making
substantial contributions to the community were now explicitly outside
the mainline of X development, separated by a wall of money too high
for any one individual to climb.

Another effect was that staff members of the X consortium were now
more equal than other developers; only they had commit access to the
source code repository, which left them as gate-keepers for the
software. Corporations were discouraged from doing in-house
developments as they were 'already paying' for X window system
development through their consortium fees. The result was that a huge
fraction of early X11 development was done by MIT staff members.

The response to this increasing workload on MIT staff was to hire more
staff. MIT offered a low overhead environment, and the consortium fees
were high enough that money didn't seem to be an issue, and getting
developers involved was reduced to a simple matter of paying them to
sit at MIT. From a community software project spanning major
universities and corporation around the world, the X window system had
devolved to a corporate-directed contract programming house with
offices on the MIT campus.

In hindsight, the resulting stagnation of the window system technology
seems only too obvious.

But wait, there's more.

Competing corporate interests eventually worked their way onto the X
consortium board. With Sun admitting defeat in the window system wars,
they were now busy retargetting their SunView API to run on top of X
and aligning themselves with AT&T by jointly producing a new toolkit
called OpenLook. While the API was largely compatible with SunView,
the look and feel were all new, and far better than anything else
available at the time. But, it was closed-source.

Again, other Unix vendors didn't want to be forced to adopt Sun's
proprietary technology, so they banded together to build another
toolkit. Starting from the Xt toolkit intrinsics, they quickly cobbled
together code from HP and Digital into the Motif toolkit. While the
toolkit itself was badly designed and hard to use, it had one
eye-catching feature -- it simulated 3D effects on the screen by using
a combination of light and dark colors on the edges of the objects.

Yes, bling beat out decent UI design. But, it wasn't really just
bling. The 3D effect was used to present Motif as a more technically
advanced toolkit, while in reality, it was just a shiny chrome finish on
a steaming pile of thrown together code. Note that Motif itself was
closed source at this point.

So, we had two toolkits, both closed source and both interested in
becoming the standard for X development. The Xt intrinsics are
(theoretically) capable of supporting multiple user interface designs
(even within the same application), and so the Motif contingent was
able to push the X consortium to adopt it as a standard.

With Xt as "the" intrinsics standard, AT&T & Sun were pushed to
discard their custom toolkit design and create a whole new widget set
using the OpenLook style based on the Xt intrinsics. The combination
of a veneer of standardization of Motif (which remained closed
source), broad (non-Sun/AT&T) vendor support and the fragmentation of
the OpenLook market into three completely separate toolkits (as the
standard NeWS toolkit interface was also OpenLook), software vendors
ran screaming from OpenLook to the "standard" Motif toolkit which then
grew up to become the common desktop environment.

So we see that corporations use the mechanism of an industrial
consortium to push their own agenda, at the expense of their
competitors, and without regard to technical capability.

Of course, we all know the end result of this fractious Unix
in-fighting -- Microsoft grew up from the bottom and took over the
entire desktop market. Large corporations aren't known for their
long-term vision...

With the death of the Unix technical workstation market, the X
consortium grew moribund; while the workstation market wasn't growing
any longer, it didn't entirely disappear. However, with ever-shrinking
revenue streams, the Unix vendors grew less and less interested in new
technology and more and more interested in avoiding additional
expenditures. The X consortium was eventually re-parented under the
Open Group who looked upon it as a potential licensing revenue
stream. Attempts by TOG to extract money from this formerly lucrative
franchise proved futile and eventually the X Consortium was partially
separated from TOG by the member companies and limped along with a
modest budget and strict instructions to not change anything to
radically. A few feeble attempts to jump-start development within that
structure went for naught.

In this same period of time, a small group of people running various
Unix variants on their intel-based machines started collaborating to
improve the support for X for this environment. Patches and eventually
a complete driver suite were passed around, with the intent that they
be plugged into the standard X consortium release and built
in-situo. The XFree86 project grew to support most of the Intel-based
unices, and eventually Linux was ported to it (more changes were
required in Linux than XFree86 to make this work).

When the Open Group attempted to change the X license to permit them
to extract license fees for its use, the XFree86 project refused to
accede and said that they'd continue to support the previous version
of the window system for use on Intel-based Unix systems. This display
of brinksmanship succeeded, and TOG was forced to undo their license
change an X11R6.4 was released with the old MIT license (although TOG
licenses from that period can still be found in some files).

The eventual result of this battle was the ascension of XFree86 as the
new home for X development, a role none of the XFree86 founders
professed to be interested in.

When other developers started working with XFree86 on areas beyond
driver development, XFree86 accepted their changes and published
several version of the window system with new technologies that went
far beyond that provided by the X consortium. Many of these
contributors wanted to see XFree86 accept the mantle of overall X
development, but were unable to lead the project in this direction.

The XFree86 Project, Inc. has a fixed Membership based on the original
founders; these Members elect a President and other officers. Because
the Membership is fixed, there is no way for new developers to gain
any influence within this political part of the organization. Most of
the XFree86 founders eventually stopped technical work on the window
system and left for other pursuits, leaving only a couple of people
with effective control of the project. These people expressed
little interest in expanding the role of the XFree86 project and
eventually removed source code modification privileges for developers
working outside the driver area. Without any way to change the project
from within, these developers were left without a place to do their
work.

Meanwhile, GNU/Linux had spread out from its roots and was starting to
make inroads into the Unix workstation market, and in some minor areas
of the Windows market as well. The former Unix vendors, along with new
GNU/Linux vendors and these disenfranchised X developers were all actively
working separately on X technologies. Eventually, these three groups
found each other and decided to "fix" the X consortium.

Curiously, the fix didn't involve a lot of money from various
corporations, and it didn't involve the creation of a large new
development organization. Instead, the newly formed X.Org Foundation
was set up as a charitable educational foundation, a target for
tax-exempt donations. With membership open to all contributors to the
X window system, and a board elected by that membership, the
organization is better positioned to adapt to change than any of the
previous X organizations.

And, for the rest, you'll have to wait for my presentation at Debconf.

-keith

Attachment: signature.asc
Description: This is a digitally signed message part


--- End Message ---
--- Begin Message --- 
On Wed, 2005-12-14 at 15:10 +0100, Andreas Schuldei wrote:

> feel free to streamline your proposal. that makes it easier for
> the commitee to read through it. it is a good read already,
> though.

I've put together a synopsis that presents the outline of the main
arguments and skips the detailed content.

> please also consider to get some debian-related aspect into it.
> that would increase the chances of accepting it into the main
> tracks.

I'm putting this presentation together for debconf because I think a
historical perspective on why you can't ignore politics in free software
is important for existing Debian developers.

I often hear prominent DDs talk about how they stay away from politics
because it's dominated by the vocal minority; I'd like to give them a
wake up call about what happens when you let that go on for a long time.

>  Like this i would like to set aside a timeslot near the
> fireplace sometimes during an evening. (c: (This would be fun,
> too!)

I'm mostly interested in poking DDs into remaining politically active
and working to fix some of the problems raised by their inaction.
I don't really care how or where it happens.

-keith


The X Community -- History and Directions
Keith Packard
X Window System Architect
keithp@debian.org

Synopsis:

The X window system has been a free software project for nearly 20 years.
The community has been through many different political structures
during this time.

This talk will describe the relationship between the political
structure, technical direction and community involvement in the
project. I will focus on how different structures have been reflected
in the technical direction of the project.

The culmination of the presentation will present the current political
structure of the X.Org Foundation and describe how it finally offers the
free software community an opportunity to effect change in the
direction of this fundemental piece of the GNU/Linux desktop
environment.

There are two separate goals for the presentation:

 1) Encourage *all* Debian developers to remain engaged in the
    political process in both the Debian project and others in which
    they are technically involved. I've seen a dispiriting lack of
    high-level involvement by some of our more technically capable
    members who become too frustrated by the politics and bow out of
    that very important part of our community. Object lessons in how
    this behaviour can go catastrophically wrong may help to pull them
    back into action.

 2) Gather free software advocates into becoming members of the X.org
    foundation so that we make X.Org more responsive to the needs of
    free software distributions and less beholden to the former
    corporate masters of the X consortium.

Attachment: signature.asc
Description: This is a digitally signed message part


--- End Message ---

Attachment: signature.asc
Description: Digital signature

Reply to: