Slashdot Mirror
Ubuntu 16.04 LTS Will Bring Snap Packages For Up-To-Date, More Secure Apps (neowin.net)
An anonymous reader points us to a report on Neowin: Canonical, Ubuntu's parent company, has announced that Ubuntu 16.04 LTS (Long Term Support) will come with support for the snap packaging format and tools. As a result, end users will get more up-to-date apps, something that proved tricky in the past due âoethe complexity of packaging and providing updates,â which prevented updates to some apps being delivered. Snaps will make the Ubuntu platform more unified, developers will more easily be able to create software for PC, Server, Mobile, or IoT devices. The other major benefit of snaps is that that they're more secure than software installed through deb packages. Snaps are isolated from the rest of the system, meaning that malware packaged with a snap won't be able to affect your Ubuntu installation.
... choose manual partitioning ("Something-else" option), then select Ubuntu system partition, set its mount point as "/". Be sure to keep the same format type, the same size, and untick the "Format" checkbox or all data on "/" will be deleted!. Also set other partitions (/boot, /home... see DiskSpace) if needed.
This is an extremely dangerous way to reinstall.
Well I hope that open source packages won't switch to the new snap system, as of course it adds duplication, and now many application providers have to update one of their libraries only because of some badlock vuln or something. Some app store owners try to counter this by threatening app owners to take down their apps if they don't update the libraries. But this only gets the biggest libraries and those with most light shined on them, the small library might never get updated.
Yes, poettering has seen correctly that the duplication can be fought with fs level dedup like btrfs is doing it, but that still doesn't solve the update problem.
Where the snap system shines at is closed source applications and open source applications which both get shipped outside of the distro's packaging system: if adopted by all distros, you can ship cross-distro binaries without having to bother about some distro's settings for their libraries.
And closed source applications is one of the areas the linux desktop sucks at. There are almost no linux versions of many more or less popular closed sourced applications.
Who gives a shit about an extra 3-5 MB of libraries per app when traditional repos are compiling apps against library revisions that the authors never tested with? This has added a lot of unpredictability to running Linux systems (especially desktops).
OS X is a model of successful packaging and distribution and its about time some Linux distros were taking inspiration from it.
OTOH, even not considering library revisions, Linux packaging never was "proper" for applications beyond the server space or lab. It is a recipe for driving real app developers away from your platform, in part because you can't really define where your platform ends and where the apps begin. Though not necessarily "Linux" itself, the typical Linux distro is its own little hell when it comes to independently distributing applications to users.
Yes, grampa, people still use Ubuntu. The only bad part about Ubuntu is the Unity desktop environment. Xubuntu and Ubuntu MATE don't suck.
If you make the mistake of downloading the vanilla Ubuntu ISO, all you have to do is install a better desktop environment (apt-get install xfce4 or apt-get install mate-desktop), logout, login with the new DE, and then remove unity (apt get purge unity*).
Packaging format is not an impediment. Nothing prevents you from installing your app and all its dependencies into a subdirectory like /opt/my-project and distributing a tarball. Using the ELF ${ORIGIN} linker macro, you can even ship subtrees that can be transparently moved around as a bundle anywhere on the filesystem, just like OS X applications. So, for example, you could create my-project.zip or my-project.tgz that unpacks to my-project, and reliably execute the binaries straight out of my-project/bin regardless of where you unpacked my-project/, and without static compilation.
glibc has excellent ABI compatibility. It makes extensive use of ELF symbol versioning, which puts it lightyears ahead of Visual Studio's CRT and is much better than Apple's awkward MACOSX_DEPLOYMENT framework. So you don't need to statically compile libc or ship your own copy, as people often did 10+ years ago.
The persistent problem is that there's no single Linux platform. Not only are there myriad distributions, but they're constantly evolving, especially when it comes to system configuration and desktop integration. The real problems, such as they are, are much higher up the stack than packaging. systemd is trying to address that problem by inserting itself at the center of the universe, but irony of ironies, containers mean everybody is running dozens of different instances of systemd.
These container solutions don't solve anything real. They're shiny new tools for sysadmins to play with, and big fat excuses for developers to create even worse and packages.