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.
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). 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.
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 Server?
Implementation: Wayland as a display server with KDE or Gnome (per Server SIG's suggestions) as the default DE. 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.
Notes for KDE: KDE's "Netbook Workspace" might be a good starting point to have since it's designed for "Quick-use", might be minimal enough for a server environment.
Alternative DE: I would also like to propose a LXDE or LXQt as a alternative DE because both KDE and Gnome are both heavy DE's in terms of RAM and widgets / flair. Also there stripped enough that they will do the job just as well as a heavily modified KDE and Gnome.
That is all, the floor is open to anyone. I am very open to constructive criticism.
Alternativo DE: i3 El nov 23, 2014 1:43 AM, "John Unland" opensourcejohn2112@gmail.com escribió:
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.
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). 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.
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 Server?
Implementation: Wayland as a display server with KDE or Gnome (per Server SIG's suggestions) as the default DE. 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.
Notes for KDE: KDE's "Netbook Workspace" might be a good starting point to have since it's designed for "Quick-use", might be minimal enough for a server environment.
Alternative DE: I would also like to propose a LXDE or LXQt as a alternative DE because both KDE and Gnome are both heavy DE's in terms of RAM and widgets / flair. Also there stripped enough that they will do the job just as well as a heavily modified KDE and Gnome.
That is all, the floor is open to anyone. I am very open to constructive criticism. _______________________________________________ server mailing list server@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/server
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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 like this.
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 Server?
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.
If they did use GTK3 (and thus supported Wayland) it would be easy to provide Broadway support to show their GTK3 based UI in Cockpit itself, remotely. GTK3 supports this natively:
http://blogs.gnome.org/alexl/2011/04/18/broadway-update-3/
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.
Cheers,
Stef
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 like this.
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 Server?
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 modern way.
If they did use GTK3 (and thus supported Wayland) it would be easy to provide Broadway support to show their GTK3 based UI in Cockpit itself, remotely. GTK3 supports this natively:
http://blogs.gnome.org/alexl/2011/04/18/broadway-update-3/
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.
Cheers,
Stef _______________________________________________ server mailing list server@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/server
On Sun, Nov 23, 2014 at 09:55:57AM +0100, Stef Walter wrote:
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.
Display the URL and a QR code:
qrencode -t UTF8 http://fedoraproject.org
(The qrencode-libs library is part of the Fedora base system because systemd uses it. So this should not be hard to add.)
Am 23.11.2014 um 05:43 schrieb John Unland:
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.
in other words going back to Fedora as with F20?
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
don't get me wrong but if somebody is not able to just
* install the desktop packages with yum/dnf *or* * install the desktop product and afterwards the server packages
he has really other and more serious problems by maintaining a server
Sidenote: Even the Windows Server has a GUI
completly wrong - even windows server *now* has a non-gui mode which did not exist over decades while you propose the opposite
On 22 November 2014 at 21:43, John Unland opensourcejohn2112@gmail.com wrote:
Hello everyone,
Implementation: Wayland as a display server with KDE or Gnome (per Server SIG's suggestions) as the default DE. 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.
So a lot of servers only come with 2d only video cards which requires that a llvm emulator of 3d to be around for various things that KDE and/or Gnome need. Having recently had to deal with an app that needed a local X this was extremely painful to try (the Raspberry pi without closed source drivers had better video performance than this). The app ran fine since it relied on gtk2 but the rest of the desktop to try and get the app working was visible redraw city. It was in the end faster to X11 forward to the laptop even though buttons didn't redraw correctly etc.
The speed issues are a problem that the desktop team aren't interested in which is part of the reason we have different products. With the fact that server admins end up using oddball desktops (i3, xfce, lxde, e18, etc etc.) for lack of 3d reasons.. I am not sure the long fights over which one gets selected because its the ligthest weight are going to be short either.
Thus I am more for the let the admin install it via a yum command when they need it and choose what they think is best.
So from everyone's responses it seems like this a no-go for the GUI. But I'm glad to have done it anyways.
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.
I like this, but there just needs to be more people that see this as a feature that needs to be added into Cockpit...
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.
Yes, I know some appliances use this freeNAS and Turnkey Linux.
Do Oracle and Bitnami installers really use GTK3? More likely they remain with the older GTK2 which requires X11.
For Bitnami, I think it's GTK3...(Don't quote me on that.) as for Oracle you would have to ask Mr. Gallagher since he and some other people have found that Oracle needs a GUI to install.
don't get me wrong but if somebody is not able to just
- install the desktop packages with yum/dnf *or*
- install the desktop product and afterwards the server packages
he has really other and more serious problems by maintaining a server
Guess you have point there...
So a lot of servers only come with 2d only video cards which requires that a llvm emulator of 3d to be around for various things that KDE and/or Gnome need. Having recently >had to deal with an app that needed a local X this was extremely painful to try (the Raspberry pi without closed source drivers had better video performance than this). The app >ran fine since it relied on gtk2 but the rest of the desktop to try and get the app working was visible redraw city. It was in the end faster to X11 forward to the laptop even though >buttons didn't redraw correctly etc.
Thus I am more for the let the admin install it via a yum command when they need it and choose what they think is best.
Yes, many of my 1U server have the ATI Rage integrated into the motherboard, but I guess having a desktop would be very problematic...
Floor is still open...
On Sun, 2014-11-23 at 18:52 -0600, John Unland wrote:
So from everyone's responses it seems like this a no-go for the GUI. But I'm glad to have done it anyways.
Well, I think that it's becoming a general sentiment that a *blessed* GUI is not aligned with our goals at this point. That doesn't mean however that we should not make an effort to document how to install any GUI of your preference manually. If you wanted to write up a blog series on common or useful graphical server tools, we can publish them on the Fedora Server blog[1] for people to find.
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.
I like this, but there just needs to be more people that see this as a feature that needs to be added into Cockpit...
Well, not necessarily. This could actually be solved at the packaging level (theoretically) by having the browser's default homepage be set up as 'http://%60hostname%60:9090' and automatically started when a graphical session is launched if you're running on a Fedora Server-based system. This wouldn't be a tremendously difficult thing to implement, I suspect. (The trickiest part would be setting the defaults on a wide range of desktops).
Maybe that's a project you would be interested in taking on, John?
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.
Yes, I know some appliances use this freeNAS and Turnkey Linux.
On Mon, 2014-11-24 at 09:02 -0500, Stephen Gallagher wrote:
On Sun, 2014-11-23 at 18:52 -0600, John Unland wrote:
So from everyone's responses it seems like this a no-go for the GUI. But I'm glad to have done it anyways.
Well, I think that it's becoming a general sentiment that a *blessed* GUI is not aligned with our goals at this point. That doesn't mean however that we should not make an effort to document how to install any GUI of your preference manually. If you wanted to write up a blog series on common or useful graphical server tools, we can publish them on the Fedora Server blog[1] for people to find.
Just to follow up on this, I've published a blog entry[1] today describing the simple mechanism for installing any of Fedora's graphical environments atop Fedora Server. Enjoy!
[1] http://fedoraserver-wgblog.rhcloud.com/graphical-desktop-environments-on-fed...
Thank you for writing that up Stephen. Awesome read!
On Tue, Dec 2, 2014 at 7:22 PM, Stephen Gallagher sgallagh@redhat.com wrote:
On Mon, 2014-11-24 at 09:02 -0500, Stephen Gallagher wrote:
On Sun, 2014-11-23 at 18:52 -0600, John Unland wrote:
So from everyone's responses it seems like this a no-go for the GUI. But I'm glad to have done it anyways.
Well, I think that it's becoming a general sentiment that a *blessed* GUI is not aligned with our goals at this point. That doesn't mean however that we should not make an effort to document how to install any GUI of your preference manually. If you wanted to write up a blog series on common or useful graphical server tools, we can publish them on the Fedora Server blog[1] for people to find.
Just to follow up on this, I've published a blog entry[1] today describing the simple mechanism for installing any of Fedora's graphical environments atop Fedora Server. Enjoy!
[1] http://fedoraserver-wgblog.rhcloud.com/graphical-desktop-environments-on-fed...
server mailing list server@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/server
----- Original Message -----
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: ... Alternative DE: I would also like to propose a LXDE or LXQt as a alternative DE because both KDE and Gnome are both heavy DE's in terms of RAM and widgets / flair. Also there stripped enough that they will do the job just as well as a heavily modified KDE and Gnome.
Just one note - it's also about ability to support these alternative DEs and have community/maintainers. It's not only about resources as computing resources.
Jaroslav
That is all, the floor is open to anyone. I am very open to constructive criticism. _______________________________________________ server mailing list server@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/server
server@lists.fedoraproject.org