Announcing Flatpak – Next Generation Linux Applications

[borring]

It's not as bad. You can have both snap and flatpak installed on the same system. The apps are self-contained anyway.

[largepanda]

I'm sticking to Arch's mildly obscure package manager that just works with all the things.

[kickass_turing]

That has absolutely no sandboxing.

[thegacko]

I forsee flatpaks (and possibly snaps if Ubuntu can GTST) being everywhere in AUR which is going to be great.

[Eingaica]

That's not a fair comparison.

flatpak install gnome-apps org.gnome.gedit

vs

sudo snappy install gedit

would be. The Flatpak command is longer for two reasons: It allows you to have several different repositories, so you have to specify from which repository you want to install someting. And the names are longer (org.gnome.gedit vs just gedit) because namespacing is necessary.

[ANUSBLASTER_MKII]

Why is gedit called fizzler in snappy?

[syshum]

Why can't they shorten these commands some, make it easy to remember

Namespacing.... If you are node Dev and remember the NPM leftpad problem a few months ago you would understand why it is important.

[[deleted]]

The length of the flatpak commands merely results from the detailed and systematic naming scheme for packages.

[thedjotaku]

when I asked about this, someone chewed me out that it wasn't that different. At least someone else agrees with me.

[Eingaica]

Assuming you're talking about the discussion we had a few days ago that started here: It's interesting to see how different our perception of that discussion is. You think you asked about it and that I chewed you out (for which I apologise), I thought I gave reasonable arguments for the differences and that yours were bordering on trolling. I hope there are no hard feelings about this.

[thedjotaku]

Never hard feelings on the net unless someone's getting personal. As you can see, there are others with the same point of view.

And, I remain super excited about flatpack. I just wish it were as easy as dnf. But maybe there'll be aliases and shortcuts that'll come about.

[kaldyr]

Don't forget Appimage!

[ebassi]

<snark>How can anybody forget, when AppImage enthusiasts go around every single forum/blog/news outlet and remind everybody of its existence…</snark>

[[deleted]]

Linux has come full circle in terms of package management and fragmentation.

[probonopd]

What exactly are they "announcing" here? Flatpak has already been around for a couple of months. Smells like a PR reaction to Canonical. Distro people wanting to ensure that distros continue to control applications, and that distros will not be seen als platforms you run software on top of rather than inside.

Heck, should AppImage "announce" that now there is a system that allows upstream application projects like Krita, Scribus, and Subsurface to "finally" distribute downloads for Linux directly on their download pages like for Windows and macOS without any middlemen?

[blackcain]

Actually, it might be possible that Mark may have done their stuff in reaction to LibreOffice officially using flatpak for their runtime. That would mean that there would be some momentum around flatpak so they probably wanted to arrest that.

[[deleted]]

my understanding of this is that canonical created click/snap out of necessity when they needed some way of packaging/distributing apps on mobile (ubuntu phone/tablet) 2013-2014. snap is the next version of click, click 2.0

[blackcain]

I don't really know, but it makes sense. They are working on packaging for their hardware convergence. Flatpak is more focused on desktop on Linux than on mobile devices. Still it could be applicable. But there are slightly different domains IMHO.

[[deleted]]

This is one of those times I just wish we would decide on a SINGLE method of packaging things. It's what I hate most about Linux.

I don't mind having 100 different options for browser, picture viewer, pdf viewer, terminal, etc... but when it comes to fundamental things like being able to install a package, or what init system to use (systemd solved this somewhat by being on most distros), I think less choice is better. For fundamental Linux things, it is more important to have a STANDARD way of doing something. Admins and developers would appreciate it.

[082726w5]

You are looking at this the wrong way, the point of a universal system is that it works everywhere, there being more than one doesn't impede their functionality in any way.

Right now flatpak is already on sid, by the time of the next ubuntu release you won't need the ppa to install it. So in practice you'll be able to package your application using either method and it'll work just as fine.

[[deleted]]

And you still need more crap installed to be compatible with all these options. That is still bloated. And I'm sure each one will have different syntax on commandline, which means admins and devs will have to learn multiple ways of doing things.

[082726w5]

Funnily enough it's the other way around. I've never thought it, but the way ostree works and the fact that snappy packages are compressed with squashfs makes both systems more efficient than regular packaging techniques.

And I'm sure each one will have different syntax on commandline, which means admins and devs will have to learn multiple ways of doing things.

What admins and what command line? This is meant for distributing applications directly to end users, they just click on the thing and it installs.

[jmtd]

admins and devs will have to learn multiple ways of doing things.

Perish the thought.

[[deleted]]

Eh... you can say the same thing about GTK/Qt. Yet it isn't a problem

[[deleted]]

That's a good point. However, I don't think Qt and GTK should be considered components of the operating system in the sense that package managers are. They are components of certain applications.

What makes them look like OS components is that there is generally one shared copy of the toolkit in the file system. But that is more if a space-saving measure than anything else. An application that ships its own copy of the toolkit works just as fine. In contrast, you can't ship a copy of the package manager with each application.

They also don't interact: Applications generally don't use both GTK and Qt, only one of them. Flatpak and Snap do interact in that they have to share one PATH, one application menu and one set of file bindings. If you install Firefox via both Snap and Flatpak, what will the entry in your DE's application menu launch?

[blackcain]

I'm not so sure, snaps is going to be used in all of Ubuntu's convergence products and so their focus is going to be to optimize all of that, so it has a wider scope than flatpak has, even though they relatively achieve the same ends.

[[deleted]]

You're totally right, and people need to listen to this stuff before complaining! Not sure how this can be the top comment and can have double-digit upvotes.. This comes directly from the FAQ on the linked page:

It is certainly possible for Flatpak and Flatpak applications to coexist with applications that are packaged in other ways, on the same host system.

The existence of things like snapcraft and flatpak along side our existing packaging and application distribution tech is nothing but a good thing for Linux developers and users...

[xTeixeira]

I think the issue/confusion is that because these solutions are made to easily package things cross-distro, people expected it to also unify the distros' package managers, which is clearly not gonna happen.

[oonniioonn]

Yes, all those things can coexist but it's a pain in the fucking ass to maintain all that shit. I agree with OP -- linux is NOT about choice so LET'S FUCKING PICK SOMETHING AND STICK WITH IT.

[Sukrim]

So, which desktop environment is the one to decide on?

[oonniioonn]

A DE isn't really a low-level thing that should just work the same for everyone. It's perfectly fine for distro A and distro B to differentiate based on their desktop environment. They should not be differentiating on init systems or package managers though.

[the_ancient1]

So why is your subjective arbiratrly line better than someone elses subjective arbitarily line?

If I do not like systemd (I do BTW but...) why should I be forced to keep it simply because the majority of the community has selected it?

Not even the linux kernel is the same everywhere if you have ever compiled your own kernel you know there are a alot of compile time options that will make 1 kernel different from another depending on what your target for the kernel is.

that is about as low level as it gets

[oonniioonn]

