18 ms·

The X-Windows Disaster (1994)

105 points by shp0ngle 7y ago

simonblack 7y ago
And yet, here we are, over a quarter-century later, and that "disaster" is still allowing our programs to run on one computer and display the result on another computer on the other side of the world. The 'Unix Hater's Handbook' is supposedly a humorous work. But it was mainly used in the 1990s by non-Unix companies as anti-Unix propaganda. Unfortunately for them, all of today's main computer/software companies either use Unix or Unix-like operating systems (Apple:BSD Unix, Google:Android, IBM and Others:Linux, Microsoft:WSL). https://en.wikipedia.org/wiki/The_Unix-Haters_Handbook https://en.wikipedia.org/wiki/The_Unix-Haters_Handbook
- ajross 7y ago
  To be fair: the UHH is a legitimately great book, a fun read, and absolutely something every modern developer should know. It's opinionated in exactly the right way, even if some of its conclusions turn out to have been wrong in hindsight. But as for X11: yeah. You can complain all you want at microdesign issues, but longevity beats all. I can run an unmodified X11R1 client from 1987 against the default install of pretty much any newly installed Linux/BSD box and it still works, something not true of literally any other contemporary GUI toolkit of the era.
  - ddingus 7y ago
    While I was learning UNIX, the UHH was given to me as a rite of passage. Great book. I learned a lot. Love UNIX.
- cowmix 7y ago
  As a someone who has used Unix for 35+ years, I feel the book is great. It actually does more to explain why things are the way they are in UNIX than any other book I've read, pro-Unix or not.. I don't agree with everything it covers and many of the complaints of the book have been addressed over the years, but it definitely still relevant today.
- uk_programmer 7y ago
  Generally I agree. However I would say with regards to iOS (not MacOS) and Android. While underneath they are both Linux and Darwin based respectively. Almost the entire OS anyone interacts (including most devs) is done through the Android and iOS APIs. They could replace what is underneath with something very different and you wouldn't be any of the wiser. There isn't really much to separate something like Ubuntu and MacOS in terms of what they are (other than polish). In Jaron Laniers book "You are not a gadget" he says the open source community are very good at making clones of existing things but not inventing new things themselves. I would argue that programmers in general are very good at making clones of existing things. This has allowed Unix-like operating be ubiquitous as they are easy to copy and are good enough.
- kick 7y ago
  It's not just a humorous work, it's also genuine criticism. dmr could find the humor in it, why can't you?
  - smhenderson 7y ago
    dmr’s forward is my favorite part though. As others have said a lot of the criticism in the book has been addressed over the years. I came late to the party so I missed out on a lot of the early bugs and mis-features of UNIX.
- gok 7y ago
  A lot of the criticisms have been addressed though. Basically no one outside of enthusiasts uses X any more; Android and Chrome OS use an entirely different graphics system. The filesystems have been replaced. Shells have been replaced and/or obviated for most users.
  - ddingus 7y ago
    Really, and this is an OK choice, but is a choice all the same: What happened is others settled on a subset of multi user graphical computing. That is not replacing X. It is something different, less. Maybe less is more too. I have an open mind. However that goes, X nailed multi user graphical computing. Pretty much any crazy thing you can think of can be done on X. Want to make a computer that several people use locally, each with their own screen, keyboard, mouse? X can do that, and permit those users to view and interact with any combination of each others display data. One says, hey can you sort this for me? Another says, "sure", and a window pops up on their screen... Now, replicate that same setup, each user has their own powerful computer, maybe with a common, shared display among them, like a wall display or something. No problem. X does that too, and chances are only the sysadmin differs. The apps will have no clue. It may be that we just do not work that way, or maybe not enough know how, but let's be clear here. X is not being replaced. A subset at best is being put forward. I think that means we just are not really doing multi user graphical computing. And that is OK.
    - tropo 7y ago
      X has never supported reliable screen locking. If the screen locker program crashes or is killed because the OS ran out of memory, the X server is unprotected. It's an unpleasant feeling to come back to an unlocked screen in a shared building.
    - battery_cowboy 7y ago
      Wow, can you tell me where I can find out about how to do those things, like: > Want to make a computer that several people use locally, each with their own screen, keyboard, mouse? X can do that, and permit those users to view and interact with any combination of each others display data. > One says, hey can you sort this for me? Another says, "sure", and a window pops up on their screen... Is there literature or something about setting up complex things like this in X? I'd be interested in learning more.
- mjcohen 7y ago
  I learned a LOT when I read the UHH in the 90s.
- ChuckMcM 7y ago
  One of the fun things about working at Sun back in the day was that there were folks trying to fix some of the issues that were legitimately raised by the UHH. That said, I shared Don's disgust with X. The difference between running X on a workstation and SunTools felt like a 300% slowdown. And yet today I sit here typing into a window that is being displayed by an X server running on a Windows OS on a computer that is acting pretty much like an X-terminal for my Linux server. It has warts, true, but its still flying as they would say on Firefly. I have often wondered what the world would be like if we had decided to move the GPU into the monitor and ran a parameterized display system over HDMI rather than something that looks like a cancerous NTSC composite video signal.
  - DonHopkins 7y ago
    >One of the fun things about working at Sun back in the day was that there were folks trying to fix some of the issues that were legitimately raised by the UHH. Like opening core files (which have gigantic gaps of unmapped zeros) by loading them into the XView text editor when you double click on them in the XView file manager? ;) That's actually how core dumps grow and reproduce and evolve, like those wasps that lay their eggs in other insects and turn them into zombies, by embedding themselves in an unwitting host process and making it core dump even bigger! https://www.wired.com/2014/10/absurd-creature-week-glyptapanteles-wasp-caterpillar-bodyguard/ https://www.wired.com/2014/10/absurd-creature-week-glyptapan... And while on the topic of XView: Do you have any good XBUGTOOL horror stories, Chuck? ;) The most foolish thing I ever did was try to use it to file a bug against itself. Boy do I regret that! http://www.art.net/~hopkins/Don/unix-haters/x-windows/xbugtool.html http://www.art.net/~hopkins/Don/unix-haters/x-windows/xbugto...
- pjmlp 7y ago
  That disaster is the major reason why UNIX FOSS clones will never get desktop or mobile computing devices beyond a single digit number. You can have all the fun you want with your beloved X, I rather use modern Windowing platforms and their composition engines. Also, UNIX underpinnings are completly irrelevant on Android, iOS and ChromeOS. In what concerns macOS and Windows, they are there to cater to the GNU/Linux crowd that buys Macs and Windows devices instead of buying GNU/Linux hardware.
- IshKebab 7y ago
  No it isn't. Almost nobody uses raw X over long distances because it is unusable. Everybody uses something else like VNC, RDP or NX. Note that NX actually moved away from the X protocol and is now just a VNC-like protocol, i.e. it only deals with pixels. Every modern remote desktop protocol works that way because it is better.
- catblast 7y ago
  > allowing our programs to run on one computer and display the result on another computer on the other side of the world. I feel sorry for anyone having to use X over a link of that latency. Especially if their internet service has a tendency to go down. How many X clients handle loss of connection better than just terminating? And are there really that many people using X remote as compared to RDP or Citrix. I would be surprised to find out that remote X is widely used in 2020 (if you can even call it’s brief heyday in the 90s while commercial UNIX was losing its balls to Windows NT due to vendor incompetence).. and I would risk the age discrimination suits and fire the IT team. X was already an ugly obsolete piece of crap in the 90s when it was foisted upon us by all the major commercial Unix vendors. It should have rightfully died with SGI, Sun, and/or DEC.
- catblast 7y ago
  > But it was mainly used in the 1990s by non-Unix companies as anti-Unix propaganda. Some strange revisionism there as few of the authors of UHH were involved with Windows.. which is what ended up completely eating commercial Unix lunch... a win that was not so much due to Microsoft’s competence as their competitors stupidity. Meanwhile calling Mac OS X or Android Unix-like just because they have some tools in common (MAC OS X is only vaguely a BSD — and launchd seems to get some love by the same people that have a conniption fit over systems) .. none of those systems use X for sure. Desktop Linux is a rounding error.. the part of Linux that gets used heavily for servers that is the reason that WSL is a thing (to ease development)?? Yeah that has basically fuck all to do with the disasters in SySV/commercial Unix... not too many people using SySV IPC on Linux, and cgroups, epoll, io_uring hardly remind me of the miserable APIs of now ancient Unix.
jgon 7y ago
A disaster, and yet I remember reading about attempts to replace it when I was still in University, and now here I am over a decade into my career and Wayland still isn't ready for primetime, especially if you use a video card from the #1 producer of performance video cards on the planet. Small use case I guess. X lets you do forwarding over the network and maybe sometime in the 2020's Wayland will have some sort of remote desktop solution? Still waiting on that to be ironed out... Replacing X feels like the nuclear fusion project of the Linux world, constantly receeding into the future even as it maintains its promises of fixing all our problem When It's Done(tm).
- cycloptic 7y ago
  There are various solutions already available for remoting in Wayland. GNOME: https://wiki.gnome.org/Projects/Mutter/RemoteDesktop https://wiki.gnome.org/Projects/Mutter/RemoteDesktop KDE: https://userbase.kde.org/Krfb https://userbase.kde.org/Krfb Sway/wlroots: https://github.com/any1/wayvnc https://github.com/any1/wayvnc Generic: https://gitlab.freedesktop.org/mstoeckl/waypipe/ https://gitlab.freedesktop.org/mstoeckl/waypipe/ Web-Based: https://github.com/udevbe/greenfield https://github.com/udevbe/greenfield You can also still use your X11 programs remotely within Wayland, by using XWayland, which is supported by all the major implementations. Unrelated to Wayland, there is also backend support in GTK3/4 for rendering to a web socket: https://developer.gnome.org/gtk3/stable/gtk-broadway.html https://developer.gnome.org/gtk3/stable/gtk-broadway.html
  - ricktdotorg 7y ago
    from this page: > GNOME: https://wiki.gnome.org/Projects/Mutter/RemoteDesktop https://wiki.gnome.org/Projects/Mutter/RemoteDesktop "Currently only remote passwordless unencrypted VNC access to an existing session is supported." i guess that is technically a solution, but not a good one.
    - cycloptic 7y ago
      Yes, the quality of these varies, pick the one that is right for you. X11 forwarding is not without issues either. With VNC you'll probably also want to tunnel the connection over SSH to secure it rather than rely on server authentication anyway.
mshook 7y ago
It's X-Window (System), no S.
- warpech 7y ago
  It says it the footnotes that the misspelling is intentional
