Wayland Archive
Wayback, the recently announced tool that will allow you to run a legacy X11 desktop environment on top of Wayland, has just announced its first release, version 0.1. As the version number implies, there be dragons here, but the developers state some of them already use Wayback on a day-to-day basis. Still, there’s no multi-monitor support yet, quite a few X.org options are just stubs for now, there’s no mouse-locking, and so on. Since the initial announcement and the first progress report a few weeks ago, Wayback has become an official part of FreeDesktop.org, which indicates the wider desktop Linux community is definitely interested in what Wayback has to offer. It’s also been split into several different parts to mimic X.org’s structure, several distributions have picked it up and packaged it already, and ton more changes have been made. It definitely seems like Wayback has a good chance of becoming a simpler, more straightforward replacement for X.org, greatly reducing the maintenance burden of Linux distributions. Not having to keep the full legacy X.org stack around alongside Wayland is going to save a lot of people a lot of time.
Is KDE too much for you? GNOME tries to do too much? Xfce still a bit too fancy? Do you need something smaller? Even more minimalist? What about a mere 20 lines of code which provide the absolute barest possible minimum of window management functionality? You need mwm. This is the smallest, actually usable window manager I know about. Even TinyWM is twice as large. However, it doesn’t let you launch programs, or assign key bindings. mwm does. ↫ Mwm’s GitHub page It will open a window, and let you switch between windows, that are always fullscreen. No titlebars, no virtual desktops, no menus, no nothing. This is the true minimalist’s experience.
What if you want to use Wayland, but prefer Window Maker, which is restricted to legacy X11? Enter wlmaker, or Wayland Maker, a Wayland compositor that reproduces the look and feel of Window Maker. It’s lightweight, very configurable through human-readable configuration files, supports dockable applications, and more. It’s actually packaged in FreeBSD and a number of Linux distributions, including Ubuntu and Debian (Fedora’s package is outdated), but of course, you can compile it yourself, too.
Alpine Linux maintainer Ariadne Conill only started working on Wayback a few weeks ago, but in a blog post today they dive into a few more details about how much progress has already been achieved. To refresh your memory, Wayback allows you to run a legacy X11-based desktop environment on top of Wayland by running a stub Wayland compositor in front of Xwayland, capable of serving as a full X server. This way, the transition to Wayland and the removal of X.org from popular distributions won’t mean you can’t run X11-based desktop environments anymore. Within just a few weeks, the project has made serious progress. There’s a lot still left to do before we can confidently say that Wayback is ready for distributions to switch to. This work is across the stack: Wayback still needs to expose surfaces that Xwayland can use, Xwayland needs to implement a few new features such as cursor warping and some X extensions inside Xwayland itself need to be properly plumbed (such as Xinerama being able to make use of the Wayland output layout data). Longer term goals aside, we are at most a few weeks away from the first alpha-quality release of Wayback. The main focus of this release is to get to a point where enough is working that users with basic setups and requirements can be reasonably served by Wayback in place of the X.org server, to allow for further testing. It’s already to a point where I am daily driving it. ↫ Ariadne Conill Of course, there’s still tons of bugs to figure out and missing functionality to implement, but the fact that they’re just weeks away from a first alpha release is honestly impressive. I really hope Wayback picks up even more and gets adopted by other distributions as well, since it’s such an elegant and future-proof solution to a very real problem. It’s important that desktop environments that will not or cannot transition to Wayland remain available to Linux users regardless of their choice of Wayland or X11. When facing the slow sunsetting of a windowing system, some people go off on deranged neofascist conspiracy rants against the woke illuminati, while others sit down and develop real forward-looking solutions. I’m glad virtually every Linux distribution that matters trusts the latter over the former.
With X.org being in maintenance mode, with the process of replacing it with Wayland accelerating pretty quickly now, a lot of projects using X.org are looking for ways to prepare for the future. Alpine Linux, a distribution focused on musl, BusyBox, and OpenRC, also wants to reduce its maintenance burden for X11 applications, and so Alpine Linux maintainer Ariadne Conill has come up with something interesting. Wayback is an experimental X compatibility layer which allows for running full X desktop environments using Wayland components. It is essentially a stub compositor which provides just enough Wayland capabilities to host a rootful Xwayland server. It is intended to eventually replace the classic X.org server in Alpine, thus reducing maintenance burden of X applications in Alpine, but a lot of work needs to be done first. ↫ Wayback GitHub page It’s nowhere near done and most likely contains massive amounts of bugs and issues, but the seed has been planted. Wayback will make it possible to keep running X11-based desktop environments even in a full-Wayland environment. This may be necessary in case you need a specific feature not yet available in the Wayland version of your desktop environment, or if your desktop environment of choice simply isn’t going to move to Wayland at all (due to lack of maintainers or whatever). It’ll also be a boon for retrocomputing, especially as over the coming years and decades unmaintained X11 desktop environments become become ever harder to keep running on modern Linux distributions. While X.org as it exists today certainly isn’t going anywhere any time soon, it will, eventually, stop working properly on Linux distributions who don’t ship it by default anymore, and it’s awesome to already have the beginnings of a project to address this problem.
With the transition from X11 to Wayland in full swing, from popular distributions removing X11 sessions altogether and the two major desktop environments planning for the removal of X11 support as well, there’s a ton of questions people are dealing with. Both the KDE and GNOME project published detailed blog posts about the matter. First, KDE’s Nathan Graham makes it very clear that KDE Plasma’s X11 sessions continues to be maintained. This means KDE Plasma will continue to work on X11, major bugs in the session (e.g. can’t log in) will be fixed, and really bad regressions in the session may eventually be fixed. That being said, minor bugs will probably not be fixed unless someone pays for it, and new features in the X11 session will not happen at all, unless someone pays for it. KDE currently has no time frame for when X11 support will be dropped from KDE Plasma, and Graham doesn’t expect it to happen within the next two years. The KDE project maintains a list of known significant issues with KDE Plasma on Wayland, and KDE plans on addressing everything on that list before removing X11 support. Graham notes that in the end, dropping X11 support from KDE Plasma is mostly up to distributions, as it wouldn’t make any sense to drop it if distributions aren’t on board. At the moment, about 70-80% of KDE Plasma users are using Wayland, he notes. On the GNOME side of things, Jordan Petridis also detailed GNOME’s position on Wayland and X11. GNOME will be disabling the X11 session in GNOME 49, with a full removal of the X11 code in GNOME 50. This won’t break any X11 applications (on either GNOME or KDE), since even if they don’t have a Wayland backend, they’ll run just fine using XWayland, which is an X server running on top of Wayland. XWayland isn’t going anywhere any time soon. According to Petridis, the Wayland session is as functional as the X11 session, and “in plenty of cases a lot more capable and efficient”. He further adds that “there’s some niche workflows that are only possible on X11, but there isn’t any functionality regression”. Basically, if you’re using your spacebar as a heater, you might run into problems. As for accessibility, Wayland is actually doing pretty great. There has been a lot of concerned trolling and misinformation specifically around this topic sadly from people that don’t care about it and have been abusing the discourse as a straw man argument. Drowning all the people that rely on it and need to be heard. Thankfully Aaron of fireborn fame wrote recently a blogpost talking about all this in detail and clearing up misconceptions. ↫ Jordan Petridis Finally, Petridis summarises why the Linux desktop world is moving to Wayland: No, the Xorg Server is still very much maintained, however its development is halted. It still receives occasional bugfixes and there are timely security releases when needed. The common sentiment, shared among Xorg, Graphics, Kernel, Platform and Application developers is that any future development is a dead-end and shortcomings can’t be addressed without breaking X11. That’s why the majority of Xorg developers moved on to make a new, separate, thing: Wayland. ↫ Jordan Petridis This pill is so hard to swallow for some people that they go full bananas and start seeing red hats and Illuminati symbols everywhere, losing their minds and spiraling deep into ludicrous conspiracy theories. The truth of the matter is, however, blatantly banal: the people developing X.org realised long ago that meaningfully improving it would irrevocably break it, and as such they developed something new so they wouldn’t have to break X11. That’s it. X.org will continue to exist and live on in its maintained state, and desktops relying on it will continue to function. If you want to keep using GNOME and KDE, though, you’ll have to drop X11, because the kinds of features and improvements these desktops want to deliver are not possible without breaking X11. Would you want an X11 that’s broken for everyone, or an X11 that keeps working as-is, while those that want to move on do so somewhere else?
For a while, X terminals were a reasonably popular way to give people comparatively inexpensive X desktops. These X terminals relied on X’s network transparency so that only the X server had to run on the X terminal itself, with all of your terminal windows and other programs running on a server somewhere and just displaying on the X terminal. For a long time, using a big server and a lab full of X terminals was significantly cheaper than setting up a lab full of actual workstations (until inexpensive and capable PCs showed up). Given that X started with network transparency and X terminals are so obvious, you might be surprised to find out that X didn’t start with them. ↫ Chris Siebenmann I did indeed assume X terminals were part of the ecosystem from day one, but it makes sense that it took a while, and that they didn’t enter the scene until X had established itself as the standard windowing system in the UNIX world. I’ve been trying to get my hands on specifically the last HP X terminal, but they’re hard to find and often very expensive. I’d love to get a taste of a proper networked X environment on real UNIX, in the way people actually used to use it professionally. As a sidenote, Siebenmann is doing such an excellent job with these stories about UNIX, X11, and related matters. He’s like the Raymond Chen of the UNIX world.
The Wayland color-management protocol extension has landed on Feb 13th, 2025, in upstream wayland-protocols repository in the staging directory. It was released with wayland-protocols 1.41. The extension enables proper interactions between traditional (sRGB), Wide Color Gamut (WCG), and High Dynamic Range (HDR) image sources and displays once implemented in Wayland compositors and used in applications. Of course, a protocol is just a language. Two participants need to speak the same language for the language to be of any use: Wayland compositors and a component on the application side (e.g., a toolkit library). Major efforts have been going on in various projects to prove and take advantage of the protocol, including KWin, Mutter, Weston, wlroots, GStreamer, GTK, Qt, SDL, Mesa, and mpv. Support in Mesa means that applications will be able to render and display in HDR by using the relevant EGL and Vulkan features. ↫ Pekka Paalanen Colour management has been an important missing piece of the Wayland puzzle, so it’s good to see this finally released and added to Wayland as a new protocol after so many years of work. It’s important to note that the work done so far focuses almost entirely on the entertainment side of things, like watching video or playing games. The other important side, professional colour management for things like photo editing or desktop publishing, is still missing, with the major holdup being measuring physical monitor response (measuring a reference image displayed on a monitor with a hardware device).
LXQt, the desktop environment that is to KDE what Xfce is to GNOME, has released version 2.1.0, and while the version number change seems average, it’s got a big ace up its sleeve: you can now run LXQt in a Wayland session, and they claim it works quite well, too, and it supports a wide variety of compositors. Through its new component lxqt-wayland-session, LXQt 2.1.0 supports 7 Wayland sessions (with Labwc, KWin, Wayfire, Hyprland, Sway, River and Niri), has two Wayland back-ends in lxqt-panel (one for kwin_wayland and the other general), and will add more later. All LXQt components that are not limited to X11 — i.e., most components — work fine on Wayland. The sessions are available in the new section Wayland Settings inside LXQt Session Settings. At least one supported Wayland compositor should be installed in addition to lxqt-wayland-session for it to be used. There is still hard work to do, but all of the current LXQt Wayland sessions are quite usable; their differences are about what the supported Wayland compositors provide. ↫ LXQt 2.1.0 release announcement This is great news for LXQt, as it ensures the desktop environment is ready to keep up with what modern Linux distributions provide. Crucially and in line with what we’ve come to expect from LXQt, X11 support is a core part of the project, and they even go so far as to say “the X11 session will be supported indefinitely”, which should set people preferring to stay on X11 at ease. I personally may have gleefully left X11 in the dustbin of history, but many among us haven’t, and it’s welcome to see LXQt’s clear promise here. Many of the other improvements in this release are tied to Wayland, making sure the various components work and Wayland settings can be adjusted. On top of that, there’s the usual list of bug fixes and smaller changes, too.
Speaking of Wayland, one of the most important parts of the transition is Xwayland, which makes sure legacy X applications not yet capable of running under a modern graphics stack can continue to function. Xwayland applications have had this weird visual glitch during resize operations, however, where the opposite side of the window would expand and contract while resizing. KDE developer Vlad Zahorodnii wanted to fix this, and he wrote a very detailed article explaining why, exactly, this bug happens, which takes you deep into the weeds of X and Wayland. Window resizing in X would be a glitchy mess, if it wasn’t for the X11 protocol to synchronize window repaints during interactive resize, which ensures that the window resize and the application repainting its window contents remain synchronised. This protocol is supported by Kwin and GNOME’s Mutter, so what’s the problem here? Shouldn’t everything just work? KWin supports the basic frame synchronization protocol, so there should be no visual glitches when resizing X11 windows in the Plasma Wayland session, right? At quick glance, yes, but we forget about the most important detail: Wayland compositors don’t use XCompositeNameWindowPixmap() or xcb_composite_name_window_pixmap() to grab the contents of X11 windows, instead they rely on Xwayland attaching graphics buffers to wl_surface objects, so there is no strict order between the Wayland compositor receiving an XSync request acknowledgement and graphics buffers for the new window size. ↫ Vlad Zahorodnii Basically, the goal of the fix is to make sure these steps are also synchronised when using Xwayland, and that’s exactly what Zahorodnii has achieved. This makes the resizing X windows under Xwayland look normal and without weird visual glitches, which is a massive improvement to the overall experience of using a Wayland desktop with a few stray X applications. Thanks to this fix, which was made possible with help from Wayland developers, Kwin is now one of the few compositors that correctly synchronises X windows running under Wayland. KDE has been doing an amazing job moving from X to Wayland, and I don’t think there’s anyone else who has managed to make the transition quite as painless. Not only do KDE developers focus on difficult bugs like this one that many others would just shrug off as acceptable jank, they also made things like the Wayland to X11 Video Bridge, a desktop-agnostic tool to allow things like screen sharing in Teams, Discord, Slack, etc. to work properly on Wayland.
The slow rise of Wayland hasn’t really been slow anymore for years now, and today another major part of the Linux ecosystem is making the jump from X to Wayland. So we made the decision to switch. For most of this year, we have been working on porting labwc to the Raspberry Pi Desktop. This has very much been a collaborative process with the developers of both labwc and wlroots: both have helped us immensely with their support as we contribute features and optimisations needed for our desktop. After much optimisation for our hardware, we have reached the point where labwc desktops run just as fast as X on older Raspberry Pi models. Today, we make the switch with our latest desktop image: Raspberry Pi Desktop now runs Wayland by default across all models. ↫ Simon Long Raspberry Pi Desktop already used Wayland on some of the newer models, through the use of Wayfire. However, it turned out Wayfire wasn’t a good fit for the older Pi models, and Wayfire’x development direction would move it even further away from that goal, which is obviously important to the Raspberry Pi Foundation. They eventually settled on using labwc instead, which can also be used on older Pi models. As such, all Pi models will now switch to using Wayland with the latest update to the operating system. This new update also brings vastly improved touchscreen support, a rewritten panel application that won’t keep removed plugins in memory, a new display configuration utility, and more.
So given that, xmem can be useful as a monitoring tool. Fluffy (my main server) runs both squid and apache, and given that fluffy only has 64MB of RAM, things can get a little cramped. If I suddenly see that the whole of xmem turns blue (i.e. the swap file’s thrashing), then I know that something is odd, and I can easily find out which processes are eating up so much RAM. I said earlier that xmem can brighten up one’s desktop. Indeed, as I use FVWM in a rather archaic fashion, it seems fitting I should like xmem. 🙂 Here’s a full screenshot showing xmem (plus other applications) in action. ↫ Thomas Adam This is basically just an excuse to show off this awesome FVWM desktop shown off in this short little article about xmem, written by one of FVWM’s core developers. It just looks neat.
Nearly three years in the making, the ext-image-capture-source-v1 and ext-image-copy-capture-v1 protocols have been merged into the Wayland Protocols repository for vastly improving screen capture support on the Wayland desktop. The ext-image-capture-source-v1 and ext-image-copy-capture-v1 screen copy protocols build upon wlroots’ wlr-screencopy-unstable-v1 with various improvements for better screen capture support under Wayland. These new protocols should allow for better performance and window capturing support for use-cases around RDP/VNC remote desktop, screen sharing, and more. ↫ Michael Larabel A very big addition to Wayland, as this has been a sore spot for many people wishing to move to Wayland from X. One of the developers behind the effort has penned a blog post with more details about these new protocols.
After two year of development, System76 has released the very first alpha of COSMIC, their new Rust-based desktop environment for Linux. This is an alpha release, so they make it clear there’s going to be bugs and that there’s a ton of missing features at this point. As a whole, COSMIC is a comprehensive operating system GUI (graphical user interface) environment that features advanced functionality and a responsive design. Its modular architecture is specifically designed to facilitate the creation of unique, branded user experiences with ease. ↫ System76 website Don’t read too much into “branded experience” here – it just means other Linux distributions can easily use their colours, branding, and panel configurations. The settings application is also entirely modular, so distributors can easily add additional panels, and replace things like the update panel with one that fits their package management system of choice. COSMIC also supports extensive theming, and if you’re wondering – yes, all of these are answers to the very reason COSMIC was made in the first place: GNOME’s restrictiveness. There’s not much else to say here yet, since it’s an alpha release, but if you want to give it a go, the announcement post contains links to instructions for a variety of Linux distributions. COSMIC is also slowly making its way into Redox, the Rust-based operating system led by Jeremy Soller, a System76 employee.
Ly is a lightweight TUI (ncurses-like) display manager for Linux and BSD. ↫ Ly GitHub page That’s it. That’s the description. I’ve been wanting to take a stab at running a full CLI/TUI environment for a while, see just how far I can get in my computing life (excluding games) running nothing but a few tiled terminal emulators running various TUI apps for email, Mastodon, browsing, and so on. I’m not sure I’d be particularly happy with it – I’m a GUI user through and through – but lately I’ve seen quite a few really capable and just pleasantly usable TUI applications come by, and they’ve made me wonder. It’d make a great article too.
For the uninitiated, what are we looking at? Could it be the Moiré Error from Doom? Well, no. You are looking at (part of) the boot up screen for the X Window System, specifically the pattern it uses as the background of the root window. This pattern is technically called a stipple. What you’re seeing is pretty important and came to symbolize a lot for me as a computer practitioner. ↫ Matt T. Proud The X bootup pattern is definitely burnt onto my retina, as it probably is for a lot of late ’90s, early 2000s Linux users. Setting up X correctly, and more importantly, not breaking it later, was almost an art at the time, so any time you loaded up your PC and this pattern didn’t greet you, you’d get this sinister feeling in the pit of your stomach. There was now a very real chance you were going to have to debug your X configuration file, and nobody – absolutely nobody – liked doing that, and if you did, you’re lying. Matt T. Proud dove into the history of the X stipple, and discovered it’s been part of X since pretty much the very beginning, and even more esoteric X implementations, like the ones used by Solaris or the various commercial versions, have the stipple. He also discovered several other variants of the stipple included in X, so there is a chance your memory might be just a tiny bit different. The stipple eventually disappeared at around 2008 or so, it disappeared as part of the various efforts to modernise, sanitise, and speed up the Linux boot process on desktops. On modern distributions still using X, you won’t encounter it anymore by default, but in true X fashion, the code is still there and you can easily bring it back using a flag specifically designed for it, -retro, that you can use with startx or your X init file. There’s a ton more information in Proud’s excellent article, but this one paragraph made me smile: I will remark that in spite of my job being a software engineer, I had never spent a lot of time looking at the source code for the X Server (XFree86 or X.Org) before. It’s really nuts to see that a lot of the architecture from X10R3 and X11R1 still persists in the code today, which is a statement that can be said in deep admiration for legacy code but also disturbance from the power of old decisions. Without having looked at the internals of any Wayland implementation, I can sympathize sight unseen with the sentiments that some developers have toward the X Window System: the code is a dead end. I say that with the utmost respect to the X Window System as a technology and an ecosystem. I’ll keep using X, and I will be really sad when it’s no longer possible for me to do so for one reason or another, as I’m extremely attached to it quirks. But it’s clear the future is limited. ↫ Matt T. Proud We all have great – and not so great – memories of X, but I am really, really happy I no longer have to use it.
Graham’s TWM page has been around for like two decades or so and still isn’t even remotely as old as TWM itself, and in 2021 they published an updated version with even more information, tips, and tricks for TWM. The Tab Window Manager finds its origins in the lat 1980s, and has been the default window manager for the X Windowing System for a long time, now, too. Yet, few people know it exists – how many people even know X has a default window manager? – and even fewer people know you can actually style it, too. OK, so TWM is fairly easy to configure but alot of people, upon seeing the default config, scream ‘Ugh, thats awful!’ and head off to the ports tree or their distro sources in search of the latest and greatest uber desktop environment. There are some hardcore TWM fans and mimimalists however who stick around and get to liking the basic feel of TWM. Then they start to mod it and create their own custom dekstop. All part of the fun in Unix :). ↫ Graham’s TWM page I’ll admit I have never used TWM properly, and didn’t know it could be themed at all. I feel very compelled to spend some time with it now, because I’ve always liked the by-now classic design where the right-click desktop menu serves as the central location for all your interactions with the system. There are quite a few more advanced, up-to-date forks of TWM as well, but the idea of sticking to the actual default X window manager has a certain charm. I almost am too afraid to ask, because the answer on OSNews to these sorts of questions is almost always “yes” – do we have any TWM users in the audience? I’m extremely curious to find out if TWM actually has a reason to exist at this point, or if, in 2024, it’s just junk code in the X.org source repository, because I’m looking at some of these screenshots and I feel a very strong urge to give it a serious go.
The goal is to be able to drag an icon from a background window without immediately raising that window and obscuring the drop target window when using the click-to-focus mode. This is a barebones description of what needs to happen. It assumes familiarity with code, protocols, etc. as needed. ↫ Quod Video The articles describes how to get there using both X and Wayland, and it’s clear there’s still quite a bit of work to do. At least on my KDE Wayland setups, the way it works now is that when I click to drag an icon from a lower Dolphin window to a higher one, it brings the lower window forward, but then, when I hover for a bit over the other window, it brings it back up. Of course, this only works if the destination window remains at least partially visible, which might not always be the case. For usability’s sake, there needs to be an option to start a drag operation from one window to the next without altering the Z-order.
David Rosenthal, one of the primary contributors to the X Windowing System, has published an awesome blog post about the recent 40 year anniversary of X, full of details about the early days of X development, as well as the limitations they had to deal with, the choices they had to make, and the environment in which they were constrained. Once at Sun I realized that it was more important for the company that the Unix world standardized on a single window system than that the standard be Sun’s NeWS system. At C-MU I had already looked into X as an alternative to the Andrew window system, so I knew it was the obvious alternative to NeWS. Although most of my time was spent developing NeWS, I rapidly ported X version 10 to the Sun/1, likely the second port to non-DEC hardware. It worked, but I had to kludge several areas that depended on DEC-specific hardware. The worst was the completely DEC-specific keyboard support. Because it was clear that a major redesign of X was needed to make it portable and in particular to make it work well on Sun hardware, Gosling and I worked with the teams at DEC SRC and WRL on the design of X version 11. Gosling provided significant input on the imaging model, and I designed the keyboard support. As the implementation evolved I maintained the Sun port and did a lot of testing and bug fixing. All of which led to my trip to Boston to pull all-nighters at MIT finalizing the release. ↫ David Rosenthal They were clearly right. During those days, the UNIX world was using a variety of windowing systems, all tied to various companies and platforms. Standardising virtually the entire UNIX world on X aided in keeping UNIX compatible-ish even in the then-new graphical era, and X’s enduring existence to this very day is evidence of the fact they made a lot of right choices early on. Rosenthal also explains why one of the main alternatives to X, Sun’s PostScript-based NeWS, which was also co-developed by Rosenthal, didn’t win out over X. It had several things working against its adoptions and popularisation, such as Sun requiring a license fee for the source code, its heftier system requirements, and the fact it was more difficult to program for. After trying to create what Rosenthal describes as a “ghastly kludge” by combining NeWS and X into Xnews, Sun eventually killed it altogether. Of course, this wouldn’t be restrospective of X without mentioning Wayland. We and Jobs were wrong about the imaging model, for at least two reasons. First, early on pixels were in short supply and applications needed to make the best use of the few they were assigned. They didn’t want to delegate control to the PostScript interpreter. Second, later on came GPUs with 3D imaging models. The idea of a one-size-fits-all model became obsolete. The reason that Wayland should replace X11 is that it is agnostic to the application’s choice of imaging model. ↫ David Rosenthal This is about as close to a blessing from the original X Windowing System developers you’re ever going to get, but Rosenthal does correctly note that XWayland is a thing, and since not every application is going to be rewritten to support Wayland, X will most likely be around for a long time to come. In fact, he looks towards the future, and predicts that we’ll definitely be celebrating 50 years of X, and that yes, people will still be using it by then.
Today just so happens to be the 40th birthday of X, the venerable windowing system that’s on its way out, at least in the Linux world. From the original announcement by Robert W. Scheifler: I’ve spent the last couple weeks writing a window system for the VS100. I stole a fair amount of code from W, surrounded it with an asynchronous rather than a synchronous interface, and called it X. Overall performance appears to be about twice that of W. The code seems fairly solid at this point, although there are still some deficiencies to be fixed up. We at LCS have stopped using W, and are now actively building applications on X. Anyone else using W should seriously consider switching. This is not the ultimate window system, but I believe it is a good starting point for experimentation. Right at the moment there is a CLU (and an Argus) interface to X; a C interface is in the works. The three existing applications are a text editor (TED), an Argus I/O interface, and a primitive window manager. There is no documentation yet; anyone crazy enough to volunteer? I may get around to it eventually. ↫ Robert W. Scheifler Reading this announcement email made me wonder if way back then, in 1984, the year of my birth, there were also people poo-pooing this new thing called “X” for not having all the features W had. There must’ve people posting angry messages on various BBS servers about how X is dumb and useless since it doesn’t have their feature in W that allows them to use an acoustic modem to send a signal over their internal telephone system by slapping their terminal in just the right spot to activate their Betamax that’s hotwired into the telephone system. I mean, W was only about a year old at the time, so probably not, but there must’ve been a lot of complaining and whining about this newfangled X thing, and now, 40 years later, long after it has outgrown its usefulness, we’re again dealing with people so hell-bent on keeping an outdated system running but hoping – nay, demanding – others to do the actual work of maintaining it. X served its purpose. It took way too long, but we’ve moved on. Virtually every new Linux user since roughly 12-24 months ago will most likely never use X, and never even know what it was. They’re using a more modern, more stable, more performant, more secure, and better maintained system, leading to a better user experience, and that’s something we should all agree on is a good thing.
Submitted by