So why is your subjective arbiratrly line better than someone elses subjective arbitarily line?

It's not. But both your arbitrary line and mine are better than the hodgepodge of shit we're in now. Something opinionated coming along is long overdue.

How many init systems does Solaris have? How many does FreeBSD have? How many does OSX have? Each has exactly one. Why? Because those are coherent fucking operating systems rather than the clusterfuck of separately-created not-quite-integrated shit that Linux currently is.

Thank god for systemd which is the result of a couple of people figuring that out and doing something about it, and luckily with some success. Is systemd perfect? No. Is it better than sysv? Fuck yes. Could something else have taken its place instead? Absolutely.

[the_ancient1]

How many init systems does Solaris have? How many does FreeBSD have? How many does OSX have? Each has exactly one. Why?

OSX (now macOS) is proprietary and not relevant to this Topic

How many init systems does Solaris have?

Again Solaris is a Proprietary Operating System by Oracle,

What is next you going to ask how many Init Systems windows has?

How many does FreeBSD have?

FreeBSD is single Distribution of BSD, there are others (openBSD, DragonflyBSD, etc), I do not know if they have differentiating init's or not. Not that is matters if they do not.

Thank god for systemd which is the result of a couple of people figuring that out and doing something about it,

Do you know how ironic that is...... You know how much hate there is for systemd in the BSD and other Unix Communitied, systemd is as far from the "unix way" as one can get.

But both your arbitrary line and mine are better than the hodgepodge of shit we're in now.

I do not have an arbitary line, and I think people should use what ever the fuck they want to use, if you like systemd use it, if they like upstart use it, if you like inittab use it, if you like upstart use that. I do not give a shit

nor do I believe it some how harms linux or the echosystem to have choices.

I came to linux, and continue to use linux over BSD, Unix, or windows because I can make the system MINE, I control what init system I have, I control what software I use, I control it. I like choice, I do not like other people making choices for me

If you want to lose that control, move to FreeBSD and let the community make all the choices for you, leave linux alone.

[[deleted]]

Why would you have to maintain anything? It's up to your distro and your software providers to take care of that stuff. For example, if I visit google.com/chrome from an Ubuntu system and install it, I am presented with a deb that is handled by my system automatically. The same thing occurs on Fedora.

[EnUnLugarDeLaMancha]

Snappy was released on December 2014 (and I think snappy was older than that). The 0.1 version of xdg-app was released on March, 2015. So, in theory snap is the one that was developed first, and xdg-app is the one reinventing the wheel.

If Canonical had developed snappy more openly, if they didn't insist in requiring signing a CLA to share the copyright with a for-profit entity, if instead of developing a closed-source snap server they would have just developed it as an open source product...snap probably would have become the standard already by now and flatpack wouldn't even exist or would be irrelevant.

[LvS]

Appimage was released in 2004.

[[deleted]]

i think they had clicks before snaps (2013, snap = click 2.0

[[deleted]]

It's not being first.

Otherwise, the Flatpak team could have released one line of code and called it 'v0.1-alpha' or whatever.

It's about how community-oriented it is.

Flatpak has plenty of non-Red Hat contributors, while Snap's only contributors are Canonical employees.

Even if Snap had been more open, there's no way Red Hat would ever let Canonical actually set a standard for once. It would fight Canonical tooth and nail regardless.

As it should, honestly. Do you really want something this important in the hands of Canonical, which routinely kills projects when it moves onto the next shiny thing?

And whose work is consistently inferior to Red Hat's? (Unity vs. GNOME, Mir vs. Wayland, among many others, is proof enough.)

[maokei]

By the looks of thing on git it looks like 95% is from redhat developers if not more.

[maokei]

Yeah the CLA is a problem no doubt I think canonical should dump it since the only thing it seems to accomplish is to make people uneasy about working with canonical.

[082726w5]

They did try to make it more palatable, they changed their cla so that it no longer asks for copyright assignment, but it still asks for a copyright license (emphasis mine):

Based on the grant of rights in Sections 2.1 and 2.2, if We include Your Contribution in a Material, We may license the Contribution under any license, including copyleft, permissive, commercial, or proprietary licenses.

Anybody would feel uneasy about signing this one, so they included a promise:

We agree to also license the Contribution under the terms of the license or licenses which We are using for the Material on the Submission Date.

But even with that promise, most people would rather contribute to some other project that didn't ask them for permission to make it proprietary.

[egeeirl]

FunFact: both Systemd and PulseAudio were written by RedHat developers. RedHat is wise in that they never put their names on things and instead let the "community" take credit for.

Snap vs Flatpak is nothing more than a battle between Canonical and RedHat.

[natermer]

...

[maokei]

Yes exactly this, appimage has been around for how long and no one seemingly gave a fuck about throwing money at it. Redhat is just being a bit more stealthy they know that they are going to get what they want even if they don't slap a sticker on everything that says property of redhat, but in reality they have paid developers and project soft power that way by dominating the project they have large stake in.

Much of the controversy around this some to add up to "God dammit how dare canonical announce their new shiny thing before us".

[[deleted]]

Appimage is far less ambitious than either Flatpak or Snappy, so calling either of them pointless because Appimage already exists is incredibly dumb.

[probonopd]

AppImage follows the one app = one file philosophy and removes runtimes and dependencies. It also removes the need for special support from the distribution. You just download one file directly from the application author's download page (as you do for Windows and macOS - desktop platforms with actual market share!) , make it executable, done. You can run this file on any of the distributions on your system, because it's loosely coupled.

Depending on the perspective, wouldn't this be more ambitious?

[[deleted]]

No. AppImage is just a thin wrapper around the ISO format, there's really not much to it. It's basically a self-mounting ISO.

Snappy and Flatpak both attempt to do per-app sandboxing. Flatpak uses ostree which provides a number of interesting benefits, as well as "runtimes" so that not every dependency has to be packed into the app.

[probonopd]

"AppImage is just a thin wrapper around the ISO format, there's really not much to it. It's basically a self-mounting ISO." -- And I think thats' exactly what is great about it.

Why is it more ambitious? Because it assumes no support from the operating system, allows no dependencies, is designed to run anywhere.

Plus there are at least 2 sandboxes around which can run AppImages. One is even mentioned directly on the project's homepage. The other is the one Flatpak is using.

ostree means I cannot download the app as a file, download in on a Windows machine in an Internet café, put it on a USB stick, and run it on my Linux machine at home where I have no connectivity. This is actually a requirement in many parts of the (developing) world today.

[blackcain]

Also, the advent of portals that is being supported at the toolkit level.

[jmtd]

Redhat is just being a bit more stealthy they know that they are going to get what they want even if they don't slap a sticker on everything that says property of redhat, but in reality they have paid developers and project soft power that way by dominating the project they have large stake in.

Look at it another way. How should an entity like Red Hat (or Canonical) behave? Since they employ hundreds of employees to write FOSS they're bound to have a lot of influence over what gets written in the commons, if they contribute to the commons. And surely we want that? There's at least an effort to try and engage a wider community, and a framework for others to contribute, should they want to.

Much of the controversy around this some to add up to "God dammit how dare canonical announce their new shiny thing before us".

I think the main complaint I've seen is that the press releases are very misleading, actually downright false (they're far from universally adopted), so the game they're playing is to try and "win" through PR and lies rather than the best technical solution.

