Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux desktop leaders unite behind Flathub app store. Here's why

zdnet.com

Post reply on HN
Print view View original

111–120 of 124 posts

Re: Linux desktop leaders unite behind Flathub app store. Here's why

#111

Post by superkuh »

kaba0 wrote: post #110
superkuh wrote: post #74

Earlier quoted context omitted.

Right. Nix is containers.

Maybe don’t double down on something you don’t understand and has been corrected about several times.

Maybe don't pretend a trivial semantic difference due to your point of view means I don't know what I'm talking about. Yes, Nix only alters environmental variables, but guess what, that's pretty much what Snaps do too plus a bit of bind use. The fact that people are constantly asking "Will Nix Overtake Docker" is another hint about actual usage.

Snaps bind in the libs, Nix sets env variables to set the available libs. The goal and end results are the same. The difference is more marketing than anything else.

Re: Linux desktop leaders unite behind Flathub app store. Here's why

#112

Post by colordrops »

superkuh wrote: post #111
kaba0 wrote: post #110

Earlier quoted context omitted.

Maybe don’t double down on something you don’t understand and has been corrected about several times.

Maybe don't pretend a trivial semantic difference due to your point of view means I don't know what I'm talking about. Yes, Nix only alters environmental variables, but guess what, that's pretty much what Snaps do too plus a bit of bind use. The fact that people are constantly asking "Will Nix Overtake Docker" is another hint about actual usage. Snaps bind in the libs, Nix sets env variables to set the available libs…

What does a container mean to you?

On Nix there is no separation of file system or network across applications. The same installed libraries can be used by multiple apps. Apps have access to the same system services and run together, e.g. with a single systemd. How can you call what Nix is doing "containers" ? There's virtually no overlap.

Zoom overtook the local freeway as the preferred mechanism for get to meetings at my company. I guess Zoom is a road by your logic.

Re: Linux desktop leaders unite behind Flathub app store. Here's why

#113

Post by ar_lan »

Fire-Dragon-DoL wrote: post #107
ar_lan wrote: post #5

What advantages does Flatpak offer over Nix? The only benefit(s) I see are: 1. Sandboxed applications (via containers?) - so applications you have don't technically have access to your home directories by default. That's sort of nice - but how many applications really warrant this overhead? 2. Possibly easier to write/package? That said, in Nix you pretty much just need to package once. I've not used Flatpak - can so…

Nix sounds amazing and better than everything else, but it also sounds really hardcore and not for common usage. You have to learn a specific programming language just to use it, so the barrier is: learn to use a computer, learn to program, learn a specific language Compare that to desktop distributions, or windows, or macOS the barrier is: learn to use a computer

Totally fair, and understood! Thanks for the response.

I agree Nix’s biggest issue is that it’s extremely hard to consume. It took me essentially over a year before I felt… proficient in using it.

Re: Linux desktop leaders unite behind Flathub app store. Here's why

#114

Post by kaba0 »

superkuh wrote: post #111
kaba0 wrote: post #110

Earlier quoted context omitted.

Maybe don’t double down on something you don’t understand and has been corrected about several times.

Maybe don't pretend a trivial semantic difference due to your point of view means I don't know what I'm talking about. Yes, Nix only alters environmental variables, but guess what, that's pretty much what Snaps do too plus a bit of bind use. The fact that people are constantly asking "Will Nix Overtake Docker" is another hint about actual usage. Snaps bind in the libs, Nix sets env variables to set the available libs…

Yeah, Nix “doesn’t only alter environment variables”, hell, the most common way of operation is simply patching/compiling standard linux ELF executables in such a way that they dynamically link to the correct dependency, so instead of just having libc mentioned, there is /nix/store/some-hash-libc/lib/libc there. This one libc is shared across many (most) of the packages you will practically have, so you get the advantages of containers, without any overhead in emulation, nor file size.

Re: Linux desktop leaders unite behind Flathub app store. Here's why

#115

Post by Fire-Dragon-DoL »

ar_lan wrote: post #113
Fire-Dragon-DoL wrote: post #107

Earlier quoted context omitted.

Nix sounds amazing and better than everything else, but it also sounds really hardcore and not for common usage. You have to learn a specific programming language just to use it, so the barrier is: learn to use a computer, learn to program, learn a specific language Compare that to desktop distributions, or windows, or macOS the barrier is: learn to use a computer

Totally fair, and understood! Thanks for the response. I agree Nix’s biggest issue is that it’s extremely hard to consume. It took me essentially over a year before I felt… proficient in using it.

That is so frustrating, it really sounds amazing, but I don't have the willpower to do that just for the day-to-day OS. Looking forward the day it gets more consumer oriented

Re: Linux desktop leaders unite behind Flathub app store. Here's why

#116

Post by Brian_K_White »

2OEH8eoCRo0 wrote: post #86
hotpotamus wrote: post #85

Earlier quoted context omitted.

And thus we re-invent shared libraries? Like that's not even really a snarky question; isn't that sort of restarting the cycle?

Good point. Yes. But there are too many versions and varieties. In the same vein there is a lot of variety of image layers. What problem does Flatpak solve? I assume it's because it's tough to create Linux desktop applications when you have no idea what shared libraries, compiler, or version expect.

So we reinvented static binaries, except 500x worse.

Re: Linux desktop leaders unite behind Flathub app store. Here's why

#118

Post by nikau »

ilovecaching wrote: post #100
blendergeek wrote: post #33

I owned a Librem 5 phone and used it as my daily driver for a few months. During this time I exclusively used Flatpaks for my apps that I installed. After installing about 15-20 apps, the 32 GB of internal storage were completely full and my phone stopped working. I had no clue how huge Flatpak apps are. Even worse, I could not find out which apps to delete. All the space was taken up by excess "runtimes" I don't kno…

The problem is that system libraries DO solve a problem that docker recreates - the kernel can efficiently map in a virtual address range for shared libraries and then add the map to all of the tasks that are using the same library, and the disk space is minimal because you only have maybe a few copies of the same lib. For some pieces like glibc, that's huge savings system wide. With container images you're bundling…

Containers have never been about system efficiency, rather admin/developer efficiency - lower skilled staff can pump out a working product cheaper.

Need to run 2 separate apps that both need to use the same userid/filesystem path/network listener port? No problems.

Need to have different library versions? No worries.

Sure you can workaround all this stuff with ld preloads and other things, but that requires more skill than copying a base dockerfile from a google search and putting in a bunch of RUN commands.

Re: Linux desktop leaders unite behind Flathub app store. Here's why

#119

Post by nikau »

gnulinux wrote: post #47
lenkite wrote: post #29

Earlier quoted context omitted.

Once the linux world moves completely to Flatpak, that would truly help languages like C++ - whose evolution and cleanliness has been tremendously crippled by being unable to have a clean ABI break.

I know this is a controversial opinion, some would strongly disagree with me, maybe most would consider me downright wrong . But as a system designer I always thoughts (by always, I mean last ~5 years since I've been thinking about this) the misery we experience with C/C++ package management is an OS problem, not a language problem. The fact that some languages roll their own package manager like pip, npm, cargo etc…

If MS4 is so breaking from MS3 they should have put the major version number into the package name.

Its not an apt problem, its a problem that the application is fundamentally a new product that needs a unique name.

Post reply on HN