21 ms·

How Not to Support Desktop GNU+Linux, Zoom Edition

204 points by 6581 5y ago

chagaif 5y ago
Not having opened the rendered (.md) file, made me see this nice touch: Each of the words in "One of the many threads" is pointing to a different thread
solarkraft 5y ago
Big news, guys: Zoom sucks! Not only do you not have to feel bad about having Zoom on your computer, using it in the browser also enables screen sharing through it (the web app sucks, but it's not like the desktop one doesn't).
FengLengshun 5y ago
...is it just me, or is the site broken? The link didn't display correctly and it shows as the raw markdown instead of the formatted result (checked with both Brave and Firefox, in private windows in case it's some extension). Is that just how the site is? It's very distracting regardless.
teilo 5y ago
How not to code an HTML page by hand.
- exciteabletom 5y ago
 How not to code an <a href="https://en.wikipedia.org/wiki/HTML">HTML</a> https://en.wikipedia.org/wiki/HTML">HTML</a> page by hand.
 - JonathonW 5y ago
 In next week's episode, how not to write your URL-detection regex.
 - sodality2 5y ago
 You can't parse [X]HTML with regex: https://stackoverflow.com/a/1732454 https://stackoverflow.com/a/1732454
- kxra 5y ago
 The end of the URL got trimmed upon submition, so its pointing to the unrendered markdown URL for some reason. Here's the rendered page: https://write.as/n5r0vjolumdnuk2k.md#title https://write.as/n5r0vjolumdnuk2k.md#title
 - 988747 5y ago
 Why won't trimmed URL simply redirect to a proper one? Or throw 404 even? This seems like a webserver misconfiguration of sorts, kind of like being able to access raw PHP pages, instead of rendered ones.
 - SahAssar 5y ago
 I'm guessing write.as is supposed to support multiple languages, and only renders the markdown if you have .md as an extension.
 - wnoise 5y ago
 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.
 kxra 5y ago
 Agreed. Write.as is open source, you can file a ticket against WriteFreely on github
 SahAssar 5y ago
 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.
 - Operyl 5y ago
 Thank god, I was thinking it was some stylistic choice to have to read all those links inline in unrendered markdown.
AshamedCaptain 5y ago
Most desktop Linuxes are changing and deprecating APIs way too fast for the usual glacial development flow of a big commercial software company. The fact that apparently the API for Wayland/Flatpak screen recording is less than 5 years old and it still does not work on X11 desktops does not inspire a lot of confidence, either. However, desktop video calls and screencasting is one area where I think the free and open source alternatives are up to the task.
- jatone 5y ago
  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.
  - AshamedCaptain 5y ago
    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 flat-out wrong, and I'm willing to bet, it's still the most used option (since even on the distros which use Wayland, in-place updates do not usually turn it on). The fact that today's screencast API does not even bother to implement support for the most used window server out there does not inspire confidence, either.
    - onli 5y ago
      > 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.
suby 5y ago
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.
- Hakashiro 5y ago
  Using Linux is not a practical decision. It is an ethical/moral decision or simply just because you like tinkering. That's fine. I like getting shit done. But then, getting mad because your favourite closed source company doesn't support Linux well is a little ridiculous. Zoom works fine on macOS and Windows. Linux is always bound to have issues one way or another, and if that's not enough, there's not even an incentive for developers to do things the right way, so get over it.
- tapoxi 5y ago
  This is just an Nvidia issue, they spent years trying to push their own driver model and have only recently come around.
- mixedCase 5y ago
  While this doesn't detract from your argument given the timelines; if you're on Arch, try again. I believe it was yesterday that the one major Qt fix that made Wayland KDE usable on Nvidia landed. Apparently Sway too has worked fine since the release of Nvidia drivers with GBM support. I'm on AMD right now so can't confirm.
  - mijoharas 5y ago
    As an nvidia hostage I can confirm that arch and sway works. (currently works out of the box with nouveau, I think I previously had to mess around with the proprietary driver and wayland-eglstreams. That stopped working around when the new driver with GBM support was released I think. uninstalling the eglstreams and switching to nouveau fixed it)
- 5y ago
Fabricio20 5y ago
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 me like some engineer at Zoom was tasked with fixing "linux" back in 2020 and after having several issues similar to what I described (possibly unable to capture other applications?) they decided that quickly screenshotting the screen was a good enough fix. Sadly linux still represents a minority of users so this issue was probably not prioritized as necessary.
- jatone 5y ago
  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 and worked with upstreams to get the support in place. then they could have properly pointed to upstream and said 'it won't work until these issues are fixed' and provided resources to fix them. as a result now they are in a shit position of having a completely broken app when the APIs in question do work. I know because I've built a screencasting program on top of them to cast my desktop to chromecast.
  - shadowgovt 5y ago
    Zoom is not as big a company as people think... They're just hustling very hard relative to the sudden explosion of use of their tools. I'd be willing to wager money that their development process involved attempting to use the correct API, finding that it either failed on a key executive's machine or the developers' own machines (possibly because of one bad driver/hardware/os configuration) but because it didn't work for single key player, they had to invent a work around with a worse solution that worked on the spanning set of architectures they needed it to work on.
DarthNebo 5y ago
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....
- shadowgovt 5y ago
  WebRTC implementations haven't converged yet. Roll your own app, or trust to the winds of multiple browser developers and rely on a library produced by Google that you may not have the resources to fix if it breaks on a key hardware / software configuration? No good choices here, only trade-offs.
- AshamedCaptain 5y ago
  Really? They're the only commercial company that bothers to create a native client (and not a Electron app) and you complain that you would prefer to have no client at all? I don't think that's the majority opinion... I'm no fan of them (I think free apps are up to the task), but give me a native client _any day_ over something that runs in a browser. I don't want any more multi-GB RAM hoarding processes running 24h on my desktop.
  - KingMachiavelli 5y ago
    Native clients may be preferred for things that are mostly offline anyway like a text editor. But for something like Zoom, it just makes sense to have a good web app and ship an Electron build for the people who really need a standalone app. The probability of browsers and by extension Electron eventually having best in class screen sharing is basically 100% since that's what almost everyone uses so there's a vested interest by some of the largest companies in the world to make it work. This is not true for the desktop application frameworks. While Zoom did have pretty good screen sharing (on Linux) via the desktop client, it had a awful bug where it would just freeze the entire system making it unusable. Since 99% of people are already going to have a browser open, the incremental memory usage of a webapp is actually pretty minimal. Electron apps are a bit heavier (mostly due to the fact they all ship with their own Electron version) but it's a small trade-off given the benefits such as having the chromium sandbox and cross-platform compatibility. Even smaller things like having a more robust and secure video decoding stack is a major advantage since it sucks when 10 applications all link against an old, vulnerable version of ffmpeg.
