May the source be with you, but remember the KISS principle ;-)

Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor

Less is More: The Orthodox File Manager (OFM) Paradigm

by Dr Nikolai Bezroukov

Content : Foreword : Ch01 : Ch02 : Ch03 : Ch04 : Ch05 : Ch06 : Ch07 : OFM1999 : OFM2004 : OFM2012

Prev Contents Next

Ch. 1: Introduction

...Do we not all too quickly become dependent upon the vote of but one  party -- that party which perhaps as much through favorable circumstances as by its own merit eventually was thrust into the foreground, and which possibly has at its disposal today the more powerful, and thus the more prevalent voice, only because the chorus of others has been muted?

Must not the historian, like the judge, preside over the parties and maintain as a primary principle the dictum audiatur et altera pars [let the other side also be heard]? When one side cannot, because of anxiety, confusion, or clumsiness, gain proper recognition, is it not the obligation of the judge -- and, mutatis mutandis of the historian -- to assist it, as best he can, to unfold its case instead of simply submitting to the mental agility and firmness, the sagacity and loquacity of the other?

Does either judge or historian dare to act as though whatever cannot be read and understood by everyone as part of the public records never existed, and thus is unimportant for passing sentence?


The Orthodox File Managers (OFMs), also affectionally (but incorrectly ;-) known as "Commanders" are probably the most influential type of file managers. But the OFMs are more than just a popular type of file managers. It is a cultural phenomenon that we ( lacking more precise definition) will call the OFM interface paradigm or even Orthodox Computer Movement.

They value the keyboard interface (while not rejecting convince and tremendous possibilities introduced by the mouse) and try to implement a novel, more efficient methods of combination of GUI interface with command line. One such innovation is the ability of Orthodox file manager to export certain values from the panels (such as path to left and right panels, the current file, etc) to the environment and then add them to the command line either via shortcuts or via the value of special environment variables. In different forms this value of "peaceful coexistence" of command line and GUI interface is also reflected in Unix administrators devotion to vi and screen, or VM/CMS users love for XEDIT. Those program are also including into Orthodox interface paradigm.

Notion of Orthodox interface

Orthodox interface is the interface that has both command line interface elements and GUI interface elements glued together.  As cynics would say this is a half-baked GUI-interface and this statement definitely has some truth as at least one of them  emerge during attempts to convert previously pure command line tool to GUI (text terminal GUI) mode: this was the case with vi which was text terminal GUI extension of ex editor.  Apple and Microsoft GUI interface attempt to hide from us the internal command that you mouse gestures are generating, while orthodox interface attempts to expose it.

In Orthodox interface there is always a set of commands that exists as a language with text  names for functions and parameters and glued together by control structures. Special keys and key combinations as well as mouse buttons and mouse gestures are just shortcuts to this basic set of commands. So interface is split into two parts:

This existence of formal internal language is the most distinctive feature of orthodox interface.

And this idea was invented and reinvented by so many people that it looks like this is a new different type of interface, distinct from Apple-Microsoft interface.

For example this is true for various OFM, for orthodox editors such as vi or XEDIT like of editors (Edit, Kedit, THE, Slickedit), for GNU screen, smith in AIX and many other programs.  Those tools were from the beginning designed is a way that allow coexistence of command line with GUI interface. So in a way Orthodox interface is all about co-existence of two principal forms of computer interfaces in a single program by using command line as the focal point. 

That means that we can look at orthodox interface as a compiler of GUI "gestures" into regular command language with text representation. Those generated statements of this command line language are executed to achieve the desired effect.

We can also introduce idea of channel: each channel forward generated or manually written commands to specific processor. For example we can thing about vi as having two command channels: one is ": channel" (internal commands channel) which process commands directed to editor buffer and another is "! channel" (external commands channel) which direct commands to OS with the possibility of using all or part of editing buffer as input as well as to modify all or part of the editing buffer using output of executed in OS command of complex pipe. 

In OFMs this is implemented differently: there is a single "OS command channel", but there is not distinct "internal command language", althouth some OFMs recently moved in this direction.

All-in-all I am convinced that the notion of Orthodox interface as an interface distinct from and based on different principles then Apple and Windows GUI interfaces (which are actually became much closer with time). As such this is a much wider phenomenon then either OFMs and orthodox editors such as vi and THE (orthodox editors),  windows multiplexers (GNU screen), windows managers (such as ratpoison).

I am still working on refining this notion but as a set of  ideas it definitely includes three following notions:

  1. Extensibility and programmability (with shell and/or scripting languages) are key to enhancing productivity of advanced users and as such they should have much higher priority for designers of the interface then chrome.  This "the ability to program as second literacy"  paradigm (see  Ershov1972 ) inherent in orthodox interface is actually radically different design paradigm than the one used in classic Apple-Microsoft GUI with their emphasis on "users" and  multicolor eye candy with gradient colors icons and fancy animations.
  2. Orthodox GUI is a "visual shell".  Like classic Unix shells, Orthodox GUI should have least one "command channel": ability to type statements in some formal language which, when executed, change the state of GUI. In other words they implement what can be called "command line controlled GUI". It can be just "external" command channel where commands  go directly to OS (like in OFMs), or internal command channel where commands are processed by internal interpreter (for example REXX or Lua) and reflected on the part of editing buffer that is displayed as in orthodox editors, or some combination of both. Commands that are entered into command channel are executed immediately like in shell and the result is immediately reflected in GUI interface. They can be glued into complex scripts by some ad-hoc or (preferably) standard scripting language like REXX or LUA.
  3. Elements of  automatic program generation with the help of GUI.  Another way of looking on orthodox interface is to assume that GUI "gestures" in it first are compiled into some command line language and that those generated statement are executed by command processor and cause corresponding changes in GUI screen. That means that we can (and probably should) look at orthodox interface as a compiler of GUI "gestures" into regular command language with text representation. Those generated statements of this command line language are executed to achieve the desired effect.

    GUI can also be used in supplementary role to generate part of command line construct that are written by the user on the command line by inserting certain elements via macros or shortcuts like (Ctrl-Enter, Ctrl-[ and Ctrl-] in OFMs) and any other creative way. Generally in OFMs you can "assemble" pretty complex commands from elements of GUI (and freely move within directory tree in a process without destroying it, the capability that was always a desirable part of Unix command interface)

    Recently those ideas related to vi and orthodox editors started cross-pollinated OFM that consider themselves not derivatives of Norton Commander, but derivatives by  vi  See ranger and vifm. have some interesting, distinct from traditional "Norton" line of OFM ideas implemented.

