Doing some idle web-browsing, I came across this recent thread, which I found very interesting. Let me start by introducing myself: I am an academic, working in computational mathematics, which has me run simulations and data analysis some, usually a small fraction of my time, write (using LaTeX), and do ordinary office tasks a (too large) fraction of it. I started running my first self-owned Linux box with Redhat 4.2 and have pretty much followed all of the Fedora releases, maybe skipping an occasional few. So the fact that I ended up reading fedora-desktop at all indicates in some way that there is lingering dissatisfaction with the state of Fedora, but a lot of the comments expressed I find encouraging enough to try to spend time to put my thoughts down in a consistent way.
First some historical remarks. Up until Fedora 14, I was actually looking forward to new releases as, despite of occasional breakage, there was a steady increase in quality and capabilities. The point when Fedora, in my experience, really blew it was the transition to Gnome 3 in Fedora 15, and for two independent reasons:
(a) The sudden requirement to have working accelerated graphics drivers in the default install broke the default install on several perfectly good systems.
(b) Pulling out fundamental UI paradigms from under one's feet feels in some way like bodily assault, as all carefully learned workflows and muscle memory suddenly start bumping you every step you take while trying to get real work done. Note that this is not a general critique of Gnome 3 which, with some reservations I will comment on later, I find interesting and a perfectly acceptable approach from a UI development perspective.
What I object to (I have to admit that it makes me angry to this day) is that it is considered acceptable at the distribution level (!) to break user's setup (hardware as well as workflows) in such fundamental ways without providing adequate fallbacks. I have heard technical arguments why this was not possible, and these are possibly strong arguments for all I can tell, but the mere existence of Mate today attests that the pain for the developers cannot have been insurmountable. I also do appreciate the fact that the transition to an accelerated desktop has probably given a good push to graphics driver development. At least all of my systems noadays run fine in accelerated mode. Still, all this is no excuse for breaking user systems at a fundamental level without having a fallback that is at least as good as what worked in the past. To put it another way: as a technically minded user (not system developer!), I do appreciate living on the bleeding edge and do not mind filing the occasional bug report or working around upgrade-related problems, but part of the unspoken deal is that I should not fear that the distribution pulls the rug from under me. If Fedora cannot maintain this fundamental trust, it will lose testers, early adaptors, and end users.
So to get the main points, let me state a few principles of how I would like "my" distribution to be:
1. Chose evolutionary over revolutionary changes whenever possible.
2. Do not remove features (even misfeatures - someone might rely on them) without really good reason (pure aesthetics is a good reason, IMO, but not a "really good reason"). If you do, do it a prepared and well-documented way.
3. Treat "developers" as users who are pushing the envelope more than others, not as a fundamentally different group. A good distribution, UI, desktop, you name it should scale well from novice users to specialists. Trying to draw a line will alienate people on both sides of it.
4. Don't let any one desktop environment define the distribution. The task of the distribution is to _integrate_ different pieces of software so that they can be used together without interference or pain.
5. That said, desktop environment proliferation is not part of a solution, it is part of the problem.
For 1: There are some big changes that appear to work (at least from my perspective, the systemd transition was such as case - it surprised me rather unpleasantly when forced to debug a nonbooting system after gdb decided it would only work with accelerated graphics drivers, but the new workflow was sufficiently well documented and coherent so that this was ultimately a non-issue), but in most cases the pain of throwing away a well-understood codebase for something new seems to outweigh the gains by far (here the anaconda and fedup transitions are a case in point).
For 2: This appears to be well understood in kernel and basic infrastructure circles, but at higher levels in the stack, this mindset is IMO underdeveloped.
For 3: In my experience, I run into either technical issues or usability problems more often when doing "developer" work, but the issues are not necessarily qualitatively different from "ordinary" computer use. Typical situations that a "developer" encounters (many open windows, independent parallel instances of applications, long-running jobs that produce occasional feedback and need monitoring from time to time, running jobs and/or keeping user data on the LAN or even "in the cloud", large amounts of installed applications (because various users on the network have different preferences) are just expressions of a scalability regime which includes the "ordinary" user in the center. Thus, any improvement in handling "extreme" behavior will benefit all users in the end.
For 4: From a user perspective, the problem is not that all g* or k* applications should maximally look and behave alike. That's a task for purists and the respective upstreams. As a user, for the better or worse, I am exposed to a variety of different electronic devices, operating systems, applications of various heritage, web applications, etc. So consistency for me is always relative to what's out there in the world, not to the best-practice example from a small homogeneous software ecosystem. So the distribution should treat all software as equal and make sure it works optimally in a heterogeneous software environment.
Here my main gripes are:
- Currently I have Gnome, KDE, and cinnamon installed (that is on my personal desktop where it might be of questionable value, but in a workgroup/university setup, this is commonplace). The menus are a terrible mess of triplicate utilities without structure, generic names, sometimes identical looking entries which are difficult to navigate if one does not already know what one is looking for.
- No clear separation between system configuration and desktop configuration. I don't need three printer configuration utilities, I need one that works. These are distribution-wide issues, not desktop issues. (I can see that the different desktops like to roll their own thing, and that is fine with me. However, the distribution should go for one option which is the optimally maintained one and use it from all other desktops. For a users it does not make ANY difference if it's the Gnome or cinnamon or KDE tool or something entirely different as long as it is logically laid out and it works.)
- At higher levels in the stack, distributions should choose best-of-breed default applications, not necessarily those who are the "official" desktop environment champions. Case in point: I have always been biased toward using Gnome rather than KDE applications when both exist, with one exception: As a document viewer (and that's a pretty central complex application), okular is such an advance over evince that IMO it really deserves the "Document Viewer" name in the defaults. (The main points: using the "trim margin" feature of okular, most PDF documents which occur in the wild can actually be read at an acceptable magnification without in-page scrolling on modern screens; the page caching of okular is notably better than evince's which is unacceptably slow with bitmapped, i.e. scanned documents even on good hardware.)
So Fedora should bundle what is the best, not what is the "politically correct" application for a given desktop.
For 5: I would very much wish if Fedora would take a lead in unifying at least the Gnome based desktops (Gnome 3, Gnome classic, cinnamon). They all have the same underlying infrastructure, which appears sound for all I know, and the differences are IMO more political than anything else.
To be precise, I have to say that from an aesthetic perspective, I like Gnome 3, and at least in principle I agree with the philosophy that one should not need hundreds of configuration options if the defaults are well chosen and the important ones are there.
However, and this is what I feel is most relevant to the "developer" discussion: Gnome 3 default fails for me mainly due to the missing taskbar. (I know there are extensions, but that is beside the point.) I'll start by saying that, from a purely aesthetic perspective, I actually dislike the taskbar: it is taking vertical screen real estate from me and it starts looking ugly, with ridiculously shortened application names, when the number of windows gets large. Unfortunately, this is precisely the regime when the Gnome overview mode (I am using cinnamon right now, so I have both for direct comparison) becomes outright unusable. The problem with overview is that when there are too many windows, I cannot read, or can hardly read the text while, at the same time, I have no good sense of the mapping of the logical order of the windows to the display order in overview mode. The taskbar, while also unable to provide meaningful text, still has an accurate history of the order in which the windows where opened. This means that I can usually find the window I need surprisingly quickly and reliably while overview mode greets me with an unusable mess and even ALT-tab is often hard to use (e.g., I am comparing the output of an old and a new run after I fixed my code. The labeling of the two windows is identical, the output looks very similar. So which is which? No problem if I have a strict time line, impossible with anything else).
Abstractly speaking, the problem is with best handling a number of 40-80 and more open windows, and here the taskbar is the least bad. (Windows seems to have a hierachical, application-based system, which I have not explored very much, and I am not sure if this is not incurring more problems than it solves.)
A second workflow where I absolutely depend on the taskbar is for spotting small differences in graphical output or data visualization where I move one window over the other and flip the upper window on and off from the taskbar. This is arguably a very specialized use case ("developer/scientific workstation"), but is incredibly useful and without replacement in the Gnome 3 paradigm.
So, if I could have a wish unconstrained by politics and internal technical issues, I would like to see the best features of cinnamon merged into Gnome classic and make Gnome classic a runtime (not start-up time) configurable option (maybe a set of related options) in standard Gnome 3. Call it even "expert mode" and hide it somewhat away from casual users. That would go a long way of reaching a wide range of users with a single setup and also reassure users that their workflows are welcome and long-term supported.
I have toyed both with current Gnome classic and cinnamon, so for the record a list of features that make me (mildly) prefer cinnamon. I think they are relevant to get a "developer user" point of view:
- Taskbar in cinnamon is right-clickable as it used to be in Gnome 2.
- It is possible to configure a "vertical maximize" feature, which is more useful than the various edge-snap options as, especially for developer use, the width of windows is usually well-defined and should not be changed, but one often wants maximal number of viewable lines. I think it would make a lot of sense to make this feature defined (rather have it as part of a broad set of otherwise relatively uninteresting configuration options)
- I came to like the "single taskbar at bottom" approach as I usually plug in an external screen into a laptop which is sitting physically above the (ultrabook) laptop, so I want it logically above, too. I did this for years also with the old Gnome 2, so the top bar on the primary screen is not a deal breaker, but in this secondary over primary screen scenario (which I think is the only natural one for the plug-into-laptop situation), it feels more natural not to have a top bar on the primary screen. Minor detail though. (Related to this, Gnome and Gnome classic had a persistent bug in this configuration which I filed but I don't think is fixed at least according to bugzilla, which is indeed a dealbreaker.)
- The panel editing and configuration seemed very natural (better than when I tried Gnome classic), but this may be just a moment's impression, so I do not attach weight to this. I do like (most of) the the cinnamon defaults, though, in particular the relatively minimal vertical footprint of the taskbar, and the windows and virtual screen switcher.
- I don't remember if this is only a Gnome thing or also a Gnome-classic thing: If I tell the UI to open a second instance of an application, I would expect a second instance and not to be shown the first.
My conclusion is that there is nothing in cinnamon which could not be done in Gnome (classic) without a major break in design philosophy. (As much as I like cinnamon in general and appreciate the work going into it, lingering bugs (I have filed a few) make it look like the maintenance burden is at the brink of feasibility.)
Two more remarks on what I find extremely important from a "developer" perspective:
- Focus follows mouse (or sloppy focus) and - right/middle mouse copy/paste.
I am mentioning this because I have seen these features, probably because they deviate from "expected" behavior in other operating systems, be relegated from standard in the old days to "dig deep in preferences", resp. talk about changing right/middle mouse behavior in Gnome. I have worked on systems without them, but I find them such tremendous productivity boosters that I keep coming back to them as soon as I can. (Note: I am writing this on a laptop which does not even have a physical middle-mouse, so I enabled three-finger tap to be equivalent to middle-mouse - this looks like a hack, but it's actually so convenient that I find myself using the three-finger tap even when, like now, I have a physical mouse attached. So again, this would be a good feature for standardization - I don't even care how it is mapped to taps or gestures as long as remains consistently reliably available on modern hardware.)
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.
Regards, Marcel
--------------------------------------------------------------------- Marcel Oliver Phone: +49-421-200-3212 School of Engineering and Science Fax: +49-421-200-3103 Jacobs University m.oliver@jacobs-university.de Campus Ring 1 oliver@member.ams.org 28759 Bremen, Germany http://math.jacobs-university.de/oliver ---------------------------------------------------------------------
On Sun, 2013-12-01 at 20:01 +0100, Marcel Oliver wrote:
(a) The sudden requirement to have working accelerated graphics drivers in the default install broke the default install on several perfectly good systems.
Unfortunately you've based your argument on a false premise. There has never been a requirement for accelerated graphics drivers in the default install; the early GNOME 3-based releases implemented fallback mode to handle cases where acceleration wasn't available, and later ones implemented llvmpipe. If anything, Fedora was a driver for both developments, and IIRC, Fedora did explicitly decide that it would be a non-starter to ship Shell without some kind of cover for non-accelerated systems.
terrible mess of triplicate utilities without structure, generic names, sometimes identical looking entries which are difficult to navigate if one does not already know what one is looking for.
Even knowing exactly what I'm looking for doesn't necessarily protect me from having to play the guessing game. For some apps it really boils down to pure chance if the right one is going to open.
Disambiguating those generic names would be an obvious and easy fix but I doubt it'll happen.
If you are willing to dispense with some of the convenience fluff that the DEs offer you might want to look at one of the tiling window managers like e.g. Awesome. They generally come with sane defaults (like focus-follows-mouse and so on) but take some learning and configuration effort until you get used to it and know how to best make use of their functionality. As a payoff you'll never have to fiddle with window placement or weird menus again. ;-)
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.
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
Hi,
I pretty much agree with what Adam replied. I'll just address one point, generalizing it:
On 1 December 2013 20:01, Marcel Oliver m.oliver@jacobs-university.de wrote:
- At higher levels in the stack, distributions should choose best-of-breed default applications, not necessarily those who are the "official" desktop environment champions. Case in point: I have always been biased toward using Gnome rather than KDE applications when both exist, with one exception: As a document viewer (and that's a pretty central complex application), okular is such an advance over evince that IMO it really deserves the "Document Viewer" name in the defaults. (The main points: using the "trim margin" feature of okular, most PDF documents which occur in the wild can actually be read at an acceptable magnification without in-page scrolling on modern screens; the page caching of okular is notably better than evince's which is unacceptably slow with bitmapped, i.e. scanned documents even on good hardware.)
So Fedora should bundle what is the best, not what is the "politically correct" application for a given desktop.
The distribution concept just needs to go. Leave it in the 1990s where it belongs and let's instead build an OS shall we?
To get on your point, what you need is not for the best document viewer to be bundled. You need a damn good document viewer for your use case. And it shouldn't be the distribution's business to find one for you. Why? Because at this level in the software stack (i.e. applications) users have very specific needs, and why should someone throwing together a distro know what's the best document viewer for you?
Yes, what we need is to let applications flourish (or not) on their own merits, build a brand for themselves. If they are good, users will find them.
What the OS should do is provide a solid and well defined base for application developers to target *and* make it really easy for users to install applications.
To get on your case again, perhaps something like Mendeley would be a good fit? Let's try it. We go to [1] and what do we see? We have Ubuntu/Debian packages (awesome, linux is supported!) and for other linuxes we get a .tar.bz2 and these instructions:
" 1. Open the downloaded archive 2. Extract the contents to any folder 3. Run the application
Within the extracted folder, open a terminal and run the following command:
./bin/mendeleydesktop "
Not really nice, is it? At least the .deb package is nicer to install with just a few clicks. Unfortunately, it runs a little script as root that adds to your apt repositories, which is convenient, but is the distribution update channel a good fit for applications? Clearly not, given all the reports around the web of failed updates due to 3rd party repositories creeping in onto users systems.
Rui
[1] http://www.mendeley.com/download-mendeley-desktop PS: I just googled this up, I didn't even know about it before, nor did I try it. You might argue it's not free software but there's no reason a free software alternative couldn't be doing the same.
desktop@lists.fedoraproject.org