Etcher - A simple way to "burn" disc images to SD cards and USB drives

[Deozaan]

I recently discovered Etcher, which is a nice utility you can use to easily write disc images to USB drives and SD cards. It's great for things such as bootable Linux Live OSes or flashing an SD card for an IoT/SBC device.

Some notable features:

• It prevents you from overwriting your internal drives.
• It verifies that the media was flashed correctly.
• It's cross platform, working on Linux, Windows, and MacOS.
• It's portable. No need to install.

Check it out at etcher.io

[Shades]

How is this better than, for example: Rufus?

[Deozaan]

I've never actually used Rufus, so I can't say I'm especially qualified to answer that question. But I do have it in my PortableApps folder, so I ran it real quick and I can see it's a lot more complicated than Etcher.

That's not to say that it's impossibly difficult to figure out. And in some cases those advanced features in Rufus may be wanted or needed over what Etcher provides.

My impression of Rufus from looking at it for a minute or two is that it seems to be a USB drive formatter, which also offers flashing images to the drive as an almost hidden feature. And on that note, it seems Rufus only accepts .iso formatted files. Etcher supports a variety of formats, such as iso, zip, img, dmg, raw, xz, and more.



So that's one way in which Etcher is ostensibly better than Rufus.

That said, I'm not saying it's absolutely better than everything else in every way possible. But I like that it's simple, straightforward, and does what I need without complicating things. I feel like I could send a link to Etcher and a disc image to a person who is "computer illiterate" and trust that they could operate it successfully on their first try. And since most of the time when I'm flashing an image onto a drive I don't care for any other settings or customizations and just want the drive to have the data on it, Etcher will fit my needs 99% of the time.

And since it hasn't been mentioned here before, I thought the good folks of DC might be interested in learning about it.

[Shades]

For me it is weird that a tool like Rufus (which writes .iso, .img, .zip, .vhd, .gz, .bzip2, .xz and .lzma files) only needs around 850KByte to its job, while Etcher claims more than 18MByte for doing the same, while hiding everything in a dreadfully simple interface. Rufus has always been among the fastest when writing an .iso/.img file as boot-able pen drive. It even allows you to make a portable hard disk boot-able if you so desire (but that requires the portable hard disk to be formatted).

Etcher comes with an interface that is dreadfully similar to a lot of websites today. All graphics and barely any useful content. I guess that is what is Etcher's most appalling "feature" to me.

[wraith808]

I guess the question I'd have, and one I've been pondering lately is, why does either have to be better or worse?  If you don't like the interface, then don't download it.  Too many times developers (including me, which is why NANY is hard for me at times) think that unless they have a new idea, they have nothing to say.  It's not just in development, but writing, art, movies, etc.  And it's not just about the product itself, but about the themes.  As long as it does what it says it does, and there isn't a non-obvious flaw that would be a potential weakness to those that are using it, and that they might not know, then just introduce people to other software (I'd not heard of rufus) while getting away from the negativity towards them.

And as far as the size and what they're doing- both are open source.  Neither is hiding anything.  The size is probably due to libraries or something, but I haven't looked.

Just my opinion, and something I've been thinking about a lot lately.

[Deozaan]

For me it is weird that a tool like Rufus (which writes .iso, .img, .zip, .vhd, .gz, .bzip2, .xz and .lzma files) only needs around 850KByte to its job,

-Shades (August 19, 2017, 01:15 PM)

Thanks for correcting my misonception about what filetypes Rufus is capable of writing. Like I said, I'd never really used it before and in my couple minutes of playing around with the interface to check it out real quick it seemed like .iso was the only format it would allow me to browse for.

while Etcher claims more than 18MByte for doing the same, while hiding everything in a dreadfully simple interface.
[...]
Etcher comes with an interface that is dreadfully similar to a lot of websites today.

-Shades (August 19, 2017, 01:15 PM)

The filesize and website-like interface are probably both explained by the fact that it essentially is a website. So in order to be portable it has to bundle an HTML engine, JavaScript engine, etc, for the consistent look across all platforms.

[highend01]

Etcher-Portable-1.1.2-x86.exe

stores it's setting inside %APPDATA%\etcher?

Very portable, indeed...

35MB vs 1MB (Rufus)

and while Etcher is still "trying" to show it's interface (after doubleclicking the .exe),
I've written half of the netinstall iso (Debian Stretch) to the USB 3 stick (Rufus)

There are things in life that I don't want to waste my time with. Etcher is clearly one of them...

[cthorpe]

I recently "burned" a bunch of SD cards for a bunch of Raspberry Pis.  I found that Etcher was considerably slower than the copy of Win32DiskImager (.07) that I've had kicking around for years.  I didn't time it or anything, but I'd say it was at least twice as long with the exact same card and image file.

https://sourceforge....cts/win32diskimager/ (Yeah, it's sourceforge. I know.)

Etcher did seem "safer" and "prettier."  But the speed when trying to prep 15 cards was a deal-breaker.

I'm on Win 10 64bit.

[Deozaan]

I've updated the topic to change the word "better" to "simple" since that seems more accurate.

I recently "burned" a bunch of SD cards for a bunch of Raspberry Pis.  I found that Etcher was considerably slower than the copy of Win32DiskImager (.07) that I've had kicking around for years.  I didn't time it or anything, but I'd say it was at least twice as long with the exact same card and image file.

-cthorpe (August 23, 2017, 11:28 AM)

I wonder if the extra time it took has something to do with Etcher verifying the image was "burned" correctly as part of the process.

[kfitting]

Wraith, I've also been thinking the same thing recently. I think Deozaan's answers have helped advance that idea.

I've often wondered how many times watching "brilliant" artists on YouTube has stifled inspiration. It certainly can inspire, but I agree that we have this idea that there is an underlying current of thought that we need to do something never been done before.

[4wd]

Just tried Etcher x64 portable on my Win10Pro x64 laptop:

• Continually tried to access the net to report usage statistics until told not to.
• Tried to access the net anyway - no way to turn off.
• On running: "Couldn't scan the drives: An unknown error occured" - even though every other program could see them fine.  This might be because I didn't give it net access which it shouldn't need.
• When a bootable ISO was selected it told me it didn't appear to be bootable, (UNetbootin read/wrote it OK).
• Couldn't select a output device because there apparently wasn't one "No removable drive detected" - despite every other program seeing it.

Easier? No.
Simpler? No, there are easier ways to do nothing.

Think I'll stick with UNetbootin. 

[Deozaan]

If you're feeling so inclined, they may appreciate hearing about your experience so they can fix the issues that led to such a poor experience for you.

https://github.com/r...sin-io/etcher/issues

[f0dder]

The filesize and website-like interface are probably both explained by the fact that it essentially is a website. So in order to be portable it has to bundle an HTML engine, JavaScript engine, etc, for the consistent look across all platforms.

-Deozaan (August 19, 2017, 02:12 PM)

I wish people would stop doing this.

It's OK if you use the webby stuff for core functionality anyway, but it's bloated and borderline insane to bundle so much crap just because you're lazy.

[ewemoa]

Aren't most electron-based things at least this size?