this is sad [LWN.net]

this is sad

Posted Jun 19, 2016 2:58 UTC (Sun) by drag (guest, #31333)
In reply to: this is sad by amacater
Parent article: Klumpp: A few words about the future of the Limba project

If you look you'll see that they are not substantially larger then their rpm/deb equivalents if done correctly. Recently they re-did the Libreoffice snap that took the size down from ~1GiB down to 280-ish MiB or so. That is only 70-ish megs larger then equivalent rpm or deb files and even then those don't include Java, which is necessary to unlock all the Libreoffice features.

to post comments

this is sad

Posted Jun 19, 2016 8:56 UTC (Sun) by lsl (subscriber, #86508) [Link]

As it is, the flatpak variants are also strictly less useful. With a standard LO installation, I can easily use its filters from a script to convert weird document formats to something more usable. I can just install a JRE to unlock the remaining features. Does the latter work with the Flatpak? What would I need to go through to achieve the former?

LibreOffice is already the kind of software that's a pretty good match for what Flatpak can do. The utility of many other programs will be much more severely restricted when decoupled from the system.

Interaction with the system is a desired feature of most software. These are not smartphone apps. It's also the hard part of any sandboxing effort. Annoying the user with thousands of file picker dialogs is not going to cut it except for the most trivial of programs.

this is sad

Posted Jun 19, 2016 8:59 UTC (Sun) by nim-nim (subscriber, #34454) [Link] (1 responses)

They're comparing pathological cases, apps which have been decades in writing, with lots of specific private code, and which have been forced to sanitize their requirements due to years of distro pressures.

That's pretty much the ideal case for flatpack or snap (I suspect just taking apache openoffice instead of libreoffice would be quite less rosy).

Even there they have ~ 30% of wastage.

That's the usual "trade dev convenience for everyone else's" and "cargo cult windows/apple/android to win market share¹" (the only change is who is being cargo culted, usually via themes of other superficial things)

It will probably end with the usual "dev does not understand why no one follows him".

I just hope they won't damage too much the platform in the meantime.

¹ Years of efforts poured in the Linux desktop, with lavish use of distro gifts and exceptions, have produced little in terms of market share. Meanwhile the people who focused on doing their own thing instead of aping the mistakes of others have actually found their way to people homes (in appliances, in owncloud, etc). With things like Office 365 and skype Microsoft is actually on the way to the network desktop that could have been done years ago Linux side if people had not focused on burying its *nix network heritage and copying every half-hassed network-ignorant Microsoft or Apple tech they could find out.

this is sad

Posted Jun 19, 2016 9:46 UTC (Sun) by halla (subscriber, #14185) [Link]

"trade dev convenience for everyone else's"

It has nothing to do with "dev convenenience" -- I would prefer not to have to make binaries, it's a timesink. And "everyone else's" only applies if by "everyone" you mean "everyone but end users".

this is sad

Posted Jun 19, 2016 21:03 UTC (Sun) by callegar (guest, #16148) [Link]

Doesn't this just prove that you can bundle all libraries in DEBs exactly as the snap packages do? This comparison is against the LibO provided DEBs, that bundle a lot of stuff. If you compare with the Debian provided DEBs, I think you get 280MB vs ~100MB, which is almost 200% larger.
Increasing size is not such a big issue for the disk (you can get a bigger one), it is an issue for your cache memory.