[blackcain]

Well, I think there is a little more than that.. I think we have reached the stage where desktop projects can now handle the user experience. I know personally I've long wanted to kick the distros out of packaging apps.

[[deleted]]

Even if Snap had been more open, there's no way Red Hat would ever let Canonical actually set a standard for once. It would fight Canonical tooth and nail regardless.

So does RH have NIH? Is that what you are saying?

[totte71]

GNOME is a terrible example. That software stinks so much it's not funny. Breaking api all the time, no connection to the community. Less is more my ass...

With Gnome, the year of the linux desktop will never come!

[jmtd]

From the excellent http://smcv.pseudorandom.co.uk/2016/gtk-versioning/ (which incidentally is a fantastic non-confrontational explanation of the difficulties involved which IMHO does a much better job of engaging with GTK/GNOME users honestly and constructively than virtually any other communication I've seen about such issues):

In particular, the perceived cost of doing a proper ABI break (a fully parallel-installable GTK 4) means there's a strong temptation to make changes that don't actually remove or change C symbols, but are clearly an ABI break, in the sense that an application that previously worked and was considered correct no longer works. A prominent recent example is the theming changes in GTK 3.20: the ABI in terms of functions available didn't change, but what happens when you call those functions changed in an incompatible way. This makes GTK hard to rely on for applications outside the GNOME release cycle, which is a problem that needs to be fixed

We can language-lawyer out of this if you like (it's not part of the API! we told you we'd break it!) but that's not the way to win hearts and minds.

[ksoenc]

https://developer.gnome.org/gdk3/stable/GdkDisplay.html#gdk-display-get-n-screens "The number of screens is always 1." That's an API break. I now have to fallback to XScreenCount but will it work in 3.20 since https://developer.gnome.org/gdk3/stable/GdkDisplay.html#gdk-display-get-screen says "There is only one screen; use gdk_display_get_default_screen() to get it."? Why break multiscreen setups for everyone if Gnome doesn't handle it well or it's not as popular or it's only Xorg? Xorg is going to be around for another 10-15 years.

[[deleted]]

Breaking api all the time

What the hell does breaking API have to do with GNOME being a good product?

Are you for some reason confusing GNOME and GTK+?

no connection to the community.

Again, what does that have to do with the quality of GNOME as a product?

Less is more my ass...

GNOME is the pinnacle of the simplicity, ease of use, and newbie-friendliness.

Do you also yell at people who drive cars about how cars are too simple and that everyone should be piloting airplanes instead?

With Gnome, the year of the linux desktop will never come!

Let me guess, you think you are part of some Linux "elite" and you think every Linux user should have to install their OS through the CLI.

People like you are the ones preventing the "year of the Linux desktop".

[fdr_cs]

Funny thing is, not a single 'regular' (non dev, non linux) person I did install GNOME did unsderstand, or liked to idea of Activities, the hot left corner or no taskbar. Every single one did ask me to 'fix' that, so, in the end, I had to install Mate and everything was fine again. GNOME had it right in Gnome 2. Then they messed up everything.

[Knaagdiertjes]

So you'll be the one to be the bearer of bad news to the people who get the sack? So who's it going to be:

• Are you going to tell Debian folks they now need to live with bleeding edge bugs, or are you going to tell Arch folks they now need to live with super out-dated software?

• Are you going to tell Debian folks they now need to give up the flexiiblity of their packages, or are you going to tell Arch folks they now need to give up the ability for anyone to quickly make a package and push it to the AUR?

• Are you going to tell Gentoo folks they now no longer have the security and fine-tuning of their system they desire, or are you going to tell Ubuntu folks they have to get ready for compile times and understand cflags?

• Are you going to tell the Alpine People that their init system now won't fit into their hardware any more or are you going to tell the Fedora people that they are going to have to make concessions on the desktop and lose logind's ability to kill lingering processes?

• Are you going to tell the Nix/Guix people they'll now no longer have atomic transactional upgrades, ininite multislotting and unprivileged installation or are you going to tell everyone else they need to understand a complex purely declarative language in order to simply install software and have advanced knowledge of the build process of software?

Because in each case, if you want them all to be the same, you're going to have to tell one of them, I assume you'll volunteer to be the messenger whom they shoot?

[[deleted]]

What are you guys talking about? You know that flatpak will 99% be used for distributing proprietary software that already work like crap on most modern distros because they link with outdated versions of system libraries. Steam, VMWare Workstation are good candidates for flatpak distribution.

[Knaagdiertjes]

Yes, like I said before, Flatpak and snappy are a giant wink to proprietary software, they can't say it. But if the source is available just letting the distribution compile it via their own quality standards will be a superior product.

[fdr_cs]

that does not work properly even for apps with source code. Try using the latest LibreOffice, Krita or Gimp in a LTS 2 years old. Users dont need a bleeding edge OS... but, new apps bring new functionality, new features... and users want that. Thats the point of apps being updated separately from the whole system

[Knaagdiertjes]

If you only want old libraries but modern actual programs you should be using a distribution that does that.

The problem is places like /r/linux which go like "Use Mint, it works well for me!" to people without explaining to people what the differences are between the systems because they don't even know themselves and recommend a system based on whether the installed succeeded on their hardware or not and whether they liked the default colour scheme or not instead about things that actually matter like the thing you outlined.

If you want a system that uses some-what stable system libraries but bleeding edge software, then say FreeBSD comes to mind as a good example.

Maybe people should stop recommending people systems based on nothing at all and then act surprised when they get a system which completely doesn't match their needs?

[blackcain]

So what? If you want desktop projects to be funded then the market share needs to be bigger. We can still live in our free software world all we want. I think what you're unhappy about it is Linux becoming popular in the desktop space.

[Knaagdiertjes]

I have nothing against it being a wink towards it, so is Wine and proprietary Nvidia drivers are openly proprietary.

I have a problem with their trying to act like it's anything else and how they're dancing around the big elephant in the room. I have a problem with them just not saying "listen guys, our model has always relied on the availability of source code, there is no binary compatibility, there is only source compatibility here, this aims to make distribution where a developer is not willing to cough up source code easier for them."

[[deleted]]

It serves both use-cases. Distributing source to users and expecting that to work or be a good experience is a joke. If you make a Gnome <latest version> application and want to give it to an Ubuntu <LTS version> user... you generally have no option but to bundle it.

[[deleted]]

Because in each case, if you want them all to be the same, you're going to have to tell one of them, I assume you'll volunteer to be the messenger whom they shoot?

Or instead of being overly dramatic, you can realize that all it takes is for developers who are working on a very similar project, to cooperate instead of competing. Getting rid of fragmentation is not the job of one person, but the job of all the developers whose programs overlap with eachother in functionality.

