Just that rather than manually configure it, it will be automatically (they hope) configured by combo of systemd, polkit and your DE of "choice".
Damn those freedesktop.org people!
The rest of us just want our own systems to run as well or better for our own usecases as they currently do. Wayland is a great opportunity to rearchitect the Linux display system rather than organically grow it as X11 has over decades. But if you don't take into consideration those of us who use our Linux workstations as more than a Facebook machine with SSH preinstalled; you're just going to recreate the problem.
People will start disregarding freedesktop, Wayland and so on and either stay in X or using a Wayland compositor that couldn't care less for standards and short-circuit every single convention and security protocol you have designed as long as it lets them get shit done, because at the end of the day, as beautiful as we like our code to be and our software to be architected; people want their systems to work for them.
Ugh, there actually are people who enjoy the GNOME desktop, so maybe don't present your personal opinion as a collective sentiment. As an owner of a MBP, I can tell you that I prefer GNOME in speed, workflow, look, customizability - you name it. In what way exactly is GNOME like macOS in your opinion?
Well, speak for yourself. Which seems to be the loudest voices in these debates, people speaking for themselves.
Wayland solves real, systemic issues in windowing, most notably around security, that need to be solved. It also allows outsourcing of many of X's most unwieldy features to the clients (IPC, rendering, and networking). In many ways, Wayland is closer to the Unix philosophy of one program/one task than X while also being safer to use.
And, it's not like you need to drop X, just like you don't need to drop init. The beauty is that you can continue to use and maintain whichever you feel are the best tools.
> People will start disregarding freedesktop, Wayland and so on and either stay in X or using a Wayland compositor that couldn't care less for standards...
I feel like the same things were said about systemd a few years ago and here we are, every major distribution uses it out of the box. And every windowing system and graphical toolkit supports Wayland, long before Wayland was a default. Though I'm not an expert in graphical compositing and rendering, I can't imagine this is by accident. Numerous projects must feel the technical advantages of Wayland outweigh the disadvantages of change.
That's exactly my sentiment and I brought it up in the comment. The problem is designing these protocols without regard for how the thing you're replacing is being used. That's only going to result on a pile of hacks. It's just baffling how short-sighted some of the Wayland devs are when the project was born precisely because of these hacks accumulating in X.
> And, it's not like you need to drop X, just like you don't need to drop init. The beauty is that you can continue to use and maintain whichever you feel are the best tools.
Oh yes, because obviously everyone wants to maintain 10 different code paths so it's not like Red Hat is pushing their software with their influence over the ecosystem oh no no. But enjoy maintaining those shims, we sure as hell don't care about standards! Gotta move fast, break things and compatibility is for losers.
>I feel like the same things were said about systemd a few years ago and here we are, every major distribution uses it out of the box.
And it's just been dandy isn't it? We still don't have stable interfaces between its parts (yet they still have the gall to say that systemd isn't monolithic), good effin luck debugging it when it shits the bed... list is long, but pick your poison: http://without-systemd.org/wiki/index.php/Arguments_against_...
Negative points will be awarded on "works for me".
> And every windowing system and graphical toolkit supports Wayland, long before Wayland was a default. Though I'm not an expert in graphical compositing and rendering, I can't imagine this is by accident. Numerous projects must feel the technical advantages of Wayland outweigh the disadvantages of change.
The premise is great, what's not to love about it. The problem is execution. Because of Wayland's model, a lot of applications relying on X's nature are left out in the dirt. Standards are the way to solve this, and some work is being done about this, but the comment I replied on by coldtea simply shat on all this with a message akin to "Don't stop the momentum, you're a minority FUCK YOU we don't care about you get on board or get ran over". This is what I was criticizing.
We need standardization. Ideally we have a single solution that improves on the status quo and we call it a day; but where there's disagreement let's find our middle ground and standardize it. If you don't need 4 mice and 4 keyboards working simultaneously great! But what you find useless and nonsensical can be the greatest fun ever in a 4-player co-op session of Serious Sam 3 for groups of friends around the world; or just as well prove to be one of the most productive formats for groups of people working together in a local application.
Can you really blame X developers for not wanting to maintain something painful?
It's fair for them to focus on things that will please the majority of users. Not everyone are happy with using 40-year-old technology for their daily needs. But this is open-source; contribute if you like it.
> We need standardization. Ideally we have a single solution
X has its own barely readable standard, and Wayland is a separate standard protocol which is unavoidably incompatible. The core X protocol makes assumptions that are no longer valid, and its maintainers have tried patching around it for dozens of years without breaking the standard, but many issues were simply unsolvable.
And I mentioned it plenty of times: But I like the idea behind Wayland, and think it's a great thing that the display system is finally getting rearchitected and rewritten.
My problem isn't "I no longer have X", my problem was the attitude of "Wayland doesn't have to care about non-average users when replacing X" which I was previously responding to.
Say hello to RH fueled code churn. First it was powerkit, then it was powerd, and now most of it is found inside systemd-logind. Want to power down the computer by clicking a button in the DE, you need systemd-logind, powerd as a wrapper (for now), polkit, and dbus to glue it all together.
That or you can forgo building your default distro install around any of the major DEs.
The CADT that JWZ railed against a decade ago have gone supersonic, and heading towards superluminal.
I really fear for the day Torvalds hands off the maintenance of the kernel, as he is likely to hand it to someone that is already very accepting of this churn.
Edit: BTW, it seems the BSDs still rely on hald. Maybe i should bite the "apple" and move on over.
The whole reason people switch to Linux in the first place is for uncommon use cases.
Well, I beg to differ.
On the server, that's not true. People use Linux for the most commonplace use cases (e.g. the LAMP stack) as well.
On the desktop, that's what needs to change, and has been promised to change since 1999 ("next year will be the year of the Linux desktop" which has been endlessly repeated was not about some outliers using it for "uncommon" use cases, but about mass adoption).
But the whole critique is wrong too. When I said about "improving common uses cases" to the detriment of "uncommon uses cases" the former wasn't referring to features different people use. The people who use those "uncommon use cases" ALSO suffered from the crappy implementations and shortcomings of the common use cases like everybody else.
On the desktop Linux have a twofold problem. No prominent presence in stores (observe that Android, being a Linux derivative, have a massive presence, and the rise of ChromeOS) and a lack of commitment to API stability from the major lib devs (again contrast Android, where you have versioned APIs going back to the early days).
Interesting.
First, just because something is common (multitouch laptops), doesn't mean something similar is equally common (multiple mice).
Second, those multiple mice weren't used for a person controlling multiple pointers at the same time, but for multiple people using the same computer in different window sessions. So not like multi-touch at all.
Third, even if multiple mice used at the same time by the same person was what we were talking about, it doesn't follow at all that it would be as convenient and approachable as multi-touch to have it be something more of an edge case.
You can use Xorg as you always did, Wayland is fully optional.
> They did it with systemd
What part of hacky, inconsistent, non-dynamic and hard to maintain InitV shell scrips do you actually miss in systemd? Or do you just hate it because it's cool, like it was with PulseAudio?
The others where just files in some server, used by almost nobody.
Ohh, and in some cases even the files have been lost: http://git.einit.org/
For now...
I don't dismiss your points at all, just showing wayland is not a subset of X.
That's the point. It'already automatic.
I haven't even mistakenly opened xorg.conf in at least five years.
And quite franky, I see no need for another thing like Wayland to add entropy to the GNU/Linux desktop.
> by combo of systemd, polkit and your DE of "choice"
eh...
I'm sure the merits can be discussed, but security is a need that Wayland addresses.
These then try to tie a video output, and at least one input device (mouse, keyboard, whatsnot) to a specific seat (as defined by systemd-logind) so that only associated (systemd-logind defined) sessions can interact with them.
Note that all this happens above the kernel, that (as best i can tell) do not have a concept of a seat, and sessions are tracked on a tty basis.
And ttys used to be physical devices connected to the computer via a serial connection (and still can be even on Linux, nice for getting those early kernel errors onto something that do not go poof the moment the GPU driver code do a belly flop).
Never mind that X was designed to work as a graphical tty of sorts. Thus rather than try to stuff raw bitmaps down the wire, the client code running on the computer would send draw command primitives (line from X,X to Y,Y, square with top left corner at A,A and bottom right at B,B, that sort of stuff) that the X server sitting on a desk somewhere would turn into a GUI.
I think Xscreensaver still use that for drawing the "screen lock" password prompt and launch popup.