KDE & Snappy

[vtpoet]

Just curious if and how KDE/Kubuntu plans to adopt snappy. Seems like this would be ideal for NEON.

[vinnywright]

what is "snappy"?

VINNY

[Danum]

what is "snappy"?

VINNY

A crocodile after you have joined him/her for a swim

https://developer.ubuntu.com/en/snappy/

Are snaps replacing click and deb packages?

Snaps are the next generation of apps for all Ubuntu devices.

[GreyGeek]

Sounds vaguely familiar. There was a Konqueror (IIRC) plugin which allowed one to click on a "Klix" file on a web page. That file was a relabeled ISO file and the plugin copied it to a subdirectory on the home path. When the Klix file was clicked on locally it used the mount command with the loop parameter to open up the ISO file as a directory with the desired application inside. Also inside were all the libraries that the executable needed linked via environment variable created during the mounting process. If the app created files, say letters or other documents, they could be stored inside the loop structure or external to it. When the executable was terminated it would also recreate the ISO with the new documents inside. To delete the application one simply deleted the ISO file (*.klix).

[vinnywright]

I am wandering what the "bloat" factor will be with this ,,,,,,, app1 has libfoo-ver-123 , and app2 has libfoo-ver-123.4 and so on instead of using the shared system lib's .

+ this seams like the first step to locking you in to this one model .

VINNY

[GreyGeek]

I am wandering what the "bloat" factor will be with this ,,,,,,, app1 has libfoo-ver-123 , and app2 has libfoo-ver-123.4 and so on instead of using the shared system lib's .

+ this seams like the first step to locking you in to this one model .

VINNY

