Think twice about Wayland. It breaks everything!

Wayland.md

Think twice before abandoning Xorg. Wayland breaks everything!

Hence, if you are interested in existing applications to "just work" without the need for adjustments, then you may be better off avoiding Wayland.

Wayland solves no issues I have but breaks almost everything I need. Even the most basic, most simple things (like xkill) - in this case with no obvious replacement. And usually it stays broken, because the Wayland folks mostly seem to care about Automotive, Gnome, maybe KDE - and alienating everyone else (e.g., people using just an X11 window manager or something like GNUstep) in the process.

Wayland proponents make it seem like Wayland is "the successor" of Xorg, when in fact it is not. It is merely an incompatible alternative, and not even one that has (nor wants to have) feature parity (missing features). And unlike X11 (the X Window System), Wayland protocol designers actively avoid the concept of "windows" (making up incomprehensible words like "xdg_toplevel" instead).

DO NOT USE A WAYLAND SESSION! Let Wayland not destroy everything and then have other people fix the damage it caused. Or force more Red Hat/Gnome components (glib, Portals, Pipewire) on everyone!

Please add more examples to the list.

Wayland seems to be made by people who do not care for existing software. They assume everyone is happy to either rewrite everything or to just use Gnome on Linux (rather than, say, twm with ROX Filer on NetBSD).

Edit: When I wrote the above, I didn't really realize what Wayland even was, I just noticed that some distributions (like Fedora) started pushing it onto me and things didn't work properly there. Today I realize that you can't "install Wayland", because unlike Xorg, there is not one "Wayland display server" but actually every desktop envrironment has its own. And maybe "the Wayland folks" don't "only care about Gnome", but then, any fix that is done in Gnome's Wayland implementation isn't automatically going to benefit all users of Wayland-based software, and possibly isn't even the implementation "the Wayland folks" would necessarily recommend.

Edit 12/2023: If something wants to replace X11 for desktop computers (such as professional Unix workstations), then it better support all needed features (and key concepts, like windows) for that use case. That people also have displays on their fridge doesn't matter the least bit in that context of discussion. Let's propose the missing Wayland protocols for full X11 feature parity.

Wayland is broken by design

• A crash in the window manager takes down all running applications
• You cannot run applications as root
• You cannot do a lot of things that you can do in Xorg by design
• There is not one /usr/bin/wayland display server application that is desktop environment agnostic and is used by everyone (unlike with Xorg)
• It offloads a lot of work to each and every window manager. As a result, the same basic features get implemented differently in different window managers, with different behaviors and bugs - so what works on desktop environment A does not necessarily work in desktop environment B (e.g., often you hear that something "works in Wayland", even though it only really works on Gnome and KDE, not in all Wayland implementations). This summarizes it very well: https://gitlab.freedesktop.org/wayland/wayland/-/issues/233

Apparently the Wayland project doesn't even want to be "X.org 2.0", and doesn't want to provide a commonly used implementation of a compositor that could be used by everyone: https://gitlab.freedesktop.org/wayland/wayland/-/issues/233. Yet this would imho be required if they want to make it into a worthwile "successor" that would have any chance of ever fixing the many Wayland issues at the core.

Wayland breaks screen recording applications

• MaartenBaert/ssr#431 ❌ broken since 24 Jan 2016, no resolution ("I guess they use a non-standard GNOME interface for this")
• https://github.com/mhsabbagh/green-recorder ❌ ("I am no longer interested in working with things like ffmpeg/wayland/GNOME's screencaster or solving the issues related to them or why they don't work")
• vkohaupt/vokoscreenNG#51 ❌ broken since at least 7 Mar 2020. ("I have now decided that there will be no Wayland support for the time being. Reason, there is no budget for it. Let's see how it looks in a year or two.") - This is the key problem. Wayland breaks everything and then expects others to fix the wreckage it caused on their own expense.
• obsproject/obs-studio#2471 ❌ broken since at least 7 Mar 2020. ("Wayland is unsupported at this time", "There isn't really something that can just be easily changed. Wayland provides no capture APIs")
• There is a workaround for OBS Studio that requires a obs-xdg-portal plugin (which is known to be Red Hat/Flatpak-centric, GNOME-centric, "perhaps" works with other desktops)
• phw/peek#1191 ❌ broken since 14 Jan 2023. Peek, a screen recording tool, has been abandoned by its developerdue to a number of technical challenges, mostly with Gtk and Wayland ("Many of these have to do with how Wayland changed the way applications are being handled")

As of February 2024, screen recording is still broken utterly on Wayland with the vast majority of tools. Proof

Workaround: Find a Wayland compositor that supports the wlr-screencopy-unstable-v1 protocol and use wf-recorder -a. The default compositor in Raspberry Pi OS (Wayfire) does, but the default compositor in Ubuntu doesn't. (That's the worst part of Wayland: Unlike with Xorg, it always depends on the particular Wayand compositor what works and what is broken. Is there even one that supports everything?)

Wayland breaks screen sharing applications

• jitsi/jitsi-meet#2350 ❌ broken since 3 Jan 2018
• jitsi/jitsi-meet#6389 ❌ broken since 24 Jan 2016 ("Closing since there is nothing we can do from the Jitsi Meet side.") See? Wayland breaks stuff and leaves application developers helpless and unable to fix the breakage, even if they wanted.

NOTE: As of November 2023, screen sharing in Chromium using Jitsi Meet is still utterly broken, both in Raspberry Pi OS Desktop, and in a KDE Plasma installation, albeit with different behavior. Note that Pipewire, Portals and whatnot are installed, and even with them it does not work.

• raspberrypi/bookworm-feedback#149 (comment) ❌ broken since at least Nov 17, 2023 ("window sharing not being available in wlroots derived compositors (such as wayfire)")
• flathub/us.zoom.Zoom#22 Zoom ❌ broken since at least 4 Jan 2019. ("Can not start share, we only support wayland on GNOME with Ubuntu (17, 18), Fedora (25 to 29), Debian 9, openSUSE Leap 15, Arch Linux"). No word about non-GNOME!
• https://community.zoom.com/t5/Meetings/Screensharing-only-works-on-GNOME-wayland-when-it-should-work-on/m-p/64823 Zoom ❌ Still broken as of 24 Jun 2022. ("... we only support Wayland on Gnome with Ubuntu 17 and above, Fedora 25 and above, Debian 9 and above ...")
• probonopd/Zoom.AppImage#8 ❌ broken since 1 Oct 2022 Zoom: "You need PulseAudio 1.0 and above to support audio share" on a system that uses pipewire-pulseaudio

Wayland breaks automation software

sudo pkg install py37-autokey

This is an X11 application, and as such will not function 100% on 
distributions that default to using Wayland instead of Xorg.

Wayland breaks Gnome-Global-AppMenu (global menus for Gnome)

• https://gitlab.com/lestcape/Gnome-Global-AppMenu/-/issues/116 ❌ broken since 24 Aug 2018 ("because the lack of the Gtk+ Wayland support for the Global Menu")

• https://bugs.kde.org/show_bug.cgi?id=424485 ❌ Still broken as of late 2023 ("I am also still not seeing GTK global menus on wayland. They appear on the applications themselves, wasting a lot of space.")

Wayland broke global menus with KDE platformplugin

• https://blog.broulik.de/2016/10/global-menus-returning/ ("it uses global window IDs, which don’t exist in a Wayland world... no global menu on Wayland, I thought, not without significant re-engineering effort"). KDE had to do additional work to work around it. And it still did not work:

• https://bugs.kde.org/show_bug.cgi?id=385880 ("When using the Plasma-Wayland session, the global menu does not work.")

Good news: According to this report global menus now work with KDE platformplugin as of 4/2022

Wayland breaks global menus with non-KDE Qt platformplugins

• https://blog.broulik.de/2016/10/global-menus-returning/ ❌ broke non-KDE platformplugins. As a result, global menus now need _KDE_NET_WM_APPMENU_OBJECT_PATH which only the KDE platformplugin sets, leaving everyone else in the dark

Wayland breaks AppImages that don't ship a special Wayland Qt plugin

• https://blog.martin-graesslin.com/blog/2018/03/unsetting-qt_qpa_platform-environment-variable-by-default/ ❌ broke AppImages that don't ship a special Wayland Qt plugin. "This affects proprietary applications, FLOSS applications bundled as appimages, FLOSS applications bundled as flatpaks and not distributed by KDE and even the Qt installer itself. In my opinion this is a showstopper for running a Wayland session." However, there is a workaround: "AppImages which ship just the XCB plugin will automatically fallback to running in xwayland mode" (see below).

Wayland breaks Redshift

• https://wiki.archlinux.org/index.php/redshift ❌ broken ("Redshift does not support Wayland since it offers no way to adjust the color temperature")

Update 2023: Some Wayland compositors (such as Wayfire) now support wlr_gamma_control_unstable_v1, see https://github.com/WayfireWM/wayfire/wiki/Tutorial#configuring-wayfire and jonls/redshift#663. Does it work in all Wayland compositors though?

Wayland breaks global hotkeys

• albertlauncher/albert#309 ❌ broken since 7 Jan 2017 ("This is a security measure, but has the side effect of preventing applications from registering their own global hotkeys") YouTube video by René Rebe

Wayland does not work for Xfce?

See below.

Wayland does not work properly on NVidia hardware?

Apparently Wayland relies on nouveau drivers for NVidia hardware. The nouveau driver has been giving unsatisfactory performance since its inception. Even clicking on the application starter icon in Gnome results in a stuttery animation. Only the proprietary NVidia driver results in full performance.

See below.

Update 2024: The situation might slowly be improving. It remains to be seen whether this will work well also for all existing old Nvidia hardware (that works well in Xorg).

Wayland does not work properly on Intel hardware

• https://cfenollosa.com/blog/fed-up-with-the-mac-i-spent-six-months-with-a-linux-laptop-the-grass-is-not-greener-on-the-other-side.html ❌ broken since at least 02 Apr 2021 ("Screen tearing with the intel driver. Come on. This was solved on xorg and now with Wayland it's back.")

Wayland prevents GUI applications from running as root

• https://bugzilla.redhat.com/show_bug.cgi?id=1274451 ❌ broken since 22 Oct 2015 ("No this will only fix sudo for X11 applications. Running GUI code as root is still a bad idea." I absolutely detest it when software tries to prevent me from doing what some developer thinks is "a bad idea" but did not consider my use case, e.g., running truss for debugging on FreeBSD needs to run the application as root. https://bugzilla.mozilla.org/show_bug.cgi?id=1323302 suggests it is not possible: "These sorts of security considerations are very much the way that "the Linux desktop" is going these days".)

Suggested solution

Wayland is biased toward Linux and breaks BSD

• https://blog.netbsd.org/tnf/entry/wayland_on_netbsd_trials_and ❌ broken since 28 Sep 2020 ("Wayland is written with the assumption of Linux to the extent that every client application tends to #include <linux/input.h> because Wayland's designers didn't see the need to define a OS-neutral way to get mouse button IDs. (...) In general, Wayland is moving away from the modularity, portability, and standardization of the X server. (...) I've decided to take a break from this, since it's a fairly huge undertaking and uphill battle. Right now, X11 combined with a compositor like picom or xcompmgr is the more mature option."

Wayland complicates server-side window decorations

• https://blog.martin-graesslin.com/blog/2018/01/server-side-decorations-and-wayland/ ❌ FUD since at least 27 January 2018 ("I heard that GNOME is currently trying to lobby for all applications implementing client-side decorations. One of the arguments seems to be that CSD is a must on Wayland. " ... "I’m burnt from it and are not interested in it any more.") Server-side window decorations are what make the title bar and buttons of all windows on a system consistent. They are a must have_ for a consistent system, so that applications written e.g., Gtk will not look entirely alien on e.g., a Qt based desktop, and to enforce that developers cannot place random controls into window titles where they do not belong. Client-side decorations, on the other hand, are destroying uniformity and consistency, put additional burden on application and toolkit developers, and allow e.g., GNOME developers to put random controls (that do not belong there) into window titles (like buttons), hence making it more difficult to achieve a uniform look and feel for all applications regardless of the toolkit being used.

Red Hat employee Matthias Clasen ("I work at the Red Hat Desktop team... I am actually a manager there... the people who do the actual work work for me") expicitly stated "Client-side everything" as a principle, even though the protocol doesn't enforce it: "Fonts, Rendering, Nested Windows, Decorations. "It also gives the design more freedom to use the titlebar space, which is something our designers appreciate" (sic). Source

Wayland breaks windows rasing/activating themselves

• https://phabricator.kde.org/D16648#470609 ("Wayland clients can't raise or activate themselves"), ❌ broken since May 27 2019

Wayland breaks RescueTime

• https://help.rescuetime.com/article/117-common-linux-issues ("One of the features of Wayland is that it prevents apps from doing precisely what RescueTime is trying to do—track activity in other windows.") ❌ broken since June 3, 2021

Wayland breaks window managers

Apparently Wayland (at least as implemented in KWin) does not respect EWMH protocols, and breaks other command line tools like wmctrl, xrandr, xprop, etc. Please see the discussion below for details.

Wayland requires JWM, TWM, XDM, IceWM,... to reimplement Xorg-like functionality

• https://gitlab.freedesktop.org/wayland/wayland/-/issues/233

• Screen recording and casting
• Querying of the mouse position, keyboard LED state, active window position or name, moving windows (xdotool, wmctrl)
• Global shortcuts
• System tray
• Input Method support/editor (IME)
• Graphical settings management (i.e. tools like xranrd)
• Fast user switching/multiple graphical sessions
• Session configuration including but not limited to 1) input devices 2) monitors configuration including refresh rate / resolution / scaling / rotation and power saving 3) global shortcuts
• HDR/deep color support
• VRR (variable refresh rate)
• Disabling input devices (xinput alternative)

As it currently stands minor WMs and DEs do not even intend to support Wayland given the sheer complexity of writing all the code required to support the above features. You do not expect JWM, TWM, XDM or even IceWM developers to implement all the featured outlined in ^1.

Wayland breaks _NET_WM_STATE_SKIP_TASKBAR protocol

• https://github.comelectron/electron#33226 ("skipTaskbar has no effect on Wayland. Currently Electron uses _NET_WM_STATE_SKIP_TASKBAR to tell the WM to hide an app from the taskbar, and this works fine on X11 but there's no equivalent mechanism in Wayland." Workarounds are only available for some desktops including GNOME and KDE Plasma.) ❌ broken since March 10, 2022

Wayland breaks NoMachine NX

• https://kb.nomachine.com/TR03S10126?s=wayland ❌ broken since 2021-03-09 ("The session becomes unresponsive once logged-in to the Wayland desktop")

Wayland breaks xclip

xclip is a command line utility that is designed to run on any system with an X11 implementation. It provides an interface to X selections ("the clipboard"). Apparently Wayland isn't compatible to the X11 clipboard either.

• AppImage/AppImageKit#1221 (comment) ❌ broken since 2022-20-15 ("Espanso built for X11 will not work on Wayland due to xclip. Wayland asks for wl-copy")

This is another example that the Wayland requires everyone to change components and take on additional work just because Wayland is incompatible to what we had working for all those years.

Wayland breaks SUDO_ASKPASS

• https://github.com/linuxhw/hw-probe-pyqt5-gui/commit/eb2d6e5145fb8571414bda57676084b7f13b94e5#diff-23cb15995f1502beebb38433bfa83204a5f45b376eaf88e2e41a0d8a1cd44722R290 ❌ broken since 2022-04-09 ("SUDO_ASKPASS doesn't work on Wayland currently, so piping the password")

Wayland breaks X11 atoms

X11 atoms can be used to store information on windows. For example, a file manager might store the path that the window represents in an X11 atom, so that it (and other applications) can know for which paths there are open file manager windows. Wayland is not compatible to X11 atoms, resulting in all software that relies on them to be broken until specifically ported to Wayland (which, in the case of legacy software, may well be never).

Possible workaround (to be verified): Use the (Qt proprietary?) Extended Surface Wayland protocol casually mentioned in https://blog.broulik.de/2016/10/global-menus-returning/ "which allows you to set (and read?) arbitrary properties on a window". Is it the set_generic_property from https://github.com/qt/qtwayland/blob/dev/src/extensions/surface-extension.xml?

Wayland breaks games

Games are developed for X11. And if you run a game on Wayland, performance is subpar due to things like forced vsync. Only recently, some Wayland implementations (like KDE KWin) let you disable that.

Wayland breaks xdotool

(Details to be added; apparently no 1:1 drop-in replacement available?)

Wayland breaks xkill

xkill (which I use on a regular basis) does not work with Wayland applications.

What is the equivalent for Wayland applications?

Wayland breaks screensavers

Is it true that Wayland also breaks screensavers? https://www.jwz.org/blog/2023/09/wayland-and-screen-savers/

Wayland breaks setting the window position

Other platforms (Windows, Mac, other destop environments) can set the window position on the screen, so all cross-platform toolkits and applications expect to do the same on Wayland, but Wayland can't (doesn't want to) do it.

• PCSX2/pcsx2#10179 PCX2 (Playstation 2 Emulator) ❌ broken since 2023-10-25 ("Disables Wayland, it's super broken/buggy in basically every scenario. KDE isn't too buggy, GNOME is a complete disaster.")

Wayland breaks color mangement

Apparently color management as of 2023 (well over a decade of Wayland development) is still in the early "thinking" stage, all the while Wayland is already being pushed on people as if it was a "X11 successor".

https://gitlab.freedesktop.org/pq/color-and-hdr/-/blob/main/doc/color-management-model.md

Wayland breaks DRM leasing

According to Valve, "DRM leasing is the process which allows SteamVR to take control of your VR headset's display in order to present low-latency VR content".

• "Unfortunately not all Wayland compositors support DRM leasing" https://help.steampowered.com/en/faqs/view/18A4-1E10-8A94-3DDA - "not all" highlights one of the fundamental problems with Wayland - there is fragmentation

Wayland breaks In-home Streaming

• ValveSoftware/steam-for-linux#6148 ❌ broken since 2019-03-17

Wayland breaks NetWM

Extended Window Manager Hints, a.k.a. NetWM, is an X Window System standard for the communication between window managers and applications

Wayland breaks window icons

• Wayland breaks window icons when no .desktop files are used: Seemingly Wayland requires developers to use the xdg-shell protocol, which in turn requires developers to use reverse-DNS application IDs and set_app_id, which causes the icon to be loaded from the .desktop file. This is serious breakage, as not all desktop environments (for good reasons) use .desktop files. A display server should have no business in this, as this belongs into the domain of the desktop environment. https://community.kde.org/Guidelines_and_HOWTOs/Wayland_Porting_Notes#Application_Icon, https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/52 ❌ broken since 2021-06-21

• Qt setWindowIcon has no effect on KDE/Wayland https://bugreports.qt.io/browse/QTBUG-101427 ("Resolution: Out of scope", meaning it cannot be fixed in Qt, "Using QT_QPA_PLATFORM=xcb works, though", meaning that if you disable Wayland then it works) ❌ broken since 2022-03-03

• LibrePCB developer: "Btw it's just one of several problems we have with Wayland, therefore we still enforce LibrePCB to run with XWayland. It's a shame, but I feel totally helpless against such decisions made by Wayland and using XWayland is the only reasonable option (which even works perfectly fine)..." https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/52#note_2155885

Wayland breaks drag and drop

• On Raspberry Pi OS (which is running a Wayland session by default), dragging a file out of a zip file onto the desktop fails with "XDirectSave failed."
• The same seems to be true in Gnome: https://discourse.gnome.org/t/xdnddirectsave-and-wayland/2954

Workarounds

