__/ [Larry Qualig] on Thursday 16 February 2006 15:43 \__
>
> mlw wrote:
>> Say whatever you want about Windows, blah blah bah
>>
>> create a shortcut:
>> ssh -XC hostname program.
>>
>> Violla!! You have a desktop link to an application on anther machine.
>
>
> Whoah... not so fast. This is interesting and brings up a much larger
> point. In the spirit of fail disclosure I'll go on record as saying
> that running X-apps remotely is very cool and the performance is
> generally better than using something like RemoteDesktop of VNC. But at
> the same time this example illustrates why Linux is doing so well at
> the IT/Server level and still strugling at the consumer desktop level.
>
> In the IT/Server running X11 apps remotely is a very nice feature. But
> in this world you also have competent technical people who can take
> advantage of this feature.
I agree that there is something less intuitive about this approach (desktop
within desktop), but see the comments which are yet to follow.
> Now lets contrast this to the average consumer desktop. I will offer to
> use my neighbor as an example for this. He's a researcher at Boston
> Scientific (a medical company) with a post graduate degree in chemistry
> from Yale. I know him well and would say that he is certainly brighter
> than the "average" computer user. But he's a chemist who studies
> pharmaceuticals and not a computer geek. This past weekend I helped him
> out for an hour or so setting up his new laptop. His problem was quite
> simple... he wanted to copy a bunch of documents from his old laptop to
> his new one. First I emailed him and told him the easiest way would be
> to "share" the drive on his old laptop and copy them over the network.
> Not a chance this was going to happen without help. So what does this
> have to do with "ssh -XC hostname program" ???
>
> For starters it's not simply typing in "ssh -XC hostname program" and
> have everything work. One simple reason is that most users don't know
> the names of their apps. They know how to click on the icon and run the
> app... but they don't know what the name of the app is. In business the
> most frequently run app is "Microsoft Word" - business users run Word
> more than any other app. So assuming that they could do this (which
> they can't) what would they type?
>
> "ssh -XC hostname Microsoft Word" wouldn't work. Even if they added
> quotes it wouldn't work. Using MSWord as the program name wouldn't work
> either. The correct name is "WinWord" with the point being that your
> typical computer user will *not* know the names of their apps. Easy to
> learn, yes. But users know icons, not application names.
Two points to make:
* Do not forget KSSH and similar front ends. SSH is not a command-line thing
anymore, but experienced users tend to choose that route, which is often
quicker. This tendency often leads to this misconception that Linux is
(still) command-line-driven.
* ssh -XC hostname gnome-panel OR ssh -XC hostname kicker. Put this behind
the KSSH GUI, for example, and voila! The user has got the entire panel
imported from the remote machine. No need for any commands or any typing
into the command-line. User taps icon on the Desktop, a prompt for password
comes up in a widget, user types in password and waits for a new panel to
load up in his/her desktop environment. Then, open any application from the
usual menus.
> But there is a much larger problem. How the hell is the average
> computer user going to learn to setup ssh? First they need to run the
> SSH server on their machine. That's the easy part.
SSH is enabled by default on some distributions. Ubuntu only needs OpenSSH
installed (Synaptic makes this a clickthough job). In SuSE, you need only
open YaST (or go via Control Centre) and tick a box under the networking
header. It makes the workstation accessible via SSH, i.e. an SSH-enabled
server.
> But before you can use ssh you need to generate a public/private
> keypair using sshkeygen. Huh... try explaining a public/private keypair
> to Joe six-pack.
No, you need only log in with your password and the key is generated
automatically. You might be facing some misunderstanding or misconception
here. I have set up SSH on several boxes and on every distribution I tried,
the process was largely automatic.
> So assume that average Joe has a public/private keypair (id_rsa and
> id_rsa.pub). The keys still need to be copied to the server and placed
> in the ~/.ssh "hidden" directory and appended to the authorized_keys
> file. Huh... what's hidden directory average Joe asks? The known_hosts
> file also needs to be updated to allow connections from this remote
> system... and so on and so on.
With all due respect, you are overcomplicating matters only to support your
argument.
> The bottom line is that only a very, very small percentage of "average"
> computer users would have a chance of setting up SSH and getting it to
> work. Once setup.... great. It works nice. But the reality is that this
> would be a nightmare for the average nurse or chemist. For them using
> something like Remote Desktop really is a better solution. But then
> again... they don't have 20 servers to administer remotely. Which once
> again explains why Linux does well in the IT/Server world but isn't
> normally found in average Joe's home.
Are you sure you have set up and are using SuSE 10?
While I concur with some of your arguments, I feel compelled to say that you
got yourself trapped in this illusion that SSH is hard. I have used SSH for
over 5 years, even as a teenager with near-zero (take away or add two)
knowledge of Linux. SSH was one of the first skills I acquired and, if I may
add, I used a front-end for it. It was utterly simple... on par with setting
up a dial-up connection where you need a username, a password and a
telephone number (machine's address). SSH activation on the server is like
pulling a knob.
Best wishes,
Roy
--
Roy S. Schestowitz | "These characters were randomly picked"
http://Schestowitz.com | SuSE Linux | PGP-Key: 0x74572E8E
4:35pm up 30 days 11:36, 14 users, load average: 0.13, 0.19, 0.28
http://iuron.com - Open Source knowledge engine project
|
|
