Hacker News Reader

Comment by oleg_antonyan | Hacker News Reader

X is almost 40yo, stable, reliable, difficult to maintain. Wayland is 15yo, barely usable. Any old timers remember 1999 when X was 15? Wayland is like IPv6 of desktops

View on HN

Anyone who believes that XFree86 was stable in 1999 was apparently running a different XFree86 to me. The sysrq key was mostly useful at the time for using the SAK shortcut to kill all processes on the current terminal, which with luck included your wedged XFree86 which would then get respawned by xdm. I don't miss those times.

XFree86 in 1999 might not have been, but in 1994 when I went to university in the UK and was using Sun computers which were solely X servers to display programs running on the "main" shared computer in the corner of the room, X and all the associated software was all stable and worked fine.

Solaris X Server wasn't the same.

At our uni, we used DEC and had vxt2000 terminals. It worked fine, just like wayland does today. But it wasn't rock stable, or even remotely secure.

Secure no, lol. But in those days telnet was still the norm.

At my college they didn't even have xauth implemented which was loads of fun embarrassing other users with xv and some cool pictures :P Or xblast

We didn't have xauth either; our fun was xeyes.

X11 became really stable in the late 00s. And since the introduction of DRI3 it is at the same technological level of Wayland concerning the efficient buffer swap mechanism. X11 is however still miles ahead on the architectural level. Parts of the system like window managers or compositors can fail or be replaced at runtime without affecting running clients. Wayland lacks the appropriate standardized interfaces for that and there are not plans if not outright refusal to actually implement them.

The choices of architecture seem to reflect different priorities, there are things that the Wayland architecture does better than X and vice versa, aren't there? Hard to say X11 is ahead architecturally if you pick features that Wayland may not consider important. I've seen commentary from people who have worked intimately on both protocols and implementations of both who consider Wayland to have the better architecture.

> I've seen commentary from people who have worked intimately on both protocols and implementations of both who consider Wayland to have the better architecture.

For those interested in details: https://www.youtube.com/watch?v=GWQh_DmDLKQ

Most of the criticisms in this talk are solved with DRI3. Also this guy makes money with a consultant agency that mainly works on Wayland and indirectly profits from shitting on X11. This is not a neutral source.

> Most of the criticisms in this talk are solved with DRI3

Not true.

> Also this guy makes money with a consultant agency that mainly works an Wayland and indirectly profits from shitting on X11.

Maybe his employer works on Wayland because there are no X11 jobs?

> This is not a neutral source.

He has experience with both, and he presents his arguments.

Right? I really feel like not enough attention is paid to the question of: Who is paid to work on "the successor to X" and what influences are at work there?

Seems to me that would be an obvious place to look for "why Wayland sucks," given that unfortunately, "paid" sometimes leads one to "exclusivity."

Seriously, if you downvoted this without replying, you're a coward. At LEAST answer the question. Maybe I'm wrong?

This link comes up in literally every Wayland thread and it is even more bullshit now than it was in 2013 when it was first posted (and it was bullshit then too). It is titled "the real story" but it is quite the opposite.

A few key points:

1) he laughs at how X has a bunch of extensions. https://wayland.app/protocols/ hypocrites much. In 2013, since it was completely unusable, it probably didn't have many. But turns out real world use leads to "useless" features being reimplemented.

2) he complains about how X.org has broad hardware compatibility. As if that's a bad thing. Meanwhile wayland, even now it still doesn't work reliably on half the graphics chips on the market.

3) It complains that certain X features are not fully network transparent. True, but most are and you can detect at runtime and gracefully degrade. Wayland "fixes" this by just dropping the whole feature.

4) it flat-out lies saying the X server does nothing yet it is so much hard to maintain code. The core X protocol provides backward compatibility and is rock solid (and really easy to impelment from scratch btw, someone did it in Javascript for a tutorial for crying out loud). Meanwhile the Wayland compositor keeps accumulating everything because of point 1. Need a screenshot? Add it it the compositor. Need a hotkey? Add it to the compositor. Need drag and drop? Add it to the compositor. Need a notification icon? Add it to the compositor. In X, all those are peer to peer. Graphics are actually a relatively small part of a graphical user interface, something Wayland is still slow to learn.

5) He complains that certain applications are written inefficiently with blocking calls which is inefficient over a network connection. Wayland's calls are ALL blocking and just has no network connection.

6) Complains that X may draw things unnecessarily. Indeed... but there's an extension to disable that. Easy fix. Wayland even uses the same drivers!

1) no, he complains that X11 has a big core and then extensions. Extensions are fine, but they were unable to kick out parts of the core, because it is the core and something somewhere assumes it is there. So they had to maintain it, despite not being used in practice, except by that little something that nobody can point their fingers at.

2) he talks about obsolete hardware. There's no really a point to support s3 trio, at the expense of support for modern hardware, which works ink wastly different way.

3) That graceful degradation is in practice the same, as just using Wayland. Ever tried to use modern X11 app over network? RDP is vastly better experience, (and RDP support is wip in wayland).

4) This is so wrong so I won't even react to it.

