Re: A proposal for Midnight Commander

[Pavel Roskin <proski gnu org>]

On Thu, 13 Nov 2003, Ali Akcaagac wrote:

> On Thu, 2003-11-13 at 21:19, Pavel Roskin wrote:
> > Actually, it were you who insisted on adding glib2 support,
> > so I'm surprised that you are complaining now !
>
> Exactly I was the guy who provided the glib2 stuff to you. Well no, you
> are misunderstanding me here I think. I have no negative intentions
> about using glib1 or glib2 or something. I use GNOME for quite some
> years myself now and glib is kinda part of my system. I was only
> proposing to have it removed in general.

Fair enough.

> > And what do you suggests to use instead of glib ?
>
> I suggest going back to plain standard C library. I like you to do this
> test. Compile MC against the latest glib 2.3.x you get from
> ftp.gnome.org and add the -DG_DISABLE_DEPRECATED to it and see what
> happens.

I cannot do it right now, but I'm well aware that some functions may
become obsolete.  The approach I intend to use is to track the latest
released version.  Once a function is removed (not just deprecated), we
should upgrade to the new equivalent.  If the new function is missing in
older versions of glib, it should be added to src/glibcompat.c (see CVS).

> Glib1 is a no option on my system and on many other people's system
> either because the majority for now seem to have switched to GNOME2 or
> GTK2 already and do not intend to use glib1 anymore - regardless of the
> fact that it co-exists. The idea itself is wrong.

I also prefer to use current versions of all software.  On the other hand,
Glib doesn't promise stability of API in the long term.  I realize that
it's a problem, but I don't consider it a major problem, based on my
experience so far.

> Glib2 as in the new version 2.3.x has some DEPRECATED functions inside
> that MC makes usage of which pretty soon may be removed. This requires
> someone to work around and use other function calls to make it work
> again.

Well, I think it can be done.

> Standard C library is the solution here. Well I know this makes
> allocating memory and free'ing memory not become easier but it works. It
> works in thousands of open source console applications. MC is the only
> app so far that uses glib for this. It's a mixture of using glib calls
> and glibc calls and soon you hit on DEPRECATED functions anyways.

Many large projects written in C use their own utility libraries.  Samba
uses ubiqx.  Apache uses APR (Apache Portable Runtime).  gcc uses
libiberty.  Other large projects use higher-level languages and their
libraries.  Still, Mozilla uses NSPR.

> I can't exactly speak for other architectures such as SUN, AIX, Darwin,
> BSD etc. but I somehow do have the feeling that using glib for this is
> kinda wrong. Removing GNOME dependency from MC was a major big and very
> cool idea from you and I fullheartly supported this decision the time
> back when you removed that junk. It would now be a good sign to remove
> the last bits of it too. Thus I propose to make it glib free.

I understand your feelings, but I'd rather go with a utility library
maintained by someone else, ideally with standard stable API.

> The first steps would be to slowly replace the
>
> g_malloc, g_free, g_new0, g_strdup, g_strconcat
>
> Calls with native C ones. Once this has been done half of the entire
> work is done. I have been playing with the code for some mins and
> replaced (only as a test) the g_malloc calls with native C ones and the
> g_free with free (without any function test, only the grep). I wanted to
> check how much of the easier things can be done and what remains
> afterwards.
>
> It may look a lot at the first moment but it's not that much. Once this
> has been done we can look whether some 'really important functions' can
> be simply cut and pasted from glib into MC itself and then replaced one
> day. Then the general cleanups here and there.

I understand that it can be done.  We should retain wrappers because the
libc functions may not be as good as the ones from glib on some platforms.

> I know some of the users here are not thrilled by the idea, others may
> definitely be (and the MP fork isn't that old either its started in
> April this year and based on MC 4.1.40 which probably was the last
> glibfree version existing) e.g. he started with an older version because
> he belived it was the better thing to do. This itself was based on
> ARPI's fork which he made earlier. I think that these people and I share
> similar ideas here and I do belive that a lot of people outside (not
> subscirbed here) may belive the same here. A console filemanager should
> be usable in even the worst ever scenarios and not depend on so much
> libs.

