**The Migration Timeline** - Has the 15+ year transition been too slow, or is this normal for such a fundamental change? - Should there have been more coordination between desktop environments? - Were users given adequate warning and preparation time? **Technical Execution** - Which desktop environments handled the transition best/worst and why? - The role of XWayland - brilliant compatibility layer or crutch that's holding things back? - Biggest technical hurdles that surprised developers **Communication & Community** - How well did the community communicate what Wayland actually solves? - The "Wayland breaks everything" narrative - fair criticism or resistance to change? - Should there have been clearer migration paths for specific use cases? **Specific Pain Points** - Screen sharing, remote desktop, and enterprise compatibility issues - Gaming performance and compatibility - where do things stand now? - Accessibility tools and assistive technology support - Multi-monitor setups and edge cases **Looking Forward** - What would he have done differently if he were leading the migration? - Are we past the worst of the transition pain now? - Will X11 ever truly die or will it persist in niche use cases? - Lessons for future major Linux ecosystem changes **Hot Takes** - Was forcing the migration through distribution defaults the right approach? - Which criticisms of Wayland were valid vs just resistance to change? - His prediction for when the transition will be "complete" and what does that mean. --- **Debian-related questions** - As someone who's been cautious about switching, what would convince hesitant users like me? - Did Debian's conservative approach actually serve users better than more aggressive adoption? - What should Debian users know about making the switch now vs waiting longer? --- **Distro Adoption** **Fedora** Fedora has been the most aggressive with Wayland adoption - they've basically been the testing ground. That's fine for bleeding-edge users, but it reinforces my feeling that they're treating their users as beta testers for something that should be production-ready. I appreciate that Fedora seems to be the testing ground while I sit in my bubble of safety. **Ubuntu/Canonical** Ubuntu pushed Wayland as default pretty aggressively with GNOME, but they've been inconsistent - they actually rolled back to X11 as default for a while when it wasn't working. As an X11 user, I appreciate that they still make it easy to switch back, but the back-and-forth messaging has been confusing. Their enterprise customers probably aren't thrilled with the instability either. **Arch/Manjaro** Arch's approach has been the most honest - they give you the tools and let you choose. That's how it should be. But even there, the Wayland implementations vary wildly between desktop environments, which shows how fragmented this whole thing is. **openSUSE** SUSE has been more measured, similar to Debian. They support both but don't force you. That feels more respectful to users who have working setups. Maybe Matt can speak on this. **Red Hat/CentOS** Enterprise distros moving to Wayland concerns me because enterprises need stability above all else. If Red Hat is pushing this in RHEL, they're essentially forcing enterprise users to be guinea pigs for desktop technology that's still maturing. **Red Hat's Decision:** Red Hat is removing the Xorg server and other X servers (except Xwayland) from **Red Hat Enterprise Linux (RHEL) 10** and future releases. **Why:** 1. The X Window System is over 30 years old and has fundamental issues. 2. Wayland has become the de-facto windowing and display infrastructure solution. 3. Maintaining both X.org and Wayland stacks is burdensome and splits resources. 4. Wayland has matured, and the feature gap with X.org has been largely closed. **Efforts made:** 1. Red Hat has contributed to Wayland's development, including HDR/color management, Xwayland, remote desktop solutions, and more. 2. They've worked with hardware vendors, software vendors, customers, and the VFX industry to close the feature gap. **Impact:** 1. Xwayland will remain to support X11 clients that aren't immediately ported to Wayland. 2. Customers can stay on RHEL 9 for its full life cycle if needed. 3. This decision allows Red Hat to focus on a modern stack and ecosystem, tackling problems like HDR, security, and better display handling. **Next Steps:** 1. Join the discussion on the customer portal to provide feedback and ask questions. 2. Red Hat is excited to work with the community and partners to build the future for Linux. **Debian** "Debian's conservative approach actually validates my concerns. If the 'stability-first' distro is still cautious about full Wayland adoption, maybe the rest of the ecosystem is moving too fast. Their approach of supporting both long-term makes the most sense to me." **Overall Take** Does the inconsistency of distros prove that the adoption of Wayland was premature? --- **Me** I use dwm and bspwm - these are minimal, patched window managers that do exactly what I need. The Wayland equivalents like dwl are still experimental, and I'd lose years of patches and customizations. bspwm doesn't even have a direct Wayland equivalent that matches its functionality. **Patching and Customization** dwm's entire philosophy is about patching the source code to customize it. I've spent years building my perfect setup with patches for gaps, scratchpads, systray support. Starting over with dwl means rebuilding everything from scratch, and the patch ecosystem barely exists compared to dwm. **External Tool Dependencies** My bspwm setup relies heavily on external tools - bspc for window manipulation, polybar for status, rofi for launching, dunst for notifications. I recognzie some of the applications have been transitioned like rofi for wayland but it is still early OR is it? **BSPC and Scripting** bspwm's bspc command lets me script everything - window placement, desktop switching, rule management. This external control model doesn't really exist in Wayland compositors. They expect you to use their built-in features instead of building your own workflow. **Minimalism Philosophy** Part of why I chose dwm and bspwm is their Unix philosophy - do one thing well. Wayland compositors try to be everything - window manager, compositor, sometimes even handling bars and notifications. That goes against everything I value about these minimal window managers. **Choices for Minimal WMs** There's barely any resources for people who want minimal, scriptable setups. I could switch to Sway for stability but it would not be a first choice. We will see where I am when Debian 13 (Trixie) is the stable branch to decide more about Hyprland. **The Bottom Line** My dwm and bspwm setups represent years of refinement. They're fast, minimal, and perfectly suited to my workflow. Wayland is asking me to throw that away for theoretical benefits I don't need, with tools that don't match the minimalist philosophy that drew me to these window managers in the first place.