> Hi, > > Ady: > > Since both included variants are currently different, and both > > variants have problems > > I am not aware of problems of the perl version. It is just lacking > the newer features which support EFI/GPT and Mac/APM. > The known bugs of isohybrid.c are with those newer features. > http://www.syslinux.org/archives/2012-May/017843.html > http://www.syslinux.org/archives/2012-May/017871.html >Not being compatible with EFI/GPT is already a problem for the Perl variant. The cases were the C variant might fail are also a problem, as common users don't know that different variants (including these two, the xorriso ones, and possibly others) might have different results. Add the lack of documentation about the differences, and you will get (sooner or later) reports about "isohybrid not working". To such reports we already answer with "which version of Syslinux?", "is your ISO image publicly available?", and "which tool was used to build the ISO image?". Without documentation (variants, versions, capabilities, limitations, requirements, OS...), how many detailed questions a common user would need to answer just to try to overcome (perhaps) the problem? How about the time to be invested just to (repeatedly) ask those questions? Updating the Perl variant would reduce the need for initial questions/details (which is frequently not something common users are in conditions to answer/provide). Since I am aware that such potential update to the Perl variant requires someone stepping up (I am sure patches are welcome), I was previously asking for some initial direction regarding the potential existence of some public reference about the different variants and their respective different behaviors (so to add documentation to the wiki, for example).> > > Ideally, the Perl variant should get updated at least with the > > patches that the C variant already includes > > As a programmer who knows the task, i'd say that C is the right > language to implement isohybrid. It introduces the least > dependencies and is well suited for the necessary byte operations. > Of course the build system of SYSLINUX would have to produce > a suitable executable from isohybrid.c.As you might have read already in prior emails, the Perl variant might be helpful under some circumstances, e.g. if we consider the OS itself a dependency.> > The executable has hardcoded MBR templates. I once got instructed > by hpa, not to mix MBR from one SYSLINUX version with the > isolinux.bin boot images from other versions. > This applies to the executable from isohybrid.c and to isohybrid.pl. > > So my proposal would be to fix isohybrid.c and to declare > isohybrid.pl frozen and deprecated. > (As long as isohybrid.in exists it will be able to adapt to > the MBR templates of new SYSLINUX versiosn.)Although I hope someone can still update the Perl variant, at least it should not be deleted and the differences / limitations should be documented. FWIW, I would not want to "declare" it frozen, as it would stop any potential contributions attempting to improve the Perl variant.> > > Ian Bannerman: > > While I did know the .exe variant was not official / untrusted, > > Is there a special reason for this ? (Except the known bugs which > affect Linux binaries, too.)I am not sure I understand you question. I don't know whether those "isohybrid.exe" are "untrusted", but they are not an official part of The Syslinux Project (read as "not distributed in official upstream archives"). Moreover, lack of documentation for them would also be a problem, and common users might not know the respective Syslinux versions they are based upon (common users frequently don't know they should match the Syslinux version at all). If one distro is already producing one "isohybrid.exe" (v.4.06 last time I checked), I would tend to think it is also possible for The Syslinux Project to generate such executable for Windows common users (who can't use the C variant without knowing how to build it under cygwin or equivalent, nor can use xorriso's method either). Although not a replacement for the Perl variant (for example under other OS), I would tend to think it would be welcome. Again, The Syslinux Project needs more development-power-time and patches are welcome.> > Have a nice day :) > > Thomas >Regards, Ady.
Hi,> Not being compatible with EFI/GPT is already a problem for the Perl > variant.The relation of both is: isohybrid.in/.pl is being left behind. http://git.kernel.org/cgit/boot/syslinux/syslinux.git/tree/utils/Makefile has: SCRIPT_TARGETS += isohybrid.pl # about to be obsoleted isohybrid.c replaces it feature-wise and adds new features. Only those new features contain the bugs, afaik.> Add the lack of documentation about the differences,... and the fact that http://www.syslinux.org/wiki/index.php/Doc/isolinux still describes the perl script, whereas http://www.syslinux.org/wiki/index.php/ISOLINUX says nothing about isohybrid. Probably one should consolidate the articles about ISOLINUX. A chapter about isohybrid could tell about all three ways to create an isohybrid ISO: isohybrid.c, isohybrid.pl, xorriso.> As you might have read already in prior emails, the Perl variant > might be helpful under some circumstances, e.g. if we consider the OS > itself a dependency.It would need a maintainer, then. A good way to enter this job would to learn about the new features in isohybrid.c, fix the bugs (with my help), and to then port the features to isohybrid.in.> FWIW, I would not want to "declare" it [isohybrid.in/.pl] frozen,It effectively is. And the shape of isohybrid.c is not much better.> I don't know whether those > "isohybrid.exe" are "untrusted", but they are not an official part of > The Syslinux Project (read as "not distributed in official upstream > archives").Neither perl nor .exe are in my knowledge base. But maybe some skilled user of MS-Windows can propose a way to create a widely usable .exe, which must be able to do >= 43 bit byte addressing in data files.> Again, The Syslinux Project needs more development-power-time and > patches are welcome.If i fix isohybrid.c then it will stick to me. After a while it would become the same as the libisofs/xorriso implementation. (I would read MBRs from the SYSLINUX installation, would drop the dependency on libuuid, ... perky changes ...) Have a nice day :) Thomas
> Hi, > > > Not being compatible with EFI/GPT is already a problem for the Perl > > variant. > > The relation of both is: > > isohybrid.in/.pl is being left behind. > http://git.kernel.org/cgit/boot/syslinux/syslinux.git/tree/utils/Makefile > has: > SCRIPT_TARGETS += isohybrid.pl # about to be obsoleted > > isohybrid.c replaces it feature-wise and adds new features. > Only those new features contain the bugs, afaik.I understand that the differences between the 2 variants are related to EFI/GPT/Apple. Whichever they are, the existence of 2 variants is not emphasized enough to common users, much less the differences. The current source of the Perl variant might not have problems when used inside its limitations, but a common user might have no idea of such limitations. Trying to use the Perl variant outside its limitations _is_ a problem _for the user_. I'll go directly to the bottom line: more (user-friendly) documentation is needed.> > > > Add the lack of documentation about the differences, > > ... and the fact that > http://www.syslinux.org/wiki/index.php/Doc/isolinux > still describes the perl script, whereas > http://www.syslinux.org/wiki/index.php/ISOLINUX > says nothing about isohybrid. > > Probably one should consolidate the articles about ISOLINUX. > A chapter about isohybrid could tell about all three ways to > create an isohybrid ISO: isohybrid.c, isohybrid.pl, xorriso.The wiki pages under ".doc/" are based on the respective documentation included in the Syslinux official distribution archives, the others don't, so the latter ones get direct updates in the wiki (it doesn't mean that the wiki documentation is all up-to-date). There are "some" mentions about isohybrid throughout the wiki, but it should probably receive its own page (linked from the ISOLINUX wiki page and from others). Most distros that support/use some variant of isohybrid already include steps to produce isohybrid images, so whatever is added to the Syslinux wiki should really _add_ (not repeat) info. The existence of different variants, their limitations, the requirement for matching the ISOLINUX (e.g. iso*.bin files) version, and the available command line options, are probably relevant points.> > > > As you might have read already in prior emails, the Perl variant > > might be helpful under some circumstances, e.g. if we consider the OS > > itself a dependency. > > It would need a maintainer, then.There is a lot to do in Syslinux, and patches are desired / appreciated / welcome. If the Perl variant is "declared" frozen, people that might be tempted to sporadically send patches might refrain from doing so, whereas a "maintainer" might sound as "too much" for them. Therefore, documenting the differences and being open to receive patches sounds to me a more flexible choice (comparing to deleting it, or to "freezing" it, for example).> A good way to enter this job would to learn about the new features > in isohybrid.c, fix the bugs (with my help), and to then port > the features to isohybrid.in. > > > > FWIW, I would not want to "declare" it [isohybrid.in/.pl] frozen, > > It effectively is. And the shape of isohybrid.c is not much better.I am not part of The Syslinux Project Team, but I am anyway using this opportunity to call for developers to send patches (it doesn't have to be regarding isohybrid; there is a lot to do).> > > > I don't know whether those > > "isohybrid.exe" are "untrusted", but they are not an official part of > > The Syslinux Project (read as "not distributed in official upstream > > archives"). > > Neither perl nor .exe are in my knowledge base. But maybe some > skilled user of MS-Windows can propose a way to create a > widely usable .exe, which must be able to do >= 43 bit byte > addressing in data files.All the "isohybrid.exe" I know of are based on the Perl variant. I don't know what would be needed so to make one based on the C variant. Until someone steps up to the challenge, I think it is worth building one isohybrid.exe from the Perl variant in the official upstream Syslinux (pre-)releases (just as Slitaz does).> > > > Again, The Syslinux Project needs more development-power-time and > > patches are welcome. > > If i fix isohybrid.c then it will stick to me. > After a while it would become the same as the libisofs/xorriso > implementation. (I would read MBRs from the SYSLINUX installation, > would drop the dependency on libuuid, ... perky changes ...)Understandable.> > Have a nice day :) > > Thomas >Just for completeness... The patch sent in http://www.syslinux.org/archives/2014-June/022259.html suggests that the 2 prior bug reports: http://www.syslinux.org/archives/2012-May/017843.html http://www.syslinux.org/archives/2012-May/017871.html might not be the only ones. Regards, Ady.