5) Wayland calls do not wait for reply. You rapid fire requests and then collect responses as they come. Heck, you can even get a response you didn't ask for ;)

> he complains that X11 has a big core and then extensions. Extensions are fine, but they were unable to kick out parts of the core, because it is the core and something somewhere assumes it is there.

The thing that I find ridiculous about this attitude is that you have two choices:

1) Remove parts of the core that some (mostly old, unmaintained) applications rely on, which will break them. You'd probably have to call it "X12" now, but that's fine: most X11 applications would continue to work with no (or very few) modifications.

2) Throw out the entire system and build a new one from scratch, that literally no applications will work on until new toolkit backends are written and some applications themselves are rewritten or at least fixed up. Those same old, possibly unmaintained apps that would stop working in #1 are still not working, but now it's along with literally everything else too.

> RDP support is wip in wayland

If I had a dollar for every time I heard "$IMPORTANT_FEATURE is WIP in Wayland", I'd be able to get several pizzas delivered.

3) Build a new system that supports the old system reasonably well and doesn't prevent people using and improving the old system until the new one meets their needs.

> If I had a dollar for every time I heard "$IMPORTANT_FEATURE is WIP in Wayland", I'd be able to get several pizzas delivered.

It's true though there have been features missing. It's good thing that they are being worked on though, no? The X protocol and the Xorg implementation are both abandonware, so your comment comes across as positive, because missing $IMPORTANT_FEATURE in X/Xorg is not WIP.

> That graceful degradation is in practice the same, as just using Wayland. Ever tried to use modern X11 app over network? RDP is vastly better experience, (and RDP support is wip in wayland).

