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

Flatpak Is Not the Future

ludocode.com

Post reply on HN
Print view View original

381–390 of 410 posts

Re: Flatpak Is Not the Future

#381

Post by goohle »

simiones wrote: post #380
goohle wrote: post #261

Earlier quoted context omitted.

You are making it backward. Linux distribution is a distribution, not a vendor. If you will write a higher level SDK, and then will write an application using the SDK, and then this application will be requested by users, then your application and your SDK will be included into the distribution. UNIX has CDE[0], but nobody uses it, so no distribution includes CDE by default. [0]: https://en.wikipedia.org/wiki/Common_…

> Linux distribution is a distribution, not a vendor. I don't understand what you mean here. Do you think that the Debian is not trying to provide a full OS, they are just curating a set of popular packages? I think this is patently false, as most distributions typically take clear decisions to standardize and maintain particular OS components, such as choosing a particular libc (glibc in most distros, musl in Alpine…

Yep, Debian is not even trying to develop a full OS. They are distributing GNU/Linux with few popular desktops (Gnome, KDE, Mate, XFCE, etc.), and popular applications.

GNU project tries to develop full OS for Linux kernel. GNOME project tries to develop full desktop for GNU/Linux. The Document Foundation tries to develop full office suite. And so on.

Re: Flatpak Is Not the Future

#382

Post by simiones »

WastingMyTime89 wrote: post #206
simiones wrote: post #173

Earlier quoted context omitted.

> On Windows and macOS, there are some SDKs the application can lean on. On Linux, the only stable "SDK" is the Linux kernel API. This is a very good observation I think. Basically, what Linux distributions have failed to do is to create a higher level SDK for their platforms - instead, they rely on a soup of libraries and on the package maintainer model to know which of these is which. Basically, they are failing to…

> This is a very good observation I think. Basically, what Linux distributions have failed to do is to create a higher level SDK for their platforms - instead, they rely on a soup of libraries and on the package maintainer model to know which of these is which. Not really no. It's both simpler and more complicated. At the very low level, everyone expects to get a POSIX system. At the user level, most users use either…

Even Gnome and KDE are not really "high level SDKs". They mostly have GUI support of various kinds, but not a full SDK for interacting with the OS (e.g. interacting with networking, with other apps, with system services etc.).

Re: Flatpak Is Not the Future

#383

Post by thereddaikon »

goodpoint wrote: post #365
jcelerier wrote: post #344

Earlier quoted context omitted.

That's a ridiculous answer. "You don't" means people go back to windows or Mac OS where they can do that easily because it's an actual need people have. That's the worst outcome by far as it leads to less support on Linux.

No, "you don't" is a valid answer. You use what is in the distribution. You chose the combination of archives (stable, stable+backports, and so on...) as you need. Then you use what the distro provides. (The same way as you use the default, tested and guaranteed engine computer on your car rather than installing one bought in a dark alley.) Like the car, distribution work when you use the whole set of components bund…

This is the opposite of freedom. People own their computers, its up to them how they are used, not some gatekeeping devs.

Re: Flatpak Is Not the Future

#384

Post by badsectoracula »

cpuguy83 wrote: post #374
badsectoracula wrote: post #370

Earlier quoted context omitted.

> There is no common/stable set of c libs. libc on one distro is different than libc on another (even just within glibc). It's why you generally can't run an app compiled on one distro on different one Pretty much everything uses glibc and distros that are to be used by end users (instead of specialized uses like embedded) also tend to have glibc versions. If someone uses a non-glibc distro it'd be out of their choic…

Yes, you can compile with a really old glibc and use it on a newer one. But glibc does introduce incompatible changes that make it not work the other way and there are issues with stable ABI's across distros.

AFAIK the issue is the symbol versioning which is explicit by design. I can understand why it exists for glibc-specific APIs but i don't see why it is also used for standard C and POSIX APIs that shouldn't change.

It is an issue if you want to compile new programs on a new distro that can run on older distros, but IMO that is much less of a problem than not being able to run older programs in newer distros. And there are workarounds for that anyway, though none of them are trivial.

Re: Flatpak Is Not the Future

#385

Post by simiones »

cpuguy83 wrote: post #374
badsectoracula wrote: post #370

Earlier quoted context omitted.

> There is no common/stable set of c libs. libc on one distro is different than libc on another (even just within glibc). It's why you generally can't run an app compiled on one distro on different one Pretty much everything uses glibc and distros that are to be used by end users (instead of specialized uses like embedded) also tend to have glibc versions. If someone uses a non-glibc distro it'd be out of their choic…

Yes, you can compile with a really old glibc and use it on a newer one. But glibc does introduce incompatible changes that make it not work the other way and there are issues with stable ABI's across distros.