There are also some other common features but they just overlap and extend the three more fundamental features listed above:

  1. Tiled, nonoverlapping windows with minimum decorations. Generally both Orthodox editors and Orthodox file manager feather rather Spartan interface.
  2. Stress on availability of all commands via keyboard, not only via mouse clicks, althouth mouse can be productively used and is widely used in such interface. In this sense claim that such interfaces are "mouse-less" is completely untrue. Simply mouse plays the role of important but supporting instrument, not as the primary instrument as "drag and drop" type of interface. 
  3. Stress on availability of macrogenerator. This is connected with viewing shortcuts as the means to generate some internal commands.
  4. Stress on the ability to utilize pipes and external program as a source of gui elements. This is especially visible in vi with its ! and !! commands. Ability to redirect output of commands executed in one window to other windows and processes. That includes the ability of forwarding result of particular command execution into panel in OFMs (panelize command in OFMs, especially external panelize command in Midnight Commander) and capability of ! command to use part of editing buffer as input and pipe the result into selected part of editing buffer in vi. For example, the command:
    will beautify your program using standard Unix beautifier (indent). This is a classic example of using piping in vi.

Alterative GUi Interface that Strives Despite Being Far from Mainstream Ideas of Proper Interface

For a typical Windows or Linux user it looks somewhat strange that people continue to use descendants of a character-based file manager called Norton Commander that was initially designed for PC XT in 1986. With interface that definitely looks out of touch with modern trends and Apple-Microsoft GUI, that became dominant force in computing and defines "fashion" (and fashion plays more important role in IT then even in women closing).  Equally strange is that a lot of talented programmers devote considerable time solving intricate problems of designing a modern versions of OFM-style file managers. I believe that many users and even developers never heard about at least half of the implementations discussed in the book, but still can almost instantly recognize any of them as belonging to a special class just after seeing a few screenshots and key bindings. Actually the number of existing OFM implementation was probably the biggest surprise for the readers of the previous two editions of this electronic book (especially the first edition) as I can judge from the number of letters from readers that either contain some variant of the phase "My God, how you dared not to mention XXX -- such a wonderful OFM file manager. Shame on you..." or some variant of the phase "Oh, I never suspect that there are so many of them" ;-).

On the Importance of Standards for Orthodox File Managers

Standards are important for any mature software as they provide a framework that helps new developers "to get to speed" that puts various implementations of this type of file manager into common general computer-science and historical context. The main idea behind the series of standards that I created is to analyze several historically important and influential implementations and refine their best features which supposedly  should be strived to achieved by all implementations.

Currently three standards exists:

  1. Orthodox File Managers Standard 1999(OFM1999) - basic OFM requirements This is the   standard that defines the currest state of development of OFMs. The base of this standard are leading implementations such as FAR, Total Commander and Midnight Commander as well as good  good NC line of OFMs which now belong to abandonware.  It is expected to be revised once in five years but in reality is revised less often.  In 2012 version three of the standard was released. It defines 21 test of file manager compatibility with the standard. Here are the scores achieved by different implementations:
    OFM1999 v.3 score (average of all 21 tests) NC VC DN FAR Total
    Scores 68 71 73 89 70 68 66 75


  2. OFM Standard 2004  This is "Advanced OFM" standard, that describes functionality which corresponds to innovations introduced in  "modern" implementations of OFMs. 
  3. OFM standard 2012 (in the works) This is "Dream OFM features" or, if you wish, cutting edge features ;-). Due to the danger of overcomplexity "excessive zeal" in defining and extending such a standard can backfire. That's why the last 2012 is still contains very few features .  Fighting "excessive zeal" is very important and "cool down period"  after I discover some generalization or new exiting feature and time when I include it in the standard is set to one year... 

I hope that those standards can be useful for the authors of the OFM implementations to ensure interoperability and to avoid reinventing the bicycle in the most incompatible way possible ;-). They also stimulate to spend proper amount of efforts on features that proved to be the most valuable features. For example,  full implementation of shell screen capabilities proved to be extremely valuable but, unfortunately, right now only FAR comes close to proper implementation of this functionality (it provides ability to resize panels both vertically and horizontally). Such otherwise excellent implementations of OFM as MC and Total Commander lagging far behind.  I think that new implementation of OFM managers this represent a viable way to gain market share and "unseat" older implementation that lack this feature.

Another extremely important, but underappreciated feature is the ability to launch scripts with parameters defined in the current panels (the active and passive directory, the current file on the active panel or list of selected files). Those environment variables should be available not only in commands added to user menu (F2), but on the command line too. MC is a pioneer of this feature and I think it deserves the adoption by all OFM developers. 

The role of standard is to unify the field and hopefully to help developers to avoid reinventing the wheel. This is impossible without proper feedback mechanism. I believe that there should be more information exchange on this important type of file managers and more sites devoted to this. I hope that my modest effort will stimulate other people to create similar sites.

Despite the simplicity of the concept OFM functionality contains very rich and well integrated combination of features, so rich that advanced users like myself still are able to discover new possibilities after using OFMs daily for almost twenty years. OFM also contain some non-obvious capabilities the value of which is not apparent without years of experience with the particular file manager and/or good knowledge of the underling shell such as bash.

Why this book was written

This book is based on  my personal experience in OFM usage since 1989 and try to present historical perspective on the development. There was conscious attempt on my side to present things in their historical progression. For full mastery of any tool it is important to know historical roots of features that are deemed important. 

