[HN Gopher] Ubuntu 20.04 LTS' snap obsession has snapped me off ...
___________________________________________________________________
Ubuntu 20.04 LTS' snap obsession has snapped me off of it
Author : uncertainquark
Score : 357 points
Date : 2020-05-02 14:53 UTC (8 hours ago)
(HTM) web link (jatan.blog)
(TXT) w3m dump (jatan.blog)
| commoner wrote:
| Snap has an issue on certain Linux distributions (including
| Fedora and Arch) in which many applications render tofu
| characters (#####) instead of text.
|
| 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.
| simion314 wrote:
| Isn't flatpack designed from the point of Desktop users (GNOME)
| where snaps are designed with a server in mind? This would mean
| that are very different and you can't just substitute them.
| commoner wrote:
| While there are Snaps for server software, Snaps are marketed
| as a way to publish applications "for desktop, cloud, and
| Internet of Things" "across Linux on any distribution or
| version" - and users expect Snap applications to work
| properly on all Linux distributions, not just Ubuntu.
| Otherwise, developers could just publish a .deb package for
| Ubuntu like they did before.
|
| https://snapcraft.io
|
| 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.
| simion314 wrote:
| My point was about making clear that snap is not a flatpack
| clone, the 2 projects were started from 2 different
| perspective and have different architectures, just wanted
| to inform some people that would think that are the exact
| same thing and Canonical can JUST drop snap and adopt
| flatpack.
|
| Edit: about autoupdates, I agree, the user should always
| have the choice.
| flatiron wrote:
| I don't even know how's it's questionable. Every single
| update we do to prod gets regression tested except for
| "cross yer fingers" 0-days that we are exposed to.
| ashtonkem wrote:
| I'm sympathetic to most of these arguments, operating systems
| should typically trend towards more clarity and user choice;
| especially ones likely to be used by professionals like Linux.
| But I will say that the Ubuntu software store has sucked for as
| long as I've ever used Ubuntu; they made it pretty years ago, and
| apparently never once considered performance or behavior. I would
| regularly search in the store for applications I knew existed,
| and it would either take forever or not find them. I always gave
| up and used apt, at least until I gave up on Ubuntu altogether.
| errantspark wrote:
| I used Ubuntu for 4 or 5 years as my daily driver for
| development. Snaps made me swap back to Arch I haven't looked
| back. All it took was one `df`.
| phosphophyllite wrote:
| It's fun to see how linux community always tries to make over
| engineered solution of any problem, instead of repeating Mac OS
| approach.
|
| Idea of ONE SINGLE DEPENDENCY TREE is just not for desktop.
| ohazi wrote:
| If you're looking for an alternative to Ubuntu but want to stick
| with a Debian-based distribution, I'll continue to recommend
| Debian testing.
|
| 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.
|
| [1] https://news.ycombinator.com/item?id=23044878
| wegs wrote:
| Is there any stable way to go Ubuntu -> Debian?
|
| 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.
| simcop2387 wrote:
| Best way is to backup your home directory and re-install.
| trying to do anything else is going to cause you far more
| headaches than anything could be worth.
|
| 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.
| paines wrote:
| Set your system up to have like 90% of the available disk
| space for /home. Rest is root. You can replace your whole
| system within half an hour.
| lucb1e wrote:
| Personally, and I'm not new to this, I find these
| partitioned setups to be quite a pain. On server systems I
| can see the point of limiting /var/log and /tmp and such,
| but on simple desktops, I only know of people dreading the
| decision to go with that historical setup instead of one
| big root.
| morsch wrote:
| It's been completely painless for me for years. I've got
| it set up pretty much exactly as the grandparent
| described: 50 GB partition mounted at /, 600 GB partition
| mounted at /home. The graphical installer has made this
| easy since ~forever.
|
| 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.
| sascha_sl wrote:
| I'm avoiding Debian like the plague since finding out a bunch
| of packages (client ones too, like nfs-common[1]) pull in
| rpcbind, which has been bugged close to ten years to
| accidentally bind to all interfaces [2].
|
| [1]: https://packages.debian.org/buster/nfs-common
|
| [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621807
| darren0 wrote:
| I tried going this route and the desktop experience was rough.
| Debian doesn't seem to have reasonable defaults for fonts so I
| spent way too much time learning and configuring all the font
| systems. So literally just the font configuration was enough
| for me to switch back to Ubuntu and just only install the stuff
| I like (no snap, gnome).
| ohazi wrote:
| Yeah, I remember this... fontconfig can be kind of a bear.
| Once you find a configuration that works for you, save your
| fonts.conf somewhere so you don't have to do it again.
|
| The Debian wiki page on fonts is helpful. The Arch wiki page
| is better, and most of it still applies:
|
| https://wiki.debian.org/Fonts
|
| https://wiki.archlinux.org/index.php/Font_configuration
| wegs wrote:
| I ran Debian for maybe 15-20 years before switching to
| Ubuntu. The first few weeks are rough. But once you get it
| configured up the way you like, it keeps on ticking for a
| decade with no announced changes or surprises. You front-load
| a lot of the work, but then productivity stays high.
|
| 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.
| lucb1e wrote:
| > Debian doesn't seem to have reasonable defaults for fonts
|
| 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.)
| ChrisSD wrote:
| Be aware that Testing may get security updates much later than
| Unstable or Stable.
|
| https://www.debian.org/security/faq#testing
| lucb1e wrote:
| Does that actually happen in practice though? And as for the
| severity, we're talking desktops so the most critical piece
| of software is the browser. Firefox is the only piece of
| software I download outside of the repositories to make sure
| the updates come directly from the source, but other than
| that, openssh very rarely has serious vulnerabilities, to
| attack Thunderbird you'd already need to mitm my traffic...
| it's all rather unlikely.
| ufo wrote:
| It is particularly bad during the freeze before the new
| stable version comes out. Some updates can be delayed for
| months.
| lucb1e wrote:
| Also security updates? Wouldn't that make the new version
| insecure at launch until someone pushes a thousand
| security updates at once (making it kind of 'testing'
| again because none of these were in testing before and
| thus haven't been widely tested)?
|
| 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.
| ohazi wrote:
| The only guarantee that the Debian project makes is that
| the stable branch is the security team's main priority. In
| practice, I've found that unstable and testing usually get
| patches pretty quickly.
| thebruce87m wrote:
| Can you use xfce as the window manager easily? Basically all I
| want is an LTE release of something with xfce or some other
| "plain" window manager.
| ufo wrote:
| The default Debian installer asks what desktop environment
| you want to use. XFCE is one of the options available.
| ohazi wrote:
| Yes! It's what I use! :-)
|
| 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.
| ComputerGuru wrote:
| Is there a way to get ZFS on Debian the same way as with Ubuntu
| (for someone that prefers text-based installers and is fine
| with an unsupported solution)? Debian has always had more
| ideological purity that got in the way of users being able to
| actually use their machine efficaciously.
| hhw wrote:
| It's not about ideological purity, but about respecting the
| GPLv2.
|
| 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.
| jlgaddis wrote:
| > _... I 'll continue to recommend Debian 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.
|
| ---
|
| [0]: https://wiki.debian.org/DontBreakDebian
| 6a74 wrote:
| There was a thread on HN about disabling Snaps last week. I found
| the process pretty straight-forward.
|
| https://news.ycombinator.com/item?id=22972661
| jablan wrote:
| It's not about whether it can be disabled or not, but about the
| direction Canonical is heading to. Also, I wouldn't call
| installing Chromium from .deb in 20.04 exactly straightforward.
| gsej wrote:
| I've been using kubuntu for a while and while I like it a lot, it
| seems very "chatty" to me - way too many notifications which I
| have to disable one at a time. I only discovered the snap
| situation when Chromium started prompting before it would open
| files, and I couldn't find a way to disable it. In the end I
| installed Chrome, but I am looking around for an alternative
| distro.
| thedevelopnik wrote:
| Was going to suggest he try Pop, glad to see he already is!
| Solves the problem while being excellent in every other way.
| risho wrote:
| I think that Pop has a bit of a branding issue. It has the
| reputation of an os with training wheels for newbies and gamer
| bros, but it is actually an all around great OS for anyone.
| It's a great gnome experience out of the box with all of the
| benefits of using Ubuntu with none of the nonsense. I'm hoping
| to see it gain popularity with the broader linux community.
| Everyone who used traditional ubuntu and isn't happy with the
| direction it's headed should really give Pop OS a shot.
| stevepike wrote:
| So I run Kubuntu on my work laptop (X1 Carbon) and just upgraded
| to 20.04 last weekend. I had a vague idea there were different
| competing standards for "linux apps that work across
| distribution" but didn't know people had such a problem with
| snap. It just seemed like a useful tool for installing
| proprietary stuff that wouldn't normally be packaged by the
| distribution. I just checked and the snaps I have that aren't
| from canonical are: datagrip, slack, discord, and spotify. I
| haven't noticed any slow app boot times and I think it's great
| that it's so easy to install third party software. Is snap
| somehow user-hostile?
| excalibur wrote:
| > Is snap somehow user-hostile?
|
| Yes, but more importantly it's insecure. The ease of typo-
| squatting is a real problem.
| lucb1e wrote:
| Isn't using the internet insecure then? I can typo
| bankname.example.nl as well.
|
| 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?
| timClicks wrote:
| > 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.
| lucb1e wrote:
| > apt is typically delivered over HTTP
|
| 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?
| blacksmith_tb wrote:
| There are some downsides (footprint, forced updates, speed,
| etc.), though depending on what you're installing those may not
| be deal-breakers. I'm using plain Ubuntu 20.04 and I tend to
| install stuff via apt and not snap in general (but I am fine
| with installing non-essential things via snap). The software
| store has a subtle toggle in the upper right for choosing to
| install a package as a snap or via apt when both are available.
| stevepike wrote:
| Yeah, is there a plan for it to long-term replace apt? I've
| just always used apt as my first choice and then snap for
| random things like spotify.
| koheripbal wrote:
| It's insecure-by-default. ...which in my mind means it's not
| really even Linux (hyperbole).
| bdamm wrote:
| How is it insecure-by-default?
| koheripbal wrote:
| Because on an Ubuntu Server, it's auto-deploying updates
| that I haven't even tested.
| bdamm wrote:
| That's not insecure-by-default, that's just you having a
| (legitimate) issue with the distribution chain. Insecure-
| by-default is installing software that has known
| weaknesses. That the process doesn't work for you doesn't
| mean the software is weak.
| gfxgirl wrote:
| Are they sandboxed individually? If not it's insecure by
| default. I mostly don't mind auto-updates on iOS and
| maybe Android as they're at least supposed to be each app
| sandboxed by default. MacOS is getting better at this.
| Windows sucks at it. Where is snaps on that spectrum?
| ClumsyPilot wrote:
| Are you alluding to possibility of an update containing
| malicious code? Is that because the update's authenticiry
| is in question or is that because of original developer
| went rogue? Leaving the system unupdated is insecure. I
| do not see how auto-updates make it insecure, but
| themselves.
| michaelmrose wrote:
| Sandboxing outside of actually using a VM isn't very
| secure on Ubuntu. The parent poster also said "server"
| nobody runs IOS on their server.
| shock wrote:
| It's insecure by default because it's allowing somebody
| else to deploy code on you machines without your prior
| say-so.
| Jonnax wrote:
| Don't you have a choice not to run snap applications on a
| server?
|
| If testing of updates is important then shouldn't you be
| running something's that's imaged or managed by something
| like ansible?
| dopeboy wrote:
| > I hate that Chromium's snap takes more than 10 seconds to load
| on cold boot on a freaking SSD, whereas .deb and Flatpak apps
| load in 1-2 seconds.
|
| Can someone verify this? As someone who will eventually upgrade
| to 20.04, this is concerning.
| [deleted]
| josteink wrote:
| > Can someone verify this? As someone who will eventually
| upgrade to 20.04, this is concerning.
|
| Chromium was converted from deb to snap already in 19.10 if not
| earlier.
| tasuki wrote:
| I can't - snap Chromium takes about 1 second to load for me on
| Ubuntu 20.04
| bitcharmer wrote:
| I can confirm this. The same app (tested VS Code, IntelliJ,
| Pycharm, Atom) installed from a deb vs a snap is like 2 seconds
| vs 8-10 seconds on my beefed up rig.
|
| It's ridiculous.
| yissp wrote:
| It takes about 5 seconds for me off an NVMe SSD. For comparison
| Firefox (installed with apt) starts in under a second.
| benhurmarcel wrote:
| Yes it starts in about 3~4 seconds for me. The only reason it
| doesn't bother me is that I normally use Firefox.
| bbbobbb wrote:
| I did not notice the load times as I basically never close
| chromium but I have noticed (not a snap expert): 1) It does not
| work well with the rest of the OS (e.g. I will pin Chromium to
| task bar but after a bit it will stop using that icon and
| instead appear as a new one where clicking the pinned one opens
| some new instance)
|
| 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.
| aritmo wrote:
| Clean install, Ubuntu 20.04. Chromium starts in around a
| second.
| wolco wrote:
| Whatever you do don't install anything else.
| mayama wrote:
| Same here. Upgrade to 20.04, but fresh install of chromium.
| Starts in 2sec in plain old HDD.
| fstephany wrote:
| Is it installed as a Snap?
|
| From what I understood, only the first start is slow. Once
| the virtual disk had been decompressed, subsequent launches
| are much faster.
| Matt3o12_ wrote:
| Apparently, snaps are compressed to save disk space, which is
| why they take so long to start:
|
| -
| 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.
| ken wrote:
| Apple has silently compressed files (including executables)
| since Snow Leopard [1] -- to _increase_ speed. Did Ubuntu
| pick the wrong compression algorithm?
|
| [1]: https://arstechnica.com/gadgets/2009/08/mac-os-x-10-6/3/
| thaumasiotes wrote:
| I see two mentions of "increased speed" in that article:
|
| 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".
| danieldk wrote:
| _It 's an interesting point, but seek times and
| rotational delays don't apply to SSDs._
|
| 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.)
| kleiba wrote:
| _Saving disk space is certainly useful for rarely used apps_
|
| Is it really? I can't recall the last time I ran into disk
| space issues, must have been in the 1990s.
| saurik wrote:
| Yeah... and when something is _truly large_ it generally
| doesn 't compress well anyway as the large assets are
| embedded media files; I don't understand the point of
| compressing stuff like this :/.
| amaccuish wrote:
| I still don't understand though. I run on btrfs with
| compression turned on and have noticed 0 performance
| issues. Only with snaps as mentioned.
| jcelerier wrote:
| I run on disk space issues almost monthly, and I have a
| fair amount of terabytes
| Matt3o12_ wrote:
| Really? I constantly run into disk space issues. Apple
| still ships their flagship 13" macbook pro 128gb storage
| and they charge $200 for another 128gb. While other
| manufacturer's laptops charge a lot less for storage these
| days, most still only come with 256 which is not enough
| these days for development IMO.
|
| 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).
| ssivark wrote:
| Yeah, then stop burying yourself with Apple devices.
|
| Anyways, it makes sense to maintain something like an LRU
| cache, and compress only the least used things.
| danieldk wrote:
| Why would you? lz4 decompresses at ~5GB/s on a modern CPU
| [1] with good compression ratios, that's still more than
| most SSDs can push nowadays. Most applications are small
| fraction of that size on-disk.
|
| 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).
|
| [1] https://github.com/lz4/lz4
| tjoff wrote:
| Whoa, it is a weird focus in this day and age...
|
| 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.
| dmw_ng wrote:
| The bottom line is they optimize installation time by
| amortizing it out over the runtime life of the package, or in
| other words, optimizing a one time 15 second process to be a
| 14 second process, in return for making a many-times 1 second
| process a 30 second process. It makes absolutely no sense.
|
| They do this using a filesystem originally designed for
| embedded devices, using a driver hacked to disable threading
| 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.
| jquast wrote:
| > On-demand decompression like this has made very little
| sense on desktops since the mid 90s
|
| 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
| zrm wrote:
| Filesystem compression is a completely different animal
| than this. It has to deal with your ability to modify the
| file at any time. It doesn't compress the whole file
| together, it does it in blocks. When you launch a binary
| (and the system mmaps it) it doesn't have to decompress
| the entire file before you can start using it, only the
| first compression block.
|
| 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.
| zrm wrote:
| > 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.
| Spooky23 wrote:
| It's a bad implementation. You can run inline compression
| on latency sensitive workloads like VDI without issue.
|
| Compression makes a lot of sense as the cost for fast high
| capacity SSD is usually much higher than the extra CPU
| cycles required to decompress.
| stefan_ wrote:
| It's not squashfs fault, it's the snap people that just
| have absolutely no clue. squashfs is designed for
| embedded systems with say 8 or 16 MiB of very slow NOR
| flash, so you maximize compression ratio at the expense
| of speed (because the flash is probably still slower).
| stingraycharles wrote:
| And decompression is typically very fast. What I don't
| understand is why they're not using something like zstd
| if they care about speed. It's a supported compression
| algo for squashfs, but still they insist on using a
| single threaded compression (xz iirc?) algo.
| Spooky23 wrote:
| I think there is a cultural bias in this type of
| application that favors disk space to reduce overheads on
| mirrors.
| cmurf wrote:
| The kernel code for reading zstd squashfs image has been
| merged for some time. But zstd is only a recently
| supported algorithm in upstream squashfs tools for
| creating the squashfs image.
|
| 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_OS
| S20...
|
| https://www.usenix.org/system/files/atc19-gao.pdf
|
| https://lkml.org/lkml/2018/5/31/306
| chrisseaton wrote:
| Isn't the point of compression to save transfer time from the
| disk to memory, not space on the disk?
|
| That's why the kernel is compressed.
| lonelappde wrote:
| Yes. It's a great idea for spinning rust, meh for SATA SSD,
| and bad for NVMe SSD.
| [deleted]
| bobmaxup wrote:
| Boots slow for me, but it isn't a big deal in my opinion. I
| like the prompts that Chromium is trying to open files, etc.
|
| Overall, snap doesn't seem terrible to me, but I haven't really
| read into the complaints everyone is sharing.
| nightfly wrote:
| Took around 10 seconds to start for me, almost exactly.
| dmw_ng wrote:
| https://forum.snapcraft.io/t/squashfs-is-a-terrible-storage-...
| LifeLiverTransp wrote:
| Any movement the buisness Operative Systems producers do, the FOS
| movement blindly mimics. In this case, treat the consumer like
| cattle and force your design decision upon him. (Win 8)I cant
| wait for FOS spyware..
| badsectoracula wrote:
| > I installed Pop!_OS 20.04 LTS just yesterday, hoping to get a
| better out of the box experience. I'll log back with thoughts
| about it next week.
|
| 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).
| gjsman-1000 wrote:
| I filed a bug a few years back asking why Snap refused to allow
| any repositories outside of Canonical's and had no open-source
| server implementation. That blew up.
|
| https://www.omgubuntu.co.uk/2017/08/bug-report-asks-why-snap...
| nottorp wrote:
| Can you still install debs with apt command line?
|
| I started to ignore ubuntu's attempts at a graphical app store
| long ago.
| mavhc wrote:
| yes, and the stupid thing is you get a second copy of the
| application, different version, different UI, seems very broken
| diablo1 wrote:
| > Browsing the Snap Store sucks
|
| 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.deb
| finnjohnsen2 wrote:
| this is one of those; ignorance is bliss. i havent noticed snap
| being slower and now I risk noticing and getting annoyed over it.
| m45t3r wrote:
| Yeah, startup times is something that you don't really notice
| until you have a system that is really fast and responsive, and
| them you simply get annoyed by when you're using a system with
| slow startup times again or get accustomed again with the
| slowness.
|
| 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
|
| It does makes a massive difference, for example spawning a new
| shell is instantaneous and when I know that I will make some
| small changes I much prefer to open a file in Neovim than Emacs
| (my main editor/IDE nowadays).
| aritmo wrote:
| Someone told my sister about the RF radiation risks of WiFi and
| now she "has headaches".
| ordinaryperson wrote:
| Maybe I'm in the minority but I like Snaps. I wish all software
| would auto-update silently in the background -- when's the last
| time you even thought about upgrading Chrome?
|
| 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.
| shaan7 wrote:
| > Maybe I'm in the minority but I like Snaps. I wish all
| software would auto-update silently in the background -- when's
| the last time you even thought about upgrading Chrome?
|
| FWIW Snap isn't a requirement to do that. You can set Ubuntu to
| update .deb packaged software automatically.
| alerighi wrote:
| The problem with snaps is that they are a stupid way to
| distribute software that doesn't solve any problem, while
| introducing many other.
|
| 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.
| ClumsyPilot wrote:
| Shared dependencies made sence back in the day, when the
| world was a simpler place and there was less variety.
|
| 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.
| tannhaeuser wrote:
| Is it? On the Linux desktop there haven't been any new
| desktop apps for well over a decade (up to maybe Krita and
| the Blender redesign). Inkscape has been 20 years in the
| making and just released 1.0. These apps are basically
| developed against the X Windows API from 1983 or so. So for
| which hypothetical apps exactly we do need these enormous
| container formats isn't clear at all. It's not that the
| existing desktops apps like Libre/OpenOffice (also from
| late 1980s/early 1990s) have grand plans for new
| components, or run better all of a sudden.
|
| 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.
| Barrin92 wrote:
| There's flat out wrong stuff in this post. First off snap
| packages don't waste a lot of disk space because they avoid
| duplication of shared dependencies by using file hashes. Snap
| packages that need the same dependencies won't duplicate
| 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.
| Conan_Kudo wrote:
| > There's flat out wrong stuff in this post. First off snap
| packages don't waste a lot of disk space because they avoid
| duplication of shared dependencies by using file hashes.
| Snap packages that need the same dependencies won't
| duplicate them.
|
| 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.
| bsdetector wrote:
| Squashfs has a sorted order to files and LZ compression
| is stable (change a byte and everything will be the same
| after the dictionary window if not sooner). So it should
| be really easy to make very small update deltas for snaps
| without any kind of complicated GIT-like infrastructure
| at all.
|
| 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.
| tapoxi wrote:
| Snap doesn't work well in distributions that don't support
| Apparmor, so you will run into various issues.
|
| 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.
| ptx wrote:
| > Snap packages that need the same dependencies won't
| duplicate them.
|
| 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.
| lucb1e wrote:
| > when's the last time you even thought about upgrading Chrome?
|
| 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.
| vetinari wrote:
| > when's the last time you even thought about upgrading Chrome?
|
| 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.
| finnthehuman wrote:
| Snap is not auto-updating, auto-updating is not snap.
|
| 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.
| michaelmrose wrote:
| You claim that snap offers real benefits but list none and
| dismiss detractors as irrational and suggest that instead of
| complaining about Snap users who have no desire to use snap
| should invest their own efforts to improve something they have
| no desire to use instead of being critical.
|
| 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.
| thawaway1837 wrote:
| The difference between systemd and snap is that systemd has
| been validated by almost all the major distro makers. The
| exceptions are largely people who don't want systemd
| precisely because of systemd's popularity, and they want to
| retain some diversity in the ecosystem.
|
| Canonical could barely get its own users to prefer snaps over
| the alternatives, which is why they are forcing it onto them.
| michaelmrose wrote:
| More people using a system doesn't validate anything by
| that definition we ought to deprecate linux and mac on the
| desktop and all just use windows. Concepts and tools
| require objective validation not popularity.
| RealityVoid wrote:
| This is the most articulate argument for why snap is
| problematic so far. I'm sold.
|
| Do you think it will be pushed to the background with time or
| will Canonical manage to push it through?
| bluedino wrote:
| Chrome auto updates cause issues on the Mac. No thanks.
| ordinaryperson wrote:
| OK, what issues does it cause? And are those issues
| outweighed by the security and standardization issues raised
| by non-updating software?
|
| 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.
| bluedino wrote:
| Crashes, freezes, stopping systems from sleeping... I don't
| want Google's (or anyone else's) code running in the
| background doing whatever it wants. Want to check for an
| update and notify me? Great. But don't do anything else.
| lonelappde wrote:
| If you want to professionally sysadmin your system, don't
| use a consumer convenience-oriented OS and userspace
| apps.
| capableweb wrote:
| You might be on the wrong operating system if you don't
| like "code running in the background doing whatever it
| wants" as Apple has never shied away from doing just so.
| Try inspecting what your computer does when you've been
| away from it for 30 or so minutes, and you'll see a lot
| of chatter from Apple apps.
| ordinaryperson wrote:
| > I don't want Google's (or anyone else's) code running
| in the background doing whatever it wants.
|
| 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.
| vageli wrote:
| Software companies are not infallible, and I've received
| updates in the past that have broken things. Enterprises
| don't get compensated for lost productivity when an auto-
| updating app results in broken workflows. Also, we recently
| got hit with a bug in a new auto-updated version. [0] It's
| great that this was finally fixed but silently rolling out
| updates like this make it harder to catch these issues
| before they are problems in the wild.
|
| [0]: https://paul.kinlan.me/correct-image-orientation-for-
| images-...
| ordinaryperson wrote:
| OK, so there was an image orientation bug in that
| specific release of Chrome.
|
| But it's estimated there are _1 billion_ users of Chrome.
| One billion! How wide of an attack surface does that
| present? Or how much of a nightmare would it be if they
| were all on wildly different versions?
|
| I get that this specific bug may have caused problems for
| you. But if I had to choose between security and
| compatibility for 1 billion software users vs an
| occasional image orientation bug, I'll choose the former,
| personally.
| wolco wrote:
| 1 billion chrome users != 1 billion ubuntu users.
|
| 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.
| vageli wrote:
| > But if I had to choose between security and
| compatibility for 1 billion software users vs an
| occasional image orientation bug,
|
| 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.
| lonelappde wrote:
| Maintaining forks of old versions is expensive and error
| prone.
| ordinaryperson wrote:
| It's a simple example but that's the kind of tradeoffs
| platforms are trying to make. Small bugs in favor of
| security and compatibility. It could be a thousand image
| orientation bugs. Same arguments still apply.
|
| 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?
| wolco wrote:
| No using third party software doesn't mean you are
| consenting to their control. Why would you believe that?
|
| 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.
| thawaway1837 wrote:
| Without commenting on the quality of snaps, I find Canonical
| replacing the App Store that supported all 3 distribution
| methods, with one that drops support for flatpak, and
| prioritizes snaps over .deb to the extent it will display a
| snap result over an exact matching .deb result in a search
| extremely user hostile.
|
| 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.
| apostacy wrote:
| It is wrong to frame this as people not liking auto-updates.
| That is not the issue. The issue is FORCED auto-updates. Or
| even just obfuscating how to turn off updates.
|
| 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...
|
| [2]: https://news.ycombinator.com/item?id=21064663
| kzemek wrote:
| Chrome, no. But I am running FRR on Ubuntu server, and it's
| also distributed as a Snap - in fact, that has spurred the most
| known discussion about Snap autoupdates[1].
|
| 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...
| ordinaryperson wrote:
| OK, but why is the problem FRR not addressing bugs it may be
| auto releasing and instead the entire principle of auto-
| updates in general?
|
| 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?
| Shared404 wrote:
| All software has bugs. Also, how are the application
| developers supposed to test for every single environment?
|
| 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
| GordonS wrote:
| I think Windows updates illustrates your point nicely.
|
| 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!
| snailmailman wrote:
| I'm still on 18.04, but I agree. Discord and VSCode keep
| occasionally prompting me to manually download and install .deb
| files. I'd really prefer if they just updated automatically.
| Discord gives a full page "download this update to keep doing
| things" message that interrupts everything. (i think only on
| larger updates? i havent seen it in a while) A quick google is
| telling me that both have snap packages - I guess I'll probably
| be switching to those when I setup 20.04. Hopefully the snap
| versions work as well as the non-snaps.
|
| 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.
| shaan7 wrote:
| > Discord and VSCode keep occasionally prompting me to
| manually download and install .deb files. I'd really prefer
| if they just updated automatically
|
| 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.
| snailmailman wrote:
| oh cool! I do see the repository in the list. Come to think
| of it I haven't noticed the popup recently. It used to be
| basically be a thing in the corner of vscode with a link to
| the download page. I would usually do the update manually
| when i saw it, cause I thought it couldn't update on its
| own.
| Avamander wrote:
| > when's the last time you even thought about upgrading Chrome?
|
| Every. Fucking. Week. Because it breaks my session every update
| thanks to the inane switch to snap.
| capableweb wrote:
| My two cents, you don't have to agree but thought I'd just add
| a different perspective.
|
| 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.
| ordinaryperson wrote:
| My position is not that certain users would prefer to update
| on their own schedule. Of course there are.
|
| 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.
| pikelet wrote:
| I guess that, exactly yes, they should ask! The problem
| people have is that there is no way to turn them off, not
| that they exist. This is nothing to do with change and
| everything to do with taking control away from the user.
| For some users, yes, that may be beneficial. But without at
| the very least giving the option you're also alienating
| many more. I want to update my system when it's convenient
| for me to do so (particularly because I'm currently in a
| location with very poor internet), not when I'm in the
| middle of important work, at the whim of my operating
| system.
|
| 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.
| zenexer wrote:
| Auto-updating isn't the only issue. I'm a stickler for
| security updates; I'm that crazy guy who always reboots his
| computer immediately whenever there's an update. I like
| that Windows forces updates.
|
| 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.
| compuguy wrote:
| I honestly haven't used snaps in a server context. I get
| them from the desktop context. I would probably use
| docker containers & docker-compose before using snaps. I
| honestly have more control in pushing updates and the
| like in that situation.
| Shared404 wrote:
| +1 for almost everything. Also, Alpine is brilliant as a
| server OS.
| ptx wrote:
| > The problem is if you want to distribute an important
| security update, what do you do? Ask everyone nicely to
| upgrade?
|
| 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.
| Aeolun wrote:
| > 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.
|
| 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.
| Legogris wrote:
| I think there would be a lot less complaining about the
| existing unattended-upgrades functionality being enabled by
| default on dektop, than the new self-updating capabilities
| of snaps.
| rlpb wrote:
| > 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.
|
| You can arrange snapd to update on your preferred schedule.
| What you cannot do is defer updates forever.
| D2187645 wrote:
| Would iptables help block snap from reaching out?
| michaelmrose wrote:
| You can just not install Ubuntu
| Longhanks wrote:
| Yes, I can. This is my computer, and if snap does not obey
| my wishes, it's getting removed.
| compuguy wrote:
| I get your points. In situations where Ubuntu 20.04 machines
| are on airgapped networks or corporate networks that use
| mirrors and the like. For personal and other situations I
| prefer flatpak and snaps...
| lmm wrote:
| > I wish all software would auto-update silently in the
| background -- when's the last time you even thought about
| upgrading Chrome?
|
| 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.
| ordinaryperson wrote:
| > Updating everything has always been one click in Ubuntu
| (and I'm sure there's an option to have it go automatically).
|
| 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?
| wolco wrote:
| The auto update because users can't make the decision
| themselves is just copying windows 10 model.
|
| 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?
| ordinaryperson wrote:
| Auto updates have existed long before Windows 10.
|
| 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?
| CathedralBorrow wrote:
| This percentage seems to be the crux of your argument so
| I'm curious to know what it is. Are you relying on any
| data?
| pessimizer wrote:
| If you're making up percentages of people who update when
| they see an icon and a message telling them updates are
| available, asking other people to make up their own
| numbers, then deciding that we should make decisions
| based on these made-up numbers, I think you're on the
| wrong track.
|
| 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.
| qznc wrote:
| The promise is that providers can build one package for all
| Linux distros, Afaik. Less work for packagers. More packages
| for obscure distros.
| Legogris wrote:
| This is getting OT, but could you elaborate on your issues
| with systemd? I'm genuinely curious. I often see people
| complain but haven't seen or experienced specifics apart from
| it being complex and having higher learning curve than initd.
|
| (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.
| z3t4 wrote:
| Systemd gives you less control. I used to pipe stderr to
| email, cant do that with sustemd. The journaling system is
| very slow compared to plain text files. Systemd overwrite
| mounts made by ip netns. Network settings is complicated
| with systemd. Not all bad though, setting up services is
| easy, and it has never failed to start a service for me so
| far, and it do start services in the correct order, which
| is all it should do imho.
| Legogris wrote:
| Can't you just wrap your service? Something along the
| lines of
|
| > 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 ;)
| MereInterest wrote:
| My first experience with systemd was when they implemented
| a default that would kill processes when a user logs off.
| This may be acceptable in some single-user desktop
| environments, but it is absolutely unacceptable in any
| server environment. If I am using tmux, emacs --daemon,
| nohup, or any other custom program that catches SIGHUP,
| then it is inexcusable for systemd to escalate to sending
| SIGKILL.
|
| 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.
| Legogris wrote:
| > 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?
|
| 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?
| ordinaryperson wrote:
| Unattended upgrades is a great example. You must manually
| install it, it's difficult to configure (you must edit some
| complex text file) and even then with it on and set to update
| all types of packages it often still doesn't. Maybe I'm doing
| something wrong but in my long experience with Ubuntu I've
| found unattended-upgrades very unreliable.
|
| 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.
| chrisma0 wrote:
| Good to see that I am not alone at being upset about the current
| snap vs. deb vs. flatpak Ubuntu situation. I always considered a
| unified package management system as a huge plus.
| Glavnokoman wrote:
| I do not understand that. Why being upset? If you do not like
| Ubuntu just install some other distro and be done with it.
| There are many out there! Fedora, Arch (Manjaro) and even plain
| Debian are all much better then Ubuntu these days.
| lonelappde wrote:
| It's exausting to switch every time an upgrade is a betrayal
| lern_too_spel wrote:
| It is not straightforward to switch distros and maintain your
| setup. You have to set aside at least a day for it.
| hypnotist wrote:
| Can anyone recommend good rpm based distro for desktop(business
| env)?
| BenjiWiebe wrote:
| CentOS or Fedora?
| mixmastamyk wrote:
| I only use the micro editor as a snap. The chromium snap was
| forced on me. I keep it around to test and separate web stuff.
| From that minimal use I get a daemon running and a dozen bullshit
| mounts. Wish they just statically compiled it.
| daneel_w wrote:
| I was asked by a friend to get Netflix working on his Lubuntu
| 20.04 Linux laptop. He was running Chromium which comes without
| Widevine, and the extension wasn't available in the Chrome Web
| Store, but it can be enabled by simply making libwidevine.so
| available in Chromium's library path. But how to add a file to
| the sandboxed lib/ directory of a Snap? You can't without
| rebuilding the entire Snap as your own custom product, and then
| it's no longer a standard package from the repo so you lose the
| blessings of package updates! Maybe there's a better way, but I
| sure could not find one.
|
| I had to ditch Chromium and unfortunately resort to Chrome
| directly provided by Google, with all of its privacy problems.
| CameronNemo wrote:
| Did Firefox not ship with widevine?
| greendave wrote:
| > Auto-updating of snaps can only be deferred at best, until at
| some point, like Windows, it auto-updates anyway. Even on metered
| connections, snaps auto-update anyway after some time.
|
| This attitude is obnoxious. Yes, not everybody is on a metered
| connection or running a mission-critical system, but some are,
| and it is hardly unreasonable to accommodate them.
| ssivark wrote:
| I don't understand this overbearing obsession for computing
| companies to direct their users into certain corners. Why?
| bitcharmer wrote:
| I've been a very faithful Ubuntu user for 12 years now but if
| there's no easy way to disable this abomination then my current
| one (18.04) will be the last. Whose idea was it to replicate
| one of the worst features of Windows?
| qznc wrote:
| 18.04 is supported for three more years. Maybe that will be
| my Ubuntu countdown.
| scrappyjoe wrote:
| 18.04 has a ten year extended security maintenance life
| AFAIK, so you could stretch to 2028.
| eitland wrote:
| Wow, that's seriously impressive if true.
|
| 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.
| danieldk wrote:
| Ubuntu security updates do not cover the _universe_
| repository, which contains the largest number of
| packages. The _universe_ repo is 'community-supported',
| which means that a lot of CVEs are not fixed in practice.
|
| 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.
| oarsinsync wrote:
| Anyone have any idea what Debian's LTS security posture
| looks like? Is it also restricted to 'main' and does it
| also ignore 'contrib' and 'non-free'?
| danieldk wrote:
| Similar policy:
|
| 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.
| na85 wrote:
| Gnome has been replicating the worst parts of windows (the
| registry comes instantly to mind) since the release of Gnome
| 3.
| harrygeez wrote:
| I think gconf and macOS's plist have proven that Microsoft
| is at least somewhat right with registry, or at least the
| idea is. I don't know why people didn't like it and
| honestly I don't have a strong opinion on it, but I have a
| feeling in some ways Microsoft didn't have much of choice
| given that they need to have backwards compatibility.
| numpad0 wrote:
| I was warned far more than necessary about corrupting The
| Holy Windows Registry Hive, I think that's the entirety
| of the problem with it.
| guitarbill wrote:
| it's handy for config, sure. but it has several
| downsides. very opaque compared to a config file.. keys
| can't have comments. the average user has no idea what a
| "dword" is. some registry paths are obscenely long. you
| can accidentally break one program or windows trying to
| edit another's settings. and i'm not sure currently, but
| a big problem in the past was uninstallers didn't remove
| registry keys reliably.
|
| 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.
| bepvte wrote:
| gconf is like the windows registry how? is it just because
| its a centralized config store? how evil is an annotated,
| easy to use, non archaic file that some apps put their
| settings into?
| mavhc wrote:
| it must be evil because Microsoft did it. Weird that they
| copied everything else Windows did and people didn't
| mind.
|
| There's way more evil things about Windows, like click to
| raise and menu bars.
| rrix2 wrote:
| Evil, huh?
| jhanschoo wrote:
| A centralized location for GNOME config has always been
| present since GNOME 2 (maybe earlier, but 2 was when I
| started with GNOME). See, for example, this page https://ww
| w.linuxtopia.org/online_books/linux_desktop_guides...
| Vogtinator wrote:
| dconf is now a binary format though.
| pengaru wrote:
| With that Ubuntu has become useless trash joining the ranks of
| Android and its impossible to disable constant Play Store
| updates funneling endless unknown changes onto a machine you
| supposedly own.
| bspammer wrote:
| I've had no problem disabling automatic Play Store updates on
| my phone. It's in the top level of the settings.
| pengaru wrote:
| I'm talking about the play store updating itself. It's
| proven impossible to entirely disable over here, and when I
| used adb to forcibly uninstall the play store the device
| stopped booting a week later requiring a factory reset.
| yjftsjthsd-h wrote:
| What? The play store lets you disable auto-updates, at least
| per-app.
| pengaru wrote:
| Try absolutely blocking the play store from updating
| itself. Even when I've jumped through all the hoops to
| supposedly stop this from happening, it will still randomly
| do an update in my experience.
| cerberusss wrote:
| Please check the HN guidelines about "shallow dismissal".
| nikanj wrote:
| I might defend this if the updates were something like a remote
| wormable hole, but the updates are more likely to be
| improvements to drawing avatar icons in Dark Mode or something
| similarly trivial.
| derefr wrote:
| How would you indicate to a package manager that something is
| a critical bugfix release, rather than a non-critical feature
| release?
|
| 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?
| nikanj wrote:
| I use a commercial OS, so there's a company out there where
| some well-paid professional decides which updates need to
| be pushed out ASAP and which ones can wait until next patch
| Tuesday.
|
| I'm not sure if that person / team can ever be replaced by
| modifications to a version numbering scheme.
| rrix2 wrote:
| > 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.
|
| 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
| ressetera wrote:
| I'm using opensnitch[1] and it can block snap requests. Pretty
| nifty software, but it brings my machine to its knees unless I
| ``` sudo service opensnitchd restart ``` once in a while.
|
| [1] https://github.com/evilsocket/opensnitch
| ajross wrote:
| To be fair, Snappy isn't aimed at "mission critical systems",
| nor even at bandwidth constrained users. It's a
| straightforward, reasonably robust and obviously used mechanism
| for pushing routine consumer software. In that realm, the
| aggregate benefit to society of having everyone running current
| software outweighs the annoyance of the specialists, sorry.
| It's always been this way.
|
| If you are running "mission critical" 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.
| stryan wrote:
| Ubuntu is sending out "Mission critical" software as snaps: I
| think the biggest offender has been LXD, but I'm sure there's
| others.
|
| 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)
| ajross wrote:
| > IMO Docker and containers in general are deployment
| tools, not packaging systems
|
| 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.
| mrweasel wrote:
| LXD is a weird one, it doesn't seem that suitable for
| distribution as a snap in the first place. The filesystem
| become a magical bundle of weirdness when you use the snap
| version. Also LXD is something I'm not that happy to have
| auto updating, I would like to roll it out to a test,
| preprod or staging environment first.
|
| To me snaps seems like a desktop solution that Ubuntu
| forgot to disable on the server edition.
| codewithcheese wrote:
| I think the issue is we expect Ubuntu to not only design
| features for common folk but also have an easy to use
| solution for the type of tech literate people that Linux
| attracts.
|
| They have prioritized snaps but how have they made life
| easier for those of us running "mission critical" software?
| inshadows wrote:
| > reasonably robust
|
| > 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.
| Stierlitz wrote:
| > .. and it is hardly unreasonable to accommodate them.
|
| I think he meant you can't totally disable snap auto-updating.
| daenz wrote:
| I guess it's finally time to switch to Arch. This is an
| absolute deal breaker for me as well, as I use an ubuntu system
| for live visual performances, and I need to ensure that no
| unexpected auto-updates take place.
| searchableguy wrote:
| Try pop os. It doesn't come with snap despite being based on
| ubuntu 20. They use flatpak in their store.
| GekkePrutser wrote:
| Personally I don't want FlatPak either except maybe for 1
| or 2 apps where the sandboxing actually makes sense. It's
| still a waste of resources just to appease lazy
| maintainers.
|
| 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.
| s_tec wrote:
| As a long-time Arch user, I can say that the switch is not
| for the faint of heart. Arch won't do _anything_
| automatically, including installing basic things like a
| window manager or a browser - Arch is more of a "build your
| own OS" experience.
|
| 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.
| daenz wrote:
| Good warning, and I agree on the learning curve. I've been
| using ubuntu mainly as a convenience, and it's amusing how
| frequently I refer to the Arch wiki (which is excellent[0])
| to diagnose/fix ubuntu-related issues. I've wanted more
| fine-grained control over my daily system for a long time,
| and this snap debacle is the final straw for me.
|
| 0. https://wiki.archlinux.org/
| SteveBash wrote:
| I'd recommend NixOS instead. Trying different desktops is
| easy as changing the config and doing a `sudo nixos-rebuild
| test`.
|
| 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).
| daenz wrote:
| I've looked into Nix, and I like what it's accomplishing in
| principle with atomic upgrades/rollbacks, but I felt very
| frustrated by their clunky package "DSL." I use quotes
| because it appears that they are trying to encompass an
| entire programming language worth of constructs. Why they
| didn't go with an existing real programming/scripting
| language is beyond me.
| modzu wrote:
| if you like Ubuntu and stability go debian. edit: the
| downvotes are fascinating. if you do LIVE performances and
| even remotely care about stability Arch is the _last_ distro
| you should use. its a great distro but its bleeding edge by
| design. part of the fun of arch. contrarian views should be
| expressed with words if possible because id like to know what
| universe some of you are from..
| maximente wrote:
| i saw it explained once to someone else that arch is more
| cutting edge, than bleeding edge. it's not like you're
| getting beta software or anything with arch - it just
| updates very frequently. it's a hacker's OS at the end of
| the day; the culture is that you're buying in to the high
| ownership/control of your machine, ergo you're going to put
| a higher effort into at least searching wiki/forums/main
| page for issues.
|
| 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.
| [deleted]
| daenz wrote:
| I didn't downvote you, but the appeal of Arch to me is the
| extreme customization. Sometimes I need to do really funky
| setups. That said, the stability of debian is also very
| appealing for the very reasons you stated.
| supernintendo wrote:
| Just remember that Arch is a rolling release distribution so
| the updates you do get will be bleeding edge. I recommend
| setting up Timeshift and always backing up your system before
| updating; if you're using BTRFS it's instant (although ext4
| is practically instant on modern NVMe drives).
|
| 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!
| shrimp_emoji wrote:
| +1 for Manjaro.
|
| 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).
| koolba wrote:
| It's beyond obnoxious. It's your computer and there's no way to
| disable it from mutating without file system hacks?
| kazinator wrote:
| It's not your computer when Canonical is chummy with
| Microsoft.
| noncoml wrote:
| There is. Don't install Ubuntu. Use Debian.
| ip26 wrote:
| The above might come across as flip, but I think it's
| actually spot on. Why would a mission critical or metered-
| connection-only machine be running the latest Ubuntu
| desktop anyway? Match the tool to the job.
| indigodaddy wrote:
| It usually wouldn't even be running Debian. More likely
| CentOS/RHEL/Suse or a Solaris.
| noncoml wrote:
| That's the beauty of Linux Distros. We are spoiled for
| choice.
| SomeoneFromCA wrote:
| Or even, gasp, *BSD.
| curt15 wrote:
| Google rebased their in-house workstation OS from Ubuntu to
| Debian a few years ago.
| https://www.zdnet.com/article/google-moves-to-debian-for-
| in-... I wonder if snaps a contributing factor.
| ashtonkem wrote:
| Ubuntu has a real problem here; Desktop Linux users are
| much more mobile than other OS users. If you've installed
| Ubuntu, you're fully capable of installing at least Debian,
| and probably any other Linux distro.
| paride5745 wrote:
| You can cleanup Ubuntu from snaps: https://www.kevin-
| custer.com/blog/disabling-snaps-in-ubuntu-...
|
| 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.
| KozmoNau7 wrote:
| Or KDE Neon, which is by far the best distro I've used in
| 20 years of messing around with Linux.
|
| 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.
| harrygeez wrote:
| This is a hard problem.
|
| And Microsoft didn't have a choice. Given an option regular
| users will never update their computers, perhaps partly due to
| fear of what they don't understand, fear of change, or maybe
| due to past bad update experiences. I witness this in my mom
| with technology all the time. Every time there's a popup she
| mini-panics, and she has trained herself to click close every
| time she sees something she 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
| michaelmrose wrote:
| Options are for everyone not power users. Options are a
| necessary escape hatch for users when you fail to take into
| account their needs.
|
| 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.
| jorams wrote:
| > Microsoft didn't have a choice. Given an option regular
| users will never update their computers
|
| 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?
| my123 wrote:
| Updates are cumulative now to avoid such issues. Prior to
| this, the updating choices were geared towards regular
| users, so that such a case wasn't really counted...
| snuxoll wrote:
| The update loop on Windows 7 is more an artifact of the
| traditional Windows servicing model where updates aren't
| cumulative and only periodically were cumulative bundles
| released, as well as service packs incorporating prior
| hotfixes as well.
|
| 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.
| jorams wrote:
| It's great that they fixed that part, but to be honest
| that was the most excusable of the problems. I understand
| that maintaining an update path from any old version to
| the current one can be hard, so updating in steps is
| fine.
|
| 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.
| gfxgirl wrote:
| 45 to 90 mins to update my Macs. They might not reboot 5 to
| 10 times but it's not quick.
|
| 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:
| ric2b wrote:
| 19.04 isn't an LTS (long term support) release, it has 9
| months of support, you're supposed to upgrade to the next
| release in a timely manner.
|
| 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
| thekyle wrote:
| Cononical should really keep the old repos up for longer.
| At least the parts necessary for upgrading to the next
| version. 19.04 is barely over a year old. It's entirely
| reasonable for users to leave a computer for a few months
| and expect it to still work when they come back.
|
| 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.
| matheusmoreira wrote:
| I don't know why major distribution upgrades are so
| unreliable. I used to be a Fedora user and it was pretty
| much impossible to upgrade the distribution version
| without breaking a lot of stuff. The package manager
| corrupted its own database once. I switched to Arch Linux
| and never had these problems ever again despite all the
| memes about Arch being unstable.
| m4rtink wrote:
| Distro upgrades have been pretty much solved problem in
| Fedora since about Fedora 20. With Fedora 32 just
| released, that means ~6 years ago.
| bragh wrote:
| > I searched the net for answers but my search foo
| sucked.
|
| 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?
| jimbob45 wrote:
| The customer is always right. Say it with me.
| rrdharan wrote:
| The other customers, impacted when one customer is out of
| date and their machine turns into part of a massive DDoS
| Botnet, are _also_ customers. Say that with me. It 's a
| distributed problem that you can't fix or meaningfully
| reason about just by imagining each user on their own in a
| vacuum.
| Achshar wrote:
| Disagree. "If I had asked people what they wanted, they
| would have said faster horses." - Henry Ford. Customer is
| _mostly_ right. Not always. Use your best judgement as a
| business owner. Innovate where necessary and stick to
| customer feedback where you think it makes sense.
| GekkePrutser wrote:
| Henry Ford was a total dick and not customer-focused at
| all.
| dTal wrote:
| I think there's a pretty big distinction between the
| customer lacking the imagination to see a better solution
| until it is presented to them, and being denied a choice
| while being in full possession of the facts.
| Achshar wrote:
| The auto update certainly falls in the former you mean?
| These (older, less tech savvy) people clearly lack the
| imagination. That's why auto update has to be mandatory.
| This is again for consumer facing OS and not for the
| server infra.
| thawaway1837 wrote:
| Yeah, and this isn't even an equivalent situation.
|
| 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.
| [deleted]
| harrygeez wrote:
| Unfortunately this is an attitude I do not agree with.
| Especially having worked in the service sector, far too
| many people use this as an excuse to be rude and
| unreasonable.
|
| I believe in mutual respect
| zaat wrote:
| I understand that Microsoft see the large number of
| vulnerable machines on the internet as a problem thay they
| are responsible for and the forced update as a necessary
| solution.
|
| 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.
| kds3 wrote:
| Like a big "pause updates" button they already have for
| years in the "advanced options" tab?
| zaat wrote:
| Exactly, just without the time limits. Also, make it work
| for all updates. Oh, and While they are at it, they
| should also remove the nasty auto update of office
| application when starting them, without giving any prior
| hint or notice.
| zerkten wrote:
| > 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 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).
| ashtonkem wrote:
| If I've got the technical know how to install Ubuntu, I
| should have full control over my machine; full stop. It's
| my hardware, so it's my rules.
|
| Of course, since it's my hardware I just uninstalled Ubuntu
| and went with something that gave me more control.
| zerkten wrote:
| It's your machine, but you are talking about software you
| don't control. This would imply that the software won't
| always follow your rules.
| jlgaddis wrote:
| So because perhaps _some_ '"power users" can't be trusted"
| (in your opinion), that makes it's okay to just take away
| their own control of their own computers?
|
| (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.
| zerkten wrote:
| >> (That kinda reminds me of "trust us, we're the
| government and we know what's best for you".)
|
| 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.
| jcelerier wrote:
| > If the world was better before from the perspective of
| the designer then they are unlikely to have changed
| anything
|
| you vastly underestimate the amount of changes which are
| just done because people have to justify doing things in
| order to get a paycheck
| cwyers wrote:
| There's a real Dunning-Kruger problem with "power users,"
| where some people know just enough to get themselves into
| trouble. And I think these D-K power users outnumber the
| "real" ones.
| Enginerrrd wrote:
| The arrogance in this comment astounds me. It's almost
| never appropriate to assume that people don't have the
| right to make decisions for themselves, even if you think
| those decisions harm them. People have different values and
| weigh their own decisions against their own values, not
| yours.
| close04 wrote:
| > It's almost never appropriate to assume that people
| don't have the right to make decisions for themselves,
| even if you think those decisions harm them
|
| 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.
| michaelmrose wrote:
| It would be appropriate if you didn't try to misuse the
| present crisis to lend undue emotional weight to your
| argument. This is manipulative.
|
| 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?
| close04 wrote:
| > It would be appropriate [...] This is manipulative.
|
| 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.
| zerkten wrote:
| I'm sorry that this is uncomfortable reading for you, but
| not everyone shares your values. What you describe is
| nice conceptually, but is not actually true for most of
| society. You can have opinions that people might bucket
| as libertarian, or similar this doesn't mean that the
| world thinks the same.
| proactivesvcs wrote:
| > Given an option regular users will never update their
| computers
|
| 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.
| mcny wrote:
| My problem on Windows has never been auto update. It is the
| forced reboot. One that Microsoft refuses to fix because
| "muh backward compatibility" and instead forces reboots.
|
| 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.
| proactivesvcs wrote:
| >My problem on Windows has never been auto update. It is
| the forced reboot.
|
| 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.
| silverreads wrote:
| It's not that they do not understand what is good for them,
| they are simply rejecting your new features.
| No1 wrote:
| > 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.
|
| 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.
| ashtonkem wrote:
| People feared Windows updates long before agile was a
| thing.
| GekkePrutser wrote:
| Microsoft did have a choice. They could simply have hidden
| the disable auto update (and telemetry for that matter!)
| somewhere deeper in the OS where non-techie users will never
| find it. Or even a registry key or whatever.
| majewsky wrote:
| Windows has a long history of tech-illiterate users
| downloading optimizer tools from shady websites that mess
| with registry keys and break stuff in surprising ways. And
| it's always Microsoft who gets the blame, not the shady
| utility. From that POV, I can understand Microsoft being
| reserved about gating this kind of stuff behind registry
| keys. These days, you can only do this stuff with group
| policies if I'm not mistaken, a feature that regular home
| users don't have access to.
| harrygeez wrote:
| I haven't been using Windows for a while, but I think
| there's a way to disable via Group Policy or registry now?
| jimbob45 wrote:
| There is. Hard, but possible, just the way it should be.
| cartoonfoxes wrote:
| Enterprise and Education only.
| Marsymars wrote:
| There always has been (though perhaps not for Windows
| Home Edition). My Windows systems have never, and still
| don't auto-update.
| simias wrote:
| >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.
|
| 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.
| majewsky wrote:
| > You make it sound like an irrational fear but there's a
| real cost/benefit ratio to consider when you upgrade a
| machine.
|
| 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.
| zozbot234 wrote:
| > 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.
| bbarnett wrote:
| That's actually untrue.
|
| 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!
| simias wrote:
| I'd argue that almost 100% of users, myself included,
| can't really make this analysis for any given update.
| Usually you can't anticipate what will brake, that's what
| makes upgrades scary.
|
| 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.
| ChrisSD wrote:
| Arch is a rolling release, upgrades are expected to break
| the system at some point. Windows updates aren't meant to.
|
| 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.
| dahdum wrote:
| > These have been an issue mostly because Microsoft had
| been using a random subset of Home users as beta testers
| for new updates.
|
| 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.
| [deleted]
| searchableguy wrote:
| Are linux users regular users?
| apexalpha wrote:
| What if your goal is to bring Linux to the masses?
| searchableguy wrote:
| That boat sailed long ago. Windows has a pretty decent
| linux subsystem now. Even devs that were hardcore linux
| enthusiasts moved to windows.
|
| 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.
| stOneskull wrote:
| I think dual booting is still the way. Gets the best out
| of linux and eliminates headaches. Boot up times are so
| fast these days, in and out of the OSs almost as fast as
| logging in and out.
| alrs wrote:
| ehhhh, I've never seen a hardcore Linux developer move to
| Windows. WSL exists to sunset Windows-based development,
| not the other way around.
|
| 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.
| indigodaddy wrote:
| Windows Server won't be getting "sold off." I'm not sure
| you understand just how entrenched Windows Server is in
| the Enterprise and just about every Fortune 500 company
| out there, including huge telecoms and ISPs. MS still
| makes a ton of money off Server, and most of the
| companies/Enterprise using Server aren't even thinking
| about Azure.
| screamingninja wrote:
| > Even devs that were hardcore linux enthusiasts moved to
| windows.
|
| Is this a personal opinion or pure speculation?
| searchableguy wrote:
| Just saw it within my circle.
| SlowRobotAhead wrote:
| Well then there is a lot of work to do besides snapping
| and updates.
|
| 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"
| BenjiWiebe wrote:
| In my experience the average Windows only user is just as
| clueless when Windows breaks. Which it does, plenty of
| times.
| SlowRobotAhead wrote:
| That's not untrue at all. It's just that when I have used
| that needs to reset his WiFi adapter, there are nice
| picture tutorials for Windows, and on Linux you better
| have some idea what a /dev/ is.
|
| 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.
| searchableguy wrote:
| For comparison -
|
| https://net2.com/how-to-fix-wifi-not-working-on-ubuntu/
|
| https://support.microsoft.com/en-in/help/10741/windows-
| fix-n...
| SlowRobotAhead wrote:
| Yea, " First determine the name of your WiFi interface by
| issuing the command : nmcli d "
|
| 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.
| stinos wrote:
| Some of them, very much. Go have a look in academia where
| there are hordes of tech-illiterates working on linux just
| because of reasons like some obscure piece of software
| working only properly on linux, because the postdoc did it
| that way, because it's cheaper, because they think it has
| to be done like that, ... Last lab I was in it was just
| painful to see how much time was completely lost on trying
| to get things working by people not understanding computers
| or OS. So if auto-update can alleviate some of those
| problems, why not. If it breaks things, well that's
| something else :)
| ashtonkem wrote:
| That's gotta be a tiny minority of Linux users.
| searchableguy wrote:
| Linux subsystem is there on windows. You don't have to
| use linux for majority of cases. Conda is pretty decent.
|
| 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.
| chrisandchris wrote:
| There's a simple reason: speed. Have you ever tried to
| use WSL 1 with npm? I doubt do, because it just takes 10
| times more time than on ,,real" linux.
|
| 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.
| searchableguy wrote:
| I have. It wasn't called wsl but bash on windows back
| then. You had to disable bunch of services related to
| scanning files (windows defender?) to make it barely
| usable but since v2, they are using a lightweight vm so
| the speeds are significantly better compared to what you
| got on bash on windows or wsl 1.
|
| 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.
| jen20 wrote:
| FWIW I tried Windows as a desktop two weeks ago, and gave
| up on it precisely _because_ the implementation of window
| snapping and positioning was so bad. I have a very wide
| monitor and need a way of splitting the screen into
| thirds, which Windows seems to lack.
| rostigerpudel wrote:
| You might try the PowerToys. With FancyZones you can
| either use one of the presets or freely define your
| window snap zones:
|
| > https://github.com/microsoft/PowerToys
| banger180 wrote:
| There are many kinds of linux users, just like there are
| many kinds of windows users.
| OrgNet wrote:
| If you want to disable updates, it should not still be
| updating... I don't get your point....
| OrgNet wrote:
| Not sure whats the point of using snaps in a stable OS release,
| but they are fairly easy to remove: https://www.kevin-
| custer.com/blog/disabling-snaps-in-ubuntu-...
|
| 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?
| williesleg wrote:
| Yeah, ditched Ubuntu for Debian Testing. Had enough.
| bluedino wrote:
| I'm a fan of Docker on the server so the idea of Snaps is great.
| Linux packaging is a pain, and one of the reasons distros exist.
|
| However, the implementation stinks right now. This isn't to say
| they won't get it right in a year or two.
| Priem19 wrote:
| So that's why two applications suddenly couldn't install anymore.
| Aw man, I've been so happy with Xubuntu the last couple of years,
| I really don't want to have to find another distro.
| beckler wrote:
| We tried to make an internal IoT device using Ubuntu Core and
| snaps because the capabilities of it were very promising. We
| started a PoC and about halfway through we hit a major roadblock.
| Our enterprise network does certificate substitution, and Ubuntu
| Core absolutely does not allow you to install your own
| certificates globally, so our devices would never receive
| updates. We tried EVERY hack we could think up, short of making
| our own core snap. We talked to Canonical about it, and they
| didn't seem interested in our fixing our complaints without a
| massive amount of money, so our PoC died, and we dropped Ubuntu
| entirely because of it.
| lucb1e wrote:
| > We tried EVERY hack we could think up
|
| 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.
| comboy wrote:
| What did you end up using?
| beckler wrote:
| We ultimately used a custom yocto image.
| eikenberry wrote:
| > [..] didn't seem interested in our fixing our complaints
| without a massive amount of money [..]
|
| Why is asking for money wrong? You want the feature, why
| shouldn't you pay for it.
| GordonS wrote:
| A colleague of mine was also looking at Ubuntu Core for an IoT
| project recently, but Ubuntu wanted $15k/y to run a private,
| branded Snap store - erm.. no.
|
| 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.
| beckler wrote:
| Wow, it's gone up! When we talked, it was $10k/year, and then
| there was an additional cost for every update we pushed out.
| It depended on the speed, size and number of devices
| receiving the update.
| GordonS wrote:
| Yes, forgot to mention they also charge for updates!
| Pricing page[0]
|
| [0] https://ubuntu.com/pricing/devices
| eikenberry wrote:
| Isn't there some old adage about how if you can't afford
| something you aren't the target audience. At the larger
| companies I've worked at you didn't even need approval for
| 15k/y.
| GordonS wrote:
| This was for a company with just under 300k employees - you
| need approval from multiple people for _everything_.
|
| 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!
| adrianN wrote:
| Sounds like a solid decision from Canonical tbh. Certificate
| substitution is terrible.
| beckler wrote:
| Not gonna disagree at all, but I don't see any widespread
| adoption from enterprises because of it. It's disappointing
| because Ubuntu Core is actually quite secure, and we were
| really impressed with it... we just couldn't use it.
| Spooky23 wrote:
| For a consumer, sure. In a business setting, it seems
| irresponsible to be to allow every random server to have an
| un-inspectable VPN.
| lukeschlather wrote:
| It seems irresponsible to inject devices into your network
| that that indiscriminately MITM all traffic and can easily
| be configured to log passwords and auth cookies, no matter
| what setting you're in.
| bdamm wrote:
| It's basically the TSA of corporate networks. They need
| to inspect traffic _because_ they can 't control what
| devices show up in their environments and what malware
| might ride along side legitimate traffic.
| lucb1e wrote:
| Plus which, it allows me to check what black box software
| is doing. Certificate pinning is great and all, but it
| also makes it way harder to know what data "huawei mobile
| services", "google play services", or a random mobile
| game for that matter, is phoning home about.
|
| 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.
| compuguy wrote:
| Actually most of these corporations have plenty of
| controls on their networks preventing the random plugging
| in of devices into networks. Most of the time they are
| using something that involves 802.1X.
| compuguy wrote:
| You and I agree. Unfortunately most large corporations,
| and US Government agencies like to be able to see and
| inspect network traffic. Mostly to prevent the theft of
| confidential data. The fact that the MITM proxies hoover
| up passwords and auth cookies still bothers me quite a
| bit.
| Spooky23 wrote:
| You transmit passwords from servers to internet
| destinations?
|
| That would be a pretty serious security incident from my
| POV.
| GekkePrutser wrote:
| Yep I couldn't imagine our Fortune 500 company ever
| allowing access without it.
| kanox wrote:
| MITM should be completely illegal.
|
| Why does this even need to be stated?
| [deleted]
| ccmcarey wrote:
| Seriously, you can think of no reasons?
|
| Many competent companies MITM employee traffic to scan for
| malware, leaking confidential data, etc.
| kazinator wrote:
| Grandparent comment by _beckler_ says they were trying to
| make some IoT product. That will be deployed in situations
| where that happens; if your customer has a MITM set up, you
| just nod your head and sell them something that works in
| that setup. You can 't say, "MITM should be illegal, please
| buy my non-auto-updating solution anyway and stop it with
| your MITM."
|
| 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.
| cortesoft wrote:
| Should you not be able to MITM your own machines?
| kanox wrote:
| Only in dev environments. Not on machines used by
| employees.
| cortesoft wrote:
| That is different than "completely illegal".
| MPSimmons wrote:
| For some situations, it's called for, but it's a huge pain
| in the ass. I am in a similar situation, and I need to
| patch every docker image I use. It's terrible to deal with,
| as an engineer, but the information security team does
| catch and eliminate a lot of content-based attacks.
| compuguy wrote:
| I agree its a pain. It also makes things like working
| with other private certificate authorities (DoD Cert
| authority, other private certs) a pain. I spent a decent
| amount of time trying to get certain work/project related
| sites whitelisted from our MITM proxy because it didn't
| recognize the certificate chain...
| GekkePrutser wrote:
| In your own company you're free to do what you want.
|
| 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.
| kanox wrote:
| > In your own company you're free to do what you want.
|
| No, it's corporate MITM specifically which should be
| illegal.
| bdamm wrote:
| Why? Companies need to control what goes in and what goes
| out.
| pnako wrote:
| Yeah, I want traders to be able to communicate and trade
| freely away from the prying eyes of their... employer?
| hedora wrote:
| The last time I installed the Ubuntu, I noticed gnome calculator
| took over a second to start in a VM on a new >$2500 laptop.
|
| I switched to a .deb, and it was instantaneous. Then I switched
| back to devuan and have been happy since.
| m0xte wrote:
| A good time to ask I suppose: Is Devuan stable and does it
| carry security updates and package repositories equivalent to
| normal Debian? If so I'll probably switch myself.
| petre wrote:
| It largely uses debian packages, so it gets the same uodates.
| Only packages that require systemd are modified by the devuan
| maintainers to run w/o it.
| aritmo wrote:
| The calculator was a snap in Ubuntu 18.04 as an experiment.
| JonoBB wrote:
| Ah, this makes sense now! I've always wondered why the
| calculator (of all apps) was by far the slowest to start on
| 18.04 for me.
| MattPalmer1086 wrote:
| I was wondering why the calculator took so long to start on
| 18.04. I thought there was some problem with my system.
|
| 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.
| jandrese wrote:
| The good news is that 18 is one of the super-LTS releases,
| so you don't have to upgrade until 2028.
| jandrese wrote:
| Yeah, it's almost as bad as the calculator in Window 10. It's
| completely ridiculous for ANY calculator app to take that long
| to load on a modern PC.
| philliphaydon wrote:
| What's wrong with the windows one? It's instant and it
| calculates things?!?
| firmnoodle wrote:
| Yeah, I'm confused as well. I just tried Calc on win10 for
| the first time in weeks or months and it opened before I
| could count 2 seconds. This is from a SSD where it won't
| have been in cache.
| umvi wrote:
| IIRC it tries to connect to the internet in the background
| to download currency exchange rates
| CarVac wrote:
| It takes a couple seconds to start the first time you
| launch it. Very much not instant.
| lonelappde wrote:
| What about the second time?
| BenjiWiebe wrote:
| Then it's in cache.
| bgorman wrote:
| Ubuntu is doing more harm than good to desktop linux at this
| point in time.
|
| 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.
| hocuspocus wrote:
| If it's so bad, then why is it the most popular?
|
| 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.
| keymone wrote:
| which distros you think are better choice for laptop?
| abeyer wrote:
| Ubuntu tried shipping wayland on by default already and it was
| a clusterf* and made that release all but unusable. Wayland
| isn't ready for an LTS release yet.
| bgorman wrote:
| Wayland is the default display server for Red Hat Enterprise
| Linux 8. I have been running Wayland for the last 2 years and
| have never had any problems. (Admittedly I haven't used
| Nvidia)
| bboozzoo wrote:
| Can you share a single window in eg. Meet? Do alternative
| input methods work for accessibility?
|
| 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.
| rwmj wrote:
| Nothing about everything being statically linked into a big
| binary blob with very little connection to sources? It's my main
| problem with containers in general.
| bproven wrote:
| I know Snap maybe offered tighter sandboxing, but why didnt
| AppImage take off? It seems like it solves the problems of
| deb/rmp/etc war and is easy to create for app devs...
| e2le wrote:
| I much prefer AppImage, just recently I created one that
| packaged an old windows game and included the required
| dependencies (wine, libopenal, etc). Starting the AppImage is
| as simple as "./game.AppImage" and in theory would work on any
| Linux distribution. I think it has good potential for
| preservation of old applications and video games.
|
| AppImage is awesome.
| lmilcin wrote:
| Not sure what was the thinking. I am, as of this moment, in the
| process of migrating my laptop to from Ubuntu to Debian.
| risho wrote:
| It is worth noting you can basically get all of the benefit of
| using ubuntu(a good gnome experience, ppa's, etc) but without
| any of the snap stuff by installing pop os. It's a bit
| unfortunate that pop os is branded as something basically for
| scrubs and new linux users, because it is still fully featured
| and a great overall experience even for a more adept linux
| user.
| mastax wrote:
| > It's a bit unfortunate that pop os is branded as something
| basically for scrubs and new linux users
|
| 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".
| lmilcin wrote:
| I don't know Pop OS. On the other hand, I have been using
| Debian on my PC since 1999 and only got Ubuntu for my laptop
| because I had trouble getting everything to work properly and
| Ubuntu seemed to do the job.
| woofie11 wrote:
| Is there any sensible documentation on this somewhere?
|
| 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.
| josteink wrote:
| > It's odd, Windows and Linux switched spots in that time.
| Windows 10 is faster, more stable, and more understandable than
| 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?
| woofie11 wrote:
| I have three machine, one is Windows, one is Ubuntu, and one
| is Mac. The statement was relative. I never said Windows was
| _understandable_. I said _more_ understandable. Nineties-era
| Debian, I felt I understood every piece of, to where I could
| fill in details with documentation or code in a few minutes.
|
| 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.
| jlokier wrote:
| I've been using Ubuntu Server non-stop on a wide range of
| differently configured (real aka bare-metal as well as virtual)
| servers for over 10 years.
|
| 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.
| tkuraku wrote:
| I feel like snaps are trying to do too much. Applications are
| slow to start. Besides, I don't want the underlying system to be
| changing and updating all the time. For me the stability of
| RHEL/Centos with flatpak for desktop applications is perfect.
| vanviegen wrote:
| For largely this reason, I've just switched to Manjaro after over
| two decades (ouch!) of using Debian and Ubuntu. I'm very happy
| with it!
|
| 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!
| wayneftw wrote:
| Came here to say this. I've been on Manjaro at work and at home
| for 2 years now. It's the longest running Linux desktop distro
| I've ever maintained and it's precisely due to the excellent
| AUR repo system.
|
| 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.
| GekkePrutser wrote:
| 100% agree! I hate snaps and Ubuntu is overdoing it too much now.
|
| I've moved to Alpine for servers and Arch for desktop now.
| pkaye wrote:
| I tried snaps and I'm okay with them atleast for non-core apps.
| Like games and a few bigger programs I want isolated from the
| rest of the systems. But I wouldn't want my calculator or browser
| as part of snaps.
| Iolaum wrote:
| I moved from Ubuntu MATE to Fedora MATE for this reason. One
| reason I use free software is that I get to have the final say in
| what my computer does. There's a big thread at snapcraft forums
| asking for the ability to shut off updates. Canonical wouldn't
| bulge. So I ve moved elsewhere and thank the Linux ecosystem for
| allowing diversity so that I can still use it as I d like to.
| d_tr wrote:
| I do not have an informed opinion on the different aspects of
| snaps, because I haven't had to deal with them at all.
|
| 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...
| nromiun wrote:
| > Snap applications auto-update and that's fine if Ubuntu wants
| to keep systems secure. But it can't even be turned off manually.
|
| 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...
| ultrarunner wrote:
| We work at remote sites on cell connections. Part of the reason
| we moved to Ubuntu from Windows was the ability to control data
| usage, which is expensive. Automatic updates quickly become a
| significant slice of the bill when random decisions like these
| get pushed on users. Ubuntu was supposed to help prevent us
| from needing to chase this.
| aeyes wrote:
| Windows 10 has an out of the box feature to mark connections
| as metered which disables automatic updates.
| ultrarunner wrote:
| On Ethernet which ultimately has a cellular uplink?
| DanBC wrote:
| Yes, but this is something that needs to be set.
|
| https://support.microsoft.com/en-us/help/4028458/windows-
| met...
| wtallis wrote:
| > which disables automatic updates.
|
| Except for the ones Microsoft thinks are really important
| to push to you.
| zdragnar wrote:
| Really? I spent a year with that on (satellite for
| awhile, then 4g lye data) and never saw an update
| automatically go through.
| nromiun wrote:
| Exactly. It seems like these days everyone assumes you are on
| a stable broadband connection. In many parts of the world
| getting a fast and stable internet connection is literally
| impossible.
| zdragnar wrote:
| Windows lets you set your network connection as metered, and
| doing so prevents it from applying automatic updates.
|
| 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?
| AsyncAwait wrote:
| I think part of the problem is that many newish users
| equate Linux with Ubuntu, good and bad. There are many
| other options and Ubuntu should not be the default anymore.
| fgonzag wrote:
| pop_os should fit the bill. Based in ubuntu, with a better
| UI, and has flatpack support and added polish
| lucb1e wrote:
| I have a much, much better idea of what process is using
| network traffic or other resources on Linux than on Windows
| (I don't know how often tracing tools pointed fingers at the
| "system" process for weird magic like CPU or network usage).
| Unless you mean the 20.04 LTS thing specifically (it sounds
| like you had this issue for longer), it should be exceedingly
| easy to turn off anything that runs automatically.
| tannhaeuser wrote:
| +1 Insightful.
|
| > _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 :)
| lucb1e wrote:
| The browser is actually the number one component you _should_
| update as soon as a security fix comes out. If you don 't
| want new features ("more free stuff!"), use an LTS version
| that only includes the security updates?
| Izkata wrote:
| That... doesn't make sense. Chrome and Firefox (and possibly
| Chromium, I'm uncertain there) already can update out-of-band
| of apt/etc.
| eloisant wrote:
| The idea is that the vendor can take care of the updates
| without having to go through all the package management
| system of all distributions
| curt15 wrote:
| When you install Google Chrome for a deb, it's already
| set to update through Google's own apt repository.
| Presumably Firefox could do the same.
| Izkata wrote:
| > Presumably Firefox could do the same.
|
| 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.
| limeblack wrote:
| > But it can't even be turned off manually.
|
| 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.
| peterwwillis wrote:
| Yeah, lol, looks like I'm no longer an Ubuntu user. Now I have
| to figure out how to force-disable this for server software and
| corporate Linux desktop users. Jesus.
| neetfreek wrote:
| Point taken on the shoddy behaviour, but if you'd like to try
| it out there's this helpful post on disabling snap[1] shared
| here[2] when I installed 20.04. Quick and painless!
|
| 1. https://www.kevin-custer.com/blog/disabling-snaps-in-
| ubuntu-...
|
| 2. https://news.ycombinator.com/item?id=22972661
|
| *Edited
| m-p-3 wrote:
| At that point I'll just use Debian.
| littlestymaar wrote:
| Debian used not to work easily on hardware that require
| proprietary drivers, did it change recently ?
|
| 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 :/
| Firehawke wrote:
| If you have proprietary drivers, you'll need to prepare a
| USB stick with them downloaded onto it. They won't be on
| the installer image.
|
| On my older 2011-era laptop, that's the wifi and wired
| network that need those drivers. It's a bit of a pain.
| pnako wrote:
| Generally it's not the drivers but the firmware for those
| devices, i.e. code that runs inside the device.
|
| 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.
| Nursie wrote:
| Nvidia has been easy on debian for quite some time now,
| are there other proprietary drivers that are important?
| neetfreek wrote:
| It's dawning on me that it's likely to only become more of
| a pain with each iteration of upgrades (e.g. install
| tweaks, synaptic, remove apport... And now remove snaps).
|
| Time to check out Debian!
|
| *Edited. I can't type on phones.
| Izkata wrote:
| Other threads have suggested various relatively-new
| distros as alternatives when stuff like this keeps coming
| up with Ubuntu. The two I have in mind to check out at
| some point in the future are Pop!_OS and Void Linux.
|
| 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).
| michaelmrose wrote:
| While this is indeed helpful why do I want a version of Linux
| that has to be decrapified like Windows immediately after
| install and may with a future update may need to be fixed
| again. If you use non LTS you will have to "fix" it every 6
| months.
| dima55 wrote:
| snaps are intended for non-power-users that don't want to deal
| with dependencies. Those users want things to mostly work
| without worrying about murky downsides. Auto-updating is
| exactly the right behavior.
|
| If this is of concern to you, why are you using snaps? And why
| Ubuntu? What's the value-add over Debian?
| michaelmrose wrote:
| You have misjudged who actually uses Linux. This setting
| would be ideal for all the billions of people Canonical
| wishes used Ubuntu.
| dima55 wrote:
| Yes... Isn't that what I said?
| jplayer01 wrote:
| The concern is that there's no simple way to disable auto-
| updates. If you want Ubuntu to turn into Windows, why not
| just use Windows?
| DoofusOfDeath wrote:
| I agree entirely. Unavoidable updates were one of the key
| factors in my choice to avoid Windows 10 for business-critical
| computing. I standardized on Ubuntu instead, but this could be
| a deal-breaker for me.
|
| I hope Canonical fixes this immediately. I'm not eager to spend
| time re-researching to market for a suitable OS.
| walkingolof wrote:
| Just disable snapd after you have achieved your ideal
| configuration. But yes, this should be a setting somewhere...
| DoofusOfDeath wrote:
| Thanks, that's helpful.
|
| 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.
| Iolaum wrote:
| The problem with that is you are fighting the platform.
| That's not a great place to be. Unless your disagreement
| with the platform's design is small enough you are likely
| to be better choosing a more appropriate platform.
| techntoke wrote:
| Just switch to Windows if you think that Ubuntu is your only
| choice for Linux desktop, and you're unhappy with it.
| petre wrote:
| We have already installed two new Debian 10.3 VMs instead if
| Ubuntu. It's quite a breath of fresh air compared to Ubuntu
| >16.04 which I had to fight all the time to do things my way.
| Still runnng 18.04 on the dev boxes though.
| ironmagma wrote:
| There are people working on Ubuntu with tons of dubious ideas.
| I wouldn't be surprised if this was the one that sealed its
| doom.
| Firehawke wrote:
| I wonder how this affects offshoot distros like kubuntu?
|
| 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.
| emilsedgh wrote:
| Give KDE Neon a try. It's based on latest Ubuntu LTS with up
| to date KDE. But it doesn't do everything like Ubuntu (like
| forcing snaps).
| konart wrote:
| >This is the exact reason I use Linux instead of Windows 10 or
| macOS
|
| 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)
| nromiun wrote:
| This is from another user in this thread:
|
| > 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?
| stephenr wrote:
| You can turn off auto updates of macOS and Mac App Store
| apps completely, yes.
|
| 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?
| koheripbal wrote:
| ...dumb question: Does this apply to Ubuntu Server as well???
|
| Because if so, I'm sticking with 18.04.
| geek_at wrote:
| only if you install your server applications using snap
| nromiun wrote:
| I was using the regular version for remote desktop VMs. I
| don't know about the server version.
| input_sh wrote:
| If you're running Ubuntu's server, odds are that you're SSH-
| ing into the box instead of running graphical interface.
| Unless you specifically install snaps, I don't see how this
| would affect you.
| koheripbal wrote:
| Perfect. So I guess that means APT is still the same,
| correct?
| pnako wrote:
| Yeah apt is still fine and I've never seen it update
| anything behind my back.
| znpy wrote:
| You might want to consider jumping ship and go into the
| RHEL/CentOS world.
|
| Stability and predictability is their main strenght. Each
| release is supported for a veeeeery long time.
| eikenberry wrote:
| Stability and predictability of the core OS. But then
| everyone uses EPEL for everything else which throws that
| all out the window.
| [deleted]
| _xerxes_ wrote:
| My issue is that they still have not sorted out suspend and
| resume. Half the time when I reopen my laptop lid my keyboard no
| longer works. Had the same issue on 18.04.
| karmakaze wrote:
| I don't use Software Center so the only thing I should be
| concerned about is getting the snap flavor of Chrome instead of
| the .deb. My main browser is Firefox anyway.
|
| 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.
| gertrunde wrote:
| And for some reason the server installer doesn't set up any kind
| of swap at all. And forces snaps and lxd on you, which also
| brings in lovely things like cloud-init... You spend 10-15
| minutes cleaning up a supposedly minimal install.
| tom_devref wrote:
| I really dislike the way snaps create disk partitions. When I run
| $ df I want to see what I defined during OS installation, not a
| dozen nasty snap mounts. An application misusing fundamental
| system features like this feels like a violation of some UNIX
| principle.
| pelario wrote:
| I cannot agree more and I'm actually surprised that I haven't
| heard this complaint more often/loudly. Perhaps there is
| something we are missing ?
| mrweasel wrote:
| Very much agreed, the fact that nobody at Ubuntu noticed that
| the extra mount points is a best annoying is kinda impressive.
|
| 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.
| tom_devref wrote:
| I don't use Ubuntu on servers but I imagine snaps would cause
| monitors like Munin and Logwatch to freak out.
| jlgaddis wrote:
| FWIW, you can pass the "-t" parameter to "df" to limit the
| output to specific filesystem types (e.g., "ext4", "xfs",
| etc.).
| veesahni wrote:
| Anybody have commentary on how this snap stuff impacts those who
| use Ubuntu on their EC2 nodes?
|
| So far I see complaints about Chromium, which typically doesn't
| exist in a server environment.
| McGlockenshire wrote:
| Why did you choose to use Ubuntu on a server instead of Debian?
| rohan1024 wrote:
| Not the best way to disable this but it works. My /etc/hosts:
|
| 127.0.0.1 api.snapcraft.io
| shock wrote:
| I am very diligent about applying updates as soon as I'm able and
| generally read the changelogs of the updates I'm applying in
| Ubuntu's Software Updater.
|
| 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!
| qidydl wrote:
| I'm surprised that something like routing software is/was being
| distributed via snap instead of as a Docker container; snap
| seems much more targeted towards end-user workstations than to
| servers.
| [deleted]
| donmcronald wrote:
| If they make it automatic and unmanageable by default, they can
| sell those features back to us tomorrow as an enterprise
| edition or a private Snap store.
|
| 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.
| shock wrote:
| > If they make it automatic and unmanageable by default, they
| can sell those features back to us tomorrow as an enterprise
| edition or a private Snap store.
|
| I'm not sure whether you're being ironic, but they're doing
| just that.
| jmgpeeters wrote:
| Oh god. What a shame. Another distro down the drain.
| securityfreak wrote:
| Ubuntu 20.04 forced me to switch to Fedora Server on my home
| server. Pretty happy so far. I have significantly fresher package
| versions and most of the software tools I use offer a RPM
| package. I think I will wait for snap to mature, before giving it
| another go.
| lifeAsNerd wrote:
| I don't understand. You stopped using Ubuntu server because of
| snap?
|
| Can you clarify?
| jablan wrote:
| they didn't say it was ubuntu server, it might just as well
| be ubuntu desktop, and used as a home server (i.e. a box used
| mostly for server software, but no necessarily without
| desktop environment).
| Stierlitz wrote:
| There was nothing wrong with Synaptic + Deb files that needed
| fixing. Same with Systemd and now they're going after our home
| directories (never mind that it breaks SSH). My home directory is
| already portable as in all my config information is in .dot
| files. As for snap, yet again a solution in search of a problem.
| you can download a nightly-build as a compressed archive and run
| it without installing. I too will be moving with my next
| installation. any recommendations for a small fast distro where
| the GUI doesn't get in your way?
| dirtydroog wrote:
| Is this an issue if we upgrade to 20.04 on our GCP machines? Is
| all this nonsense there for server releases?
___________________________________________________________________
(page generated 2020-05-02 23:00 UTC)