[syslinux] Module Versioning... and other things

BALATON Zoltan balaton at eik.bme.hu
Tue Mar 8 07:46:28 PST 2016


On Tue, 8 Mar 2016, Pete Batard via Syslinux wrote:
> 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).
[...]
> 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?

No because a tech savvy human can modify the iso hybrid tool if it does 
not do what he wants but the automated process used by a non-tech savvy 
user can only rely on the intelligence already built into the automated 
process. Yes, you can change the automated tool and fix it and make it 
work the next time but I think it's not the same fixing iso hybrid for a 
specific problem of a single iso than creating an automated process for 
all possible and unknown cases that it can encounter. The latter is 
significantly more complex in my opinion. Which is OK if you take up this 
endeavour, it just can become arbitrarily complex with no clean solution. 
(I think the difference in your thinking that you also assume iso hybrid 
creation tool will be used by non tech savvy users and has to be automated 
while I regard it as a tool only used by experts creating the isos who can 
get what it's doing and fix it if needed.)

> 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.

This is truely a great achivement, I did not mean to question that. Within 
a limited playfield it can indeed be solved but if there are no guarantees 
that you won't leave this playfield there are no guarantees that it will 
work outside that as well other than luck.

> 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").

I did not mean to offend you and sorry if I did. What I meant was that you 
were lucky that there were no incompatible changes made in the part of 
syslinux so far that you were relying on, so a replacement worked even 
with a slight version mismatch. But there's no guarantee for this and that 
is the stem of your problem. The versioning should guarantee that binaries 
with the same version are compatible but it does not now. This is what 
interface versioning should guarantee (or more strict release versioning). 
But I may be wrong and still not get the problem completely.

> 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.

It's not personal or because it's not what syslinux was designed for that 
I don't really believe in an automated process, but because of the 
inherent fragility of relying on elements that just not happened so far 
but could break any time without your control and having no way to remove 
all of this fragility. I don't think it can be solved generally but only a 
pragmatic solution could work within limitations and that needs to be kept 
up constantly for changes in distros. It is not an easy task and respect 
for taking up this difficult task.

I did not mean to turn it into a flame war and I hope we can agree on that 
our views are different but I'm not against of anything that could help 
what you are doing. Just wanted to discuss and share my views but we don't 
have to convince each other.

Regards,
BALATON Zoltan


More information about the Syslinux mailing list