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

141–150 of 223 posts

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

#141

Post by mikepavone »

Georgelemental wrote: post #127
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.

Most users on a Zoom call aren't screensharing so I don't think this math remotely works out here.

That said, even when users of a minority platform impact the experience of a broader community you're still going to make development resource tradeoffs based on userbase. Honestly, I think Linux punches way above its weight here because software developers are much more likely to be Linux users than normal people. That said, when development for your platform is happening in developer's free time or in between official priorities*, making things easy is perhaps even more important.

*I don't know if this specifically happening at Zoom, but this kind of thing is not uncommon when it comes to Linux support in commercial apps.

EDIT: Fixed formatting

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

#142

Post by buzzwordninja »

cluoma wrote: post #73
funcDropShadow wrote: post #13

Earlier quoted context omitted.

I've been using Zoom on Gnome almost daily in the last three years. I've basically no problem with video conference itself. Video just works for me. But audio is a never ending story. Zoom randomly selects other audio devices, when I quit one video session and start another. Sometimes, I have to to quit zoom and start it again. Sometimes I have to disconnect my table speaker/microphone to be able to use it in zoom ag…

Same audio issues here. Zoom always wants to set my mic level to 0 and change the default output source for whatever reason. My last company used Teams which I had a much better experience with on Linux (gnome+xorg) than Zoom.

Oh, I had that problem.

Settings, Audio, uncheck Automatically adjust microphone volume.

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

#143

Post by burnished »

Georgelemental wrote: post #127
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.

No, you have one Linux user who is now scrambling to get it to work or is using a device that will make it work. Your example sort of under cuts your argument, just imagine sending that email "I will not be attending our remote meetings due to what some may call a philosophical argument with Zoom, rest assured, I am in the right, and as soon as they see the light and correct their ways, I will start attending meetings again".

Instead, in frustration, they will reach for another device. They will use an old laptop, or a smartphone, something.

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

#144

Post by mikepavone »

pmontra wrote: post #137
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…

> 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 Do you mean that you cannot share the whole desktop? The typical coding / debugging session (browser, editor, terminal) would be very difficult to do.

I mean that at an API level, you can't manually select what you want to capture whether that be a particular screen or a single window. You have to send a dbus message to the DE which will then pop up its own UI to select the thing you're going to share.

So lets say you have some cross-platform UI code for screensharing with an OS abstraction layer that has functions to get a list of potential sources (perhaps with previews) and another that starts screensharing with a particular source. That particular design works fine on Mac and Windows (except in the UWP ecosystem, but no one cares about that) and also with X11, but not with Wayland. So now it's not just about having another implementation of your OS abstraction layer for a new capture API, it's also about mucking around with the UI flow. In the grand scheme of things, this is not a huge deal, but it makes supporting the API kind of a PITA.

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

#145

Post by aidenn0 »

cluoma wrote: post #73
funcDropShadow wrote: post #13

Earlier quoted context omitted.

I've been using Zoom on Gnome almost daily in the last three years. I've basically no problem with video conference itself. Video just works for me. But audio is a never ending story. Zoom randomly selects other audio devices, when I quit one video session and start another. Sometimes, I have to to quit zoom and start it again. Sometimes I have to disconnect my table speaker/microphone to be able to use it in zoom ag…

Same audio issues here. Zoom always wants to set my mic level to 0 and change the default output source for whatever reason. My last company used Teams which I had a much better experience with on Linux (gnome+xorg) than Zoom.

Teams is terrible on Linux for me, but which thing is broken changes from version to version.

A few examples:

- My USB headset only works for the first call. Restarting teams let's me use it for one more call

- joining a meeting from the calendar spins forever. Doing it from the chat list works fine

- incoming calls don't ring my Linux teams, but ring everywhere else

- the settings for setting which device to use rarely have any effect; I can use any pulse mixer to switch though

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

#146

Post by amatecha »

kxra wrote: post #140
CameronNemo wrote: post #125

Earlier quoted context omitted.

@dang can we get the link updated?