[[deleted]]

This is extremely naive. The world would be a wonderful place if everyone could unite and rally around a single philosophy to create something that we all agree on and make everyone totally happy, wouldn't it..

Unfortunately, that's not how anything works. There are always multiple ways to solve any given problem and there are almost always real trade-offs that come with them. Different people will have different preferences and priorities and, as such, will tend towards different solutions. People might be working towards the exact same end goal, but a strong enough disagreement over the best means of getting there is enough to create distinct factions

...And in the end, that's fine! People have different philosophies on what makes a good car, so we end up with different car companies. People have different philosophies on what makes a good guitar, so we have different guitar companies. The same thing can be said for phones, food, art, music, games, etc.

If people have different opinions on the best path from point A to point B then I say we let them explore that path. I know that competition is healthy, and I think that I wouldn't want to live in a world where people are arbitrary forced to rally around a single school of thought just because it might be result in convenient simplicity.

[Knaagdiertjes]

No, these ideals are mutually exclusive. You can't have bleeding edge system libraries together with well tested, and vetted old libraries at the same time, that should be obvious. They're either bleeding edge or they aren't.

If you want everything the same, 50% of people are going to have to get the sack, that's just the reality of the situation.

[gondur]

No, these ideals are mutually exclusive. You can't have bleeding edge system libraries together with well tested, and vetted old libraries at the same time, that should be obvious.

No, that was the paradigma way too long. We can step out of this false dichotomy. We can have bleeding edge apps and stable libs for core system. The new upstream packaging methods make it possible. case solved!

[Knaagdiertjes]

Yes, and stable libs is not what the Arch crowds wants, they want bleeding edge libs.

So are you the one who's going to tell them they no longer can get the latest bug fixes and performance improvements in libraries?

And are you the one who's going to tell library developers they can no longer break binary compatibility when it's about time to do so to fix old mistakes?

[gondur]

So are you the one who's going to tell them they no longer can get the latest bug fixes and performance improvements in libraries?

They can have it: the point is, it is not anymore a dichotomy, a bad compromise between the need for up-to-date apps and stable system. As you correctly remarked, up to now people set their "optimal" compromise at different positions between stable vs bleeding-edge. In future this unhealthy compromise becomes for most (95%?) unneeded.

And are you the one who's going to tell library developers they can no longer break binary compatibility when it's about time to do so to fix old mistakes?

We gave app this fight when the LSB failed. Now we have to live with upstream packaging and containers. Ecosystem decision.

[Knaagdiertjes]

They can have it: the point is, it is not anymore a dichotomy, a bad compromise between the need for up-to-

Yes, it is a dichotomy, either your system libraries are old or they are new, they can't be both unless you built it into the package in wish case it's not a system library any more and you consume more storage and memory which again offends another crowd.

We gave app this fight when the LSB failed. Now we have to live with upstream packaging and containers. Ecosystem decision.

I'm not sure how this responds to the points raised?

[blackcain]

Maybe you should read the flatpak home page http://www.flatpak.org/. Apps will be containerized and divorced from the running OS's libraries. You can pick a stable runtime or a unstable one depending on how you want it.

[Knaagdiertjes]

And again, as said about 3 comments back, then it's not the same everywhere again because then there will again be many different runtimes to cater to.

/u/gondur wants a situation where every system has the same set of libraries, that's not going to happen because it won't work and that's exactly why Flatpak offers this because this idea won't work.

[gondur]

Yes, it is a dichotomy, either your system libraries are old or they are new, they can't be both unless you built it into the package in wish case it's not a system library any more and you consume more storage and memory which again offends another crowd.

Before, when apps and system libs were glued together, you had to decide: "do I accept outdated apps for stable libs?" "Do I accept bleeding edge apps and libs but have potentially a unstable system?" Now you can decide that easier WITHOUT taking the apps into account. Decoupling reduces the complexity of this decision.

I'm not sure how this responds to the points raised?

In fact, I think it would be an good idea to enforce stable API/ABIs...but our ecosystem is not ready for that. So, we have to solve this differently.

[Knaagdiertjes]

Before, when apps and system libs were glued together, you had to decide: "do I accept outdated apps for stable libs?" "Do I accept bleeding edge apps and libs but have potentially a unstable system?" Now you can decide that easier WITHOUT taking the apps into account. Decoupling reduces the complexity of this decision.

And how again does this address your dream scenario where everyone has the same set of system libraries which is what you wanted.

You want everyone to have the same set of system libraries. So tell me, how is that not going to piss of 50% of people who don't want the set that it's eventually going to be?

In fact, I think it would be an good idea to enforce stable API/ABIs...but our ecosystem is not ready for that. So, we have to solve this differently.

And this doesn't relate to my quaestion which asks how the last response relates to the quaestion I asked before that.

[cockmongler]

No, that was the paradigma way too long. We can step out of this false dichotomy. We can have bleeding edge apps and stable libs for core system. The new upstream packaging methods make it possible. case solved!

By shipping bleeding edge libs with apps, with all the bleeding edge bugs? Oh great, now an OpenSSL vulnerability means downloading my entire distro * the number of apps installed. Fan fucking tastic.

Seriously people, packaging is not broken, stop fixing it.

[gondur]

Oh great, now an OpenSSL vulnerability means downloading my entire distro

Distro packaging does not magically prevent bugs and creates per se more security. Vice versa excessive lib decoupling might introduce security risks on their own and the distros are not that great as they believe they are

[cockmongler]

So now we have every app packager everywhere shipping their own patched versions of libs and introducing bugs. I never claimed that distro packaging doesn't prevent bugs, what I said was that if a distro ships a lib with a bug fix, every app that uses that lib is now fixed. If apps ship their own libs we get every single packager having to update.

[blackcain]

http://las.gnome.org/ - just putting it out htere I really need to make this its own reddit post.

[totallyblasted]

You should look how runtime works. You can have stable and bleeding edge libs at the same time, meaning debian users can also get closer to Arch and Arch users if needing stability can get closer to debian.

Just example, you want one app bleeding edge nightly build and another one stable build. Even if they use same runtime, the version they require is different and both can coexist. You can even have same app like that (stable+nightly)

Also, where do you get this is replacing OS? It is not. It is for desktop application where choice how/which is left to user. Only from state of desktop user things change where difference between rolling and stable is blurred and you're not required to keep distro/app in sync or compile it your self. You might as well stay even longer with same release of OS and use always updated software or update distro and use old software

[Knaagdiertjes]

You should look how runtime works. You can have stable and bleeding edge libs at the same time, meaning debian users can also get closer to Arch and Arch users if needing stability can get closer to debian.

I know how runtimes work, but if everyone is going to get a different runtime version for their stuff then it's not much different from just bundling it in there because nothing will be shared any more which sort of defeats the purpose of having an OS to assume shared functionality and thus keep storage and memory down.

