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.
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.