- s_gourichon 7y ago
  The text of the article actually has it correct most of the time. The name is just "X". It's a windowing system that happens to be named "X". It's named this way because it is a successor to another windowing system named "W" and "X" comes after "W" in alphabet order. https://en.wikipedia.org/wiki/X_Window_System#Predecessors https://en.wikipedia.org/wiki/X_Window_System#Predecessors
  - ptx 7y ago
    Exactly. Many people seem to read it as "the system named X Window", but, as you say, it's actually "the window system named X". The Linux Operating System is an operating system and the X Window System is a window system. Maybe part of the reason is the Title Case convention in English? (And the other part may be the name of Microsoft's window system leading the mind along this path.)
    - sicnus 7y ago
      Oh, I wanna hop in on this train. tell that fool to man X yo. ;) I've been getting pissed about people calling it "X Windows" since 1995 so there.
      - DonHopkins 7y ago
        You made my day! I'm so delighted to hear you're pissed that people call it X-Windows. ;) Thank you for letting me know my long term project of always calling it X-Windows worked perfectly as planned. I've been systematically calling it X-Windows to piss people off since June 1988, when I read the article "Things That Happen When You Say ‘X Windows’" in my copy of Volume 1 Number 2 of the June 1988 of the “XNextEvent” newsletter, “The Official Newsletter of XUG, the X User’s Group” (which I quoted above): https://news.ycombinator.com/item?id=22501380 https://news.ycombinator.com/item?id=22501380 From the end of the X-Windows Disaster article: >Don wrote the chapter on the X-Windows Disaster. (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. I started programming X10 in June 1986. Here's my first X10 program, a pie menu test application (I was calling them "theta menus" then): https://donhopkins.com/home/archive/piemenu/theta.test/ https://donhopkins.com/home/archive/piemenu/theta.test/ After that I modified the X10 "uwm" window manager to support pie menus, and integrated it with FORTH so I could interactivally program and extend the window manager in FORTH, and use it to implement and perform an experiment comparing pie menus with linear menus. https://medium.com/@donhopkins/an-empirical-comparison-of-pie-vs-linear-menus-466c6fdbba4b https://medium.com/@donhopkins/an-empirical-comparison-of-pi... Forth pie menu X10 window manager source code (the main FORTH part -- other C and FORTH source code is in the same directory): https://donhopkins.com/home/archive/piemenu/uwm/fuwm-main.f https://donhopkins.com/home/archive/piemenu/uwm/fuwm-main.f X10 Pie Menu Window Manager: https://www.youtube.com/watch?v=IJhvB6kwmog https://www.youtube.com/watch?v=IJhvB6kwmog Then I moved on from X10 to NeWS (and from FORTH to PostScript), because NeWS was so much better than X10 or X11, and supported round windows and non-terrible graphics. At Sun in 1991 I helped write an X-Windows ICCCM X11 window manager in PostScript so NeWS could manage X-Windows, which supported non-rectangular tabbed window frames, pie menus in round windows, multiple displays, multiple rooms, scrolling virtual desktops (with an iconic map that let you scroll your view around), and many other nice features that other X window managers couldn't do at the time. Plus it was faster and more efficient than any X window manager because it actually ran in the window server instead of running in a separate process and communicating over the network, so it was able to immediately synchronously handle events, provide feedback, draw rubber-band lines in the overlay, pop up and track menus immediately, perfectly support quick mouse-ahead gestures, move and resize windows instantly, all without context switching or network traffic or grabbing the server or freezing event distribution or lagging behind or missing any events, instead of being asynchronous and laggy and flakey and dropping events like all other outboard networked X11 window managers do by design. (This was extremely important when running on a slow diskless Sun 3/50 paging over the network.) The idea of running something as crucial and interactive as the window manager in a separate process using an asynchronous protocol is quite insane, inefficient, wasteful, and flakey, but that's how X was designed to be. https://donhopkins.com/home/archive/NeWS/owm.ps.txt https://donhopkins.com/home/archive/NeWS/owm.ps.txt Demo of the Pie Menu Tab Window Manager for The NeWS Toolkit 2.0: https://www.youtube.com/watch?v=tMcmQk-q0k4 https://www.youtube.com/watch?v=tMcmQk-q0k4 In 1992 I made a pie menu window manager called "piewm" based on "tvtwm", and I also ported SimCity to X11, using TCL/Tk, redesigning it to be a multi player networked game, and encountering and solving all kinds of problems trying to make X11 play a game, support multiple users, do fast shared memory graphical animation, mix sounds with a network audio mixer, and support different types of screens and devices (both black and white and color). Those experiences were what motivated me to write the Unix-Haters Handbook chapter on the X-Windows Disaster, and compare my experiences with NeWS and X-Windows. http://www.art.net/~hopkins/Don/piemenus/index.html http://www.art.net/~hopkins/Don/piemenus/index.html >The "piewm" X11 window manager with pie menus. When I was a research programmer at CMU, faced with using X11, I realized that I needed pie menus to help me move my windows around, so I went shopping around for a reasonable window manager, and since there weren't any, I choose the least unreasonable one at the time, "tvtwm", and hacked it up with an updated version of the old X10 "uwm" pie menus, and called it "piewm". The source code is available here: piewm.tar.Z. http://www.art.net/~hopkins/Don/piemenus/piewm.tar.Z http://www.art.net/~hopkins/Don/piemenus/piewm.tar.Z >The TCL/Tk pie menu widget. I accidentally ported the HyperLook version of SimCity to X11, making it multi player in the process, using the TCL/Tk toolkit, which was the only X11 toolkit that didn't suck. I needed some fancy looking graphical pie menus, so I made a TCL/Tk pie menu widget, whose window shape could be shrink-wrapped around iconic labels. The source code is available here: tkpie.tar.gz. I recorded an X11 SimCity demo, showing pie menus in action. SimCity for X11 won a "best product of 1992" award from Unix World! http://www.art.net/~hopkins/Don/piemenus/tkpie.tar.gz http://www.art.net/~hopkins/Don/piemenus/tkpie.tar.gz More stuff about X11 window management and multi player SimCityNet: http://www.art.net/~hopkins/Don/unix-haters/x-windows/i39l.html http://www.art.net/~hopkins/Don/unix-haters/x-windows/i39l.h... http://www.art.net/~hopkins/Don/simcity/simcity-announcement.html http://www.art.net/~hopkins/Don/simcity/simcity-announcement... http://www.art.net/~hopkins/Don/simcity/simcitynet.html http://www.art.net/~hopkins/Don/simcity/simcitynet.html X11 SimCity Demo: https://www.youtube.com/watch?v=Jvi98wVUmQA https://www.youtube.com/watch?v=Jvi98wVUmQA Multi Player SimCityNet for X11 on Linux (you can see the date changing so fast it blurs at 1:25): https://www.youtube.com/watch?v=_fVl4dGwUrA https://www.youtube.com/watch?v=_fVl4dGwUrA Here's how fun it is trying to draw the SimCity map efficiently with X-Windows: if only a few pixels have changed (which is a very common case), instead of sending the entire image, it sorted the changed pixels by color, then used XDrawPoints to draw each batch of different colored pixels that changed. Changing colors is expensive, so if you changed colors for every dot it would be very slow, but X-Windows lets you draw a bunch of dots at any position in the same color efficiently, so SimCity finds the pixels that changed, and if there are few enough of them, it sorts them by color, then goes through setting each color and drawing every pixel that changed to that color with XDrawPoints. If more than max_pix (256) changed, it just sends the whole image. Yes, that was the most efficient way to do it if the server didn't support shared memory or was across the network on a different host, since the X protocol and graphics API is so awkward and inefficient. And even if you have the shared memory extension in your server, X still requires that you ALSO write code to support the case of no shared memory, since it still needs to be able to run over the network. Decades later when I updated the code to support different bit depths than an 8 bit color palette, computers and networks were astronomically faster, and the code was too tricky for its own good, and SimCity on the OLPC was usually running locally with shared memory anyway, so I punted, commented out that code, and just sent the image every time. https://github.com/SimHacker/micropolis/blob/b0c5a3f495ebabbc51d5e45dac948d8e40fc53ee/micropolis-activity/src/sim/w_map.c#L466 https://github.com/SimHacker/micropolis/blob/b0c5a3f495ebabb... /* * Sending the whole image is 108108 bytes. * Sending points is 4.4 bytes per point. * One image is as big as 24570 points. * But we have to sort these dang things. */ #define MAX_PIX 256 int max_pix = MAX_PIX; [...] /* TODO: Fix this. I disabled this incremental drawing code for now since it seems to be buggy. */ /* Sort the changed pixels by their color */ qsort(pix, different, sizeof (struct Pix), (int (*)())CompareColor); /* Draw the points of each color that have changed */ points = (XPoint *)malloc(sizeof (XPoint) * different); last = 0; pts = 0; for (i = 0; i <= different; i++) { if ((i == different) || (pix[i].color != pix[last].color)) { XSetForeground(view->x->dpy, view->x->gc, pix[last].color); XDrawPoints(view->x->dpy, view->pixmap, view->x->gc, points, pts, CoordModeOrigin); if (i == different) break; pts = 0; last = i; } points[pts].x = pix[i].x; points[pts].y = pix[i].y; pts++; } free(points); The map editor "DrawOverlay" code also has a lot of fun hairy optimizations to draw fast over the network, and it measure how long it takes in different situation and uses the most efficient technique (drawing the lines every time, or caching them in an offscreen pixmap overlay): https://github.com/SimHacker/micropolis/blob/b0c5a3f495ebabbc51d5e45dac948d8e40fc53ee/micropolis-activity/src/sim/w_editor.c#L1426 https://github.com/SimHacker/micropolis/blob/b0c5a3f495ebabb... When I was timing and optimizing SimCity to make it run as fast as possible on X-Windows, I noticed that when you ran it super-duper flat-out fast, skipping screen updates to run the simulator in a tight loop, a huge amount of time was wasted simply redrawing the date field, since it changed so many times per screen refresh. So I implemented a special custom TCL/Tk widget just for displaying the date, which only lazily updates occasionally at a fixed frequency, and knows how to draw the text in an offscreen pixmap and "fake blur" the parts of the date that are changing quickly by overprinting the letters and digits in gray (you can't easily blur or blend text in X-Windows with an 8 bit color mapped display, so I did the next best thing that was possible and efficient, and it got the point across that time was moving very fast, without slowing the computer down or making it unresponsive). https://github.com/SimHacker/micropolis/blob/b0c5a3f495ebabbc51d5e45dac948d8e40fc53ee/micropolis-activity/src/sim/w_date.c#L597 https://github.com/SimHacker/micropolis/blob/b0c5a3f495ebabb... More about NeWS in this recent discussion: https://news.ycombinator.com/item?id=22455722 https://news.ycombinator.com/item?id=22455722
gok 7y ago
> like Sun's Open Look clock tool, which gobbles up 1.4 megabytes of real memory Meanwhile the clock app on my phone is currently using 12 MB. A popular time telling website uses over 100MB on my laptop.
- tinus_hn 7y ago
  Is it http://whattimeisitrightnow.com/ http://whattimeisitrightnow.com/
  - gok 7y ago
    That was what I looked at yeah, and I appreciate that it's actually a Netflix gag site for Bojack Horseman but still.
- donio 7y ago
  It's like the Eight Megabytes And Constantly Swapping joke for Emacs. These days a minimal Emacs is more like 18MB RSS rather than 8 but that's still tiny compared to modern apps.
- speedgoose 7y ago
  I don't know about your phone but mine which is not new has 6gb of ram and the latest Samsung s20 flagship has 12gb of ram. In comparison to the total ram, it's much better nowadays.
- 0xff00ffee 7y ago
  I bet 99% of that 12MB is graphical assets: different sized icons for different display geometries. I always found asset management for multiple platforms to be most annoying when developing for mobile. This reminds me of when people started to realize Microsoft Foundation Class (MFC) was blowing up and were bemoaning code-bloat. In 1997.
  - hermitdev 7y ago
    The very mention of MFC gave me shivers down my spine. The macro horror show and indecipherable error messages... Thankfully, I never had to do much MFC professionally, but holy shit, if you inadvertently messed with one of the generated macros, good luck. I remember it sometimes being easier to throw away everything and start from scratch than debug the horrible compiler errors.