As we discuss multiple examples of OFM for several OSes, we also can demonstrate the level of diversity of the field. This way some cross pollination of ideas also can be achieved as extracting all this information individually, while possible is quite time consuming. Here is presented as a more or less coherent ebook and is based on almost 25 years of experience with this filed by the author as well as his training as a computer scientists. Few books about file managers are written by Ph.D in computer science as the field is looked upon as too low. But I became fascinated with it and don't care what my colleagues think about this :-). As m=some of OFM managers are now belong to open source I consider this book as my modest pro-bono contribution to open source software development, although I do not share all the related ideas. In any case I think that my computer science background might be an asset in my attempts to define the state of the art of the OFM construction both with this ebook and OFMs standards mentioned above. 

For users this ebook might provide an interesting glimpse into the history and major players as well as help to select an implementation most suitable for their needs. As you will see, not all OFM implementation are created equal. 

In both cases the availability of some kind of OFM standard is very important as a benchmark against which to measure existing implementations. As implementation change and new, better implementation arrive on the scene (or developer team changes in old implementations like happened with Midnight Commander) such a standard should be periodically revised. In developing such a standard by analyzing many different OFMs created for different platforms I see the main value of the book and my modest contribution to this field.

Recently there was a new wave of interest in OFM implementations for Unix. Midnight Commander, the development of which was stalled for a couple of years, again shows sign of life. It is now clear that OFMs provide a unique extension of the command like interface provided by typical Unix shells and despite being created initially for DOS environment blend perfectly into Unix command line environment. That's why Midnight Commander and other Unix-based OFMs implementations are considered so important and discussed in such detail on this book. In author opinion they have the lasting value as a new generation of command line interface of Unix shells and may in future blend with bash or other Unix shell (actually one attempt of merge OFM and bash was already made). I also think that at present level Linux console interface is close to elimination of limitations of older Unixes and can emulate most features of classic DOS interface with Ctrl, Alt, Shift and their combinations fully supported. OFM partially depend of the richness of keyboard functionality and it is really stupid not to provide full emulation of capabilities of standard PC keyboard in modern Unixes: the standard PC keyboards now probably constitute 99% of keyboards in active use.

Ten Commandments ;-)

Orthodoxy: The things that are considered correct and proper beliefs. This word comes from the Greek words 'orthos' meaning straight or right and 'doxa' meaning belief.

TheoGlossary - A Glossary of Words and Theological Terms by Dr. Terry E. Shoup

Orthodoxy: Any practice or teaching that falls within the established framework of the conventions, beliefs and doctrines of a given religious tradition.

Glossary of Important Terms

There is a large variety among OFM implementations. Moreover different OFMs are good for different situations and tasks -- there is no and never will be the best OFM for all situations and environments. But they all share same distinctive interface framework and the following basic features:

  1. Spartan interface with unique, "non-fashionable" but very functional structure: two symmetrical panels that display files in two directories and a minimized (but extendable to half and full screen)  telnet-style terminal session with local host ( command line ) at the bottom of the screen.  
  2. Seamless integration with the shell making OFMs a synonym to "Visual shell.". There are two features that are obligatory for orthodox file managers
  3. The ability to extend file manager functionality with custom scripts providing users with script library (called user menu and traditionally available via F2). Both command line and GUI-based OFMs should have the ability to create a library of "helpers": simple (or not so simple) shell scripts accessible using F2 . You can invoke them by assigning each of them special hotkey. Scripts should permit macro variables that reflect the current status of both panels (path to active/passive panel, the current file on active/passive panel, selected files , if any, etc).  This simple, ingenious, and very functional  extensibility with custom shell scripts make OFM very attractive for system administrators. They are useful for advanced users as they greatly simplify working with archives, ISO and so on and so forth. Actually in late 80th, early 90th of the last century in the former USSR region many DOS users never suspected that any other DOS interface exists: OFM interface was the standard and the only DOS interface they knew. 
  4. The availability of scripts associated with file extensions via special file extension menu and invoked by pressing Enter on the file with the particular extension on a panel.  This is another way to extend file manager functionality and file extension associations were pioneered by Norton Commander.  Special customizable extension files that permit context-dependent invocation of scripts and programs on a  file click (execute), F3(view) and in F4(edit). Customizable file extension menu should provides automatic passing of various panel-based parameters to shell scripts via macro variables (or environment variables) that were discussed above (active file, path to left and right panels, list of selected files, etc)
  5. "History for everything" approach to user input in command line and dialogs.  Starting from Norton Commander all OFMs provided the history of commands. Modern OFMs add to this the history of directories visited, files edited, selections, etc. Some advanced OFMs like Midnight Commander add to this the idea of "file/text completion for everything".
  6. Integration of application protocols into file manager framework via virtual file systems(VFS). Most popular are  ftp client VFS and archive VFS. Commonly they are implemented as plug-in based on some defined plug-ins API. Less popular, but still very important are Search VFS and "flat tree" VFS. They are all based on the same concept of a virtual file system:
  7. Tight integration of text files viewer and editor within OFM. An integrated viewer for text files and an integrated editor provide some additional and valuable integrating capabilities

    Both editor and viewer should be able to work in full screen mode (default) and "panelized" and should have access to information on both panels (current file, path to the active/passive panel, etc) and ability to treat selections as objects to past into command line (for example for moving to directories). Both editor and viewer should permit pasting information to from the editor to panel (for example, change directory to selected, paste selected into command line, etc) and getting information from panel (names of selected files, etc) and selected parts of the command execution screen back into the editor. 
  8. The ability to add search results to a  browsable virtual panel (panelize command) and a special "directory only" search in a special "find folder" panel. There should be abilities to find an arbitrary file(s) in the filesystem with capabilities equal of better then Unix  find and grep utilities, but with more friendly interface. All panel operations that make sense (view, edit, copy, move, rename, delete) operations should be available from panelized search results:
  9. Client-server connectivity. There should be some kind of client-server connectivity between two instances of OFMs (preferably SSL based TCP/IP connection, or unencrypted TCP/IP connection like in MC, or connection via serial cable like in NC3-NC5, or parallel cable and USB cable like in Total Commander).  This is a fundamental feature because it dictates client-server architecture of OFM with client part and server part separated by some kind of API. Generally one instance OFM should be able to perform as a server (represented by one panel) and second as a slave (represented be the other panel) with the ability to copy files and perform  commands on the remote host. 
  10. Extensibility via plug-ins mechanism. System of plug-ins that extends functionality of the OFM (FAR, Total Commander) and corresponding API.  This is important for OFM architecture as it separates panel interface from the rest of OFM.  FAR is now open source and its plug-in API can serve as an inspiration for future developers.