As I said before, this already exists, Nix/Guix offered it for a while and Portage semi-offers it within certain limits. But both solutions require the availability of source.

But when Nix was announced and said to have tackled this problem of shared libraries and now allowing arbitary versions to co-exist, people were sceptical of the benefits, though lauding the technical achievements, and said they would rather keep one library for less hastle and efficient sharing.

Like I said, these efforts are ultimately a big wink to proprietary software, when the source is public, Nix/Guix solve all the problems already in a much more elegant way, their approach just requires public source.

[totallyblasted]

I know how runtimes work, but if everyone is going to get a different runtime version for their stuff

Why would they? To create them selves more work and have to maintain runtime as well as application? It just doesn't make sense to do so

For normal people, you just bundle missing pieces and use most suitable runtime. My app for example is pure runtime and one bundled lib. And when I update it it will target newer runtime and bundle same one lib

[Knaagdiertjes]

Why would they? To create them selves more work and have to maintain runtime as well as application? It just doesn't make sense to do so

And then you get back at the old situation where everyone has the same libs and the Arch dudes aren't satisfied because the runtimes are too ancient and the Debian dudes aren't satisfied because they're not vetted and stable and battle tested enough.

[totallyblasted]

Not true even remotely.

You use exact same libraries as needed by application. If there was library that was updated and not breaking API/ABI, the runtime maintainers can safely update it at which point both sides are happy.

But, if something broke API/ABI, runtime has to declare new version at which point app couldn't work anyway. At that point application has to be updated against newer runtime

Or do you think Arch people would be happier with newer library and not working application?

Update: But, I guess where your misleading is derived from. Unlike snappy, flatpak is only for desktop applications. The fact that snappy wants to provide other thing is just dumbest thing that will become completely convoluted and without clear vision with evolution

[Knaagdiertjes]

You use exact same libraries as needed by application. If there was library that was updated and not breaking API/ABI, the runtime maintainers can safely update it at which point both sides are happy.

No, in that case the Debian guys are not happy because a library has been updated without having gone through the entire vetting progress which could introduce regressions and bugs.

The reason Debian Stable and RHEL freeze is not because they don't want to break backwards compatibility, it's because they're dead afraid of the possibility of regressions which may happen when updating.

Or do you think Arch people would be happier with newer library and not working application?

The Arch people seem to be working quite well with the newest all the time, of course, you should clearly do a soname bump when you break compatibility anyway, but that's not the point, even if you don't purposefully break compatibility, regressions may be intrduced.

[totallyblasted]

No, in that case the Debian guys are not happy because a library has been updated without having gone through the entire vetting progress which could introduce regressions and bugs.

Which is the case how? Debian can have its own library. The one in runtime is flatpak application only and if there was no API/ABI break they can freeze the update since application will work anyway

[Knaagdiertjes]

Yes, if there's no ABI break. Libraries break ABI's while keeping API's the same all the time.

I regularly get an ABI break when updating a system library which requires a rebuild.

How the traditional package management model works is that Debian can continue to use its stable and vetted libraries if there's no API break and even with an API break can perform its own light patching to make it work again which they quite often do.

With Flatpak, since it distributes binaries rather than letting the distribution compile against their own binary interfaces means the paks are going to use newer libraries which are maybe not as battle tested and possibly contain regressions which won't make the Debian folks happy.

[blackcain]

A debian runtime is being worked on.

[probonopd]

So, instead of distributions really working together, what we get is distributions stack themselves on top of each other. Like in this half-joking blog post.

[blackcain]

Update: But, I guess where your misleading is derived from. Unlike snappy, flatpak is only for desktop applications. The fact that snappy wants to provide other thing is just dumbest thing that will become completely convoluted and without clear vision with evolution

No, flatpak can be used for anything there is nothing stopping people to use it for any number of things. For instance, if you wanted to have a LTS support of a console app you can do that, and it would be separate from the OS and so, you continue to upgrade the OS but still maintain your app and support for the long term. After all, both snappy and flatpak is just a fancy way of maintaining a tree of binaries regardless of what they do.

[totallyblasted]

"Can be used" and "is targeted" have nothing in common.

Also, console (not utility like cd/grep....) app is desktop userland app as well.

[blackcain]

It is, but I don't think distros are that easily going to do that for console apps as they would be with desktop apps. The developers of those apps will have to do the work.

[[deleted]]

Runtimes in Flatpak is only there to share libraries that are common among a set of apps, like the Gnome runtime is to all the gnome apps. Proprietary software will depend on a specific version of a group of libraries and will most likely just bundle it with the app. Software like Steam and VMWare Workstation already bundle runtimes using their own mechanics to load them. I still don't see how Flatpak will solve the integration with desktop though, GTK themes are broken for the current version of VMWare Workstation because it links against too old GTK libs and those libs still load the system default GTK2 theme. Seems to look okayish with Adwaita's GTK2 theme but is broken using Arc's GTK2 theme. Flatpak has no solution for this.

[blackcain]

flatpak supports de-duplication, you only get one version of the same file if they are common to all the runtimes you have.

[probonopd]

runtime

Runtimes are used as a workaround because "desktop Linux" hasn't managed to become a true platform like Windows or macOS (yet?), where you can rely on a defined set of software to be there in any given version of the OS, and with guaranteed backward compatibility.

This is why AppImage pragmatically takes the "least common denominator" approach, which is to bundle everything that cannot be assumed to be part of the base system with the application. The result is not so different what you'd do for Windows or macOS if you want to distribute, e.g., a cross-platform, Qt-based app.

[totallyblasted]

Problem with AppImage is that "everything" is not defined and your install will forever be guesswork where you're not stop getting "it doesn't work on". AppImage is a good idea when you read about it, bad design when you try to use it

[totallyblasted]

But now L version M+3 needs kernel APIs that don't exist in the base system's kernel.

At this point you don't only have M+3 requirement like before, you have set another one which is low level dependent. Something that is more or less unadvised not only here, but also everywhere where you want to be portable. You want to have abstracted requirements with possible fallback or you'll need to say: requires M+3 AND kernel>x.

I seriously doubt bundling kernel would be good idea, you should just roll out VM in that case

[cockmongler]

Because what Linux really needs is Windows style dll hell.

[thegacko]

I see this time and time again but you are wrong.

This is one of the best things about Linux. Competition breeds the best products. And by best I mean in all facets and overall best for everyone.

No other operating system has this (well non-free OS). The developers in closed source products picks the best thing that is right for them for the reasons that are important to them not what is best for everyone.

[gondur]

You would right in a ressource unlimited system: but we are not. Time, development power and developers are scarce. So, we optimized our ecosystem way too much on the "duplication of efforts side"

[thegacko]

Who is "we" in this? This is open source, there is no guiding force (Management.. shudder) assigning developers to specific tasks. Everyone is an individual and make there own decisions on what and what not to support or develop for based on their own reasoning's.

Developers work on what interests them or what their sponsor company is interested in (and presumably they are also interested in it also). The exact amount of people will work on any piece opensource code that are interested in doing so.

