> > > > I don't like the idea of changing "UI" (e.g. command line options that > > might be used by some users) without very well-thought reasoning. > > This is not an UI. AFAIK, this script is not shipped to the user. I > don't even see what a user could do with it. > >Well, the Perl script _is_ shipped in the official release, and the change we are referring to is a command line parameter, which means it is part of the way a "user" (which I am using here as a generic term, not necessarily a final non-developer physical individual) interacts with the code. I also added, more than once, the general scope of my comments, as opposed to taking the very specific case of this particular Perl script. Reading the complete email (for context) is relevant.> > > > In the particular case of "padsize" vs. "maxsize" (options / parameters > > of the Perl script), there used to be a separate use of them. Although > > there _seems_ to be no use for having both of them simultaneously at > > this time _for a normal build of Syslinux_, we cannot discard / > > disregard the possibility that some script in some distro might want to > > take advantage of each of them independently, especially for some > > debugging situation (e.g. some buggy / old BIOS). > > > > Another potential (hypothetical) use-case might be some "bootable USB > > tool" making use of some/many/all parts of the Syslinux code. Let's not > > forget that some distros are still using older versions of Syslinux > > (even v. 3.xx), and (unnecessarily) changing command line options makes > > the updates (unnecessarily) more difficult, generally speaking. > > Keeping some legacy in the compilation chain for a potential usage > we're not even aware about seems a bit insane. If someone play with > the syslinux's internal compilation process, he is probably aware that > it may change completely on every single commit. We just do not > support this usage. >The example I gave (moving the location of binary files) could also be included in such category; after all, the location of binary files in prior versions is "legacy" too, and it doesn't affect the compilation of the new resulting version. And yet, it had (and still has) a clear impact on "users" (and by "users" I don't just mean final users, but rather package maintainers, other scripts, common users, and more).> > PS: Let's also not forget the existence of other methods / code to > > generate / install MBRs and/or VBRs such as: > > _ "sys.com" / "sys.exe" (v.3.8) from FreeDOS; > > _ "sys-freedos-linux"; > > _ "ms-sys" ( _code in C_ ) and its forks such as: > > _ "ms-sys-free" (current latest code is older than its parent); > > _ a fork of "ms-sys" by Pete Batard (used in RUFUS) with additional > > recent patches. > > These projects are completely unrelated to syslinux. Should someone > use our checksize.pl, he would probably copy it to his repository. As > I said, this script isn't shipped to the user. The only purpose of > this script compared to the standard command "truncate" is that it has > several default size recorded depending on the file name pattern and > fail if the file is already too large. >My "PS" in my prior email is/was not directly related to the Perl script, nor to the specific patch (thus, it was written after my signature, as a "PS"). It was about the generation of the "*mbr*.bin" files (which is the goal of the Perl script in question). Mentioning those projects is a way of inviting the potential investigation (by developers) of alternative ways of delivering MBR (and VBR) files and their installers in Syslinux.> > > > Common users and third-party scripts might rather use the Perl script > > for simplicity, so having scripts available is helpful. Having code > > written in C for the generation / installation of MBRs / VBRs might be > > (at least in part, or as a first step) an alternative to the generation > > of the current syslinux / extlinux installers, and/or eventually an > > alternative installation method. > > This script just extend the file to the size of the boot sector and > fail if it's too large. Nothing more. It has very little to do with > the installers.The current installers include "ldlinux.*", which makes the them version-dependent. If the "real" installation code were to be separated, and the "ldlinux.*" files were to be arguments of such hypothetical alternative command line installer(s), we could have installers that could be independent of the version. It could simplify several situations / use-cases (while making other cases more complex), and in some cases it could even reduce the resulting size for users -- incidentally, I wrote about this matter in irc #syslinux just a few days ago. Again, this was part of a "PS", not directly related to the original patch.> > Don't try to invent new use cases or new goals for the Syslinux > project.We provide a set of boot loaders and installer for those boot > loaders. Not a set of tools to help people make their own boot > loaders.The interaction with (other) code / users, either within or outside of The Syslinux Project, is the relevant point I was trying to make. This seems to be one of those different points of view between developers and users (including maintainers of packages and of generic installation methods in several distros); we see things with a different perspective.> > > CelelibiRegards, Ady.> _______________________________________________ > Syslinux mailing list > Submissions to Syslinux at zytor.com > Unsubscribe or set options at: > http://www.zytor.com/mailman/listinfo/syslinux >
2015-11-20 8:15 UTC+01:00, Ady via Syslinux <syslinux at zytor.com>:>> > >> > I don't like the idea of changing "UI" (e.g. command line options that >> > might be used by some users) without very well-thought reasoning. >> >> This is not an UI. AFAIK, this script is not shipped to the user. I >> don't even see what a user could do with it. >> >> > > Well, the Perl script _is_ shipped in the official releaseMy bad. I only checked the debian packages, none of them include a file named checksize.pl. I just checked the official release, it actually include the whole source tree. Does that mean we can't change any argument of the shell or perl scripts or any target of the Makefiles? Of course not.> >> > >> > In the particular case of "padsize" vs. "maxsize" (options / parameters >> > of the Perl script), there used to be a separate use of them. Although >> > there _seems_ to be no use for having both of them simultaneously at >> > this time _for a normal build of Syslinux_, we cannot discard / >> > disregard the possibility that some script in some distro might want to >> > take advantage of each of them independently, especially for some >> > debugging situation (e.g. some buggy / old BIOS). >> > >> > Another potential (hypothetical) use-case might be some "bootable USB >> > tool" making use of some/many/all parts of the Syslinux code. Let's not >> > forget that some distros are still using older versions of Syslinux >> > (even v. 3.xx), and (unnecessarily) changing command line options makes >> > the updates (unnecessarily) more difficult, generally speaking. >> >> Keeping some legacy in the compilation chain for a potential usage >> we're not even aware about seems a bit insane. If someone play with >> the syslinux's internal compilation process, he is probably aware that >> it may change completely on every single commit. We just do not >> support this usage. >> > > The example I gave (moving the location of binary files) could also be > included in such category;No. I specified "in the compilation chain". Because this script is only this: one tool used to build the binaries. Same would go for the following files: - efi/wrapper.c - lzo/prepcore.c - core/lstadjust.pl - utils/bin2hex.pl - **/*.pl They're all just some custom tools when a single shell line in the Makefiles would be too clumsy. Best regards, Celelibi
> 2015-11-20 8:15 UTC+01:00, Ady via Syslinux <syslinux at zytor.com>: > >> > > >> > I don't like the idea of changing "UI" (e.g. command line options that > >> > might be used by some users) without very well-thought reasoning. > >> > >> This is not an UI. AFAIK, this script is not shipped to the user. I > >> don't even see what a user could do with it. > >> > >> > > > > Well, the Perl script _is_ shipped in the official release > > My bad. I only checked the debian packages, none of them include a > file named checksize.pl. > I just checked the official release, it actually include the whole > source tree. Does that mean we can't change any argument of the shell > or perl scripts or any target of the Makefiles? > Of course not. > > > > >> > > >> > In the particular case of "padsize" vs. "maxsize" (options / parameters > >> > of the Perl script), there used to be a separate use of them. Although > >> > there _seems_ to be no use for having both of them simultaneously at > >> > this time _for a normal build of Syslinux_, we cannot discard / > >> > disregard the possibility that some script in some distro might want to > >> > take advantage of each of them independently, especially for some > >> > debugging situation (e.g. some buggy / old BIOS). > >> > > >> > Another potential (hypothetical) use-case might be some "bootable USB > >> > tool" making use of some/many/all parts of the Syslinux code. Let's not > >> > forget that some distros are still using older versions of Syslinux > >> > (even v. 3.xx), and (unnecessarily) changing command line options makes > >> > the updates (unnecessarily) more difficult, generally speaking. > >> > >> Keeping some legacy in the compilation chain for a potential usage > >> we're not even aware about seems a bit insane. If someone play with > >> the syslinux's internal compilation process, he is probably aware that > >> it may change completely on every single commit. We just do not > >> support this usage. > >> > > > > The example I gave (moving the location of binary files) could also be > > included in such category; > No. > I specified "in the compilation chain". Because this script is only > this: one tool used to build the binaries. Same would go for the > following files: > - efi/wrapper.c > - lzo/prepcore.c > - core/lstadjust.pl > - utils/bin2hex.pl > - **/*.pl > > They're all just some custom tools when a single shell line in the > Makefiles would be too clumsy. > > > > Best regards, > CelelibiI seem to be failing to express my point clearly. I'll try one last time. My comments were generic, not specific to the patch, nor to the Perl script. Previous proposed patches (before the one about the checksize.pl script) sent by Nico don't seem to have interaction with external factors (although, there was at least one factor that was taken in consideration in a later commit, after I brought it up in irc #syslinux). If I am not mistaken, dependencies (e.g. mtools) and (root) privileges were not changed in prior proposed patches, neither parameters used in scripts nor user input. Being part of the arguments of the current normal procedures for building Syslinux (whether in use or not), or some optional script, or some file location, are some of the many examples in which there is some kind of interaction (between scripts, users, third-party tools...). The proposed patch for the checksize.pl script changes the potential arguments. In the current context of these comments, which are _generic_, I do not care whether the code is improved, nor whether the optional parameter that was eliminated was not being normally used in the current building steps. The only thing I am focusing on in my present comments is that there is some kind of interaction, and that it is being changed. The assumption that "something is not really being used so let's simplify it by eliminating it from the code" is frequently not evaluated to its fullest, and finding that such elimination was not %100 adequate usually takes a lot of effort, including from common users testing the results. When the elimination of code affects some kind of interaction, the effects are even more difficult to predict, and therefore the eventual correction needs even more resources. Instead of "elimination", the action could had been any kind of change related to any kind of interaction, and the main point of my comments would have been the same. I am going to say it again: this is a generic comment, not specific to the patch nor to this Perl script in particular. Some code that is "so clear that it can be improved in a certain manner" for one developer at a certain time / moment might not be so. I can give many examples, including a very recent one in the Syslinux development, but that's besides my point. Considering that: _ Nico is new to the code; and that, _ there are very few developers that actually have enough experience with different (use) cases with the storage-related installers in Syslinux; and that, _ beta testers in Syslinux are also very few; then... ... I decided to comment about what _I_ consider a potential interaction. I am well aware that developers might have a different point of view, and therefore I express this concern of mine _now_. For instance, if someone would had expressed similar concerns when the binaries where moved to the "bios/" sub-directory, _perhaps_ the negative comments and strong complaints (and many, many problems) such move caused (and still causes) _might_ had been re-evaluated. Maybe the resulting decision would had been the same, or maybe not, or maybe the move would had been much better communicated, or maybe package maintainers would had been consulted for suggestions, or... There are other cases of interaction changes that brought some degree of headaches; the "offset" parameter or the use of "-i" for installers are just 2 of them, which I mention because they are clear examples. Other examples were seemingly not so clear at the time, but impact they had. I took this opportunity to express a _generic_ comment / concern, and I do it when it might count for something, before it might be too late. We are all genius after the fact, right? Whether this particular suggested patch could have a minor impact, a greater one, or none at all, is not my main point. After all, the main Syslinux's developers will decide. So, the replies to my comments are being "too-specific", related only to the specific patch, or to the specific current use of the script, as if I had made my comments in direct relation to the particular patch. I don't think I expressed it in such way, and I clearly mentioned the "generality" of my comments several times in all my posts in this email thread. The patch was only a trigger, an excuse, an oportunity. I think I'm done with the matter. Regards, Ady.> _______________________________________________ > Syslinux mailing list > Submissions to Syslinux at zytor.com > Unsubscribe or set options at: > http://www.zytor.com/mailman/listinfo/syslinux >