[syslinux] Module Versioning... and other things

Pete Batard pete at akeo.ie
Tue Mar 8 09:12:48 PST 2016


Well, I still disagree with a lot of what you are positing (because now 
you've turned your tech-savvy isohybrid _user_ into a tech-savvy 
isohybrid _developer_, and there are limits to how far you can go in 
that direction before the laws of physic becoming a barrier to human 
ingenuity), and also you are trying to put words in my mouth (isohybrid 
being used by regular joes) that are the complete opposite of what 
implied. But I don't want to turn this into a flame war either.

I will just state this: There does exist well defined repetitive tasks 
where you get a much greater degree of reliability through automation 
than through human action (no matter how skilled the human). And, again, 
the process I described is actually very straightforward (when you 
remove factors that are actually irrelevant, such as FAT32 conversion 
--because if I though there was an actual need, I could add ext 
formatting to Rufus to alleviate that--, the process boils down to 
replacing an 'isolinux.bin' with the best 'ldlinux.sys' one can find) 
and human-adaptive, which means that, apart from specific corner cases 
that "de-facto" tells me are exceedingly unlikely to ever occur, a human 
can both make the decision of telling the automated process which 
'ldlinux.sys' should be used (without the end-user having to update 
their app) or, that very same human can even build a custom 
'ldlinux.sys' for a specific ISO/group of ISOs... which, if you do 
consider that sky is the limit for a tech-savvy _developer_, you should 
be the first to welcome as a something that alleviates relying on what 
you call "luck".

Regards,

/Pete

On 2016.03.08 15:46, BALATON Zoltan via Syslinux wrote:
> 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
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux



More information about the Syslinux mailing list