uhnllon
Well, I have found some strange, out of common, software - mostly comercial stuff - which doesn't have any .deb available nor ppas, nor nothing.
It is clearly a decision from somebody who said "no, we are not spending hours packaging our app, if they want it, they will try to install it with the methods we will provide"
Kind of nonsense, except that if you're in Linux looking to install a comercial app, special snowflake, is probably because you have zero chances to do otherwise, then you bit the bullet and try whatever crazy method to deploy their app they have put in place.
Most common stuff I found: - Just download my zipped binary, you know how to deploy it - Just run this command line, "sh something" giving it root credentials to run code from the Internet (YEAH I KNOW TOO, as much insecure as it gets)
Having said that, many comercial apps are there for to be easyly downloaded as .debs (they should just install with a GUI right out from the link, in old-Ubuntu behavior). Or they even offer you detailed instructions to configure a ppa (to manually install with apt).
Heck, nowadays it is common sense and good netiquette to make your installation scripts in the downloaded .deb to just deploy the ppa for apt, so next upgrade happens automatically.
If you ask me and I wouldn't dreaming to control the app-deployment infrastructure in Linux, I would say "yeah, you need to contact EVERY software not providing the .deb format and start working with them, providing them free support, even free scripts to handle the packaging"
I remember in the 90s, there was LOTs of shareware because Microsoft knew this stuff from the 70s and 80s: if you want you're software in use, you need to talk directly with those who could probably use it.
No, links hanging in some flashy website won't cut it, nor repos in github half sharing some code.
Nobody can assemble some new kind of app packaging, slowing the starting speed to 5-10 seconds and call that "good rounded software"
"It is just a couple of seconds more sometimes, not a big deal" isn't going to cut it. Most of the Internet using Ubuntu, already knows that.
I think Canonical is again in denial.
It already happened a couple of times: MIR, Unity (buried by not being community driven probably), Unity8, the mobile project or something, all but forgotten now.
This snap thing is probable the pet project from a couple top guys in Canonical. Maybe hundreds of powerpoint presentations have been watched about some "big strategy" for the next years, but they didn't know the thing (snap) is unbearable slow.
Sorry, snaps are a LOT slower than just running a binary. Did I said they're slow, well they're slow.
I have an SSD and it feels like it's 1992 and I'm trying to run some snap from a Cyrix without cache and 16MB of RAM. I switch to binary version (oh my chromium), and it freaking flash, 0.x sec. and you're there, the full app is available.
Snaps are a NO GO my friends.
Besides having LOTS of problems running out of the standard GUI (Gnome3), or even in the standard (supposedly heavy-tested) GUI, they are slow.
Sorry, I've already said that uh? SLOW, that's snaps.
If there is somebody from Ubuntu here, please take a serious look about how snapped apps (pun intended), read/write $HOME defaults.
I mean we have to have defaults somewhere. So thingies like the colour theme, the theme engine, default download path, etc. are fully followed just as the user has configured them.
I use Ubuntu, but I certainly would not be using in the future if my applications which now take merely 0.x seconds to open start to take, 3-4-15! seconds to open. I fact I started to look to Debian and Fedora, they currently appear to have saner defaults than Ubuntu.
No, the second time I open an app in a session doesn't count AT ALL for the speed.