From jeroen@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.
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.
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!
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.
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. 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.
What is wrong with this way and why do you constantly tell people to do things that won't work in real world?
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.
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.
???
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.
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.
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...
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Joerg,
Hi :)
I'm working on replacements for all the gnu utilities, so I'd be grateful if you fill in a few details, and give me some recomondations...
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...
What would you say is wrong exactly? Excuse me for my ignorance... And why is it not fully POSIX compliant?
The trouble is that we are 'stuck' with backwards compatibility, and forwards compatibility. If we add features to programs, we then are no longer compatible with everyone else (everyone else being other NIX's, and people who don't use the latest-and-greatest)
This is good in some peoples books - after all everyone seems to be against 'bloat'. But for example I patched tar to auto detect compression - but it was of course a hated feature... ;)
JohnFlux
On Mon, 2002-03-18 at 09:41, Joerg Schilling wrote:
From jeroen@dekkers.cx Sun Mar 17 14:13:56 2002
You are getting a bit too far IMO Joerg. I respect you and also use your cdrecord (once every 6 months but still use it), but I have to partly disagree with most of your statemens lately. First of all I think cdrecord is a great software but you are a little too optimistic in thinking _most_ people use it. I know people that use it but not so much, I still know a lot of people that use linux and do not have a burner or prefer some windows based proprietary program for burning, however I'm not there to judge how used your program is, as it is a nonsense as we do not have any reliable statistical analisys on that, so please stop with this "mine is longer than yours stupid joke".
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.
Sorry you are wrong: - first: it does not make sense to even use a proprietary program but anyone is free to think the way she likes, you like free (as in beer) programs? ok, but do not take as grant that others here agree with you, most there will disagree with you as we like freedom, not free beer.
- second: in large free software projects patches from outher people are very welcome, I do not know your experiences, but you are wrong in thinking your personal development model is the one widely adopted in the rest of the free software world. In the main project I'm involved with (samba) patches are very welcome and we use and apply many many patches from contributors, plus we use gnu make and we do support many many platfroms (free and non-free), probably more than you do with cdrecord (even some non-posix platforms ports have been done and from people that made it on their own!)
They don't complain about GNU make.
Because they only use a small fractioction of what makes sense to do with make.
They use what they need! fullstop!
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!
You ARE wrong! I personally applied many patches to samba from others!
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.
Probably because it was poorely coded from Alan point of view, they are very selective and you took the worst project on the world (from this point of view) to make patches against.
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.
hmm I think you are wrong again here, my experience with samba tell me so. We use GNU make and I see no multi platform problems (take a look to http://build.samba.org to see how many different platfroms works ok! They are not all the platforms samba runs on, but only the platforms we have currently available in the build farm)
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.
???
He mean that your inclusion features are not included in GNU make because nobody need them, and you do not want to contribute code to make GNU make better. I do not want to say that GNU make is very good or that you should not use smake, if you are ok with smake I'm too, it's your choice, you are the developer, but generally in free software world, if you want to see a feature added to a program (GNU make) you either make a patch your self or contact the mainteiner and convince him it is a needed feature so that he can add it by itself. If you do not take either ways, please at least do not shout on other people work, you already said "code do not speak" (about the Hurd), I would like to say the same to you.
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.
You have a vrey strange idea of restriction and freedom IMO !
Work with people to improve GDB! If you do not care, please do not bother us telling to use proprietary debbugers, we will not do so!
regards, Simo.
On Mon, Mar 18, 2002 at 09:41:34AM +0100, Joerg Schilling wrote:
From jeroen@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
On Mon, Mar 18, 2002 at 09:41:34AM +0100, Joerg Schilling wrote:
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.
Besides the broken realpath() interface, there are two other deficiances which come to my mind immediately:
1. No way to get hold of the open file descriptors. This lead to poor work arounds like looping over all possible file descriptors and running close() on them before an exec(). This basically enforces that RLIMIT_NOFILE has a reasonably low soft limit (although the standard allows any arbitrary high value, even 2^31 - 1, which will break some apps). Note that close on exec is not a solution for a library that wants to call fork/exec.
2. No way to raise permissions, only to lower them. This has really hurt the Unix world in leading to very effect security holes, because daemons like ftp must run as root initally, before they can fork/exec, accept a connection and then lower permission. In the Hurd you can raise and lower permissions arbitrarily (you can even drop all permissions and run without any uids or gids).
You can call both defects of UNIX, and POSIX only documents them properly. I sometimes find confusing things or small typos etc in my POSIX draft, but I don't keep a list of those.
Thanks, Marcus