[syslinux] Module Versioning... and other things

[Pete Batard]

On 2016.03.08 13:13, BALATON Zoltan via Syslinux wrote:
> For isohybrid
> tech-savvy users are creating a bootable iso (from scratch or converting
> an exiting non-hybrid iso) with all of their brain power available to
> solve problems as they encounter it and (hopefully) understanding what
> they are doing with non-tech savvy end users having nothing to do.

Which doesn't mean that they won't get it as wrong as an automated 
process would. As I mentioned, I've seen reports of ISOHybrids that 
didn't boot in DD mode, but that seemed to work using the Rufus process. 
And you will always be limited by what the "automated process" that is 
the ISOHybrid algorithm can do (which can of course be modified by a 
developer, but so can Rufus' automated process).

> While for iso to usb conversion with Rufus non-tech savvy users rely on
> the expertise put in that software to do this conversion for them
> automatically. So Rufus should be as intelligent as a tech-savvy human
> to do this by itself in the general case.

That's a bit of a stretch, don't you think, considering that we are 
discussing 2 algorithmic processes that are inherently limited by their 
design?

It doesn't matter how smart you are if the automated process from 
creating ISOHybrid limits you. You are treating the ISOHybrid creation 
application as if it was something that will _always_ solve everything 
you throw at it, provided you're smart enough, while at the same time 
saying that automated algorithms (which an ISOHybrid creation tool is) 
are inherently limited. Isn't that a bit contradictory?

We're not inventing a new AI here - we're considering the process of 
converting a Syslinux bootable ISO to Syslinux bootable USB, which is 
something that has limited playfield and variables, which can readily be 
identified, and that you can most certainly devise a reliable automated 
algorithm for. I've done just that, and the lack of Syslinux related 
issues in the Rufus github tracker should be plenty evidence that it is, 
in fact, as reliable as if someone was doing it manually behind the scenes.

Oh, and if you're still not convinced by the above, let me remind you 
that the process I described was also designed so as to leave a part for 
human intervention, as it will attempt to contact a server to download a 
set of files, which can be modified by the person controlling that 
server. So, even as you would like to describe as such, it's not exactly 
bot vs human here...

> You were lucky. There's nothing that would guarantee this in my
> understanding.

Considering Rufus' large user base and the e-mails I get, I know that a 
few people so use Rufus with obscure ISOs.

If I was "lucky", then, I'd expect to be getting quite a few reports of 
Syslinux breakage from my process, whereas this has actually been one of 
the area that has seen the least amount of bugfixes (which you can see 
by yourself by cloning Rufus in git, and looking for "syslinux" in 
commit messages).

Therefore, I believe I do have evidence that backs the fact that "luck" 
has little to do with it (and, by the way, I will take offence to the 
insinuation that a conversion process, which I carefully designed, has 
only been working so far because of "luck").

Yes, I get that you don't like the process because "It's not what 
Syslinux was designed for", and that there does exist a few elements 
that I would qualify as fragile in that process, which I am well aware 
of, and which I _deliberately_ chose not to handle you may consider as 
relying on luck. But you have to realize that I did consider the 
likelihood of these "fragile" parts being triggered during design (which 
was based in part from empirical evidence of what distro maintainers had 
been doing up to that point), and I have further empirical evidence now 
that backs up my initial assertion that these elements would almost 
never be triggered, was correct.

Then again, like the prodigal isohybrid tech-savvy user, I can always 
use my brain to tweak the process should the need arise (especially as 
Rufus does have a solid auto-update process). So I hardly see the part 
where "luck" plays a factor.

> In this case the maintainers could just include the needed ldlinux.sys
> on the iso as well so it can be easily converted.

That would be nice, and this is something I considered asking them to 
do. But as you should understand, it's not a very realistic thing to 
request. Besides, now you've broken the process as soon a new distro 
appears, whose maintainers haven't been alerted to the fact that they 
should place an 'ldlinux.sys', to help users of an application that they 
probably never heard of (because it's Windows only).

Regards,

/Pete