RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk)

[Mark Bidewell]

>
>
> No one said that stuff should change "unexpectedly" (and that's not
> what currently happens either).
> Actually its the opposite you want to consider the "whole picture"
> when doing changes and not think
> of independent pieces stuck together. That's why the "lets build some
> core platform and put stuff on top
> of it" is flawed.
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>

Honestly, I keep seeing this argument in this thread, but it doesn't square
with reality.  The concept of an OS and all of its apps as a monolithic
distribution with a single release schedule is unique to Linux.  Every
other major OS (with the exception perhaps of Windows) strictly
differentiates between core OS and apps.  Some examples:

FreeBSD - installs a core OS  on which ports and packages are installed
into a separate tree.  Versions of Ports are allowed to float independent
of the BSD base.
PC-BSD - listing separately because in addition to the separation by
FreeBSD, it introduces self-contained packages that even ship with their
own libraries to keep the core clean
MacOSX - System is kept in a separate tree from apps.  Modification of
System Paths is strongly discouraged.  Apps are installed in a parallel
tree or as packages similar to PC-BSD.
Solaris - only ships with an extremely minimal system.  Virtually all apps
must be install separately.

Windows ships a core OS but allows (at least in the past - can't speak to
8) installed apps and libraries to mix with system libraries.  But even
they seem to be moving toward a more sandboxed model.


This is not to say that the Above OSs have it right, but to say a core /
apps separation is fundamentally flawed is incorrect.  I would say the
separation allows for more robust upgrades ( user-installed software
doesn't taint the system tree) and more rapid upgrades of apps (a
Libreoffice update should have to wait on the Kernel).




-- 
Mark Bidewell
http://www.linkedin.com/in/markbidewell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130726/c092c631/attachment.html>