News for hackers. Stuff that matters.
Re:A Quick Introduction to Flatpak by curt15 on Monday December 05, 2016 @12:15PM (#13107012)
Something like the Windows API or OS X API would seem to provide a reasonable approximation of what functionality ought to belong in the runtime. These platforms have withstood the test of time and you don't hear about many problems resulting from third party developers bundling libraries. The base systems in those cases are comprehensive enough that app developers generally need to worry only about functionality unique to their applications. For example, when the "gotofail" bug was discovered in the OS X crypto libraries, Apple issued an OS update that ended the story right there.
Re:A Quick Introduction to Flatpak by davexunit on Monday December 05, 2016 @12:26PM (#13107143)
>These platforms have withstood the test of time and you don't hear about many problems resulting from third party developers bundling libraries.

If you run Windows, OS X, Android, or iOS it's 100% likely that you have several different versions of some C library that have known vulnerabilities in them. Think about things like proprietary games that aren't updated often, if ever, where things like libpng and stuff get bundled in. When the upstream libpng developers release a security fix, do the game developers release a new version of the game with that fix included? Almost certainly not. This is the problem with bundling. You are dependent on N upstreams for security updates to any given non-core library. It's a rampant problem, and it's a problem that GNU/Linux distributions address for the safety of their users.

>For example, when the "gotofail" bug was discovered in the OS X system crypto frameworks, Apple issued an OS update that ended the story right there.

Right, that is good. All of the applications were dynamically linked against the system's openssl, so the security update was easy. But only a few things are like that on these proprietary operating systems. GNU/Linux distributions, on the other hand, have this property for all software. It's absolutely crucial for user security.

Asking users to install these new Flatpak/Snappy/Docker things is asking them to accept a bunch of software known to be insecure. Running vulnerable software in a container doesn't make it much better. We need to develop systems that make it easier to run software that has all of the latest security patches. Tools like Flatpak are a bold step backwards.

Re:A Quick Introduction to Flatpak by cmurf on Monday December 05, 2016 @01:01PM (#13107568)
Users routinely do not do updates at all, let alone every other day which some distros make available. It's tedious. There's all kinds of peripheral breakage that really happens in contrast to security vulnerabilities that rarely become exploits let alone active ones.

Also Flatpak does contain the extent of damage by putting the application in a sandbox - different in implementation detail but hardly different conceptually than how Apple "app store" apps likewise run sandboxed with minimal interaction between apps allowed.

Re:A Quick Introduction to Flatpak by jjnoakes on Monday December 05, 2016 @02:31PM (#13108466)
Are the two really the same though?

I mean an application that breaks sucks, and you might have to roll back an update or wait for a patch. It is annoying and you may lose some time.

A security breach may be more rare, but it also might be much more damaging. You might lose your whole business or worse.

The right answer is probably some subtle equation of both problems relative to one's specific circumstances (trade offs) but "it depends" never makes for a good internet argument so most people don't bother with the nuances.

Re:A Quick Introduction to Flatpak by cmurf on Monday December 05, 2016 @02:44PM (#13108657)
Breakage on macOS, iOS, Android, is pretty rare. It's a bit more common on Windows but I'd still say it's rarish. On Linux distros it's just a matter of time before something breaks during an update, and rollback is not easy at all.
Re:A Quick Introduction to Flatpak by davexunit on Monday December 05, 2016 @04:27PM (#13109802)
Rollback on current mainstream distros isn't really possible because their package managers are rather primitive. Newer system package managers like GNU Guix and Nix feature atomic updates and rollback so breakage is easily remedied. Their associated distros, GuixSD and NixOS, feature rollback for the entire OS. I made a bad configuration change the other day that kept me from logging in to my desktop environment, so I just rebooted and chose the previous generation of my system from the GRUB menu and was back in action.
Re:A Quick Introduction to Flatpak by jjnoakes on Monday December 05, 2016 @09:35PM (#13111823)
I pin older versions of packages all the time via yum.
Re:A Quick Introduction to Flatpak by davexunit on Tuesday December 06, 2016 @06:35AM (#13113842)
Not the same thing. Yum also doesn't provide atomic upgrades.
Re:A Quick Introduction to Flatpak by jjnoakes on Tuesday December 06, 2016 @02:58PM (#13117767)
While not identical to Guix or Nix, it certainly is analogous to rolling things back. If I upgrade a package from 1.0.1 to 1.0.2 and it breaks, I can pin it to 1.0.1 and continue on my merry way.
Re:A Quick Introduction to Flatpak by davexunit on Tuesday December 06, 2016 @09:25PM (#13120011)
But without the rollback being atomic, there is potential for the rollback to fail and the system to be left in a broken state. Guix and Nix also can record many generations of the system and roll back to any one of them. Pinning packages with yum is very primitive and unsafe by comparison.
Re:A Quick Introduction to Flatpak by jjnoakes on Friday December 09, 2016 @11:28PM (#13144015)
Yum typically upgrades packages through very minor version changes. Like a.b.c to a.b.c+1.

Rolling back is not nearly dangerous as you are implying in a curated distribution.