Again those are Commandments and like in everyday life not everybody is observing them ;-). The worst situation is with providing ability to extend command line at the bottom to command line window. Please note that This unique, innovative capability of Norton Commander (the one that makes it a graphical shell) for some reason is rarely implemented correctly if at all. Please remember that the original name of Norton Commander was VDOS -- visual shell for DOS.

Please remember that the original name of Norton Commander was VDOS -- visual shell for DOS.

Even such leading OFMs like Total Commander and Midnight Commander  do not implement them correctly. For example, in Total Commander  just basic command line functionality is available without ability to extend command line window to half screen of full screen.

In Midnight Commander only full screen command line window available but its functionality is limited (no ability to extend command line window to half screen or expand it line by line as in FAR) and behavior of command line window is different from typical bash shell command line windows which makes it unattractive for power users (compare with  GNU screen "split windows" mode, which should serve as reference implementation of this feature).  In other words MC command window implementation represent example of a cheap hack.  Paradoxically Unix OFMs users (and first of all Unix sysadmins) who would benefit from this functionality most (as culture of using command line is strongest in Unix) need to deal with the weakest in implementation of this feature

Notwithstanding differences and weaknesses of existing implementations three key features stands out and are the key postulates of faith of the "OFM religion":

Complex file operations using mouse is not faster and as cases became more complex are less convenient then performing the same operations using keyboard-based interface using the file manager that implements Orthodox interface paradigm. In a way orthodox means "having the right opinion/following the right practice". And using full power of keyboard (while not rejecting mouse) looks exactly like this. Provided by OFMs unique combination of GUI elements with the preservation of the power of command line is superior to any "mono" interface: either "classic Unix command line" interface or Windows-style GUI interface.  There are several reasons for that. See GUI vs Command line interface.

Text-based vs. GUI-based interface

Another important question that arises is why to use to a text mode file manager when GUI file managers with fancy bars, buttons, drag and drop are standard for Windows and are widely available for Linux. Orthodox File Managers are example of "less is more" and prove that functionality of programs with well developed command line interface can give a run for the money in functionality to any GUI-based file managers. Actually functionality of Volkov Commander, a 64K (sixty four kilobytes!!!) COM program is superior to many file managers twenty time this size. While mouse is a convenient pointing device as we will see later there are certain undisputable advantages of a command line interface-based OFM   because they essentially are a new generation of the command line interface for the operating system shell.

Console interface OFMs  usually have much lower resource requirements: often they are small programs that can be used on different computers without any installation and are loaded instantly. For example one of the famous early implementations of OFM Volkov Commander (VC) is just 64K program that can be downloaded even on a computer over slow modem. They can be carried on small USB solid state disk, CDs or even floppies.

Of course there are some drawbacks as well. But actually the key features of OFMs do not depend on whether it has GUI-based or command line interface. It is the idea of full utilization of keyboard capabilities that really matters. That's why that are so many excellent GUI-based OFMs like Total Commander. Although the OFM paradigm is rooted in the character text interface and command line OFM implementations are text-based, OFMs are not limited to it. It is not a type of GUI per se, it's not keystrokes (if you can reassign them), it's the presence of the command line and the ability to perform them using the keyboard that matter most. Now a lot of OFMs successfully use GUI interface. Some, like Midnight Commander 4.5, have two versions: one text mode based and the second GUI-based.

The key features of OFMs do not depend on whether it has GUI-based or command line interface based. It is the idea of full utilization of keyboard capabilities that really matters. That's why that are so many excellent GUI-based OFMs like Total Commander.

GUI with it's ability to display different fonts, provides much more capabilities, than restrictive character-based interface. Nevertheless the character interface is really important and considered classic from another point of view. Artists know well the saying "form liberates". In the same way puritan character interface liberates a programmer from spending too much time and effort on unimportant things and thus provides the possibility to spend most of the time implementing richer set of operations. Paying too much attention/time/effort to the "face makeup" is characteristic to Windows developers and often negatively influence the core functionality of the product.

But it is possible to create a very good OFM with GUI-based interface that is as rich in functionality as the best OFMs with shell-style character-based interface. It's actually nice to have both keyboard interface capabilities and mouse-based drag and drop capabilities. I found more then a dozen pretty advanced GUI-based OFM implementations on both Windows and Unix platforms. Among them:

The history of the OFM implementations

The first OFM was written by John Socha in 1985-1986. He started developing Norton Commander before joining the company called Peter Norton Computing started to sell them commercially. Later when he became the first director of research and development for now defunct Peter Norton Computing. It was this  company which released the first version of the product under the name of Norton Commander in 1986, and where it it established name.  Peter Norton who wrote the initial version of Norton Utilities but AFAIK was not involved in writing Norton Commander. He was one of the pioneer entrepreneurs in PC software development and his company was among the first wave of successful PC software development startups that includes such names as Borland, Lotus and, of course, Microsoft. 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" ;-).

