Thank you for your thoughtful responses, so let me just add a few
comments and a more precise explanation where I am coming from.
Adam Williamson writes:
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.
We should discuss applications and configuration/infrastructure
separately.
On the application level, I see no real problems with the current
situation from my personal perspective. The integration of KDE or
most other applications is seemless enough that this topic is a
non-issue.
For the distribution, on the other hand, it is still worth discussing.
I concede that in most cases it is debatable which of several more or
less equivalent applications is better - if you ask two people, you'll
get three different answers. Also, the choice between a simple clean
tool and a more fully featured one is not universally clear. The
example I gave, though, is one where I personally feel that Fedora is
carrying what at least I perceive as a severely substandard tool (on
many levels, including recurring stability problems and basic
usability deficit) as a default in a very prominent role even blessed
with the generic name "Document Viewer". I think it comes down to the
question of reputation of the distribution: if you push stuff at
people in some officially blessed way (that's what a default setting
is), it is a kind of endorsement, and if you disappoint with your
endorsement, it will reflect back on you. Now this is not the place
to debate whether my judgment in this particular instance is right.
But a distribution should reflect on it and not be afraid to consider
substituting a default if upstream does not get their act together.
Maybe the main point is that you are not forced to default to Gnome in
every case (as for browsers where the is probably a Gnome browser,
too, which few people have ever used - you default to firefox and that
is just fine).
Now concerning system configuration and plumbing, I very much agree
with your sentiments that it is a terrible waste for every
distribution to roll their own system configuration tools. The fewer
different tools, the better. I also have no problem with the current
set of Gnome-based tools, they are clean, work well as far as my
moderate explorations go, and are generally unobtrusive.
So here is where the problem comes in which makes me very itchy: I am
happily using Cinnamon for reasons stated, on Fedora 19, everything is
working great. Now Cinnamon upstream decides, around August/September
this year, that stock Gnome configuration tools are not good enough
for them and they need to roll their own. Fedora picks up the changes
and pushes them out, breaking a couple of things
(suspend/powerbutton/lid close issues, now mostly fixed but still
flaky; network configuration/authentication issues, some fixed, others
with workarounds, VPN still doesn't work at all so need to log into
Gnome to use it on the rare occasion). Fedora cinnamon maintainer is
helpful, says that cinnamon rebased to an old Gnome version, and he
cannot find which Gnome patches fixed these issues, so is waiting for
upstream.
Small issues, but very annoying if you depend on certain features. So
what should I do? Go back to Gnome (classic) where all of this works,
but accepting a small step back in features which I have come to
really like in my day-to-day work? (And hoping that the secondary
screen on top of primary screen is fixed by now.) It's an option.
Wait it out until Fedora cinnamon gets fixed? Could do, it's working
reasonably well and I basically like it, but will it be stable? (I am
fairly tolerant here, but current state is NOT stable.)
I don't have an answer, but I would like Fedora, as a distribution, to
develop an answer without simply deferring to the respective upstreams.
I explained my habits and needs pretty clearly in the earlier post, so
am I a user that Fedora is targeting, who is getting a first-rate
experience?
I am not asking for making cinnamon a first-class supported desktop.
To be honest, I think that would be another outright waste of
resources. But Fedora should acknowledge that cinnamon has raised the
bar on what is the gold-standard for a "traditional" Gnome-based
desktop and react accordingly by making sure that Gnome (most likely
the classic variant, although I don't see a reason why the explicitly
distinction is necessary) is considered at least as attractive as the
competition. That does not mean a feature-for-feature copy, but you
need to determine what people who are currently drawn to Gnome
alternatives are looking for. And please do work with upstream to the
extent possible, a big distribution like Fedora has a clout to
influence what upstream does.
I am also not asking for aggressive rebranding and arbitrary fiddling
with upstream choices (I did use SuSE on university machines for a
while, and it annoyed the hell out of me that they appear make
seemingly random configuration file patches all over the place without
really good reason). But the desktop is so central, the face of the
distribution, that Fedora should have a strategy which is developed
for and with its (Fedora's) userbase. If the strategy matches with
upstream, great, if it doesn't, one has to discuss and potentially
take action. But not having an independent strategy is bad.
That's why I find this discussion so important - it appears for once
to consider a group of users which I consider myself aligning with.
--Marcel
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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop