Etcher was a nice simple application, but now it's an attention grabbing adware monster. I don't need any promotions when I'm burning my SD cards, thank you very much. I'm surprised that so many people here chose to defend it.
I was shocked to hear they turned such an easily replaceable tool into a bloated pile of adware. Such behavior is hostile to developers in a way that calls into question all of their other choices, including those they will make in the future.
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.
Thanks for linking this, I love the multi-front-end approach. With the simplicity of the program and it’s UI it doesn’t really benefit from one-front-end-everywhere the way something more complex would.
When you format the FAT32 partition using Windows 10, or execute BOOTSECT.EXE /nt60 on the partition, it writes an NT6 bootsector to the partition which seeks & loads BOOTMGR.
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.
I've been using Win32DiskImager since the first Raspberry Pi. Never found a reason to change.
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?
Pi Imager has some nice Raspbian-specific advanced features hidden behind a keyboard shortcut (Ctrl+Shift+X), which can be useful if you plan on deploying a headless system.
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.
Did anyone have a good experience with Balena Etcher? I don’t have a good runs with it, the boot process always failed to detect the files in the USB drive that was formatted by Etcher. BIOS couldn’t detect the partition or anything in that USB. I tried with various Linux distro and Windows ISOs, it just failed to load or not detectable in the booting. Even it couldn’t load a simple Gparted partition.
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 haven't used Balena etcher in forever, but back when it came out it was a godsend. This was also during a time when I already had enough skills with the command line that writing images to drives on either Linux or Windows should have been easy. But I always ran into roadblocks. When I discovered Balena, everything just worked.
I hope it didn't devolve into something that doesn't just work.
Same here - I have had issues with the other mentioned softwares but rarely with etcher. (I have had cards be seemingly broken and fail to image - I don’t think etcher was to blame. )
Seems to be hardware- and OS-dependent. Eons ago, don't know the version anymore I used it under Linux out of curiosity I guess, and because some project nagged about using it for verification of written images, or else.
Anyways, that thing always complained about a bad checksum at the end, no matter which media, system, port, writer I used.
And I always thought: Oh, really? And booted the failed checksum images flawlessly. To me this thing seemed like a stupid prank, adding no value over any other method. Even less so, considering the Electron crap.
Btw. the writing checksummed perfectly fine with dd on all the media, hardware, system and ports I used.
Balena Etcher has been popular for a while and works really well, I’ve never seen it screw up. I’d honestly prize that reliability over download size, I have terabytes of space.
If usbimager takes off and becomes the default, cool, but I’ll take boring reliable Etcher over some trendy new thing any day.
There is no reason not to use dd. Yes, its option syntax is weird; yes, it has its dangers. But all the GUI tool does is show you the danger with a confirmation dialog.
I see this from the reverse: while I strongly dislike that my day to day apps like Slack use Electron I couldn’t care less that Balana Etcher does. I use it every few months at most. It has features that the macOS Disk Utility does not so I still need it in my tool belt but if Electron allows Balana to make the thing more quickly and effectively then so be it. 140MB is not really notable to me in any way beyond irritating my OCD tendencies that know it could be smaller.
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.
I'm guessing the gigantic size is due to it bundling Chromium as it's an Electron app. I've been wondering why we still haven't fixed that problem with some form of compression (although I wonder how feasible that would be with binaries). Signal takes up 400MB, Element takes up 300MB. It just feels like way too much.
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.
Yeah, the way we solved that is by including all the UI framework code in shared libraries bundled with the OS or separately installable. But for some reason people like to spaghetti-code in JavaScript inside a bloated web browser now
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.
When every application is an Electron application, you suddenly can only run one quarter of the number of applications concurrently. If your workflow depends on multiple applications running at the same time to remain efficient, that's not great. And no, I can't just "buy more RAM", because it might be soldered onto the mainboard, or out of the available budget range for such upgrades.
That's without even getting into people that still have limited bandwidth in 2021.
Not every application is an Electron app and you have plenty of choices if you don't want to use Electron apps.
It really depends on individual use. For instance, I am currently running at least 6 browser engine instances as I type this, probably more than that, and I just am not experiencing a meaningful performance hit that would cause me to get pissed at Electron.
If that happens to you, then sure, I can't argue against that.
But yours may not be everyone's experience. I am personally skeptical as to whether 140 MB (I'm pretty sure we were talking about binary size, not memory usage) is as big a problem as HN makes it out to be.
> For instance, I am currently running at least 6 browser engine instances as I type this, probably more than that, and I just am not experiencing a meaningful performance hit
Repeat after me: your computer is not the same as everyone else's computer. As a programmer, your computer is statistically significantly better than the average user's. If you're running 6 browser engine instances without noticing, it's almost certainly way better.
My wife's laptop is an almost decade-old Thinkpad x230 tablet. Looking on eBay, I see that most of the available x230's have Intel Core i7-3520M[1] processors (22nm, 2c/4t, 2.9 GHz base clock, 5 MB L3), and my machine has 4 GB of RAM. You willing to bet that you could run 5 Electron instances on that machine without any noticeable slowdowns, especially when doing something like running a sixth browser for web browsing?
According to Mozilla's hardware report as of the time of this comment, the median Firefox user's machine has two physical cores[2]. 8GB of RAM, sure, but a full quarter still have only 4GB. The most popular graphics vendor is Intel integrated graphics. And so on.
> Repeat after me: your computer is not the same as everyone else's computer.
You're repeating pretty much what I said, so I really am not receptive to this "repeat after me" statement you're making towards me.
I think I agree with you and see your point, but I see what you wrote as kind of standoffish. Like, post my machine specs? lol There's no need to be that sarcastic.
Also, just because the big Electron apps are a problem for a part of the user base, I don't think that's necessarily evidence that they are an outright problem.
I could just as easily come up with anecdotes of people I know whom aren't developers and run multiple Electron-based apps. It really wouldn't prove anything.
It would certainly be a bigger problem if literally every app is an Electron app. Even in 2021 most of what I'm using isn't using a browser engine. Then again, maybe there are plenty of circumstances where people are forced to use lots of apps that all bundle browser engines. I really don't have much knowledge about that. Maybe this is way more common than I've been lead to believe.
My original question was really about just how prevalent the need for apps smaller than 140 MB actually is. As far as I can tell, that's a valid question, even if some of my premise was out of ignorance.
> You're repeating pretty much what I said, so I really am not receptive to this "repeat after me" statement you're making towards me.
My apologies, that was poor form, and unnecessarily hostile. And, you're right, I didn't read your comment thoroughly. I'm going to leave my original response unedited so that others can see that my original comments were made partially in error.
Now, with that said, here's the refinement of my point: my computer specs are more valid than yours, because they're far more representative of the average user's computer than yours - so your comment "It really depends on individual use" applies far more to your experiences using less-standard hardware than mine using more-standard hardware.
Moreover, all programs written for the performance target of piddly little machine are guaranteed to work on your machine, but not the other way around. It doesn't really "depend on individual use", because implementing an application with native tech vs. Electron just plain works better for a larger fraction of the population - it's not like the Firefox/Chrome performance tradeoff, where Firefox uses more CPU and Chrome uses more memory, and which one is better depends on your situation.
> Like, post my machine specs? lol There's no need to be that sarcastic.
I was dead serious. Show us what your development device is like, and then we'll see how it stacks up to my x230. Better yet, tell me what apps you're using, and I can install them on that x230 and we'll see how it behaves.
> I could just as easily come up with anecdotes of people I know whom aren't developers and run multiple Electron-based apps. It really wouldn't prove anything.
Well, if you're going to insist on statistics, then the best we can do is probably the Mozilla hardware report[1], where slightly over half of users have only two physical cores, two-thirds have Intel integrated graphics, the most prevalent CPU frequency is 2.3 to 2.7 GHz, and over half of users have either 8 or 16 GB of memory - which are pretty close to the x230 example I gave, again supporting my argument.
I don't think that there should be much contention that the average user's computer is significantly less powerful than the average developer's computer.
> My original question was really about just how prevalent the need for apps smaller than 140 MB actually is.
That's not really an answerable question, nor is it a useful one, because it rarely makes sense to talk about the "need" for particular software traits. Unless you perform some pretty egregious violations of users' privacy, you're never going to be able to determine which fraction of users computers literally cannot run a particular Electron app - and that's not even an interesting piece of data, because the question isn't "how many users are there that are in a life-or-death situation where they need an application to not be written in Electron" (as that number is probably pretty close to zero, but I wouldn't be surprised if it was non-zero), it's "how much concrete value is being taken away from users' experiences because of Electron apps" - which is not something you can measure.
The lag you get while watching a YouTube video on a netbook because Discord is in the background isn't measurable, and it's not a need - but it's still there, and it's still bad. Similarly, you don't need Discord, Spotify, Steam, Slack, and Balena to all be running at once - but being able to listen to music in the background sure is nice, as is being able to leave applications running in the background when you aren't using them.
Electron applications detract from the value you get from a computer by needlessly consuming meaningful amounts of disk space, memory, CPU, and battery life, and introducing noticeable lag and jitter, for no value to the user.
Right, plenty of choices. Unless your social network uses WhatsApp, Discord, or Slack. Or your work team uses MS Teams or Postman to collaborate.
Network effects are real, and some people just have crappy or old computers. You may be happy with an M1, and meanwhile some are running computers that originally came with Vista but were put out of their misery after the friendly neighborhood tech support nephew installed Windows 10 or Linux.
Is it a problem? I wouldn't call it an earth-shattering one, but yeah, I think we're rife with opportunity to, say, take a note from Docker's use of UnionFS, to provide common baseline electron, and layer on dependencies on top of it.
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.
Yes. The gargantuan size implies it's some complex application carrying out out some special processes, rather than a simple utility that can also be performed with shell builtins. This makes users less in touch with the workings of systems, which if they're playing around with disk images, is the opposite of what they'd like to accomplish.
Writing directly to sectors of a block device is the kind of low level task I'd not think could be done well by web derived technologies like electron. I'm glad I was wrong.
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.
Yep, this is exactly the type of application I don't care if it eats my RAM for a couple of minutes if it does its job well. In my experience it does. I just use `dd` if I have access to it but otherwise etcher does the job for me, for example on Windows machines.
Agreed. Little GUI utilities that I'm likely to only use for a few minutes every now and then can be Electron. Doesn't bother me a bit.
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.
The problem is that Electron applications don't just eat lots of RAM and CPU - they also have significantly larger installer sizes - usually in the hundreds of megabytes, it seems. (Balena's seems to be 140 MB, compared with 12MB-1MB for alternatives[1])
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?
There are comments elsewhere in the thread about this, but storage is not the only thing in play here: bandwidth (even in modern countries some rural places have very slow connections), energy use (it takes proportionally more electricity to transfer 140 MB vs. 1 MB, and running an UI that basically needs a web browser in the background is also a waste of electricity). Moreover in some countries a 1 TB SSD is not exactly affordable. And also in western economies, it might not be affordable for some people.
I'm the first person to complain about bloated electron apps, but this is a task that I do so rarely I really don't mind it's electron.
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?
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.
I had to write a 100MiB "rescue" Linux image to a USB drive, and was offered two methods to do it: 150MiB "Etcher" and 1.1MiB Rufus.
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 ?
So is it a piece of trash because of the size of the software or because it doesn't work well? I'll grant that the size seems excessive but I tend to use it because I hardly ever need to use it and it makes a task that I don't want to have to care about really really easy. That's sad if there's a smaller piece of software that makes the task just as easy and error proof I'm certainly happy to switch to that.
What's wrong with Electron? Etcher is a tool with 5 minutes maximum running time, it's not Slack where you have to run on background for hours. Also size is irrelevant these days, you can download a 150 mb file in 2 seconds.
> Also size is irrelevant these days, you can download a 150 mb file in 2 seconds.
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.
Yes, it's incredibly frustrating to hear people assume everyone has high speed home connections. I operate entirely off cellular. 150 MB is not chump change and it certainly does not download in 2 seconds. If it's not a problem that affects the developer shipping the software it's not a problem that gets noticed or cared about, unless it ends up on a PM's radar or sentry.
Every time you hear someone making false assumptions about internet connections, don't forget to mention Dan Luu's excellent page on this! https://danluu.com/web-bloat/
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].
Even using mostly the terminal for tools like dd and file management, I've used Etcher sometimes. Also I've recommended it for a few people less experienced than me.
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 don't care about interface "beauty", but GUIs definitely add a lot of comfort for things like drive operations and Git commits: I hate writing an arcane one-off command line command, and not truly being sure the outcome until it's already running.
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.
When I first heard of it I thought it was some kind of a joke on the current state of desktop software, and a rather tasteless one at that. Then it was recommended to me where I was studying...
Do you choose your block size when you use dd? For me, on multiple OSes and oldish hardware,
$ dd if=/path/to/iso of=/path/to/disk bs=1M
seems noticably faster than etcher. I suspect thats not even the optimal choice
Edit:noticed this is sort of a repeat answer, leaving it so the people saying its slow can copy/paste and try it out.
I recently tried to write an Ubuntu .iso to the USB flash drive on OSX using dd. And for some reason that I couldn't easily figure out, write speed was so slow as to be almost unusable. Enter Etcher, and that image got written in a flash. So what ever it maybe, alternatives aren't sometimes that great.
There are a lot of gotchas with "dd" and its command line syntax is baroque to say the least. On MacOS it's worse because it's easy/natural to write to /dev/disk2 instead of the "raw" /dev/rdisk2 and make everything dog slow.
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 think it's pretty popular for cloning raspberry pi SD cards. It has a feature where you can stick a bunch of USB SD card peripherals and program multiple cards at the same time. Honestly most people don't care too much about the image size or performance I think it's more that when you use it you are pretty certain that you are writing the correct target drive. I've done it may times with dd command and every time I am nervous about overwriting my os drive.
from a technical writing perspective, it lets you write one set of direction that works for every single user every single time. This is great if a project is supporting via volunteers. And if you know enough about imaging to do it without etcher, you can just do it.
You know, I've been on both sides of this. I used to feel that way, like why not dd? And lately I've come to really value tools that don't force me to think at all.
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.
It's good looking, simple, reliable, and most people aren't too concerned with an extra 100 MB download if they're already downloaded a few GB of disk image. It makes sense that it would be popular in tutorials, and spread out from there.
As always: please show me an alternative to Electron that works out of the box on Linux/Win10/MacOS with zero edits to your JavaScript.
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...)
If all the assets are downloaded from your website then make it a PWA. Example - ms outlook (web version).
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.
I thought of distributing a node server, but it is going to non-sophisticated users who expect a EXE or DMG or tar.gz and a binary. Also, it interfaces with a wide range of system hardware, USB, VISA, serial ports, GPIB, etc. I tried to build a docker image, but that also was too complex for the end user, and it had some serious hardware issues with some USB devices.
So you have requirements to interface to low level peripherals, and you need to do this in the worst language ever invented, which is at the same time one of the highest level languages? It boggles my mind.