presz 5y ago
People still call it GNU+Linux? Modern distros have less GNU pieces on each iteration. Might as well start calling it Gnome+Linux from now on.
- teddyh 5y ago
  “that is not the deepest way to consider the question.” — https://www.gnu.org/gnu/linux-and-gnu.html https://www.gnu.org/gnu/linux-and-gnu.html
  - adwn 5y ago
    That entire page can basically be summarized as "The GNU components in Linux distributions are becoming less significant each year, but please call it the 'GNU system' anyway because we like that name better."
  - Shared404 5y ago
    I... don't like the argument made here. > But the reason it is an integrated system—and not just a collection of useful programs—is because the GNU Project set out to make it one. We made a list of the programs needed to make a complete free system, and we systematically found, wrote, or found people to write everything on the list. First of all, I mostly use Alpine for Linux servers, so I guess that should be referred to as Busybox/Linux according to this? Second, the work done to make an integrated OS on desktop is not done by GNU anymore[0], it is done by the GNOME/KDE dev's. [0] Also, what does "integrated" even mean in the context of a UNIX-like OS. Doesn't that sorta defeat the point?
    - yjftsjthsd-h 5y ago
      > First of all, I mostly use Alpine for Linux servers, so I guess that should be referred to as Busybox/Linux according to this? Yes. GNU/Linux, Busybox/Linux, and Android/Linux are all different things, and all perfectly good descriptions.
      - Shared404 5y ago
YEwSdObPQT 5y ago
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 and it absolutely useless as I have to crop the video afterwards). Slack and Discord can't share the whole screen. Not much of an issue with Discord. But with Slack sometimes I need to demo my whole screen and it doesn't work with Wayland enabled in Gnome. So this isn't a problem just for zoom. It seems other software has problems with this as well. Also with Wayland I have weird issues when using a browser (doesn't matter which one I've tried them all) if the memory usage on my dev machine goes up over 32gb (I have 64GB installed). Wayland starts to slow down. Windows seems to start becomes randomly unresponsive and scrolling keeps hitching. It isn't the CPU time because I ran top and the CPU usage was fine. Before anyone tells me not to use a Nvidia card or Do I have the right drivers installed etc. I am using kernel 5.10 on debian 11 (bullseye) and I have a AMD 6800XT. I have the correct firmware installed and I played Rise of the Tomb Raider (linux native games) recently at 4k with absolutely no problems (I have one crash in 40 hours of gameplay). So it not the card or the drivers. I've basically given up using Wayland. The only issue I've had was screen tearing in Dark Souls 3 and a few other games that were being played via proton and that was solved by enabling TearFree in an Xorg conf file. cat /etc/X11/xorg.conf.d/20-amd.conf Section "Device" Identifier "AMD" Driver "amdgpu" Option "TearFree" "true" EndSection People keep on saying Wayland is better, X11 is rubbish. But I frequently find the opposite. I know there are security issues. But I need the full screen record and I've tried almost everything and none of the software (open or proprietary) I've tried works properly with Wayland.
- throwdbaaway 5y ago
  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.
  - YEwSdObPQT 5y ago
phkahler 5y ago
OBS studio only recently got it right on Wayland. I'm not so sure Zoom has been slacking since 2018 on this one.
RcouF1uZ4gsC 5y ago
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 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.
- Filligree 5y ago
  > 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.
- matheusmoreira 5y ago
  > 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.
  - badsectoracula 5y ago
    You need workarounds but you can make it work. Though you can say the same thing for Linux too, it is just that Windows coming out of the box with a much richer API (e.g. for GUI functionality) makes things easier.
  - AnIdiotOnTheNet 5y ago
    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 works so well in part because Windows APIs are so stable.
encryptluks2 5y ago
They don't care about you, stop pretending like they will. You chalk this up as incompetence but it is more than that as shown by their actions.
thanatos519 5y ago
Microsoft Teams: Hold my beer.
asveikau 5y ago
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.
- chaorace 5y ago
  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 entire system that isn't up to the job. Being forced to jump through hoops like that when you're using a common and modern system configuration is a sign of a poorly supported product and something users should rightfully complain about.
  - yjftsjthsd-h 5y ago
    > 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.
    - nemetroid 5y ago
      You can run it, but not with reasonable screen sharing support, which arguably is a part of "supporting the distro".
      - yjftsjthsd-h 5y ago
        My point was that distos don't map 1-1 to Xorg or Wayland; you can run the very latest Fedora with Xorg, or Ubuntu 18.04 with Wayland. They support the distro just fine, the problem is a specific graphical server.
seltzered_ 5y ago
Thanks for sharing this. I'm using a relatively simple setup (Ubuntu 21.10 on wayland, single hiDPI tablet display - no secondary gpu, no second monitor) and was frustrated to see Zoom screensharing only show the upper right quarter of the screen (presumably due to not accounting for hidpi) recently. This said, it generally works fine, and am thankful Zoom at least exists on Linux. -- "If you're stuck using Zoom [...] we can work to pry our organizations and loved ones away from the hapless engineering at Zoom." I disagree with this sentiment. Zoom has been a huge enabler with it's setup to minimize video/audio latency compared to the other solutions I've seen when faciliating a global audience that doesn't necessarily have fast internet access.
- throwdbaaway 5y ago
  Zoom product/engineering is indeed hapless when compared to Google Meet product/engineering.
