I wouldn't want it to be a very common solution really because it's not that efficient and means you get updates for security when that vendor feels like it.

I'm happiest with MOST software being in the distribution.

Anyhow I know there are lots of ways to look down on Arch/Pacman (Artix in my case - dinit instead of systemd) but I have to say that it is simply much more enjoyable to use than Ubuntu or Fedora or even Debian IMO. Perhaps one day some terrible thing will happen to make me regret it but I just cannot imagine going back to the horrible burdens of those distros - upgrading from one version to another (especially on Fedora - groan), selinux, snap Firefox etc

I was outspoken in my interview about snaps. Of course this is the path to success in a monoculture.

It does! It'd be even simpler and more consistent if they dropped snaps and only used debs!

There we are.

A shame, since ubuntu got me into linux desktop back then, but in the end they keep screwing things up needlessly.

It's not some tinfoil stuff. Community oriented or driven (entirely community driven like Arch) always listens to the community. This snap and flatpaks wouldn't happen in the first place.

Use Linux Mint if you don't have time to initially set it up. Else use Arch Linux if you have initial time and patience to read. Arch is not scary like community is bad. There is a wall of text and it is intimidating. It needs time like a couple of days when you do it for the first time. But it is just about RTFM.

Flatpak and Snap are unneccessary abstractions which adds a hell a lot of bloat and for what? To make a point release distro work similar to rolling release. Nothing else. So just use a rolling release distribution like Arch or OpenSuse Tumbleweed (which I haven't used but have been hearing good things. Especially since last week here in HN).

But but, point release is bleeding edge and unstable!

NO! They are stable versions of packages and not development streams.

We seriously need to clear this confusion between a Linux distro's stable, testing, unstable repos and upstream's development branches. These two things are completely different.

When you say for eg; Firefox v222222.1 with a serious security patch is in testing branch for your distro, it means it is not tested with YOUR distro which did some hacks to make it work cos it is a point release and froze your package for a point release. *AND NOT BECAUSE OF THE UPSTREAM DEVELOPMENT BRANCH HAS BUG.* Majority of the time, it is fixed already in upstream. And even if it is a bug which is new, your package needs to be an important one. Otherwise you will have to wait till your next point release update or version bump before receiving the update. This backporting and picky patching on point releases is creating a huge amount of unneccessary overhead on upstream because hacks/patching differ on each distro.

Use any rolling release, Arch, Open Suse Tumbleweed, PCOSLinux, Void or a point release which uses unstable/testing branches (which ever is closest to upstream) like Debian unstable (Or whatever is being the distro's repo which is closest to upstream stable versions) which is essentially closer to upstream.

These are for desktop users. AND NOT SERVERS. FYI.

Here's Mark Shuttleworth in 2010:

The next major transition for Unity will be to deliver it on Wayland, the OpenGL-based display management system.

We came to the conclusion that any such effort would only create a hard split in the world which wasn’t worth the cost of having done it. There are issues with Wayland, but they seem to be solvable, we’d rather be part of solving them than chasing a better alternative. So Wayland it is.

https://www.markshuttleworth.com/archives/551

Then in 2013, Unity 8 was released with Mir.

Snap was largely developed in parallel with FlatPak (called xdg-app initially).

There was a talk about the plans at GUADEC 2013:

https://www.superlectures.com/guadec2013/sandboxed-applicati...

> When will these system designers realize that the system shouldn't do anything observable without me telling it to?

My vehicle changes gears without asking me. If someone makes a broad statement like "when are these vehicle designers going to realize that a vehicle shouldn't do anything observable without me telling it to?" I'm just going to laugh at them.

https://conveyor.hydraulic.dev/7.2/outputs/#linux

It works by downloading the Ubuntu package index and using it to look up ELF dependencies, devs can also extend the inferred list with other package names if they like. The deb installs an apt sources file and public key so users can stay entirely in the GUI. The control scripts are auto-generated but can have extra code appended to them via the config file if the developer so wishes.

It works pretty well. Conveyor is used primarily for cross-platform apps that use {Electron, JVM, Flutter, C++/Rust} and those don't normally have very complex Linux specific dependencies. Also, in practice Ubuntu and Debian and its various forks are close enough that package metadata is compatible in basically all cases.

People do ask us for Flatpak sometimes. Probably RPM is a higher priority though. Those two get most Linux users, they're stable, there are portable libraries that can make them and they can package anything without code changes. Flatpak requires mastering a new file format and the mandatory sandboxing is guaranteed to cause problems that will end up in the support queue of the deployment tool.

Care to expand on this? I'm not in Ubuntu-land but can't imagine how a service with an open protocol and multiple clients forces you onto Snap.

The Firefox deb (such as in 20.04) became unusable and tabs crashed when the deb was updated without a restart.

It's really down to each individual app as to whether it will work being updated in the background or not.

AIUI the new snap implementation gets everything ready in the background, so the update on closing it and re-opening it is quick.

This is one of the points they are missing with snaps and flatpaks.

These formats might be OK for desktops, but are absolutely awful for servers, containers, etc., which, incidentally, are where Linux dominates.

Do I want to spend my time worrying about setting up a package cache, because a handful of updates are costing me a small fortune in transfers? Why would I need to think about what snap is doing in my small instance with a 16GB volume, when I use it to run a certainly small application?

Snaps are an absolute nightmare in these scenarios.

1) a unified database for package names (it's all unnecessarily ad-hoc right now, with different distros having different policies for capital letters, whether libraries are prefixed with "lib", whether python packages have "py" or "python" or "py3" etc...

2) a standard format for declaratively describing how to build a package.

Basically, we have FreeBSD ports, Arch PKGBUILDs, Void templates, Gentoo ebuilds - they all do more or less the same thing in the same way, they all work really well, and they're all incompatible for sheerly incidental reasons. I'd like to see these incompatibilities papered over in such a way that I can write one template and generate all the others.

..wait a minute

> (2) We use a UPnP library called miniupnp in the current version. We have to statically link it because of issues like (1) and also because some distros were for a time stuck on a version that had security bugs that they would not upgrade because it would break other packages.

Wouldn't this solve the same problem without adding snap/etc?

- Gnome

- KDE

- Xfce

- Cinnamon

- Mate

- LXDE/LXQt

- Several *box stacked and assorted tiling window managers and assorted glue scripts

That's a fairly solid base of "support" even if the distributions don't provide live CDs with any particular setup preinstalled.

The only exception I've seen are the "we took an existing distro, threw away half the repository, patched 2 packages and slapped our own logo on top" wannabe hipster distributions that last an entire two years before folding due to being pointless.

It's as simple as

     apt-get install $DE

You can disable auto-updates with eg. "snap refresh --hold firefox". See: https://snapcraft.io/docs/keeping-snaps-up-to-date#heading--...

Though not taking security updates for Firefox seems like a very dangerous thing to do.

For my own sanity I began avoiding Canonical's software years ago, but to me they always built stuff with shiny UI that demoed well but with performance seemingly a distant afterthought. Their software aspirations always seemed much larger than the engineering resources/chops/time they were willing to invest.

I think you're right that Canonical creates and releases projects and assumes they are in charge of them, but I disagree about Red Hat (honestly not sure what you mean by "rough ideas and code"), I think they tend to see whats already out there and then throw their weight behind that, then only if there isn't do they create their own and even then they are more open about how the project runs. That difference means Red Hat gets more momentum behind its projects, and that is what counts. (of course RH can throw more engineers at stuff as well, and that also helps a lot)

Its not some sort of conspiracy, nothing Canonical has ever done has had the same amount of hate as systemd has, its just a difference in approach.

Or rather because they're proprietary, often closed-source, like Snap server.

When there's a package manager / runtime that does both then I'm extremely interested.

That means you need three builds to cover Ubuntu and its derivatives (20.04, 22.04, 22.10). Two to cover Debian (10 and 11). Three to cover RHEL (7,8,9) and also a few more if you want to support Fedora. If you want to support multiple architectures you get at least twice as much builds.

No matter how you put it, that's a lot more work than maintaining a simple flatpak manifest, which allows you to target all those platforms with one automated build for each architecture. And you also get the benefit of being placed in the app store and not being hold back by whatever API is the lowest-common-denominator between all those platforms or having to clutter your code base with `ifdef`s; if you want your app to use an API which was only added in GLib 2.74, then you can just do that and it'll work.

The system package manager is convenient when it works, because it's already there. But that's about it. Using it to install any random apps is a recipe for disaster, it leads to fragmentation since everyone on a different distro uses different commands/workarounds to fuck up their systems in different ways when trying to install poorly packaged software.

If everyone just used Debian, we wouldn't need Flatpak, but obviously that's not the case. Whenever you find a "linux app" that's packaged for distroA, but you're on distroB, there's a chance that it will work. That is 100% luck and coincidence, because most linux distros just so happen to ship the same family of system software/libs, sometimes even with the same versions.

Rather than leave it up to the undefined behavior lottery, a standardized non-system packaging format can guarantee that things will work across any distro. That's better for everyone involved: users, sysadmins, distro maintainers, and developers. Whether Flatpak is that format idk, but IMO it's the best overall out of the three main contenders (Flatpak, Snap, AppImage)

I don’t think building MSI installers is especially difficult; it’s kind of a set-it-and-forget-it thing. Configure Wix or Inno Setup once and then you’re good to go (on every Windows machine, no need to worry about multiple distros).

But during this time they regularly update packages. My kernel is always the latest version.

But I trust it because Fedora has a massive testing automated update and testing system. Every package is thoroughly tested for regressions and other things. https://bodhi.fedoraproject.org/ to look for yourself.

It is also integrated into their bug and other systems so it's a very well oiled machine.

It's been rock solid stable for me and I've been running it since 35. And upgrades are super easy.

There is also COPR which is their AUR/PPA hybrid system that lets them provide a way for users to setup their own repos but build using Fedoras learnings and systems. It's pretty cool.

Also with `dnf` RPMs are as easy as DEBs. And some of the commands are similar.

I find dnf is even smarter and better at managing dependencies.

I only ever run 2-3 commands. `dnd install` `dnf update` and `dnf remove`. Update handles the repo refresh and actually updating packages. And force refreshing repos you just add `--refresh` to the command. Otherwise it does it every few hours on its own (the refreshing of repos, not installing updates)

Fedora is a breath of fresh air after decades of Ubuntu, and then Manjaro. I wouldnt go back and I have used Ubuntu since 5.04 til 22.04

There are better packages/attempts at handling it, but I still find myself switching it to an LTS kernel if I have Nvidia or ZFS involved.

It's useful for things I can't manage otherwise. Though I'll admit I'm in an incredibly small niche -- I maintain RPMs on COPR for fun... and at work.

I part with an anecdote! We weren't too careful on some Ubuntu systems and ended up with critical networking services in Snap.

The saving grace was: these systems are completely offline, so it couldn't sneak in updates. Note: this usually shouldn't be a big worry, but we have some debt

Not saying you're wrong, but this is surprising to me, and not my own reaction as a full-time Linux user.

Immediately formatted and switched to pop OS and I've never been happier.

If you wanted to run a 2 year old version of SomeApplication, that would work just fine. Is that what you really want? Is that what most users want?

If you instead install a snap/flatpack of the latest version of SomeApplication, you are installing also new libraries instead of the good old stable libraries your distro provides. So what's the point then?

IOW, if RH wanted to "join in", there was a cheaper path forward.

I'm on Ubuntu for now because Snaps can be disabled but it does make me wonder since they also dumped Unity Desktop a few years back. It almost seems like they don't care about Linux Desktop users any more.

I’ve switched all my laptops and workstations from Ubuntu to Arch.

There are rough edges here too, but on overall I’m much happier. I feel like I know how my machine works again. Ubuntu lately has been giving me that windowsy feeling with lots of things running for god knows what reason.

Also in arch the repos seems to not only contain more current versions of things. They seem to bundle more things altogether.

You can use any container registry (including self hosted) with docker and it will work. Last I checked, you cannot use any other repo at all with snap without recompling it to add support for your snap repo.

On a bit older desktop I have seen it take 5-10 seconds just to start Chromium. And not the initial start after fresh install, it happens every single time. Meanwhile Flatpak or local packages start instantly on the same machine.

I try to give the new release about a month to bake

    $ sudo aptitude install wine-stable

    62)     wine32:i386 [Not Installed]

    Leave the following dependencies unresolved:
    65)     wine64 recommends wine32 (= 3.0-1ubuntu1)

    Accept this solution? [Y/n/q/?] 