• Users: Refuse to use Wayland sessions. Uninstall desktop environments/Linux distributions that only ship Wayland sessions. Avoid Wayland-only applications (such as PreSonus Studio One) (potential workaround: run in https://github.com/cage-kiosk/cage)
• Application developers: Enforce running applications on X11/XWayland (like LibrePCB does as of 11/2023)

Examples of Wayland being forced on users

This is exactly the kind of behavior this gist seeks to prevent.

• Asahi Linux enforces Wayland for ARM-based Macs: https://social.treehouse.systems/@marcan/110354541574112092
• Fedora enforces Wayland for KDE Plasma: https://fedoraproject.org/wiki/Changes/KDE_Plasma_6#Why_drop_the_X11_session_with_the_Plasma_6_upgrade?
• Red Hat enforces Wayland for RHEL:https://www.redhat.com/de/blog/rhel-10-plans-wayland-and-xorg-server

History

• 2008: Wayland was started by krh (while at Red Hat)
• End of 2012: Wayland 1.0
• Early 2013: GNOME begins Wayland porting

Source: "Where's Wayland?" by Matthias Clasen - Flock 2014

A decade later... Red Hat wants to force Wayland upon everyone, removing support for Xorg

References

• Dudemanguy's Musings, Wayland Isn't Going to Save The Linux Desktop
• Chris Titus Tech: Wayland vs Xorg https://www.youtube.com/watch?v=U_MBJcD3SFI
• tildearrow: did somebody say "anti-Wayland horseshit"?
• pcsx2: CI/Linux: Disable Wayland and spring cleaning
• Testing SCREEN RECORDERS on Linux Mint Wayland
• ProtonPenguin: Wayland Breaks Everything

I'd say Wayland just has teething issues. We just need to wait for it to grow its beard.

I'd say Wayland just has teething issues. We just need to wait for it to grow its beard.

Teething occurs around 1-2 years, not 15. ;)

It is.

As long as this egregious gaslighting liar is in this topic, I'm not going to post here ever again: I found widget.wayland.fractional-scale.enabled on my own. Period. And to make things worse this option does not result in Firefox working nearly as well as it works in X11 with a non-standard DPI. A basic feature of the modern desktop is outright broken for everyone who ventures to use fractional scaling in Wayland. Wayland is ready and I'm out.

Everyone? I guess I'm not included in everyone because I tried it and it worked. Then again it seems like everything works in Sway and KwinFT but not others...

https://www.youtube.com/watch?v=qkTUxHUc7PE

I've been using Wayland for 4 years and haven't had 99% of the issues listed here. You are all exaggerating everything. X11 has been broken for decades. I could write a book on the years of suffering i've gone through with screen tearing on Nvidia laptops because Vsync didn't actually sync the video buffer between the two GPUs, only between the integrated GPU and the screen.

X11 was a dumpsterfire since its inception. Who thought a single, hacked together crapware should be shared between like 10 different operating systems and 100 window managers?

@EternalPlanemo

I've been using Wayland for 4 years and haven't had 99% of the issues listed here. You are all exaggerating everything.

Another kiosk user.

X11 has been broken for decades. I could write a book on the years of suffering i've gone through with screen tearing on Nvidia laptops because Vsync didn't actually sync the video buffer between the two GPUs, only between the integrated GPU and the screen.

Are you talking about NVidia prime? What does this have to do with Xorg?

Who thought a single, hacked together crapware should be shared between like 10 different operating systems and 100 window managers?

Real engineers who know what unification and standards are and you should too.

Teething occurs around 1-2 years, not 15. ;)

These sort of committee things take a while. I do like what Arcan is doing, though.
But X11 sucks, and so does Wayland, but it's sucking less as time goes on.

Another kiosk user.

Yes, the well-known kiosks of... the ThinkPad x220, 2004 Dell Inspiron, and a Ryzen 7800X3D & RX 6600 desktop.

fwiw, wrt to redshift, the current version of gnome has working night light in wayland, and there's also a program called xwaylandvideobridge now that helps obs-studio work

@binex-dsk

Another kiosk user.

Yes, the well-known kiosks of... the ThinkPad x220, 2004 Dell Inspiron, and a Ryzen 7800X3D & RX 6600 desktop.

Yes, it's a shame to use a kiosk on such hardware.

Why form a coherent argument when you can use a strawman?

libsdl-org/SDL#9345
interesting news popped up. SDL reverts a commit that prefers wayland over x. some choice quotes:

Wayland has a myriad of unresolved problems regarding surface suspension blocking presentation and the FIFO (vsync) implementation being fundamentally broken leading to reduced GPU-bound performance.

There is no advantage to games and average applications preferring Wayland over X11 -- only severe performance and unusability regressions right now.

Thus, we must revert this change until fifo-v1 and commit-timing-v1 are released and at least in a stable release for major compositors.

fwiw, wrt to redshift, the current version of gnome has (...)

Thanks @andrewfader, you probably want to genuinely help by sharing this information, but unfortunately this is exactly the kind of answer that always drive me nuts. When people have issues with Wayland, "solutions" are offered that only work in certain desktops. Redshift on X11 works in a truly desktop environment agnostic way. Wayland tends to be a pain especially for those of us who are not running the 1-2 largest desktop environments.

And OP has recently discovered Wayfire is already a default in Raspberry Pi OS.

And it's broken like hell. For example, try to run the standalone Dexed exe using wine. Screen sharing is broken as well.

What's wrong with kiosks?

https://en.wikipedia.org/wiki/Kiosk,_Ontario

Wayland tends to be a pain especially for those of us who are not running the 1-2 largest desktop environments.

Sway is not a "desktop environment", yet every single one of the problems you listed here doesn't happen to me.

Well, Sway was specifically made for Wayland. Whereas the software we have been using for decades was made way before Wayland was a thing.

i3 was made specifically for X11. Openbox was made specifically for X11. DWM was made specifically for Windows (or X11 if we're talking about Suckmore's). Quartz was made specifically for macOS. LXDE/LXQT were made specifically for X11. What's your point?

@probonopd I get it. It's annoying. The ecosystem is fragmented and there are many actors who are acting on behalf of stakeholders or some political goal, not the user experience. Just look at nvidia, what a nightmare, but things have been better lately. I'm just trying to be helpful, not engage in a flamewar. I use Wayland despite the pain because I find it a lot more secure and stable, and support has been improving, so maybe someone finds this info helpful in their own quest. But in 2024 it is possible to solve a lot of problems and there are some advantages to doing so. Redshift alternatives - wlsunset, clight, gammarelay, gammastep are mentioned at https://wiki.archlinux.org/title/Backlight#Wayland - I do use Gnome, but I imagine hyprland or whatever else can take advantage of those if they use wlroots for compositing.

@binex-dsk my point is that virtually all software on "Desktop Linux" was made for X11. And we want to continue using that software without having to change it too much. I didn't ask for this Wayland thing to exist in the first place, much less for desktop environments nor Linux distributions to make it the default. From the perspective of a normal user, Wayland is splintering and hence destroying what was previously a more or less working platform. Writing this from a Windows machine.

@andrewfader a Nvidia user myself, I never had issues when using their drivers for X11 on Linux (or FreeBSD for that matter).

I am in no way affiliated with Nvidia. But if I were them, having invested tons of money into X11 drivers, I'd not be happy if the Wayland folks came along and rendered my investment useless, forcing me to rewrite stuff. Maintaining one driver for Linux is probably already only borderline profitable, much less two different ones. So from a business perspective I can understand them being hesitant about this whole Wayland thing.

@andrewfader

I get it. It's annoying. The ecosystem is fragmented and there are many actors who are acting on behalf of stakeholders or some political goal, not the user experience.

No, you don't. If you were, you wouldn't be using Wayland.

Why are overweight Reddit users like @Monsterovich so angry?

Yankee thinks everyone on this planet uses Reddit.

Yankee thinks everyone on this planet uses Reddit.

Lol, the people in this thread act like they do

Full ack. And Fedora, Gnome, Red Hat are usually the leaders when it comes to "hostile change". But this time KDE is also pushing for the (in my opinion premature) change, and even Cinnamon, Mate, and Xfce are working on Wayland. Hopefully they will not push it onto people until it is ready (which I expect no sooner than 5-10 years down the road). For the rest of us, there is GNUstep which as far as I know has no plans to go Wayland.

For the rest of us, there is GNUstep which as far as I know has no plans to go Wayland.

For the rest of us exists pure X.Org with no WMs which obviously also has no plans to go Wayland.

And we obviously need something like libdecor to force any X11 clients to allow modifying at least their geometry and z-order with no need in a window manager.

This would be the opposite to the Wayland's idea "only the compositor know how surfaces are positioned", in favour of "only clients know how they are positioned". Enjoy the minarchism!

As a Classic MacOS lover, you also should embrace the idea of ditching the preemptive multitasking. It has brought so many disasters, like crackling sound in PulseAudio and PipeWire, thrashing, 12309 and so. Cooperative multitasking is much better. I love when SheepShaver freezes completely because some app fails to release its time quantum to the system!

Full ack. And Fedora, Gnome, Red Hat are usually the leaders when it comes to "hostile change". But this time KDE is also pushing for the (in my opinion premature) change, and even Cinnamon, Mate, and Xfce are working on Wayland. Hopefully they will not push it onto people until it is ready (which I expect no sooner than 5-10 years down the road). For the rest of us, there is GNUstep which as far as I know has no plans to go Wayland.

At MATE, we are not interested in forcing anyone to use wayland. Rather, we are bringing up wayland support so no distro forces users to give up MATE by dumping x11. It was in fact reports of distros considering "sunsetting" x11 that caused me to take up this work.

Staying on old distro versions can become a real problem if you lose a system to electromigration, a power surge, or thieves. You can get another off the shelf motherboard and CPU in an hour, but they will be newer versions that may need at least a newer kernel. X11 or wayland, you may need a new mesa version too to go with newer graphics.

I have made MATE on wayfire my own default session, but that's to keep the issues in front of me as I am doing much of the wayland work. As I've said several times before, we will be there so long as you can get either x11 OR wayland from distros, no matter which way this goes. We are not betting anything on this competition's outcome.

no distro forces users to give up MATE by dumping x11

Debian did drop Compiz from the repos somewhere in mid-10s, and? Did it stop me from using it? no.

Staying on old distro versions can become a real problem if you lose a system to electromigration, a power surge, or thieves

VM.

Using a VM will cost performance (more code to run) and jack up your system requirement. An extreme example of this is the ultra-high security "qubes" distro that runs each toplevel app in a separate VM.This makes it hard for ANY app to harvest hardware information and just as hard for one app to spy on another.

Qubes is reputed among some of its users to be a mouthful, and sometimes too much for a small, high-portability laptop. At least 32GB of RAM recommended (16 required ) for instance due to so many VMs running at once. I did in fact manage to stuff that into a laptop that came w 4GB so I could edit 4K video on it

For the rest of us, there is GNUstep which as far as I know has no plans to go Wayland.

For the rest of us exists pure X.Org with no WMs which obviously also has no plans to go Wayland.

And if they decide to drop x11 support in the libraries like gtk and qt itself, is that even possible?

It would be GTK5 that drops x11 support in that case. Few non-GNOME programs have even gone to GTK4, we have no plans at MATE to do so. If this because a big enough problem, you might even see a "WaylandX" compatability layer to let wayland apps run in x11. That however can already be done, by nesting a wayland session inside an x11 session just like nesting X inside X. Done this myself when I was first getting wayfire up and running on my system.

like gtk and qt itself

Bloated and unusable anyway, even more with years.

Suckless software tends to avoid them and use pure Xft.

(@binex-dsk triggered in 3… 2… 1…)

It was in fact reports of distros considering "sunsetting" x11 that caused me to take up this work.

This gist partly exists in order to remind everyone, including distros, that "sunsetting" X11 anytime soon (i.e., in this decade) would be a very bad idea. I am not sure that everyone obediently jumping onto the Wayland bandwaggon is really helping (despite good intentions): It just makes it easier for distributions to go ahead with the "sunsetting". If many popular desktops don't offer Wayland yet (because it doesn't have what it needs yet), then it is harder for distributions (who want to keep the users of said desktops) to jump ship.

So what is an actual solution to this?

If I had to make a plan on how to make Wayland viable, I'd:

1. Stop positioning Wayland as an X11 successor. Position it as what it is, an incompatible alternative instead. Acknowledge that it will live alongside X11 for decades to come.
2. Do not assume that all existing software (still) has developers who are interested in further developing it, just because there now is Wayland. Many applications were made decades ago and don't see much active development anymore, but are still used every day. So make XWayland a first-class citizen to ensure that existing software runs at least as well as before without code changes or recompilation
3. Acknowledge that every functionality in X11 that is in active use is actually wanted and useful for someone (even if it is not you). Never say things like "applications should not be able to do this", or "in order to do this, you need ". If Wayland wants to become a worthy alternative to X11, then it must not leave out significant portions of what X11 can do (and is in active use)
4. For every functionality in X11 that is in active use, describe a clear migration path for those developers who do want to port their software to Wayland (e.g.: How can my application position its window in absolute pixel coordinates and set an arbitrary icon on the window)
5. Create /usr/bin/wayland - one universally shared display server (compositor) that is agnostic and entirely independent of any particular desktop environment. So that what is supported in "Wayland" is supported in all desktops, just like with X11. Stop using the "Wayland is just a protocol" as an excuse why stuff is broken in different ways in every desktop environment.
6. Do not assume that Wayland desktops applications are following any of the XDG specifications (such as desktop files). Those are too limiting and dictating how desktops and applications should work. E.g., GNUstep does not use them at all, and for that reason has features that no XDG based desktop environment has.

Yeah deprecating Xorg and defaulting to Wayland isn't ideal, but if nobody is maintaining Xorg wouldn't it break eventually?

According to some Wayland proponents, Xorg hasn't been maintained for a while, yet it is working just as well for me as always. In fact, I consider the best software "mature" in the sense that it is no longer a moving target but a stable platform that doesn't change anymore in unexpected ways.

I do it on GNOME no problem

That is precisely the issue with Wayland.

I've never wanted to (...)

So what? There are people who do.

set a window position outside of dragging windows to snap positions/Exposé

If you are running a complex desktop application with many floating windows (a.k.a. palettes, think professional software, not a toy/mobile "app" like the ones that ship with Gnome), then you might see why this is essential.

I've never witnessed GNOME on Wayland crash since late 20/early 30 Fedora.

These are all promoted by IBM Red Hat. As soon as you stay closely inside their software stack, stuff tends to (halfway) work. But the Unix philosophy is that you can freely mix and match any element of the software stack. And IBM Red Hat tends to really make that hard, because their stuff tends to either explicitly (think: dependencies) or subtly (think: it was tested together) depend on each other. Try to replace any software that is promoted by IBM Red Hat with an alternative (e.g., Glib, Gtk, gdm, Gnome, systemd, Wayland, Pipewire, OSTree, Flatpak, Fedora, etc.), and you will see what I mean.

There is not one /usr/bin/wayland display server application

Why would I care about this? GNOME on Wayland

Because as soon as you use something else than "GNOME on Wayland", you will encounter a different set of features, different breakages, and other bugs in the compositor. Unlike with X11, where you can rely on display server functionality to work in the same way no matter which desktop environment you are running.

Now imagine you are an application developer trying to make stuff work consistently across all desktops. Then it should be obvious what the problem is.

Recording full displays and windows works perfectly from OBS Studio on GNOME on Wayland,

It does not work at all on other combinations. Point in case, see the above.

Wayland breaks drag and drop

I do it on GNOME no problem

It does not work at all on other desktops. E.g., on Raspberry Pi OS, I cannot drag a file from an archive to the desktop when Wayland is enabled.

I don't do color management anyway

So? If you were a professional graphics designer, you would be dependent on it.

Wayland breaks windows rasing/activating themselves

I'd raise that as a benefit

Well, how hard would it be to make it an opt-out thing via a config?

Suckless software tends to avoid them and use pure Xft.

I tried Suckless software once. Somehow used up more resources than a pure Qt application.

It was in fact reports of distros considering "sunsetting" x11 that caused me to take up this work.

This gist partly exists in order to remind everyone, including distros, that "sunsetting" X11 anytime soon (i.e., in this decade) would be a very bad idea. I am not sure that everyone obediently jumping onto the Wayland bandwaggon is really helping (despite good intentions): It just makes it easier for distributions to go ahead with the "sunsetting". If many popular desktops don't offer Wayland yet (because it doesn't have what it needs yet), then it is harder for distributions (who want to keep the users of said desktops) to jump ship.

Sorry, I'm not willing to let MATE be held hostage by the outcome of this dispute/competition. If GNOME 3 had been the default in 2005, I could very easily have gotten stuck with MS Windows and all of its dangerous security problems and back doors.

I don't see distros changing decisions about keeping or dumpinmg Xorg over loss of any DE that is not their primary DE. This could well be like a proposed highway or pipeline: by the time it is being discussed in public, the people who make the decisions have already made up their minds. That ship may have sailed a year ago.

Very much for the proposed steps to make Wayland more viable though

Can see your point @lukefromdc. Thanks for working on MATE.

thank god you guys have calmed down today

thank god you guys are still calm today

thank god you guys are still calm today

Everyone busy with xz-utils. :D

thank god you guys are still calm today

Everyone busy with xz-utils. :D

Lol.

this read like some one saying linux breaks every thing after coming over from windows

Someone voluntarily switching from Windows to Linux (or vice versa) is something entirely different.

We are talking about users who have been using the *nix desktop. Now this new thing comes along and breaks stuff.

We are talking about users who have been using the *nix desktop. Now this new thing comes along and breaks stuff.

Soo.. don't use the new thing?
And if your distro is actually removing X11 use another distro?
But no, that would be too logical and obvious.

The new thing wants to win over the users of the current thing. So it needs to be compatible with the current thing, or at the very least provide a clearly documented and sensible migration path imho.

So there must never be something in general that does things differently from before, I see.
I guess that is why we are still punching holes in cards.

Thing is, Wayland doesn't allow us to do certain things at all (e.g., work properly without the need for additional dependencies like portals and Pipewire, set the absolute position of windows or set custom icons on windows).
If magnet tape wanted to replace punch cards but wouldn't allow you to store certain numbers, maybe people would have kept punching until that issue was resolved.

If magnet tape wanted to replace punch cards but wouldn't allow you to store certain numbers, maybe people would have kept punching until that issue was resolved.

Right, so just keep punching then?
Or try to improve the magnet tape protocols or implement shiny new compact disks rather than maintaining this gist.

Thing is, Wayland doesn't allow us to do certain things at all (e.g., work properly without the need for additional dependencies like portals and Pipewire, set the absolute position of windows or set custom icons on windows). If magnet tape wanted to replace punch cards but wouldn't allow you to store certain numbers, maybe people would have kept punching until that issue was resolved.

that's not the same thing, Wayland just have a more refined scope then X11 does

The new thing wants to win over the users of the current thing. So it needs to be compatible with the current thing, or at the very least provide a clearly documented and sensible migration path imho.

Perhaps this is what was intended. To ensure that widget set developers are discouraged and thus impose their own Wayland widget set.

Last I heard is that Qt and GTK are mostly working fine for the absolute majority of applications with their wayland backends.
Also, most wayland compositors still provide the X11 API via xwayland as well so not sure what "impose their own Wayland widget set" refers to.

I am still trying to figure out what the motivation of this whole gist is and what audience it targets. It indeed somewhat sounds like some MS fanboy needing to tell the whole word that a Linux desktop is unusable because there is no explorer.exe and no registry editor.

Qt and GTK are not alone in the world. Sorry if you dont understand "impose their own Wayland widget set" and the big regression that this represents for the concept of opensource. But I know, it's very fashionable to follow the herd, like a sheep.

. It indeed somewhat sounds like some MS fanboy needing to tell the whole word that a Linux desktop is unusable because there is no explorer.exe and no registry editor.

Their argument is "it doesn't work when I use incompatible software"

By the way, a good exercise for the “Wonderful AI Revolution”: create a converter from X11 methods to Wayland methods.
I give it code for an application that uses a widgetset using X11 methods and it will convert it to source using Wayland.
From C++, Java and Pascal.
Come on AI, show me your code.

