[HN Gopher] How Not to Support Desktop GNU+Linux, Zoom Edition
___________________________________________________________________
How Not to Support Desktop GNU+Linux, Zoom Edition
Author : 6581
Score : 179 points
Date : 2022-01-21 12:54 UTC (10 hours ago)
(HTM) web link (write.as)
(TXT) w3m dump (write.as)
| DarthNebo wrote:
| Not surprised at all.
|
| Instead of making use of the WebRTC API in the browser, they just
| threw us back to Skype days of needing a native client installed
| on your OS....
| matheusmoreira wrote:
| 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.
| AshamedCaptain wrote:
| Really? They're the only commercial company that bothers to
| create a native client (and not a Electron app) and you
| complain that you would prefer to have no client at all?
|
| I don't think that's the majority opinion...
|
| I'm no fan of them (I think free apps are up to the task), but
| give me a native client _any day_ over something that runs in a
| browser. I don't want any more multi-GB RAM hoarding processes
| running 24h on my desktop.
| KingMachiavelli wrote:
| 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.
| AshamedCaptain wrote:
| > 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.
| Beltalowda wrote:
| You can use the browser version too, no? I used it a few times
| for job interviews in the last few months, and seems to work
| well enough in Firefox.
|
| The link for the web version is easy to miss below a big
| "download zoom" button though.
| shadowgovt wrote:
| 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.
| presz wrote:
| People still call it GNU+Linux? Modern distros have less GNU
| pieces on each iteration. Might as well start calling it
| Gnome+Linux from now on.
| teddyh wrote:
| "that is not the deepest way to consider the question."
|
| -- https://www.gnu.org/gnu/linux-and-gnu.html
| adwn wrote:
| That entire page can basically be summarized as "The GNU
| components in Linux distributions are becoming less
| significant each year, but please call it the 'GNU system'
| anyway because we like that name better."
| Shared404 wrote:
| I... don't like the argument made here.
|
| > But the reason it is an integrated system--and not just a
| collection of useful programs--is because the GNU Project set
| out to make it one. We made a list of the programs needed to
| make a complete free system, and we systematically found,
| wrote, or found people to write everything on the list.
|
| First of all, I mostly use Alpine for Linux servers, so I
| guess that should be referred to as Busybox/Linux according
| to this?
|
| Second, the work done to make an integrated OS on desktop is
| not done by GNU anymore[0], it is done by the GNOME/KDE
| dev's.
|
| [0] Also, what does "integrated" even mean in the context of
| a UNIX-like OS. Doesn't that sorta defeat the point?
| yjftsjthsd-h wrote:
| > First of all, I mostly use Alpine for Linux servers, so I
| guess that should be referred to as Busybox/Linux according
| to this?
|
| _Yes_. GNU /Linux, Busybox/Linux, and Android/Linux are
| all different things, and all perfectly good descriptions.
| Shared404 wrote:
| 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?
| yjftsjthsd-h wrote:
| 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;)
| Shared404 wrote:
| All valid points!
|
| > And, of course, the other reason is because we are
| Hackers and hackers love their pedantry;)
|
| Some things never change :P
| teddyh wrote:
| > _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.
| 0xbadcafebee wrote:
| > which meant a lack of security (allowing all apps full access
| to spy on the entire screen)
|
| I really do not care if an application that I installed can "spy"
| on my screen. It can execute arbitrary code on my machine. My
| security concerns no longer exist.
|
| I really hope developers will abandon wayland, policykit, rtkit,
| dbus, systemd, and the rest of the overkill that now
| unnecessarily introduces bugs and complexity into the Linux
| desktop. My laptop shouldn't need an entire distributed system to
| let me click some buttons in a GUI.
|
| Maybe the problem is we let corporations like RedHat and Ubuntu
| tell us how the desktop should work (it's their developers
| introducing all this crap). Maybe it's time to start over.
| YEwSdObPQT wrote:
| People are saying this is Zoom's fault. Maybe it is. However I've
| given up on Wayland entirely and just gone back to X11.
|
| I frequently need to record my screen to show bugs or fixes in
| features. Most of the open source screen recording software seems
| to only support X11. I've tried quite a few different open source
| alternatives (other than the built Gnome Screen recorder which is
| kinda hidden in a keyboard short-cut and it absolutely useless as
| I have to crop the video afterwards).
|
| Slack and Discord can't share the whole screen. Not much of an
| issue with Discord. But with Slack sometimes I need to demo my
| whole screen and it doesn't work with Wayland enabled in Gnome.
|
| So this isn't a problem just for zoom. It seems other software
| has problems with this as well.
|
| Also with Wayland I have weird issues when using a browser
| (doesn't matter which one I've tried them all) if the memory
| usage on my dev machine goes up over 32gb (I have 64GB
| installed). Wayland starts to slow down. Windows seems to start
| becomes randomly unresponsive and scrolling keeps hitching. It
| isn't the CPU time because I ran top and the CPU usage was fine.
|
| Before anyone tells me not to use a Nvidia card or Do I have the
| right drivers installed etc. I am using kernel 5.10 on debian 11
| (bullseye) and I have a AMD 6800XT. I have the correct firmware
| installed and I played Rise of the Tomb Raider (linux native
| games) recently at 4k with absolutely no problems (I have one
| crash in 40 hours of gameplay). So it not the card or the
| drivers.
|
| I've basically given up using Wayland. The only issue I've had
| was screen tearing in Dark Souls 3 and a few other games that
| were being played via proton and that was solved by enabling
| TearFree in an Xorg conf file. cat
| /etc/X11/xorg.conf.d/20-amd.conf Section "Device"
| Identifier "AMD" Driver "amdgpu"
| Option "TearFree" "true" EndSection
|
| People keep on saying Wayland is better, X11 is rubbish. But I
| frequently find the opposite. I know there are security issues.
| But I need the full screen record and I've tried almost
| everything and none of the software (open or proprietary) I've
| tried works properly with Wayland.
| throwdbaaway wrote:
| Have you tried running slack as a tab in
| chrome/chromium/firefox? I just started doing that very
| recently on wayland, and it seems to work fine.
| indymike wrote:
| 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.
| chagaif wrote:
| 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
| ho_schi wrote:
| _As an aside, the Flathub package is another incredible example
| of how much volunteer labor Zoom benefits from, but neither takes
| advantage of internally or passes along back to their users. I
| guess they would rather continue having to maintain iffy support
| for 7 distributions than make a Flatpak release official which
| would cover them all...and make updates automatic._
|
| It is incredible that their all still companies which try to
| support specific Linux distributions. YOU SHALL NOT! And it was
| never an acceptable or useful practice. Release the source or at
| least the binaries and allow redistribution. But how? Put the
| necessary information into the usual README.txt (e.g.
| dependencies) and LICENSE.txt (e.g. copyright ACME,
| redistribution allowed). Thank you :)
|
| In addition you can - but don't must - maintain a Flatpak for all
| distributions.
|
| PS: Even Valve did that mistake and fixed it quickly - many years
| ago. Look at your ~/.steam you will find there a file which
| allows redistribution.
| bArray wrote:
| How Not to Support HTML Text, write.as Edition:
|
| > If you're stuck using Zoom, jump on
| [one](https://community.zoom.com/t5/Meetings/Sharing-
| application-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?
| hackmiester wrote:
| I don't think it was caused by your lack of JS. I have JS
| enabled and it still did this until I altered the link.
| duiker101 wrote:
| > _Pssst, coming from Hacker News? Add a ".md" to the URL_
|
| This might have been added after your comment.
|
| Link with md: https://write.as/n5r0vjolumdnuk2k.md
| CameronNemo wrote:
| @dang can we get the link updated?
| kxra wrote:
| 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
| amatecha wrote:
| It was probably submitted incorrectly, my guess
| kxra wrote:
| When I tried to resubmit the correct URL, it was stripped
| again. Does it work for you?
| amatecha wrote:
| didn't try myself, but looks like the URL has been
| corrected now! :D
| [deleted]
| bArray wrote:
| > This might have been added after your comment.
|
| If that's the case, great work in responding so quickly.
|
| > Link with md: https://write.as/n5r0vjolumdnuk2k.md
|
| You'd think the `.md` would be the markdown and the
| blank/`.html` would be the HTML? Not the other way around?
| Might be worth the owner of the website swapping that around
| afterwards.
| saurik wrote:
| 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.
| AshamedCaptain wrote:
| Most desktop Linuxes are changing and deprecating APIs way too
| fast for the usual glacial development flow of a big commercial
| software company.
|
| The fact that apparently the API for Wayland/Flatpak screen
| recording is less than 5 years old and it still does not work on
| X11 desktops does not inspire a lot of confidence, either.
|
| However, desktop video calls and screencasting is one area where
| I think the free and open source alternatives are up to the task.
| jatone wrote:
| 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.
| yjftsjthsd-h wrote:
| > x11 is no long maintained expecting an modern API to
| support it is foolish.
|
| _Xorg_ is _mostly_ unmaintained, but still extremely
| popular, and expecting things to work on it is completely
| reasonable.
| jatone wrote:
| I didn't say it was unreasonable to expect x11 to work. I
| said it was unreasonable to expect a modern API to jump
| through hoops to work on x11.
|
| 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.
| AshamedCaptain wrote:
| Was Pipewire even on distros by the time they decided to
| "abuse the one API" ?
|
| Even I have had to resort to abusing the one API, and it was
| just for taking the values of a couple pixels on the screen.
| Everything else is just too slow, requires setting up way too
| much infrastructure (e.g. PipeWire! a H264 encoder!), or has
| been fixed "last year" or some other uselessly recent date.
|
| X11 is no longer maintained is also flat-out wrong, and I'm
| willing to bet, it's still the most used option (since even
| on the distros which use Wayland, in-place updates do not
| usually turn it on). The fact that today's screencast API
| does not even bother to implement support for the most used
| window server out there does not inspire confidence, either.
| onli wrote:
| > _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.
| boudin wrote:
| 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).
| onli wrote:
| It's possible I did not notice the non-audio part was
| already in the wayland-enabling distros before, if that
| was the case.
| bitwize wrote:
| 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.
| Filligree wrote:
| Regardless, if I want to do something as simple as
| running a Minecraft client, I need to run X11 or else
| live with about 20 FPS.
|
| 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.
| yjftsjthsd-h wrote:
| moribund, stable, I don't care what you call it; X11
| actually works consistently, which remains more than
| Wayland can say
| phkahler wrote:
| 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.
| jatone wrote:
| x11 is no longer maintained. you're thinking of xwayland,
| which is the only thing getting releases these days. but
| that is built on wayland.
|
| 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.
| AshamedCaptain wrote:
| 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.
| jatone wrote:
| 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.
| badsectoracula wrote:
| > no its not
|
| 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/06084
| 2.html [1] https://lists.x.org/archives/xorg/2021-October
| /060799.html
| AshamedCaptain wrote:
| 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.
| jatone wrote:
| 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.
|
| https://www.phoronix.com/scan.php?page=news_item&px=XWayl
| and... https://www.phoronix.com/scan.php?page=news_item&p
| x=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.
| boudin wrote:
| 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.
| AshamedCaptain wrote:
| Even stuff such as OBS Studio was significantly slower on
| Wayland than on X11, at least until the efforts done _last
| year_ (e.g. https://feaneron.com/2021/03/30/obs-studio-on-
| wayland/ ) . Single-Window support for screencast API is also
| only a couple years old! Before that it would just error out,
| even if the D-Bus interface was there (
| https://github.com/flatpak/xdg-desktop-portal-
| gtk/blob/b2b5e... ).
|
| 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 ?
| boudin wrote:
| 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.
| AshamedCaptain wrote:
| 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.
| boudin wrote:
| 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.
| AshamedCaptain wrote:
| 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.
| boudin wrote:
| 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.
| AshamedCaptain wrote:
| 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.
|
| 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.
| jrm4 wrote:
| 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.
| phkahler wrote:
| OBS studio only recently got it right on Wayland. I'm not so sure
| Zoom has been slacking since 2018 on this one.
| cosmiccatnap wrote:
| smoldesu wrote:
| > 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.
| bvrmn wrote:
| Most security features of Wayland is useless for most of Linux
| desktop users. And there is no way to tune security. It's always
| on "nothing useful works" level.
| avrionov wrote:
| a few comments from somebody who worked for many years for a
| competitor to Zoom.
|
| The article author complains about some relatively minor details
| but completely misses the big picture.
|
| I'm not going to talk about the availability and quality of the
| Wayland API, this was covered in other posts.
|
| Here is what the decision looks like from the POV of someone
| building a product:
|
| - Zoom is one of the few collaboration products which supports
| Linux with a native client. The native clients offer much better
| performance on every operating system.
|
| - Some of the collaboration products (Zoom being one of them)
| implement 2 different codecs for the video streams and screen
| sharing. This is done to offer better performance, lower
| bandwidth, and better quality. For screen sharing the most
| important requirement is not which API is used, but if the text
| is readable.
|
| - Zoom is a multiplatform product. All other platforms offer API
| for screenshots. Not all platforms have an API that captures the
| screen as a video stream. Using screenshots is the best way to
| cover all platforms.
|
| - Collaboration products have high requirements for screen
| sharing: Capturing the entire desktop, capturing a single
| application, capturing a portion of the screen, excluding its own
| UI, etc. Support for multiple monitors, 4k, 5k support. Most of
| these use cases are not going to be covered by the Wayland API.
|
| - This is a different use case than streaming your screen to
| twitch or youtube. Collaboration products have very low latency (
| < 500ms). The presenter can change and any moment and clients can
| join at any time and they expect the screen-sharing stream to
| start immediately.
|
| - Zoom supports h264 as their main codec. API which provides VP8
| will require contradicting and encoding which will slow down the
| performance.
|
| - Even if the video stream coming directly from the screen didn't
| require transcoding, it is still required to do a post
| processing. For screen sharing (with no video on the screen) it
| is wasteful to generate too many frames.
| pmontra wrote:
| Two questions.
|
| 1. Why not the .md URL for everybody?
|
| 2. Is this really a problem with Zoom or one with Wayland and the
| Linux distros? I mean Fedora switched to Wayland in 2016 and the
| screensharing API was added only in 2018. A rushed deployment?
|
| Then maybe the Wayland team should make a list of the
| applications that must absolutely work with Wayland and support
| their vendors to release a correct implementation, not the
| screenshotting implemented by Zoom. I know time and money are
| finite but replacing X11 is a huge task. I'm still on X11 exactly
| because of problems like this one.
| renox wrote:
| Fedora's credo is to deploy new technologies so they did a lot
| of rushed deployment, no surprise there but I don't see how
| this "excuse" Zoom, 2018 is not so recent anymore..
| throwdbaaway wrote:
| > 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.
|
| 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.
| ddtaylor wrote:
| > 2. Is this really a problem with Zoom or one with Wayland and
| the Linux distros? I mean Fedora switched to Wayland in 2016
| and the screensharing API was added only in 2018. A rushed
| deployment?
|
| I use OBS on Fedora 35 and overall it's been really nice. I use
| the Flatpak version of OBS and it uses Pipewire. When I want to
| screen record an OS-level dialog box pops up asking me which
| screen/window I want to share and the entire time I am
| recording/sharing I have an indicator icon that is orange
| (whereas all other icons are white)
| peakaboo wrote:
| I share my desktop screen in Google Meet using pipewire as
| well, and just like you say, I get a choice which screen or
| window I want to share and that's it.
|
| Wayland is very stable these days.
| suby wrote:
| 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.
| eptcyka wrote:
| The vast majority definitely isn't running Linux with a 3080.
| I've been running Wayland for 5 years on Gnome on AMD and Intel
| GPUs without issues.
| suby wrote:
| 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.
| tapoxi wrote:
| This is just an Nvidia issue, they spent years trying to push
| their own driver model and have only recently come around.
| mixedCase wrote:
| While this doesn't detract from your argument given the
| timelines; if you're on Arch, try again. I believe it was
| yesterday that the one major Qt fix that made Wayland KDE
| usable on Nvidia landed.
|
| Apparently Sway too has worked fine since the release of Nvidia
| drivers with GBM support. I'm on AMD right now so can't
| confirm.
| mijoharas wrote:
| 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)
| phkahler wrote:
| >> 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.
| encryptluks2 wrote:
| They are probably running a distro with an old kernel and
| can't be "bothered" to figure out and fix the actual issue.
| [deleted]
| suby wrote:
| 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.
| phkahler wrote:
| 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?
| my123 wrote:
| > and that Nvidia did not support Wayland
|
| 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.
| Steltek wrote:
| Has anyone tried using an AMD card for desktop/Wayland
| alongside an Nvidia card for ML/CUDA? Especially with Sway?
|
| I use Sway/AMD for desktop but all the photogrammetry
| software out there requires CUDA. It's a bit of a PITA.
| Mehdi2277 wrote:
| 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.
| dathinab wrote:
| > the vast majority of hardware
|
| 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.500EUR+ 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?
| dathinab wrote:
| If anyone cares:
|
| 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.
| pkulak wrote:
| Vast majority? I just searched for "laptop" on BestBuy and
| didn't see a single nvidia GPU in three page scrolls.
| peakaboo wrote:
| I run 300 fps with a nvidia card in counterstrike using wayland
| and gnome, so perhaps it's not the driver that is your problem.
| funcDropShadow wrote:
| 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.
| nine_k wrote:
| 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.
| CoastalCoder wrote:
| 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.
| saltcured wrote:
| 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.
| IceWreck wrote:
| Virtual Background works perfectly for me on Linux. On a
| laptop with nvidia hardware.
|
| (On Fedora 34, xorg)
| bashinator wrote:
| As of _very_ recently, like within the past month, same
| here. They rolled out just a simple blurred background
| slightly earlier. Running latest Pop! OS.
| nine_k wrote:
| Yes, it works for me on NVidia hardware under Linux, too.
|
| What's interesting is that the hardware requirements for
| the virtual background seem to be higher under Linux than
| under Win10.
| Proven wrote:
| cluoma wrote:
| Same audio issues here. Zoom always wants to set my mic level
| to 0 and change the default output source for whatever
| reason.
|
| My last company used Teams which I had a much better
| experience with on Linux (gnome+xorg) than Zoom.
| aidenn0 wrote:
| Teams is terrible on Linux for me, but which thing is
| broken changes from version to version.
|
| 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
| dfawcus wrote:
| 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.
| buzzwordninja wrote:
| Oh, I had that problem.
|
| Settings, Audio, uncheck Automatically adjust microphone
| volume.
| asddubs wrote:
| 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
| smcl wrote:
| 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.
| suby wrote:
| I read it in a much different tone, but maybe that was me
| reading too much into it.
| boudin wrote:
| 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.
| suby wrote:
| Thank you, that's a fair point. I was only considering the
| AMD vs Nvidia marketshare.
| pdimitar wrote:
| > The good news is that Nvidia has finally decided to fix its
| drivers, it's still beta though.
|
| Can you elaborate on that?
| nemetroid wrote:
| This should give a rough idea of the order of events:
|
| 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...
| pdimitar wrote:
| These are very helpful, thanks!
| Arkanosis wrote:
| I assume GP was thinking of Nvidia having started to work
| on the GBM API, available starting with nvidia 495.44: http
| s://www.nvidia.com/Download/driverResults.aspx/181274/en...
| smoldesu wrote:
| 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.
|
| In other words, "fix" is a relative term.
| [deleted]
| mikepavone wrote:
| 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.
| ho_schi wrote:
| 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.
| Georgelemental wrote:
| 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.
| mikepavone wrote:
| 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.
|
| EDIT: Fixed formatting
| burnished wrote:
| 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.
| AshamedCaptain wrote:
| Or they will switch to Windows.
|
| 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?".
| pmontra wrote:
| > Linux+Wayland is the only major desktop environment that
| requires you to use an OS-provided dialog to pick the window
| you want to share
|
| Do you mean that you cannot share the whole desktop? The
| typical coding / debugging session (browser, editor, terminal)
| would be very difficult to do.
| mikepavone wrote:
| 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.
| takluyver wrote:
| > 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.
| Asooka wrote:
| 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".
| RcouF1uZ4gsC wrote:
| I think a better title would be:
|
| How Desktop GNU+Linux sucks for desktop developers: Zoom edition
|
| Windows will happily run GUI apps written 20 years ago. GDI is
| still supported. MFC Apps still run. Likely VB6 apps still run.
|
| Desktop GNU+Linux switches graphics engines, breaks backwards
| compatibility, ships something with performance and driver
| issues, and complains that user software doesn't work.
|
| Frankly this post turns me off towards even thinking about
| developing any type of native Linux app and if I need one, just
| use the browser or Electron.
| Filligree wrote:
| > 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.
| chmod775 wrote:
| 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.
| badsectoracula wrote:
| > 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).
|
| [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/
| matheusmoreira wrote:
| > Windows will happily run GUI apps written 20 years ago.
|
| Don't think this is true anymore. Old software on Windows just
| isn't guaranteed to work anymore. Last time I tried to play an
| old game on newer Windows versions, it didn't even start up
| despite automatic and manual installation of a ton of
| dependencies. I suppose the Raymond Chen stories about heroic
| bug fixing in third party code is a thing of the past.
| badsectoracula wrote:
| You need workarounds but you can make it work. Though you can
| say the same thing for Linux too, it is just that Windows
| coming out of the box with a much richer API (e.g. for GUI
| functionality) makes things easier.
| AnIdiotOnTheNet wrote:
| 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.
| matheusmoreira wrote:
| 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.
| ModernMech wrote:
| 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.
| matheusmoreira wrote:
| I remember there were several games in my Steam library
| that didn't survive any upgrades past 7.
| jchw wrote:
| Most irritatingly, I use v4l2loopback to do screen capture, but i
| need to emulate the gnome screenshot API and lie about what
| environment I'm on to even get the option to use a secondary
| webcam as desktop sharing, even though that's just v4l2 and not
| related to any of this.
| faisal_ksa wrote:
| A game developer [1] once said that Linux "accounted for <0.1% of
| sales but >20% of auto reported crashes and support tickets."
| Unfortunately, this is the reality of Linux. It's very hard to
| support due to its fragmentation. It requires so much effort to
| work in a fast-changing environment that a few users even use. To
| make Linux easier to support, we need to make it as easy to
| develop as Windows, macOS, iOS, and Android. We need a unified
| Linux platform with a friendlier developer experience. Something
| similar to Android (which has Linux kernel inside it).
|
| [1]: https://twitter.com/bgolus/status/1080213166116597760 Also,
| see: https://news.ycombinator.com/item?id=18845205
| homarp wrote:
| And another game developer [1]
|
| > The report quality [from Linux users] is stellar. I mean we
| have all seen bug reports like: "it crashes for me after a few
| hours". Do you know what a developer can do with such a report?
| Feel sorry at best. You can't really fix any bug unless you can
| replicate it, see it with your own eyes, peek inside and
| finally see that it's fixed. And with bug reports from Linux
| players is just something else. You get all the software/os
| versions, all the logs, you get core dumps and you get
| replication steps. Sometimes I got with the player over discord
| and we quickly iterated a few versions with progressive fixes
| to isolate the problem. You just don't get that kind of
| engagement from anyone else.
|
| Notably, of those bug reports, fewer than 1% (only 3 bugs) were
| specific to the Linux version of the game. That is, over 99% of
| the bugs reported by Linux gamers also affected players in
| other platforms. Moreover (quoting from the OP):
|
| [1]
| https://old.reddit.com/r/gamedev/comments/qeqn3b/despite_hav...
| also see https://news.ycombinator.com/item?id=28978086
| homarp wrote:
| and on zoom itself
| https://googleprojectzero.blogspot.com/2022/01/zooming-in-
| on... also see https://news.ycombinator.com/item?id=29982954
| "Zooming in on Zero-click Exploits "
|
| the researcher used the Linux client to do the RE work... so
| I guess it's not just for 'bug' but also for free security
| audit! (2 CVE were reported)
| faisal_ksa wrote:
| 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.
| acomjean wrote:
| 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.
| Fabricio20 wrote:
| I believe this is not entirely Zoom's fault, I've heard a few
| horror stories with Wayland and screensharing over the last few
| years. Particularly when I once tried using OBS Studio and it
| just didn't work on Wayland. I also remember screenshare from
| things like Google Meet or Discord only being able to share other
| chromium tabs and not able to share the desktop or any specific
| applications.
|
| This whole story sounds to me like some engineer at Zoom was
| tasked with fixing "linux" back in 2020 and after having several
| issues similar to what I described (possibly unable to capture
| other applications?) they decided that quickly screenshotting the
| screen was a good enough fix. Sadly linux still represents a
| minority of users so this issue was probably not prioritized as
| necessary.
| jatone wrote:
| its entirely zoom's fault. the apis they should be using have
| been well known and in use for years before they used the
| improper APIs.
|
| chrome's (and by extension every electron app) issues stem from
| the fact it had not updated to use the screencasting APIs.
| afaik they've been updated.
|
| abusing APIs isn't the right way to go here. and zoom is
| entirely at fault for it. they should have used the correct
| (and known) apis and worked with upstreams to get the support
| in place. then they could have properly pointed to upstream and
| said 'it won't work until these issues are fixed' and provided
| resources to fix them.
|
| as a result now they are in a shit position of having a
| completely broken app when the APIs in question do work. I know
| because I've built a screencasting program on top of them to
| cast my desktop to chromecast.
| shadowgovt wrote:
| 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.
| computerfriend wrote:
| > 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.
|
| https://en.wikipedia.org/wiki/Zoom_Video_Communications#Wor
| k...
| shadowgovt wrote:
| 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.
| pie_flavor wrote:
| 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.
| [deleted]
| CameronNemo wrote:
| Even Chrome/Chromium, the web browser with the most developer
| attention period, has not enabled the pipewire screen sharing
| support by default.
| tuetuopay wrote:
| 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.
| fanatic2pope wrote:
| OBS works fine for me on Wayland through pipewire.
| phkahler wrote:
| 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.
| throwdbaaway wrote:
| On distro with rolling release, I would say pipewire has
| been working fine since at least January 2021.
| Fabricio20 wrote:
| 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.
| rmurri wrote:
| This explained pipewire pretty well to me:
| https://www.youtube.com/watch?v=HxEXMHcwtlI
|
| The short answer is that pipewire reimplements pulseaudio
| and jack, keeping compatability with both at the same time.
| rjzzleep wrote:
| 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.
| solarkraft wrote:
| 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.
| smoldesu wrote:
| 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.
| CameronNemo wrote:
| 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.
| solarkraft wrote:
| To be fair: It's not only screensharing, it's also
| screenshots and desktop overlays (important for shells
| and such).
| __s wrote:
| > permission-less screen snooing.
|
| snooping
| thanatos519 wrote:
| Microsoft Teams: Hold my beer.
| aidenn0 wrote:
| 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.
| solarkraft wrote:
| Big news, guys: Zoom sucks!
|
| Not only do you not have to feel bad about having Zoom on your
| computer, using it in the browser also enables screen sharing
| through it (the web app sucks, but it's not like the desktop one
| doesn't).
| dathinab wrote:
| I'm not surprised, I mean they didn't even manage to have proper
| browser support.
|
| Like last times I had to do interviews from Teams, Slack over
| Google Meet to (best experience) Jitsi everything worked more or
| less on chrome, Meet worked also on Firefox, Jitsi flawless on
| Firfox.
|
| And Zoom?
|
| Randomly decided to not deliver audio, at all. No way to fix it,
| no reconfiguration of inputs, while others did work at the same
| time, so probably not a browser bug either.
| teilo wrote:
| How not to code an HTML page by hand.
| kxra wrote:
| 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
| 988747 wrote:
| Why won't trimmed URL simply redirect to a proper one? Or
| throw 404 even? This seems like a webserver misconfiguration
| of sorts, kind of like being able to access raw PHP pages,
| instead of rendered ones.
| SahAssar wrote:
| I'm guessing write.as is supposed to support multiple
| languages, and only renders the markdown if you have .md as
| an extension.
| wnoise wrote:
| Which is the exact opposite of what I expect and want --
| the bare filename should render, and the .md extension
| should get the markdown source.
| kxra wrote:
| Agreed. Write.as is open source, you can file a ticket
| against WriteFreely on github
| Operyl wrote:
| Thank god, I was thinking it was some stylistic choice to
| have to read all those links inline in unrendered markdown.
| exciteabletom wrote:
| <p>How <b>not</b> to code an <a
| href="https://en.wikipedia.org/wiki/HTML">HTML</a> page by
| hand.</p>
| JonathonW wrote:
| In next week's episode, how not to write your URL-detection
| regex.
| sodality2 wrote:
| You can't parse [X]HTML with regex:
| https://stackoverflow.com/a/1732454
| thrower123 wrote:
| How terrible is the Windows version of Zoom running on
| Wine/Proton?
| denton-scratch wrote:
| > In 2016, Fedora switched to Wayland entirely, and has since
| been joined by Ubuntu, RHEL, Debian, and others.
|
| Debian, for one, has _not_ switched to Wayland entirely. I didn
| 't read on; counterfactuals tend to have that effect on me.
| asveikau wrote:
| This person wants to replace the window system and is calling
| that a Zoom issue. And says they're working on it.
|
| I fail to see the problem.
|
| Wayland is not a drop-in replacement and creates work to get to
| parity. Nothing will explode if they use Xorg. The problems with
| Xorg are exaggerated. That they find Xorg completely unacceptable
| due to theoretical security issues (nobody is really writing and
| deploying code that targets xorg's issues) shows where their head
| is.
| chaorace wrote:
| I guess the core problem is the false advertising. Zoom
| "supports" Wayland-only distros... with the fine print that
| they only support outdated builds from before the switch to
| Wayland.
|
| Aside from that, my only complaint is that Zoom is unavoidable
| and thus the lowest common denominator. If Zoom doesn't work
| with your window system, you're forced to give up and change...
| even if it's the only piece of software in your entire system
| that isn't up to the job. Being forced to jump through hoops
| like that when you're using a common and modern system
| configuration is a sign of a poorly supported product and
| something users should rightfully complain about.
| yjftsjthsd-h wrote:
| > I guess the core problem is the false advertising. Zoom
| "supports" Wayland-only distros... with the fine print that
| they only support outdated builds from before the switch to
| Wayland.
|
| They support the _distro_ just fine. They might not support
| one of its graphical layers, but you can run Zoom on Xorg on
| the same distro just fine.
| nemetroid wrote:
| You can _run_ it, but not with reasonable screen sharing
| support, which arguably is a part of "supporting the
| distro".
| yjftsjthsd-h wrote:
| 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.
| nemetroid wrote:
| 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?
| yjftsjthsd-h wrote:
| 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?
| ihattendorf wrote:
| 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.
| YEwSdObPQT wrote:
| cupcake-unicorn wrote:
| The mass adoption of Zoom in areas where it really shouldn't have
| been used and the lack of support to users has been shocking to
| me. It really felt like this just happened to be the company that
| took off because of the pandemic but a scrappy startup could have
| done this 1000x better.
| not2b wrote:
| Zoom has better Linux support than almost any proprietary desktop
| application of similar complexity. For pretty much anything else
| only a web client is provided. My non-technical wife has no
| trouble using the Ubuntu version, flipping between using the
| laptop sound and earbuds. True, she doesn't need desktop sharing
| and there are issues with that.
|
| The fact that there's any support at all for desktop Linux
| (beyond "it works in the browser") is pretty amazing, and it's
| probably better not to crap all over the people who have done
| 80-90% of the job for the missing 10-20%.
| linsomniac wrote:
| BlueJeans has a native Linux app that for the last 6 weeks,
| every time I've started it, has told me that there is an update
| available and asking if I want to upgrade it. When I go to
| download it, I find I have the latest Linux version available.
|
| Nothing like telling your users every time they start your app
| that you don't prioritize their OS.
| binwiederhier wrote:
| I agree with this wholeheartedly. Zoom on Ubuntu works
| perfectly. It supports switching audio and video sources,
| annotating, screen sharing with previews of screens, window
| sharing, even break out rooms and the chat. Some things feel a
| bit unpolished but it pretty much just works.
|
| The only thing I ever had trouble with are custom backgrounds,
| and they are a little silly anyway.
| listic wrote:
| What's wrong with custom backgrounds? I tried them and they
| worked amazingly well for me.
| binwiederhier wrote:
| It sort of works, but the background cuts in my face and
| arms and all that all the time. It may just be my actual
| background isn't optimized. Overall I'm happy with zoom.
| seltzered_ wrote:
| Thanks for sharing this.
|
| I'm using a relatively simple setup (Ubuntu 21.10 on wayland,
| single hiDPI tablet display - no secondary gpu, no second
| monitor) and was frustrated to see Zoom screensharing only show
| the upper right quarter of the screen (presumably due to not
| accounting for hidpi) recently.
|
| This said, it generally works fine, and am thankful Zoom at least
| exists on Linux.
|
| --
|
| "If you're stuck using Zoom [...] we can work to pry our
| organizations and loved ones away from the hapless engineering at
| Zoom."
|
| I disagree with this sentiment. Zoom has been a huge enabler with
| it's setup to minimize video/audio latency compared to the other
| solutions I've seen when faciliating a global audience that
| doesn't necessarily have fast internet access.
| throwdbaaway wrote:
| Zoom product/engineering is indeed hapless when compared to
| Google Meet product/engineering.
| encryptluks2 wrote:
| They don't care about you, stop pretending like they will. You
| chalk this up as incompetence but it is more than that as shown
| by their actions.
___________________________________________________________________
(page generated 2022-01-21 23:01 UTC)