Canonical has quite a history of the behavior you're dinging Red Hat for: Mir, Unity, LXD, Juju/Charms, Launchpad, and I'm sure I'm forgetting several.

Also it’s Orwellianly named “Harmony” effort to popularize CLAs because Canonical has long sought to control upstream technologies - and consistently failed because they do not play well with others.

Read this thread:

https://web.archive.org/web/20140928104327/https://plus.goog...

Here, Upstart author and former Canonical employee Scott James Remnant wrote:

Had the CLA not been in place, the result of the LF Collab discussions would have almost certainly been contributions of patches from +Kay Sievers and Lennart (after all, we'd all worked together on things like udev, and got along) that would have fixed all those design issues, etc.

But the CLA prevented them from doing that (I won't sign the CLA myself, which is one reason I don't contribute since leaving Canonical - so I hold no grudges here), so history happened differently. After our April 2010 meeting, Lennart went away and wrote systemd, which was released in July 2010 if memory serves.

I avoid it because I find it hard to use and hard-or-impossible to configure adequately. It takes a "my way or the highway" approach. If you like how it does things, it's great. If you don't, you're better off using a different DE, which is what I do.

I’ve tried adding desktop environments to a pop installation, but I really don’t like having all of the apps included with other desktop environments cluttering the taskbar menu and the like.

Flatpaks/Snaps are almost exactly the same, conceptually, as apps on MacOS. Go look inside something in /Applications/... The .app is a folder, with all of its deps.

> Linux distros have a history of abandoning useful, well-understood technology for fads that then cause power users all kinds of headaches later-on (e.g. by cluttering output of useful tools like mount). Eventually, power users just lose the will to adapt, and move on.

"Power users" have a history of complaining about distro maintainers abandoning useful, well-understood techology because the "power users" don't actually understand the technology, nor do the understand the enormous headaches it causes distro maintainers to put a sane face on 30 year old design philosophies and continue moving forward.

The goal of distro maintainers is to STOP investing endless man hours in trying to make X work with high DPI displays, scaling, high refresh rates, a fundamentally insecure design model, and so on. The goal of systemd is/was for distro maintainers to STOP wasting endless man hours on edge cases because sysvinit didn't have reasonable mechanisms for "if anything in this dependency chain is restarted or changed, re-evaluate it" or "don't try to start this service if the mount isn't available so systems stop hanging on startup if some NFS server isn't available" or whatever.

> In the time of Jenkins et al the burden of creating bistro-specific packages is negligible.

Under the assumption that they are ABI stable, which is a bad one. Otherwise, it's the same old kaleidoscope of mapping out whether it's `libfoo-dev`, `libfoo-devel` for build requirements, whether it's a distro with a completely different naming system, dissecting the ELF header or reversing depchains in Python/Node/whatever to try to find deps and what THOSE are named in some distro, or whether they're even packaged at all, then building for every possible supported version of RHEL, Debian, Ubuntu, Fedora, SuSE, and down the line.

This is why "power users" aren't an important user model. Arch, Gentoo, Nix, and others exist if you want to be a "power user". Otherwise, extremely naive assumptions about the amount of effort expended by distro/package maintainers hand-wave the complexity away with "duh, just put it in Jenkins."

Flatpak/Snap are essentially a re-invention of putting things in /opt and using LD_LIBRARY_PATH or chrooting. Disk space is much less of a concern than it was before, and sacrificing a little space to AVOID the mess of shit above is a good investment.

Next server though. Not Ubuntu for sure. Probably Debian?

You can replace pipewire with pulseaudio. It's doable, just not trivial enough for an HN comment. In general, you'd have to force removal of pipewire without removing all dependent packages, install pulseaudio and then have apt check that all dependencies are ok. Then, having Pulseaudio in the system, you can install paprefs, a Pulseaudio application.

As I said, it's a solid system, rather impossible to break into an unrecoverable state.

Would I rather have the deb package be up-to-date? Sure. But when I've used distributions that try to stick closer to the bleeding edge everywhere, I've had bad experiences with stuff breaking. This lets me keep a stable, well-tested distribution for everything except for the one package I want to be newer.

I can't compare to Flatpak or AppImage because I've never used them.

I really wonder how i can have such a different experience to theirs apart from really esoteric parts/apps. Not saying it's not happening.

While i'd prefer just using apt, they let me work without being a pain so i don't really care.

Is there another option for that than Snap, or Docker which is a bit too complicated to set up? (that’s not rhetorical, I would like to know if there is)

I think the argument over flat pack versus snaps may expressed in technological terms but in reality, it's just your damn ego. Let it go, it's really not worth arguing over. Use what solves your work problem and then go have a life away from computers.

https://news.ycombinator.com/item?id=34505239

Anyway I’m not about to engage the systemd evangelization task force, thanks. Good luck elsewhere.

I have an Arch Linux desktop (KDE + AMD), I update it every few days, and it's always fine.

I also have a shell VM that runs IRC etc that often isn't updated in months, and I run `pacman -Syyu` and everything works fine.

I've never had the infamous 'Arch updates are unreliable' issue. Is it certain packages that are more prone to it, or something?

If this was a little hobbiest distro, I'd agree with you, but this is one of the most popular distros out there. There is a certain expectation of competency and quality.

I would argue that shipping the master branch of a bootloader isn't competent when there are stable releases available, and not addressing the issue when literally thousands of users are having the problem isn't very respectful of your userbase.

FWIW, I did eventually fix it, but the endeavour os folks were much more understanding and helpful with the issue. The arrogance I saw on r/arch was insane and offputting.

> Those are all upstream bugs, not Arch's.

IIRC the grub issue was in the update script, so it may have been an Arch bug rather than an upstream bug?

Still, it would also be nice if a package is known to be broken due to an upstream bug it would get rolled back, so once the breakage is known, no one else will update into a broken state. That would save some time over each person individually updating to a broken state, debugging for a bit and then downgrading the broken package and then also paying attention not to reupdate it each time they update the system until the problem is resolved.

But again, not trying to complain or assign blame, I was just responding to a question in a parent comment.

The old model works for established software, but breaks down a little now that it becomes easier to write software applications.

Personally I use my distro packages for foundational stuff (DE, systemd, tools and utilities) but I use an alternative package manager (flatpak) for most other applications.

What Flatpak, Snap and AppImage try to achieve is to limit the packaging burden for both distro maintainers and application developers, so that end-user applications can become immediately available on a wide variety of distros.

Quite a few maintaining teams are the exact same people in Debian and Ubuntu.

I use a 3rd party repo for ZFS drivers, which gets checked for compatibility with each new kernel release by the maintainers, so ZFS frequently stops me from upgrading, and crucially it stops me after I've already fetched the new package databases.

Running pacman -Sy and then installing an individual package isn't supported and it's understandable why.

Running pacman -Syu and having it break sticks you into this limbo where if you install anything before finishing the upgrade, you risk shooting yourself in the foot.

For software that they can't do this with, or that isn't worth their time, they just omit it from the package manager.

It's probably one of the most solid Linux distros at the moment and their website makes it seem.. boring.. No screenshots, features, mentions of whats available (like apps), that Fedora uses newer graphics/drivers kernels, that you can run Steam, that apps are sandboxed etc.

Stark contrast to something like https://vanillaos.org/

Right now e.g. there's openssl (still at version 3.0.x, because nobody supports 3.1.x yet) and openssl-1.1 (1.1.x-y) to handle the rather slow migration of upstreams to the new major release.

And to a degree, the line is blurry with Windows as well, what with how deep MSVC/win32 is integrated into the system. .NET took decades to dis-entangle itself from Windows and become a proper standalone platform, and Microsoft's attempts at getting people to use UWP instead of win32 is ongoing and not very successful so far.

Interesting. It never occurred to me that there's a blurry line between the two. It seems to me that there's a very hard line between the two. I'm not sure I understand what you're saying here.

> For example, installing a C# or Go compiler on Linux is great with a package manager. But doing the same with a C or Python is different?

I'm confused by this question, so forgive me if this answer isn't really addressing it. A package manager is a convenience, nothing more. Using one means makes your life easier in a number of ways. But not using one isn't really that much more difficult. Package managers are 100% optional.

If a package is not in the repo? Sorry, you have to compile from source. Want a newer version? Compile from source and hope that the build environment dependencies are in the repo. Want an older version for some reason? Break out docker or KVM so you don't break your system.

None of this is fundamental to the model, that much is true, but in practice it is how all Linux distributions using a package manager/repo model without things like Snap, AppImage, and Flatpak work.

Here's the best part though: Even with Flatpaks and AppImage you can still use a repo! In fact Fedora Silverblue, which uses an immutable base system and installs everything through Flatpak and Toolbox, uses a Fedora controlled Flatpak repo by default.

[0] http://saimei.ftp.acc.umu.se/pub/debian-meetings/2014/debcon...

Yes, and that's a good thing for a whole bunch of reasons.

If you don't want to leave it up to the distro maintainers, nothing's stopping you from standing up your own repo to distribute your software to a particular distro. It's a one-liner for users to add your repo to their list so they can use their package manager to install and update your software as usual.

> Essentially, something like Flatpak is a middle-ground solution

Yes, I get that it's convenient for maintainers. But it kinda sucks for users (at least for me), which is why I avoid using software packaged that way.

I'll give flatpack this much credit, though -- it's not a nightmare like snaps are.

This is mostly a Debian issue fwiw. Debian is literally notable because they're obsessed with making sure that any package in their repositories is kept with the same "API"[0], no matter how old the software is. The result is that Debian packages can end up hugely derivative compared to the equivalent of upstream and other distros, but it's usually also because the software in question is half a decade old.

With other distros, packaging changes to upstream usually just reflect the preference to match a certain style of configuration (to pull another example from Debian: nginx ships with sites-{enabled,available} folders and is configured to load from sites-enabled by default. This is to match the same configuration style that's used for apache2 and that it's associated tools assume you configure apache2 with, even though nginx just uses a conf.d folder and has no extra tools to facilitate anything fancy with sites-{enabled,available}).

The extreme end is nix, which actively requires you to have the upstream written with nix in mind because nix will basically demand you configure the source code in ways to accommodate for it.

[0]: This includes actual software-intended interfaces and the ones hacked together by users by ie. reading out logfiles.

And there is a lot of more obscure examples: fontconfig e.g. at some point changed their config file format in a not backwards compatible way, and now some Steam games crash on startup because the developers earlier vendored it to get around its ABI breaking repeatedly.

And that sort of software doesn't really obsolete. Steam and GoG allow games to have a 10+ years long tail of slow but steady sales that don't really justify constant maintenance releases but still both let people enjoy good games (those don't really obsolete), and serve as advertisement for the developers' newer games.

Also one more person who can inject malware or break something. How did that Debian keygen issue happen again? Oh right.

https://askubuntu.com/questions/1259840/why-an-old-nodejs-ve...

Nodejs v4.x was "new" when Ubuntu 16.04 LTS came out. It was added to its apt repos, LTS releases are supported for 5+ years, and LTS policy is not to update major versions of software within a release.

So while nodejs was pumping out new major versions every 6-months, people running Ubuntu 16.04 and installing "apt-get install nodejs" were stuck on the same ancient version.

Meanwhile, Snap and Flatpak are package managers - what's more, they're invasive heavyweights with permanent costs that are even worse than distro package managers. Snap permanently runs a daemon, and Flatpak requires you to run programs with "flatpak run" - yuck! They are both trying to impose some dubious vision of sandboxed apps that require bureaucracy to communicate with each other, instead of just tackling the core issue of software distribution. Maybe you even like sandboxing! But I've seen no justification why that should be co-mingled with package management.

First of all, there is no such thing as an average user. Also, it is not relevant to the discussion. I care about what I want in a system, not what some imaginary users want.

Now, we could stop there but I will play: Electron solves a real problem for developers. Writing cross-platform GUI apps is a real pain. Yes, there are native solution but ensuring the user has the exact same experience on every platform tends to be orders of magnitude more costly compare to web based solutions. (That or they are exotic options like Lazarus with Free Pascal that have a much lower Developer pool.) Many apps wouldn't even have Linux ports if they were not written on Electron.

Now, why do users accept them? Why are they not out-competed by native solution? Oh, honey. Why do I have Microsoft Teams installed? Because I like it? Hell, no! Because I need it for work. Why do I have the Discord Client? Because it is great? Nah, I long for good old IRC but Discord it there the people currently are. Did I think the Epic Games launcher is such an great app? Nah, they bought me with offering free games.

Users tolerate shitty software for many reasons, mostly because they have to. It does not follow from that, that they don't mind software being shitty.

You build one flatpak and it will work for all distributions.

  sudo tee <<EOF /etc/apt/preferences.d/firefox-no-snap >/dev/null
  Package: firefox*
  Pin: release o=Ubuntu*
  Pin-Priority: -1
  EOF

  sudo add-apt-repository ppa:mozillateam/ppa
  sudo apt update
  sudo apt install firefox

Alternately, I could shill for NixOS. It's also really nice. Eventually.

I can't move work off of Ubuntu; it's too embedded now, but I'm looking for something else for home. Switching distro-base isn't so easy when you've been using it for decades though; I tried NixOS but it wasn't comfortable (Nix is a steep learning curve), though their community is top notch, and everything I do is deb based.

Looking for a way to get a modern debian (something akin to non-LTS Ubuntu) or just go all out and switch to something Arch based like EndeavourOS.

Here's how to properly install firefox on ubuntu

https://www.omgubuntu.co.uk/2022/04/how-to-install-firefox-d...

and, once you're done:

   apt-get purge snapd

1: https://fostips.com/ubuntu-21-10-two-firefox-remove-snap/

You keep trying to hand wave this relatively straightforward point: users are already used to, and accepting of, slow and bloated applications. Therefore, the downsides that app containerization introduces are irrelevant to most people that will use them.

Instead, I think distros have to provide the base packages like desktop environments and related software. All configured for compatibility and complying with the distro philosophy.

But third party desktop applications that are not directly related to the desktop environment are a different category. There is an endless amount of them with varying quality and resources. You cannot expect distro maintainers to spend time on all these random applications.

However, if a third party app is not included in a distro, it does not mean users have to build the software by themselves. That is the problem that Flatpak and Snap and others are trying to solve. They provide sets of distro-agnostic libraries that developers can target instead of having to target each distro separately.

This way a developer can only package the app once, distro maintainers don't have to do extra work, and users can install applications without having to manually configure and build them. Everyone is happy.

Ironically I was about to set up a new Linux Dev machine with Ubuntu and now I'm more inclined to go back to Mint since I never had a bad experience with it. I was fortunate to skip the Gnome 3 days and the Cinnamon and Xfce implementations have been very stable for a while now.

Actually, I think the LTS mentality is one of the bigger problems in security right now. The hardest problems I've had to deal with in tech all stem for LTS:

* Getting an not-substantial budget to update an essential but forgotten server with custom software and an unpatched heartbleed problem.

* Convincing developers to even look at old web services that have massive SQL injection and were built with libraries with known (six years ago) exploits, all running on some 13 year old version of RedHat.

* Inevitable meetings where you try your best to avoid saying "I told you so" when a disclosure, cryptolocker or malware infestation happens because of the above. These are no fun because they quickly devolve into career-end bingo.

If someone knows why this sandboxing is better/worse than SELinux or AppArmor access rules, can you pls elaborate? I'd really like to know.

So, they decided that the update path is always defined, from any state to the latest, without having to update the packages in specific order, where some steps needed may disappear. You know, being robust.

If the year of linux desktop has to happen, not borking the system during updates is a requirement. You don't have a problem with daily updates? Congratulation, but your grandma probably has.

> mmutable systems can be a nightmare to actually use. Wrote your own software? Copying to /usr/local/bin is no longer an option, hope you like packaging up your one-off tool!

Immutable system does not prevent writable /usr/local/bin. Your one-off tool has no business messing with /usr/bin or /usr/lib.

Immutable systems are also minimal; they don't care about your additional software, as it is separated from the base system. You can update your software at any pace you want; nightlies if you want. It just cannot touch anything in /usr (with /usr/local being exception).

I personally have had them ship out WIP patches not meant for production, which has wasted a lot of my (volunteer) time chasing down phantom bugs in software I maintain. This has personally happened to me on at least four different occasions. A lot of other FOSS maintainers I know have similar stories.

More info: https://manjarno.snorlax.sh/

Is Manjaro really that noob-friendly? All I know about Manjaro is that it's based on Arch, which I always understood as being the LEAST noob-friendly distro besides LFS.

I've had Fedora for over five years and I've never had my laptop get completely borked by an upgrade, but I've had just enough things break between releases in the past that I still get get the sweats every time I've gotta do the restart upgrade, whether it will come up completely and just work or whether my WiFi is now broken because resolve-d changed to systemd-resolved.

Ubuntu is just maddening.

Pop OS is nice out of the box too, but I just don't want to use Ubuntu derivatives at this point even if they've removed snaps

Meanwhile, Mozilla still maintains ppa (mozillateam) with apt version. There's also Flatpak version, which delivers what snap promised.

Another firefox blunder to add to their growing list.

If you're using a "Debian based" distribution, the "standard" .deb is the one shipping with Debian. If it doesn't work on the derivative distro, they are doing something wrong. Or like I said, maybe the dependencies are doing something wrong.

I mean, you can, if you also install its dependencies. And you may end up with a weird franken-system, but you can. You can even automate it and set preferred distros with pinning, it's how people run things like hybrid testing-unstable distros.

https://refspecs.linuxfoundation.org/lsb.shtml

These are, of course, not distro packages, but ISV packages and most RPM features cannot be used.

The irony here is that we’re discussing flatpak/snap, which take the idea of static linking to the absolute extreme by doing something closer to a container where every dependency is part of the package. Maybe static linking being “against distro policy” is tossing the baby with the bath water by causing maintainers to reach to a much worse packaging method (snap) because the distro policy is just too obnoxious.

There’s no good reason you couldn’t just statically link (or relocatably copy) your dependencies into your .deb except the distro maintainers being purists. It would make the process of building a deb (or RPM or whatever) trivial because you’re using it as a dumb archive format for your build artifacts, similar to how a container works.

Try installing any Debian flavor on an Intel Mac. Keyboard, mouse, bluetooth, wifi drivers all incredibly hard to get working. Need to perform some voodoo extracting the drivers from a MacOS image then making them available during boot.

Ubuntu had its place in popularising Linux but they jumped the shark a long time ago, now they are just another player jostling for their own niche.

I didn't say that you should use Arch on the server, but it's great for the desktop.

You can refer to this entire thread to see how well Flatpak/Snap... are working out. Pretty much universally reviled by developers (people who actually use Linux on the desktop).

If I install software on MacOS or Windows, I don't have to care if it was packaged for an older version etc, or that my distro may not package a dependency.

> distros don't have every library packaged.

Exactly. And for those that are packaged they say "these are the versions we support. If you want to us to do the support work, use these". Again for stuff like windows ltsc that means I install version X now and want this to be supported for the next 5 years. If I instead install a consumer version of windows it means X will be out if support by then and I am expected to have upgraded to X+1, X+2, X+3 during these 5 years.

Case in point, Firefox has multiple current versions: 102 ESR and 111. Both get regular updates and neither is "out of date".