Sorry if you dont understand "impose their own Wayland widget set" and the big regression that this represents for the concept of opensource. But I know, it's very fashionable to follow the herd, like a sheep.

Now I get it, its like when in the past X11 was being used by more and more people and that caused grep, emacs and vim to die. Thanks for enlightening me, maybe there is a small chance that I can overcome my sheepness some day.

@Consolatis 👍

For my part, I am absolutely not against Wayland (even if it is not yet fully operational) but am disappointed by its side "Qt and GTK only", which will quickly turn into a war between Qt and GTK.
And it is more than obvious that Wayland does everything (or rather nothing) so that other "competitors" cannot adapt their widgetset for Wayland.

On a more serious note, I still don't get it. Most wayland compositors support X11 via xwayland and there is also no "Qt and GTK only" requirement. I didn't follow the wayland support for flutter and friends but I'd assume they will add (or already have) wayland backends as well and if not they can simply run via X11. You can also use no toolkit at all (for example the wayland native foot terminal emulator is an example of that).

It's not about XWayland which is absolutely essential. It's about widgetsets who use X11 and who would also like to develop an interface for Wayland.
For example this Widgetset attempts to create an interface for Wayland but passion fades little by little due to the lack of clarity.

By the way, a good exercise for the “Wonderful AI Revolution”: create a converter from X11 methods to Wayland methods. I give it code for an application that uses a widgetset using X11 methods and it will convert it to source using Wayland. From C++, Java and Pascal. Come on AI, show me your code.

so xwayland?

@fgclue: In your presentation:

i use these for designs: Figma GIMP Inkscape Krita

Inkspace does not work (or bad) on XWayland. It does not exist a "pure" Wayland version of Inkspace. Figma does not work (or bad) on XWayland. It does not exist a "pure" Wayland version of Figma. Krita does not work (or bad) on XWayland. It does not exist a "pure" Wayland version of Krita. Gimp has a "pure" Wayland version but the "pure" X11 version works better with XWayland.

But! Xwayland is pure wayland. Wayland is very pure, and Inskape is working on PURE wayland, did you know that? Did you know that? Did you know that? Did you know that? Well. Also It works so much better than your NO MORE X11 VERSION BAD BAD BAD

No MORE X11!!! 😠 😡 😡 😡

By the way, a good exercise for the “Wonderful AI Revolution”: create a converter from X11 methods to Wayland methods. I give it code for an application that uses a widgetset using X11 methods and it will convert it to source using Wayland. From C++, Java and Pascal. Come on AI, show me your code.

so xwayland?

XWayland needs X11, I want a converter of X11 methods into Wayland methods (Humans said that it is not possible).

By the way, a good exercise for the “Wonderful AI Revolution”: create a converter from X11 methods to Wayland methods. I give it code for an application that uses a widgetset using X11 methods and it will convert it to source using Wayland. From C++, Java and Pascal. Come on AI, show me your code.

so xwayland?

XWayland needs X11, I want a converter of X11 methods into Wayland methods (Humans said that it is not possible).

I want a converter of X11 methods into Wayland methods

xwayland does that

edit: fix typo

Funny post. A new standard breaks stuff? Cars aren't exactly made for horses either, huh?

@franzos

Funny post. A new standard breaks stuff? Cars aren't exactly made for horses either, huh?

That's the most inappropriate comparison I can think of.

By the way, a good exercise for the “Wonderful AI Revolution”: create a converter from X11 methods to Wayland methods.

In order to give the AI a chance to succeed, Wayland would need to provide the missing protocols.
But apparently they don't care enough or it would have happened many years ago.

I want a converter of X11 methods into Wayland methods

xwayland does that

I understand that he is looking for a tool that converts an existing code base written for X11 to one that is written for Wayland.
In order for that to work, Wayland would need feature parity, which it doesn't have yet (e.g.,: set random icons on windows, just as one example).

Just a reminder to everyone, please stay on topic and do NOT post ad-hominem comments.

Handle windows (not: "surfaces") like in X11 (window ID, etc.) (for now we are assuming that zwlr_foreign_toplevel_handle_v1 [for non-Wayland applications] and xdg_toplevel [for Wayland applications] is the Wayland equivalent of a window ID)

You are aware of ext-foreign-toplevel-list ?

I want a converter of X11 methods into Wayland methods

xwayland does that

I understand that he is looking for a tool that converts an existing code base written for X11 to one that is written for Wayland. In order for that to work, Wayland would need feature parity, which it doesn't have yet (e.g.,: set random icons on windows, just as one example).

I would already be very happy if some workaround or macros are used. For example XWayland can find workaround if some X11 atoms cannot be realized by Wayland.
But I dream, of course, it would be a kind of bridge that converts (with workaround or macros sometime) the methods of libX11.so.6 using the Wayland methods of libwayland-client.so and other wayland libraries.

Example, in my code that use XCreateWindow() a bridge will create code using wayland methods and, at compilation, libwayland-client.so will be used for linking (and not libX11.so).

How is this not insanely revealing and the best reason to boycott Wayland ever?
https://www.reddit.com/r/linux/comments/1bzna16/hyprland_creator_vaxry_is_now_banned_from/
We should stop acting like we're not in the majority here. Not the majority of corporate and political power, but the majority of sane and competent contributors and users. We're catching this quite early on... If you think they won't increase the ideological policing and leveraging their power over you when they're the only game in town, then you've got another thing coming!

How is this not insanely revealing and the best reason to boycott Wayland ever? https://www.reddit.com/r/linux/comments/1bzna16/hyprland_creator_vaxry_is_now_banned_from/ We should stop acting like we're not in the majority here. Not the majority of corporate and political power, but the majority of sane and competent contributors and users. We're catching this quite early on... If you think they won't increase the ideological policing and leveraging their power over you when they're the only game in town, then you've got another thing coming!

What is your point? I am not a wayland fan but this CoC thought police is cancer. Some ppl are butthurt because someone was "toxic" on another platform? Am I missing something?

That is a JURISDICTION issue: Freedesktop has no jurisidiction over any activity not part of their projects or on their servers, just as Facebook has no jurisdiction over what I say on Mastodon. Has nothing to do with whether Xorg, wayland, or any particular wayland compositor is better code.

I see a future where Wayland has taken over to the point that every day applications rely on it, not Xwayland, and you will essentially be forced to use Wayland, but because there's no common compositor the only two real options are KDE and Gnome, compositors like wlroots exist but are severely lacking because of a lack of funding and a large team. Oh wait, that's already happening.

I see a future where Wayland has taken over to the point that every day applications rely on it, not Xwayland, and you will essentially be forced to use Wayland, but because there's no common compositor the only two real options are KDE and Gnome, compositors like wlroots exist but are severely lacking because of a lack of funding and a large team. Oh wait, that's already happening.

Get off the drugs. :D

Summary of the Red Hat vs. Hyprland drama: https://www.youtube.com/watch?v=UQ770FOWgeY. Original source documents.

tl;dr: IBM Red Hat employee exercising undue power (apparently politically motivated) using a company email address while insisting that it has nothing to do with IBM Red Hat.

Maybe it's time to avoid projects in which IBM Red Hat employees play a significant role.

I see a future where Wayland has taken over to the point that every day applications rely on it, not Xwayland, and you will essentially be forced to use Wayland, but because there's no common compositor the only two real options are KDE and Gnome, compositors like wlroots exist but are severely lacking because of a lack of funding and a large team. Oh wait, that's already happening.

The combination of MATE using wayfire (and thus wlroots) and probably the other non-GNOME/non-KDE desktops also using wlroots based compositors should ensure that people who don't like GNOME always have an alternative. It's possible that some proprietary
applications might use GNOME-only or (less likely) use KDE-only compositor features, but there are a lot of linux users who don't use proprietary apps simply to get away from online activation and paid software.

Also note that if KDE rebases to wlroots that's a game changer. The only reason they didn't use it is that wlroots didn't exist yet when they started adding wayland support to KDE.

Also note that if KDE rebases to wlroots that's a game changer.

Do you think it's planned?

What is your point?

Pretty obvious. If they're willing to go to this level of trying to centralize control of the means of production, then it is clear they're planning to overstep even more... And the so-called "conspiracy theory" about trying to lock down the desktop (mobile has already been locked down) so users/engineers barely have access to their own devices should be considered factual. It has happened many times in many scenarios with many cross company and supposed cross ideology strategies. The intelligent thing would be to protect against it by not losing ground. In the context of software, the engineers in this thread should not have a problem parsing what it means to not lose ground against such attacks.

Maybe it's time to avoid projects in which IBM Red Hat employees play a significant role.

Right, so this goes back to a previous point of mine that "a distro" is a skillful level of organization to operate from. Having a lot of devs using the same env (and CI system testing everything within that env) is obvious in a company, but not an open source community trying to protect against attacks from companies & ideologies? Makes no sense. A group of developers with interests in control over their own computing environments would empower themselves to deal with such things. Linux still has the most power and flexibility, so it would be some form of Linux - and I would bet it would converge on the most stable and sane set of defaults and would become a distro the subverters would be begging to gain influence within.

I've heard speculation that KDE will rebase to use wlroots but having no connection to KDE I really do not know

BTW, mobile is not entirely locked down. Certain specific Android devices with unlockable bootloaders can be reflashed with alternative operating systems. You decide what OS you want to run, then get a compatable device. Not great, but enough to break out of the locked "customer experience."

BTW, mobile is not entirely locked down. Certain specific Android devices with unlockable bootloaders can be reflashed with alternative operating systems. You decide what OS you want to run, then get a compatable device. Not great, but enough to break out of the locked "customer experience."

you might be locked in by an app you use, as google does not allow some of their apis to be used on open systems

BTW, mobile is not entirely locked down. Certain specific Android devices with unlockable bootloaders can be reflashed with alternative operating systems. You decide what OS you want to run, then get a compatable device. Not great, but enough to break out of the locked "customer experience."

How can you get a reasonable security/privacy experience with a rooted phone the way it is now setup? OSs like Graphene say letting the user have full filesystem access and root-of-trust "defeats the purpose" of their OS. So there's no straight forwards way to have your cake and eat it anymore like there almost was with phones like the Nokia N900.

you might be locked in by an app you use, as google does not allow some of their apis to be used on open systems

Nothing wrong with getting locked into a specific proprietary app you use, but making it so the only decent way to use these apps you have to give up easy access to your entire device (including updates to some degree) seems to qualify.

Graphene is the OS of choice for those facing state level or other high capability attackers. For a rooted system to allow arbitrary changes you'd use something else. To have both, you'd need something where you set up the image on your desktop, sign it there if you will be using secure boot with custom keys (as Graphene does) , and then add those keys to the phone over USB and flash your modified image to the phone. You have root when and only when the image is on your desktop, in a controlled environment in this scenario. If you need su, add it while the OS image is mounted on the desktop and before signing it, but be aware this does make attacks on the phone easier. You might need it for say, a system level adblocker that doesn't tie up the VPN interface as Tracker Control does.

As for apps that don't work on open devices, those can be either quarantined to a separate phone tethered to your main phone, or not used at all. For instance, banking apps won't work on anything I own, but I don't trust online banking anyway so that doesn't matter. No banking apps on any device I own. Note that I do not allow Google Play Services (or anything that depends on it) on my phones, which closes 90% of the privacy busting attack surface. I use F-droid, note that the Google Play Store is useless without an account anyway, and I refuse to have a Google account.

A computer (ANY computer) can only be trusted by at most one party. Any application that requires a computer to be trusted by Google, by a bank, by Hollywood etc means that computer can no longer be trusted by you and should not be used to handle sensitive information. When they ban rooted/modded/open phones, they demand you use a device they can trust as opposed to one you can trust. Never can both you and they trust the same device as these businesss regard their users as adversaries.

Banking is a special case due to the severity of damage an attacker can do, for that purpose best practices may be to trust nothing save the bank's own ATMs, for it's a lot easier to make them pay if a skimmer gets put on their ATM (under the nose of their own cameras) than to get your money back if a "banker" worm on your phone or desktop (or a phishing attack) gets your creds and empties your account. In other words, banking may be a case of neither you nor the bank can trust the computer.

You might need it for say, a system level adblocker that doesn't tie up the VPN interface as Tracker Control does.

Use DNS level adblocking, it's literally a stock Android feature (Settings > Network > Private DNS) that I don't know why more people don't use.

google does not allow some of their apis to be used on open systems

Specifically Google Pay won't work on GrapheneOS. Anyways, is this thread not about user choice? Why consider subduing oneself to Google when everybody is mad at Wayland for supposedly suppressing user choice? Just use cash if you care about privacy, and a credit card if you don't.

On the topic of Wayland usability and X parity: I've gotten KDE's Wayland to work flawlessly on a laptop with an NVidia card, including gaming and even screensharing via Teams (which uses either Electron or an embedded Chromium browser). If green team laptop hardware and M$ software can cooperate with Wayland well enough for it to become my daily driver, I guess I don't get the vitriol towards Wayland. Granted I am not a GUI developer, but as a user I can't see the issue

Xorg is my go-to for flexibility. I mean, you can tweak just about everything with it. It's got this UNIX philosophy vibe going on, keeping things simple and modular.

But then there's Wayland. Now, don't get me wrong, it's got some cool stuff, especially for specialized devices. But here's where it starts to lose me: it feels like Wayland's going against the whole UNIX philosophy. It's trying to be this monolithic thing (compositor), kinda like a Windows vibe, which is weird for the UNIX world. The lack of a base library or display server in Wayland means that fixes or improvements made in one compositor won't necessarily translate to others. It's like each compositor is doing its own thing.

The folks behind Wayland are also the ones behind Flatpak, right? It seems they're not too bothered about code duplication, which is a bit concerning. I mean, it reminds me a lot of the Windows ecosystem.

It's got this UNIX philosophy vibe going on, keeping things simple and modular.

Seems to me that is what Wayland aims to do. But if you search for the "Unix filosophy" Wikipedia page, it states that this means doing one thing and doing it right. Ask actual X.org devs and they will tell you it's the opposite.

I mean, the X.org server initially included a print server, talk about keeping things simple (yes they scrapped that for obvious reasons).

From an engineering (and funding) standpoint, X can't be maintained

I would never use something like Google Pay. One of the reasons is that there are those who want your phone to be tied to you by a government ID, to BE your government ID,and also be your only way of making payments so as to render private transactions impossible save for barter. Google Pay is fundamentally incompatable with the idea of deniable ownership of a prepaid phone.

The folks behind Wayland are also the ones behind Flatpak, right? It seems they're not too bothered about code duplication, which is a bit concerning. I mean, it reminds me a lot of the Windows ecosystem.

That's design by committee for ya.

The lack of a base library or display server in Wayland means that fixes or improvements made in one compositor won't necessarily translate to others. It's like each compositor is doing its own thing.

That was swiftly rejected: https://gitlab.freedesktop.org/wayland/wayland/-/issues/233

And now we have three libraries:

• libweston
• wlroots
• Louvre

Two major implementations not using them:

• Mutter
• Kwin

And then a ton of minor WMs. Essentially it's a zoo. And God forbid you use anything but KWin/Mutter. Everything else is just woefully incomplete.

I think its quite funny how some people always scream "but its about choice" and when they then have a choice they scream "but its a zoo".

I think its quite funny how some people always scream "but its about choice" and when they then have a choice they scream "but its a zoo".

Some things need to just work without multiple implementations. You don't have multiple display servers in Windows, MacOS, iOS, Android or ChromeOS. The choice proponents would instantly say that those OSes don't have multiple desktop environments either, and that's not true, as no one stops you from creating one for Windows and MacOS, Android has a metric ton of "launchers", and ChomeOS is an Internet OS, so it's just irrelevant. And Windows indeed has several third-party desktop environments, only they are relatively unknown. And I have zero clue how multiple inferior Wayland implementations would even help anyone.

The display server is such a core low-level OS thing, it makes zero sense to waste resources reimplementing it over and over again. In Linux somehow we have a single kernel, a single C library (yeah, there's MUSL but it's mostly for embedded devices), a single font rendering library (freetype which still sucks ass vs. ClearType v2), a metric ton of singular implementations and no one has cried foul about that. Complexity is a bitch you have to deal with.

No one also cried foul about a single X11 implementation (for all intents and purposes Linux distros always came with a single Xorg server, be it XFree86 or Xorg later on) until people decided they needed something more modern and yeah, X11 has a number of glaring issues which couldn't have been resolved without breaking compatibility with the protocol.

That was swiftly rejected: https://gitlab.freedesktop.org/wayland/wayland/-/issues/233

It's disappointing to see the discussion closed without thorough consideration. Rejection doesn't automatically mean it's the best choice or reflects the community's view.

IMHO they should have made screen recording a priority, I cannot share my screen in all meeting apps, and I have to constantly defend why I use Linux when it doesn't allow me to share screens, it's almost as if I am using a calculator for development and trying to justify it as ideal for my workflow

It's almost as if we went back twenty years when there was no screen recording and were lucky to get something to even show up on the screen

You can use wl-sunset instead of redshif.

also wf-recorder can do screencapture instead of ffmpeg.

I've been trying wayland, for a couple months, i do not recommend it unless you are a power user with way too much time on your hands. Even then, the time would proabbly be better spent elsewhere.

How is this not insanely revealing and the best reason to boycott Wayland ever? https://www.reddit.com/r/linux/comments/1bzna16/hyprland_creator_vaxry_is_now_banned_from/ We should stop acting like we're not in the majority here. Not the majority of corporate and political power, but the majority of sane and competent contributors and users. We're catching this quite early on... If you think they won't increase the ideological policing and leveraging their power over you when they're the only game in town, then you've got another thing coming!

It is, they're literally banning developers (and vaxry is imo one of the best ones) from contributing to wayland and wlroots over political nonsense because someone (who is not the developer) said something on discord a few years ago and that is somehow the developers fault and a good reason to ban him from their gitlab.

It's like the wayland devs actually want wayland to suck, it's like they always wanted it to suck, I'm not even surprised to say that the wayland devs want it to suck, i mean look at the bloody thing, it sucks by design! And everyone even knows it.

That's hyprland, not Wayland. Hyprland is CoC cuckery.

That's hyprland, not Wayland. Hyprland is CoC cuckery.

I find it very interesting that in reality the Freedesktop and by proxy Wayland exactly insist on their "code of conducts", wield that like a weapon and impose these onto other people who have nothing to do with them.

It's also very interesting that the circle of people who so rabidly are defending and promoting Wayland (also trying by force) is overlapping really heavily with the GNOME people. Many of these people also have very strong opinions in other topics which they don't shy away to declare that their way of thinking is the one true way and everyone else is a heretic for not exactly aligning with them and must be purged.

They also like to throw things at other people at their heads they are doing themselves or like doing themselves.

I don't mind Wayland, but it is not usable for me and I really dislike people promote that like a religion.

In technical debate the word "cuck" should be avoided: it reeks of Gamergate and the "manosphere" misogynists

and I really dislike people promote that like a religion.

That I can agree with. And it works both ways:

DO NOT USE A WAYLAND SESSION! Let Wayland not destroy everything and then have other people fix the damage it caused. Or force more Red Hat/Gnome components (glib, Portals, Pipewire) on everyone!

IMHO use whatever floats your boat and contribute to projects that share your vision. Otherwise you just come across as some whiny kid. This is FOSS after all, nobody owes you anything.

In technical debate the word "cuck" should be avoided: it reeks of Gamergate and the "manosphere" misogynists

What do you mean? Misogynist is a compliment these days.

Misogynist is NOT a compliment-and I utterly dispise Gamergate, Qanon, and the rest of that fascist SHIT.

Misogynist is NOT a compliment-and I utterly dispise Gamergate, Qanon, and the rest of that fascist SHIT.

Schizoposting? What do any of the words you just typed mean?

Let me make this crystal clear: hating women is NOT acceptable, not now, not ever. No other part of the agenda of creeps like Trump is acceptable to me either.

and I really dislike people promote that like a religion.

That I can agree with. And it works both ways:

