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%.
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.
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.
With the same account I had about the same bugs in Teams in different, OS with different computers, and even in my phone, and every time in every machine in every OS I had to close the application and open it again to solve it. They funny thing here is that they weren't account related fails, like not having permission to do Z thing, but not having audio, video, or being unable to watch a shared screen.
By the other hand, a simple thing like Google Meets have worked in any OS without any problem to most of the people I know, and the problems were usually related to microphone and webcam permissions.
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.
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.
I still cannot run a Wayland session on my machine w/ an nvidia 3080 with the latest drivers. It either fails to boot (KDE) or runs at about 15 FPS (Gnome).
It seems a little unreasonable to be this mad at a company for not supporting an environment that doesn't work for the vast majority of hardware out there. Especially given that you can just use Zoom within Firefox.
I dunno. This isn't a person who's throwing a tantrum because something just didn't work perfectly. This is a pretty even-handed description of a problem whose solution was delivered to Zoom on a plate multiple times, which they repeatedly ignored before declaring that they personally discovered the cause and then blamed Gnome. I would have understood if this person got upset and wrote expletive-laden write-up because it's quite an irritating sequence of events, but that's not what this is.
I've been using Zoom on Gnome almost daily in the last three years. I've basically no problem with video conference itself. Video just works for me. But audio is a never ending story. Zoom randomly selects other audio devices, when I quit one video session and start another. Sometimes, I have to to quit zoom and start it again. Sometimes I have to disconnect my table speaker/microphone to be able to use it in zoom again. It still works with every other software I've tried. When I start zoom, I get the dialog to share crash information 95% of the times I start zoom. Zoom is not able to store my account password or even the username under linux. So, when I open my macbook, it's zoom client wakes up, disconnects my zoom client on linux and I have to go fetch my zoom password from 1password once more. The zoom client under linux fails to safe room passwords all the time. The Zoom client makes it extra hard to call it with command line args to open a special room including password immediately. I could go on. It is just a huge pain in the ... . But most "entreprise grade" competitors are far worse.
Even though my experience with Zoom under Linux is much smoother, I can confirm the "random audio device" issue; it may be daunting. And the inability to accept command-line arguments is a choice, not a technical problem.
Another fun bit: the same version of Zoom on the same hardware (T470, i5) offers virtual background support under Windows, and disables it under Linux. The machine has no dedicated GPU to have driver issues with.
I've had luck by adding OBS to the setup. OBS connects to the real webcam and microphone, does whatever magic I want, and exposes the results as a virtual webcam that Zoom uses.
I eventually stopped using OBS because it was overkill, but it worked very well.
Are you using Wayland? My wife saw functions disappear with a recent Zoom update on her quite old laptop, and starting her GNOME session via GNOME on X11 restored those functions.
Or that it presumably makes use of override_redirect, as it escapes the X WM decorations, and draws its own windows not fitting in to the style of one's WM.
That is then made worse if one uses the ability to pop out a chat in a new window, such that it is very difficult to see the popped out chat.
I've resorted to always running the web version in a Chromium instance, that being the only way to make its UI usable.
Oddly enough, the macOS client is a bit more usable, but I've not tried popped out windows there.
Over and above that, it seems to be a bandwidth hog while just sitting there watching an idle chat/team/channel.
Something I'd not use if it hadn't been adopted as the corporate "solution" at $EMPLOYER.
on the mute button, there's a tiny arrow you can click to select your audio device and microphone. you shouldn't have to restart zoom for this (but yes I have had this issue too although it seems to have gotten better).
another thing zoom does to me is mute my mic whenever i switch a session/join a breakout room, but there's an option to disable it controlling the mic in the zoom settings to fix that one
Most people uses intel igpus no?
There's a good nvidia population but it's not the majority, especially in a work environment.
The good news is that Nvidia has finally decided to fix its drivers, it's still beta though.
I think there's a little irony there, considering that the same update that introduced GBM also created a pretty terrible issue where Nvidia would flood your DBUS channels with garbage until you system runs out of memory and crashes.
I wasn't claiming the vast majority were running a 3080, merely that they were running an nvidia card. I mentioned the 3080 to demonstrate that the FPS problems were not a matter of old hw. Regardless, I was wrong on this because I wasn't considering integrated gpu's.
3080 is definitely not the vast majority of hardware.
The vast majority of hardware is:
- older
- a lot of Laptop integrated graphics
- a lot of less expensive graphic cards
Like, I just went and took a look at the price of a 3080 in Germany, no joke it's 1.500€+ on Amazone and Ebay. That is 50%+ more then most people can/want to afford to spend for there whole computer!
In the steam survey it has 1.16% usage, and as a game related Survey it's already biased in it's favor as all the "simple office work only" systems won't even show up there.
I wouldn't be surprised if for Zoom relevant usage it's more like 0.2% (as it includes many more "office focused" systems then gaming systems) or so. So kinda irrelevant?
>> I still cannot run a Wayland session on my machine w/ an nvidia 3080 with the latest drivers.
You might try buying hardware that has proper Linux support. That would include graphics from AMD or Intel, and might even include Apple before nvidia gets it together.
I was aware that AMD had officially supported open source linux drivers, and that Nvidia did not support Wayland. Unfortunately, I needed a machine which would work well with the existing machine learning ecosystem, and that means getting an nvidia card over AMD. It's pretty terrible that the machine learning ecosystem is centered around nvidia hardware.
Yeah, 15 years ago it was nvidia for Linux because they were the only ones with functioning graphics drivers even if they were closed source. Now it's similar for ML on Linux even though for regular graphics the situation has reversed. I suppose many new areas start out with proprietary solutions and become more open and standardized over time?
You'll have to wait until that gets to your distribution to have a usable KDE experience with NVIDIA on Wayland. In general, if you use those GPUs, please use the latest distributions.
It can work but generally you either have performance issues or less library support or run into more operational pains. I mainly work on building library tooling over tensorflow. Losing support for good number of operations is not something that I could reasonably consider. Also cloud amd gpu support is near non-existent and most of my company's compute relies on the cloud. t4 pricing is very nice on gcp.
Like AMD rocm exists for ml, but is very far behind cuda in support/libraries for ml. I don't think any moderate investment in AMD gpus is likely to catch up, so I'm pretty pessimistic of AMD being a good solution for ML usage anytime in the next several years.
I think a hobbyist who already owns an AMD card and wants to do basic ML is only situation I'd consider it. Any other situation and I'd strongly advise against it.
Sorry, I think you misunderstood. This is installing both types of card in the same computer: one for desktop/Wayland (AMD), and the other for ML/CUDA (Nvidia).
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.
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)
> nvidia 3080... vast majority of hardware out there
Uhm, no. Nvidia GPUs are not the vast majority. Unless you are gamer and talking about other gamers, then it might be right, but otherwise, Intel is the wast majority and Intel has had Wayland working fine since forever now.
Intel is not alone in this, either. My AMD Vega64 was running Wayland fine since I bought it in 2017. So if your Nvidia has a problem, ask the people you paid your money to, when they want to solve it.
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.
You'd think the `.md` would be the markdown and the blank/`.html` would be the HTML? Not the other way around? Might be worth the owner of the website swapping that around afterwards.
Maybe the idea is that you edit plain text files but then can optionally claim "this file can be parsed as X", which actually I want to say is kind of cool? Though... I guess if this were my site, to make that less confusing, I would make the plain text version .txt and then just not really have a "default" version.
Do we know why it was modified? I think hackernews stripped off the .md for some reason, but if you submit the URL with an anchor like https://write.as/hash.md#title that seems to preserve it
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.
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.
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.
> In January 2020, Zoom had over 2,500 employees, with 1,396 in the United States and 1,136 in international locations. It is reported that 700 employees within a subsidiary work in China and develop Zoom software.
And Zoom is using that headcount to support 55 billion hours of videoconferencing a year. In contrast, YouTube is supporting only six times that much video watched annually with 40 times Zoom's staff.
"Small" is relative, but Zoom is punching above its weight for the size of its userbase and the load on its services.
Testing on the desktops you claim to support isn't a relative question, it's an absolute question. You can do it - or at least an approximation of it that covers the major facets like Xorg vs Wayland - with 25 employees, let alone 2500.
If you can only share chrome and some apps, that's because you're running Chrome/Discord/Slack/etc in XWayland, hence only having access to other XWayland apps. Chromium (hence Electron apps) still hasn't made the switch to defaulting to wayland when available, you need a few CLI flags to get proper sharing.
You have heard these stories because there were different APIs floating around, some specific to particular compositor families. The author is offering the generic API that should work with all of them.
That's kinda a macrocosm for why Wayland still sucks, though. It always starts with a far-too-small scope, saying "we don't want to retread Xorg's mistakes", after which developers create 15 Competing Standards to replace Xorg functionality, and then the Wayland devs realize that if they don't put their foot down then 90% of the Linux desktop will have a subpar experience. It's a brutal, never-ending treadmill for users and developers alike.
Seems like hyperbole. In this case, there were maybe 3 competing screenshot/screen share methods. None of them were billed as standard. Without the core Wayland devs having to get involved, or even any protocol extensions needing to be made, all of the major desktop environments and even wlroots standardized on a single D-Bus API for the functionality. That API is now a few years old. Yeah it took a while to get adopted/implemented, and Zoom probably has higher priorities. But I do not think X would have magically made the situation better, except by having gone through the process a decade (or more?) ago.
Nobody said the X->Wayland transition would be easy or even straightforward. Only that X has key architectural issues inherent to the protocol and a clean break was needed to make further efficiency and quality gains.
As well as global keyboard shortcuts, compositing effects, efficient framebuffer rendering, xWayland functionality, configuration-agnostic multidisplay support and input polling.
I'll let you decide for yourself if that's hyperbole, but I think I'm comfortable sticking with Xorg for now.
The recommended session manager for pipewire is called WirePlumber. Not something I would think of it I were to look for it on my own. It didn't even exist a couple months back, and about 6months ago pipewire hardly worked on my laptop.
It's great that OBS works fine for you, but it's really odd that Wayland has been around for over a decade and some things people would consider basic functionality has only recently started working.
I for one hope there is something new coming where the core developers aren't so far detached from reality.
Here's my two cents: What even IS pipewire? I know what the compositor is because I've been given the choice of either X or Wayland in the past so I had to learn what they are. I've heard of pipewire in the past but I have no clue what it is, where does it fit in the display stack, etc.. Same for the linux audio stack.
I don't expect final users to know how to do these though. They want to download OBS and it needs to just work. I'm not sure how hard it would be to implement both in the case of Zoom as to support all setups but I'd assume it's not that trivial, and given other comments above where Wayland seems to have had more than one API for capture you can see where some of these issues come from.
OBS working well on Wayland is AFAICT just in the last year. Pipewire is also just landing in the last 6 months - the most recent Fedora release is the first to use it by default.
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.
If it is generally true that the bulk of the folks working on this space in Linux genuinely believe that Wayland is the "future" and X needs to be deprecated, they really need to put up or shut up. I'm not aware of what's going on behind the scenes, but it's painfully obvious that someone was entirely too confident on this whole deal.
It's just very surprising considering how well Linus' philosophy of "never break things backwards" holds up over time, and that the Wayland people appear to have nearly entirely missed this.
flat out incorrect in this case. this has nothing to do with a deprecated API. they just decided to abuse one API when there was an API available for their use case available.
x11 is no long maintained expecting an modern API to support it is foolish.
Was Pipewire even on distros by the time they decided to "abuse the one API" ?
Even I have had to resort to abusing the one API, and it was just for taking the values of a couple pixels on the screen. Everything else is just too slow, requires setting up way too much infrastructure (e.g. PipeWire! a H264 encoder!), or has been fixed "last year" or some other uselessly recent date.
X11 is no longer maintained is also 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.
2 years before the 2020 date in the article. so in short:
in 2020 zoom abused a gnome only api to implement desktop sharing,
when a proper gnome only desktop sharing api already existed for ~8 years.
which was the precursor to the current desktop portal stuff and you're trying to blame wayland for the problem.
1. X11 is definitely maintained, unless you are thinking of XFree86. Xorg's last release 2 weeks ago. Many LTS distros containing it are preparing releases with it _right now_ and they will also be supporting it for at least one decade, probably way more. I would bet that Wayland will become unsupported way before (at least some implementation of) X11 does.
2. This entire article is about avoiding the Gnome private API. The only other alternative, the XDG/portal API, uses Pipewire. It's literally the only alternative even if you don't use Flatpak.
EDIT: Your "2018" link is also not showing the screencast portal API. And I am not blaming Wayland; I am blaming the distros who switch to it and as a consequence BROKE user programs.
1. no its not, no security fixes or new features are being developed, its entirely on life support: the changes are to just keep it limping along while distros finish transitions to wayland. https://lists.freedesktop.org/archives/xorg/2022-January/060...
2. the article is about them abusing a gnome only API when alternatives existed that would have worked better. WLR had its first commits for its desktop portal api in 2018, gnome has had some form of the desktop portal api for 8 years now.
if you're going to use a DE only API at least use the right fucking one.
1. Even if what you were saying was true (which it is not, even your own link is just showing that bugs and regressions are still being fixed), the distros who are shipping have commited to decades of security updates.
2. "The right fucking" Gnome-exclusive API is, obviously, Gnome-exclusive, and just didn't work for me for the reasons I mentioned in my original message, and probably didn't for them either (my guess because they have a custom H264 encoder for latency/licensing reasons). The "less-Gnome-specific" XDG portal API, Pipewire-based, wasn't really usable when the distro is not even packaging Pipewire.
My go-to conferencing solution is still Jitsi Meet and I am well aware of how crazy the entire situation is, even for browsers.
the last release was afaik I know just to get the majority of patches contributed out that had stagnated and to finally split xwayland out of the xserver release.
its dead, the maintainers have said its dead, all major distros have either moved or will be moving in the coming year. x11 as an api will limp along due to xwayland but that's about it.
no amount of assertions will change that unless individuals/organizations step up to actual maintain it.
as for rest of your statement ./shrug I've already been very clear on the fact they were already using a gnome only api incorrectly. the generic desktop portal api not being strictly ready in 2020 due to pipewire doesn't change the fact they had a perfectly reasonable api to use inside gnome and they decided not to and were burned.
> Was Pipewire even on distros by the time they decided to "abuse the one API"?
No. Pipewire only arrived on the most unstable distros end of last year. It's in no way available for all, and not a common standard (yet). And you are right, wayland in general is not the norm yet. I'd even say it's likely to never replace X11 completely, given its shortcomings and X11's stability.
Pipewire has been there for more than that, I've been using it for a few years now.
You might be mistaken with the audio part of it (that replaces Pulseaudio and Jack).
It 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.
X11 is moribund. Part of why is because literally everyone who was working on it in a major way, possibly excepting Keith Packard, eventually considered it a dead end and jumped ship to Wayland.
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.
At the same time, it's because they don't care much. I'm quite sure that if Microsoft or Apple would change the way screen-sharing works between version of their OS, Zoom wouldn't wait 2 years to look at it.
I understand it's not as much market share, but it does make Zoom look really poor in tech companies where using Linux is more common.
It's also quite shameful for a company where the main thing they do is video conference and screen sharing, it's not like it's a small side feature.
Also you make it sounds like it changes every other day, but that's not the case. Screen sharing in wayland has been stable for a while now and it's adopted by all major compositors (mutter, kwin, wlroots).
As you mentioned, it's pretty well supported by a lot of open source software other than Zoom, so there's plenty of implementation examples they can go through as well.
That's why I say that it just moves way too fast for the glacial speed that commercial houses normally have. For at least 2 years (thinking 2016-2018) some distros were even shipping Wayland _without_ an actual working screen capture API. How do you even support those ?
We're not talking about supporting things years ago though, we're talking about supporting it now which is a few years after, when it's been stable and supported across the whole ecosystem for a quite a while.
That's their job, providing multi-platform video-conferencing and screen sharing.
If they can't do that they could chose to drop their app and try to build a decent web version instead because this thing is quite an horror show as well. Screen sharing works well in Chromium and Firefox.
Less than a year ago is NOT "quite a while". A couple years ago is also not quite a while. The fast distributions have a 2 year release cycle for their LTS releases; even longer on the slower distributions. When you have an API that has been stable and working on these distributions for _at least_ 2 of these releases, maybe I will consider using it. I'm not going to rewrite my core business every other year just to use today's API for it to change again by the next release.
I blame the distributions that literally _break_ programs one release to the next without even bothering to ensure that the newer API is working.
I will bet that most of Zoom's Linux-using enterprise customer base is still on Redhat6-7 or similarly old releases, and that is where most of their money likely comes from. Note their support pages explicitly claims they still support them.
You mean 3 years ago? It is a while. Definitely enough, lot of software implemented it in the meantime. Zoom is actually the only one I know that didn't
LTS distribution before that are on X11, so this discussion doesn't even apply, supporting both is definitely possible since they already support X11.
No, I mean last year. The current API for screencast (the only one which might work on anything other than Gnome) uses Pipewire and even OBS didn't support it until last year.
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-window screencasting now works in Gnome since sometime around last year, when I try to do it on _anything_ else I get a black screen.
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.
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.
This solution to require the user to pick and allow screencastig is right and justified. Chromium is doing it already nicely. Bonus, you get the actual allowance and confirmation that it must work as developer.
We see similar approaches on mobile systems. Sadly they stuffed everything into a limited number of buckets {pictures, contacts, gps} and every app requests all of them.
UNIX brought us file-permissions and multi-user and right now Linux ships cgroups and process-permissions. So Chromium wants more than allowed `max.memory`? The kernel has bad news for the memory eating resource hog.
> I'm not entirely convinced this is a big deal since you're usually pretty hosed if you've installed a malicious native app anyway.
This specific restriction is part of a more general push for sandboxing, to limit the damage one app can do. It's probably not massively useful against actually malicious apps, because they'll probably just declare they need arbitrary filesystem access anyway. But it should be beneficial when honest apps have security flaws.
The "low marketshare" argument doesn't work as well for a communication service like Zoom, because it's important for everyone on the Zoom call to have access. If 1% of users have Linux, that means that on a Zoom call connecting 10 randomly chosen users, around 10% have at least 1 Linux user in the call.
Most users on a Zoom call aren't screensharing so I don't think this math remotely works out here.
That said, even when users of a minority platform impact the experience of a broader community you're still going to make development resource tradeoffs based on userbase. Honestly, I think Linux punches way above its weight here because software developers are much more likely to be Linux users than normal people. That said, when development for your platform is happening in developer's free time or in between official priorities*, making things easy is perhaps even more important.
*I don't know if this specifically happening at Zoom, but this kind of thing is not uncommon when it comes to Linux support in commercial apps.
No, you have one Linux user who is now scrambling to get it to work or is using a device that will make it work. Your example sort of under cuts your argument, just imagine sending that email "I will not be attending our remote meetings due to what some may call a philosophical argument with Zoom, rest assured, I am in the right, and as soon as they see the light and correct their ways, I will start attending meetings again".
Instead, in frustration, they will reach for another device. They will use an old laptop, or a smartphone, something.
I used to be in a company that was developing _desktop software exclusively for Linux_ (not multiplatform at all -- Gtk+ based!), and they all (even the developers) used Windows workstations. They would use Windows conferencing software, Windows PIM, Windows mail clients, Windows WWW browsers, Windows IDEs. But all of them would religiously VNC into a Linux server somewhere just to test the tool they were writing. Which they would screencast to fellow developers using Windows software. Nowadays, they likely use Teams (still for Windows).
No one developer found this bizarre. They all claimed it was the same in competitors or previous jobs.
When I asked IT "can I get a laptop with Linux, not Windows?" the response was "but how will you run Outlook?".
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.
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.
> 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)
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.
> 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-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.
[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.
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..
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.
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.
> 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.
I would say advertising support for Fedora (or any other Wayland by default distro) without explicitly saying you don't support Wayland/only support X11 is misleading.
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.
The grandparent referenced Wayland-only distros, so I assumed your comment was about Xwayland. But your point is that there aren't any Wayland-only distros?
Erm. I'm not aware of any Wayland-only distros, except tiny hobby projects (which did it because when they added GUI they just didn't add Xorg). Are there any (widely-used) distros that don't package Xorg?
I used Linux 95% of the time at work and generally it is a mess when it comes to proprietary stuff. Even if it is decently supported there are about 4 different ways to install it and because I use Debian and not Ubuntu I have to hope the package just works with my distro or use snaps.
I've distro hopped around and packaging is a perennial issue no matter which distro you use. Some proprietary apps only support Ubuntu, or Redhat based distros but not CentOS/RHEL and only Fedora even though they are kinda the same thing.
I think at this point I might just download the tarballs and install it manually because I think that might actually be easier.
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.
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.
> 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?
My comments are directed at the general performance of Video and Audio components. Zoom implements their own protocol which performs better than the WebRTC. Their codecs are also better optimized, on of the reasons being that VP8 lacks hardware optimization on many platforms.
Background blur most likely require GPU optimization. The implementation on Windows/Mac and Linux looked different for a while. It is possible that they had to deal with compatibility and driver issues on Linux.
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.
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.
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.
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.
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.
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.
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.
> 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.
> 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?
> I guess that should be referred to as Busybox/Linux according to this?
I don’t know how you could come to that conclusion. The linked page basically says the opposite of that. The Linux project is a project to write a kernel (created to replace the existing MINIX kernel). The Python project is a project to write a programming language (for many operating systems). The GNU project, on the other hand, is to create (and integrate pre-existing parts into) an entire operating system, from the bare metal to the desktop. It’s more like the Debian project in that respect, except that the GNU project themselves write, or asks others to write, a lot of the non-existing components. Debian on the other hand tries to not do much software creation themselves, and has chosen to use the existing parts of the GNU system components combined with the Linux kernel to make a complete and working operating system.
Fair point. I feel like you could make a case for $DE/Linux on desktop, $COREUTILS/Linux on server and Android/Linux on mobile then whenever greater precision is needed.
That said, how often do you need to distinguish between the Coreutils in use? If you say Linux server, unless you specify something out of the ordinary, everyone will assume you have GNU or Busybox coreutils - which doesn't matter that much, you can do pretty much anything with either afaik - and whatever server software is in use. Or on desktop, you can just mention the distro in question and everyone will know or be able to find out all of the above. Why specify every single time?
Honestly you probably should prefer to specify by distro, and use the userspace+kernel convention only when you specifically care or it matters for some reason. If I say Fedora, I probably don't need to say "Fedora GNU/Linux", since GNU and Linux (as well as RPM and systemd) are implicit in "Fedora". On the other hand, "Debian" usually means "Debian GNU/Linux" but Debian has a living HURD version (Debian GNU/HURD) and a basically-dead FreeBSD version (Debian GNU/kFreeBSD), and experimental work has been done to allow replacing its coreutils with... I think the Rust rewrite? So there it can be useful to specify.
And, of course, the other reason is because we are Hackers and hackers love their pedantry;)
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."
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.
> Windows will happily run GUI apps written 20 years ago.
Don't think this is true anymore. Old software on Windows just isn't guaranteed to work anymore. Last time I tried to play an old game on newer Windows versions, it didn't even start up despite automatic and manual installation of a ton of dependencies. I suppose the Raymond Chen stories about heroic bug fixing in third party code is a thing of the past.
Games are an especially difficult case as they have a habit of bypassing higher level APIs and abusing undocumented behavior for performance reasons. Still, a shockingly high number of games from 20+ years ago work out of the box on the latest Windows despite things like the shift from 32 bit to 64, all without recompilation.
Linux Desktop's compatibility story is laughable by comparison unless you count WINE, which works so well in part because Windows APIs are so stable.
Microsoft also used to have a history of maintaining bug compatibility with applications, including use of undocumented data structures and functions. I've read the stories: once they tried to change some data structure only to revert the change when some proprietary software broke because it did insane things like put data into unused bits of some internal data structure.
At some point all this must have been lost because I don't see Microsoft going out of its way to fix memory allocation bugs in games for our benefit anymore. I did try playing the game on Wine and it worked, ironically. Wouldn't be surprised if it eventually became the best way to run older Windows software.
The ABI compatibility situation of Linux user space sucks. Apparently the kernel itself can run binaries from the 90s with no problem. The more dependencies you have, the worse the situation gets because in the free software world people seem to make it a point to avoid caring about binary compatibility since everyone is supposed to have the source code to everything in order to recompile software as needed. Because of this I've personally resolved to eliminate all dependencies in my own code by using Linux system calls directly.
I can't find it now, but I remember there was a video of someone upgrading windows from like Windows 3 all the way to the latest Windows... maybe it was 7? I forget how long ago this was. But each time they upgraded Windows, they showed that the programs installed in the original OS still worked. I think they did it with Doom installed in 3, and showed that it still worked after 20 years of upgrades. That's some impressive backwards compatibility.
Does anyone know the video I'm thinking of? I'd love to watch it again.
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.
A Quake 3 binary compiled in 1999 still runs on Linux today. How much backward compatibility do you need?
> Windows will happily run GUI apps written 20 years ago.
Your best bet at running 16 bit Windows applications on a modern OS is running them via Wine. The same is true for some older 32 bit software.
I wanted to relive some memories replaying my copy of GTA (the first one) on Windows 10 the other day, gave up after about half an hour after multiple step-by-step guides for getting it to run failed, and just installed it on my work laptop that's running a flavor of Linux with Wine. The latter required one extra step - installing some library by ticking a checkbox in winetricks.
For all of Windows' touted backwards compatibility I wasn't exactly impressed. It seems to be little more than a meme at this point. What Windows does better (than other OS) is play modern games, which is why I keep it around on my desktop computer. I'm not sure it deserves credit for that though.
I don't even know what you mean by switching "switches graphics engines". The X to Wayland migration? The former has been backwards compatible for more than three decades and the latter can host the former to remain backwards compatible.
Wishy-washy terminology aside, are you absolutely confident your opinion is formed from an informed position?
There's valid criticisms to be made of desktop Linux, but I don't think those are it.
> Your best bet at running 16 bit Windows applications on a modern OS is running them via Wine.
Fun fact, you can use a WineVDM-based 16bit emulator on Windows[0] that translates 16bit calls to 32/64bit calls and install it system-wide thus allowing the use of 16bit programs in 64bit Windows. Here are two examples from screenshots i have around: Microlathe[1], a small utility to build 3D models by rotating a line around an axis (i also made my own clone[3] of it) and [2]a free Smalltalk environment (Smalltalk Express - which i actually consider one of the simplest Smalltalk environments since it only contains a small subset of what you'd find in a modern one thus making it easier to grok).
> 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.
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.
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.
> The probability of browsers and by extension Electron eventually having best in class screen sharing is basically 100%
And yet they are not! Even multiplatform programs like OBS have better support in Linux than browsers.
> 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.
First we make dynamic linking difficult, then we complain that static linking makes everything old and vulnerable, so as to that the only viable solution is for all desktop development to move to the browser. It doesn't sound very good.
Yes, the desktop client is a complete pain, I have to join a zoom call with a client every few months and for that I have to install a security hold riddled client.
Everything else just opens in my browser where I'm doing 70% of my work anyway, and every random place I visit is secured in it's box
Why would anyone need to install some untrustworthy software though? The web site works fine for me. I can participate in meetings through my browser, everything works.
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.
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".
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
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.
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.
> 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.
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).
> 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):
I have no doubt that Linux users are awesome at reporting, debugging and finding problems. Also, they tend to be tech-savvy. So reporting bugs are not a big deal for them. Unlike most average users.
My argument was about how hard it's to develop and support software for Linux. Not about the users. You have to admit that Linux (due to its fragmentation) is a nightmare to support. And it has a very small users base to justify putting the effort to support all Linux distros and all desktop environments and hardware configurations and Wayland and Xorg ...etc.
I like Linux, and I wish I could use it all the time. But to be honest, it's more work than what I'm willing to do.
I'll agree that your argument that making linux apps easier to write deploy is a good goal. Its not an easy thing when you have a bunch of different windowing libraries (GTK, QT..) a whole host of desktops, multiple distribution channels (flatpack, snap, apt-get...) ususally computing platforms converge on something common, but I haven't seen it in linux. I wonder if I was writing a application for linux, where would I start?
It is a little of chicken and egg problem. Not a lot of users on linux, so not worth writing software for it. Users see there is not a lot of software and might go somewhere else. But there is enough. And most of it is a little buggy and free. Some of the applications are just great (blender, kritta). The core OS is rock solid though.
I've been using it as my home desktop and honestly linux on the desktop is pretty great.
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.
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.
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.
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.
...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).
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.
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.
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
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).
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%.