Updated Fedora Workstation PRD draft

Marcel Oliver m.oliver at jacobs-university.de
Tue Dec 3 01:18:18 UTC 2013


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 at lists.fedoraproject.org
 > https://admin.fedoraproject.org/mailman/listinfo/desktop


More information about the desktop mailing list