DO NOT USE A WAYLAND SESSION! Let Wayland not destroy everything and then have other people fix the damage it caused. Or force more Red Hat/Gnome components (glib, Portals, Pipewire) on everyone!

IMHO use whatever floats your boat and contribute to projects that share your vision. Otherwise you just come across as some whiny kid. This is FOSS after all, nobody owes you anything.

Why would you criticize someone who is warning people who don't understand such thing? The brave person who highlighted the problem with Wayland serves those who struggle to find there way through problems created by something thought to be good thing. I wish I had been able to read this information a year ago, it would have saved me a months worth of head aches.

A warning would be something like "Your wayland session may have the following issues, if you can't accept that or are not comfortable investing time to work around them you may want to keep using the X11 session instead.".

Let Wayland not destroy everything and then have other people fix the damage it caused.

Sounds very different.

Let me make this crystal clear: hating women is NOT acceptable, not now, not ever.

no one here said that is was okay

I have been following this thread for over a year and I am still confused as to how we ended up with Wayland. I like analogies so here is one to express my confusion. We had a ship. It was an large old ship. Whether you liked or disliked the ship, you knew how big it was, how to steer it, provision it, sail on it, etc. It was a known quantity. One day, the operators of the ship decided they needed a new ship. They said they did not want a replacement for the old ship, just a new ship. Oh, and by the way the operators were also going to take the old ship out of service. Eventually, the ship builders delivered the new ship. However, what the ship operator received from the ship builders was a diesel engine, a propeller, and a rudder. When the operator asked about the hull and other parts of the ship, they were told by the builders that they had to create those items themselves. Because the operators were not ship builders, this lead to the construction of a very odd ship, full of quirks, missing features, and confusion for passengers who were not accustomed to the novel idiosyncrasies of the new ship.

So please help me understand why, rather than create a full featured replacement for X Window that directly addressed its shortcomings, we ended up with something replacing it that is explicitly not a replacement for it and decentralizes the implementation of key functionality. What I have heard over the year feels like attempts to rationalize the decisions made for Wayland. My interest in this is not just as a developer who relies on X Window features, but as a decades long user and believer in Linux, who is concerned that fragmentation of such core capabilities will hurt the platform.

Your analogy isn't perfect. What is missing is that the old ship can be duplicated many times within seconds and you can put a new crew on each of the duplicated old ships.

Regarding why wayland doesn't offer "all the features" I think it boils down to:

1. xorg didn't offer all the features from the start either, they were added over a long period of time. Writing a completely fully-featured new system from scratch is just not feasible and even if it were, there are just too many potential use-cases to cover that might even contradict themselves.
2. The wayland-protocols members have a very strict view on some things and prefer enabling use-cases rather than generic features that can be used in bazillion different ways. Add to that that the whole accepting-a-protocol process is *slooow*.
3. There is also xwayland support in almost every wayland compositor so running (most) X11 applications should not be an issue. This might remove some incentives to support something in a wayland protocol because there exists this fallback path.

@Consolatis Thank you for the quick and thoughtful reply.

xorg didn't offer all the features from the start either, they were added over a long period of time. Writing a completely fully-featured new system from scratch is just not feasible and even if it were, there are just too many potential use-cases to cover that might even contradict themselves.

I'm sick of reading this nonsense. Wayland has been flawed since day one. No amount of time will fix it, because the architecture is just bad.

The wayland-protocols members have a very strict view on some things and prefer enabling use-cases rather than generic features that can be used in bazillion different ways. Add to that that the whole accepting-a-protocol process is slooow.

Okay, everyone's already realized that Wayland-CСP are jerks. Where the fck is the library with all the display server features? Where the fck is it?

There is also xwayland support in almost every wayland compositor so running (most) X11 applications should not be an issue. This might remove some incentives to support something in a wayland protocol because there exists this fallback path.

Stop lying, XWayland won't run half of the applications, and those that it does run, run with limitations.

xorg didn't offer all the features from the start either, they were added over a long period of time. Writing a completely fully-featured new system from scratch is just not feasible and even if it were, there are just too many potential use-cases to cover that might even contradict themselves.

Yeah, Xorg was made in a different time when tech was way simpler. Hardware and software were way less advanced back then. Also, for something trying to replace Xorg and being the standard for many Linux distros, it can't start off incomplete like that. Wayland should've come out stronger right from the start if it wants to be the go-to choice for everyone.

Yeah, Xorg was made in a different time when tech was way simpler. Hardware and software were way less advanced back then.

The hardware and software remains exactly the same. All that has changed is mostly hardware performance.

Yeah, Xorg was made in a different time when tech was way simpler. Hardware and software were way less advanced back then.

The hardware and software remains exactly the same. All that has changed is mostly hardware performance.

Really? Did we have DRI back in the '80s? Over the years, Xorg got a bunch of extensions like Xinerama, RANDR, and more to tackle current issues. Saying Xorg was "incomplete" from the start isn't an excuse for Wayland's limitations. It aims to replace what Xorg does now, not what Xorg did decades ago.

@gustavosbarreto

Really? Did we have DRI back in the '80s? Over the years, Xorg got a bunch of extensions like Xinerama, RANDR, and more to tackle current issues.

These are improvements regarding the graphical stack that followed the development of hardware. Wayland has not invented anything new. It's just some stupid desire to "be different" for the sake of showing off or something like that.

No one back then even seriously thought of making a bunch of incompatible graphical servers with different protocols for each DE. This option has always been unsustainable.

Saying Xorg was "incomplete" from the start isn't an excuse for Wayland's limitations. It aims to replace what Xorg does now, not what Xorg did decades ago.

Absolutely agree, all the developers had to do was make an improved version of X11 and Xserver without reinventing the wheel. Either that or nothing at all.

Wayland, however, is a complete deception. First it was that Wayland was "X12", then Wayland was just a replacement for X11/Xorg. Now its fanatics are giving up and promoting it as "an incompatible modern alternative that must destroy everything before it, because the old must die. Why? Because we can."

I'm sick of reading this nonsense. Wayland has been flawed since day one. No amount of time will fix it, because the architecture is just bad.

okay @Monsterovich so you have made this claim are you able to prove it? (this is not a gotcha i would like to know)

Wayland, however, is a complete deception. First it was that Wayland was "X12", then Wayland was just a replacement for X11/Xorg. Now its fanatics are giving up and promoting it as "an incompatible modern alternative that must destroy everything before it, because the old must die. Why? Because we can."

The more I read about Wayland the more I get the impression what started as a technical issue is now rooted in ideology, almost like a social engineering op.

@Consolatis

xorg didn't offer all the features from the start either, they were added over a long period of time. Writing a completely fully-featured new system from scratch is just not feasible and even if it were, there are just too many potential use-cases to cover that might even contradict themselves.

@gustavosbarreto

Really? Did we have DRI back in the '80s? Over the years, Xorg got a bunch of extensions like Xinerama, RANDR, and more to tackle current issues. Saying Xorg was "incomplete" from the start isn't an excuse for Wayland's limitations. It aims to replace what Xorg does now, not what Xorg did decades ago.

This is a garbage reply/counter-argument.

The XFree86/Xorg server later on offered the same featureset for all its users. At no time people dealt with different levels of implementation of X11 on Linux.

This is exactly the case with Wayland. Multiple Wayland protocols are not mandatory, and the experience and features that you're getting with compositor X for Wayland could be radically different from compositor Y.

The wayland-protocols members have a very strict view on some things and prefer enabling use-cases rather than generic features that can be used in bazillion different ways. Add to that that the whole accepting-a-protocol process is slooow.

Desktop users need none of this shit. Wayland was promised to be a better X11/Xorg out of the box. It's still not by a long shot. Microsoft replaced the entire graphics stack in Vista (and moved it into user space for good measure) and even low-level Windows XP and earlier applications continued to work just fine. Some very rare applications broke, e.g. those that hooked into low-level Windows features with no public APIs, e.g. WindowBlinds, but those worked against Microsoft's will and guidelines. There's no concept of private APIs in Linux.

There is also xwayland support in almost every wayland compositor so running (most) X11 applications should not be an issue. This might remove some incentives to support something in a wayland protocol because there exists this fallback path.

Another garbage reply. XWayland is good only for running basic single-window applications because everything else is broken.

@baron1405

Your analogy is almost perfect, except you were talking about this:

However, what the ship operator received from the ship builders was a diesel engine, a propeller, and a rudder.

No, they didn't receive even that. They received blueprints for certain parts of the new ship. And those blueprints were quite vague as to whether you needed to be put them in place or not, thus we now have multiple ships, some of which are missing toilets, others are missing hallways or kitchen, others have no poles, etc. etc. etc.

And now we have multiple ships where only few selected come with all the amenities but it's claimed that they are all better than the old clunky ship.

Wayland is just a spec where x11 is a spec and implementation

I'm sick of reading this nonsense. Wayland has been flawed since day one. No amount of time will fix it, because the architecture is just bad.

okay @Monsterovich so you have made this claim are you able to prove it? (this is not a gotcha i would like to know)

I (and others) in this thread have already written thousands of proofs that Wayland is flawed, and I already post in circles sometimes.

@zarlo

Wayland is just a spec where x11 is a spec and implementation

The fact that Wayland is just a spec (and every DE has their own) is VERY BAD. The reason for this is fragmentation.

Wayland is just a spec where x11 is a spec and implementation

Well. X11 is the spec and Xorg is just one of multiple implementations, but the one practically everyone is using on the *nix desktop.

Contrast this with Wayland where not even Gnome and KDE use the same implementation, and hence are broken in different ways (as in: different features supported, different bugs).

... not even Gnome and KDE use the same implementation, and hence are broken in different ways (as in: different features supported, different bugs).

I think we'll see the free market take care of what features make it in as things progress. It shouldn't have taken this long, however.

Wayland, however, is a complete deception. First it was that Wayland was "X12", then Wayland was just a replacement for X11/Xorg. Now its fanatics are giving up and promoting it as "an incompatible modern alternative that must destroy everything before it, because the old must die. Why? Because we can."

The more I read about Wayland the more I get the impression what started as a technical issue is now rooted in ideology, almost like a social engineering op.

100%

Use DNS level adblocking, it's literally a stock Android feature (Settings > Network > Private DNS) that I don't know why more people don't use.

That isn't a solution when you realize how few adverts it can block versus ublock.

The folks behind Wayland are also the ones behind Flatpak, right?

Don't you want to be part of their wonderful utopia? Wayland + systemD + flatpak + ... secure boot with Google/Intel/AMD/Apple at the root-of-trust. Being able to enforce DRM (amongst other things) onto everyone will give us all a century of the Linux Desktop! Utopia!

Don't you want to be part of their wonderful utopia? Wayland + systemD + flatpak + ... secure boot with Google/Intel/AMD/Apple at the root-of-trust

I bet if you repeat the same strawman slop 100 more times it'll eventually be funny.

import gi

gi.require_version("Gtk", "3.0")
from gi.repository import Gtk, Gdk

offset_x = 0
offset_y = 0

def press(widget, event):
    global offset_x, offset_y
    offset_x = event.x
    offset_y = event.y

def move(widget, event):
    win.move(event.x_root - offset_x, event.y_root - offset_y)

win = Gtk.Window()
win.connect("destroy", Gtk.main_quit)
win.connect("button-press-event", press)
win.connect("motion-notify-event", move)
win.set_events(Gdk.EventMask.BUTTON1_MOTION_MASK|Gdk.EventMask.KEY_PRESS_MASK)
win.show_all()
Gtk.main()

xdecor1.mp4

If someone promoted something like libdecor for any X clients decades ago, we wouldn't need window managers for X.Org in the first place.

BTW, found this in Xnest logs: http://selinuxproject.org/page/NB_XWIN

You don't need a ship at all if all you need in reality is a bunch of boats.

https://en.wikipedia.org/wiki/Cossack_raid_on_Istanbul_(1615)

But ship lovers keep assuring you need a full-fledged ship to win.

That is some very weird example for you to pick. Movement of windows should belong to the user (e.g. the compositor) rather than to random applications. Anyway, running it with GDK_BACKEND=x11 (and thus via xwayland) magically makes it work for me.

That is some very weird example for you to pick

Wayland haters criticize Red Hat, GOOME or whatever for attempting to push libdecor onto everyone and enforce all the Wayland clients to support CSD, instead of accepting that every compositor should support SSD as an option and not mandate simplistic clients to support CSD, regardless of the Wayland spec.

My point is to demonstrate that X clients can in fact support CSD too, and talk to the X server directly instead of relying on some window manager to draw decorations for them and to provide ability to move and resize their windows. So if they massively did, it wouldn't be crucial to also run some window manager along with X.Org.

A decade ago, I already was willing to ditch any window managers and only use pure X.Org and small UNIX-way utilities to manage the windows. But discovered that such tools don't work without any WM at all somehow (and only years later discovered the reason: that they actually talk not to X.Org but to a WM via EWMH, and it does not even work with any WM). I was highly frustrated that if I kill a WM, X clients become totally helpless, I couldn't even change their z-order, not even focus them if I have X-Mouse disabled. Some simpler apps had CLI flags or other means to specify their initial geometry, but more normie things like browsers just launched their windows with some default geometry, not even occupying the whole screen by default as I wished.

Oh, I just checked that GTK+3 CSD apps in fact support window manipulations with pure X server and no WM too. So I did not even need to write an artificial example, hehe. Just the maximize button doesn't work (it probably works via EWMH on X11 as well).

Instead of the quirky conception of struts, I would implement the non-fullscreen maximization in a way where every window advertises its geometry to others, and tells if it allows collisions or not. Something like it happens in game engines (2D or 3D, doesn't matter). X clients would then, when changing their window geometries, query all the other windows and check if there is any room for them. Just like when you join some Minecraft server and look for an unoccupied area for your buildings lol.

How is it better than struts? Panels may occupy not the whole screen side, but only a part. Thus some space around remains, where a wallpaper can be usually seen through. There's no reason non-maximized window cannot occupy this space, but that's exactly how struts work! It would also provide a simple way to avoid physical notches: just put a dummy non-colliding window there.

Oh, and of course, if some non-colliding window appears, or changes its geometry, it should send a «посунься!!!» signal to other windows, just in the case they already occupy some space where it is supposed to appear. It could even query their geometries first and send such a signal only to those who actually occupy some space there, neat? Just make sure to avoid race conditions… somehow… transactions? And to manage conflicts, like what if two non-colliding windows claim overlapping regions the same time, what would happen?

Sounds like fun to implement in every single application. And if the application doesn't implement it you can't move the window at all as a user. Doesn't sound that great to me. Not even starting to think about features like snap to edge.

And if the application doesn't implement it you can't move the window at all as a user.

Some think splash screens are in fact a feature.

They always were frustrating to me, and I'm glad that for Word 2007 in Wine I can omit them and switch to other window anyway by putting a splash screen down, unlike for Word 2007 on Windows (but I suspect, even there it's possible to force it down via some 3rd party tools).

i hate splash screens like why show some thing just to hide it and like 99% of them dont set a sane _NET_WM_WINDOW_TYPE so tiling window managers dont know to make them auto flow

The point is to discourage the user from doing anything while the app is launched so it is launched as fast as possible and nothing interferes with the process.

It's all wlroots. Nothing works without wlroots. Wayland is Wayland + wlroots in the same way that X11 is X11 + XOrg.server. Anything usable that doesn't use wlroots pulls a thousand fucking dependencies. Fuck that.

It's all wlroots. Nothing works without wlroots.

Except the desktop environment "everyone" is using... it's so sad that many new Linux users get served Gnome by distributions - not only by Fedora (which is to be expected due to IBM Red Hat control), but also Ubuntu. Otherwise we could just not care about it anymore at this point.

It's all wlroots. Nothing works without wlroots.

Except the desktop environment "everyone" is using... it's so sad that many new Linux users get served Gnome by distributions - not only by Fedora (which is to be expected due to IBM Red Hat control), but also Ubuntu. Otherwise we could just not care about it anymore at this point.

I've never had GNOME work, on X11, or Wayland , it just sucks. Something is always broken even on default settings for GNOME Debian. Never had any issues with Kwin{FT,} on plasma

What the hell is wlroots?

@Espionage724 its a Wayland compositor library that a lot of compositors use, it was a part of sway

It's all wlroots. Nothing works without wlroots.

Except the desktop environment "everyone" is using... it's so sad that many new Linux users get served Gnome by distributions - not only by Fedora (which is to be expected due to IBM Red Hat control), but also Ubuntu. Otherwise we could just not care about it anymore at this point.

I've never had GNOME work, on X11, or Wayland , it just sucks. Something is always broken even on default settings for GNOME Debian. Never had any issues with Kwin{FT,} on plasma

Oh please, stop using broken hardware or use a mainstream distro. Fedora, Ubuntu, and openSUSE all provide good implementations for GNOME and have for years. I'm using GNOME 46 on Xorg on Fedora 40 right now.

Mainstream distro? You mean the mainstream distros that force me to use Snap? No thanks.

Broken hardware? You mean the ThinkPad X220 and Ryzen 7800X3D systems I have. Yes, very broken!

I have Ryzen and Wayfire (Wlroots based) working just fine. Mate on wayland with a window list and icons on the desktop. This was supposed to be impossible but I proved otherwise by coding it up.

Fedora, Ubuntu, and openSUSE all provide good implementations for GNOME and have for years.

I never heard anyone praise Debian for their GNOME implementation.

implementation feels like the wrong word here configuration or distribution feels more right

It's all wlroots. Nothing works without wlroots.

Except the desktop environment "everyone" is using... it's so sad that many new Linux users get served Gnome by distributions - not only by Fedora (which is to be expected due to IBM Red Hat control), but also Ubuntu. Otherwise we could just not care about it anymore at this point.

It is one of many reasons to stop recommending these "mainstream distributions". Mint if someone is super novice and wants the easiest possible experience. Void or Arch for basically anyone wanting a workstation. Debian/Devuan for servers.

The ThinkPad I guess can be explained by the distro implementation, and I never heard anyone praise Debian for their GNOME implementation. Can't say I'd rule hardware out with Ryzen.

More likely is that Gnome is just bad, lol.

They finally woke up, almost according to my prediction, in an attempt to unite the whole GTK+ ecosystem beyond GNOME against GNOME: https://blog.linuxmint.com/?p=4675

Sadly, too late, and not in GTK+2 times, as GTK+3 has an awful rendering performance. This had to be done in times when Audacious and LXDE refused from porting to GTK+3, stayed on GTK+2 and were ported to Qt later.

I really hope the insanity of GNOME developers will finally make it as a marginal thing as Enlightenment is. Decades ego, E16 was much more open to integration with other environments, but further versions turned into a totally isolated and alien thing following crazy guidelines. Just like, well, GNUstep. Modern GNOME Shell is totally something akin to those.

Im facing some problems with KDE and Wayland, all the web apps like VS Code or web browsers are flikering on wayland sessions, some times it makes unusable all the apps.
For Brave Browser it function very well moving on brave://flags OzoneWayland to use wayland but the whole webapps are flikering and make it unusable.
And it happens on Fedora 40, Arch Linux and Ubuntu
I have been switch to X11 and the problems gone, but its compatibiliti with Nvidia it not the best like wayland, pros and cons.

Im facing some problems with KDE and Wayland, all the web apps like VS Code or web browsers are flikering on wayland sessions, some times it makes unusable all the apps. For Brave Browser it function very well moving on brave://flags OzoneWayland to use wayland but the whole webapps are flikering and make it unusable. And it happens on Fedora 40, Arch Linux and Ubuntu I have been switch to X11 and the problems gone, but its compatibiliti with Nvidia it not the best like wayland, pros and cons.

The problems is with the Nvidia drivers and lack of implicit sync and bad GBM support, since Nvidia only want to support explicit sync. Explicit Sync was added recently in the Linux kernel. This should be solved with the driver 555 from Nvidia that will be released this year. I hope that fixes all this.

Thanks for your answer, and it also fix the zoomed apps? everything looks bigger on waylando, like taskbar on KDE looks bigger compared with XORG