commandlinefan 7y ago
When I first saw X, I had already grown up with PCs, so the whole concept of running the “main program” on another computer just to display it on my computer seemed so illogical I thought I must just be misunderstanding it. I mean.. I have a computer right here, why not run the program on this computer…? However, if you think about it - the X philosophy was actually mostly correct (or at least more useful than it initially seemed), they just did it in a clunky way. We’ve been slowly migrating to web applications which are the same basic concept: the program runs on the web server and your browser displays the results. This actually is better from a security standpoint (the server can access data that isn’t distributed to the client) and a maintenance standpoint (I can deploy a new version to the server and it’s instantaneously available to all clients). Running a “program” remotely and displaying the results locally is so ubiquitous now that my teenage kids are confused by the entire concept of desktop applications. What I’d love to see, and wish I had the free time to implement, is a Linux UI based on something like SVGALib that doesn’t use X at all; just enough to run a terminal and a browser (and maybe an email client and a word processor if somebody wanted to write one).
- s_gourichon 7y ago
  The modern equivalent of SVGALib is Linux' Direct Rendering Infrastructure. If you just want fullscreen app, you can run them on top of DRI. For "a terminal and a browser" at the same time you have to create some sort of protocol for windowed display, and an implementation of one side of that protocol that provides window management, and apps would implement the other side. People did that. They named the protocole "Wayland", the window management implementation "Weston", and a number of graphical toolkits can target Wayland (GTK, QT, SDL...). Ref: https://wayland.freedesktop.org/faq.html#heading_toc_j_2 https://wayland.freedesktop.org/faq.html#heading_toc_j_2 As a sidenote, if you want to run such a program standalone, fullscreen, can you do that without running a "server" or a "window manager"? IIRC, programs intended for Wayland can run fullscreen on top of plain DRI (or perhaps only SDL provides this facility).
  - cycloptic 7y ago
    The simplest thing I know of is the minimal Cage compositor for wayland, that only supports running a single fullscreen program: https://github.com/Hjdskes/cage https://github.com/Hjdskes/cage With some hackery, you could probably build this as a backend for GTK/Qt that would run the server in the same process. But I don't know how useful that would really be.
ddingus 7y ago
X is kind of amazing. Once, just for fun, I had an SGI do window management, another one serve up fonts, a linux box serving apps via NFS, and yet another headless SGI running a shared app displayed on yet another Linux machines X window server session. It was surreal. Launch that app, and all those machines contributed to the interaction of it. Plus, it made that instance of RH Linux look like an SGI. 4dwm has a distinct look and feel. For the most part, running over a 100T network, one could not tell all that was happening. (Was a high end CAD app.) Later, I did run that same app remotely, using its Windows NT build and the Exceed X server for Win NT. Cool.
- kevin_thibedeau 7y ago
  I like being able to run a Linux desktop in a VM on windows and "extend" to another monitor with VM X apps rendering to a Cygwin Xorg instance. Wayland can't do that.
  - cycloptic 7y ago
    There is no reason wayland couldn't do that, other than that your compositor doesn't support the concept of virtual screens. I can't say that this is a very high-priority feature for any compositors at the moment.
    - ddingus 7y ago
      And that is why X is kind of amazing. They thought it all through. Today, it is a game of which pieces make the most sense, and whether multi user graphical computing should be a thing. We know it can. X did all that. Should it?
      - cycloptic 7y ago
        As far as Wayland goes, that is up to the developers and users of those compositors. The protocol itself supports the concept of multiple seats. I can't speak for all the original X developers but TFA seems to suggest that they didn't think it all through.
downerending 7y ago
At the time when X was first being developed, there simply were no open source alternatives. I used a few of the closed source ones and they were nice enough, but generally available on only a single platform (e.g., HP), which made them fairly useless. Even if Wayland succeeds, it'll be a long time before it has truly replaced X. In reality, I think it's more likely that both will be (or already have been) been run over by web apps.
- ahartmetz 7y ago
  That's like saying that CPUs will be run over by Linux.
- code_duck 7y ago
  The browser needs to be displayed somehow.
  - pjmlp 7y ago
    Yes, and as proven by ChromeOS, X is not a requirement.
    - code_duck 7y ago
      The comment I replied to said X and Wayland would be 'overrun by web apps' and I'm not sure what that means. ChromeOS is not a web app and neither is chrome.
      - pjmlp 7y ago
        They already have been, X accounts for single digit desktop market size. ChromeOS is a Web based OS with more market share than GNU/Linux, thus just by measuring its usage across US school system, it is higher than X. Then we can add all remaining desktop and mobile OSes into the mix. Finally, SaaS Web applications are in many cases the only way some applications ever reach FOSS UNIX clones.
        7y ago
andyjpb 7y ago
The UNIX Haters Handbook was funny at the time but doesn't make much sense these days unless you understand all the rival hacker groups and cultures that were largely eventually unified under "Free Software" and, later, "Open Source". Even the LISPers have come in from the cold! Much of this criticism of X was prescient for things to come. Autotools, dependency problems, modularity issues, compatibility, "DLL-hell", etc. Many of these problems don't have solutions today that are orders of magnitude better than then. On the other hand, one thing that's really holding X back, especially on handhelds, is 'Myth: X is "Device Independent"'. If the difference between a 75dpi screen and a 100dpi workstation screen was too much, today's "retina" displays really struggle to run a usable X. You're heavily reliant on the toolkits (Qt, GTK, etc) to scale things for you and they mostly understand about font scaling but not about widget scaling. Lots of distributions that might want to use it, for example Maemo Leste, Ubuntu Touch or Gemian, are having to do a lot of UI work and hand-pick applications for "porting" to the screens and input devices (touch) that they want to use them on. This means that Linux-on-the-smartphone is not yet in any position to give Android or iOS a run for it's money because it really struggles to effectively leverage its existing app ecosystem. Even ignoring security models, X struggles to provide even a compelling visual of a vision for handheld devices. Don't even mention Wayland: that has other economic incentives that are not yet properly aligned for widespread success (including X's app ecosystem ones).
- jcelerier 7y ago
  > If the difference between a 75dpi screen and a 100dpi workstation screen was too much, today's "retina" displays really struggle to run a usable X. I've been running X11 on retina displays since 2014 without much of an issue. The only big offenders were chrome and firefox. Nowadays everything just works.
  - fsh 7y ago
    It works if you have more or less the same pixel density across all screens. As soon as you mix very different ones, X becomes essentially unusable. Microsoft and Apple have solved that issue years ago.
ddingus 7y ago
Here is one advantage of X that was notable, even today: Keeping user data out of user hands. A high end CAD application I used to do sales, service, sysadmin for used X and the SUID permission bit in UNIX to accomplish keeping data out of users hands. On my bigger systems, I would run one application image, shared by a lot of users. This app, when run by a user, had the data permission and "ran as" data admin. The user has no permission. All access to the data was through the app. And the users had no access to the app or data, just a remote X session. I had tens of users interacting on big designs that way. No worries. Secondly, I could where needed, spawn a second copy of the app to run local to be served up to or even just ran directly by needy users and everything still worked fine. I just had the app run as a different user and the access barrier remained intact. But the big win was one application, one data repository, many users via X. I made a scripted login for them. They would launch it, do their thing, and that's it. All I needed was a respectable X server for whatever box they ran locally. I could admin that setup, and did, on a free JUNO dialup from all over the country. This was the 90's through early 00's.
- tinus_hn 7y ago
  This kind of security is more like a suggestion. It only works without an adversary. X and the libraries used on it are not suitable for setuid programs.
  - ddingus 7y ago
    Context matters. The notable part today isn't hacker protection. I'm sorry I implied that. It's user error / protection. And at the time, getting that on anything that required data move around? Horrors! We've got that today, though it took an amazing amount of thrashing about to get where I was then. And it's more secure in the adversarial sense too. Still, a lot of data has to move around, and it's still a PITA when it does. The better tools today are rapidly converging on that same basic model: App serve to users through display only protocols.
_ph_ 7y ago
I have been using X-Windows in that timeframe - on VMS workstations. The biggest problem was indeed, that X-Windows mostly was a place to run xterms on. But there were a few native GUI applicatons and they were quite nice. The biggest problem was, that Motiv wasn't freely available. You had to pay license costs. If not for that, "Unix on the desktop" might have actually happened. And as the time progressed, Motiv wasn't unbearably slow any more.
- donio 7y ago
  I remember those days too, the lack of a good GUI toolkit felt like such a big deal. Funny that nowadays I find myself using applications that don't use a UI toolkit, Emacs (compiled without toolkit), st, mupdf, games that do their own UI. The only application I have running that uses GTK is chromium.
  - _ph_ 7y ago
    The point I was trying to make was, that there were too few gui applications at all, most of the application I was running were just terminal applications. A widely available GUI toolkit might have helped this. The funniest example was a chemical database software, which would be VT100 based running inside an xterm, but for graphical input/output would spawn a separate window based on X toolkit graphics. But beyond that, those expensive workstations (like $20k in todays money) were mostly running xterm. While being technically widely superior to the PCs of that time - there were also Win3.1 machines around, running a dreadful VT100 emulation - they made little out of it, because there was so little software. So they were eventually replaced with PCs at a fraction of the price. Ironically, even if it were the times of Linux 1.0, I suggested they should run Linux, as they would get excellent X Windows support, unfortunately the suggestion wasn't taken upon.
- DonHopkins 7y ago
  Thank you for calling it X-Windows! ;)
  - DrScump 7y ago
XMPPwocky 7y ago
"The right graphical client/server model is to have an extensible server. Application programs on remote machines can download their own special extension on demand and share libraries in the server. Downloaded code can draw windows, track input eents, provide fast interactive feedback, and minimize network traffic by communicating with the application using a dynamic, high-level protocol." Huh, that's surprisingly prescient. Applications on remote machines can download their own special JavaScript on demand and share code in the server. Downloaded code can draw windows, track input events, provide fast interactive feedback, and minimize network traffic by communicating with the application using HTTP.
- ddingus 7y ago
  Interesting parallel there.
- gopalv 7y ago
  > Applications on remote machines can download their own special JavaScript Depending on what era we imagine writing this, this could be a Java applet or a Flash application or an ActiveX component.
  - XMPPwocky 7y ago
    Yeah, but "SPAs" based on Java/Flash/ActiveX weren't nearly as ubiquitous as web-based SPAs are now, were they?
    - fiddlerwoaroof 7y ago
      Flash was
- DonHopkins 7y ago
  https://en.wikipedia.org/wiki/NeWS https://en.wikipedia.org/wiki/NeWS NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently: - used PostScript code instead of JavaScript for programming. - used PostScript graphics instead of DHTML and CSS for rendering. - used PostScript data instead of XML and JSON for data representation.
