BitKeeper licence critic

Jeroen Dekkers jeroen at
Sun Mar 17 13:13:52 UTC 2002

On Sun, Mar 17, 2002 at 09:59:16AM +0100, Joerg Schilling wrote:
> >From jeroen at Sun Mar 17 04:02:59 2002
> >> >On Sat, Mar 16, 2002 at 04:44:41PM +0100, Joerg Schilling wrote:
> >> >> >From jeroen at Sat Mar 16 15:41:29 2002
> >> >> >Nice. Do you also fix the bugs in solaris if you find them?
> >> >>=3D20
> >> >> There are much much less bug then in Linux. If I find a bug, I report =
> >it.
> >>=20
> >> >And if they don't fix your reported bug? Or if it takes a month and
> >> >you want to get something done which triggers that bug?
> >>=20
> >> Well if it ets fixed in months on Solaris this is much much faster than=
> >=20
> >> on Linux or even other GNU tools.
> >For me it's just how long it takes to fix the bug.
> To make it easier to understand for you: those sort of bugs that gets fixed
> fast with Linux are not present on Solaris because Sun is doing a better job
> with testing. 

I do the testing myself. I fix the bug myself. That's possible because
I have the freedom to do so.

> The bugs that are fixed within months on Solaris are fixed within
> years on Linux. 

It's nice that we agree both agree that Linux sucks. But if I find a
bug in a package, I file a bugreport for the Debian package and if I
know how to fix it I include the patch. Depending on how busy the
maintainer of that package is and how critical the bug is, it can even
be fixed within days in Debian unstable.

> You are right: it _is_ important how fast bugs are fixed ;-)

Yes, that's why I fix the bugs myself if I can do so. I've the freedom
to do so with Debian. You don't have that with Solaris. You depend on
the willingness of some company. Poor you, that you've to wait a month
for a simple bugfix.
> >> GNU make bugs are not fixed in years too. GNU make is still handling=20
> >> 'include' statements wrong although I posted a bug report more than
> >> 3 years ago :-(
> >Did you include a patch? AFAIK I see you didn't. Reading the archives,
> Why should I spend my time on a badly written make program when I have my
> own make program that does what I like?

They don't complain about GNU make.

> You did not understand how software development works....

You don't understand that you can't force volunteers to do
something. If you want to see something, you've to do it yourself.

> If there is a simple problem that couls be fixed by anybody, it could be
> fixed in seconds by the original author. If there is a problem that 
> is hard to find because the structure of the program is bad (as with GNU make)
> then the original author is the only person who is able to fix the problem
> within a reasonable time.

And both of the original authors are too busy with more important
things than fixing this bug. One is the president of the FSF and
almost doesn't code anymore. The other author is also the author of
glibc and the Hurd, 2 things which have much more interesting things
than fixing that bug triggered by your use of makefiles.

> So you found the proof that the persons envolved with GNU make don't even
> understand how to use make decently.

I never have problems with GNU make. Nor do the authors of GNU make or
somebody else who wants to see it fixed. It works perfect, why should
we change it? Because it doesn't work perfect for YOU? Then YOU should
change it if you care about it. If you don't care about it, then
happily use your own make.

> In fact the method shown in this mail is deprecated and the only method
> that works correctly is the method I use in the Schily makefile system.
> Ifg somebody believes that dependencies must not be put into platform
> dependant sub directories he simply did not understand how to create a portable
> multi platform make system.

Look at glibc. It's portable, it uses GNU make and it works correctly.

> The basic rule for any make program is:
> 	try first to make anything before you try to use it.
> While GNU make does make the Makefile before using it (e.g. by retrieving
> it from SCCS) it does not make make files to be included even if there is a 
> rule.

And nobody with enough interest in GNU make needs this, so GNU make
doesn't do it.
> >I try to make the Hurd POSIX compliant. I don't develop Linux nor
> >GDB. If you want to see anything, you can always pay somebody to
> >implement it. It might be a better use of your money then buying
> >solaris licenses.
> I don't need to pay somebody to make GDB better because I get a better
> debugger for fre with Solaris. As I am sure that you don't have machines
> with >= 8 CPUs to do your development work, Solaris is free.
> Don't tell thigs you should know better.

Sorry, I don't have much knowledge about companies and software who
only like to restric me. Solaris might be free beer then, who cares.

> >> Tht GNUtar command line systax is not POSIX compliant _and_ it is much
> >> worse than the one from star.=20
> >POSIX compliant command line syntax sucks and isn't compatible with
> >the GNU Coding Standards. A nice free standard has a higher priority
> >for me than some crappy non-free standard.
> The GNU coding standard suck.

POSIX sucks more. It even contradicts itself. There are dozen of
broken things in it.
> >> I am usng star on a dayly base since 1984 (long before GNUtar exists).
> >I use GNU tar since I've started using tar. I never had any problems
> >with it other than that it doesn't support translators and or GNU
> >extensions to the filesystem.
> So you never received POSIX compliant tar archives and never did more
> than simple stuff with GNU tar.

AFAIK GNU tar makes POSIX compliant tars if you use the --posix
option. I've done enough stuff with GNU tar, but GNU/Linux and
GNU/Hurd are the only operating systems I use for real work.
> If you believe that mkisofs needs to be ported to HURD before you can
> send bug reports, then do it. The Schiloy makefile system is a easy to use
> portability framework. Just compile smake and then go forth...

Probably somebody else should do this. I don't care enough about it.

Jeroen Dekkers
Jabber supporter - Jabber ID: jdekkers at
Debian GNU supporter -
IRC: jeroen at openprojects
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <>

More information about the Discussion mailing list