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

Console-based OFM Implementations:
size vs. functionality battle

In order to be useful and efficient OFM does not has to be big. Probably 80% of OFM functionality can be delivered in a very small binary package. Even source codebase can be very small, say 3K lines in a decent scripting language like Python, Ruby or Perl.  Please remember that NC 3.0 binary was less then 100K and Volkov commander (which widely considered to be classic DOS OFM) the binary was less then 64K. On the other side DN was huge by DOS standards and although it provided a lot of additional functionality all-in-all it was no match for Volkov Commander.

This battle between functionality and size was replayed in Unix arena almost the same way it was played in DOS. The classic example of a useful but still small OFM is probably deco, the OFM that we will discuss next.

An example of a useful but huge OFM is probably MC.  Still even in this case adding features at some point caused revolt: with his misguided orientation on Microsoft imitation Miguel De Icaza decided to create a Gnome GUI-based version of mc that imitates Windows File Explorer. This decision created a split in the community, several forks and at last revolt that removed GUI functionality and at least partially returned the program to its roots. Still even with GUI-functionality removed some people thought that  mc should be a lightweight portable tool in best Unix tradition and felt betrayed and expressed negative feelings toward Pavel Roskin, the program maintainer who assumed this role when mc was in crisis and made the decision to remove GUI-based functionality:  

> > Gabucino votes for glib1
> No, I vote to no glib at all! A two panel filemanager doesn't need all these
> sophisticated stuff! Check Volkov Commander, it's a 64kb DOS COM executable
> (and imho it's much faster/stabler/better than mc, pity it's on DOS).
>
> But this argument is getting very very pointless, it seems Pavel apparently
> listens to noone, likes reinventing the wheel, dropping simple support for
> many OS'es, and his dictatoric means of maintaining resulted in the
> appearing of many mc forks...

They felt that he stopped half-road and simplification should run deeper. Especially troubling for this category of users and developers was the fact that when faced with the usage of gnome libraries, specifically glib, Pavel Roskin decided to preserve glib usage, although many developers were against this decision (and usage of glib was the second decision that fueled the forks). 

Actually the pressure to lessen the complexity of the code is acute in large C-based projects like mc. And libraries looks like a natural place to go. But adopting any "general purpose" library (and especially library created for Gnome project which is famous for the amount of bloat)  is a path that is connected with problems of its own. In some cases cure can be worse then the disease.

First of  all general purpose libraries are often too general purpose and their functionality is an overkill and does not suit the developer of a particular application (for example mc) as well as custom libraries. No one wants to duplicate effort and rightly so.  But road to hell is paved with good intentions and each of these libs tries to do every possible thing. They all end up hugely bloated while functionally deficient for each application they are used.   As a result  you application became a bloated pig where you rely on libs for everything instead of actually thinking about best algorithms and data structures for each particular case (which is an essence of programming).  So it is not the problem to use the library, it is the problem of finding right library that stops at the right point before you kill your own project with additional complexity. Sometimes it is also possible to influence the developers of this library to resist further bloat. As Michael Meeks  noted:

For example, I think it is extremely important that in the free software community we stop duplicating code [2]. One good place to start helping Netscape / OpenOffice share a common cross platform compatibility layer with us would be at the system abstraction level.

This is (unusually) somewhere where all the projects agree 'C' is the best choice of language, and somewhere where all the projects have a simple set of module dependencies, and where real co-operation would be possible.

Of course, having done this it would be far easier to start merging higher level parts of these projects to reduce wasteful redundancy, but, instead of having a sensible system abstraction in glib, 'we' are pushing more and more clutter into it. eg. the new, meaner cleaner glib has:

Sensible:
        * sized types: guint16 etc.
        * generic warning/error code
        * helpful assertion macros
        * a niceish IO abstraction
        * thread abstraction
        ...
Incredible [4]:
        * Lots of C helpers, GList, etc.
        * A cut down XML parser
        * A simple lexical scanner
        * A simple C type system
        ...
</case_study>

And so, it becomes progressively more impossible to try and get people to cooperate using glib because it has lots of crud that people don't want to link to - so instead every user of GNOME and Mozilla pays a per function penalty.

[ And this is without the almost impossibility of encouraging people to fuse duplicate projects, make non-technical compromises to share code, loose overall control of the result etc. etc. ]

So yes, keeping the code in small modules is good, but please don't eternaly keep moving code into Gtk+/glib. I in no way look forward to the day when  ORBit, bonobo, evolution, mozilla, postgress etc. have been 'folded' into glib/Gtk+.

        Regards,

                Michael.

[1] - increasingly it seems that the Gtk+ team want to build everything from GNOME into Gtk+ where it suits them to have it. Understandable in many ways, and often resulting in greater code quality due to the mess that exists in gnome-libs [3]

[2] - cf. Unix Sucks, etc. etc. ad-nauseum

[3] - I'm not optimistic that the eclectic maintainer situation that lead to the mess in gnome-libs is going to improve at any stage without a full migration away from gnome-libs ( so I don't altogether disapprove of this strategy ).

[4] - don't misunderstand me, I think that moving the object system to glib is far, far better than having it in Gtk+ where it clearly doesn't belong.

The second problem is that libraries create "version hell" (called DLL hell in Windows) when any dynamically linked version of, say, mc stops working on any system that does not contain (or should not contain) such libraries. The only way is to statically link mc with all the libraries. The compromise that was found in mc development was to limit usage of glib to version 1 as less intrusive and smaller then version 2 (and that looks like a right one; quick data check: glib-1.2.10 is 1/2 of uclibc in size. glib-2.2.2 is 2 times uclibc. Four times growth in size with very little useful functionality premium ;-). But this compromise was broken by Pavel Roshin himself who pushed glib2 through the throat of other developers.

BTW switching to another more powerful compiled language like C++ is also a mixed blessing and we will discuss this is some more details when we review mc development history. I am convinced that using scripting language (and associated libraries) is the best architectural approach to creating powerful but at the same time maintainable and portable OFMs. That path also permits introduction of internal scripting language for creation of macros and doing all kinds of customarizations, the things that mc does very poorly.

Of course, Linux in general (and Gnome in particular) is getting fat and that influences applications like mc in a negative way, but still it looks like there is some upper limit in size of codebase and size of executables after which written in C programs start to exhibit Java-application syndromes ;-).

Etc

Society

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

Quotes

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 quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

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

History:

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 DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting 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-Month :  How 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 Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

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 Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. 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.

Last modified: March 12, 2019