kkotak 7y ago
I think first successful implementation of Client-Server OS (and wide adoption in the banking industry) was BTOS/CTOS that was developed by Burroughs Technologies (BTOS) and then continued by Convergent Technologies (CTOS). It was sweet to works with - with modular Hardware and built in debugger on the CLI!
dang 7y ago
By Don Hopkins! https://news.ycombinator.com/user?id=DonHopkins https://news.ycombinator.com/user?id=DonHopkins
dang 7y ago
A thread from 2017: https://news.ycombinator.com/item?id=15035419 https://news.ycombinator.com/item?id=15035419
0xff00ffee 7y ago
I never thought about it from this person's perspective because I never had to program X beyond the graphics and OS classes I took in the early 90's. (Motif's insane verbosity makes code look awful.) I've been using X + MWM since 1991 (AIX and Solaris, anyone?). It is still everywhere, and I wonder how it managed to persist for so long. Why didn't anything ever disrupt Xorg?
- anthk 7y ago
  TBH, Using TCL/TK as a Motif replacement for RAD tools don't look inside, a Pentium3 back in the day was fast enough for TCL 8.4 and 8.5.
- DonHopkins 7y ago
  MOTIF ANGST PAGE If you have any ANGSTFUL Motif code, comments, documentation, or resources, please share them with me! Here is some of the stronger stuff I've found. Note: this is only for official Open Software Foundation Motif inspired Angst. If you're experiencing TCL/Tk That Only Looks Like Motif But Doesn't Suck Angst, then you should stop whining and fix the problem yourself, if somebody else hasn't already. http://art.net/~hopkins/Don/unix-haters/x-windows/motif.html http://art.net/~hopkins/Don/unix-haters/x-windows/motif.html
jasoneckert 7y ago
The Unix hater's handbook was never intended to be taken seriously. It was written by Unix gurus that have the quirky hacker sense of humour. It's just a Unix roast. X was always awesome. Y, on the other hand, well.....
m463 7y ago
I have so agreed with this for years. Not setting policy is what ALL of unix does... and then everyone is fumbling around for years trying to find a policy that works for them. I'm reminded of that Lilly Tomlin quote: "I always wanted to be somebody, but now I realize I should have been more specific."
Izkata 7y ago
> 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." Um, what? By your own description, X's terminology is correct and straightforward: > The idea was to allow a program, called a client, to run on one computer and allow it to display on another computer that was running a special program called a window server. The "service being provided" is "display a window", that the client connects to. There is no inversion here.
- stormbrew 7y ago
  The inversion is at a higher level of the conceptual stack, where a user generally thinks of their own computer as a client in all things. When they connect out to another machine, that's the server. So if you ssh to another machine (a server) and then use a program on it that now displays on your machine, the direction of the connection is absolutely "you're the server, they're the client" but it inverts the user's intuition of what is in which role.
  - salawat 7y ago
    You're not looking at it right. Imagine the X server running on your local machine as a server providing access to your eyeballs. That's why the remote machine is the client; it is a subscriber to the server providing access to your screen.
    - stormbrew 7y ago
      I am not confused about the metaphor. Or at least, I haven't been since like.. 1997 or so. I am explaining why it confuses people. It's pretty undeniable that it does, and telling people that they're wrong about their confusion is shockingly unhelpful.
      - salawat 7y ago
        I'm not telling you you're wrong; simply stating a fact. You are looking at it the wrong way. Projects/solutions often don't make sense unless you look at them from the perspective of the implementers; and like it or not, there is nothing wrong with the reversal of client and server in reference to X. The rendering to be done requires that your particular local hardware be controlled and orchestrated by X aware software. It makes no sense for the remote machine to in any way be burdened with the implementation details of every prospective display set up it could potentially have to talk to. Therefore, the better approach is to define an abstract API from which the remote machine can just speak "X" and leave the details up to the server on the other end to display. Thus, the reversal of Client and Server makes sense. The Server translates your local interactions and display state into "X" protocol messages while the remote client tracks and translates the specifics of the raw display interactions into the implementation details specific to how what is displayed on your local machine interacts with the system present on the remote machine. You're getting confused by Client and Server meaning something in particular, when that isn't really the case. X isn't doing just one thing. The X Server provides the service allowing the client to draw on your hardware. The remote Client is also a Server in that it provides an interface through which actions that take place through your local system are translated into useful functionality on the remote system; however that is a fundamentally different perspective from which to view what X does than through the lens of being a rendering mechanism alone. X does both things. As a rendering technology, the "X client" is remote, the "X server" is local. As a binding between I/O events and program functionality, you can absolutely view the "X server" running on your machine as a client behaviorwise of the server that is the "X client" on the remote machine; but it is still a server in the sense of being aware what your specific hardware setup is, and how to handle it, because the "X client" on the remote is blissfully unaware, and is only there to translate what your "X server" reports to it into meaningful state changes on the remote host. Client/Server is not an atomic concept in computing. You can be both depending on how you are looking at the system. It's a bit like a duck-rabbit. Is it complicated? Yes. Why? Because something that powerful is pretty much guaranteed to be so, and because we try to apply terminology that is generally used in a much more straightforward manner elsewhere to a system that taken as a whole adopts a bidirectional client/server relationship with regards to different subsets of the functionality that the software is intended to enable; namely, to allow graphical interfaces to be utilized between machines with wildly different characteristics, without burdening the "source" machine (the remote machine) with the responsibility of driving our (the local machine's) hardware. Again, There is nothing wrong with the approach except that yes, at first blush, it feels unpleasant to wrap your head around terminology-wise because the conventional way the terms are used exists in both directions in the same software. I don't expect most to grok X the first time. You just have to dig in and get uncomfortably familiar with the hell that is the rat's nest of abstractions that makes remote graphical computing possible.
kabdib 7y ago
I was in a used bookstore a few years ago, and ran across a book titled something like "User Interface Design with MOTIF". Well, it had been a power of years since I last touched X-Windows (with intent to draw pixels, anyway) and I started leafing through it. Looking for user interface examples. Leaf, leaf, nothing. Flip, flip, flipflipflip . . . oh, we're at the index. Nothing. Over 300 pages and no pictures. Zero diagrams. No user interface principles or discussion about good or bad practices. It was all descriptions of APIs. There was nothing about user interface design in there at all. IMHO, that's all you really need to know about X-Windows.
- pengaru 7y ago
  > IMHO, that's all you really need to know about X-Windows. That there was at least one poor, misleadingly titled book about MOTIF? I've had many X-related textbooks over the years, and frankly the documentation was exceptionally good and felt like a total waste on something as byzantine as X.
  - anthk 7y ago
    OpenBSD has one book about Motif in in the books sectin of ports. book/vol6a I think.
- pjmlp 7y ago
  Steve Jobs had a couple of interesting remarks regarding UNIX's culture lack of understanding of UI/UX. The only exceptions are NeWS and NeXTSTEP (OS X derived from it anyway). Everything else are just clones of other desktop OS, with GNOME and KDE trying as good as they can, while dealing with such clunky stack.
  - DonHopkins 7y ago
    (An excerpt from another longer reply I just posted): From: npg@East (Neil Groundwater - Sun Consulting) Date: Wed, Jun 27, 1990 Subject: Humor from Dennis Ritchie (at USENIX) (Actually Dennis's latter remark was attributed by him to Rob Pike) from Unix Today 6/25 page 5. "..., Richie reminded the audience that Steve Jobs stood at the same podium a few years back and announced that X was brain-dead and would soon die. "He was half-right," Ritchie said. "Sometimes when you fill a vacuum, it still sucks." http://www.anvari.org/fortune/Miscellaneous_Collections/133229_in-his-90-usenix-presentation-dennis-ritchie-reminded-the-audience-that-steve-jobs-stood-at-the-same-podium-a-few-years-back-and-announced-that-x-windows-was-brain-dead-and-would-soon-die.html http://www.anvari.org/fortune/Miscellaneous_Collections/1332...
pjmlp 7y ago
> X-Windows started out as one man's project in an office on the fifth floor of MIT's Laboratory for Computer Science. A wizardly hacker, who was familiar with W, a window system written at Stanford University as part of the V project, decided to write a distributed graphical display server. An overview of how this came to be: "A Political History of X" - Keith Packard (LCA 2020) https://www.youtube.com/watch?v=cj02_UeUnGQ https://www.youtube.com/watch?v=cj02_UeUnGQ
phosphophyllite 7y ago
> I have a "window system" on my unix box. You see, in the unix world, "system" means "a bunch of unrelated programs." ... and this is still true after almost 30 years!
DonHopkins 7y ago
Bill Joy referred to X-Windows as "Rasterop on Wheels". I gave a NeWS/Pie Menus/HyperTies/Emacs demo to Steve Jobs once, on the trade show floor at the Educom conference, right after he finally released the NeXT Machine, in November of 1988. Sun was letting me demo NeWS and the stuff we were developing at the UMD Human Computer Interaction Lab on a workstation at their booth, and NeXT's booth was right across the aisle, so Ben Shneiderman rope-a-doped him and dragged him over for a demo. He jumped up and down and yelled "That sucks! That sucks! Wow, that's neat. That sucks!" I figure a 3:1 sucks:neat ratio was pretty good for him comparing something different than his newborn baby NeXT Step, which critics had taken to calling NeVR Step, since it had been vaporware for so long until then. When I tried to explain to him how flexible NeWS was, he told me "I don't need flexibility -- I got my window system right the first time!" Here's Ben's account (I love how he gently put it that "Jobs had little patience with the academic side of things" -- and by "engage" he meant "jump up and down and yell"): Date: Tue, 1 Nov 88 07:55:48 EST From: Ben Shneiderman <ben@mimsy.umd.edu> To: hcil@tove.umd.edu Subject: steve jobs visit I just couldn't resist telling this story.... On Tuesday I was at the EDUCOM conference in DC and Steve Jobs was showing NeXT...I was quite impressed...a nice step forward, improving, refining and developing good ideas. I invited him to see our Hyperties SUN version that we were showing at the SUN booth. The gang managed to get the new NeWS version working and the Space Telescope looked great...Jobs spent about a half hour with us going from positive comments such as "Great!" to "That sucks"...he had a terrific sensitivity to the user interface issues and could articulate his reasons wonderfully. On Wednesday he came out to the lab and spent time looking at a few more of our demos...the students (and me too) were delighted to have him as a visitor. What impresses me is that he took his ideas and really put them to work... pushing back the frontier a bit further. His system really works and has much attractive in the hardware and software domains. Jobs had little patience with the academic side of things, but was very ready to engage over interface issues. Do check out NeXT...there are things to criticize, but I did come away more impressed and pleased than ready to pick at the flaws. -- Ben Here's some old email from the Sun internal NeWS mailing list I saved: From: npg@East (Neil Groundwater - Sun Consulting) Date: Wed, Jun 27, 1990 Subject: Humor from Dennis Ritchie (at USENIX) (Actually Dennis's latter remark was attributed by him to Rob Pike) from Unix Today 6/25 page 5. "..., Richie reminded the audience that Steve Jobs stood at the same podium a few years back and announced that X was brain-dead and would soon die. "He was half-right," Ritchie said. "Sometimes when you fill a vacuum, it still sucks." http://www.anvari.org/fortune/Miscellaneous_Collections/133229_in-his-90-usenix-presentation-dennis-ritchie-reminded-the-audience-that-steve-jobs-stood-at-the-same-podium-a-few-years-back-and-announced-that-x-windows-was-brain-dead-and-would-soon-die.html http://www.anvari.org/fortune/Miscellaneous_Collections/1332...
AzzieElbab 7y ago
Yeah sure, having CAD display on a PC with x11 server hooked to a Unix workstation with dialup is a complete disaster and total waste of resources when compared to uber apps of today like slack
jeffrallen 7y ago
Companion website to the Unix Hater's Handbook: https://web.archive.org/web/19981202041010/http://catalog.com/hopkins/unix-haters/handbook.html https://web.archive.org/web/19981202041010/http://catalog.co...

