Re: A proposal for Midnight Commander

[Koblinger Egmont <egmont uhulinux hu>]

On Sat, 15 Nov 2003, Ali Akcaagac wrote:

> Assuming that glib itself is free of bugs - which you can't depend on.

Neither is glibc.

> Excuse me, in case I may repeat myself half a dozen times now. There are
> no large significant parts inside Midnight Commander that justifies it
> to use Glib2. It's not like you are removing 2000 lines of code within
> Midnight Commander and have it replaced with 1 line Glib2 code. The
> memory allocation/free calls are a good example. While they may check
> whether they could allocate the memory or could even free NULL they have
> no significant benefits over the calls made by glibc or the g_strdup vs.
> strdup calls.

I exactly understand what you say, didn't say you're wrong in it. I agree
that _currently_ mc doesn't use glib too much, it would be easy to remove
glib stuff. I only disagree in the direction we should move to, I guess mc
should move intensively take advantage of glib, instead of manually
re-implementing everything in pure glibc.

> About Maintainance. If it wasn't possible to reduce all bugs until now
> after X years then something must have significant wrong. Maintainance
> of Glib2 on the otherhand makes you depend on other people. Say you
> detect a serious bug in Glib2 in an important function you use. You file
> [...]

Yes, there are bugs in glib1 and glib2. You may have bad experiences about
glib development. But, on the other hand, glib is a layer that hides OS
specific stuff, is able to workaround libc bugs, and provides a less
OS dependant interface.

There might be bugs in glib. You may report them. It's possible that it's
fixed within a few hours. It's also possible that it's not touch for many
months.

But what do you do if you find a bug in glibc? Have you seen their bug
tracking system? If you have, you wouldn't say any nasty words about gnome
people. Glibc maintenance is terrible.

I do have some bug reports pending both in the Gnome bugzilla and at the
glibc folks, so I do have experiences... glibc's bugtracker system (gnats)
has been down for many months when I reported my latest bug (I don't know
if it's back alive), so I sent it to their bug mailing list. I keep on
checking their archives. No reply, only 10 spam and 2 normal messages
every day in the archive. It's impossible to work with such a system.
Also see how often a new release of glib2 and glibc are out there, and how
much compatibility issue they bring in. (Do you remember all the errno
stuff with glibc 2.3.2 which broke many utilities building, and even broke
wine runtime? Compared to this, marking some glib2 function as deprecated
and removing them in one or two years is a fair thing.)

What if you find a bug in glib2 that makes mc misbehave? You document that
it's a glib bug, create a patch, put it into their bugzilla, and write in
the documentation that glib2 needs to be patches. What if you find such a
bug in libc? Do you tell the people to patch and recompile libc of
this-and-that-particular-unix-like-system?

So glib is IMHO no way worse than pure libc.


Every software has bugs. If mc uses glib, it increases the probability
that a glib bug will be caught, it'll be fixed and improve the quality of
other software as well.



-- 
Egmont