[HN Gopher] Usbimager - A non-electron based alternative to Bale...
___________________________________________________________________
Usbimager - A non-electron based alternative to Balena Etcher
Author : charsi
Score : 95 points
Date : 2021-10-18 11:25 UTC (11 hours ago)
(HTM) web link (bztsrc.gitlab.io)
(TXT) w3m dump (bztsrc.gitlab.io)
| naoru wrote:
| 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.
| 1MachineElf wrote:
| This usbimager tool looks great.
|
| 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.
| ravenstine wrote:
| Honestly, is 140 MB really a problem anymore?
|
| 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.
| selfhoster11 wrote:
| 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.
| ravenstine wrote:
| 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.
| selfhoster11 wrote:
| 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.
| fouric wrote:
| > 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.
|
| You want to post your machine specs?
|
| [1] https://ark.intel.com/content/www/us/en/ark/products/
| 64893/i...
|
| [2] https://data.firefox.com/dashboard/hardware
| ravenstine wrote:
| > 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.
| fouric wrote:
| > 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.
|
| [1] https://data.firefox.com/dashboard/hardware
| fouric wrote:
| > Honestly, is 140 MB really a problem anymore?
|
| 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.
|
| [1] https://danluu.com/web-bloat/
| belthesar wrote:
| 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.
| mindslight wrote:
| 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.
| Shadonototra wrote:
| Yes, it cost more in bandwidth, CDN has to cache file on
| actual disks, the more used, the more you need
|
| 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
| bityard wrote:
| $ ls -lh /usr/bin/dd
|
| -rwxr-xr-x 1 root root 79K Dec 5 2020 /usr/bin/dd*
| JasonFruit wrote:
| 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.
| Uehreka wrote:
| 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.
| burnte wrote:
| Rufus is the best, IMO. Tiny amazing tool tha does exactly what
| it needs to do.
| charsi wrote:
| Rufus is windows only. This is cross platform. Probably
| should have put it in the title.
| tentacleuno wrote:
| 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.
| VRay wrote:
| 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
| Isthatablackgsd wrote:
| 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).
| ravenstine wrote:
| 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_.
| cordite wrote:
| I've had a _bad_ experience!
|
| 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.
| treesknees wrote:
| Yes, I've used Balena Etcher dozens of times from my Windows
| machine and I've never had a problem with it. Windows and
| Linux ISOs work just fine.
| pletnes wrote:
| 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. )
| afavour wrote:
| 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.
| factorialboy wrote:
| I've used USBImager for several months now. It is exactly the
| kind of app I love: Minimal, does one thing well, no-bloat.
|
| https://gitlab.com/bztsrc/usbimager
| kitsunesoba wrote:
| 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.
| [deleted]
| marcodiego wrote:
| 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.
| folkrav wrote:
| 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.
| handrous wrote:
| 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.
| fouric wrote:
| 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?
|
| [1] https://news.ycombinator.com/item?id=28905752
| BiteCode_dev wrote:
| 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?
| nlarion wrote:
| > I'm the first person to complain about bloated electron apps
| BiteCode_dev wrote:
| Can we report this account? It has been opened 4 years ago,
| with 2 comments, including this one.
| JasonFruit wrote:
| Why? It's not a great comment, but hardly offensive.
| BiteCode_dev wrote:
| Because it looks like a bot, not a human being.
|
| Hey, @nlarion, if you are not a bot, say so.
| charsi wrote:
| I should have used the much better url for this -
| https://bztsrc.gitlab.io/usbimager/
|
| 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...
| korse wrote:
| Got to give a shout out to my boy, dd.
| craftoman wrote:
| 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.
| fouric wrote:
| > size is irrelevant these days
|
| 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].
|
| [1] https://news.ycombinator.com/item?id=28907045
| tentacleuno wrote:
| > Also size is irrelevant these days, you can download a 150 mb
| file in 2 seconds.
|
| 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.
| trillic wrote:
| Maybe you and I have near gigabit connections, but not
| everybody has constant access to high-speed non-metered
| internet
| KMnO4 wrote:
| > 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.
| WA9ACE wrote:
| 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.
| fouric wrote:
| 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/
| WA9ACE wrote:
| Thank you for linking me to this this, it's a wonderful
| write up that I had not seen before!
| baal80spam wrote:
| Praise the lord.
|
| 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.
| infinitezest wrote:
| 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.
| AshamedCaptain wrote:
| 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 ?
| automato wrote:
| it's probably written as one of those "universal" apps that's
| basically just a packaged browser
| colinfinck wrote:
| 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?
| m-p-3 wrote:
| 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.
|
| https://www.raspberrypi.com/news/raspberry-pi-imager-update-...
| jason0597 wrote:
| I highly recommend Rufus for Windows users. I've used it many
| times in the past without any issues. Very lightweight and very
| reliable
|
| https://rufus.ie/en/
| mattowen_uk wrote:
| If you are feeling brave it can be done in Windows without any
| extra software...
|
| 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)
| craftoman wrote:
| I had boot problems with Rufus when burning a custom distro.
| AnonHP wrote:
| Mod/OP: The link leads to a person's profile page on GitLab.
| Please update it to this link for the README on Usbimager:
|
| https://gitlab.com/bztsrc/usbimager/-/blob/master/README.md
| tecleandor wrote:
| https://gitlab.com/bztsrc/usbimager should be ok too
|
| Also, for the "site":
|
| https://gitlab.com/bztsrc/usbimager
| dang wrote:
| Ok, we've changed to that from https://gitlab.com/bztsrc.
| Thanks to both of you.
| charsi wrote:
| Sorry i got this wrong on the first attempt. An even better
| url exists for this -https://bztsrc.gitlab.io/usbimager/
| dang wrote:
| Ok, we'll change to that. Thanks!
| izackp wrote:
| There is also 'dd' and winDD for windows.
| SavantIdiot wrote:
| 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.
| charsi wrote:
| 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.
| SavantIdiot wrote:
| 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.
| sudosysgen wrote:
| You understand that such a solution would have exactly the same
| issues as Electron, right?
| NikolaeVarius wrote:
| I've always found it so weird that a piece of trash like Etcher
| could become so popular
| BBC-vs-neolibs wrote:
| Well, I'm pretty techy, but it was easy to use.
| jabroni_salad wrote:
| 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.
| marcodiego wrote:
| 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 wouldn't call it a piece of thrash.
| ocdtrekkie wrote:
| 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.
| kiryin wrote:
| 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...
| lpcvoid wrote:
| Unfortunately, Etcher is a perfect metaphor for the state of
| "modern" technology in general. Inefficient to it's core.
| automato wrote:
| it burns my microsd cards way faster than dd, what do you
| mean "inefficient to its core"?
| gs17 wrote:
| 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.
| bob229 wrote:
| Maybe because it works and is very easy to use
| mrweasel wrote:
| Exactly, I could create a bootable USB device using the
| command line, but I don't do it very often, so I quickly
| forget how.
| rixrax wrote:
| 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.
| AlexandrB wrote:
| 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.
| mcshicks wrote:
| 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.
| [deleted]
___________________________________________________________________
(page generated 2021-10-18 23:02 UTC)