105 points by shp0ngle 7y ago

And yet, here we are, over a quarter-century later, and that "disaster" is still allowing our programs to run on one computer and display the result on another computer on the other side of the world. The 'Unix Hater's Handbook' is supposedly a humorous work. But it was mainly used in the 1990s by non-Unix companies as anti-Unix propaganda. Unfortunately for them, all of today's main computer/software companies either use Unix or Unix-like operating systems (Apple:BSD Unix, Google:Android, IBM and Others:Linux, Microsoft:WSL). https://en.wikipedia.org/wiki/The_Unix-Haters_Handbook https://en.wikipedia.org/wiki/The_Unix-Haters_Handbook

ajross 7y ago
To be fair: the UHH is a legitimately great book, a fun read, and absolutely something every modern developer should know. It's opinionated in exactly the right way, even if some of its conclusions turn out to have been wrong in hindsight. But as for X11: yeah. You can complain all you want at microdesign issues, but longevity beats all. I can run an unmodified X11R1 client from 1987 against the default install of pretty much any newly installed Linux/BSD box and it still works, something not true of literally any other contemporary GUI toolkit of the era.
- ddingus 7y ago
  While I was learning UNIX, the UHH was given to me as a rite of passage. Great book. I learned a lot. Love UNIX.
cowmix 7y ago
As a someone who has used Unix for 35+ years, I feel the book is great. It actually does more to explain why things are the way they are in UNIX than any other book I've read, pro-Unix or not.. I don't agree with everything it covers and many of the complaints of the book have been addressed over the years, but it definitely still relevant today.
uk_programmer 7y ago
Generally I agree. However I would say with regards to iOS (not MacOS) and Android. While underneath they are both Linux and Darwin based respectively. Almost the entire OS anyone interacts (including most devs) is done through the Android and iOS APIs. They could replace what is underneath with something very different and you wouldn't be any of the wiser. There isn't really much to separate something like Ubuntu and MacOS in terms of what they are (other than polish). In Jaron Laniers book "You are not a gadget" he says the open source community are very good at making clones of existing things but not inventing new things themselves. I would argue that programmers in general are very good at making clones of existing things. This has allowed Unix-like operating be ubiquitous as they are easy to copy and are good enough.
kick 7y ago
It's not just a humorous work, it's also genuine criticism. dmr could find the humor in it, why can't you?
- smhenderson 7y ago
  dmr’s forward is my favorite part though. As others have said a lot of the criticism in the book has been addressed over the years. I came late to the party so I missed out on a lot of the early bugs and mis-features of UNIX.
gok 7y ago
A lot of the criticisms have been addressed though. Basically no one outside of enthusiasts uses X any more; Android and Chrome OS use an entirely different graphics system. The filesystems have been replaced. Shells have been replaced and/or obviated for most users.
- ddingus 7y ago
  Really, and this is an OK choice, but is a choice all the same: What happened is others settled on a subset of multi user graphical computing. That is not replacing X. It is something different, less. Maybe less is more too. I have an open mind. However that goes, X nailed multi user graphical computing. Pretty much any crazy thing you can think of can be done on X. Want to make a computer that several people use locally, each with their own screen, keyboard, mouse? X can do that, and permit those users to view and interact with any combination of each others display data. One says, hey can you sort this for me? Another says, "sure", and a window pops up on their screen... Now, replicate that same setup, each user has their own powerful computer, maybe with a common, shared display among them, like a wall display or something. No problem. X does that too, and chances are only the sysadmin differs. The apps will have no clue. It may be that we just do not work that way, or maybe not enough know how, but let's be clear here. X is not being replaced. A subset at best is being put forward. I think that means we just are not really doing multi user graphical computing. And that is OK.
  - tropo 7y ago
    X has never supported reliable screen locking. If the screen locker program crashes or is killed because the OS ran out of memory, the X server is unprotected. It's an unpleasant feeling to come back to an unlocked screen in a shared building.
  - battery_cowboy 7y ago
    Wow, can you tell me where I can find out about how to do those things, like: > Want to make a computer that several people use locally, each with their own screen, keyboard, mouse? X can do that, and permit those users to view and interact with any combination of each others display data. > One says, hey can you sort this for me? Another says, "sure", and a window pops up on their screen... Is there literature or something about setting up complex things like this in X? I'd be interested in learning more.
mjcohen 7y ago
I learned a LOT when I read the UHH in the 90s.
ChuckMcM 7y ago
One of the fun things about working at Sun back in the day was that there were folks trying to fix some of the issues that were legitimately raised by the UHH. That said, I shared Don's disgust with X. The difference between running X on a workstation and SunTools felt like a 300% slowdown. And yet today I sit here typing into a window that is being displayed by an X server running on a Windows OS on a computer that is acting pretty much like an X-terminal for my Linux server. It has warts, true, but its still flying as they would say on Firefly. I have often wondered what the world would be like if we had decided to move the GPU into the monitor and ran a parameterized display system over HDMI rather than something that looks like a cancerous NTSC composite video signal.
- DonHopkins 7y ago
  >One of the fun things about working at Sun back in the day was that there were folks trying to fix some of the issues that were legitimately raised by the UHH. Like opening core files (which have gigantic gaps of unmapped zeros) by loading them into the XView text editor when you double click on them in the XView file manager? ;) That's actually how core dumps grow and reproduce and evolve, like those wasps that lay their eggs in other insects and turn them into zombies, by embedding themselves in an unwitting host process and making it core dump even bigger! https://www.wired.com/2014/10/absurd-creature-week-glyptapanteles-wasp-caterpillar-bodyguard/ https://www.wired.com/2014/10/absurd-creature-week-glyptapan... And while on the topic of XView: Do you have any good XBUGTOOL horror stories, Chuck? ;) The most foolish thing I ever did was try to use it to file a bug against itself. Boy do I regret that! http://www.art.net/~hopkins/Don/unix-haters/x-windows/xbugtool.html http://www.art.net/~hopkins/Don/unix-haters/x-windows/xbugto...
pjmlp 7y ago
That disaster is the major reason why UNIX FOSS clones will never get desktop or mobile computing devices beyond a single digit number. You can have all the fun you want with your beloved X, I rather use modern Windowing platforms and their composition engines. Also, UNIX underpinnings are completly irrelevant on Android, iOS and ChromeOS. In what concerns macOS and Windows, they are there to cater to the GNU/Linux crowd that buys Macs and Windows devices instead of buying GNU/Linux hardware.
IshKebab 7y ago
No it isn't. Almost nobody uses raw X over long distances because it is unusable. Everybody uses something else like VNC, RDP or NX. Note that NX actually moved away from the X protocol and is now just a VNC-like protocol, i.e. it only deals with pixels. Every modern remote desktop protocol works that way because it is better.
catblast 7y ago
> allowing our programs to run on one computer and display the result on another computer on the other side of the world. I feel sorry for anyone having to use X over a link of that latency. Especially if their internet service has a tendency to go down. How many X clients handle loss of connection better than just terminating? And are there really that many people using X remote as compared to RDP or Citrix. I would be surprised to find out that remote X is widely used in 2020 (if you can even call it’s brief heyday in the 90s while commercial UNIX was losing its balls to Windows NT due to vendor incompetence).. and I would risk the age discrimination suits and fire the IT team. X was already an ugly obsolete piece of crap in the 90s when it was foisted upon us by all the major commercial Unix vendors. It should have rightfully died with SGI, Sun, and/or DEC.
catblast 7y ago
> But it was mainly used in the 1990s by non-Unix companies as anti-Unix propaganda. Some strange revisionism there as few of the authors of UHH were involved with Windows.. which is what ended up completely eating commercial Unix lunch... a win that was not so much due to Microsoft’s competence as their competitors stupidity. Meanwhile calling Mac OS X or Android Unix-like just because they have some tools in common (MAC OS X is only vaguely a BSD — and launchd seems to get some love by the same people that have a conniption fit over systems) .. none of those systems use X for sure. Desktop Linux is a rounding error.. the part of Linux that gets used heavily for servers that is the reason that WSL is a thing (to ease development)?? Yeah that has basically fuck all to do with the disasters in SySV/commercial Unix... not too many people using SySV IPC on Linux, and cgroups, epoll, io_uring hardly remind me of the miserable APIs of now ancient Unix.

jgon 7y ago

A disaster, and yet I remember reading about attempts to replace it when I was still in University, and now here I am over a decade into my career and Wayland still isn't ready for primetime, especially if you use a video card from the #1 producer of performance video cards on the planet. Small use case I guess. X lets you do forwarding over the network and maybe sometime in the 2020's Wayland will have some sort of remote desktop solution? Still waiting on that to be ironed out... Replacing X feels like the nuclear fusion project of the Linux world, constantly receeding into the future even as it maintains its promises of fixing all our problem When It's Done(tm).

cycloptic 7y ago
There are various solutions already available for remoting in Wayland. GNOME: https://wiki.gnome.org/Projects/Mutter/RemoteDesktop https://wiki.gnome.org/Projects/Mutter/RemoteDesktop KDE: https://userbase.kde.org/Krfb https://userbase.kde.org/Krfb Sway/wlroots: https://github.com/any1/wayvnc https://github.com/any1/wayvnc Generic: https://gitlab.freedesktop.org/mstoeckl/waypipe/ https://gitlab.freedesktop.org/mstoeckl/waypipe/ Web-Based: https://github.com/udevbe/greenfield https://github.com/udevbe/greenfield You can also still use your X11 programs remotely within Wayland, by using XWayland, which is supported by all the major implementations. Unrelated to Wayland, there is also backend support in GTK3/4 for rendering to a web socket: https://developer.gnome.org/gtk3/stable/gtk-broadway.html https://developer.gnome.org/gtk3/stable/gtk-broadway.html
- ricktdotorg 7y ago
  from this page: > GNOME: https://wiki.gnome.org/Projects/Mutter/RemoteDesktop https://wiki.gnome.org/Projects/Mutter/RemoteDesktop "Currently only remote passwordless unencrypted VNC access to an existing session is supported." i guess that is technically a solution, but not a good one.
  - cycloptic 7y ago
    Yes, the quality of these varies, pick the one that is right for you. X11 forwarding is not without issues either. With VNC you'll probably also want to tunnel the connection over SSH to secure it rather than rely on server authentication anyway.

mshook 7y ago

It's X-Window (System), no S.

