From jeroen@dekkers.cx Sun Mar 17 04:02:59 2002
On Sat, Mar 16, 2002 at 04:44:41PM +0100, Joerg Schilling wrote:
From jeroen@dekkers.cx 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. The bugs that are fixed within months on Solaris are fixed within years on Linux. You are right: it _is_ important how fast bugs are fixed ;-)
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?
You did not understand how software development works....
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.
So you found the proof that the persons envolved with GNU make don't even understand how to use make decently.
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.
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.
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.
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.
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.
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...
Jörg
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) If you don't have iso-8859-1 schilling@fokus.gmd.de (work) chars I am J"org Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
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 - www.berlios.de
On Sun, Mar 17, 2002 at 09:59:16AM +0100, Joerg Schilling wrote:
From jeroen@dekkers.cx Sun Mar 17 04:02:59 2002
On Sat, Mar 16, 2002 at 04:44:41PM +0100, Joerg Schilling wrote:
From jeroen@dekkers.cx 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