12 ms·

X.org on NetBSD – The State of Things

166 points by dagenix 2y ago

xvilka 2y ago
Would be interesting to know also the current status of Wayland development in NetBSD, since the last blog post about it was quite a while ago.
- deleted 2y ago
  [deleted]
- shrubble 2y ago
  I came to the conclusion a while back that Wayland just doesn't matter very much. As long as Chromium and Firefox plus the GUI mode of Emacs works under X11, that is all 90% of users need/use.
  - hapless 2y ago
    I doubt it I really, truly suspect Wayland is the future We have had like one hundred X11 replacements between 1990 and now, and at least half a dozen have caught on with the open source community What makes Wayland different is that it has attracted multiple vendors supporting it. Most notably IBM/Redhat, Intel, AMD, and, to a lesser extent, nVidia. I am posting this message from an X11 environment, because I need X11 for a lot of things, home and work both, but, I can at least imagine a world where Wayland is the new default. That is not something I could say about the last hundred attempts to replace X11. Edit: Again, this is just a suspicion. A notion. I neither hope for Wayland's success nor failure. I just keep my finger to the wind.
    - Kwpolska 2y ago
      Wayland might be the future (though I'm personally a bit skeptical). It is already the default on many distros. At the same time, X11 is very unlikely to just stop working or disappear, since there's really no good reason to kill it.
      - hapless 2y ago
        My skepticism should be quite obvious: I am still posting through an X11 system. But, Wayland is far and away the best and most serious attempt to replace X, ever, in thirty years and more. If there is gonna be an X11 replacement, ever, Wayland is the most credible attempt in decades
        vundercind 2y ago
        Agreed that it’s made the best show of attempting, but Wayland’s only got about nine years before it’s as old as x11 (the protocol) was when the Wayland showed up. If it’s gonna mostly displace x11… man, it’s sure taking its time. It’s older than xfree86 was when the xorg fork occurred.
        The_Colonel 2y ago
        > If it’s gonna mostly displace x11… man, it’s sure taking its time. Yes, and I'm fine waiting 5, 10, or 20 years. It's natural that such major shifts take a long time in an already mature ecosystem.
        raffraffraff 2y ago
        I'm also using X11, even though I've attempted to switch to Warplanes twice and had to switch back due to screen sharing and remote desktop being trash or just breaking after some update or other (most recently, browser). It's a work machine and I simply can't waste an hour fucking around with it. Aside from those issues which are deal-breakers in work, there's a bunch of minor annoyances I won't go into, thrust not deal brakes but they're "there". With X11 everything I need just works. I'm on a bleeding edge distro (OpenSUSE Tumbleweed) so I'll probably try it out on a weekend every few months to see if it's better. But in fairness I did that before, made the switch and then lost screen sharing after some random update...
        petepete 2y ago
        Screen sharing was the final hurdle for me. I switched to running Slack in a Chrome tab and it works better than it ever did on X11 for me. I've used it on both my work computers for a few years now and it's been totally solid.
    - guappa 2y ago
      wayland's main purpose is to isolate ~~malware~~ proprietary software running in a container, which Xorg doesn't allow (unless of course you run nested servers). It wouldn't be too bad of a goal if it had feature parity, which it still doesn't have.
      - welterde 2y ago
        X11 does have various ways to restrict access (one of which ssh does use for instance) and some more advanced security extensions. But as far as I can tell there has never been that much motivation to widely deploy any of it.
        nolist_policy 2y ago
        Eh even if you secure the X11 API itself, the Xorg server still is a 33 year old (!) c codebase.
        guappa 2y ago
        Linux is 33 years old as well. Let's stop using it to be secure?
        jdiez17 2y ago
        Linux is not as secure as most tech people would assume at first glance. The monolithic kernel with all device drivers in ring0 is, let's just say, not the best approach if one were writing a new OS from scratch. It is mostly "secure" due to it being used in practically every server and billions of devices, so there is an active maintainer community around it. Xorg has none of that.
        welterde 2y ago
        It is only one old C codebase however (or a couple if one counts the *BSD semi-forks separately) instead of many different fresh c codebases (one per compositor with some shared code between some of them to be fair). I don't buy that this is actually better for security. It is a lot of more fun/less painful than cleaning up and improving some legacy codebase however.
    - deleted 2y ago
      [deleted]
    - j16sdiz 2y ago
      I hope not. The core wayland protocol have so many missing piece and many extension are not standardized nor well defined. This is basically killing the interoperability between UI toolkit for non-trivial cases.
      - postepowanieadm 2y ago
        Good enough for Gnome.
        yjftsjthsd-h 2y ago
        Well.... yeah? GNOME doesn't care about interoperability; they're the ones known for ex. suggesting that applications remove features for other desktops because GNOME doesn't use them ( https://trac.transmissionbt.com/ticket/3685#no1 https://trac.transmissionbt.com/ticket/3685#no1 ).
  - kragen 2y ago
    games, blender, audacity, gimp, mpv, eclipse, prusa slicer,...
    - cies 2y ago
      IntelliJ IDEs. They are working on it though: https://youtrack.jetbrains.com/issue/JBR-3206/Native-Wayland-support https://youtrack.jetbrains.com/issue/JBR-3206/Native-Wayland... https://wiki.openjdk.org/display/wakefield/Known+problems+and+solutions https://wiki.openjdk.org/display/wakefield/Known+problems+an...
  - gtirloni 2y ago
    If I use X11, I have to live with screen tearing, which Wayland doesn't suffer from.
    - p_l 2y ago
      Unless your application use GPU for rendering and you have more than one GPU involved, or have GPU driver that doesn't implicitly serialize events behind the scenes (as it should NOT), and your display stack has not yet migrated to experimental extension that patches Wayland with actual support for synchronized rendering (explicit sync). If any of the above applies, tear-free behaviour is accidental, because Wayland protocol design fucked up synchronization primitives from day 1.
      - hawski 2y ago
        Could you expand on what is wrong with the synchronization primitives in Wayland protocol?
        p_l 2y ago
        tl;dr the core protocol only lets you inform the compositor that the surface object is "ready" - which turns out to work effectively only for software drawing, or waiting possibly entire frame for your image to show up on screen. That's if you're careful about calling "commit" on the surface only after whatever GPU draw calls you executed on it finished and the surface has been fully rendered to memory. Turns out it somewhat works even if you're not properly careful because a lot of drivers (especially Mesa) had unspoken, implicit serialization happening in the drawing pipeline. One issue is when you have more than one GPU (common on higher-end laptops). Even when you're rendering application surfaces on one GPU, they will often have to be synced to another GPU's memory to render them, because it's common to have some video outputs on iGPU and some on dGPU (example from my 2023 laptop: internal screen is behind mux that allows either GPU to exclusively write, but USB4 DP is iGPU exclusive, and separate USB-C DP is dGPU exclusive). But with increased use of asynchronous rendering APIs (OpenGL AZDO patterns, Vulkan) and with variable refresh rate screens becoming more common (even if you don't have physical one, RDP/waypipe/etc are possible users for that) you can find out a situation where compositor will start drawing a window using a surface that is not yet fully rendered, bringing back tearing. It also means it's harder to properly utilize VRR in cases where applications render at different speeds (which is fine - not everything has to render at highest possible FPS), possibly locking you down to slowest rendering element. So, the new extension, available if you ride latest patches on linux (the final part missing is new nvidia beta driver release, but not because nvidia lagged on the issue - nvidia apparently spearheaded it because their driver internals had no implicit synchronization), compositors are able to synchronize their rendering at the GPU level, getting fence objects for DRM buffer based surfaces. Meaning compositor can attempt to prevent drawing an unfinished surface, nor will application have to add extra waits in its display code.
- deleted 2y ago
  [deleted]
bitwize 2y ago
What about the fact that X.org itself is unmaintained and falling apart? It's nice that the modesetting driver covers most new hardware, but without active maintenance and governance the writing is on the wall for X.org. Without a Wayland story, the BSDs will really end up dying, at least as desktop systems.
- rabbits77 2y ago
  The article begins by explaining that it’s a follow-up to an earlier article on Wayland!
  - bitwize 2y ago
    Indeed; and if you read that article it says that current Wayland compositors depend heavily on Linux infrastructure, and have not yet accepted patches to support NetBSD. Everything Wayland on the BSDs is in the "one guy faffing about to see if he can get it working" stage. Unless/until the Wayland project starts mainlining BSD support, or the BSD projects have robust parallel maintenance of the core Wayland packages and compositors, BSD as a desktop system is dead in the water.
    - doublerabbit 2y ago
      And that's what Wayland wants. "We will only develop for Linux if you want it do it yourself" is the vibe I get from the Wayland team. Why should FreeBSD be the ones who have to develop? The stubbornness of Linux users.
      - asveikau 2y ago
        I think it's more the detail they lost (or do not agree with) is that working successfully in multiple environments can valide the strength of the design. Some people will look at a slightly different structure underneath and see it as noise and hassle instead, where you or I may see their action as taking unnecessary or questionable dependencies.
MBCook 2y ago
The article makes an offhand comment about the popularity of NetBSD in Japan. Can anyone explain why that is?
- jmclnx 2y ago
  NetBSD did change their 'logo; to a single flag years ago. And I heard the same also.
- bch 2y ago
  I seem to recall good support for PC98[0][1] was seminal. Our friend ‘washbear has notes[2], which might be touching on (eg) KAME[3] too. [0] https://en.wikipedia.org/wiki/PC-98 https://en.wikipedia.org/wiki/PC-98 [1] https://hackaday.com/2023/12/26/the-strange-world-of-japans-pc-98-computer-ecosystem/ https://hackaday.com/2023/12/26/the-strange-world-of-japans-... [2] https://news.ycombinator.com/item?id=32375371 https://news.ycombinator.com/item?id=32375371 [3] https://en.wikipedia.org/wiki/KAME_project https://en.wikipedia.org/wiki/KAME_project
  - hapless 2y ago
    PC98 support grew from the facts on the ground: NetBSD and friends had Japanese-language mailing lists and irc channels, for decades If you were a Japanese enthusiast who wanted to have a "real UNIX" on readily available hardware, NetBSD and FreeBSD were relatively more accessible
hapless 2y ago
tl;dr: X11R6 is very healthy on NetBSD and has active contributors from the same blog: Wayland is also approaching healthy on NetBSD and has active contributors There is no reason to get bent out of shape. NetBSD as a project has commitments to desktop support and seems to be living up to those commitments very well.
- deleted 2y ago
  [deleted]
Gud 2y ago
Quite frankly I hope Wayland doesn't replace X. The main killer feature for me is how easy it is to run graphical applications over the network using X. I run a FreeBSD desktop with virtualized Linux, OpenBSD and Windows systems. the ability to run applications like they are on the host system is something I have not yet seen how to do with Wayland.
- tsimionescu 2y ago
  While it's a cute idea, I doubt this feature of X has serious support behind, and I don't think any future graphics system, be it Wayland or something else, will support it. Sending rendering commands over a network is just much worse for the vast majority of applications than rendering on the source system and sending a (compressed) video stream. Sending rendering commands over a network is only decently fast if you have simple windows and no pictures. As soon as you want anyhting fancier, even as simple as opening a high res photo, the video streaming approach becomes significantly better. X's model can have one advantage, when the machine running the X client doesn't have rendering resources locally at all (so that local rendering + video streaming would take too long for the CPU, despite the network advantage). But that is an even rarer use case.
  - rwmj 2y ago
    Remote X works fine and seamlessly. I use it every hour of the day for real work.
    - Gud 2y ago
      The first time I used remote X was 10 years into my Unix career over a gigabit link. My mind was blown and still is.
  - Gud 2y ago
    That “the network is slow” is not something I am willing to accept and go to great lengths to make sure it doesn’t happen. Which is why I run a virtualized Linux(with PCI pass thru)for max wifi performance and have a 10Gbit internet pipe at home. Besides, we are talking local virtual machines in my case. Any performance issues so far has been negligible.
deleted 2y ago
[deleted]

166 points by dagenix 2y ago

Would be interesting to know also the current status of Wayland development in NetBSD, since the last blog post about it was quite a while ago.

deleted 2y ago
[deleted]
shrubble 2y ago
I came to the conclusion a while back that Wayland just doesn't matter very much. As long as Chromium and Firefox plus the GUI mode of Emacs works under X11, that is all 90% of users need/use.
- hapless 2y ago
  I doubt it I really, truly suspect Wayland is the future We have had like one hundred X11 replacements between 1990 and now, and at least half a dozen have caught on with the open source community What makes Wayland different is that it has attracted multiple vendors supporting it. Most notably IBM/Redhat, Intel, AMD, and, to a lesser extent, nVidia. I am posting this message from an X11 environment, because I need X11 for a lot of things, home and work both, but, I can at least imagine a world where Wayland is the new default. That is not something I could say about the last hundred attempts to replace X11. Edit: Again, this is just a suspicion. A notion. I neither hope for Wayland's success nor failure. I just keep my finger to the wind.
  - Kwpolska 2y ago
    Wayland might be the future (though I'm personally a bit skeptical). It is already the default on many distros. At the same time, X11 is very unlikely to just stop working or disappear, since there's really no good reason to kill it.
    - hapless 2y ago
      My skepticism should be quite obvious: I am still posting through an X11 system. But, Wayland is far and away the best and most serious attempt to replace X, ever, in thirty years and more. If there is gonna be an X11 replacement, ever, Wayland is the most credible attempt in decades
      - vundercind 2y ago
        Agreed that it’s made the best show of attempting, but Wayland’s only got about nine years before it’s as old as x11 (the protocol) was when the Wayland showed up. If it’s gonna mostly displace x11… man, it’s sure taking its time. It’s older than xfree86 was when the xorg fork occurred.
        The_Colonel 2y ago
        > If it’s gonna mostly displace x11… man, it’s sure taking its time. Yes, and I'm fine waiting 5, 10, or 20 years. It's natural that such major shifts take a long time in an already mature ecosystem.
      - raffraffraff 2y ago
        I'm also using X11, even though I've attempted to switch to Warplanes twice and had to switch back due to screen sharing and remote desktop being trash or just breaking after some update or other (most recently, browser). It's a work machine and I simply can't waste an hour fucking around with it. Aside from those issues which are deal-breakers in work, there's a bunch of minor annoyances I won't go into, thrust not deal brakes but they're "there". With X11 everything I need just works. I'm on a bleeding edge distro (OpenSUSE Tumbleweed) so I'll probably try it out on a weekend every few months to see if it's better. But in fairness I did that before, made the switch and then lost screen sharing after some random update...
        petepete 2y ago
        Screen sharing was the final hurdle for me. I switched to running Slack in a Chrome tab and it works better than it ever did on X11 for me. I've used it on both my work computers for a few years now and it's been totally solid.
  - guappa 2y ago
    wayland's main purpose is to isolate ~~malware~~ proprietary software running in a container, which Xorg doesn't allow (unless of course you run nested servers). It wouldn't be too bad of a goal if it had feature parity, which it still doesn't have.
    - welterde 2y ago
      X11 does have various ways to restrict access (one of which ssh does use for instance) and some more advanced security extensions. But as far as I can tell there has never been that much motivation to widely deploy any of it.
      - nolist_policy 2y ago
        Eh even if you secure the X11 API itself, the Xorg server still is a 33 year old (!) c codebase.
        guappa 2y ago
        Linux is 33 years old as well. Let's stop using it to be secure?
        jdiez17 2y ago
        Linux is not as secure as most tech people would assume at first glance. The monolithic kernel with all device drivers in ring0 is, let's just say, not the best approach if one were writing a new OS from scratch. It is mostly "secure" due to it being used in practically every server and billions of devices, so there is an active maintainer community around it. Xorg has none of that.
        welterde 2y ago
        It is only one old C codebase however (or a couple if one counts the *BSD semi-forks separately) instead of many different fresh c codebases (one per compositor with some shared code between some of them to be fair). I don't buy that this is actually better for security. It is a lot of more fun/less painful than cleaning up and improving some legacy codebase however.
  - deleted 2y ago
    [deleted]
  - j16sdiz 2y ago
    I hope not. The core wayland protocol have so many missing piece and many extension are not standardized nor well defined. This is basically killing the interoperability between UI toolkit for non-trivial cases.
    - postepowanieadm 2y ago
      Good enough for Gnome.
      - yjftsjthsd-h 2y ago
        Well.... yeah? GNOME doesn't care about interoperability; they're the ones known for ex. suggesting that applications remove features for other desktops because GNOME doesn't use them ( https://trac.transmissionbt.com/ticket/3685#no1 https://trac.transmissionbt.com/ticket/3685#no1 ).
- kragen 2y ago
  games, blender, audacity, gimp, mpv, eclipse, prusa slicer,...
  - cies 2y ago
    IntelliJ IDEs. They are working on it though: https://youtrack.jetbrains.com/issue/JBR-3206/Native-Wayland-support https://youtrack.jetbrains.com/issue/JBR-3206/Native-Wayland... https://wiki.openjdk.org/display/wakefield/Known+problems+and+solutions https://wiki.openjdk.org/display/wakefield/Known+problems+an...
- gtirloni 2y ago
  If I use X11, I have to live with screen tearing, which Wayland doesn't suffer from.
  - p_l 2y ago
    Unless your application use GPU for rendering and you have more than one GPU involved, or have GPU driver that doesn't implicitly serialize events behind the scenes (as it should NOT), and your display stack has not yet migrated to experimental extension that patches Wayland with actual support for synchronized rendering (explicit sync). If any of the above applies, tear-free behaviour is accidental, because Wayland protocol design fucked up synchronization primitives from day 1.
    - hawski 2y ago
      Could you expand on what is wrong with the synchronization primitives in Wayland protocol?
      - p_l 2y ago
        tl;dr the core protocol only lets you inform the compositor that the surface object is "ready" - which turns out to work effectively only for software drawing, or waiting possibly entire frame for your image to show up on screen. That's if you're careful about calling "commit" on the surface only after whatever GPU draw calls you executed on it finished and the surface has been fully rendered to memory. Turns out it somewhat works even if you're not properly careful because a lot of drivers (especially Mesa) had unspoken, implicit serialization happening in the drawing pipeline. One issue is when you have more than one GPU (common on higher-end laptops). Even when you're rendering application surfaces on one GPU, they will often have to be synced to another GPU's memory to render them, because it's common to have some video outputs on iGPU and some on dGPU (example from my 2023 laptop: internal screen is behind mux that allows either GPU to exclusively write, but USB4 DP is iGPU exclusive, and separate USB-C DP is dGPU exclusive). But with increased use of asynchronous rendering APIs (OpenGL AZDO patterns, Vulkan) and with variable refresh rate screens becoming more common (even if you don't have physical one, RDP/waypipe/etc are possible users for that) you can find out a situation where compositor will start drawing a window using a surface that is not yet fully rendered, bringing back tearing. It also means it's harder to properly utilize VRR in cases where applications render at different speeds (which is fine - not everything has to render at highest possible FPS), possibly locking you down to slowest rendering element. So, the new extension, available if you ride latest patches on linux (the final part missing is new nvidia beta driver release, but not because nvidia lagged on the issue - nvidia apparently spearheaded it because their driver internals had no implicit synchronization), compositors are able to synchronize their rendering at the GPU level, getting fence objects for DRM buffer based surfaces. Meaning compositor can attempt to prevent drawing an unfinished surface, nor will application have to add extra waits in its display code.
deleted 2y ago
[deleted]

bitwize 2y ago

What about the fact that X.org itself is unmaintained and falling apart? It's nice that the modesetting driver covers most new hardware, but without active maintenance and governance the writing is on the wall for X.org. Without a Wayland story, the BSDs will really end up dying, at least as desktop systems.

rabbits77 2y ago
The article begins by explaining that it’s a follow-up to an earlier article on Wayland!
- bitwize 2y ago
  Indeed; and if you read that article it says that current Wayland compositors depend heavily on Linux infrastructure, and have not yet accepted patches to support NetBSD. Everything Wayland on the BSDs is in the "one guy faffing about to see if he can get it working" stage. Unless/until the Wayland project starts mainlining BSD support, or the BSD projects have robust parallel maintenance of the core Wayland packages and compositors, BSD as a desktop system is dead in the water.
  - doublerabbit 2y ago
    And that's what Wayland wants. "We will only develop for Linux if you want it do it yourself" is the vibe I get from the Wayland team. Why should FreeBSD be the ones who have to develop? The stubbornness of Linux users.
    - asveikau 2y ago
      I think it's more the detail they lost (or do not agree with) is that working successfully in multiple environments can valide the strength of the design. Some people will look at a slightly different structure underneath and see it as noise and hassle instead, where you or I may see their action as taking unnecessary or questionable dependencies.

MBCook 2y ago

The article makes an offhand comment about the popularity of NetBSD in Japan. Can anyone explain why that is?

jmclnx 2y ago
NetBSD did change their 'logo; to a single flag years ago. And I heard the same also.
bch 2y ago
I seem to recall good support for PC98[0][1] was seminal. Our friend ‘washbear has notes[2], which might be touching on (eg) KAME[3] too. [0] https://en.wikipedia.org/wiki/PC-98 https://en.wikipedia.org/wiki/PC-98 [1] https://hackaday.com/2023/12/26/the-strange-world-of-japans-pc-98-computer-ecosystem/ https://hackaday.com/2023/12/26/the-strange-world-of-japans-... [2] https://news.ycombinator.com/item?id=32375371 https://news.ycombinator.com/item?id=32375371 [3] https://en.wikipedia.org/wiki/KAME_project https://en.wikipedia.org/wiki/KAME_project
- hapless 2y ago
  PC98 support grew from the facts on the ground: NetBSD and friends had Japanese-language mailing lists and irc channels, for decades If you were a Japanese enthusiast who wanted to have a "real UNIX" on readily available hardware, NetBSD and FreeBSD were relatively more accessible

hapless 2y ago

tl;dr: X11R6 is very healthy on NetBSD and has active contributors from the same blog: Wayland is also approaching healthy on NetBSD and has active contributors There is no reason to get bent out of shape. NetBSD as a project has commitments to desktop support and seems to be living up to those commitments very well.

deleted 2y ago
[deleted]

Gud 2y ago

Quite frankly I hope Wayland doesn't replace X. The main killer feature for me is how easy it is to run graphical applications over the network using X. I run a FreeBSD desktop with virtualized Linux, OpenBSD and Windows systems. the ability to run applications like they are on the host system is something I have not yet seen how to do with Wayland.

tsimionescu 2y ago
While it's a cute idea, I doubt this feature of X has serious support behind, and I don't think any future graphics system, be it Wayland or something else, will support it. Sending rendering commands over a network is just much worse for the vast majority of applications than rendering on the source system and sending a (compressed) video stream. Sending rendering commands over a network is only decently fast if you have simple windows and no pictures. As soon as you want anyhting fancier, even as simple as opening a high res photo, the video streaming approach becomes significantly better. X's model can have one advantage, when the machine running the X client doesn't have rendering resources locally at all (so that local rendering + video streaming would take too long for the CPU, despite the network advantage). But that is an even rarer use case.
- rwmj 2y ago
  Remote X works fine and seamlessly. I use it every hour of the day for real work.
  - Gud 2y ago
    The first time I used remote X was 10 years into my Unix career over a gigabit link. My mind was blown and still is.
- Gud 2y ago
  That “the network is slow” is not something I am willing to accept and go to great lengths to make sure it doesn’t happen. Which is why I run a virtualized Linux(with PCI pass thru)for max wifi performance and have a 10Gbit internet pipe at home. Besides, we are talking local virtual machines in my case. Any performance issues so far has been negligible.

deleted 2y ago

[deleted]