I’m clearly late to this copulation of clusters, but from purely technical standpoint, where can one find an authoritative, *detailed* document describing what problems Snap attempts to address and what mechanisms it employs to do so.
I ask because this feels very familiar. When SUN led the way by putting dynamic linking into SunOS, the first versions were absolutely pilloried because of process startup overhead. (App launch delay.) SUN figured out the hot paths and added a couple of small caches in the dynamic linker and presto! Much much better. But it did require some serious sleuthing.
Likewise, when Apple introed sandboxing, the world was going to end. Luckily the devs fought it to a draw before anything slipped out, but the behavior did change fundamentally and only now is it getting to be mostly invisible.
This is all important because the “user”-based protection model we’ve used since forever, even augmented by the operational nightmare of ACLs, is completely insufficient.
Ex: at three different banks I am three completely unrelated people. A malware attachment to a banking app like Quicken
which has access to all three banks could
interfiltrate information between banks to
identify customers ripe for the picking.
Likewise, the trust level in apps is certainly not uniform. Library routines that read data
from files is trusted mot to make clandestine
copies of information. The Apple sandboxing
is the only widely deployed system which
can manage a “least privilege” surface down
to libraries which heretofore have been trusted because there was no alternative.
So even if an app is running as “you”, there
are areas which have historically used the fact it was running as “you” to perform some clandestine compromise. By doing a better job of compartmentalizing the app trust model a great deal can be done to prevent “surprising” app behavior.
I am wondering if the Snap machinery is trying to address these issues and is
plowing its own set of furrows trying to get there.
sorry for the length, but i’ve been working in this space for some time and hope there is something there to learn from.
I tested the startup of Calculator on a Ubuntu system a year (two? three?!) ago and while the universe version from the repository took little to no time to launch cold the snapped version took several seconds. I have never used snapped packages after that. I love the idea of the Unsnap project. 😂
Also, don't you dare SIDELOAD an AppImage on your Ubuntu system!
I suspect that snap was always designed to be a packaging and deployment system for server and edge computing devices, not desktop. Though I can also imagine those weird, extremely costly proprietary Linux software also finding snap useful too.
I don't think applying it to the average piece of free software was the intended usecase at all and you can see how flawed a desktop built off of snap tends to be.
People in the Linux community are an odd bunch. Unity was hated, but you can now run it on Arch, and the ubports folks have kept working on it… it’s actually quite nice. Upstart was hated, but quite a bit less than systemd and that’s now half of the system in most distributions (though most have configs that ameliorate a few flaws that are default in systemd). Now, we have snap. A new thing to hate, and while it is likely to fail and flatpak is likely to succeed, it’s still interesting seeing the amalgam of things that Canonical has tried. It would be very interesting to see a release that had all of these things: Unity, Snaps, Upstart, and Mir. Just what vision has Ubuntu been chasing?
I’m clearly late to this copulation of clusters, but from purely technical standpoint, where can one find an authoritative, *detailed* document describing what problems Snap attempts to address and what mechanisms it employs to do so.
I ask because this feels very familiar. When SUN led the way by putting dynamic linking into SunOS, the first versions were absolutely pilloried because of process startup overhead. (App launch delay.) SUN figured out the hot paths and added a couple of small caches in the dynamic linker and presto! Much much better. But it did require some serious sleuthing.
Likewise, when Apple introed sandboxing, the world was going to end. Luckily the devs fought it to a draw before anything slipped out, but the behavior did change fundamentally and only now is it getting to be mostly invisible.
This is all important because the “user”-based protection model we’ve used since forever, even augmented by the operational nightmare of ACLs, is completely insufficient.
Ex: at three different banks I am three completely unrelated people. A malware attachment to a banking app like Quicken
which has access to all three banks could
interfiltrate information between banks to
identify customers ripe for the picking.
Likewise, the trust level in apps is certainly not uniform. Library routines that read data
from files is trusted mot to make clandestine
copies of information. The Apple sandboxing
is the only widely deployed system which
can manage a “least privilege” surface down
to libraries which heretofore have been trusted because there was no alternative.
So even if an app is running as “you”, there
are areas which have historically used the fact it was running as “you” to perform some clandestine compromise. By doing a better job of compartmentalizing the app trust model a great deal can be done to prevent “surprising” app behavior.
I am wondering if the Snap machinery is trying to address these issues and is
plowing its own set of furrows trying to get there.
sorry for the length, but i’ve been working in this space for some time and hope there is something there to learn from.
-mo
I tested the startup of Calculator on a Ubuntu system a year (two? three?!) ago and while the universe version from the repository took little to no time to launch cold the snapped version took several seconds. I have never used snapped packages after that. I love the idea of the Unsnap project. 😂
Also, don't you dare SIDELOAD an AppImage on your Ubuntu system!
Easy enough to add flatpack support after the fact, maybe a inconvenient hurdle for newer users.
I suspect that snap was always designed to be a packaging and deployment system for server and edge computing devices, not desktop. Though I can also imagine those weird, extremely costly proprietary Linux software also finding snap useful too.
I don't think applying it to the average piece of free software was the intended usecase at all and you can see how flawed a desktop built off of snap tends to be.
People in the Linux community are an odd bunch. Unity was hated, but you can now run it on Arch, and the ubports folks have kept working on it… it’s actually quite nice. Upstart was hated, but quite a bit less than systemd and that’s now half of the system in most distributions (though most have configs that ameliorate a few flaws that are default in systemd). Now, we have snap. A new thing to hate, and while it is likely to fail and flatpak is likely to succeed, it’s still interesting seeing the amalgam of things that Canonical has tried. It would be very interesting to see a release that had all of these things: Unity, Snaps, Upstart, and Mir. Just what vision has Ubuntu been chasing?