Re: A proposal for Midnight Commander

[Pavel Roskin <proski gnu org>]

Hi, Ali!

Sorry for late reply.  I was away when this thread was active, and later I
didn't have time to read such a long thread.  It took me 2 hours just to
read all messages, and yours is perhaps the only one that needs my reply.

On Sat, 15 Nov 2003, Ali Akcaagac wrote:

> On Fri, 2003-11-14 at 22:41, Nerijus Baliunas wrote:
> > Well, Ali is right. I remember one of mplayer developers
> > posted a few patches, but got no reply from Pavel...
>
> Actually it was not one of the MPlayer developers. It was the lead
> developer of MPlayer himself - Arpi. The guy who has bigger balls in his
> pants than others (refering to his skills here). Ok it was always
> criticised that the MPlayer code looked awfull but this is hopefully
> being dealth with in MPlayerG2. But more interesting is that he and his
> team of developers were those who finally brought one of the best
> mediaplayers around to open source.

The patches were not suitable for 4.6.1 release.  Fortunately, we have the
patch repository on savannah.gnu.org, so the patches can be put there and
applied later.

I know, some of those patches could have been applied after some work.
That's what I do with simple patches.  I simply cannot afford to spend
time applying large patches if I know that the underlying code needs
cleanup and I'll spend more time on more complicated code.  I'm just
trying to maximize the return for the time I can spend on the project.

It's painful for me not to be able to take every contribution immediately,
but I have to choose.  There are more factors than whether the patch works
and who wrote it.  If the code becomes harder to understand or to change,
we may be losing in the long term, including the end users who won't get
some features because maintainers are trying to understand what the code
does and why it breaks instead of adding new features and making releases.

The 4.6.1 release is primarily held by the undocumented timestamping code,
that also "mostly works", but crashes in some situations (extfs inside
extfs).  There is nobody actively working on the project who has the
complete understanding of that code.

4.6.0 has a buffer overflow in VFS and the editor will close by Ctrl-g
without asking.  If not that crash in VFS, 4.6.1 would have been released
already.

Arpi may be a great programmer, and his code may be ideal, but if it makes
it hard to understand the existing code, it's also important.  If if takes
a day to understand a patch (and that always involves understanding the
existing code) I must consider if I want to spend that day on something
else and maybe understand the existing code better, add some comments,
understand the limitations.

I'm sure some other person could have performed better in my place, but I
don't know such person who would take my place, and my choice is between
doing what I can and not doing it.

> This makes him a qualified person as soon as it comes to innovate and
> bringing projects futher. I only didn't caught his signal where he
> wanted to create a new mainstream Midnight Commander early Spring this
> year. Anyways have you people paid attention that during this entire
> conversation that Pavel didn't replied to it anymore ? This is a
> development Mailinglist so raising Proposals and ideas what can be
> changed is a common practice. I am not talking out of my back here - I
> do know what I am talking here and raising some good points that others
> may not have seen so far is definately a good point but I take his
> silence as - not wanting to cooperate in any ways. Accpeting patches
> from others and the normal smaltalk is welcome but major changes or
> raised opinions somehow not.

I was away and could not participate.  It took me 2 hours to read the
whole thread, and I didn't have time for that before now.  Again, I'm just
trying to spend my time effectively.  Participation in active discussions
could drain my time resources while there were important patches in the
message queue.

I don't consider the glib dependency a major issue.  It will be a bigger
issue if we start using it for real.

> After all we are just talking about software here and I am happy that we
> kept it that way. Anyways I would wish that people are more cooperative
> and more open about innovation and going a good way rather than keeping
> their tunnelview and stay stuck in road they are going. Midnight
> Commander is a nice tool, the source code layout in the Midnight
> Commander dir looks quite promising. After all we are not pushing
> Mountains here. Anyways Pavel, my offer to help removing the glib
> dependency still stays. I would accept it, it's a general benefit for
> all.

I appreciate your readiness to work on free software.  But I'm still not
convinced that it's the right thing to do.

Let me sum up the arguments as I see them.  It should be easier than to
reply individual messages.

1) glib is easy to remove

I don't care if it's easy or not.  Just because it can be done, it doesn't
mean it should be done.

2) glib adds code size at the runtime

Many other things do.  Those who design embedded systems should consider
what can be removed or disabled.  I believe that glib 1 should be used and
linked statically to eliminate unused code.  Maybe glib 2 should have
better support for embedded systems, e.g. it should be possible to
eliminate some unneeded features, like selection of the malloc
implementation.  Also, some sources could be split to make smaller object
files and this make linking more fine-grained.

3) glib adds (or will add) dependency on GNOME, XFree86 etc

That's an invalid argument.  Maybe there is a problem with perception of
glib as part of GNOME, but I cannot fix perception by technical means.

4) glib may have its own bugs

Yes, but I'd rather trust the list code written by somebody specifically
writing the list code rather than the code by somebody implementing e.g.
directory list in mc.  There are some little details that are hard to get
right if you are thinking of something else.

I must admit that glib makes it easy to make certain errors with lists.
I don't know if alternative implementations were considered.  But I don't
know of any replacement for the list functions in glib.

5) glib has an unstable API

Unless you specifically disable deprecated functions, it should be
backward compatible.

6) glib is hard to compile

That's true for glib2 because of its dependency on libiconv, gettext and
pkgconfig.  I still cannot get the build script build-glib2.sh to work on
FreeBSD 5.1.  This needs to be fixed.  In particular, recent versions of
gettext hardcodes the ".so" suffix in some places.  Also, glib doesn't
detect libiconv properly in some situations (it uses headers not matching
the library).

On the other hand, we have glib1 now, and it's easy o compile.

7) glib brings additional dependencies

glib2 doesn't bring any additional dependencies for full-featured mc.  We
are using gettext already, and libiconv is used if the charset conversion
is enabled.  If you are building an embedded system, use glib1 for now,
but help glib2 developers to make glib2 leaner (optionally).

8) glib brings no real benefits to mc

Not true.  A lot of string operations are simplified by functions like
g_strdup_printf().  It may seem easy to replace each function with an
equivalent not using glib, but it may not be so easy to understand and
modify the code using standard string functions.

9) we don't need glib2, let's just integrate parts from glib1

glib2 has potentially useful code, such as Unicode support and the event
loop.  If we were using the event loop, porting mc to BeOS with its
braindamaged socket-only select() would have been trivial.  We cannot rely
on Unicode support in libc if we want to stay portable.

10) glib is not portable

glib1 is portable.  There are minor issues with some OSes, but they are
trivial to fix.

glib2 has issues with one of its dependencies, namely gettext.  I'm not
aware of portability issues in glib2 itself.  These problems can and
should be fixed before we drop glib1 support.

11) the alternative to glib is glibc

We cannot rely on GNU extensions if we want to stay portable.  There are
many libc implementations that crash on free(NULL).

12) shared libraries are inconvenient, fault prone etc

Shared libraries are good enough for OpenBSD.  Modular design is good
enough for spacecrafts.

13) users won't find glib, especially the glib-devel package

If you are compiling code, you are supposed to understand something.
Otherwise, use precompiled packages, including mc.

-- 
Regards,
Pavel Roskin