Without a Wayland story, the BSDs will really end up dying, at least as desktop systems.
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
> ...and governance the writing is on the wall for X.org.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.
"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.
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 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.
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.
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.
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.