smoldesu 5y ago
> and the inevitability of a complete switchover is known. Uh, yeah, no. If you press even the most hardcore of Wayland advocates, they'll eventually admit that Wayland is not a true replacement for Xorg. They'll make the case that you shouldn't use Xorg, but at the end of the day, Wayland's development will always be a treadmill since it's goal is to be less feature-complete than the protocol it's replacing. Yes, I hate x11. Yes, I want a better window server. Wayland is absolutely, positively not it though, and I reckon I'll be sticking with Xorg for the foreseeable future (at least 5 years). This is yet another "why won't companies take Wayland seriously!?" blogpost. You want your answer? It's because Wayland has been in development for more than a decade, with top-priority attention from the most well-funded organizations in open source. And it's still not finished.
mikepavone 5y ago
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 usually pretty hosed if you've installed a malicious native app anyway...), but this kind of requirement tends to break existing abstractions. Now on some level, that's not a big deal. Having to use a different UI flow on Wayland than everywhere else is annoying, but that's just life in software development. BUT, Linux has a relatively tiny share of the desktop market which makes it hard to justify devoting engineering resources to it. When you've only got 1% of the market, you're only going to get good adoption of a new API if you make it easy.
- pmontra 5y ago
  > 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.
  - mikepavone 5y ago
    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.
- 5y ago
aidenn0 5y ago
There are many good points, but the article says "Wayland has been in development for all this time, and the inevitability of a complete switchover is known" for a time period starting in 2008? Mir was a potential competitor as late as 2017. Today I have yet to successfully run plasma5 under Wayland with success on my home workstation, despite trying annually since 2018.
faisal_ksa 5y ago
A game developer [1] once said that Linux "accounted for <0.1% of sales but >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 unified Linux platform with a friendlier developer experience. Something similar to Android (which has Linux kernel inside it). [1]: https://twitter.com/bgolus/status/1080213166116597760 https://twitter.com/bgolus/status/1080213166116597760 Also, see: https://news.ycombinator.com/item?id=18845205 https://news.ycombinator.com/item?id=18845205
- homarp 5y ago
 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 something else. You get all the software/os versions, all the logs, you get core dumps and you get replication steps. Sometimes I got with the player over discord and we quickly iterated a few versions with progressive fixes to isolate the problem. You just don’t get that kind of engagement from anyone else. Notably, of those bug reports, fewer than 1% (only 3 bugs) were specific to the Linux version of the game. That is, over 99% of the bugs reported by Linux gamers also affected players in other platforms. Moreover (quoting from the OP): [1] https://old.reddit.com/r/gamedev/comments/qeqn3b/despite_having_just_58_sales_over_38_of_bug/ https://old.reddit.com/r/gamedev/comments/qeqn3b/despite_hav... also see https://news.ycombinator.com/item?id=28978086 https://news.ycombinator.com/item?id=28978086
 - homarp 5y ago
 and on zoom itself https://googleprojectzero.blogspot.com/2022/01/zooming-in-on-zero-click-exploits.html https://googleprojectzero.blogspot.com/2022/01/zooming-in-on... also see https://news.ycombinator.com/item?id=29982954 https://news.ycombinator.com/item?id=29982954 "Zooming in on Zero-click Exploits " the researcher used the Linux client to do the RE work... so I guess it's not just for 'bug' but also for free security audit! (2 CVE were reported)
ho_schi 5y ago
As an aside, the Flathub package is another incredible example of how much volunteer labor Zoom benefits from, but neither takes advantage of internally or passes along back to their users. I guess they would rather continue having to maintain iffy support for 7 distributions than make a Flatpak release official which would cover them all…and make updates automatic. It is incredible that their all still companies which try to support specific Linux distributions. YOU SHALL NOT! And it was never an acceptable or useful practice. Release the source or at least the binaries and allow redistribution. But how? Put the necessary information into the usual README.txt (e.g. dependencies) and LICENSE.txt (e.g. copyright ACME, redistribution allowed). Thank you :) In addition you can - but don't must - maintain a Flatpak for all distributions. PS: Even Valve did that mistake and fixed it quickly - many years ago. Look at your ~/.steam you will find there a file which allows redistribution.
bArray 5y ago
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-window-on-Wayland-Linux-when-will-be/td-p/20324 https://community.zoom.com/t5/Meetings/Sharing-application-w...) [of](https://community.zoom.com/t5/Meetings/Linux-screen-sharing-broken-in-new-client/td-p/3067 https://community.zoom.com/t5/Meetings/Linux-screen-sharing-...) [the](https://community.zoom.com/t5/Meetings/Unable-to-share-screen-on-Linux-Fedora-at-200-scale-factor-of-a/td-p/10737 https://community.zoom.com/t5/Meetings/Unable-to-share-scree...) [..] Why do you need JS to translate your unreadable HTML into readable HTML?
- duiker101 5y ago
  > _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 https://write.as/n5r0vjolumdnuk2k.md
  - deleted 5y ago
    [deleted]
  - CameronNemo 5y ago
    @dang can we get the link updated?
    - kxra 5y ago
      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 https://write.as/hash.md#title that seems to preserve it
      - amatecha 5y ago
        It was probably submitted incorrectly, my guess
        5y ago
indymike 5y ago
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.
pmontra 5y ago
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 the screenshotting implemented by Zoom. I know time and money are finite but replacing X11 is a huge task. I'm still on X11 exactly because of problems like this one.
- ddtaylor 5y ago
  > 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)
  - peakaboo 5y ago
    I share my desktop screen in Google Meet using pipewire as well, and just like you say, I get a choice which screen or window I want to share and that's it. Wayland is very stable these days.
- renox 5y ago
  Fedora's credo is to deploy new technologies so they did a lot of rushed deployment, no surprise there but I don't see how this "excuse" Zoom, 2018 is not so recent anymore..
