On Sun, 2013-12-01 at 20:01 +0100, Marcel Oliver wrote: > OK, this was a long post, but I have the impression that there is > actually an audience of Fedora developers somewhat appreciative of > such ideas. I think it would buy Fedora a lot of trust if things were > thought through from the workflows and needs across the spectrum of > existing users, including specialists and "power users". I.e., be > inclusive in your approach to the extent possible with honest effort, > it's going to benefit ALL users. With respect, I don't think this is really what you've outlined in your post; you haven't identified uncontroversial ways in which we could achieve what you suggest, but you've outlined a single particular approach to building a distribution which comes - like any such approach - with both advantages and drawbacks. What you described is the old-school approach to building a distro. It's how RHL started and more or less the approach Fedora took for several releases, and it's how Mandrake used to work, and old-school SUSE. I guess I'll outline it again for clarity's sake and to make sure we're talking about the same thing: You think it ought to be the *distribution's* role to build a coherent environment. Distributions shouldn't follow the designs of upstream desktops, but pick and choose bits between them, and either write their own 'desktop independent' configuration tools or force one set of configuration tools, pulled together by the distribution from the various desktops, on users of all desktops. The distribution should see itself as the product, and tweak upstream code and configuration where appropriate to make it look that way. Like I said, this is how many distros used to work. That's where all the system-config-* tools on Fedora come from; Fedora used to attempt to maintain a comprehensive set of 'configuration tools' named system-config-(something), and strongly encourage the use of those by all Fedora users, whatever desktop they used. We used to try and implement a coherent theme across all desktops and brand the entire bootup series so everything looked like you were running Fedora OS. Other distros did/do this too; Mandrake with the Mandrake Control Center, SUSE with YAST, and so on. I worked on (and for) Mandrake/iva for years, so I'm pretty familiar with the approach. It certainly has its advantages: if the distro strongly encourages use of a single set of configuration tools, for instance, it gives a consistent experience for that distro's users and makes the support situation clear for users and developers: they have to make sure the distro's blessed set of tools works in all situations that are supported. Some people, like you, believe that there's some 'best set of applications' pulled from different desktops - using k3b as the default disk burner in all desktops, for instance. But...it has disadvantages as well, and those disadvantages are the reason Fedora moved away from it. It's a pretty inefficient way to build an operating system, really: distributions are not really where development expertise tends to concentrate, yet the approach places a very heavy burden of development on distributions. They have to write an entire suite of configuration tools and keep it working across multiple desktops. This is an arduous effort; IIRC, probably more than half of Mandrake's entire engineering staff worked full-time on the configuration tools. That's an awful lot of work being done at a rather odd point in the upstream<->downstream chain, and being duplicated by X distributions. It makes it just about impossible to ever design a _really_ cohesive experience: the distribution's configuration tools will inevitably be a major part of the user experience, but they inevitably will not fit in perfectly with how any of the desktops on which they are run are designed. The Fedora config tools never felt quite native in GNOME, KDE or anything else. It introduces more possibilities for bugs to show up, and bugs that aren't simple to resolve at that - the more a distribution 'customizes' upstream stuff, the more likely bugs are to show up in the distro customizations that don't exist upstream, and inevitably in some cases, you get arguments about whether the bug is in the distro customizations or the upstream code, and who ought to fix them. It makes it difficult to develop tight integration between configuration tools and desktops; it requires some kind of abstraction that all the desktops can agree upon. To give a concrete example - distro-implemented config tools typically do okay at configuring systemwide, permanent settings in shared components. But take a look, for instance, at how current GNOME and KDE handle input methods. This is something GNOME has pushed a lot of work into lately. If you happen to want to use Linux in Japanese, GNOME since 3.8 gives you a pretty awesome experience: you pick Japanese during gnome-initial-setup and it configures a very good ibus input method for you. If you pick many other languages that require an input method to type, it handles that very smoothly too. You can switch between input methods for multiple languages and xkb keyboard layouts from the GNOME top panel with a neat little switcher icon. It would be very, very difficult for Fedora to have something like that if we were still sticking to the distribution-developed, desktop-agnostic configuration tool paradigm, because the plumbing for that just doesn't exist in any other desktop. You couldn't write a tool that worked by poking systemwide config files which every desktop respects which would work in the same way, the capacity just doesn't exist. When GNOME considers it GNOME's responsibility to build a coherent environment, and Fedora doesn't try to override GNOME's design and force its own design and configuration tools on it, treating GNOME as just a single element of the 'product called Fedora' to be poked and fiddled into place, this kind of improvement is much more viable. So, I'm not saying you're necessarily wrong, but I think what you're suggesting may be more radical than you may think, and it is not a straightforward decision. Different approaches to distribution design have advantages and disadvantages, there isn't clearly one that is correct. And to go back to my 'prototype' point, I'd argue that the approach Fedora currently uses is probably the best approach for such a 'prototype' distribution. If Fedora still sees it as our goal to drive innovation and improvement of F/OSS software as a whole, to push the envelope and help get new stuff done, then it is appropriate for Fedora *not* to follow the old-school distribution integration approach, because it uses a lot of development resources in writing distribution-level modifications and tools and fixing distribution-level bugs - all resources that could otherwise go to _building better F/OSS software_ - and having such an infrastructure at the distribution level tends to act as a *brake* on rapid development, because you can't land changes into the distro until they are reconciled with the distro's own customizations. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/desktop
