Yes, Balena Etcher is popular, and it works well on different operating systems, but it's EXE installer is over 140 MB. That's far, far more than is needed for this functionality. Compare Balena Etcher on Windows to Win32DiskImager, which needs only 12 MB. UNetbootin accomplishes this with just 5 MB. Rufus gets it done with just over 1 MB. That's all you really need on Windows to accomplish this task.
On macOS, no 3rd party software is even required at all. It has a graphical Disk Utility program that makes this easy to do. Major Linux distros also have built-in GUI programs for this. For cross platform GUI, this Usbimager tool appears to fulfill the need too.
The bloat and potential attack surface of Balena Etcher makes me unreasonably sad. I would like to see less of it.
The only one I found consistent working is Rufus, it always works for me. Gparted, Linux Mint, Ubuntu, various distro and it works great with Windows ISO (even there is a Windows Media Creator). Rufus is only one so far in my experience that handles everything perfectly. Rufus is basically VLC of USB bootable utility, whereas Balena Etcher is Windows Media Player without all of the codecs (the original window version, not the MPC-HC/BE).
After writing a usb boot disk, it automatically switched to my external drive media instead of selecting nothing at all. I had to do another and after plugging the same drive back in, I wrote to the external drive media instead. I lost several personal things that day and paid for some recovery software.
The safe thing to do here was to not to automatically select some high-volume media.
I hope it didn't devolve into something that doesn't just work.
If usbimager takes off and becomes the default, cool, but I’ll take boring reliable Etcher over some trendy new thing any day.
-rwxr-xr-x 1 root root 79K Dec 5 2020 /usr/bin/dd*
That said, I imagine I’d have a different opinion if I used Balana Etcher like I do Slack: a lot, every day. I imagine some sysadmins out there somewhere do. So I’m glad they have a non-Electron alternative.
Especially for an app like Etcher, which I'm guessing most people set-and-forget until they need it. Most people aren't constantly burning ISO's onto USB's.
Like yeah, I don't like the idea that everything using Electron includes and runs an entire browser API every time they execute.
But these days 140 MB is chump change. Unless you're on Hughesnet, I get the impression most users have the disk space and bandwidth to deal with a one-time download of 140 MB.
Yes, it'd certainly be nice if it could be 5 MB instead. It's pretty stupid that applications of old could probably do the same stuff with even less than that, but today we just use applications as dumping grounds for imported modules. At the same time, I think we are kind of living in the past when it comes to being concerned about megabytes. Countless people stream gigabytes of video daily.
The reason I am more concerned with browser APIs than bandwidth is because more code running in memory means more things to either potentially go wrong or be exploited.
Even then, that's not really high on my list of concerns.
Yes. I have a 1 GiB/month cellular data plan. If I'm on the go, or my home internet is down (like it is now), that 140 MB is a seventh of my internet for the entire month.
If you live in Africa and have a connection like Ben Kuhn, 2.6 mbps[1], then downloading that 140 MB installer will take over 7 minutes, while a 5 MB installer will take 15 seconds, and Windirstat's 630 KB will take about 2 seconds.
If you have a 16k connection from Ethiopia[1], then 140 MB takes almost 20 hours to download (5 MB is 43 minutes, 630 KB is 5 and a half minutes). Good luck with that.
If you're on a 32 GB SSD (like I was just a few years ago), 140 MB for a highly specialized tool is a huge amount. Or if you're building a system recovery image.
Or, if you have a large, but slow, HDD in an older computer (or worse - a small and slow SSD in a netbook), then reading that 140 MB installer (or the potentially-even-larger installed program) is going to be far worse than a 5 MB one.
I can think of a dozen situations where 140 MB is a problem. Don't assume that everyone else is in the same situation as you. As a matter of fact, if you're a programmer, your hardware is probably significantly better than the average computer user.
That's without even getting into people that still have limited bandwidth in 2021.
It cost more electricity to download, and users has to store file too, it causes bloat, and then system bloat if you also have to install it
So yes, file size, performance, bandwidth optimization, everything matter, EVEN MORE IN TODAY DAY AND AGE!
1000x disk increase only just for a GUI for dd is beyond useless, a pure egoist waste
For first world countries, the concept of burning gigabytes of data on the daily is no real concern, but in less connected places, less privileged regions of the world, gigabytes an hour is a pipe dream. Even for us folks with more dense data connectivity, making more room on transit bandwidth is a boon for everyone (even if it is to make more room to stream more cat videos).
Happily cede that it's not a top level concern, but I do agree with the sentiment that we can do better, and we should try to.
The reason: it is very user friendly, the interface is beautiful and, even for more experienced people, it brings a little more confidence than using dd directly.
I wouldn't call it a piece of thrash.
That being said, I'd much rather not install a miniature Chrome browser just to provide the UI for a command line tool, so I'm glad to see non-Electron as a selling point.
I understand the appeal of Etcher, but it seems like such overkill to launch Chrome just to write some data to a disk. I wish Windows/MacOS shipped with good tools for this out of the box instead. Disk Utility seems to be getting less useful over time though.
I'm FULLY aware that this premise has enabled the vast majority of garbage software that exists, but I think perhaps it's good to remember that we can have software that is both "very very mindlessly good" and "absolutely also respects users," Syncthing comes to mind here.
I would be delighted if there was an alternative. I ask every time an Electron hate discussion pops up. Still nothing anywhere near as good for Node Server + Browser Framework.
If we generalize to other languages, Qt does it very well in C++. You might like Qt or not (I'm not a big fan, but heavily prefer it over Electron), but it definitely does the job using much less resources than Electron (but still much bigger than pure platform-dependent native code...)
Because that is a design requirement.
If you want to put the assets on the user's computer run it as a webserver on localhost and launch it in the user's already installed browser. Example - syncthing.
Browser weirdness is not a thing anymore. So packing your own build with the application is super weird.
Definitely not the case for the majority of the world. Sure, it’s probably true for most HN readers, but many countries still rely on 3G infrastructure — or worse: satellite.
I remember spending over a week downloading Ubuntu 18, which also consumed ~10% of my monthly data cap for that single ISO. And before you make any assumptions, this was rural Ontario, Canada in 2019.
Objectively false - this matters for people with limited cellular data, in countries like Africa, on crowded wifi/cellular/satellite connections, with limited storage, and many other cases[1].
Where I live the average internet speed is around 30Mbps (even going as low as 15/10 in some cases) so that definitely isn't true, sadly.
Electron apps may eat too much RAM, have their performance impact, but for an app that is seldom used and won't be running continuously in the background, that is really not a problem. Considering that hardware constantly evolves, even if such evolution has been slowing down, the benefits on portability for these apps are a price I'm very willing to pay for.
If it's something I run frequently for short spans (a calculator, a search-to-launch tool, that kind of thing) or leave open for long stretches of time (so, messengers, most kinds of document or text editors editors, anything that lives in the system tray) then it's outside that narrow sweet spot in which Electron doesn't suck.
For small, one-off utilities, you might not care about CPU or memory usage - but you might want to minimize the installer/binary size because you're using it for such a short period of time or a specific task.
For instance, the Windirstat installer is 630 Kb, which is appropriate, because I use it fairly rarely. Want to guess how large the smallest Electron application would be?
I had to use Ether recently to write a Linux image to a pendrive (it didn't work when I used Rufus, they specifically stated on the site to use Etcher) and I couldn't believe what a piece of trash software that is.
To think I had to install an over a 100 MB application to do such a trivial task, it was mind-boggling.
Yes, the flasher was larger than the image I was trying to flash. The word monstrosity comes to mind. Rufus literally has more features. You may think the interface of Etcher is "better", but is it really 150x times better ?
1. Use DISKPART to wipe the USB storage, and create a new active partition as FAT32
2. Use Windows Explorer to open the ISO and copy all the files to the new blank USB Storage.
Works for most 'live' DVD/USB based distros supplied as ISOs, but not-so-much for .img files with multiple partitions (like Raspbian)
When you format the FAT32 partition using DOS, or execute SYS.COM on the partition, that would write a DOS bootsector to the partition which seeks & loads IO.SYS.
When you SYSLINUX the target FAT32 partition using either Windows or Linux, that writes a Syslinux bootsector to the partition (also writes ldlinux.sys & ldlinux.c32 files) which seeks & loads ldlinux.sys (and ldlinux.c32). Which then searches for the syslinux folder and a syslinux.cfg file inside. Also ldlinux.c32 and any .C32 files in the syslinux folder need to be the same version that you SYSLINUX'ed the partition bootsector with.
With the full fileset of the live Linux distribution copied to the bootable Syslinux'ed FAT32 USB drive, change the name of the isolinux folder to syslinux and inside your new syslinux folder, change the name of isolinux.cfg to syslinux.cfg.
A good live distribution will then boot from a Syslinux'ed USB FAT32 partition using a syslinux folder, instead of from a DVD using an isolinux folder.
This is, btw, not really an alternative to etcher, more like an alternative to rufus or unetbootin.
Indeed, the reason they made etcher was because they had too many help requests from hobbyists trying to flash their raspi sd cards. So they made a candy UI, and the requests dropped.
The candy UI is the main goal of etcher, if you remove that, then why not use the already very fine existing solutions?
Source code is a crown jewel for an IoT device, and they have opened a door for potential exploitation and exfiltration right where the sausage gets made. This tool has absolutely no business talking to the network for any reason, but now it downloads and displayed ads from potential third party sources (that the user cannot fully control and probably does want to not trust). What an unimaginably bad security decision. And they expect us to trust them with an IoT infrastructure?
As a direct consequence of this strategy, I have started to actively steer my IoT customers away from their offering, because I feel this move demonstrated that their stack should not be trusted.
Usbimager looks nice in comparison to the bloated Balena Etcher, but otherwise very similar to the Win32DiskImager I'm already using. Or is there something I am missing?
https://www.raspberrypi.com/news/raspberry-pi-imager-update-...
Also, for the "site":
I like rufus on windows but it feels weird to fire up my gaming rig to write a linux usb. Usbimager is cross platform.
Also discovered this user's manual for usbimager -
https://gitlab.com/bztsrc/usbimager/raw/master/usbimager-man...
