|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
| Bulletin | 1998 | 1999 | 2000 | 2001 | 2002 | 2003 | 2004 | 2005 | 2006 | 2007 |
| 2008 | 2009 | 2010 | 2011 | 2012 | 2013 | 2014 | 2015 | 2016 | 2017 | 2018 |
| Jan | Feb | Mar | Apr | May | Jun | Jul | Sept | Oct | Nov | Dec |
Version 1.5, November, 2012
Copyright 2012, Dr. Nikolai Bezroukov. This is a copyrighted unpublished work. All rights reserved.
|
|
The Orthodox File Managers (OFMs) that are also known as "Commanders" are remote descendants of Norton Commander (NC) written by John Socha and first released in 1986 for MS DOS. Despite Spartan interface (or, more correctly, due to it) Orthodox file managers provide an extremely rich functionality, unsurpassed by any other type of file managers. Including a unique way of shell and file manager integration via user menu with a set of macrovariables as well as shell terminal window, making them natural sysadmin IDE. Due to unique blend of power, flexibility and portability they became the tool of choice for system administrators, especially in xUSSR region, Eastern Europe, Germany and Scandinavian countries. Those regions were place of birth of the most impressive OFM implementations such as Far, Total Commander, deco, Volkov Commander, Dos Navigator, Altap Salamander and many others.
There are three fundamental properties of Orthodox file managers:
- Conservative (as in "far from being fancy"), very stable (25 years without major changes), very flexible interface with two symmetrical windows (called panels, with trademark white on blue letters, by default) that hides behind Spartan interface very rich functionality. It really teaches us that "less is more"
- One "terminal style" window that initially is minimized to a single line at the bottom of panels, but can be expanded to full screen, half-screen or any number of lines. The user can work in this window like with regular console screen.
- Additional way of integration with the underling OS shell via so called User menu and extension menu using the same set of macro variables that are available for command line, which is also used in the built-in editor, providing an opportunity to pipe result of the shell script execution to the place after the cursor or pipe a selected block as input of some script.
At the same time they represent just one instance of a larger category that can be called Orthodox interface. This category includes editors such as vi and THE (orthodox editors), windows multiplexers (GNU screen), windows managers (such as ratpoison) and probably some other that I just don't yet discovered. I am still working on refining this notion but as a set of raw ideas it includes:
- Distinct command set layer with commands that can be entered from the command line and reflected in GUI interface. In this sense vi is a reference implementation and OFM inspired by vi have some interesting, distinct from traditional line of OFM ideas implemented. See ranger and vifm.
- Tiled, nonoverlapping windows with minimum decorations
- Stress on availability of all commands via keyboard, not only via mouse clicks, althouth mouse can be productively used and is used in such interface.
- Ability to redirect output of commands executed in one window to other windows and processes.
- Usage of GUI elements to generate commands on command line (macrovariables and such commands as Ctrl-Enter, Ctrl-[ and Ctrl-] in OFM. )
- Accent of extensibility and programmability (with shell and/or scripting languages) instead of eye candy.
The Orthodox File Managers (OFMs) also known as "Commanders" are remote descendants of Norton Commander (NC) written by John Socha. The latter was first released in 1986 for MS DOS. Orthodox file managers provide a unique way of shell and file manager integration making them natural sysadmin IDE. Due to power, flexibility and portability they became the tool of choice for system administrators, especially in xUSSR region, Eastern Europe, Germany and Scandinavian countries. Those regions were place of birth of the most impressive OFM implementations such as Far, Total Commander, deco, Volkov Commander, Dos Navigator, Altap Salamander and many others.
The word "Orthodox" comes from Greek orthos ("right", "true", "straight") + doxa ("opinion" or "belief", related to dokein, "to think"). And OFMs are really in my humble opinion "true way of thinking" about complex file management operations. As a former editor of Softpanorama bulletin, a ezine which was published on floppies from 1989 till 2006, I was amazed by tremendous enhancement of my productivity they provided. It goes without saying that publishing of it would be impossible, if I did not learn how to use Norton Commander 2.0 in early 1989 (at the end of the year I switched to NC 3.0 and in 1992 to Volkov Commander). Provided by user menu simple extensibility proved for me to be an indispensable tool. Later FAR added the concert of plug-ins which make extensibility of this type of managers even more impressive. Even without writing your own plug-in you can configure a set that provides more critical for you functions than standard distribution. For example, for me such an indispensable thing proved to be WinSCP plugin.
While many sysadmin/webmaster tasks can be accomplished in many different ways, I think high level of mastery of OFM provides one of the best results. It also organize thinking about complex file operation is a chunks of operations that are available in OFM. That's why I called by ebook about those file managers The Orthodox File Manager(OFM) Paradigm.
OFMs provide a unique integration of three components critical for sysadmin IDE -- file manager, file viewer and file editor. Advanced OFMs has extensibility via two major mechanisms:
The most promising from the point of view of extensibility are OFMs written in Python or other scripting language, but there are very few such OFMs. See Scripting Language based OFMs
I introduced the term "orthodox file managers" in 1996 (see OFM Bulletin 1998 ) because this type of file managers has an interplay of three features:
They have found the second home and became tremendously popular (dominant in DOS days) in the USSR and Eastern European countries with the population at least formally belonging to Eastern Orthodox Church with its unique polyphonic musical tradition (Basso profondo from Russia, Do not reject me in the time of old age, Orthodox music and Basso Profundo Beautiful Russia in Winter, Let my prayer come true, Gabriel Appeared, Lord, now lettest thou thy servant depart in peace, Glandsome Light, Great Litany). This is some at least superficial similarity in how they with just human voice create magnificent masterpieces to the way keyboard is also pushed to the extreme in OFMs (althouth mouse can and should be used)
They emphasize computer minimalism philosophy. In a way orthodox file managers represent a different way of thinking (paradigm) about file operations, a remnant of DOS culture that emphasized the value of keyboard, simple text interface and simplicity in general. They also have an implicit appeal as simple, minimal tools as opposite to baroque, complex tool typical for modern Windows and Linux environments. With its adherence to command line and character-based interface they represent a trend that is often called computing minimalism. Modern "click-drag-click" GUI interface designers view such approach to interface as antiquated and worthless, but ability to mix and match keyboard with mouse operations carries a rich and valuable cultural tradition from glorious, but long forgotten DOS days of personal computers. As old PC users remember the original versions of IBM PCs did not have mouse, it was introduced only with IBM PS/2 series in 1987. Actually key assignments for OFMs are difficult to understand without knowing about 83 keys XT keyboard with 10 F-keys to the left in two rows F1-F2, F3-F4 (View/Edit in OFM), F5-F6(Copy/Move in OFM), F7-F8(Make directory/Delete in OFM), and F9-F10), keyboards which disappeared around 1994-1996. So from 1987 DOS users tried to combine the best features of both interfaces. Symmetrical two panels with hidden command window interface also speaks volumes about the value of simplicity and because such software can be replicated independently and you do not have a vendor lock. As such, simple flexible interfaces like used ion OFMs can survive for many decades, producing enormous benefits for the long-term users. Ability to use the same interface for 20 years or more produces level of motor skills when operations became almost subconscious and user can think about file management problems is a larger "chunks" of OFM operations like (make_directory-select files-move chunk, or compare_directories-move_newer chunk). This way of thinking gradually evolves into the second nature of the users and a way of thinking about all file operations (paradigm).
Note: After demise of XP some keyboard manufactures tried to incorporate XT keyboard F-keys into AT keyboard layout but none was particular successful (the most long lasting and popular was probably Gateway AnyKey). Some programmable keyboards contain XT-style two columns of programmable keys on the left side of keyboard (for example, Logitech G110, $55). Those keys can be programmed into "classic" OFM configuration (see Programmable Keyboards) making OFM usage more enjoyable and operations slightly faster.
While not perfect, the term Orthodox File Managers is much more precise and definitive then alternatives. There are actually three main alternatives:
You can read more about pro-and-contra those alternative terms in Wikipedia discussion, which among other thing contains some very emotional philippics against the term "orthodox file manager" and judge the level of participants on the either side of the debate yourselves. The funniest argument, that probably deserve to be published by Onion were along the lines: Waah, if those are orthodox then all others are unorthodox and that means infidel. So they called my favorite file manager infidel ! Bastards. Damn the author and the term ;-). With one particularly nasty Wikipedia user was going as far as claiming that the term was inserted by me at all pages with them that can be found on the WEB...
Of course any term has drawback, but this one still the term reflects my convictions that interface provided by OFMs reflects "less in more" approach and its Spartan interface somewhat reflect ideas asceticism propagated (but not always followed) by Orthodox Priests. If also reflects judging of this interface as a "right, but now viewed as archaic" pretty well and I am sticking to it :-).
Orthodox file managers is also appropriate name in a sense that they stress the value of ability of working with command line using the command set instead of click & drag type of interface that is typical for modern GUI programs. OFMs also managed to preserve "look and feel" of the original program which is now more then 25 years old (this is amazing case of interface longevity, if you think about it). This unique, recognizable two symmetrical panel (often with white letters on blue background) interface is a hallmark of the genre with its ability to shrink and manipulate visibility of left and right panel windows as well as expand command window (preferably gradually but at least to half-screen and full-screen) despite the fact that this interface is quite different from the established by Apple and Microsoft standard for those programs. In this sense we can call Microsoft type of GUI interface with its excessive attention to GUI details "a catholic interface" ;-).
Members of this family of file managers that are represented by such popular file managers as FAR, FC, Total Commander and WinSCP on Windows as well as MC (Midnight Commander) in Unix. Less popular names include probably a dozens of implementations (Demos Commander, Krusader , EmelFM2, GNU Commander, GNOME Commander in Linux, FreeCommander, Altap Salamander, Necromancer's DOS Navigator on Windows, see CategoryOrthodox file managers in Wikipedia). All of them use simple yet very powerful paradigm of three windows: two symmetrical panels and command window (shell terminal window) hidden behind them with only the last line of this window (command line) visible. There are three fundamental properties of Orthodox file managers:
Conservative (as in "far from being fancy"), very stable (25 years without major changes), very flexible interface with two symmetrical windows (called panels, with default trademark white on blue letters). It teaches us that less is more. By default panels contain listings of files in two (not necessary different -- they can provide two different views of the same directory, for example, sorted by time and by name) directories. One panel is "active" (it has cursor in it), the other is "passive". Tab changes active panel to passive and makes other panel active. All manipulations are performed from active panel with possible target of passive panel directory (in case of copy operations). In advanced OFM along with vertical split panels can be displayed with horizontally which is useful for Unix as permits displaying both attributes of the files and its ownership. Key variables that describe status of those two panels (often called macrovariables), should be exported to the environment and available as a keyboard shortcuts (for example Ctrl-Enter, Ctrl-[ and Ctrl-] in FAR) for inserting into command line. In a sense OFM is for users who learned this interface, found it highly usable and don't care about with "innovation" like drag and drop and eye candy unless they really increase productivity. Remember that an important part of KISS principle is famous "If it aren't broke, don't fix it"... Every time you hear the screams of millions of users crying because of another "innovation" from MS or Apple like happened in change of interface from Office 2003 to Office 2007, remember that simple reliable tools like OFM give people what they want and what they already learned and get used to, not an "Even-Newer-Paradigm" each three to five years. The classic "orthodox" lesson that OFM teach us that "If you've got time on your hands, and are looking for something to do, please spend it on improving functionality and flexibility of the application, not the visual candy. " The UI does not need anything "new", nor do the users want anything new or unfamiliar. It's more than enough hassle to keep up with "innovations" in the OS space... please don't make us learn new tricks for the file managers, which are good enough... As we saw in some popular GUI programs the lion share of "innovations" in new releases is confined to endless variations of GUI interface. Not so much adding functionality, as adding confusion. And the pace is such that sometimes users just get used to new interface and, voila it got updated. The impression is that aging brass imitates "creativity" by meeting some stupid formal parameters in yet another spreadsheet staffed in the endless maze of bureaucratic perversions. Imitates without a soul. And after brass creates "grand plan for innovation" a lower level boss pushes plan for interface "innovations" to worker bees. Who knowing the situation all too well and understand that "resistance is futile" say, "OK, boss. As you wish !" Let's shuffle the menu from vertical to horizontal and change location and shape of the buttons. Done deal! Everybody is now happy. And in order to meet the deadline, let's do not fix existing bugs. Because real quality control is gone as the key criteria of their work became meeting the release date too. So both management, software development and quality control are now just imitations of "real thing". The release date hangs over their heads like Damocles sword. And only after the release, the real attempts to fix bugs begin. Until a new "innovation cycle" starts....
You got the idea of such an "innovation process". And described perversion and waste of talent and resources for meaningless changes of eye candy under the name of innovation happens with GUI based applications way too often, so often that the description above does not looks so much as a caricature. I think in this respect US software developers finally reached the level on which industrial projects were completed in the USSR just before its dissolution! Which suggests not only widespread rot at the top, but something deeper and more menacing...
With OFM the situation is different. Interface is primitive and its structure was fixed 26 years
ago. Users learned it long ago and expect it to stay the same; they do not take "innovations" very
friendly to say the least. Moreover, there is one stupid guy named Bezroukov who put an effort to
document it and published widely ignored but still available standard. And now if somebody deviates
from it too much, he/she might be shamed by some too curious user who read OFM1999 or old
hand who used FAR or Norton Commander 3.0, who expected that that this feature should be done
not this way, but that way ;-). Which creates implicit pressure to keep the interface compatible
with good old Norton Commander and channel your creative energy into something more valuable then
deciding which key combination should be designated for "copy" and which for "move" :-). Or how
many panels your file manager should have. Or how shell terminal window should behave.
An additional twist of this capability is the ability to paste macrovariables (current file, path to left and right panel, list of selected files, etc) not only via putting the names of macrovariables in your input string, but also by using keyboard shortcuts such as Ctrl-F (current file), Ctrl-[ (path to left panel), Ctrl-] (path to right panel). This feature introduced in Volkov Commander simplifies many operations in comparison with both die hard command line Unix users on one hand and CDD (click-drag-drop) addicted type of Windows users on the other. I always admired the persistence with which Windows users can repeat the same operation using strictly mouse "drag and drop" four dozen times, for example moving 50 files to 10 different directories one by one, when in OFM it takes just slightly more then a dozen of keystrokes :-). As well as Unix command line users who type command ls probably several hundred times a day each day (the ability to suppress ls command in bash history exists not without a reason) and still feel great and don't even suspect that there is a better way ;-)
This "visual shell" memo is one of the most powerful ideas within OFM paradigm, but unfortunately "the religion became corrupted" as it often happens. Only FAR and Midnight commander (starting from version 4.8) implement this idea correctly, but with different strong points of the implementation:
I would like to stress it again that such a popular Windows OFM implementation as Total Commander
is completely defective in this respect: the third command line allow only a single command to be
executed and output is not visible other that (if this is command affects file in the panel) with
the feedback via changes in listed in panels files.
= t r
+ ! t
y Gzip or unzip current file
unset DECOMP
case %f in
*.gz) DECOMP=-d;;
*.[zZ]) DECOMP=-d;;
esac
gzip $DECOMP -v %f
+ t t
Y Gzip or gunzip tagged files
for i in %t
do
unset DECOMP
case "$i" in
*.gz) DECOMP=-d;;
*.[zZ]) DECOMP=-d;;
esac
gzip $DECOMP -v "$i"
done
+ f \.tar.gz$ | f \.tgz$ | f \.tpz$ | f \.tar.Z$ | f \.tar.z$ | f \.tar.bz2$ | f \.tar.F$ & t r & ! t t
z Extract compressed tar file to subdirectory
unset D
set gzip -cd
case %f in
*.tar.gz) D="`basename %f .tar.gz`";;
*.tgz) D="`basename %f .tgz`";;
*.tpz) D="`basename %f .tpz`";;
*.tar.Z) D="`basename %f .tar.Z`";;
*.tar.z) D="`basename %f .tar.z`";;
*.tar.bz2) D="`basename %f .tar.bz2`"; set bunzip2 -c ;;
*.tar.F) D="`basename %f .tar.F`"; set freeze -dc;
esac
mkdir "$D"; cd "$D" && ("$1" "$2" ../%f | tar xvf -)
For Linux/Unix users the simplest way to understand Orthodox file manager interface is to view it as a specialized implementation of GNU screen that contains three predefined windows: two symmetrical panels side by site at the top and a regular command line window (by default minimized to a single line) at the bottom The unique feature is that operation in one window (command line window) cause changes in other two windows (panels). This feature actually can be implemented in screen by running two programs in panels that read two files in, say /tmp directory with location of current (active -- always shows the current directory) and passive (say previous directory) and then update content of their window.
Paradoxically leading Windows implementation (FAR) has richer interface with shell then leading Unix version -- Midnight Commander (partially because of design flaws in Midnight commander where shell interface is implemented as a hack). There are also many GUI version of orthodox file managers that implement mainly file handling capabilities but not "visual shell" capabilities. The most prominent example is Total commander which in 2007 became fifteen years old implementation.
There are numerous advantages of modern Orthodox File Managers, which refines the functionality of the original Norton Commander for DOS and incorporated into the same interface more then 20 years of development by many talented programmers including John Socha, Vsevolod Volkov, Eugene Roshal (of RAR fame) and Christian Ghisler (Total Commander). Three main advantages are:
|
Three main advantages of OFM are (1) close integration with the shell, (2) portability and (3) the availability of public standard |
All OFMs have a Spartan interface with the main window which is divided into three sub-windows. Two of them are called "panels" that are identical in structure (but can have different sizes and/or be hidden), and are usually positioned side by side at the top of the screen (in Unix positioning one on top of the other is more common as there are additional attributes to display with files). The third screen-wide window contains an instance of the shell and usually is minimized to one line but can be expanded either gradually, like by line (like in FAR) and/or is large increments (half screen and full screen as in classic Norton Commander implementation). You should view this command line as a almost minimized (to a single line) command window. Or, if you wish, a separate telnet session to localhost. In case panels are hidden (with hotkey Ctrl-O ) command window should provide full functionality of the OS shell window including history of commands, command completion and other niceties.
In essence OFMs can be viewed as a special type of windows manager (similar to GNU screen) with functions of two upper windows (panels) largely fixed. But the important feature of OFMs is that panels are implicitly connected to the operations performed in command window in several ways:
Surprisingly, this Spartan interface proved to be long lasting feature of OFMs. There were attempts to create the OFM manager with four panels. There were attempts to use tree view as the right panel (similar to Windows Explorer) and most OFM has the ability to replace left panel with tree view. But I personally and many advanced users whom I know never learned to use this productively and prefer classic symmetrical panel view with two directories. Strangely enough this two symmetrical panel with two directories remain the most productive for a very wide spectrum of real life file operations that are used by sysadmins and advanced users. When I need tree view for quick navigation I usually use separate view available vie Alt-F10 (find folder). Probably there are some structures in brain that provide higher productivity with the symmetrical two panels interface vs. various often more sophisticated asymmetrical variants. Moreover after you achieve proficiency with it, it's rather difficult to switch to any other: all of them look inferior even if in reality they are more expressive for some operations (like the Windows File Explorer asymmetric interface with tree on the left side or XTree interface, which provides very good capabilities of coping/moving files from left panel to the arbitrary place in the directory tree). There is some kind of implicit "lock in": after several years of usage you start thinking about file movements and directories restructurings in terms of OFM operations. That also provide you with some hidden "language" using which you can perform pretty sophisticated directories transformations, the skill that often amazed those who never using OFM manager and observe operations of an advanced user.
Another, already mentioned, advantage of OFM is that this is the only type of file manager that is standardized and the skills are transferable from command like to GUI and back as well as from one platform to another (for example Windows to Unix -- this is an excellent way to dampen shock of the Unix command line for Windows users who want also use or even migrate to Unix).
| Another advantage of OFM is that this is the only type of file manager that is standardized and the skills are transferable from command like to GUI and back as well as from one platform to another (for example Windows to Unix -- this is an excellent way to dampen shock of the Unix command line for Windows users who want also use or even migrate to Unix) |
OFMs are not for dummies. You will be more productive if you know the shell of the OS you are using. In this case you can use OFM as a navigational helper and a simple generator of complex command as you can easily insert into command line such elements of two panels as the current file, the current directory, directory of inactive panel and so on. That's why they are extremely popular among administrators, especially in Eastern Europe and xUSSR area.
The author argues that this simple classic interface offers the most efficient way to perform complex file operations, and both users and software developers deserve some help in the form of the standard and some kind of commentary about "the state of the art" of this type of file managers. That's why I spend considerable time writing my online book The Orthodox File Manager (OFM) Paradigm that introduced two level of standards (OFM1999 - minimal OFM requirements and Dr Nikolai Bezroukov. The Orthodox File Manager (OFM) Paradigm. Ch. 9 The OFM2004 provide both commentary and overview of major implementations. This is a volunteer effort and some parts are outdated. Still this is the only e-book on the subject and as such it can help system administrators more consciously choose the implementation they need and polish the methods of work with OFM.
In this ebook I tried to distill several possible reasons for this surprisingly high productivity of OFM users, the productivity that despite of the age of the interface (more then 25 years) and its Spartan character remains unmatched. Please read at least Ch.1 of the OFM book, the chapter that introduces the concept.
But even if you do not want to read it, selects and enjoy any OFM you like! I am using this class of filemanagers since 1987 (NC 2.0) and still learn new things each year, things that help to increase my productivity. Despite interface simplicity latest OFMs are very powerful and flexible programs, that have rather steep learning curve and you will be better off learning incrementally, starting with simple file operations and gradually moving toward full power that bring customarization and availability of user many, extensions menu and several other features of OFM.
I also have found OFMs to be indispensable productivity tool for webmasters and despite my interest and professional exposure to other Windows and Unix filemanagers I am still convinced that in the hands of professional, productivity-wise, OFMs have a huge edge. BTW I never managed to fully switched to GUI based OFMs, and still use mc in Unix and FAR in Windows environments although recently I spent considerable time using Total Commander. That's because command line OFMs should be viewed not only as filemanagers but as a new ingenious graphical interface to shell, interface that makes standard Unix-style typing command on the terminal irrevocably backward. Professional Unix administrator fully versed in OFM usually outperform Unix administrator limited to "pure" commend line by a factor of two in not more. It's actually a pity to see how this poor folk spends valuable time typing innumerous ls commands ;-)
And that brings us to an important point. While invented as a file manager in reality (and especially in Unix environment) OFM should be viewed as new generation of shell interface (visual shell) and as such they should be closely integrated with shell. Unfortunately this point was missed by most Unix developers and capabilities of typical Unix implementation in this respect are rather primitive. In a way you should think about Unix OFM implementation as a fork of screen with specially predefined top windows split vertically (I know screen cannot split windows vertically but let's assume that this is just an implementation limitation). This ides of "OFM as a visual shell for Unix" is the main point that I advocate in my ebook especially in chapter 4 devoted to Unix OFMs. That's why despite their origin in Windows OFMs proved to be extremely natural to Linux/Unix environment. IMHO a Linux/Unix sysadmin with good OFM skills can be probably twice more productive then any super-skilled UNIX guru that use just plain vanilla command line ;-) Actually good knowledge of OFMs is a trademark of best Unix administrators from Eastern Europe.
But while Europe (especially xUSSR region, Eastern Europe and Germany) became the new home of Captain Norton, the initial versions of NC were written by a talented American programmer John Socha. Like with any brilliant idea it did not take long to implement and develop it to a mature condition: all the major work concentrates in just two years 1985-1987. At this time John Socha was the first director of research and development for now defunct small software company: Peter Norton Computing. Peter Norton who wrote the initial version of Norton Utilities, but AFAIK was not involved in writing Norton Commander was one of the pioneer entrepreneurs in PC software development; now he is known mainly due to his role as a photo model on the boxes of Norton Utilities and other Symantec products belonging to a "Norton line" ;-).
The first version of Norton Commander was released in 1986 and it instantly became the dominant file manager for DOS. In 1987-1991 more then a million copies were sold. In Eastern Europe Norton commander became a synonym of DOS interface and many users did not even understand that this is an add-on program.
In 1990 Peter Norton sold his company to Symantec to pursue his interests outside programming. John Socha left the company after the merger and created his own company, which was later acquired by Asymetrix. He continued cooperation with the Norton division of Symantec and wrote for them several good computer books including classic introductory assembler textbook Peter Norton's Assembly Language Book for the IBM PC .
Symantec first displayed some lukewarm support for this cash cow, but with the introduction of Windows killed it (as well as some other brilliant DOS product it acquired -- XtreeGold). Later they understood the mistake they made and in 1997 there was a reincarnation attempt: Norton Commander for Windows 1.0 was reintroduced in the Symantec product line. But talent was already gone and it was "too little, too late" and after version 2.0 it died again (still as of January 2003 you can buy Norton Commander for Windows 2.0 in Europe, especially in Eastern Europe). Not that I advice you to do that :-)
I would repeat it again that OFM can increase the productivity of sysadmins several times, especially for performing complex operation on Unix-style hierarchical file systems. For some unknown reasons no other file manager can compete with OFM in performing complex copying or moving of files on the directory tree. I several time managed to win a bottle of wine competing against Unix administrators who used only command line, and believe me as typists they were much better them me. The only other tools that I know, that have a similar semi-religious status with its adherents (but in a different area) are Xedit and vi editor (see my Orthodox Editors for details). That's why I consider OFMs to be a must (along with orthodox editors) for any advanced user, sysadmin or webmaster (both Windows and Unix). As I wrote in my book:
One of the most distinctive advantages of OFMs is that the productivity of the power users is really amazing, especially in the command-line environment. To the uninitiated it often looks like a magic -- the speed with which an advanced user can perform complex file operations. It looks much like playing piano. Advanced user probably have "motor maps" for typical operations that are executed on subconscious level much like a good piano player can instantly recognized specific accords in music notation.
OFMs can be found on all major and minor operating systems including all flavors of UNIX, OS/2, all existing versions of DOS, Windows 3.1, 9x, NT and even PalmOS and Personal PC. Actually OFMs probably represent the most portable family of filemanagers in existence (Xtree is also a very good filemanager available on several platforms, but not that many; Windows Explorer is an average filemanager that was also widely ported to almost any OS in existence because of the influence of Microsoft Windows).
|
The first and the main advantage of OFMs is simplicity and stability. Attempts to radically enhance this simple, Spartan interface largely failed. Also after the first three years of using OFM most file operations can be performed so fast that usefulness of further improvements might be marginal ;-) |
Actually forgetting useful functionality is a problem as one fundamental shortcoming of relying of keyboard shortcuts is that there way too many of them. This is a problem that require paying special attention to help facilities. OFM always have had a bottom line (or bottom menu as item are clickable by the mouse) that describes function of each of F1-F12 keys and if Ctrl or Alt is pressed and hold this dynamic "mini cheat sheet" changes accordingly. This feature needs to be implemented uniformly and extended to all dialogs.
The right way to look on OFMs is not as on file managers, but as an IDE for sysadmin. That means the quality of shell terminal window provided is of paramount importance for OFMs and the role of user menu is central. Unfortunately most current implementation are very weak in this area and that might be the reason OFMs did not got the popularity among sysadmins they deserve. Some like Total Commander treat shell terminal window functionality like red hair step child despite availability and great productivity enhancing potential of PowerShell on Windows. In Unix OFMs the low quality of shell terminal window implementation (that should be equal to GNU Screen split window implementation) in my view greatly influenced the fact that particular OFM implementation have difficulties to attract critical mass of sysadmins as is visible from scarcity of manpower and development resources in most implementations.
| Unfortunately most current implementation are very weak in this area and that might be the reason OFMs did not got the popularity among sysadmins they deserve. Some like Total Commander treat shell terminal window functionality like red hair step child despite availability and great productivity enhancing potential of PowerShell on Windows. On Unix quality of shell terminal window implementation (that should be equal to GNU Screen split window implementation) in my view greatly influence whether particular OFM implementation can attract critical mass of users, or not. |
Simplifying the reference implementation for OFM terminal window implementation should serve GNU screen. Anything less than make them much less attractive for Unix sysadmins. That also means that internal viewer and built-in editor are very important, "first class citizens" parts of OFMs and implementation of them should get attention they deserve. The quality of their integration with panel-based file management subsystem by-and-large-determine the quality of this IDE. In this respect pioneered by Midnight Commander editor user menu is an important step forward and should be implemented in other OFMs, especially Unix/Linux OFMs. I would say that without this feature as well as dynamic user menu (also pioneered by Midnight Commander) OFM looks like second rate tools. Unfortunately Midnight Commander is not that perfect in shell terminal window implementation although there is a progress from version 4.6 to version 4.8 and implementation in version 4.8 while far from perfect looks more sysadmin friendly.
They can also serve the role of IDE for webmasters of the sites that use plain-vanilla HTML (as opposed to database driven sites). With ftp and SSH virtual filesystems available for such site an OFM is a quintessential Webmaster tool. It definitely plays this role for Softpanorama. This unique role that OFMs can play as a webmaster IDE fuels my interest in the field after more then two decades of usage.
Along with integration of file managers, internal viewer and editor OFM also integrate functionality of a dozen command line utilities including but not limited to:
| "I have found Jesus. He came to me in the form of muCommander." -- A happy user |
OFM are tools written by programmers for programmers, sysadmins and power users. The elite of PC users. We can distinguish between two levels of OFM skills:
Although basic skills can be acquired in less then a week and gradually can be enhanced to "power user" level, this is not true for master level skills. First of all getting to this level require knowledge of shell (or other scripting language). Also you need to spend some time studying default "user menu" supplied with mc (for a given user many entries are redundant and he/she can start with deleting them) and, if possible, experience of your colleagues in this area. But return of investment is tremendous -- you really will be working in more productive environment, environment productivity of which can't be matched with any number of "off-the-shelf" tools.
Fundamental problem with any interface oriented on extensive keyboard usage is that the set of commands is large. That means that some important commands and methods are easily forgotten without practice (this situation is typical for any tool with extensive command set, such as vim). Based on my more then 20 years experience with OFM (I started using them in 1989) I would recommend the following methods of enhancing your skills:
Time spend on those activities will be repaid many times. Learning OFM is one of the best investment in time you can make. Good luck !
There is an old saying that "Really innovative ideas are never stolen." It is very true because "innovative" means ideas or products that go against established practice/fashion. Just read Talk: Orthodox file manager - Wikipedia, the free encyclopedia to get some insight into related mentality (Wikipedia actually removed the page "Orthodox file managers").
Why are they called Orthodox? --Error 23:55, 12 March 2006 (UTC)
- Exactly. Because some 'tard' here is totally dependent on the MU way of thinking, never progressed beyond, and is not trying to convert the world. Of course there is nothing orthodox about them. Try 'crippled' - a much more appropriate term. I suspect the MU Commander people are behind it, shilling their own product. It's not ethical for Wiki. —Preceding unsigned comment added by 86.213.91.157 (talk • contribs)
- The existence of that page just goes to show what a joke Wikipedia is.--88.149.233.68 09:17, 21 May 2007 (UTC)
Who dreamed up this definition? A Google search for "Orthodox file manager" yelds a measly 305 results. Moreover, there is NO MENTION of this thing in the Jargon file. The term "orthodox" is NEVER mentioned in GNU Midnight Commander 's home page. This entry is either a joke or somebody's personal "invention" and should be removed. --88.149.168.128 10:35, 28 November 2006 (UTC)
- I agree. --24.21.72.22 16:16, 26 March 2007 (UTC)
- Third the motion. So we should now seen this page removed, right? —The preceding unsigned comment was added by 86.213.91.157 (talk) 16:13, 5 May 2007 (UTC).
- I think everyone knows your opinion. You're not getting very far by writing (unsigned) criticism all over this page. We had the AFD following the comments from 88.149.168.128. Since then, there seems to have been two complaints about the name of this article & both came from anonymous IPs. I think that deletion of this article is unlikely, but we do have a process for that if it is something you believe so strongly in. A move might be more reasonable, since the article (while not well written) is hardly "nonsense" & does describe something worth describing. I don't think anyone would argue that "orthodox file manager" isn't a neologism. However, it is a useful one. It has been adopted on the interwikis, by DMOZ, and by others. --Karnesky 23:17, 5 May 2007 (UTC)
Inappropriate
Unless the term is a de facto standard - which it is not - then the use of 'orthodox' to describe something as retarded as a Norton file manager is tantamount to shilling and advertising. I strongly object to this. This page was evidently started over two years ago from an IP in China. I call on Wiki to show more discretion and as others I call on Wiki to IMMEDIATELY remove this STUPID PAGE. If you don't - we shall. —Preceding unsigned comment added by 86.213.91.157 (talk • contribs)
Usually reception on innovative ideas is deeply hostile and there are great difficulties even to convince potential users to try them or venture capitalists to finance the project. Inertia on one hand and (opposites meet ;-) fashion on the other rule IT (I think IT is more subjected to fashion whims then woman clothing with a new fad each second year playing role of the length of woman hemline and style of shoes; right now this is cloud computing ;-). As Charles Simonyi who oversaw the development of Excel and MS Word at Microsoft once noted:
“I have always worried that when these claimed incredible new benefits come, we will lose all the old ones. Then it becomes a kind of trade-off situation where you have to see if you are better off. I like clear wins. I would bet on improving what we have while maintaining all the benefits and eliminating the drawbacks, rather than introducing new games where there are new benefits and new drawbacks.”
OFM contains a set of innovative ideas that were only recently analyzed and somewhat generalized despite 25 years history. The level of adoption of this set of ideas (and first of all the idea of graphical shell) is surprisingly low. It is very low even among Unix sysadmin, who theoretically should be early adopters of this technology due to obvious OFM style visual shell interface advantages over plain vanilla command line interface. One reason for this that proper implementation of shell terminal window capability in OFM is rare and this feature is mostly treated like red hair step child in current OFM implementations.
That's why I am still working on analyzing the set of key ideas behind OFMs and popularizing this set of ideas to wider audience. I think that while each new implementation is an important step in popularizing the OFM concepts, only those implementation which try fully integrate into the design the visual shell "paradigm" and the idea that OFMs is actually a specialized IDE for system administrators and power users (that that entails deep integration of build-in editor into OFM along the line of editor user menu pioneered by Midnight Commander) can scratch a deeper itch and have a lasting value.
Commercial success of OFMs was and is limited and there little chance that situation might change in the future, although some market openings probably exist for smartphone which are now much more powerful then old IBM PC (and has better screens). But in general this type of software does not feed developers well. Consider this as a special kind of academic research. Actually all open source development can be viewed this way.
History suggests that OFM as research field has difficulties in attracting and retaining the most talented developers. John Socha switched to other projects just four years after release of Norton Commander 1.0 (it was released in 1986 and in 2000, one year after the release of NC 3.0 (1999) he left the company). If we add, say, additional two years before the first release it would six years in total. Vladislav Volkov worked on his Volkov Commander even less, but manage to create a masterpiece of assembler programming which even now looks incredible achievement (he started it being a student and did not even have had his own PC at the time). Eugene Roshal was involved with his OFM (FAR) approximately five years or so. So far only Christian Gisler succeeded maintaining and enhancing his shareware Total Commander for almost two decades...
Still for young, ambitious developers that can be the field where they can prove their value as a programmers to the surprised world and learn quite a lot in the process. The latter part is probably the most important no matter what will be the final destiny of the product created and is one of the main attraction of open source in my opinion, making it somewhat similar to academic research, In old day there was a saying that in order for a computer science student to become a "real" programmer he need to write his own text editor. Now it can be reformulated that the student need to write file manager with integrated viewer and editor. This way you really learn OS API, and learn to work with substantial codebase and experience problems typical for such projects (including gradual decrease of enthusiasm ;-) on your own skin.
Moreover, even small OFM projects are visible and have early adopters, who not only stimulate you to overcome difficulties, but also provide some helpful advice, or at least encouragement. Look at two very interesting projects related to creating vi-style OFMs ( ranger and vifm ). Linking OFMs with vi concepts and vi culture proved to be a treasure trove of new ideas.
Just don't expect the project last forever and be ready to move to other things when you feel it became more of a burden then a education tool and writing new code for it, and especially maintaining the old one, lost most of the fun. But why not to try? There are visible gaps in functionality not filled by current implementations. For example as I already mentioned Unix implementation are surprisingly, dismally weak in implementing the idea of "visual shell" even on FAR level. If you manage to advance OFM in this direction you may attract enough following to continue the project when you'll leave it.
Actually for open source project it can happen that project died and then after several years the codebase is resonated with somebody own ideas and is picked up by a new talented developer who continued it for a while (that happened with FTE editor and GNU screen). That's the beauty of open source which again make it close to academic research, for example research in mathematics (one may argue that each program is a kind of specialized mathematical theory). So you do not need to start your project from scratch. You can pickup some promising but abandoned project and try to move it one step further. If you doing so it is important to resist natural temptation to wile out all traces of the original author. Again this is more like adademic research so please treat them as you want further generation of OFM developers to treat your modest contribution to the field. Among project that I think have value for developeing further are
'Bash Commander' is a version of the GNU Bourne Again shell extended with two-panel file manager. Visit http://groups.google.com/group/bashc for project news, FAQ, discussions etc.
Starting from version 3 Norton Commander has client-server capabilities (initially via serial null modem line). It was clear even in tiles of DOS that OFM actually consists of two parts:
- Client -- part that provides typical for OFM interface
- Server -- which consists of different programs performing actual manipulations with the filesystem
Now those capabilities are reimplemented using more modern technology. Client part can be implemented as a an extension of a browser and there is at least one such an implementation: firecommander in Google Projects
CGI interface looks pretty adequate for communication with various program that perform user actions. Moreover CGI-based interface between client and server parts of OFM make it almost infinitely portable: all you need to run it on a new platform is some basic web-server. Browser with JavaScript capabilities can be on other platform. And Web server implementations exist for any platform.
The second approach for the creating of truly portable OFM is to use Java for both parts. Java can be run inside the browser and that solve the client part of equation. And Java can run on any server and that solve that server part of equation.
In other words the principal idea here is to split OFM into two independent parts communicating well established and refined HTTP or HTTPS protocol.
This is also provides an interesting capability for X11 based remote solutions such as VNC for administering servers over dial-up lines or other low bandwidth communication lines. Also in this case keyboard emulation can be perfect and does not depend on idiosyncrasies of terminfo database on a particular platform -- the issue that hunts Unix OFMs.
Another reason is the crisis of several implementation, like Midnight Commander, which grow codebase to the extent that it became a complex mess of different libraries that are typical only for Linux. Which created problems with portability and actually discourage usage such OFM as mc as portability outside a couple of platforms (Linux and Solaris) is problematic.
In this case, even usage of traditional implementation of OFM using Java, such as muCommander along with VNC represents much more portable solution as long as JVM is already installed (which is true for all Unix flavors).
Of couse it is difficult to sustain project of pure enthusiam and time will come to leave it. Please provide documentation for the next generation of developers, as they might come. Even if you abandon your project, you efforts are not in wait as any such project is a great programming school, the school that you can't attent anywhere else for any money. And your experience in developing OFM has a great value in itself as for the reason I explained above, and so be it. Move on.
There are several ways to beat older OFM implementations in the same game, despite having much small resources:
A very promising way of simplifying codebase and lessening the amount of lines which are needed to achieve given set of OFM functions is to use a popular scripting language as implementation language and, simultaneously as a macro language. Or at least try to integrate scripting language like LUA into design from the very beginning.
To make your effort more productive it is of paramount importance to use the highest level of language that you know well (or plan to learn; writing an OFM is perfect programmer training exercise) and that is available on the platform of your choice. In case of scripting language you can get some decent functionality with a manageable for regular human size of codebase (say less then 5K of lines instead of more common for light-weight OFMs sizes like 10K lines; please note that mc is ~72K lines including comments if we count them via command cat `find ./src` | wc -l)
I think it makes great sense to restrict yourself to certain number of "kilolines" and try to do something useful within those restrictions. Projects like mc have pretty high barrier of entry, although they are modular and the largest part probably less then 45K lines with comments or ~25K without them.
If you will feel interest and see perspectives for the project, you can later abandon those restrictions or, better, start anew with a new level of understanding of the problem and the benefit of already acquired experience. Abandoning a couple of thousand lines is not that painful. Abandoning 10K lines written partially on weekends and stolen from family and friends is quite another story (despite the fact that a very good programmer can easily write 1K lines in a weekend). Another benefit of small codebase is that you do not need to kill yourself in endless debugging sessions.
In any case for those who are rotting in some large corporation and feel that they can leave their brains in the morning at home and still perform well this is one way to lessen the frustration from working in a large corporation and enjoying good salary, great benefits, access to the latest hardware and other pluses that large corporation provide. Talented system administrators with programming abilities can definitely try this path as for them the level of frustration after university is especially high and designing own or supporting an existing OFM project provide immediate value in their primary work environment. See Social Problem in Enterprise Unix Administration
Classic example of an application with a command line interface and a scripting language as a macrolanguage is XEDIT and its derivatives KEDIT and THE. The latter is an open source implementation. While it uses REXX which is not very popular those days, all key implementation ideas are applicable to any other scripting language. This way all options in panel configuration (sorting by specific attributes, filtering files of specific types, etc can be delegated to this macro language and all you need to implement is the filtering of file list via this user supplied macro. This alone saves provably 30% of codebase. Even larger savings can be achieved by implementing panels as specialized editor windows with read-only files in them. Editors and OFMs are actually two very similar projects and if you have editor of your liking with open source codebase available this is probably the best way to learning it in professional level. Tight integration of built-in editor and filemanager is a promising but never properly implemented idea that still wait for some breakthrough implementation.
As power users are generally very attached to their editors, you can try to implement some minimal implementation of OFM within the framework available for existing programmable editor. As OFMs are genetically oriented toward sysadmins, vi is a natural choice. Emacs is also a possibility but it way too complex to serve as a reference platform althouth usage of lisp or lisp-like language for extending OFM like Emacs worth investigating.
VIM is an obvious candidate and there are already several file managers implemented for it. Similarly some implementations already exist for Emacs (Sunrise Commander) which was implemented on top of Emacs in elisp. Even if your OFM project fail, after programming those extensions and learning API you will became a real specialist in this editor. And deep knowledge of editor is a tremendous asset in your professional career.
You can also leave the codebase alone and just to use ideas of editors in OFMs, for example the idea of distinct command set (: command in vi) and (piping from and into the editor which actually now is also present in some OFMs such as Midnight Commander). That can be in interesting and promising angle. For example vi has set of ideas that really can enrich OFM concepts. Look not only at attempts to create OFM inside vim in a macrolanguage, but also on attempts to emulate vim concepts in OFM. There are two very interesting projects related to creating vi-style OFMs ( ranger and vifm ). Linking OFMs with vi concepts and vi culture proved to be a treasure trove of new ideas.
OFM in reality represent something "in-between" tile windows manager (look at Ratpoison for inspiration) and multi-window terminal emulator like GNU screen on one hand and editors on another. The people who manage to find right architectural solution along those lines stand better change to compete with established players, because they can reuse pretty rich codebases. While convoluted ad-hoc solutions to those problems hamper "old-style" OFM implementations. Again Achilles part here is the implementation of command line window and the flexibility of integration of internal editor on the base of common macrolanguage and common library of primitives. Ad-hoc hacks in those areas inhibit further growth.
As we mentioned before, one way to look at OFMs as to view them as an IDE for system administrators, who have different needs and preferences them programmers.
But that does not exclude reusing some open-source framework created for, say, scripting language and written in scripting language. You can definitely reuse a part of implementation of windows system and the editor.
Who candidates that instantly come into mind are Parde or Eclipse. Please not that I hate Eclipse as it is a heavy weight framework, but for experimentation with new OFM features this is a perfect tool. Using IDE also will help you as a developer, as you will be more productive due to in depth knowledge of this IDE.
In case your chosen IDE is Eslipse, the knowledge you obtain in process of reuse it has great market value: an additional advantage of this approach is that cal simultaneously became an expert in Eclipse which has its own value on the marketplace. In any case IDE architecture already resolves one way or another all major problems that OFM designer faces and if particular IDE is still developed here again there can be a synergy between two project that can benefit both. Which is always good for open source projects that are typically starved for money and workforce and survive mainly on the enthusiasm of a single developer or a very small team of dedicated designers who really sacrifice their time to the project. Look at ht history of Midnight Commander for more information. In this sense donations to the project are very important and users of open source products would always remember that there is no free lunch. If they do not support the project it has significant chances of dying and they will be hanging in the cold, if they depend on it. And forced to pay the price of switching to another which can be really significant. In this sense shareware development (possibly with open code base -- the danger of stealing codebase of significant complexity in reality is close to zero) is more sustainable then open source development. Also FSF can (and should) act as a charity, not as a Stallman vanity promoting venture that stamps GNU label on the projects as a seal of approval of project license with zero real support. It should allocate some money for important projects like GNU Midnight Commander from member dues. Actually for orthodox file managers, orthodox monks should also provide some help ;-)
If existing file manager is flexible enough you can try to modify it to comply with the requirements of OFM1999 standard. Victor Zverovich tried the same for Nautilus, see his captain-nemo.
Of cause there are other opportunities about which I do not know. For example you can use screen and implement panels as shell windows using screen vertical split patch. There probably other interesting architectural opportunities for OFM about existence of which I do not even suspect.
I know everybody thinks that he can do better and that's mostly true. But this is not the all truth. Real truth is deeper. Remember that, as artists know all too well, "form liberates" and the less time you spend on designing your own interface and set of keyboard shortcuts, the more time you have on developing quality implementation of features that you value most. Under Spartan interface of OFM and within restriction put by OFM1999 there are tremendous possibilities for innovation. First of all in the area of integration with shell and virtual panels (in general panel can contain arbitrary set of files, not just content of some directory). Then in integration on built-in editor with the rest of file manager (the difference between the editor and panel management code is not that big -- panels can be considered as read only windows of the editor and implemented as such)
In view that involvement of most OFM developers is limited in both time and the total size of codebase (if this is a single person project, but mist such projects are), the most optimal way of designing new OFM managers is to concentrate on better implementation of one of two key ideas and limit "bells and whistles" to some future period when and if users provide feedback and make it clear that it makes sense to develop the product further.
A single developer simply can't compete with, say, Midnight Commander, or FAR, or Total Commander in the "total coverage" of functions. But you can implement minimal OFM standard and try to beat other developers by attacking a different set of problem or implementing one of the features that are "misunderimplemented" in current implementations. For Windows OFM the key is usage (and integration with) PowerShell; for Unix implementing command like window should in in a style of GNU screen, as a "first class citizen" not as a bastard child like in Midnight Commander.
In this sense it is important to understand that 80% of your users will probably be limited to basic features described in minimal OFM standard (Orthodox File Managers Standard 1999(OFM1999) - minimal OFM requirements). They will be attracted by "the feature" that your OFM implements better then competitors, not the general richness of features and "total coverage"...
For standalone application the question if you can built a better mousetrap probably revolves around three features that IMHO are badly addressed in current generation of OFMs:
In case of Unix/Linux with its severe restrictions of keyboard driver capabilities you can imitate DOS helpline functionality by "rotating" line with some shortcut with each "slot" representing one of the four position like in the revolver -- plain (no special keys pressed), Alt, Ctrl and Shift.
This problem with "excessive richness" of command set for keyboard oriented applications is a generic problem, for example vim suffers from it too. So putting efforts in solving it in some elegant way might have far greater return than just your OFM.
In a way quality of such built-in cheat sheet like OFM bottom "helpline" is much more important
for applications that emphasize keyboard usage, then for GUI applications. And solving it in an
elegant, inventive way will definitely attract users, especially users who have some investment
in other OFM but hit the "glass ceiling" and just can't remember more shortcuts. For example, from
my own experience I suspect that this is a fundamental problem for users of Midnight Commander which
does not implement "helpline" properly and in menus does not implement anything sophisticated in
this area at all.
Your web site can as a powerful tool of popularizing the idea that you have chosen. In case you are doing open source development; don't be shy to ask for donations, especially in a form of equipment.
I think that for system administrators this is a question of "esprit de corps" to support development of one of OFMs. As sysadmin IDE this open source development helps everybody and this page is my small contribution to the development of OFMs as sysadmin IDE of choice. If you think how dull typical enterprise environment is, you probably can find a couple of hours a month to contribute to the project. It is not necessarily contribution via coding. Testing and creation of documentation are also very valuble, albeit much underappreciated activates.
A challenge for human-computer interface is to support creativity and that's flexibility that OFM interface provides and close integration with shell make them far more extensible and "creativity friendly" from other types of file managers.
If you are a sysadmin who never tried one, please spend a couple of hours and play with Midnight Commander or FC for Linux/Unix and FAR on Windows. All of them provide some implementation of shell terminal windows which is of primary importance for sysadmins. FAR also provides rich set of plug-ins. Please note that OFMs have a rather steep learning curve and don't be discouraged by initial difficulties. Your persistence will pay you nicely...
The Orthodox File Manager(OFM) Paradigm
Dr. Nikolai Bezroukov