- throwdbaaway 5y ago
  > Is this really a problem with Zoom or one with Wayland and the Linux distros? I would say this is really a problem with Zoom, mostly due to the lack of attention paid to their web client. For me, when it comes to video conferencing, the "table stakes" is working duplex audio over bluetooth, and so far only pipewire has solved this, which means Linux only. After that, two very important features to have are screen sharing and background blur. For screen sharing, both Chrome/Chromium and Firefox have great support for screencast over pipewire, and so do many wayland compositors such as KDE kwin. As such, on a "pure" wayland system with no X11 window [1], screen sharing is also a solved problem. Background blur is more ... complicated. When Google Meet rolled out https://ai.googleblog.com/2020/10/background-features-in-google-meet.html https://ai.googleblog.com/2020/10/background-features-in-goo..., it immediately worked with chrome/chromium, on either wayland or X11. However, to this day, I think it still doesn't work with firefox, for whatever reason. Meanwhile, Zoom Linux client only started to support background blur (without green screen) since 5.7.6 released in August 2021, while Zoom web client remains hopeless. In my previous job, we use Google Meet, and all is well with wayland. In the current one, we use Zoom, and I have to setup https://github.com/fangfufu/Linux-Fake-Background-Webcam https://github.com/fangfufu/Linux-Fake-Background-Webcam as a workaround. [1] This is very much doable these days, unless you want to run Slack desktop, which is hit-and-miss when running with --ozone-platform=wayland (unlike other electron-based apps such as Signal desktop), and of course the Zoom Linux app, which is just crap, as described in the article. Solution: run Slack and Zoom as Firefox tabs.
Asooka 5y ago
This reads more like "How to ruin user acquisition at a critical time by being a stubborn jackass". There is no way just supporting the relevant X11 APIs wouldn't have been possible. Both projects live under the same foundation, it should be possible to make it so when an X11 application tries to record the desktop to pop up a notification in the Wayland shell like "App Z wants to record your screen, allow? [Yes] / [No]". If there was an actual project manager this issue would have been marked "critical" two years ago and fixed. Because actually supporting the software that exists today, and not theoretical future software, is critical for projects that seek to replace foundational OS technologies, e.g. Wayland. I'm not asking for Microsoft-level iron backwards compatibility, but not supporting Zoom during COVID is about the most braindead move I can imagine. Not that I expect anything to improve, I've been using Linux daily since 2005 and this is par for the course for the Linux "desktop".
denton-scratch 5y ago
> In 2016, Fedora switched to Wayland entirely, and has since been joined by Ubuntu, RHEL, Debian, and others. Debian, for one, has not switched to Wayland entirely. I didn't read on; counterfactuals tend to have that effect on me.
- the_why_of_y 5y ago
  Debian has switched to Wayland with the release of buster (version 10) in 2019. https://www.debian.org/releases/buster/amd64/release-notes/ch-whats-new.en.html#wayland-by-default-on-gnome https://www.debian.org/releases/buster/amd64/release-notes/c...
  - denton-scratch 5y ago
    The Debian default became Wayland with Buster. Xorg is still supported. The very second sentence of the linked release notes states that Xorg is still installed by default.
    - the_why_of_y 5y ago
      Yes, of course. Same as every other distro that defaults to Wayland today.
bvrmn 5y ago
Most security features of Wayland is useless for most of Linux desktop users. And there is no way to tune security. It's always on "nothing useful works" level.
0xbadcafebee 5y ago
> which meant a lack of security (allowing all apps full access to spy on the entire screen) I really do not care if an application that I installed can "spy" on my screen. It can execute arbitrary code on my machine. My security concerns no longer exist. I really hope developers will abandon wayland, policykit, rtkit, dbus, systemd, and the rest of the overkill that now unnecessarily introduces bugs and complexity into the Linux desktop. My laptop shouldn't need an entire distributed system to let me click some buttons in a GUI. Maybe the problem is we let corporations like RedHat and Ubuntu tell us how the desktop should work (it's their developers introducing all this crap). Maybe it's time to start over.
dathinab 5y ago
I'm not surprised, I mean they didn't even manage to have proper browser support. Like last times I had to do interviews from Teams, Slack over Google Meet to (best experience) Jitsi everything worked more or less on chrome, Meet worked also on Firefox, Jitsi flawless on Firfox. And Zoom? Randomly decided to not deliver audio, at all. No way to fix it, no reconfiguration of inputs, while others did work at the same time, so probably not a browser bug either.
jchw 5y ago
Most irritatingly, I use v4l2loopback to do screen capture, but i need to emulate the gnome screenshot API and lie about what environment I’m on to even get the option to use a secondary webcam as desktop sharing, even though that’s just v4l2 and not related to any of this.
__s 5y ago
> permission-less screen snooing. snooping
avrionov 5y ago
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 ( < 500ms). The presenter can change and any moment and clients can join at any time and they expect the screen-sharing stream to start immediately. - 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.
- throwdbaaway 5y ago
 > The native clients offer much better performance on every operating system. Background blur uses significantly less CPU in Google Meet running as a chrome/chromium tab, than in native Zoom Linux client. Besides, Zoom Linux client also makes some arbitrary decision that my more powerful i7-3720QM is not qualified to have background blur enabled, while my less powerful i5-8250U is allowed to do so. Background blur works just fine with both CPUs in Google Meet. From your POV, perhaps Zoom product/engineering is doing a good enough job. From my POV, what we have is a crappy Zoom Linux client and a half-arsed Zoom web client. And if corporate wants to give everyone Mac and Windows machines only, just so its highly paid engineers and highly paid product managers can share their screen over a Zoom session, who can argue with that logic?
not2b 5y ago
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%.
- linsomniac 5y ago
  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.
- binwiederhier 5y ago
  I agree with this wholeheartedly. Zoom on Ubuntu works perfectly. It supports switching audio and video sources, annotating, screen sharing with previews of screens, window sharing, even break out rooms and the chat. Some things feel a bit unpolished but it pretty much just works. The only thing I ever had trouble with are custom backgrounds, and they are a little silly anyway.
  - listic 5y ago
    What's wrong with custom backgrounds? I tried them and they worked amazingly well for me.
    - binwiederhier 5y ago
      It sort of works, but the background cuts in my face and arms and all that all the time. It may just be my actual background isn't optimized. Overall I'm happy with zoom.
- 5y ago
cosmiccatnap 5y ago
thrower123 5y ago
How terrible is the Windows version of Zoom running on Wine/Proton?
cupcake-unicorn 5y ago
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.
- avrionov 5y ago
  Genuinely curious: which are these areas where Zoom shouldn't be used?
  - cupcake-unicorn 5y ago
    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.
rozab 5y ago
I have had 0 issues using zoom on Linux with X. I am disappointed with the constant hostility by Wayland proponents to projects which have problems with screencasting (i.e. literally everyone). Even prominent OSS projects like OBS only implemented it recently.
mcfedr 5y ago
It's amazing the amount of engineering zoom is willing to do to work around os security. Just because they don't want to ask user permission to do screen sharing they do this while screen shot thing. Reminds of how they made a whole security issues filled webserver for macos just to avoid the browser security button to open their app.

