This is the replacement open-source GUI USB imager app I have been waiting for.
> 500KB vs 210 MB
Essentially this is a 99.99999% reduction of disk space and run-time usage with the same functionality which really puts its electron garbage counterpart to infinite shame. There is no contest here.
Feel the satisfying moment of removing this 'balenaEtcher' bloatware and replace it with a true, efficient and magnificent cross-platform native alternative app.
I can't agree more. Using electron to make a simple program into a 200MB behemoth just so you can draw a window and some text with javascript is a slap in the face to your users.
It would be an interesting test to test all USB imagers alongside one another, and then use a different USB imager than the one used to write the USB stick, to verify it.
Or, use every USB imager other than the one used as the writer -- to perform multiple verifications...
Perhaps one would find interesting discrepancies in some, but probably not all, USB imaging softwares -- that way...
Anyway, this one seems to deserve some points for being quite close to as simple as possible, with as minimum dependencies as possible...
Seems to me the imaging is more perfect than the subsequent hardware interaction.
Different USB drives and controllers can have greatly dissimilar working geometries as they carry partitions & filesystems, so the hardware is not really interchangeable enough to begin with for direct imaging to be a very reliable means of getting a different partition and/or filesystem onto a flash drive for instance.
The working layout may or may not be based on the _native_ detected geometry of the device.
And mainboards can have their preferences as to which geometries they prefer and when.
This can make data appear to disappear depending on where you plug in the USB drive, and more commonly cause difficulty booting.
The IMG file of a floppy disk is standard but the blank disk always needed complete perfect sectors to write the IMG to, afterward their FAT12 filesystem was universally accessible and bootable just like it had actually been formatted indivdually by standard MSDOS. It was just a clone.
The ISO of a CDROM is standardized too.
USB drive behavior is not very standard, so an IMG or DD type file captured from a particular device can not be expected to perform indentically unless it is restored in an identical way to the original device or an equivalent device which has no show-stopping dissimilarity.
Since the beginning until just recently USB flash drives were sold pre-formatted with FAT32. Now they are just getting too big for FAT32, so over 32GB has NTFS.
Now not always will most of the drives in the world have been originally formatted with very Microsoft-compatible procedures. At least one major supplier has a fundamental formatting error propagated for years. Different mainboards will tolerate this to different degrees.
Depending on what you start with the image you capture might not be the best to rely on.
Defragmentation can also be an issue to work around.
A Live Linux distribution intended for direct _burning_ to flash drives is not a good distribution method compared to burning the ISO to disk.
Rufus is good because it takes a bootable ISO and writes it in a file-based way onto just about any USB device, and various USB drives end up more bootable than you can get from perfectly copying a prepared master image bitwise.
Suggestion for the developer if they see this - please add a PayPal or other donation option in addition to BTC. Just a bit too much friction on BTC for normals/muggles like me, but if there was a PayPal link you might have had money in your account by now.
I want to support this just because of what it represents - native app development, small executables, tools that are optimized. None of this bloated Electron junk. I bet they could even put some Etcher like graphics / PNGs into this interface and it would still be 100x smaller than Etcher.
I wonder if it would be possible to port this natively to Haiku too?
Is a more portable way to do that, as "status=progress" is a GNU modification to dd, as I recall. Of course the most portable is to use one of the POSIX mainstays like cat or cp.
29 comments
[ 5.4 ms ] story [ 57.6 ms ] threadThe size versus Etcher -- 256 kb to 210 MB -- makes this worth checking out!
This is the replacement open-source GUI USB imager app I have been waiting for.
> 500KB vs 210 MB
Essentially this is a 99.99999% reduction of disk space and run-time usage with the same functionality which really puts its electron garbage counterpart to infinite shame. There is no contest here.
Feel the satisfying moment of removing this 'balenaEtcher' bloatware and replace it with a true, efficient and magnificent cross-platform native alternative app.
The binary size on windows is actually only 268KB
Not sure why one would choose it, when there are so many options.
It was bigger than the .img I wanted to write, and that was a whole distro!
Or, use every USB imager other than the one used as the writer -- to perform multiple verifications...
Perhaps one would find interesting discrepancies in some, but probably not all, USB imaging softwares -- that way...
Anyway, this one seems to deserve some points for being quite close to as simple as possible, with as minimum dependencies as possible...
Maybe Etcher accomplishes some of this too.
Seems to me the imaging is more perfect than the subsequent hardware interaction.
Different USB drives and controllers can have greatly dissimilar working geometries as they carry partitions & filesystems, so the hardware is not really interchangeable enough to begin with for direct imaging to be a very reliable means of getting a different partition and/or filesystem onto a flash drive for instance.
The working layout may or may not be based on the _native_ detected geometry of the device.
And mainboards can have their preferences as to which geometries they prefer and when.
This can make data appear to disappear depending on where you plug in the USB drive, and more commonly cause difficulty booting.
The IMG file of a floppy disk is standard but the blank disk always needed complete perfect sectors to write the IMG to, afterward their FAT12 filesystem was universally accessible and bootable just like it had actually been formatted indivdually by standard MSDOS. It was just a clone.
The ISO of a CDROM is standardized too.
USB drive behavior is not very standard, so an IMG or DD type file captured from a particular device can not be expected to perform indentically unless it is restored in an identical way to the original device or an equivalent device which has no show-stopping dissimilarity.
Since the beginning until just recently USB flash drives were sold pre-formatted with FAT32. Now they are just getting too big for FAT32, so over 32GB has NTFS.
Now not always will most of the drives in the world have been originally formatted with very Microsoft-compatible procedures. At least one major supplier has a fundamental formatting error propagated for years. Different mainboards will tolerate this to different degrees.
Depending on what you start with the image you capture might not be the best to rely on.
Defragmentation can also be an issue to work around.
A Live Linux distribution intended for direct _burning_ to flash drives is not a good distribution method compared to burning the ISO to disk.
Rufus is good because it takes a bootable ISO and writes it in a file-based way onto just about any USB device, and various USB drives end up more bootable than you can get from perfectly copying a prepared master image bitwise.
I want to support this just because of what it represents - native app development, small executables, tools that are optimized. None of this bloated Electron junk. I bet they could even put some Etcher like graphics / PNGs into this interface and it would still be 100x smaller than Etcher.
I wonder if it would be possible to port this natively to Haiku too?
- Rufus: https://rufus.ie/
- UNetbootin: https://unetbootin.github.io/
- Win32 Disk Imager: https://sourceforge.net/projects/win32diskimager/
- Ventoy https://www.ventoy.net
usbimager_1.0.4-i686-win-gdi crashes without error and leaves a USB corrupt (works fine again after a format)
As simple as
sudo dd if=name-of-iso.iso of=/dev/sdb status="progress"
https://medium.com/@tbeach/use-unix-dd-command-to-os-bootabl...
You're Welcome.