Usbimager – A non-electron based alternative to Balena Etcher
bztsrc.gitlab.io
bztsrc.gitlab.io
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.
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.
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...
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-...
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.
If usbimager takes off and becomes the default, cool, but I’ll take boring reliable Etcher over some trendy new thing any day.
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.
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.
And don't bug me with did you file a bug?
Why? They can bug off for all I care :)
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.
That's without even getting into people that still have limited bandwidth in 2021.
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.
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.
You want to post your machine specs?
[1] https://ark.intel.com/content/www/us/en/ark/products/64893/i...
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.
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.
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.
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. 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.
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
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.
-rwxr-xr-x 1 root root 79K Dec 5 2020 /usr/bin/dd*
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?
Also, for the "site":
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?
Hey, @nlarion, if you are not a bot, say so.
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 ?
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.
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.
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].
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.
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 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 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.
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.