Hacker News new | ask | show | jobs
by mcpackieh 1034 days ago
Optimizing for disk space in 2023 seems misguided at best, all computers come with hundreds of GB at least, often one TB or more. Most people never fill these unless they download media, and people who download media have additional hard drives anyway.

Ease of use, RAM usage, startup time and security should all rank higher than disk space.

3 comments

I'm not going through the effort to upgrade my 250GB system SSD because a random podcast app can't figure out how to distribute a binary without shipping half an OS. Most people aren't going to upgrade their storage at all.

We're talking about Linux users here, not your run-of-the-mill generic end user. If you download an AppImage, you're most likely an advanced computer user. Maybe you don't download media yourself, but you'll probably have huge node_modules/cargo/venv/maven directories slowly clogging up your drive.

AppImages aren't easy to use (you can't double click them like on Windows and they all have to provide a mechanisms of their own to register a shortcut in the system menu), their startup time is affected by the compression tying all the files together, the security is no better than any other application (worse, in fact, because when I update my system's openssl client I'll still need to wait for every AppImage program to publish a security update with the patches included, which usually takes months or longer). I don't know about RAM usage, but the duplicate libraries being loaded by the executables will cause at least a few megabytes of unnecessary RAM usage.

AppImage is mostly there to help the developer spread the software. The benefit for the user is "at least there's something I can run, I guess".

> AppImages aren't easy to use (you can't double click them like on Windows

Uh, but that's exactly how they work. What file manager are you using them that doesn't recognize them? Also you can just chmod+x them and execute them.

As for their size, my XPS13 has a 250GB SSD too, not easily upgradable, but AppImages just aren't a significant burden to me. Once a month or so I move downloaded media to my NAS, but all of my AppImage applications together add up to maybe 15GB or so, the redundancy in them is really the least of my concerns.

When I double click an AppImage, I get ab error ('Could Not Display "Something.AppImage"\n There is no app installed for "AppImage application bundle" files. Do you want to search for an app to open this file?'). That's in Nautilus. If I click on the file from the Firefox download thingy, it asks me how I want to open "file links" with no suggestions for what to do next. Thunar asks me to pick a program to open "AppImage application bundle" files with, but has no recommended application.

Dolphin does seem to support AppImages natively and will execute the file (after clicking through two security prompts). I guess KDE users are AppImage's target audience, then?

> all computers come with hundreds of GB at least

There's a whole range of tiny/small computers that run Linux and that absolutely don't have hundreds of GBs of storage space.

Until a few years ago Apple was shipping new Macs with 120 GB. Probably same was (is?) happening with Windows vendors. TB-level disk space isn’t ubiquitous yet.
The difference between apple products and non apple products is that you can easily upgrade them. My core i9 laptop (a cpu that easily competes with anything apple can offer, so it should be fine for heavy workloads, albeit at bateryy cost), has 5600 mhz ram speed, 7 gb / s dual nvme support, both of which upgradeable. Most folks i know with non mac laptops can at least upgrade their hard drives and often ram. Disk space and ram not an issue for non apple users. TB disk level is absolutely feasible outside that platform. You can buy 2TB nvmes capable of 5 gb / s for less than 100$ easily.
Okay but how much dedupable dependencies does the average AppImage user have across his programs? A few hundred megabytes? A few gigabytes at most? Even 120 GB is big compared to this problem.