1. 28
  1.  

  2. 28

    This should hardly be surprising but a prominent Intel open-source developer has conceded that the X.Org Server is pretty much “abandonware” with Wayland being the future.

    No. Wayland is nowhere near being ready at all, nor is a lot of software ready to be used with it.

    And I’m not speaking “oooh no proprietary drivers”, it’s fundamentally not ready for every day use unless it can manage to fulfill your specific needs.

    They’ll have to pry X away from my cold dead body.

    1. 18

      Can you give examples?

      1. 2

        Pidgin is the main one I can think of (and anything still using Gtk 2?). A number of Qt5 apps (qutebrowser, qcachegrind, freecad some to mind) will (or at least used to as of a couple months ago) crash after some time on Wayland compositors, so I end up running them with Xwayland. There was some Qt bug about it but I’m not able to find it at the moment.

        That said, I try not to use Xwayland as much as possible, prefering to use native Wayland apps.

      2. 9

        Hard disagree. I’ve been running wayland as a daily driver ~2 years and aside from some random Firefox bugs, have had no problems.

        1. 17

          T470, Fedora 31. Ryzen 7, R9 380x, Fedora 32.

          • Blender crashes.
          • GNOME crashes.
          • Firefox issues.

          I want to use Wayland. I really do. I test it on every Fedora release. I’ve had to switch back every single time since its introduction.

          1. 11

            As with every other piece of software, it’s easy to get it to run on your laptop, it’s getting it to run on everyone else’s laptop that’s hard :).

            I, too, have a machine on which it’s running great. I bought it specifically in order to test things on Wayland (specifically, on Gnome’s Wayland compositor because “it’s just a protocol” etc. etc, but that’s another story). It’s the only machine I have on which it works (for any decent definition of “works”).

            1. 10

              I managed to completely freeze/deadlock my entire system with 10 minutes of Wayland experimentation today, which doesn’t exactly inspire confidence.

              At any rate, by far the biggest reason I’m not really look forward to switching is because I don’t want to find and configure all the apps and such for Wayland. For example I’ve been running the same dwm binary for over two years. I like that it never changes and Just Works™. I’d have to re-do all the setup and such. I can keep running most other X apps with the compat layer I suppose, but at that point you might as well just be running X if you’re running mostly X apps under Wayland. I suppose I’ll be sufficiently bored to spend time on it at some point … eventually.

              The entire thing reminds me of IPv6: sure, it’s better I guess; but the costs of switching is expensive for many. I always wondered why they never made X protocol 12 instead of making something entirely new, which would certainly have an easier migration path.

            2. 4

              I agree. I can’t use Wayland until it supports my usecases, including Window Maker and ssh -X just to begin with. Other UIs aren’t a replacement for Window Maker and RDP isn’t a replacement for single-window remoting, just to head off anyone trying to be “helpful” in the replies; really, Wayland won’t be done unless and until it can run any X window manager at least as well as X.Org does without needing to port that window manager. That’s the kind of compatibility low-level software needs, and if Wayland is as low-level as has been advertised, it should be possible, if not easy, to make it happen.

              1. 3

                No kidding. I’ll happily run a 2018 build of X until I die unless something better appears

              2. 14

                We need more expressive languages in order to maintain a modern display-server stack. I think that we are reaching the limits of what can be maintained. As I have argued before, one of the main scaling limitations in the low-level graphics stack is the fact that so much code is written as open-coded C, and C has no expressive tools aside from C preprocessor macros for refactoring that complexity.

                That said, though, I don’t think that anybody is abandoning the Xorg repositories. The wider FreeDesktop ecosystem now has a GitLab instance, and code is still being merged. It seems that the article’s concerns are largely being driven by corporate engineers, specifically from Intel and Red Hat IBM, who fret that they cannot afford to continue contributing at their historical pace. While I’m not fond of the corporate point of view, I think that nobody can afford to continue contributing at the current level of complexity, and the corporations are the last to find out because they are the last to find their time and money being ill-spent.

                If there’s something that it’s time to admit, something that we need to put our foot down on as a collective community, then it’s time to admit that we cannot support closed-source GPU drivers in the ecosystem. It’s time to stop letting nVidia, Intel, etc. have so many blobs. It is not an accident that Nouveau is smaller than nVidia’s proprietary driver; with a deeper and more open understanding of the hardware comes a reduction in complexity. Because we tolerated them for so long, they are starting to desire firmware signing. We were complacent here, and we will continue to pay the price.

                The punchline is that Xorg folks are aware of all of this. Aside from Wayland, there’s a long-standing wishlist for X12 and what the X protocol could include in the future, and the XCB project refactored large amounts of hand-written C into XML-driven generic tables which can be compiled to many different languages.

                I think that the main thrust of Wayland which we should keep in mind is not necessarily to remove the X11 network-transparent API, but to remove the need for the high-level networking server to also be the low-level hardware driver. This is another pattern which has seen improvement in the past couple decades, but we are arriving at a bit of a crossroads as Linux device support becomes increasingly conditionalized on whether Google or Apple think that we should have access to any particular part of a device.

                The next step forward may not happen until we have a more common usage of rump techniques to not just build unikernels, but to reuse the same GPU driver modules in both the “kernel” and “userspace” portions of whatever division of responsibilities we choose. Ironically, this is the pattern which Xorg originally moved away from, decades ago. In a real way, Xorg cannot be better than the common intersection of Linux and the BSDs, aside from some localized specific GPU support. (Don’t undercount that; the entire Android ecosystem operates on localized specific GPU support on Linux.)

                1. 11

                  Just dropping here some IRC discussions.

                  We need more expressive languages in order to maintain a modern display-server stack.

                  00:25 <airlied> the X server sucks to maintain not because it's 20 year old code base in C, it's because it has 20 years of concepts that only 5 people understand
                  

                  That said, though, I don’t think that anybody is abandoning the Xorg repositories.

                  00:28 <airlied> well the article is that The X.org server is abandonware
                  00:28 <airlied> and that is pretty much true
                  00:28 <airlied> the X.org server isn't the graphics stack or drivers
                  00:29 <airlied> I think even at it's peak the X.org server never got more than maybe 10 contributors
                  00:30 <airlied> and I believe the peak of the X.org server development was ripping stuff out of it
                  
                  00:35 <airlied> it's abandonware in that PRs get merged but have 0 paths to a user
                  00:35 <airlied> unless they have a reason to get fixed in the stable branch
                  00:36 <airlied> it'll just end up distros piling patches onto 1.20 for ever until someone steps up and fills the void
                  00:37 <airlied> like maybe someone will salvage a 1.21 release and it can then admit to new PRs that it's pointless
                  
                  1. 14

                    Hi, please don’t exclude the context. In particular, please don’t exclude my side of the discussion. I am not interested in arguing against myself nor against people who I worked with harmoniously in a prior career. Here is a complete log of the IRC discussion from #xorg-devel on Freenode:

                    16:20 <simpson> I saw the recent Phoronix "abandonware" story and wrote out some thoughts. I'm a little embarrassed that my position hasn't shifted much in a decade. https://lobste.rs/s/vqv6nu/it_s_time_admit_it_x_org_server_is#c_dxumkl
                    16:21 <daniels> I'm all for better languages, e.g. Rust in Mesa, but the last thing I'd ever want to try to do is rewrite the X server
                    16:23 <simpson> Yes. What I have aimed to do instead (and failed at, FWIW) is to explore design of languages that would make rewriting the X server a straightforward, easy, necessary refactoring task. I think that the Genode folks have a reasonable angle for how to do this, but again it is a little inconvenient to admit that the best angle forward could be more XML and lots of C++.
                    16:24 <airlied> I can't see rewriting the X server helping in any way
                    16:24 <airlied> no matter what language you choose
                    16:25 <airlied> it's just one of those fallacies of grass is greener
                    16:25 <airlied> the X server sucks to maintain not because it's 20 year old code base in C, it's because it has 20 years of concepts that only 5 people understande
                    16:25 <simpson> Yes, that's the other thing. It would be much more comfortable, knowing what we know now, to have a much more robust low-level common GPU interface which can support Xorg and also Wayland and etc. However, now it's 2020 and the community has done just that; I hear regularly of folks living entire lives on top of Wayland alone. And yet the GPU drivers are still hard to maintain, so there's still problems
                    16:25 <simpson> to figure out.
                    16:26 <airlied> gpu driver maintainence seems pretty mature at this point
                    16:26 <airlied> like we are never going to be swimming in resources
                    16:27 <airlied> but the kernel and mesa tick over pretty nicely
                    16:27 <emersion> > the best angle forward could be more XML and lots of C++
                    16:27  * emersion reads lots of complexity
                    16:27 <simpson> airlied: Right, that's the *other* thing: The thesis of the original article is bogus, and maintainers are still here, still working in established patterns, and still producing working software. There might not actually *be* any problems.
                    16:28 <airlied> well the article is that The X.org server is abandonware
                    16:28 <airlied> and that is pretty much true
                    16:28 <airlied> the X.org server isn't the graphics stack or drivers
                    16:29 <airlied> I think even at it's peak the X.org server never got more than maybe 10 contributors
                    16:30 <airlied> and I believe the peak of the X.org server development was ripping stuff out of it
                    16:31 <simpson> Sure. From a downstream perspective, though, that's not at all abandonware, and it's not functionally distinguishable from parts of Xorg (or indeed parts of FreeDesktop!) which are receiving steady releases. The act of integrating a complete Xorg release is sufficient to validate that the software still works, and PRs appear to get merged.
                    16:35 <airlied> it's abandonware in that PRs get merged but have 0 paths to a user
                    16:35 <airlied> unless they have a reason to get fixed in the stable branch
                    16:36 <airlied> it'll just end up distros piling patches onto 1.20 for ever until someone steps up and fills the void
                    16:37 <airlied> like maybe someone will salvage a 1.21 release and it can then admit to new PRs that it's pointless
                    16:37 <simpson> Understandable. In nixpkgs, at least, we can do that indefinitely; it is as much effort to bump from "1.20" to "1.21" as it is to include a patch. But that isn't something that will help all distros.
                    

                    You seem reluctant to make a point, but I’ll try to guess. Yes, I am not happy that XML and C++, as used by Genode, form the most promising path forward for managing complexity. It is a little soothing to know that OCaml is also viable, thanks to the MirageOS project. However, in any case, we’re still trapped in a prison of text, writing one-dimensional syntax to express multi-dimensional structures. There aren’t any available programming languages which properly manage this complexity, and part of my frustration is that I’ve spent a few years exploring one of these paths only to find deep disappointment.

                    1. 3

                      Again… We don’t need new and/or complex languages to solve problems. This isn’t the reason why xserver isn’t being maintained. A complex language will only make the maintainers job harder IMHO.

                      I don’t see the problem of expressivity you describe.

                      1. 2

                        My main reading recommendation on this topic is Shutt’s Abstractive Power.

                        I will gladly concede that we may have different ideas of what is readable and maintainable. I have trouble reading more than one module at a time, or examining more than one screenful of code at once. The typical GPU datasheet has hundreds of pages, and the typical GPU driver has hundreds of KLoC spread across dozens of modules. Just like how the GPU datasheet could be in a structured format but is usually delivered as a machine-unreadable PDF, the GPU driver could be in a structured specification but is usually delivered as piles of C spaghetti.

                      2. 2

                        we’re still trapped in a prison of text, writing one-dimensional syntax to express multi-dimensional structures. There aren’t any available programming languages which properly manage this complexity, and part of my frustration is that I’ve spent a few years exploring one of these paths only to find deep disappointment.

                        Developments are slow, but not nonexistent. There is fructure, a structured editor for scheme; and I saw another web-based one for an ML dialect. Another project along similar lines is semgrep.

                        Neither of those projects is an ideal—not even close—but it’s a start.

                      3. 6

                        the X server sucks to maintain not because it’s 20 year old code base in C, it’s because it has 20 years of concepts that only 5 people understand

                        Totally agree, but the 20 year old code base in C certainly doesn’t help.

                        1. 3

                          Not related to the story about X.org, but is there a chance we could get these one-line <code> sections to wrap? I can’t read the first excerpt, because when I try to scroll it left, it gets obscured by the scrollbar, that just pops up.

                          1. 3

                            They should’ve been using quotations instead, no?

                            1. 2

                              That tripped on the angle brackets unfortunately.

                              1. 1

                                You should be able to escape those, though; no?

                        2. 3

                          the XCB project refactored large amounts of hand-written C into XML-driven generic tables which can be compiled to many different languages.

                          While the XML tables are certainly better than hand-written C, they’re still very complex, underdocumented, and full of concepts that only 5 people understand. I started a project trying to understand them and compile them to higher-level languages (OCaml in particular, but it infers enough information that making a code generator for any other language shouldn’t be too hard) and while I’m only working on it on and off in my spare time and I burned out on it a few times, it’s been about two years since I started and there’s still stuff I don’t understand. That said, I’m doing my best to document my struggles so I hope I’ll be able to contribute some documentation back to it.

                          1. 1

                            May be too superficial on my side, but could D [1] be used to compile Xorg (may be with awk magic to massage includes) ?

                            [1] https://dlang.org/blog/the-d-and-c-series/

                            1. 5

                              Why would that help?

                          2. 8

                            The head of Red Hat’s desktop team (Christian F.K. Schaller) posted a comment in June 2019 warning that this was likely to happen soon:

                            Once we are done with this we expect X.org to go into hard maintenance mode fairly quickly. The reality is that X.org is basically maintained by us and thus once we stop paying attention to it there is unlikely to be any major new releases coming out and there might even be some bitrot setting in over time. We will keep an eye on it as we will want to ensure X.org stays supportable until the end of the RHEL8 lifecycle at a minimum, but let this be a friendly notice for everyone who rely the work we do maintaining the Linux graphics stack, get onto Wayland, that is where the future is.

                            Though there’s a bit of contradiction there, because RHEL8 is officially supported through 2029. I guess they will just do absolute minimum support (e.g. patching CVEs)?

                            1. 5

                              The productive thing to do here is to put up a pool funding to show that some ~90% of foss desktop prefer Xorg over WL. Maintainers will come out of the woodworks. I know enough of the DDX/DIX/Xxxx internals to dislike the codebase, though would do the job at a fair price while sneering. Much much much better still, pool the money (+hugs) for Keith Packard, Jason Ekstrand, Jasper st. Pierre, … to do it and it’s done, but that’s what is lacking.

                              1. 9

                                I think the truth is that most people doesn’t care. They will use whatever ships with their distro/DE.

                                I have tried using GNOME on wayland, there is basically no difference in the experience. I can safely say most GNOME users won’t care if their systems run on X or Wayland. It’s probably similar on the KDE side as well.

                                1. 2

                                  some ~90% of foss desktop prefer Xorg over WL

                                  I wouldn’t bet on that. For example, here are some stats about the i3/Sway split on Arch Linux:

                                  https://pkgstats.archlinux.de/packages/i3-wm https://pkgstats.archlinux.de/packages/sway

                                  And nothing says that the existing i3 users prefer X11, maybe they stay on X11 because they don’t care. The reverse isn’t true.

                                  Of course, this is just stats about a specific distribution, and probably not 100% accurate, so needs to be taken with a grain of salt. But it does give an idea about the amount of users who prefer Wayland.

                                  EDIT: not trying to argue that it’s a competition and/or that i3 should be dropped.

                                  1. 3

                                    If we’re looking at Arch’ stats, why not just look at xorg-xserver? https://pkgstats.archlinux.de/packages/xorg-server

                                    In fact, it’s possible to compare stats, too: https://pkgstats.archlinux.de/compare/packages#packages=wayland,xorg-server . Note that the wayland package is just the protocol definitions, so it’s pulled by a lot of metapackages whether you use a Wayland compositor or not. Looking at the graph, it looks like somewhere between 5% and 10% of Arch users have Wayland installed and don’t have xorg-xserver installed, suggesting that they definitely use a Wayland compositor as their “daily driver” and nothing else.

                                    Maybe the other 90-95% don’t prefer X11 over Wayland, but it’s a pretty sure bet that most of them can’t do without it, either.

                                    1. 3

                                      This doesn’t mean everybody in the rest of the users use X11 as their daily driver. xorg-server is for instance pulled as a dependency of gdm. I imagine people who migrated from X11 to Wayland still have xorg-server installed, too.

                                      1. 3

                                        No, of course not, the only thing that made it interesting is the baseline difference between the two (although even the 5-10% figure is of doubtful use. Having tried to build a Wayland-only Arch system I’m pretty sure most of those machines are headless machines where the wayland package got pulled in as a build dependency). Similarly, not everyone who has sway installed uses it, either.

                                        Unfortunately, Arch’s “enable everything everywhere” approach to packaging doesn’t make it too easy to disentangle this. I will point out, though, that their public stats are heavily skewed towards the Arch userbase: they also show Firefox’ popularity at 77% and Lua being significantly more popular than Node.js ;).

                                  2. 1

                                    I think that’s the main issue in any project. The barrier of entry, lack of motivation, and missing documentation. If people spark interest in the project and start writting articles and document the inner workings, then it would be much easier to “upgrade” the software in the X11 stack.

                                  3. 7

                                    Related: “The Real Story Behind Wayland and X” by Daniel Stone (a longtime X developer)

                                    https://www.youtube.com/watch?v=RIctzAQOe44

                                    1. 8

                                      “related” why? it’s a bad presentation and mostly shits on other people’s work rather than saying WHY it is advantageous (it is not). Ask daniels if he’s proud of it, I’ll doubt he says yes. 35 minutes of ranking down on X then waves hands wayland is a solution for ten minutes before fin. – It’s emphatically not – but there is no technical substance to it whatsoever.

                                      1. 5

                                        The presentation explains why X11 is complicated to maintain, why X11’s issues are complicated to fix, and how Wayland fixes them. The presentation gives clear examples.

                                        But the real reason why I like it is that it contains a few asides directed towards “the peanut gallery” – ie. people criticizing Wayland without really knowing what’s up. I read too many “critiques” of Wayland which don’t have any meaningful content (e.g. “Wayland sucks”, “it’s so bad”, “it doesn’t work”). If Wayland exists, it’s because the X11 developers couldn’t stand working around X11’s issues anymore.

                                        1. 1

                                          No it doesn’t. I have watched it. Repeatedly. Referencing it doesn’t help Wayland’s case - at all. He throws air punches at everything yet nothing and no-one gets bruised. Nobody that is confused about this whole thing will get anything of a reasonable perspective from it. Furthermore, it is from 2013 - a time where KMS/GBM was about as reliable as trying to walk on stilts on ice in under pouring rain. A number of refactors haven’t happened; meson refactor, xcb-protocol-packaging problem merged etc. If you remove the constraint that ‘there are other X implementations than Xorg and the protocol should be respected’ the cleanup would even be fun. I’d probably pay 5-6 figures from my own wallet just to see how Keith (and the other X11 developers that didn’t move to Wayland - they outnumber you) would do it when it is “minimal backwards compatibility”.

                                          Ironically enough - if they (krh, daniels) had listened to the lessons inside some of the parts that were gleefully removed some, far from all, of the basic flaws that makes wayland, at most, a substitute of the mistakes of the 80ies with the grander mistakes of the 90ies; Density-aware rendering, linear-alpha for composition, atypical colour spaces, variable refresh - those sort of things were accounted for, it was there in the code. I have read it. All of it. Have you?

                                          It wouldn’t save the absolute trash fire the security situation you are in, but I doubt anyone involved have even sneered at CTFs enough to spell adversarial thinking. It wouldn’t save how the input model managed to get worse (and even be a vulnerability for ~6 years). I think Wayland is uniquely ‘special’ in thinking the client should interpret the keyboard state machine with all the negative consequences that entails. It wouldn’t solve how basic queue theory 101 fails and clients randomly disconnect if they fail to flush in an expedient manner, or how the dependency tree killed the strongest exploit mitigations in order to implement this “COM for dummies”. I have about a hundred more, having actually done the homework. Should the pandemic end and I feel in a disseminating mode (low risk), it might be time for the security con circuits. Given the 40+ exploitable UAFs you have had in wlroots to date, have you done anything to prevent or detect the next ones? How is the testing stuation?

                                          When it comes to the peanut-gallery, since you lot have the tendency to ‘correct someone that is wrong on the internet’ rather than go ‘is there something with our dissemination that gives people the wrong idea?’ (and don’t reference drew’s half-assed manpages-marketed-as-book missing what, 2/3rds of it? again, I know the code.).

                                          As with this thread, michael-phoronix has been allowed to drive the narrative for close to a decade, and there is nothing to reference in order to slap the demographic over the face. Being beaten by, in the wise word of GLaDOS “He’s not just a regular moron. He’s the product of the greatest minds of a generation working together with the express purpose of building the dumbest moron who ever lived. And you just put him in charge of the entire facility.”. That is where you should focus the energy or you’ll be drained being misunderstood, actually explain what it is about. You can’t go ‘it is just a protocol’ – overloaded terminology exists: a compositor is not a wl_compositor or a wl_subcompositor. For 5? years the docs themselves said the Wayland Display Server…

                                    2. 4

                                      Do we really want polarising posts like these on lobsters? Seems like a hacker news kind of thing to me, and I don’t think anyone would miss the arguments.

                                      1. 3

                                        I feel like if we restricted the site’s posts to “things unlikely to be contentious between programmers” there would be a quick decline in content…

                                        But in all seriousness, I view things here as more tightly focused and reasoned discussions than HN, not a place where things that are broadly on-topic but controversial are off-limits. That said I think some pushback is good - I wouldn’t want the majority of posts to be so deliberately provocative.

                                        1. 1

                                          Yeah, you make some good points. Thanks

                                        2. 2

                                          I was wondering whether to post it.

                                          I did it because I found it was a good article (even if structured to be controversial) and I wanted to read informed retorts. We have some graybeard unix wizards here on Lobsters, and I thought the discussion would be good.

                                          In any case, as @cepheus mentions, I don’t think that a restriction of controversial articles would be positive for a news site, as long as the controversy is technological and not pure drama or tech politics.

                                        3. 4

                                          The only thing I’m getting out of this article and the discussion is that it doesn’t even matter because Wayland is barely usable but X.Org still works.

                                          Just because software isn’t getting updated often doesn’t mean it’s suddenly unusable.

                                          Or is everyone gonna drop vim because it hasn’t been updated in about a year now?

                                          1. 4

                                            Waiting for my really big nvidia™ card to be not crawl on wayland. The same card that carried my through the witcher 3 on linux is all sorts of wack on wayland WMs, feels not good

                                            1. 13

                                              Probably because NVIDIA is actually not supporting Wayland at all, but instead are attempting to force Wayland compositor developers to bend to their will. See Drew DeVault’s article for a more detailed explanation, but the gist of it is that NVIDIA deliberately implements an API that was disregarded by the Linux graphics community just so they can keep as much of their driver proprietary as possible.

                                              1. 4

                                                just so they can keep as much of their driver proprietary as possible

                                                I suspect it’s more likely they simply don’t want to devote any resources to it. As it stands, the nvidia graphics blob is basically the same as the windows driver with a light shim layer (to my understanding at least) and the graphics API the rest of the driver community settled on would be a fundamental change to how nvidia’s driver functions. Not trying to defend nvidia, but I don’t think their motivation has anything to do with proprietary vs not.

                                                1. 4

                                                  I have the theory that their driver code is so badly architectured, they basically couldn’t implement the API designed by Linux graphics community. So they tried their best to come up with something which doesn’t require refactoring their whole codebase.

                                                  Totally unsubstantiated, but looking at some of the quirks their driver has, I could as well be right.

                                                  1. 3

                                                    What some conveniently forget amongst the religious zealotry is that NVIDIA asked for the very primitive that is in contention quite early on. https://lists.freedesktop.org/archives/dri-devel/2012-October/028857.html

                                                    The licensing situation has been rectified since then, but these are fundamental components that you just don’t change overnight or even over a year. NVIDIA moved on and the stack lost feedback on design flaws from, regardless of what-degree-of-assholes status, the most competent players around. Several years later, asking for a 2-3M investment like this (at the least) with very uncertain payout after the response given and the animosity displayed, what would a developer manager say?

                                                    1. 3

                                                      If Nvidia wants to build proprietary drivers, there are platforms that allow that, but if Nvidia wants drivers that run on Linux, it has to follow the rules.

                                                      asking for a 2-3M investment

                                                      That’s literally pocket change for Nvidia, and even if it wasn’t – having to deal with costs caused by external factors is a normal thing when doing business.

                                                      1. 0

                                                        If wayland wants to run without nvidia, there are some people that will use it, but if wayland wants to actually replace X and be run by all Linux users, it has to follow the rules (and reach some kind of compromise).

                                                  2. 6

                                                    Same witcher story, except on AMD and thus no wayland issues.

                                                    I blame NVIDIA, and only NVIDIA, for NVIDIA cards not working well on Wayland.

                                                    Other GPU vendors properly provide documentation and open drivers.

                                                    1. 1

                                                      It’s nice they provide open drivers, but I tried editing 4k video on my open AMD setup and it was a disaster.

                                                      Everyone I talked to said to use the Nvidia blob, because it’s the only one that gives proper acceleration.

                                                      I don’t know how well the closed AMD drivers would fare, and I don’t have time to mess about right now. Allegedly it’s always inferior to Nvidia.

                                                      Due to ideological masochism, lack of money and not having an extra pcie that could use a modern card as a slave, I will continue eating the plate of shit that is open-source.

                                                      Something else is needed beyond documentation and open drivers, like people to write the code that makes things go brrrrrrr.

                                                      Or add something to OpenShot so I can pay Amazon for the render.

                                                      1. 1

                                                        Everyone I talked to said to use the Nvidia blob, because it’s the only one that gives proper acceleration.

                                                        The NVIDIA marketing machine is strong.

                                                        1. 1

                                                          Maybe I need to clarify.

                                                          The hoops you’d expect to jump through for accelerated video editing on OSS AMD did not do it.

                                                          Nvidia’s blobs may be inferior to AMD’s, but I’m told by peers more experienced they are not.

                                                          Messing around with drivers takes time, messing around with hardware takes money. A hobby experiment (for me now) is worth neither.

                                                          This has nothing to do with marketing, but with “did it get the job done?”

                                                          And here I am, still voluntarily supporting AMD for their openness for the foreseeable future, but let’s not kid ourselves into conflating openness with functionality or achievements in implementation, ok?

                                                          1. 0

                                                            but let’s not kid ourselves into conflating openness with functionality or achievements in implementation, ok?

                                                            I was once an NVIDIA user. Never again.

                                                            NVIDIA is suffering. AMD is bliss.

                                                            1. 2

                                                              That depends on the GPU in question. I am very happy with my GTX 960, yet I have an R9 290 sitting on a shelf because it is unusable on linux. However lame its thermals might be, it functions without issue on windows. I wrote a blog post about the experience.

                                                              1. 2

                                                                R9 290 was a “hot rod” card, and cards often didn’t have adequate cooling. As far as I can tell, you got one of the bad cards.

                                                                285 (later 380/380x, codename “tonga”, actually a newer architecture than 290) was the good one of that generation. It was succeeded by Polaris.

                                                                I own a 380x and a Vega64, use them mainly with Linux, and never had any issues with them. They run cold, too. HD4850 preceeded them. I do not use anymore, but it is still functional.

                                                                Prior to that, I was an NVIDIA user. Stability issues aplenty on Linux, and all the cards actually ended up dead (hardware), despite the fact I never overclocked them.

                                                                Never again. My experience with Mesa / the open graphics stack has been nothing but bliss.

                                                                1. 4

                                                                  Oh, I know the card is bad. But if the windows driver can properly manage the power and fan speed and the linux driver can’t, the blame is on the driver.

                                                                  It’s exactly this kind of situation, where the hardware can overheat easily, that the power management capabilities are put to test. When everything goes well on the hardware side, it doesn’t really matter how bad of a job the driver is doing.

                                                                  1. 1

                                                                    Newer generations have better power management.

                                                                    The old ones got better power management only recently, because they focused on the newer cards first.

                                                                    At the time, open support for GCN was much more early stages, and they focused on tonga (3rd gen) then polaris (4th gen), whereas 290 were 1st gen.

                                                                    It is only recently that we got to the point where cards are supported on release day.

                                                  3. 3

                                                    My big detractors from Wayland are:

                                                    • i3 (I know about sway, but see below)
                                                    • nVidia (at least on one of my machines)
                                                    • Applications such as OBS or Firefox

                                                    Each time I try to switch from i3 to sway its just too much work to get my current i3 config and workflow functioning. I have real work to get done, and until either i3 supports Wayland, or sway actually becomes i3 compatible I’ll be stuck on X.

                                                    nVidia should be self explanatory, but at least on that one machine I’m stuck with X.

                                                    OBS may work under Wayland now, I haven’t tried lately but before it didn’t. Firefox I hear is OK now with some workarounds, but again I have real work to get done and don’t really like having to follow the latest hacks just to get something working that should work by default. Even if both of these applications work flawlessly now, the i3 and nvidia issues are deal breakers for me.

                                                    1. 3

                                                      As of this morning, I’m testing out sway on HardenedBSD. It’s working… fine-ish… Sway itself is working fine, but there’s little to no real useful documentation on how to properly migrate from i3wm to sway. I created my own little status bar script for i3wm (shows my tmux sessions and shows which VMs are running) and that doesn’t work with sway for some odd reason.

                                                      Sway seems to be somewhat in its infancy still. I’ll give it a few days, but I’m already leaning towards switching back to i3wm.

                                                      1. 2

                                                        It is official; Netcraft now confirms: X11 is dying.