Canonical Reportedly Not Planning To Enable Wayland-By-Default For Ubuntu 20.04 LTS

[Weasel]

It doesn't need to be better, it needs to be more modern.

Maybe for tools like you and other fashionistas.

[Creak]

Maybe for tools like you and other fashionistas.

No need to be condescending.

[Weasel]

No need to be condescending.

If you don't use what's better for you, but instead use what is "more modern", you are the DE or society's tool.

[Creak]

If you don't use what's better for you, but instead use what is "more modern", you are the DE or society's tool.

I actually use what's better for me (i.e. X.org) but that doesn't prevent me from looking at alternatives and their benefits compared to the current standard.

But indeed, if I don't have the same opinions as yours, then I must be just an ignorant sheep raised by this evil society and thus unable to think by myself! Oh poor me!

[vegabook]

That's the first place you're wrong. Wayland simply isn't failing, anywhere except in your mind. Wayland has been a huge success so far, and only has more success to come in the future.

Delays don't mean failure - delays are inevitable in any major software project. The last 10% of a project always takes 90% of the time, it's one of the first things you learn. The only thing that's failed is certain fanboy expectations which were never realistic in the first place.


That's not the only thing it can offer end users, but I will actually agree with you 100% that it's still too buggy for users to switch over and there's not a strong reason for them to. That's as it should be. Wayland is a low-level system the OS cares about. Users shouldn't be expected to care one way or the other whether it's running or not, things should just work regardless.

Here's where the fanboyism hurt Wayland, because people were on message boards claiming it would cure cancer or sprout unicorns or something, and that was never going to happen. But it does have a few decent upsides to it, and it will go out when it's ready and users won't notice any downsides.


Wrong. The problems just need to be fixed, something that is happening.


Huh? I'm not sure where you're going with this... Vulkan can be used by Wayland compositors, of course, there's nothing stopping that. I honestly haven't heard of anything that would go in a completely different direction like you seem to be suggesting here, even in passing, let alone anything that would be taken seriously. I'd be interested if you could elaborate on this point.


Definitely not the only thing it has going for it.


So is windows 95, but that doesn't mean we shouldn't try to create something better 20 years later.


That's all compositor details, which isn't at all comparable to Wayland as a technology. You can do the same thing on Wayland if you want (and in fact MIR now supports Wayland as a backend) - which is all to say that you're just comparing Mir to KWin and Gnome Shell, not Wayland.

I'll even agree with you that I was disappointed to see Mir the desktop shell dropped by Canonical. I don't think that was good for anyone. I also don't think it says anything at all about Wayland, though, other than maybe they could have succeeded in keeping it around by lowering development costs if they had been content to base it off others work first instead of doing everything from scratch themselves.


Agreed, but it does make it pretty silly for someone to come around and claim that it's less of a failure than Wayland.



And there I sadly have to disagree once again. With open source software, it's not user pull that creates software success. It's developer pull. User pull can generate that developer pull for you, but there are other ways of doing it as well - such as a big push by Red Hat. User pull isn't why systemd is everywhere right now. It's not because a million different users couldn't wait to get it on their systems and play with it. It's because Red Hat built an ecosystem around it while making it a technically superior (or at least good enough in comparison to it's competition). If they do the same thing with Wayland - and all signs point to that currently being in the process of happening - then you'll see the exact same thing happen again. Distros will port over one by one, and there will be massive wailing and sobbing by various fanboys when it happens, but it's still going to happen. And in the end, everyone will be the better for it.

Wayland isn't like a browser, that users directly interact with and will download a new package in order to get their preferred UI. It's a hidden OS service that just needs to work invisibly. Users shouldn't even know the name Wayland or X, they should just be using whatever their distro provides and not have to think about it.

smitty3268

Now here is something interesting:

https://www.omgubuntu.co.uk/2019/04/new-project-brings-android-apps-to-the-linux-desktop

Works only under Wayland looks like.....

[Luke]

In my opinion wayland by default should wait until icons on the desktop can be done natively in wayland, rather than requiring an instance of nemo-desktop (or a future caja-desktop splitout) on xwayland. GNOME isn't interested it seems in pursuing that with their own resources.

On another note, someone mentioned replacing apt with snaps. That would be rather extreme, worry that Ubuntu was going down that path was exactly why I switched my continuously updated systems (which require backward compatability) to Debian from Ubuntu years ago. Snaps and Flatpacks are in my judgement best for stuff that's hard to deploy cross-platform. They strike me as good for dealing with complex toplevel apps that have issues with handling varying system library versions, and optionally as a contained way to update such an app on an older system.

Their downside of using this for ALL toplevel apps is the same as Windows apps that ship all their own dlls: massive filesystem volume, download volume, and RAM consumption if that many copies of the same libraries are downloaded, stored, and loaded multiple times.

[starshipeleven]

On another note, someone mentioned replacing apt with snaps. That would be rather extreme, worry that Ubuntu was going down that path was exactly why I switched my continuously updated systems (which require backward compatability) to Debian from Ubuntu years ago. Snaps and Flatpacks are in my judgement best for stuff that's hard to deploy cross-platform. They strike me as good for dealing with complex toplevel apps that have issues with handling varying system library versions, and optionally as a contained way to update such an app on an older system.

This is true only for Flatpak, Snap can also be used as "normal package format" too (i.e. nothing more fancy than what .deb packages are doing already).

[Luke]

This is true only for Flatpak, Snap can also be used as "normal package format" too (i.e. nothing more fancy than what .deb packages are doing already).

Interesting. Anyway, removing dpkg and APT would screw up my local package management. Not going to do that here.

[ssokolow]

This is true only for Flatpak, Snap can also be used as "normal package format" too (i.e. nothing more fancy than what .deb packages are doing already).

Is there a way to selectively blacklist the ones which work via loopback device mounting? I ripped out snapd to prevent those things from getting set up.

[starshipeleven]

Is there a way to selectively blacklist the ones which work via loopback device mounting? I ripped out snapd to prevent those things from getting set up.

AFAIK no, but I'm by no means an expert.

From what I know about the enemy side (I'm not a Ubuntu user)their idea is to have most application snaps as read-only loopback devices, while the "normal package format" ones that drop stuff in a /snappy folder are the "legacy snap" format which may or may not still exist in the future, and the "normal package format" ones that can install freely in the system are reserved for system components (kernel, base libs and whatever).