After the first version of Norton Commander was released in 1986 it instantly became a dominant file manager for DOS. Version 2 was released in 1988 and version 3 followed the next year in 1989. In 1986-1991 more then a million copies were sold.

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 letter acquired by Asymetrix. He no longer participated in the development of Norton Commander and this line of products experienced a fast decline. He continued cooperation with the Norton division of Symantec in other areas 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 and released version 4 (1992) and 5 (1994), but with the introduction of Windows 95 killed it and other DOS products (XtreeGold) that it acquired. Later they understood the mistake they made and in 1996 there was a reincarnation attempt in the form of a GUI-based version. Norton Commander for Windows 1.0 was launched in 1997, three year after NC5. But that was "too little, too late" and after one upgrade (version 2.0, 1998) it died again (still as of January 2003 you can buy Norton Commander for Windows 2.0 in Europe, especially in Eastern Europe).

But it was Europe where this type of file managers found new home after being abandoned by Symantec. Although originated in the USA, since early 90th of the last century the OFMs became mostly a European phenomenon with a very strong following in Eastern Europe (especially in former USSR countries), Scandinavian countries and Germany. I believe that the total number of the OFM implementations (including discontinued) is close to a hundred and more then two-third of them belong to developers from Eastern Europe and xUSSR area.  This figure alone says a lot about the phenomenon. No other type of file managers ever managed to get such a strong following. The concept migrated to Amiga and considered by many Amiga fans as a native -- some of OFMs listed below are continuations of the Amiga line, but I am not familiar with Amiga -- other that it pioneered usage of REXX both as an external (shell) and internal (macro) scripting language and was a very nice OS, so this avenue of OFM development is underrepresented in the book. Actually Amiga managed to integrate several great concepts into its environment and was probably the first OS where both shell and application macro language was the same (REXX).

OFM usage is also part of the hacker culture, especially East European hacker culture -- for example in Russia it is a must to any self-respected hacker to impress his friends by performing blazingly fast file operations on a favorite OFM (in old days it was usually VC). Later it migrated in Unix administration and most Linux and FreeBSD administrators in Eastern Europe used this type of managers in their daily work (Deco and Midnight Commander are probably the most popular but many others are used).

We will distinguish between command line character-based interface OFM implementations that use text interface and GUI-based OFM implementations. As with any popular product along with mainstream (orthodox) implementations there are various non-conformant/alternative implementation which deviate in some ways from the orthodox set of features and key bindings. Still most command line OFMs are quite compatible and users have no problems with switching from one to another.

One of the first attempt to generalize Norton Commander functionality was probably PIE Commander by Valentin Chernyak (Moscow). It has had four independent panels instead of two. The first Unix-based implementation was probably deco  (Demos Commander) by Sergey Vakulenko. It was also written in Moscow in 1989.

Four major DOS-based OFM implementations (VC, DN, FAR and CN ) are from Ukraine, Moldavia, Russia and, again, Ukraine. There are several Unix-based OFM implementations from this region as well (deco, Northern Capitan, etc.). In the former USSR countries OFMs are often taught at introductory university courses and books describing techniques of working with this type of file manager has been published in several millions of copies. Moreover from the late eighties till the early nineties for entry level users in the former USSR countries OFM interface was a synonym to the DOS interface. Many users never ever suspected that the OFM is not a part of DOS or that regular command-line DOS interface exists :-).

In other European countries OFMs are very popular as well. There are many implementations of OFMs in that region (probably at least three for each European country, I just do not know all of them and would appreciate additional information from the readers; also attribution to country in the list below might be wrong). Here is the list that I compiled from my Orthodox File Managers Bulletin:

Other continents also joined the race :-). Among them

The remaining part of this book provides the following information:

Unique Portability of OFMs

I would like to stress that OFMs are truly portable file managers that can be used on PalmPilot and on mainframes with PC and Unix computers in between. Although OFMs originated in DOS, they proved to be very natural to Unix environment and more than a dozen OFM implementations exist for UNIX. The first UNIX implementation of OFM was released in 1989. It was deco  (Demos Commander) by Sergey Vakulenko. The development continued till 1993 and currently the source resides on Sourceforge. It is still widely used in FreeBSD administrators. Currently the most popular in the UNIX environment is Midnight Commander.

Right now OFM development is slightly biased toward GUI-based implementations. As I mentioned above it is perfectly possible to create a very good OFM with GUI-based interface (especially in scripting language like Perl, Python or TCL). It's actually nice to have both keyboard interface capabilities and mouse-based drag and drop capabilities. While I have found more then a dozen of pretty advanced GUI-based OFM implementations on both Windows and Unix platforms, only TCL-based implementation are fully scriptable OFMs in existence.

Among GUI-based OFMs I would like to mention the following (in alphabetic order, in bold are those that are discussed in the book):

OFMs used to be popular among OS/2 users. I have found almost a dozen of implementation of OFMs for OS/2 in Hobbes archive. Probably we should double this number to get a reasonable approximation of total number of implementations for OS/2. It's not surprising because OS/2 users represented the most advanced part of PC-users. Technically OS/2 was superior to both Windows 95 and Linux and has two unique, still unmatched, advantages:

But unfortunately this nice OS is dead and we will discuss only one OS/2 implementation -- FC (BTW it has a very good Windows95/NT ports) in the third chapter of the book. Just because it also has Windows and Linux ports. It does not support REXX as a macro language.

Sometimes OFM-style managers are incorrectly called NC clones. The truth is that the latest incarnation of OFMs represented by FAR, Midnight Commander (MC) and Total Commander (as well as many other contemporary implementation) others are far from being clones and contain important original ideas. Moreover, from the historical point of view many new features in NC 4 and especially NC 5 were implemented in other OFMs at least a year before, so actually it was the attempt of Symantec to catch independent developers (that failed in NC4 but was pretty successful in NC5) that can be called cloning :-)

IMHO Symantec served as a graveyard for several very interesting programs and utility packages. Norton commander was one of the first such victim and Symantec lost interest in it soon after version 3.0 of NC was released. Or, more correctly, Symantec tried to close this product line after acquisition of Peter Norton Computing in 1991 (Norton Utilities v.6 that were released in 1991 had been the first product from Norton Computing that was copyrighted by Symantec). Anyway, with the introduction of Windows 3.0 the firm jumped into GUI bandwagon and never looked back. It realized that it made a huge mistake and that NC has its place in GUI environment only when it was too late. After 1993 independent developers were the only source of innovation in the OFM area.

