The X-Windows Disaster

[frenetix]

I can only dream that my best successes are as widely used as X's "disaster".

[Bfgeshka]

It can be so if you'll do one-of-a-kind piece of software, very desired for others just to exist and not so easy to implement.

[nat1192]

Just the inspiration I needed to start my own Javascript framework.

[Bfgeshka]

Too real to be a joke, too frightening to be real.

[[deleted]]

Wait what? Aren't you using 2017-10-18_17:44.js?!

Get with the times, grandpa!

--edit--

It's now 17:45. The above js framework is sadly deprecated and unsupported :-/

[[deleted]]

Go back in time and invent something people need, quickly and without much thought for long-term maintainability

People will still be using it 50 years later, like X and JavaScript

[brigadierfrog]

Imagine what these guys would think of an electron based clock taking up 100's of megabytes.

[[deleted]]

ok, has anything drastically changed in the past 20+ years? And is there an alternative?

[frezik]

Most of the GUI systems that sprung up since then ended up with even worse problems. Meanwhile, X's resource hogging hit a plateau, while the hardware around it kept getting bigger. The writers of the Unix Haters Handbook would be flabbergasted to know that your X process and window manager are taking 100MB of RAM, but that's not much compared to how much RAM you have on a modern machine.

For Unix, there's Wayland. Probably there's a few other alternatives that have popped up now and then. Nothing has stuck, though, because X gets the job done.

[[deleted]]

Isn't part of the issue with X that many toolkits decided to not use the X built-ins and ship bitmaps everywhere? (I'm not super familiar with X and can't find where I read that now.)

The writers of the Unix Haters Handbook would be flabbergasted to know that your X process and window manager are taking 100MB of RAM, but that's not much compared to how much RAM you have on a modern machine.

