GNOME 3.21.2 Released With More Wayland Improvements, Flatpak

[Anvil]

Empathy, i have never really used the crap. but will it now use Webkit? i think it was supposed to be ported over to webkit if im not wrong. . Ubuntu IMO is just getting step closer to being a .exe extension OS

[forgiver]

I've had no issues with wayland gnome, aside from 2 main issues, which aren't related to gnome.
Firstly, mpv has a fullscreen issue where it won't fill in black for video aspect ratios that don't exaclty match the screen.
Secondly, wayland doesn't support the necessary bits required by redshift to work

[Akka]

I've had no issues with wayland gnome, aside from 2 main issues, which aren't related to gnome.
Firstly, mpv has a fullscreen issue where it won't fill in black for video aspect ratios that don't exaclty match the screen.
Secondly, wayland doesn't support the necessary bits required by redshift to work

What is different between the support needed by redshift and colord. I get the impression gnome is supporting color profiles?

[forgiver]

What is different between the support needed by redshift and colord. I get the impression gnome is supporting color profiles?

Actually, colord is something i will have to look into it. I only know that redshift doesn't when i use wayland on gnome, even 3.20.2. There is this:

https://github.com/jonls/redshift/issues/55

[feregember]

So, it's going to again have 2 standards for the containerized apps (Snap and flatpak) ? why ?

In 2013 kernel 3.8 shipped with completed namespaces support, a software isolation technology built into the kernel. People started to experiment with it (and with cgroups, selinux, ..) to solve both the security and package dependency problems. Since then, some experiments became a product, like AppImage, Docker, Snappy, others.
So there are actually many new software packaging formats. It's a hot area, expected to cool down in the coming years.

Because once again, Canonical decided to go their own way. Flatpack is the renamed XDG-App, that has been in development for a while now

Canonical started it's ubuntu phone project years ago. A key component is the distribution and isolated running of apps. It was called Clicky, and renamed to Snappy later.
Alex Larsson's ideas and work in the topic was previously marketed as a freedesktop.org solution (xdg-app), recently as a Gnome software (Flatpak).
I dont see why canonical should throw out years of work (which is already in use) just because someone is developing his own solution.

(Flatpak) is arguably the more secure solution since the libraries can be updated. Snap is Canonical's faster-to-market route which goes with basically static libraries.

System security in the new system is ensured by app isolation.
Let's say a person or company considers developing a software for Linux (hooray ). The software depends on 50 libraries directly or indirectly. Each of those dependencies has 30 versions in the distribution (not including modified home-compiled packages). They want to provide support for the last 10 versions of they SW, so they can get support requests from any of the 10*50*30 = 15000 combinations.

[bkor]

Canonical started it's ubuntu phone project years ago. A key component is the distribution and isolated running of apps. It was called Clicky, and renamed to Snappy later.
Alex Larsson's ideas and work in the topic was previously marketed as a freedesktop.org solution (xdg-app), recently as a Gnome software (Flatpak).
I dont see why canonical should throw out years of work (which is already in use) just because someone is developing his own solution.

GNOME software uses xdg-app/flatpack. GNOME software using flatpack does not make flatpack GNOME specific. It can be used for loads of things.

Canonical usually goes for solutions which only will work for them, plus always trying to get ownership of parts of the stack. E.g. the required server bits are secret. While pretty much any other solution is usually designed to be reused, also by competitors. That's a hugely different approach as well as the reason various Canonical solutions always end up Canonical-only.