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

How Not to Support Desktop GNU+Linux, Zoom Edition

write.as

Post reply on HN
Print view View original

121–130 of 223 posts

Re: How Not to Support Desktop GNU+Linux, Zoom Edition

#121

Post by ihattendorf »

yjftsjthsd-h wrote: post #77
chaorace wrote: post #62

Earlier quoted context omitted.

I guess the core problem is the false advertising. Zoom "supports" Wayland-only distros... with the fine print that they only support outdated builds from before the switch to Wayland. Aside from that, my only complaint is that Zoom is unavoidable and thus the lowest common denominator. If Zoom doesn't work with your window system, you're forced to give up and change... even if it's the only piece of software in your…

> I guess the core problem is the false advertising. Zoom "supports" Wayland-only distros... with the fine print that they only support outdated builds from before the switch to Wayland. They support the distro just fine. They might not support one of its graphical layers, but you can run Zoom on Xorg on the same distro just fine.

I would say advertising support for Fedora (or any other Wayland by default distro) without explicitly saying you don't support Wayland/only support X11 is misleading.

Re: How Not to Support Desktop GNU+Linux, Zoom Edition

#122

Post by faisal_ksa »

homarp wrote: post #113
faisal_ksa wrote: post #107

A game developer [1] once said that Linux "accounted for 20% of auto reported crashes and support tickets." Unfortunately, this is the reality of Linux. It's very hard to support due to its fragmentation. It requires so much effort to work in a fast-changing environment that a few users even use. To make Linux easier to support, we need to make it as easy to develop as Windows, macOS, iOS, and Android. We need a unif…

And another game developer [1] > The report quality [from Linux users] is stellar. I mean we have all seen bug reports like: “it crashes for me after a few hours”. Do you know what a developer can do with such a report? Feel sorry at best. You can’t really fix any bug unless you can replicate it, see it with your own eyes, peek inside and finally see that it’s fixed. And with bug reports from Linux players is just so…

I have no doubt that Linux users are awesome at reporting, debugging and finding problems. Also, they tend to be tech-savvy. So reporting bugs are not a big deal for them. Unlike most average users.

My argument was about how hard it's to develop and support software for Linux. Not about the users. You have to admit that Linux (due to its fragmentation) is a nightmare to support. And it has a very small users base to justify putting the effort to support all Linux distros and all desktop environments and hardware configurations and Wayland and Xorg ...etc.

I like Linux, and I wish I could use it all the time. But to be honest, it's more work than what I'm willing to do.

Re: How Not to Support Desktop GNU+Linux, Zoom Edition

#123

Post by [deleted] »

duiker101 wrote: post #116
bArray wrote: post #111

How Not to Support HTML Text, write.as Edition: > If you're stuck using Zoom, jump on [one]( https://community.zoom.com/t5/Meetings/Sharing-application-w... ) [of]( https://community.zoom.com/t5/Meetings/Linux-screen-sharing-... ) [the]( https://community.zoom.com/t5/Meetings/Unable-to-share-scree... ) [..] Why do you need JS to translate your unreadable HTML into readable HTML?

> _Pssst, coming from Hacker News? Add a ".md" to the URL_ This might have been added after your comment. Link with md: https://write.as/n5r0vjolumdnuk2k.md

[deleted]

Re: How Not to Support Desktop GNU+Linux, Zoom Edition

#124

Post by hackmiester »

bArray wrote: post #111

How Not to Support HTML Text, write.as Edition: > If you're stuck using Zoom, jump on [one]( https://community.zoom.com/t5/Meetings/Sharing-application-w... ) [of]( https://community.zoom.com/t5/Meetings/Linux-screen-sharing-... ) [the]( https://community.zoom.com/t5/Meetings/Unable-to-share-scree... ) [..] Why do you need JS to translate your unreadable HTML into readable HTML?

I don't think it was caused by your lack of JS. I have JS enabled and it still did this until I altered the link.

Re: How Not to Support Desktop GNU+Linux, Zoom Edition

#125

Post by CameronNemo »

duiker101 wrote: post #116
bArray wrote: post #111

How Not to Support HTML Text, write.as Edition: > If you're stuck using Zoom, jump on [one]( https://community.zoom.com/t5/Meetings/Sharing-application-w... ) [of]( https://community.zoom.com/t5/Meetings/Linux-screen-sharing-... ) [the]( https://community.zoom.com/t5/Meetings/Unable-to-share-scree... ) [..] Why do you need JS to translate your unreadable HTML into readable HTML?

> _Pssst, coming from Hacker News? Add a ".md" to the URL_ This might have been added after your comment. Link with md: https://write.as/n5r0vjolumdnuk2k.md