204 points by 6581 5y ago

Not having opened the rendered (.md) file, made me see this nice touch: Each of the words in "One of the many threads" is pointing to a different thread

solarkraft 5y ago

Big news, guys: Zoom sucks! Not only do you not have to feel bad about having Zoom on your computer, using it in the browser also enables screen sharing through it (the web app sucks, but it's not like the desktop one doesn't).

FengLengshun 5y ago

...is it just me, or is the site broken? The link didn't display correctly and it shows as the raw markdown instead of the formatted result (checked with both Brave and Firefox, in private windows in case it's some extension). Is that just how the site is? It's very distracting regardless.

teilo 5y ago

How not to code an HTML page by hand.

exciteabletom 5y ago
How not to code an <a href="https://en.wikipedia.org/wiki/HTML">HTML</a> https://en.wikipedia.org/wiki/HTML">HTML</a> page by hand.
- JonathonW 5y ago
 In next week's episode, how not to write your URL-detection regex.
 - sodality2 5y ago
 You can't parse [X]HTML with regex: https://stackoverflow.com/a/1732454 https://stackoverflow.com/a/1732454
kxra 5y ago
The end of the URL got trimmed upon submition, so its pointing to the unrendered markdown URL for some reason. Here's the rendered page: https://write.as/n5r0vjolumdnuk2k.md#title https://write.as/n5r0vjolumdnuk2k.md#title
- 988747 5y ago
  Why won't trimmed URL simply redirect to a proper one? Or throw 404 even? This seems like a webserver misconfiguration of sorts, kind of like being able to access raw PHP pages, instead of rendered ones.
  - SahAssar 5y ago
    I'm guessing write.as is supposed to support multiple languages, and only renders the markdown if you have .md as an extension.
    - wnoise 5y ago
      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.
      - kxra 5y ago
        Agreed. Write.as is open source, you can file a ticket against WriteFreely on github
      - SahAssar 5y ago
        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.
- Operyl 5y ago
  Thank god, I was thinking it was some stylistic choice to have to read all those links inline in unrendered markdown.

AshamedCaptain 5y ago

Most desktop Linuxes are changing and deprecating APIs way too fast for the usual glacial development flow of a big commercial software company. The fact that apparently the API for Wayland/Flatpak screen recording is less than 5 years old and it still does not work on X11 desktops does not inspire a lot of confidence, either. However, desktop video calls and screencasting is one area where I think the free and open source alternatives are up to the task.

jatone 5y ago
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.
- AshamedCaptain 5y ago
  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 flat-out wrong, and I'm willing to bet, it's still the most used option (since even on the distros which use Wayland, in-place updates do not usually turn it on). The fact that today's screencast API does not even bother to implement support for the most used window server out there does not inspire confidence, either.
  - onli 5y ago
    > 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.

suby 5y ago

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.

Hakashiro 5y ago
Using Linux is not a practical decision. It is an ethical/moral decision or simply just because you like tinkering. That's fine. I like getting shit done. But then, getting mad because your favourite closed source company doesn't support Linux well is a little ridiculous. Zoom works fine on macOS and Windows. Linux is always bound to have issues one way or another, and if that's not enough, there's not even an incentive for developers to do things the right way, so get over it.
tapoxi 5y ago
This is just an Nvidia issue, they spent years trying to push their own driver model and have only recently come around.
mixedCase 5y ago
While this doesn't detract from your argument given the timelines; if you're on Arch, try again. I believe it was yesterday that the one major Qt fix that made Wayland KDE usable on Nvidia landed. Apparently Sway too has worked fine since the release of Nvidia drivers with GBM support. I'm on AMD right now so can't confirm.
- mijoharas 5y ago
  As an nvidia hostage I can confirm that arch and sway works. (currently works out of the box with nouveau, I think I previously had to mess around with the proprietary driver and wayland-eglstreams. That stopped working around when the new driver with GBM support was released I think. uninstalling the eglstreams and switching to nouveau fixed it)
5y ago

Fabricio20 5y ago

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 me like some engineer at Zoom was tasked with fixing "linux" back in 2020 and after having several issues similar to what I described (possibly unable to capture other applications?) they decided that quickly screenshotting the screen was a good enough fix. Sadly linux still represents a minority of users so this issue was probably not prioritized as necessary.

jatone 5y ago
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 and worked with upstreams to get the support in place. then they could have properly pointed to upstream and said 'it won't work until these issues are fixed' and provided resources to fix them. as a result now they are in a shit position of having a completely broken app when the APIs in question do work. I know because I've built a screencasting program on top of them to cast my desktop to chromecast.
- shadowgovt 5y ago
  Zoom is not as big a company as people think... They're just hustling very hard relative to the sudden explosion of use of their tools. I'd be willing to wager money that their development process involved attempting to use the correct API, finding that it either failed on a key executive's machine or the developers' own machines (possibly because of one bad driver/hardware/os configuration) but because it didn't work for single key player, they had to invent a work around with a worse solution that worked on the spanning set of architectures they needed it to work on.

DarthNebo 5y ago

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

shadowgovt 5y ago
WebRTC implementations haven't converged yet. Roll your own app, or trust to the winds of multiple browser developers and rely on a library produced by Google that you may not have the resources to fix if it breaks on a key hardware / software configuration? No good choices here, only trade-offs.
AshamedCaptain 5y ago
Really? They're the only commercial company that bothers to create a native client (and not a Electron app) and you complain that you would prefer to have no client at all? I don't think that's the majority opinion... I'm no fan of them (I think free apps are up to the task), but give me a native client _any day_ over something that runs in a browser. I don't want any more multi-GB RAM hoarding processes running 24h on my desktop.
- KingMachiavelli 5y ago
  Native clients may be preferred for things that are mostly offline anyway like a text editor. But for something like Zoom, it just makes sense to have a good web app and ship an Electron build for the people who really need a standalone app. The probability of browsers and by extension Electron eventually having best in class screen sharing is basically 100% since that's what almost everyone uses so there's a vested interest by some of the largest companies in the world to make it work. This is not true for the desktop application frameworks. While Zoom did have pretty good screen sharing (on Linux) via the desktop client, it had a awful bug where it would just freeze the entire system making it unusable. Since 99% of people are already going to have a browser open, the incremental memory usage of a webapp is actually pretty minimal. Electron apps are a bit heavier (mostly due to the fact they all ship with their own Electron version) but it's a small trade-off given the benefits such as having the chromium sandbox and cross-platform compatibility. Even smaller things like having a more robust and secure video decoding stack is a major advantage since it sucks when 10 applications all link against an old, vulnerable version of ffmpeg.