Thanks for your answer, and it also fix the zoomed apps? everything looks bigger on waylando, like taskbar on KDE looks bigger compared with XORG

I didn't hear about that problem, maybe it's a KDE problem, is everything big or just specific things?

I think it's just KDE things, window decorations like the title bars, the taskbar, for example the terminal in wayland by default looks much larger as if the pixels were not well calculated in wayland

first one screenshot its X11 and second one its wayland, as you can see both images have the same scroll on the page but in wayland its bigger compared with X11 yaou can see also the difference on title bars

Good Wayland v X11 thread: https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1461854-netbsd-on-the-state-future-of-x-org-x11

Thanks for the pointer. Looks like some people are waking up. Some of the points from this gist are discussed there as well. tl;dr:

• Wayland is Linux centric, leaving the BSDs in a lesser position (my 2 cents: not good)
• Some people think BSDs are not relevant on the desktop (my 2 cents: I'd like to help change that)
• People realize that Wayland leads to feature and bug fragmentation (my 2 cents: not good)
• Some people say "but it works for me on Gnome/KDE" (my 2 cents: that is besides the point)
• People realize that Wayland does not offer feature parity for all actively used X11 features (my 2 cents: not good)

Good Wayland v X11 thread

Aside from a large number of insults, maybe. Especially from mrg666 who calls anyone who he disagrees with a troll.

Strangely myownfriend has disappeared. Must be a day off for the dude. He always finds a way to turn Wayland deficiencies into advantages or downplays them as if they are irrelevant.

10 cents in total. My jar gets heavier.

I think it's just KDE things, window decorations like the title bars, the taskbar, for example the terminal in wayland by default looks much larger as if the pixels were not well calculated in wayland

first one screenshot its X11 and second one its wayland, as you can see both images have the same scroll on the page but in wayland its bigger compared with X11 yaou can see also the difference on title bars

Your images are broken for some reason. Are you in Plasma 6 of 5?

I think it's just KDE things, window decorations like the title bars, the taskbar, for example the terminal in wayland by default looks much larger as if the pixels were not well calculated in wayland
first one screenshot its X11 and second one its wayland, as you can see both images have the same scroll on the page but in wayland its bigger compared with X11 yaou can see also the difference on title bars

Your images are broken for some reason. Are you in Plasma 6 of 5?

I dont know why are broken :( but im on Plasma 6
Will try here


first one its wayland and second X11
both with same settings ej: Taskbar 32 px

I think it's just KDE things, window decorations like the title bars, the taskbar, for example the terminal in wayland by default looks much larger as if the pixels were not well calculated in wayland
first one screenshot its X11 and second one its wayland, as you can see both images have the same scroll on the page but in wayland its bigger compared with X11 yaou can see also the difference on title bars

Your images are broken for some reason. Are you in Plasma 6 of 5?

I dont know why are broken :( but im on Plasma 6 Will try here first one its wayland and second X11 both with same settings ej: Taskbar 32 px

Looks like even the web pages are bigger, did you try changing the scale in settings?

:O yup that solved the problem, I'm using Endeavor OS and every time I installed it everything always seemed much bigger apparently by default in Wayland it uses a scale of 125%, or I moved it by accident but it happened every time install it, now we just have to wait for the release of the 555 driver

I dont know why are broken :( but im on Plasma 6

The Wayland screenshot is blurry as hell.

Make sure you've enabled widget.wayland.fractional-scale.enabled in about:config or otherwise Firefox under Wayland looks like ass.

Too bad Thunderbird 115, the last stable version, still does not support this option and is basically unusable for me.

Maybe by 2040 linux will have a display server that matches windows in 2015. If this bad joke that is wayland and gtk 3+ starts to degrade the linux desktop too much, then I will just move back to windows and use my linux tools from wsl.

Im not sure if wayland and gtk devs have considered that they are in competition with windows and mac. They can try to perform a type of coupe and force themselves into dominant position of control over the linux desktop, but you can get access to all the power that headless linux has from other platforms.

Im not sure if wayland and gtk devs have considered that they are in competition with windows and mac.

There's none.

Windows of any version after at least Windows 2000 is known to contain at least one extra governmental signing key. Also Windows 10 and 11 contain all kinds of antifeatures related to privacy that are on by default, must be turned off, and who knows if that's all of the phone-home crap? Worst of all is the efforts to "nudge" people to logging into their desktop with a Microsoft account or any other online account, and the dangers that MS could attempt to turn Windows 11 into a subscription product. There is no amount of bugs, breakage, etc that could cause me to use Windows due to my particular needs, which include complete isolation of all systems from the ad and tracking world. The data they scarf up is traded on the open market and can find its way to "people finder" doxxing sites, law enforcement is a known and proven buyer as of a couple years ago, no doubt private investigators buy it, etc. Thus, I do not run Windows, and I do not use Google Play Services or Gapps on phones, the works. The only real issues with updates to hardware breaking things on the desktop are the kernel and GPU drivers. I don't see any new kernel that any new CPU must use coming out with neither x11 nor wayland support anytime soon.

Windows of any version after at least Windows 2000 is known to contain at least one extra governmental signing key.

I would be curious to know if ameliorated.info has ameliorated that - which I would assume so... I don't think it is impossible to run modern windows without the nonsense. However, it is impossible to run a modern computer/phone without a "management engine" that is transparent with respect to the OS. This is a bit off topic, but I didn't bring it up :) However, where I suppose the topics intersect is digital rights management control on open source operating systems - and potential funding & strategies for that. Maybe that would be entirely restricted to the GPU drivers - but maybe include the DE/WM as well.

For my purposes both digital rights management and all files dependent on it are banned from all of my hardware. The only use I have for such things is repurposing them for other purposes. Example: HDCP might be possible to use to encrypt all traffic from your computer to your monitor, so as to scramble the take for anyone sniffing for monitor signals to spy on your screen. While HDCP is broken, all the cracks for it depend on having access to the cable and probably on posession of the monitor in question. Might be unbroken for this use, but I don't know.

Other than that, I operate on a zero subscription model and do not purchase digital media of any type.

Windows of any version after at least Windows 2000 is known to contain at least one extra
governmental signing key.

We don't need conspiracy crap in this discussion.

and who knows if that's all of the phone-home crap?

Crap is solely in your head. Fire up Wireshark and show what Windows leaks. It literally takes 10 minutes to download it and enable MITM using your own SSL certificate. Considering Windows has been leaking left and right for over a decade now, we now must have had thousands of web pages documenting it. Where are they?

@probonopd

Hide or delete this reply. I don't want "Windows leaking data to MS/government" crap in this discussion.

Gist comments have no "hide" function, so the only option is to leave it as-is or delete.
So please let's stay on the topic of Wayland deficiencies in this gist and discuss unrelated topics elsewhere.
Posts that stray away from the topic too far may get deleted. Not something I like to do but it seems necessary to have a somewhat focused discussion.

Gnome people acknowledge that "GNOME Wayland" exists:

So it's not fixed for Wayland as a whole, just for "GNOME Wayland"?

Please read again what that post actually says. There is a new wayland protocol and gnome implements it in its wayland variant. Don't get me wrong, there are issues with wayland but you are actively framing and rewording things that were never said (nor implied).

@Consolatis

Please read again what that post actually says.

It says "GNOME Wayland", literally.

Yes, Gnome in its wayland variant compared to Gnome in its X11 variant. The post above frames it as if it was meant to say "wayland belongs to gnome and gnome only". Lets please keep being objective here and not maliciously frame things in this way.

Gist comments have no "hide" function, so the only option is to leave it as-is or delete.

Why have you even chosen Gist as the platform? It obviously bites for many reasons for this purpose.

Yes, Gnome in its wayland variant compared to Gnome in its X11 variant. The post above frames it as if it was meant to say "wayland belongs to gnome and gnome only".

It's worse: it somehow implies than X.Org is only a backend for Gnome, rather than gnome-shell being merely an ordinary X client which can be killed at any time in runtime and replaced with some other WM.

Why have you even chosen Gist as the platform?

Well... I have just used Gist to collect my thoughts, never would have expected more than 5 comments ;-)

Yes, Gnome in its wayland variant compared to Gnome in its X11 variant.

OK, that's one way to read it. I was reading it as "Wayland in its Gnome variant". But that is the thing - you can never know whether something that has been fixed in "Wayland" for one desktop will automatically make it work in all desktops.

Well... I have just used Gist to collect my thoughts, never would have expected more than 5 comments ;-)

And now you suddenly have a burden of moderating all of this.

I switched to sway so that I wouldn't have to recreate a workflow without having the fall back of x11. Of course this is under the assumption that x11 won't be an option at some point in the future thanks to the powers that be (so i might as well learn it now). While I have mostly been able to stick with sway/wayland, it has been one sacrifice after another with no gain to speak of for me. So for that reason my stance is that wayland (various implimentations and supporting software included) is an inferior product.

Hide or delete this reply. I don't want "Windows leaking data to MS/government" crap in this discussion.

lmao just close your eyes

But that is the thing - you can never know whether something that has been fixed in "Wayland" for one desktop will automatically make it work in all desktops.

Wayland can either refer to a collection of protocols or to a shared library that basically only handles the wire format. Many (but not all) compositors use that shared library so fixing a bug in there could indeed fix something in multiple compositors at once. In the case of the protocols.. they are just a bunch of XML files so any "fixes" there don't do anything at all. If a compositor supports a new version of a given protocol or not is completely up to the compositor. Same for which protocols it supports in the first place.

So to sum up: in most cases, a compositor "fixing" something will only "fix" it in that compositor. Other's might not have had the issue in the first place or decide against supporting some protocol or new version of a protocol (for example due to a lack of manpower or because of disagreement with the goals of the protocol).

Edit:
There are also libraries like wlroots or smithay, fixes there may obviously impact multiple compositors that use that library.

I switched to sway so that I wouldn't have to recreate a workflow without having the fall back of x11. Of course this is under the assumption that x11 won't be an option at some point in the future thanks to the powers that be (so i might as well learn it now). While I have mostly been able to stick with sway/wayland, it has been one sacrifice after another with no gain to speak of for me. So for that reason my stance is that wayland (various implimentations and supporting software included) is an inferior product.

What sacrifices have you made? I sacrificed nothing but gained a lot after the i3->sway transition.

I switched to sway so that I wouldn't have to recreate a workflow without having the fall back of x11. Of course this is under the assumption that x11 won't be an option at some point in the future thanks to the powers that be (so i might as well learn it now). While I have mostly been able to stick with sway/wayland, it has been one sacrifice after another with no gain to speak of for me. So for that reason my stance is that wayland (various implimentations and supporting software included) is an inferior product.

What sacrifices have you made? I sacrificed nothing but gained a lot after the i3->sway transition.

Sway does not support (and devs say will not support) i3 layouts or an equivalent. I can't find anything to replace xrandr's functionality. I couldn't get sunshine to actualy share the screen (eventually figured out the screen sharing is broken on wayland which Seems like something that is important to a lot of people.) For the one xorg application that I use on wayland, xrdb behaves erraticly, and I would randomly have to reload Xresources. Transparency issues that will not be fixed. Other things that I eventualy found work arounds for. etc... I'm glad that you haven't had to make sacrifices but I and may others have had a different experience. Since we're sharing experiences, what have you gained from switching to sway over i3?

Sway does not support (and devs say will not support) i3 layouts or an equivalent

What are i3 layouts? My config supports a load of different layouts.

I can't find anything to replace xrandr's functionality.

All that is handled by swaymsg.

I couldn't get sunshine to actualy share the screen (eventually figured out the screen sharing is broken on wayland which Seems like something that is important to a lot of people.)

I can't say for sunshine specifically, but if you have xdg-desktop-portal-wlr installed and running then any applications that support the portal protocol can screenshare on sway.

For the one xorg application that I use on wayland, xrdb behaves erraticly, and I would randomly have to reload Xresources. Transparency issues that will not be fixed.

I can't say for these as I've never heard of xrdb and never hears of anyone having transparency issues...

Since we're sharing experiences, what have you gained from switching to sway over i3?

Outside of sway having better configuration, I also noticed considerable performance gains, with marginally less RAM usage and great improvement in draw time and CPU/GPU usage. I later found out this is partially caused by Xorg having a weird obscure bug in their driver for that specific computer (it was an '06 laptop which sold terribly, nobody used it let alone Linux users). In spite of this, I still see marginal to decent improvement in draw time and resource usage even on my balls to the wall overpowered desktop running a 7800X3D and an RX6600. I imagine the compositor being built-in rather than running it separately is partially responsible.

I sacrificed nothing but gained a lot after the i3->sway transition.

YWNBAS.

What

https://copypastatext.com/wayland/

https://copypastatext.com/wayland/

You need to step up your trolling game. It has potential but is full of errors.
Like the forced vsync example: there is actually a tearing protocol which allows applications to opt-in to render broken frames and waste CPU and GPU resources.

Also the general assumption that wayland compositors are written to gain some popularity and make them famous is pretty ridiculous. There may be compositors out there that are maintained and written for personal use and because its fun to write and work in a team to enhance it. Corporate projects can be different obviously and there are definitely compositors out there that try to tell everybody that they are the best since sliced bread but you really can't generalize it that way.

Posting random links in here rather than writing what you have to say directly is also pretty weak.

What are i3 layouts? My config supports a load of different layouts.

It is i3's format for saving the current layout to disk so that you could easily script loading that exact layout later. When loading it would capture the programs as they are launched and everything would match the layout you manually created.

I can't find anything to replace xrandr's functionality.

All that is handled by swaymsg.

Much of it but not all of it. Particularly the color shifting. I had a script running in the background to shift yellow at a certain battery percentage while discharging and red for another percentage. Losing that ability sucks since in Sway the notifications don't show up when a window is in full-screen mode. I believe Wayfire is the only one who has implemented it and that was fairly recent.

I can't say for sunshine specifically, but if you have xdg-desktop-portal-wlr installed and running then any applications that support the portal protocol can screenshare on sway.

Well, that looks interesting. Are there any open-source applications that implement this in a low-latency remote desktop application like Sunshine/Moonlight? That would be awesome, and one less sacrifice.

I can't say for these as I've never heard of xrdb and never hears of anyone having transparency issues...

For some xorg applications that don't have their own configs, they can take configuration from an x resources database.
And as far as transparency it just doesn't behave the same way on sway as it did in i3 with picom. Sway community says those were violations of the standards so they have no interest in implementing that behavior. I don't agree with the standards on this. There are some patches that kinda work-ish, I'm not a dev so it would probably take me more time than it's worth to write a solution myself.

Outside of sway having better configuration, I also noticed considerable performance gains, with marginally less RAM usage and great improvement in draw time and CPU/GPU usage. I later found out this is partially caused by Xorg having a weird obscure bug in their driver for that specific computer (it was an '06 laptop which sold terribly, nobody used it let alone Linux users). In spite of this, I still see marginal to decent improvement in draw time and resource usage even on my balls to the wall overpowered desktop running a 7800X3D and an RX6600. I imagine the compositor being built-in rather than running it separately is partially responsible.

What do you consider better about Sway's config? It's pretty similar to i3's. I do prefer that sway has includes built-in but despite me being an amateur, I didn't find it difficult to script around not having includes.
I hear a lot about performance gains but I don't personally notice them. My system felt just as snappy/responsive on i3, If I have to open up benchmarking software to notice a difference then that difference is inconsequential to me. I don't usually do graphicly intense things on my daily driver. I'd much prefer to not lose functionality that impacts my daily workflow/usage. Aside from the screen sharing, for which I briefly switch back to x11 on that box (fortunately I can accomplish that switch over SSH), nothing else is a deal breaker, Just a collection of small sacrifices. But those sacrifices do impact my opinion of Wayland vs Xorg.

Well, that looks interesting. Are there any open-source applications that implement this in a low-latency remote desktop application like Sunshine/Moonlight? That would be awesome, and one less sacrifice.

A looooong time ago I remember reading about a VNC protocol in the works for Wayland. I have no idea how far it's gotten or if it still exists. I think there is some kind of way to do remote desktop though.

What do you consider better about Sway's config?

It's been so long since I used i3 that I can't recall the specifics, lol. All I really know is that my i3 config was a lot more clunky than sway for whatever reason (skill issue is possible). Also, I like waybar a lot more than polybar.

For performance I do many graphics intensive tasks on my desktop, while my older laptop is just unbelievably underpowered. For my X220 where I don't do many graphically intensive things while its still decently powerful, I don't see much difference. Just a veeery slight increase in snappiness.

For sway (and other wlroots based compositors): https://github.com/any1/wayvnc/

For sway (and other wlroots based compositors): https://github.com/any1/wayvnc/

This is what I was thinking of. I believe the consensus in that discussion that once KWin used wlroots (now KwinFT), that would be the standard.

Pushing wayland onto people: it is enabled by default in ubuntu 22.

Breaking stuff: found right after the first reboot when upgrading from 20 on an old machine as I could not access it with x11vnc.
I guess they are ways around (working in some or all cases) but I don't care or have time to get basic things to work again: it's a small server doing a few things, not the project of my life. The linux machines I admin and use for work don't have any display anyways so I don't care.
Linux is not a religion or a hobby for me. It's a tool.

At windows haters: you can still run 20+ years old applications on windows 10. Open 30 years old office files.

@phourglass

At windows haters: you can still run 20+ years old applications on windows 10. Open 30 years old office files.

Windows 11 and Ubuntu 22 compete to see who has degraded the most. :)

...and Ubuntu wins easily (thanks to Wayland and Snap). Typing this from Windows 11. So sad.

For sway (and other wlroots based compositors): https://github.com/any1/wayvnc/

So each wayland flavour needs its own vnc implementation?

kwin vnc
wlroots vnc
mutter vnc
?

For sway (and other wlroots based compositors): https://github.com/any1/wayvnc/

So each wayland flavour needs its own vnc implementation?

kwin vnc wlroots vnc mutter vnc ?

@hendrack Yes.

...and Ubuntu wins easily (thanks to Wayland and Snap). Typing this from Windows 11. So sad.

Fortunately there is still Xubuntu + Xfce which limits the damage.

For sway (and other wlroots based compositors): https://github.com/any1/wayvnc/

So each wayland flavour needs its own vnc implementation?

kwin vnc wlroots vnc mutter vnc ?

Fortunately only one of these actually works, so only one implementation is needed.

For sway (and other wlroots based compositors): https://github.com/any1/wayvnc/

So each wayland flavour needs its own vnc implementation?
kwin vnc wlroots vnc mutter vnc ?

Fortunately only one of these actually works, so only one implementation is needed.

I've tried the kde vnc client and other than screen, I could not control anything. It recently broke or something, who knows.
Or perhaps its only cause I use Fedora on mac m1 (asahilinux) ...

...and Ubuntu wins easily (thanks to Wayland and Snap). Typing this from Windows 11. So sad.

Wins what? Or this is sarcasm? I don't get why engineers give Ubuntu & RedHat so much free press considering most that have honestly looked into it have better distro preferences (whether for personal workstation or server) with good reasons to cite. Like I described more thoroughly in this thread, an OS/distro is a meaningful and useful unit of abstraction to consider for the purposes of software development - especially regarding the pain-points discussed here.

Fortunately only one of these actually works, so only one implementation is needed.

You're American, you need only one keyboard layout, no surprise you somehow believe Sway "works".

XKB_DEFAULT_LAYOUT env var..

env var.

Pfff.

Runtime switching of layout sets means nothing for you, right?

I did even experiment with my own layouts, so I had to reload them often.

Runtime switching of layout sets means nothing for you, right?

XKB_DEFAULT_LAYOUT=de,us
XKB_DEFAULT_OPTIONS=grp:alt_shift_toggle

← You ←

 . My point

Runtime switching of sets is

setxkbmap us,ru,ua
setxkbmap us,gr,ua
setxkbmap us,ar,ua
setxkbmap 'us,ru,ua(aesthetic)'
setxkbmap 'us,ru,ua(shavian)'

...and Ubuntu wins easily (thanks to Wayland and Snap). Typing this from Windows 11. So sad.

Wins what? Or this is sarcasm? I don't get why engineers give Ubuntu & RedHat so much free press considering most that have honestly looked into it have better distro preferences (whether for personal workstation or server) with good reasons to cite. Like I described more thoroughly in this thread, an OS/distro is a meaningful and useful unit of abstraction to consider for the purposes of software development - especially regarding the pain-points discussed here.

@dm17 I think he is replying to the these comments:

At windows haters: you can still run 20+ years old applications on windows 10. Open 30 years old office files.

Windows 11 and Ubuntu 22 compete to see who has degraded the most. :)

So he's saying Ubuntu easily wins the race toward trashing itself.

@probonopd in my opinion Windows took a flying leap into the trash with Windows 8. I think I used Windows 10 breifly and I've been full time linux ever since so I don't know much about anything after. Last time I used ubuntu was with a live usb to do one task so I usually don't have snaps shoved down my throat. But I believe you can use other deb package repos like Debian's and Cinnamon's and stuff mostly works, so at least there is some escape from Ubuntu's crap.

Fortunately only one of these actually works, so only one implementation is needed.

You're American, you need only one keyboard layout, no surprise you somehow believe Sway "works".

I'd gladly believe you if all three of your points were correct. Also, wlroots is more than sway... I've used other wlroots WMs (KwinFT mostly) and they work just as well. Layout switching has worked well for me through a simple rofi script.

wlroots is more than sway

That's the point: there is still no generic mechanism. Wayfire has implemented it by reloading its config at runtime. Nice solution, hehe.

I'm delving through the Pango source code to hunt a bug and discovered there are areas which remain unchanged since 00s:

Hilariously, the only modern change there by modern GOOME developers is for migrating to the new documentation generator. The one which requires JS, unlike the old static HTML one, which still isn't a complete replacement, and which they manage to put down from time to time which already caused butthurt to me and totally not just to me.

I doubt there still is even a single person who remembers how this code works. Still, no one seems to whine that Pango is dying like X.Org, because of bitrot. Think about it.

Still, no one seems to whine that Pango is dying like X.Org, because of bitrot. Think about it.

You know what else was likely not changed in forever? The yes command. Think about it.

wlroots is more than sway

That's the point: there is still no generic mechanism. Wayfire has implemented it by reloading its config at runtime. Nice solution, hehe.

wlroots supports it natively and wayfire's solution is stupid.

wlroots supports it natively

What do you mean exactly? The aforementioned environment variable mechanism is not dynamic.

The yes command

Nice derailing attempt, but Pango is definitely way more complex. And text rendering is not cast in stone since 00s, at least combined emojis appeared since then. BTW, the genmon plugin for xfce4-panel has drastically increased RAM usage several years ago when I upgraded Pango to a version supporting fonts with embedded colourful images.

The yes command

Nice derailing attempt, but Pango is definitely way more complex. And text rendering is not cast in stone since 00s, at least combined emojis appeared since then. BTW, the genmon plugin for xfce4-panel has drastically increased RAM usage several years ago when I upgraded Pango to a version supporting fonts with embedded colourful images.

Yes, that was exactly my point. You were comparing Pango to X11.

What do you mean exactly? The aforementioned environment variable mechanism is not dynamic.

Keyboard layout switching is supported in wlroots natively, not through whatever Wayfire does. It supports XKB and can switch at runtime for 7 years now.

A fellow user just reported running a highly demanding patched game with an old lwjgl version runs pretty poorly on wayland KDE plasma6. Switched to X11 and it was immediately playable.
So much for backwards compatibility.

I knew already, X11 performs better for such an old game, but now I got confirmation.

Seems like the return of blackouts in Ukraine would finally motivate me to pay more attention to Wayland, huh?


BTW, I wondered if my anti-GUI ideology and the belief (justification, rather) that the text mode is beneficial in terms of power consumption is still relevant on modern video cards which don't support the text mode natively anymore. Back then, one of primary reasons of my migration to GNU/Linux was the deprecation of text mode in Windows: Alt+Enter doesn't work in CMD.EXE with WDDM anymore, and later (in Windows 10?) they replaced it with a fake fullscreen mode. Back in my student years, I had spent a lot of time in the framebuffer console, being one of the few text mode idelogists on L.O.R. (the other one was saahriktu), and installed a lot of tools like fbi/fim/fimgs/fbterm (Vim/elinks work there "for free") to survive there without having to make a sluggish switch to the X.Org VT. (Wayland totally wasn't ready to use in any form on bare hardware that years.)

And you know what? the consumption is also around 9W when in a text TTY, hehe. X.Org (or Compiz?) consumes energy merely by repaints, so having it in a separate inactive VT doesn't matter much.

(I wonder what would happen if I launch that many windows in Wayfire session, hehe. Or replace Compiz with some lighter WM with no compositing. Wait for more tests.)

The consumption barely changed when I replaced Compiz with Openbox. But it dropped to 9W too when I minimized (almost) all the windows, hehe.

Yeah, just launched Chromium and it's like this:

Case closed, it's not X11, it's GUI apps who are greedy.

I have no idea how anyone is continuing to follow this discussion,* so I decided to ask one of those large neural networks for some help.†

Queries

I've attached 500 comments on a controversial blog post about Wayland vs Xorg. Summarize both sides of the debate.

Based on the 500 comments, there seem to be two main sides to the debate around Wayland vs Xorg:

Arguments critical of Wayland:

• Wayland breaks compatibility with many existing Linux applications and tools that were built for Xorg, requiring them to be ported or patched to work with Wayland compositors. This places a burden on application developers.
• Wayland lacks some features and capabilities that Xorg has, like global hotkeys, controlling mouse cursor position, screen capture/sharing in some cases, color management, etc. Implementing these often requires using additional libraries or Wayland protocol extensions.
• Wayland compositors lack consistency - things that work on GNOME's Mutter may not work the same way on KDE's Kwin or Sway. More standardization is needed.
• Some see Wayland as being biased towards or controlled by GNOME/Red Hat/Fedora and not caring about other environments.
• As a newer, less mature protocol, Wayland may have more undiscovered security issues compared to the battle-tested Xorg.

Arguments in favor of Wayland:

• Xorg is old, archaic and has accumulated a lot of bloat over the years with its many extensions. It has fundamental architectural limitations that are hard to change. A fresh, modern protocol is needed.
• Wayland has some technical advantages over Xorg, like better performance, smoother graphics, easier HiDPI and mixed refresh rate support, more secure architecture.
• Many of the lacking features can be implemented as Wayland protocol extensions without the core protocol getting bloated. Libraries like wlroots make it easier to implement compositors.
• With toolkits like GTK and Qt supporting Wayland and projects like PipeWire, XDG desktop portals providing key functionality, most applications work fine on Wayland now with a few exceptions. XWayland provides backwards compatibility for X11 apps.
• As Wayland matures and gains adoption, remaining issues and gaps in functionality will get ironed out. But this is a gradual transition and some breakage is inevitable in the process of replacing something as entrenched as Xorg.

In summary, opponents see Wayland as immature, not respecting existing ecosystem/workflows, and trying to force change for change's sake. Proponents see it as a necessary modernization step for the Linux graphics stack to overcome Xorg's legacy limitations, even if the transition is painful. The debate is often quite heated and emotional on both sides.

Here are the last 100 comments. What issues remain to be resolved among the participants—or is the debate simply running in circles?

Based on the last 100 comments, it seems the debate is largely running in circles at this point, with a few new specific issues being raised but no real progress or consensus being reached.

The main recurring points of contention appear to be:

1. Wayland's readiness and feature-completeness compared to X11. Critics argue it is still lacking key functionality and consistency across implementations, while proponents say it is usable for most people's needs now.

2. The fragmentation of Wayland implementations across different desktop environments and the lack of universal standards for certain features. This is seen as a regression from X11's uniformity.

3. Whether the architectural changes in Wayland are justified improvements or needlessly disruptive changes that burden application developers. There is disagreement on how much of an improvement Wayland actually provides over X11.

4. The influence/control of GNOME, Red Hat, and other major corporate players over the direction of Wayland and surrounding technologies like systemd, compared to the more decentralized development of X11.

5. Some debate over the backwards compatibility story - how well Wayland supports legacy X11 applications and workflows.

A few new specific pain points were brought up, like issues with screen sharing, VNC remote access, color management, keyboard layout switching, and performance regressions for some games. But in general, the discussion seems to be rehashing earlier arguments rather than reaching any new understanding or agreement.

Both sides appear quite entrenched in their views at this stage. The Wayland critics see it as an immature, over-hyped and politically driven change that is shattering the X11 ecosystem to serve corporate/GNOME interests. The Wayland advocates argue it is a overdue modernization of the Linux graphics stack that is already usable and will only get better, and that X11 is an unmaintainable legacy system holding back progress.

Some frustration and animosity is evident between the camps, with accusations of shilling, trolling and spreading FUD. But no clear resolution seems in sight, as the debate has deadlocked into restating grievances rather than finding common ground. The intractability of some architectural differences between X11 and Wayland makes compromise challenging.

Code for this

#!/usr/bin/env python3
# -*- coding: utf-8 -*-

import github
from github import Github

import json

from util import *

def serialize_datetime(dt):
    return dt.strftime('%Y-%m-%d %H:%M:%S')

def serialize_user(user):
    if hasattr(user, 'login'):
        return {
            'login': user.login,
            'id': user.id,
            'avatar_url': user.avatar_url,
            'html_url': user.html_url
        }
    elif user is not None:
        return {
            'deleted': True,
            'raw_extra_data': dict(user)
        }
    else:
        return {
            'deleted': True
        }

class SerializableGistComment:
    def __init__(self, comment):
        self.comment = comment

    def serialize(self):
        return {
            'id': self.comment.id,
            'body': self.comment.body,
            'created_at': serialize_datetime(self.comment.created_at),
            'updated_at': serialize_datetime(self.comment.updated_at),
            'user': serialize_user(self.comment.user)
        }

    def to_json(self):
        return self.serialize()

class Gist:
    def __init__(self, username, gist_id, token=None):
        if token:
            self.g = Github(token)
        else:
            self.g = Github()
        self.username = username
        self.gist_id = gist_id
        self.gist = None
        self.comments = None
        self.get()

    def get_gist(self):
        self.gist = self.g.get_gist(self.gist_id)
        eprint('Got gist:', self.gist.description)

    def get_comments(self, max_comments=None):
        self.comments = []
        i = 1
        for comment in self.gist.get_comments():
            comment = SerializableGistComment(comment)
            self.comments.append(comment)
            eprint("Got comment №{}: {}".format(i, comment.comment.body))
            i = i + 1
            if max_comments is not None and max_comments > -1 and i > max_comments:
                eprint('Gist has more than {} comments, stopping'.format(max_comments))
                break
        eprint('Got {} comments'.format(len(self.comments)))


    def get(self):
        self.get_gist()
        self.get_comments()

    def serialize(self):
        return {
            'id': self.gist_id,
            'description': self.gist.description,
            'files': {name: {'language': file.language, 'content': file.content, 'filename': file.filename, 'size': file.size, 'raw_url': file.raw_url}
                      for name, file in self.gist.files.items()},
            'comments': self.comments,
            'created_at': serialize_datetime(self.gist.created_at),
            'updated_at': serialize_datetime(self.gist.updated_at),
            'owner': serialize_user(self.gist.owner),
            'html_url': self.gist.html_url,
            'public': self.gist.public,
            'comments_count': len(self.comments)
        }

    def to_json(self):
        return json.dumps(self.serialize(), indent=4, default=gist_comment_serializer)

def gist_comment_serializer(obj):
    if hasattr(obj, 'serialize'):
        return obj.serialize()
    else:
        raise TypeError('Object of type {} is not serializable'.format(type(obj)))

if __name__ == '__main__':
    import os
    import sys

    get_github_token_from_env_file_if_exists()

    assert len(sys.argv) == 3, 'Usage: {} <username> <gist_id>'.format(sys.argv[0])
    username, gist_id = sys.argv[1], sys.argv[2]

    token = os.getenv('GITHUB_TOKEN')
    if token is None:
        eprint('Warning: GITHUB_TOKEN is not set, you may encounter rate limit.')

    gist = Gist(username, gist_id, token)

    print(gist.to_json())

python getgist/gist.py probonopd 9feb7c20257af5dd915e3a9f2d1f2277 > 9feb7c20257af5dd915e3a9f2d1f2277.json
jq -r '.comments[]|[.user.login, .body]|@tsv' < 9feb7c20257af5dd915e3a9f2d1f2277.json > 9feb7c20257af5dd915e3a9f2d1f2277_comments.tsv

Notes

* Even loading the whole thing is proving impossible, so I had to use GitHub's API's to put it all in one large Markdown file which I could then attempt to read.
† “Claude AI Opus 3”, it'll probably be out of date by tomorrow so that's not important.

10/10 method name get_github_token_from_env_file_if_exists i hope it does what it says

Good catch, I forgot to attach util.py, but you'll be glad to know it does:

#!/usr/bin/env python3
# -*- coding: utf-8 -*-

# getgist utilities

import os
import sys
import warnings
from pathlib import Path

def eprint(*args, **kwargs):
    print(*args, file=sys.stderr, **kwargs)

def get_github_token_from_env_file_if_exists():
    env_file = Path('.env')
    if env_file.exists():
        with env_file.open() as f:
            for line in f:
                key, value = line.strip().split('=', 1)
                if key == 'GITHUB_TOKEN':
                    os.environ['GITHUB_TOKEN'] = value
                else:
                    warnings.warn('Unknown key in .env file: {}'.format(key))
    return None

Okay, okay, got it, Wayland matters and we widget developers need to adapt.
From our side, a "pure Wayland with wlroots" target is on the way, but moving from Form X11 to Wayland is not "out of the box" and will take time.

So, one of our solutions to become "pure Wayland" would be to use SDL (we already have this target working):
https://jan.newmarch.name/Wayland/SDL/

What do you think about SDL-Wayland, does it work well and can it be called a “pure Wayland” application?

My personal migration plan for when or if the day comes that I buy graphics hardware which is supported in the Linux kernel, but which is not supported by Xorg, due to abandonment of its development on GNU/Linux more broadly, is to just run fullscreen Xwayland with some Xorg supporting window manager.

Is there some reason of which I'm unaware that makes this unworkable? If not, I'm not sure what all of the fuss is about, really. :) !

Come on, you have to know what's inferior by now :p Why are you typing that from W11 and not W10 LTSC?

Why would you not use Spectre if you're using Windows?

Nice job @ctrlcctrlv! Would you mind asking it what it thinks a reasonable amount of years to catch up would be? Or if there should be a cut off or due date before another option is considered?

My personal migration plan for when or if the day comes that I buy graphics hardware which is supported in the Linux kernel, but which is not supported by Xorg, due to abandonment of its development on GNU/Linux more broadly, is to just run fullscreen Xwayland with some Xorg supporting window manager.

Is there some reason of which I'm unaware that makes this unworkable? If not, I'm not sure what all of the fuss is about, really. :) !

