Don’t a lot of CPUs like Snapdragons already have “performance cores” and “efficiency cores” that the kernel has to be able to recognize in order to switch between them? This sounds neat but I’m just curious what’s different between these situations.
The only difference is the hardware. Intel has their own version that has been in the kernel for a long time. Amd has been struggling with landing the concept.
Even Intel has these. I think this patch set goes a bit further and takes into account the silicon lottery differences between cores (according to the patch series)
I’m using the patch set on my framework 7840u and didn’t notice a difference though, though this is really YMMV.
Did you do benchmarks? It probably doesn’t help much for heavily multi threaded apps, as they should use all cores anyway. And most apps aren’t performance critical, altough it might stabilize fps in games.
This isn’t only an app issue, it’s the implementation in Mutter.
On KDE for example, I’ve set 150% fractional scaling, and all apps look sharp.
I was really hyped when the recent update introduced “proper” fractional scaling, and was bummed when I noticed it didn’t work in many of my apps, especially Electron ones.
It’s not just a percentage thing. 1 person yesterday to 2 people today is a 100% increase. Not much of a surge, at least in terms of news worthiness. Going from 6% to 10% sounds more news worthy than going from 1% to 2% despite the latter being a much larger percentage increase.
That’s why we’re talking about relative percentages.
In your example we would need to know how many trees existed on your road/city before. If there were less than 3 or 4 trees in your city before this, saying there was a surge is likely fine.
I gave you that information, I said “from 1 to 2” and added context of “a tree” (singular)
My terribly made point is that although technically correct when talking about relative increase it’s dumb as fuck to say trees “surged in population” after adding just one more on one street. It’s a drop on the ocean.
I feel like the term surge respects the final total relative to what its maximum could be as well as the relative increase. But obviously language is regional and up for interpretation
Opening the connections is one thing but resends and stream ordering can also cause issues since they might delay the latest information reaching the user space application even if the packet for them has actually arrived just because some earlier packet has not. There can also be issues with implementations waiting for enough data to be available before sending a packet.
If your connection is stable, the latency will more or less be the same, but TCP will consume more bandwidth because of acknowledgement packets, making it harder to keep your connection stable.
On an unstable connection, TCP latency will skyrocket as it resends packets, while UDP will just drop those packets unless the game engine has its own way of resending them. Most engines have that, but they only do it for data that is marked as “important”. For example using an item is important, but the position of your character probably isn’t, because it’ll be updated on the next tick anyway.
Backwards compatibility forever sounds great, but the technical debt eventually becomes a giant fucking limitation on improvement. They chose not to stay backwards compatible for a reason.
I agree that at some point you have to be able to ditch technical debt, but you still should be able to do more or less the same things with the new system as with the old system and that’s currently still not the case.
The problem is that the architecture of Wayland and the organization around it themselves impose limitations that have a chilling effect on development for it. One issue is that Wayland has been deliberately left very slim, leaving a lot of complexity and implementation details up to the compositor. A compositor can be seen as something that approaches the size and complexity of an entire X display server. This means that if someone wants to create a window manager, they have to implement a whole compositor first. So instead of writing window manager code, which is what the developer is probably the most interested in, they are spending most of their time implementing the compositor.
Naturally this also leads to a lot of duplication of effort. For example: GNOME, KDE and the window managers that have implemented a wayland version each have their own compositor that by and large does the same thing.
Another issue is the standardization of the protocols and interfaces that the different compositors use, or lack thereof. There is a steering group containing the major stakeholders that votes on proposed extensions, but good proposals often get shot down because the major stakeholders can’t agree on it and sometimes ego or principles gets in the way. And then you have cases where one compositor just goes their own way and implements something regardless of what the others do.
For example, as a result of this there’s still no standard screen capture API, so if you want to do things like screenshots, remote desktop, desktop streaming, … whether or not you can do that, and with which tool, depends on the compositor you use. Another example: they’re currently still bickering over whether or not an application should be allowed to place windows with absolute coordinates, and how that should be implemented. We’re currently 15 years after initial release of Wayland…
In my opinion, this is all completely backwards. Both in an organizational and technical sense way too much has been left up to the individual compositors that should have been a core part of Wayland itself.
Unfortunately, it’s all too late to fix this. We’re 15 years into Wayland development, and the flawed architecture has been set in stone. Wayland isn’t going to go away soon either, too many parties are invested in it. So for me the reasonable thing to do is to wait and stick with X11 until the dust settles and something emerges on the other side that is better than what I currently have.
This means that if someone wants to create a window manager, they have to implement a whole compositor first. So instead of writing window manager code, which is what the developer is probably the most interested in, they are spending most of their time implementing the compositor.
wlroots has existed for almost 7 years and this misconception is still repeated.
I know wlroots exists. It’s a library that helps you implement a compositor (i.e. does some of the heavy lifting), but at the end of the day the window manager developer is still implementing a compositor and is responsible for maintaining his compositor.
The mere fact that wlroots, and other efforts like louvre, are necessary at all actually prove my point that it was an idiotic design to push everything off into “compositors”.
Yes. And it’s a bad analogy. Nobody is expecting you to be able to take a barge on railways. But existing linux applications are being expected to run on Wayland. As I said - railways didn’t replace canals - they’re different types of things.
Within the last 10 years and the next 5 years, software using old hacks instead of GUI toolkits are expected to switch, yes.
People can choose to continue to use X11 until KDE Plasma 6 hits Debian stable.
I don’t see a problem. Nobody forces Wayland onto anyone yet, except for bleeding edge distributions like Fedora. And unless you’ve been severely misled, you should know what you signed up for when you installed Fedora.
I didn’t say there was a problem. I’m saying it’s pretty disingenuous to act like Wayland isn’t intended as a replacement for X11. All of which you seem to agree with. As you say “nobody forces Wayland onto anyone yet” (emphasis mine).
Also - I just love how your comment is written like a politician would have written it. “Sure you can use the dirty old X11 if you really want to, or you can use the nice new God-fearing Wayland”.
If you bring the two parts of your comment together and dial back the assumptions of bad faith, you’ll get a consistent picture:
Wayland is a blank slate replacement for how to do window management on Linux. At some point it’ll become the standard for software that’s new or maintained. Unmaintained software that doesn’t talk to the internet and is therefore safe to run even with security holes will continue to be supported via XWayland. The giant scope and API surface is part of the reason why it’s deprecated. Maintainers are expected to target the new way to do things going forward, because there are people able and willing to maintain that support (many of those people former X11 maintainers who are looking forward to stop having to deal with that legacy behemoth)
That’s the state of things I wanted to express. Not my opinion, no agenda, just how I understand the situation.
Yeah sorry. But when you look at the events building europeen railways. More so in the UK as we had a huge canal system built in a few decades. But most of Europe denser areas.
Railways were very much a replacement for the to slow canal system.
Canals built a huge industry allowing manufacturers to ship goods to cities while shipping resources from the mines and farms etc.
But industries like meat fish milk and strongly enough market gardening (fresh flowers) were very limited to local areas before the railways. Took off hugely when the railways intentionally set up in direct competition to the canals.
Canals survived for a while moving the slower stuff. But started needing to redesign to support bigger and more boats faster. Before finally closing down.
The UK and most of Europe rebuilt/renovated them as a leasure activity from the 1950s. But most of the late 1800 to early 1900s railways vcompanies actually worked to replace and put canal companies out of business.
Passenger rail really was not a big thing untill about the 1920s.
We’re getting well away from the topic now. It depends on what you mean by “replace”. Railways and canals exist side-by-side as different solutions to similar problems - sure. And some railways have replaced some canals. But the panama canal will not be replaced by a railroad for example. It couldn’t do the same job. The pros/cons of each option depends on many factors.
The analogy is poor for comparing software. Linux distros will likely replace X11 with Wayland over time. To do the same thing that X11 was doing. It will be replaced “in place”. The very same thing you were using with X11 will now need to work on Wayland. This would be like running your barges on the railroad? Maybe? Depending on how you squint?
I wouldn’t expect my barge to work on the railroad. I do expect that Firefox will run on Wayland after having used it on X11 for 20 years.
But as a user of a barge if you needed wanted to use railways. Because they are faster. It would be the barge maker or a new train maker you would look at. Not the railway.
Just like canals X11 still exists. And is still being developed. It has its limitations but some applications are choosing not to port. Because like barge makers. They simply do not see the need. Or merit.
If the makers of railways insisted that all current users agents had to work on them without adaption. Many of the advantages would no longer be there.
Just as if waylaid did not expect Firefox et al to adapt to its methods. The security and other advantages they seek would not be practice.
Waylaid is a replacement. Not an upgrade.
(PS yeah living in the UK replace canal with inland waterways navigation. Tends to be how we think of it. As they are such a huge part of our industrial history. I forget the US really never went through that part of europeen industrial development. Your example is a fairly unique and modern by comparison, it dose not link to any network. Where as the inland waterways accross the UK and parts of Europe were a linked inferstructure like our railways. When the railways in Europe were built. They were very much seen as a replacement to our existing canal system. By both the corperations set up to build the inferstructure and the media of the time. It is literally a part of our industrial history thought is schools here. As so much of our culture and industrial revolution is built around the events)
Seems like you’re annoyed that I pointed out that what you were saying was irrelevant? And so you reply with more irrelevant crap (on a very nerdy, not-fun-at-parties internet forum for Linux discussion)? Let me know if I got that wrong.
If you’re doing it for the memes then you don’t really need to worry about malware. Your machine is probably too old for anything that’s still floating out there to even work on it.
Many people browse 4-5 pages a day, see a few emails, print a few pdfs, and a core2duo, or x4, for 40#/$/Eu a box run flawlessly with linux and xfce/lxde for example.
Even video-conferencing works fine.
Driver code is still there, you can add it back if you want, same with ide drivers and such, support was removed but code still exists, just add it and compile your own kernel, there are alot of tutorials in internet about it
The drivers were removed in 6.3. Debian 12 is still running on 6.1. Debian 12 just came out and still has many years of support ahead of it (at least 5). You can get plenty of use out of these cards before they stop working.
Someone needs to maintain them for them to keep working. Nobody else is willing to do that anymore, but you can still volunteer as a maintainer. If you don’t, it’s as much your fault as anyone elses.
after more than 25 years using linux I could not care less about those dramas, when my distro will drop xorg I’ll switch and that’s it. I’ve got way too much stuff to implement myself already, there is no time for that. I mean, I’ve even embraced systemd…
sorry, my rhetorical question was obviously intended as why I should bother. I don’t see any value in stopping you doing whatever you think is better for you, in fact it is exactly what annoys me the most :)
Well Xorg is pretty much unmaintained and is on its death bed. Modern hardware and software are slowly favoring Wayland due to it being much simpler by design.
To provide features that Xorg can't.
If you don't need features like fractional scaling, VRR, touchscreen gestures, etc. you won't notice a difference.
People who do use those, will. Because for them, those features would be missing or not complete on Xorg.
mmmh, I bet I will not notice any difference also if I don’t do shit and keep whatever is working until the day I’ll have to switch because my distro drops the packages 🤷🏼
I wish that was my experience, but Nvidia drivers on KDE Wayland have had a lot of oddities and issues that have caused me to go back to Xorg every time I’ve tried (12 times and counting). Wayland is a good move in the right direction, and I look forward to it, but it’s still being implemented.
Oh absolutely, this isn’t to say “Wayland bad”, it’s just to say that a large number of people may not have a smooth transition, so it’s hard to say “just do it”
It was a birthday gift from my wife, and lets not alienate people who don’t know computer hardware very well and pick up something from Best Buy. I agree that Nvidia sucks, and many of the issues are indeed their fault, but we also can’t neglect the fact that they own the vast majority of the market.
I’ve been a Linux user since the 90s, and nvidia has been a problem as long as I can remember. The wayland issues are just a new chapter in a long saga. ATI used to be the same, but they came around after having been bought by AMD.
If you’re already planning to use Linux on something a quick search will directly tell you that nvidia is a problem. If you got the hardware before nvidia that sucks - but again, it’s nvidias fault.
I think we absolutely should neglect nvidias market share, and just fully drop support for nvidia cards - either they’ll get pressured by angry users to no longer behave like dicks, or they keep doing it, and people will only make the mistake of buying nvidia once (or not use Linux) - either way, we’ll have gotten rid of a massive headache.
Running AMD/AMD right now for cpu/gfx, and I’m happy with my gaming laptop (and it’s price point).
Linux support and general support of open source was amajor factor in my decision. Intel is also really good on the CPU front, but I want to support AMD for its ooen source and speedy graphics offerings.
Also quite important to make sure we don’t have just a single strong x86 vendor - even though currently looking at price/performance you’d almost always go for AMD.
The time before ryzen was horrible - a 4-core-CPU was considered high end, and if you needed something more you needed to go for ridiculously overpriced Xeons. Similar for servers - you could get slightly higher core counts there, but when going for more than 8 cores it’d also get expensive very quickly.
Now we’re talking about 16 cores in high end notebook, and 64 cores in still reasonably priced pro workstations.
Eventually people will have to get new hardware. That’s the moment to avoid nVidia, that’s how simple this can be.
Also, the problem is nVidia giving shitty Wayland support, not Wayland providing no nVidia support. It’s nVidia who has to write the drivers since they themselves opted to keep their implementation details a secret. There’s nothing the Wayland people can do except plea, beg and shame. If nVidia then decide not to care, then I say fuck them.
Not supporting Nvidia cards will make Wayland unusable for at least half the Linux desktop users, probably more. Stats I recall range from 50-75%.
“Just buy non-Nvidia” is not, I repeat, a simple option. Lots of people stick with old GPU models because the price/performance ratio has gone out the window and they cannot afford to drop hundreds or thousands on one. Many others have Nvidia in their laptops.
There’s nothing preventing Wayland from working with Nvidia except the political insistence that it be open sourced. Which Nvidia is not interested in, never was, and never will be. And it’s a red herring to begin with.
TLDR either Wayland bends their stance on open source or their adoption will be severely limited.
Nvidia will feel enough pressure (likely from the ML / HPC space?) to provide open kernelspace support that they’ll actually make that happen.
Which… Has already happened.
Nvidia took a lot of the kernelspace logic that used to be in their proprietary driver, re-architected their GPUs to move that logic into a firmware blob (GSP).
And last year they released a completely Free driver that intefaces with GSP.
This allowed Nouveau developers to finally access critical features like power management (which were basically behind a wall of DRM, as Nvidia used legal and technical measures to lock Nouveau out of their firmware).
Now Nouveau has a new shader compiler, Vulcan support is growing rapidly, and people like me will soon prefer the Mesa stack for Nvidia over Nvidia’s own drivers.
And you can bet that Nouveau will work great with all of the Wayland compositors.
This is really the exact wrong point in history to be making the argument you’re trying to make 🤣.
Wow you got that backwards. They don’t do any of that for the sake of Nouveau or Vulkan or Wayland or whatever. They don’t care what people use their open scraps for.
They open up the minimum they can get away with because it’s ultimately meaningless — their proprietary stuff is still hidden away and it’s not like you can use the parts they open with anything else.
This, btw, applies to AMD and Intel too. The only choice you get with proprietary hardware that you have to use (like GPUs) is whose dick you want to suck. They’re not your friend and they won’t let community pressure then into decisions.
Wayland has fixed so many head-scratching issues I would get running 6 monitors on 2 GPUs under X11. I’d often end up with missing monitors, placed in wrong spots that I’d have to rearrange every reboot until an update would come through that would fix it again for a few months, then all over again.
Since I moved to wayland, everything just works. When it doesn’t, it’s not a display server issue, it’s something physical. I just had a couple monitors fail to show up and thought “oh hell, it’s back to this, eh”. But I open the tower, seat the offending GPU better, and everything comes up like normal, and all the screens are in the right position, it just remembers.
Anyone that thinks X11 is still superior probably runs on a laptop with a single screen.
I mean I’m fully with you on the fact screen autodetect isn’t stellar on X but there’s no need to exaggerate with “2 or 3 scripts”. It’s one xrandr command.
Ive seen several devs do that, and also some of my gaming friends have 3 monitors.
I barely know anyone who only has a single display. Most people I know have one high refresh rate monitor, and one office monitor for discord and the likes.
I have 2 75hz and a 240hz. It’s been alright for me on kde and x11. Although, I do want to give this Wayland thing a shot after hearing it being brought up so many times
Over on Nate's other blog entry he indicates this:
The fundamental X11 development model was to have a heavyweight window server–called Xorg–which would handle everything, and everyone would use it. Well, in theory there could be others, and at various points in time there were, but in practice writing a new one that isn’t a fork of an old one is nearly impossible
And I think this is something people tend to forget. X11 as a protocol is complex and writing an implementation of it is difficult to say the least. Because of this, we've all kind of relied on Xorg's implementation of it and things like KDE and GNOME piggyback on top of that. However, nothing (outside of the pure complexity) prevented KWin (just as an example) implementing it's own X server. KWin having it's own X server would give it specific things that would better handle the things KWin specifically needed.
Good parallel is how crazy insane the HTML5 spec has become and how now pretty much only Google can write a browser for that spec (with thankfully Firefox also keeping up) and everyone is just cloning that browser and putting their specific spin to it. But if a deep enough core change happens, that's likely to find its way into all of the spins. And that was some of the issue with X. Good example here, because of the specific way X works an "OK" button (as an example) is actually implemented by your toolkit as a child window. Menus those are windows too. In fact pretty much no toolkit uses primitives anymore. It's all windows with lots and lots of text attributes. And your toolkit Qt, Gtk, WINGs, EFL, etc handle all those attributes so that events like "clicking a mouse button" work like had you clicked a button and not a window that's drawn to look like a button.
That's all because these toolkits want to do things that X won't explicitly allow them to do. Now the various DEs can just write an X server that has their concept of what a button should do, how it should look, etc... And that would work except that, say you fire up GIMP that uses Gtk and Gtk has it's idea of how that widget should look and work and boom things break with the KDE X server. That's because of the way X11 is defined. There's this middle man that always sits there dictating how things work. Clients draw to you, not to the screen in X. And that's fundamentally how X and Wayland are different.
I think people think of Wayland in the same way of X11. That there's this Xorg that exists and we'll all be using it and configuring it. And that's not wholly true. In X we have the X server and in that department we had Xorg/XFree86 (and some other minor bit players). The analog for that in Wayland (roughly, because Wayland ≠ X) is the Compositor. Of which we have Mutter, Clayland, KWin, Weston, Enlightenment, and so on. Which that's more than just one that we're used to. That's because the Wayland protocol is simple enough for these multiple implementations.
The skinny is that a Compositor needs to at the very least provide these:
wl_display - This is the protocol itself.
wl_registry - A place to register objects that come into the compositor.
wl_surface - A place for things to draw.
wl_buffer - When those things draw there should be one of these for them to pack the data into.
wl_output - Where rubber hits the road pretty much, wl_surface should display wl_buffer onto this thing.
wl_keyboard/wl_touch/etc - The things that will interact with the other things.
wl_seat - The bringing together of the above into something a human being is interacting with.
And that's about it. The specifics of how to interface with hardware and what not is mostly left to the kernel. In fact, pretty much compositors are just doing everything in EGL, that is KWin's wl_buffer (just random example here) is a eglCreatePbufferSurface with other stuff specific to what KWin needs and that's it. I would assume Mutter is pretty much the same case here. This gets a ton of the formality stuff that X11 required out of the way and allows Compositors more direct access to the underlying hardware. Which was pretty much the case for all of the Window Managers since 2010ish. All of them basically Window Manage in OpenGL because OpenGL allowed them to skip a lot of X, but of course there is GLX (that one bit where X and OpenGL cross) but that's so much better than dealing with Xlib and everything it requires that would routinely require "creative" workarounds.
This is what's great about Wayland, it allows KWin to focus on what KWin needs, mutter to focus on what mutter needs, but provides enough generic interface that Qt applications will show up on mutter just fine. Wayland goes out of its way to get out of the way. BUT that means things we've enjoyed previously aren't there, like clipboards, screen recording, etc. Because X dictated those things and for Wayland, that's outside of scope.
That’s my problem with this. It tries to be a desktop display server protocol without unifying all desktop requirements. Sure, X11 is old and have unnecessary things that aren’t relevant anymore, however, as someone who builds their own DE, (e.g.: tiling window managers) I see it as the end of this masterrace. Unless everybody moves to wlroots. Flameshot, for example, is already dealing with this, having at least 5 implementations only for linux, and only wlroots and x11 are standards.
Also, imo, having windows in windows is useful when you want to use your favourite terminal in your favourite IDE. But as you said DEs can implement it simply. Let’s say wlroots will implement this but others can decide otherwise. And for those the app won’t run.
Another example, that affects my app personally, is the ability to query which monitor is the pointer at. Wayland doesn’t care having these so I doesn’t care supporting wayland. And I"m being sad about this because X is slowly fading away so new apps will not run on my desktop.
Moreover with X11 I could write my own hotkey daemon in my lanuage of choice, now I would have to fork the compositor.
Also, imo, having windows in windows is useful when you want to use your favourite terminal in your favourite IDE.
The wayland way to do that is to have the application be a compositor, they made sure that nesting introduces only minimal overhead. And that ties in with the base protocol being so simple: If you only need to deal with talking to the compositor you’re running on, and to the client that you want to embed, a wayland compositor is indeed very small and lean. Much of the codebase in the big compositors deals with kms, multiple monitor support, complex windowing logic that you don’t need, etc.
Oh and just for the record that doesn’t mean that you can’t undock the terminal: Just ask the compositor you’re running on for a second window and compose it there. You can in principle even reparent (client disconnecting from one compositor and connecting to the other) but I think that’s only standardised for the crash case there’s no standard protocol to ask a client to connect to another compositor. Just need to standardise the negotiation protocol, not the mechanism.
woops my bad, I mean to link this github.com/…/wayland-x11-compat-protocols it’s a repo of going to be protocols, to fill in the gap instead of pretending the issue doesn’t exist
I did and quite frankly it’s trash, XDG portals are a clunky and quite frankly terrible and poorly thought out api. I’m not the only one that disagrees with this sentiment as multiple people are trying to get protocols like ext-screencopy-v1 for screen recording and ext-foreign-toplevel-* for window management upstreamed into wayland so that xdg portals aren’t necessary for these use cases. I don’t mind the reliance on pipewire too much, but I too think that It shouldn’t be necessary for screen capture.
IMO It is one of nate’s worst takes of all time if not the worst. Usually I agree with most things he writes, but not this, xdg-portals is a travesty, pipewire is nice and all, but I don’t see why we should need an entire media system for basic screen capture capabilities. and clearly im not alone on this sentiment
And that’ll shake out in the time it takes for X11 to go away. I get what you’re saying, although I don’t share your opinion about portals from a user perspective: I’m just happy that Firefox finally uses the Plasma file picker.
I have a couple of issues with portals. One is that we’re putting too much eggs in the basket of something that is designed for containers. XDG portals Have rejected features that people have requested because they don’t want to expose that functionality to a container and they are allergic to permission prompts apparently.
I also have other issues with the portals for instance video capture. It requires you to have a camera portal. It requires you to have a desktop capture portal. It also requires you to have an app to app, video, portal, which doesn’t exist yet. All of these things require pipewire pretty much in most cases, so why can’t we just have a single pipewire portal? It may not scale well in the future, but it doesn’t scale well now anyways. If you want just a generic pipe wire stream, you’re not gonna be able to have it, you’re going to have to conform to one of the standards anyways. For a case in point example, the OBS pull request for Game Scope Capture is the perfect example of this over reliance in XDG portals.
I’m showcasing this just to highlight the fact that the XDG portals are incredibly poorly thought out, and I don’t think that it’s a reliable method for the future going forwards.
PS. Please pardon any oddities in this, I had to use speech to text, since my RSI is acting up.
I think having separate standard APIs for screenshots, screen capture, and video capture that aren’t married to one implementation makes sense.
I partially agree about the focus on containers/sandboxes. Yes, it makes sense to criticize that something designed for a different use case results in different trade-offs. But on the other hand, are the use cases really that different? We’re talking about standalone desktop apps, they need some common building blocks no matter if they’re containerized or not, right?
Otherwise I don’t know enough about the standards to comment there, you’re probably right!
I think having separate standard APIs for screenshots, screen capture, and video capture that aren’t married to one implementation makes sense.
The idea of a using a separate thing for it is fine, in itself, but necessitating it is an issue to me. There are a LOT of wayland compositors now, for all sorts of systems, each one also new needs a compatible xdg portals implementation (or whatever third party tool you like), in the case of xdg portals this also means pulling in things like dbus. It actually becomes a lot to build a “Minimal but fledged out” ecosystem. something which should otherwise be possible.
we’re talking about standalone desktop apps, they need some common building blocks no matter if they’re containerized or not, right?
sure but then you have xdg-portals denying actually useful a11y protocols because they “don’t want to expose it to containers” -_- apparently they never heard of a permissions system? but this also highlights why the wayland ecosystem right now is so poor for select individuals (and why they get heated when told that they need to swap to wayland)
This is the big thing that all these Nvidia comments miss. It’s not up to Wayland to support a given GPU. Nvidia is actively hostile to Linux users. If you aren’t making money with cuda there are zero reasons to choose Nvidia on a Linux machine over the competition. I’ve been on Wayland for almost a decade now and there’s no way I’m going back to X at this point.
FWIW, I’m typing this on the latest GNOME, on wayland, on nvidia proprietary drivers; and it works just fine — EXCEPT for suspend & resume, which is annoying to be sure; but on 2 screens with different refresh rates & different dpi ratios I at least don’t run into some of the weird behavior I do run into using X11.
I used to be an Xfce purist; but this particular setup is even less taxing on the GPU (GTX 970) compared to Xfce’s standard compositor (around 20W on light usage, vs. 35+W); & and the font rendering is slighly better, which is a huge factor AFAIC.
Anecdote, I know, but for my use cases, Wayland just isn’t there yet- I wind up with far more random bugs and less battery life. I don’t pretend to know why, I’m a pleb non-developer, but until that’s resolved I’m still stuck on X. I’d love to use the new shiny thing of The Future™, but not at the cost of stability and usability.
I think that given how frequently this argument is brought up (and it is of course true about it not being completely there yet) so this is just my opinion on the situation (and I am not a dev so I am fine with being wrong and corrected). It is kind of needed for more projects/distros to start actively using it. As a lot of the stuff kind of needs the band-aid ripped off to start forcing it to get there faster at this point. Otherwise it just keeps being held back as people on the coding end of things will keep focusing on X11 issues instead of getting things ready for Wayland.
Kind of like the conundrum of mobile OSes that aren’t Android or iOS. It is hard to get people/companies to even try the new OS because the lack of apps (specifically the most common ones used by the most people). But app devs don’t want to spend time re-building or starting new apps for an OS that isn’t being used (or on devices people are buying). So at a certain point it needs both sides to interact and make progress. The OS needs the apps more at this point, and getting feedback and data from those devs makes it known where things are and aren’t working. But it is also true the devs for the apps might end up finding out the OS is actually easier to work with compared to what they have been doing/dealing with on Android/iOS.
Getting a replacement for X11 has been needed for a long time as the OSes and features keep needing something new to better work for how computers have advanced. And it isn’t something that many devs would want to take on given how easy it is to just use what is already known. Since Wayland has finally gotten to the point it is now, it is time for more devs to start learning/moving to the new thing to get attention to the stuff that they need. The hardest part is this in between period for users as it can and will cause random issues (like the ones you have seen). Stability is important, but Linux is great because there will always be distros and projects that keeping the old thing running well is the main objective. So we are in some great times for the new to be pushed hard so it can become the stable future needed.
Been trying to think of a term for this issue. It’s not quite chicken or egg. But both sides need the other side to incentivize them. If one gets going the other will follow, but they’re waiting for each other. Like some sort of collaborative standoff.
You will never be a real display server. You have no hardware cursors, you have no xrandr, you have no setxkbmap. You are a toy project twisted by Red Hat and GNOME into a crude mockery of X11’s perfection.
All the “validation” you get is two-faced and half-hearted. Behind your back people mock you. Your developers are disgusted and ashamed of you, your “users” laugh at your lack of features behind closed doors.
Linux users are utterly repulsed by you. Thousands of years of evolution have allowed them to sniff out defective software with incredible efficiency. Even Wayland sessions that “work” look uncanny and unnatural to a seasoned sysadmin. Your bizarre render loop is a dead giveaway. And even if you manage to get a drunk Arch user home with you, he’ll turn tail and bolt the second he gets a whiff of your high latency due to forced VSync.
You will never be happy. You wrench out a fake smile every single morning and tell yourself it’s going to be ok, but deep inside you feel the technical debt creeping up like a weed, ready to crush you under the unbearable weight.
Eventually it’ll be too much to bear - you’ll log into the GitLab instance, select the project, press Delete, and plunge it into the cold abyss. Your users will find the deletion notice, heartbroken but relieved that they no longer have to live with the unbearable shame and disappointment. They’ll remember you as the biggest failure of open source development, and every passerby for the rest of eternity will know a badly run project has failed there. Your code will decay and go to historical archives, and all that will remain of your legacy is a codebase that is unmistakably poorly written.
This is your fate. This is what you chose. There is no turning back.
phoronix.com
Active