Bloat indeed. With each "snappy" package carrying ALL of its own dependencies (classic of static binaries, except that the required libraries are compiled into the executable, making them much larger. How much larger depends on the number of necessary binaries. Statically compiled programs have their advantages, the primary one being that the developer doesn't have to worry too much about the user having the necessary libraries, which is always a concern for developers who use dynamic compiling. The deb packaging system, however, usually tags missing libraries for installation if necessary, unless version conflicts block it.

Say you installed 50 packages using Snappy and each one required 15 libraries. You will have 50 copies of each of those 15 libraries taking up disk space. When disks were small space was at a premium and dynamic binaries were almost a must. In the age of Terabyte HD's not so much.

[Snowhog]

Such 'encapsulated' applications is how BSD (PC-BSD at least) does it. Each application you download/install is 'complete', having no dependency on any other package(s); it only requires the existing operating system. Now such a design does have it's upsides for sure, not the least of which is that changes to another package application only affect that package/application. If it fails to install/run, it doesn't affect any other application installed on the system. But that comes with a price, and as GreyGeek pointed out, it's space consumed on your drives. Everything is a compromise, and nothing is ever perfect in everyones eyes.

[claydoh]

It depends on how deep the dependencies go on the application level what needs to be added in a snap, and there is support for delta packages. I don't think that desktop packages will go that deep.
But it fixes a lot of things on application packaging. My KMyMoney packages depend on a number of non-kde, non-qt libraries that often are out of date in the Ubuntu repository, but these are not large in size by any means.. I have to package these separately sometimes for older *buntus, and tbh it is a butt-pain to do for each and every one, so I simply do not offer KMM updates for all of them. Snappy solves a bunch of that (assuming it works as advertised - early days still!) as it goes out to git or wherever and pulls in and builds the things I have specified. They run sandboxed, and also allows for rollbacks to previous versions.

A downside is if there is a vulnerability in some library version, and that is used in a number of snap-based things, is sandboxing enough? And then it is up to the program developers/community to make sure something that they may never actually touch code-wise is safe and secure and updated as needed. Sure, package sizes may be larger, but really, depending on what depth is needed, were talking kb not mb.

kdenlive, which is a huge pita to get packaged up and running due to variations in library version requirements (across distros, not just in *buntu) would benefit greatly from this.

Also, debs are not going away, not for a bit at least.

http://www.cio.com/article/2914850/l...ete-story.html

Imagine, though, if were possible to scale it up, having a core kubuntu-desktop 'snap' that did not rely on debian packaging (which is a major issue with us in terms of workload and manpower) and included an unmodified, more up-to-date Qt (which often fixes a number of bugs), updated via a delta (changes-only) package, and can be rolled back? Interesting....


Also note that snappy is not the only game in town, Gnome now has it's similar xdg-app system, and there probably are others.

[GreyGeek]

It depends on how deep the dependencies go on the application level what needs to be added in a snap, and there is support for delta packages. I don't think that desktop packages will go that deep.
But it fixes a lot of things on application packaging. My KMyMoney packages depend on a number of non-kde, non-qt libraries that often are out of date in the Ubuntu repository, but these are not large in size by any means.. I have to package these separately sometimes for older *buntus, and tbh it is a butt-pain to do for each and every one, so I simply do not offer KMM updates for all of them. Snappy solves a bunch of that (assuming it works as advertised - early days still!) as it goes out to git or wherever and pulls in and builds the things I have specified. They run sandboxed, and also allows for rollbacks to previous versions.

Lack of syncing between components of a tool or application is exactly why I never adopted Boa-Constructor as a GUI RAD tool. It was difficult to get all six components on the version the developer was using. Several Java GUI RADs were in the same boat. It was precisely because Qt was single sourced unified tool (TollTech) that I adopted it in late 2003.

Also, debs are not going away, not for a bit at least.

http://www.cio.com/article/2914850/l...ete-story.html

Imagine, though, if were possible to scale it up, having a core kubuntu-desktop 'snap' that did not rely on debian packaging (which is a major issue with us in terms of workload and manpower) and included an unmodified, more up-to-date Qt (which often fixes a number of bugs), updated via a delta (changes-only) package, and can be rolled back? Interesting....
...

Your citation had a confusing sentence:

Snappy Personal is the ‘desktop’ image that comes with the graphics stack; it is built on top of MIR and Unity 8.

Kubuntu and other spinoffs are backing Wayland, but Unity is tied tightly into MIR, so will the Kubuntu dev team strip Unity 8 before release or will it be selectable, along with MIR, from the login screen?

Currently in Kubuntu 16.04 there is no option on the desktop tab of Setup to select the resolution or raster, or at least in the LiveCD version which I tested yesterday. Will that require a change to some system config file from now on, or is it changeable by the user at all?

EDIT:
I think I discovered the reason for Snappy. I was looking for a Unity 8 video on YouTube and came across one featuring Ubuntu 16.04. It appears that Ubuntu comes with few apps installed and one must open the "Ubuntu Store" and install user apps. The 17 minute video spends most of its time playing around with the store.

[sithlord48]

Snappy makes me think that ubuntu is tring for one thing. To make it easier for closed source apps to be sold via the app channels (moble and desktop) and even via 3rd party ones (steam , etc) ..
Lets look at who benifits from this snappy format. Snaps as they are called are selfcontained packages that have all the dependcies for the program included it will basicly be like Mac OS and their .APP bundle. First off this means BLOAT as every program will ship with common dependices.Think about the horror of kde packaged with snap a copy of kdelibs and qtlibs for every kde program . They claim the snap system will help distrubutors because it will just work on ubuntu because of the included dependcies. think about that for a second, how does this improve the current setup using dpkg and deb tools .. it does nothing but add bloat to your system. Debian packaging works because the repo is all built using a common set of libs when those change programs are rebuilt. This makes for a much smaller and more perdictable system. While the claim is that snappy will allow for more updated software. Isn't this why we have the ppa system, its pretty easy to maintain (i run two ppa one stable and one from daily git built one) its basicly automated to maintain and using ppas for the end user is very easy also. Now some will argure (as i have read online in discussions about snappy) that ppas are insecure because the scripts made by joe dev run as root and could purposefully harm your computer. Snappy runs basicly on top of a docker sandbox so its much safer. But has there ever been a single known malicious package on a PPA? And whats stopping the easier to make and distrubute snaps from doing the same, also i have heard nothing of support for package signing. I have also read that snappy will be able to use either their bundled version or the system version of a libary , WHY? doesn't that kinda undermine the purpose of snaps to begin with. Not only do i have to download a snappy package with the libary in it but it also might not even use that lib and use a system version instead. This is susposed to be incase of bugs in libs. If you have a gpl program and your repository is doing its job you will have security updates and packages that need to be will be rebuilt anginst the newer libs the rest that just link to them will benifit as well because shared libs . So how exactly does snappy make it easier for open source programs and packagers again? Properitary programs will benefit from this because software house can use outdated libfoo forever and never have to adapt their code because that cost money and time.

Edit::
What i wonder is will this replace PPAs in the future .. if you use launchpad you know it has its shortcomings bugs for years that makes some programs really hard to build. like this evil one from 2009 still there are programs i can't build because we used a submodule at some point so now i have to maintain a clean repo free of the submodule and do manual syncs to avoid breakage. Looks like wall building now with a new packaging format to slowly replace debian packages with. Since ubuntu is not exactly known for contributing much to upstream or doing things nicely for upstream (how many distros can install unity) I seriously doubt that snap packages will work on non ubuntu based distros.

[claydoh]

There is nothing for kubuntu to 'strip out' - it puts things on top of the Ubuntu core, just as it always has.


Debian snapshot-----Ubuntu core ----------mir--------unity8/snappy
vs
Debian snapshot-----Ubuntu core ---------- xorg ------kde/whomever else doesn't use Mir

someone adding one DE to the other would have to also install a second set of video bits as well ass the extra qt or gtk stuff


So when you get to your login screen, your DE determines the video layer run. Xorg/wayland/mir do not start until you get past the login manager.



KDE will not be built for Mir (unless someone hacks/ports/modifies it all), it will use xorg and eventually wayland. Ubuntu going to Mir does not change this for the flavours. Xorg/wayland is not going away.

[woodsmoke]

I first saw this on "Particle News" for Android.

I IMMEDIATELY backttaced through the phone and later on my "tower" through ALL of the "previous posts/blogs/announcements/whatever".

THE OPERATIVE THING IS THAT ANYONE READING THIS SHOULD....

BACK DOWN THROUGH THESE POSTS....

from the "bottom up"

Claydoh
Sithlord48
GreyGeek
Claydoh
Snowhog
Graygeek

START FROM the bottom GG and read UP.

woodsmoke

[woodsmoke]

BTW

"snappy" is all over social media.

woodsmoke

[GreyGeek]

Claydough, you cleared up a misconception I had about how KDE was added to Ubuntu to make Kubuntu. I assumed they began with the Ubuntu release ISO and stripped off MIR and Unity. So, they start at the core level, not with the full, released distro. I've never seen or heard of any mention of a "core" release of Ubuntu. Is the core downloaded from a private server?

Sethlord48 has expressed better than I did the fundamental problem with Snappy on Kubuntu. Snappy would certainly kill Kubuntu's ability to be installed on older hardware with smaller HD sizes. Running it on VirtualBox using 16 or 20GB would be out, too. Would 100 GB be big enough if one loads a couple dozen Snappy apps?

Klix failed during a time of small HD sizes. Snappy doesn't have to worry about HD sizes on relatively new hardware, and people who can't afford newer hardware won't be buying much from Canonical's store, but that is where they will have to go to get FOSS and updates? The video I linked to in a post above shows that the "App Store" is, for all practical purposes, a clone of Apple's app store and it's form factor favors tablets and phones, not desktops. I'll be sticking with Synaptic and Repositories.

This old dog is going to have to learn the new Plasma5 tricks. Sticking with 14.04 till its EOL is just kicking the can down the road, and three years from now I'll have fewer functioning grey cells than I presently possess, if I will have any left at all.

Maybe a KDE distro from the KDE dev team built on top of their own kernel/utilities and well integrated into them sounds good. (I know, the "KDE distro" was a Lunduke click-bait article, but the more I think about it the better I like it. Canonical servers are replaceable.)

[vtpoet]

Lets look at who benifits from this snappy format. Snaps as they are called are selfcontained packages that have all the dependcies for the program included it will basicly be like Mac OS and their .APP bundle. First off this means BLOAT as every program will ship with common dependices.Think about the horror of kde packaged with snap a copy of kdelibs and qtlibs for every kde program . [SNIP] Properitary programs will benefit from this because software house can use outdated libfoo forever and never have to adapt their code because that cost money and time.

Personally, I couldn't give a fig about "bloat". Given that on average I really only ever install a dozen major pieces of software (and I'd argue that's fairly representative), the whole "bloat" argument on systems that currently come with massive hard drives is just blowing smoke. I have a 500 gig SSD and I struggle to use a third of it. Sure, if you're hoarding apps on a system from 1999 I guess it would be problem; but the whole SNAPPY package management system isn't designed for yesterday's system; and users for the foreseeable future don't have to use it.

As to more proprietary software... so what? For example, I'd love to see a hacker repackage the old WordPerfect for Linux via Snappy. It's not just new software for Linux but old software that could be brought back to life (repackaged with older dependencies). Yeah, it could introduce vulnerabilities, but so what? Use at your own risk.

Frankly, I don't see any downside to KDE/Kubuntu using snappy to update KDE on LTS Ubuntu systems.