On Tue, 8 Mar 2016, Pete Batard via Syslinux wrote:> On 2016.03.08 03:10, BALATON Zoltan via Syslinux wrote: >> The difference is that the >> headache in this case is for those tech savvy people creating the hybrid >> iso who should be able to figure it out so the non-tech savvy end users >> should not have a problem with it as long as used as intended. > > You're trying to reframe the context in a direction that was never there. My > context was always the one of tech savvy developer trying to create a > bootable USB from an ISO (be it in a process that automates this creation or > something else, with the goal of making the result easy to use for non > teach-savvy users). So I don't think you can go around saying "Ah, but > ISOHybrid is for this context and the ldlinux.sys replacement is for that > context", when, in essence, those contexts are the same.I really don't think these are the same context. 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. 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. This seems to be a bit more difficult to me. I don't think hybrid isos are a better solution just easier to program than an automatic conversion because the problems to solve by software is not the same.>> (But then trying to use a >> substitute part from a release for this customised version would likely >> break too.) > > How so? I would argue that, on the contrary, it's very unlikely that people > will modify the Syslinux core files, as opposed to tweaking a module that > does something close to what they, but not quite. My experience so far has > been that replacing 'ldlinux.sys' by the closest official Syslinux version > always works and I haven't seen a single case, so far, where it didn't.You were lucky. There's nothing that would guarantee this in my understanding.> In other words, as surprising as it may seem, it is my understanding that > most Linux distro maintainers are very conscious that what they put on an ISO > may end up on a FAT filesystem, and will therefore try to ensure that it will > work there. At least I know the Debian people are (and will fix issues > related to copying to FAT32 when they arise [1])In this case the maintainers could just include the needed ldlinux.sys on the iso as well so it can be easily converted. This is the same as including it in isolinux.bin. Although it's probably easier to do this once in syslinux then have all the packagers pick it up with the next release than having all of them make a change independently. I'm not against this change and I don't have a word on what's included in syslinux so you don't have to convince me. Although as you said, with new machines having UEFI and missing CD/DVD drives this problem could resolve itself by USB boot images replacing ISOs as the preferred boot media in the near future. (Or even boot over http can become the most used way.) Regards, BALATON Zoltan
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
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