BitKeeper licence critic

[Jeroen Dekkers]

On Mon, Mar 18, 2002 at 09:41:34AM +0100, Joerg Schilling wrote:
> >From jeroen at dekkers.cx Sun Mar 17 14:13:56 2002
> 
> >> 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.
> 
> Let me give a simple example to you that your assumption makes no sense in the 
> real world:
> 
> There is a nasty bug in SunPRO make. If I would be able to fix it myself
> (I really am because it is easy to get Sun's sources) this would not help.
> It would force me to tell all users of my makefiles that they need to 
> use my fix what many of them probably don't like (the same would happen
> with GNU make). 
> 
> You see that while  can introduce workarounds in my makefile system, it makes
> no sense to fix the program myself.

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
can intergrate it in the actual package and all users of the package
gets the fix. This system works quite well. I think better than the
SUN system.

> >> 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.
> 
> Because they only use a small fractioction of what makes sense to do with
> make.

I guess you never looked at the Hurd and glibc makefiles.
 
> >> 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.
> 
> You don't understand that it does not make sense to to it yourself because
> the maintainers will not use your patches!

If you patch is right it won't be difficult to convince the maintainer
if the maintainer isn't an asshole!!
 
> I started to do this once with Linux and the /dev/sg* driver and I failed
> miserably because Alan Cox decided not to use my enhanced driver.

This is because Linux development sucks. And bitkeeper won't solve
that. Now we're back to the original discussion.

> >> 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.
> 
> It works perfect if you use a limited set of features. 

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

> I am using
> documented feeatures because I need them, I tell people that they either
> may usev GNU make, but because of the GNU make bugs they should not complain
> before they were able to reproduce a problem using my smake.

Is the thing which doesn't work in GNU make a documented feature?
 
> What is wrong with this way and why do you constantly tell people to do
> things that won't work in real world? 

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.

> >> 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 po=
> >rtable
> >> multi platform make system.
> 
> >Look at glibc. It's portable, it uses GNU make and it works correctly.
> 
> The person was talking about the way to create dependency files and I can tell
> you that the only method that works reliable in a multi platform environment
> is the method used in the schily makefile system and the method promoted
> by the FSF people is deprecated because it will result in overwritten
> files in a multi-platform environment. Maybe if the GCC people learn to 
> understand how to do it correctly inside GCC and there is no more old GCC
> outside I may switch to a better method for dependencies.

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.

> >> 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=20
> >> rule.
> 
> >And nobody with enough interest in GNU make needs this, so GNU make
> >doesn't do it.
> 
> ???
 
What's difficult to understand about this?

 
> >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.
> 
> 
> Well the authors of GDB restrict me because it is the only debugger available 
> on Linux and because I cannot do the things I expect a debugger to do.

Don't redefine restrict.
 
> >POSIX sucks more. It even contradicts itself. There are dozen of
> >broken things in it.
> 
> This is often heard by people like you, but they are getting quiet when
> it comes to making concrete examples.

Those people aren't like me. Don't try to make me look bad before I
have the chance to give an example.

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.
 
> >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.
> 
> 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.

Jeroen Dekkers
-- 
Jabber supporter - http://www.jabber.org Jabber ID: jdekkers at jabber.org
Debian GNU supporter - http://www.debian.org http://www.gnu.org
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: <http://lists.fsfe.org/pipermail/discussion/attachments/20020318/edd8f6c5/attachment.sig>