Experiences with KDE-CVS at LinuxWorldExpo

[Kurt Pfeifle]

Kurt Pfeifle wrote:

[....]
> Two items will get mentioned in this mail:
> 
>  * the need (and "market") for a desktop configuration that
>    satisfies the rollout of 1000s of machines within a short
>    period
[....]

Hi, all,

I was unable to follow the threat for the last 2 days. I re-read how it
developed just now. So I won't reply specifically to all points. But here
is a summary of my thoughts.

First of all, thank you for those hints to the kde-kiosk mailing list and
their archives, as well as the README.kiosk file. They contain valuable
information.

Now for some arguments which were used in the discussion.


* "Unix tools can do that all since a long time..."

Excuse me, this reminds me of the same arrogant responses I met 3 years
ago when I started to campaign for the ditching of LPR/LPD in favour of
CUPS. "We don't need no new printing system, Unix tools can do whatever
you want...". One difference is, that *then* I knew the old venerable
printing daemon as well as a better alternative to the old tool, while
today I don't really know either.

Wasn't even KDE itself received with the "same" argument: "UNIX does have
more than one GUI desktop already -- why looking for something new?"

This argument is of no help at all. Show me where these tools are used in
a real-world installation (even if it is only a few dozen machines). Or
show me at least a fully-worked out HOWTO which describes the setup. A
"plan" in the mind of a UNIX-guru who already has a clear idea for himself
how he *would* do it with the help of shell scripts and existing Unix tools
if he got assigned the task will not convince any potential customer (nor me).

Of course, all available tools should be utilized. But they need to be
integrated into one unified, concise administration tool (web based or GUI)
which allows for a central installation, configuration and long-term
administration for thousands of KDE-based clients. And of course this must
include non-KDE applications too.


* "There is no way to avoid learning shell scripting to achieve what you want."

Nice. Convincing. *Not*! I myself started to create my own shell scripts a
few months ago. This was only because there was KDE first, which built a bridge
for me: use UNIX/Linux with a GUI first, and after I felt comfortable there,
leave the GUI on occasions to do some work more efficiently on the shell...
But this is hardly a good way to start on Linux, if you are used to a Windows
GUI.

The same argument could have been thrown at our bold KDE pioneers more than 5
years ago: "If you want people to do their work on UNIX workstations, teach them
shell scripting...." -- Fortunately they didn't listen, and the caravane moved on...


* "This reminds me of Windows."

So what?

Even if anybody had said s.th. similar as that, it wouldn't turn to become a
valid argument in and of itself. Would it mean this is a bad thing? If so, tell
why. Name some arguments why this is bad. Name or describe a specific
alternative.


* "These customers seem to want a 1:1 copy of Windows"

No. They want to get their work done. They want to know if it could be done on
Linux. They describe what they need to have done on these machines. They also
want an efficient way to install and run and maintain a potential new deployment.
If they were out for a 1:1 copy of Windows, they would stick to the original
in the first place. Fact is, they want to move *away* from the dependency to
Microsoft Windows... "Accusing" them of wanting to copy Windows is just a silly
stance...

The potential customers did rarely say "we want it made to work like Windows".
And if so, it meant that they had a well working solution on Windows.
All they did was describing their environment, what their requirements are and
how they imagine a solution should work. This is what I paraphrased in my first
mail. I won't repeat it here and now.

---------------

I think there are two distinct models to solve tasks like that, and I think
KDE needs solutions for both:

# 1 #
-----
Thin or very thin clients. No program runs natively on the client (apart from
just the X server) -- all applications run on one or more centralized servers,
which also store the user "profiles",  probably in a database or in an LDAP
directory.

# 2 #
-----
"Fat" clients. A complete set of all programs are installed on the clients.
"Profiles" and home directories are on central file servers. The profile is
retrieved if the user logs in and decides about the subset of programs the
user is allowed to start and use.

----------------

Of course, this is not just concerning KDE applications. It is to be applied
to all programs. (After all KDE is an environment friendly enough to let
GNOME, OpenOffice.org, Netscape, Mozilla or whatever applications run on its
desktop...)

The argument for the creation of a GUI program is not just "to do a favor to
all these ex-NT administrators" whom we want to enable to administer a large
environment of KDE desktops in an enterprise. It is also doing a favor to all
Unix/Linux people who like GUIs too. After all, KDE is about GUIs, by and
large... Or am I missing something?   ;-)

Cheers,
Kurt