Firefox with your CLI it would instead execute the command to install it as snap. Shit like that is just outright disrespectful to the user.
I get it and, at the same time, I get it.
Ubuntu needs to be able to deliver with some level of guarantee for its corporate clients, which means testing. A browser like Firefox has a lot of dynamically linked libraries. How do ensure that it works with all reasonable combinations? 10 libraries with 2 supported versions each is 1024 combinations. A browser will have more libraries and more compatible versions of each, which leads to a massive number of combinations. Nothing like having a support customer with issues because a very specific patch version doesn’t work with another very specific patch version.
Compare that to snap. 1 artifact that contains all dynamically linked libraries. 1 artifact to test and support.
So, now Canonical has a tested and supported snap for a security sensitive application, whose method of delivery also isolates it from the host it runs on. Should they point users to that? Or some upstream binary that may have the above compatibility issues and lacks isolation, and wasn’t tested by them.
Short of it is that DLLs made a lot more sense when storage was expensive and programs were smaller. Now, they are problematic. Containers are a way to address that without having to update a ton of software, and they also improve security. If they hadn’t done it, the community would have torn them a new one for keeping the good stuff for their corporate clients.
That said, there have been a lot of missteps. The inability to have a self-hosted store of snaps (this may have changed since I last checked) and improper packaging of apps like Steam are good examples of this. On the other hand, PCSX2’s 32-bit version ran just fine long after Ubuntu went 64-bit-only.
That’s a good argument for Snaps & Flatpaks, not for putting an alias in place so “apt install Firefox” gets translated to “snap install org.mozilla.firefox” (or whatever the exact app name is). Corporate clients manage their systems as a fleet anyway, if the IT department sets it up a certain way their employees don’t fiddle with this stuff. There’s no good argument to redirect a users’ CLI commands to whatever Canonical believes is better.
That’s a good point. I think Canonical offers some services where they will actively support your system, so it makes economic sense for them to make choices that limit transparency a bit for stability and predictability.
I think the dislike comes from the fact that Ubuntu was and still is many people’s intro to Debian based OSes, and it’s just not as user-centric as it used to be. Thankfully alternatives like Mint exist to bring it back a little bit for people who care.
I get it and, at the same time, I get it.
Ubuntu needs to be able to deliver with some level of guarantee for its corporate clients, which means testing. A browser like Firefox has a lot of dynamically linked libraries. How do ensure that it works with all reasonable combinations? 10 libraries with 2 supported versions each is 1024 combinations. A browser will have more libraries and more compatible versions of each, which leads to a massive number of combinations. Nothing like having a support customer with issues because a very specific patch version doesn’t work with another very specific patch version.
Compare that to snap. 1 artifact that contains all dynamically linked libraries. 1 artifact to test and support.
So, now Canonical has a tested and supported snap for a security sensitive application, whose method of delivery also isolates it from the host it runs on. Should they point users to that? Or some upstream binary that may have the above compatibility issues and lacks isolation, and wasn’t tested by them.
Short of it is that DLLs made a lot more sense when storage was expensive and programs were smaller. Now, they are problematic. Containers are a way to address that without having to update a ton of software, and they also improve security. If they hadn’t done it, the community would have torn them a new one for keeping the good stuff for their corporate clients.
That said, there have been a lot of missteps. The inability to have a self-hosted store of snaps (this may have changed since I last checked) and improper packaging of apps like Steam are good examples of this. On the other hand, PCSX2’s 32-bit version ran just fine long after Ubuntu went 64-bit-only.
That’s a good argument for Snaps & Flatpaks, not for putting an alias in place so “apt install Firefox” gets translated to “snap install org.mozilla.firefox” (or whatever the exact app name is). Corporate clients manage their systems as a fleet anyway, if the IT department sets it up a certain way their employees don’t fiddle with this stuff. There’s no good argument to redirect a users’ CLI commands to whatever Canonical believes is better.
That’s a good point. I think Canonical offers some services where they will actively support your system, so it makes economic sense for them to make choices that limit transparency a bit for stability and predictability.
I think the dislike comes from the fact that Ubuntu was and still is many people’s intro to Debian based OSes, and it’s just not as user-centric as it used to be. Thankfully alternatives like Mint exist to bring it back a little bit for people who care.