GNOME.org
 

Re: Your mc efforts is a great job !!! [Warning]: Long

Hi Pavel,

Pavel Roskin wrote:


On Wed, 29 Oct 2003, Nikolai Bezroukov wrote:

[snip]


This discussion is something that others are more likely to participate
in.

True.  Still no takers...

[snip]


I think we are completely misunderstanding each other.  Hotkeys have
noting to do with it.  Either mcserv remains are a file server, or it
becomes a file server plus shell server (like sshd).  I believe we don't
need another shell server.  If you have a different opinion, please show
your code.  But if you don't document every function, I'm not going to
look at your patch.  There are enough good patches in the queue that I
don't have time to apply.
We actually don't, unless you want us to ;-). We just have different positions on the issue. I expressed algitimate (I suppose) opinion that mcserv can be a perfect "fileserver+shell server" conbination. You already vioced your opinion before that msserv is redundant and now reiterated your points again. I disagree, but I suppose that understood you correctly. And please do not overuse this hammer 
"show me the code" ;-).
[snip]


I'm not going to compromise on security.  If you want insecure mcserv,
make it a separate project.  Port it to DOS, VxWorks, whatever.  I'm sure
embedded developers will like it.  GNU Midnight Commander will not enable
by default any inherently insecure code as long as I maintain it.
Security is the matter of IQ. Rephazing a Russian proverb, it's better to lose some with a clever admin, 
than to gain some with a foollish one.
Idiot admin with ssh will always have a less secure system that a competent admin with telnet and ftp 
and my point is that mc is for intelligent admins ;-)
In no way encryption on the application level like in ssh is panacea. On the transport level its another story (Ipsec). FYI Open SSH 1 was one of the major sources of "real" break-ins for ISPs. Do not know stats for 'real' breakins for SSH2 but the latest CERT advisories (CA-2002-36. etc) does not encorage blind trust 
and suggest that there still risks due to the complexity of the codebase.

[snip]


I'd rather have a blend of ssh and scp/sftp.


Here I have other opinion, but I respect yours.
[snip]


> I was confused by "VFS" meaning two different things on adjacent
> lines. I still don't know what NC5 XTree VFS is. I have never used NC5.

That's how I call "flat file VFS". As a PhD I have the responsibility to
obscure things by inventing new terms ;-). See also
http://www.softpanorama.org/OFM/Ofm_00.shtml.  The book discuses several
implementations including NC5.


Actually, this should be implemented separately from VFS, as a higher
level.  It's representations of the tree on the panels, not
representations of something as a tree.
You might be wrong, as semantically this is yet another VFS, not that different from tar VFS or gzip VFS. 


> > The idea is to have access to top and bottom directory in the
> > current panel (which of course depends of your sorting mode) via
> > hotkeys.
> As I said, I'm not aware of such key in mc.

