Matthew Garrett writes:
Some comments on this proposal: From my POV what is missing is the
academic/science/engineering workstation use:
* Use of a variety of standard, in-house developed, and/or third party
tools to run simulations, analyze data, visualize results, etc.
Examples are R, Scipy, Sagemath, gnuplot, ... from standard
repository, as well as Matlab, Mathematica, IDL, ... from the
* Complex workflows involving a variety of different tools
* Users depend on window manger for managing windows (it cannot be
assumed that applications are nice/self-managing in any way, often
no IDE or several IDEs as mixture of tools is too diverse). Typical
scenarios are lots of terminal windows displaying text diagnostic
output of long-running jobs on local or remote machines, lots of
visualization windows created by various tools - often home-brewed,
all mixed with editor windows for program or glue code,
wordprocessing, LaTeX, web, several open documents in PDF viewer,
email, everything is part of the same workflow.
* At least on centrally managed machines software selection is close
to install everything as academic users tend to have very different
ideas of what software they should use, so system administrators
will install a lot. Disk space is cheap, but it's taxing on
* Use of big/high-res/multiple screens in various geometric
configurations; also: projector use for presentations needs to
absolutely work in all circumstances (which it mostly does nowadays,
from my observations at least on par with Windows/Mac now).
Especially in academia on tends to encounter a great variety of
different projector generations of varying quality, typically
without the chance of much prior testing, so it absolutely needs to
* Various roaming scenarios need to work (VPN, eduroam which is
PEAP/MSCHAPv2 authentication). This should in principle be a
non-issue, but I mention this because of recent problems with both,
so I get the impression that QA in this area is not very strong.
Particular challenges for the desktop:
* How to unclutter menus, make entries non-ambiguous?
* How to reliably find a particular window if you have 10 terminal
windows each displaying number columns? (This is where Gnome 3
falls flat, for example.)
* How to efficiently navigate to windows on big/multiple screen
* How to efficiently manage windows on big/multiple screens?
(maximize, edge snap is usually doing the wrong thing. Vertical
maximize works usually better, good tiling strategies???)
* Good workspace switching, keep child windows on their proper
workspaces even if they pop up in the background
* Taskbar or taskbar-like behavior for raising single windows without
disturbing the visual context by overview mode.
* For big server/large workgroup installations, Fedora is probably too
unstable by definition. I have only ever seen either RHEL/CentOS or
OpenSuSE used in this context. So going for serious stability is
probably out of scope, and conflicts at some level with the need to
get timely updates on fast-moving software.
* From the draft: "This would include items like theming and making
sure we offer a consistent accessibility story across different
development toolkits." From my POV theming plays no role at all so
long as the basic workflow requirements are met. Also, "consistent
accessibility" I see more on the side of a consumer product.
Consistency is nothing that Fedora can achieve at the level where it
would really be useful, so what is more important is accessibility
and compatibility in the face of real-world inconsistencies.
* From the draft: "a requirement that any software that wants to be
part of Fedora Workstation can run against Wayland or directly
output sound to Pulse Audio". I am not sure what that buys. Yes,
it would be a generally good idea to fix up software that violate
these goals. But that's a general (and worthy) Fedora goal.
Especially for Fedora _Workstation_ I would see the requirement the
other way round: can the base system be compatible enough so that I
can get legacy code from back when Wayland was not even dreamed of,
strange in-house developments, obscure toolkits etc. run at least in
some way without running through impossible hoops.
* For compatibility with third party/commercial software, one should
probably narrow down to specific needs. From my perspective, these
would include Matlab, Mathematica, Maple, NAG libraries, ifortran,
IDL, and similar tools with a long and usually good history of
compatibility. But ideally the free software alternatives should be
there and integrated well to reduce the need for commercial tools as
much as possible while still acknowledging that people might have
(legacy) needs which make it inconvenient or impossible to avoid
proprietary software. Other users might have completely different
needs, so it would be good to compile a collection of wider