There is no killer app. There is killer functionality very much needed.
preinst + postinst functionality
user account addition
For a kiosk like application I’ve been experimenting with migrating a .DEB to one or more snaps. With such an application you need the ability to create a non-priv user then to auto-launch an application for that user. This requires writing to the .config directory of said user, once the install creates the user. Normally, with a .DEB, you do stuff like this in the postinst proc because now you’ve unzipped everything AND you know the architecture.
preinst tends to be used for determining the architecture and which portions of content will be “activated” (for lack of a better term).
The current snap universe seems to be focused on the rather microscopic universe of a single pre-existing user install an app (like a text editor) from a store for themselves or perhaps all users. All of the requests I see for postgresql aliases seems to bear that out.
The ability of snap to completely replace Debian packages in every way, including letting 32-bit executables run on 64-bit hardware is high on the wish list of many.
It wasn’t abuse or a random discussion. The title of the other thread was
Snap wishlist - suggestions wanted!
and it made no restriction/limitation of the wishlist being only for new packages. The above requested features, especially the ability to create users.
At any rate, your assertion that auto-launched applications always run as root is completely incorrect. On some single application embedded systems poor design would have the application running as root, but, most, especially in the FDA regulated medical device world (been there, done that, got the t-shirt), run as a user with minimal required privs. The reason behind such a regulation is the kernel can protect (in many cases) a mere mortal user from programmer stupidity/unintialized something or other. It will kill the offending application off and the (usually hardware) watchdog will re-launch it. Some watchdogs will even trigger the transmission of the last N-thousand bytes of syslog along with configuration information so a failure can be analyzed.
Even industrial devices with custom Linux builds will avoid running as root for the very same reason. Got both the t-shirt and hat.
Having said that, there are literally millions of kiosk style applications running every day on ordinary desktops, laptops, tablets and other consumer devices. These applications all install as a captive/non-prived user and can be removed by nuking the kiosk user from a root/admin account. Applications like these are everywhere and none of them run as root. You will see them at trade shows/fairs, seminars and pretty much every big box store in the world. (Walk through the computer section and see if you don’t find quite a few (all?) with some kind of “Explore this computer” kiosk application.) When the promotion ends, or the store needs to sell the “open box” item, they nuke the kiosk user and the machine is now ready either for the current owner to continue using it or for the purchaser to perform their very first login and set up the machine.
Sorry, but I’ve been at this software development thing a while.
Not trying to be a jerk or anything, just pointing out the width of experience in one’s past dramatically impacts the width of one’s field of forward vision.
If snap really wants to earn the slogan of “universal Linux package” or whatever, it must provide all things Debian and RPM provide. Keeping tunnel vision focused on single person apps downloaded from some store and installed by an ordinary user won’t let it achieve that status.