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

201–210 of 223 posts

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

#201

Post by cupcake-unicorn »

avrionov wrote: post #195
cupcake-unicorn wrote: post #188

The mass adoption of Zoom in areas where it really shouldn't have been used and the lack of support to users has been shocking to me. It really felt like this just happened to be the company that took off because of the pandemic but a scrappy startup could have done this 1000x better.

Genuinely curious: which are these areas where Zoom shouldn't be used?

I just felt like the Zoom calls that I participated in telehealth wise were really sloppily managed - I wasn't clear as a patient with smaller providers if they were using a HIPPA compliant provider account or just a personal Zoom account.

In a group therapy Zoom I encountered one of the members being inflammatory/disruptive, and there are no controls for me to block that user's video/text on my end. Before briefly thinking of ways to programmatically block out the screen using Greasemonkey/macros I just quit the group.

In addition I was on a local city government summit call that was just a nightmare. They were trying to be accessible to people who needed interpretation but what it ended up looking like was that every time someone said something, it was repeated back by interpreters in 3 different languages, making everything 3 times longer. Some of this stuff was worked out at the end, but the solution was just basically to stop people from expressing themselves. Maybe there's a better solution to this both then and now but if there was they didn't seem to be aware of it. It does seem like a no brainer to be able to opt in to translator channels and not have all the translations going at once.

In all these cases I saw that people were changing their meeting styles and habits around the limitations of Zoom, which led to worse outcomes, worse creativity, and more stress, rather than Zoom being particular proactive in adding new features that could address these valid roadblocks people were running into. That's where I feel like a startup with an eat your own dogfood approach could have addressed real issues like this rather than just profiting from being the only company around and not really meaningfully expanding features in any way since it's been widely adapted.

I don't use Zoom THAT much and these are my personal experiences, but it feels like a junky product - maybe to people who are used to Office 365 it's fine, but as someone who used Slack and other startup friendly tools/services Zoom and Office just seem like they are so stuck technology wise.

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

#202

Post by hkmaxpro »

avrionov wrote: post #172

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

I really appreciate your explanation from the point of view of the software developer.

One question: Zoom web client supports screen sharing using WebRTC Screen Capture API. This is why Zoom web client allows screen sharing using pipewire on Wayland. Do you think WebRTC screen sharing codec offers suboptimal performance?

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

#203

Post by avrionov »

hkmaxpro wrote: post #202
avrionov wrote: post #172

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

I really appreciate your explanation from the point of view of the software developer. One question: Zoom web client supports screen sharing using WebRTC Screen Capture API. This is why Zoom web client allows screen sharing using pipewire on Wayland. Do you think WebRTC screen sharing codec offers suboptimal performance?

I don't work for Zoom, so this will be my best guess.

WebRTC supports VP8 and h264, but it really depends on the platform. h264 is not free and may not be available. The screen capture API will give them a video stream which they need to decode and the encode again in their own format. This is where some of the efficiencies will come.

It is also more likely that h264 to be hardware optimized than vp8.

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

#204

Post by avrionov »

cupcake-unicorn wrote: post #201
avrionov wrote: post #195

Earlier quoted context omitted.

Genuinely curious: which are these areas where Zoom shouldn't be used?

I just felt like the Zoom calls that I participated in telehealth wise were really sloppily managed - I wasn't clear as a patient with smaller providers if they were using a HIPPA compliant provider account or just a personal Zoom account. In a group therapy Zoom I encountered one of the members being inflammatory/disruptive, and there are no controls for me to block that user's video/text on my end. Before briefly t…

Thank you for the detailed answer. These are really interesting use cases, which I didn't think about.

For the local government sessions, it seems that a webinar product is a better option.

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

#205

Post by bitwize »

shrimp_emoji wrote: post #196
phkahler wrote: post #170

Earlier quoted context omitted.

YMMV but I've found both to work fine, with Wayland providing the advertised tear-free video experience that X never could. Granted, when I tried OBS about a year ago I had to resort to an X-session, and that worked as expected. Not that OBS works properly on Wayland, my own use for X - I think - is done.

The solution for tearing is adaptive sync monitors. Wayland's justification should be a (theoretically) better platform and codebase.

You can also set TearFree in X.

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

#206

Post by YEwSdObPQT »

throwdbaaway wrote: post #189
YEwSdObPQT wrote: post #27

People are saying this is Zoom's fault. Maybe it is. However I've given up on Wayland entirely and just gone back to X11. I frequently need to record my screen to show bugs or fixes in features. Most of the open source screen recording software seems to only support X11. I've tried quite a few different open source alternatives (other than the built Gnome Screen recorder which is kinda hidden in a keyboard short-cut…

Have you tried running slack as a tab in chrome/chromium/firefox? I just started doing that very recently on wayland, and it seems to work fine.

I don't really want to run a messenger in a web browser. I know it is electron and is running an instance of chromium, but I want a separate application.

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

#207

Post by Too »

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…

Haven’t tried Zoom on Linux but there the competitor Microsoft Teams is a total disaster Electron app. Beating that one is a really low bar.

Starting with screen sharing since that’s the main topic here. Doesn’t work at all on wayland so no point to even compare further.

Moving on to UI performance, it must be among the worst applications I’ve ever seen since 1993. Even on a super beefy gaming machine. Basic stuff like scrolling in a chat or just switching between chat tabs measures in several seconds rather than milliseconds, and always comes with some weird flicker or jank. Toggling between two open chats, you know the thing you do 1000 times per day, is equally slow and frustrating. I’d rather take no Linux support at all than this vomit.

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

#208

Post by boudin »

onli wrote: post #174
boudin wrote: post #65

Earlier quoted context omitted.

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.

It was definitely available in distros like arch and gentoo. Fedora as well when then switched to wayland by default. More conservative distro might not have included it though, but they are on X11 by default so it's not needed in the first place.

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

#209

Post by boudin »

AshamedCaptain wrote: post #81
boudin wrote: post #64

Earlier quoted context omitted.

No, Pipewire and xdg-desktop have been there for ~3 years. OBS supported Wayland for ~2 years (maybe more, but I've been using it for ~2 years), but you had to install a third party plugin for it, and the app itself was running in Xwayland. The Flatpak version did include the plugin for a while. And it's not MIGHT work on anything other than Gnome, it DOES.

Even the _current_ LTS from Ubuntu does not ship Pipewire 0.3, which is _required_ to use the portal API for screencasting (no dma-buf import in pipewire 0.2), unless you want for it to be significantly slower than using X11 and Xshm. So this API doesn't even work in the current fastest-LTS-cycle distro. > And it's not MIGHT work on anything other than Gnome, it DOES. well, I say that because even thought single-wind…

Ubuntu LTS is on x11, not wayland. So pipewire is irrelevant here.

Pipewire and xdg-desktop are fairly new but not changing every day at all, that's just pure lies. Now that's it's supported by almost all software but zoom, it's unlikely to introduce big breaking changes as well in the future.

If the compositor itself do not support one part of it, it's the problem of the compositor itself, not Zoom, it won't change a thing on Zoom sides. That's exactly the concept behind it being a protocol that abstract the compositor.

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

#210

Post by SahAssar »

wnoise wrote: post #82
SahAssar wrote: post #47

Earlier quoted context omitted.

I'm guessing write.as is supposed to support multiple languages, and only renders the markdown if you have .md as an extension.

Which is the exact opposite of what I expect and want -- the bare filename should render, and the .md extension should get the markdown source.

If the source can be different languages (like md, html, rst, org-mode, wikitext) and the language isn't stored then this choice makes text.
Post reply on HN