For example, making it so key applications and development stacks
> 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
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
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.