Live data from Hacker News

How Not to Support Desktop GNU+Linux, Zoom Edition

write.as

51–60 of 223 posts

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

#51
post #18
post #4

I still cannot run a Wayland session on my machine w/ an nvidia 3080 with the latest drivers. It either fails to boot (KDE) or runs at about 15 FPS (Gnome). It seems a little unreasonable to be this mad at a company for not supporting an environment that doesn't work for the vast majority of hardware out there. Especially given that you can just use Zoom within Firefox.

Most people uses intel igpus no? There's a good nvidia population but it's not the majority, especially in a work environment. The good news is that Nvidia has finally decided to fix its drivers, it's still beta though.

[deleted]

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

#52
post #14

Earlier quoted context omitted.

flat out incorrect in this case. this has nothing to do with a deprecated API. they just decided to abuse one API when there was an API available for their use case available. x11 is no long maintained expecting an modern API to support it is foolish.

Was Pipewire even on distros by the time they decided to "abuse the one API" ? Even I have had to resort to abusing the one API, and it was just for taking the values of a couple pixels on the screen. Everything else is just too slow, requires setting up way too much infrastructure (e.g. PipeWire! a H264 encoder!), or has been fixed "last year" or some other uselessly recent date. X11 is no longer maintained is also…

x11 is no longer maintained. you're thinking of xwayland, which is the only thing getting releases these days. but that is built on wayland.

gnome shell has had some version of the screencast API for 8 years now. pipewire is irrelevant to the discussion.

https://gitlab.gnome.org/GNOME/gnome-shell/-/blame/main/data...

the first commit for the desktop portal (which is the end result of the gnome api above) for wlr was in 2018.

https://github.com/emersion/xdg-desktop-portal-wlr/commit/4e...

2 years before the 2020 date in the article. so in short: in 2020 zoom abused a gnome only api to implement desktop sharing, when a proper gnome only desktop sharing api already existed for ~8 years. which was the precursor to the current desktop portal stuff and you're trying to blame wayland for the problem.

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

#53
This person wants to replace the window system and is calling that a Zoom issue. And says they're working on it.

I fail to see the problem.