warpech 7y ago
It says it the footnotes that the misspelling is intentional
s_gourichon 7y ago
The text of the article actually has it correct most of the time. The name is just "X". It's a windowing system that happens to be named "X". It's named this way because it is a successor to another windowing system named "W" and "X" comes after "W" in alphabet order. https://en.wikipedia.org/wiki/X_Window_System#Predecessors https://en.wikipedia.org/wiki/X_Window_System#Predecessors
- ptx 7y ago
  Exactly. Many people seem to read it as "the system named X Window", but, as you say, it's actually "the window system named X". The Linux Operating System is an operating system and the X Window System is a window system. Maybe part of the reason is the Title Case convention in English? (And the other part may be the name of Microsoft's window system leading the mind along this path.)
  - sicnus 7y ago
    Oh, I wanna hop in on this train. tell that fool to man X yo. ;) I've been getting pissed about people calling it "X Windows" since 1995 so there.
    - DonHopkins 7y ago
      You made my day! I'm so delighted to hear you're pissed that people call it X-Windows. ;) Thank you for letting me know my long term project of always calling it X-Windows worked perfectly as planned. I've been systematically calling it X-Windows to piss people off since June 1988, when I read the article "Things That Happen When You Say ‘X Windows’" in my copy of Volume 1 Number 2 of the June 1988 of the “XNextEvent” newsletter, “The Official Newsletter of XUG, the X User’s Group” (which I quoted above): https://news.ycombinator.com/item?id=22501380 https://news.ycombinator.com/item?id=22501380 From the end of the X-Windows Disaster article: >Don wrote the chapter on the X-Windows Disaster. (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. I started programming X10 in June 1986. Here's my first X10 program, a pie menu test application (I was calling them "theta menus" then): https://donhopkins.com/home/archive/piemenu/theta.test/ https://donhopkins.com/home/archive/piemenu/theta.test/ After that I modified the X10 "uwm" window manager to support pie menus, and integrated it with FORTH so I could interactivally program and extend the window manager in FORTH, and use it to implement and perform an experiment comparing pie menus with linear menus. https://medium.com/@donhopkins/an-empirical-comparison-of-pie-vs-linear-menus-466c6fdbba4b https://medium.com/@donhopkins/an-empirical-comparison-of-pi... Forth pie menu X10 window manager source code (the main FORTH part -- other C and FORTH source code is in the same directory): https://donhopkins.com/home/archive/piemenu/uwm/fuwm-main.f https://donhopkins.com/home/archive/piemenu/uwm/fuwm-main.f X10 Pie Menu Window Manager: https://www.youtube.com/watch?v=IJhvB6kwmog https://www.youtube.com/watch?v=IJhvB6kwmog Then I moved on from X10 to NeWS (and from FORTH to PostScript), because NeWS was so much better than X10 or X11, and supported round windows and non-terrible graphics. At Sun in 1991 I helped write an X-Windows ICCCM X11 window manager in PostScript so NeWS could manage X-Windows, which supported non-rectangular tabbed window frames, pie menus in round windows, multiple displays, multiple rooms, scrolling virtual desktops (with an iconic map that let you scroll your view around), and many other nice features that other X window managers couldn't do at the time. Plus it was faster and more efficient than any X window manager because it actually ran in the window server instead of running in a separate process and communicating over the network, so it was able to immediately synchronously handle events, provide feedback, draw rubber-band lines in the overlay, pop up and track menus immediately, perfectly support quick mouse-ahead gestures, move and resize windows instantly, all without context switching or network traffic or grabbing the server or freezing event distribution or lagging behind or missing any events, instead of being asynchronous and laggy and flakey and dropping events like all other outboard networked X11 window managers do by design. (This was extremely important when running on a slow diskless Sun 3/50 paging over the network.) The idea of running something as crucial and interactive as the window manager in a separate process using an asynchronous protocol is quite insane, inefficient, wasteful, and flakey, but that's how X was designed to be. https://donhopkins.com/home/archive/NeWS/owm.ps.txt https://donhopkins.com/home/archive/NeWS/owm.ps.txt Demo of the Pie Menu Tab Window Manager for The NeWS Toolkit 2.0: https://www.youtube.com/watch?v=tMcmQk-q0k4 https://www.youtube.com/watch?v=tMcmQk-q0k4 In 1992 I made a pie menu window manager called "piewm" based on "tvtwm", and I also ported SimCity to X11, using TCL/Tk, redesigning it to be a multi player networked game, and encountering and solving all kinds of problems trying to make X11 play a game, support multiple users, do fast shared memory graphical animation, mix sounds with a network audio mixer, and support different types of screens and devices (both black and white and color). Those experiences were what motivated me to write the Unix-Haters Handbook chapter on the X-Windows Disaster, and compare my experiences with NeWS and X-Windows. http://www.art.net/~hopkins/Don/piemenus/index.html http://www.art.net/~hopkins/Don/piemenus/index.html >The "piewm" X11 window manager with pie menus. When I was a research programmer at CMU, faced with using X11, I realized that I needed pie menus to help me move my windows around, so I went shopping around for a reasonable window manager, and since there weren't any, I choose the least unreasonable one at the time, "tvtwm", and hacked it up with an updated version of the old X10 "uwm" pie menus, and called it "piewm". The source code is available here: piewm.tar.Z. http://www.art.net/~hopkins/Don/piemenus/piewm.tar.Z http://www.art.net/~hopkins/Don/piemenus/piewm.tar.Z >The TCL/Tk pie menu widget. I accidentally ported the HyperLook version of SimCity to X11, making it multi player in the process, using the TCL/Tk toolkit, which was the only X11 toolkit that didn't suck. I needed some fancy looking graphical pie menus, so I made a TCL/Tk pie menu widget, whose window shape could be shrink-wrapped around iconic labels. The source code is available here: tkpie.tar.gz. I recorded an X11 SimCity demo, showing pie menus in action. SimCity for X11 won a "best product of 1992" award from Unix World! http://www.art.net/~hopkins/Don/piemenus/tkpie.tar.gz http://www.art.net/~hopkins/Don/piemenus/tkpie.tar.gz More stuff about X11 window management and multi player SimCityNet: http://www.art.net/~hopkins/Don/unix-haters/x-windows/i39l.html http://www.art.net/~hopkins/Don/unix-haters/x-windows/i39l.h... http://www.art.net/~hopkins/Don/simcity/simcity-announcement.html http://www.art.net/~hopkins/Don/simcity/simcity-announcement... http://www.art.net/~hopkins/Don/simcity/simcitynet.html http://www.art.net/~hopkins/Don/simcity/simcitynet.html X11 SimCity Demo: https://www.youtube.com/watch?v=Jvi98wVUmQA https://www.youtube.com/watch?v=Jvi98wVUmQA Multi Player SimCityNet for X11 on Linux (you can see the date changing so fast it blurs at 1:25): https://www.youtube.com/watch?v=_fVl4dGwUrA https://www.youtube.com/watch?v=_fVl4dGwUrA Here's how fun it is trying to draw the SimCity map efficiently with X-Windows: if only a few pixels have changed (which is a very common case), instead of sending the entire image, it sorted the changed pixels by color, then used XDrawPoints to draw each batch of different colored pixels that changed. Changing colors is expensive, so if you changed colors for every dot it would be very slow, but X-Windows lets you draw a bunch of dots at any position in the same color efficiently, so SimCity finds the pixels that changed, and if there are few enough of them, it sorts them by color, then goes through setting each color and drawing every pixel that changed to that color with XDrawPoints. If more than max_pix (256) changed, it just sends the whole image. Yes, that was the most efficient way to do it if the server didn't support shared memory or was across the network on a different host, since the X protocol and graphics API is so awkward and inefficient. And even if you have the shared memory extension in your server, X still requires that you ALSO write code to support the case of no shared memory, since it still needs to be able to run over the network. Decades later when I updated the code to support different bit depths than an 8 bit color palette, computers and networks were astronomically faster, and the code was too tricky for its own good, and SimCity on the OLPC was usually running locally with shared memory anyway, so I punted, commented out that code, and just sent the image every time. https://github.com/SimHacker/micropolis/blob/b0c5a3f495ebabbc51d5e45dac948d8e40fc53ee/micropolis-activity/src/sim/w_map.c#L466 https://github.com/SimHacker/micropolis/blob/b0c5a3f495ebabb... /* * Sending the whole image is 108108 bytes. * Sending points is 4.4 bytes per point. * One image is as big as 24570 points. * But we have to sort these dang things. */ #define MAX_PIX 256 int max_pix = MAX_PIX; [...] /* TODO: Fix this. I disabled this incremental drawing code for now since it seems to be buggy. */ /* Sort the changed pixels by their color */ qsort(pix, different, sizeof (struct Pix), (int (*)())CompareColor); /* Draw the points of each color that have changed */ points = (XPoint *)malloc(sizeof (XPoint) * different); last = 0; pts = 0; for (i = 0; i <= different; i++) { if ((i == different) || (pix[i].color != pix[last].color)) { XSetForeground(view->x->dpy, view->x->gc, pix[last].color); XDrawPoints(view->x->dpy, view->pixmap, view->x->gc, points, pts, CoordModeOrigin); if (i == different) break; pts = 0; last = i; } points[pts].x = pix[i].x; points[pts].y = pix[i].y; pts++; } free(points); The map editor "DrawOverlay" code also has a lot of fun hairy optimizations to draw fast over the network, and it measure how long it takes in different situation and uses the most efficient technique (drawing the lines every time, or caching them in an offscreen pixmap overlay): https://github.com/SimHacker/micropolis/blob/b0c5a3f495ebabbc51d5e45dac948d8e40fc53ee/micropolis-activity/src/sim/w_editor.c#L1426 https://github.com/SimHacker/micropolis/blob/b0c5a3f495ebabb... When I was timing and optimizing SimCity to make it run as fast as possible on X-Windows, I noticed that when you ran it super-duper flat-out fast, skipping screen updates to run the simulator in a tight loop, a huge amount of time was wasted simply redrawing the date field, since it changed so many times per screen refresh. So I implemented a special custom TCL/Tk widget just for displaying the date, which only lazily updates occasionally at a fixed frequency, and knows how to draw the text in an offscreen pixmap and "fake blur" the parts of the date that are changing quickly by overprinting the letters and digits in gray (you can't easily blur or blend text in X-Windows with an 8 bit color mapped display, so I did the next best thing that was possible and efficient, and it got the point across that time was moving very fast, without slowing the computer down or making it unresponsive). https://github.com/SimHacker/micropolis/blob/b0c5a3f495ebabbc51d5e45dac948d8e40fc53ee/micropolis-activity/src/sim/w_date.c#L597 https://github.com/SimHacker/micropolis/blob/b0c5a3f495ebabb... More about NeWS in this recent discussion: https://news.ycombinator.com/item?id=22455722 https://news.ycombinator.com/item?id=22455722

gok 7y ago

> like Sun's Open Look clock tool, which gobbles up 1.4 megabytes of real memory Meanwhile the clock app on my phone is currently using 12 MB. A popular time telling website uses over 100MB on my laptop.

tinus_hn 7y ago
Is it http://whattimeisitrightnow.com/ http://whattimeisitrightnow.com/
- gok 7y ago
  That was what I looked at yeah, and I appreciate that it's actually a Netflix gag site for Bojack Horseman but still.
donio 7y ago
It's like the Eight Megabytes And Constantly Swapping joke for Emacs. These days a minimal Emacs is more like 18MB RSS rather than 8 but that's still tiny compared to modern apps.
speedgoose 7y ago
I don't know about your phone but mine which is not new has 6gb of ram and the latest Samsung s20 flagship has 12gb of ram. In comparison to the total ram, it's much better nowadays.
0xff00ffee 7y ago
I bet 99% of that 12MB is graphical assets: different sized icons for different display geometries. I always found asset management for multiple platforms to be most annoying when developing for mobile. This reminds me of when people started to realize Microsoft Foundation Class (MFC) was blowing up and were bemoaning code-bloat. In 1997.
- hermitdev 7y ago
  The very mention of MFC gave me shivers down my spine. The macro horror show and indecipherable error messages... Thankfully, I never had to do much MFC professionally, but holy shit, if you inadvertently messed with one of the generated macros, good luck. I remember it sometimes being easier to throw away everything and start from scratch than debug the horrible compiler errors.

