Live data from Hacker News

Ubuntu stops shipping Flatpak by default

lwn.net

601–610 of 624 posts

Re: Ubuntu stops shipping Flatpak by default

#601

Earlier quoted context omitted.

I'm genuinely curious about this, as I see people say it a lot but it's not my experience at all. 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…

I haven't had it often but I've had stuff break sufficiently badly that I couldn't boot to a graphical environment before. I agree with the other posters that a lot of the stuff that breaks is in the AUR, but practically most users rely on the AUR so if the AUR is prone to breakage so is the typical user's arch Linux environment. I'll also freely concede that part of this stems from the common practice of treating th…

>> but I've had stuff break sufficiently badly that I couldn't boot to a graphical environment before.

Is there some "restore to previous state" (Windows-style) feature for that case? Because I'm too afraid to install Arch on my only working PC.

Re: Ubuntu stops shipping Flatpak by default

#602
post #56

Earlier quoted context omitted.

The original model is that software developers don't package their software for distributions at all, at best they provide helper scripts that the distribution maintainers can use to do that. That's why distributions are typically either giant volunteer-run organizations like Debian or companies like RedHat or Canonical.

The problem with that model is that it puts the burden on the distro maintainers to package every possible application for their distro. And application developers have to essentially wait for each distro to repackage their app before it becomes available on that distro. Or start messing with alternate repositories for each distro they want to support. The old model works for established software, but breaks down a l…

> And application developers have to essentially wait for each distro to repackage their app before it becomes available on that distro.

Nonsense. Developers can do their thing, and distro maintainers can do theirs. The two have very different priorities and goals.

I'm perfectly happy downloading the latest version of hip package X directly from the developer's website while relying on distro packages for all the boring, stable stuff.

The whole "it's either all hip or all boring" is a false dichotomy.

Re: Ubuntu stops shipping Flatpak by default

#603

Earlier quoted context omitted.

Sadly, modern software development practices have neutered a lot of LTS releases -- but the need for real LTS releases is stronger than ever.

> but the need for real LTS releases is stronger than ever 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 hav…

(This entire comment is about my use of my own machines, not about the use of machines in an enterprise setting. In the enterprise, much of this is very, very different)

From a security point of view, yes, you have a point.

But I blame the problem on the industry shift to lumping security and feature updates together. I hate, and prevent, automatic software updates because I don't want feature changes to happen except if/when I'm ready for them. Feature updates are very disruptive, and sometimes break things horribly.

If I could just get security updates, I'd allow those to automatically happen without thinking twice. LTS releases were a (poor) compromise to accomodate those of us who can't, or won't, take on random feature updating.

Sadly, the LTS time periods are getting so short that they're often not effective for this purpose anymore -- so in those cases, I resort to blocking updates entirely until I'm ready for them.

That's also a bad security place to be. I just don't see any other way to handle it aside from separating security and feature updating, like we used to do. But that's not going happen. So all I'm left with is LTS releases and blocking updates.

Re: Ubuntu stops shipping Flatpak by default

#604

Earlier quoted context omitted.

> I'm a professional dev So you have particularly skewed perspective; you should try a bit of operations, or at least devops, to normalize it. > Arch perfectly suits my needs Good for you. You just need to realize that you are minority. Do you notice that Arch is not the dominant distro? There's a reason for that. > where as Flatpak/Snap... cause excruciating pain every time I'm forced to interact with them You are h…

> So you have particularly skewed perspective; you should try a bit of operations, or at least devops, to normalize it. 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).

People who actually use Linux on the desktop en masses is Chromebook users. Immutable OS is just fine as we see, let's people reach their goals.

Re: Ubuntu stops shipping Flatpak by default

#605

Earlier quoted context omitted.

glibc breaks regularly, as does mesa occasionally, so it would realistically be required if you wanted win32-style 20+ years of backwards compatibility. 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 repeated…

> glibc breaks regularly, as does mesa occasionally Neither of this is true. > 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. Bundling fontconfig but not it's internal config is retarded, yes. Rea…

Calling everyone except yourself too retarded to figure out compiling Linux software is not a productive discussion. And glibc/mesa related breakages are well documented, if you care.

Re: Ubuntu stops shipping Flatpak by default

#606
post #162

Earlier quoted context omitted.

They’re better than Flatpak for CLI applications I guess since Flatpak doesn’t aim to support those 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)

Another option https://appimage.org/

Those are actually kind of nice.

Re: Ubuntu stops shipping Flatpak by default

#607

Earlier quoted context omitted.

Slackware, perhaps? Honestly, if you just want the naked OS, you don't need a distro at all. Or just don't use the package manager.

I'm curious what a Linux would look like that behaved more like windows or android in the sense that there isn't such a blurry line between the OS and its applications. 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? This is basically the Unix "I'm not just an OS, I'm a platform for building and running C programs" heritage that…

> in the sense that there isn't such a blurry line between the OS and its applications.

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.

Re: Ubuntu stops shipping Flatpak by default

#608

Earlier quoted context omitted.

Everyone's done with Ubuntu. It's just not good. Its got a stereotype at this point for being the easy noob distro but that's not even true. Its top to bottom awful and has been for many years.

Call me a noob if you like, but I don't like hunting down drivers. Tried to go to debian on my last dev machine upgrade, but reverted straight back to ubuntu. I may be lazy, but I really don't want to hunt down drivers. I'll try debian again next cycle.

You could also try Linux Mint. I moved to that two years ago when Ubuntu started to go sideways and I've been very happy so far.

Re: Ubuntu stops shipping Flatpak by default

#609
post #587

Earlier quoted context omitted.

I'm curious - what's wrong with snaps on the server?

Same as on Desktop. They are terribly slow, resource hungry, update automatically. 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.

So if I install a web server as a snap, it'll be slower, take up more resources, and restart randomly? I find that hard to believe.

Re: Ubuntu stops shipping Flatpak by default

#610
post #54
post #44

Earlier quoted context omitted.

> Mir, Unity, now Snap. Ubuntu has a track record of wanting to go it alone. This. Also bzr. They seem to want to control their projects completely and so even when they have good tech they lose out to more open, community developed, equivalents that build wide engagement and momentum. I honestly don't understand it, you would have thought they would have learned by now that they don't have the engineering resources…

Bzr is a great counter example. Bzr "lost" because git had GitHub, whereas Launchpad was one too many things and slow to optimize for modern sensibilities. (And Linux used a different VCS before git, so that didn't matter in adoption) Imagine a world without GitHub, and I don't think git would be our go-to VCS. Though maybe not even Baazaar, but there are things like Mercurial too.

bzr lost because it was poorly-architected, infuriatingly slow, and kept changing its repository storage format trying (and failing) to narrow the gap with Mercurial and Git performance. Or, at least that's why I gave up on it, well before GitHub really took off and crushed the remaining competition.

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.

Post reply on HN