presz 5y ago

People still call it GNU+Linux? Modern distros have less GNU pieces on each iteration. Might as well start calling it Gnome+Linux from now on.

teddyh 5y ago
“that is not the deepest way to consider the question.” — https://www.gnu.org/gnu/linux-and-gnu.html https://www.gnu.org/gnu/linux-and-gnu.html
- adwn 5y ago
  That entire page can basically be summarized as "The GNU components in Linux distributions are becoming less significant each year, but please call it the 'GNU system' anyway because we like that name better."
- Shared404 5y ago
  I... don't like the argument made here. > But the reason it is an integrated system—and not just a collection of useful programs—is because the GNU Project set out to make it one. We made a list of the programs needed to make a complete free system, and we systematically found, wrote, or found people to write everything on the list. First of all, I mostly use Alpine for Linux servers, so I guess that should be referred to as Busybox/Linux according to this? Second, the work done to make an integrated OS on desktop is not done by GNU anymore[0], it is done by the GNOME/KDE dev's. [0] Also, what does "integrated" even mean in the context of a UNIX-like OS. Doesn't that sorta defeat the point?
  - yjftsjthsd-h 5y ago
    > First of all, I mostly use Alpine for Linux servers, so I guess that should be referred to as Busybox/Linux according to this? Yes. GNU/Linux, Busybox/Linux, and Android/Linux are all different things, and all perfectly good descriptions.
    - Shared404 5y ago

YEwSdObPQT 5y ago

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 and it absolutely useless as I have to crop the video afterwards). Slack and Discord can't share the whole screen. Not much of an issue with Discord. But with Slack sometimes I need to demo my whole screen and it doesn't work with Wayland enabled in Gnome. So this isn't a problem just for zoom. It seems other software has problems with this as well. Also with Wayland I have weird issues when using a browser (doesn't matter which one I've tried them all) if the memory usage on my dev machine goes up over 32gb (I have 64GB installed). Wayland starts to slow down. Windows seems to start becomes randomly unresponsive and scrolling keeps hitching. It isn't the CPU time because I ran top and the CPU usage was fine. Before anyone tells me not to use a Nvidia card or Do I have the right drivers installed etc. I am using kernel 5.10 on debian 11 (bullseye) and I have a AMD 6800XT. I have the correct firmware installed and I played Rise of the Tomb Raider (linux native games) recently at 4k with absolutely no problems (I have one crash in 40 hours of gameplay). So it not the card or the drivers. I've basically given up using Wayland. The only issue I've had was screen tearing in Dark Souls 3 and a few other games that were being played via proton and that was solved by enabling TearFree in an Xorg conf file. cat /etc/X11/xorg.conf.d/20-amd.conf Section "Device" Identifier "AMD" Driver "amdgpu" Option "TearFree" "true" EndSection People keep on saying Wayland is better, X11 is rubbish. But I frequently find the opposite. I know there are security issues. But I need the full screen record and I've tried almost everything and none of the software (open or proprietary) I've tried works properly with Wayland.

throwdbaaway 5y ago
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.
- YEwSdObPQT 5y ago

phkahler 5y ago

OBS studio only recently got it right on Wayland. I'm not so sure Zoom has been slacking since 2018 on this one.

RcouF1uZ4gsC 5y ago

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

Filligree 5y ago
> 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.
matheusmoreira 5y ago
> 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.
- badsectoracula 5y ago
  You need workarounds but you can make it work. Though you can say the same thing for Linux too, it is just that Windows coming out of the box with a much richer API (e.g. for GUI functionality) makes things easier.
- AnIdiotOnTheNet 5y ago
  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 works so well in part because Windows APIs are so stable.

encryptluks2 5y ago

They don't care about you, stop pretending like they will. You chalk this up as incompetence but it is more than that as shown by their actions.

thanatos519 5y ago

Microsoft Teams: Hold my beer.

asveikau 5y ago

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.

chaorace 5y ago
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 entire system that isn't up to the job. Being forced to jump through hoops like that when you're using a common and modern system configuration is a sign of a poorly supported product and something users should rightfully complain about.
- yjftsjthsd-h 5y ago
  > 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.
  - nemetroid 5y ago
    You can run it, but not with reasonable screen sharing support, which arguably is a part of "supporting the distro".
    - yjftsjthsd-h 5y ago
      My point was that distos don't map 1-1 to Xorg or Wayland; you can run the very latest Fedora with Xorg, or Ubuntu 18.04 with Wayland. They support the distro just fine, the problem is a specific graphical server.

seltzered_ 5y ago

Thanks for sharing this. I'm using a relatively simple setup (Ubuntu 21.10 on wayland, single hiDPI tablet display - no secondary gpu, no second monitor) and was frustrated to see Zoom screensharing only show the upper right quarter of the screen (presumably due to not accounting for hidpi) recently. This said, it generally works fine, and am thankful Zoom at least exists on Linux. -- "If you're stuck using Zoom [...] we can work to pry our organizations and loved ones away from the hapless engineering at Zoom." I disagree with this sentiment. Zoom has been a huge enabler with it's setup to minimize video/audio latency compared to the other solutions I've seen when faciliating a global audience that doesn't necessarily have fast internet access.

throwdbaaway 5y ago
Zoom product/engineering is indeed hapless when compared to Google Meet product/engineering.

smoldesu 5y ago

> and the inevitability of a complete switchover is known. Uh, yeah, no. If you press even the most hardcore of Wayland advocates, they'll eventually admit that Wayland is not a true replacement for Xorg. They'll make the case that you shouldn't use Xorg, but at the end of the day, Wayland's development will always be a treadmill since it's goal is to be less feature-complete than the protocol it's replacing. Yes, I hate x11. Yes, I want a better window server. Wayland is absolutely, positively not it though, and I reckon I'll be sticking with Xorg for the foreseeable future (at least 5 years). This is yet another "why won't companies take Wayland seriously!?" blogpost. You want your answer? It's because Wayland has been in development for more than a decade, with top-priority attention from the most well-funded organizations in open source. And it's still not finished.

