Re: The future of mkisofs
Bill Davidsen [EMAIL PROTECTED] wrote: I happily offer the suggestion that since the program has not been limited to ISO9660 images for years, the name implies limitations which don't apply, and since you can create images for most common optical media, that a name like mkoptimage would be more correct as well as preventing confusion. mkisofs is a well known program name and I cannot see that your proposal for a name change could help to reduce confusion for users. The probably biggest help for _new_ users was to list only the most important options in case of a usage error: Most important Options: -posix-HFollow sylinks encountered on command line -posix-LFollow all symlinks -posix-PDo not follow symlinks (default) -o FILE, -output FILE Set output file name -R, -rock Generate Rock Ridge directory information -r, -rational-rock Generate rationalized Rock Ridge directory info -J, -joliet Generate Joliet directory information -print-size Print estimated filesystem size and exit -UDFGenerate UDF file system -dvd-video Generate DVD-Video compliant UDF file system -iso-level LEVELSet ISO9660 level (1..3) or 4 for ISO9660 v 2 -V ID, -volid IDSet Volume ID -graft-points Allow to use graft points for filenames -M FILE, -prev-session FILE Set path to previous session to merge to lead people to the right options. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The future of mkisofs
Joerg Schilling wrote: Bill Davidsen [EMAIL PROTECTED] wrote: I happily offer the suggestion that since the program has not been limited to ISO9660 images for years, the name implies limitations which don't apply, and since you can create images for most common optical media, that a name like mkoptimage would be more correct as well as preventing confusion. mkisofs is a well known program name and I cannot see that your proposal for a name change could help to reduce confusion for users. Wow, think about that! You have to tell people many times a month that the program called cdrecord in many distributions is really wodin and works differently than your original cdrecord. Do you really want to be bothered by having questions about *three* versions of mkisofs, the current one in a38, the old one shipped with some distributions, and your new cleaned up version? It sounds like a waste of your time to me! And as for user confusion, I always install current cdrecord as CDrecord so I won't get the one which comes with a distribution. It would help the users if you did that with the enhanced mkisofs, because they wouldn't use an old version and complain, or try to use features in the new version and find they don't work. You know that no matter how confused the user is, it always gets reported as bug in your software. Best of both worlds, you don't get questions caused by users confusion, waste time chasing bugs that aren't, and users know what they are getting. The probably biggest help for _new_ users was to list only the most important options in case of a usage error: Most important Options: -posix-HFollow sylinks encountered on command line -posix-LFollow all symlinks -posix-PDo not follow symlinks (default) -o FILE, -output FILE Set output file name -R, -rock Generate Rock Ridge directory information -r, -rational-rock Generate rationalized Rock Ridge directory info -J, -joliet Generate Joliet directory information -print-size Print estimated filesystem size and exit -UDFGenerate UDF file system -dvd-video Generate DVD-Video compliant UDF file system -iso-level LEVELSet ISO9660 level (1..3) or 4 for ISO9660 v 2 -V ID, -volid IDSet Volume ID -graft-points Allow to use graft points for filenames -M FILE, -prev-session FILE Set path to previous session to merge to lead people to the right options. Jörg -- Bill Davidsen [EMAIL PROTECTED] Woe unto the statesman who makes war without a reason that will still be valid when the war is over... Otto von Bismark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The future of mkisofs
Bill Davidsen [EMAIL PROTECTED] wrote: mkisofs is a well known program name and I cannot see that your proposal for a name change could help to reduce confusion for users. Wow, think about that! You have to tell people many times a month that the program called cdrecord in many distributions is really wodin and works differently than your original cdrecord. Do you really want to be bothered by having questions about *three* versions of mkisofs, the current one in a38, the old one shipped with some distributions, and your new cleaned up version? It sounds like a waste of your time to me! I don't see three versions of mkisofs as I know from several professional users of mkisofs that they don't use the hsfs feature. ... and the main difference I see between mkisofs and the clone from cdrkit is the bugs that are present in the clone but not in the original. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The future of mkisofs
Joerg Schilling wrote: mkisofs is a program that has been originally writen in 1993 by Eric Youngdale and that has been extended by many people. In 1997, after Eric Youngdale mostly stopped working on mkisofs, I added mkisofs to the cdrecord source tree and started working on bugs and important extensions. After 2 years (in 1999) Eric Youngdale transferred the complete code reporitory to me. At that time, several people helped to enhance mkisofs. The most active one was James Pearson - he is unfortunately no longer reachable since he became a father years ago. Since that time, more than 5 years ago, I am the main mkisofs maintainer. Being now able to decide myself in mkisofs since 1999, I spend half a year only with bug fixes and code restructuring to make the code prepared for the future Now more than 8 years later, mkisofs has a lot more features than in 1999 and needs another code lifting. As mkisofs is very powerful and supports many OS and filesystem-hybrids, it has become a de-facto standard for creating ISO-9660 based filesystem images. We are currently a short time before the next stable release of cdrtools and I am planning to start a bigger code clean up after that time. The current plan is to do it the following way: - cdrtools-xxx.zzz-final (the next stable release) will be the last release that includes all features that are currently in mkisofs. People who need these features (e.g. because they own old hardware) need to keel the version of mkisofs that is included in the next stable version of cdrtools. - The ability to create Apple-Hybrid filesystem images causes problems since many years already because the Apple HFS filesystem type does not support files 2 GB and includes other limitations. - Support for this old filesystem is only needed for owners of Mac OS 9 systems and for people who like to boot Apple PPC based systems. These Apple PPC based systems are out of production since 3 years already. - Recent Apple systems boot using El-Torito extensions and understand UDF + Apple extensions. Both is supported in mkisofs since a while. It seems that support for Apple HFS is no longer needed in mkisofs and removing the support could help to clean up the code. I am planning to remove the Apple-Hybrid support with the developer versions for cdrtools that follow the next stable release of cdrtools. People who believe that this change would cause problems are called to explain their arguments. Please comment. I would offer the thought that to avoid confusion and people getting the wrong functionality, this would be a great time to pick a new name for the program and use that to indicate both deleted and added functionality. It would be easier than explaining having different features by the same name. Having two programs with different behavior called cdrecord has been confusing and has wasted your (and our) time repeatedly, so the cleanup could start by cleaning up confusion. I happily offer the suggestion that since the program has not been limited to ISO9660 images for years, the name implies limitations which don't apply, and since you can create images for most common optical media, that a name like mkoptimage would be more correct as well as preventing confusion. -- Bill Davidsen [EMAIL PROTECTED] Woe unto the statesman who makes war without a reason that will still be valid when the war is over... Otto von Bismark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
The future of mkisofs
mkisofs is a program that has been originally writen in 1993 by Eric Youngdale and that has been extended by many people. In 1997, after Eric Youngdale mostly stopped working on mkisofs, I added mkisofs to the cdrecord source tree and started working on bugs and important extensions. After 2 years (in 1999) Eric Youngdale transferred the complete code reporitory to me. At that time, several people helped to enhance mkisofs. The most active one was James Pearson - he is unfortunately no longer reachable since he became a father years ago. Since that time, more than 5 years ago, I am the main mkisofs maintainer. Being now able to decide myself in mkisofs since 1999, I spend half a year only with bug fixes and code restructuring to make the code prepared for the future Now more than 8 years later, mkisofs has a lot more features than in 1999 and needs another code lifting. As mkisofs is very powerful and supports many OS and filesystem-hybrids, it has become a de-facto standard for creating ISO-9660 based filesystem images. We are currently a short time before the next stable release of cdrtools and I am planning to start a bigger code clean up after that time. The current plan is to do it the following way: - cdrtools-xxx.zzz-final (the next stable release) will be the last release that includes all features that are currently in mkisofs. People who need these features (e.g. because they own old hardware) need to keel the version of mkisofs that is included in the next stable version of cdrtools. - The ability to create Apple-Hybrid filesystem images causes problems since many years already because the Apple HFS filesystem type does not support files 2 GB and includes other limitations. - Support for this old filesystem is only needed for owners of Mac OS 9 systems and for people who like to boot Apple PPC based systems. These Apple PPC based systems are out of production since 3 years already. - Recent Apple systems boot using El-Torito extensions and understand UDF + Apple extensions. Both is supported in mkisofs since a while. It seems that support for Apple HFS is no longer needed in mkisofs and removing the support could help to clean up the code. I am planning to remove the Apple-Hybrid support with the developer versions for cdrtools that follow the next stable release of cdrtools. People who believe that this change would cause problems are called to explain their arguments. Please comment. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