Advantages of OFMs

Much like Johann Sebastian Bach's music OFMs simultaneously belong both to the previous century and to the next century. The DOS-style character based interface is more than 25 years old and is somewhat archaic. Some key assignments have no rational explanation from the point of view of a typical Windows user (but that deficiency can be easily cured by providing a key-mapping mechanism, see below).

At the same time OFMs offer a unique blend of simplicity and power. They provide a very efficient paradigm (a way of thinking about performing these operation - that's why the word paradigm appears in the title of this book) for operations on a large collections of file dispersed in a complex tree directory structures. Advanced users that start using OFMs seldom switch to any other file manager. There are a lot of users (including the author) with more that ten years of experience in one or several OFM implementations. This is a rare level of loyalty in the fast paced software world.

I see the following major advantages of OFMs:

  1. A better file manipulation paradigm than implemented in other file manages including File Explorer and other "windows-style" GUI-based file managers.
  2. Richer variety and more flexible semantics of file operations.
  3. Productivity of power users.
  4. Unique suitability to system administration tasks.
  5. Portability.
  6. "Small is beautiful".
  7. Dynamic development.
  8. "Form liberates".

Let's discuss them one by one.

A Better File-manipulation Paradigm

OFM idea of two absolutely symmetrical interchangeable panels (similar to the text editor with two text windows, actually OFMs have strong links with editors ) is not only more powerful model that asymmetrical model (the directory tree at the left, list of files to at the right) used in Windows-style GUI-based managers. It's also more natural. The tree in the left panel and the file list in the right with the possibility of drag and drop from one panel to the other permits only selection of files on the right panel, while OFM permit selection of the files in both panels and file operation can be performed simultaneously from left to the right and from right to the left panels.

Also command interface string at the bottom of two panels provides a kind of generalization of "drag and drop" -- the very thing that Windows users are craving for but this implementation is more flexible that "drag and drop" can ever be: MS Windows style "drag and drop" is convenient only for simple operations. For example if you need to supply a program with just one argument it's really convenient to drop file on the program icon on the desktop. But if you need to supply more complex string of parameters drag and drop simply does not work. GUI-based drag and drop is by nature a limited although simple and elegant interface. It's great for introducing simplicity and consistency to applications that perform a simple non-repetitive set of tasks. But it's not that impressive at handling huge, complicated, and unpredictable administrative operations that step outside the nice, neat boundaries of coping one or several files to other directory or dropping a file into application icon.

As Don  Gentner  and  Jakob Nielsen noted in their very interesting paper Anti-Mac Interface:

Using direct manipulation, users interact directly with objects in the interface [17]. The archetypal example is to move a file from one directory to another by opening the original folder and using the mouse pointer to drag the file icon to the destination folder. This procedure works well for simple actions with a small number of objects, but as the number of actions or objects increases, direct manipulation quickly becomes repetitive drudgery. The dark side of a direct manipulation interface is that you have to directly manipulate everything. Instead of an executive who gives high-level instructions, the user is reduced to an assembly line worker who must carry out the same task over and over.

Direct manipulation also means that users must always operate at the atomic level. They cannot group a related series of basic actions into one high-level action or use conditionals. Suppose we have a group of images and want to convert all of the PICT files into icons (see Figure 2). If the conversion requires several steps, this will be a very tedious process with direct manipulation, but a simple scripting language provides a natural means for specifying this task. Direct manipulation also limits the precision of our actions to the precision achieved with eye-hand-mouse coordination. Language and mathematics can be more precise ("Place the bottom of the triangle level with the middle of the circle") and more dynamic ("Maintain the height of this histogram bar at 37% of that of the bar to its left"). Finally, direct manipulation requires the user to be involved in every action, but sometimes the user may not know what to do....

At the same time the idea of assembling a command line from the program name and file name(s) in a special area (OFM command line) does work and is flexible enough to be useful both in command-line environment and GUI environment.

From this point of view I consider OFM operations Ctrl-Enter, Ctrl-[, Ctrl-] (or, better, using macros like %fn, %lp for the left panel path, %fn, %rp for the right panel path, etc. as in MC) to be a generalization of drag and drop. Again my assumption here is that drag and drop is just a special case that works well only in simple cases but deteriorates and quickly became a nuisance when you need to perform complex and/or repetitive manipulation on files.

Presence of explicit command line or more correctly command assembly line also provide possibility to add arbitrary strings to the argument list -- Achilles part of simple drag and drop where one needs to provide different icon for that purpose.

Richer variety and more flexible semantics of file operations

OFMs have richer variety and more flexible semantics of file operations that often permit performing tasks with fewer keystrokes and fewer mistakes. A simple example is a very common operation of moving file from the current directory to a subdirectory that exists in it. In OFM that can be done with the following sequence:

  1. Select files to be moved/copied (not necessary for one file -- in this case positioning panel file cursor on this file is enough);
  2. Invoke file tree with the F10 button
  3. Select the target directory (not necessary if there only one directory or you want to move file(s) into the first directory in the list)
  4. Press Enter

This sequence for a long time OFM user is performed automatically as a single operation and is blazingly fast, probably ten times faster than similar mouse-based operation (despite the fact that it is a perfectly suitable for mouse drag and drop example).

An advanced OFM users have some internal "patterns" for typical operations that he/she performs and can invoke those patterns each type the situation arise. Richness of semantics of file operations permits rather complex operations to be completed with a few keystrokes. For example to FTP selected files from the current directory to a known FTP server (that exists as a bookmark in a particular OFT, be it FAR or Total Commander) can be accomplished with just a half-dozen keystrokes. Any Unix sysadmin can appreciate this as ftping files is probably one of the most unpleasant operations in pure command line environment. Amazing power of OFM interface is most evident with the operations that on different "virtual file systems" (FTP is just one an example of such a filesystem, see below).

The OFM concept of multiple associations -- any extension in OFM (for example .txt) can be associated not with a single program, but with multiple programs. this is a more flexible approach then an approach used in Windows. Also the process of selection of group of files is more flexible and power of operations on groups is much bigger than in any known to be Windows Explorer-style manager.

At the same time OFM paradigm is flexible enough to successfully integrate useful concepts from other important families of file managers (Xtree and Windows-style) as well as ideas originated in WEB-browsers (directory favorites or bookmarks, back operation, etc.).

Now best OFMs (for example FAR) provide history support on the level that surpassed XTree implementations. And for the power users the history is a big productivity enhancement tool -- I would like to say uniquely powerful and useful tool.

Some very advanced concept, for example the concept of bookmarks were present in rudimentary, provincial form in OFMs from the beginning (traditionally user menu items were often used as bookmarks for directories in a file system) and several OFM implementations tried to develop it further (directory favorite lists), but recently WEB-browser semantics provide a unified framework for implementing this feature and it fits OFM paradigm quite naturally.

Productivity of power users

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.

Command line work well not only for file operations, but for a typical "administration mix" in windows and Unix environments. It is not sexy, but it work better that GUI based application is probably 80% of typical Unix administrator jobs. It also much more efficient than GUI for any remote applications and troubleshooting.

Established motor skills of power OFM users means that different key assignments kill an "deviant' OFM implementation almost instantly due to inability of users to apply already existing motor skills. Implementation can be better, but it just feels foreign like piano with different number of keys or without black keys would feel for a decent piano player. I still remember pain of mastering MC with it (obscure for me) Unix-culture induced key assignments -- I cursed designers a lot for their apparent inability to understand that some of the MC users would have established Dos-based OFM motor skills. Not everybody even in Unix world love Vi or Emacs ;-). Even today I hate to press Ctrl-S (or Alt-S) to invoke fast search on the MC panel.

Availability of virtual file systems (VFS) make some complex operations much simpler. Generally it seems that for complex file operations the OFM paradigm of symmetrical interchangeable panels with emphases on keyboard is more productive then Windows-style GUI interface with asymmetrical windows and strong emphases on mouse based operations (drag and drop). Here OFMs traditionally were great with search panel available from early versions (although only recently search panel became close to regular panels in best OFM implementations). Neat trick that power users of old versions of OFMs (that does not support Xtree VFS -- flat directory tree representation) used to use was to search files with mask *.* in a subtree staring from the current directory. That produced simulated Xtree view -- all files in the subtree that you can (in a limited way) manipulate. Now in best OFMs functionality of a search panel is very similar to the functionality of regular panels with the ability to view files, edit files, manipulate files, etc. In this sense Xtree VFS and search panel merged in functionality, but still I am waiting for Xtree level implementation of this idea.

The idea of Alt-F10 as a instant third panel with the tree view of the current disk (or mountable filesystem) is a very powerful and useful solution for a lot of typical file manipulation problems. The key word here is that it should be instant. Any scanning as in MC kill the idea. For example I almost never use tree representation of the second panel to navigate the tree, I use it for mainly for quick browsing. To navigate the tree I automatically invoke tree view of the current panel with Alt-F10 and navigate to the necessary directory on it.

Dynamic toolbar provides for user instant picture of available functions. OFM are very convenient for using with script languages and command line utilities -- user menu, extension menu and execution menu provide a very powerful integrating mechanisms for shell scripts and command line utilities.

Unique suitability to system administration tasks

OFMs are a very powerful tool for system administrators, and using them can considerably cut time needed to perform usual system administration tasks. I think that OFMs provide a cure for Unix-style command line perversions while preserving command line flexibility and richness.

As humans tend to understand filesystems better with graphical clues, OFMs are very useful for troubleshooting.

Many command line implementation of OFMs (Volkov Commander is a famous example) are small programs that can be used from the floppy. They are immensely useful in troubleshooting.

I believe that an OFM should be a part of the toolbox of any decent system administrator. Sysops of FIDO BBS were probably the most active OFM adopters and some features in OFMs are generalizations of BBS maintenance experience (4DOS file description support is one such feature). Most OFMs (FAR, NC5, Norton Commander for Windows, Windows commander, etc.) provide additional system administration tools for NetWare (drive mapping, etc.). MC provides additional UNIX management tools and good integration with Unix shells.


With its simple character-based interface OFM is the only portable file manager. OFMs managed to migrate to almost any other OS (including palmtops OSes, all flavors of UNIX, OS/2, Amiga and even IBM mainframe VM/CMS operation system). It can be implemented on black and white screen with limited number of shades of gray or even no shades at all. OFM is probably one of two types of file managers (the second is Xtree and its derivatives) with implementations on all five (or more, it depends on how you count them ;-) major Microsoft operating systems (DOS 2.0-6.22, Windows 3.xx, Windows CE, Windows 9x and Windows NT).

What is even more important is that OFMs provide unique possibility of having similar (although never identical) sets of skills dealing with command line and GUI. A very common observation about power Unix users is that they are usually command line jockeys and underutilized GUI interface. Often even if power Unix user works in GUI environment half of open windows are just terminal emulators. And sadly enough it's true because of long training in plain vanilla command line interface produce skills that although provide very powerful problem solving capabilities, are not directly transferable to the GUI environment.

"Small is beautiful"

OFMs are rather small programs that efficiently utilize system resources and can be developed by a single author. Now famous Volkov Commander 4.01 is an extreme case - it's a 64K program that was blazingly fast even on the most primitive and underpowered PCs of DOS era. At the same time the functionality of this 64K program beats the functionality of many Windows file managers that have a size of more than a hundred megabytes.

Dynamic development

OFM field is not static with well known players. It is a rapidly developing culture with a lot of innovation from newcomers. For example FAR -- current leader among command line OFM implementations -- is a recent introduction to the OFM family with v.1.0 released in 1996. Competition in the field of OFMs is really strong with several dozen talented programmers working on their products. The functionality of the latest generation of OFMs ("made in 1997" OFMs) is vastly superior to their predecessors made in 1993 or 1990. Also important are attempts to understand OFMs from the academic point of view (this book is probably just a humble beginning of the trend; more should follow).

"Form liberates"

The character based interface of command line OFMs is easy to implement, so most of the developer efforts can be spend of the semantic aspects of the file manager and polishing the set of operations instead of a series of cosmetic upgrades of the face ;-). That is probably also true if you are using TCL/Tk for implementation of a GUI-based OFM, but still it take more effort to implement GUI even in this much more comfortable environment.