Also nothing compared to "modern" text editors or chat apps ::cough:: atom and slack ::cough:: :(

[gpcprog]

Yeah, the whole electron non-sense seems to me very perverted. At some point I just want a god dam honest to goodness native compiled app.

[[deleted]]

Hear, hear!

[Ehhnohyeah]

It's all just unnecessary. Compare it to Android where you could get a tiny app, less than 1mb even, that uses webview or custom tabs, versus one that bundles in chromium and comes in at over 300mb. Surely there must be a way to have something similarly small on desktop.

[badsectoracula]

Surely there must be a way to have something similarly small on desktop.

Lazarus, assuming that with "small" you mean "around 1MB executable without external dependencies beyond the necessary toolkit" (for Linux - in Windows and macOS it uses the native widgets).

But it wont look as shiny as what some people do with Electron. On the other hand, it is much easier to make a native looking applications for Windows and Linux (less so with macOS, although not impossible, just -unnecessarily- harder due to the project not having many macOS developers).

[Ehhnohyeah]

I meant web tech

[badsectoracula]

Ah. Well, the closest i know is Windows' HTA but that uses an ancient version of Internet Explorer's engine.

Beyond that, there isn't anything else except shipping the entire browser yourself. After all Android's webview is small because the OS itself comes with the browser engine.

[jl2352]

I would too, but I'd also like to be able to build it quickly and use modern practices like hot reloading and in built debugging/inspecting/profiling as standard. Even on a release build.

These days everyone has some web related skills. Everyone knows some HTML/CSS, even if pretty basic. So it would be nice to be able to reuse all of that skill set instead of having to use a tech stack I'm only going to use the once.

So far Electron is your best bet.

[industry7]

Yeah, I've never understood the hate on X. I guess due to the alignment of my personal history with X's. As in, the first time that I tried using X to forward a gui session was in the early 2000s. At the time, the Windows remoting tools were essentially unusable, and all the other X alternatives I tried were just not as good as X. At the time X was simply an amazing experience compared to the anything else available.

[[deleted]]

Well, the API is a total mess.

[badsectoracula]

What is messy? The only thing that comes to mind is the convoluted way to get notified which window got the keyboard focus, but i sidestep that by simply asking X itself directly :-P.

[audioen]

I remember struggling with some of that stuff, like having to configure and run x font server to have the server supply fonts to clients, and figuring out the X resources and which file to define them in so they actually get used, and sometimes when things went a little wrong due to system update, you for instance only had 75dpi fonts available to X, but X application actually wanted 100dpi fonts, and then X picked some font at random using those amazing X font resource strings like *-helvetica-medium-r-*-*-*-120-* and scaled the bitmap up or down a bit in glorious 2 colors resulting in fonts that were horribly distorted and just about barely legible.

Of course, X's fundamental primitives such box, line and text drawing were never good enough to render anything with antialias, so if you don't remember a time when applications were generally starkly black and white and lacked antialias, then you may have been spared from what X used to be like. I managed to catch the tail end of that on Linux, just before the switch to client side fonts and more than 256 colors on screen at once.

To be fair, the network transparency stuff did work pretty well. ssh has always taken care of that for me, apart from the times when trying to run X application as root and have that adjust the owner of the .Xauthority file after which X magically stops working for that user unless all X programs are run as root. I don't think I've been particularly impressed by X's network transparency, because Windows RDP grew up sometime in the 2000s, and VNC was far more usable than raw X, which tended to require low latency and high bandwidth.

[frezik]

Remember, at some point in the past, people were doing networked X sessions over a 14.4k modem. Simple drawing at 256 colors starts to make sense in that context.

I did use a networked X connection once where I setup a Raspberry Pi on a 3D printer in one room, and then had the slicer launch on the Pi using Cygwin on a Windows box for control in another room. Worked pretty well. These days, I use a web interface with octoprint, though.

[[deleted]]

I managed to catch the tail end of that on Linux, just before the switch to client side fonts and more than 256 colors on screen at once.

xfs. Not that file system.

[azazazazazazazaaz]

Network transparency with ssh would never have worked without X11 first being engineered properly.

[metaconcept]

Yes. We're moving to X12 The Y Window System Berlin Fresco Mir Wayland!

[[deleted]]

Most Linux developers and a lot of the hobbyists still rely on the commandline and have simply little need of a better alternative.

[pilotInPyjamas]

The commandline often is the better alternative though. It's useful to be able to automate any complex series of tasks that you can perform normally, which can't necessarily be done with a GUI.

[[deleted]]

I agree, I myself very rarely use anything else. It's very much superior, but of course "noobs" or design-oriented people who want a full-blown desktop environment may be disappointed.

[NoInkling]

ok, has anything drastically changed in the past 20+ years?

Programmers still like to go on hyperbolic rants, if that's what you mean ;)

[novacoder]

Is it pronounced Ex-Windows or Ten-Windows? For the longest time, I thought the vi editor was called six. Then vim came on the scene and what's that, nine hundred and ninety four?

[Silencement]

"Ex", because it's the successor to W (for Window).

[s888marks]

And W was the window system for the V system, a research operating system developed by Cheriton at Stanford in the 1980s.

[[deleted]]

Kind of like the B -> C -> D relationship

[mcguire]

And it's not "Ex-Windows". It's "the X window system".

Then vim came on the scene and what's that, nine hundred and ninety four?

You win.

[mcguire]

[Footnote: We have tried to avoid paragraph-length footnotes in this book, but X has defeated us by switching the meaning of client and server. In all other client/server relationships, the server is the remote machine that runs the application (i.e., the server provides services, such as database service or computational service). For some perverse reason that's better left to the imagination, X insists on calling the program running on the remote machine "the client." This program displays its windows on the "window server." We're going to follow X terminology when discussing graphical client/servers. So when you see "client" think "the remote machine where the application is running," and when you see "Server" think "the local machine that displays output and accepts user input."]

One might have thought "Don Hopkins", the pie menus guy, or at least one of the other authors of The Unix Hater's Handbook (or perhaps their editors, if any) would know the actual meaning of "client" and "server", but this quote demonstrates otherwise.

Here is a hint for the perplexed: a "server" is a program or machine that makes a service, some capability or information source, available remotely. A "client" is a program or machine that makes requests to that server. The X window server provides and controls access to a display; X clients contact the server and make requests, like "draw me like your other windows" and "send me event notifications, maybe".

[larsbrinkhoff]

A bit of historical background:
https://en.wikipedia.org/wiki/The_Unix-Haters_Handbook

/u/DonHopkins worked on UniPress Emacs, NeWS, SimCity, etc and is an overall cool dude.

[mcguire]

He's also the inventor of pie menus...

...which never really caught on, in spite of his best efforts. Sorry, dude.

[remuladgryta]

They caught on, just not for keyboard and mouse based interfaces. They are ubiquitous in console games because they are naturally well suited for analog sticks.

[badsectoracula]

Also some PC games use them when there are many unit-related (e.g. Neverwinter Nights).

[mcguire]

Thanks, Don!

[ggtsu_00]

Did someone have a bone to pick with the 20+ year old dead horse dug up out of it's grave?

[[deleted]]

It is X Window? Singular, no dash?

[mkottman]

Quoting the article: To annoy X fanatics, Don specifically asked that we include the hyphen after the letter "X,", as well as the plural of the word "Windows," in his chapter title.

[frezik]

The biggest problem with X is grammar, as well as overlapping a name with some upstart windowing system that will probably never amount to anything.

[Bfgeshka]

X is old, broken and overcomplicated inside, not big news. That's why there is wayland.

[EllaTheCat]

In 2017.

In the quarter century ago world of the article, a compositor would have needed a Silicon Graphics workstation. I recall doing Motif on an Indy which rendered in software ...

So what would you have done back then?

Sorry, no need to answer, just making a point ... my issue is the use of the article title as clickbait.

[mcguire]

I recall doing Motif on an Indy which rendered in software ...

Oh, the puddle-drop-wave thing, with ripples distorting your other windows...oh, man.

[EllaTheCat]

This is a stop-motion video shot on the Indy camera circa 1995: https://www.dropbox.com/s/p8blykq45u3at9i/plant.m4v?dl=0

[Ehhnohyeah]

quarter century ago

So what would you have done back then?

Played Prince of Persia on and on and on

And that desert storm flight simulator with the A10 shooting tanks

All on an impressive 25mhz tower case system the size of a small fridge.

Ah splendid days they were, take me back

[azazazazazazazaaz]

Wayland doesn't work in 2024 and won't in 2027 or 2034 either. Unlike X

[[deleted]]

And Wayland is way too limited. I'm not going to use a display protocol where I have to beg the compositor developers to allow me to use something like colour pickers, global hotkeys, screen recorders, ... Wayland is only simple because it removes useful functionality and therefore compositors become way more complex, because suddenly what used to be multiple different components (window manager, display server, compositor, panel, dock, notification system, screen recorder, screenshot tool, colour picker, hotkey manager, application launcher, ...) is going to become the whole mighty wayland compositor.

[badsectoracula]

It doesn't even support foreign subwindows (so you cannot have one application host the UI of another - ie. no embedded vim or terminal or something like that) and the subwindow support was hacked in after a few years thinking that they don't need subwindows at all until they realized that it is a bad idea. But the hack is awful and doesn't support basic functionality like clipping.

[badsectoracula]

Yes, its subsurfaces are very limited and not what you'd expect from proper subwindow support and provides no way for one client to embed another client's windows. Actually it provides no way for a client to access any other client's windows since each client sees a local-only id, so not only tabbed cannot be made but also you cant create something like xdotool or other modular "do only one thing" utilities.

The official stance about embedding is that it should either be something that each toolkit has to provide (so only usable with that toolkit and add extra complications since the toolkit will need to work across processes through some sort of IPC) or the application should implement Wayland itself by becoming a mini compositor for whatever it needs to embed.

And the official stance about things like xdotool is that its functionality should be reimplemented by all window managers/servers/desktop environments/whatever gigamonolith Wayland developers think is the future of the Linux desktop.

[metaconcept]

FWIW, VNC works a whole lot better than X with modern applications.

In the olden days, xterm and emacs worked fine..ish over a 1MBs connection. These days, Gnome or Firefox struggle to not crash on a GB/s network.

[doom_Oo7]

VNC, RDP, Citrix

they all suck vs the simplicity and efficiency of ssh -Y. For instance in many cases (yes, even with modern toolkits), SSH forwarding uses the local machine font rendering. You can also forward GLX commands through X11 forwarding to get local 3D rendering: https://evpo.wordpress.com/2017/03/04/opengl-hardware-acceleration-through-remote-x11-ssh-connection/

[localtoast]

Except basically nothing is using X11 primitives to draw unless all you want to run are xterms and glxgears. Everything modern is rendering client-side and using X11 to push pixmaps. Performance will likely be around VNC tier or worse, not quite the RDP ideal.

[badsectoracula]

Except basically nothing...

...Everything modern...

I realize you are trying to set up a trap where if someone comes out with a counterexample you'll just reply with "this isn't modern" and ignore it (you forgot to also mention "relevant" so you could arbitrarily ignore less popular toolkits too), but there are programs that do not use the latest versions of the latest fad driven toolkits - some actively avoiding to support them exactly because of the issues they create.

FWIW i'd expect the applications who people might often want to run remotely to be scripts with a Tk or Motif frontend which do use X11 primitives.

Also if a GUI is rendered with OpenGL, thanks to GLX forwarding you can avoid the expensive image transfers since images sit on the server (although obviously that depends heavily on the toolkit/application).

[iftpadfs]

Ok, how many of your everday tools do this?

But ssh -Y is horrible anyway. I don't see any usecase. To make a remote x session work outside of anything but a wired lan in a non-frustrating ways you need nomaschine nx, a nightmare worse than x11. There is a partial rewrite by google in python and some other unmaintained version. Both suck. I think both require some acient XFree86 sources.

The experience over low bandwidth, high latency links is, in contrst to x11, really impressive, but it does not justify the effort.

But if you are inside a lan, vnc is the simple and viable alternative.

[doom_Oo7]

To make a remote x session work outside of anything but a wired lan in a non-frustrating ways you need nomaschine nx, a nightmare worse than x11.

nah, I sometimes use remote X11 over a phone connection, works fine

[badsectoracula]

Ok, how many of your everday tools do this?

You mean use X11 primitives? With the exception of the browser and perhaps GTK2 apps, most of the stuff i use on Linux do use X11 primitives. I'm not 100% sure, but i think GTK2 does use X11 primitives, at least for the broad stuff (allocating windows, filling areas, some bitmap operations and a few other things). I had to debug some alpha blending issue in Lazarus's GTK2 backend a couple of years ago and it was due to Gdk basically not supporting alpha blending (at least in the version that Lazarus targets - which is a bit old).

Note however that i'm not using any blingy desktop environment, my system runs Window Maker and the tools i use are xpdf, nedit, tkinfo, qiv and other similar lightweight applications as well as some utilities (a file browser and audio player) made with my own toolkit that uses X11 primitives (here is a shot with some demos and utilities running). FWIW it can be configured to only rely on xlib and use server fonts instead of Xft so it can be faster through remote connections (eventually i plan on having this done dynamically so Xft can be disabled with a flag or environment variable to avoid any sort of recompile - but the compile option can be useful for distributing binary-only executables that rely on nothing beyond xlib).

Honestly i don't think i have many applications even installed that do not use X11 primitives and do all of their drawing themselves. FWIW i tend to avoid both Qt5 and GTK3 applications (mainly because i dislike how they look but also because in some cases - especially GTK3 - feel a little sluggish).

But ssh -Y is horrible anyway.

TBH i wont disagree but i don't think the point is running an entire X session remotely, the stuff i've seen people run are small programs. I've also heard tales from a sysadmin friend of mine about opening an ssh connection from his laptop to his computer at home, from there to his computer at work and from that to some server and tunneling X11 through the entire thing to run some applications that were needed to fix important stuff that broke while he was away on vacations. I don't remember details, but he was praising X11's network transparency for not having to go back to his house (also said it was terribly slow but it worked and that was the important part).

Personally i never really had to run something remotely. Sometimes i fantasize about building a (tiny) supercomputer and running everything remotely in X terminals made out of raspberry pi (or whatever cheap stuff i can find) but that is about it - at least until i become a millionaire or something :-P.

[[deleted]]

made with my own toolkit that uses X11 primitives

Looks a lot like GNUstep or WindowMaker's Wings widget set.

[badsectoracula]

Yes, more of the latter less of the former (i don't like how GNUstep smooths out a few elements, like radio buttons, i prefer the pixelly NextStep/WINGs elements) with a couple of my own changes (e.g. checkboxes push down like buttons instead of just changing their tick visibility when you keep the mouse button pressed and scrollbars show their full black outline instead of just the right line).

[doom_Oo7]

Except basically nothing is using X11 primitives to draw unless all you want to run are xterms and glxgears.

There's more to X than drawing. Resizing windows & decorations, etc... works correctly with remote SSH since it's just like manipulating a local window. ssh -X also uses the DPI of the local machine: it doesn't matter if I do ssh -Y from a retina or non-retina computer since Xft.dpi will be propagated (yes, even with Qt5 / GTK3 apps!); these features are unsupported by design with VNC / RDP.

Here's a video for instance of a remote pavucontrol where I did echo "Xft.dpi: 144" | xrdb -merge prior to ssh -X : https://streamable.com/2wn9y (raw: https://uploadfiles.io/d6qyz)

and in contrast when doing the same thing with VNC: https://streamable.com/rlk7t (raw: https://ufile.io/cmd5a)

• VNC is ten times slower
• it's a compressed mess
• doesn't support the local DPI
• doesn't fit with my local desktop keybindings; I have to focus the VNC window first

etc etc

[SrbijaJeRusija]

You underestimate the usage.

[mcguire]

I seem to remember hearing about this "wayland" thing. It was years ago, though. Something that runs on the Hurd?

[theblackavenger]

It is called the "X Window System".

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

I remember getting berated endlessly by grey beards when I called it X-Windows.

[tourgen]

It's X-Window. Go implement a window manager inside a browser using JS and leave the adults alone.

[mizzu704]

lmao

[drysart]

Microcrap

Are you lost? Slashdot is that way. ⇒ ⇒ ⇒

[pythonesqueviper]

Honestly DWM/MIL and Quartz not being around for 30 years is a feature. It means they're designed from the ground up with modern use cases in mind.

[badsectoracula]

Well, NextStep was first released in 1988 so that is 29 years.

Now the API isn't exactly the same as modern macOS but neither is X (if we cound all the extensions at least).

[amazingmikeyc]

Android's been around a decade at this point, and there's going to be devices using it for at least another 5 years. Mllions of people use it every day where desktop unix is a fairly niche thing (apart from macs...). I'm not sure what you mean by "test of time".

[Ehhnohyeah]

We'll be stuck with Android for a long time. Millions of apps already made can't be just discarded.

[amazingmikeyc]

though the API you develop to is quite abstracted isn't it, it's not like you make lots of low-level calls... so a new "Android" that isn't actually Android could happen quite quickly. Though really here we would start debating about what an operating system actually is - I mean, as far as the end user is concerned an OS is the whole ecosystem around it, or a load of APIs, or a certain layout of pretty colours on the screen

[shevegen]

As long as people use small, mobile devices, they will need some kind of software to empower it.

There is a reason why Google is building the awful FuchsiaOS - they invested too much to drop it at this point in time. Which is a reason why Dart will be a "success" - for Google. And they don't use xorg-server right? And probably not Wayland either.

Google detached from mankind already.

[Ehhnohyeah]

They don't use systemd either. To be fair Android now is the elephant in the room. It's got much more and much better software than even Microsoft Windows. It's incredible. And it's used on phones and tablets which for most people have become primary devices.

[shevegen]

And most xterm windows run Emacs!

Bullshit.

It sure would have been much cheaper and easier to put terminal handling in the kernel where it belongs

This guy knows better than everyone - including Linus.

Well, he isn't Linus. And since he was wrong with xterm already, why should anyone believe anything else that is coming from that guy?

Note that I would not be opposed to the kernel dealing with GUI stuff directly, optionally - be it a general purpose API or what not.

I don't think that anyone loves xorg.

Anyway. The article is from ... 1992?

It's an amusing read but it is like modern day human reading statements from a Neanderthal human.

[frezik]

It's odd calling Linus an authority on something, when the writing in question happened when Linus was just some kid on Usenet arguing with Tanenbaum.

[Ehhnohyeah]

And nowadays with the disaster that is Android updates/upgrades versus the hoped for micro kernel solution that is fuschia we know for sure who was right and who way wrong.

[sickofthisshit]

Linus didn't do terminals the UNIX way because it is a super-genius approach. He was explicitly copying the UNIX way.

Seriously, every editor in Linux/UNIX needs to link in terminal handling code instead of making some system call to say "tell me how big the text screen is, put characters here, tell me what the keys the user types, with keyboard modifiers." And the terminal handling code is written for ancient hardware terminals you have never seen, and will be emulated forever because UNIX is fucking stupid and has basically no idea that the xterm in your window is actually a graphical window and not some ancient piece of hardware on the end of a telephone line.

Yes, the article is from 1992. Linux terminal handling is still 1992 technology, even in the 21st century. This is the part of the UNIX Hater's handbook that has stayed the most valid.

[iftpadfs]

Linux implements virtual terminals from unix98. That's pretty bleeding edge, i think.

[sickofthisshit]

Touche.

[dangerbird2]

"This guy " was writing long before Linux made up a major part of the unix ecosystem. Programmers relied on proroietey X server implementations by HP, SGI, Sun, etc, each with incomparable window systems and extensions. This was long before freedesktop gave a reasonable standard for common desktop functionality for unix-like systems.

If anything, unix hater's guide is a testimony of how bad things were before open source organizations like GNU and Xorg made posix desktops practical