Mozilla To Begin Offering Firefox In Snap Format For Ubuntu

[davcri]

I would like to point out that there's lot of applications delivered similar way for xdg-app - I use it for getting Pitivi daily build for example. Anyway, xdg-app and snap is really way forward for development builds AND developers wanting to avoid deb/rpm building process.

Can you tell us more about how do you use XDG ? Which distro, how do you install xdg-apps ?
There is a similar project named Limba Project (https://people.freedesktop.org/~mak/limba/)! But it seems that both of them are not ready to use.

[duby229]

disk space is still valid opinion... for those that stayed in 1990 and only have 40MB HDD some people just refuse to go with progress

That's not it at all. HDD's and yes even SSD's are still the slowest component of your computer. Do you really want to wait for it to read and write gigabytes of data? (make that a hellz to the nah!)

[Passso]

That's not it at all. HDD's and yes even SSD's are still the slowest component of your computer. Do you really want to wait for it to read and write gigabytes of data? (make that a hellz to the nah!)

If applications are still valid years after, yes. Because my SSD can write 1 gigabyte in 2s.

[blackout23]

That's not it at all. HDD's and yes even SSD's are still the slowest component of your computer. Do you really want to wait for it to read and write gigabytes of data? (make that a hellz to the nah!)

Yes because a PC opens and reads every file, when he wants to load a specific library in a specific path....

[duby229]

If applications are still valid years after, yes. Because my SSD can write 1 gigabyte in 2s.

Which is still thousands of times slower than RAM. Only 10 times 1GB is 10GB which would be 20s (that's a very best case scenario).... It's clear you're willing to put up with bottlenecks most people would find unbearable.

[duby229]

Yes because a PC opens and reads every file, when he wants to load a specific library in a specific path....

Totally besides the point I'm making. Look at Firefox loading times, and that is only one example..... At the very minimum it's proof beyond any doubt that loading from a (any) medium is a major bottleneck.

EDIT: My opinion is you should avoid touching storage at almost any cost. It -will- represent a bottleneck if you're careless about it.

[zanny]

Yes. If something needs GTK 3.20, but Ubuntu 16.04 only has 3.18 it will be bundled with the application. The "hur dur muh disk space" argument never was an issue in case anyone wants to complain about that. People happily install steam which downloads over a freaking Gigabyte of Ubuntu 12.04 Libs for the Steam Runtime so that games work out of the box on all distros with steam.

Coherent dependency management is not about disk space, it is about performance. When your software is all using the same so files, they can be shared in RAM and in CPU cache, dramatically reducing memory usage of programs and speeding them up by letting more of the common libraries be cached in ram or resident within it.

It is the difference between when you start a Qt program on KDE versus running a GTK program when no others are running, even on an SSD the startup times and memory overhead are very notable.

Throwing out twenty years of package management knowledge because simply providing up to date software is "too hard" is an egregious cop out worthy of Microsoft, not self respecting free software users. If you have a dozen programs using completely different versions of GTK your performance will be awful and your RAM will be full for no reason beyond the distributor being too lazy to do proper dependency management.

Arch even has dedicated users maintaining a native runtime for Steam to avoid the incredible overhead the Steam runtime imposes.

[plonoma]

Yes. If something needs GTK 3.20, but Ubuntu 16.04 only has 3.18 it will be bundled with the application. The "hur dur muh disk space" argument never was an issue in case anyone wants to complain about that. People happily install steam which downloads over a freaking Gigabyte of Ubuntu 12.04 Libs for the Steam Runtime so that games work out of the box on all distros with steam.

Interesting, does it also have a system to avoid duplicates of identical dependencies?
How similar is the Ubuntu Snappy approach in the file system to GoboLinud?

http://www.gobolinux.org/?page=at_a_glance

[duby229]

Coherent dependency management is not about disk space, it is about performance. When your software is all using the same so files, they can be shared in RAM and in CPU cache, dramatically reducing memory usage of programs and speeding them up by letting more of the common libraries be cached in ram or resident within it.

It is the difference between when you start a Qt program on KDE versus running a GTK program when no others are running, even on an SSD the startup times and memory overhead are very notable.

Throwing out twenty years of package management knowledge because simply providing up to date software is "too hard" is an egregious cop out worthy of Microsoft, not self respecting free software users. If you have a dozen programs using completely different versions of GTK your performance will be awful and your RAM will be full for no reason beyond the distributor being too lazy to do proper dependency management.

Arch even has dedicated users maintaining a native runtime for Steam to avoid the incredible overhead the Steam runtime imposes.

+1. Exactly the point I was trying to make, but you said it better than I could have.

[Passso]

Coherent dependency management is not about disk space, it is about performance. When your software is all using the same so files, they can be shared in RAM and in CPU cache, dramatically reducing memory usage of programs and speeding them up by letting more of the common libraries be cached in ram or resident within it.

It is the difference between when you start a Qt program on KDE versus running a GTK program when no others are running, even on an SSD the startup times and memory overhead are very notable.

This is a valuable argument.
But the reality is that, statistically, library size is ridiculously small compared to data size.