It's not accidental that the revolutionary concept of plug-ins was first implemented in FAR -- a command line text-based OFM. I essentially do not know any other file manager that implement this very powerful and elegant concept.

Here is one interesting comment from LinuxToday discussion The Role of the Modern GUI

zerblat - Subject: Keep it simple, stupid! ( Jul 5, 2000, 19:39:12 )
Oh no, not another nostalgic article about old text based DOS apps! For the record,
I do spend most of my time in the console, since a have a rather old computer, and
there are lots of good console apps for Linux. (Who needs a wordprocessor when we
have TeX?)

However, it's important to realize that there is no fundamental difference between
character based interfaces and graphical interfaces.
The only real differences
are WYSIWYG and displaying graphics. OTOH there's nothing you can't do with a
GUI that you can do in textmode. But you still have the same principles -- buttons,
text entry boxes, chechboxes, windows, menus etc. The difference is the bandwidth
of the interface. A typical console can display 80x25 characters; how many characters
can you display on a 1600x1200 X display? In GUIs you can clutter the screen with
enormous amounts of icons, buttons, toolbars and whatever; character based apps can
only display a limited amount of information at a time, so the interface can't be
as complex.

It's the forced simplicity -- the limitations -- of the text mode, that makes
many textmode interfaces "better" than GUIs. Also, you can't expect console users
to have a mouse, so the interface has to be completely keyboard based, the mouse
is just a complement (the way it should be IMHO).