mikepavone 5y ago

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 usually pretty hosed if you've installed a malicious native app anyway...), but this kind of requirement tends to break existing abstractions. Now on some level, that's not a big deal. Having to use a different UI flow on Wayland than everywhere else is annoying, but that's just life in software development. BUT, Linux has a relatively tiny share of the desktop market which makes it hard to justify devoting engineering resources to it. When you've only got 1% of the market, you're only going to get good adoption of a new API if you make it easy.

pmontra 5y ago
> 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.
- mikepavone 5y ago
  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.
5y ago

aidenn0 5y ago

There are many good points, but the article says "Wayland has been in development for all this time, and the inevitability of a complete switchover is known" for a time period starting in 2008? Mir was a potential competitor as late as 2017. Today I have yet to successfully run plasma5 under Wayland with success on my home workstation, despite trying annually since 2018.

faisal_ksa 5y ago

A game developer [1] once said that Linux "accounted for <0.1% of sales but >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 unified Linux platform with a friendlier developer experience. Something similar to Android (which has Linux kernel inside it). [1]: https://twitter.com/bgolus/status/1080213166116597760 https://twitter.com/bgolus/status/1080213166116597760 Also, see: https://news.ycombinator.com/item?id=18845205 https://news.ycombinator.com/item?id=18845205

homarp 5y ago
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 something else. You get all the software/os versions, all the logs, you get core dumps and you get replication steps. Sometimes I got with the player over discord and we quickly iterated a few versions with progressive fixes to isolate the problem. You just don’t get that kind of engagement from anyone else. Notably, of those bug reports, fewer than 1% (only 3 bugs) were specific to the Linux version of the game. That is, over 99% of the bugs reported by Linux gamers also affected players in other platforms. Moreover (quoting from the OP): [1] https://old.reddit.com/r/gamedev/comments/qeqn3b/despite_having_just_58_sales_over_38_of_bug/ https://old.reddit.com/r/gamedev/comments/qeqn3b/despite_hav... also see https://news.ycombinator.com/item?id=28978086 https://news.ycombinator.com/item?id=28978086
- homarp 5y ago
  and on zoom itself https://googleprojectzero.blogspot.com/2022/01/zooming-in-on-zero-click-exploits.html https://googleprojectzero.blogspot.com/2022/01/zooming-in-on... also see https://news.ycombinator.com/item?id=29982954 https://news.ycombinator.com/item?id=29982954 "Zooming in on Zero-click Exploits " the researcher used the Linux client to do the RE work... so I guess it's not just for 'bug' but also for free security audit! (2 CVE were reported)

ho_schi 5y ago

As an aside, the Flathub package is another incredible example of how much volunteer labor Zoom benefits from, but neither takes advantage of internally or passes along back to their users. I guess they would rather continue having to maintain iffy support for 7 distributions than make a Flatpak release official which would cover them all…and make updates automatic. It is incredible that their all still companies which try to support specific Linux distributions. YOU SHALL NOT! And it was never an acceptable or useful practice. Release the source or at least the binaries and allow redistribution. But how? Put the necessary information into the usual README.txt (e.g. dependencies) and LICENSE.txt (e.g. copyright ACME, redistribution allowed). Thank you :) In addition you can - but don't must - maintain a Flatpak for all distributions. PS: Even Valve did that mistake and fixed it quickly - many years ago. Look at your ~/.steam you will find there a file which allows redistribution.

bArray 5y ago

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-window-on-Wayland-Linux-when-will-be/td-p/20324 https://community.zoom.com/t5/Meetings/Sharing-application-w...) [of](https://community.zoom.com/t5/Meetings/Linux-screen-sharing-broken-in-new-client/td-p/3067 https://community.zoom.com/t5/Meetings/Linux-screen-sharing-...) [the](https://community.zoom.com/t5/Meetings/Unable-to-share-screen-on-Linux-Fedora-at-200-scale-factor-of-a/td-p/10737 https://community.zoom.com/t5/Meetings/Unable-to-share-scree...) [..] Why do you need JS to translate your unreadable HTML into readable HTML?

duiker101 5y ago
> _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 https://write.as/n5r0vjolumdnuk2k.md
- deleted 5y ago
  [deleted]
- CameronNemo 5y ago
  @dang can we get the link updated?
  - kxra 5y ago
    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 https://write.as/hash.md#title that seems to preserve it
    - amatecha 5y ago
      It was probably submitted incorrectly, my guess
      - 5y ago

indymike 5y ago

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.

pmontra 5y ago

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 the screenshotting implemented by Zoom. I know time and money are finite but replacing X11 is a huge task. I'm still on X11 exactly because of problems like this one.

ddtaylor 5y ago
> 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)
- peakaboo 5y ago
  I share my desktop screen in Google Meet using pipewire as well, and just like you say, I get a choice which screen or window I want to share and that's it. Wayland is very stable these days.
renox 5y ago
Fedora's credo is to deploy new technologies so they did a lot of rushed deployment, no surprise there but I don't see how this "excuse" Zoom, 2018 is not so recent anymore..
throwdbaaway 5y ago
> Is this really a problem with Zoom or one with Wayland and the Linux distros? I would say this is really a problem with Zoom, mostly due to the lack of attention paid to their web client. For me, when it comes to video conferencing, the "table stakes" is working duplex audio over bluetooth, and so far only pipewire has solved this, which means Linux only. After that, two very important features to have are screen sharing and background blur. For screen sharing, both Chrome/Chromium and Firefox have great support for screencast over pipewire, and so do many wayland compositors such as KDE kwin. As such, on a "pure" wayland system with no X11 window [1], screen sharing is also a solved problem. Background blur is more ... complicated. When Google Meet rolled out https://ai.googleblog.com/2020/10/background-features-in-google-meet.html https://ai.googleblog.com/2020/10/background-features-in-goo..., it immediately worked with chrome/chromium, on either wayland or X11. However, to this day, I think it still doesn't work with firefox, for whatever reason. Meanwhile, Zoom Linux client only started to support background blur (without green screen) since 5.7.6 released in August 2021, while Zoom web client remains hopeless. In my previous job, we use Google Meet, and all is well with wayland. In the current one, we use Zoom, and I have to setup https://github.com/fangfufu/Linux-Fake-Background-Webcam https://github.com/fangfufu/Linux-Fake-Background-Webcam as a workaround. [1] This is very much doable these days, unless you want to run Slack desktop, which is hit-and-miss when running with --ozone-platform=wayland (unlike other electron-based apps such as Signal desktop), and of course the Zoom Linux app, which is just crap, as described in the article. Solution: run Slack and Zoom as Firefox tabs.

