Re: cdrtools-2.01a22 ready
Joerg Schilling wrote: And this is definitely wrong! Unfortunately, Linux-2.6 did change iterfaces in a way so it is impossible to run all applications compiled under earlier releases. To avoid confusion you probably should say "not all applications... will run" since clearly you don't mean that NO applications will run. Or if you do you're totally wrong. -- E. Robert Bogusta It seemed like a good idea at the time
Re: cdrtools-2.01a22 ready
Joerg Schilling wrote: And this is definitely wrong! Unfortunately, Linux-2.6 did change iterfaces in a way so it is impossible to run all applications compiled under earlier releases. To avoid confusion you probably should say "not all applications... will run" since clearly you don't mean that NO applications will run. Or if you do you're totally wrong. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a22 ready
On Thu 8 January 2004 20:10, Scott Bronson wrote: > Arguing about MAY vs WILL and the proper use of a colon > is just a waste of time don't you think? How does any > of this noticeably impact _your_ life? Well, the original statement was false (at least IMHO, it seems we disagree a bit, about what the statement was, whether it was true, and about another zillion things that are somehow related :-), although we do seem to agree that some programs will work between kernel versions, and others won't). If someone acts on it and then posts here, then we'll have to help them solve the problem. Better to get it correct in the first place. As for the BerliOS advertisement, I've been looking at it for a long time now, and it just bugs me. If I'm promised new features, I want new features, not an advert. After all, I'm not watching television. Also, Jörg spends a lot of time and effort making cdrtools into a high-quality professional set of tools, and I think it's a shame that the presentation is the way it is. > Any chance this thread can be put to rest here? Well it is getting silly I guess, and I think everyone now basically believes the same thing, but we can't seem to convince one another that we all agree. Just letting it go doesn't seem like a bad idea really... Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Re: cdrtools-2.01a22 ready
On Thu, Jan 08, 2004 at 11:10:54AM -0800, Scott Bronson wrote: > Any chance this thread can be put to rest here? You could try invoking Godwin's Law
Re: cdrtools-2.01a22 ready
On Thu 8 January 2004 20:10, Scott Bronson wrote: > Arguing about MAY vs WILL and the proper use of a colon > is just a waste of time don't you think? How does any > of this noticeably impact _your_ life? Well, the original statement was false (at least IMHO, it seems we disagree a bit, about what the statement was, whether it was true, and about another zillion things that are somehow related :-), although we do seem to agree that some programs will work between kernel versions, and others won't). If someone acts on it and then posts here, then we'll have to help them solve the problem. Better to get it correct in the first place. As for the BerliOS advertisement, I've been looking at it for a long time now, and it just bugs me. If I'm promised new features, I want new features, not an advert. After all, I'm not watching television. Also, Jörg spends a lot of time and effort making cdrtools into a high-quality professional set of tools, and I think it's a shame that the presentation is the way it is. > Any chance this thread can be put to rest here? Well it is getting silly I guess, and I think everyone now basically believes the same thing, but we can't seem to convince one another that we all agree. Just letting it go doesn't seem like a bad idea really... Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a22 ready
On Thu, Jan 08, 2004 at 11:10:54AM -0800, Scott Bronson wrote: > Any chance this thread can be put to rest here? You could try invoking Godwin's Law -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a22 ready
Arguing about MAY vs WILL and the proper use of a colon is just a waste of time don't you think? How does any of this noticeably impact _your_ life? Any chance this thread can be put to rest here? On Thu, 2004-01-08 at 05:47, Lourens Veen wrote: > On Thu 8 January 2004 13:47, Joerg Schilling wrote: > > From [EMAIL PROTECTED] Wed Jan 7 16:34:14 2004 > > > > >> If you unpack this on a Linux-2.6 system using a "star" binary > > >> that has been compiled on Linux-2.4, you will extract a > > >> character special with minor 88 instead of minor 7000. > > >> > > >> This proves that you cannot run binaries from Linux-2.4 on > > >> Linux-2.6 correctly. > > > > > >Well, it proves that you cannot run _some_ binaries that were > > >compiled under linux 2.4 on linux 2.6 correctly. > > > > Well as you may easily read frm the mail to this thread, most > > people are unable to understand which programs would have such > > problems. For this reason, I did use a general warning. > > No, you did not. You said, and I quote (module formatting): > > "It has _always_ been wrong to compile software only once for > different kernel versions (e.g. for compile Linux-2.4 and later > install a 2.2 kernel on the so created system). > > Now that Linux-2.6 introduces incompatible changes to kernel/user > interfaces, the resulting binaries will not work correctly > anymore." > > You did not issue a warning, you said it was impossible, and that no > matter what kind of program it is, it will never work. As I said > before, you should either say that it _may_ not work for software > in general, or that it _will_ not work for cdrecord and star. > > > >Incidentally, your announcements are still a mess. I keep > > > thinking that the BerliOS Open Source center is a new feature > > > of cdrtools each time I read them. Advertisements should be at > > > the bottom. > > > > Well I could put the first line a bit lower, but I cannot > > understand that people could take the sentence starting with > > "Please have a look..." as an announcement for a new feature. > > Well, your first line reads: > > "NEW features of cdrtools-2.01a22:" > > Generally, a colon is followed by an enumeration of things > described. Hence, after reading the first line, I expect new > features of cdrtools, not an advertisement for BerliOS. It's rather > obvious that it is an advertisement, and not a description of a > cdrtools feature, but that doesn't make it any better. > > Lourens > -- > GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key >
Re: cdrtools-2.01a22 ready
On Thu, Jan 08, 2004 at 07:02:57PM +0100, Joerg Schilling wrote: > > >From: Matthias Schniedermeyer <[EMAIL PROTECTED]> > > >Take this "as given". > > > > >Same as you can assume that the libc of Solaris 9 is compiled on Solaris > >9 and is forward compatible to Solaris 8. > > Libc from Solaris 2.6 definitely does not work on Solaris 2.5.1 > Libc from Solaris 7 definitely does not work on Solaris 2.6 > Libc from Solaris 10 definitely does not work on Solaris 9 I said FORWARD compatible. Which means: A program compiled on Solaris 8 works on Solaris 9. Which should be true for system independend programs in 99% of the cases. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous.
Re: cdrtools-2.01a22 ready
On Thu, Jan 08, 2004 at 07:17:16PM +0100, Lourens Veen wrote: > On Thu 8 January 2004 18:42, Matthias Schniedermeyer wrote: > > On Thu, Jan 08, 2004 at 05:37:33PM +0100, Lourens Veen wrote: > > > On Thu 8 January 2004 17:07, Matthias Schniedermeyer wrote: > > > > On Thu, Jan 08, 2004 at 04:24:22PM +0100, Joerg Schilling > wrote: > > > > > It _is_ wrong to assume that a random program compiled for > > > > > OS revision A will run correctly on OS revision B > > > > > > > > Definetly NOT. > > > > > > > > e.g. "grep". > > > > > > Aaargh! > > > > > > Perhaps we should communicate in proposition logic instead af > > > English? Jörg is right, it is wrong to assume that any random > > > program compiled for OS revision A will run correctly on OS > > > revision B. If you disagree, you have to show that every single > > > possible program _will_ work, not just give one example. > > > > If you say it this way, then you even have to say: > > > > You can't assume that a random programm compiled for OS Revision > > A.0.0.0.0.0 will run correctly on OS revision A.0.0.0.0.1 > > > > They MAY be a subtle bug that prevents the 10thousands program to > > run correctly. > > Agreed. Ofcourse, if you start assuming that there are bugs, > anything might happen and the entire discussion is moot. Exactly. I would say: It is save to assume that a system independend program has a chance of 99% to work in the next Revision. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous.
Re: cdrtools-2.01a22 ready
>From: Matthias Schniedermeyer <[EMAIL PROTECTED]> >Take this "as given". >Same as you can assume that the libc of Solaris 9 is compiled on Solaris >9 and is forward compatible to Solaris 8. Libc from Solaris 2.6 definitely does not work on Solaris 2.5.1 Libc from Solaris 7 definitely does not work on Solaris 2.6 Libc from Solaris 10 definitely does not work on Solaris 9 For the other versions, I would need to spend too much time to check for differences Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am J"org Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
Re: cdrtools-2.01a22 ready
Arguing about MAY vs WILL and the proper use of a colon is just a waste of time don't you think? How does any of this noticeably impact _your_ life? Any chance this thread can be put to rest here? On Thu, 2004-01-08 at 05:47, Lourens Veen wrote: > On Thu 8 January 2004 13:47, Joerg Schilling wrote: > > From [EMAIL PROTECTED] Wed Jan 7 16:34:14 2004 > > > > >> If you unpack this on a Linux-2.6 system using a "star" binary > > >> that has been compiled on Linux-2.4, you will extract a > > >> character special with minor 88 instead of minor 7000. > > >> > > >> This proves that you cannot run binaries from Linux-2.4 on > > >> Linux-2.6 correctly. > > > > > >Well, it proves that you cannot run _some_ binaries that were > > >compiled under linux 2.4 on linux 2.6 correctly. > > > > Well as you may easily read frm the mail to this thread, most > > people are unable to understand which programs would have such > > problems. For this reason, I did use a general warning. > > No, you did not. You said, and I quote (module formatting): > > "It has _always_ been wrong to compile software only once for > different kernel versions (e.g. for compile Linux-2.4 and later > install a 2.2 kernel on the so created system). > > Now that Linux-2.6 introduces incompatible changes to kernel/user > interfaces, the resulting binaries will not work correctly > anymore." > > You did not issue a warning, you said it was impossible, and that no > matter what kind of program it is, it will never work. As I said > before, you should either say that it _may_ not work for software > in general, or that it _will_ not work for cdrecord and star. > > > >Incidentally, your announcements are still a mess. I keep > > > thinking that the BerliOS Open Source center is a new feature > > > of cdrtools each time I read them. Advertisements should be at > > > the bottom. > > > > Well I could put the first line a bit lower, but I cannot > > understand that people could take the sentence starting with > > "Please have a look..." as an announcement for a new feature. > > Well, your first line reads: > > "NEW features of cdrtools-2.01a22:" > > Generally, a colon is followed by an enumeration of things > described. Hence, after reading the first line, I expect new > features of cdrtools, not an advertisement for BerliOS. It's rather > obvious that it is an advertisement, and not a description of a > cdrtools feature, but that doesn't make it any better. > > Lourens > -- > GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a22 ready
On Thu 8 January 2004 18:42, Matthias Schniedermeyer wrote: > On Thu, Jan 08, 2004 at 05:37:33PM +0100, Lourens Veen wrote: > > On Thu 8 January 2004 17:07, Matthias Schniedermeyer wrote: > > > On Thu, Jan 08, 2004 at 04:24:22PM +0100, Joerg Schilling wrote: > > > > It _is_ wrong to assume that a random program compiled for > > > > OS revision A will run correctly on OS revision B > > > > > > Definetly NOT. > > > > > > e.g. "grep". > > > > Aaargh! > > > > Perhaps we should communicate in proposition logic instead af > > English? Jörg is right, it is wrong to assume that any random > > program compiled for OS revision A will run correctly on OS > > revision B. If you disagree, you have to show that every single > > possible program _will_ work, not just give one example. > > If you say it this way, then you even have to say: > > You can't assume that a random programm compiled for OS Revision > A.0.0.0.0.0 will run correctly on OS revision A.0.0.0.0.1 > > They MAY be a subtle bug that prevents the 10thousands program to > run correctly. Agreed. Ofcourse, if you start assuming that there are bugs, anything might happen and the entire discussion is moot. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Re: cdrtools-2.01a22 ready
On Thu, Jan 08, 2004 at 05:11:36PM +0100, Joerg Schilling wrote: > > >From: Matthias Schniedermeyer <[EMAIL PROTECTED]> > > >> It _is_ wrong to assume that a random program compiled for OS revision A > >> will run correctly on OS revision B > > >Definetly NOT. > > >e.g. "grep". > > >grep only uses libc-interface. As long as the program <-> libc interface > >is stable it will have no problem with the libc <-> site. > > >It is excatly THE job of libc to abstract away the "right" side. > >(Or the left when you assume hardware/kernel is leftmost) > > >Only "system dependend"(hardware, kernel interfaces, ..) software (e.g. > >cdrecord, star, ps, lspci, iptables) have this type of problem. > > Well of course libc too. This is something that people tend to forget. > > Who make sure that the libc that has been installed matched the current > kernel? Take this "as given". Same as you can assume that the libc of Solaris 9 is compiled on Solaris 9 and is forward compatible to Solaris 8. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous.
Re: cdrtools-2.01a22 ready
On Thu, Jan 08, 2004 at 07:02:57PM +0100, Joerg Schilling wrote: > > >From: Matthias Schniedermeyer <[EMAIL PROTECTED]> > > >Take this "as given". > > > > >Same as you can assume that the libc of Solaris 9 is compiled on Solaris > >9 and is forward compatible to Solaris 8. > > Libc from Solaris 2.6 definitely does not work on Solaris 2.5.1 > Libc from Solaris 7 definitely does not work on Solaris 2.6 > Libc from Solaris 10 definitely does not work on Solaris 9 I said FORWARD compatible. Which means: A program compiled on Solaris 8 works on Solaris 9. Which should be true for system independend programs in 99% of the cases. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a22 ready
On Thu, Jan 08, 2004 at 05:37:33PM +0100, Lourens Veen wrote: > On Thu 8 January 2004 17:07, Matthias Schniedermeyer wrote: > > On Thu, Jan 08, 2004 at 04:24:22PM +0100, Joerg Schilling wrote: > > > It _is_ wrong to assume that a random program compiled for OS > > > revision A will run correctly on OS revision B > > > > Definetly NOT. > > > > e.g. "grep". > > Aaargh! > > Perhaps we should communicate in proposition logic instead af > English? Jörg is right, it is wrong to assume that any random > program compiled for OS revision A will run correctly on OS > revision B. If you disagree, you have to show that every single > possible program _will_ work, not just give one example. If you say it this way, then you even have to say: You can't assume that a random programm compiled for OS Revision A.0.0.0.0.0 will run correctly on OS revision A.0.0.0.0.1 They MAY be a subtle bug that prevents the 10thousands program to run correctly. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous.
Re: cdrtools-2.01a22 ready
On Thu, Jan 08, 2004 at 07:17:16PM +0100, Lourens Veen wrote: > On Thu 8 January 2004 18:42, Matthias Schniedermeyer wrote: > > On Thu, Jan 08, 2004 at 05:37:33PM +0100, Lourens Veen wrote: > > > On Thu 8 January 2004 17:07, Matthias Schniedermeyer wrote: > > > > On Thu, Jan 08, 2004 at 04:24:22PM +0100, Joerg Schilling > wrote: > > > > > It _is_ wrong to assume that a random program compiled for > > > > > OS revision A will run correctly on OS revision B > > > > > > > > Definetly NOT. > > > > > > > > e.g. "grep". > > > > > > Aaargh! > > > > > > Perhaps we should communicate in proposition logic instead af > > > English? Jörg is right, it is wrong to assume that any random > > > program compiled for OS revision A will run correctly on OS > > > revision B. If you disagree, you have to show that every single > > > possible program _will_ work, not just give one example. > > > > If you say it this way, then you even have to say: > > > > You can't assume that a random programm compiled for OS Revision > > A.0.0.0.0.0 will run correctly on OS revision A.0.0.0.0.1 > > > > They MAY be a subtle bug that prevents the 10thousands program to > > run correctly. > > Agreed. Ofcourse, if you start assuming that there are bugs, > anything might happen and the entire discussion is moot. Exactly. I would say: It is save to assume that a system independend program has a chance of 99% to work in the next Revision. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a22 ready
>From: Matthias Schniedermeyer <[EMAIL PROTECTED]> >Take this "as given". >Same as you can assume that the libc of Solaris 9 is compiled on Solaris >9 and is forward compatible to Solaris 8. Libc from Solaris 2.6 definitely does not work on Solaris 2.5.1 Libc from Solaris 7 definitely does not work on Solaris 2.6 Libc from Solaris 10 definitely does not work on Solaris 9 For the other versions, I would need to spend too much time to check for differences Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am J"org Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a22 ready
On Thu 8 January 2004 18:42, Matthias Schniedermeyer wrote: > On Thu, Jan 08, 2004 at 05:37:33PM +0100, Lourens Veen wrote: > > On Thu 8 January 2004 17:07, Matthias Schniedermeyer wrote: > > > On Thu, Jan 08, 2004 at 04:24:22PM +0100, Joerg Schilling wrote: > > > > It _is_ wrong to assume that a random program compiled for > > > > OS revision A will run correctly on OS revision B > > > > > > Definetly NOT. > > > > > > e.g. "grep". > > > > Aaargh! > > > > Perhaps we should communicate in proposition logic instead af > > English? Jörg is right, it is wrong to assume that any random > > program compiled for OS revision A will run correctly on OS > > revision B. If you disagree, you have to show that every single > > possible program _will_ work, not just give one example. > > If you say it this way, then you even have to say: > > You can't assume that a random programm compiled for OS Revision > A.0.0.0.0.0 will run correctly on OS revision A.0.0.0.0.1 > > They MAY be a subtle bug that prevents the 10thousands program to > run correctly. Agreed. Ofcourse, if you start assuming that there are bugs, anything might happen and the entire discussion is moot. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a22 ready
On Thu, Jan 08, 2004 at 05:11:36PM +0100, Joerg Schilling wrote: > > >From: Matthias Schniedermeyer <[EMAIL PROTECTED]> > > >> It _is_ wrong to assume that a random program compiled for OS revision A > >> will run correctly on OS revision B > > >Definetly NOT. > > >e.g. "grep". > > >grep only uses libc-interface. As long as the program <-> libc interface > >is stable it will have no problem with the libc <-> site. > > >It is excatly THE job of libc to abstract away the "right" side. > >(Or the left when you assume hardware/kernel is leftmost) > > >Only "system dependend"(hardware, kernel interfaces, ..) software (e.g. > >cdrecord, star, ps, lspci, iptables) have this type of problem. > > Well of course libc too. This is something that people tend to forget. > > Who make sure that the libc that has been installed matched the current > kernel? Take this "as given". Same as you can assume that the libc of Solaris 9 is compiled on Solaris 9 and is forward compatible to Solaris 8. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a22 ready
On Thu, Jan 08, 2004 at 05:37:33PM +0100, Lourens Veen wrote: > On Thu 8 January 2004 17:07, Matthias Schniedermeyer wrote: > > On Thu, Jan 08, 2004 at 04:24:22PM +0100, Joerg Schilling wrote: > > > It _is_ wrong to assume that a random program compiled for OS > > > revision A will run correctly on OS revision B > > > > Definetly NOT. > > > > e.g. "grep". > > Aaargh! > > Perhaps we should communicate in proposition logic instead af > English? Jörg is right, it is wrong to assume that any random > program compiled for OS revision A will run correctly on OS > revision B. If you disagree, you have to show that every single > possible program _will_ work, not just give one example. If you say it this way, then you even have to say: You can't assume that a random programm compiled for OS Revision A.0.0.0.0.0 will run correctly on OS revision A.0.0.0.0.1 They MAY be a subtle bug that prevents the 10thousands program to run correctly. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a22 ready
>From: Matthias Schniedermeyer <[EMAIL PROTECTED]> >> It _is_ wrong to assume that a random program compiled for OS revision A >> will run correctly on OS revision B >Definetly NOT. >e.g. "grep". >grep only uses libc-interface. As long as the program <-> libc interface >is stable it will have no problem with the libc <-> site. >It is excatly THE job of libc to abstract away the "right" side. >(Or the left when you assume hardware/kernel is leftmost) >Only "system dependend"(hardware, kernel interfaces, ..) software (e.g. >cdrecord, star, ps, lspci, iptables) have this type of problem. Well of course libc too. This is something that people tend to forget. Who make sure that the libc that has been installed matched the current kernel? Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am J"org Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily .,
Re: cdrtools-2.01a22 ready
On Thu 8 January 2004 17:07, Matthias Schniedermeyer wrote: > On Thu, Jan 08, 2004 at 04:24:22PM +0100, Joerg Schilling wrote: > > It _is_ wrong to assume that a random program compiled for OS > > revision A will run correctly on OS revision B > > Definetly NOT. > > e.g. "grep". Aaargh! Perhaps we should communicate in proposition logic instead af English? Jörg is right, it is wrong to assume that any random program compiled for OS revision A will run correctly on OS revision B. If you disagree, you have to show that every single possible program _will_ work, not just give one example. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Re: cdrtools-2.01a22 ready
On Thu, Jan 08, 2004 at 04:24:22PM +0100, Joerg Schilling wrote: > It _is_ wrong to assume that a random program compiled for OS revision A > will run correctly on OS revision B Definetly NOT. e.g. "grep". grep only uses libc-interface. As long as the program <-> libc interface is stable it will have no problem with the libc <-> site. It is excatly THE job of libc to abstract away the "right" side. (Or the left when you assume hardware/kernel is leftmost) Only "system dependend"(hardware, kernel interfaces, ..) software (e.g. cdrecord, star, ps, lspci, iptables) have this type of problem. And btw. There is also a "binary" and "compile" compatiblity factor in this. e.g. libc6 aka glibc2 broke compatiblity with libc5 so A FEW programms needed patches to be COMPILABLE on new systems whereas (when the needed shared libraries where installed or the programm was static compiled) the libc5 binaries where still runable. Or in other words for >95% of all programms your statement is false! There is, always was and will ever be a small fraction of programs with this type of problem. The majority of software doesn't have this type of problem(s)! Or in other other words: It is wrong to assume that a random system dependend program compiled for OS revision A will run correctly on OS revision B for system. I have more other words: If Linux (for 2.8/3.0 whatever) would get incompatibel to every other Unix(type) OS AND to POSIX, BSD (and would need to drop glibc2). Then you can say what you have said. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous.
Re: cdrtools-2.01a22 ready
On Thu 8 January 2004 16:24, Joerg Schilling wrote: > From: Lourens Veen <[EMAIL PROTECTED]> > > >No, you did not. You said, and I quote (module formatting): > > > >"It has _always_ been wrong to compile software only once for > >different kernel versions (e.g. for compile Linux-2.4 and later > >install a 2.2 kernel on the so created system). > > Why do you repeat this? > > The current discussion proves that you cannot expect more than 1% > of the audience to understand the background. There is so much confusion in this thread that it's getting funny :-). > For this reason, it is better to write a general warning. > > It _is_ wrong to assume that a random program compiled for OS > revision A will run correctly on OS revision B Yes. I agree completely. My point is not that you _shouldn't_, my point is that you _didn't_. That is why I quoted you. Incidentally, you cut off the second part of that quote, which was really the problematic portion. This first part is fine. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Re: cdrtools-2.01a22 ready
>From: Lourens Veen <[EMAIL PROTECTED]> >No, you did not. You said, and I quote (module formatting): >"It has _always_ been wrong to compile software only once for >different kernel versions (e.g. for compile Linux-2.4 and later >install a 2.2 kernel on the so created system). Why do you repeat this? The current discussion proves that you cannot expect more than 1% of the audience to understand the background. For this reason, it is better to write a general warning. It _is_ wrong to assume that a random program compiled for OS revision A will run correctly on OS revision B Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am J"org Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
Re: cdrtools-2.01a22 ready
>From: Matthias Schniedermeyer <[EMAIL PROTECTED]> >> It _is_ wrong to assume that a random program compiled for OS revision A >> will run correctly on OS revision B >Definetly NOT. >e.g. "grep". >grep only uses libc-interface. As long as the program <-> libc interface >is stable it will have no problem with the libc <-> site. >It is excatly THE job of libc to abstract away the "right" side. >(Or the left when you assume hardware/kernel is leftmost) >Only "system dependend"(hardware, kernel interfaces, ..) software (e.g. >cdrecord, star, ps, lspci, iptables) have this type of problem. Well of course libc too. This is something that people tend to forget. Who make sure that the libc that has been installed matched the current kernel? Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am J"org Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily ., -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a22 ready
On Thu 8 January 2004 17:07, Matthias Schniedermeyer wrote: > On Thu, Jan 08, 2004 at 04:24:22PM +0100, Joerg Schilling wrote: > > It _is_ wrong to assume that a random program compiled for OS > > revision A will run correctly on OS revision B > > Definetly NOT. > > e.g. "grep". Aaargh! Perhaps we should communicate in proposition logic instead af English? Jörg is right, it is wrong to assume that any random program compiled for OS revision A will run correctly on OS revision B. If you disagree, you have to show that every single possible program _will_ work, not just give one example. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a22 ready
On Thu, Jan 08, 2004 at 04:24:22PM +0100, Joerg Schilling wrote: > It _is_ wrong to assume that a random program compiled for OS revision A > will run correctly on OS revision B Definetly NOT. e.g. "grep". grep only uses libc-interface. As long as the program <-> libc interface is stable it will have no problem with the libc <-> site. It is excatly THE job of libc to abstract away the "right" side. (Or the left when you assume hardware/kernel is leftmost) Only "system dependend"(hardware, kernel interfaces, ..) software (e.g. cdrecord, star, ps, lspci, iptables) have this type of problem. And btw. There is also a "binary" and "compile" compatiblity factor in this. e.g. libc6 aka glibc2 broke compatiblity with libc5 so A FEW programms needed patches to be COMPILABLE on new systems whereas (when the needed shared libraries where installed or the programm was static compiled) the libc5 binaries where still runable. Or in other words for >95% of all programms your statement is false! There is, always was and will ever be a small fraction of programs with this type of problem. The majority of software doesn't have this type of problem(s)! Or in other other words: It is wrong to assume that a random system dependend program compiled for OS revision A will run correctly on OS revision B for system. I have more other words: If Linux (for 2.8/3.0 whatever) would get incompatibel to every other Unix(type) OS AND to POSIX, BSD (and would need to drop glibc2). Then you can say what you have said. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a22 ready
On Thu 8 January 2004 16:24, Joerg Schilling wrote: > From: Lourens Veen <[EMAIL PROTECTED]> > > >No, you did not. You said, and I quote (module formatting): > > > >"It has _always_ been wrong to compile software only once for > >different kernel versions (e.g. for compile Linux-2.4 and later > >install a 2.2 kernel on the so created system). > > Why do you repeat this? > > The current discussion proves that you cannot expect more than 1% > of the audience to understand the background. There is so much confusion in this thread that it's getting funny :-). > For this reason, it is better to write a general warning. > > It _is_ wrong to assume that a random program compiled for OS > revision A will run correctly on OS revision B Yes. I agree completely. My point is not that you _shouldn't_, my point is that you _didn't_. That is why I quoted you. Incidentally, you cut off the second part of that quote, which was really the problematic portion. This first part is fine. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a22 ready
>From: Andy Polyakov <[EMAIL PROTECTED]> >> > star -tv < /tmp/cdev.tar.bz2 >> > ... >> > 255 7000 crw-r--r-- 1 root/other Jan 5 22:06 2004 cdev >> > >> > AS you see, this is a tar archive that includes a character >> > special with major 255 and minor 7000. >Postulate. Restoring of device entries from another architecture was >never guaranteed to provide meaningful results for following reasons: >- different platform allocate different amount of bits for major and >minor numbers, e.g. SVR3 specification reserves for 7 and 8 bits >respectively, SVR4 (e.g. Solaris and IRIX) - for 14/18, HP-UX - for >8/24, OSF - 12/20; >- restoring of devices from another platform can have undesirable effect >(imagine world writable /dev/null from another platform to coincide with >your system disk) and treated with special consideration or be avoided; Are you trying to open another unrelated thread or do you like to prove that you did not understand the current discusion? Nothing is wrong with calling: mknod cdev c 255 7000 on Linux-2.6 and for the same reason, it is completely legal to unpack the tar archive on Linux-2.6. How major()/minor() is handled is OS specific and the TAR archive does not contain any OS specifics. It does not make any sense to comment the rest of your text as it is completely unrelated to the problem. It seems that you just are unable or unwilling to admit that is is impossible to correctly use an star on Linux-2.6 if it has been compiled on Linux-2.4. Being able to use includes for me using all documented features and e.g. make backups and restores on the system. If you try to use an star compiled on 2.4 to make backups and restores on 2.6, then the device nodes may not be restored correctly, that's the problem! Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am J"org Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
Re: cdrtools-2.01a22 ready
>From: Lourens Veen <[EMAIL PROTECTED]> >No, you did not. You said, and I quote (module formatting): >"It has _always_ been wrong to compile software only once for >different kernel versions (e.g. for compile Linux-2.4 and later >install a 2.2 kernel on the so created system). Why do you repeat this? The current discussion proves that you cannot expect more than 1% of the audience to understand the background. For this reason, it is better to write a general warning. It _is_ wrong to assume that a random program compiled for OS revision A will run correctly on OS revision B Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am J"org Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a22 ready
>From: Andy Polyakov <[EMAIL PROTECTED]> >> > star -tv < /tmp/cdev.tar.bz2 >> > ... >> > 255 7000 crw-r--r-- 1 root/other Jan 5 22:06 2004 cdev >> > >> > AS you see, this is a tar archive that includes a character >> > special with major 255 and minor 7000. >Postulate. Restoring of device entries from another architecture was >never guaranteed to provide meaningful results for following reasons: >- different platform allocate different amount of bits for major and >minor numbers, e.g. SVR3 specification reserves for 7 and 8 bits >respectively, SVR4 (e.g. Solaris and IRIX) - for 14/18, HP-UX - for >8/24, OSF - 12/20; >- restoring of devices from another platform can have undesirable effect >(imagine world writable /dev/null from another platform to coincide with >your system disk) and treated with special consideration or be avoided; Are you trying to open another unrelated thread or do you like to prove that you did not understand the current discusion? Nothing is wrong with calling: mknod cdev c 255 7000 on Linux-2.6 and for the same reason, it is completely legal to unpack the tar archive on Linux-2.6. How major()/minor() is handled is OS specific and the TAR archive does not contain any OS specifics. It does not make any sense to comment the rest of your text as it is completely unrelated to the problem. It seems that you just are unable or unwilling to admit that is is impossible to correctly use an star on Linux-2.6 if it has been compiled on Linux-2.4. Being able to use includes for me using all documented features and e.g. make backups and restores on the system. If you try to use an star compiled on 2.4 to make backups and restores on 2.6, then the device nodes may not be restored correctly, that's the problem! Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am J"org Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a22 ready
On Thu 8 January 2004 13:47, Joerg Schilling wrote: > From [EMAIL PROTECTED] Wed Jan 7 16:34:14 2004 > > >> If you unpack this on a Linux-2.6 system using a "star" binary > >> that has been compiled on Linux-2.4, you will extract a > >> character special with minor 88 instead of minor 7000. > >> > >> This proves that you cannot run binaries from Linux-2.4 on > >> Linux-2.6 correctly. > > > >Well, it proves that you cannot run _some_ binaries that were > >compiled under linux 2.4 on linux 2.6 correctly. > > Well as you may easily read frm the mail to this thread, most > people are unable to understand which programs would have such > problems. For this reason, I did use a general warning. No, you did not. You said, and I quote (module formatting): "It has _always_ been wrong to compile software only once for different kernel versions (e.g. for compile Linux-2.4 and later install a 2.2 kernel on the so created system). Now that Linux-2.6 introduces incompatible changes to kernel/user interfaces, the resulting binaries will not work correctly anymore." You did not issue a warning, you said it was impossible, and that no matter what kind of program it is, it will never work. As I said before, you should either say that it _may_ not work for software in general, or that it _will_ not work for cdrecord and star. > >Incidentally, your announcements are still a mess. I keep > > thinking that the BerliOS Open Source center is a new feature > > of cdrtools each time I read them. Advertisements should be at > > the bottom. > > Well I could put the first line a bit lower, but I cannot > understand that people could take the sentence starting with > "Please have a look..." as an announcement for a new feature. Well, your first line reads: "NEW features of cdrtools-2.01a22:" Generally, a colon is followed by an enumeration of things described. Hence, after reading the first line, I expect new features of cdrtools, not an advertisement for BerliOS. It's rather obvious that it is an advertisement, and not a description of a cdrtools feature, but that doesn't make it any better. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Re: cdrtools-2.01a22 ready
>From [EMAIL PROTECTED] Wed Jan 7 16:34:14 2004
>> If you unpack this on a Linux-2.6 system using a "star" binary
>> that has been compiled on Linux-2.4, you will extract a character
>> special with minor 88 instead of minor 7000.
>>
>> This proves that you cannot run binaries from Linux-2.4 on
>> Linux-2.6 correctly.
>Well, it proves that you cannot run _some_ binaries that were
>compiled under linux 2.4 on linux 2.6 correctly.
Well as you may easily read frm the mail to this thread, most people
are unable to understand which programs would have such problems.
For this reason, I did use a general warning.
>> 3) Interfaces that libc is not even aware of (like ioctl()
>> functions). If major()/minor()/makedev() are CPP macros and not
>> functions in libc, then they are part of this group of
>> interfaces.
>Not necessarily. If the macros only call functions in libc, then
>they're in category 1. But I see your point.
Well, in Solaris this is true for at least 12 years:
#define OLDDEV 0/* old device format */
#define NEWDEV 1/* new device format */
#define makedev(maj, min) (__makedev(NEWDEV, maj, min))
#define major(dev) (__major(NEWDEV, dev))
#define minor(dev) (__minor(NEWDEV, dev))
...
>> Star with respect to device major/minor handling is another one.
>>
>> There are most likely a lot more user land applications that will
>> observe incompatibilities from changes in the Linux kernel
>> interfaces.
>Ofcourse, but are they a majority? There aren't that many programs
>that talk directly to hardware. There aren't that many programs
>that create device files. This email program manages some files on
Do you _really_ know if the major()/minor()/makedev() change introduced
the _only_ incompatibility?
>I could live with "Do not use cdrtools on a different kernel than it
>was compiled against" or even "I don't recommend using software
>with a different kernel than it was compiled under". Simply stating
>that it will never work...well, try this:
>#include
>int main()
>{
> printf("Hello, world!\n");
>}
>Compile under 2.4, run under 2.6. I'm sure it'll work fine, because
>it falls in your category 1 above.
There is a general rule that is many many years old:
If you like to run a binary on differen OS versions, compile on the oldest
and make decent tests to verify of there are problems.
As the program above calls ioctl() and other OS dependent interfaces,
you cannot grant that it will work.
>Incidentally, your announcements are still a mess. I keep thinking
>that the BerliOS Open Source center is a new feature of cdrtools
>each time I read them. Advertisements should be at the bottom.
Well I could put the first line a bit lower, but I cannot understand that
people could take the sentence starting with "Please have a look..."
as an announcement for a new feature.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni) If you don't have iso-8859-1
[EMAIL PROTECTED](work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling
ftp://ftp.berlios.de/pub/schily
Re: cdrtools-2.01a22 ready
On Thu 8 January 2004 13:47, Joerg Schilling wrote: > From [EMAIL PROTECTED] Wed Jan 7 16:34:14 2004 > > >> If you unpack this on a Linux-2.6 system using a "star" binary > >> that has been compiled on Linux-2.4, you will extract a > >> character special with minor 88 instead of minor 7000. > >> > >> This proves that you cannot run binaries from Linux-2.4 on > >> Linux-2.6 correctly. > > > >Well, it proves that you cannot run _some_ binaries that were > >compiled under linux 2.4 on linux 2.6 correctly. > > Well as you may easily read frm the mail to this thread, most > people are unable to understand which programs would have such > problems. For this reason, I did use a general warning. No, you did not. You said, and I quote (module formatting): "It has _always_ been wrong to compile software only once for different kernel versions (e.g. for compile Linux-2.4 and later install a 2.2 kernel on the so created system). Now that Linux-2.6 introduces incompatible changes to kernel/user interfaces, the resulting binaries will not work correctly anymore." You did not issue a warning, you said it was impossible, and that no matter what kind of program it is, it will never work. As I said before, you should either say that it _may_ not work for software in general, or that it _will_ not work for cdrecord and star. > >Incidentally, your announcements are still a mess. I keep > > thinking that the BerliOS Open Source center is a new feature > > of cdrtools each time I read them. Advertisements should be at > > the bottom. > > Well I could put the first line a bit lower, but I cannot > understand that people could take the sentence starting with > "Please have a look..." as an announcement for a new feature. Well, your first line reads: "NEW features of cdrtools-2.01a22:" Generally, a colon is followed by an enumeration of things described. Hence, after reading the first line, I expect new features of cdrtools, not an advertisement for BerliOS. It's rather obvious that it is an advertisement, and not a description of a cdrtools feature, but that doesn't make it any better. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a22 ready
>From [EMAIL PROTECTED] Wed Jan 7 16:34:14 2004
>> If you unpack this on a Linux-2.6 system using a "star" binary
>> that has been compiled on Linux-2.4, you will extract a character
>> special with minor 88 instead of minor 7000.
>>
>> This proves that you cannot run binaries from Linux-2.4 on
>> Linux-2.6 correctly.
>Well, it proves that you cannot run _some_ binaries that were
>compiled under linux 2.4 on linux 2.6 correctly.
Well as you may easily read frm the mail to this thread, most people
are unable to understand which programs would have such problems.
For this reason, I did use a general warning.
>> 3) Interfaces that libc is not even aware of (like ioctl()
>> functions). If major()/minor()/makedev() are CPP macros and not
>> functions in libc, then they are part of this group of
>> interfaces.
>Not necessarily. If the macros only call functions in libc, then
>they're in category 1. But I see your point.
Well, in Solaris this is true for at least 12 years:
#define OLDDEV 0/* old device format */
#define NEWDEV 1/* new device format */
#define makedev(maj, min) (__makedev(NEWDEV, maj, min))
#define major(dev) (__major(NEWDEV, dev))
#define minor(dev) (__minor(NEWDEV, dev))
...
>> Star with respect to device major/minor handling is another one.
>>
>> There are most likely a lot more user land applications that will
>> observe incompatibilities from changes in the Linux kernel
>> interfaces.
>Ofcourse, but are they a majority? There aren't that many programs
>that talk directly to hardware. There aren't that many programs
>that create device files. This email program manages some files on
Do you _really_ know if the major()/minor()/makedev() change introduced
the _only_ incompatibility?
>I could live with "Do not use cdrtools on a different kernel than it
>was compiled against" or even "I don't recommend using software
>with a different kernel than it was compiled under". Simply stating
>that it will never work...well, try this:
>#include
>int main()
>{
> printf("Hello, world!\n");
>}
>Compile under 2.4, run under 2.6. I'm sure it'll work fine, because
>it falls in your category 1 above.
There is a general rule that is many many years old:
If you like to run a binary on differen OS versions, compile on the oldest
and make decent tests to verify of there are problems.
As the program above calls ioctl() and other OS dependent interfaces,
you cannot grant that it will work.
>Incidentally, your announcements are still a mess. I keep thinking
>that the BerliOS Open Source center is a new feature of cdrtools
>each time I read them. Advertisements should be at the bottom.
Well I could put the first line a bit lower, but I cannot understand that
people could take the sentence starting with "Please have a look..."
as an announcement for a new feature.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni) If you don't have iso-8859-1
[EMAIL PROTECTED](work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a22 ready
> > star -tv < /tmp/cdev.tar.bz2 > > ... > > 255 7000 crw-r--r-- 1 root/other Jan 5 22:06 2004 cdev > > > > AS you see, this is a tar archive that includes a character > > special with major 255 and minor 7000. Postulate. Restoring of device entries from another architecture was never guaranteed to provide meaningful results for following reasons: - different platform allocate different amount of bits for major and minor numbers, e.g. SVR3 specification reserves for 7 and 8 bits respectively, SVR4 (e.g. Solaris and IRIX) - for 14/18, HP-UX - for 8/24, OSF - 12/20; - restoring of devices from another platform can have undesirable effect (imagine world writable /dev/null from another platform to coincide with your system disk) and treated with special consideration or be avoided; First bullet above means that multi-platform achiever *might have to*/should take into consideration differences between platforms and act accordingly, at least warning user about possibly unexpected results, optionally trying to note actual inconsistencies. > > If you unpack this on a Linux-2.6 system using a "star" binary > > that has been compiled on Linux-2.4, you will extract a character > > special with minor 88 instead of minor 7000. Yes. But the result is not guaranteed to be sane in *either* case. You can't really complain about something being broken if it's not guaranteed to be intact. The only thing which is quaranteed to be meaningful for device entries is pack-unpack on *same* platform. And this works perfectly in either combination. Compile "2.6 binary" and pack-unpack devices under 2.4 kernel. Does it work? Yes! Compile "2.4 binary" and pack-unpack devices under 2.6 kernel. Does it work? Yes, as long as you pack-unpack those created by Linux /etc/MAKEDEV. Is there 2.6-specific /etc/MAKEDEV? Not currently. Will there be one? Unlikely. First extended namespace user is devpts, "memory-based" *file system* and there are all reasons to believe it will remain "memory-based" file systems' domain. Note that I wrote "2.6 binary" and "2.4 binary" in quotes! Why? Because there're *no* such things as "2.6" or "2.4" binaries! There're glibc 2.3 and glibc 2<3 ones! Linux 2.6 kernel does not actually require glibc 2.3 for operation. Nor does glibc 2.3 require Linux 2.6 kernel. glibc 2.3 is required for 2.6 in some particular cases. This one is included: restoring of device entries from *another* architecture [which in turn has pure academic value in either case]. > > This proves that you cannot run binaries from Linux-2.4 on > > Linux-2.6 correctly. Once again, result is not guaranteed to be sane, the result is expected to be unexpected and the only right thing to do is to make best of the situation! That's what multi-platform programming is/should be about. > Well, it proves that you cannot run _some_ binaries that were > compiled under linux 2.4 on linux 2.6 correctly. Linux 2.4 provided 8 bits for major and 8 bits - for minor numbers, 2.6 extends it to 12/20, but it does this in backward compatible way! Can application developers *deny* the fact that Linux kernel 2.6 provides larger device namespace? No, application developers should be aware of it and should respect it. Can applications be modified to produce result with makes most sense in current run-time environment? Absolutely yes. Should they be? Multi-platform ones, yes. Now note "2.6 extends device namespace in backward compatible way." Does it? Yes! Yet programs using makedev will get broken? How come and when? Is it kernel issue? No! It's glibc 2<3 bug, makedev macro in particular. The macro should have been ((major&0xff)<<8)|(minor&0xff). What should glibc 2.3 archiver do to make best of situation and be runnable under both 2.6 and 2.4 kernels? It should modify device verification procedure and mask 16 least significant bits, when st_rdev doesn't match, e.g. 'if (s.st_rdev != makedev(a,b) && s.st_rdev != (makedev(a,b)&0x) verification_failed();' Can such archiver program be modified to be compilable for glibc 2<3 and make best of run-time environment? Yes! E.g. by redefining the makedev macro you at least can provide more consistent over major device numbers. Of course modification procedure has to be modified too. To summarize. To make the program in question glibc 2<3 vs. glibc 2.3 aware *and* safe to execute under either Linux 2.4 and 2.6 kernels in either combination, one could modify it as following. 1. *Whenever* minor number is to be used in makedev macro, it can be screened as "if (makedev(2,0x100)==0x300) minor&=0xFF;" Note that this operator doesn't have to be #ifdef __linux-ed or autodetected by a configure procedure. Also note that "if" will most likely be optimized away at compile time. 2. Whenever restored device number is to be verified, I would go for dev_t devcompare; ... devcompare = s.st_rdev ^ makedev(major,minor); if (devcompare && devcompare&0x) verification_failed(); Yes, mi
Re: cdrtools-2.01a22 ready
> > star -tv < /tmp/cdev.tar.bz2 > > ... > > 255 7000 crw-r--r-- 1 root/other Jan 5 22:06 2004 cdev > > > > AS you see, this is a tar archive that includes a character > > special with major 255 and minor 7000. Postulate. Restoring of device entries from another architecture was never guaranteed to provide meaningful results for following reasons: - different platform allocate different amount of bits for major and minor numbers, e.g. SVR3 specification reserves for 7 and 8 bits respectively, SVR4 (e.g. Solaris and IRIX) - for 14/18, HP-UX - for 8/24, OSF - 12/20; - restoring of devices from another platform can have undesirable effect (imagine world writable /dev/null from another platform to coincide with your system disk) and treated with special consideration or be avoided; First bullet above means that multi-platform achiever *might have to*/should take into consideration differences between platforms and act accordingly, at least warning user about possibly unexpected results, optionally trying to note actual inconsistencies. > > If you unpack this on a Linux-2.6 system using a "star" binary > > that has been compiled on Linux-2.4, you will extract a character > > special with minor 88 instead of minor 7000. Yes. But the result is not guaranteed to be sane in *either* case. You can't really complain about something being broken if it's not guaranteed to be intact. The only thing which is quaranteed to be meaningful for device entries is pack-unpack on *same* platform. And this works perfectly in either combination. Compile "2.6 binary" and pack-unpack devices under 2.4 kernel. Does it work? Yes! Compile "2.4 binary" and pack-unpack devices under 2.6 kernel. Does it work? Yes, as long as you pack-unpack those created by Linux /etc/MAKEDEV. Is there 2.6-specific /etc/MAKEDEV? Not currently. Will there be one? Unlikely. First extended namespace user is devpts, "memory-based" *file system* and there are all reasons to believe it will remain "memory-based" file systems' domain. Note that I wrote "2.6 binary" and "2.4 binary" in quotes! Why? Because there're *no* such things as "2.6" or "2.4" binaries! There're glibc 2.3 and glibc 2<3 ones! Linux 2.6 kernel does not actually require glibc 2.3 for operation. Nor does glibc 2.3 require Linux 2.6 kernel. glibc 2.3 is required for 2.6 in some particular cases. This one is included: restoring of device entries from *another* architecture [which in turn has pure academic value in either case]. > > This proves that you cannot run binaries from Linux-2.4 on > > Linux-2.6 correctly. Once again, result is not guaranteed to be sane, the result is expected to be unexpected and the only right thing to do is to make best of the situation! That's what multi-platform programming is/should be about. > Well, it proves that you cannot run _some_ binaries that were > compiled under linux 2.4 on linux 2.6 correctly. Linux 2.4 provided 8 bits for major and 8 bits - for minor numbers, 2.6 extends it to 12/20, but it does this in backward compatible way! Can application developers *deny* the fact that Linux kernel 2.6 provides larger device namespace? No, application developers should be aware of it and should respect it. Can applications be modified to produce result with makes most sense in current run-time environment? Absolutely yes. Should they be? Multi-platform ones, yes. Now note "2.6 extends device namespace in backward compatible way." Does it? Yes! Yet programs using makedev will get broken? How come and when? Is it kernel issue? No! It's glibc 2<3 bug, makedev macro in particular. The macro should have been ((major&0xff)<<8)|(minor&0xff). What should glibc 2.3 archiver do to make best of situation and be runnable under both 2.6 and 2.4 kernels? It should modify device verification procedure and mask 16 least significant bits, when st_rdev doesn't match, e.g. 'if (s.st_rdev != makedev(a,b) && s.st_rdev != (makedev(a,b)&0x) verification_failed();' Can such archiver program be modified to be compilable for glibc 2<3 and make best of run-time environment? Yes! E.g. by redefining the makedev macro you at least can provide more consistent over major device numbers. Of course modification procedure has to be modified too. To summarize. To make the program in question glibc 2<3 vs. glibc 2.3 aware *and* safe to execute under either Linux 2.4 and 2.6 kernels in either combination, one could modify it as following. 1. *Whenever* minor number is to be used in makedev macro, it can be screened as "if (makedev(2,0x100)==0x300) minor&=0xFF;" Note that this operator doesn't have to be #ifdef __linux-ed or autodetected by a configure procedure. Also note that "if" will most likely be optimized away at compile time. 2. Whenever restored device number is to be verified, I would go for dev_t devcompare; ... devcompare = s.st_rdev ^ makedev(major,minor); if (devcompare && devcompare&0x) verification_failed(); Yes, mi
Re: cdrtools-2.01a22 ready
On Wed 7 January 2004 11:37, Joerg Schilling wrote:
>
> For all people who have enough background knowledge in software
> engineering, here is a text that I did write for another purpose:
>
> /*---
>---*/
>
> star -tv < /tmp/cdev.tar.bz2
> star: WARNING: Archive is 'bzip2' compressed, trying to
> use the -bz option.
> star: Blocksize = 7 records.
> Release star 1.5a35 (i386-pc-solaris2.9)
> Archtypeexustar
> Dumpdate1073336802.243055000 (Mon Jan 5 22:06:42 2004)
> Volno 1
> Blocksize 20
> 255 7000 crw-r--r-- 1 root/other Jan 5 22:06 2004 cdev
> star: 1 blocks + 0 bytes (total of 3584 bytes = 3.50k).
>
> AS you see, this is a tar archive that includes a character
> special with major 255 and minor 7000. You can list the correct
> major/minor numbers on any OS if you use star -tv, as the content
> of the tar archive is kernel interface independent.
>
> If you unpack this on a Linux-2.6 system using a "star" binary
> that has been compiled on Linux-2.4, you will extract a character
> special with minor 88 instead of minor 7000.
>
> This proves that you cannot run binaries from Linux-2.4 on
> Linux-2.6 correctly.
Well, it proves that you cannot run _some_ binaries that were
compiled under linux 2.4 on linux 2.6 correctly.
> If you compile on Linux-2.6, there is a big chance that the
> autoconf run will detect interfaces that are not present on
> Linux-2.4, so trying the other direction will most likely give
> just other problems.
>
>
> I am sorry, but the current work on the Linux kernel is
> overshadowed by severe missunderstandings. Linus and other people
> from LKML seem to be unable to understand how interfaces work.
>
> Let me explain it to you. There are three types of interfaces,
> you can see in libc and /usr/include/*:
>
> 1)Interfaces that are fully created by libc, such as strcpy()
>
> 2)Interfaces that are defined by the kernel but propagated by
> libc. Interfaces of this type are things similar to
> open()/read()/write(),..
>
> 3)Interfaces that libc is not even aware of (like ioctl()
> functions). If major()/minor()/makedev() are CPP macros and not
> functions in libc, then they are part of this group of
> interfaces.
Not necessarily. If the macros only call functions in libc, then
they're in category 1. But I see your point.
> Interfaces of type 1) are independent of the kernel and for this
> reason, the statements from Linus on how (from his belief)
> include files should be treatened apply _only_ to these
> interfaces.
> To allow an application to match the interface, you need an
> include file that is published by the same instance or person who
> does work on libc.
>
> Interfaces of type 2) require that libc and the kernel version
> match. This means, that you need to recompile and in some cases
> even to modify the libc sources in order to get a working
> complete system every time the kernel interface (used by libc)
> changes. This is needed to keep the upper level interface from
> libc stable.
>
> Interfaces of type 3) are independent of libc!
> Any application that likes to use them, _needs_ to use the
> include files from the kernel they are going to be run on. This
> is the only way, to make sure that the user level application
> uses an interface that matches the adjacent interface from the
> kernel. If you use different include files, you are unable to
> even test the kernel interface. For this reason, it is important
> that all include files from the kernel (that define interfaces
> that are visible from user land) are written in a way that allows
> a consistent usage from a user land application (which does never
> #define __KERNEL or similar).
>
> Cdrecord is definitely a user land application that needs to be
> compiled with the include files from the current kernel -
> otherwise it could not e.g. use new features from SCSI drivers
> inside the kernel.
>
>
> Star with respect to device major/minor handling is another one.
>
> There are most likely a lot more user land applications that will
> observe incompatibilities from changes in the Linux kernel
> interfaces.
Ofcourse, but are they a majority? There aren't that many programs
that talk directly to hardware. There aren't that many programs
that create device files. This email program manages some files on
the disk and it makes some network connections and that's it. Other
office software likely doesn't do this either. And audio and video
servers such as MAS or X abstract away from the hardware, so that
client programs don't use the kernel interface directly either.
I could live with "Do not use cdrtools on a different kernel than it
was compiled against" or even "I don't recommend using software
with a different kernel than it was compiled under". Simply stating
that it will never work...well, try this:
#include
int main()
{
printf("Hello, world!\n");
}
Compile under 2.4, run under 2.6. I'm sure
Re: cdrtools-2.01a22 ready
On Wed 7 January 2004 11:37, Joerg Schilling wrote:
>
> For all people who have enough background knowledge in software
> engineering, here is a text that I did write for another purpose:
>
> /*---
>---*/
>
> star -tv < /tmp/cdev.tar.bz2
> star: WARNING: Archive is 'bzip2' compressed, trying to
> use the -bz option.
> star: Blocksize = 7 records.
> Release star 1.5a35 (i386-pc-solaris2.9)
> Archtypeexustar
> Dumpdate1073336802.243055000 (Mon Jan 5 22:06:42 2004)
> Volno 1
> Blocksize 20
> 255 7000 crw-r--r-- 1 root/other Jan 5 22:06 2004 cdev
> star: 1 blocks + 0 bytes (total of 3584 bytes = 3.50k).
>
> AS you see, this is a tar archive that includes a character
> special with major 255 and minor 7000. You can list the correct
> major/minor numbers on any OS if you use star -tv, as the content
> of the tar archive is kernel interface independent.
>
> If you unpack this on a Linux-2.6 system using a "star" binary
> that has been compiled on Linux-2.4, you will extract a character
> special with minor 88 instead of minor 7000.
>
> This proves that you cannot run binaries from Linux-2.4 on
> Linux-2.6 correctly.
Well, it proves that you cannot run _some_ binaries that were
compiled under linux 2.4 on linux 2.6 correctly.
> If you compile on Linux-2.6, there is a big chance that the
> autoconf run will detect interfaces that are not present on
> Linux-2.4, so trying the other direction will most likely give
> just other problems.
>
>
> I am sorry, but the current work on the Linux kernel is
> overshadowed by severe missunderstandings. Linus and other people
> from LKML seem to be unable to understand how interfaces work.
>
> Let me explain it to you. There are three types of interfaces,
> you can see in libc and /usr/include/*:
>
> 1)Interfaces that are fully created by libc, such as strcpy()
>
> 2)Interfaces that are defined by the kernel but propagated by
> libc. Interfaces of this type are things similar to
> open()/read()/write(),..
>
> 3)Interfaces that libc is not even aware of (like ioctl()
> functions). If major()/minor()/makedev() are CPP macros and not
> functions in libc, then they are part of this group of
> interfaces.
Not necessarily. If the macros only call functions in libc, then
they're in category 1. But I see your point.
> Interfaces of type 1) are independent of the kernel and for this
> reason, the statements from Linus on how (from his belief)
> include files should be treatened apply _only_ to these
> interfaces.
> To allow an application to match the interface, you need an
> include file that is published by the same instance or person who
> does work on libc.
>
> Interfaces of type 2) require that libc and the kernel version
> match. This means, that you need to recompile and in some cases
> even to modify the libc sources in order to get a working
> complete system every time the kernel interface (used by libc)
> changes. This is needed to keep the upper level interface from
> libc stable.
>
> Interfaces of type 3) are independent of libc!
> Any application that likes to use them, _needs_ to use the
> include files from the kernel they are going to be run on. This
> is the only way, to make sure that the user level application
> uses an interface that matches the adjacent interface from the
> kernel. If you use different include files, you are unable to
> even test the kernel interface. For this reason, it is important
> that all include files from the kernel (that define interfaces
> that are visible from user land) are written in a way that allows
> a consistent usage from a user land application (which does never
> #define __KERNEL or similar).
>
> Cdrecord is definitely a user land application that needs to be
> compiled with the include files from the current kernel -
> otherwise it could not e.g. use new features from SCSI drivers
> inside the kernel.
>
>
> Star with respect to device major/minor handling is another one.
>
> There are most likely a lot more user land applications that will
> observe incompatibilities from changes in the Linux kernel
> interfaces.
Ofcourse, but are they a majority? There aren't that many programs
that talk directly to hardware. There aren't that many programs
that create device files. This email program manages some files on
the disk and it makes some network connections and that's it. Other
office software likely doesn't do this either. And audio and video
servers such as MAS or X abstract away from the hardware, so that
client programs don't use the kernel interface directly either.
I could live with "Do not use cdrtools on a different kernel than it
was compiled against" or even "I don't recommend using software
with a different kernel than it was compiled under". Simply stating
that it will never work...well, try this:
#include
int main()
{
printf("Hello, world!\n");
}
Compile under 2.4, run under 2.6. I'm sure
Re: cdrtools-2.01a22 ready
>From [EMAIL PROTECTED] Tue Jan 6 17:38:11 2004 >> You did just prove that there is a difference between an attempt for a test >> and a real test! >> >> Try to unpack and verify this archive: >Isn't it typical? I've complained about wording of statement attached to >usage of major macro in cdda2wav and discussion is immediately led to >other spheres. Yes, these issues (original and the one brought up here) >are related, but I would like to get answer to original question >*first*. Do you or do you not agree that original statement was in fact >"it has always been wrong to compile cdrtools only once for different >kernel versions" and not "it has always been wrong to compile software >only once"? I'm ready to proceed with further discussion on the issue >brought up in this mail (I suggest to continue on >cdwrite@other.debian.org) only after you clarify the original statement. Looks typical for you :-( Sorry, but you just again proved that it is a waste of time trying to be more versartile in explanations. What you write is completely irrelevant because you just proved that you are one of the persons that are unable to decide whether a binary compiled on Linux-2.4 will run correctly on Linux-2.6 As this is the case, it is better to publish general warnings that tell people not to try this at all, rather than giving a versatile explanation. For all people who have enough background knowledge in software engineering, here is a text that I did write for another purpose: /*--*/ star -tv < /tmp/cdev.tar.bz2 star: WARNING: Archive is 'bzip2' compressed, trying to use the -bz option. star: Blocksize = 7 records. Release star 1.5a35 (i386-pc-solaris2.9) Archtypeexustar Dumpdate1073336802.243055000 (Mon Jan 5 22:06:42 2004) Volno 1 Blocksize 20 255 7000 crw-r--r-- 1 root/other Jan 5 22:06 2004 cdev star: 1 blocks + 0 bytes (total of 3584 bytes = 3.50k). AS you see, this is a tar archive that includes a character special with major 255 and minor 7000. You can list the correct major/minor numbers on any OS if you use star -tv, as the content of the tar archive is kernel interface independent. If you unpack this on a Linux-2.6 system using a "star" binary that has been compiled on Linux-2.4, you will extract a character special with minor 88 instead of minor 7000. This proves that you cannot run binaries from Linux-2.4 on Linux-2.6 correctly. If you compile on Linux-2.6, there is a big chance that the autoconf run will detect interfaces that are not present on Linux-2.4, so trying the other direction will most likely give just other problems. I am sorry, but the current work on the Linux kernel is overshadowed by severe missunderstandings. Linus and other people from LKML seem to be unable to understand how interfaces work. Let me explain it to you. There are three types of interfaces, you can see in libc and /usr/include/*: 1) Interfaces that are fully created by libc, such as strcpy() 2) Interfaces that are defined by the kernel but propagated by libc. Interfaces of this type are things similar to open()/read()/write(),.. 3) Interfaces that libc is not even aware of (like ioctl() functions). If major()/minor()/makedev() are CPP macros and not functions in libc, then they are part of this group of interfaces. Interfaces of type 1) are independent of the kernel and for this reason, the statements from Linus on how (from his belief) include files should be treatened apply _only_ to these interfaces. To allow an application to match the interface, you need an include file that is published by the same instance or person who does work on libc. Interfaces of type 2) require that libc and the kernel version match. This means, that you need to recompile and in some cases even to modify the libc sources in order to get a working complete system every time the kernel interface (used by libc) changes. This is needed to keep the upper level interface from libc stable. Interfaces of type 3) are independent of libc! Any application that likes to use them, _needs_ to use the include files from the kernel they are going to be run on. This is the only way, to make sure that the user level application uses an interface that matches the adjacent interface from the kernel. If you use different include files, you are unable to even test the kernel interface. For this reason, it is important that all include files from the kernel (that define interfaces that are visible from user land) are written in a way that allows a consistent usage from a user land application (which does never #define __KERNEL or similar). Cdrecord is definitely a user land application that needs to be compiled with the include files from the current kernel - otherwise it could not e.g. use new features from SCSI drivers inside the kernel. Star with respect to device major/minor handling is
Re: cdrtools-2.01a22 ready
>From [EMAIL PROTECTED] Tue Jan 6 17:38:11 2004 >> You did just prove that there is a difference between an attempt for a test >> and a real test! >> >> Try to unpack and verify this archive: >Isn't it typical? I've complained about wording of statement attached to >usage of major macro in cdda2wav and discussion is immediately led to >other spheres. Yes, these issues (original and the one brought up here) >are related, but I would like to get answer to original question >*first*. Do you or do you not agree that original statement was in fact >"it has always been wrong to compile cdrtools only once for different >kernel versions" and not "it has always been wrong to compile software >only once"? I'm ready to proceed with further discussion on the issue >brought up in this mail (I suggest to continue on >[EMAIL PROTECTED]) only after you clarify the original statement. Looks typical for you :-( Sorry, but you just again proved that it is a waste of time trying to be more versartile in explanations. What you write is completely irrelevant because you just proved that you are one of the persons that are unable to decide whether a binary compiled on Linux-2.4 will run correctly on Linux-2.6 As this is the case, it is better to publish general warnings that tell people not to try this at all, rather than giving a versatile explanation. For all people who have enough background knowledge in software engineering, here is a text that I did write for another purpose: /*--*/ star -tv < /tmp/cdev.tar.bz2 star: WARNING: Archive is 'bzip2' compressed, trying to use the -bz option. star: Blocksize = 7 records. Release star 1.5a35 (i386-pc-solaris2.9) Archtypeexustar Dumpdate1073336802.243055000 (Mon Jan 5 22:06:42 2004) Volno 1 Blocksize 20 255 7000 crw-r--r-- 1 root/other Jan 5 22:06 2004 cdev star: 1 blocks + 0 bytes (total of 3584 bytes = 3.50k). AS you see, this is a tar archive that includes a character special with major 255 and minor 7000. You can list the correct major/minor numbers on any OS if you use star -tv, as the content of the tar archive is kernel interface independent. If you unpack this on a Linux-2.6 system using a "star" binary that has been compiled on Linux-2.4, you will extract a character special with minor 88 instead of minor 7000. This proves that you cannot run binaries from Linux-2.4 on Linux-2.6 correctly. If you compile on Linux-2.6, there is a big chance that the autoconf run will detect interfaces that are not present on Linux-2.4, so trying the other direction will most likely give just other problems. I am sorry, but the current work on the Linux kernel is overshadowed by severe missunderstandings. Linus and other people from LKML seem to be unable to understand how interfaces work. Let me explain it to you. There are three types of interfaces, you can see in libc and /usr/include/*: 1) Interfaces that are fully created by libc, such as strcpy() 2) Interfaces that are defined by the kernel but propagated by libc. Interfaces of this type are things similar to open()/read()/write(),.. 3) Interfaces that libc is not even aware of (like ioctl() functions). If major()/minor()/makedev() are CPP macros and not functions in libc, then they are part of this group of interfaces. Interfaces of type 1) are independent of the kernel and for this reason, the statements from Linus on how (from his belief) include files should be treatened apply _only_ to these interfaces. To allow an application to match the interface, you need an include file that is published by the same instance or person who does work on libc. Interfaces of type 2) require that libc and the kernel version match. This means, that you need to recompile and in some cases even to modify the libc sources in order to get a working complete system every time the kernel interface (used by libc) changes. This is needed to keep the upper level interface from libc stable. Interfaces of type 3) are independent of libc! Any application that likes to use them, _needs_ to use the include files from the kernel they are going to be run on. This is the only way, to make sure that the user level application uses an interface that matches the adjacent interface from the kernel. If you use different include files, you are unable to even test the kernel interface. For this reason, it is important that all include files from the kernel (that define interfaces that are visible from user land) are written in a way that allows a consistent usage from a user land application (which does never #define __KERNEL or similar). Cdrecord is definitely a user land application that needs to be compiled with the include files from the current kernel - otherwise it could not e.g. use new features from SCSI drivers inside the kernel. Star with respect to device major/minor handling is another o
Re: cdrtools-2.01a22 ready
> You did just prove that there is a difference between an attempt for a test > and a real test! > > Try to unpack and verify this archive: Isn't it typical? I've complained about wording of statement attached to usage of major macro in cdda2wav and discussion is immediately led to other spheres. Yes, these issues (original and the one brought up here) are related, but I would like to get answer to original question *first*. Do you or do you not agree that original statement was in fact "it has always been wrong to compile cdrtools only once for different kernel versions" and not "it has always been wrong to compile software only once"? I'm ready to proceed with further discussion on the issue brought up in this mail (I suggest to continue on cdwrite@other.debian.org) only after you clarify the original statement. A.
Re: cdrtools-2.01a22 ready
> You did just prove that there is a difference between an attempt for a test > and a real test! > > Try to unpack and verify this archive: Isn't it typical? I've complained about wording of statement attached to usage of major macro in cdda2wav and discussion is immediately led to other spheres. Yes, these issues (original and the one brought up here) are related, but I would like to get answer to original question *first*. Do you or do you not agree that original statement was in fact "it has always been wrong to compile cdrtools only once for different kernel versions" and not "it has always been wrong to compile software only once"? I'm ready to proceed with further discussion on the issue brought up in this mail (I suggest to continue on [EMAIL PROTECTED]) only after you clarify the original statement. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a22 ready
>From: Andy Polyakov <[EMAIL PROTECTED]>
Let us make it short .
>OK, I've just compiled second star binary. I mean I've had one compiled
>under 2.4 (left from Dec 2002, when you posted request for help with
>mkisofs -dvd-video:-), so I've compiled one under 2.6 too... Well, I
>can't confirm your experience, as archive files produced by both
>binaries are identical and they both cross-extract correctly. I
>therefore have no other choice, but to challenge your proof:-) But see
>even below!!!
You did just prove that there is a difference between an attempt for a test
and a real test!
Try to unpack and verify this archive:
begin 644 cdev.tar.bz2
M0EIH.3%!62936=&]\I< &[EMAIL PROTECTED] ,! 8__B3&18)'_OWW" "# !>TE@,IE3
MU/1/331JC)M0T'J ,[EMAIL PROTECTED]"-%#(-30]3)B!H&1DTR:,F D4B>@IF2&FG
MJ9-#1ZAH-#31IB:&G ;]>U$"!NL_-,RC6,A0A)3JP((!B0SZA7BP+UJP-W(J
MA>#X>[EMAIL PROTECTED]"')%QFF2,[EMAIL PROTECTED];!?RTZ.?-V%*P5//=;:3M"[EMAIL
PROTECTED]
[EMAIL PROTECTED]&*E,WC2FYE0'*\-ZXN$)B>*ES%EJQ8" &015?]&I/*9N\F\
MS%; [EMAIL PROTECTED] 0JVQ>*"W798D.5NPT*E)Z&FL"N'?I$"F9)[EMAIL
PROTECTED](:L!05B10
M49)%*IZ(QA3'=MUAY.1KJ/E!?T(,[EMAIL PROTECTED]'N%'00-A 0#'XT#I^2/WETMW/^
MPW?^6T3<[EMAIL PROTECTED]>X>F426F>0F:@J?3!IPIN9O4X,.*%SJY'1-1#,A04LF&@Q7R?7(#+$B!#L:U*L;*KSX8!("$P6
/P5VD#B+N2*<*$AHWOE+@
end
by using an star compiled on Linux-2.4
If you like to do real tests, you need to know _how_ to test.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni) If you don't have iso-8859-1
[EMAIL PROTECTED](work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling
ftp://ftp.berlios.de/pub/schily
Re: cdrtools-2.01a22 ready
> >As such wording sounds very much as "political statement," I feel > >necessity to comment on following. > > It is definitely not politocal but it tries to be so simple that even > the morons you typically meet on the LKML will understand it :-( Has it occurred to you that, after posting that "thing" twice now, the people on LKML may think the same about you? Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
Re: cdrtools-2.01a22 ready
>From: Andy Polyakov <[EMAIL PROTECTED]>
Let us make it short .
>OK, I've just compiled second star binary. I mean I've had one compiled
>under 2.4 (left from Dec 2002, when you posted request for help with
>mkisofs -dvd-video:-), so I've compiled one under 2.6 too... Well, I
>can't confirm your experience, as archive files produced by both
>binaries are identical and they both cross-extract correctly. I
>therefore have no other choice, but to challenge your proof:-) But see
>even below!!!
You did just prove that there is a difference between an attempt for a test
and a real test!
Try to unpack and verify this archive:
begin 644 cdev.tar.bz2
M0EIH.3%!62936=&]\I< &[EMAIL PROTECTED] ,! 8__B3&18)'_OWW" "# !>TE@,IE3
MU/1/331JC)M0T'J ,[EMAIL PROTECTED]"-%#(-30]3)B!H&1DTR:,F D4B>@IF2&FG
MJ9-#1ZAH-#31IB:&G ;]>U$"!NL_-,RC6,A0A)3JP((!B0SZA7BP+UJP-W(J
MA>#X>[EMAIL PROTECTED]"')%QFF2,[EMAIL PROTECTED];!?RTZ.?-V%*P5//=;:3M"[EMAIL
PROTECTED]
[EMAIL PROTECTED]&*E,WC2FYE0'*\-ZXN$)B>*ES%EJQ8" &015?]&I/*9N\F\
MS%; [EMAIL PROTECTED] 0JVQ>*"W798D.5NPT*E)Z&FL"N'?I$"F9)[EMAIL PROTECTED](:L!05B10
M49)%*IZ(QA3'=MUAY.1KJ/E!?T(,[EMAIL PROTECTED]'N%'00-A 0#'XT#I^2/WETMW/^
MPW?^6T3<[EMAIL PROTECTED]>X>F426F>0F:@J?3!IPIN9O4X,.*%SJY'1-1#,A04LF&@Q7R?7(#+$B!#L:U*L;*KSX8!("$P6
/P5VD#B+N2*<*$AHWOE+@
end
by using an star compiled on Linux-2.4
If you like to do real tests, you need to know _how_ to test.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni) If you don't have iso-8859-1
[EMAIL PROTECTED](work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a22 ready
> >As such wording sounds very much as "political statement," I feel > >necessity to comment on following. > > It is definitely not politocal but it tries to be so simple that even > the morons you typically meet on the LKML will understand it :-( Has it occurred to you that, after posting that "thing" twice now, the people on LKML may think the same about you? Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a22 ready
> >> Cdda2wav (By Heiko Eißfeldt [EMAIL PROTECTED]): > >> > >> - Now using the major() macro for some Linux duties. > >> > >> WARNING to creators of Linux distributions: > > >As such wording sounds very much as "political statement," I feel > >necessity to comment on following. > > It is definitely not politocal but it tries to be so simple that even > the morons you typically meet on the LKML will understand it :-( ^^^ Speak for yourself, please! All right! Then you should have written "WARNING to those [morons(*) I, J. Schilling, typically meet] on LKML" and not something as politically loaded as "creators of Linux distributions," which basically refers to e.g. Suse, Mandrake, Redhat, etc. (*) As mentioned earlier I personally can't find such expressions acceptable on public lists. This is exactly kind of wording which breaks the trust and tears the community apart. > >> It has _always_ been wrong to compile software only once for > >> different > >> kernel versions (e.g. for compile Linux-2.4 and later install a > >> 2.2 kernel on the so created system). > > >I can't find the above statement to hold universally true. I would > >accept "it has always beed wrong to compile *cdrtools* only once for > >different kernel versions," but I refuse to accept formulation as broad > >as above. There is possibility that author's intention *was* to make > >statement about cdrtools in particular, in which case a clarification > > Sorry, Linux-2.6 _did_ definitely change interfaces in an incomptible way. *All* [kernel] interfaces? Once again! I can't find the statement in its original wording, i.e. as "it has *always* been wrong to compile *software* ..." to hold *universally* true. I can accept "it's wrong to compile *certain* software," preferably accompanied by solid explanation *why* it's wrong. *If* your statement [in its original wording] was actually true, then noone would ever be able to dual-boot same root-partition on 2.4 and 2.[56]. > >note would be appropriate. Meanwhile I can say that I disagree with the > >above statement in its current wording, because it's perfectly possible > >to design software for backward binary compatility and even for two-way > >compatibility. Moreover! Creators of Linux distributions *should* > >actually strive for at least backward compatibility in maximum possible > >extent, i.e. programs compiled under elder distribution should work and > >even be supported under newer release, unless there is stronger reason > >not to. I mean "it works in latest distribution if recompiled" per se > > And this is definitely wrong! What is definitely wrong? Is it definitely wrong to *expect* developers to *strive* for binary compatibility between kernel [or even distribution] releases? That's what it says above! Do you disagree with assessment that Linux would provide better foundation if binary compatibility would be #1 design goal? You can't possibly disagree, as this is exactly what you're complaining about, aren't you? > Unfortunately, Linux-2.6 did change iterfaces in a way so it is impossible > to run all applications compiled under earlier releases. > > This may be proved by looking at star: As the major()/minor() macro did > change in an incompatible way, star just _cannot_ work correctly if you > mix versions. Star compiled for pre-2.6 does not handle device nodes > correctly on 2.6 and this is _not_ caused by a bug in star. > > As it has been prooven, OK, I've just compiled second star binary. I mean I've had one compiled under 2.4 (left from Dec 2002, when you posted request for help with mkisofs -dvd-video:-), so I've compiled one under 2.6 too... Well, I can't confirm your experience, as archive files produced by both binaries are identical and they both cross-extract correctly. I therefore have no other choice, but to challenge your proof:-) But see even below!!! > that there are problems with at least one program, > what is wrong when I warn people that there might problems with other > programs also? As already mentioned, wording is wrong. As already implied, "It has always been wrong to compile at least software written/maintained by me, J. Schilling, ..." would be *perfectly* appropriate. You can strenthen it by saying "I, J. Schilling, concluded that it has always been wrong to compile every piece of software I have examined ...," but you can't possibly mean as broad as "It has always been wrong to compile software..." > I am just warning people that unless they did 100% prove that every single > aspect of a program will work correctly, if you run it on 2.6 vs. non 2.6 > systems, it is more safe to assume that there is no binary compatibility. Well, are you positive that this is actually a kernel incompatibility issue and not glibc? I bet you are not, as that's what it has to be, binary incompatibility at glibc level! Meaning that you can fall victim to this problem even under 2.4! Formally speaking if bin
Re: cdrtools-2.01a22 ready
> >> Cdda2wav (By Heiko Eißfeldt [EMAIL PROTECTED]): > >> > >> - Now using the major() macro for some Linux duties. > >> > >> WARNING to creators of Linux distributions: > > >As such wording sounds very much as "political statement," I feel > >necessity to comment on following. > > It is definitely not politocal but it tries to be so simple that even > the morons you typically meet on the LKML will understand it :-( ^^^ Speak for yourself, please! All right! Then you should have written "WARNING to those [morons(*) I, J. Schilling, typically meet] on LKML" and not something as politically loaded as "creators of Linux distributions," which basically refers to e.g. Suse, Mandrake, Redhat, etc. (*) As mentioned earlier I personally can't find such expressions acceptable on public lists. This is exactly kind of wording which breaks the trust and tears the community apart. > >> It has _always_ been wrong to compile software only once for different > >> kernel versions (e.g. for compile Linux-2.4 and later install a > >> 2.2 kernel on the so created system). > > >I can't find the above statement to hold universally true. I would > >accept "it has always beed wrong to compile *cdrtools* only once for > >different kernel versions," but I refuse to accept formulation as broad > >as above. There is possibility that author's intention *was* to make > >statement about cdrtools in particular, in which case a clarification > > Sorry, Linux-2.6 _did_ definitely change interfaces in an incomptible way. *All* [kernel] interfaces? Once again! I can't find the statement in its original wording, i.e. as "it has *always* been wrong to compile *software* ..." to hold *universally* true. I can accept "it's wrong to compile *certain* software," preferably accompanied by solid explanation *why* it's wrong. *If* your statement [in its original wording] was actually true, then noone would ever be able to dual-boot same root-partition on 2.4 and 2.[56]. > >note would be appropriate. Meanwhile I can say that I disagree with the > >above statement in its current wording, because it's perfectly possible > >to design software for backward binary compatility and even for two-way > >compatibility. Moreover! Creators of Linux distributions *should* > >actually strive for at least backward compatibility in maximum possible > >extent, i.e. programs compiled under elder distribution should work and > >even be supported under newer release, unless there is stronger reason > >not to. I mean "it works in latest distribution if recompiled" per se > > And this is definitely wrong! What is definitely wrong? Is it definitely wrong to *expect* developers to *strive* for binary compatibility between kernel [or even distribution] releases? That's what it says above! Do you disagree with assessment that Linux would provide better foundation if binary compatibility would be #1 design goal? You can't possibly disagree, as this is exactly what you're complaining about, aren't you? > Unfortunately, Linux-2.6 did change iterfaces in a way so it is impossible > to run all applications compiled under earlier releases. > > This may be proved by looking at star: As the major()/minor() macro did > change in an incompatible way, star just _cannot_ work correctly if you > mix versions. Star compiled for pre-2.6 does not handle device nodes > correctly on 2.6 and this is _not_ caused by a bug in star. > > As it has been prooven, OK, I've just compiled second star binary. I mean I've had one compiled under 2.4 (left from Dec 2002, when you posted request for help with mkisofs -dvd-video:-), so I've compiled one under 2.6 too... Well, I can't confirm your experience, as archive files produced by both binaries are identical and they both cross-extract correctly. I therefore have no other choice, but to challenge your proof:-) But see even below!!! > that there are problems with at least one program, > what is wrong when I warn people that there might problems with other > programs also? As already mentioned, wording is wrong. As already implied, "It has always been wrong to compile at least software written/maintained by me, J. Schilling, ..." would be *perfectly* appropriate. You can strenthen it by saying "I, J. Schilling, concluded that it has always been wrong to compile every piece of software I have examined ...," but you can't possibly mean as broad as "It has always been wrong to compile software..." > I am just warning people that unless they did 100% prove that every single > aspect of a program will work correctly, if you run it on 2.6 vs. non 2.6 > systems, it is more safe to assume that there is no binary compatibility. Well, are you positive that this is actually a kernel incompatibility issue and not glibc? I bet you are not, as that's what it has to be, binary incompatibility at glibc level! Meaning that you can fall victim to this problem even under 2.4! Formally speaking if binary co
Re: cdrtools-2.01a22 ready
>From: Andy Polyakov <[EMAIL PROTECTED]> >> Cdda2wav (By Heiko Eißfeldt [EMAIL PROTECTED]): >> >> - Now using the major() macro for some Linux duties. >> >> WARNING to creators of Linux distributions: >As such wording sounds very much as "political statement," I feel >necessity to comment on following. It is definitely not politocal but it tries to be so simple that even the morons you typically meet on the LKML will understand it :-( >> It has _always_ been wrong to compile software only once for >> different >> kernel versions (e.g. for compile Linux-2.4 and later install a >> 2.2 kernel on the so created system). >I can't find the above statement to hold universally true. I would >accept "it has always beed wrong to compile *cdrtools* only once for >different kernel versions," but I refuse to accept formulation as broad >as above. There is possibility that author's intention *was* to make >statement about cdrtools in particular, in which case a clarification Sorry, Linux-2.6 _did_ definitely change interfaces in an incomptible way. >note would be appropriate. Meanwhile I can say that I disagree with the >above statement in its current wording, because it's perfectly possible >to design software for backward binary compatility and even for two-way >compatibility. Moreover! Creators of Linux distributions *should* >actually strive for at least backward compatibility in maximum possible >extent, i.e. programs compiled under elder distribution should work and >even be supported under newer release, unless there is stronger reason >not to. I mean "it works in latest distribution if recompiled" per se And this is definitely wrong! Unfortunately, Linux-2.6 did change iterfaces in a way so it is impossible to run all applications compiled under earlier releases. This may be proved by looking at star: As the major()/minor() macro did change in an incompatible way, star just _cannot_ work correctly if you mix versions. Star compiled for pre-2.6 does not handle device nodes correctly on 2.6 and this is _not_ caused by a bug in star. As it has been prooven, that there are problems with at least one program, what is wrong when I warn people that there might problems with other programs also? >> Now that Linux-2.6 introduces incompatible changes to kernel/user >> interfaces, the resulting binaries will not work correctly anymore. >The "political statement" appearence is strengthened by the fact that >this issue has no apparent connection with context in which they're >brought up, namely switching to major() macro in cdda2wav. I mean as far >as calculation of major device number goes, at least 2.4 and 2.6 kernels >are two-way binary compatible. Even binary compatibility with 2.2 (once >again as far as calculation of major device number goes!) is rather libc >issue than kernel one. A. If you obviously cannot distinct between political statements and serious warnings about Linux kernel incompatibilities, please don't shout too loud I am just warning people that unless they did 100% prove that every single aspect of a program will work correctly, if you run it on 2.6 vs. non 2.6 systems, it is more safe to assume that there is no binary compatibility. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am J"org Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
Re: cdrtools-2.01a22 ready
>From: Andy Polyakov <[EMAIL PROTECTED]> >> Cdda2wav (By Heiko Eißfeldt [EMAIL PROTECTED]): >> >> - Now using the major() macro for some Linux duties. >> >> WARNING to creators of Linux distributions: >As such wording sounds very much as "political statement," I feel >necessity to comment on following. It is definitely not politocal but it tries to be so simple that even the morons you typically meet on the LKML will understand it :-( >> It has _always_ been wrong to compile software only once for different >> kernel versions (e.g. for compile Linux-2.4 and later install a >> 2.2 kernel on the so created system). >I can't find the above statement to hold universally true. I would >accept "it has always beed wrong to compile *cdrtools* only once for >different kernel versions," but I refuse to accept formulation as broad >as above. There is possibility that author's intention *was* to make >statement about cdrtools in particular, in which case a clarification Sorry, Linux-2.6 _did_ definitely change interfaces in an incomptible way. >note would be appropriate. Meanwhile I can say that I disagree with the >above statement in its current wording, because it's perfectly possible >to design software for backward binary compatility and even for two-way >compatibility. Moreover! Creators of Linux distributions *should* >actually strive for at least backward compatibility in maximum possible >extent, i.e. programs compiled under elder distribution should work and >even be supported under newer release, unless there is stronger reason >not to. I mean "it works in latest distribution if recompiled" per se And this is definitely wrong! Unfortunately, Linux-2.6 did change iterfaces in a way so it is impossible to run all applications compiled under earlier releases. This may be proved by looking at star: As the major()/minor() macro did change in an incompatible way, star just _cannot_ work correctly if you mix versions. Star compiled for pre-2.6 does not handle device nodes correctly on 2.6 and this is _not_ caused by a bug in star. As it has been prooven, that there are problems with at least one program, what is wrong when I warn people that there might problems with other programs also? >> Now that Linux-2.6 introduces incompatible changes to kernel/user >> interfaces, the resulting binaries will not work correctly anymore. >The "political statement" appearence is strengthened by the fact that >this issue has no apparent connection with context in which they're >brought up, namely switching to major() macro in cdda2wav. I mean as far >as calculation of major device number goes, at least 2.4 and 2.6 kernels >are two-way binary compatible. Even binary compatibility with 2.2 (once >again as far as calculation of major device number goes!) is rather libc >issue than kernel one. A. If you obviously cannot distinct between political statements and serious warnings about Linux kernel incompatibilities, please don't shout too loud I am just warning people that unless they did 100% prove that every single aspect of a program will work correctly, if you run it on 2.6 vs. non 2.6 systems, it is more safe to assume that there is no binary compatibility. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am J"org Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a22 ready
> Cdda2wav (By Heiko Eißfeldt [EMAIL PROTECTED]): > > - Now using the major() macro for some Linux duties. > > WARNING to creators of Linux distributions: As such wording sounds very much as "political statement," I feel necessity to comment on following. > It has _always_ been wrong to compile software only once for different > kernel versions (e.g. for compile Linux-2.4 and later install a > 2.2 kernel on the so created system). I can't find the above statement to hold universally true. I would accept "it has always beed wrong to compile *cdrtools* only once for different kernel versions," but I refuse to accept formulation as broad as above. There is possibility that author's intention *was* to make statement about cdrtools in particular, in which case a clarification note would be appropriate. Meanwhile I can say that I disagree with the above statement in its current wording, because it's perfectly possible to design software for backward binary compatility and even for two-way compatibility. Moreover! Creators of Linux distributions *should* actually strive for at least backward compatibility in maximum possible extent, i.e. programs compiled under elder distribution should work and even be supported under newer release, unless there is stronger reason not to. I mean "it works in latest distribution if recompiled" per se should not be a viable argument, but only "it doesn't work *because* this and that, there is nothing we can do to make [re]compiled binary for elder distribution work under latest distributions, but to recompile it there." Yes, this means that I would very much like to see packages being assembled under eldest possible distribution to provide binary compatibility under latest distribution. This approach stimulates developers to write better code and is the only way to create and maintain trust-worthy foundation which lasts. > Now that Linux-2.6 introduces incompatible changes to kernel/user > interfaces, the resulting binaries will not work correctly anymore. The "political statement" appearence is strengthened by the fact that this issue has no apparent connection with context in which they're brought up, namely switching to major() macro in cdda2wav. I mean as far as calculation of major device number goes, at least 2.4 and 2.6 kernels are two-way binary compatible. Even binary compatibility with 2.2 (once again as far as calculation of major device number goes!) is rather libc issue than kernel one. A.
Re: cdrtools-2.01a22 ready
> Cdda2wav (By Heiko Eißfeldt [EMAIL PROTECTED]): > > - Now using the major() macro for some Linux duties. > > WARNING to creators of Linux distributions: As such wording sounds very much as "political statement," I feel necessity to comment on following. > It has _always_ been wrong to compile software only once for different > kernel versions (e.g. for compile Linux-2.4 and later install a > 2.2 kernel on the so created system). I can't find the above statement to hold universally true. I would accept "it has always beed wrong to compile *cdrtools* only once for different kernel versions," but I refuse to accept formulation as broad as above. There is possibility that author's intention *was* to make statement about cdrtools in particular, in which case a clarification note would be appropriate. Meanwhile I can say that I disagree with the above statement in its current wording, because it's perfectly possible to design software for backward binary compatility and even for two-way compatibility. Moreover! Creators of Linux distributions *should* actually strive for at least backward compatibility in maximum possible extent, i.e. programs compiled under elder distribution should work and even be supported under newer release, unless there is stronger reason not to. I mean "it works in latest distribution if recompiled" per se should not be a viable argument, but only "it doesn't work *because* this and that, there is nothing we can do to make [re]compiled binary for elder distribution work under latest distributions, but to recompile it there." Yes, this means that I would very much like to see packages being assembled under eldest possible distribution to provide binary compatibility under latest distribution. This approach stimulates developers to write better code and is the only way to create and maintain trust-worthy foundation which lasts. > Now that Linux-2.6 introduces incompatible changes to kernel/user > interfaces, the resulting binaries will not work correctly anymore. The "political statement" appearence is strengthened by the fact that this issue has no apparent connection with context in which they're brought up, namely switching to major() macro in cdda2wav. I mean as far as calculation of major device number goes, at least 2.4 and 2.6 kernels are two-way binary compatible. Even binary compatibility with 2.2 (once again as far as calculation of major device number goes!) is rather libc issue than kernel one. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a22 ready
>From: Volker Kuhlmann <[EMAIL PROTECTED]> WARNING: if you continue to include an illegal reply email address in your mailings, you will be ignored in future! >> >Can you be more specific about the bugs please? Or does that "contain >> >bugs" simply refer to that they're not the latest alpha version? >> >> Patches that don't follow the conceptional design of complex data structures >> easily break functions that the author of the patch is not aware of. >In the past so many years cdrecord has always worked for me, but I >haven't tried their latest version. I am talking about the patches tha are intended to implement DVD writing. >> SuSE implements a "device manager" deamon that opens device nodes for other >> programs. This daemon is less secure than cdrecord/libscg as libscg >> does far more than a simple string compare/pattern matching on the device >> node >> name. >Your alternative requires cdrecord to be SUID root, which from my point >of view (not knowing the details about either) isn't any safer than >resmgr (programmed by a professional + paid security person). IMHO it Well, why then SuSE does not hire a professional for help? The SuSE hack is definitely less secure than an official cdrecord version. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am J"org Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
Re: cdrtools-2.01a22 ready
>From: Volker Kuhlmann <[EMAIL PROTECTED]> WARNING: if you continue to include an illegal reply email address in your mailings, you will be ignored in future! >> >Can you be more specific about the bugs please? Or does that "contain >> >bugs" simply refer to that they're not the latest alpha version? >> >> Patches that don't follow the conceptional design of complex data structures >> easily break functions that the author of the patch is not aware of. >In the past so many years cdrecord has always worked for me, but I >haven't tried their latest version. I am talking about the patches tha are intended to implement DVD writing. >> SuSE implements a "device manager" deamon that opens device nodes for other >> programs. This daemon is less secure than cdrecord/libscg as libscg >> does far more than a simple string compare/pattern matching on the device node >> name. >Your alternative requires cdrecord to be SUID root, which from my point >of view (not knowing the details about either) isn't any safer than >resmgr (programmed by a professional + paid security person). IMHO it Well, why then SuSE does not hire a professional for help? The SuSE hack is definitely less secure than an official cdrecord version. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am J"org Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a22 ready
> >Can you be more specific about the bugs please? Or does that "contain > >bugs" simply refer to that they're not the latest alpha version? > > Patches that don't follow the conceptional design of complex data structures > easily break functions that the author of the patch is not aware of. In the past so many years cdrecord has always worked for me, but I haven't tried their latest version. > >What "security holes" are you talking about? > I tought that I did already mention it. Not on this list in the months I've been subscribed to it, but thanks for clarifying. > SuSE implements a "device manager" deamon that opens device nodes for other > programs. This daemon is less secure than cdrecord/libscg as libscg > does far more than a simple string compare/pattern matching on the device node > name. Your alternative requires cdrecord to be SUID root, which from my point of view (not knowing the details about either) isn't any safer than resmgr (programmed by a professional + paid security person). IMHO it isn't worth kicking up a security scare about, especially when that scare is accompanied by a complete nought of facts. Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
Re: cdrtools-2.01a22 ready
>From: Volker Kuhlmann <[EMAIL PROTECTED]> >> All recent SuSE distributions contain inofficial and modified versions >> of cdrecord that are known to contain bugs and open new security holes. >Can you be more specific about the bugs please? Or does that "contain >bugs" simply refer to that they're not the latest alpha version? Patches that don't follow the conceptional design of complex data structures easily break functions that the author of the patch is not aware of. >What "security holes" are you talking about? I tought that I did already mention it. SuSE implements a "device manager" deamon that opens device nodes for other programs. This daemon is less secure than cdrecord/libscg as libscg does far more than a simple string compare/pattern matching on the device node name. Linux does not implement a device node system with a stable device <-> node relation. Libscg maps device node names to more stable bus/target/lun values and is thus more secure than the simple system used by SuSE. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am J"org Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
Re: cdrtools-2.01a22 ready
> >Can you be more specific about the bugs please? Or does that "contain > >bugs" simply refer to that they're not the latest alpha version? > > Patches that don't follow the conceptional design of complex data structures > easily break functions that the author of the patch is not aware of. In the past so many years cdrecord has always worked for me, but I haven't tried their latest version. > >What "security holes" are you talking about? > I tought that I did already mention it. Not on this list in the months I've been subscribed to it, but thanks for clarifying. > SuSE implements a "device manager" deamon that opens device nodes for other > programs. This daemon is less secure than cdrecord/libscg as libscg > does far more than a simple string compare/pattern matching on the device node > name. Your alternative requires cdrecord to be SUID root, which from my point of view (not knowing the details about either) isn't any safer than resmgr (programmed by a professional + paid security person). IMHO it isn't worth kicking up a security scare about, especially when that scare is accompanied by a complete nought of facts. Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a22 ready
> All recent SuSE distributions contain inofficial and modified versions > of cdrecord that are known to contain bugs and open new security holes. Can you be more specific about the bugs please? Or does that "contain bugs" simply refer to that they're not the latest alpha version? What "security holes" are you talking about? > Unfortunately, SuSE stopped sending free CD sets to developers about > 9 months ago, so it is hard to get hold of these problems ftp://ftp.suse.com/pub/suse/ seems pretty simple to me. > Also note that for the above reasons, it is always a good idea to > compile > cdrtools yourself from official sources in order make sure that you run > an official version. Well, personally I'm interested in something which works, and couldn't care less whether it's "official". Compiling stuff is the responsibility of the distro-maker, that's what I pay for. Obviously I make exceptions, but being "official" is not one of them. Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
Re: cdrtools-2.01a22 ready
>From: Volker Kuhlmann <[EMAIL PROTECTED]> >> All recent SuSE distributions contain inofficial and modified versions >> of cdrecord that are known to contain bugs and open new security holes. >Can you be more specific about the bugs please? Or does that "contain >bugs" simply refer to that they're not the latest alpha version? Patches that don't follow the conceptional design of complex data structures easily break functions that the author of the patch is not aware of. >What "security holes" are you talking about? I tought that I did already mention it. SuSE implements a "device manager" deamon that opens device nodes for other programs. This daemon is less secure than cdrecord/libscg as libscg does far more than a simple string compare/pattern matching on the device node name. Linux does not implement a device node system with a stable device <-> node relation. Libscg maps device node names to more stable bus/target/lun values and is thus more secure than the simple system used by SuSE. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am J"org Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a22 ready
> All recent SuSE distributions contain inofficial and modified versions > of cdrecord that are known to contain bugs and open new security holes. Can you be more specific about the bugs please? Or does that "contain bugs" simply refer to that they're not the latest alpha version? What "security holes" are you talking about? > Unfortunately, SuSE stopped sending free CD sets to developers about > 9 months ago, so it is hard to get hold of these problems ftp://ftp.suse.com/pub/suse/ seems pretty simple to me. > Also note that for the above reasons, it is always a good idea to compile > cdrtools yourself from official sources in order make sure that you run > an official version. Well, personally I'm interested in something which works, and couldn't care less whether it's "official". Compiling stuff is the responsibility of the distro-maker, that's what I pay for. Obviously I make exceptions, but being "official" is not one of them. Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cdrtools-2.01a22 ready
NEW features of cdrtools-2.01a22: Please have a look at the German open Source Center BerliOS at www.berlios.de BerliOS will continue to support free hosting of cryptography projects even when US laws change and don't allow to host cryptography projects in the USA. Also look at sourcewell.berlios.de, the first Open Source announcement service that itself is implemented as Open Source project. * Important news For the 'Slottable Source Plugin Module' SSPM Features read README.SSPM * Please Test * NOTICE: for supporting the CW-7501 and for supporting SAO/DAO with the Sony CDU-920, Sony CDU-924, Sony CDU-948, the driver interface has been modified. This change did affect more than 3000 lines of code. The new driver interface again is more simple and more extendable than the old one, but the change may affect -dummy and -multi writing for any other drive. Please test if the change did not introduce new bugs. Also the change on the packet writing structures may affect packet writing. The changes for the DVD+ drive/media recognition may affect drive or media type recognition for any other drive. The changes for DVD+RW & DVD+R media support may cause cdrecod to fail in other circumstances. With cdrecord-2.01a13, the track parsing has been completely rearranged in order to support new features in the future. This causes a high risk for bugs. With cdrecord-2.01a14, CUE Sheet handling has been introduced and 1200 lines of new code has been integrated. Please test. GPL violation hint: All recent SuSE distributions contain inofficial and modified versions of cdrecord that are known to contain bugs and open new security holes. At least SuSE 8.2 (maybe other SuSE releases too) did contain a modified version of cdrecord that did violate the GPL § 2 Paragraph c) and GPL Preamble Section 6 by not making clear that they published a modified version that differs from the original and thus may have bug not found in the official version. As the version published by SuSE definitely has bugs, it is obvious that this hint is needed. SuSE 9.0 mow seems to honor the GPL but the cdrecord binaries on SuSE 9.0 are definitely defective - please compile cdrecord yourself to get binaries that work as expected. Unfortunately, SuSE stopped sending free CD sets to developers about 9 months ago, so it is hard to get hold of these problems Hint for interested people: Solaris x86 is free for personal use and the CD images may even be downloaded for free. Also note that for the above reasons, it is always a good idea to compile cdrtools yourself from official sources in order make sure that you run an official version. All: - New macros to platorm intependantly set up integers in little endian format. This is needed to e.g. write PC disk labels from big endian platforms. Libparanoia (Ported by Jörg Schilling, originated by Monty [EMAIL PROTECTED]): Libedc (Optimized by Jörg Schilling, originated by Heiko Eißfeldt [EMAIL PROTECTED]): Libscg: Rscsi: Cdrecord: - Better documentation and EXAMPLE for -setdropts driveropts= in the man page. - print a help pessage to direct the user to use -raw96r in case the drive does not accept the cue sheet with -dao. Cdda2wav (By Heiko Eißfeldt [EMAIL PROTECTED]): - Now using the major() macro for some Linux duties. WARNING to creators of Linux distributions: It has _always_ been wrong to compile software only once for different kernel versions (e.g. for compile Linux-2.4 and later install a 2.2 kernel on the so created system). Now that Linux-2.6 introduces incompatible changes to kernel/user interfaces, the resulting binaries will not work correctly anymore. Readcd: Scgcheck: Mkisofs (By Jörg Schilling and James Pearson [EMAIL PROTECTED]): - Added a NOTE regarding the SILO boot program for Linux sparc to the man page. - Added support for Solaris x86 boot CDs. This includes the following new options: - -sunx86-bootto create a fdisk & SVr4 partition table - -sunx86-label to set the "disk label" name for the SVr4 partition table. - New file README.sunx86boot TODO: - read Joliet filenames with multi-session if no TRANS.TBL or RR is present. I am looking for a volouteer for this task! Note that this can never be 100% correct as there is no relation between the names on the master (UNIX) filesystem, the ISO-9660 names and the J
cdrtools-2.01a22 ready
NEW features of cdrtools-2.01a22: Please have a look at the German open Source Center BerliOS at www.berlios.de BerliOS will continue to support free hosting of cryptography projects even when US laws change and don't allow to host cryptography projects in the USA. Also look at sourcewell.berlios.de, the first Open Source announcement service that itself is implemented as Open Source project. * Important news For the 'Slottable Source Plugin Module' SSPM Features read README.SSPM * Please Test * NOTICE: for supporting the CW-7501 and for supporting SAO/DAO with the Sony CDU-920, Sony CDU-924, Sony CDU-948, the driver interface has been modified. This change did affect more than 3000 lines of code. The new driver interface again is more simple and more extendable than the old one, but the change may affect -dummy and -multi writing for any other drive. Please test if the change did not introduce new bugs. Also the change on the packet writing structures may affect packet writing. The changes for the DVD+ drive/media recognition may affect drive or media type recognition for any other drive. The changes for DVD+RW & DVD+R media support may cause cdrecod to fail in other circumstances. With cdrecord-2.01a13, the track parsing has been completely rearranged in order to support new features in the future. This causes a high risk for bugs. With cdrecord-2.01a14, CUE Sheet handling has been introduced and 1200 lines of new code has been integrated. Please test. GPL violation hint: All recent SuSE distributions contain inofficial and modified versions of cdrecord that are known to contain bugs and open new security holes. At least SuSE 8.2 (maybe other SuSE releases too) did contain a modified version of cdrecord that did violate the GPL § 2 Paragraph c) and GPL Preamble Section 6 by not making clear that they published a modified version that differs from the original and thus may have bug not found in the official version. As the version published by SuSE definitely has bugs, it is obvious that this hint is needed. SuSE 9.0 mow seems to honor the GPL but the cdrecord binaries on SuSE 9.0 are definitely defective - please compile cdrecord yourself to get binaries that work as expected. Unfortunately, SuSE stopped sending free CD sets to developers about 9 months ago, so it is hard to get hold of these problems Hint for interested people: Solaris x86 is free for personal use and the CD images may even be downloaded for free. Also note that for the above reasons, it is always a good idea to compile cdrtools yourself from official sources in order make sure that you run an official version. All: - New macros to platorm intependantly set up integers in little endian format. This is needed to e.g. write PC disk labels from big endian platforms. Libparanoia (Ported by Jörg Schilling, originated by Monty [EMAIL PROTECTED]): Libedc (Optimized by Jörg Schilling, originated by Heiko Eißfeldt [EMAIL PROTECTED]): Libscg: Rscsi: Cdrecord: - Better documentation and EXAMPLE for -setdropts driveropts= in the man page. - print a help pessage to direct the user to use -raw96r in case the drive does not accept the cue sheet with -dao. Cdda2wav (By Heiko Eißfeldt [EMAIL PROTECTED]): - Now using the major() macro for some Linux duties. WARNING to creators of Linux distributions: It has _always_ been wrong to compile software only once for different kernel versions (e.g. for compile Linux-2.4 and later install a 2.2 kernel on the so created system). Now that Linux-2.6 introduces incompatible changes to kernel/user interfaces, the resulting binaries will not work correctly anymore. Readcd: Scgcheck: Mkisofs (By Jörg Schilling and James Pearson [EMAIL PROTECTED]): - Added a NOTE regarding the SILO boot program for Linux sparc to the man page. - Added support for Solaris x86 boot CDs. This includes the following new options: - -sunx86-bootto create a fdisk & SVr4 partition table - -sunx86-label to set the "disk label" name for the SVr4 partition table. - New file README.sunx86boot TODO: - read Joliet filenames with multi-session if no TRANS.TBL or RR is present. I am looking for a volouteer for this task! Note that this can never be 100% correct as there is no relation between the names on the master (UNIX) filesystem, the ISO-9660 names and the Joliet