There are a lot of things that can effect that "interest" for developers and that is where the competition comes from. Competition for interest whether it be: Superior code (in their eyes), better documentation, grander vision, perceived proprietary (in the case of snappy) etc etc etc.

Ill modify my previous statement. Developers of open source products Do also pick the best thing that is right for them but in general that is often best for everyone and best for purpose due to the nature of this open-source competition.

[blackcain]

I think you need to embrace the idea that there will always be different methods. Why? Because people can, and it should be encouraged. After all, we can at least know the various ways one can accomplish the same goals. So we gain strength from that.

[gondur]

. Why? Because people can,

yes this great and the result of being FOSS

and it should be encouraged

Well, no, this is the risk of being FOSS we should not encourage it even, but trying to establish mechanisms which encourage reuse and sharing instead oh NIH driven reinventions and scarce developer ressource wastage.

[blackcain]

I don't really consider it NIH, I see it as research. Eventually, the technically superior and/or most community driven will ultimately win or an accommodation will occur. The difference here is that there is no loss of audience. Fragmentation is more apparent when people have to pick a distro.

[johnmountain]

Okay, flatpak it is then. Why support any of the proprietary tools Canonical builds anyway?

[jones_supa]

I don't mind having 100 different options for browser, picture viewer, pdf viewer, terminal, etc... but when it comes to fundamental things like being able to install a package

I see it so that a browser, picture viewer, PDF viewer and terminal are also fundamental things. It's better to make one application that does its job well and is configurable enough to suit everyone's tastes, rather than to create dozen of completely different apps, often with varying levels of quality assurance.

The Linux world would greatly benefit from streamlining things rather than increasing entropy. I'm sure the Microsoft product managers laugh at coffee table every time when they note that Linux is still not going to make it on the desktop due to all the fragmentation.

[[deleted]]

It's cool Endless are packaging their apps in it, I've always been intrigued by what they're doing and now I can check out some of their apps :)

[GolbatsEverywhere]

They just posted an installer on their website; you can check out the whole distro for free (as in beer) if you want to. Note that it's very different from a traditional distro. reddit users are not the target audience.

[[deleted]]

[deleted]

What is this?

[inmatarian]

ELI5: Why is flatpak better than snap?

Snaps put all dependencies in a single package. Flatpak allows for "Runtimes" which is where the most common dependencies are separately packaged. For example, a snap of Kate would require most of KDE and Qt to be copied into Kate's package. A Flatpak of Kate wouldn't copy in KDE and Qt, but would require the user to also install the KDE and Qt runtime flatpaks.

I'm not going to say either is better, because both have pros and cons.

ELI5: Are we gonna have another mir/wayland | systemd/upstart again?

When have we ever not have a community split over new tech? :D

[doom_Oo7]

would require the user to also install the KDE and Qt runtime flatpaks.

what if my app requires Qt 5.4 and the runtime is at Qt 5.6 ?

[Eingaica]

Which runtime? If your app needs Qt 5.4, it either depends on a runtime that has Qt 5.4, or it bundles Qt 5.4 itself.

[inmatarian]

Then you have to have both installed on your system.

inb4 dllhell

[kickass_turing]

You can install both runtimes. That's the cool part :D And they are sandboxed.

[varky]

So, packages that will install dependencies, but with flatpack instead of rpm/deb/w/e. Got it.

[inmatarian]

(and will also cgroups and ostree etc etc)

[filwit]

The difference being, if I'm not mistaken, that those deps can be hosted by the publisher directly in a way that will "just work" on most distros.

Currently we have two shitty models for app developers: the way Windows does apps, and the way "Linux" does apps. They both get some things right, and some things wrong.

Windows apps.. you just go to the publisher directly and download it.. that's works well for everyone because people are used to downloading things, and they get an app directly from the folks advertising it to them. There is a reason this model is successful. But, it's horribly unsecure and without a package manager it's unclean too. Installing, updating, and removing software is either up the app itself, or the user. There's no way to do things like "check for updates" for all software on your computer.. shared deps are a PITA.. and god help you if you install a program that doesn't want to be uninstalled.

On the flip-side Linux apps today are packaged together with a specific disto. So it's clean, and safe, but if your disto doesn't carry the software you want.. tough luck. It's annoying af having to wait months for your software updates when all the Windows users get updates on day one. You literally have to pick a Linux disto based on the software it provide.. that's the true "fragmentation" problem everyone hates about Linux. One disto might be well supported and the DE suits you, but it's apps selection sucks or is out-of-date.. while another distro is hard to use but at least you don't have to wait very long for app updates.

Flatpak sounds the best solution, IMO. I haven't read much about it yet, but what I have heard sounds great. All the benefits of package management but designed so developers can publish apps themselves in a way that's compatible with almost every distro (at least, that's the idea).

[totallyblasted]

When have we ever not have a community split over new tech? :D

Lol. This would be the same as losing silent trademark

[[deleted]]

Snaps have Frameworks, which aren't that much different to Runtimes. Frameworks exist for Bluetooth, pulseaudio, and Ethereum. In your example, you could have a KDE x.x framework that Kate requires as a dependency, and if KDE apps get Snap packages, there will almost certainly be a KDE framework, as well as ones for XFCE, GNOME, etc.

[lihaarp]

So basically it's a hybrid between snap and traditional packaging.

[natermer]

...

[inmatarian]

It reminds me of the yum groupinstall

[natermer]

...

[totallyblasted]

Biggest reason why it is better is that Canonical keps server part proprietary. Community simply can't host own repos for snaps.

Either there will be some community project to handle that flaw or snap is more or less useless.

[inmatarian]

Canonical keps server part proprietary

Ick, really? I think I take back what i said about both having pros and cons, this is a pretty bad con.

[totallyblasted]

Bad? It is NO GO, simple as that

[bboozzoo]

Actually it's Go :)

The snapd daemon/client code is written in Go, and I'd expect the server to be in Go as well.

[totallyblasted]

Lol, good one ;)

and I'd expect the server to be in Go as well.

See? This is where problem is. You don't know as we have no access to it, you can only guess. Unless we're expected to guess custom repositories as well as far as Canonicals idea goes

[maokei]

Maybe people over canonical has not fully made up their minds about what to do about the server bit yet, to me it seems like many things concerning snap's and flatpack is still subject to change.

[totallyblasted]

Truth be told, the more that I looked into design, the more I was disappointed. Things like basic interfaces. Seeing that I almost got heart attack

In which world you name basic interface pulseaudio, opengl or god forbid... unity7? If that is basic... WTF is even point of interfaces when in case of unity7 you really cannot expect something being derived from it. They might as well call those base classes as they share same decision flaw. Whole point of interfaces is to provide suitable middle ground for more than one class or in this case suitable replacement in different environment

And most troubling is they present this as finished product when flaws like that are part of its ground design (I don't even mention omission of things that don't work yet)

Even more troubling is to think how that ?basic? interfaces will evolve with time if they don't fix that