Forwards compatibility is basically non-existent in the software world. It's not like you can compile a Win 10 program and expect to any time run it on Win 7.

Re: Flatpak Is Not the Future

#386

Post by iggldiggl »

simiones wrote: post #117
enriquto wrote: post #43

Earlier quoted context omitted.

> Is there any difference in trust between package maintainers and flatpack packagers? You shouldn't need to trust either. Just the sandboxing system of your OS.

That's only true for the simplest of apps. The whole point of desktop OSs is that programs can integrate with each other, but that necessarily discards the notion of a sandbox almost entirely.

Yeah, e.g. file sandboxing approaches that work along the lines of "don't let the program access any files outside of its private directory except for those explicitly and lovingly hand-picked by the user" commonly ignore the existence of multi-file file formats.

Re: Flatpak Is Not the Future

#387

Post by dylan-m »

oynqr wrote: post #307
dylan-m wrote: post #282

Earlier quoted context omitted.

> Basically, what Linux distributions have failed to do is to create a higher level SDK for their platforms - instead, they rely on a soup of libraries and on the package maintainer model to know which of these is which. At the same time, the tools which solve this really shine. You inevitably run into these issues with random third party dependencies on other platforms, too, but it's further from the norm, so you en…

It also makes some software under the Gnome umbrella incredibly hard to package for distributions.

Oh, for sure. Reconciling a bunch of different things' ideas of what libturkey they think they need into a single image must be a nightmare. In theory, that's what BuildStream should be helping with since gnome-build-meta[1] is only going to have one of those for different components to depend on. (If there were two libturkeys, it would be very obviously wrong). But I guess the trouble then is a lot of extra apps aren't in gnome-build-meta?

When I was messing with BuildStream a while ago I found myself wishing projects put reference BuildStream elements in their own git repos, but I suppose that would get messed up in the same way.

[1] https://gitlab.gnome.org/GNOME/gnome-build-meta

Re: Flatpak Is Not the Future

#388

Post by simiones »

jhaygood86 wrote: post #349
simiones wrote: post #173

Earlier quoted context omitted.

> On Windows and macOS, there are some SDKs the application can lean on. On Linux, the only stable "SDK" is the Linux kernel API. This is a very good observation I think. Basically, what Linux distributions have failed to do is to create a higher level SDK for their platforms - instead, they rely on a soup of libraries and on the package maintainer model to know which of these is which. Basically, they are failing to…

I'd like to point out elemenatary OS as a counter-example: They have consistently provided a high level SDK for their OS. With elementary OS 6, they moved their high level SDK to using flatpak (not flathub) as a distribution mechanism.

That's probably because they are a very niche OS, while flatpak seems to be gaining in popularity.

Re: Flatpak Is Not the Future

#389

Post by goodpoint »

thereddaikon wrote: post #383
goodpoint wrote: post #365

Earlier quoted context omitted.

No, "you don't" is a valid answer. You use what is in the distribution. You chose the combination of archives (stable, stable+backports, and so on...) as you need. Then you use what the distro provides. (The same way as you use the default, tested and guaranteed engine computer on your car rather than installing one bought in a dark alley.) Like the car, distribution work when you use the whole set of components bund…

This is the opposite of freedom. People own their computers, its up to them how they are used, not some gatekeeping devs.

This is absurd. You are confusing Linux distributions with DRM.

Did you not read the last line? You are free to do whatever change you want.

You are also free to use a distribution as it is without having to spend your time handling security, stability and compatibility across applications all by yourself.

Yet you cannot mash together a frankenstein OS while also expecting it to provide security and stability. Not because of a distribution decision but because of reality.

Re: Flatpak Is Not the Future

#390

Post by badsectoracula »

simiones wrote: post #385
cpuguy83 wrote: post #374

Earlier quoted context omitted.

Yes, you can compile with a really old glibc and use it on a newer one. But glibc does introduce incompatible changes that make it not work the other way and there are issues with stable ABI's across distros.

Forwards compatibility is basically non-existent in the software world. It's not like you can compile a Win 10 program and expect to any time run it on Win 7.

Actually you can, as long as it doesn't use Win10 APIs (or use them via dynamic loading) it will work on Win7.

The issue with glibc is that when you use it it adds requests for the latest versions of the exported symbols that the glibc you use in your system has. You can work around this in a variety of ways (e.g. use __asm__ to specify the version you want and use the header files of an older glibc to ensure that you aren't using incompatible calls) but you need to go out of your way to ensure that whereas in Windows you can just not use the API (well, also make sure your language's runtime library doesn't use the API either but in practice this is less of a concern).

Post reply on HN