So, the old console doesn't really have any inherent advantages over the GUI
(except when you on an old box or telnetting). But, many GUI apps could learn a
thing or two from many text apps -- keep the interface simple and uncluttered,
and only use the mouse as a complement to the keyboard.
Of course, there are also
lots of examples of bad character interfaces. . .

Milestones of the OFM paradigm.

OFM paradigm is now more then 25 years old. BTW NC 1.0 stills works in Windows XP and there are still users of this version; this is an amazing, probably unsurpassed in Windows world, longevity of a program ;-). Here is the letter that I got in October 2005:

Norton Commander 1.0


I'm still using Norton Commander version 1.00 (1986) in Windows 98SE,
even in Windows 2000 Professional and Windows XP.

I prefer it's small size and fast, and I can write with it small batch programs.


Alvaro Alonso
From: Bogota, Colombia (South America)

During this time it has substantially changed and now support much richer set of operations and functionality. Some important events in OFMs development are shown in the Table 1:

Table 1


Dos/Win32 command line

Win32 GUI Os/2 Unix Web-based Comment

NC 1.0

The first version written by John Socha

NC 2.0

A lot of concepts were refined

NC 3.0

The most influential version of NC line. The last version written by John Socha. This is the command line version that inspired independent implementations
deco The first implementation of OFM for UNIX by Serg Vakulenko

Pie commander

The first implementation of OFM with 4 panels

DN 0.9

Start of an important OFM line

NC 4.0

Rather weak, but still important

VC 4.0

Assembler masterpiece. Much better OFM implementation than NC 4.0
TotalCMD 1.0 One of the first GUI-based OFM implementations. Start of an important GUI-based OFM line
FC 0.1 Start of the most popular OS/2 line


DN 1.10

The first archive VFS, generalization of the panel list and many other enhancements.

NC 5.0

The last representative of DOS NC line. Late, but very influential. Integrates some important features. The archive VFS became standard feature for OFMs.
MC 0.6 Midnight Commander was started

DN 1.35

VFS breakthrough. Archive VFS and three additional VFS were implemented
MC 3.0 FTP-based VFS was introduced


FileRunner The first OFM based on Tcl/Tk

CN 7.0

The first Dos/Windows OFM with (very limited) built-in scripting language (for editor and terminal only)
NCW 1.0 Symantec revives NC line

VC 5.0 alpha 03

New version of this assembler masterpiece

FAR 1.5

Plugins were introduced in FAR
TotalCMD 3.03 Proved that GUI-based OFMs are viable alternative to other windows file managers
MC 4.0 External panelize command was introduced

CN 7.5

Built-in HTML viewer support; better scripting language support
NCW 2.0 The last of Mohicans; The Symantec line of OFMs that was a continuation of the original Norton line seems to be dead

Drall The first WEB-based OFM (Drall) and a new idea of implementation of FTP VFS (WebDrive FTP).
2000 Dead season for OFMs started.
2001 Dead season for OFMs ended

TotalCMD 5


Northern Captain 5

New wave of GUI-based implementations. Old implementations like deco get a new life on Sorceforge.

FAR 1.70 beta 5

MC 4.6.0

TotalCMD was renamed into Total Commander (TotalCMS) Reincarnation of an important Unix OFM -- Midnight Commander -- after almost complete "Gnome GUI-based self-destruction" ;-)
2004 TotalCMD 6 was launched

TotalCms 6.51

New crisis in mc development: no new version for two years.
FAR is also in trouble.
Krusader started to take mc user share.

MC 4.6.1

New version of MC
2007 TotalCMD 7.0 Total Commander is 15 years old !!! Ghisler just needs to fix command line window functionality and it would be a perfect GUI-based OFM :-)
Prev Contents Next


FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes.   If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner. 

ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.  


Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy


War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes


Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law


Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Haterís Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least

Copyright © 1996-2016 by Dr. Nikolai Bezroukov. was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License.

The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting development of this site and speed up access. In case is down you can use the at


The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: June, 04, 2016