111–120 of 645 posts
Anybody have commentary on how this snap stuff impacts those who use Ubuntu on their EC2 nodes? So far I see complaints about Chromium, which typically doesn't exist in a server environment.
Earlier quoted context omitted.
Software companies are not infallible, and I've received updates in the past that have broken things. Enterprises don't get compensated for lost productivity when an auto-updating app results in broken workflows. Also, we recently got hit with a bug in a new auto-updated version. [0] It's great that this was finally fixed but silently rolling out updates like this make it harder to catch these issues before they are…
OK, so there was an image orientation bug in that specific release of Chrome. But it's estimated there are 1 billion users of Chrome. One billion! How wide of an attack surface does that present? Or how much of a nightmare would it be if they were all on wildly different versions? I get that this specific bug may have caused problems for you. But if I had to choose between security and compatibility for 1 billion sof…
My phone living on an older version of chrome is included in that number. It won't be updated.
You are looking at 20 million at most. Most are running just a server. If you are lucky if 1% are affected. Doesn't really close the loop and in the worst cases it breaks more experienced computer users.
Not the greatest tradeoff.
> Auto-updating of snaps can only be deferred at best, until at some point, like Windows, it auto-updates anyway. Even on metered connections, snaps auto-update anyway after some time. This attitude is obnoxious. Yes, not everybody is on a metered connection or running a mission-critical system, but some are, and it is hardly unreasonable to accommodate them.
I guess it's finally time to switch to Arch. This is an absolute deal breaker for me as well, as I use an ubuntu system for live visual performances, and I need to ensure that no unexpected auto-updates take place.
> Auto-updating of snaps can only be deferred at best, until at some point, like Windows, it auto-updates anyway. Even on metered connections, snaps auto-update anyway after some time. This attitude is obnoxious. Yes, not everybody is on a metered connection or running a mission-critical system, but some are, and it is hardly unreasonable to accommodate them.
To be fair, Snappy isn't aimed at "mission critical systems", nor even at bandwidth constrained users. It's a straightforward, reasonably robust and obviously used mechanism for pushing routine consumer software. In that realm, the aggregate benefit to society of having everyone running current software outweighs the annoyance of the specialists, sorry. It's always been this way. If you are running "mission critical"…
That combined with Ubuntu forcing snaps as the main packaging method (i.e. you have to jump through various hoops to install .debs of snaps) is what a lot of the outrage about.
(Side note: Something about listing Docker as a packaging mechanism makes me uncomfortable. IMO Docker and containers in general are deployment tools, not packaging systems)
It's a rolling release, so you don't have to stop what you're doing every 6 months - 3 years to install a huge update that changes the way everything works. It's more stable than the name would suggest, as long as you follow a few reasonable best-practices [1].
Software available on Debian testing is pretty up-to-date... If you're previously tried Debian stable but were put off by ancient packages, you won't see this in testing. Keep in mind that Debian testing (not stable) is upstream for Ubuntu's releases, so Debian testing's packages will be about as new as Ubuntu's packages on release day (but they're updated continuously, so they stay fresh).
I have personal systems running Debian testing or unstable that have been running continuously for 5-10 years without issues. They don't look or feel any different than systems I set up a few months ago.
> Auto-updating of snaps can only be deferred at best, until at some point, like Windows, it auto-updates anyway. Even on metered connections, snaps auto-update anyway after some time. This attitude is obnoxious. Yes, not everybody is on a metered connection or running a mission-critical system, but some are, and it is hardly unreasonable to accommodate them.
To be fair, Snappy isn't aimed at "mission critical systems", nor even at bandwidth constrained users. It's a straightforward, reasonably robust and obviously used mechanism for pushing routine consumer software. In that realm, the aggregate benefit to society of having everyone running current software outweighs the annoyance of the specialists, sorry. It's always been this way. If you are running "mission critical"…
They have prioritized snaps but how have they made life easier for those of us running "mission critical" software?
The last time I installed the Ubuntu, I noticed gnome calculator took over a second to start in a VM on a new >$2500 laptop. I switched to a .deb, and it was instantaneous. Then I switched back to devuan and have been happy since.
Yeah, it's almost as bad as the calculator in Window 10. It's completely ridiculous for ANY calculator app to take that long to load on a modern PC.
> Auto-updating of snaps can only be deferred at best, until at some point, like Windows, it auto-updates anyway. Even on metered connections, snaps auto-update anyway after some time. This attitude is obnoxious. Yes, not everybody is on a metered connection or running a mission-critical system, but some are, and it is hardly unreasonable to accommodate them.
It’s beyond obnoxious. It’s your computer and there’s no way to disable it from mutating without file system hacks?
Earlier quoted context omitted.
This is a hard problem. And Microsoft didn't have a choice. Given an option regular users will never update their computers, perhaps partly due to fear of what they don't understand, fear of change, or maybe due to past bad update experiences. I witness this in my mom with technology all the time. Every time there's a popup she mini-panics, and she has trained herself to click close every time she sees something she…
Are linux users regular users?
Earlier quoted context omitted.
The bottom line is they optimize installation time by amortizing it out over the runtime life of the package, or in other words, optimizing a one time 15 second process to be a 14 second process, in return for making a many-times 1 second process a 30 second process. It makes absolutely no sense. They do this using a filesystem originally designed for embedded devices, using a driver hacked to disable threading suppo…
It’s a bad implementation. You can run inline compression on latency sensitive workloads like VDI without issue. Compression makes a lot of sense as the cost for fast high capacity SSD is usually much higher than the extra CPU cycles required to decompress.