Do we know why it was modified? I think hackernews stripped off the .md for some reason, but if you submit the URL with an anchor like https://write.as/hash.md#title that seems to preserve it

It was probably submitted incorrectly, my guess

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

#147

Post by matheusmoreira »

AnIdiotOnTheNet wrote: post #86
matheusmoreira wrote: post #59

Earlier quoted context omitted.

> Windows will happily run GUI apps written 20 years ago. Don't think this is true anymore. Old software on Windows just isn't guaranteed to work anymore. Last time I tried to play an old game on newer Windows versions, it didn't even start up despite automatic and manual installation of a ton of dependencies. I suppose the Raymond Chen stories about heroic bug fixing in third party code is a thing of the past.

Games are an especially difficult case as they have a habit of bypassing higher level APIs and abusing undocumented behavior for performance reasons. Still, a shockingly high number of games from 20+ years ago work out of the box on the latest Windows despite things like the shift from 32 bit to 64, all without recompilation. Linux Desktop's compatibility story is laughable by comparison unless you count WINE, which…

Microsoft also used to have a history of maintaining bug compatibility with applications, including use of undocumented data structures and functions. I've read the stories: once they tried to change some data structure only to revert the change when some proprietary software broke because it did insane things like put data into unused bits of some internal data structure.

At some point all this must have been lost because I don't see Microsoft going out of its way to fix memory allocation bugs in games for our benefit anymore. I did try playing the game on Wine and it worked, ironically. Wouldn't be surprised if it eventually became the best way to run older Windows software.

The ABI compatibility situation of Linux user space sucks. Apparently the kernel itself can run binaries from the 90s with no problem. The more dependencies you have, the worse the situation gets because in the free software world people seem to make it a point to avoid caring about binary compatibility since everyone is supposed to have the source code to everything in order to recompile software as needed. Because of this I've personally resolved to eliminate all dependencies in my own code by using Linux system calls directly.

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

#148

Post by ddtaylor »

pmontra wrote: post #134

Two questions. 1. Why not the .md URL for everybody? 2. Is this really a problem with Zoom or one with Wayland and the Linux distros? I mean Fedora switched to Wayland in 2016 and the screensharing API was added only in 2018. A rushed deployment? Then maybe the Wayland team should make a list of the applications that must absolutely work with Wayland and support their vendors to release a correct implementation, not…

> 2. Is this really a problem with Zoom or one with Wayland and the Linux distros? I mean Fedora switched to Wayland in 2016 and the screensharing API was added only in 2018. A rushed deployment?

I use OBS on Fedora 35 and overall it's been really nice. I use the Flatpak version of OBS and it uses Pipewire. When I want to screen record an OS-level dialog box pops up asking me which screen/window I want to share and the entire time I am recording/sharing I have an indicator icon that is orange (whereas all other icons are white)

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

#149

Post by matheusmoreira »

ModernMech wrote: post #108
matheusmoreira wrote: post #59

Earlier quoted context omitted.

> Windows will happily run GUI apps written 20 years ago. Don't think this is true anymore. Old software on Windows just isn't guaranteed to work anymore. Last time I tried to play an old game on newer Windows versions, it didn't even start up despite automatic and manual installation of a ton of dependencies. I suppose the Raymond Chen stories about heroic bug fixing in third party code is a thing of the past.

I can't find it now, but I remember there was a video of someone upgrading windows from like Windows 3 all the way to the latest Windows... maybe it was 7? I forget how long ago this was. But each time they upgraded Windows, they showed that the programs installed in the original OS still worked. I think they did it with Doom installed in 3, and showed that it still worked after 20 years of upgrades. That's some impr…

I remember there were several games in my Steam library that didn't survive any upgrades past 7.

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

#150

Post by takluyver »

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…

> I'm not entirely convinced this is a big deal since you're usually pretty hosed if you've installed a malicious native app anyway.

This specific restriction is part of a more general push for sandboxing, to limit the damage one app can do. It's probably not massively useful against actually malicious apps, because they'll probably just declare they need arbitrary filesystem access anyway. But it should be beneficial when honest apps have security flaws.

Post reply on HN