Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ubuntu stops shipping Flatpak by default

lwn.net

Post reply on HN
Print view View original

591–600 of 624 posts

Re: Ubuntu stops shipping Flatpak by default

#591

Post by account42 »

creshal wrote: post #560
account42 wrote: post #333

Earlier quoted context omitted.

> they have a higher risk of breaking due to incompatibilities (kernel interface for your graphics driver changed, configuration file syntax for your font renderer changed, etc.) Simply don't vendor glibc and graphics drivers and you will be fine. Vendoring drivers doesn't make sense anyway as your application will be obsolete by the next HW cycle.

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. Really, games have no business looking at system fonts at all.

Re: Ubuntu stops shipping Flatpak by default

#592

Post by the_why_of_y »

veeti wrote: post #157
phkahler wrote: post #132

Earlier quoted context omitted.

>> The problem with that model is that it puts the burden on the distro maintainers to package every possible application for their distro. That's kinda what the distros ARE. Also, if you're debian based and debian packages are not compatible with your distribution you're actively fucking something up for "reasons" - stop doing that. If an app can't use a standard .deb or .rpm then the distro is doing something wrong…

Have you ever actually worked on distribution packaging? There is no such thing as a "standard" .deb or .rpm. Unless you're statically linking against distro policy they have dependencies on the particular version of the distribution they are built for. You can't take a "standard" .rpm from the Fedora repositories and install it on CentOS. You can't take a .deb from Debian 11 and install it on Debian 10.

Technically there is such a thing as a standard RPM, as specified by LSB.

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

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

Re: Ubuntu stops shipping Flatpak by default

#593

Post by esarbe »

moreresearchplz wrote: post #216
tapoxi wrote: post #166

Earlier quoted context omitted.

No, users don't do it. The application developers do it in their CI pipelines. Application developers should be the ones building and testing the app, not distro maintainers responsible for a dozen other applications.

Why should a developer of a free and open-source application, provided free of charge and without any guarantees, have any obligations to package and even test their software on random, thirdparty distributions? If a distro wants to include their application they have every right in the world to do so. So its up to them to do what ever is necessary to enhance their product with the freely available product of the unp…

That's the point of flatpaks - you don't.

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

Re: Ubuntu stops shipping Flatpak by default

#594

Post by the_why_of_y »

dTal wrote: post #121
bionade24 wrote: post #103

Earlier quoted context omitted.

No, an Appimage still ships a dynamically linked executable + lots of dynamically linked libraries, that only link against system libraries when strictly needed, e.g glibc and libGL. Those files are bundled in a squashfs and have a script setting a custom LD_LIBRARY_PATH to the squashfs content for the binary. Snap does use this technique, too, but does more, for worse. AppImages are not comparable with statically li…

I can't make out what you're disagreeing with - you seem to be arguing against something I didn't say? The point is that the contents of an AppImage - "a dynamically linked executable + lots of dynamically linked libraries" - works just as well without all the squashfs backflips. If you can ship an AppImage, you can ship a regular ol' tarball with a binary named "RunMe" inside. The purpose of an AppImage is simply to…

The problem with AppImage is that it doesn't tackle the core issue of software distribution: how to build the software so that it runs on all the systems you want it to run on.

Flatpak and Snap have SDKs for this purpose, but with AppImage an ISV is forced to guess which libraries need to be bundled and which may be dynamic link dependencies from the OS.

Not to mention the requirement for fuse2, which is being replaced with fuse3.

Re: Ubuntu stops shipping Flatpak by default

#595

Post by qbasic_forever »

bombolo wrote: post #552
qbasic_forever wrote: post #95

Earlier quoted context omitted.

I agree but I don't think the software packages themselves should be held back by the available time and attention of packagers. In the new world a packager or distro creator can just pick and choose what flatpaks, snaps, appimage, etc. sources they deem good enough to push to users. They shouldn't be a roadblock in the way of users getting the latest version of software.

Then you install the new version, find out it requires a new version of python and all its libraries, but you can't install it because pytorch only works on old versions of python.

That doesn't happen when apps are packaged in their own containers with all dependencies. The new version you installed has its own python dependencies.

Re: Ubuntu stops shipping Flatpak by default

#596

Post by remram »

jklinger410 wrote: post #475
remram wrote: post #211

Earlier quoted context omitted.

I don't think the Linux ecosystem likes Flatpak that much more than Snap. They are both pretty terrible.

People love flatpak and hate snap, actually.

Over AppImage or APT, really? Do people ever go "great, it's not in my distro but there's a FlatPak available, just as good"?

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

Re: Ubuntu stops shipping Flatpak by default

#597

Post by jklinger410 »

remram wrote: post #596
jklinger410 wrote: post #475

Earlier quoted context omitted.

People love flatpak and hate snap, actually.

Over AppImage or APT, really? Do people ever go "great, it's not in my distro but there's a FlatPak available, just as good"? Not saying you're wrong, but this is surprising to me, and not my own reaction as a full-time Linux user.

I'm saying flatpak over snap, that's all.

Re: Ubuntu stops shipping Flatpak by default

#598

Post by bravetraveler »

nunodonato wrote: post #269
joao_lopes wrote: post #244

Earlier quoted context omitted.

I've moved from Ubuntu to Fedora and it's been more stable while also being more up-to-date without rolling-release distros headaches. Strongly recommend it.

I gave Fedora a try some years ago (4-5?) and had a couple of issues with nvidia drivers. Whats the status these days? I also have a long history with debs, so going to rpm is a mystery for me :)

Nvidia is still nvidia -- with newer kernels you may occasionally find some build problems for their drivers. Fedora amplifies this by using such recent kernels

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.

Re: Ubuntu stops shipping Flatpak by default

#599

Post by DavideNL »

wing-_-nuts wrote: post #265
lumb63 wrote: post #239

Earlier quoted context omitted.

Canonical seems to be trying to push users off of Ubuntu. I switched to Arch from Ubuntu about 6 years ago after seeing how aggressively Ubuntu would auto-update, and because of Zeitgeist. I would never look back. Arch is customizable, simple (in the sense that there are no surprises; things work as expected), and has a great community. Folks here can argue about snaps or flatpaks, and I can happily use AUR to instal…

I also switched to arch for a bit, but then I was left with an unbootable system after the arch devs shipped grub's master branch as stable. The arch devs were completely unapologetic and told me 'well maybe you shouldn't use arch if you can't recover a system who won't boot' Immediately formatted and switched to pop OS and I've never been happier.

Same here, also i was surprised how well popOS worked "out of the box" with just the default settings, running on a new pc/latest hardware.

Re: Ubuntu stops shipping Flatpak by default

#600

Post by IYasha »

tcmart14 wrote: post #476
conor- wrote: post #430

Earlier quoted context omitted.

I feel like hunting down drivers hasn't been an issue on Linux for any relatively modern machine I've run in over 10 years. If it really is something that you have had problems with, maybe try PopOS instead of Debian. The restricting non-free repos by default out of principle with Debian can sometimes get annoying when you need to install certain non-free drivers (looking at you Nvidia), but PopOS is a really well-po…

Or another recommendation. If you want all the drivers and you want to run Debian, use the non-free image which I believe they just decided to make it easier to find?

I've tried non-free KDebian last month. It still booted without wi-fi. But what's most frustrating - it didn't detect any partitions on my drive. The KDE installer I mean. lsblk showed everything just fine. Same with Neon live.

And guess what? It works in KUbuntu. But ubuntu is just SO slow now. ( And I couldn't install it of my current dual-boot anyway because it does NOT have option to NOT TO install new bootloader. :-/ I love Linux (lie).

Post reply on HN