Hacker News Reader

Comment by toyg | Hacker News Reader

300mb of memory to do a bit of money-counting, which you could probably do equally well with MSVC in 2mb.

Such a wasteful world.

My favourite example is Etcher[1] which is effectively a GUI for "dd" and ships as a 227MB "app" that uses >200MB of RAM idling.

"dd" is 37KB.

[1] https://www.balena.io/etcher/

Etcher is okay to me because you won't run it in background, you are gonna close it right away after flashing anyway.

BTW comparing an GUI app with a CLI-only program sounds unfair.

I've used Etcher a bunch of times. It's pretty and gets the job done.

But it's also heavily recommended within the Raspberry Pi community, and used by Balena's customers for starter IoT applications. We can assume most of the users of this application are beginners.

So, do you think these beginners would care about the size of this "app" that they'll probably delete as soon as it finishes? Do you think they'd care about 200MB of RAM when they're almost certainly running it on any modern PC instead of some ancient EeePC from hell? As a beginner, would you feel more comfortable in front of Etcher or dd?

The crux of your argument basically boils down to "a GUI takes up more RAM than a CLI." Which is obviously true, but it doesn't invalidate the need for more GUIs in the world. Could Etcher have been built with a native GUI? Sure, but it's free software, there are no expectations. If you wanted to, you could clone the repo and build it natively yourself.

But why would you? Etcher already exists, and it would save you from hundreds of hours of debugging and learning new frameworks. Knowing HTML/CSS/JS, you could build Electron Etcher in a fraction of the time it would take you to build Qt4 Etcher, and the compromises are acceptable given the target audience.

And now you understand why the Etcher devs chose Electron.

> So, do you think these beginners would care about the size of this "app" that they'll probably delete as soon as it finishes

Well, looks like enough people care (or at least noticed) https://imgur.com/LV6AT7d

The dev's justification:

https://github.com/balena-io/etcher/issues/2365#issuecomment...

> And now you understand why the Etcher devs chose Electron.

No one is claiming that the choice to use electron is without merit or that it is a mysterious choice. It's just heavily disappointing that we've gotten to the point where 300mb and 4 processes is acceptable for the cruft developed with it.

Why is that disappointing? Worrying about how much RAM your program is using feels similar to worrying about how much paper you're using to take notes - at best it's a distraction from what's actually important.

If you want disappointing, how about the fact that we're still finding buffer overflow vulnerabilities? IMO we shouldn't even begin to talk about software performance while we have such difficulty getting software to behave correctly at all.

If I wanted disappointing, I would accept that some people in this world will never see the big picture and are so out of touch that they try 1-upping others on a message board by throwing out buzz-words.

This performance-related bug report looks pretty damning: https://github.com/balena-io/etcher/issues/2740

thats 300mb across several completely necessary helper processes.

garbage in, garbage out

garbage collected

In the author's defense, it's just an example he was using to explain a development setup and some techniques. You can also do a factorial on a sheet of paper at 0mb RAM

The 230MB (not 300MB) is from my real app Actual. The example project uses much less because it does nothing except start electron, which looks like it uses about 80MB baseline.

Using 2Mb with MSVC instead of 1Kb with MASM. Such a wasteful world.

Even 2mb is disgusting for a bit of money-counting.

A 64kb Z80 computer is perfectly suitable for a few rows to balance. After all, they went to the moon with 16kb of RAM.

Reply on news.ycombinator.com