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

[Reindl Harald]

Am 26.07.2013 14:20, schrieb Mark Bidewell:
> 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

what is a good compromise

> 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

which is completly broken from a security point of view

* the app-bundles heavily contain their own library versions
* the typical app on a Mac is installed by the user and writeable by the user
* there is no sane way for a *central* update of all applications

> 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.

the same as OSX in case of bundling libraries resulting in your never
know which of your apps are still vulnerable

> This is not to say that the Above OSs have it right

they don't

> but to say a core / apps separation is fundamentally flawed is incorrect

it is correct

* go and play around with "ldd /usr/bin/whatever-application
* look how many share openssl, nspr, nss, libxml and a lot of more
* and now draw the picture of the result fix a security issue in libxml

with having app-bundles you finally end in more and more bring their
bundeled libraries because they are built against specific versions
and the one from the core maybe too old or too new for a specific
application version

in the end you have a unknown mixture of different versions of
several libraries with different bugs and vulerabilities and
the fun of more used ressources because they are not shared


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130726/b248b7a7/attachment.sig>