It's actually not defined either in OFM1999 standard or in OFM2004
standard  (see http://www.softpanorama.org/OFM/Ofm_08.shtml and
http://www.softpanorama.org/OFM/Ofm_09.shtml ). Here is what OFM1999 is
saying  (sorry, it's slightly Windows-biased ;-) :

   The hotkey assignment for sorting is optional.  If the hotkey is
   defined its action should correspond to the F9-(LR)-S sequence for
   the current panel and display the same menu so that the proper order
   can be selected with the second key from the menu. Alternatively,
   Ctrl-F3, Ctrl-F4, Ctrl-F5, Ctrl-F6 and Ctrl-F7 can be used for
   sorting by name, extension, modification time, size and unsorted,
   correspondingly ("NETSU" order).

For Unix you need to add the ability to sort by sort by permissions,
owner and group.  So the menu selection string became "NETSUPOG".

As for the hotkey, actually, how about Ctrl-A ?  A very convenient
hotkey for a frequently used operation  (and resorting of columns is
definitely very frequently used, at least by advanced users). Actually
you are in a better position to suggest a suitable hotkey as I do not
really understand all the tradeoffs of the Unix environment especially
the potential conflicts with Emacs/XEmacs (I use Vim/Gvim).


Please reread this.  I think you are misunderstanding me.  As I understand,
you wanted a hotkey to place the cursor on the first or last directory by
one keystroke.
No, that was a wrong idea. Forget about it. I realized that this should be better addressed by F10 (already in the TODO list), if the tree is positioned on the current directory. 


I wrote you that we don't have such keys Actually, for the first
directory, Home is pretty close in most cases.  But suppose we have 1000
directories and 2000 files in some directory.  Then going to the last
_directory_ can be a boring task.

Now you are quoting text about sorting and asking me what I think about
using Ctrl-A for _sorting_, not for going to the last directory.

Here I was probably wrong. I learned that FAR is using Ctrl-F12.


I consider your efforts to be really outstanding because you not only
managed to revitalize the development, but also stop the feature creep.
Without your efforts mc probably would scale down to version 4.35.  IMHO
two of your recent decisions  (1) to clean the code of GUI-related staff
and (2) Windows-port related staff were very timely.


Thank you for your support.  I wish you were around when those features
were being added.

You are quite welcomed. Thank  you very much for your efforts !!!


Two things are now more or less clear:

   -  mc is in the stabilization phase and it's level of maturity is
   reasonably high,


This doesn't apply to VFS, although I hope to fix it.  Support for
background operations is a worse problem - it's useful, but I cannot be
implemented correctly without major changes.

I would say the code is in the "active stabilization" mode.  Sometimes the
only way to fix the code is to change it until it's clear what it does.
I'm not kidding, unfortunately.
That's a common situation not limited ot mc. You might benefit from Doxygen <http://www.abisource.com/doxygen/> 

[snip]


That's why I think it make sense to bite the bullet and move this
"cleaning" strategy on a new level by using the capabilities of S-lang.
Adding S-lang and exposing relevant internal functions might took the
same amount of efforts as a regular cleaning of code that is needed
anyway,  but with much better return on the investment. Iit gives you an
opportunity to concentrate on simplifying and refactoring the core
codebase by removing several ad hoc mini-languages invented in usual
hacker-style traditions. For example, the code implementing "user
extension predicates" and "user menu visibility predicates" are two
examples of mini-languages, implementations of which can instantly be
replaced with S-lang with no or very little effort.


I want to release a version that doesn't complain about "Invalid read of
size 4" in extfs_free().  Then I want to release a version that doesn't
have buffers of fixed sizes for paths.  I want to release a version that
has all contributed patches incorporated.

Please note that we don't currently include S-Lang interpreter, only
S-Lang screen library.  Also, it's possible to compile mc with ncurses
without S-Lang.  I believe ncurses support is worth keeping for now.
That complicates things. If the current goal is simplicity, that should be wieghted against the amount of code that need to be maintaned when you support both, and the amount when you need to support just S-lang. 
I'd like to see how you would handle something like the Open action for
HTML (search for "html" in mc.ext.in) - that action indeed has grown too
large.
That's a drawback of any scripting approach -- it can be too slow. So be it. 
Nothing is perfect and scripting is not a panacea for all situations.


Also the pool of people who can develop/polish scriptable parts is
bigger/deeper.  That's a natural separation of labor that the current
development environment is lacking:  you need to be a jack of all trades
and react to each and every hotkey problem (actually even in todays
situation several things from the discussions can probably be added to
FAQ to cut the number of such issues).  Assuming the core and scripting
part are separated you have a core team and the extension development
community like in Emacs. that's a more powerful combination and I
suspect that more people might be willing to help with the scripting,
but few would dig into the current C codebase.


I agree with your idea of separation of labor, but I don't see how it can
work with the current codebase.  Besides, all changes need to be reviewed,
and I don't see how switching to S-Lang would help.  I don't know any
S-Lang programmers.
Niether do I. But IMHO anybody with scripting language experience can do useful things in S-lang. 
Still I agree with you that this is currently "bird in the sky" thing.


Also I'm afraid you are overestimating the number of problems with
keys that can be fixed by making them scriptable.  Many problems are
inherent to terminals.
True. It does not make them to go away, thouth. I would like to stress it again: in case one meed to administer many different OSes, mcserver might help as it is not dependent on the terminal on the target machine. 
Moreover S-lang usage in mc may provide stimulus for further improvement
of both the S-lang and its interpreter and thus lift some or all of the
current limitations/reservations. There also may be some kind of
cross-pollination / integration with jed, which is a much better editor
then cooledit , so this is actually not a one time tradeoff when you can
lose of win, but a dynamic situation, a potentially mutually beneficial
two-way process.


My experience shows that "cross-pollination" doesn't work.  We had
Cooledit code in mc.  There were patches sent to the mc lists with fixes
for the editor.  Some were specific to the text mode, some were not.
Nobody cared to forward those patches to the Cooledit maintainer.  It
takes time.  When people contribute code for free, it's hard to ask them
to do extra efforts, especially with software they don't use (i.e.
graphical Cooledit).

Neither did "cross-pollination" work for Samba.  Changes in vfs/samba are
not contributed to the Samba project.  In fact, the code we are including
has become a library of its own, based on old Samba code.

You might be right. .


It is true that S-lang has its own warts and limitations, but please
understand that is such situation there is no best choice, only the
worst choice and this might be inaction.  The truth is that even the
worst choice (let's say adopting bash ;-) is better than none: scripting
language is one of the few available avenues of addressing the feature
creep problem .


I really don't care that much about the programming language for the
scripts as long as it works.

I suggested using bash for mc.ext, but others in this list didn't like the
idea.  I don't remember the reasons, but it should be archived.
Actually I was wrong. You idea with bash for mc.ext might actually be not a bad idea 
and can be used in mc.menu too.


The real question is whether you want to make mc.ext and mc.menu single
programs or not.  If they are single programs, then the choice of the
language doesn't matter - mc will be communicating with a program.
IMHO they are not monolitic scripts. I suspect that they are closer to script libraries, similar to startup scripts, but this does not invalidate your idea. For example you can represent shortcuts as soft link names for the script. Variables exposed by mc can be just be converted into environment variables like MC_ALTPATH for %D, or MC_FILE for %f, etc. That might help to solve problem with non-working substitution in quick cd command. The question is what is the return on the investment 
in the simplification of code, as better is the enemy of good.


If you want mc.ext and mc.menu to be sets of scripts that are parsed by
mc, then I can say that they are already written in bash.
I agree about bash. Both looks like a sets of scripts and as I mentioned above it might make sense to store them in a way similar to starup scripts. To achive the effect of generation of the menu that is used in mc you need to have a special option for each script (like status) and when invoked with this option the script needs to produces a menu entry if conditions are met, nothing if not. 


The other solution might be exposing API and introducing a FAR-style
plug-ins mechanism, although they have their own problems and having a
two dozens or more of them installed lead to "overcrowding of the
kitchen". But technically this is as simple as introducing plug-in menu
in addition to the user menu or option to call a plug-in in the user menu.


This would lock the API at the time when significant reorganization of
code is underway.
True, but my point is that it's easier then adding scripting language because you can partially reuse ideas that FAR and Total Commander APIs. And that might suggest some directions of reorganization 
of the codebase.


If the recent crisis, that you resolved by stepping in, is any
indication about the future, a large pure-C open-source implementation
like mc might not be sustainable due to the level of complexity and
those of them, which cannot not attract enough resources need either to
scale down of face the possibility of extinction. Just because the pool
of really knowledgeable C developers is shrinking and they are in fact
pretty close to becoming an endangered specie.  We all like free lunch
but somebody needs to heat it even if the food is free ;-)


There are so many issues here, let me comment on them separately.

Pure C.  Yes, I appreciate your insight.  Even slightly "impure" C, like C
with gcc extensions, could be helpful.  Linux kernel is an example.  It's
well structured thanks to macros, initializers of structures, constructors
and explicit exports.
Least common denominator prevails in application. Kernel is quite another story and different animal altogether. And the only realistic way to implement this you idea of "better-C" (which is right by itself) is to separate mc into a core and peripheral parts. Which again returns us to a scripting language issue and/or plug-in issue. 


But in fact, the code is screaming for a language with OOP support.  A lot
of incorrect interdependencies would have been avoided in the compiler was
enforcing some rules.  It's especially important for collaborative
projects.
C++ would probably harm as much as it might help. This is like in a quote from 12 chairs 
"all the money were eaten by the 'apparatus' (bureaucracy)"
(Note for non-Russian readers: "12 chairs" is a famous Russian satirical novel about building socialism in the USSR; not connected in any way with open source/free software movement. The quote belongs to the leading character of the novel Ostap Bender, who wants to became millionaire by expropriating money from other millionairies, who in his opinion got thier money in a wrong, criminal way; 
again no connection to open source) .


But on the other hand we have Gtk, which is pure C and sustainable.
Maybe it's because Gtk developers avoided feature bloat from the beginning
and cared about code quality.  But it's a library - you are guaranteed to
have many programmers using it.  GNU Midnight Commander is for end users,
even if they happen to be e.g. Perl programmers.  Besides, Gtk is used in
GUI.

I know programmers that only work in GUI.  There was the punchcard
generation, the command line generation, the text UI generation (TUI), and
now we have the GUI generation of programmers.  GNU Midnight Commander
serves only the text UI generation of users, and so it's not appealing to
the young users and programmers.  It's a niche project.
IMHO not true. Good young programmers know and use command line, sometimes even better then the "old guard". For example the productivity of using mc by skilled admin is such that people with pure GUI skills cannot compete. And as sysadmins is a mass speciality, in no way mc is a niche project and it's *very* appeling to young sysadmins and programmers. Some of my students became expert users of mc or FAR in year or so.
The second consideration is that it might represent a new generation of command line interface for bash (or other unix shell) and one can think about mc as a bash extention. Bash is not going away any time soon no matter what interface you prefer. That's why I consider your idea of convering mc.ext and user.menu into a libraries of bash scripts to be a very good idea. 


There are 3 large free office suites in development, so the programmers
resources are not scarce.  Those who started with Microsoft Word are young
and have enough time.  Those who started with Norton Commander have
serious jobs and in many cases families.  We are endangered species - the
text UI programmers with enough time for free software that one won't put
on resume like Linux kernel, Apache or cryptography.  But let's not
generalize.

You might be overestimating Open Office stuff. It's all Sun's money.
I think that open source has more chances on the command line level were things are simpler and programs can be smaller. IMHO the best chances to compete on GUI level is to adopt a scripting language with the TK or QT or similar library, and that's not an easy game from the point of view of speed. But for problems with low-level compiled language approach in GUI applications 
just look at Gnome.
All this "attempt to catch and then leave behind Microsoft" is IMHO partially a temporary aberration of the overenthusiastic crowd (or if you are in IPO game, a new "make money fast" game) that volunteer developers might pay with their health, family life, etc. As the complexity grows, the advantage of proprietary development grows too and IMHO Microsoft or IBM or Sun or other big software company will always have an upper hand in Office-style applications just because they can mobilize far bigger resources and to impose stricter discipline, that is absolutely necessary in such a tremendous task. I am convinced that simplicity is the only advantage of open source and thus the command line applications deserve a prominent place among open source tools. This advantage will never go away. 



That's why making this decision and taking some steps now, when the mc
development is clearly revitalized because of your efforts is, in my
opinion, so important.

OK, I'm afraid I cannot spend any more time on the discussion unless you show me something more specific.

Agreed.  Thank you for the discussing those issues with me.  Good luck !

--
Regards, 
Dr. Nikolai Bezroukov
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]