glib is a single hard compile time dependency.  There are some hard
runtime dependencies (gpm, ext2fs), but their number will be reduced if
gmodule (or perhaps libltdl if we get rid of glib) is used to load them.

> Statically compiling - ok is an argument, but requires that glib exists
> on the system. Some people would argument that this may be a stupid
> thing but on the otherhand it does make sense, we don't want to stagnate
> here because we throw our pro's and con's at each of us. If we go that
> way then we make no real progress, while I do belive that it should be
> clear to everyone that having it not depend on many libs result in an
> application that may run in even worst case scenarios. Many people are
> trapped with prebuild distributions and installations, how many of the
> people using open source these days really know howto deal with the
> system. They all live in the best scenario e.g. when my system crashes I
> then go and re-install it from debian or red hat, but what about
> critical situations, e.g. your harddisk crashed, or some other thing
> happened which made your system inaccessible and you urgently need to
> rescue some stuff, you boot some rescue CD-Rom, you enter MC and it
> throws out libglib-2.0.so libgobject-2.0.so required.. Where to get
> these libraries quickly.. in the strange situation you may be trapped in
> ? You can't access the internet, you can't call up a friend, you have no
> other CD laying around infront of you and you didn't made recent
> backups. You then need to figure out another way to do the stuff.
> Doesn't this ring a bell or something ? I can't imagine that there isn't
> one on here that wasn't in such a situation.. and I can bet that there
> is the one or other who may have said 'Shit. I wished it wouldn't depend
> on glib.'

I'm not trying to convince you that the glib dependency is good.  I'm just
trying to find the best solution, just like you.  Note that I'm only
challenging bad or weak arguments of yours.

If you have a bad crash, you are as likely to lose libc as glib.  You must
have knoppix around anyway.

It's perfectly OK for programs to depend on many libraries.  There is
nothing inherently wrong with it.  Libraries allow code reuse.  They
allow separating of efforts between developers.  They don't make the
software less stable if certain versioning rules are followed.

I accept your argument that specifically GNU Midnight Commander should not
have too many dependencies because it can be used as a recovery tool.
It's just that the weight of this argument is not as significant as it
used to be.  The most widespread media for recovery tools is now a CD, not
a floppy disk.

On the other hand of the equation we have security, usability and
maintainability of GNU Midnight Commander under normal (i.e. not
emergency) conditions.  And they do profit from having a portable layer
between the code and libc.

Actually, I would be just as much concerned about gpm because it depends
on ncurses.  That's two libraries.  Remove any of them, and mc won't work.

> I would really like to go with the flow here. I know you are doing a
> great work on Midnight Commander and the majority of people are usually
> 'I go with the real thing' person and I do see the benefits that we work
> together to figure a good solution for this and I am not a friend of
> forks myself. 20 forks, all halfassed, half supported, left unmaintained
> after a while. There is no benefits.

As I said, I don't think the reason is glib.  The reason was GNOME.  If
the forks still exist, the reason is quality.  It's easy to fix many
problems, but it's not easy to fix the underlying problem, and that's what
I'm trying to do.  People who care about clock in the upper left corner
more than about use of uninitialized variables will keep their forks until
the hard stuff is fixed.

I'm not saying I'm doing enough.  Maybe I'm doing 20% of what should be
done.  But I know that if we reduce requirements on the quality, the code
will become mess once again.  Neither am I saying that my handling of the
situation is correct.  I'm just trying to do what I can.

Also, there was a misconception that glib depends on X11.  We cannot cater
to misconceptions - we are not politicians.

> I mean we are not going to change visible stuff to the user, or workflow
> relevant parts. We are only changing something in the bottom framework.
> It makes you happy, it makes me happy, it makes others happy and finally
> an MC with less dependencies. I even think that the uClibc people gonna
> thank you here because I do not belive that glib compiles against uClibc
> here.

I remember I did it in the past.  If you have any problems, please report
them to glib and uClibc developers.

> The embedded guys would probably be thankful using a most recent, active
> and alive project such as mc 4.6.0 on their embedded platforms or
> rescue systems.

I agree.

> I hope you see my point here.

Absolutely.

-- 
Regards,
Pavel Roskin