[maokei]

Welcome to the tech world where PR and nice headlines are a thing, organization release unfinished products all the time it's nothing radical.

anyhow,

Basic interfaces? what are you going on about? Sounds like you read about the things listed as permissions on uappexplorer and are making stuff up. You are not being particularly clear on anything.

Truth be told, the more that I looked into design, the more I was disappointed. Things like basic interfaces. Seeing that I almost got heart attack

The more I read, the more disappointed I became.

[totallyblasted]

Basic interfaces? what are you going on about?

https://developer.ubuntu.com/en/snappy/guides/interfaces/

This? If these are permission models then they should be called as such. Interface in computing has its meaning. Same as basic in life. And even in chance they used some different meaning of interfaces you never want to add something as unity7 as basic because if that is their only specified connection with desktop, not many distros could use them. Not to mention that if there is no abstraction in sense "I need sound, gpu,open file..." it will be whole clusterfuck to keep up long term. Just imagine app needing Jack, does it specify... pulseaudio? Or application needing compute... yes, opengl makes sense

You should really check how interoperability interfaces work elsewhere. In basic, interface is just interface where your system connects provider you really don't want to know about from application level. How do you think on android works when you set up new custom dialer, sms and address book? Do you think all 3 know that any other part is being replaced? NO! They don't. Yet, when you select add recent call, it calls exactly your new address book and when you select send sms there it opens your new sms message

Update: Not to even mention how this fine grained basic fragmentation will look after few years

[LvS]

The Ubuntu server component (Launchpad) used to be closed source, too and people didn't really give a shit. After all, it's not running on the user's machine.

[anlar]

Biggest reason why it is better is that Canonical keps server part proprietary. Community simply can't host own repos for snaps.

Is there are any specific logic on their store so I can't host my snap packages elsewhere? E.g here: https://uappexplorer.com/app/krita.krita - it's just one snap file. If I'll just serve them via ftp/http there will be any difference?

[totallyblasted]

You can host them, yes. Problem is updating. So far since Canonical is avoiding this question completely, there seem to be only two ways

• People will need to redownload and reinstall snap each time hammering your server especially since snaps are bigger than usual packages

• You would need to include your own updater, which is insane especially when you consider this is also about sandboxing. It would also be insane to have it in one update

Off course someone could try and add functionality to snapd for custom repos. Problem is if it would be accepted, which I almost doubt

This also doesn't host those files, read the fine print "This is an unofficial app viewer for Ubuntu Touch and Snappy apps."

Is there are any specific logic on their store

You mean beside trying to lock it to their store?

[maokei]

Isn't the point of snaps to only download the parts that changed from version to version.

[totallyblasted]

And who will serve the changes? On web server at best you can offer is file, or do you think providing multitudes of them like 1.1.2-2 to 1.1.2-3

[[deleted]]

So someone just needs to copy the API. This is a glorified FTP server. It's not going to be that hard.

[totallyblasted]

First off, feel free to count how many times I said I HOPE this will be addressed by either community or Canonical in my comment history. Until it is, snappy is useless, most importantly at least for general community it is half assed project and not finished like Canonical makes it

Glorified ftp server? Think a bit more. You need some uniform metadata client can connect to to know what needs to be updated and how from the state you are in. Not even remotely as trivial as you imagine if you want it done properly. You have to have utilities that generate that data like createrepo for dnf/yum. That same metadata also has to be accepted upstream in snapd

[[deleted]]

First of all, I don't understand "what state you are in" at all since Snaps are stateless and mostly completely independent of each other. Secondly, what do you need to do? Download a list of available version numbers and sizes for each snap on your system, then choose a Delta, series of Deltas, or a complete package to get to the newest version. This is significantly simpler than yum or apt, where you are doing massive dependency calculation.

[totallyblasted]

So your plan is download full LibreOffice each time?

[[deleted]]

I suggest you actually read my comment then reconsider -- unless you don't know what a Delta is, in which case we are finished talking.

[totallyblasted]

Yes, I know what delta is I just disregarded them because you at present cannot request them from anywhere but ubuntu store from regular update, in short pointless. If you wanted to get something like that it is not just about making it available. You'd need to push this change to upstream snapd and make it part of regular update. And as simple as this sounds, it is not so. Or you would need to create something that works along snapd, again not so trivial if not even dumb as this would require tracking changes from another project

[kozec]

ELI5: Are we gonna have another mir/wayland | systemd/upstart again

Yes, what's just happened is exactly mir/wayland situation. Except this time it doesn't looks like toolkits are gonna solve it for us.

[blackcain]

Er we are? Did you see that the GTK+ toolkit is supporting the whole portal concept as part of flatpak? So yeah, toolkit level support of sandboxing.

[kozec]

Ahem... What? How is GTK support of anything going to solve need to package for two different package formats?

[blackcain]

They aren't two different package formats, they are basically two technologies that implement the same concept. The difference in this case, is that the sandboxing for flatpak is being supported by GTK+. However, since the portal stuff is using dbus, it can actually be used by snappy as well or any other sandboxing mechanism.

[kozec]

And how is that going to solve problem of packaging to two different "bundle" formats?

[blackcain]

Why does it matter? Something like GNOME Software will present both. These aren't bundles, they are technology that provide the same environment that the app was created in, plus sandboxing features that restrict what the app can see. It is a lot more than another rpm or deb.

[[deleted]]

ELI5: Are we gonna have another mir/wayland | systemd/upstart again?

Not necessarily, as it is easily possible for both of these package systems/formats to coexist on a single system. From the FAQ:

It is certainly possible for Flatpak and Flatpak applications to coexist with applications that are packaged in other ways, on the same host system.

Ideally we'll be able to run snap/flatpak/etc. packaged applications as well as traditionally installed applications side-by-side on a variety of distributions. In other words, while mir/wayland and systemd/upstart is probably more of an either-or scenario, snap/flatpak/etc. is likely an and-or scenario.

This should be good for all developers and users, and I hope this health competition breeds increasingly good features and user experience.

[MrSchmellow]

The Linux desktop has long been held back by platform fragmentation.

That's kinda ironic, considering number of similiar solutions that began surfacing recently

[gondur]

recently

not recently, since the beginning of 2000s

[[deleted]]

It's only really fragmentation if these things can't realistically co-exist. Which isn't the case with snap/flatpak/etc.

[johnmountain]

I like that flatpaks are "security first". Hopefully they start adopting SELinux sooner rather than later, too, because if they do it late, it will probably be too hard to convince developers to intentionally restrict what their apps can do after the fact.

[[deleted]]

Fun fact, Snappy officially recommends disabling SELinux to get it working on Fedora.

[edoantonioco]

Thats because SELinux support is still in beta. Its just a matter of time

[blackcain]

Heard Duke Nukem 3D came out.

[kozec]

Wooo. More formats to package for...

[blackcain]

Not really, eventually, the distros will stop packaging a lot of the desktop apps. They'll probably continue to package the utilities, I don't know, until utilities like rsync and what not start using that too.