I do, in fact, use modern X11 apps over the network literally every day. Some are better than others - if the programmer made the effort to actually gracefully degrade it can be a considerably better experience than the ones who just shoot a constant stream of bitmaps down the wire (which do work better on rdp, i remember once upon a time, I'd ssh to my linux box and set up port forwarding to a windows box on my lan so i can remote desktop to it, then run Xming from there... which is absurd that that actually worked better), but if you do it well, remote X is very nice to use.

The seamless integration of windows from multiple computers is a thing to behold. Remote Desktop is great and I like a lot about it, but even the "Seamless" rdp doesn't work as nice as X.

If you don't mind answering, what do you do that uses GUI over network? Not looking to argue or try to claim <something> would work better or anything, just curious what people use it for seriously these days.

One common example is running data analysis/reduction remotely on a big fast box and then looking at the products on that machine via X11 forwarding. On a fast low-latency connection there is hardly any noticeable difference between running the application locally or remotely (it's just another window locally opposed to another window in another desktop in a window).

I use tons of things on it. When I use my laptop, often I'll run a local browser (though sometimes I run remote browsers too - Chromium's core works actually surprisingly well on a remote X link - but the bigger problem there is that chromium doesn't support multiple instances, so if I left the browser open on the desktop, the cookies and history aren't shared on the remote instance on the laptop which defeats the purpose of reusing the instance anyway, but sometimes the shared passwords still nice to have) with most everything else being run remote.

Among the specific applications are my developer tools, image viewers, music editors, the apps I'm actually working on, etc. Of course, some of these also work fine on ssh terminals and I do plenty of that too, but there's just no need to be limited and I'll run whatever I want to.

The last time I had to use remote X11, it was to run Oracle's dbca. Everything else was possible to do in some other way, usually more comfortable.

RDP does support integration of windows from multiple computers, in a way of RemoteApps. Even if you are running GUI apps inside WSL2 locally, you are using it.

I was about say, literally WHAT? x2go destroys every other solution I've ever tried for this.

> Graphics are actually a relatively small part of a graphical user interface, something Wayland is still slow to learn.

This I think is a key insight. I talk about this in another post, but I've been working on "porting" parts of Xfce to Wayland, and there are so many things missing in Wayland that have nothing to do with "graphics" that means that Xfce+Wayland will be missing a lot of useful features until/unless Wayland protocols are invented or extended to make them work.

This sounds suspiciously like the conversations around "just use OpenGL/Vulkan instead of DirectX".

Because DirectX is more than just Direct3D?

Used to be; meanwhile, DirectDraw/DirectInput/DirectSound/DirectPlay/etc have been dead for quite a while.

I don't do Windows development, but I remember that used to be the rebuttal from game devs that Linux missed the point about all the ease of use features that Microsoft provided.

Although all the other Direct services are dead, have they not been replaced with new versions?

And it was true at the time, thought the rebuttal would be "use SDL then" -- it did provide equivalent functionality, packaged into a single library.

They were replaced not by new versions, but by new or even existing libraries/subsystems, that are not marketed as Direct anything anymore. Just like alsa or pulse are not marketed as SDL or Open anything either.

TIL, thanks!

None of Waylands internal functions between a client and compositor are blocking or synchronous to my knowledge. Generally you fire off a message and will later receive an event back from the compositor, which is happening in an event loop.

There is an exception, which is the explicitly blockling "roundtrip" function(s), but that is meant for special cases only.

Being asynchronous was an design goal for Wayland from the very beginning.

This isn't that different than X though which also has the fire off a message and receive event back. Very few of the functions actually make you want (even in xlib, which wraps the protocol itself to be a bit easier to use from C, the majority of functions still are async - much to the chagrin of newbies trying to decipher error messages)

What do you mean by all Wayland's calls being blocking though?

It isn't really Wayland's calls itself, I prolly stretched too much there, but the main thing is the async discussion usually comes up in the context of running applications remotely, which Wayland simply doesn't support. If you do a loop of XInternAtom (which btw you shouldn't do, even in xlib - notice that there's also XInternAtoms, plural, for that kind of thing which batches them to reduce wait time...) locally, it is unlikely to matter. The time spent there is near zero anyway. But remotely, now you might be looking at several ms per iteration and that adds up fast. Now the blocking aspect can become problematic.

Since Wayland doesn't support this kind of network remote use anyway, the distinction doesn't matter. Local X vs Wayland are both fast.

> It isn't really Wayland's calls itself, I prolly stretched too much there,

Do you mean simply incorrect i.e., that Wayland calls are not all blocking? Or do you mean that in practice there are some important high-level situations that do require a round trip despite the low level purporting to be mostly asynchronous?

> Since Wayland doesn't support this kind of network remote use anyway, the distinction doesn't matter. Local X vs Wayland are both fast.

Wayland can run to remote displays though, right? You could argue it's not complete or well supported or nicely integrated into the core protocol or whatever, but you can literally use it today and probably have a package to do it available in any Linux distro you're using (e.g., waypipe). So it's hard to see what you're getting at. Wayland may not have been made with transparent networking support foremost in the protocol but AFAIK the idea was always that you'd be able to do remoting by forwarding buffer contents with the protocol.

Async X11 was tried with xcb, and it failed. In the above linked video, this is illustrated in the "Bad IPC" part, with the example of gedit startup (gedit uses gtk and gtk uses xcb) and where it blocks.

He claims gedit does 130 blocking InternAtom calls, 34 blocking GetProperty calls, and 116 property change requests. None of those are actually using the available async functions (or even available XInternAtoms call to batch all those 130 into the main thing).

Since this video is coming up on ten years old, it might have been true at the time, and gtk/gedit have since changed the implementation. But regardless, if the video is accurate, they didn't use the non-blocking calls. If the video is not accurate, it is meaningless anyway.

> The core X protocol provides backward compatibility

I had a bit of fun a while back trying to get an old X/11 terminal to work with a modern Linux machine and was somewhat surprised I was able to make it work. Sort of at least. Many display managers didn’t implement the proper protocols, but XDM did and I was able to get it to work at least a few times.

> Anyone who believes that XFree86 was stable in 1999 was apparently running a different XFree86 to me

XFree86 on Linux wasn't very stable in 1999 (although it was more than usable, more than Wayland is today).

X11 on IRIX in 1999 was pretty stable.

Parent said X, not specifically XFree86.

also something to consider: how many people were working on Xfree86 in 1999 and how many people are working on Wayland in 2023?

What was the state of the technology, tools, documentation, availability of specs, reverse engineering etc. back then?

AFAIK nobody was being paid by major tech companies (RH, just to name one) to work on free software in 1999.

Parts of X have always been free. Sun and DEC among others contributed to the development of X11.

XFree86 worked fine for me since 1994. I sometimes had problems when exiting a video game like Doom or Quake. SVGAlib would give problems but that wasn't X.

Yep, my point was my experience in 1999 with XFree86 was with Linux, which was less stable than today per se, before that I only used Xsgi on SGI Workstations, which was proprietary and was already HW accelerated.

It would help if you did not give easily verifiable facts to reveal the inaccuracy of your recall. You may have been using Doom in 1994 but you certainly were not using Quake. If this is an accurate memory, what year is it from?

I installed Linux on my PC in September 1994 at the start of my sophomore year of college. I remember playing Doom during that school year from Sept 1994 to May 1995.

The Quake Wiki says Qtest was released Feb 24, 1996 and I remember playing that the week it was released.

I always felt that X11 on Linux was just as stable as X11 on SunOS, Solaris, Ultrix, HP-UX, IRIX, and AIX.

Xfree86 is the commonly-used but bastard stepchild of X. X started on DEC, Sun, HP, SGI unix boxes, Linux came later.

Linux is and was awesome, I still recall installing it using boot/root floppy disks, but X was around well before the '386 machine in the corner being used for CD creation was recognized as "Hey, this is actually useful"...

> Wayland is 15yo, barely usable

It's the default on several distros. I regularly play AAA games on my gentoo gaming PC, using proprietary NVIDIA drivers, on KDE Plasma, with little or no performance differences compared to X11.

Even the Steam Deck, arguably the most popular linux PC, runs its default UI on Wayland.

Gamescope is wayland while the desktop is x11

A little weird to classify the Steam Deck as a "personal computer". It's a special-purpose handheld gaming device that just happens to run Linux & Wayland under the hood.

While I wouldn't call Android phones "personal computers" either, they're much closer to being the "most popular Linux PC" than a Steam Deck is.

I did say "arguably".

I mean more in the sense of the hardware it uses, i.e. it's PC-compatible (x86) hardware that runs a desktop linux distribution by default.

The Steam Deck is literally a PC, no doubts about that. It's even more "P" than many other "C"s, like most Apple hardware for instance. But I think that the notion that it somehow validates Wayland as mature tech is kinda weak.

It appears that the justification for switching to Wayland in many distros (just like systemd before it) was so that the devs could actually abstract away work on these components and invest time into their flagship features (WM, filesystems, shells, look & feel, the works). For what its worth, looks like this was achieved.

At least it's closest to a "Linux distro" software-wise.

(Otherwise Android phones would be the most widespread Linux devices with a powerful GUI.)

The Steam Deck is not locked down, unlike e.g. the Nintendo Switch.

I have tried Wayland several times over the last few years, but I have many persistent niggles caused by third parties refusal to fully support it. For one, Discord doesn't support push-to-talk VOIP on Wayland (I believe it requires them to create a daemon for global keypresses). I also recently 'upgraded' my RX 5700 XT to a 3070, because I received the 3070 for free, and Nvidia just refuses to support Wayland.

It's not that Wayland is bad. It's that companies, whose primary focus is Windows, just refuse to develop for it.

Does it? Desktop mode reports itself as X11. I don't think Gamescope supports Wayland either...

Gamescope itself is a wayland compositor, although it only supports X clients at the moment, getting frames through Xwayland.

Wayland is the default on RHEL since 2019.

Wayland is the default on Centos since 2019.

Wayland is the default on Ubuntu and Debian since 2022.

In Arch, Wayland is the default for GNOME installs.

Wayland is far from "barely usable"

And yes, I remember 1999. X was a pain to get working properly with many graphics cards. Some things never change...

Have you ever tried sharing your screen? Do your organization uses Microsoft Teams? It is barely usable for quite some people.

Wayland screen sharing works fine (in Chrome, Webex...). It doesn't work in Teams, but that's Microsoft's issue, since they didn't bother with implementing it.

If it's preventing your users to switch to your platform, it's your problem too...

Microsoft releasing worse implementation for competing system? How surprising. /s

The linux team client seems to be completely unmaintained and might be thrown away soon. If you need to use teams, use it in a browser.

This, teams works just fine in the browser.

I use linux at home, but have to use Windows at work. Microsoft team's desktop app even runs like ass on Windows.

The Linux Teams client has been unceremoniously abandoned. The debs have been removed from the ms-teams repository. The download instructions haven't been updated, it's managed shockingly poorly.

the rpm repo is also empty, in the same unceremonial way.

> Do your organization uses Microsoft Teams? It is barely usable for quite some people.

That describes Teams on any platform.

I'm on Arch on my work machine and it started working with pipewire about 3 months ago... no config necessary just works as intended both screen and window. There are some others at work on Ubuntu LTS but that is because Ubuntu is using ancient packages.

Ah, but the reply was about defaults. Do any of those distros ship with Pipewire as the default? If so, I'm sure it hasn't been since 2019 as the original poster claimed.

Pretty much all distros ship pipewire. Just not as the default audio server.

Fedora has it as default, but that's only been since 2021 not 2019. It's still been a couple of years though.

FYI, the native MS Teams client, which doesn't implement screen capture on Wayland, has been discontinued. You can't even download it any more!

https://packages.microsoft.com/repos/ms-teams/pool/main/t/te...

> Wayland is the default on Ubuntu and Debian since 2022.

In Debian, only GNOME has Wayland by default. KDE wouldn't be there for next release, and there's a long list of (unsupported) [0]

[0] https://wiki.debian.org/Wayland#Desktops

Wayland is default on several distributions and has some pain points, much like X did in 1999 (it had many back then, and in fact still does today). But it’s definitely usable, it’s my daily driver here.

The main difference is in 1999 X did not have real alternatives, so if you wanted a graphical desktop, you had to fix the X bugs period. Here if you don’t want to deal with wayland issues you can fall back to X. It makes for slower development…

Wayland is usable. It is simply not fully used.

Wayland is just a protocol and there are multiple implementations in different compositors. Instead of focusing on a single great implementation, there are multiple average and weak implementations.

It puts quite a bit of pressure on desktop environment developers and it seems like they don't really care about many of the defined protocols. https://wayland.app/protocols/

I wonder if Linux desktop would be in a better state now if Wayland also came with a new and advanced compositor used by new DE's and not just a reference example one.

I also want to point out that you will likely get a better Wayland experience on KDE. They are much more active in implementing Wayland protocols and overall it feels more solid.

This makes me sad because I really like how Gnome looks like, but Gnome developers don't seem to care as much about Wayland stuff.

I have been a KDE user since 2010. I've started this habit a few years ago that every time I upgrade my desktop distro's release, which is twice per year (first Kubuntu, now NixOS), I try out the wayland mode for a while, until I find the bugs to be too annoying. A few years ago I switched back after a couple of hours. The last time I tried I remained there for 3 months. So yes, a lot has improved, but I'm still back on X11.

I'd also confirm this. Gnome started out ahead by virtue of being the target or idealization of most of Wayland's features, but it's stagnated. Nothing is ever improved and they refuse to fix the technical problems holding them back, like the lack of I/O being separated from drawing in Mutter. They claimed to have improved it several times, but it's just as bad as ever. Either they're hesitant, or they just don't have the time and resources to break and rebuild it properly.

Meanwhile, KDE/Plasma's kwin finally stepped past them. And there's also the kwinft project that's rebasing kwin idiomatically as a wlroots compositor.

We may finally get full Wayland adoption, but I don't think Gnome is going to be prominent in it anymore.

> It puts quite a bit of pressure on desktop environment developers and it seems like they don't really care about many of the defined protocols.

The problem is that the existing protocols are missing key functionality that desktop environment developers need (source: I am one).

Want to list all the toplevel windows that are on a particular workspace so you can write a pager or taskbar widget? Nope, can't do it. The foreign-toplevel protocol and ext-worspace protocol (the latter of which has been in standardization purgatory for 2-3 years now) don't know anything about each other, so you can't do that.

Want to write a widget that lists windows and lets you do a bunch of operations on them? Well, you can, if all you care about is minimize, maximize, fullscreen, and close. If you want to pin/unpin windows, move them between workspaces, resize them, or move them around on the current workspace... nope, can't do it.

That's just two examples off the top of my head. Looking at the list of Wayland protocols, and then digging in to figure out what they provide shows them to be immature and severely lacking.

>Want to list all the toplevel windows that are on a particular workspace so you can write a pager or taskbar widget?

I can do this with a trivial "jq" script in Sway with this command:

    swaymsg -t get_tree

Not sure why it wouldn't be possible for other compositors to offer an interface for this like Sway does.

Wayland is the default on Fedora, Ubuntu, Red Hat, and Debian. The majority of desktop linux users is probably on Wayland by now.

Conditionally default. Except the latest version of Fedora, all the others fallback to X on nvidia hardware.

The majority of graphics cards are Nvidia which don't play nicely at all with Wayland.

The average user has a laptop with an Intel or AMD iGPU. Gaming machine are niche.

The average user isn't running a Linux desktop.

That may not be true any more.

ChromeBooks were outselling Macs from 2017-2021, although the pandemic meant hundreds of millions of people suddenly needed new computers for remote working and the kids to use for remote schooling, so sales spiked and have since collapsed.

But they sold ITRO 100 million units per year for several years.

China's 5-3-2 program is also nearing its end:

https://medium.com/technicity/chinese-3-5-2-policy-is-a-majo...

That means hundreds of millions more Linux PCs in the PRoC.

As such, that's somewhere around quarter to half a billion Linux desktops in the last few years, and maybe twice that.

Windows PC sales are struggling:

https://www.computerworld.com/article/3675895/pc-sales-fall-...

Still hundreds of millions of units, but they're falling.

More people are staring at Linux all day than you might think.

Chrome OS isn't Linux desktop.

Even if you mention Linux sandbox environment, it is only available in selected models.

I disagree.

It's a relatively standard distro up until the GUI layer, based on Gentoo.

I'd agree that Android is something else, but ChromeOS is mostly the usual GNU + Linux stuff, and a weird display server which is Chrome rendering direct to the screen.

Then have fun running GNU stuff on ChromeOS, specially the devices that don't support the GNU/Linux sandox (crostini).

Maybe take advantage of WASM for it.

And even if Crostini is available, the usual stuff

https://support.google.com/chromebook/answer/9145439

-- Cameras aren't yet supported.

-- Android devices are supported over USB, but other devices aren't yet supported.

-- Android Emulators aren't yet supported.

-- Hardware acceleration isn't yet supported, including GPU and video decode.

-- ChromeVox is supported for the default Terminal app, but not yet for other Linux apps.

> Then have fun running GNU stuff on ChromeOS

I do. My only ChromeOS device at present is an old Thinkpad T420 with a Core i5 and 6GB of RAM. It runs very quickly with ChromeOS Flex. Currently I have Firefox ESR running on it, and DOSemu. Inside DOSemu I have MS Word for DOS.

It's a Linux. It runs Linux stuff thanks to a built-in feature, and since Flex came out, the Linux support has improved visibly: so for instance Firefox now works properly with either a full titlebar or none, and this depends on the settings within Firefox not on ChromeOS.

It works, it runs, it's useful, now, today.

Personally I don't give a toss about any of the other things you mention. It plays videos smoothly, it's fast and responsive, and my webcam works. I've tried Skype, Whatsapp, Facebook Messenger and Zoom in ChromeOS and all worked fine.

Sure it may be limited. I am not denying that. But it's selling well up against Windows and Mac, which is something no other Linux distro has ever managed to do. Despite all their fancy acceleration features and being free, ordinary consumers are not interested, even though they are FREE.

ChromeOS is not free: you can only get the full version by buying it on custom hardware, and you need a Google account to use it. Those are significant drawbacks compared to every free distro...

And yet 10x more Chromebooks sell per year than all the free distros put together can GIVE AWAY.

That is not just noise. That is no rounding error. That is massive.

The year of Linux on the desktop came, over half a decade ago now, and the Linux world was too busy with infighting and squabbling over Snap vs Flatpak and other pointless nonsense to even notice that the mainstream consumer world has adopted Linux bigtime.

A bit late to this party, but you are woefully, badly misinformed as to what ChromeOS is, and what you can run on it. Well over a decade ago, I was running a full suite of gnu-linux devtools, natively, within chromeos.

You don't even need to install a chroot from another distro. Just get a gcc (chromebrew was the first to package this), and the rest is just gentoo linux (with portage ripped out - and in the early days, you could run a shell script which PUT PORTAGE BACK IN).

And if you take the time to understand the wierd partitioning layout, a couple of bind mounts in the right places is all you need to get the chromeos gui file manager (which is rather crappy, btw) to see your stuff.

The average user isn't running a desktop.

Oof, that hits hard, but you're probably right: I expect there are more people who primarily (or even exclusively) use a smartphone or tablet than a general-purpose computer running a general-purpose OS.

It's a sad state of affairs, to be sure.

There are libre mobile devices, but approximately no-one uses them, just like approximately no-one uses Linux on the desktop. Unless some large vendors start shipping Linux by default on all their devices, or the current mainstream OS vendors become really obnoxious and people go searching for alternative devices with Linux installed by default, that isn't going to change since people really don't want to have to do installs themselves.

I have been running linux on various hardware since about 2003. Zero of those computers had discrete gpus.

The last Linux box I used that had a discrete gpu had a Matrox G400 (released 1999). Every one since then has been Intel onboard.

No, but the average Linux user has probably been bitten by nvidia compat issues so much in the past that they're even more likely than the average generic laptop user to be using Intel or AMD graphics.

> The majority of graphics cards are Nvidia

The majority of graphics cards are Intel.

Very few graphics cards are Intel.

OK, since we are splitting hair there, then most graphics controllers and gpus used are Intel.

Also note, that users that use graphics cards are minority themselves.

This isn't nearly as true as it used to be. I regularly game on KDE Plasma on Wayland on a 3080 Ti with the proprietary NVIDIA drivers, and it works fine.

Until they have to share screen in a meeting and give up tweaking flags in different places, login using X and never look back again.

Seriously for anyone who works remotely sharing screen is essential, but it still doesn't work flawlessly in Wayland.

> Until they have to share screen in a meeting

This was absolutely true, until I switched to pipewire. Once I did, this started to just work, with no issues whatsoever. (No configuration required, just followed Debian's package dependencies switching to pipewire and it started working in Firefox.)

So then, in other words, the default setup is still broken?

No, for many distros the default setup is now pipewire.

Screensharing works perfectly in firefox and given how awful linux versions of zoom, teams, etc are, that's all that matters

Just do real time video encoding of the screen and forget about X.

I recall none of these distros change existing installs, also plasma (KDE) is often still on X11. So it depends on proportions of new users+new installs+selected DE+video card...

I don’t identify as an old timer but I was using NCD X-Terminals connected to Data General Aviion back in the mid 90s and they were solid as a rock.

XF86 also worked quite well in the late 90s but it did require a lot of work and there were warnings that certain settings could blow the monitor.

Fun times.

I remember creating a new modeline and adding it to the list. Then using ctrl+alt and +/- to cycle through the modes. I would get to the new mode and the monitor would start buzzing and clicking and the image would flicker. I would quickly toggle to the next mode that was "safe" then go back and edit the modeline and try again.

I did manage to get my monitor to run at 1280x1024 @72Hz but couldn't make it go 75Hz

to be fair, we had Keith Packard working with us at NCD during the mid 90's. it helped to have someone innately connected to X11.

That NCD terminal wasn't mine, but I had the use of it while I worked at a customer's site for 6 months or so. One of my all-time favourite devices. I wrote so much code on that thing. Thanks!

I ended up leaving with a couple of generations of x terminals, my favorite which could pxe-boot and had a compactflash-like slot on it.

the weirder was an Apollo we had for an internal auction, strangest unix system I've ever run. but the b&w screen was very high resolution for the time and quite crisp.

X11 in '99 was stable, reliable and difficult to maintain :).

Let's see where Wayland is in 25 years.

Old timers remember when xmodconfig could be used to burn monitors.

Not exactly burn them, just gently char the innards until the finest magic smoke was released.

Easy. At the very least, IPv6 works well, and does not introduce new significant limitations.

As a user(!), Wayland is much more usable at 15 than X was at 25.

I'm not sure if it was 1999, but I remember Mir being the golden future of display servers and Wayland being a pipedream. That didn't work out very well.

> “barely usable”

I run Hyprland just fine with Wayland, I seriously doubt it is barely usable.

> IPv6 of desktops

Dunno if you’ve looked at your ip link lately but you probably have an ipv6 address!

> I run Hyprland just fine with Wayland, I seriously doubt it is barely usable.

Same. I wasn't convinced about Wayland until I tried Hyprland. It's just great!

The design of X11 meant many windows managers, which mostly were average. But that was ok, as the issues could be addressed by separate tools

Wayland had 3 issues 1) not many tools (now there's wev, ydotools...) 2) they were limited in what they could do, as the keys to the kingdom are mostly given to the compositor, and 3) outside sway (with its own issues) the compositors were not so great.

So if you didn't have a good one, or if it was missing essential options, you suffered until you went back to X: to prep my laptop for uni in the late 2010s I evaluated wayland but returned to X as it was simpler to get a better experience.

Now with hyprland, I love wayland: I can script again very precise behaviors with hyprctl and wlrctl. The foot terminal emulator is great. Edge works fine with the right wayland options.

Much has changed since I first discovered Wayland in 2016: I'd put 50% of that on hyprland (it's seriously wonderful) and the other half on the availability of more wayland-compatible tools.

I'm eagerly waiting for the patches for wine on wayland: not just because I love Office, but because for a long time it was said to be impossible to have a good wine experience on wayland.

Well, these patches prove it wasn't impossible, just a bit hard, and old people are stuck in their ways and hate change even for better tools.

It's like how systemd was so unpopular at first, except it had most of everything ready. Wayland in comparison was missing many small tools that are only important for very few people (ex: for scripting) but about everyone had one thing they couldn't do on Wayland.

Having an ipv6 address is the easy part. Having ping6 actually able to ping something over ipv6 is another thing entirely.

I don’t know that much. Why does ping6 matter? Isn’t most internet traffic HTTPS? Like when I check my cloud logs they’re all coming from ipv6 addrs, so I figured it was working

1999 had many people hitting Ctrl-Alt-Backspace on a semi-regular basis. It was not all puppies and unicorn farts back then.

I remember in 1996 when we were told that X12 (Broadway?) would be viewable within a web browser as well as on our local display...

It's basically imperceptible that I'm using wayland on ubuntu (from default config on install). It works, no problems.

I think you’re being unfair to IPv6

In terms of usability - definitely. But it's built on top of similar unfulfilled promise: we're running out IPv4 addresses VS X11 is unmaintainable legacy full of security bugs. 20 years later IPv4 is still dominant, Wayland is still unusable and X11 just works.

> Wayland is still unusable

Wait, what have I been doing my work on then? Someone should inform Ubuntu and Fedora, too. Who knew it hasn’t been possible to use the most popular Linux distro out of the box for two years?

YMMV. When it reaches the level of X11 that "just works for everyone without preconditions" it will become usable in my coordinate system

X11 is not usable for everybody without preconditions though.

Exactly, there's hundreds of lines of illegible X configuration for every such "just works" setup.

There's a difference between "the community has learned to deal with it" and "just works".

I honestly don’t get people, like were these people just extremely lucky and never had to tweak anything? Like, I remember times when I had to blindly log into my user and try to fix my setup from there, purely by muscle memory.

> I honestly don’t get people, like were these people just extremely lucky and never had to tweak anything?

Yeah, that's about how I feel about Wayland. I'm not sure quite why there are two groups of people with such wildly different experiences talking past each other, but I suspect it comes down to what each user wants the software to do and what hardware they're running on.

I remember in the early 2000s still needing to write to a config file to get X to work on my desktops at the time. Was it 30 years old at that time? I've been running Wayland crash free for a few years already, without the need to touch a single config file. Does that mean it reached better usability at least twice as fast compared to X?

I remember having to tweak Xorg.conf in the late 00s. The X11 xkcd[1] is from 2011.

[1]: https://xkcd.com/963/

> But it's built on top of similar unfulfilled promise: we're running out IPv4 addresses.

It’s not an unfulfilled promise. We’re out of IPv4 addresses and have been for almost a decade.

NAT444444444444444444444 is not the solution.

Sure, but the end result is that nobody can host a service with an ipv4 address only. You would be missing out on the majority of your audience.

You absolutely can. I’m single stacking IPv6 on my fresh hetzner box.

Cloudflare in front of web services and it just works(tm).

For everything else - Argo can do arbitrary TCP (requires cloudflared though) and then you can start bugging your ISP about the very real need for IPv6.

> Cloudflare in front of web services and it just works(tm).

Well... yeah? That's adding support for both stacks; just because you farmed it out to a middle-man doesn't mean that it's not there.

> Well... yeah? That's adding support for both stacks; just because you farmed it out to a middle-man doesn't mean that it's not there.

Not strictly true. It means that you only have to worry about IPv6 addresses in Layer 7, and you can forget about layers 2 and 3 altogether.

And Layer 7 isn’t a problem for people who should be deploying IPv6 right now because https://ipv6bingo.com/

Well, most providers worldwide still use IPv4 which means that cost of switching to IPv6 is higher than cost of maintaining workarounds for 10 years, and who knows, maybe it will be the same for another 10 years

No it's higher because they've started charging for IPv4 addresses, they don't want to lose their cash cow...

But it's really not. About 85% of the entire public IPv4 range is currently announced.

Transfering IPv4 prefixes comes with a 2 year transfer restriction period.

IPv4 addresses currently cost about $50, and you have to buy an entire subnet at once, minimum /24.

It makes perfect sense to start charging for them if you're running out of them and don't want to buy additional prefixes.

Not to mention that there's also additional cost involved in case someone was using that particular address (or even worse multiple addresses from the same /24) for spam or malicious purposes, because that means that the entire prefix is currently trashed and there's some effort involved for it to be removed from all the independently maintained blacklists etc.

Yes, having everyone involved learn IPv6 is more expensive than burying your head in the sand and adding another 4 at the end of NAT444444444444444444444, but at some point it’ll just be too ridiculous.

It has been Good Enough™ unfortunately. At this point I feel like we will never see IPv6 fully deployed.

X11 cannot handle the average user connecting an average laptop to an average external monitor (no usable per-screen scaling). Maybe this was good enough in the 80s, but today it is seriously holding back the platform.

This is my situation. I use sway for this reason and it’s just about okay if you’re not on Nvidia.

Screen sharing is the main gripe, it’s a pain to configure, involves a lot of different bits of software which have to be orchestrated and none of them are mature enough not to break occasionally in an unexpected fashion.

Sigh. X11 actually can. Even in its original release it supported different PPIs for different displays. But a lot of Linux programs (especially GTK ones) will flat out assume the specified monitor PPIs are just wrong and will use 96 PPI. Plus with the way modern multi-monitor usage works with X11 by faking one giant single screen that doesn't work anymore. But when it works, it works.

But even with that it's STILL possible with the right setup using xrandr where you essentially render at a higher res and then downscale. Ubuntu's X11 version of Gnome has had this out of the box since I think 20.04 and it works very well. IIRC upstream Gnome refused it because that's what Wayland is supposed to do...

> Even in its original release it supported different PPIs for different displays

Yes and no.

X11 screens could have different resolutions, color modes and pixel density, but windows could not span over multiple screens, or moved from one screen to another. The only way the user/the application could move window to a different screen would be to open a new connection to the screen (denoted by that familiar DISPLAY:0.x environment variable) and recreate all the resources there.

There was exactly one application that was capable of doing that at runtime (XEmacs). For all the others it meant restarting the application with a new DISPLAY env var.

Hence Xinerama. It joined all the different physical displays into a single screen, which allowed to move windows around, but came with limitations, like the same color modes or DPI for all displays -- since it was single screen logically.

> But even with that it's STILL possible with the right setup using xrandr where you essentially render at a higher res and then downscale.

You actually don't even have to do this for updated programs - hidpi aware applications scale themselves, vector graphics style, so there's no up then down scaling going on. And applications can easily read the xrandr config and adjust their factor when moved to a different monitor. However, xrandr's ppi factor is not the scale factor you likely want, so this isn't really standardized; each toolkit might do it a bit differently. But all the pieces are there.

Non-aware applications might be bitmap scaled if needed though. (Of course, wayland just breaks all legacy applications anyway so that sets the compatibility bar low regardless)

> YMMV. When it reaches the level of X11 that "just works for everyone without preconditions" it will become usable in my coordinate system

I don't think X11 ever "just worked" for me. Every computer I installed Linux on had X11 problems.

The XKCD about Xorg.conf was very relatable back then: https://xkcd.com/963/

More like the aptly named "Duke Nukem Forever" of the desktop.

https://en.wikipedia.org/wiki/Development_of_Duke_Nukem_Fore...

More like the R6RS of desktops.

Really? I thought that one of the complaints about R6RS was that it was too broad and overspecified, while Wayland is too small so every other compositor is reinventing half of X11 by itself. I'd say it's more like R7RS (hash tables? No. Procedural records? No. Enumerations? Nope).

EDIT: This comment may age poorly when R7RS Large is complete.

One of my problems with R6RS was it was a profound shift in philosophy. The consensus criterion was changed from unanimous to simple majority, for instance, and there was much more emphasis on building a practical software engineering language rather than a language core intended to be built upon.

But it kind of failed at that because its standard library had only a small fraction of the features that "practical languages" like Python or Java had! ("> 1 line to send an email -- NON-STARTER!") So it was kind of a fuck you to the existing Scheme user base, in favor of new users that had yet to materialize, and yet it didn't deliver what those new users wanted! (R7RS Small was kind of a return to form for Scheme. I really appreciate the Small vs. Large profiles, akin to C's freestanding vs. hosted implementation profiles.)

And Wayland is kinda the same. "Fuck everything about X11" is as significant a rationale for Wayland as any, but there's a lot of things X11 users need that it didn't do very well until fairly recently. But literally everyone with the know-how to work on X11 backs Wayland instead... so unlike the R6RS situation it's kind of a fait accompli. Enough Scheme implementers were assmad about R6RS that there had to be a compromise.

X11 is actually not really difficult to maintain. There is just no corporate funding anymore. Wayland is designed to be used in car entertainment systems. At least this is where most of the funding is coming from. As such it is completely unsuitable for any desktop use and has had zero community mind share in that space for a very long time.

Reply on news.ycombinator.com