today Xorg uses a generic driver called "modesetting" that works in a similar way to Wayland, using kms/drm kernel infrastructure. So it is unlikely that in the foreseeable future there will be any boards that do not work at all on Xorg. However, it is possible that in the very distant future some proprietary drivers will be discontinued (Nvidia)

a fun screenshot for people to see something fun.

probono doesn't update the OP so this is just an image i think is pretty good, I can do this again with a freebsd desktop in a couple years (because freebsd doesn't have good modesetting support for dg2).

My personal migration plan for when or if the day comes that I buy graphics hardware which is supported in the Linux kernel, but which is not supported by Xorg, due to abandonment of its development on GNU/Linux more broadly, is to just run fullscreen Xwayland with some Xorg supporting window manager.

Is there some reason of which I'm unaware that makes this unworkable? If not, I'm not sure what all of the fuss is about, really. :) !

I think a bigger problem for you at that point is going to be finding X11 windows managers that are still maintained and that work on modern linux.

As long as Linus Torvalds manages Linux, "modern Linux" shall not break userland (source). So existing userland software should continue to run on newer versions of the Linux kernel pretty much indefinitely. Many X11 window managers are mature by now, can be used as-is and are pretty much maintenance-free (read: ideal) nowadays. No need to fix what is not broken.

https://www.linux.org.ru/news/opensource/17630584?cid=17633042

TL;DR: IPv6 is like Wayland, just 15 years older. It's 30 years old soon, and half of the planet still ignores it.

I think a bigger problem for you at that point is going to be finding X11 windows managers that are still maintained and that work on modern linux.

Compiz is long abandoned, yet I'm still using it somehow. How?

Things don't magically break if you don't touch them.

today Xorg uses a generic driver called "modesetting" that works in a similar way to Wayland, using kms/drm kernel infrastructure. So it is unlikely that in the foreseeable future there will be any boards that do not work at all on Xorg. However, it is possible that in the very distant future some proprietary drivers will be discontinued (Nvidia)

Then why the Macbook video driver in Asahi Linux only supports Wayland?

My personal migration plan for when or if the day comes that I buy graphics hardware which is supported in the Linux kernel, but which is not supported by Xorg, due to abandonment of its development on GNU/Linux more broadly, is to just run fullscreen Xwayland with some Xorg supporting window manager.
Is there some reason of which I'm unaware that makes this unworkable? If not, I'm not sure what all of the fuss is about, really. :) !

I think a bigger problem for you at that point is going to be finding X11 windows managers that are still maintained and that work on modern linux.

Like IceWM, for example?

today Xorg uses a generic driver called "modesetting" that works in a similar way to Wayland, using kms/drm kernel infrastructure. So it is unlikely that in the foreseeable future there will be any boards that do not work at all on Xorg. However, it is possible that in the very distant future some proprietary drivers will be discontinued (Nvidia)

Then why the Macbook video driver in Asahi Linux only supports Wayland?

The Software Rendering was faster on Asahi running xorg.
With the GPU driver, they went to use Wayland and found that faster.

Has this been posted in this thread? Sorry, it if has been:

Has this been posted in this thread? Sorry, it if has been:

@birdie-github I already posted it, but thanks for saving the picture because the author on reddit deleted it.

Missing clipboard API over dbus. What is that nonsense?

As long as Linus Torvalds manages Linux, "modern Linux" shall not break userland (source). So existing userland software should continue to run on newer versions of the Linux kernel pretty much indefinitely. Many X11 window managers are mature by now, can be used as-is and are pretty much maintenance-free (read: ideal) nowadays. No need to fix what is not broken.

Yes, however glibc does not keep that promise. In fact it changes its ABI fairly often.

Yes, however glibc does not keep that promise. In fact it changes its ABI fairly often.

No, it is because some devs use glibc the wrong way. If you use the great feature of symbol versioning for each method called, the compatibility is maintained, even if your code uses the old GLIBC_2.2.5 symbol table.

And just like Wayland, it's technically better in every way, and it is steadily gaining adoption

Not a fair comparison at all. You'd have to find equivalent criticisms of ipv6. I don't see anything technically wrong with it. The fact that it wasn't so quickly and completely replacing ipv4 is not due to issues with ipv6. However, the primary reason Wayland hasn't wiped the floor with xorg is that it isn't so great technically. It is inferior in ways and not superior enough where it counts. We've been over this ad nasueum in this thread, but I wanted to point out the apples to oranges comparison.

Maybe if all the developers here who are crying about Wayland's problems (I'm one of them) decided NOW to target X12 (of course backward compatible with X11), X12 would work before all of Wayland's problems are fixed.
And given the remarkable work of XWayland, I'm sure it would be possible to create a "new X11" with the absolutely necessary new features of Wayland (if there are any).

That sounds like a great idea. Suggest opening a MR over at https://gitlab.freedesktop.org/xorg/proto/xorgproto and https://gitlab.freedesktop.org/xorg/xserver. Also maybe for GTK, Qt, SDL and other GUI frameworks. Should not take longer than a week to get everything designed, written and merged.

