Linux port?

[lukehutch]

Thanks for creating this great utility. I would love to see this ported to Linux, even if only as a commandline tool, since the existing tools often fail for some combination of ISO image, USB stick, BIOS etc. Have you looked into the difficulty of porting the code?

[Masamune3210]

He has stated multiple times that it would be alsmost not worth it if not impossible to port to anything but Windows in the programs current state as the program relies on many different Windows API's to do what it needs
https://github.com/pbatard/rufus/wiki/FAQ#Do_you_plan_to_port_Rufus_to_LinuxOS_XSome_other_OS

[pbatard]

Have you looked into the difficulty of porting the code?

Yup. My most conservative estimate put the effort at a minimum of 6 months, full time work, to do a port that I would consider barely worthy of release.

Oh, and this question gets asked over (#550) and over (#509) and over (#520) and over (#515) (and I could go on!). So, next time, please don't be afraid to use search before asking for something that, in all likelihood, you're probably not the first person to ask.

Besides, it's not like there isn't a dedicated FAQ entry for this very question.

Now, if you really want to know what might be so hard, well...

• First of all, there's the whole UI to redesign from scratch, since it's intimately tied to Windows. Even if using a framework (but then bye bye small size app), you can count at least 2 months of work, especially as I'm already planning on one month of work just to redesign the UI for Rufus 3.0 on Windows only (to better handle positioning, Windows 10 recommended UI elements, high DPI and stuff). [NB: The redesign for Rufus 3.0 actually took 4 months, so, yeah, I hope you'll excuse me for not being too keen on to find out by how much I am off, wrt to my "porting to Linux" estimate...]
• Then there's the whole matter that formatting is not actually done by Rufus, but by asking Windows nicely, to do that for us through one of the numerous native DLLs we have at our disposal. Which works great when you have an OS that has native NTFS support. But suddenly, if you're on Linux, or even worse, OS X (because if you're gonna start porting to Linux, you might as well open the road for OS X), you need to ensure that people have the right dependencies and stuff. Still, that's not exactly the worst...
• The worst is, if you want Windows To Go, or VHD dump (which Rufus happily does), then you're probably going to have to write your own library for it, pretty much from sratch. Yeah, there exist wimlib, but 1) It's a pain to use if you want to remove stuff that you don't need and 2) it doesn't handle the writing of the BCD, without which you're not gonna boot anything To Go anyway. And I'm not even going to talk about the need to have an ISO mounted and accessible before you can do anything to set up To Go (which, to be fair, might be one of the few things that might be simpler to implement on Linux compared to Windows).
• Oh, and God forbid Microsoft do what they usually do, and change their API in a new version of Windows (which they actually did in Windows 10), because then, instead of simply going with the flow, you're going to have to (re)implement whatever it is they did in Linux/OS X just to be on par in terms of features.
• Finally, if you know a good implementation of ReFS for Linux (since Rufus can happily format a drive using ReFS on Windows), I'm all hears. Otherwise, yeah, whatever port of Rufus is being carried out will have to compromise A LOT in terms of features, and then, even as I might have spent more than half a year working on a Linux port, I'll still have to answer a new github request every other week on how difficult it could actually be to allow the Linux version of Rufus to format a drive to ReFS.

I realize that I may sound flippant, but I really wish that people would realize that, yes, there exist a very good reason a Linux or OS X port is not happening anytime soon (and will most likely never happen). Hope that answers your question.

[lukehutch]

Apologies. I did look for an answer to my question before posting, by looking through the open bugs, and I didn't find a match. I didn't spot the link to the FAQ on the project homepage.

To some of your points: Linux does have formatting built in for numerous filesystems, including NTFS, and it has NTFS read/write support built-in too. Linux users would be fine with a commandline utility, and someone else could build the UI, or it could be built into an existing UI at some later date, like gnome-disks. I'm sure porting some features, like Windows To Go, would be hard or impossible, so the Linux version wouldn't have all the same features. Ultimately though this is all moot, since it's your time and your project!

The main reason I'm interested in Rufus is that it appears to do a better job of handling weirdness with ISO formats, filesystems, partition formats, USB flash geometries, BIOS quirks etc. than the existing tools in Linux. Perhaps you could put together a doc at some point (I know you're busy) that describes all the gotchas to writing a bootable USB stick, in technical detail, since the knowledge you have gained through building Rufus is invaluable, and maybe this knowledge could be used to improve the Linux tools.

[pbatard]

I'm afraid I'll have to say: the documentation is already there - it's the Rufus source!
I feel like I'd do a disservice to whoever wants to understand Rufus if I tried to write documentation, because I would most definitely miss critical data, which users would complain about. Heck that actually already happened (The "and adds a line, which github.com/pbatard/rufus/wiki/Targets-Supported does not mention, so thank..." part), so, yeah, there's a reason why most developers won't write doc. It's because someone who wants to truly understand what an Open Source application does is always better off reading the code itself.

As to your other points: Rufus is designed around having an UI. I actually have a >3 year old request around adding commandline support, which I'm deferring because from implementing part of it, I've seen how much of a massive pain it was to turn a UI operation into a commandline one.

With regards to NTFS, there is no guarantee that Linux will have NTFS support, so it'll need to be detected (which is no big deal, but then, what do you do if it isn't present). And NTFS is only one of the many filesystems Rufus supports. I very much doubt that many Linux systems come with exFAT. And what about UDF formatting? Those come native on Windows. And I already mentioned ReFS. So yeah, Linux users will have to contend with 2 file systems (NTFS and FAT32) instead of 5. Or let's talk about the quirks needed for make Windows 7 EFI bootable (need to extract the EFI boot file from a .wim). If we decide to go without .wim Support, then suddenly people can't install Windows 7 in EFI mode. Also, you can forget about MS-DOS, since the files are non redistributable and come from a Windows DLL. Granted, people should be okay with FreeDOS (and Windows 10 did away with MS-DOS anyway), but now the app is starting to look more and more and crippled... and, as I mention in the FAQ, if you are going to remove that many features, your app's going turn out not that different from what you can easily get by installing ms-sys (did you know the newly released ms-sys can install ALL of the boot records that Rufus can handle?) plus Grub or Syslinux. So the question quickly becomes, what's the point of porting Rufus if, in the end, what you're going to be left with is stuff you can already accomplish with a handful of native Linux commandline tools today.

[lukehutch]

OK, thanks for taking the time to explain.

[ghost]

I was trying to use it on raspberry pi with the ARM build with wine but failed for some exception. the pi community doestn have any other option to burn windows images, not even linux ones because I compiled unetbootin and didnt work either.

[Masamune3210]

As far as I remember Rufus relies on too many Windows things to be worth porting. Have you tried etcher?

[ghost]

Ok, i compiled wine 4.x and the rufusarm start on rpi3!... but just like on x86 wine it could detect my usb drives. Ive tried alt f and alt . but nothing. I will keep trying to make it wok.

[Masamune3210]

Because it relies on windows only things. For the second time, have you tried etcher?
Wine will not work with rufus

[blackcrack]

think also on Reactos, this is also at moment a x86 WinNT System (WinNT Server 2013)
Rufus should also work in Reactos ..
you could compile in reactos and this in virtualbox ..
use the bootcd for reactos/Virtualbox : https://reactos.org/getbuilds/

[Masamune3210]

Nope, not using windows dll's and api's, just mimicking them. Maybe sometime in the future, but not right now

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query.