De: "Kevin Kofler"
Matthew Miller wrote:
> And, it will also allow those of us working on assembling spins
and more
> options — for example, we can have different streams for Atomic without
> needing to actually duplicate every package. (And we could do the same for
> KDE or whatever other artifacts would benefit from that, if we want.)
That destroys the possibility to install all Fedora packages on all
Fedora
spins, which the shared Everything repository guaranteed.
Indeed :(
The initiative posits it is technically possible to define clear-cut autonomous modules,
it is human-effective to do so and that the result will satisfy users. It underestimates
the huge end-user value of an integrated unified repository, that drastically reduces the
human cost of using Fedora.
The technical possibility seems dubious to me given that an awful lot of the software
ecosystem Fedora ships is developed in a bazaar interconnected style. Case in point the
various attempts to make perl optional — it's always rising back somewhere. However
Fedora and Red Hat are good at technical stuff, throw enough devs at it it and some sort
of technical solution to identify and manage possible module boundaries will probably
emerge.
The human effectiveness seems harder. Fedora was never this ambitious before. Spins are
polite abstractions that are mere starting points (by design). I doubt any big deployments
of "pure" Fedora spins without added packages exist. How many market studies do
one need to define sensible functional module boundaries? What will be the shelf life of
the result? How many people need to work on creating and maintaining those boundaries? Is
the community interested on working on this or will it have to be shouldered by the
generous sponsor, making Fedora less a community organisation? A general-purpose OS is
much more complex than the simplistic single-purpose leaf GUI apps shipped on smartphones.
I happily use rygel on a headless box to stream music to various appliances, making it a
dlna server installation even though it is created for desktops. Plus the whole additional
module definition step introduces friction and delay in a fast-moving software
distribution.
Finally, do the users ask for this modularity? Will they like the result? The huge selling
point of live images some years ago was that one could install packages without being
constrained by the predefined selection. Customer feedback on RHEL split repositories and
multiplication of additional channels was dire enough Red Hat had to nix them. I can see
the benefit from a monetization point of view, modules are a great way to construct
textbook market segmentation. However at this stage the benefits of modularity for end
users seem less clear to me. Certainly not clear, concrete and immediate enough to make
huge and inflexible blobs more palatable than modular packages.
I guess Modularity needs to progress to have some answers, but as an experiment it seems
awfully risky to me.
With Modularity
fully implemented, you can end up being unable to install KDE Plasma on the
GNOME Workstation or the other way round (at least without resorting to
containers) because the desktops depend on conflicting versions of some
library module. How is that an improvement?
The problem is not containerization versus parallel installation. Because, let's be
honest, network, storage and hardware will absorb it if not now then in the next years.
And inter-container communication can probably be solved with enough technical investment.
Sure, this investment may seem huge and unnecessary, but that's for the people doing
the work to judge. And I hope they won't forget the dire reputation for slowness
Solaris acquired after years of priorizing convenience over performance (SUN played with
zones before us!).
The problem is that different versions of the same components will have slightly different
behaviour and configuration rules. The amount of divergence users are willing to tolerate
on a single system is way way lower that what can be technically installed using technical
means such as containers or parallel install. That will drastically limit the imaginary
savings of deferring porting apps to the same deps. Unified theming history show it is not
so easy to hide behaviour differences even for simple stupid stuff such as colour values.
Best regards,
--
Nicolas mailhot