I don't see anything technically wrong with it

Wayland inventors don't see anything technically wrong with it too. The problem is with adapting it to reality rather than to isolated fantasies of idealists.

From the same thread: https://apenwarr.ca/log/20170810

That sounds like a great idea. Suggest opening a MR over at https://gitlab.freedesktop.org/xorg/proto/xorgproto and https://gitlab.freedesktop.org/xorg/xserver. Also maybe for GTK, Qt, SDL and other GUI frameworks. Should not take longer than a week to get everything designed, written and merged.

If you are talking about X12 (with the few absolutely necessary new features of Wayland), the adaptation for GUI widgetsets X11 compatible will be a funny game. Of course if the spirit of X11 is maintained (like atoms, ... etc).

And it would also be good, before asking something from the X11 developers, to discuss here what would be absolutely necessary to add in the new X12 version.

And a fantastic project like wine, which managed to create a Windows emulator that works even better than all official Windows versions (thanks to X11), could retain this status (which it lost with the wayland-wine version).
The same for XQuartz for Mac.

You know, there is still Arcan. I bet they would appreciate some manpower and resources.

You know, there is still Arcan. I bet they would appreciate some manpower and resources.

Does Arcan have an out of the box solution for GUI widget sets containing code for X11 or do they all need to be rewritten like when using Wayland?
The huge advantage of an X12 version compatible with X11 is that the immense stock of application code using X11 would not be lost.

And a fantastic project like wine, which managed to create a Windows emulator that works even better than all official Windows versions (thanks to X11), could retain this status (which it lost with the wayland-wine version).

Wine can run ~40% of windows applications I've tried on Wayland. Wine can run the exact same amount of Windows applications, if not a bit less, on X11.

Wine can run ~40% of windows applications I've tried on Wayland. Wine can run the exact same amount of Windows applications, if not a bit less, on X11.

By default, Wine runs on Wayland through Xwayland, are you sure you used the native wine-Wayland driver?

And about your ~40%, maybe, but here on X11 100% of the Windows apps that I need are working (an only 10% with wine-Wayland driver) .

Yes, I was running wine-wayland

Now that Wayland is on multiple distributions and tested, what Wayland features should definitely be added for a possible X12?
It might be interesting if we shared our hopes here.

Has this been posted in this thread? Sorry, it if has been:

This image makes no sense. Why on X11 are all window managers contained in one rectangle, while on Wayland each compositor is placed in a different box? Furthermore, XWayland is only needed for X11 compatibility, if it is present in the Wayland diagram, equivalently something for Wayland compatibility should be present in Xorg

This image makes no sense. Why on X11 are all window managers contained in one rectangle, while on Wayland each compositor is placed in a different box? Furthermore, XWayland is only needed for X11 compatibility, if it is present in the Wayland diagram, equivalently something for Wayland compatibility should be present in Xorg

I also think it's strange that compositors and window managers are not properly distinguished. these are often split and different.
(X11 compositors are also a god-damn terrible thing since they can break rendering in ways which (unlike with wayland where expectations are clear) are not properly communicated (if anyone disagrees then I'd be happy if you could help me set a wallpaper in a way that makes picom render it correctly))

This image makes no sense. Why on X11 are all window managers contained in one rectangle, while on Wayland each compositor is placed in a different box? Furthermore, XWayland is only needed for X11 compatibility, if it is present in the Wayland diagram, equivalently something for Wayland compatibility should be present in Xorg

I also think it's strange that compositors and window managers are not properly distinguished. these are often split and different. (X11 compositors are also a god-damn terrible thing since they can break rendering in ways which (unlike with wayland where expectations are clear) are not properly communicated (if anyone disagrees then I'd be happy if you could help me set a wallpaper in a way that makes picom render it correctly))

I admit that all this is still obscure.

If you are creating an X11 GUI application, after compilation you need to link to 'libX11.so.6' and maybe the most used dependencies 'libXft.so', 'libXrender.so', ...
And your application will work regardless of which compositor/window manager you use.

But for Wayland GUI application, you have to write code for Wayland and for the compositor used.

That's what I understood.

But for Wayland GUI application, you have to write code for Wayland and for the compositor used.

The way I understand it:

You can write a GUI application for Wayland and it should run on all Wayland compositors, but since not all compositors support all features, functionality may be broken in different ways on each of them.

But for Wayland GUI application, you have to write code for Wayland and for the compositor used.

The way I understand it:

You can write a GUI application for Wayland and it should run on all Wayland compositors, but since not all compositors support all features, functionality may be broken in different ways on each of them.

So, I haven't yet figured out how to create a compositor-agnostic Wayland GUI app.

But for Wayland GUI application, you have to write code for Wayland and for the compositor used.

The way I understand it:
You can write a GUI application for Wayland and it should run on all Wayland compositors, but since not all compositors support all features, functionality may be broken in different ways on each of them.

So, I haven't yet figured out how to create a compositor-agnostic Wayland GUI app.

If you are using only stable protocols, it should work in all compositors

@alfredon996

Why on X11 are all window managers contained in one rectangle, while on Wayland each compositor is placed in a different box?

Because an X11 window manager is totally optional software (as I demonstrated above by writing a simple X11 client which is capable of changing its window geometry itself with no running WM).

With Wayland it's totally not the case, you cannot run some ordinary "Wayland" software (if you don't consider Weston as such). You have to run some compositor, and all compositors provide significantly different flavours of "Wayland".

If you are using only stable protocols, it should work in all compositors

Useless suggestion. In case of tachycardia, cut the heart out and use only stable organs?

Oh, and I didn't even start the topic of incompatible blood types. How do I write generic blood which works for all blood types and Rh factors, and for minor cases of angitens incompatibility as well, like Kell, Kidd, Duffy, MNSs, etc.?

With Wayland it's totally not the case, you cannot run some ordinary "Wayland" software (if you don't consider Weston as such). You have to run some compositor, and all compositors provide significantly different flavours of "Wayland".

You can run ordinary "wayland" software. The window can composite itself over DRM with minimal LOC.

You can run ordinary "wayland" software. The window can composite itself over DRM with minimal LOC.

You seriously believe a single Wayland app will ever do that? Why? LMAO, what a joke.

I don't recall any widespread apps designed to work like that but is so low-overhead that you could probably slap it onto any application you wanted.

I don't recall any X11 apps that were meant to run without a window manager either. In the end, you actually end up with less overhead on Wayland thanks to everything talking client->compositor->DRM, not client->compositor(optional) -> WM -> server -> DRM

Though, this is perhaps an unfair comparison since an X11 compositor and a Wayland compositor are fundamentally dissimilar concepts.

I don't recall any X11 apps that were meant to run without a window manager either. In the end, you actually end up with less overhead on Wayland thanks to everything talking client->compositor->DRM, not client->compositor(optional) -> WM -> server -> DRM

The point is that when developing an X11 application, you don't have to worry about which window manager will be used.
But yes, the X11 application will of course work with a window manager (if installed).

To summarize, Wayland certainly has many qualities but, instead of doing everything to attract developers, everything seems to be done to discourage them, obsolete docs and demos, war of compositors, ...

And like it or not, the end developers of the applications that will run on Wayland are the key to Wayland's possible success.

Or perhaps Wayland's policy is "only for applications made by tenors, who of course do not forget to give alms".

Lets face it though, if you use GTK or Qt your application just magically works fine on wayland. Unless you used X11 specific functions manually instead of via the toolkit wrapper. Also, frameworks have a bunch of X11 WM workarounds in place. Just because you don't see them when writing your application doesn't mean that all WMs behave the same way.

Lets face it though, if you use GTK or Qt your application just magically works fine on wayland.

Yes, thank you, I know that.
The problem is that I don't want to use GTK or QT, all my apps use another widgetset that don't have the tons of bugs of those big Tenors.
And making that other widgetset Wayland-compatible is just boring, tedious, unappealing and ultimately only focused on Linux (while destroying its philosophy).

Why is it only focused on Linux? FreeBSD for example works fine (at least for wlroots based compositors). And the philosophy of X11 protos vs wayland protos is really the same. Both have a required core and lots of optional extensions.

@Consolatis

And the philosophy of X11 protos vs wayland protos is really the same. Both have a required core and lots of optional extensions.

No. Wayland doesn't have any "core" because there is no unified server. Nobody cares that there is some "core" specification. This core specification without implementation is nothing. Moreover, this core specification is obviously insufficient.

Wayland's philosophy is very simple - “we'll write an incompatible server for our DE from scratch, now do the same to compete with us, let's see if you have the enough resources”. The architecture based on this philosophy is inherently flawed.

If you want to stay sane, don't play this game.

The Wayland inventors don't care that users and the entire ecosystem will suffer. All for the sake of Wayland cargo cult.

Why is it only focused on Linux? FreeBSD for example works fine (at least for wlroots based compositors). And the philosophy of X11 protos vs wayland protos is really the same. Both have a required core and lots of optional extensions.

OK, so I'm going to ask you again because you're a connoisseur of Wayland.
Could you please show the code for a simple, fully functional demo using a wlroots compositor, out-of-the-box, ready to use and not obsolete?

Tip: If you can't find one, here are the working codes for all chapters in the Wayland-book: https://wayland-book.com/

Original C++ code (updated and fixed):
https://github.com/fredvs/wayland-pascal/tree/main/src/c

Translated Pascal code:
https://github.com/fredvs/wayland-pascal/tree/main/src

Like in the Wayland-book, the last chapter is how to use the compositor and is on the "TODO" world.

Many thanks.

The problem is that I don't want to use GTK or QT, all my apps use another widgetset that don't have the tons of bugs of those big Tenors.

The "bugs" you're facing are caused more so by your incompetence, because I've never seen any show-stopping bugs that don't get fixed by a single extra LOC.

The problem is that I don't want to use GTK or QT, all my apps use another widgetset that don't have the tons of bugs of those big Tenors.

The "bugs" you're facing are caused more so by your incompetence

Thanks for the interesting tip.

Also note that I switched to another widgetset to avoid the numerous incompatibilities between versions (GTK1 vs GTK2 vs GTK3, Qt4 vs Qt5), the huge need for dependencies, and that, for audio applications, this eats up latency.

But that's another story, let's talk about Wayland and its open doors.

Could you please show the code for a simple, fully functional demo using a wlroots compositor, out-of-the-box, ready to use and not obsolete?

https://github.com/emersion/hello-wayland could be an example. Took me like 2 minutes to find, compile and test.

Wayland doesn't have any "core" because there is no unified server. Nobody cares that there is some "core" specification. This core specification without implementation is nothing.

Some parts of the core (e.g. what is defined in libwayland via wayland.xml) + xdg-shell (from wayland-protocols) should be enough for a basic application (also used by ^). For sane compositors (e.g. basically everything other than gnome) I would also add the decoration protocol so you have some proper server side decorations.

Also note that I switched to another widgetset to avoid the numerous incompatibilities between versions (GTK1 vs GTK2 vs GTK3, Qt4 vs Qt5), the huge need for dependencies, and that, for audio applications, this eats up latency.

There are no "incompatibilites" within Qt that can't be solved by 4 lines of Macros.

@Monsterovich

No. Wayland doesn't have any "core" because there is no unified server.

that's like saying there is no core of http as there is no unified server.

Also note that I switched to another widgetset to avoid the numerous incompatibilities between versions (GTK1 vs GTK2 vs GTK3, Qt4 vs Qt5), the huge need for dependencies, and that, for audio applications, this eats up latency.

There are no "incompatibilites" within Qt that can't be solved by 4 lines of Macros.

Yes, you already said it, it's because of my incompetence.
And it's because of this that some of my old applications written for Qt4 (what a bad idea I had) force users to tinker with their system because the qt4/libqt4-* dependencies are removed in last distros.
Of course you will tell me that with 4 lines in the console, forcing the user to add the PPA repository, it will work.

With my "other widgetset" this won't happen.

In fact, my view of open source and out-of-the-box applications is inconsistent with the Wayland philosophy.

So, I apologize for the noise and good luck in your closed world of Wayland and friends.

So, I apologize for the noise and good luck in your closed world of Wayland and friends.

I don't like Wayland either. But either way, it seems to be a accumulated issue...

@zarlo

@Monsterovich

No. Wayland doesn't have any "core" because there is no unified server.

that's like saying there is no core of http as there is no unified server.

These are incomparable things. A graphical server is many times more complicated than any web server. Isn't that obvious?
Even more so, applications depend on the approach to implementing things in that server.

Also note that I switched to another widgetset to avoid the numerous incompatibilities between versions (GTK1 vs GTK2 vs GTK3, Qt4 vs Qt5), the huge need for dependencies, and that, for audio applications, this eats up latency.

There are no "incompatibilites" within Qt that can't be solved by 4 lines of Macros.

Yes, you already said it, it's because of my incompetence. And it's because of this that some of my old applications written for Qt4 (what a bad idea I had) force users to tinker with their system because the qt4/libqt4-* dependencies are removed in last distros. Of course you will tell me that with 4 lines in the console, forcing the user to add the PPA repository, it will work.

With my "other widgetset" this won't happen.

In fact, my view of open source and out-of-the-box applications is inconsistent with the Wayland philosophy.

So, I apologize for the noise and good luck in your closed world of Wayland and friends.

Again, you can port a Qt 4 app to Qt 5 with minimal effort, and don't have to rely on some library that 4 other people use and you have to add 4 PPAs or compile 13 6000-file dependencies from the AUR or GURU.

Also note that I switched to another widgetset to avoid the numerous incompatibilities between versions (GTK1 vs GTK2 vs GTK3, Qt4 vs Qt5), the huge need for dependencies, and that, for audio applications, this eats up latency.

There are no "incompatibilites" within Qt that can't be solved by 4 lines of Macros.

Yes, you already said it, it's because of my incompetence. And it's because of this that some of my old applications written for Qt4 (what a bad idea I had) force users to tinker with their system because the qt4/libqt4-* dependencies are removed in last distros. Of course you will tell me that with 4 lines in the console, forcing the user to add the PPA repository, it will work.
With my "other widgetset" this won't happen.
In fact, my view of open source and out-of-the-box applications is inconsistent with the Wayland philosophy.
So, I apologize for the noise and good luck in your closed world of Wayland and friends.

Again, you can port a Qt 4 app to Qt 5 with minimal effort, and don't have to rely on some library that 4 other people use and you have to add 4 PPAs or compile 13 6000-file dependencies from the AUR or GURU.

Maybe you didn't understand it.
Once an application is "published", only the application binary is made public.
And if this application, when compiled, was linked to some qt4 libraries, these libraries are necessary to run the release binary.

Of course I can port the application to Qt x, but then I have to provide 2 different binary versions.

To get in the "Linux" mood, Qt and GTK should take a look at how glibc did with its signed symbol table for each method.
This way only one libc.so is used with multiple symbol tables to always ensure backward compatibilities.

Once an application is "published", only the application binary is made public.

I seriously hope you are complying with the respective licences of those libraries.

Once an application is "published", only the application binary is made public.

I seriously hope you are complying with the respective licences of those libraries.

Yes, of course, there is always a readme.txt and a license.txt and for open source projects there is a link to the source and contributors in the reame.txt and brush my teeth every morning.

But now that I'm using another widgetset with root code that only needs to link libx11.so, I'm no longer bothered by forgetting to add a license and being afraid of possible incompatibilities/outdated dependencies on the end-user system.

...until that widgetset gets an update that introduces incompatibilities. Software evolves. If you don't want to worry about widgetset incompatibilities, you're free to use GTK1 and Qt 1.45. This is a completely invalid complaint, because supporting Qt 5 and Qt 6 at the same time is minimal effort--4 LOC and a flag in your make system.

Maybe you didn't understand it.
Once an application is "published", only the application binary is made public.
And if this application, when compiled, was linked to some qt4 libraries, these libraries are necessary to run the release binary.

Then update it to support Qt 5 or 6. Unless you're releasing proprietary crapware, in which case we have no room to continue this discussion. Distros don't even offer Qt 4 anymore, so forcing users to find some outdated Qt 4 overlay or PPA is anti-user. What's even worse is forcing them to install a widget library that likely doesn't even exist in GURU, honestly.

...until that widgetset gets an update that introduces incompatibilities.

That widgetset dont need dependencies (apart libx11.so) because his code is compiled with the application.
And one of his priority is to always be compatible with previous version.

f you don't want to worry about widgetset incompatibilities, you're free to use GTK1 and Qt 1.45. This is a completely invalid complaint, because supporting Qt 5 and Qt 6 at the same time is minimal effort--4 LOC and a flag in your make system.
Then update it to support Qt 5 or 6.
Distros don't even offer Qt 4 anymore

I think I've already explained that I don't use GTK or Qt for several reasons, why do you insist that I use them?

Either way, my choice is made for now. I will stop the conversion of the widgetset to Wayland. And continue to use the X11 version which works wonderfully with XWayland (obviously, its only dependency is libx11.so).

And maybe when Wayland has enslaved the planet and killed XWayland, I'll dive again.

By the way, I just tried Gimp, Inkspace and Audacity on Wayland.
Unfortunately, there is no working Wayland version of these essential applications yet.
It is on the todo list with not lot of enthusiasm.
And with XWayland the result is not perfect.
In their forum the advice is: go back to x11.

And about XWayland.

OK it works more or less but the solution to completely install an X ​​server is from Jurassic IT.

If they were serious, they would create an API compatible Xlib and XCB library that speaks the Wayland protocol underneath rather than X11.
Look at wine, they have done it for Windows to X11.

I'm disappointed, I was hoping for lots of wow in exploring Wayland.
But ultimately I get a lot of meh instead.

@zarlo

@Monsterovich

No. Wayland doesn't have any "core" because there is no unified server.

that's like saying there is no core of http as there is no unified server.

These are incomparable things. A graphical server is many times more complicated than any web server. Isn't that obvious? Even more so, applications depend on the approach to implementing things in that server.

my point was by your definition no spec has a core

there are no unified:

• js runtime
• tls
• smtp
• bgp
• sql

Again, you can port a Qt 4 app to Qt 5 with minimal effort

Not all applications are still being developed, but need to continue to work.

Then update it to support Qt 5 or 6. Unless you're releasing proprietary crapware, in which case we have no room to continue this discussion.

This mindset is what imho holds back "the year of the Linux desktop". The fact is, there is software out there that needs to continue to run. Not everyone wants to or can afford to invest into updating everything all the time.

@probonopd

Not all applications are still being developed, but need to continue to work.

yes but there has a limit, you cant have backwards compatibility with every thing for ever.
i would say there is a point that its on people who are still using it to make it work

This mindset is what imho holds back "the year of the Linux desktop". The fact is, there is software out there that needs to continue to run. Not everyone wants to or can afford to invest into updating everything all the time.

Not everyone wants to or can afford to invest into backwards compatibility everything all the time. this goes 2 ways.

you cant have backwards compatibility with every thing for ever.

Well, on Xorg I can still happily run the Mosaic web browser... (have even created an AppImage of it)

Not everyone wants to or can afford to invest into backwards compatibility everything all the time. this goes 2 ways.

Yes, but companies like IBM Red Hat who are pushing Wayland have way more resources than random joe hobby developer working on a little app in his spare time out of passion. And, unlike the developers of some applications, they are still around.

And, unlike the developers of some applications, they are still around.

okay at that point its on the user to make it work or move on

Yes, but companies like IBM Red Hat who are pushing Wayland have way more resources than random joe hobby developer working on a little app in his spare time out of passion.

and? in this case there is a good change it will work under xwayland

okay so i have been a i3-wm user since 2012 is x11 only some of the scripts i have made depend on x11 and i use fedora.

have i been whining since i found out they will be dropping x11 at some point no i have looked at my options and have just need dropping x11 only things right now the only thing left is i3 its self i just pick 1 thing every few week tryed out the x11/wayland options it was not hard to do nor did it take a long time

and you are always free to use a distribution that supports x11 i doubt arch would drop it any time soon