Asooka 5y ago

This reads more like "How to ruin user acquisition at a critical time by being a stubborn jackass". There is no way just supporting the relevant X11 APIs wouldn't have been possible. Both projects live under the same foundation, it should be possible to make it so when an X11 application tries to record the desktop to pop up a notification in the Wayland shell like "App Z wants to record your screen, allow? [Yes] / [No]". If there was an actual project manager this issue would have been marked "critical" two years ago and fixed. Because actually supporting the software that exists today, and not theoretical future software, is critical for projects that seek to replace foundational OS technologies, e.g. Wayland. I'm not asking for Microsoft-level iron backwards compatibility, but not supporting Zoom during COVID is about the most braindead move I can imagine. Not that I expect anything to improve, I've been using Linux daily since 2005 and this is par for the course for the Linux "desktop".

denton-scratch 5y ago

> In 2016, Fedora switched to Wayland entirely, and has since been joined by Ubuntu, RHEL, Debian, and others. Debian, for one, has not switched to Wayland entirely. I didn't read on; counterfactuals tend to have that effect on me.

the_why_of_y 5y ago
Debian has switched to Wayland with the release of buster (version 10) in 2019. https://www.debian.org/releases/buster/amd64/release-notes/ch-whats-new.en.html#wayland-by-default-on-gnome https://www.debian.org/releases/buster/amd64/release-notes/c...
- denton-scratch 5y ago
  The Debian default became Wayland with Buster. Xorg is still supported. The very second sentence of the linked release notes states that Xorg is still installed by default.
  - the_why_of_y 5y ago
    Yes, of course. Same as every other distro that defaults to Wayland today.

bvrmn 5y ago

Most security features of Wayland is useless for most of Linux desktop users. And there is no way to tune security. It's always on "nothing useful works" level.

0xbadcafebee 5y ago

> which meant a lack of security (allowing all apps full access to spy on the entire screen) I really do not care if an application that I installed can "spy" on my screen. It can execute arbitrary code on my machine. My security concerns no longer exist. I really hope developers will abandon wayland, policykit, rtkit, dbus, systemd, and the rest of the overkill that now unnecessarily introduces bugs and complexity into the Linux desktop. My laptop shouldn't need an entire distributed system to let me click some buttons in a GUI. Maybe the problem is we let corporations like RedHat and Ubuntu tell us how the desktop should work (it's their developers introducing all this crap). Maybe it's time to start over.

dathinab 5y ago

I'm not surprised, I mean they didn't even manage to have proper browser support. Like last times I had to do interviews from Teams, Slack over Google Meet to (best experience) Jitsi everything worked more or less on chrome, Meet worked also on Firefox, Jitsi flawless on Firfox. And Zoom? Randomly decided to not deliver audio, at all. No way to fix it, no reconfiguration of inputs, while others did work at the same time, so probably not a browser bug either.

jchw 5y ago

Most irritatingly, I use v4l2loopback to do screen capture, but i need to emulate the gnome screenshot API and lie about what environment I’m on to even get the option to use a secondary webcam as desktop sharing, even though that’s just v4l2 and not related to any of this.

__s 5y ago

> permission-less screen snooing. snooping

avrionov 5y ago

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 ( < 500ms). The presenter can change and any moment and clients can join at any time and they expect the screen-sharing stream to start immediately. - 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.

throwdbaaway 5y ago
> The native clients offer much better performance on every operating system. Background blur uses significantly less CPU in Google Meet running as a chrome/chromium tab, than in native Zoom Linux client. Besides, Zoom Linux client also makes some arbitrary decision that my more powerful i7-3720QM is not qualified to have background blur enabled, while my less powerful i5-8250U is allowed to do so. Background blur works just fine with both CPUs in Google Meet. From your POV, perhaps Zoom product/engineering is doing a good enough job. From my POV, what we have is a crappy Zoom Linux client and a half-arsed Zoom web client. And if corporate wants to give everyone Mac and Windows machines only, just so its highly paid engineers and highly paid product managers can share their screen over a Zoom session, who can argue with that logic?

not2b 5y ago

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

linsomniac 5y ago
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.
binwiederhier 5y ago
I agree with this wholeheartedly. Zoom on Ubuntu works perfectly. It supports switching audio and video sources, annotating, screen sharing with previews of screens, window sharing, even break out rooms and the chat. Some things feel a bit unpolished but it pretty much just works. The only thing I ever had trouble with are custom backgrounds, and they are a little silly anyway.
- listic 5y ago
  What's wrong with custom backgrounds? I tried them and they worked amazingly well for me.
  - binwiederhier 5y ago
    It sort of works, but the background cuts in my face and arms and all that all the time. It may just be my actual background isn't optimized. Overall I'm happy with zoom.
5y ago

cosmiccatnap 5y ago

thrower123 5y ago

How terrible is the Windows version of Zoom running on Wine/Proton?

cupcake-unicorn 5y ago

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.

avrionov 5y ago
Genuinely curious: which are these areas where Zoom shouldn't be used?
- cupcake-unicorn 5y ago
  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.

rozab 5y ago

I have had 0 issues using zoom on Linux with X. I am disappointed with the constant hostility by Wayland proponents to projects which have problems with screencasting (i.e. literally everyone). Even prominent OSS projects like OBS only implemented it recently.

mcfedr 5y ago

It's amazing the amount of engineering zoom is willing to do to work around os security. Just because they don't want to ask user permission to do screen sharing they do this while screen shot thing. Reminds of how they made a whole security issues filled webserver for macos just to avoid the browser security button to open their app.