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.
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.
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.
> Was Pipewire even on distros by the time they decided to "abuse the one API"?
No. Pipewire only arrived on the most unstable distros end of last year. It's in no way available for all, and not a common standard (yet). And you are right, wayland in general is not the norm yet. I'd even say it's likely to never replace X11 completely, given its shortcomings and X11's stability.
X11 is moribund. Part of why is because literally everyone who was working on it in a major way, possibly excepting Keith Packard, eventually considered it a dead end and jumped ship to Wayland.
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.
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.
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.
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.
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.
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.
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)
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 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?
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).
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.
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 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?
> 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.
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.
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.
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.
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.
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.
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."
> 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?
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;)
> 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.
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.
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.
> 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.
> 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).
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.
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 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.
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.
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).
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.
> 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.
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.
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.
> 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.
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.
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.
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.
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
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.
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.
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.
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..
> 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.
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 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.
222 comments
[ 3.1 ms ] story [ 323 ms ] threadThe 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.
x11 is no long maintained expecting an modern API to support it is foolish.
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.
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.
If the old thing is broken, and the new thing isn't ready yet, then what are we supposed to do? Use Windows I suppose.
Wayland's justification should be a (theoretically) better platform and codebase.
gnome shell has had some version of the screencast API for 8 years now. pipewire is irrelevant to the discussion.
https://gitlab.gnome.org/GNOME/gnome-shell/-/blame/main/data...
the first commit for the desktop portal (which is the end result of the gnome api above) for wlr was in 2018.
https://github.com/emersion/xdg-desktop-portal-wlr/commit/4e...
2 years before the 2020 date in the article. so in short: in 2020 zoom abused a gnome only api to implement desktop sharing, when a proper gnome only desktop sharing api already existed for ~8 years. which was the precursor to the current desktop portal stuff and you're trying to blame wayland for the problem.
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.
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.
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.
https://www.phoronix.com/scan.php?page=news_item&px=XWayland... https://www.phoronix.com/scan.php?page=news_item&px=XWayland...
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.
Yes it is, the mail you linked at was about a new standalone X server (ie. not XWayland) release by its new maintainer.
> no security fixes
The very previous version released just last month[0] has security fixes.
> or new features are being developed
Two versions before that[1] added a bunch of new features.
[0] https://lists.x.org/archives/xorg/2021-December/060842.html [1] https://lists.x.org/archives/xorg/2021-October/060799.html
Xorg is mostly unmaintained, but still extremely popular, and expecting things to work on it is completely reasonable.
x11 works fine as is, and will continue to do so through xwayland. but don't expect new apis to give a rats ass about x11.
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 ?
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.
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.
LTS distribution before that are on X11, so this discussion doesn't even apply, supporting both is definitely possible since they already support X11.
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.
> 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.
And turns out because _as of today_ it is not yet implemented for wlr https://github.com/emersion/xdg-desktop-portal-wlr/blob/c34d...
This stuff is just way too recent and unstable and changing every day.
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.
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.
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.
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.
(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)
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.
(On Fedora 34, xorg)
What's interesting is that the hardware requirements for the virtual background seem to be higher under Linux than under Win10.
I eventually stopped using OBS because it was overkill, but it worked very well.
My last company used Teams which I had a much better experience with on Linux (gnome+xorg) than Zoom.
Settings, Audio, uncheck Automatically adjust microphone volume.
A few examples:
- My USB headset only works for the first call. Restarting teams let's me use it for one more call
- joining a meeting from the calendar spins forever. Doing it from the chat list works fine
- incoming calls don't ring my Linux teams, but ring everywhere else
- the settings for setting which device to use rarely have any effect; I can use any pulse mixer to switch though
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.
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
Can you elaborate on that?
In other words, "fix" is a relative term.
https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-G...
https://www.phoronix.com/scan.php?page=news_item&px=Mesa-21....
https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-4...
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 use Sway/AMD for desktop but all the photogrammetry software out there requires CUDA. It's a bit of a PITA.
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.
Nvidia does support Wayland.
For KDE, the issue is: https://invent.kde.org/qt/qt/qtwayland/-/merge_requests/24
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.
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?
All RTX 3000 GPUs (both non-TI an TI) together are around 11.4%.
Which sounds like quite a bit.
But again this are systems wit Steam installed.
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.
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.
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.
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.
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.
https://en.wikipedia.org/wiki/Zoom_Video_Communications#Work...
"Small" is relative, but Zoom is punching above its weight for the size of its userbase and the load on its services.
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.
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.
The short answer is that pipewire reimplements pulseaudio and jack, keeping compatability with both at the same time.
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.
I'll let you decide for yourself if that's hyperbole, but I think I'm comfortable sticking with Xorg for now.
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....
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.
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.
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.
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
The link for the web version is easy to miss below a big "download zoom" button though.
— https://www.gnu.org/gnu/linux-and-gnu.html
> 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?
Yes. GNU/Linux, Busybox/Linux, and Android/Linux are all different things, and all perfectly good descriptions.
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?
And, of course, the other reason is because we are Hackers and hackers love their pedantry;)
> And, of course, the other reason is because we are Hackers and hackers love their pedantry;)
Some things never change :P
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.
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.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.
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.
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.
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.
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.
Does anyone know the video I'm thinking of? I'd love to watch it again.
> 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.
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).
[0] https://github.com/otya128/winevdm
[1] https://i.imgur.com/e26mqWP.png
[2] https://i.imgur.com/r5aQNyJ.png
[3] http://runtimeterror.com/tools/lila/
Not only that, but Windows 11 ships with msvbvm50.dll and msvbvm60.dll in \WINDOWS\SysWOW64
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.
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.
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'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.
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).
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.
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.
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.
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.
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.
EDIT: Fixed formatting
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?".
Do you mean that you cannot share the whole desktop? The typical coding / debugging session (browser, editor, terminal) would be very difficult to do.
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.
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.
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.
[1]: https://twitter.com/bgolus/status/1080213166116597760 Also, see: https://news.ycombinator.com/item?id=18845205
> 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_hav... also see https://news.ycombinator.com/item?id=28978086
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)
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.
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.
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.
> If you're stuck using Zoom, jump on [one](https://community.zoom.com/t5/Meetings/Sharing-application-w...) [of](https://community.zoom.com/t5/Meetings/Linux-screen-sharing-...) [the](https://community.zoom.com/t5/Meetings/Unable-to-share-scree...) [..]
Why do you need JS to translate your unreadable HTML into readable HTML?
This might have been added after your comment.
Link with md: https://write.as/n5r0vjolumdnuk2k.md
If that's the case, great work in responding so quickly.
> Link with md: https://write.as/n5r0vjolumdnuk2k.md
You'd think the `.md` would be the markdown and the blank/`.html` would be the HTML? Not the other way around? Might be worth the owner of the website swapping that around afterwards.
Now at least the link here is updated, though my RSS reader had the old link.
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.
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.
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)
Wayland is very stable these days.
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.
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 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.
This is on the same ThinkPad with 2 cores (broadwell era).
I tried Zoom's Blur function on an old as hell Dell Inspiron, probably the first generation i5 on windows and it works well there!
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".
Debian, for one, has not switched to Wayland entirely. I didn't read on; counterfactuals tend to have that effect on me.
https://www.debian.org/releases/buster/amd64/release-notes/c...