Discussion of Fedora Server use-cases

Miloslav Trmač mitr at volny.cz
Wed Oct 30 17:11:16 UTC 2013


On Wed, Oct 30, 2013 at 1:20 AM, "Jóhann B. Guðmundsson"
<johannbg at gmail.com> wrote:
>
> On 10/29/2013 09:48 PM, Miloslav Trmač wrote:
>>
>> This has been done in the past, and this could be done again, if we
>> really tried.
>
> Why waste our time with something that has never worked in the past?

Because the past has been different.

In the past, even most of the "simple" servers (... well, even the
underlying multi-processing OS kernel, and the TCP/IP stack) were a
Big Deal, very costly proprietary software.
In the past, a company could have saved money by not buying that
proprietary software and instead hiring a specialized administrator to
deal with the Open Source alternative.

Nowadays, every server product will give you a HTTP server, a DNS
server, a DHCP server, and the like, for a fraction of an admin's
salary.  Using the free product is no longer that good a deal if the
software requires extra manual effort or extra training to manage (or
googling to find the right man page).

> Why focus on desktop on servers when Microsoft the OS you seem to be so
> desperately trying to imitating is moving away from having a DE running on
> their servers?

A "desktop" is not necessary: What about (completely fictional) a
terminal login prompt on one virtual console, a browser on another
console, and on a third console a GUI combining immediate status
display (CPU usage at 50%; your hard drive is failing! RAID out of
sync!) with a login prompt to access a configuration GUI?  No window
manager or desktop is necessary to get this.

> Our primary task as I see it is deployment/ha/scalability/reliability while
> we leave the desktop application to the workstation WG and the web frontent
> to the Cloud WG...

Yes; a good UI is a part of the deployment/reliability story.  The
"desktop application" for managing a server is really out of scope for
the Workstation WG as proposed.  The management interface and the
underlying API would be much better implemented by the same group.
    Mirek


More information about the server mailing list