91–100 of 166 posts
Work backward from that requirement and constraint. Solutions and designs that barely work for the linux desktop will never bring a revolution...
Earlier quoted context omitted.
I guess millage may vary, the only thing I can say is that there are multiple instances (particularly GoG which the article seems to praise) that literally never work on some of my systems. The few times I've run into Flatpak crashes, they're architecture problems that would have been present in any version of the app, so I'd be doing that work regardless. They're harder to debug in Flatpak, but also heck debugging c…
But on the other hand, app crashes aren't something that common on linux. I mean at least on my distro. Whenever I have an app available as rpm, I choose the rpm over the flatpak version, for space saving purpose mostly. None of my apps crashes except one. And that is a piece of shit of a proprietary app that is not packaged by the distro maintainers: Microsoft Edge.
Strong disagree, my experience is that app crashes are extremely common on Linux if you step outside of official repositories; I say this as someone who literally only runs Linux and nothing else. I'm not necessarily saying Windows is better but... it's not like nothing ever breaks. It's impressive how well developers are able to hold it all together, but my experience is that Linux systems are fragile the moment anyone stops actively managing the dependencies and putting in the work to compile everything to match.
> that is not packaged by the distro maintainers
It is not feasible or scalable for Linux for every single app (even every Open Source app) to be distributed and managed by the distro maintainers. And this is what I'm getting at with dependency isolation -- the vast majority of crashes and bugs I see on Linux (and I mean by a massive margin) are all due to dependency mismatches and shared dependencies. A lot of Linux software is generally stable if the system looks like what it's expecting the system to look like. But if you're not going through an official repository where a bunch of volunteers are putting in the work to make it consistent, then it very often doesn't look like what developers expect.
This is why people run games through Wine instead of using the Linux versions -- it's not because it's impossible to build good native versions, it's because if they don't use the Linux version they can use Bottles. That's the biggest reason; it's about the dependency isolation.
Flatpak seems to follow a similar path as many other Linux technologies like Wayland or Systemd, in the sense that they seem to arouse the anger of a small but very vocal crowd who really can't stand any challenge to the status quo. So this is the template of the story: There is a new tool or workflow trying to replace or complement an old one. This new tool tries to solve many different complex problems that the old…
Please change, HN.
Neither are snaps. The future, for regular daily use, are appimages. Much like MacOS dmgs, these are a "single" file (from an end user perspective) that you download, double click, and run. That's it. Ideally we'd see more work in this area. I am slowly trying to figure out how to automate builds for GUI apps and I am considering somehow settings up an inexpensive server to pull, package, and submit appimages to appi…
Flatpacks solve no problem that I have, and bring their own headaches, so for me, flatpack is certainly not the future. Same with snaps, although I dislike snaps more.
Neither are snaps. The future, for regular daily use, are appimages. Much like MacOS dmgs, these are a "single" file (from an end user perspective) that you download, double click, and run. That's it. Ideally we'd see more work in this area. I am slowly trying to figure out how to automate builds for GUI apps and I am considering somehow settings up an inexpensive server to pull, package, and submit appimages to appi…
Do appimages have a proper well maintained store now with a good cli for maintaining them? When I last year moved to portable Apps, I check out flatpak, appimages and snap, and move to flatpak, and some appimages. But while flatpaks are easy to maintain, the appimages are basically dead weight. Some can be updated, some not. There were a number of different tools for maintaining them, not one-for-all. Similar there w…
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
AppImages waste even more disk space. At least with Flatpak I only need to install libraries once, with AppImages I'm getting a second copy of everything with every application I download. If AppImages were actually directories, like they are in macOS, I could at least run duperemove to fix the disk space issue on BTRFS, but with full images that become a lot harder.
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.
There's a whole range of tiny/small computers that run Linux and that absolutely don't have hundreds of GBs of storage space.
Earlier quoted context omitted.
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.
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.