DapperStandardsBase

Differences between revisions 9 and 10
⇤ ← Revision 9 as of 2005-11-05 17:02:16 →
Size: 2070
Editor: 209
Comment:
← Revision 10 as of 2005-11-05 17:38:29 → ⇥
Size: 3353
Editor: 209
Comment: save occasionally
Deletions are marked like this. Additions are marked like this.
Line 10: Line 10:
With only a little extra work, we can make a Standerds Base by providing a set of dapper features that will be supported in every further Ubuntu release for five years.

This standards base should specify the library APIs that can be used (old libraries can be shipped in a compat section or pocket of further releases) and also focus on the system APIs (how do you add your program to Applications, etc.) that we will support in Ubuntu releases (through packages in the compat section or pocket). This BOF should outline those APIs and provide a specification for writing the DapperStandardsBase document.		 Any attempt to make a "Dapper Standards Base" is likely doomed to the same failures that the "Linux Standards Base" have had. The need for a system against which people can certify and can also make derivatives is key to the success of Ubuntu. This specification provides a middle road that balances these two needs.
Line 16: Line 14:
Dapper will be supported for five years, which makes it a great thing for vendors that which to support their software on Ubuntu. Dapper will be supported for five years, which makes it a great thing for vendors that which to support their software on Ubuntu. Ubuntu and Launchpad make it trivial to brand and customize Ubuntu. The conflicting needs of these two use cases require us to define a core of Ubuntu that can be counted on.

However, the more variables we introduce into the supported system, the more trouble we will have asking vendors to certify. Further, security updates may cause necessary kernel ABI changes causing problems for third party hardware vendors.
Line 20: Line 20:
* Sue from Oracle wants to certify that their DBMS runs on Ubuntu, and they don't want to have to recertify every release or update. === Servers ===

 * Sue from Oracle wants to certify that their DBMS runs on Ubuntu, and they don't want to have to recertify every release or update.

=== Desktop ===

 * Seb from Canonical purchased his computer from emachines, which ships a branded version of Ubuntu. He wants to purchase third party commercial products that have been certified against Ubuntu.

=== Hardware Vendors ===

 * Sally from 3com wants to sell more network cards. 3com cards have hardware acceleration in them that handles multicast packets. The code to feed these is proprietary and not possible to provide in a GPLd driver. Sally wants to solve this problem by providing a network driver for servers running their cards.
Line 24: Line 34:
== Design == All packages included in main.
Line 28: Line 38:
=== Code === We have chosen to be conservative when defining the core of Ubuntu. A branded derivative MUST NOT remove or alter any packages that are installed by default with ubuntu-minimal, ubuntu-standard, ubuntu-desktop, or linux-*. The exception to this is that a branded derivative MAY replace the contents of ubuntu-desktop and ubuntu-artwork.
Line 30: Line 40:
=== Data preservation and migration === An Ubuntu derivative MAY installation additional software from main by default.

An Ubuntu derivative MAY install third-party software by default, but a third party vendor MAY require that software to be removed before accepting bug reports on their software.

Summary

Any attempt to make a "Dapper Standards Base" is likely doomed to the same failures that the "Linux Standards Base" have had. The need for a system against which people can certify and can also make derivatives is key to the success of Ubuntu. This specification provides a middle road that balances these two needs.

Rationale

Dapper will be supported for five years, which makes it a great thing for vendors that which to support their software on Ubuntu. Ubuntu and Launchpad make it trivial to brand and customize Ubuntu. The conflicting needs of these two use cases require us to define a core of Ubuntu that can be counted on.

However, the more variables we introduce into the supported system, the more trouble we will have asking vendors to certify. Further, security updates may cause necessary kernel ABI changes causing problems for third party hardware vendors.

Use cases

Servers

  • Sue from Oracle wants to certify that their DBMS runs on Ubuntu, and they don't want to have to recertify every release or update.

Desktop

  • Seb from Canonical purchased his computer from emachines, which ships a branded version of Ubuntu. He wants to purchase third party commercial products that have been certified against Ubuntu.

Hardware Vendors

  • Sally from 3com wants to sell more network cards. 3com cards have hardware acceleration in them that handles multicast packets. The code to feed these is proprietary and not possible to provide in a GPLd driver. Sally wants to solve this problem by providing a network driver for servers running their cards.

Scope

All packages included in main.

Implementation

We have chosen to be conservative when defining the core of Ubuntu. A branded derivative MUST NOT remove or alter any packages that are installed by default with ubuntu-minimal, ubuntu-standard, ubuntu-desktop, or linux-*. The exception to this is that a branded derivative MAY replace the contents of ubuntu-desktop and ubuntu-artwork.

An Ubuntu derivative MAY installation additional software from main by default.

An Ubuntu derivative MAY install third-party software by default, but a third party vendor MAY require that software to be removed before accepting bug reports on their software.

Outstanding issues

Do we support the whole thing for five years, or do we try to split out a server api from desktop api stuff?

There are interesting questions about kernal ABI compatability changes over security releases. Sometimes the ABI change is required.

BoF agenda and discussion

Dapper Standards Base comes out to the fact that ISV's will not certify on an extra "compat" repository.

Users can usually just make things work by editing their repositories to get "backwards compatability" by adding Dapper to their repository list.

So, even if this isn't much work it does not generate anything significant that is worth doing.

Oracle FAQ about linux: http://www.oracle.com/technology/tech/linux/htdocs/oracleonlinux_faq.html

DapperStandardsBase (last edited 2008-08-06 16:17:15 by localhost)