As X11Libre has become a fork by dissatisfied programmers who previously worked on X11 (Xorg), there has been some interesting discussion about the projects, and how X11 was being extinguished from within in favor of Wayland being rushed through by Red Hat and IBM. People are very dissatisfied with the tech reporters covering Linux, and I’ve found their coverage to be pretty slanted as well and devoid of any depth. So I am highlighting a post from the X11Libre mailing list and one member’s two documents below that give some depth to the issues. The documents cover the situation well, and this rushed through Wayland is insufficient for developers writing complex programs like Kicad. Consequently, if you’ve used GNOME also run by Red Hat and IBM, it equally lacks depth as a desktop environment and one on my least favorite ones. And you’d have to say that the security model of Wayland fits megacorp philosophy as they like to use new and cheap programmers over experienced ones for a lot of applications, one of the reasons I parted ways with the large megacorp I worked for after 18 years, all because it became so unbearable.
[xlibre] Kicad devs: use X11, Wayland is bad by design
| guido iodice <dmarc-noreply@freelists.org> | Jun 16, 2025, 2:00 PM (17 hours ago) |
https://www.kicad.org/blog/2025/06/KiCad-and-Wayland-Support
“These problems exist because Wayland’s design omits basic functionality that desktop applications for X11, Windows and macOS have relied on for decades—things like being able to position windows or warp the mouse cursor. This functionality was omitted by design, not oversight.
The fragmentation doesn’t help either. GNOME interprets protocols one way, KDE another way, and smaller compositors yet another way. As application developers, we can’t depend on a consistent implementation of various Wayland protocols and experimental extensions. Linux is already a small section of the KiCad userbase. Further fragmentation by window manager creates an unsustainable support burden. Most frustrating is that we can’t fix these problems ourselves. The issues live in Wayland protocols, window managers, and compositors. These are not things that we, as application developers, can code around or patch.
We are not the only application facing these challenges and we hope that the Wayland ecosystem will mature and develop a more balanced, consistent approach that allows applications to function effectively. But we are not there yet.
Recommendations for Users For Professional Use
If you use KiCad professionally or require a reliable, full-featured experience, we strongly recommend:
Use X11-based desktop environments such as:
XFCE with X11
KDE Plasma with X11
MATE
Traditional desktop environments that maintain X11 support
Install X11-compatible display managers like LightDM or KDM instead of GDM if your distribution defaults to Wayland-only
Choose distributions that maintain X11 support – some distributions are moving to Wayland-only configurations that may not meet your needs
————————
Guido Iodice
The Evolution of Display Servers: X.org vs. Wayland and the Debate on Security and Flexibility
By Jason Cravens
Introduction
The ongoing discussion about X.org and Wayland, two major display server protocols, delves deep into the heart of modern computing’s evolution. On one hand, X.org’s modularity and network transparency have been celebrated for decades, offering flexibility and freedom for developers to implement custom solutions. On the other hand, Wayland’s modern approach emphasizes advanced graphics capabilities, improved performance, and security features integrated directly into its architecture.
However, the philosophical underpinnings of these systems—particularly in terms of security design and developer autonomy—have sparked heated debates. Should security be abstracted and centralized within the display server to simplify development, or should it remain flexible, giving developers complete control? This article explores the juxtaposition of these approaches, uncovering the implications for both security and innovation in software development.
X.org: A Legacy of Flexibility and Modularity
The Design Philosophy of X.org
X.org, or the X Window System, has been the backbone of graphical user interfaces in Unix-like operating systems for decades. Its defining characteristic is network transparency, which allows graphical applications to run on one system while being displayed on another. This modular design prioritizes flexibility, enabling developers to create their own layers of functionality, including security.
In this design, X.org acts more like a framework than a rigid system. Much like how networking protocols like UDP and TCP provide fundamental building blocks for communication, X.org provides the basic tools for graphical display, leaving developers free to implement additional layers as needed.
Security as a Developer’s Responsibility
X.org’s architecture does not enforce a predefined security model. This absence is not a flaw but a deliberate choice, empowering developers to build customized security implementations tailored to their specific applications. Just as TLS/SSL can be layered atop TCP for secure communication, developers have the freedom to create robust and efficient security solutions atop X.org without interference from the display server itself.
However, this freedom comes with responsibility. Developers must have a deep understanding of security principles to correctly implement these measures. While this approach promotes innovation and customization, it may pose challenges for less experienced developers, who might struggle to implement effective security practices without built-in guidance.
Wayland: Streamlining Modern Graphics and Security
By Jason Cravens
Advanced Capabilities for Modern Workflows
Wayland was designed to address some of X.org’s limitations, particularly in areas like performance, efficiency, and support for modern graphics hardware. Its architecture eliminates many of the legacy components of X.org, offering a more streamlined and efficient system. Applications like gaming engines, 3D rendering software, and even machine learning frameworks benefit from Wayland’s ability to leverage advanced drivers and hardware acceleration.
These advancements make Wayland particularly well-suited for modern use cases, where high-performance graphics and minimal latency are paramount. Additionally, its compatibility layer, XWayland, allows legacy X11 applications to run on Wayland-based systems, easing the transition for developers and users alike.
Integrated Security: An Asset or a Bottleneck?
One of Wayland’s most notable features is its integrated security model. Unlike X.org, which leaves security implementation to the developer, Wayland enforces stricter permissions and security protocols directly within the display server. This design aims to mitigate vulnerabilities stemming from X.org’s unrestricted application access and elevated privileges.
However, this approach has sparked criticism. By centralizing security within the display server, Wayland reduces the developer’s ability to implement custom solutions. This one-size-fits-all model may simplify development for some but can lead to inefficiencies and subpar configurations for others, particularly those with specialized needs.
The Case Against Centralized Security in Display Servers
The Risks of Over-Engineering
While the intention behind integrating security into Wayland is commendable, it risks over-engineering the system. By attempting to anticipate every possible use case and enforce a universal security model, Wayland may inadvertently stifle creativity and adaptability. Developers who would have otherwise implemented leaner, more effective solutions may find themselves jumping through unnecessary hoops, leading to bloated and less efficient code.
Over-engineering also raises concerns about future-proofing. In a rapidly evolving technological landscape, rigid security frameworks may struggle to adapt to new workflows and challenges. A more modular approach, like that of X.org, allows developers to pivot quickly and implement changes as needed, ensuring the longevity and relevance of their applications.
Encouraging Dependency and Skill Degradation
Centralized security models can foster dependency among developers, particularly those new to the field. By abstracting away the complexities of security implementation, Wayland may inadvertently discourage developers from learning the underlying principles of secure coding. This hand-holding, while well-intentioned, could lead to a generation of programmers who rely on abstractions rather than developing a deep understanding of the systems they work with.
In contrast, X.org’s philosophy of developer autonomy encourages skill development and expertise. By requiring developers to engage directly with security practices, it fosters a culture of learning and innovation, ultimately leading to more robust and effective solutions.
Striking a Balance: Flexibility vs. Security
The Need for a Hybrid Approach
The debate between X.org and Wayland is often framed as an either/or proposition: flexibility versus security, legacy versus modernity. However, this dichotomy oversimplifies the issue. The ideal solution lies in a hybrid approach that combines the strengths of both systems.
For instance, Wayland could retain its advanced graphics capabilities while adopting a more modular approach to security. By providing developers with the tools and resources to implement their own security measures—without enforcing a rigid framework—it could strike a balance between usability and empowerment. Similarly, X.org could benefit from incorporating some of Wayland’s performance optimizations while maintaining its commitment to developer autonomy.
Empowerment Through Knowledge
At the heart of this discussion is the importance of empowering developers. Rather than abstracting away complexities, systems should provide the tools and documentation necessary for developers to learn and grow. This approach not only leads to better security implementations but also fosters a more knowledgeable and innovative developer community.
Encouraging self-sufficiency does not mean abandoning beginners to fend for themselves. Instead, it involves striking a balance between guidance and freedom, offering support without stifling creativity. By fostering an environment where developers can experiment, learn, and adapt, we ensure the continued evolution of technology in a way that benefits everyone.
Conclusion: The Path Forward for Display Server Development
The debate between X.org and Wayland highlights a fundamental tension in software development: the balance between flexibility and abstraction. While Wayland’s integrated security model simplifies certain aspects of development, it risks stifling innovation and adaptability. X.org’s modular approach, on the other hand, empowers developers to create tailored solutions but requires a higher level of expertise.
The path forward lies in recognizing that these approaches are not mutually exclusive. By combining the strengths of both systems, we can create a development ecosystem that prioritizes both security and flexibility. This hybrid approach will not only address the challenges of today but also prepare us for the unknowns of tomorrow.
As technology continues to evolve, it is crucial to prioritize developer autonomy and adaptability. By fostering a culture of learning and innovation, we can ensure that our systems remain robust, secure, and capable of meeting the demands of a rapidly changing world.
Meta Description:
Explore the debate between X.org and Wayland, focusing on the balance between security and flexibility. Dive into the implications of centralized security in display servers and the need for a hybrid approach to foster innovation and adaptability.
The Wayland and Xorg Saga: A Fork In The Road
By Jason Cravens
Introduction: A Brewing Conflict in Display Protocols
The Linux desktop environment has long relied on two primary players to handle its graphical display systems: Xorg and Wayland. While Xorg served as the backbone of graphical environments for decades, Wayland emerged as a modern alternative, promising enhanced performance, security, and simplicity. However, what was once billed as progress has turned into a deeply polarizing subject within the Linux community. Recent developments, including the rumored quiet “abandonment” of Xorg and the emergence of the XLibre fork, have reignited debates about Wayland’s intentions and its wider impact on the Linux ecosystem.
This article explores the unfolding conflict, including the alleged challenges surrounding Wayland’s development philosophy, the decline of Xorg, and the eruption of XLibre as a response. Are Wayland’s issues simply growing pains, or is there something more nefarious at play? Let’s delve into the controversy.
The Perpetual Problems of Wayland
Wayland was initially introduced as a streamlined replacement for Xorg, one that promised to address the latter’s perceived inefficiencies and outdated architecture. However, the project has been fraught with challenges since its inception. Many in the Linux community have voiced concerns about Wayland’s lack of receptiveness to user feedback and its apparent disregard for compatibility with longstanding applications and development practices.
A Community Disillusioned
From the day Wayland was released, critics have pointed to its unwelcoming nature toward end users. Unlike Xorg, which fostered a community-centered approach and emphasized cross-stack development, Wayland has often been described as rigid and inflexible. This rigidity has alienated developers and users alike, particularly those relying on legacy systems or specific software configurations that Wayland struggles to accommodate.
One of the most glaring issues is Wayland’s lack of backward compatibility. By failing to support older applications or workflows that depend on Xorg, Wayland has made it difficult for many users to transition. While proponents argue that this focus on modernity is necessary for progress, skeptics believe it reflects a lack of genuine concern for the broader user base.
Broken Releases and Eroding Trust
Another major criticism is the state of Wayland’s releases. Public confidence in the project has been repeatedly shaken by broken updates, incomplete features, and an overall lack of polish. For a system touted as the future of Linux display protocols, its inability to deliver a stable, reliable experience has left many wondering whether Wayland is truly ready for prime time.
To compound matters, the Wayland team has been accused of ignoring or dismissing community concerns. This perceived indifference has only fueled frustration among users and developers who feel sidelined by the project’s insular approach.
The Decline of Xorg: Quiet Abandonment or Strategic Neglect?
For years, Xorg served as the backbone of Linux graphical environments, providing a robust and versatile platform for countless applications. However, in recent years, its development has slowed to a crawl, with many accusing the Xorg team of deliberately undermining Xorg to pave the way for Wayland’s takeover.
A Period of Silence
The last two years have been particularly contentious. Xorg’s development has largely stagnated, with hundreds—now over a thousand—merges left untouched. This lack of activity has led many to believe that Xorg has been quietly abandoned, despite the absence of any official announcement or roadmap outlining its future.
Critics argue that this silence from both parties involved, is itself a form of sabotage, designed to erode confidence in Xorg and force users onto Wayland. By refusing to engage with the community or address outstanding issues, the RedHat team has effectively left Xorg to wither on the vine.
A Fork in the Road: The Emergence of XLibre
The recent creation of XLibre, a fork of Xorg, has brought these tensions to a head. Spearheaded by developers frustrated with the state of Xorg, XLibre aims to breathe new life into the project and provide a viable alternative to Wayland. The fork has been described as a direct response to RedHat’s perceived neglect, and its emergence has forced the issue of Xorg’s future back into the spotlight.
The Worst Kind of Lie: Omission of Data
At the heart of the controversy lies a fundamental issue of transparency—or the lack thereof. Critics of Wayland argue that the project’s leaders have consistently withheld information, leaving users and developers in the dark about critical decisions. This omission of data is seen as a deliberate strategy to help undermine Xorg and push Wayland as the default choice.
The Consequences of Silence
When a project fails to communicate openly with its community, it creates an environment of uncertainty and mistrust. This is particularly damaging in the open-source world, where collaboration and transparency are key pillars of success. By refusing to address the status of Xorg or engage with its user base, the RedHat team has alienated a significant portion of the Linux community.
Security vs. Compatibility: The Heart of the Debate
One of Wayland’s core selling points has always been its focus on security. Unlike Xorg, which relies on a more permissive architecture, Wayland was designed with strict internal security measures to prevent malicious applications from interfering with the system. While this is undeniably a step forward in many respects, it has also created significant compatibility issues.
The Trade-Offs of Modernity
The incompatibility between Wayland and many older applications has been a major sticking point for users. While some argue that these trade-offs are necessary to ensure a more secure and modern system, others believe that Wayland’s refusal to accommodate legacy software represents a fundamental flaw in its design philosophy.
The Way Forward: Can XLibre Challenge Wayland?
The emergence of XLibre has injected new life into the debate over Linux display protocols. By offering a revitalized version of Xorg, XLibre has the potential to provide a viable alternative to Wayland, particularly for users and developers who feel alienated by the latter’s approach.
Challenges Ahead
However, XLibre faces significant challenges. As a fork of Xorg, it inherits many of the same issues that led to the original project’s decline. Additionally, it will need to build a strong community of developers and users to ensure its long-term success.
A Call for Collaboration
Ultimately, the Linux ecosystem would benefit from greater collaboration between the Xorg, Wayland, and XLibre communities. By working together, these projects could address their respective shortcomings and create a more unified and robust system for Linux users.
Conclusion: A Divided Future
The ongoing conflict between Xorg and Wayland highlights the challenges of balancing progress with compatibility in the open-source world. While Wayland represents a bold step forward, its insular approach and compatibility issues have alienated many users. Conversely, Xorg’s stagnation has left it vulnerable to obsolescence, forcing the community to consider alternatives like XLibre.
As the dust settles, one thing is clear: the Linux community must find a way to bridge these divides and create a future that works for everyone. Whether that future involves Wayland, XLibre, or a combination of the two remains to be seen.
Meta Description:
Explore the ongoing conflict between Wayland and Xorg, the rise of XLibre, and the future of Linux display protocols. Discover the challenges and potential solutions in this divisive debate.