>I think we have a UNIX guru v.s Windoz end user split here.
I totally agree.
>I am a long time UNIX user/developer. I did a port of V7 UNIX to a 68000 in
>1981. I conceed UNIX guru standing to few people. In many ways my carreer
>has been data transfer. I could create a solution from scratch with enough
>time and money. In spite of that I can't find an EASY solution to the file
>transfer problem between Windoz systems. On Windoz I am a relative novice
>and I have sympathy for the other Windoz novices. I think this is the key
>platform generating all of these requests. Every UNIX box already has an FTP
>server running unless someone goes out of their way to disable it. Windoz
>(and the Mac) are more problematic.
Well put. I haven't even been able to *find* a workable, free SSH or SCP
implementation for my Macs, let alone figure out how to use it. Such
things do exist for Windows, but I'm not sure whether they are avilable in
"free AND easy-to-use" flavour. In that respect, running OpenSSH under
Cygwin32 doesn't cut it.
The same goes for file transfer - and by that I mean across the Internet.
Putting security concerns aside for a moment, I can run a freeware FTP
server and/or client on my Mac with a reasonable amount of ease. However,
these Macs are behind a double-firewall which I have little control over,
and so accessing these services is extremely difficult. It's fiddly enough
setting up a tunnel to run VNC through in the first place.
There is a *very* simple FTP client built into Windows, but it's hardly
easy to use. It's essentially a badly-done port of the original BSD FTP
client, which itself was originally designed for "UNIX gurus". Does the
average user even know where this client is, let alone how to use it? Can
they remember that you have to set it into BINARY mode every time you start
it up? Doubt it. Is there a free, easy-to-use Windows FTP server, along
the lines of NetPresenz for the Mac? Again, doubt it. BTW, even
NetPresenz is shareware.
Speaking from my own point of view as a "power user" familiar with multiple
platforms, the current situation is workable but darned inconvenient.
Without trying to insult the general userbase, I notice that few "normal
users" have the skills necessary to juggle FTP clients/servers, SSH
tunnels, and a VNC session all at once, nor have the inclination to learn.
As it is, it takes quite a feat of mental agility to fully understand how
an SSH tunnel works, without even trying to look at the encryption side of
it or tunnel FTP through it. Consider that one of the FAQ's on this list
concerns the distinction between the HTTP and RFB ports on the server, and
ask yourself whether that class of user would find it "easy" or
"convenient" to set up an FTP server and transfer files that way.
One of the main arguments against the file-transfer capability of VNC
appears to be the old "creeping featurism" one, leading to "code bloat".
AFAIK, the current server AND viewer (for Windows) fit on a single floppy
disk together. It is possible to fit a Mac server and viewer on a floppy
twice over at present, without using compression. I hardly think that a
simple file-transfer capability, such as the one I outlined the other day,
would increase the executable code size by more than about 20K - and that's
a pessimistic estimate, based on my experience with RISC processors (which
usually have larger-than-normal code sizes). Secure connections, which are
the other "big want" right now, will need more than that due to the complex
encryption algorithms involved - but I think we should still easily be able
to fit the Mac server and viewer on a floppy together. Without using
compression.
>Part of the problem is the ease of VNC installation. 90% of the people of
>all skill levels are quickly up and running assuming secure access has
>already been addressed. This means that VNC itself is usable by a large
>spread of skill sets.
Which is exactly the reason why file-transfers and secure connections have
to be just as easy - if not easier - as setting up a VNC session in the
first place.
>What would be helpful as a start is for someone to collect the currently
>existing solutions into a single document and then somehow make that
>document available to VNC users, probably as a pointer in the FAQ. (I would
>be happy to host the document on my web pages if there is no better
>solution.) It is all well and good to declare this to be not a VNC issue but
>it is a perennial issue for many VNC users. Once you make a connection often
>the second thing many users want to do is copy a file. The current FAQ
>addresses this issue basically by saying "we ain't going to do it; you're on
>your own." This is unhelpful to say the least and generally perceived as
>negative and adversarial by people trying to solve the problem for
>themselves.
I think even "power users" like myself would love to have such a
description, especially in the case where (as at present) no file-transfer
facility is available at the VNC level, or that functionality has been
disabled. Sometimes we have to work with unfamiliar platforms, too.
--------------------------------------------------------------
from: Jonathan "Chromatix" Morton
mail: [EMAIL PROTECTED] (not for attachments)
big-mail: [EMAIL PROTECTED]
uni-mail: [EMAIL PROTECTED]
The key to knowledge is not to rely on people to teach you it.
Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/
-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
-----END GEEK CODE BLOCK-----
---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to [EMAIL PROTECTED]
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------
