Discussion of Fedora Server use-cases

Stephen Gallagher sgallagh at redhat.com
Wed Oct 30 12:47:20 UTC 2013


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/29/2013 05:41 PM, Miloslav Trma─Ź wrote:
> On Mon, Oct 28, 2013 at 3:18 PM, Simo Sorce <simo at redhat.com>
> wrote:
>> Sorry I am not sure what you mean here. If you mean the Server
>> image will never have a graphical UI I don't think we are all on
>> the same boat.
>> 
>> Not that I want to install such UI by default, but not all people
>> are comfortable managing headless servers, so the option almost
>> certainly needs to be there.
> 
> <flame_proof_suit> The UNIX CLI is, over time, less and less an
> acceptable interface.
> 
> It's good and efficient at what it has been originally designed
> for (manipulating line-oriented text by experts - all those two-
> and three-character commands and little languages).
> 
> It's not particularly great at interactive use when compared to an 
> efficient GUI (the command names and options inconsistent, many
> and long; the configuration file format is even more inconsistent
> than the command names and options; to use either of them one has
> to either remember a lot of option names / config directives, or to
> constantly read documentation).
> 
> It's not a particularly good programming environment either - no
> IDE, no type checking / lint / code completion.
> 
> There are only two major interfaces worse than the UNIX CLI: A GUI 
> that was not designed to be efficient, and an application with a
> GUI that doesn't have any programmable interface. 
> </flame_proof_suit>
> 
> I think we should, over time, move towards a "G"UI (whether local
> or web is an implementation detail in this) for one-time use, and
> an actual API used by an actual, current-era, programming language,
> for automated use.  The CLI will obviously stay, both because many
> users are comfortable with it, and because we can't replace it
> during this decade.


I agree with this completely, and it's one of the principal drivers of
the OpenLMI project[1] (full disclosure: I'm heavily involved in this
effort).

Under the hood, we have abstracted large amounts of the underlying
subsystems of the Linux system into a set of CIM object models and
exposed them as a stable API. We've then gone and built a scripting
environment (using the python language; nothing new to learn like
PowerShell) and cli "meta-command" builder[2].

Right now, we don't have any public GUI consuming this interface
because our research among Red Hat's customers strongly indicated that
real-world administrators care more about a scriptable interface than
they do a GUI. That's not to say that there is zero interest in such a
GUI, but that it's secondary to getting day-to-day, repetitive tasks done.

Also, to head off some of the NIH concerns that may be in your mind
after reading the earlier discussion about the system-config-* UIs,
the OpenLMI project is currently being developed jointly by several
companies, led by Red Hat but with contributors from Dell, SUSE and
others.


[1] http://www.openlmi.org
[2] http://www.openlmi.org/scriptdocs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJw/9gACgkQeiVVYja6o6NQ+gCgknEO2JVi5iGwVeIsvG9d16pn
f1MAnR0WpM7FvKYusuH6Hl6cmDw06bVF
=cxP0
-----END PGP SIGNATURE-----


More information about the server mailing list