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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