Think of things like GNUstep. Developed a long time ago, few active developers (not much development needed anymore, stable and feature complete since a long time). No resources to cater for work created by external changes in the underlying platform.

Think of things like GNUstep. Developed a long time ago, few active developers (not much development needed anymore, stable and feature complete since a long time). No resources to cater for work created by external changes in the underlying platform.

then either

• it works in xwayland
• someone updates it
• you say on x11
• you stop using it

Not all applications are still being developed, but need to continue to work.

Updating it so that it's actually usable for people who don't have access to 20-year old abandoned ebuilds is much closer to basic maintenance than development.

That widgetset dont need dependencies (apart libx11.so) because his code is compiled with the application.
And one of his priority is to always be compatible with previous version.

This is a good mindset to have, but ultimately there is going to be some kind of incompatibility someday. It's simply not possible to make 100% of everything 100% backwards compatible. Even Windows, lauded for its backward compatibility, struggles to have applications work on both Windows 7 and 11--though Qt does an excellent job making this happen.

Also, only depending on libX11 is great in theory, but what if you want to support Windows?

@zarlo

it works in xwayland

Wayland proponents keep telling me that XWayland is not "proper" and somehow only a temporary "workaround".

someone updates it

I don't think so, no developers are interested in that. No GNUstep developers have asked for Wayland to exist nor to create additional work for them.

you stay on x11

Exactly my point, hence I urge everyone to be careful and not abandon X11 anytime soon.
IBM Red Hat (surprise) has already stated their intent to do the exact opposite, though.

you stop using it

No. Not because someone at IBM Red Hat decided to shove Wayland upon us.

The proper solution imho would be: XWayland becomes an integral first-class citizen and the default way for applications to use Wayland without having to rewrite or even recompile them.

Unfortunately, it's unlikely that the Wayland proponents will ever see it this way. They think the world revolves around them and everyone is keen to rewrite everything to please their moving-target and still feature incomplete protocols.

Unfortunately, it's unlikely that the Wayland proponents will ever see it this way.

Please don't try to act high and mighty as if you aren't doing the same thing in a different font.

Also, only depending on libX11 is great in theory, but what if you want to support Windows?

Of course libX11 is mainly for Unix systems.
For Windows the widgetset links to the root gui gdi32.dll.
https://github.com/mse-org/mseide-msegui

And luckily, the world isn't just ruled by C and Java.
This widgetset + ide is in Pascal and uses the Free Pascal Compiler.
https://www.freepascal.org/

but ultimately there is going to be some kind of incompatibility someday.

Maybe not. If the application correctly uses libx11.so and libc.so and its signed symbol table, there is no reason to have an incompatibility.
libx11.so.6 is static now, it won't change anymore and using the libc.so signed symbol table ensures compatibility.

I have applications compiled on the latest version of XUbuntu that work perfectly on the first version of Ubuntu.
And the same applications compiled on the first version of Ubuntu which work perfectly on the latest version of XUbuntu.

And this using the same code and the same compiler.

@probonopd

@zarlo

it works in xwayland

Wayland proponents keep telling me that XWayland is not "proper" and somehow only a temporary "workaround".

someone updates it

I don't think so, no developers are interested in that. No GNUstep developers have asked for Wayland to exist nor to create additional work for them.

you stay on x11

Exactly my point, hence I urge everyone to be careful and not abandon X11 anytime soon. IBM Red Hat (surprise) has already stated their intent to do the exact opposite, though.

you stop using it

No. Not because someone at IBM Red Hat decided to shove Wayland upon us.

The proper solution imho would be: XWayland becomes an integral first-class citizen and the default way for applications to use Wayland without having to rewrite or even recompile them.

Unfortunately, it's unlikely that the Wayland proponents will ever see it this way. They think the world revolves around them and everyone is keen to rewrite everything to please their moving-target and still feature incomplete protocols.

Do you really want to live in a world where nothing, ever breaks backwards compatibility? If that were the case we would still be using unencrypted HTTP, broken and duct-taped init systems like SysVinit, slow and insecure BIOS boot, the list is huge.

You need to understand that we have to do this in order to progress our technology. Real fundamental improvement usually only come with real fundamental changes, which break compatibility. This will have to be done at some point, and it only gets worse the more we put it off.

In 10 years, do you really want to use a 50 year old windowing system? I don't think you understand the implications of what you're calling for here.

Real fundamental improvement usually only come with real fundamental changes, which break compatibility.

Yes I would accept for fundamental improvement but Wayland is not the case.

Do you really want to live in a world where nothing, ever breaks backwards compatibility?

Yes, I would prefer.

In 10 years, do you really want to use a 50 year old windowing system?

And why not if old interesting apps can run on it and if the new windowing system of 24 year old cannot do what the 50 year old can do?

Do you really want to live in a world where nothing, ever breaks backwards compatibility?

Yes, I would prefer.

The obvious solution for old applications is to open source them. If they are valuable enough for enough people you'll find people making them work on current software eco systems. There is a reason that Doom for example is still around.

Do you really want to live in a world where nothing, ever breaks backwards compatibility?

Yes, I would prefer.

The obvious solution for old applications is to open source them. If they are valuable enough for enough people you'll find people making them work on current software eco systems. There is a reason that Doom for example is still around.

Of course, with the source you can do it. But this requires some expertise and if the root-developer cares about backwards compatibility (and it's possible with x11) it's not even necessary.

Yes, I'd prefer to use Windows 2000, Mac OS X 10.4 and Linux with KDE 3 without hesitation over what we have today - if it ran on modern hardware and if "the web" would still work on it. To me it seems like the desktop computing user experience has steadily declined since then. (Everything dumbed down, constant flow of notifications, not designed for offline usage, constant updates for no real reason, n-th reshuffling of the settings, advertising tricking you into subscriptions, mobile UI paradigms bleeding into the desktop, "Secure Boot", lockdown, etc.)

In fact, if I could have the desktop experience from System 7 from 30+ years ago on today's Linux I'd be super happy.

What we are lacking is an appreciation of when a product is mature. At that point, it should best be left alone. I consider a mature product a good thing. No longer a moving target.

Remember when iOS apps were ~3 MB? Today everything seems to require hundreds of megabytes because people mistake JavaScript for "app development". Those 3 MB apps were better than what we have today.

And don't even get me started on things like Windows Recall (which is constantly spying on the user and saving its findings so that malware can easily steal them).

The obvious solution for old applications is to open source them.

That doesn't mean that there are any developers willing to work on them for no reason other than to chase a moving target, Point in case: GNUstep.

Well.. I think a distro highlighting mature Linux software would be a good thing.

This in fact is a broader indictment of current society AS A WHOLE. People don't seen when something has been developed to the "just right" point and they must keep moving. On my systems and in my life, I try to roll back changes I see as negative and keep those I see as positive. Systems should change as users and needs change, not for sake of a "refresh."

In my own usage, I use custom GTK and icon themes whose purpose is to roll back most of the visual changes to the GNOME 2 UI since when I first set up an UbuntuStudio machine in 2008 and customized the theme a bit. Thus I have MATE on wayfire looking and acting much like GNOME 2 with Compiz did for me over a decade ago. I added one more customization: the first few versions of GNOME shell used a tranparent black "shell theme" I thought was gorgeous, so I retrofitted it via my GTK theme and some widget naming to mate-panel and applet menus. The origjnal 2008-era UbuntuStudio theme had tried to do something similar with panel menus but could only do a few of them due to GTK2 theming limitations.

My goal with all this is an unchanging or minimally changing front end fitted to the backend of the day over the hardware of the day. I only replace hardware now if it is destroyed, as we have long ago reached the point that most machines can handle editiong 1080p video, which is usually my most demanding task.

Yes, I'd prefer to use Windows 2000, Mac OS X 10.4 and Linux with KDE 3 without hesitation over what we have today - if it ran on modern hardware and if "the web" would still work on it. To me it seems like the desktop computing user experience has steadily declined since then. (Everything dumbed down, constant flow of notifications, not designed for offline usage, constant updates for no real reason, n-th reshuffling of the settings, advertising tricking you into subscriptions, mobile UI paradigms bleeding into the desktop, "Secure Boot", lockdown, etc.)

In fact, if I could have the desktop experience from System 7 from 30+ years ago on today's Linux I'd be super happy.

What we are lacking is an appreciation of when a product is mature. At that point, it should best be left alone. I consider a mature product a good thing. No longer a moving target.

Remember when iOS apps were ~3 MB? Today everything seems to require hundreds of megabytes because people mistake JavaScript for "app development". Those 3 MB apps were better than what we have today.

And don't even get me started on things like Windows Recall (which is constantly spying on the user and saving its findings so that malware can easily steal them).

The obvious solution for old applications is to open source them.

That doesn't mean that there are any developers willing to work on them for no reason other than to chase a moving target, Point in case: GNUstep.

@probonopd

it works in xwayland

Wayland proponents keep telling me that XWayland is not "proper" and somehow only a temporary "workaround".

i would just tell them to fuck off as they must not know what they are talking about as there are not such things as "temporary" workaround only workarounds that become features. but i think i get why they are saying this they dont want new work to rely on xwayland to work on wayland

The proper solution imho would be: XWayland becomes an integral first-class citizen and the default way for applications to use Wayland without having to rewrite or even recompile them.

im 100% with you on this as it would fix most of the issues but you would have issues as i doubt it would be a 100% comparable x11 api ever

It would be outrageous to see games and software only running on Wayland, but not on X.

Well some time ago I was here on a misguided mission against my better judgement to correct some what I was TOLD were misconceptions despite knowing otherwise implicitly. That's over. So is a lot of things if you look me up. Linux and the BSDs are out there for anyone to create a system from.

People should bake their own bread and the like. Not necessarily mill the flour but baking the loaf.. Anyone can do that and if we don't watch out and don't take advantage of the digital raw materials around they will eventually vanish or be mutated beyond whatever it was intended to do in the first place with CLOOOOOOUUUUUUDDDD and AAAAAAAAAAYYYYYY-EEEEEEYYYYYEEEEE.

Also, did someone inject some JS into this? Was it that BomberFish? I had to use devtools to get rid of the BSOD overlay..

EDIT: Yeah @BomberFish is abusing some math js thing.. A 9x BSOD would have been far better imo. I am reporting it to our overlords.

EDIT2: Went to the profile.. big ol tiled trollface.jpg for a background. Cool as hell but now he may have to do it all over again with another account.

EDIT3: It's all been resolved by apparently being resolved rolls eyes.. Luckily I had screenshots when I made the reports so in the event he reverted it himself they will still be aware of it.

Also, did someone inject some JS into this? Was it that BomberFish? I had to use devtools to get rid of the BSOD overlay..

EDIT: Yeah @BomberFish is abusing some math js thing.. A 9x BSOD would have been far better imo. I am reporting it to our overlords.

EDIT2: Went to the profile.. big ol tiled trollface.jpg for a background. Cool as hell but now he may have to do it all over again with another account.

Haha, you got me. Looks like they patched it completely by now... it was fun nonetheless.

@BomberFish Surprised they didn't ban you outright. It is Microsoft.

Anyway, what was I on about before blue screens of troll? Oh yeah, do these FUCKS (not you BomberFish) not understand you need a stable, working, and predictable surrounding system to properly test and create new stuff that also becomes stable, working, and predictable?

I mean I just got called psychotic by a Linux-from-Scratch user in their IRC channel for not wanting systemd (despite the fact that LFS continues to produce their SysVInit instructions) and not just systemd but systemd-boot instead of my distro-independent grub configuration not managed by anyone but me, manually. Also for keeping my kernel not in /boot or that I put files on my computer in a file structure I want my files to be in.

And accused (when I was disconnected from one client) of never having used systemd and wayland. Thing is, when I started doing my servers I was on a systemd distro because at the time I didn't really mess with much except start stop and do a couple of those ini-like unit files. But the moment I wanted to do more advanced and specific management of my systems it became me fighting the system for who would comply with what. At this point I am good enough with bash scripting to manage in a SysVInit environment which does only the things I tell it to.

As for wayland, I have had my fill since October last year and previous short previews as well as researching into what Wayland is and isn't. It also doesn't work properly on my system regardless of what card I use from graphical glitches to crazy ass infinite mirror effects to complete stalling out. Basically doing everything people bitch about X11 for without any of the advantages of X11 like actually working properly (or at least as expected and advertised).

I seriously do not fully understand why any of this is happening though. Why any of it was needed in the way it has unfolded.

@mattatobin

Also for keeping my kernel not in /boot

you might be psychotic

Tell me the technical reason why the kernel needs to live in /boot? When the kernel even being accessible to the booted operating system isn't required. And tell me the technical reason why I can't have files where I want on my own system.

You see, this is the whole thing.. There should not be this kind of crap. There was a time when people took pride in tailoring their system to their needs and sharing the unique setups and solutions. Where a well running and solid system was an accomplishment to be celebrated. Now there are Fedora release parties every six months for the next round of depercaitions, removals, and arbitrary changes. Fedora encourages celebrating mediocrity and then Redhat sells you the after-work fixscription that should have been in it from the start and for free and for the benefit of everyone not just IBM and partners.

aaand now I get it.. Debian the only so-called major distro even with a pretense of being a stable linux foundation is the only one without an enterprise subscription.

I am a fuckin moron. (take note it's rare I say that) Why does linux suck and why are all these fucked over replacement systems being pushed as the only thing? Because Corporate Linux is pushing it. Because they are the vendors and facilitators and arbiters of what their distros ship and anyone looking to make major corperate money from selling Linux Support and Fixes as their core business model has a vested intrest in keeping the recent-buzz-word'd SUPPLY CHAIN in the shitter until they can service their customers first with errata and updates and eventual upstreaming (but only so they don't have to put the work in to patch everything forever like debian).

So it was the same old shit all along.. Just refactored with a perpetual testing initiative for anyone who doesn't pay.

To bring it back down to just X11 vs Wayland.. Well X11 is old as dirt, mature, doesn't take shit from anyone and tends to work if you don't disrespect its fuckin design or expect it to do things it wasn't designed to do unless you are willing to put the care into making it do it. This is a system that once working doesn't TEND to break. Wayland is ripe for enterprise support and deepening strategic business partnerships as a system designed to always need an update.

Tell me the technical reason why the kernel needs to live in /boot?

It doesn't. However it has to be accessible for your boot loader (whatever that may be). So if you end up on some more exotic root-filesystem that isn't supported by your boot loader you basically can't boot your system anymore. I think that was one of the reasons for a /boot partition in the earlier days that then might also have been using a more standard filesystem like ext2 or even some FAT variant.

When the kernel even being accessible to the booted operating system isn't required.

Uh, I don't know about that. Ever tried to update your kernel?

Yes. Because I run a custom grub configuration added into efibootmgr my self and have been experimenting with compiling a kernel in the way I want that can run this pseudo-stableish Fedora 39 userspace well.. If I can do that it should handle anything I want to do. Because I am taking the time and care to manage this manually the only time it needs pissed with is when I, manually want or need to piss with it.

Otherwise, why have it mounted in a running system and why crowd my custom shit right along side what the distro is managing assuming I didn't custom install avoiding their's and using mine or whatever I am doing.

Which if it is redhat-based I can yum --installroot edit my grub.cfg and reboot either selecting the distro kernel and just.. manually clean them up if I care enough and set the config to the version I want or just use my own, initramfs free. Now I don't expect most people to ever wanna have to do this but I expect most people to not shit upon me for my self needing or wanting to. Shame my expectations are rarely met though.

As for filesystems.. XFS all the way.. ext4 if I don't particularly care about the partition like if it is a temporary staging partition or whatnot.

#!/bin/bash

cd "$(dirname "$0")"
SCRIPT_DIR="$(pwd)"

echo "This script also doubles as an ad-hoc installer so if you choose the default below it will assume you want to prep the root not merely access it."
echo -e "If you still want to use the default mount point then touch .linuxnt in the target root file system and run this script again.\n"

read -p "Enter Mount Point [/mnt/sysroot]: " TARGET_SYSROOT

TARGET_SYSROOT=${TARGET_SYSROOT:-"/mnt/sysroot"}

if [ "$TARGET_SYSROOT" == "/mnt/sysroot" ]; then
  if [ ! -f "$TARGET_SYSROOT/.linuxnt" ]; then
    INSTALL_SYSTEM=1
  fi
fi

# -----------------------------------------------------------------------------

dossetup() {
  read -p "Press enter to prep the virtual filesystems..."
  mkdir -pv {$TARGET_SYSROOT/dev/pts,$TARGET_SYSROOT/dev/shm,$TARGET_SYSROOT/etc,$TARGET_SYSROOT/proc,$TARGET_SYSROOT/run,$TARGET_SYSROOT/sys}
  cp -v /etc/resolv.conf $TARGET_SYSROOT/etc/resolv.conf
}

dosconfig() {
  echo "Mounting virtual filesystems..."
  mount -v --bind /dev $TARGET_SYSROOT/dev
  mount -vt devpts devpts -o gid=5,mode=0620 $TARGET_SYSROOT/dev/pts
  mount -vt proc proc $TARGET_SYSROOT/proc
  mount -vt sysfs sysfs $TARGET_SYSROOT/sys
  mount -vt tmpfs tmpfs $TARGET_SYSROOT/run

  if [ -h $TARGET_SYSROOT/dev/shm ]; then
    install -v -d -m 1777 $TARGET_SYSROOT$(realpath /dev/shm)
  else
    mount -vt tmpfs -o nosuid,nodev tmpfs $TARGET_SYSROOT/dev/shm
  fi
}

winnt32() {
  read -p "Press enter to begin the installation."

  dnf install --installroot=$TARGET_SYSROOT --releasever=39 --setopt=install_weak_deps=False --setopt=keepcache=True --nodocs --refresh --assumeyes \
    @custom-environment \
    @c-development \
    @development-libs \
    @development-tools \
    @fedora-packager \
    bc \
    dbus-daemon \
    curl \
    htop \
    httpd-tools \
    nano \
    fuse-sshfs \
    ntfsprogs \
    python2* \
    rsyslog \
    traceroute \
    unzip \
    wget \
    zip \
    screen \
    net-tools \
    dos2unix \
    rsync \
    time \
    tree \
    whois \
    git \
    curl \
    wimlib* \
    -x ccache \
    -x plymouth* \
    -x audit \
    -x abrt* \
    -x firewall* \
    -x vim* \
    -x audit \
    -x zram*
  

  touch $TARGET_SYSROOT/.linuxnt
  read -p "Install either worked or it didn't. Press enter to continue."
}

ntldr() {
  echo -e "\nEntering $TARGET_SYSROOT..."
  echo -e "\n================================================================================"
  echo -e "\nOpen Source Linux NT [Version $(uname -r)]\n$(uname -v)\n"
  chroot "$TARGET_SYSROOT" /usr/bin/env -i   \
      HOME=/root                  \
      TERM="$TERM"                \
      PS1="(Linux NT) \u:\w \$ "  \
      PATH=/usr/bin:/usr/sbin     \
      MAKEFLAGS="-j$(nproc)"      \
      TESTSUITEFLAGS="-j$(nproc)" \
      /bin/bash --login
  echo -e "\n================================================================================\n"
}

dosexit() {
  echo "Unmounting virtual filesystems..."
  umount -v $TARGET_SYSROOT/dev/pts
  mountpoint -q $TARGET_SYSROOT/dev/shm && umount -v $TARGET_SYSROOT/dev/shm
  umount -v $TARGET_SYSROOT/dev
  umount -v $TARGET_SYSROOT/run
  umount -v $TARGET_SYSROOT/proc
  umount -v $TARGET_SYSROOT/sys
}

# -----------------------------------------------------------------------------

# Setup filesystem
if [ -n "$INSTALL_SYSTEM" ]; then
  dossetup
fi

# Mount virtual filesystems
dosconfig

# Install system
if [ -n "$INSTALL_SYSTEM" ]; then
  winnt32
fi

# Chroot to system
ntldr

# Unmount virtual filesystems
dosexit