Linux Foundation Collaboration Summit

An exceptionally full house at the Linux Collaboration Summit with nearly all the names that matter.  Current panel has Andrew Morton, James Bottomley, Chris Wright, Ted T'so and Greg KH, moderated by Jonathan Corbet.  See the web site for the full agenda for details.  Jonathan's first question was related to the stability of Linux, which led to a fairly lively discussion discussion.  Even Christoph Helwig had some heckling, er, good points to make, including the fact that the rate of change has led to less community review, and the fact that there is still no regression test suite.



There are several forces pulling in different directions, leading to a lot of tension on the core kernel, including support for new hardware, stability for old hardware, support for new features, stability for commercial end users, continued subsystem clean up, purity and simplicity of design, ease of mainenance, etc.  Also, the "scratch your own itch" philosophy of code development leads to a lot of new and conflicting technologies moving in parallel to mainline.



Mark Shuttleworth started and engaged in a discussion where Andrew Morton requested more detailed input from the distros, including problem areas, proposed release dates, staying closer to mainline (perhaps), and better dealing with API stability (and how that causes divergence from mainline and related stability).  There was some applauding of the fact that distros were pushing back on accepting changes that were not also and already upstream.  That helps maintain a single source for bug fixing, stabilization, and a location for hardware enablement.



Don Marti from LinuxWorld.com asked about Andrew's State of the Union comments about Linux's lack of Power Management and for an update on the state of Power Management and what help others could provide.  Today most power management in linux is binary - on or off, where many vendors are now providing low power or reduced power states.  Andrew strongly requested access to specifications to devices in general, specifically here for power management APIs but generally the community has requested APIs for devices in general to help make the devices operate optimally on Linux.



Jonathan pointed out that a recent driver he had written did not have suspend/resume capabilities and the community did not point out the need for power management as a basis for accepting a fully functioning driver (good point) but Greg KH pointed out that the community will accept drivers at any stage of development, assuming that they will evolve over time to have more complete functionality.  Jesse Barnes from Intel pointed out that there is not a robust, complete API or environment for people to program to.  Also, Jesse reiterated that specs for devices are good - but he would also like to see vendors write their own Linux drivers for their hardware.  Greg KH pointed out that he has 85 driver writers standing by, ready to write drivers for devices that vendors contribute and provide specifications to.



David Slessinger from Axxess pointed out that mobile/open source activites are more prolific now but Chris Wright countered that the mobile folks are not very visible to the kernel community.  More engagement, visibility and interaction there would be helpful.  Greg KH pointed out that servers have the same power management needs as the mobile community and the two communities need to work together better (server and mobility) with respect to power management.



Ted suggested that an interface to broadccast that a disk was just spun up could be used to communicate to other subsystems that the disk is available, power has been expended, why not opportunistically do any other current activities that need access to a spun up disk?  Andrew pointed out that he has not seen requests, requirements from the mobile community and really doesn't know what capabilities that they really need.



Accessibility workgroup chair, Janina Sajka is present and mentioned that a screen reader patch is available for the kernel but Greg KH pointed out that the patch needs a lot of work and it needs some testing - however he doesn't have access to the hardware to test.  Janina promised to work with him to get a coder and tester to get the code into the kernel.



Darren Dagless (sp)? from Novell brought up ATI & nVidia proprietary drivers.  Novell has a lot of proprietary driver partners and Novell does not support those drivers directly.  Christoph suggested to tell them to "go away" - however we do want access to the hardware that some of those vendors provide.  This area is as contentious as always - with the primary viewpoint of the kernel community is that vendors need to provide open source drivers or users need to avoid the use of those hardware.  Ted also pointed out that both individual users and system vendors integrating hardware into their systems need to be conscious of the open source driver availability of the hardware components that they use.



Greg KH pointed out that the Linux Foundation has a mechanism for allowing vendors to provide specifications to the Linux Foundation under NDA and still get a driver written and supported by the community.



Stephen Von Nicholson from Ziff-Davis talked about how ATI has now offered up specifications even if not drivers.  On June 29th 2007 the GPLv3 will go live.  He asked what the kernel community now thinks about GPLv3 (earlier some had claimed that the GPLv3 was the end of free software as we know it).  Greg KH still believes that the GPLv3 has not addressed the primary problems and is not a fan of it for use with the Linux kernel.  James pointed out the the logistics for converting to GPLv3 are probably also prohibitive because there are no localized ownership for copyright, etc., and the benefits of GPLv3 are not likely to be compelling for a change that would be logistically overwhelming at best.  Ted pointed out that the GPLv3 has improved dramatically over the past year or so, and he is not as opposed to the use of GPLv3 for user level applications as appopriate.  James and Ted point out that Eban Moglen was very responsive to the problems pointed out by the kernel community (among others).  And, there is now one more license in the ecosystem and they will all over time co-exist.



Someone asked if the kernel could be converted to GPLv2/GPLv3 dual licensed.  General answer was "not easily" and "not likely".  Don Marti pointed out that 1/3rd of the kernel is already licensed (in source code comments) as GPLv2 or later, as opposed to GPLv2 only.  Also, much of the kernel is dual licensed today, especially in the driver space (e.g. drivers used in both Linux and BSD is pretty common, with different licenses).



Jonathan posed a question about contributors - lots of US and Europe centric contributors, lots of desktop and server vendors, but not much from Asia, not much from mobile and embedded companies.  His question focused on how to expand the contributor community to include a more representative, diverse set of companies and interests.  Andrew pointed out that some vendors have not seen a need to interact with the communiy, in part because of the high rate of change of their products, and the need for a longer term involvement with the kernel community.  James pointed out also that the discussions are all in English, so non-English speakers are at an inherent disadvantage.  There is an LF collaboration summit in Japan already, James suggested one in India or Africa would be possible.  Also, the existance of a "universal translator" might help, with a couple of chuckles aimed at the Google folks present since they seem to be active in spaces like this.  Chris pointed out that the developer community has not been getting as much "new" membership lately, especially in the core contributor space.  Ted pointed out that the OSDL/LF sponsored Japanese collaboration summits provided simultaneous translation to/from Japanese/English which substantially helped collaboration at those summits.



That ends the first session, and I'll do more if my battery, fingers, and attention span all hold out.

Powered by ScribeFire.