commandlinefan 7y ago

When I first saw X, I had already grown up with PCs, so the whole concept of running the “main program” on another computer just to display it on my computer seemed so illogical I thought I must just be misunderstanding it. I mean.. I have a computer right here, why not run the program on this computer…? However, if you think about it - the X philosophy was actually mostly correct (or at least more useful than it initially seemed), they just did it in a clunky way. We’ve been slowly migrating to web applications which are the same basic concept: the program runs on the web server and your browser displays the results. This actually is better from a security standpoint (the server can access data that isn’t distributed to the client) and a maintenance standpoint (I can deploy a new version to the server and it’s instantaneously available to all clients). Running a “program” remotely and displaying the results locally is so ubiquitous now that my teenage kids are confused by the entire concept of desktop applications. What I’d love to see, and wish I had the free time to implement, is a Linux UI based on something like SVGALib that doesn’t use X at all; just enough to run a terminal and a browser (and maybe an email client and a word processor if somebody wanted to write one).

s_gourichon 7y ago
The modern equivalent of SVGALib is Linux' Direct Rendering Infrastructure. If you just want fullscreen app, you can run them on top of DRI. For "a terminal and a browser" at the same time you have to create some sort of protocol for windowed display, and an implementation of one side of that protocol that provides window management, and apps would implement the other side. People did that. They named the protocole "Wayland", the window management implementation "Weston", and a number of graphical toolkits can target Wayland (GTK, QT, SDL...). Ref: https://wayland.freedesktop.org/faq.html#heading_toc_j_2 https://wayland.freedesktop.org/faq.html#heading_toc_j_2 As a sidenote, if you want to run such a program standalone, fullscreen, can you do that without running a "server" or a "window manager"? IIRC, programs intended for Wayland can run fullscreen on top of plain DRI (or perhaps only SDL provides this facility).
- cycloptic 7y ago
  The simplest thing I know of is the minimal Cage compositor for wayland, that only supports running a single fullscreen program: https://github.com/Hjdskes/cage https://github.com/Hjdskes/cage With some hackery, you could probably build this as a backend for GTK/Qt that would run the server in the same process. But I don't know how useful that would really be.

ddingus 7y ago

X is kind of amazing. Once, just for fun, I had an SGI do window management, another one serve up fonts, a linux box serving apps via NFS, and yet another headless SGI running a shared app displayed on yet another Linux machines X window server session. It was surreal. Launch that app, and all those machines contributed to the interaction of it. Plus, it made that instance of RH Linux look like an SGI. 4dwm has a distinct look and feel. For the most part, running over a 100T network, one could not tell all that was happening. (Was a high end CAD app.) Later, I did run that same app remotely, using its Windows NT build and the Exceed X server for Win NT. Cool.

kevin_thibedeau 7y ago
I like being able to run a Linux desktop in a VM on windows and "extend" to another monitor with VM X apps rendering to a Cygwin Xorg instance. Wayland can't do that.
- cycloptic 7y ago
  There is no reason wayland couldn't do that, other than that your compositor doesn't support the concept of virtual screens. I can't say that this is a very high-priority feature for any compositors at the moment.
  - ddingus 7y ago
    And that is why X is kind of amazing. They thought it all through. Today, it is a game of which pieces make the most sense, and whether multi user graphical computing should be a thing. We know it can. X did all that. Should it?
    - cycloptic 7y ago
      As far as Wayland goes, that is up to the developers and users of those compositors. The protocol itself supports the concept of multiple seats. I can't speak for all the original X developers but TFA seems to suggest that they didn't think it all through.

downerending 7y ago

At the time when X was first being developed, there simply were no open source alternatives. I used a few of the closed source ones and they were nice enough, but generally available on only a single platform (e.g., HP), which made them fairly useless. Even if Wayland succeeds, it'll be a long time before it has truly replaced X. In reality, I think it's more likely that both will be (or already have been) been run over by web apps.

ahartmetz 7y ago
That's like saying that CPUs will be run over by Linux.
code_duck 7y ago
The browser needs to be displayed somehow.
- pjmlp 7y ago
  Yes, and as proven by ChromeOS, X is not a requirement.
  - code_duck 7y ago
    The comment I replied to said X and Wayland would be 'overrun by web apps' and I'm not sure what that means. ChromeOS is not a web app and neither is chrome.
    - pjmlp 7y ago
      They already have been, X accounts for single digit desktop market size. ChromeOS is a Web based OS with more market share than GNU/Linux, thus just by measuring its usage across US school system, it is higher than X. Then we can add all remaining desktop and mobile OSes into the mix. Finally, SaaS Web applications are in many cases the only way some applications ever reach FOSS UNIX clones.
      - 7y ago

andyjpb 7y ago

The UNIX Haters Handbook was funny at the time but doesn't make much sense these days unless you understand all the rival hacker groups and cultures that were largely eventually unified under "Free Software" and, later, "Open Source". Even the LISPers have come in from the cold! Much of this criticism of X was prescient for things to come. Autotools, dependency problems, modularity issues, compatibility, "DLL-hell", etc. Many of these problems don't have solutions today that are orders of magnitude better than then. On the other hand, one thing that's really holding X back, especially on handhelds, is 'Myth: X is "Device Independent"'. If the difference between a 75dpi screen and a 100dpi workstation screen was too much, today's "retina" displays really struggle to run a usable X. You're heavily reliant on the toolkits (Qt, GTK, etc) to scale things for you and they mostly understand about font scaling but not about widget scaling. Lots of distributions that might want to use it, for example Maemo Leste, Ubuntu Touch or Gemian, are having to do a lot of UI work and hand-pick applications for "porting" to the screens and input devices (touch) that they want to use them on. This means that Linux-on-the-smartphone is not yet in any position to give Android or iOS a run for it's money because it really struggles to effectively leverage its existing app ecosystem. Even ignoring security models, X struggles to provide even a compelling visual of a vision for handheld devices. Don't even mention Wayland: that has other economic incentives that are not yet properly aligned for widespread success (including X's app ecosystem ones).

jcelerier 7y ago
> If the difference between a 75dpi screen and a 100dpi workstation screen was too much, today's "retina" displays really struggle to run a usable X. I've been running X11 on retina displays since 2014 without much of an issue. The only big offenders were chrome and firefox. Nowadays everything just works.
- fsh 7y ago
  It works if you have more or less the same pixel density across all screens. As soon as you mix very different ones, X becomes essentially unusable. Microsoft and Apple have solved that issue years ago.

ddingus 7y ago

Here is one advantage of X that was notable, even today: Keeping user data out of user hands. A high end CAD application I used to do sales, service, sysadmin for used X and the SUID permission bit in UNIX to accomplish keeping data out of users hands. On my bigger systems, I would run one application image, shared by a lot of users. This app, when run by a user, had the data permission and "ran as" data admin. The user has no permission. All access to the data was through the app. And the users had no access to the app or data, just a remote X session. I had tens of users interacting on big designs that way. No worries. Secondly, I could where needed, spawn a second copy of the app to run local to be served up to or even just ran directly by needy users and everything still worked fine. I just had the app run as a different user and the access barrier remained intact. But the big win was one application, one data repository, many users via X. I made a scripted login for them. They would launch it, do their thing, and that's it. All I needed was a respectable X server for whatever box they ran locally. I could admin that setup, and did, on a free JUNO dialup from all over the country. This was the 90's through early 00's.

tinus_hn 7y ago
This kind of security is more like a suggestion. It only works without an adversary. X and the libraries used on it are not suitable for setuid programs.
- ddingus 7y ago
  Context matters. The notable part today isn't hacker protection. I'm sorry I implied that. It's user error / protection. And at the time, getting that on anything that required data move around? Horrors! We've got that today, though it took an amazing amount of thrashing about to get where I was then. And it's more secure in the adversarial sense too. Still, a lot of data has to move around, and it's still a PITA when it does. The better tools today are rapidly converging on that same basic model: App serve to users through display only protocols.

_ph_ 7y ago

I have been using X-Windows in that timeframe - on VMS workstations. The biggest problem was indeed, that X-Windows mostly was a place to run xterms on. But there were a few native GUI applicatons and they were quite nice. The biggest problem was, that Motiv wasn't freely available. You had to pay license costs. If not for that, "Unix on the desktop" might have actually happened. And as the time progressed, Motiv wasn't unbearably slow any more.

donio 7y ago
I remember those days too, the lack of a good GUI toolkit felt like such a big deal. Funny that nowadays I find myself using applications that don't use a UI toolkit, Emacs (compiled without toolkit), st, mupdf, games that do their own UI. The only application I have running that uses GTK is chromium.
- _ph_ 7y ago
  The point I was trying to make was, that there were too few gui applications at all, most of the application I was running were just terminal applications. A widely available GUI toolkit might have helped this. The funniest example was a chemical database software, which would be VT100 based running inside an xterm, but for graphical input/output would spawn a separate window based on X toolkit graphics. But beyond that, those expensive workstations (like $20k in todays money) were mostly running xterm. While being technically widely superior to the PCs of that time - there were also Win3.1 machines around, running a dreadful VT100 emulation - they made little out of it, because there was so little software. So they were eventually replaced with PCs at a fraction of the price. Ironically, even if it were the times of Linux 1.0, I suggested they should run Linux, as they would get excellent X Windows support, unfortunately the suggestion wasn't taken upon.
DonHopkins 7y ago
Thank you for calling it X-Windows! ;)
- DrScump 7y ago

XMPPwocky 7y ago

"The right graphical client/server model is to have an extensible server. Application programs on remote machines can download their own special extension on demand and share libraries in the server. Downloaded code can draw windows, track input eents, provide fast interactive feedback, and minimize network traffic by communicating with the application using a dynamic, high-level protocol." Huh, that's surprisingly prescient. Applications on remote machines can download their own special JavaScript on demand and share code in the server. Downloaded code can draw windows, track input events, provide fast interactive feedback, and minimize network traffic by communicating with the application using HTTP.

ddingus 7y ago
Interesting parallel there.
gopalv 7y ago
> Applications on remote machines can download their own special JavaScript Depending on what era we imagine writing this, this could be a Java applet or a Flash application or an ActiveX component.
- XMPPwocky 7y ago
  Yeah, but "SPAs" based on Java/Flash/ActiveX weren't nearly as ubiquitous as web-based SPAs are now, were they?
  - fiddlerwoaroof 7y ago
    Flash was
DonHopkins 7y ago
https://en.wikipedia.org/wiki/NeWS https://en.wikipedia.org/wiki/NeWS NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently: - used PostScript code instead of JavaScript for programming. - used PostScript graphics instead of DHTML and CSS for rendering. - used PostScript data instead of XML and JSON for data representation.

kkotak 7y ago

I think first successful implementation of Client-Server OS (and wide adoption in the banking industry) was BTOS/CTOS that was developed by Burroughs Technologies (BTOS) and then continued by Convergent Technologies (CTOS). It was sweet to works with - with modular Hardware and built in debugger on the CLI!

dang 7y ago

By Don Hopkins! https://news.ycombinator.com/user?id=DonHopkins https://news.ycombinator.com/user?id=DonHopkins

dang 7y ago

A thread from 2017: https://news.ycombinator.com/item?id=15035419 https://news.ycombinator.com/item?id=15035419

0xff00ffee 7y ago

