X was the solution to the problem MIT had, and as such, the problem X was trying to solve. It worked very, very well for what it was trying to solve.
How we ended up with billions of people able to interact with an app that we can all build at home seems insane...
Java. Java did this. On billions of devices! Everywhere from your smart card to the mainframe. Before Java, Dis! Before Dis, Forth! Good luck running a web browser plus your application on a smart card, or even (decently) on an underpowered netbook.
Sufficiently young people probably suspect these were called netbooks as some joke. They run Emacs just fine and without constantly swapping, but a web browser?
If not, they can’t even run JavaScript ads, because apparently ads like to refresh the screen with a static image at 60fps. Software rasterizers can’t keep up with that (even on 32 core, >200W TDP xeons, from what I’ve seen...)
The web really sucks at everything other than network effects.
Hardware acceleration makes things slower, not faster.
> Software rasterizers can’t keep up with that (even on 32 core, >200W TDP xeons, from what I’ve seen...)
You're nuts. Software rasterizers keep up with DOS games just fine, even on an old 386.
It's the fact that they're trying to use Javascript and other garbage-collected or object-oriented languages to code these rasterizers.
At least JS had the excuse of being designed and implemented by a single developer in three weeks. X Windows was part of Project Athena, a $50 million project from MIT, DEC, and IBM with a five-year schedule.
Here's a nice little article from 1989 telling just how great it was for the time:
The layers of abstraction are there because X is such a godawful piece of shit. Sure, your application will be fast if you only use XCB or Xlib (and XCB is just a modern replacement for Xlib, made because of how deeply flawed Xlib is, and it can’t even fully replace Xlib). But few people are willing to put in the blood, sweat, and code to write something that is pure X.
So if X worked great for what it was aiming to do, it was aiming to do the wrong thing.
Sure, if you're using it to connect to a box in Canada over a satellite connection in Johannesburg during 1995 with countless abstractions, you're going to have a horrible time. Use the right tool for the job.
The X-Windows Disaster
https://medium.com/@donhopkins/the-x-windows-disaster-128d39...
>X: The First Fully Modular Software Disaster
https://news.ycombinator.com/item?id=17056516
John Steinhart wrote XTool, a nice snappy reimplementation of X11 on top of SunView! ;)
https://web.archive.org/web/20171008204348/https://minnie.tu...
X and NeWS History
https://news.ycombinator.com/item?id=15325226
Jon Steinhart wrote:
>XTool was very small and fast compared to the X sample server because I wrote the server from scratch. I think that I'm the only person to write an X server outside of the X Consortium. One of the things that I learned by doing it was that the X Consortium folks were wrong when they said that the documentation was the standard, not the sample server. There were significant differences between the two.
>The only really worthwhile thing about X was the distributed extension registration mechanism. All of the input, graphics and other crap should be moved to extension #1. That way, it won't be mandatory in conforming implementations once that stuff was obsolete. As you probably know, that's where we are today; nobody uses that stuff but it's like the corner of an Intel chip that implements the original instruction set. As an aside, I upset many when working on OpenDoc for Apple and saying the same thing there.
>The atom/property mechanism allows clients to allocate memory in the server that can never be freed. Some way to free memory needs to be added.
>The bit encodings should be part of a separate language binding, not part of the functional description.
>Had he done some real design work and looked at what others were doing he might have realized that at its core, X was a distributed database system in which operations on some of the databases have visual side-effects. I forget the exact number, but X includes around 20 different databases: atoms, properties, contexts, selections, keymaps, etc. each with their own set of API calls. As a result, the X API is wide and shallow like the Mac, and full of interesting race conditions to boot. The whole thing could have been done with less than a dozen API calls.
Recommendation: People who like saying "X-Windows" also enjoy saying "Project Anathema".
Those others I think get it wrong with their "whole desktop" sharing. The experience of having X clients streamed as they are launched and the local WM gets to manage decorations - I like that model a lot more, for say the scenario where I ssh into a machine and launch a GUI program.
RDP is much faster than X. It had the benefit of being designed later I guess.
VNC usually feels laggier than X to me somehow. As if there is a cursor sync issue.
These are just my observations as a user.
How we ended up with billions of people able to interact with an app that we can all build at home seems insane...