Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

USBImager – A minimal GUI app that can write disk images to USB drives

gitlab.com

Post reply on HN
Print view View original

11–20 of 30 posts

Re: USBImager – A minimal GUI app that can write disk images to USB drives

#11

Post by colejohnson66 »

mbroncano wrote: post #7
mig39 wrote: post #6

Earlier quoted context omitted.

balenaEtcher has advertising for sure. Not sure about spyware.

It’s debatable whether there’s an actual difference nowadays.

I can’t really see it as spyware if it’s your own product, though.

Re: USBImager – A minimal GUI app that can write disk images to USB drives

#12

Post by fizzled »

rvz wrote: post #3

YES. 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 magnifi…

What, do you have a 30MB drive or something? Did you ban all applications over 1MB?

Re: USBImager – A minimal GUI app that can write disk images to USB drives

#14

Post by SyneRyder »

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?

Re: USBImager – A minimal GUI app that can write disk images to USB drives

#17

Post by fuzzfactor »

peter_d_sherman wrote: post #4

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 des…

This does seem like excellent work.

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.

Post reply on HN