Re: Survey results

[Pavel Roskin <proski gnu org>]

Hello, Miguel!

> > So, the Windows port stays in the tree, but perhaps we should drop support
> > to all compilers but one.  I mean MinGW - it's free, it's maintained, it
> > comes with Cygwin.  Also I would like to use "configure" rather than rely 
> > on the distributed pc/config.h.
>
> Well, there is the issue of how to attract Windows people to use MC.  I
> am not sure if MC will ever compete on the Windows world with other
> alternatives (I have not kept track of the alternatives on Windows
> myself), but it would be nice to encourage the Windows port to be
> maintained.

If it becomes easier to compile the current code (as opposed to 4.1.36),
there will be a maintainer.  There are people who want this project to
exist, but they either cannot make all the necessary changes, or don't
want to feed those massive changes back to the sources.

I'll try to do some cleanup if I find time for that.

> > The only "tough call" is mcserv.  It got just 2 votes despite being rather
> > bug-free (although slow) and despite being distributed as a separate
> > package by many Linux distributions (even by the brand-new Mandrake 9.0),
> > whcih could give it some "legitimacy".
>
> Mcserv is only useful for those trying to understand the VFS code, and
> it serves as a reference implementation.  A poor one, which is also
> insecure and not particularly good.

OK, I'll keep is at least until sftp support is implemented.  I hope that
sftp will the the next reference implementation.

> The insecurity bit regarding the password can be fixed by just using a
> challenge/response mechanism to validate the login information instead
> of using the plain text, but that still keeps the data insecure.

Challenge/response requires a shared secret.  The system password is not
good for this purpose, since it will have to be kept unencrypted on the
server.  Encrypted password could be used as the shared secret, but only
on the systems without shadow passwords, which are rare these days.

This opens a whole can of worms, and I don't want to promise more security
that the existing team can provide.  As far as I know, there are no
security experts active in mc-devel gnome org 

> mcserv used to fill the hole of "copy files across computers" which is
> still a useful thing when you lack sysadmin privileges to do an nfs/smb
> mount.  So maybe the functionality is important for some people, if this
> is the case, maybe we should also include mcserv functionality from the
> Command menu `Start Slave Mode' or something.

Well, I didn't realize that.  I always assumed that mcserv is primarily
for embedded systems, which cannot run mc themselves due to memory
constraints.  I'll think about your idea.  That would resolve the problem
of the shared secret - it can be requested on both ends.

> > I think that mcserv should be spun off as a separate project.  It is
> > good for development of embedded systems, when the memory size is an
> > issue, and the security is not.  mcserv can be made very portable,
> > more portable than mc itself (think MS DOS, VxWorks, Netware etc).  
> > As for mcfs, it should stay in the code, disabled by default.
>
> If you disable the code, it will get bit rot.  You should just keep it
> enabled.  That is my suggestion, unless you plan to completely drop
> mcfs.

The item "Network link" in the menu is too generic and may be confusing to
some users.  I've talked to enough users, and I know how easy it is to
confuse them.  mcserv is a dangerous toy for the users who e.g. specify
--with-termcap and --with-terminfo on the same command line and generally
don't know what they are doing.

I don't think that the bit rot will be a big issue until sftp support is
added.  I'm ready to reenable mcfs, but only after making sure that nobody
will consider it _the_ mc filesystem.  See this message:
http://mail.gnome.org/archives/mc-devel/2002-September/msg00128.html

> I think that disabling mcfs and splitting off mcserv amounts to
> completely removing the code.  So either the code stay or you remove it,
> the middle ground is just too much work, and would result in dead code
> anyways.

Well, we have different backgrounds and look differently on the same
issue.  I know many engineers who would be happy to be able to edit some
files on embedded devices without the need to connect the serial console.  
The server doesn't need to change when VFS changes if the protocol is the
same.  On the other hand, mcserv may need to be ported to more embedded
operating systems.

Maybe mcserv should be moved to a separate directory vfs/mcserv with its 
own configure script.  Then the embedded engineers would go straight 
to vfs/mcserv and run configure there.

I don't know is mcserv can succeed as an embedded tool or as a "laplink" 
tool or as both.  I think I'll ask those two users how they use mcserv.

-- 
Regards,
Pavel Roskin