@dang can we get the link updated?

Re: How Not to Support Desktop GNU+Linux, Zoom Edition

#126

Post by indymike »

Long story short: Zoom does not work well with Wayland.

I use zoom daily on Ubuntu. Its wonderful to have apps like Zoom that actually work and support Linux.

Every so often I fire up Wayland and end up switching back because enough apps just get weird on me... Maybe one day it will work. Until then, I'm good.

Re: How Not to Support Desktop GNU+Linux, Zoom Edition

#127

Post by Georgelemental »

mikepavone wrote: post #101

I think this is somewhat of a self-inflicted wound by the developers of the Linux desktop here. Linux+Wayland is the only major desktop environment that requires you to use an OS-provided dialog to pick the window you want to share when screensharing from a desktop app. Now obviously there are some security benefits to this approach (though in practice I'm not entirely convinced this is a big deal since you're usuall…

The "low marketshare" argument doesn't work as well for a communication service like Zoom, because it's important for everyone on the Zoom call to have access. If 1% of users have Linux, that means that on a Zoom call connecting 10 randomly chosen users, around 10% have at least 1 Linux user in the call.

Re: How Not to Support Desktop GNU+Linux, Zoom Edition

#128

Post by Fabricio20 »

fanatic2pope wrote: post #48
Fabricio20 wrote: post #6

I believe this is not entirely Zoom's fault, I've heard a few horror stories with Wayland and screensharing over the last few years. Particularly when I once tried using OBS Studio and it just didn't work on Wayland. I also remember screenshare from things like Google Meet or Discord only being able to share other chromium tabs and not able to share the desktop or any specific applications. This whole story sounds to…

OBS works fine for me on Wayland through pipewire.

Here's my two cents: What even IS pipewire? I know what the compositor is because I've been given the choice of either X or Wayland in the past so I had to learn what they are. I've heard of pipewire in the past but I have no clue what it is, where does it fit in the display stack, etc.. Same for the linux audio stack.

I don't expect final users to know how to do these though. They want to download OBS and it needs to just work. I'm not sure how hard it would be to implement both in the case of Zoom as to support all setups but I'd assume it's not that trivial, and given other comments above where Wayland seems to have had more than one API for capture you can see where some of these issues come from.

Re: How Not to Support Desktop GNU+Linux, Zoom Edition

#129

Post by CameronNemo »

smoldesu wrote: post #99
solarkraft wrote: post #76

Earlier quoted context omitted.

You have heard these stories because there were different APIs floating around, some specific to particular compositor families. The author is offering the generic API that should work with all of them.

That's kinda a macrocosm for why Wayland still sucks, though. It always starts with a far-too-small scope, saying "we don't want to retread Xorg's mistakes", after which developers create 15 Competing Standards to replace Xorg functionality, and then the Wayland devs realize that if they don't put their foot down then 90% of the Linux desktop will have a subpar experience. It's a brutal, never-ending treadmill for us…

Seems like hyperbole. In this case, there were maybe 3 competing screenshot/screen share methods. None of them were billed as standard. Without the core Wayland devs having to get involved, or even any protocol extensions needing to be made, all of the major desktop environments and even wlroots standardized on a single D-Bus API for the functionality. That API is now a few years old. Yeah it took a while to get adopted/implemented, and Zoom probably has higher priorities. But I do not think X would have magically made the situation better, except by having gone through the process a decade (or more?) ago.

Nobody said the X->Wayland transition would be easy or even straightforward. Only that X has key architectural issues inherent to the protocol and a clean break was needed to make further efficiency and quality gains.

Re: How Not to Support Desktop GNU+Linux, Zoom Edition

#130

Post by CameronNemo »

jatone wrote: post #9
Fabricio20 wrote: post #6

I believe this is not entirely Zoom's fault, I've heard a few horror stories with Wayland and screensharing over the last few years. Particularly when I once tried using OBS Studio and it just didn't work on Wayland. I also remember screenshare from things like Google Meet or Discord only being able to share other chromium tabs and not able to share the desktop or any specific applications. This whole story sounds to…

its entirely zoom's fault. the apis they should be using have been well known and in use for years before they used the improper APIs. chrome's (and by extension every electron app) issues stem from the fact it had not updated to use the screencasting APIs. afaik they've been updated. abusing APIs isn't the right way to go here. and zoom is entirely at fault for it. they should have used the correct (and known) apis…

Even Chrome/Chromium, the web browser with the most developer attention period, has not enabled the pipewire screen sharing support by default.
Post reply on HN