For example, making it so key applications and development stacks
could
> easily float from one base OS to the next would make it less of an issue
> when the base OS needs to be upgraded.
>
Not sure I catch your drift here, but it sounds like it could cause API
mismatch headaches.
>
>
It underscores the need for the base OS or core to be absolutely as small
as possible. FreeBSD provides a good model, small installed system
customized with packages/ports. Personally I would like to see a
three-level approach:
Level 1 (Core) - OS Kernel, command-line utilities, C/C++ compiler and libc
- moves the slowest.
Level 2 (System) - Dev Libraries, interpreters (Python, Ruby, etc), X11,
KDE/QT, GNOME, etc - moves faster.
Level 3 (Userland) - LibreOffice, Firefox, Games, etc.
A major change to one level should cause a rebuild of higher layers to
avoid the API issues you mention. Changes within a layer should be
independent. I would propose change rates of:
Level 1 - 12-18 mos
Level 2 - 6-12 mos
Level 3 - release as soon as stable packages are available.
--
Mark Bidewell
http://www.linkedin.com/in/markbidewell