What would you propose as the alternative when the deb version of a package is no longer available in a new distro release? Removing the package on upgrade would mean the user loses access to the software, and leaving the version from the last distro release in place is just asking for conflicts down the line.
Remember that the primary purpose of these packages is to allow someone to continue using the application they installed after upgrading to the new distro release. There is a long history of using transition packages to smooth over the upgrade process in both Debian and Ubuntu (e.g. transitioning from OpenOffice to LibreOffice, XFree86 to Xorg, etc).
What would you propose as the alternative when the deb version of a package is no longer available in a new distro release?
User has a choice:
1- allow snaps, and update the application from deb to snap
2- refuse snaps, and application no longer works
Todayâs situation, with the âdeb that actually installs a snapâ, doesnât really fix that problem, it just silently chooses option 1 for the user.
1- Snaps donât solve much for a normal user. Snaps give some new edge abilities such as user can run two different versions of an app in same system. Not many users need that. Installing a new app is less likely to break existing apps, because theyâre no longer sharing packages. And snaps create problems for some users: some (mainly server people) do not want to update, maybe ever.
2- Snaps are a big win for app developers: package once and it runs in N distros x M distro releases. Get a bug report or support request, probably no need to interrogate the user about the exact distro and release and system configuration etc.
3- Snaps are a pretty big win for distro developers: push packaging work onto the app developers.
⊠and you think it is okay to let them do this so their insecure server software can be hooked up to that botnet that serves the paypal fishing site you type in your account password at next login ?
Being a server admin comes with responsibilities to protect not only your users (or companies) data but also the rest of the world (if your machines are internet facing at least) from spreading malicious code.
I personally expect a responsible server admin to have regular maintenance windows for their servers, to create and check backups and close known security holes by applying updates. snapd allows you to set such scheduled maintenance times, the snap store even provides various channels to pick from so you can have a test system set up prior to the security update hitting the stable channel.
And as a last resort there is always snap revert to get you back to the last known good snap revision.
The internet is mankinds biggest community project, to prevent malware from spreading in pandemic ways, some hygiene is required ⊠even in the virtual world
What do you think of the other transitions I mentioned? Would it have been sensible to leave users stuck on an ancient OpenOffice release when there is a new LibreOffice package that is the obvious continuation of what they were using before?
Frankly, absolutely, yes. The owner of the system has the right to make decisions about it. It is not Canonicalâs or Snapâs job to force them into certain decisions. Linux gives the owner/user the power to do things, and sometimes itâs the power to shoot themselves in the foot.
Who knows, maybe they have good reason to prevent updates. Maybe security holes are being handled by a firewall or something else external to the system. Maybe an update would break their payroll-check-printing system. You and I and Canonical and Snap canât know the right thing for every situation.
The user (or system owner) should make an informed choice. Having a deb that really installs a snap seems underhanded. Inform them that the deb path no longer exists, or the version theyâre using has security vulns, give them the opportunity to change to the better/newer snap. But donât force them or deceive them.
well, not sure you read my words, i dont care at all if they shoot themselves in the foot but i do care about the fact that their unmaintained server becomes part of the botnet that kills my server with a DOS attack ⊠or that they provide hackers a platform to operate from to steal your data ⊠i dont care about their feet but about ours âŠ
they are free to use slackware from 1995 instead of ubuntu, nobody forces anyone to pick Ubuntu and snaps over anything else but if they do pick Ubuntu, snaps are there and come with a secure update mechanism that gives you enough abilities to adapt them to your own schedule.
And nobody forces them to use snaps or Ubuntu as i said in my last paragraph
(note that iâm working a lot with customers. most of them grok snaps and thier update mechanism and actually picked snaps explicitly because of it to run critical infrastructure in their factories, robots, IoT setups and embedded systems.
it isnt like people run away screaming from it, despite there being some loud complainers in the community.
from a business perspective it is exactly the opposite, people take snaps because of this)
Okay, every debate about snap updates that Iâve seen has said you can postpone updates, but not completely stop them. If true, this ability to disable updates forever should be publicized by Snap/Canonical.
To me, as a normal desktop user and an as observer⊠all of this discusión are artificial, there are number of ways to plan / pospone / remove all snaps and, if you want to, remove completly snap or use another linux distro. All the comments that scream that they are forced to swalow snap down their throath are to me just nonsense.
Nobody is forcing you and if, snaps are a failure then we can allways choose something else. The developers are open to discuss to constructive conversations, but as always you sometimes have to say ânoâ.
I for one, like the idea of snaps, and there are getting better with each release.
they are free to use slackware from 1995 instead of ubuntu, nobody forces anyone to pick Ubuntu and snaps over anything else but if they do pick Ubuntu, snaps are there and come with a secure update mechanism that gives you enough abilities to adapt them to your own schedule.
That sounds exactly as I said, like take it or leave. Nothing wrong with the approach, itâs fine with me - but I do understand why itâs not to others. Itâd be easier if the third path existed: some people do want to use Snaps, but donât want to have them auto updated. Sounds reasonable to me, but it seems you at Canonical see differently.
Edit: I know there are ways to prevent them form updating at all, but they all seem hackish; should be âofficialâ.
My main point is that while I understand Canonicalâs perspective and motives regarding auto-updating, I think that the alternatives (i.e. Flatpak, AppImage) are just a much more compelling, less âmy-way-or-the-highwayâ approach for distribution operators. Distribution operators are the key here: Developers arenât going to be happy if this âuniversalâ format turns out to be not universal after all.
Canonical seems to think that distributions will fall in line with their âmy way or the highwayâ approach. While Snap is nice, the highway (a certain alternative) is looking pretty attractive and is just âgood enough.â
Please note that while I work at Cannical, and do largely agree with the update design, I am an individual, only expressing my own opinion here, I do not speak fo the company.
That said ⊠note also that the update policy chosen for snaps by Canonical is actually a result of 16 years of experience dealing with update and security issues of users and customers. In my very personal view (having been around for that time) it is an awesome step forward in the evolution of packaging. Still though, please take my optiinon as mineâŠ
All formats are built with distribution-centered design in mind except Snaps. Snaps are built with user-centered design in mind. This is what makes Snaps different and good and the reason users like it and distribution devs dislike it. I donât want Snaps to become yet another format that is harder to use because itâs better for distros that way. I like what is better for users way.
If you prefer distribution-centered design itâs good all other formats are to your requirements. IMHO users are the key and it doesnât matter what distro devs support out of box if users want something else. Just like you, the user, have chosen right now to use something else.
Wikipedia would require a citation here with a âwho?â tag. If you are not in the demographic that wants this then please point those that are to come here to elaborate on why they want this. As you have implied you are not one of these people then what youâre saying is anecdotal.
There is a lot of noise with no real substance other than complaining. Without understanding the reasoning for people to want to disable updating we have nothing to go on. Until we have that clarity we will continue with our plan to ensure that people are updated so that their systems remain secure.
I must raise my hand here. I use snaps, I build snaps and I love snaps but I hate when snapd unexpectedly brings my machine to a halt. Yes, I could schedule the updates but I canât predict when Iâm going to be working on something important. Iâd much rather get a prompt to update instead of this happening beneath my feet.
One thing Iâve noticed is long boot times if you havenât used Linux for a while and all your snaps need updating. It would be nice to have snapd moderate itâs update process to do updates after the system is booted rather than during the bootup. I agree that updating when youâre about to go onstage for example would be really bad. I would like to see a âIâm doing important stuff nowâ button that holds updates until you close the lid, logout, or the screen idles to turn off or some other more reliable indicator that youâre finished with your important task and that updates can resume. What I donât want, though, is for that âimportant stuff nowâ button to be permanently effective once set; I would want some automated mechanism to reset it to âoffâ again.
