Wayback 0.3 released
Uncategorized
17
Posts
6
Posters
0
Views
-
Wayback 0.3 released
Wayback, the tool that will allow you to run a legacy X11 desktop environment on top of Wayland, released a new version just before the Christmas. Wayback 0.3 overhauls its custom command line option parser to allow for more X.org options to be supported, and its manual pages have been cleaned up. Other fixes merely include fixing some small typos and similar small changes. Wayback is now also
-
Wayback 0.3 released
Wayback, the tool that will allow you to run a legacy X11 desktop environment on top of Wayland, released a new version just before the Christmas. Wayback 0.3 overhauls its custom command line option parser to allow for more X.org options to be supported, and its manual pages have been cleaned up. Other fixes merely include fixing some small typos and similar small changes. Wayback is now also
@mcc You're much more knowledgeable on graphics stacks than I am - may I ask about your current take on the Wayland/X11 transition?
My own background is that of a lapsed but recently returned Linux desktop user, gamer and occasional streamer, who is kinda rooting for the maturation of the newer tech, sure, but also low-key baffled by the remaining number of issues.
(Not trying to start anything or asking you to defend stuff, just curious about your two cents on this field of FOSS evolution.)
-
@mcc You're much more knowledgeable on graphics stacks than I am - may I ask about your current take on the Wayland/X11 transition?
My own background is that of a lapsed but recently returned Linux desktop user, gamer and occasional streamer, who is kinda rooting for the maturation of the newer tech, sure, but also low-key baffled by the remaining number of issues.
(Not trying to start anything or asking you to defend stuff, just curious about your two cents on this field of FOSS evolution.)
(1) The Wayland transition is unavoidable. X11 can't any longer be maintained: Nobody *wants* to maintain X11, and there's no mechanism to *force* anyone to maintain X11. X11 is a contract with GPU manufacturers and new GPUs are made all the time, so you can't just stick with what you have.
(2) The Wayland transition probably couldn't have been delayed, at least not much, because I don't know where the resources to maintain both stacks in parallel much longer would have come with.
-
(1) The Wayland transition is unavoidable. X11 can't any longer be maintained: Nobody *wants* to maintain X11, and there's no mechanism to *force* anyone to maintain X11. X11 is a contract with GPU manufacturers and new GPUs are made all the time, so you can't just stick with what you have.
(2) The Wayland transition probably couldn't have been delayed, at least not much, because I don't know where the resources to maintain both stacks in parallel much longer would have come with.
(3) The Wayland transition was very disappointing. Needs from user groups as varied as (a) fractional-DPI laptop owners, (b) disabled users, (c) graphics apps managing floating palettes !! Were not considered early enough or thoughtfully enough. I don't see hard evidence there's a timeline for addressing them now.. I would call this a failure. But I need to be clear the failure was neither the decision to go Wayland, or the decision to do it now. It was a failure to plan ahead.
-
(3) The Wayland transition was very disappointing. Needs from user groups as varied as (a) fractional-DPI laptop owners, (b) disabled users, (c) graphics apps managing floating palettes !! Were not considered early enough or thoughtfully enough. I don't see hard evidence there's a timeline for addressing them now.. I would call this a failure. But I need to be clear the failure was neither the decision to go Wayland, or the decision to do it now. It was a failure to plan ahead.
(4) Going forward, here is the problem that concerns me: Wayland withholds many capabilities apps had under X, reserving them for the compositor or extension designers. This would be fine if people could just pick the compositor with the features they need. But you don't get to pick your compositor because your compositor is bound to your DE. Your DE picks it. Compositors are fragmented, and fragmented in the way that holds back innovation rather than the way that promotes it.
-
(4) Going forward, here is the problem that concerns me: Wayland withholds many capabilities apps had under X, reserving them for the compositor or extension designers. This would be fine if people could just pick the compositor with the features they need. But you don't get to pick your compositor because your compositor is bound to your DE. Your DE picks it. Compositors are fragmented, and fragmented in the way that holds back innovation rather than the way that promotes it.
(4, contd) We need *some way* to give people the freedom to replace the compositor out from under the DE if they need a better feature set, so that extension innovation becomes possible. I may about to be say something incorrect, but I believe the problem here is GNOME. I *think* other DEs/WMs are ultimately based on wlroots, so wlroots-based compositors could be drop in replacements. But GNOME's Mutter is way more specialized. IDK how to work around that. We all switch to Cosmic? :(
-
(4, contd) We need *some way* to give people the freedom to replace the compositor out from under the DE if they need a better feature set, so that extension innovation becomes possible. I may about to be say something incorrect, but I believe the problem here is GNOME. I *think* other DEs/WMs are ultimately based on wlroots, so wlroots-based compositors could be drop in replacements. But GNOME's Mutter is way more specialized. IDK how to work around that. We all switch to Cosmic? :(
@mcc @glennseto i thought about this a few days ago—it might be fun to do a gnome-shell-ish compositor based on wlroots which can run gnome shell's javascript stuff as a regular wayland client, using wlr-layer-shell, instead of being baked into the compositor. then the top bar, dock and neat control panel and extensions could be shared with other desktops, while not being at the whim of mutter's rendering. i think there's no really well engineered bar+control panel thing outside gnome+kde.
-
(4, contd) We need *some way* to give people the freedom to replace the compositor out from under the DE if they need a better feature set, so that extension innovation becomes possible. I may about to be say something incorrect, but I believe the problem here is GNOME. I *think* other DEs/WMs are ultimately based on wlroots, so wlroots-based compositors could be drop in replacements. But GNOME's Mutter is way more specialized. IDK how to work around that. We all switch to Cosmic? :(
> We need *some way* to give people the freedom to replace the compositor out from under the DE if they need a better feature set, so that extension innovation becomes possible.
more than this, we need software that actually works by default. it's easy to get distracted by how technical people can tinker themselves out of this mess, but at the end of the day most users aren't hypernerds and couldn't give a toss about any of that. they just want their computer to let them work
-
@mcc @glennseto i thought about this a few days ago—it might be fun to do a gnome-shell-ish compositor based on wlroots which can run gnome shell's javascript stuff as a regular wayland client, using wlr-layer-shell, instead of being baked into the compositor. then the top bar, dock and neat control panel and extensions could be shared with other desktops, while not being at the whim of mutter's rendering. i think there's no really well engineered bar+control panel thing outside gnome+kde.
@mntmn @mcc @glennseto yeah i mean the architecture of gnome-shell is kinda terrifying broadly. like why is there javascript running in the compositor. why is dynamically switching to triple buffering to work around performance issues in javascript and rendering. in any of my head-canon work in the space i'd want to yeet gnome-shell out of the compositor, and have the compositor just do compositing robustly and fast. (broadly this is a core issue i have with wayland architecture anyway)
-
@mntmn @mcc @glennseto yeah i mean the architecture of gnome-shell is kinda terrifying broadly. like why is there javascript running in the compositor. why is dynamically switching to triple buffering to work around performance issues in javascript and rendering. in any of my head-canon work in the space i'd want to yeet gnome-shell out of the compositor, and have the compositor just do compositing robustly and fast. (broadly this is a core issue i have with wayland architecture anyway)
@dotstdy @mcc @glennseto yes, that is pretty terrifying. i don't think this architecture was intended by the people dreaming up wayland protocols. wayland seems pretty performance oriented to me
-
> We need *some way* to give people the freedom to replace the compositor out from under the DE if they need a better feature set, so that extension innovation becomes possible.
more than this, we need software that actually works by default. it's easy to get distracted by how technical people can tinker themselves out of this mess, but at the end of the day most users aren't hypernerds and couldn't give a toss about any of that. they just want their computer to let them work
@mcc @glennseto step 1 is the hypernerds tinkering themselves out of that mess. step 2 is a bunch of other hypernerds packaging that up as a ready-to-go solution. step 3 is now we have some half-baked solution that patched over a deficiency in what was available, but since it's the only frictionless way to do it right now that's what everyone does. repeat forever. oh whoops we're back with the X11 problem of immense techdebt.
-
@dotstdy @mcc @glennseto yes, that is pretty terrifying. i don't think this architecture was intended by the people dreaming up wayland protocols. wayland seems pretty performance oriented to me
@mntmn @mcc @glennseto it's part of wayland's core design to unify the compositor and the window manager. one could imagine they were thinking of a window manager / shell that wasn't written in javascript at the time, but i think i disagree with it either way. and you can see kde doing the work to undo the damage.
-
@mcc @glennseto step 1 is the hypernerds tinkering themselves out of that mess. step 2 is a bunch of other hypernerds packaging that up as a ready-to-go solution. step 3 is now we have some half-baked solution that patched over a deficiency in what was available, but since it's the only frictionless way to do it right now that's what everyone does. repeat forever. oh whoops we're back with the X11 problem of immense techdebt.
@gsuberland @glennseto it's so frustrating that *canonically*, like *according to the Linux hater's handbook*, the big mistake X11 made early was not standardizing enough in the base protocol and deferring everything to extensions. And then Wayland did the exact!! Same!! Thing!! how does an entire community make the same mistake TWICE
-
@gsuberland @glennseto it's so frustrating that *canonically*, like *according to the Linux hater's handbook*, the big mistake X11 made early was not standardizing enough in the base protocol and deferring everything to extensions. And then Wayland did the exact!! Same!! Thing!! how does an entire community make the same mistake TWICE
@gsuberland @glennseto I realize that having a core profile which lacks knowledge of things like windows and pixels and just configures u a Vulkan surface is useful for like VR headsets and car infotainment boxes, and that's something that should exist. But I would have expected then like. I don't know. A "desktop usage profile" set of standard extensions that a WM needs. Does that exist? Is that slated to exist? I am in the dark.
-
@gsuberland @glennseto I realize that having a core profile which lacks knowledge of things like windows and pixels and just configures u a Vulkan surface is useful for like VR headsets and car infotainment boxes, and that's something that should exist. But I would have expected then like. I don't know. A "desktop usage profile" set of standard extensions that a WM needs. Does that exist? Is that slated to exist? I am in the dark.
@mcc @gsuberland @glennseto no, it is not a thing, nor is it likely to become a thing. basically the position of the wayland committee such as it is, is that implementations should be free to do whatever they like, and that there's no binding power in wayland anyway. (which is why things like server-side-decorations aren't universally supported, as an example)
-
@mntmn @mcc @glennseto it's part of wayland's core design to unify the compositor and the window manager. one could imagine they were thinking of a window manager / shell that wasn't written in javascript at the time, but i think i disagree with it either way. and you can see kde doing the work to undo the damage.
@dotstdy @mntmn @glennseto unifying compositor with window manager is definitely unacceptable if the compositor also determines which features are available to apps.
i guess one question is whether the things KDE, GNOME, etc need to do their window-manager-y things could be pushed into an extension and then downstreamed from the compositor. I don't know how you get KDE, GNOME on board with that. But "no fundamental improvements unless KDE and GNOME agree" is hell. That is the W3C all over again
-
@mcc @gsuberland @glennseto no, it is not a thing, nor is it likely to become a thing. basically the position of the wayland committee such as it is, is that implementations should be free to do whatever they like, and that there's no binding power in wayland anyway. (which is why things like server-side-decorations aren't universally supported, as an example)
@dotstdy @gsuberland @glennseto maybe it shouldn't be the wayland committee's job tho, maybe it's freedesktop's.
-
undefined oblomov@sociale.network shared this topic on
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
Stai a vedere che adesso il governo italiano combinerà casini anche con le stampanti
-
-
@aeva yeah, they have "servers" now, some kind of low-to-mid level abstractions. The RenderingServer looks like I could work with it but I have found no guidance in how to use it in more advanced situations than the tutorials telling you to dispatch and immediately wait on GPU idle on that, which is, mmh
-
•
c u c ù..!
-
My God! Potevamo esplodere tutti! https://viacabane.wordpress.com/2013/07/28/umorismo-partigiano/
-
My shoes are barking.
Mi abbaia le scarpe.
-
Tra quei giovani credo ci fosse anche Italo Calvino https://viacabane.wordpress.com/2013/06/23/18/
-
Dall’archivio di Cassandra/ Pirati al cinema
Non si tratta di una recensione de il Forziere Fantasma ma di considerazioni molto più generali del rapporto tra cinema, passione del cinema, cultura del cinema e spot antipirateria prima della proiezione.
https://www.lealternative.net/2026/01/26/dallarchivio-di-cassandra-pirati-al-cinema/
