BitKeeper licence critic

Joerg Schilling schilling at
Tue Mar 19 08:28:11 UTC 2002

>From jeroen at Mon Mar 18 16:23:19 2002

>Do you want to know the way Debian works? You fix it yourself and tell
>the patch to the maintainer about it. The maintainer intergrates it
>and all users get the fix. As soon as the Debian maintainer
>intergrates the patch it's available in Debian unstable. Debian
>maintainers must forward patches upstream, so the upstream developers

Sorry, but I am forced to repeat me:

The Debian Bug list is badly managed (at least for cdrecord) and it does
not help to keep cdrecord bug-free. Tehy never removed remarks for bugs that
never exists but are a result of missunderstood or unread documentation.

>If you patch is right it won't be difficult to convince the maintainer
>if the maintainer isn't an asshole!!

So you just made a statement anbout the GNU make maintainer.
I send him a description for an algorithm that fiyes the problem and would
allow somebody who knows the program to create a fix in less than 3 hours.

>> It works perfect if you use a limited set of features.=20

>It doesn't work if you try to use a feature which it does *NOT* have.

Again: we are talking about dcumented features!

>> before they were able to reproduce a problem using my smake.

>Is the thing which doesn't work in GNU make a documented feature?

		Y E S 

>> What is wrong with this way and why do you constantly tell people to do
>> things that won't work in real world?=20

>If it works for you, then stop complaining about the bugs in GNU
>make. I only tell that if you have problems with GNU make you should
>fix them yourself. If you want to use another piece of software,
>happily do so. Just don't promote non-free software on this list which
>goes about free software.

You again start to reverse facts:

I stopped complaining about GNU make 3 years ago and don't take GNUmake 
for serious anymore. 

	YOU are the person who asked me to use the buggy GNU make and thus
	forced me to explain why I don't like this.

>What do you mean with "multi-platform environment"? According to my
>experience developping glibc parts the build system works fine. If you
>have suggestions to improve it you're always welcome of course.

	READ the schily makefile documentation!

I am talking about features of this system (e.g. untar the archive
and then fire up a 'make' on all supported platforms simultaneously
whithout the need to di more than just call 'make'):

>What's difficult to understand about this?

YOu have difficulties to understand, so you need to answer this
question yourself.

>> Well the authors of GDB restrict me because it is the only debugger avail=
>> on Linux and because I cannot do the things I expect a debugger to do.

>Don't redefine restrict.

I don't do it sorry but you sesm to fail to understand the meaning of the
word. GDB _is_ a restricted debugger because it has a limited set of
features that  restrict me when I try to use it.

>If you have a system when there isn't a limit on the path and PATH_MAX
>doesn't exist, realpath() doesn't work correctly then. You've no way
>to be sure the buffer doesn't overflow, it's even a security risk.

If PATH_MAX does not exist, then pathconf() must work to return the needed

>> Many GNU users have this wrong assumption, this is why I am more and more
>> angry with the people who wrote documentation tha makes users believe
>> untrue things about the GNU programs...

>I hope you aren't in the group of people who just named and can give
>an example of the POSIX incompatible thing when using tar with the
>--posix option.

All information you need is in the star distribution. I am sorry, but
I am at CeBIT and it takes too much time to constantly repeat facts
known and described since (at least) 1993....


 EMail:joerg at (home) Jörg Schilling D-13353 Berlin
       js at		(uni)  If you don't have iso-8859-1
       schilling at		(work) chars I am J"org Schilling
 FOKUS at CeBIT Hall 11, A14 - BerliOS at CeBIT Hall 11 D11 (Future Market)
 Meet me at CeBIT in Hall 11 D11 on the BerliOS booth -

More information about the Discussion mailing list