Ubuntu 20.04 LTS’ snap obsession has snapped me off of it
jatan.blog
jatan.blog
One thing I will not do is willingly allow somebody else a way to deploy and execute code on my computer without my say so (which snap is).
After reading the whole thread at https://forum.snapcraft.io/t/disabling-automatic-refresh-for... and seeing Gustavo Niemeyer's arrogance (we know better than you when you should be applying updates) I will be voting with my feet and will be installing Pop!_OS instead of Ubuntu, and if snapd is present I will remove it.
The stated goal of Niemeyer, to have users use updated software, would have been fulfilled in my case if I had a way to see what updates would be applied beforehand, instead of the updates being force-installed.
Lengthy dialog with Niemeyer in the forum thread seems to have been a waste of time for all the people who participated trying to convince him to allow disabling of force-installed updates so I suggest you do the same as me and vote with your feet!
It’s the same thing MS did with Windows 10. You buy the product, but have to pay again if you want any semblance of control. Us normal users are now test subjects for the real customers. Look how non-enterprise Office 365 customers are on a monthly cadence for forced updates and the expensive plans get SAC or better.
I'm not sure whether you're being ironic, but they're doing just that.
You can do it in a privaledged container afaik though.
(For server apps, the auto-update mechanism has a really painful consequence, which is that for clustered apps you have a built-in race condition that might kill your cluster)
With regards to updates, it seems that 20.04 continues in the mold of Pop OS 18.04: You get periodic notifications that updates are available, and can go to the Pop Shop to install them. If there are multiple apps receiving updates, you can review and install them piecemeal (although OS/library updates are bundled together as one item in the UI).
The idea of using it for my servers feels weird at first (when I think of Pop OS the UI comes to mind) but after thinking about it, it is a really solid OS and there’s no reason I can think of that it wouldn’t work.
I could remove some packages, like ubuntu-report or unattended-upgrades, but some seemed to be intertwined with other packages in a (purposeful?) labyrinth of nested dependencies.
They made themselves critical and uninstalling would break or cripple other fundamental system components.
Some I disabled in the config files, like apport, motd_news and kerneloops. Some I disabled and masked in systemd and others like snapd and whoopsie/whoopsie-preferences, I had to do:
dpkg -L snapd |
while read f
do
cat /dev/null > "$f"
done
Is it developers from commercial software vendors changing jobs and solving the problems the same way they solved them for other corporate customers? Or is it marketing carefully plotting a release by release path to dominance? Or is it people who truly believe that having a viable market for linux software will be good?
I mean, there might be some truths - people lag with their updates, people don't defend their privacy, and people would like to pay for software but have no avenue to do so.
But accepting those truths and unilaterally forcing "solutions" might find linux is a different sort of animal.
It's not like you're paying them for support.
And it seems like you're modifying the OS in such a way that might break compatibility.
Also commercial software? Linux is commercial software. Red hat and Canonical.
Changing a paradigm usually involves pushing the envelope and breaking some existing assumptions; systemd is everybody's favorite example of that in the Linux world. The root of this issue with snaps is the trade-off between built-in security and user control. Some points to consider:
1. Browsers like FF and Chromium [on Windows] simply self-update, and disabling that requires configuration. So there is at least some precedent for taking the position that user applications should just update themselves. Server apps are more complex and are a strong argument counter to the existing behavior, as is the fact that many apps cannot be refreshed without user impact.
2. Ubuntu, since 16.04 LTS, ships with unattended-upgrades enabled, which means that for debian packages the default behavior is already auto-updating (although automated reboots are not enabled by default, as that would be crazy for the general purpose case). That feels like the correct default, too, given the risk of running code exposed to exploitable, public CVEs — and how reluctant users (like my dad and my wife!) are to click on "Install now" in the update-manager dialog.
3. Debian package updates run as root. Snap updates run in userspace, and confined. So in principle the risk exposure for snap updates is much smaller. And snaps do have an auto-rollback mechanism for failed updates [a]. Counter to that argument is the fact that snaps are meant to be under third-party control, and that there is no clear mechanism to separate security patches vs updates which you get with the debian pocket mechanism (i.e. focal-security vs focal-updates).
The lack of any official [b] means of user control over the snap auto-update mechanism feels wrong to many of us, including me. And while we may seem somewhat opaque in these debates, the feedback we get in threads like this one (and the snapcraft.io one) actually feeds into our decision making. So please do keep pushing on this topic and we'll do our part internally.
[a] See https://kyrofa.com/posts/snap-updates-automatic-rollbacks for a detailed guide on this topic. Of course, if your snap refreshes and you hate the new version, downgrading isn't quite always possible.
[b] There are ways to, hmmm, control auto-updating (i.e. refresh.metered, refresh.hold) if you really want to; that thread has a few. That doesn't help the debate, but I'm sharing in case someone has a technical need for it.
I might want the latest Chrome and Firefox. But I don’t necessarily want the latest update to other applications.
Do these options currently exist?
In general, you can opt of snaps entirely and `apt-get remove snapd`, but you'll miss out on potentially critical components that are only available via snaps.
I understand the argument with browsers, but that does not justify the default on ubuntu-server. LXD being Snap-only really feels like force-feeding Snap.
I don't use, but see the advantages of such packaging. But auto-updating software (FOSS or blob) brings-in it's own barrel of concerns. In the event of something 'critical', a -message- alerting the user ... who can then research and decide ... is far preferable.
As a former Gentoo user, this whole Snap concept is a huge deal-breaker. I wouldn't consider Ubuntu for anything other than some thin-client/smart terminal/kiosk usage, and I'd still be wary of what gets pushed and what sort of potential holes might get opened.
> but you'll miss out on potentially critical components that are only available via snaps
REALLY shitty move.
Until the snap maintainer of Qt decides to upgrade you out of version compliance with your compositor and... Well, hope your kiosk doesn't do anything critical...
sudo apt-get autoremove snapd
sudo apt-mark hold snapd
If it doesn't work sufficiently well when I'm ready to upgrade from 16.04 LTS, then I'm switching to Debian. (I'd intended to be on 18.04 LTS by now, but life doesn't always cooperate and I haven't found time to risk a day or two of squashing upgrade-induced bugs)
What this tells me is that I am not the kind of user you are targeting. I don't either need or want any such trade-off. I'm knowledgeable enough to make my own decisions about security; I don't need a third party to do it for me. So if your distro will end up insisting that I cede any control over what software runs on my machine to a third party, it's a nonstarter as far as I am concerned.
That may or may not change your overall strategy, and I emphasize that it's your decision either way and I would not have a problem if your response is simply: "Well, we are targeting a particular kind of user and that's just the way it is." (I would simply go find another distro to run.) But I think you need to be clear about what kind of users you are targeting and what kinds of control you expect those users to give up to third parties, so users know what they are getting into.
I also think that this idea of having third parties control the security of your computer is against the basic Unix/Linux philosophy, because the whole point of running Linux or some other variety of Unix is to opt out of the walled gardens and third-party controls that other operating systems that I won't name force users to accept. So if you're going that route, IMO you're going to have a tough time explaining to users why they shouldn't just go ahead and run one of those other operating systems instead.
There is a whole other set of users that would prefer that Ubuntu kept out of their way administrative actions for which they trust the machine to handle. They are probably more silent because they are mostly OK with how things work. And I'll say that I'm not comfortable with everything about snaps so it's more of a spectrum than binary acceptance.
Snaps were invented because we had a problem. We wanted to make it easier for software publishers -- think games, desktop tools, browsers -- to deliver their software to Ubuntu users, but debs were both too hard and too powerful to make that a viable proposition. In the old days, people relied on archive.canonical.com [1] from which debs like skype were published, but it was unsustainable and led to poorly packaged and out of date software.
Regarding third parties, in the end, nobody in the community reads through the source code of every patch applied to binaries in their systems. There is a degree of assumed trust in any update. I accept that trusting Canonical is one thing and trusting third party publishers is another, but given the motivation I describe in the previous paragraph, the decision to use snaps wasn't made in a vaccuum.
[1] Which still exists, if you want to go and check out the pool for third-party binaries. All of those installed as root!
Is there somewhere--a blog post on Canonical's website, perhaps--that explains this in more detail? Off the top of my head I'm having a hard time seeing how snaps improve the situation, unless it's simply the "dependency hell" problem.
> nobody in the community reads through the source code of every patch applied to binaries in their systems
That's true, but irrelevant to the concerns of users like me. We aren't saying we insist on controlling when all updates are applied to our systems because we want to ensure that we have time to read the source code. We're just saying we insist on controlling when all updates are applied to our systems, period.
> There is a degree of assumed trust in any update.
Trusting that, for example, a particular update doesn't include malware is one thing. Trusting a third party to control when an update is applied to my system is something quite different. It seems to me that you are trying to conflate the two, which might be fine for some set of users (and, again, if that's simply the only set of users you are targeting, that's your call), but is not fine for me, nor I suspect for other users with similar concerns to mine.
> All of those installed as root!
Doesn't any update get installed as root? I certainly don't want system-level binaries installed to my user account; that would be a huge breach of security since my user would then have write access to them.
You know just as well as I do that if you criticize Snap within the company, you get fired. Especially if Mark overhears you. There is no room for criticism. You either drink the koolaid or you shutup. So, no, sorry, we're going to keep pumping out Snap and those who don't fall inline will just fall out of the company. This is how we've always done these things, despite it failing repeatedly, and Snap is no exception. Actually, Snap is in particular no exception, given how hard it's being pushed by top level management.
[An aside from the main point of this comment: your point 3 is nonsense, and any security guy will tell you the same. For packages that the main sudo-ing user executes, sandboxed or not, there still is effectively no difference between that and root. Snap's sandbox is alpha quality at best, and major platform hurdles remain to make it capable of doing anything remotely useful. Say no to auto-updating snap backdoors. Please. There's a reason why Linux has thrived and benefited with its vetted-by-distros traditional package managers.]
But meanwhile, I'm curious about point 3 as you seem to have facts that I lack -- when a confined snap refresh runs through snapd, is the upgrade payload not executed entirely in userspace within the sandbox? I haven't looked at the code, but my understanding of the model is that the snap can only modify its own writable areas (and do stuff like add a symlink to /snap/bin, though that's also limited). So a snap update could't, for instance, modify arbitrary files, nor read restricted ones. Whereas a dpkg install can do anything as root. Can you help clarify?
First, has anybody actually been fired for criticizing snaps? Your comment seems to imply through hyperbole that we don't debate inside Canonical, but in my experience that simply isn't true. In fact, I've seen a lot more intense IC to CEO debate in Canonical than anywhere else I've worked. It's not always super constructive debate, but I don't know how much better it is in any relatively small organization with the broad impact Canonical has.
Second, debate and reflexion is how these positions get refined. An idea starts out crazy and radical -- "let's make an OS which costs zero and which anybody on the planet can figure out how to use!", or "Launchpad will only support bzr", or yet again "upstart, not systemd" -- but over time it evolves towards a place of greater consensus. So I don't think we're the destination for snaps; in fact, if these blog posts are only coming out now, it signals we are rather early in the journey.
Finally, I can understand creating a throwaway account to disclose something you're not comfortable with at your workplace, but it's not cool -- nor constructive, civil or all sorts of C words -- to create one to and start with "you're simply not telling the truth". C'mon, I'm your coworker.
Separately... "In fact, I've seen a lot more intense IC to CEO debate in Canonical than anywhere else I've worked."
As an outsider, this makes me wonder if the CEO is too involved in day-to-day operations. (And overriding the work of those with more expertise than himself.)
Yes, functionality and workflows around installation and updates are still insufficient for many use cases, but that could have been ironed out given enough time.
But what you messed up badly, IMO, was to force-migrate packages to Snap in an LTS release before it was ready.
Had you waited until Ubuntu 20.10, I'd have been more forgiving. But you (collectively) were so eager to get this in before the window closed for another two years.
If you had made Snap a compelling product, even LTS users might have voluntarily migrated to snaps once they saw how good it was. Now you've kind of pulled off the opposite.
Sadly the ship has sailed: Both in general, since you've pushed so heavily for Snap in a LTS release when it simply wasn't ready yet. And for me personally, where the forced installation of Snaps by some debs (notably Chromium) broke my trust significantly enough that I turned my back on Ubuntu after over a decade.
Not only is the Chromium Snap dog slow, it also can't see my NFS shares. So the snap version is objectively worse, at least for now.
But if I install a deb, I expect to get a deb. You don't want to offer it anymore, fine, take it out of the repo. But sneakily migrating me to a snap, and not even notifying me, is just trust-breaking.
Indeed.
We need to modify the age old saying:
"Computers do what you tell them to do, not what you want them to"
By applying the following patch:
"Computers do what you tell them to do, not what you want them to do - except Ubuntu 20.04 LTS"
At the risk of reigniting this particular flamewar, systemd changed that paradigm for the worse, using flimsy arguments that don't hold much water to anyone who knows better. Comparing snap to systemd doesn't exactly do the former a whole lot of favors.
> Browsers like FF and Chromium [on Windows] simply self-update
If I was okay with this being the norm then I'd still be using Windows.
> Ubuntu, since 16.04 LTS, ships with unattended-upgrades enabled
That's horrifying.
> and how reluctant users (like my dad and my wife!) are to click on "Install now" in the update-manager dialog.
Your dad and your wife are reluctant for good reason. Having experienced first-hand how prone Windows updates are to break things, and now seeing an admission here that y'all want to make Ubuntu more like Windows, this doesn't bode well in the slightest for a good user experience.
Like, one of the main points I make to people to convince them to at least try a Linux distro is "well unlike Windows it won't shove updates down your throat, and the updates are quick and easy and painless anyway". And then here comes Canonical wrecking the former assumption (and who knows how it's impacting the latter, but I don't exactly have high hopes).
Not that it matters much since I've given up on Ubuntu (in favor of openSUSE) in my recommendations to others (and switched to Slackware for my own use) ever since God-Emperor Mark chose to double-down on the Amazon Lens instead of listening to His users. Every once in awhile I take a look at Ubuntu again, hoping that maybe Canonical's figured things out, but always come away disappointed. It's always a bummer, given that my first distro was Ubuntu 7.10, and every once in awhile I'll fire that one up in a VM and remind myself what Ubuntu used to be, before it seemingly became a soulless husk of a distro.
But I digress.
Updates to non-server applications can also have a big user impact and there needs to be a way to avoid/delay them when you know you won't have time to deal with any potential fallout.
OMG. Is this real? This is the exact reason I use Linux instead of Windows 10 or macOS. I am not a grandma who can't stay up to date on tech news. At the least there should be a toggle for power users. But no, you can only defer it. Am I the only one who doesn't like it when your already slow internet slows down even further? It feels like hell when you are working.
I am not upgrading to this. I have been using Arch Linux as my personal OS. Maybe I should look into Debian for my VMs.
And just read this thread[1]. Is this how they treat their users? Even Reddit is better then this.
1. https://discourse.ubuntu.com/t/is-ubuntu-software-going-to-b...
Because if so, I'm sticking with 18.04.
Stability and predictability is their main strenght. Each release is supported for a veeeeery long time.
I mean... As long as you don't use EPEL, stability and predictability are pretty much granted.
I've been using epel on some machine and haven't had that many problems, though.
> Even on metered connections, snaps auto-update anyway after some time.
https://support.microsoft.com/en-us/help/4028458/windows-met...
Except for the ones Microsoft thinks are really important to push to you.
I recently switched back to linux myself, but there are certain utilities and conveniences and options in Windows that linux distros don't yet provide, and ubuntu definitely is not meant to be light weight in any sense of the term. Is switching to something else an option at this point?
An experienced user could probably find a nicely tuned arch / manjaro setup to work better for them than Ubuntu, but if someone is just first getting their toes wet and learning, Ubuntu isn't a bad recommendation for a first go-round.
Can I mark all my network connections as metered?
And I'm pretty sure NM lets you set all network connections metered, i.e.
nmcli connection modify $CONNECTION connection.metered yes
Canonical should be up front about this type of information.
I hope Canonical fixes this immediately. I'm not eager to spend time re-researching to market for a suitable OS.
Another huge differentiator for Ubuntu over Windows was that I didn't think the OS vendor was trying to seize control of my computer. Canonical jeopardized that trust with this choice. I truly hope they take steps to restore it. I don't want the added work of switching OSs.
I tried to disable it from systemd, but it had some weird way of relaunching itself.
just do a web search on disabling snapd to see how many people want to do this.
Backwards compatibility is a positive as long as it's secure. This makes me hesitatant to what is going on. Auto updates good, no blocking not sure.
1. https://www.kevin-custer.com/blog/disabling-snaps-in-ubuntu-...
2. https://news.ycombinator.com/item?id=22972661
*Edited
I left Ubuntu almost ten years ago, after 5 years of using it, when they started using MIR instead of Gnome2 and I replaced it with Linux Mint and I haven't looked back. This whole snap thing looks like the new weird decision made by Canonical to make their faithful users leave :/
On my older 2011-era laptop, that's the wifi and wired network that need those drivers. It's a bit of a pain.
I think it's an over-zealous position from Debian not to redistribute firmware. Even systems that are very strict about licensing, like OpenBSD, redistribute firmware, because they have some common sense.
OTOH I believe it's a position fully aligned with their ethical standpoint. Equating common sense with your personal preference isn't very gracious.
If you want something that's less zealous about respecting (and eschewing) stupid licensing, but is more zealous about randomly upgrading all your software packages unexpectedly, there's always Ubuntu.
What exactly do you achieve by refusing to load it? Are you more free in one case and not the other?
https://wiki.debian.org/Firmware
you could perhaps offer to update that page to remove the ambiguities you believe exist.
For all intents and purposes, firmware is like a key or a password you must supply to the device to make it work. The driver, which is indeed open-source, just says: "here, device, is the firmware you need". That's it. You are not achieving anything useful at all by making people go through some ceremony to download it separately. Maybe they just want to send the signal that people should buy devices where the firmware is already burned into ROM or ASIC or whatever?
Firmware is typically copyrighted, large, obfuscated, and executable on your system.
A password is a string that you can examine and offers no intrinsic threat - either exploit, or legal.
As per the link I provided to you, Debian's policy is that free firmware are shipped in the distribution -- non-free firmware requires you add the 'non-free' and/or 'contrib' parameters to your repository lists.
There is no need to wildly speculate about the motivations of the Debian team -- eg 'send a signal people should buy certain devices' -- when their motivation is explicitly stated.
The DFSG dictates non-free software will not part of the standard distribution. But they've made it easy to pull those files in (as above) via a one word addition to one line of your sources.list file.
Not really. Debian also offers one with all the firmware included but explicitly labels it "unofficial" (though very much official in practice and hosted on debian servers). The "pain" is thus literally to click on another download link.
It is true that the first-presented installer ISO images on Debian's downloads page lack the worst proprietary drivers, but another couple of clicks takes you to images with them included. So, worst case, you find that the image you have lacks such a needed driver, and you use another image. In practice, I just start with the latter, and have not encountered hardware not covered. For the absolute newest equipment, a "testing" installer may be the right version to use.
The Debian download pages provide installer images for all needs. I have not needed to look at secondary sites, which also exist for specialized needs.
Debian's problem is that it's stodgy updating policy means 'Stable' is still on 4.19, things like Wireguard require a simple, but odd procedure to request apt pull packages from newer releases, and most of the copy/pasteable examples out there assume Ubuntu, and their versions/customization to critical infrastructure packages.
IMHO, the stodgy updates make it a perfect candidate for server based software. Personally, my Debian know-how makes it great for my desktop, and It has not failed for my use case: Development, Sysadmin, Browsers, Steam (or any other games releasing linux versions)
That's not a good idea, as it breaks the assurance that Debian Stable provides. Using the backports repository is the recommended approach if you need a newer version of some clearly-defined piece of software. It will pull the newer dependencies it requires from backports, while still relying on stock-provided packages as far as practicable.
I tried it. Long story short, now I'm on Sid.
Time to check out Debian!
*Edited. I can't type on phones.
Pop! is Ubuntu-based, so no idea of the situation with all these other problems, but it intrigues me because they're doing tiling windows first-class.
My understanding of Void is that it doesn't use snaps or systemd, making the system as a whole significantly easier to understand, and simply sounds much much closer to what I want out of a computer (and much like 8.04 was when I first switched to Ubuntu).
Watching this snap thing play out, and in the past, watching Mir, Unity, and Amazon Lens, has provided steady confirmation that I've made the right decision to stay away from Ubuntu.
> GNOME Calculator was put on the ISO as a snap to help us test the whole “seeding snaps” process, not because it was a fast-moving, CVE-prone applications. Chromium, Firefox and LibreOffice fall more into that category.
Ok so the whole snap thing comes down to updating browsers. Is this for real? I want the web, not the browser to change daily, or to consume more bandwidth than my www usage :)
The problem is that there is no way to have a browser that only pushes updates for security fixes. They're always mixed in with changes to the UI that force people to re-learn workflows.
> If you don't want new features ("more free stuff!"), use an LTS version that only includes the security updates?
There is no such thing. I run Ubuntu 16.04 LTS on all my computers at home and I'm posting this on, IIRC, the fifth or sixth new version of Firefox I've had to accept (and that's only counting major version changes), because, as noted above, there was no way to just get the security updates and leave out the others.
Yes there is, it's called firefox esr.
At least when I encountered it a few years ago, if you go to Help -> About Firefox in the menu, it'll check for updates in the background, download the most recent version, and upgrade itself the next time you restarted the browser.
And yes, this was on Ubuntu.
So the capability is there, even if it's not on generally.
If this is of concern to you, why are you using snaps? And why Ubuntu? What's the value-add over Debian?
The idea that you "misjudged who actually uses Linux" was based on the assumption that you think a product should generally cater to its users. If instead you think most of the users should leave, then okay, that's a valid opinion, it's just surprising.
People will never buy linux but they might buy computers with linux at some point just like they have bought phones with it. Android had things that iphone didn't have and at a much cheaper price point thus linux based phones are everywhere. I wish steam boxes had taken off.
That said, I don't think Newbie friendly and power user friendly must be at odds with each other. If you can figure out what the sensible defaults are, and provide simple toggles to customize things, you can cater to newbies, average users, and power users alike.
Not sure about win10, but macOS won't autoupdate apps if you turned it off.
If the app is not from an app store - it's up to the devs to have option to (auto) update. Most apps allow you to turn autoupdate off (in fact I can't think of single one without this option)
> I've used both Windows and OSX for my professional work and while Windows is the worst offender when it comes to automatic updates, OSX is pretty horrible as well. At least with Windows you can expect some sort of backwards compatibility, while on OSX, one day you have to upgrade your entire OS, otherwise Notes or some stupid application won't launch.
- capableweb
I used to run OS X some time ago. When even Windows supported turning off auto updates. These days I am seeing Github issues saying that they can't use brew, clang etc because there is a update. And most of the time the updates are just huge (even compared to Windows).
Is this not true? Can you put off OS updates for some time (a few hours is enough for me) and keep using XCode, brew etc?
I stayed on Mojave for months after Catalina was released and I had a MAS app that broke compatibility with the same companies own (abandoned) self-hosted server software so I just didn’t update it. I’ve since resorted to running that single app (and the abandoned server app) in a High Sierra VM.
The only version issues I know of that sound like what that other person referenced is:
If you update eg iOS to a new major version, sometimes iCloud-linked apps will say they need to upgrade something for new functionality (Notes specifically did this at least once in the last couple of years and iCloud Drive did it a few years ago).
But that is (a) not forced and (b) you’re told exactly what will happen (ie that older macs/iPhones won’t be able to use iCloud until they update too).
Some third party apps will set minimum required OS version (ie to use a new framework or api) but that doesn’t sound like what the other post was talking about?
Every MacOS app from Google auto-updates. You can turn it off iff you have hacker skills. The average user can't do it.
I'm currently on Debian with KDE, but I think I might need to move to a rolling release distro due to some issues with SMB/CIFS (that have already been fixed in newest builds of KDE) that probably won't be fixed in Debian until the next release.
Maybe I should start looking at distros in general-- but Ubuntu is definitely out of the picture.
Yes, but more importantly it's insecure. The ease of typo-squatting is a real problem.
Not that I don't see your point: a curated list like the repositories is preferable to a system where anyone can claim any name, but I am not sure that this extrapolates to the statement that "it's insecure" as a whole.
Out of interest (I don't use Ubuntu/snaps myself), is that really the case? Can I actually a publish <insert popular package> without any checks and, once I got half a million users by repackaging the deb file in snap, add some subtle malware? There is no review process or anything?
This is already possible with every other distribution method. If you host your own debs, then you can easily get them to do whatever you want. Even relying on the main archive isn't great - apt is typically delivered over HTTP to make mirroring easier, for example.
This is a large misunderstanding of how it works. You can't MITM millions of servers around the world just because they use HTTP for downloading their apt archives.
It verifies the cryptographic signatures. That's why you need to "apt-key add" when you add a custom repository. It doesn't rely on the transport method for integrity.
> [Typo-squatting] is already possible with every other distribution method.
No, the counterpoint we're talking about is apt. In apt, not anyone can just register any package name. My question was whether that's really a thing in snap.
> If you host your own debs, then you can easily get them to do whatever you want.
I'm not quite sure what you're trying to say here. Why would I host my own deb files (in the first place, but even if I did) only to hack myself? I could just install the modified deb files directly or modify the files on-disk, no hosting needed?
Actually, a bug allowing exactly that was in the last 3 ubuntu LTS versions: https://justi.cz/security/2019/01/22/apt-rce.html https://usn.ubuntu.com/3863-1/
If they used HTTPS then an attacker would have to control the mirror instead of being able to perform the attack as a MITM.
Also using HTTP allows someone in the middle to know what software is installed on a server, which while not critical if it is kept up to date it leaks some information.
For the 'which software is installed' argument (confidentiality in addition to integrity), I agreed but your first link actually argues this:
> the privacy gains [of using https] are minimal, because the sizes of packages are well-known
Yes they can. Yes distributions maintain archives and are able to decide what to include. But there's nothing special about apt per se that prevents namesquatting.
If you create a well-used PPA, for example, you could easily add extra packages, e.g. "firefix", later on. The next time someone runs `apt update`, they'll be exposed to the new package.
> My question was whether that's really a thing in snap.
It looks like that from the outside, but in practice that's not possible. All snap package names are tightly managed by Canonical staff.
> I'm not quite sure what you're trying to say here.
Lots of software vendors host their own archives. It's very difficult to get new packages into distros, and they're often updated infrequently once they're there. For example, the OSGeo project distributes its suite of packages this way.
Sweet strawman argument dude. "That's bad, but this other unrelated thing is also bad, so the first thing can't be THAT bad in comparison". For real though, this is like a picture perfect example. I may put it on the Wikipedia page.
I find it strange that we trust as much as we do on our computers. Would you let 1000 people walk through your house unsupervised and unannounced? Would you expect everything to be ok after? Yet so many apps are created either directly or more likely indirectly via its dependencies by 1000s of people. Each one of those people has to be trusted. That's insane IMO. And as we get more and more connected the incentives to do evil rise.
From say 1993 to 2010 I mostly didn't care that Windows wasn't sandboxed. Now every app I download is trying to spy on everything I do either for marketing directly or for analytics which is then shared with "business partners" who then share it with others.
I wouldn't have to worry as much a random library is going to do something bad if it wasn't possible for it to do something bad
By the time you are deciding whether to update candy crush or whatever application, you can't actually check all of it's dependencies. You can postpone updates, or only update manually, but what difference does it make?
If testing of updates is important then shouldn't you be running something's that's imaged or managed by something like ansible?
The author of this article claims it's too difficult to find Flatpak apps and that the Ubuntu software center prioritizes Snaps over .deb. Are platforms never allowed to migrate to a new standard? Why is it Canonical's fault that authors of individual applications have yet to migrate Snaps?
If we all agree that on the whole auto-updating software is generally better and more secure than manually updated software, why not single out the applications that haven't migrated instead of blaming the whole standard?
Maybe I'm just naive and not doing advanced super user stuff these Snap haters are doing but from a distance to me this resembles the systemd vs init controversy. One which, IMHO, Linux super users seemed unusually attached to an older standard for not always clear reasons. Snaps offer real benefits: maybe instead of complaining that 'this sucks' users could offer constructive criticism about how to improve the new standard.
Just my opinion tho.
I don't know who all remembers having to develop websites compatible with outdated versions of Internet Explorer but I do and still have nightmares about it.
Is it really "doing whatever it wants" or just updating itself? Doing whatever it wants seems like a much broader range of activities.
Crashing or freezing is a problem, but isn't all software susceptible to those bugs? What if Chrome was crashing or freezing on other people's computers and the latest update fixed it for them?
The problem with your preferred methodology of opting in to updates is that 90% of users won't do it, which leads to security and compatibility nightmares.
I get that an update can cause problems. But to say that all auto-updating is terrible and it just breaks things and software is doing "whatever it wants" in the background seems like an exaggeration and misses the larger benefits.
[0]: https://paul.kinlan.me/correct-image-orientation-for-images-...
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 software users vs an occasional image orientation bug, I'll choose the former, personally.
This is a disingenuous characterization of my argument. The image orientation bug was a simple example. Further, why can't there be some kind of compromise where security updates are automatically applied and feature updates are not (of course I understand that the line can get blurry)?
Lastly, in a philosophical sense, I don't want to cede control of my machine to a third party. Automatically updating apps removes the chance for me to consent to changes and puts me at the mercy of a third party. It removes my ability to make an informed choice.
And yes, you can't cordon off security updates from everything else. They accidentally break other things. But this is a general problem of software development.
If you're using a third-party's software, aren't you already consenting to their "control"? How much control do you have over someone else's software?
For open source you can read the source and decide to install or change. You can limit permissions by assigning to different user groups. You can disallow firewall access. You can choose to use selinux and have additional restrictions.
Automatically updating anything introduces risk.
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.
https://www.forbes.com/sites/kateoflahertyuk/2019/09/26/goog...
Microsoft itself ended up developing a somewhat more nuanced understanding of autoupdates than the current Canonical standard - business clients have various ways to override autoupdates. Surely Canonical can improve upon this standard, rather than learn the hard way the same lessons.
Of course I can - and do - use the deb version, but it's just one of the critical-always-on things that can creep onto a system as a Snap. For example, LXD is moving with Snap as the default way to distribute on Ubuntu[2].
[1]: https://forum.snapcraft.io/t/disabling-automatic-refresh-for...
[2]: https://discuss.linuxcontainers.org/t/is-the-snap-the-recomm...
If we agree that auto-updates on the whole improve security for the platform, why is that not a goal worth pursuing? Why are application devs totally blameless in releasing buggy software?
In an ideal world, you could get away with pushing all updates automatically, but I for one would rather not get my production server get totalled because of a botched update.
*edit to fix question mark
Microsoft are a vast organisation and do a huge amount of testing before pushing updates, yet time after time, there are reports of serious issues with updates.
As a software developer myself, I completely understand the desire to have consumers running the latest version - but I also recognise that real world users have different workloads, different levels of acceptable risk, and different consequences when things go wrong.
I think automatic updates probably are the best thing for most desktop users, and for some server users but certainly not for everyone all of the time - I don't even mind if auto update is the default, but make it clear and give people a config option where they can control updates themselves!
I prefer my own package manager (pacman) over snaps for the following reasons:
1) I like to upgrade on my own schedule. I use my computer for work, and I cannot have things break in the middle of the day or in the morning, just as I get started with work. I usually save upgrades for when I less things to do, so that in case stuff breaks, I can spend time fixing it. This has happened twice during the last 2 years, or something like that. One time Firefox got broken (or rather, the version upgrade broke an extension I use) and second time some API in neovim changes to a couple of plugins broke. If this breakage would just happen by itself, it would break the two most common tools I use on a day-to-day basis.
I've used both Windows and OSX for my professional work and while Windows is the worst offender when it comes to automatic updates, OSX is pretty horrible as well. At least with Windows you can expect some sort of backwards compatibility, while on OSX, one day you have to upgrade your entire OS, otherwise Notes or some stupid application won't launch. On the other hand, Windows eventually forces you to upgrade no matter if you like it or not. So both of them suck equally, but in different ways.
2) snap seems to create mountpoints for the applications and never removes them. When trying snap apps I always end up with bunch of pollution in my environment. Could be that I'm using snap/snapd wrong, but left a sour taste in my mouth, as I saw snap as something that wants to solve a problem that existed for a long time. Instead, they look a bit amateurish because of this.
Or that new updates sometimes break things and that's a hassle. Of course they do and it is.
The problem is if you want to distribute an important security update, what do you do? Ask everyone nicely to upgrade? How? Again, what % of users will manually update their software? Not a lot.
For #2, that seems like a resolvable problem that can be brought to Canonical. I'd prefer to see auto-updates fine-tuned rather than have super users immediately dismiss the idea in general.
It's just my opinion but I think the greater good of the Linux community is served by auto updates, even if occasionally it means an update to an individual application has a bug here or there.
Maybe this doesn't apply to you but I wonder how much of the Linux community just doesn't like change. Sometimes Canonical stuff does crazy stuff (Mir?) but auto-updates seem like a noble principle worth attempting to adopt.
The thing is, I do not give a rats ass what the maintainer of the software wants.
I’m sure they’d like their software to be patched quickly on all the PC’s that use it, and more power to them. But I do not want their decision to patch something to affect my system unless I explicitly tell it to, period.
If I do want my software to update automatically, I’ll enable that. Just don’t force it onto me.
Even I recognize that this doesn’t make sense in the Linux world, though. Ubuntu is trying to be something it’s not—they’re trying to appeal to a new demographic, and, in doing so, driving away their existing users.
Even with my stance on auto-updating, snaps are a problem for me because I mostly use Linux in the context of servers. Like it or not, that’s where Linux has the largest market share; Android aside, Linux’s consumer market share is negligible.
In that context, snaps have problems:
- I can’t have my servers updating on their own. Security updates rarely break things, but most other updates need testing.
- I use auto-scaling. That means servers need to come up quickly when load increases. If a bunch of new servers come online and all decide to update, that’s worse than no servers coming online.
- I don’t want or need a sandbox. In a cloud environment, the server is the sandbox.
- Environments and server states need to be reproducible for testing and auditing. If I’m doing a post-mortem, I need the software on the relevant image to be in the exact same state as when the problem occurred.
- Performance is critical. I’m already paying AWS for sandboxing in the form of many small EC2 instances; I don’t need the additional overhead of snaps. I’m not working with bare metal.
All of these issues could be resolved, and I wouldn’t object to this experiment running in a non-LTS or desktop-only release. But it is truly an experiment: snaps aren’t ready for prime time. My options are to pay Canonical for extended support for old software, wait it out and hope the issues are sorted before I stop receiving security updates, or switch to something like Alpine or Debian.
Keep in mind, this is coming from someone who loves automatic updates, generally prefers systemd, rather liked Unity, and didn’t see what all the fuss was with Upstart and Mir:
- systemd works pretty damn well and is a big improvement, although it has its hiccups
- Unity was fine. It looked nice out-of-the-box and wasn’t a resource hog.
- Upstart usually worked well enough, though it sometimes had reliability issues.
- Mir never really saw the light of day, so it didn’t matter.
Snaps are where I draw the line. They might be the future, but they’re not ready for the present. And that’s not for lack of trying on my part—I had no trouble embracing Upstart and later systemd.
Edit: Apparently you can set a preferred schedule for the updates (from another comment)? That's still one more thing I need to think about, that I shouldn't have to. Just make it optional and everyone is happy.
What the application author wants isn't all that matters. It's the user's system, so they install what they want when they want to.
Ensuring that the user can easily install important updates while preserving the overall order of the system is the job of the disto maintainers for the distro the user has chosen. This is the whole point of distros. The alternative, where each individual application author has free rein to jam their app into the system without coordination, gets you the kind of mess Windows has.
It is "fine" to make auto updates the default. It is "not fine" to make it the only option.
Have some respect for your userbase. Who was the bonehead that make this call -- so stupid.
I have this vague feeling snap is here to stay but I don't like it.
"Greater good"? You sound like an ambassador for Red Star OS[1]. :)
You can arrange snapd to update on your preferred schedule. What you cannot do is defer updates forever.
At the same time, it's also perfectly valid to instead, express what you want and don't want, and generally try to fix something that has broken or correct the aim of something that has veered off course.
Approving of the new change is also valid for that matter.
The only invalid thing is telling whichever camp you're not in that they can leave if they don't like it.
Remember, this is a change, not just the way something has always been.
How about, if you like the idea of everything packaged in the form of snaps, and all those snaps updating themselves outside of your control, you can just go find, or create, some new distro that works that way, instead of changing one that already exists and forcing all it's existing users to either accept the change or move, to accomodate a change you like?
"Take it or leave it" are not the only options, and it says something unflattering about anyone who tries to suggest that they are.
Says who? AFAIK the person who paid my hardware (me) is who is in command.
Updating everything has always been one click in Ubuntu (and I'm sure there's an option to have it go automatically).
> The author of this article claims it's too difficult to find Flatpak apps and that the Ubuntu software center prioritizes Snaps over .deb. Are platforms never allowed to migrate to a new standard? Why is it Canonical's fault that authors of individual applications have yet to migrate Snaps?
Churn is bad, and having to migrate your application is burdensome. Maybe the benefits justify it, but what are those benefits supposed to be?
> Maybe I'm just naive and not doing advanced super user stuff these Snap haters are doing but from a distance to me this resembles the systemd vs init controversy. One which, IMHO, Linux super users seemed unusually attached to an older standard for not always clear reasons. Snaps offer real benefits: maybe instead of complaining that 'this sucks' users could offer constructive criticism about how to improve the new standard.
I hate systemd because it breaks a bunch of stuff but I'm still forced to use it. So far that's been my experiences of snap as well (specifically it breaks Japanese input for some applications).
What are those "real benefits"? You've only talked about auto-update, which was already working fine thank you very much. Snap, like systemd, seems to be more a case of https://www.jwz.org/doc/cadt.html than something that actually makes my system better.
(I don’t know if you’ve tried MX Linux BTW; Debian derivative without systemd by default)
I will never defend pulseaudio though, that’s a horrible mess.
> ExecStart=/bin/sh -c "/usr/bin/foo > /var/foo/bar 2>&1"
As for networking, it's not like you have to buy in to systemd-networkd, systemd-resolved et al - or am I missing something?
What I've definitely had issues with is the way networking services are configured in recent releases of Debian, but that's mostly from several of the network subsystems being in different degrees of weird limbo with "the new way" and "the old" interfering with each other. For example how resolv.conf is managed. And the whole back-and-forth with network names. Come to think of it, it's a bit reminiscent of snap/deb in Ubuntu 20.04 ;)
I know that there is a separate command that can be used to tell systemd to allow a program to live. I know that there are systemd libraries that an executable can link against in order to opt out of the new behavior. These do not matter, because they shows that systemd is willing to break existing programs, and to break specified conventions. Systemd developers cannot be trusted to provide a foundation to build upon.
I know that this default setting can be overridden at the distribution level, or at the system level. This doesn't matter, because it shows that systemd developers do not know how to choose appropriate defaults, and that any changes that are made in systemd need to be continually monitored for stupidity.
Maybe this is just me being soured by a very poor first impression of systemd, but I haven't seen anything since to dissuade me from this impression.
Is that still the default? That’s horrific.
At this point, my standard .bashrc includes a check of whether systemd is running, and whether this absurd setting is set, so at least I will get some warning, and can either fix it or complain to the sysadmin.
And what percentage of users do that? From your experience in software in general how much of the general population manually updates their software? It's almost always a low number and that creates problems. A different set of problems than new updates that cause bugs, but IMHO worse ones.
> Maybe the benefits justify it, but what are those benefits supposed to be?
Security, compatibility, uniformity. Not having to support 18 different versions.
> I hate systemd because it breaks a bunch of stuff but I'm still forced to use it.
Exactly what stuff does it break? And are those things more important than the benefits of systemd?
Do applications break after auto-updates? of course they do and that is something that is important to ubuntu users because they have to manually fix. Given the choice I would rather choose when to upgrade so I could set aside time for fixes.
Ubuntu users are not windows 10 users. Why treat them in the same way?
It's great that you are diligent about updating your software regularly. But how many people do? If you agree that it's a low percentage, then why is not better for the ecosystem as a whole to improve security and compatibility?
How often Ubuntu users who turn auto-update off manually update themselves is an actual thing that can be researched. It's disappointing how many developers just think you should assume the worst based on your imagination and ego, then justify taking away control from users whenever one can get away with it as a safety measure.
Many more examples.
Everyone certainly don’t agree on that. It really depends on the situation. And if that’s what you want, you had that already with unattended-upgrades. I really prefer to manage what updates, how, when, and under what conditions myself.
What’s next, forced unscheduled reboots a la Windows 10?
I get that some people prefer a less secure ecosystem and never want to update their software. But it seems like the greater community is better served by auto updates.
The solution to that would be to fix unattended-upgrades and ship it as working by default, with an easy-to-use script to remove it. I bet that would have been orders of magnitude easier than developing snap.
But that would have kept the onus of packaging, testing, and delivering updates on Ubuntu. Instead, with snaps, they can offload all that to upstream developers. That is really the endgame here. Snap is a play for developers, not for users.
Ubuntu are saying to developers "if you build a snap, you don't have to worry ever again about distro differences! And you can update anything you need, at will!" and in exchange Ubuntu get to reduce their support costs. Win-win, right? And it is... except for power-users, who will get autoupdates shoved down their throats and their mount tables polluted up the wazoo. But nobody in Ubuntu ever cared about power-users on the desktop, really, so no news there.
I've always said that if your updates are such a benefit, then surely users would almost never even need to turn them off without a good reason, so why not give them the option? Most of the time this happens, it is because a company is doing it to maintain their platform, at the expense of their users.
Don't say it is just for safety. Why is it easier to install an outdated kernel than an outdated web browser?
Operating systems and toolchains are FRAGILE. If I have a computer doing anything important, I have to be vigilant about keeping rolling images of it. Updates break things all the time, if you are doing more than just the basics.
I travel a lot. Sometimes I have to reschedule a flight from a 2G cellular connection and can't share that bandwidth with updates. I have computers that run proprietary CNC machines, use specialized musical hardware, or need to have ancient toolchains to build highly specialized software (like J2ME and other embedded toolchains) for internal use for some of my clients. This self serving evergreen mentality is filled with contradictions. Like that I can't use an insecure version of SSL to fix a SCADA device on a secured closed network because they would be insecure, but nobody has a problem with me using telnet or HTTP, without any warnings whatsoever.
It's my computer, I don't have to justify why I want to say no to updates! We should not even be having this conversation about why it is not ok for Google or Microsoft to make permanent changes to my data when I have said no.
Yes, I probably should make more backups, and I have had to become way more careful about that. But the response to a lot of botched updates is just to blame users for trusting them and not making backups. I shouldn't have to worry about data loss or loss of functionality from updates -- it used to be unheard of for updates to not to have built in rollback functionality.
And don't get me started on Google. They are the worst offender. And what bothers me even more, is that they lie about why they are doing it. They've treated their users as unwilling beta testers for years. They installed a persistent menu bar widget without my consent on my mac, which you could either hide, or disable using obscure undiscovered flags.[1]
It is only because I got fed up and made Chrome.app immutable and completely removed and locked their Keystone updater, that my Mac wasn't rendered unbootable by Google's recent involuntary update.[2]
This should tell you everything you need to know. They have such hubris that not just are they modifying their users's computers, but they are making it nearly impossible for the average users to say no.
If companies were truly being honest and stood behind their updates, then there would be a clearly labeled and discoverable checkbox to disable updates, like what OSX has. I'm fine with putting that checkbox behind a bunch of scary warnings, and having the OS check back to make sure you really want to keep updates disabled. But what Google and Microsoft are doing with updates is blatantly dishonest and immoral.
[1]: https://www.reddit.com/r/osx/comments/26eorb/chrome_notifica...
I think its interesting that they are pushing snaps so hard on this LTS release though. I always thought of the LTS versions as getting stuck with older versions and being very strict about updates not breaking things. I guess perhaps with the snap-sandboxing this should work smoother? Personally, as long as my system works I don't care. If the software gets updated, that's fine with me.
I installed VSCode from the .deb package on the VSCode website and it automatically added the update repository so that it auto updates via apt.
"Installing the .deb package will automatically install the apt repository and signing key to enable auto-updating using the system's package manager" See https://code.visualstudio.com/docs/setup/linux
Discord doesn't, though.
FWIW Snap isn't a requirement to do that. You can set Ubuntu to update .deb packaged software automatically.
Basically a snap package is a container, that means an image of an operating system just to run one software. Just this idea should be considerered stupid, is like saying every software is distributed in a Docker container. It's a great way to waste disk space, and also RAM since shared library are no longer really shared...
You can have software that update automatically also with debs, where is the problem? Unattended upgrades exists since decades, you install it, and it updates all your packages automatically.
You can even have proprietary software packaged in .deb packages, why not, if for Canonical that is a concern. You can even have software that runs in a container packaged as a .deb package, why not?
Snap has no real purpose to me.
Flatpack is something that makes more sense, since it aims at providing a way to package software for multiple distributions, doesn't really need a runtime, a daemon like snap, but it builds application bundles that you double click and run, without installing them.
Secondly, snap works on pretty much all major distributions just like flatpak (for a list go here https://snapcraft.io/docs/installing-snapd).
One big advantage that snap has over flatpak is the "--classic" option to allow non-sandboxed applications given that some applications are hard to ship completely sandboxed without getting into some serious usability issues.
This is not true. Snaps are just squashfs images, there's nothing fancy there. No deduplication or anything. You're thinking of Flatpaks with OSTree, which does do this.
I've only glanced at the docs but Flatpack looks very complicated with lots of infrastructure and things that can go wrong; use Git to extract the app into a local repository with hard links to resources? It sound like typical linux centralized overcomplication.
Snaps may be slow, there may be a lot of machinations going on to make it happen, but at the end of the day it's just a file. You have the file, your program runs. That's a big advantage.
The biggest concern I have with Snap is that it’s hardcoded to a store controlled by Canonical. The store itself is closed source. Snaps can be side loaded, but doing so is a huge pain. Snap also requires you sign a CLA with Canonical, allowing them to relicense the ecosystem however they see fit.
As long as they depend on exactly the same versions, right? This seems unlikely to happen by chance, without someone there to actively coordinate the versions, so there will still be substantial duplication.
We have long since arrived at a point where its much more sensible to sandbox every application, with a majority of it's dependencies - less things break, less compatability problens, easier updates, greater reliability. All major operating systems have done this now, Windows, Mac, etc. There is no turning back now.
Is it browser-/Electron-based apps that need constant updates? Then the developers really should consider their choices; why would I download a webapp along with a whole browser runtime repeatedly rather than simply run the app from their website, especially when the target environment is also sandboxed like a browser? That simply doesn't make sense. At a certain point, after over 25 years of attempting to shoehorn the web into an app delivery platform, things get absurd.
It's true though that shared libs have caused more trouble than worth, and are the root of this mess. But the solution is simply to not use them and just ship statically linked binaries instead rather than put a layer of abstraction over them. Even on DOS/Windows back in the day users were able to download an .EXE.
Snap is more than just an update system. Even if snap's only concern was auto-updating, it would still carry a set of implementation decisions regarding auto-updating and it's irresponsible to rhetorically treat criticism/praise of an implementation as inseparable from the concept in general.
>from a distance to me this resembles the systemd vs init controversy.
Yes, people are again playing fast and loose with the distinction between features, and holistic analysis of systems that implement those features.
But that's exactly what apt does. I last thought about updating Firefox (to use a more fitting example in the context of FOSS) around the same time as I thought about updating GIMP: not that I can remember.
On Linux, Chrome does not autoupdate as it does on Windows or Mac. It installs apt or yum repository and then it is updated together with other packages, when YOU run the update using apt/yum/dnf/whatever frontend you use.
You are correct that this appears to be EXACTLY like the systemd debate.
Snap HOPES to provide an easier environment for developers to target and thus provide a richer ecosystem for users to enjoy. This like trickle down economics probably isn't real. Like literally every other time Canonical decided to go their own way they will provide an inferior option that isn't taken up outside their own ecosystem before eventually giving up and joining the crowd. Unless it attracts highly hypothetical new developers to linux it offers nothing but downsides to users.
- It's tied to a close source server run by and solely controlled by Canonical with no ability to add software channels like virtually every other major software distribution model for Linux. This means not only could Canonical exercise undue control over how their users use software on their platform it means others including repressive governments could force it to on their behalf.
- Users may only install the most recent version of software and will be updated to the most recent as soon as it comes out. -- This means that if devs push a buggy version you are stuck with it until its fixed. If it isn't fixed for months you just can't use the software. Bugs that effect everyone will probably get fixed immediately. Bugs that effect niche features or a smaller number of users are liable to go unfixed for longer. Please see bugs that are open for years at a time.
-- In case of developer getting compromised ability to push updates to all users as soon as users machine is online means that a substantial portion of user base can be hit within minutes and almost all within hours. If a new version had to get pulled in and then distributed at irregular intervals a new version would take at least weeks to compromise most users. This would give users/packagers/distros/developers time to realize what is going on before all users are effected.
- For some reason they are slow to start
- Waste users bandwidth and storage even with one or the other is dear.
- Results in 17 different apps having 17 different version of a dep 16 of which have known security vulnerabilities because apps don't use system libraries that get updates.
Canonical could barely get its own users to prefer snaps over the alternatives, which is why they are forcing it onto them.
Do you think it will be pushed to the background with time or will Canonical manage to push it through?
And the fact that they first did it in an LTS release seriously jeopardises the trust is have in canonical. This is a deprecation which may have significant undetermined consequences. This is exactly the kind of change they should have introduced in 19.04 and then used the ensuing year to iron out any issues before 20.04 LTS.
What this tells me, however, is that for Canonical their business interests are placed above ensuring the stability of the LTS release, and that’s extremely disappointing to say the least.
Every. Fucking. Week. Because it breaks my session every update thanks to the inane switch to snap.
Canonical is the one pushing for snaps, and they own the centralized Snap store. On most other distros snap support is either non-existent or much less than for package manager or even flatpak. Let me turn that question around. Why should individual application developers have to package their apps as snaps, which are mostly just used on ubuntu?
> Maybe I'm just naive and not doing advanced super user stuff these Snap haters are doing
Most of the complaints here have been about the automatic updates (and specifically that you can't disable it, not that they are on by default). But, personally, I am more concerned with the fact that snap apps run slower. Snap uses squashfs for the program and any associated files, and squashfs is not designed to be fast, it's designed to store a file system in a small amount of (usually read-only) space, such as on a Live CD. Besides slower startup times, snaps also take up more space on disk (which may not be a huge issue for most people), and more time to download (a bigger issue) since each snap has to include its own copy of all its dependencies.
The containerization of snaps provides some security benefits, but there are also a couple security concerns with snaps:
- Unlike the official apt repos, the snap store is not curated. It is much easier to put malicious software on the snap store than get in the official apt repos.
- Since all dependencies are bundled with the snap, if there is a vulnerability in a common dependency, such as libc or openssl, then instead of updating a single package on your system to get a fix, you need to update all of the snaps. And you are dependent on the maintainers of all of those snaps to watch for such vulnerabilities and make sure their dependencies are kept up-to-date.
And from developer's point of view, I can attest that if I'm to package and publish something for Linux, I'd certainly use snap or Flatpak or both before using deb or rpm so long as they're not affecting me in some major negative way. I assure the reader this is not the minority opinion and the software catalog is only going to grow because of it. This is our way out of PPAs and dependency problems (among other things) for publishing up to date out-of-distro software. I have no problem with a particular set of users not wanting the latest version if they know what they're doing but that doesn't negate the benefits this kind of a system brings.
We've seen this play out with other new and needed Linux systems before and that's OK.
Why does this even need to be stated?
Many competent companies MITM employee traffic to scan for malware, leaking confidential data, etc.
Good thing beckler found this while eating their own dogfood due to their own network being that way. Imagine that everything worked fine in their environment and then so customers came back with this issue. Then they would be beavering away hacking up their own core snap or whatever.
There are different value tradeoffs in different countries. The US says it is okay to spy on employees for no reason at all as long as you use company equipment. The EU says that employees like every other human being have rights and you better have a good reason and do so in a respectful way and be clear about it.
I can understand the reason for this. Now that most suppliers treat their devices as 'black boxes' and call home to install updates whenever they want, the security team no longer has visibility nor control over this. So much stuff runs Linux which we don't manage but still has to have full access to our network.
And public repositories have been compromised and spread malware in the past. So yeah I totally understand this, even though as an enterprise Admin it's a total PITA to manage the root CAs.
No, it's corporate MITM specifically which should be illegal.
I'm not a big fan of these corporate MITM boxes that contain the keys to the TLS traffic of the whole company (which additionally often double as employees' private phones and laptops), but I do like to look at my own device's traffic.
That would be a pretty serious security incident from my POV.
If they really want snaps to succeed, there should be an open source snap store protocol, and 3rd parties should be allowed to run their own stores, just like you can add 3rd part apt repos, for example.
We decided on Photon OS, BTW. It's tiny, and perfect for use as a Docker host.
From the marketing, blogs etc, Ubuntu Core does seem to be targeted at everyone, not just people that would drop $15k/y like it was nothing.
It's almost like a trap - it sounds perfect for IoT, so you start wasting your time building a PoC, and then much later you find out about the costs. And as another commenter mentioned, they also charge you for doing updates on top!
Why is asking for money wrong? You want the feature, why shouldn't you pay for it.
Just to be sure, installing the CA from that MITM box didn't work? Because that should be the generally recommended solution and I can't see why snap would have a hardcoded CA list separate from the system. If that didn't work, it's indeed a bug, but a rather weird one; definitely worth posting to the bug tracker.
That being said, there are a list of paths you can write to, and they're listed here (for core18): https://github.com/snapcore/core18/blob/master/static/etc/sy...
That is ridiculous. Thanks for the info, yet another reason to stay far away from snap...
I’m not blaming Ubuntu, nor Snaps for this issue, but we had a new server come online and our monitoring noticed that two or three partition was already at 100% usage. Those where snap mount point.
alias df='df -x"squashfs" -x"tmpfs"'
https://forum.snapcraft.io/t/snapped-app-not-loading-fonts-o...
Canonical needs to invest in compatibility if it wants Snap to be adopted in distributions other than Ubuntu. Flatpak doesn't have this issue, and unlike Snap, its server implementation is decentralized, free, and open source.
Yes, Flatpak is targeted to desktop applications while Snap has a broader scope, but it's questionable whether Snap's mandatory automatic updates are desirable in a server environment.
Edit: about autoupdates, I agree, the user should always have the choice.
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.
I don't want testing. Stable is fine.
I find each version of Ubuntu worse than the previous. It's change for the sake of change, and as in this case, something really thoughtful like .deb gets replaced with something which appears slapped together poorly.
I just want a stable, working system, and Ubuntu seems to no longer be the way to have that.
You may also want to keep some places like /var/lib/ if you have databases going, etc. I'd just do a complete backup and restore pieces as you find you need them.
The only pain I can come up with is that I'm wasting about 20 GB, because the operating system doesn't actually need 50 GB. So maybe not a great solution for people who have to do with Laptop with a non-replaceable 128 GB SSD. But 20 GB is not a big deal to me.
The upside is that I've done clean Ubuntu reinstalls two or maybe three times since then, and my data was a non-issue, just reassign the existing partitions and don't format /home. I'd estimate it takes rather less than the 30 minutes the paines refers to, and I always grin despite myself when Firefox restores the browser window as if nothing had happened.
Those 15-20 years, it was the same Debian install. Everything else in the computer changed, but Debian kept on ticking.
There was a while Debian was behind on supporting things like laptop power management and graphics cards, when I switched to Ubuntu. For a while, it was a more polished, user-friendly up-to-date Debian. That was nice.
Now that Ubuntu re-invents the wheel each new release (and quite often, replacing a spoked, pneumatic-tired wheel with a square piece of wood), and hardware support is a little more standardized, I think it's time to switch back. It feels more like a tech gizmo, designed for Ubuntu developers, than an end-user OS.
The Debian wiki page on fonts is helpful. The Arch wiki page is better, and most of it still applies:
When was this? I can confirm that it breaks from time to time but usually that means I haven't rebooted for four months and by restarting everything, it all works again. I never needed to dive into the font system at all while using Debian stable or testing in the past 5+ years with Cinnamon as DE. (Firefox, not from the repositories, being the exception where one might need to toggle gfx.canvas.azure.backends in about:config.)
You raise a good point since I notice I don't know the process as well as I thought I did, but it seems odd that the frozen testing repo would only get all security updates all at once months later.
The Debian wiki mentions that delays can be specially large after a new release comes out. I don't know if I was misremembering it or if it can be problematic both before and after a stable release comes out. Hopefully someone with more Debian experience can clear this up.
http://security.debian.org/debian-security/dists/testing-sec...
I don't know if anything actually shows up here, but you no longer get the error for security.debian.org when you try to upgrade via s/stable/testing/ in sources.list.
Given that some trigger happy devs remove support from old versions as soon as they leave support, this can directly affect browsing experience.
Just apt install xfce4
Most of the package names are the same between Ubuntu/Debian. Honestly, using testing just feels like using a "level headed boring adult" spin of Ubuntu. Instructions for installing or compiling XYZ for Ubuntu will typically work without modification on testing.
I run the "unstable" branch, personally -- but I've been using Debian for ~22 years now. It's definitely not for everyone (and not for production!) but a lot of the "power users" here on HN would manage just fine with it.
Just make sure to read the tips linked in the parent and the "Don't Break Debian" [0] page.
---
https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/
IANAL but Canonical's justification for the ZFS kernel module and Linux kernel being totally separate works, and the distribution itself not being a derivative work of GPLv2 seems dubious to me.
https://blog.dustinkirkland.com/2016/02/zfs-licensing-and-li...
Seeing as how the Software Freedom Conservancy believes this to be a GPLv2 violation, and Oracle could launch a lawsuit as a result of it also being a CDDLv1 violation, I think it's safe to say that it's not just ideological purity that factored into Debian's decision not to include ZFS.
[1]: https://packages.debian.org/buster/nfs-common
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621807
Can someone verify this? As someone who will eventually upgrade to 20.04, this is concerning.
From what I understood, only the first start is slow. Once the virtual disk had been decompressed, subsequent launches are much faster.
- https://www.reddit.com/r/Ubuntu/comments/9scoif/snap_package...
Saving disk space is certainly useful for rarely used apps, however, your web browser (and any other frequencely used apps), shouldn't be compressed, especially if there is ample disk space.
Is it really? I can't recall the last time I ran into disk space issues, must have been in the 1990s.
Even on my desktop, I managed to fill 750GB with various VMs and android development tools (the SDKs, etc). While I am not sure how much compression could have saved me, it could still be worth it (especially since I only use certain VMs or SDK version once a month).
Anyways, it makes sense to maintain something like an LRU cache, and compress only the least used things.
The problems arise when you start using xz-compressed squashfs images. LZMA2 is optimized for compression ratio and typically decompresses several times slower than even zlib deflate (which is already ~10 slower than lz4).
Especially since this has been a solved problem for ages without any real performance penalty. NTFS have had this since 1995 it seems and zfs probably since its inception.
They do this using a filesystem originally designed for embedded devices, using a driver hacked to disable threading support because the sheer number of filesystems snapd mounts would otherwise consume a huge amount of memory in per-cpu buffers used for decompression. In other words, they broke squashfs for everyone in the process of trying to make it work for snap.
On-demand decompression like this has made very little sense on desktops since the mid 90s, and even if it did, snapd's manifestation of it is particularly terrible.
Ok, maybe not desktops? But ZFS on-disk compression is a sysadmin's frickin dream -- just one example that you can access logfiles with plaintext tools like grep while benefiting from the space savings with neglible cost, LZ4 has basically no overhead at all, https://www.servethehome.com/the-case-for-using-zfs-compress...
I really hope you will try on-disk compression, encryption, deduplication, and that sort of thing sometime, you will see it is so much better than gzip-compressed, gpg-encrypted files
Compression also typically makes it faster to launch applications from spinning rust, because the bottleneck is the drive and reading 50MB and decompressing it is faster than reading 100MB uncompressed. This would be true of SSDs as well except that most of them already do this internally.
But snap isn't reading e.g. 64kB and then giving you 128kB on demand (and then prefetching the next block) like the filesystem does, it has to read and decompress the entire 100+MB package before you can even open it. That is very silly and adds a perceptible amount of latency.
Wait, I could be wrong about this. I was deducing it from other people saying that it has to decompress the package every time you open it plus the empirically long application load times, but it turns out it's using squashfs which at least in principle could be doing the compression the same way as zfs. I haven't checked whether it does or not.
They're doing something wrong though or it wouldn't be this slow. Possibly more than one thing. Unfortunately there are a lot of different ways to screw this up, like not caching the decompressed data so it has to be decompressed again on every read even if it's already in memory, or using too CPU intensive a compression algorithm or too large a block size, or double (or triple or quadruple) caching because it's loop-mounted and then forcing slow disk reads through inefficient cache utilization, or over-aggressive synchronous prefetching, or any combination of these. Or maybe it actually is doing whole-file-level compression.
Now I'm curious which one(s) it really is.
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.
In my testing with OS installs that depend on squashfs+xz, there is a significant lzma hit for decompression, resulting in significant latencies. And the higher the compression level used, the more the hit when decompressing. While compression computational hit for zstd is in the same ballpark as xz to achieve the same compression ratio, (a) decompression computational cost is far less with zstd, translating into faster reads; (b) is fairly consistent regardless of compression level.
Another factor for squashfs is the block size. The bigger it is, the better the compression ratio, but the greater the read amplification. I haven't looked at it, but it might be they're overoptimized for space reduction with too little consideration for performance. Since this isn't a one time use image, like for an installation, but intended to be read over and over again, erofs might be an alternative worth benchmarking.
https://linuxreviews.org/images/d/d2/EROFS_file_system_OSS20...
That's why the kernel is compressed.
[1]: https://arstechnica.com/gadgets/2009/08/mac-os-x-10-6/3/
1. Increased installation speed. This one's obvious; less data takes less time to install. This is mentioned in your parent comment.
2. "But compression isn't just about saving disk space. It's also a classic example of trading CPU cycles for decreased I/O latency and bandwidth. Over the past few decades, CPU performance has gotten better (and computing resources more plentiful—more on that later) at a much faster rate than disk performance has increased. Modern hard disk seek times and rotational delays are still measured in milliseconds. In one millisecond, a 2 GHz CPU goes through two million cycles. And then, of course, there's still the actual data transfer time to consider. [...] Given the almost comical glut of CPU resources on a modern multi-core Mac under normal use, the total time needed to transfer a compressed payload from the disk and use the CPU to decompress its contents into memory will still usually be far less than the time it'd take to transfer the data in uncompressed form."
It's an interesting point, but seek times and rotational delays don't apply to SSDs. This is kind of an uneasy comparison to draw with "I hate that Chromium’s snap takes more than 10 seconds to load on cold boot on a freaking SSD".
There is another reason to do compression on SSDs: you have more storage free and thus less write amplification and your SSDs will last longer. In fact some SSD controllers (e.g. SandForce controllers used to do this) compress data to reduce write amplification.
https://en.wikipedia.org/wiki/SandForce#Technology
The trick that they applied is that say, if you had a 500GB SSD and you stored 400GB uncompressed which the controller compressed to 200GB, the drive would still report only having 100GB free, giving it an ample 300GB of free blocks, thus greatly reducing write amplification.
(Of course, the benefit of controller-level compression is gone with full-disk encryption. But I guess FDE was less popular when SandForce SSDs became popular.)
The list of dumb decisions that Ubuntu has been making recently just keeps increasing.
Overall, snap doesn't seem terrible to me, but I haven't really read into the complaints everyone is sharing.
It's ridiculous.
Chromium was converted from deb to snap already in 19.10 if not earlier.
2) It somehow consumes insane amount of CPU for me. I have noticed my fans going crazy (mind you I am using a 32GB RAM, 12 core brand new machine) and all my cores being at 60%.
The kicker about that, I did not even see chromium running! I had closed it but the rogue snap processes would not die. I had to sigterm everything and uninstall it.
Then I wanted to install chromium without snap but as the post says - YOU CAN'T! At least not easily enough.
So the solution for me - download Google Chrome after years of using Chromium because you could easily install it natively (I still use Firefox as main browser but sometimes stuff only works in chromium based ones).
It's a total disaster as far as I am concerned. Next time I am reinstalling the OS (hopefully not any time soon since I've just upgraded from 19.10 to 20.04) it will not be ubuntu.
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.
However, Canonical pushes snaps via deb packages (e.g. Chromium).
The best option is the use an Ubuntu-based distro, like PopOS or Linux Mint or Elementary OS.
I wish they would have based it directly on Debian instead of Ubuntu, but I just stay away from Snaps and get on with my life.
As many others I haven't liked vanilla Ubuntu since they swapped Gnome 2 for a (what I think is a) clone of the Mac OS interface, but my desktop still uses the Ubuntu 18.04 base system under the hood so this might come in handy for a number of people like me.
https://people.canonical.com/~ubuntu-security/cve/universe.h...
So, Ubuntu's LTS support is only relevant security-wise if you mostly stick to the main repository.
https://www.debian.org/security/faq#contrib
However most packages in Debian are in main. AFAIK contrib is for FLOSS packages that somehow depend on packages that are not FLOSS.
There's way more evil things about Windows, like click to raise and menu bars.
personally, i think XDG_CONFIG_HOME + a robust config file framework with a standardized format (yaml/toml, whatever) would work as well. being able to specify a schema could be extremely useful, too, to prevent borked configs. as you've said, we've seen a lot of tools/OS's go this direction. and it doesn't have to be perfect, the 80% case would be a huge improvement.
i'm also sure the registry made a lot of sense at the time. it was probably way quicker than reading and parsing files. we didn't care so much about sandboxing/isolation and backing up. people probably had less application installed.
If you are running "mission critical" software, you need to be using a packaging mechanism (c.f. Docker) which lives at a lower level and provides harder guarantees about what you're running. Those solutions exist, they just aren't Snappy.
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)
To me snaps seems like a desktop solution that Ubuntu forgot to disable on the server edition.
Obviously it sits at the boundary, but a "Dockerfile" is (at least when properly used) a recipe for reliably reproducing a specific version of software packaged in a format that can be deployed to all sorts of systems with absolutely minimal dependence on host configuration.
That's what people who want a "mission critical Snap" almost certainly want.
They have prioritized snaps but how have they made life easier for those of us running "mission critical" software?
> obviously used mechanism
OK...
> If you are running "mission critical" software, you need to be using a packaging mechanism (c.f. Docker) which lives at a lower level and provides harder guarantees about what you're running. Those solutions exist, they just aren't Snappy.
What? No it doesn't live at lower level. Docker uses same Linux APIs as Snappy.
The only upside of Docker when compared to Snappy is that it doesn't turn your hardware into zombie execution unit constantly pulling code from mothership (Canonical).
> 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.
There's in fact an easy way to satisfy both groups, but for some weird reason Canonical chose to turn every user into zombie execution unit, no matter the level of proficiency. It's not like a patch to disable this malware behavior would be hard to submit, but it's crystal clear it'd be rejected.
And it's clearly not for causal user benefit. They have documented switches to postpone calls to mothership. That's command line realm for experienced users.
I honestly wonder what their real motivation is. Those who seek to take back the control are people who want to control their own machines. The only thing that comes to mind is that sometime in future blog posts recommending to disable automatic updates would crop up and those dumb pesky users would just copy paste it into console without much thinking.
Ubuntu went totally overboard with their snaps, putting everything in it trying to force it to become a standard. But FlatPak is not great either even though it is an open standard.
It's nice for the 1 or 2 niche apps that aren't available any other way, but for the most part I prefer normal packages.
you can actually get a very stable system in the same way you would any other OS: install only the packages you can live with. you can install, say, xmonad and no DE and have a slick, solid, low resource dev setup, whereas ubuntu comes with some goofy ubuntu software store that's not removable (or wasn't when i last used it) - one wonders what other "goodies" are in there, esp. after amazon search behavior change. remember that deleted code is debugged code: the more spartan, the less chance for issues. so arch's actually a plus there.
FWIW my boomer parents run arch on 2 different desktops solidly, without much sysadmin work from me other than a few pacman upgrades whenever i remember to VPN back in, perhaps biweekly on average. yes the occasional breakage happens, see above re: website/forum/etc.
debian stable was OK as firefox was fairly regularly updated for vulnerabilities, but the actual version number was lagging a fair bit behind. ubuntu LTS just seemed like a worse debian. ubuntu non-LTS is a non-starter: probably 50% of the dist-upgrades i ran ended up failing and basically needing a clean reinstall for anything not in /home, so it's fairly admin hostile in that sense.
Also consider Manjaro if you want an Arch-based distro but don’t want to go through the trouble of manually setting everything up on first install. I’ve been running the KDE edition as my main OS and it’s fantastic!
I always shill for it.
It's like Ubuntu if Ubuntu were rolling (so much faster drivers and DE features, but nerfed delivery to minimize breakage and still really user-friendly, with a GUI kernel and driver switcher) and if instead of PPAs it had a big repo that just had everything on it (the AUR, which Manjaro's GUI package manager, Pamac, works with once the setting's toggled).
On the flip side, this is incredibly empowering. If something breaks, you can just fix it, since you were the one who put it together in the first place. That's a big jump from Ubuntu, where everything just works, but you have less control. Arch is worth it if you think of it as a future investment, rather than a short-term easy fix.
Arch with its rolling release model is prone to breakage. Every upgrade gets you closer to having to reinstall everything from scratch. On contrast, NixOS is transactional and if something breaks you can switch to a previous version easily.
(I actually went from Arch to NixOS, after using Arch for about 3 years).
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 doesn't understand.
Google started the trend of silently updating Chrome and everyone including Microsoft followed after, except upgrading an OS is nothing like updating a browser.
For most parts, I think auto update is necessary for tech illiterates, especially now that everybody's jumping on the Agile bandwagon, including Windows. There needs to be a way to ensure new versions reach their users given everyone's just churning out barely working software these days.
Honestly I don't have a problem with that. But if they don't give power user the option to opt out, this is just disrespectful
The benefit of linux is that it doesn't force stuff on you that you can't disable compared to windows. If you take that away, there are very little reasons for any normal user to move.
Windows Server gets to exist so long as it acts as a funnel into Azure. Someday it will be sold off to Wipro, a la VMS or OS/2.
I'm well aware of how important Windows Server was in the enterprise, and I'm aware of how far it has fallen.
Is this a personal opinion or pure speculation?
For a normal user, the INSTANT something goes wrong in Linux, you step from “something kinda like Windows” to “100% Voodoo you are expected to know”
Think about explaining to grandma over the phone.
It’s just a non-starter for Linux. Which is fine, it’s what it is for a reason. But it’ll never have mass appeal because of it.
I knew that, but only in the back of my head. If the internet wasn’t working, you know, a WiFi problem, I would have a very tough time remembering that. Which is the point, trying to remember the voodoo.
And if I had to ask grandma to type in nmcli d then read me what she sees? Well, if anyone wants to prove me wrong, I’ll set my grandma up on Linux and give her your cell number.
I get that there are a lot of Linux fans here, but be realistic, it’s not for most people and never will be. You need autism or have never worked outside of tech lack the empathy of how mass computer users interact with their machines.
But I want to know what specific things they use that can't work on linux subsystem?
Maybe there are some and I don't know about them.
Also, it‘s way easier to work with multiple desktops and windows position better than on Windows where it seems that they are opening always there where you don‘t look.
There are also quite a lot of others, IMHO.
I don't have anything to say about your other nitpick.
A good reason to use windows is games, Adobe and office. Games using anti-cheat will not be available on linux and if you can get them to work, good luck not getting banned.
And IMHO, the discussion about which OS one should use is probably older than any OS at all. It comes down to personal preferences and experiences. I would not for any longer time want to use only Windows for a couple of reasons. I use it for some office stuff (we have SharePoint and OneDrive for Businsess does not exist for Linux).
I did a quick search and here are two references about the WSL speed:
[1] https://vxlabs.com/2019/12/06/wsl2-io-measurements/ [2] https://github.com/microsoft/WSL/issues/4197
It seems that they already improved a lot bur are still nowhere near native FS speed because of some technical limiations on how to embed the FS.
A more comparable situation is if Ford had requested his supplier send him a certain type of screw but the supplier sent him a completely different type of screw because it was “better”. It may be better. But it may also be absolutely the wrong thing to build Ford cars out of because they weren’t designed to use it.
And that’s what Canonical often seems to forget. Ubuntu isn’t just a product. It’s also infrastructure, and an individual (although critical) part in many other products and systems.
And AFAICT Ubuntu as a product is far less popular, and pays far less of the bill than Ubuntu as infrastructure, which is why their actions are doubly incomprehensible.
I look out my window today and I see many colorful cars. It's better this way. Fuck control freaks.
I believe in mutual respect
This does not reflect the hundreds of regular users that I have serviced over the years. Perhaps fewer than five would postpone updates beyond a few days for convenience / uncertainty, the rest would always install Windows updates within a day or two of being prompted.
Part of the solution should be that Microsoft Windows should refuse to install on any mechanical hard disk or eMMC and on any SSD slower than a certain benchmark. The other option would be to minimize the obnoxious amounts of reading and writing Windows does to disk but that would make sense.
Personally, I don't mind snaps that auto update. Apparently, "modern" snaps are sandboxed but "classic" snaps are not? I think this is the biggest failure of snap. What is a snap? Why couldn't we give legacy snap and real snap two different names? It isn't like there used to be snaps and then we got modern snaps. They both started existing at the same time.
I agree - when one's workflow must be interrupted by either application or OS restart, then the software must work for the user and wait for a convenient time.
After having an update happen at a bad time, one closing a file I hadn't yet saved, and another killing a process of computations I had been leaving to run overnight, I decided that I wanted to use my computer the way I saw fit, not the way someone else saw fit. If someone cannot wrap their head around the idea that I might leave a process running while I sleep, or that I might forget to save something in a program that doesn't have an autosave feature, well, they're not considering all of the use cases.
For giggles, after LTSB I did "all the things" to get rid of forced updates on one particularly infrequently-used tablet and, as an experiment, left it unpatched for slightly over a year before seeing what would happen once I finally let it do its thing. For one, the updates took about three and a half hours, which I thought was interesting; just re-installing would likely be faster.
More interesting, though, was that the world did not end because I had not patched this tablet.
I get aiming at the eighty percent of your users who just would not think to update, but being that hostile to the other twenty percent who are aware of updates and still would like that control is annoying. It is sad to see that this kind of thinking has made its way to Linuxland, which I had imagined to be the last bastion of "we're doing this for your own good."
It's just really hard to get officially for consumers. They should sell it to everyone that wants it.
And yeah, Ubuntu Desktop is kinda the "Windows Home Edition" of Linux though. Something like Arch, Debian or Alpine won't do this to you.
It's annoying having to set up a whole windows domain just to disable this though :(
You make it sound like an irrational fear but there's a real cost/benefit ratio to consider when you upgrade a machine. I personally always try to keep my machines up to date but stuff does break from time to time. Like last week an arch upgrade updated some system library to a new major version which forced me to regenerate my python dev env for work (which is not a trivial task because for various reasons our environment is fairly custom).
Windows is even worse in that regards because its upgrades are often significantly more intrusive (and they use automatic update to push new features and products, which is a great way to have people attempt not to update just to avoid them).
IMO if OS vendors want their users to update at all costs they shouldn't force it onto them, instead they should develop better transactional update systems that effortlessly and reliably let you revert to a previous version if something goes wrong. Then there would effectively be no reason to fear any update, since you know that at any point if something goes wrong you can just click on "undo update" and you're good to go.
95+% of users have no chance of even making this cost-benefit analysis because they cannot assess the scope or risk associated with the upgrade even if they wanted to. They have to rely on vendors making those assessments for them.
That's why I run Debian stable, which provides security updates and critical bugfixes for 5 years or more post-release with very limited changes otherwise. Maximized benefit, minimal cost.
FYI -- use Debian almost exclusively, been doing so for 20+ years and love it. (Well mostly, the last 5-7 years have been rough though.)
What Debian provides, is security updates for 1 year after the next stable release. That's it.
'5 years' is via LTS is volunteer support, provided by corporate and private donations, via a corporation in France. Their goal is to extend Debian oldstable's lifespan. The entire process is absolutely not the same as updates when running Debian stable.
For example, due to its volunteer nature, companies get to decide where they 'put their money'. What packages are prioritized. Rare / unused packages may never be addressed, depending upon funding.
Use PHP? Apache? The Linux Kernel? Sure, you'll see updates! Use rare package $x, and that may not happen, even though Debian Security would handle it.
I can also tell you via experience, that QA is not quite as good as Debian proper.
Still, is it a good thing? Sure! Is it managed by the Debian security team, 100% embracing all of its methods, and so on? NO.
I felt it is important for you (and others) to know this.
It's not as stable as Debian, not managed by Debian, and should ONLY be used as a stop-gap. You want stable?
Stay on Debian managed security updates!
What everybody does however is to use past experiences to evaluate the risks. Who hasn't had a system upgrade break something that took a while to fix? In these conditions, who wants their system to auto-update if the system is critical and it could happen at the worst possible moment?
As I said I try to keep my system up to date, but if I know that I have an important deadline in the near future I'm likely to postpone updates to avoid shooting myself in the foot.
Most Windows updates are security or bug fixes only. The exception being the twice yearly feature updates. These have been an issue mostly because Microsoft had been using a random subset of Home users as beta testers for new updates. However, they are being less aggressive with this now.
Oh, that might explain my experience a bit. I've never had any issues with automatic Windows Updates managing 50+ with a mix of common software. Every one of them was always Pro or Enterprise though.
Ran Arch for a couple years for dev with a nightly cronjob of (iirc) "pacman -Syuw --no-confirm". That broke regularly but I knew it was a bad idea.
The problem is that "power users" can't be trusted to use this power responsibly, or they operate based on assumptions that won't always be true. Either way they end up hurting other people in enough situations that this becomes an ecosystem issue.
Power users often help others set up their systems like they do, but those users can't manage them. Other times, power users will move on. When they were managing the systems, it wasn't a problem. Now that someone else is, the systems stop getting updated and someone has to clear up the mess. Yes, good power users help transition things properly, but don't kid yourself on the number of times this actually happens.
This phenomenon is prevalent in software. Just looks at the defaults which "power users" frequently choose (cf. JWT).
But when those decisions affect others? When your computer becomes part of a botnet and is used to attack a target then it's no longer just your problem anymore. The responsibility to prevent this must lie somewhere, either with the user or with the manufacturer. And Microsoft would rather force the updates on users and occasionally be in the news for a botched one than to constantly be in the news for botnets of hundreds of thousands of "abandoned" Windows PCs, or the constant complaint that Windows is insecure because people keep their PCs stuck on the same version they came with.
To use some very current imagery, imagine if someone walked around coughing in your face saying the decision whether to wear a mask or not is theirs.
Further your argument draws a connection but its spurious a sufficient difference in degree is a difference in kind. The way in which we comport ourselves while sick have the potential on net to kill millions of people where as the peril implied by users failing to update windows has never resulted in peril of that magnitude. Further one can reasonably suppose that one can with sufficient care design a system where updates are on by default and we don't create perverse situations which inspire many users to turn them off entirely.
For example one in which applications are updated without disturbing or interrupting the users workflow, where updates aren't effective until the user reboots, where applications are isolated from their underlying environments where users can roll back and pin a particular version if a new version is buggy or undesirable. Where major changes to entire user interfaces are rare and opt in for years.
How many are going to bother disabling updates?
Please don't make unfounded accusations and personal attacks based on suppositions. It was just an easy to understand analogy of how your decisions can have consequences beyond yourself, and does the job without any hint of "emotional weight". The rest is in the eye of the beholder.
> have the potential on net to kill millions of people
Talk about manipulative and lending undue emotional weight to your argument. Nothing gives weight to your own words like not following them yourself.
> one can reasonably suppose that one can with sufficient care design a system where updates are on by default and we don't create perverse situations which inspire many users to turn them off entirely.
This supposition didn't fare well in reality because it's easy to suppose but hard to implement. Especially when talking about a very complex system that has to be put in the hands of ~87+% of computer users out there, and work with tens of thousands of combinations of hardware, software and different configurations. And perhaps the most critical aspect is that the perverse incentives are left to the judgement of users with little to no understanding of the system or the wider implications of misusing it. They are more likely to follow terrible advice because the explanation for the good advice is too complicated. This is why the easy to understand analogy was useful.
This is true of capitalism and democracy. The worst choice for economics or governance except for all the other choices. I want a system that respects the users judgement not yours. No matter how well meaning you can't adopt the perspective of all users nor do I desire to see the mediocre results of smart people who know better than their users trying.
It's actually not that hard. If you make updates something that silently happens periodically without interrupting the users or making many changes to the UI that the users rely on they will let you update the parts they don't directly touch all you want to secure their systems.
When you want to make major changes make them opt in and test them to ensure they are actually substantially superior. After a while deprecate the old UI. People will tolerate infrequent major changes far better than constant small breaking changes to their workflow.
Again if you don't make updates suck you don't have to coerce people into doing them. If you are figuring out how to coerce users for their own good you are solving the wrong problem.
Of course, since it’s my hardware I just uninstalled Ubuntu and went with something that gave me more control.
(That kinda reminds me of "trust us, we're the government and we know what's best for you".)
Sorry, but that goes against everything that this whole "free software" thing stands for.
Or, why we have regulations to protect workers. Everyone doesn't have to share your worldview. There are plenty of reasons why these changes are happening. The people making the changes are normally aware of their trade-offs.
Change is the key word. If the world was better before from the perspective of the designer then they are unlikely to have changed anything, or introduced an approach you disagree with. The choice is for you: accept it, or find an alternative. That's they way of the market, no?
>> Sorry, but that goes against everything that this whole "free software" thing stands for.
I agree. Ubuntu is a particular vision of free software. They can do it the way they want. There are way that you can do free software the way that you want to have it.
you vastly underestimate the amount of changes which are just done because people have to justify doing things in order to get a paycheck
Nevertheless, I dual-boot my laptop and use Windows almost only for presentations. Whenever connections to external devices and other OS shenanigans force me to reboot my machine when I'm in the speaker position and the dreaded forced update cycle begins I swear I'll never touch that ugly OS ever again. And I already developed routine of checking for updates and booting in advance, but somehow this still happens from time time.
I guess there's need to be a special "seriously not now pretty please" button.
The fact that everyone is on the agile bandwagon churning out barely working software is the main reason why people do not want new versions of software magically appearing on their computers.
Once you've got a version that actually works for you, allowing an update to come through is like playing russian roulette.
I think this is a misconception.
A few weeks ago I was updating my Windows 7 install that hadn't booted for a year or so. I opened Windows Update. It looked for updates, and found some. I clicked the update button. It proceeded to start downloading, by which I mean it would hang for 1 to 2 minutes and then download very quickly.
When it was done updating, it required a reboot. After the reboot it needed to do something for another 5 minutes. The last 2 of those minutes it showed 100% progress, seemingly stuck again. Then when that was done, it rebooted again.
I started Windows Update again. It looked for updates. There were more updates. I clicked the update button. It proceeded to start downloading, by which I mean it would hang for 1 to 2 minutes and then download very quickly.
When it was done updating, it required a reboot... and so on, and so on, 5 or so times. Every iteration took somewhere between 10 and 45 minutes. Determining how long an iteration would take was impossible, because everything appeared to just get stuck all the time. This has been the Windows update experience through XP, Vista, 7, 8 and now 10.
The result of this madness is of course that nobody updates Windows. To solve that, you can go two different ways: Make updates painless, or force everyone to go through the pain again, and again, and again. Microsoft being Microsoft, they picked the latter.
Meanwhile, on a typical Linux system, I just decide to update every once in a while. I make it look for updates, get a list of everything that will get updated, and accept. It starts downloading, by which I mean it immediately downloads everything very quickly.
When it is done updating, it may require a reboot if the kernel got updated. After the reboot it doesn't have to do anything.
I make it look for updates, and there are none. Updating my system actually brought it up-to-date. This generally takes 2 to 15 minutes, almost entirely dependent on the amount of data that needs to be downloaded.
The result of this is that I update my Linux systems very often. It's painless, so why not?
The Windows 10 servicing model doesn’t have that problem, a new cumulative update gets pushed out every month and can get a machine to the latest update for that branch regardless of how long it’s been out of contact with Windows Update. The semi-annual branches can also be directly upgraded to from any prior branch, as they are essentially a full upgrade of Windows just like moving between releases of Ubuntu/Fedora/etc.
None of the other problems are excusable though.
No download should take 2 minutes to start, especially from a company like Microsoft. Sure, an anomaly is possible, but this update loop took several hours and every iteration was like that.
No update should ever take 5 minutes after the reboot, especially on an SSD.
No progress meter (that isn't dependent on a remote service) should ever be at 100% for 40% of its total runtime.
No single update should ever require 2 reboots.
19.04 Ubuntu just died on me today (I know some expert could have gotten in working). Apparently 19.04 support ended and someone took down the servers. So trying to update would tell me something about the servers having no release file. And they wouldn't let me update to 20.04 until I patched 19.04. I never modded anything. Whatever broke it broke itself. I searched the net for answers but my search foo sucked. Someone said download the 19.04 ISO and extract the sources.list file out. I did, it had different repos but got the same errors (with the source urls pointing to the new places of course)
So, 8 hours later I just finished reformatted the drive and installed 20.04
Yep, Linux is painless :rolleyes:
If you're not going to do release upgrades frequently you should stick to LTS releases (20.04 is one), which are supported for over 4 years: https://ubuntu.com/about/release-cycle
Sure they could use LTS but that has the same problem, just on a longer timescale.
I could turn on a PC with the first Windows 10 beta and it would update to the latest Windows 10 no problem. There's no reason Ubuntu can't do the same.
Do not feel bad about it at all: somehow it seems impossible to search for answers related to Ubuntu. Anything related is for something like 14.* or 12.* releases. I do not understand what is going on: are people really not asking the questions for newer versions, both Google and DDG not properly ranking or are the questions/answers getting somehow marked as dupe and deleted?
Inevitably you will miss some use cases. Given sufficient configurability users faced with substantial challenges will be able to find a way to use your software.
If you can easily search options including a description of the option this can still be usable for all.
Package managers (including snapd) basically just "think" in semver. Semver is one-dimensional: releases are arranged on a big line, and they'll know to auto-update based on e.g. whether a given release is close to your current release on the line.
For the cases where we do distinct security updates (e.g. kernel updates), we seem to do them using all sorts of hacks.
Maybe we just need a superset of semver, that can encode more than just the "newness" dimension, but also the "criticality" dimension?
I'm not sure if that person / team can ever be replaced by modifications to a version numbering scheme.
This is NOT how semver works, though... each section has, well, semantic meaning. Some updaters might linearize, sure, and many developers run fast and loose with versioning, but semver is a graph of varying major, minor, and patch version numbers which change with their own semantics which can describe more than just newness
Bump major -> y'all best be careful
Bump minor -> something you care about maybe changed, read the changelog
Bump patch -> we'll probably just fix some bugs
patch releases could and should be backportable to other minor releases under the same major release if people care about stability of a module. I think that the "work from master" mentality that npm and GitHub UX has lead people to is one of a handful of reasons that prople misunderstand versioning strings...
I agree that flagging criticality is useful, though. Linux packagers like YUM/DNF have had this for a while, even the ability to feed a CVE identifier or bug id in to the package manager to resolve them
I think he meant you can't totally disable snap auto-updating.
Continuing to push Xorg over Wayland. Removing support for flatpak (cross-distro way of using sandboxed apps) Horrible PPA system that works much worse in practice than the AUR or other ports systems. No daemonless docker (podman)
Lots of people try Ubuntu since it is the "most popular" version of Linux, realize it isn't great and think desktop Linux is in bad shape. The reality is Canonical doesn't seem to have good ideas and refuses to incorporate the good ideas from other distros.
FWIW I would like Wayland to finally take off, but each time there some random shit that's still broken despite 12 years of development.
> Admittedly I haven't used Nvidia
Yeah, that. Not supporting ~half the video cards in the world sounds like a clusterf*. I know it's largely nvidia's fault, but at the same time, I have a lot of investment with them, and none w/ wayland.
Arch is a no-go for most people and any sane IT department. Fedora doesn't offer LTS and RH/CentOS feel quickly outdated on desktops, let alone laptops.
Ubuntu ships a distribution that works on most hardware and provides a reasonable desktop environment. While snaps aren't the most elegant solution, they do the job when your users need to install stuff like Jetbrains IDEs for instance.
Marketing and brand recognition.
I switched to a .deb, and it was instantaneous. Then I switched back to devuan and have been happy since.
Doesn't bode well for 20.04. I've been with Ubuntu for a very long time, I like that it just works most of the time. May be time to try out another distro if all the applications are this sluggish.
https://www.omgubuntu.co.uk/2017/08/bug-report-asks-why-snap...
What if I'm a business relying on that specific version? Do I just say "oh well" and close shop?
And what about airgapped systems?
I understand there's the "security", but then, on the other hand:
1. If snapd gets forked because of this, the snap ecosystem becomes fragmented and Canonical loses control of part of their baby.
2. If snapd stays as-is, and Canonical keeps preventing user control of the update cadence, then people will just run away from using snaps once the magical auto-updates create any high-profile problem. Lxd is a snap as well, so containers will be in the crosshairs.
All in all it feels like a silly decision if you ask me.
Can you clarify?
Package installs are unbelievably fast. But mostly, the AUR repository of user contributed packaging scripts is awesome! Although I'm a bit worried about installing packages from random internet people, they are generally short and very easy to check for unwanted *ware. Haven't been disappointed yet!
I've had to install very few things from source, mostly small, opinionated system tweak utilities. But even installing from source is easier than hunting down a PPA and a key and trying to keep apt from getting corrupted somehow.
Yeah a lot of the software you see in the store is legacy software that seems to be stuck on an older version. Also many of the items are lacking a screenshot and a comprehensive description of what the software does. I find myself using the store to discover software and then go to the software's official website (usually on Github) and install it the oldskool way by doing:
./software.debI had to ditch Chromium and unfortunately resort to Chrome directly provided by Google, with all of its privacy problems.
Is it though? https://pop.system76.com/
> Pop!_OS is an operating system for STEM and creative professionals who use their computer as a tool to discover and create.
Okay but who is STEM specifically? Further down it mentions "Deep Learning" "Engineering" (Mentioned apps are all for software dev) "Media Production" "Bioinformatics".
I don't know about you, but to me that gives the exact opposite impression of "something basically for scrubs and new linux users".
That said, the feature "automatic updates whenever the system feels like it", is an annoyance for me, even if I can defer them. Typing "sudo apt full-upgrade" takes a few seconds.
I just use Ubuntu Server and get only what I need, which is available through the APT repositories. I have not noticed these repositories getting any smaller in favor of snaps and I am already using the 20.10 development branch. The Ubuntu Server installer does not install any snaps by default. However, snapd is there but it is trivial to remove it if one wants to. Chromium is the only "loss" I have witnessed and I also saw this mentioned in other comments. Note that there exists a really nice PPA, maintained by Pop!_OS, that contains quite a few packages, including Chromium.
I am wondering what security issues do snaps address that apparmor, whose purpose is security, does not. I also think it is unfortunate that we need snaps to deal with different applications / packages needing different library versions...
AppImage is awesome.
Snap is an extremely big pain when it comes to this. We have to workaround for forceful updates by telling it to use a non-existent proxy, it’s very dumb.
127.0.0.1 api.snapcraft.io
I've moved to Alpine for servers and Arch for desktop now.
As a server OS I've really found it useful.
(Except for that time when they shipped buggy versions of high-availability tools, warned against by the upstream maintainers, which segfaulted occasionally and showed inconsistent state across different nodes - thanks :/)
I found it an improvement over Debian. And that an improvement over Red Hat (before it was RHEL and Fedora). And that an improvement over Slackware. CentOS and RHEL got used too in parallel on some sites, and were very solid, but with their own annoyances.
But recently, on the server, LXD (aka LXC 2) switched from being a .deb package to being a Snap. They made a policy decision to stop shipping the .deb, to force server admins to start using Snap whether they wanted to or not, I guess.
So I was forced to use Snap just to run LXD, which was annoying as things like configs and paths to the container images are buried inside the Snap somewhere, and various things with container-uids and host-container shared mounts stopped working. At least, the upgrade broke a bunch of working scripts.
But it wasn't too painful, just a bit of work that felt like it was caused by an unnecessary annoyance.
Ironically given other comments, the Snap does not seem to auto-update unlike all the other .debs on the system!
Now, hearing about Ubuntu 20.04 and application snaps, I'm extra cautious before assuming Ubuntu 20.04 Server will be a smooth change. I'll take a look, and if the server software is much like 18.04 (except for annoying LXD) I'll use 20.04.
But if they've moved a lot of things away from .deb to Snaps-only on the server, that's going to be some overhead to deal with, and it will at least result in evaluating whether switching distro is no more effort and a better choice.
I've not been a fan of CentOS, but that time I was burned by the high-availability tools due to Ubuntu (and Debian) shipping a dangerously buggy version in an LTS release did make me realise that RHEL/CentOS are well maintained in that department and just wouldn't do that.
Even coffee shops do it. First they sell high quality coffee for little margin and "don't expect or accept tips". Then they switch to the dark side to monetize the trust: they cut hard on materials, they pay $2/hour to employees and expect the customers to subsidize their minimum wages with tips (that are now accepted and very much expected).
This is terrible. We use Ubuntu on systems where bad things can happen if software becomes unstable due to an unwanted update. In other words, nobody, nobody would ever even dream of installing any software of updating the OS without authorization. And this authorization would require regression testing in order to verify the changes would not compromise the system.
I don't understand how anyone working on Ubuntu could think this is a good idea.
To be clear, if Linux (let's say Ubuntu) is going to become a viable OS for the masses it probably needs something like this. I get it. However, there is no reason to break the traditional stability of Linux and even risk creating danger.
Disabling this mode should be as simple as one setting. In fact, it should be offered as a choice during installation with a full explanation. This is where they could make a pitch for the functionality. Those of us who don't need it (or can't use it for other reasons) can opt out and move on. Consumers, sure, I don't care.
I've always been a KDE user, which was always a first class citizen option during the Debian installation process. For Gnome / Unity users having that default promoted and baked into the distribution might have been compelling.
The refrain 'but it's so much easier to install' never really sat well with me -- I hand-install my desktop & laptop OS's infrequently, given the upgrade process (with Debian) has always been wonderfully robust. I auto-install and maintain, almost exclusively headless, every other VM, so a nicer installer wasn't relevant there.
Claims of 'stodgy' versions are rebutted by using testing or unstable branches, or even backports. For enterprise, stodgy's often a plus in any case -- look at what you get with RHEL/CentOS.
Ubuntu (or rather Kubuntu's) schedule [1] unsurprisingly isn't faster than the mothership's.
I guess there's been a lot going on in the world since February, so people haven't been 100% focused on getting free software packaged up into a free distribution as fast as normal.
[1] https://community.kde.org/Get_KDE_Software_on_Your_Linux_Dis...
I already wouldn't use ubuntu due to their long established phone-home practices, but this further strengthens the case.
FWIW, I'm pretty happy with the recently released Fedora 32 so far.
However, the implementation stinks right now. This isn't to say they won't get it right in a year or two.
Startup times didn't bother me too much, but nowadays it does, specially for things that my brain assumes that should be fast. This is why, for example, both my Neovim and Zsh configuration is tuned to start in <0.1s:
time zsh -c exit
zsh -c exit 0.00s user 0.00s system 84% cpu 0.007 total
time nvim -c qall
nvim -c qall 0.07s user 0.02s system 100% cpu 0.081 total
I don't mind autoupdates of apps, especially sandboxed ones like Snaps, and especially when they can be rolled back if issues arise. Snaps do, in fact, allow for easy reverting to a previously used revision:
$ sudo snap revert vlc
vlc reverted to 3.0.5-1
I get that the forced direction toward snaps seems premature. I wouldn't stop using it though if there's simple measures to get around it. Also use Xfce/Xubuntu.
I started to ignore ubuntu's attempts at a graphical app store long ago.
I tried Pop!_OS 20.04 in a VM just yesterday and my experience was dreadful especially with its "store" application. Things like the entire program freezing randomly for seconds while trying to fetch things, images taking ages to show up (btw, i have high speed connection), showing me ridiculous download sizes for flatpak packages (think something like Geany requiring 1.1GB or something like that), not giving any indication about download processes if you navigate away, wasting screen space when showing applications in a category (it uses a list view where each entry gets a huge icon at the left side, its title, some very short and useless description next to the icon like "Goofy is a goof foogbar", an "Install" button at the right side and vast swaths of emptiness in between), etc.
Also had UI screwups everywhere, like the Preferences application cutting out the "Preferences" title in the titlebar to "Preferenc..." when a) those three dots took the same space as the rest of the word and b) that title was the only thing in the entire titlebar with almost 500px of unused space at each side. Or controls moving and windows resizing a few pixels after i start typing something (e.g. trying to type some number in the calculator has the divider between the buttons and the number move down a little the first time i type something). And the entire "let's merge titlebar and toolbar" idea is as awful as it was when GNOME 3 introduced it (well, actually it was iTunes but i do not remember anyone ever saying that they liked iTunes). Trying some of the preinstalled apps, i accidentally clicked some tool buttons trying to move a window around (the UI being slow didn't help).
And it was dog slow. Terribly, irredeemably, laughably slow. Opening the icons had the entire UI chug worse than my 386 running Windows 3.1 (and actually i'm pretty sure if i wrote a program to move icons around in Windows 3.1 it would be faster).
IMO the only time i felt Linux had a high quality desktop environment was actually the first Linux distribution i used: Caldera OpenLinux 2.3 (to the point that in my youthful enthusiasm i force installed it to every relative and friend's computers i encountered :-P). That distribution was very well put together and thought out (try to find it in archive.org and test it in 86box or PCem with an emulated Pentium 200 and 32MB of RAM to see what i'm talking about). It had some issues, but two decades later things should have been much improved - instead everything went downhill after that and for most Linux users their desktop use is mainly a matter of how much tolerance you have for all the issues you encounter (ie. when you see someone having a problem and there is a reply like "i never had that problem" or "i've been using Linux XYZ for years and that has never been my experience", it is usually from someone who had a high enough tolerance that anything non-major does not even register anymore).
So far I see complaints about Chromium, which typically doesn't exist in a server environment.
I've been running Debian, and then Ubuntu, for a quarter-century now, largely because things just worked. .deb is nearly perfect.
Having used Docker, it's the last thing I want on my desktop, for a whole slew of reasons.
It's odd, Windows and Linux switched spots in that time. Windows 10 is faster, more stable, and more understandable than Ubuntu. Ubuntu is increasingly layered, convoluted, and bloated. Windows runs on light systems. Ubuntu requires a ton of RAM and CPU.
I think this might be the thing which will makes me give up Ubuntu.
I mean, you can claim a lot of stuff about lot of things, but saying Windows is understandable is pretty rich. You can’t even reliably cron a single script to run once an hour without weird, unfathomable, undebuggable bugs starting to pop up.
Care to elaborate exactly what you mean?
2020-era Ubuntu developed the same layeritis as Windows, only worse. Microsoft cleaned up a little bit from the bad, old Windows 95 days too. Windows 10 is slightly simpler than Windows 95, but a heck of a lot more stable.
ie: I thought they were more useful for installing a random app that is not supported by your OS... Is it easier to include a snap then it is to create a regular package? or are there any other advantages?
Shit. Just don't use Ubuntu. The writing is on the wall.