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

171–180 of 223 posts

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

#171

Post by Mehdi2277 »

Steltek wrote: post #131
suby wrote: post #79

Earlier quoted context omitted.

I was aware that AMD had officially supported open source linux drivers, and that Nvidia did not support Wayland. Unfortunately, I needed a machine which would work well with the existing machine learning ecosystem, and that means getting an nvidia card over AMD. It's pretty terrible that the machine learning ecosystem is centered around nvidia hardware.

Has anyone tried using an AMD card for desktop/Wayland alongside an Nvidia card for ML/CUDA? Especially with Sway? I use Sway/AMD for desktop but all the photogrammetry software out there requires CUDA. It's a bit of a PITA.

It can work but generally you either have performance issues or less library support or run into more operational pains. I mainly work on building library tooling over tensorflow. Losing support for good number of operations is not something that I could reasonably consider. Also cloud amd gpu support is near non-existent and most of my company's compute relies on the cloud. t4 pricing is very nice on gcp.

Like AMD rocm exists for ml, but is very far behind cuda in support/libraries for ml. I don't think any moderate investment in AMD gpus is likely to catch up, so I'm pretty pessimistic of AMD being a good solution for ML usage anytime in the next several years.

I think a hobbyist who already owns an AMD card and wants to do basic ML is only situation I'd consider it. Any other situation and I'd strongly advise against it.

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

#172

Post by avrionov »

a few comments from somebody who worked for many years for a competitor to Zoom.

The article author complains about some relatively minor details but completely misses the big picture.

I'm not going to talk about the availability and quality of the Wayland API, this was covered in other posts.

Here is what the decision looks like from the POV of someone building a product:

- Zoom is one of the few collaboration products which supports Linux with a native client. The native clients offer much better performance on every operating system.

- Some of the collaboration products (Zoom being one of them) implement 2 different codecs for the video streams and screen sharing. This is done to offer better performance, lower bandwidth, and better quality. For screen sharing the most important requirement is not which API is used, but if the text is readable.

- Zoom is a multiplatform product. All other platforms offer API for screenshots. Not all platforms have an API that captures the screen as a video stream. Using screenshots is the best way to cover all platforms.

- Collaboration products have high requirements for screen sharing: Capturing the entire desktop, capturing a single application, capturing a portion of the screen, excluding its own UI, etc. Support for multiple monitors, 4k, 5k support. Most of these use cases are not going to be covered by the Wayland API.

- This is a different use case than streaming your screen to twitch or youtube. Collaboration products have very low latency ( - Zoom supports h264 as their main codec. API which provides VP8 will require contradicting and encoding which will slow down the performance.

- Even if the video stream coming directly from the screen didn't require transcoding, it is still required to do a post processing. For screen sharing (with no video on the screen) it is wasteful to generate too many frames.

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

#173

Post by amatecha »

kxra wrote: post #153
amatecha wrote: post #146

Earlier quoted context omitted.

It was probably submitted incorrectly, my guess

When I tried to resubmit the correct URL, it was stripped again. Does it work for you?

didn't try myself, but looks like the URL has been corrected now! :D

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

#174

Post by onli »

boudin wrote: post #65
onli wrote: 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.

Pipewire has been there for more than that, I've been using it for a few years now. You might be mistaken with the audio part of it (that replaces Pulseaudio and Jack).

It's possible I did not notice the non-audio part was already in the wayland-enabling distros before, if that was the case.

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

#175

Post by saltcured »

nine_k wrote: post #56
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…

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 drive…

Are you using Wayland? My wife saw functions disappear with a recent Zoom update on her quite old laptop, and starting her GNOME session via GNOME on X11 restored those functions.

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

#176

Post by acomjean »

faisal_ksa wrote: post #122
homarp wrote: post #113

Earlier quoted context omitted.

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…

I'll agree that your argument that making linux apps easier to write deploy is a good goal. Its not an easy thing when you have a bunch of different windowing libraries (GTK, QT..) a whole host of desktops, multiple distribution channels (flatpack, snap, apt-get...) ususally computing platforms converge on something common, but I haven't seen it in linux. I wonder if I was writing a application for linux, where would I start?

It is a little of chicken and egg problem. Not a lot of users on linux, so not worth writing software for it. Users see there is not a lot of software and might go somewhere else. But there is enough. And most of it is a little buggy and free. Some of the applications are just great (blender, kritta). The core OS is rock solid though.

I've been using it as my home desktop and honestly linux on the desktop is pretty great.

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

#177

Post by not2b »

Zoom has better Linux support than almost any proprietary desktop application of similar complexity. For pretty much anything else only a web client is provided. My non-technical wife has no trouble using the Ubuntu version, flipping between using the laptop sound and earbuds. True, she doesn't need desktop sharing and there are issues with that.

The fact that there's any support at all for desktop Linux (beyond "it works in the browser") is pretty amazing, and it's probably better not to crap all over the people who have done 80-90% of the job for the missing 10-20%.

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

#179

Post by linsomniac »

not2b wrote: post #177

Zoom has better Linux support than almost any proprietary desktop application of similar complexity. For pretty much anything else only a web client is provided. My non-technical wife has no trouble using the Ubuntu version, flipping between using the laptop sound and earbuds. True, she doesn't need desktop sharing and there are issues with that. The fact that there's any support at all for desktop Linux (beyond "it…

BlueJeans has a native Linux app that for the last 6 weeks, every time I've started it, has told me that there is an update available and asking if I want to upgrade it. When I go to download it, I find I have the latest Linux version available.

Nothing like telling your users every time they start your app that you don't prioritize their OS.

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

#180

Post by saurik »

bArray wrote: post #169
duiker101 wrote: post #116

Earlier quoted context omitted.

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

> This might have been added after your comment. If that's the case, great work in responding so quickly. > Link with md: https://write.as/n5r0vjolumdnuk2k.md You'd think the `.md` would be the markdown and the blank/`.html` would be the HTML? Not the other way around? Might be worth the owner of the website swapping that around afterwards.

Maybe the idea is that you edit plain text files but then can optionally claim "this file can be parsed as X", which actually I want to say is kind of cool? Though... I guess if this were my site, to make that less confusing, I would make the plain text version .txt and then just not really have a "default" version.
Post reply on HN