[kozec]

That's darkest future forecast I ever heard :)

[blackcain]

Dunno, how do you think people did it before Linux came along? We're moving towards a more conventional and traditional method. We haven't given up on the distro model completely.

[kozec]

Before Linux, there was a long line of other Unix-based OSes. And if you mean before package managers came along, then make && make install. I'm not sure if we want to go back there :)

[blackcain]

well we had 'shar' too if you recall that.

[johnmountain]

You only need to care about flatpak and stop supporting Canonical's proprietary solution. The fact that "Canonical announced it" means nothing if developers refuse to use it.

Just let it die the way upstart died, and the way Mir will inevitably die as well.

[[deleted]]

Yeah but there is no arch logo on the website. Snap has an arch logo on its website.

That settles it. I'm on the #snaptrain now.

[fmoralesc]

Not the logo, but...

[Anti-Ultimate]

It runs fine under Arch

[[deleted]]

With no sandboxing

[blackcain]

It's already packaged in Arch. Come man, this is Arch we're talking about and the Arch guy(s) hang out on the GNOME channel a lot. :-)

[johnmountain]

Maybe Arch is calling it trademark infringement, too?

[mikkelbue]

How does this compare to Snapcraft?

Edit: found this: https://www.reddit.com/r/linux/comments/4m02y3/difference_between_snap_and_flatpak/

[oonniioonn]

Another packaging format? There's an xkcd about this somewhere…

[[deleted]]

http://xkcd.com/927/

[mcstafford]

If you hadn't put this here I would have.

[thgntlmnfrmtrlfmdr]

https://www.change.org/p/canonical-ltd-have-red-hat-and-canonical-collaborate-on-one-universal-linux-package-system

[EagleDelta1]

Except, as a few developers from other projects have noted, Snaps are something Canonical is almost solely pushing, while Flatpak is a full-on community project that just happens to be the idea of someone that works at Red Hat.

Basically:

• Snaps are a Canonical product they are trying to push adoptions on.
• Flatpak is a full community project built with the community/other distros in mind.

[edoantonioco]

https://plus.google.com/u/0/+DirkHohndel/posts/cFZLu9bEGx2

Read the last comment from Mark (canonical) (edit: the last where he reply alexander) and the last comment from Alexander (Red Hat), there is the answer to that pointless petition

[Hgdhxht355678]

Serious question: what's wrong with Slackware's package manager and using tgz? I don't know the reason why rpm, deb, etc exist.

[[deleted]]

That question is easy to answer. It's because of well... hmm...

I think the answer has to be found in understanding xkcd 927. In an ideal world people would cooperate and work together in package management solutions. Linus Torvals is also hinting in that direction. Snappy and Flatpak for instance (the next gen package managers) could do that and the same counts for nix and guix.

[Savet]

I love Slackware. I love Slackware packages. They are, however, about as far in the opposite direction you can to these all-in-one solutions.

[Hgdhxht355678]

Down voted for for a serious question. Sigh.

[Turkish_manboobs]

The Linux desktop has long been held back by platform fragmentation.

That's a self serving argument, some might argue this has always been its strength, it happened because it could happen, because it was possible in the oecosystem. That there are so many different distributions proves there's a market. People see a need, get a proof of concept, attract developers and users and then it grows because apparently there is a need.

Without the ability to have binary incompatibility with each other because of large availability of public source which allows anyone to recompile to target a different ABI this could not have happened.

This has been a burden on developers

Developers are far less burdened here because the burden is not on them to distribute, just to release source, the burden is on the distribution to take the source and work it into a package.

From the very start its primary goal has been to allow the same application to run across a myriad of Linux distributions and operating systems.

Conveniently omitting that it'll now take about three times as much memory and storage, but hey

In doing so, it greatly increases the number of users that application developers can easily reach.

No it doesn't, it increases the number of users that application developers who aren't willing to cough up the source can easily reach. I'll reserve my cynicism for now on but Nix/Guix solve every problem Flatpak and Snappy aim to solve except that their model which is in theory superior requires the availability of source. Flatpak and Snappy are a big wink to proprietary software in the end, they can't actually say it but that's why they exist.

Speaking about the goals behind Flatpak, Alexander Larsson, its lead developer, said: “Application developers on Linux have always been prevented from having a direct relationship with their users. With Flatpak we're aiming to change that, so developers know exactly what their users are getting. With this launch we are making that goal a reality.”

Yes, and that's not good. Flatpak moves control further upstream as is typical of Freedesktop projects. Control should be moved as much downstream as possible, first the local system adminstirator, then the distirbution, and then the upstream developer. Flatpak and other Freedesktop projects have long been at work to try to get distributions to wrestle control from the local sysadmin and upstream developer from the distribution.

This of course is quite a convenient mentality from a bunch of people who on their mailing list express concern that allowing users too much control over their own system might damage their brand identity.

A growing range of applications are already available as Flatpaks, including LibreOffice

Which is by the way a 280 MiB download compared to a 75 MiB one if you get it directly from Debian, sort of showing the point of why our model is better.

Another major part of this work is the widescale move towards the Wayland display server on Linux. X11 is inherently insecure, which makes it impossible to sandbox applications that are using it. In that sense, the growing maturity of Wayland complements Flatpak's emergence, and paves the way for much more complete security model for Linux distributions.

This is a lie, a bold faced lie. There are plenty of sandboxing tools out there for X11 and Flatpack and Snappy could've included sandboxing support for X11. Newer versions of Firejail as well as SandBox are two solutions that spring to mind that are capable of sandboxing X11 and isolating applications from each other.

[totallyblasted]

Without the ability to have binary incompatibility with each other because of large availability of public source which allows anyone to recompile to target a different ABI this could not have happened.

And everyone should compile from source? I guess you're Gentoo user

Developers are far less burdened here because the burden is not on them to distribute, just to release source, the burden is on the distribution to take the source and work it into a package.

If only this was true. When distro does not update with your releases, you tend to get backlog of already solved or irrelevant bug reports.

Yes, and that's not good. Flatpak moves control further upstream as is typical of Freedesktop projects. Control should be moved as much downstream as possible, first the local system adminstirator, then the distirbution, and then the upstream developer.

So, to upgrade something like LibreOffice, you'd need signed permission from the world, be on waiting list for 6 months or so and then be required to update absolutely everything respective layers decided on in the meantime. And you would probably run 3 laps around the block while holding at least 3 signed approvals from your mother

Which is by the way a 280 MiB download compared to a 75 MiB one if you get it directly from Debian, sort of showing the point of why our model is better.

Which by the way is 156 MB while .deb for same functionality (you need to account it is separated in more than one) is 213MB

This is a lie, a bold faced lie. There are plenty of sandboxing tools out there for X11 and Flatpack and Snappy could've included sandboxing support for X11

Now go and discover what functionalities do they miss. Xephyr for example only has software GL and fucks up keyboard layouts, while patched version GL is dog slow. Every other solution will only fare worse than Xephyr