Why didn't Rufus become a multiload creation tool? [closed]

Why has Rufus not added support for adding bootable images to USB without subsequent re-formatting, such as Windows1, Windows2... or Windows1, Linux1...? Why didn't Rufus become a multiload creation tool?

Solution 1:

Rufus dev here. This is answered in our FAQ, but to elaborate a bit further:

1. Because, despite what proponents of multiboot are usually adamant about, that vast majority of people creating bootable drives will only ever boot a specific image once, and never need to use it again (especially these days where any ISO older than 6 months is most likely obsolete). So it's actually a minority of power users, or bona fide sysadmins, that may need to have a 512 GB USB drive filled with all sorts of ISOs "just in case".
2. However, Rufus is actually not developed for sysadmin/power users, but instead it is designed for the casual user that needs to boot a specific ISO to install a specific OS right now, and, once that's done, is likely to reformat the drive for some other purpose. So I very much prefer investing my limited development time on making sure that this specific usage works, and works well. Throwing multiboot into the mix would either degrade that experience or, as I believe the Ventoy developer has found out, require a large continuous time investment making sure that the utility is fine tuned so that such and such ISO can be supported by the multiboot method.
3. Speaking of Ventoy (which is probably what you are looking for, and we are always happy to point people looking for a multiboot utility to Ventoy), and while we think their method of supporting multiboot is pretty nifty, one of the concerns we have is that this requires injection of content into the original ISO data, whereas we very much designed Rufus to never alter the ISO content (the small exception to this being some GRUB/Syslinux config files to accommodate for the limitations of FAT32, but if the distro maintainers do their job properly, this shouldn't be needed). So our concern is that, should Microsoft or Linux distro maintainers start to validate the trust chain for the boot content being executed, the method used by Ventoy to provide multiboot (which for Windows requires replacing Windows\System32\winpeshl.exe with an executable that wasn't produced by Microsoft) would immediately be rendered obsolete. And as you should know, there is definitely a push for OSes to add more extensive validation and trust for the boot process. Now, that's not to say that we envision that happening anytime soon, especially as Microsoft most likely has loads of corporate customer that rely on the ability to inject custom executables for their installation process. But we can't help but be concerned that anything that requires injection to be able to function may be rendered obsolete on a whim by the OS manufacturer, whereas that problem is very unlikely to happen when you don't need injection in the first place, which a non-multiboot utility like Rufus doesn't. But, please don't misconstrue this statement as a diss on Ventoy, because quite frankly the creator of Ventoy deserves a lot of credit for figuring out an awesome generic method of adding support for reading the ISO content and, even as that wouldn't have changed my stance on multiboot, I kind of wish I had thought of something as clever as that myself.

In summary, multiboot that doesn't suck and that is likely to work in the long run is hard, because optical boot and USB disk boot are completely different beasts, usually using widely incompatible methods that are difficult to make work together nicely (and, again, props to Ventoy for figuring out a way to make it less sucky). So we estimated that both the cost/benefit ratio was too high and also (though this is of course an educated guess, that you are free to disagree with) that, unless someone is a sysadmin, they are most likely going to waste more time trying to maintain a multiboot USB than simply recreating a single boot USB for the image they need to use right now. As a result of this, we decided that spending time implementing multiboot in Rufus wasn't a good investment.