I never thought about it from this person's perspective because I never had to program X beyond the graphics and OS classes I took in the early 90's. (Motif's insane verbosity makes code look awful.) I've been using X + MWM since 1991 (AIX and Solaris, anyone?). It is still everywhere, and I wonder how it managed to persist for so long. Why didn't anything ever disrupt Xorg?

anthk 7y ago
TBH, Using TCL/TK as a Motif replacement for RAD tools don't look inside, a Pentium3 back in the day was fast enough for TCL 8.4 and 8.5.
DonHopkins 7y ago
MOTIF ANGST PAGE If you have any ANGSTFUL Motif code, comments, documentation, or resources, please share them with me! Here is some of the stronger stuff I've found. Note: this is only for official Open Software Foundation Motif inspired Angst. If you're experiencing TCL/Tk That Only Looks Like Motif But Doesn't Suck Angst, then you should stop whining and fix the problem yourself, if somebody else hasn't already. http://art.net/~hopkins/Don/unix-haters/x-windows/motif.html http://art.net/~hopkins/Don/unix-haters/x-windows/motif.html

jasoneckert 7y ago

The Unix hater's handbook was never intended to be taken seriously. It was written by Unix gurus that have the quirky hacker sense of humour. It's just a Unix roast. X was always awesome. Y, on the other hand, well.....

m463 7y ago

I have so agreed with this for years. Not setting policy is what ALL of unix does... and then everyone is fumbling around for years trying to find a policy that works for them. I'm reminded of that Lilly Tomlin quote: "I always wanted to be somebody, but now I realize I should have been more specific."

Izkata 7y ago

> 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." Um, what? By your own description, X's terminology is correct and straightforward: > The idea was to allow a program, called a client, to run on one computer and allow it to display on another computer that was running a special program called a window server. The "service being provided" is "display a window", that the client connects to. There is no inversion here.

stormbrew 7y ago
The inversion is at a higher level of the conceptual stack, where a user generally thinks of their own computer as a client in all things. When they connect out to another machine, that's the server. So if you ssh to another machine (a server) and then use a program on it that now displays on your machine, the direction of the connection is absolutely "you're the server, they're the client" but it inverts the user's intuition of what is in which role.
- salawat 7y ago
  You're not looking at it right. Imagine the X server running on your local machine as a server providing access to your eyeballs. That's why the remote machine is the client; it is a subscriber to the server providing access to your screen.
  - stormbrew 7y ago
    I am not confused about the metaphor. Or at least, I haven't been since like.. 1997 or so. I am explaining why it confuses people. It's pretty undeniable that it does, and telling people that they're wrong about their confusion is shockingly unhelpful.
    - salawat 7y ago
      I'm not telling you you're wrong; simply stating a fact. You are looking at it the wrong way. Projects/solutions often don't make sense unless you look at them from the perspective of the implementers; and like it or not, there is nothing wrong with the reversal of client and server in reference to X. The rendering to be done requires that your particular local hardware be controlled and orchestrated by X aware software. It makes no sense for the remote machine to in any way be burdened with the implementation details of every prospective display set up it could potentially have to talk to. Therefore, the better approach is to define an abstract API from which the remote machine can just speak "X" and leave the details up to the server on the other end to display. Thus, the reversal of Client and Server makes sense. The Server translates your local interactions and display state into "X" protocol messages while the remote client tracks and translates the specifics of the raw display interactions into the implementation details specific to how what is displayed on your local machine interacts with the system present on the remote machine. You're getting confused by Client and Server meaning something in particular, when that isn't really the case. X isn't doing just one thing. The X Server provides the service allowing the client to draw on your hardware. The remote Client is also a Server in that it provides an interface through which actions that take place through your local system are translated into useful functionality on the remote system; however that is a fundamentally different perspective from which to view what X does than through the lens of being a rendering mechanism alone. X does both things. As a rendering technology, the "X client" is remote, the "X server" is local. As a binding between I/O events and program functionality, you can absolutely view the "X server" running on your machine as a client behaviorwise of the server that is the "X client" on the remote machine; but it is still a server in the sense of being aware what your specific hardware setup is, and how to handle it, because the "X client" on the remote is blissfully unaware, and is only there to translate what your "X server" reports to it into meaningful state changes on the remote host. Client/Server is not an atomic concept in computing. You can be both depending on how you are looking at the system. It's a bit like a duck-rabbit. Is it complicated? Yes. Why? Because something that powerful is pretty much guaranteed to be so, and because we try to apply terminology that is generally used in a much more straightforward manner elsewhere to a system that taken as a whole adopts a bidirectional client/server relationship with regards to different subsets of the functionality that the software is intended to enable; namely, to allow graphical interfaces to be utilized between machines with wildly different characteristics, without burdening the "source" machine (the remote machine) with the responsibility of driving our (the local machine's) hardware. Again, There is nothing wrong with the approach except that yes, at first blush, it feels unpleasant to wrap your head around terminology-wise because the conventional way the terms are used exists in both directions in the same software. I don't expect most to grok X the first time. You just have to dig in and get uncomfortably familiar with the hell that is the rat's nest of abstractions that makes remote graphical computing possible.

kabdib 7y ago

I was in a used bookstore a few years ago, and ran across a book titled something like "User Interface Design with MOTIF". Well, it had been a power of years since I last touched X-Windows (with intent to draw pixels, anyway) and I started leafing through it. Looking for user interface examples. Leaf, leaf, nothing. Flip, flip, flipflipflip . . . oh, we're at the index. Nothing. Over 300 pages and no pictures. Zero diagrams. No user interface principles or discussion about good or bad practices. It was all descriptions of APIs. There was nothing about user interface design in there at all. IMHO, that's all you really need to know about X-Windows.

pengaru 7y ago
> IMHO, that's all you really need to know about X-Windows. That there was at least one poor, misleadingly titled book about MOTIF? I've had many X-related textbooks over the years, and frankly the documentation was exceptionally good and felt like a total waste on something as byzantine as X.
- anthk 7y ago
  OpenBSD has one book about Motif in in the books sectin of ports. book/vol6a I think.
pjmlp 7y ago
Steve Jobs had a couple of interesting remarks regarding UNIX's culture lack of understanding of UI/UX. The only exceptions are NeWS and NeXTSTEP (OS X derived from it anyway). Everything else are just clones of other desktop OS, with GNOME and KDE trying as good as they can, while dealing with such clunky stack.
- DonHopkins 7y ago
  (An excerpt from another longer reply I just posted): From: npg@East (Neil Groundwater - Sun Consulting) Date: Wed, Jun 27, 1990 Subject: Humor from Dennis Ritchie (at USENIX) (Actually Dennis's latter remark was attributed by him to Rob Pike) from Unix Today 6/25 page 5. "..., Richie reminded the audience that Steve Jobs stood at the same podium a few years back and announced that X was brain-dead and would soon die. "He was half-right," Ritchie said. "Sometimes when you fill a vacuum, it still sucks." http://www.anvari.org/fortune/Miscellaneous_Collections/133229_in-his-90-usenix-presentation-dennis-ritchie-reminded-the-audience-that-steve-jobs-stood-at-the-same-podium-a-few-years-back-and-announced-that-x-windows-was-brain-dead-and-would-soon-die.html http://www.anvari.org/fortune/Miscellaneous_Collections/1332...

pjmlp 7y ago

> X-Windows started out as one man's project in an office on the fifth floor of MIT's Laboratory for Computer Science. A wizardly hacker, who was familiar with W, a window system written at Stanford University as part of the V project, decided to write a distributed graphical display server. An overview of how this came to be: "A Political History of X" - Keith Packard (LCA 2020) https://www.youtube.com/watch?v=cj02_UeUnGQ https://www.youtube.com/watch?v=cj02_UeUnGQ

phosphophyllite 7y ago

> I have a "window system" on my unix box. You see, in the unix world, "system" means "a bunch of unrelated programs." ... and this is still true after almost 30 years!

DonHopkins 7y ago

Bill Joy referred to X-Windows as "Rasterop on Wheels". I gave a NeWS/Pie Menus/HyperTies/Emacs demo to Steve Jobs once, on the trade show floor at the Educom conference, right after he finally released the NeXT Machine, in November of 1988. Sun was letting me demo NeWS and the stuff we were developing at the UMD Human Computer Interaction Lab on a workstation at their booth, and NeXT's booth was right across the aisle, so Ben Shneiderman rope-a-doped him and dragged him over for a demo. He jumped up and down and yelled "That sucks! That sucks! Wow, that's neat. That sucks!" I figure a 3:1 sucks:neat ratio was pretty good for him comparing something different than his newborn baby NeXT Step, which critics had taken to calling NeVR Step, since it had been vaporware for so long until then. When I tried to explain to him how flexible NeWS was, he told me "I don't need flexibility -- I got my window system right the first time!" Here's Ben's account (I love how he gently put it that "Jobs had little patience with the academic side of things" -- and by "engage" he meant "jump up and down and yell"): Date: Tue, 1 Nov 88 07:55:48 EST From: Ben Shneiderman <ben@mimsy.umd.edu> To: hcil@tove.umd.edu Subject: steve jobs visit I just couldn't resist telling this story.... On Tuesday I was at the EDUCOM conference in DC and Steve Jobs was showing NeXT...I was quite impressed...a nice step forward, improving, refining and developing good ideas. I invited him to see our Hyperties SUN version that we were showing at the SUN booth. The gang managed to get the new NeWS version working and the Space Telescope looked great...Jobs spent about a half hour with us going from positive comments such as "Great!" to "That sucks"...he had a terrific sensitivity to the user interface issues and could articulate his reasons wonderfully. On Wednesday he came out to the lab and spent time looking at a few more of our demos...the students (and me too) were delighted to have him as a visitor. What impresses me is that he took his ideas and really put them to work... pushing back the frontier a bit further. His system really works and has much attractive in the hardware and software domains. Jobs had little patience with the academic side of things, but was very ready to engage over interface issues. Do check out NeXT...there are things to criticize, but I did come away more impressed and pleased than ready to pick at the flaws. -- Ben Here's some old email from the Sun internal NeWS mailing list I saved: From: npg@East (Neil Groundwater - Sun Consulting) Date: Wed, Jun 27, 1990 Subject: Humor from Dennis Ritchie (at USENIX) (Actually Dennis's latter remark was attributed by him to Rob Pike) from Unix Today 6/25 page 5. "..., Richie reminded the audience that Steve Jobs stood at the same podium a few years back and announced that X was brain-dead and would soon die. "He was half-right," Ritchie said. "Sometimes when you fill a vacuum, it still sucks." http://www.anvari.org/fortune/Miscellaneous_Collections/133229_in-his-90-usenix-presentation-dennis-ritchie-reminded-the-audience-that-steve-jobs-stood-at-the-same-podium-a-few-years-back-and-announced-that-x-windows-was-brain-dead-and-would-soon-die.html http://www.anvari.org/fortune/Miscellaneous_Collections/1332...

AzzieElbab 7y ago

Yeah sure, having CAD display on a PC with x11 server hooked to a Unix workstation with dialup is a complete disaster and total waste of resources when compared to uber apps of today like slack

jeffrallen 7y ago

Companion website to the Unix Hater's Handbook: https://web.archive.org/web/19981202041010/http://catalog.com/hopkins/unix-haters/handbook.html https://web.archive.org/web/19981202041010/http://catalog.co...