Softpanorama (slightly skeptical) Open Source Software Educational Society

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

Softpanorama University Library

The Orthodox File Manager (OFM) Paradigm

by Dr Nikolai Bezroukov

Console-based OFM Implementations:
size vs. functionality battle

In order to be useful and efficient OFM does not to be big. Probably 80% of OFM functionality can be delivered in a very small package. Please remember that NC 3.0 was less then 100K and Volkov commander, which widely considered to be classic DOS OFM 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 who think that  mc should be a lightweight portable tool in best Unix tradition felt betrayed and expressed negative feeling toward Pavel Roskin, the program maintainer who assumed this role when mc was in crisis and made (and by-and-large implemented) 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...

At the same time when faced another dilemma connected with the usage of gnome libraries, specifically glib, Pavel Roskin decided to preserve glib usage, although many developers were against this path (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 definient 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 exprely 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 ;-).