X.org on NetBSD – The State of Things
blog.netbsd.org
blog.netbsd.org
[0] https://en.wikipedia.org/wiki/PC-98
[1] https://hackaday.com/2023/12/26/the-strange-world-of-japans-...
If you were a Japanese enthusiast who wanted to have a "real UNIX" on readily available hardware, NetBSD and FreeBSD were relatively more accessible
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.
waypipe works. Instead of doing `ssh -X user@host <command>` I do `waypipe ssh user@host <command>`.
Could be faster, but it does work.
I assumed it was a bit slow because of the long startup lag; but it seems it's mostly because of my slow (WiFi) network, and is even worse with X forwarding.
I just tried opening the same (simple) application through waypipe and through X forwarding, and using waypipe it's actually a lot more usable.
(Using waypipe 0.9.0-1 as packaged in Debian).
I’ll give it a go when I have a wayland system
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.
The RDP protocol also sends graphics commands (mostly). It works really well on Linux with Xrdp/rdesktop. The idea of sending a video stream over network sounds good but somehow the implementations always manage to screw it up (especially on high bandwidth networks). I just did a quick test by directly streaming video over WLAN and it performed way better that VNC. I was able to stream a videogame smoothly on 30FPS, which is pretty impressive considering this was done in a very unoptimized way (netcat, TCP instead of UDP, etc.)
I will admit that in part this was just my ignorance; I just used it to access my desktop on occasion from my laptop on the sofa and didn't really want to spend a lot of time on it. rdp was "it works out of the box effort-free and I can move on with my life" and X11 wasn't. Maybe I just didn't RTFM hard enough, but I didn't have to RTF anything for rdp, so...
I use samba/SMB for similar reasons by the way; recently I wanted to setup a network drive (for the first time in about 10 years) and samba provided a much smoother "just works" type of experience than NFS. Sometimes I find the old-type Unix stuff a bit painful, especially for the "just want to get shit done" type of workflow (I did use NFS extensively with FreeBSD and NetBSD back in the day, but it seems I've forgotten almost everything).
https://techcommunity.microsoft.com/t5/security-compliance-a...
My mind was blown and still is.
Which is another reason xorg isn't going to disappear, since large labs absolutely need computer A to display a resource-intensive program running on more-powerful computer B
The idea was I sign in to my underpowered workstation and run spice (or whatever) on the more powerful server. I would like the outputs to display on my weak computer. That's the whole point of this, and labs still use it religiously.
The only technical advantage of doing it the X Server way is if the machine running the program doesn't have the resources/hardware to render.
I know it's not a usual case - which is why I'm saying this doesn't need to be built into the window system at all.
unless you're volunteering to write the code to make it not, that's how it is
Besides, we are talking local virtual machines in my case. Any performance issues so far has been negligible.
I totally disagree. Obviously it just depends on your use case, but most user interfaces are almost completely static and sending vector commands is going to be a win over raster in almost any condition. Low bandwidth? Vector wins. High RTT link? Vector wins. Dual 4k screen? Not a problem with vector, but difficult with video and disastrous with raster.
One may argue whether the current implementation in Xorg is useful or not, but conceptually, I see vector as definitely the way to go. Vector even allows you to do some predictive interpolation, while raster -- good luck.
Maybe sending HTML+javascript over the wire is the solution, ala Display PostScript except more fashionable these days. Thinking about it, one could argue that's exactly what we have these days with the web...
Sending vector commands only makes sense if you have simple vectors. That isn't the case for modern apps and can't be the case for many kinds of apps.
Have you tried modern remote desktop solutions, like Parsec? Streaming 4K games or CAD works quite well, latency is about 20ms over the internet, low enough for most things.
As long as Chromium and Firefox plus the GUI mode of Emacs works under X11, that is all 90% of users need/use.
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.
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.
Stuff might eventually decide to render directly to Wayland only APIs or something.
I'm actually not a very big Wayland fan, I prefer the single implementation model rather than all the different implementations of Wayland.
But I'd rather have just only the Wayland fragmentation mess, instead of the Wayland mess plus also X11, so I'm glad Pi OS and Ubuntu(Right now the only distros I pay much attention to) have switched.
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
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.
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.
The major bit will be when and if toolkits like GTK, Qt, SDL, etc. drop X11 support and applications update to X11-less versions. AFAIK there are no plans for that and is still years away (there was some talk about GTK 5, but nothing firm and no one even started work on GTK 5).
I also think Wayland will eventually replace all of X11, in the same way as IPv6 will eventually replace all of IPv4.
As XWayland. XWayland will be the new X.
Some qualified language in all of the above, because hard to predict the future etc. etc.
Or, if necessary, with just a tiny bit of Wayland; XWayland rootful mode lets you run a full X stack with Wayland as little more than a shim to the graphics driver. As a worked example, Puppy Linux implemented this: https://github.com/puppylinux-woof-CE/woof-CE/pull/2265
People that prefer X11 is not what I'd optimize for. To me X11 is deprecated, unmaintain{ed,able}. It became too much of a stumbling block for Linux and other opensource OSes. It's painful, but we have to move on. Wayland is not perfect but it seems to be doing the job lately. In two year --my prediction-- it will be more stable than X11 in all aspects.
I wouldn't either, but that doesn't mean it won't work.
both Wayland and X11 are fairly stable AFAIK. For my part I'd rather not rewrite all my X11-specific stuff. For some I probably need to have direct compositor support as you can do less with scripts, so that's not so easy. I'll probably have to spend the effort at some point, but until I don't have to: why bother?
It wouldn't be too bad of a goal if it had feature parity, which it still doesn't have.
Trusted Solaris 7 had shipped in 1999; 9 years BEFORE Wayland ever existed.
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.
They are working on it though:
https://youtrack.jetbrains.com/issue/JBR-3206/Native-Wayland...
https://wiki.openjdk.org/display/wakefield/Known+problems+an...
If any of the above applies, tear-free behaviour is accidental, because Wayland protocol design fucked up synchronization primitives from day 1.
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.
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.
Without a Wayland story, the BSDs will really end up dying, at least as desktop systems.
bitwize on Aug 31, 2015 - https://news.ycombinator.com/item?id=10149015
> It's written against an obsolete windowing model for a deprecated window system.
bitwize on Jan 9, 2016 - https://news.ycombinator.com/item?id=10869618
> Since X is now deprecated tech
And tons more: https://hn.algolia.com/?dateRange=all&page=3&prefix=true&que...
Maybe give it a rest and let others have their toys without flying off the handle with comments that say or contribute nothing.
And it's not even applicable here; there's literally a linked post about how Wayland is being worked on in this article's first sentence. But I guess the volunteers of NetBSD aren't working hard enough or something.
That is what it is! It's fine! if Wayland is the future, so be it, but it won't be because X11 got deprecated again. X11 has been deprecated plenty of times before!
Wayland may very well take over the unix and most especially linux desktop story, but that is not a done deal, yet. My last two? three? jobs all explicitly required X11 as a thing, so if giant enterprises are not picking up wayland, the deal ain't done, yet, you read me?
As an fvwm2 addict, I do not relish that day.
The problem is that said feature bloat is also exactly what makes it attractive to desktop users. I'm not saying that Wayland has no use; it can reliably cover ~90% of all computer tasks and if you're just setting up some sort of kiosk/server with one application, I think it's hard to not pick Wayland since you can just grab a thin renderer and avoid all the extra crap that comes with XOrg.
But for desktop, the weird/random things XOrg allows you to do are what makes it the undisputed king to this date.
It's not what's best that wins. It's that what covers the widest amount of usecases that does, regardless of any amount of bizarre rituals that you need to do to get it working (and only if you have feature parity does less weird rituals take over in priority). Wayland already lost that race before it even started since feature parity with XOrg is a non-goal.
Other examples of this concept in action: Any old-school Microsoft project (really, just all of MS Office), the entire HTTP frontend stack, SQL, PDF.
Works for me, and has for literal decades.
> ...without active maintenance...
This update to xorg-server was stabilized on April 14th, and it looks like library changes required me to rebuild and reinstall it like two days ago:
$ eix -I xorg-server
[I] x11-base/xorg-server
Available versions: 21.1.13(0/21.1.13)^t **9999(0/9999)*l^t {debug +elogind minimal selinux suid systemd test +udev unwind xcsecurity xephyr xnest xorg xvfb}
Installed versions: 21.1.13(0/21.1.13)^t(03:15:55 PM 05/03/2024)(elogind udev xorg -debug -minimal -selinux -suid -systemd -test -unwind -xcsecurity -xephyr -xnest -xvfb)
Homepage: https://www.x.org/wiki/ https://gitlab.freedesktop.org/xorg/xserver/xorg-server
Description: X.Org X servers
Weird. Looks like they're running Board of Directors elections. [0]
[0] <https://lists.x.org/archives/xorg-devel/2024-March/thread.ht...>
Just so you know: The X.Org Foundation also oversees Wayland.
X.org the foundation is electing a board of directors. They're also all-in on Wayland.
For example, in January this year, xrandr got code to allow for multiple virtual monitors on a physical display. In April, there were 2 bugfix releases.
If they were all-in on Wayland, they wouldn't be making regular xorg-server releases, and definitely wouldn't be adding new features to xorg components. (Because, yanno, they wouldn't have any staff available to do those things.)
Is it? Seems to work just fine. Not all that is new is good. Not all that is old is bad.
To begin with, when we hear the word "dead," one's mind might instinctively leap to its most literal and unfortunate meaning—devoid of life. In biology, this means the cessation of all vital functions: no heartbeat, no brain activity, no breath. The ultimate and irreversible state that all living things, sadly, will eventually meet. It's quite final, isn't it? The end of the line. Kaput. There's no ambiguity here; dead means dead.
However, the wonders of language allow us to use words in metaphorical or idiomatic expressions to convey more complex or nuanced situations or states. And that's where "dead in the water" swims into the scene. This phrase, you see, has nothing to do with the literal cessation of life. Oh, no. It's far more colorful and applicable in a variety of non-lethal scenarios.
Originally, this idiom comes from the nautical world—a domain rich with metaphorical language, given the myriad challenges and adventures faced at sea. Imagine a ship, if you will, its sails billowing as it cuts through the waves. Now, picture it suddenly unable to move; the wind has died down to nothing, the sails slump, and the ship is merely adrift, going nowhere. It is, quite poetically, "dead in the water." The ship isn't literally dead, of course—it's just temporarily incapacitated, unable to proceed along its intended course until the wind decides to grace it with its presence once again.
Transposed into everyday usage beyond the high seas, "dead in the water" is a vivid metaphor for projects, plans, or initiatives that have come to a halt—stymied, unable to progress, much like that becalmed ship. It's used to describe something that has little hope of success or revival in its current state. For instance, if a business venture runs out of funding or a new policy is halted by regulatory issues, they might be described as "dead in the water." Not literally deceased, but stuck, with no forward momentum.
In essence, while "dead" is the cessation of life, "dead in the water" is about cessation of progress or movement—figuratively speaking, of course. The latter suggests a temporary state, a problem potentially fixable, perhaps with effort, change in strategy, or a shift in external conditions, unlike the permanence and finality of being literally dead.
Isn't it simply marvelous how language lets us draw such specific shades of meaning with just a tweak of phraseology? Through this exploration, we can appreciate not only the richness of English idioms but also the joy of explaining something so deceptively simple yet profoundly different. Here we stand—or float, if you will—at the junction of literal and metaphorical, grasping the beauty of expression. And isn't that what language is all about?
Seems blown out of proportion, at least partially because of missing figurative language. The above wall of text seems a long-winded, somewhat tongue-in-cheek way to say "yeah I didn't say that."
The guy in the old west who drew his gun and said “them’s fightin’ words?” He probably didn’t enough English to understand the whole sentence but picked out a few words which meant to him “fight.”
Anyway, it was pointed out that the same user that said "dead in the water" did indeed comment upthread that BSDs will "end up dying," so goes to show that I wasn't paying attention.
I am literally pointing out that Wayland enthusiasts love to gang on X11 as "dead" as a put-down and anybody who still uses it is evil or something. It's a toxic attitude that I've seen a lot here. It should ... pardon the metaphor .... die.
> ...the BSDs will really end up dying,...
That wasn't very figurative, even if "dead in the water" was. For all it's worth, bitwize might have been using that figure of speech inappropriately when they really meant "dead".
All this to say that even as an outside observer, one can read exactly the same things differently, so perhaps we should all get off our high horses and start riding ponies or bicycles (what? :)) — I mean, back to the discussion at hand.
No, I didn't miss it at all, and this is a weird take.
However, its appropriateness as a metaphor does have to do with the literal meaning. Even a less maintained software project with a longer-term deprecation roadmap that still has millions relying on it is not "dead". This very article is talking about how the *BSDs are putting more maintenance into that tree than upstream, and those are actually signs it isn't a total dead-end; they've done that maintenance over the years because it's valuable to them. But bitwize was calling it dead in an attempt to put it down. I've found this particular brand of negativity is very common in Wayland enthusiasts. It is like ad hominem in software maintenance discussion. The source is available for anyone to hack on and use, or not, as they please. There's no sense in ad hominem attacks, exactly as bitwize engages in above, for that.
To be honest, the attacks like this remind me of the XZ backdoor. The sock puppets in those mailing list threads complaining, I would say whining, about "dead", "unmaintained" libzma were channeling the exact same energy. Cool it down. It's not necessary.
"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.
At least, I think everything they’ve been up to and these projects they heavily influence have been doing makes a ton more sense if that’s the plan. It’s that or a lot of weirdly-hostile and disorganized stuff has been happening by chance in a way that achieves that effect by accident.
The BSDs are just collateral damage, I reckon.
Good news then, FreeBSD already has working Wayland and NetBSD is working on it. Granted, I think OpenBSD stands out without a Wayland plan, but maybe I'm wrong there.
check this out - https://www.openbsd.org/papers/eurobsdcon2023-matthieu-wayla...
Not sure about other desktop environments as I don't use them.
(It fares better compared against x11 instead, but not as much-better as one might guess—either way, it’s been a sloooow moving project)
I find especially funny how Wayland attempted to have "tear free done right"... and the expected display path (GPU accelerated) turned out to either involve 1 or more frame delay, or tearing because Wayland protocol didn't support explicit sync on render finish.