Wayland is not a drop-in replacement and creates work to get to parity. Nothing will explode if they use Xorg. The problems with Xorg are exaggerated. That they find Xorg completely unacceptable due to theoretical security issues (nobody is really writing and deploying code that targets xorg's issues) shows where their head is.

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

#54

Not surprised at all. Instead of making use of the WebRTC API in the browser, they just threw us back to Skype days of needing a native client installed on your OS....

Why would anyone need to install some untrustworthy software though? The web site works fine for me. I can participate in meetings through my browser, everything works.

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

#55
post #36
post #23

Earlier quoted context omitted.

> Was Pipewire even on distros by the time they decided to "abuse the one API"? No. Pipewire only arrived on the most unstable distros end of last year. It's in no way available for all, and not a common standard (yet). And you are right, wayland in general is not the norm yet. I'd even say it's likely to never replace X11 completely, given its shortcomings and X11's stability.

X11 is moribund. Part of why is because literally everyone who was working on it in a major way, possibly excepting Keith Packard, eventually considered it a dead end and jumped ship to Wayland.

Regardless, if I want to do something as simple as running a Minecraft client, I need to run X11 or else live with about 20 FPS.

If the old thing is broken, and the new thing isn't ready yet, then what are we supposed to do? Use Windows I suppose.

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

#56
post #4

I still cannot run a Wayland session on my machine w/ an nvidia 3080 with the latest drivers. It either fails to boot (KDE) or runs at about 15 FPS (Gnome). It seems a little unreasonable to be this mad at a company for not supporting an environment that doesn't work for the vast majority of hardware out there. Especially given that you can just use Zoom within Firefox.

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…

Even though my experience with Zoom under Linux is much smoother, I can confirm the "random audio device" issue; it may be daunting. And the inability to accept command-line arguments is a choice, not a technical problem.

Another fun bit: the same version of Zoom on the same hardware (T470, i5) offers virtual background support under Windows, and disables it under Linux. The machine has no dedicated GPU to have driver issues with.

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

#57

I think a better title would be: How Desktop GNU+Linux sucks for desktop developers: Zoom edition Windows will happily run GUI apps written 20 years ago. GDI is still supported. MFC Apps still run. Likely VB6 apps still run. Desktop GNU+Linux switches graphics engines, breaks backwards compatibility, ships something with performance and driver issues, and complains that user software doesn't work. Frankly this post t…

> Frankly this post turns me off towards even thinking about developing any type of native Linux app and if I need one, just use the browser or Electron.

Electron apps haven't worked on my system for a while. Since I switched to Wayland, they come up as black rectangles instead of displaying any graphics.

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

#58
post #52

Earlier quoted context omitted.

Was Pipewire even on distros by the time they decided to "abuse the one API" ? Even I have had to resort to abusing the one API, and it was just for taking the values of a couple pixels on the screen. Everything else is just too slow, requires setting up way too much infrastructure (e.g. PipeWire! a H264 encoder!), or has been fixed "last year" or some other uselessly recent date. X11 is no longer maintained is also…

x11 is no longer maintained. you're thinking of xwayland, which is the only thing getting releases these days. but that is built on wayland. gnome shell has had some version of the screencast API for 8 years now. pipewire is irrelevant to the discussion. https://gitlab.gnome.org/GNOME/gnome-shell/-/blame/main/data... the first commit for the desktop portal (which is the end result of the gnome api above) for wlr was…

1. X11 is definitely maintained, unless you are thinking of XFree86. Xorg's last release 2 weeks ago. Many LTS distros containing it are preparing releases with it _right now_ and they will also be supporting it for at least one decade, probably way more. I would bet that Wayland will become unsupported way before (at least some implementation of) X11 does.

2. This entire article is about avoiding the Gnome private API. The only other alternative, the XDG/portal API, uses Pipewire. It's literally the only alternative even if you don't use Flatpak.

EDIT: Your "2018" link is also not showing the screencast portal API. And I am not blaming Wayland; I am blaming the distros who switch to it and as a consequence BROKE user programs.

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

#59

I think a better title would be: How Desktop GNU+Linux sucks for desktop developers: Zoom edition Windows will happily run GUI apps written 20 years ago. GDI is still supported. MFC Apps still run. Likely VB6 apps still run. Desktop GNU+Linux switches graphics engines, breaks backwards compatibility, ships something with performance and driver issues, and complains that user software doesn't work. Frankly this post t…

> 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.

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

#60
post #52

Earlier quoted context omitted.

x11 is no longer maintained. you're thinking of xwayland, which is the only thing getting releases these days. but that is built on wayland. gnome shell has had some version of the screencast API for 8 years now. pipewire is irrelevant to the discussion. https://gitlab.gnome.org/GNOME/gnome-shell/-/blame/main/data... the first commit for the desktop portal (which is the end result of the gnome api above) for wlr was…

1. X11 is definitely maintained, unless you are thinking of XFree86. Xorg's last release 2 weeks ago. Many LTS distros containing it are preparing releases with it _right now_ and they will also be supporting it for at least one decade, probably way more. I would bet that Wayland will become unsupported way before (at least some implementation of) X11 does. 2. This entire article is about avoiding the Gnome private A…

1. no its not, no security fixes or new features are being developed, its entirely on life support: the changes are to just keep it limping along while distros finish transitions to wayland. https://lists.freedesktop.org/archives/xorg/2022-January/060...

2. the article is about them abusing a gnome only API when alternatives existed that would have worked better. WLR had its first commits for its desktop portal api in 2018, gnome has had some form of the desktop portal api for 8 years now.

if you're going to use a DE only API at least use the right fucking one.

Post reply on HN