On Sun, 2014-11-23 at 09:55 +0100, Stef Walter wrote:
On 23.11.2014 05:43, John Unland wrote:
> Hello everyone,
> I have been talking with Stephen about a DE for F22 and he has
> given me a green light for proposing just that so here it goes:
> Objective for proposal:
> -To implement a desktop environment for F22 Server.
> -Let the user have a choice for going to a DE or bare CLI.
> -Have a GUI toolbox to diagnose hardware and networks.
First lets note that all of the above are possible today with F21, and
are easy for people to do when the need arises. Using various methods:
a) There is a single command to install a DE on Fedora Server:
# yum install @xfce (or whatever desktop you feel like)
b) Install Fedora Workstation and install the services you want
your Server to provide on top of that.
But secondly, having a big heavy GUI displayed on screens attached to
the server is the legacy way of doing things, and not best practice
going forward. Remotely controlling your server from a laptop (or
other device) has been the best practice for a long time now. Even
Windows has realized this.
I think that Fedora should strive make the best-practice things
trivial. Other non best-practice stuff should also be possible. As
noted above this use case is already possible in F21 without
additional development effort. We should not go out of our way to make
it trivial to do legacy stuff, especially if it's already possible.
> Justification for proposal: The addition of a DE to F22 (x86)
> would give system admins a choice of going to headless or use GUI
> interface. Additionally many companies do not have the resources to
> have rack cabinets or extra machines to access the Cockpit (Most of
> these companies are small businesses).
The expected method for using Cockpit is *not* to install an
additional workstation with a monitor sitting next to your servers.
You use your laptop and/or tablet to control and access your servers.
Even sysadmins at small businesses have these.
> Also there are some software packages that need a desktop interface
> to install such as Bitnami (https://bitnami.com/
) or Oracle
> Database, this not only applies to open source software but
> proprietary software which mostly installs on a GUI interface.
These are legacy situations. Server software that requires X11 just to
install is due for an update. But as noted above, Fedora Server 21
already gives you what you need right now to accommodate situations
> Sidenote: Even the Windows Server has a GUI and if you want to go
> to just a plain CLI then you can do that. So why not Fedora
Even having said all that, I wouldn't be against having Cockpit run on
a monitor plugged into the server, when that's desired and configured.
In fact I used to think this was a prerequisite for Cockpit. But I'm
now of the opinion that this is a legacy situation. Neither I nor
anyone I'm aware of has put development effort toward it. I wouldn't
be against such work however. It's just not a priority.
That said, what I think *should* be a F22 priority is displaying the
Cockpit URL on the VT. So that if someone does plug in a monitor
directly to a server (eg: troubleshooting situation), it is trivial to
discover what URL to type into their laptop or tablet.
> Implementation: Wayland as a display server with KDE or Gnome (per
> Server SIG's suggestions) as the default DE.
Do Oracle and Bitnami installers really use GTK3? More likely they
remain with the older GTK2 which requires X11.
I don't know about Bitnami, but Oracle's installers are pretty much all
Java-based, so they use whatever underlying tech is available to the
virtual machine. This is also true of a LOT of other third-party tech. A
huge number of apps are written with Java-based graphical installers
because that works on most Windows deployments and "it's Java, so we'll
just keep it the same on all other systems".
In keeping with your comments above, I'd be interested in seeing whether
we can solve some of these problems by potentially having an in-browser
X server for Cockpit, so that (with the exception of a few edge cases
that don't work with remote X) we can handle this legacy stuff in a
If they did use GTK3 (and thus supported Wayland) it would be easy
provide Broadway support to show their GTK3 based UI in Cockpit
itself, remotely. GTK3 supports this natively:
> Most of the applications if not all will be removed including
> widgets and any fancy graphics. Also this would be a great
> opportunity to apply some GUI tools such as Wireshark to the DE.
Side note: Best practice for Wireshark is to run it against a server
remotely. In fact running it on the server in question, especially
running it privileged, opens up a bunch of security attacks. While
this is possible today, it should be made to be trivial (see above
about best-practice -> trivial).
> That is all, the floor is open to anyone. I am very open to
> constructive criticism.
Lastly, I believe that installers should get simpler with less
options, not more. It is a concrete usability issue when the user
configures everything in the installer, and then has no idea where to
go to make a change to the choice made at install time.
If we're using Windows as an example, it should be noted that their
Windows Server installer asks no questions about how they would like
their server to be configured, or what to display at first boot. All
of that is configured afterwards.
So while I appreciate the time and thought in this proposal, I believe
it goes in the wrong direction for a Server OS. The legacy use cases
it puts forward are already possible today with F21.
server mailing list