On Fri, Jan 06, 2017 at 07:14:58PM +0100, Kevin Kofler wrote: > > This is a good point; we're already pretty much awful on this point, > > and let's not make it worse. (On the other hand, modularity has the > > potential to help significantly on this point, as you should't need > > detailed metadata about what's _inside_ a module at runtime in normal > > circumstances.) > > At that point, we stop being a distribution and become a salad bar of > bits and pieces that may or may not work together, where both look > and feel integration and functional features will end up disabled > because they would depend on libraries from another module, and that > each contain their own redundant copies of the same libraries. I > think that is a huge step backwards, and if actually fully > implemented, will likely force me to switch to a different > distribution.
Analogies are always tricky, but I think that's definitely the wrong one here. Right now what we have is a casserole, where we bake every ingredient together in the same way - in the same dish at the same temperature for the same time. With that approach, you're always going to get some ingredients which ... don't work so well. What we're exploring with Modularity is offering a menu of different dishes - and, yeah, it might be a menu where you can't order the goulash and the chocolate pudding on the same plate. This is a change, but sometimes change is okay. This change reflects a very, very real shift in IT, which containers have accelerated but which really took off over a decade ago (!) with datacenter virtualization. Not only does one not need all of the stuff running in one namespace, but it's best practice _to not to_. We spend a lot of effort optimizing for that everything-cooked-together dish, which increasingly people do not even want. As I've said since the first "Rings" proposal, if people in Fedora want to continue working on the casserole, and feel like that's an important and valuable thing, *awesome*. But if that's *all* we do, we're going to be a footnote in history. -- Matthew Miller <mat...@fedoraproject.org> Fedora Project Leader _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
