13 ms·

X: The First Fully Modular Software Disaster

206 points by handpickednames 9y ago

amelius 9y ago
I love Unix, but I have to admit there is some truth to this article.
sidlls 9y ago
"Self abuse kit" is such an appropriate way to describe Motif.
- sevensor 9y ago
  I haven't used Motif in almost 20 years, and I don't think I've seen more than a handful of Motif widgets in the last 10 years, but I still can't get over how incredibly ugly and hard to use Motif was. People actually paid money for Motif!
  - gpjt 9y ago
    OTOH every time I use CSS to try to lay something out in a manner that can handle different window sizes, I think nostalgically of the Motif Form widget.
  - rjsw 9y ago
    I'm running mwm on my desktop machine now and I build emacs against Motif too.
    - agumonkey 9y ago
      tru master. Send a screenshot please, I like motif.
      - DonHopkins 9y ago
        I don't have a running one on me, but here is an actual screen snapshot from 1990 or so, showing what happens when you resize XCalc again and again, as the layout rounding errors build up in the bounding boxes of the X Toolkit widgets used for the buttons. And Motif is based on that very same code. http://www.art.net/studios/hackers/hopkins/Don/unix-haters/x-windows/XCalc.gif http://www.art.net/studios/hackers/hopkins/Don/unix-haters/x... At one point I got frustrated and hacked the window manager (probably piewm) so I could pass it a command line parameter telling it the window ID on which to run instead of the root framebuffer, and then I ran it on the XCalc window, so I got window frames around all the buttons and could pop up menus on them, move them back to where they belonged, resize them, iconify them, etc. Yay ICCCM! How powerful! It was totally worth ICCM being that complicated and pushing all that complexity into every other toolkit and application, just in order to make that trick possible just once. http://www.freshports.org/x11-wm/piewm/ http://www.freshports.org/x11-wm/piewm/
        agumonkey 9y ago
        Ha, I didn't even read your nick, how unsurprising :) you know what, I love http://www.crynwr.com/piewm/ http://www.crynwr.com/piewm/ screens a lot. I'm deep into a retro 8bit mindset these days. Very fitting. Alas I never had to write code for it, but I like the idea and look.
        DonHopkins 9y ago
        Some people like to configure it to not have any frames at all, and operate it with pie menus bound to alt/command keys (which if you mouse ahead through quickly, they will not appear on the screen), rendering the window manager practically invisible. Here's a version of the original X10 "uwm" window manager from which "piewm" is a distant descendent (pre-ICCCM, for X10, not X11), that I hacked to implement my original version of pie menus, and then integrated with FORTH, so you could program the window manager in FORTH (foreshadowing programming NeWS in PostScript), and even fork off light weight FORTH tasks to bounce the windows around! http://www.donhopkins.com/home/archive/piemenu/uwm1/ http://www.donhopkins.com/home/archive/piemenu/uwm1/ http://www.donhopkins.com/home/archive/piemenu/uwm1/fuwm-main.f http://www.donhopkins.com/home/archive/piemenu/uwm1/fuwm-mai... Here's the bouncy window code, including some reverse polish notation 68k assembler code for 256/ and 256*: http://www.donhopkins.com/home/archive/piemenu/uwm1/hacks.f http://www.donhopkins.com/home/archive/piemenu/uwm1/hacks.f
      - sevensor 9y ago
        Different strokes for different folks, I guess. Personally I'd rather use twm. I like the flat-looking widgets better.
- kabdib 9y ago
  A few years ago I found a book on Motif user interface programming in a used bookstore, and started leafing through it. The entire book had exactly ONE picture. ONE. And it was some architectural diagram describing X, depicting a network of terminals and servers and happy little cloud things. The rest of the book (asymptotically, all of the book) described APIs and widgets and protocols and whatnot, all without the benefit of showing what the user would be interacting with. That someone could write a book on UI programming and someone else would publish a book on UI programming without any actual depictions of UI is pretty much all I need to know about X and its community (although I know a lot more, and my actual exposure to X goes back to early versions that came on 9-track tapes directly from MIT and supported mostly just frame buffers on DEC Vaxen). (For years -- and this may still be true -- the software to manage the equipment in Comcast's head end datacenters was controlled by some X-based UI. Now, I ain't gonna say "Them folks surely deserve it, because they done me wrong" but that miserable train-wreck of a system goes a long way towards explaining why it's often hard for Comcast to fix their stuff. I have un-fond memories of taking down whole QAMs because I was fool enough to click some check boxes in a dialog in the wrong order...) You can write hideous UI in just about anything, but X seems to have a special place in the ecosystem.
  - DonHopkins 9y ago
    It's because Motif is so ugly, they were embarrassed to include a screen snapshot. Then TCL/Tk came along and emulated Motif's look and feel, only better because its default color was bisque. "Bisque is Beautiful" http://www.ucolick.org/~de/Tcl/pictures/ http://www.ucolick.org/~de/Tcl/pictures/ "The procedure tk_bisque is provided for backward compatibility: it restores the application's colors to the light brown (“bisque”) color scheme used in Tk 3.6 and earlier versions." https://www.tcl.tk/man/tcl/TkCmd/palette.htm https://www.tcl.tk/man/tcl/TkCmd/palette.htm http://mars.cs.utu.fi/BioInfer/files/doc/public/Tkinter.Misc-class.html#tk_bisque http://mars.cs.utu.fi/BioInfer/files/doc/public/Tkinter.Misc...
  - grayarea 9y ago
    Are you referring to the Motif programming manual(there are few motif programming books so I am assuming you are). If so that was a mutli volume effort with books devoted to particular subjects(ie the API would be one of them).
- swiley 9y ago
  I far prefer Motif to Gnome. It's much lighter, I think it's much nicer looking (Gnome's default theme is really really ugly IMO, Motif feels well defined and simple.) and seems to have far fewer dependancies. I've written software that uses both and I don't remember thinking that one was significantly easier than the other, I did dislike that they took control of the main loop, Plan9's method of synchronous event polling is much nicer IMO.
  - mathw 9y ago
    GNOME isn't a toolkit, it's a full desktop environment. The toolkit is GTK+. And yeah it is heavier than Motif. It does a lot more with it, though. Whether you think those things are valuable or not presumably depends on what software you use and your own sense of aesthetics. Also when GTK+ was created, Motif was proprietary. There was Lesstif, but if I recall correctly that wasn't all that good, so there was a good incentive to develop a Free Software GUI toolkit.
maxxxxx 9y ago
I am not sure if the whole idea is considered bad or the way it has been implemented. In general I think X is very useful.
jdalgetty 9y ago
To me this is always what made linux fun.
ethbro 9y ago
I'd say that X is the foremost example of actual software evolution. In the sense that (in the words of my pathologist father when I asked him how hard drug discovery and design was), "Nature is lazy before it's intelligent. At every turn, it would rather reuse a system designed for a completely different purpose than design something new from the ground up. Which is how we end up with single pathways affecting six completely unrelated systems in the body."
- krylon 9y ago
  > Nature is lazy before it's intelligent. At every turn, it would rather reuse a system designed for a completely different purpose than design something new from the ground up. So we can blame all the crazy things we do with computers and software on nature? ;-) But seriously, that is a great insight. Both where evolution is concerned, and software development. (And other branches of engineering, too, I bet.)
zitterbewegung 9y ago
Reading this reminds me of people complaining about Electron for desktop apps.
pjc50 9y ago
Ah, this is entertaining to contrast with https://news.ycombinator.com/item?id=15031814 https://news.ycombinator.com/item?id=15031814 "Why did software go off the rails". The "UNIX haters handbook" is extremely old, as if you couldn't tell from the references to Reagan and the 50-MIPS workstation (roughly equivalent to a $1 Cortex-M0 in today's money). And in many ways they're not wrong: - "X has defeated us by switching the meaning of client and server" - "most computers running X run just four programs: xterm, xload, xclock, and a window manager" : the intervening 20 years have added a web browser. Almost all software run by the user is in either the xterm or the browser. - ICCCM is hilariously complicated, although cut-and-paste largely works now. It's just that there are two different cut-and-paste mechanisms in play. - client/server division of labour is still being fought over on the web - X authentication is painful to do with the original mechanism, but was eventually fixed by ssh X forwarding - Xdefaults is a great mystery, largely obsoleted by the GNOME people with their own mysterious pseudo-registries and, god help you, polkit - X still has trouble with the wide variety of graphics hardware out there, although you can usually get 2 monitors working eventually. - "NeWS an d NEXTSTEP were political failures because they suffer from the same two problems: oBNoXiOuS capitalization, and Amiga Persecution Attitude(TM)." : basically true, until they dropped the attitude and capitals and became Cocoa.
- krylon 9y ago
  > - "X has defeated us by switching the meaning of client and server" If you think in terms of network programming, "server" is the program that accepts incoming connections and handles requests from clients, and "client" is the program that initiates the connection and sends requests, it is not confusing at all. The security part is true, though. X authentication sucks, and using ssh might make that usable (plus, encryption), but that is kind of like saying that eMail is not a secure communication channel, but PGP solved that. But there is no alternative that solves the problems with X while keeping or improving upon its strengths (that I know of, I should add): The "mechanism not policy" part is the reason it is possible to choose from several desktop environments. Also, X has achieved something that no other current windowing environment can do: Transparent, cross-platform windowing. There are X servers available for all the free Unices, macOS, Windows, and once upon a time, I am told, for OpenVMS, too.
2sk21 9y ago
One of the amazing things about X was how easy it was to snoop on others. There was one prof at my university who appeared to be working long hours until a grad student came up with the idea of dumping out the prof's frame buffer - and it turned out he was playing Tetris! Default settings were very permissive...
- sevensor 9y ago
  The engineering workstation lab at my alma mater had very permissive settings. When it got late and the students got tired, they would pop up xclock on other people's workstations. There was a lab rule aginst doing anything devious, and I don't recall it ever being violated. I'm sure those Suns are long gone now, and the relaxed policy with them.
- teddyh 9y ago
  Dumping the frame buffer has nothing to do with X; you can’t blame X for bad permissions on the underlying device node in Unix. X didn’t create the device node, and is therefore not responsible for the permissions on it.
  - emmelaich 9y ago
    Maybe the GP means the DISPLAY? People couldn't be bothered using xauth and even just had xhost + (allow anyone). When we got internet connectivity at Sydney University we used to just dump X-Windows from all over the world. One in particular was some displays in Sweden. Forget what was actually on them though.
    - buckminster 9y ago
      It worked the other way round too. You could overwrite the screen buffer of anyone on the network. Usually with something offensive. Sun even provided a command to do it. This was hilarious in 1989.
    - 2sk21 9y ago
      You are right - I did mean display not frame buffer :-) Exactly as you say, most people used to run with "host +" at my university.
fergie 9y ago
You can still use X to run a local GUI hooked up to a remote machine, and 15 years ago that was pure voodoo magic.
- jandrese 9y ago
  Even today that's not exactly a common feature. Usually you need to start a full desktop (RDP, VNC, etc...) to do anything similar. I still use X display forwarding regularly. Often for something like sending a Firefox window back so I can look at a page on a test network without needing a direct route to it.
  - tatersolid 9y ago
    RDP has supported running single apps remotely for a decade. Windows Server 2008 had this feature.
- stordoff 9y ago
  That still felt like magic every time I did at university. Popping up a local UI on my Windows machine for something running on the computer lab's Linux machines was good stuff.
kronos29296 9y ago
So this means we really need Wayland. Hope that somebody puts a EOL like Flash on X. Only then will all those projects move to Wayland. Even Python 2 to 3 took well over a decade and we still haven't reached EOL.
- nly 9y ago
  I dunno... modern X (XCB) doesn't seem so different to Wayland. Both are asynchronous RPC protocols with bindings generated from a bunch of XML specs. Both use shared memory aggressively. Both share a lot of concepts. X just has more back-compat to deal with.
  - nhaehnle 9y ago
    People over-emphasize a lot of the problems X has. A lot of the real original problems like high latency were evolved away. And while backwards compatibility can be annoying, that's just what you get for trying to do serious software engineering. So I agree with you that the differences between X and Wayland are greatly exaggerated. However, there is one significant architectural difference between X and Wayland that is quite difficult to evolve away. In modern X, there are actually three processes involved: the client (app), the X server, and the compositor. In Wayland, there are only two: the client (app) and the compositor. The X design is more fragile (state managed in 3 places instead of 2) hence ICCCM, and has more latency and overhead. However, it made a lot of sense back when the X server talked to the hardware directly and therefore needed both an integrated driver and special privileges. It'd be silly to implement drivers as part of compositors, so the separation of mechanism and policy was the right way to go back then. Since then, however, the mechanism has basically entirely moved into the kernel (DRM/KMS) and Mesa (OpenGL). This happened in bits and pieces first with the evolution of the DRI protocol and then the jump to kernel mode setting. That is the evolutionary development which lead to the move to Wayland makeing sense. I suppose this 3-to-2-process transition could have been evolved by refactoring the core of the X server source (the whole protocol handling etc.) into a library that compositors then simply link against. But that would have been a truly herculean task with not very many natural intermediate steps. Implementing something like Wayland from scratch on the modern Linux graphics stack is actually much less work -- except perhaps for transitioning all the toolkits, but then again, the X server source lends itself fairly well to writing various "X-on-something-else" servers, since people have been doing that for a while, so there's a natural if slightly awkward solution for backwards compatibility. So hacking up an initial prototype for Wayland could be done very quickly, but note that actual adoption still took a long time. But the point is that the Wayland path had more presentable intermediate steps (unlike the X server refactor), so that's the path that software evolution took. (Man, this got a lot longer than originally intended...)
bonyt 9y ago
> X has had its share of $5,000 toilet seats -- like Sun's Open Look clock tool, which gobbles up 1.4 megabytes of real memory! If you sacrificed all the RAM from 22 Commodore 64s to clock tool, it still wouldn't have enough to tell you the time. Even the vanilla X11R4 "xclock" utility consumed 656K to run. And X's memory usage is increasing. I just opened up "clocktab.com" on Chrome, the first simple clock I could find by googling "clock," and Chrome's task manager shows it using a full 42 megabytes of memory.
- agumonkey 9y ago
  Found a pocket calculator / timer in a drawer the other day. That thing is probably not even measured in kB. And also run with 4 thumbnail size solar tiles.
  - dom0 9y ago
    Yes, these are hard-wired logic and just a handful of bytes for two to four registers (at least input and accumulator registers, everything in BCD). Only more advanced calculators use floating point.
    - exikyut 9y ago
      I've been interested in how 4-function calculators and cheap clocks work for a while. Most of the implementational details would appear to be buried in files on engineering workstations at Chinese factories. I found a calculator teardown at http://electronupdate.blogspot.com.au/2016/08/reverse-engineering-simple-four.html http://electronupdate.blogspot.com.au/2016/08/reverse-engine... a while ago. The author says it's very old but doesn't provide a ballpark (eg, 1990, 1995, 1998, 2003, etc). It does look quite hairy (and possibly not particularly compactly designed?). I would guess there's a ridiculously simple ALU somewhere in there, but I wonder what else is involved in the specific context of a high-production-volume fixed-functionality design. I hope to find something similar for a clock at some point.
- chillingeffect 9y ago
  My friend complained when I got my Amiga. He said, "When you put a disk in the drive, it takes up 10K!" I needed space on my phone the other day so I deleted the flashlight app, which turns an LED on and off, recovering 79 megabytes.
avolcano 9y ago
Uh, as a frontend developer, I am kind of _shocked_ I've never read this before. There's a lot of fascinating parallels to modern web development. zitterbewegung noted the similarity to complaints about Electron apps' memory consumption, for example, but: > 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. Certainly sounds a heck of a lot like how web applications work (even though we're currently terrible at sharing libraries, heh). > X gave programmers a way to display windows and pixels, but it didn't speak to buttons, menus, scroll bars, or any of the other necessary elements of a graphical user interface. Programmers invented their own. Soon the Unix community had six or so different interface standards. Now _that's_ certainly familiar. Sure, the DOM is a heck of a lot closer to a platform for displaying complex UIs than X was, but it still falls so far short of what developers need that a plethora of frameworks, UI libraries, etc. have appeared and fragmented the community. You could also stretch a bit and say things like Google's work on web components are an attempt at a Motif-like standardization around one questionable standard, but I don't know if I'm quite cynical enough to make that jump. > Even if you can get an X program to compile, there's no guarantee it'll work with your server. If an application requires an X extension that your server doesn't provide, then it fails. X applications can't extend the server themselves -- the extension has to be compiled and linked into the server. While a lot of new browser features are polyfillable, a lot of the more advanced ones (e.g. service workers) are not, and users and developers are at the mercy of their browsers, much users would be with their X servers. > Myth: X is "Device Independent" The quirks discussed in this section apply to responsive web apps too. There's actually quite a bit of nuance in making fancy canvas, WebGL, or CSS transforms that look good on retina screens, etc. I'm sure none of these comparisons truly map 1:1 to X development (having never done it myself), but damn if it doesn't remind me how cyclical software development has been over the past few decades. Not that that's a bad thing, just that some things are very, very hard :)
- DonHopkins 9y ago
  >Certainly sounds a heck of a lot like how web applications work (even though we're currently terrible at sharing libraries, heh). 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. https://en.wikipedia.org/wiki/NeWS https://en.wikipedia.org/wiki/NeWS
PLenz 9y ago
Excerpted from Eric S. Raymond's The Unix Hater’s Handbook, Reconsidered (2008)[http://esr.ibiblio.org/?p=538 http://esr.ibiblio.org/?p=538]: This chapter begins unfortunately, with complaints about X’s performance and memory usage that seem rather quaint when comparing it to the applications of 14 years later. It continues with a fling at the sparseness of X applications circa 1990 which is unintentionally funny when read from within evince on a Linux desktop also hosting the Emacs instance I’m writing in, a toolbar with about a dozen applets on it, and a Web browser. I judge that the authors’ rejection of mechanism/policy separation as a guiding principle of X was foundationally mistaken. I argued in The Art of Unix Programming that this principle gives X an ability to adapt to new technologies and new thinking about UI that no competitor has ever matched. I still think that’s true. But not all the feces flung in this chapter is misdirected; Motif really did suck pretty badly, it’s a good thing it’s dead. ICCCM is about as horrible as the authors describe, but that’s hard to notice these days because modern toolkits and window managers do a pretty good job of hiding the ugliness from applications. Though it’s not explicitly credited, I’m fairly sure most of this chapter was written by Don Hopkins. Don is a wizard hacker and a good man who got caught on the wrong side of history, investing a lot of effort in Sun’s NeWS just before it got steamrollered by X, and this chapter is best read as the same bitter lament for NeWS I heard from him face to face in the late 1980s. Don may have been right, architecturally speaking. But X did not win by accident; it clobbered NeWS essentially because it was open source while NeWS was not. In the 20 years after 1987 that meant enough people put in enough work that X got un-broken, notably when Keith Packard came back after 2001 and completely rewrote the rendering core. The nasty resources system is pretty much bypassed by modern toolkits. X-extension hell and the device portability problems the authors were so aggrieved by turned out to be a temporary phenomenon while people were still working on understanding the 2D-graphics problem space. That having been said, Olin Shivers’s rant about xauth is still pretty funny and I’m glad I haven’t had to use it in years.
DonHopkins 9y ago
Oh please don't bring up Eric S Raymond's name so soon after the nation is trying to recover from Nazis and White Supremacists marching and murdering in Charlottesville. Eric S Raymond has a long sordid track record of racism and climate change denial. http://rationalwiki.org/wiki/Eric_S._Raymond http://rationalwiki.org/wiki/Eric_S._Raymond An archetypical example is his mean spirited name-calling defense of Russell Nelson, who was acting as President of the Open Source Initiative, a position that Raymond had just been kicked out of because his divisive in-fighting and life-long jihad against Richard Stallman was embarrassing them and damaging their reputation -- Russell was his replacement: OOPS! After having been appointed President, Russell Nelson posted a blog entry entitled "Blacks are lazy", which of COURSE drew a lot of criticism, because it was obvious race baiting, and riddled with logical fallacies and racist bigoted presumptions. Russell expressed that it was "poor writing" and withdrew the blog posting, and resigned his position as President of the Open Source Initiative. The original blog posting can be seen in the comments section of his wikipedia page, so you can draw your own conclusions: https://en.wikipedia.org/wiki/Talk:Russ_Nelson#Blacks_are_lazy https://en.wikipedia.org/wiki/Talk:Russ_Nelson#Blacks_are_la... Russell agreed with his critics that his blog posting was wrong -- although as to HOW wrong, he still disagrees with most critics, and he's generalized his argument to "everyone is lazy" and has characterized the criticism of him as "slander": http://blog.russnelson.com/economics/blacks-are-lazy.html http://blog.russnelson.com/economics/blacks-are-lazy.html So, now that I've explained the background, I will demonstrate what I mean by how Eric Raymond typically constructs his arguments to support his political agenda, by ignoring valid criticism and turning it around on the critic by calling people names: Even though Russell agreed the article was badly written, took it down, and voluntarily resigned, Eric demanded that OSI not only SUPPORT Russell, but waste their precious money, time, energy and reputation FIGHTING a BATTLE based on his own extreme right-wing libertarian "principles" against Russell's critics (who he called "FOOLS" and "THUGS"), which had NOTHING at all to do with open source software: http://www.eweek.com/c/a/Linux-and-Open-Source/New-OSI-President-Steps-Down/#sthash.EJtgGdxJ.dpuf http://www.eweek.com/c/a/Linux-and-Open-Source/New-OSI-Presi... “The people who knew Russ as a Quaker, a pacifist and a gentleman, and no racist, but nevertheless pressured OSI to do the responsible thing and fire him in order to avoid political damage should be equally ashamed,” Raymond said. “Abetting somebody elses witch hunt is no less disgusting than starting your own.” "Personally, I wanted to fight this on principle," Raymond said. "Russ resigned the presidency rather than get OSI into that fight, and the board quite properly respected his wishes in the matter. That sacrifice makes me angrier at the fools and thugs who pulled him down." Since both Eric Raymond and Russell Nelson lost their leadership positions as President of the Open Source Initiative because of their bigoted, racist, divisive and very public beliefs, you can guess which side of the Brendan Eich controversy they came down on: "My first thought on hearing of the resignation of Brendan Eich as CEO of Mozilla: Congratulations, gay activists. You have become the bullies you hate." -Eric Raymond
gozur88 9y ago
I liked xwindows very much. Still do. What other system allows you to use your local window manager to control windows from multiple different machines?
- pjmlp 9y ago
  RDP does.
  - Zardoz84 9y ago
    Its'n the same. With RDP, you are sharing a whole desktop. With X protocol, you can share WINDOWS! You not need to run the whole windows manager/desktop on the remote machine. You can simply launch the X11 application and allow the local client to manage the windows. It's far more efficient and far more responsive (if is compressed and cached like does NX). I remember connecting to my desktop from a computer on the university using NX protocol and running remote apps like was on local. And I don't had a superb internet connexion.
    - wbkang 9y ago
      Quick note, RDP has extensions to forward just the app. It has been able to do that for a while.
    - pjmlp 9y ago
      My first UNIX was Xenix and I used quite a few variants since then including doing X programming, I know how X works. It is called RemoteApp on Terminal Services and exists since 2008. https://technet.microsoft.com/en-us/library/cc753844(WS.10).aspx/dd401668(v=vs.85).aspx https://technet.microsoft.com/en-us/library/cc753844(WS.10)....
    - Tsiklon 9y ago
      I remember when I first did that with a unix machine, immediately my perspective on desktop computing changed. i thought it was witchcraft.
paol 9y ago
The Unix Haters Handbook is pretty interesting reading, but I remember that the chapter on X was one of the weakest. It doesn't help that it starts with the hoary old myth that X named the 'server' and 'client' backwards. More relevant however is that from the vantage point of 2017, it becomes clear that X is one of the most unreasonably successful software architectures of all time. Think about it: how many pieces of software design have remained in heavy use worldwide for 30 years. The fact that no one bothered to replace it in all that time is proof enough that whatever warts it has can't be that painful. (Now, finally, it seems like it's going to happen with Wayland, but it's not there yet.) Not only that, but computer display technology has changed massively over X's lifetime. I'm writing this in a composited window manager hardware accelerated via natively-3D hardware outputting to multiple monitors of different resolutions over as many different digital display links. How much of this was even imagined in the 1980s? Yet the X protocol via it's extension mechanisms has proven adaptable enough to take in massive changes in the technology, and still keeps on ticking.
- swiley 9y ago
  People hate on X quite a lot. I'm not even too fond of it personally. But it runs on /everything/ it's lighter than most display frameworks and it's very easy to program for. And to your point, there isn't a single display framework as old as it is that's still used. > I'm writing this in a composited window manager hardware accelerated via natively-3D hardware outputting to multiple monitors of different resolutions over as many different digital display links And I'm writing this from a very underpowerd netbook with no working hardware graphics and everything still works. Try that with windows 10, wayland, coaca or whatever other display framework you like.
- fsloth 9y ago
  "how many pieces of software design have remained in heavy use worldwide for 30 years. The fact that no one bothered to replace it in all that time is proof enough that whatever warts it has can't be that painful. " I'm not convinced modern software ecosystem optimizes for quality. Many CAD packages used today have roots as old or older. The dominant CAD format (at least in construction) is DWG which - I can tell you from experience - is about as nice to work with on programmatic level as trying to skin rotten cod. The data contained in this steaming heap of obfuscation is mostly trivial in complexity. Just because we have tools in use does not mean they could not be better - it's rather that once something is in use, social proof, sunk cost fallacy and some practical reasons kick in and development stagnates to dealing with the kinks in the established system.
Cockbrand 9y ago
It's called X Window, man. Singular, not plural.
- lioeters 9y ago
  From the bottom of the page: 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.
- jwilk 9y ago
  Actually it's called "X Window System" or simply "X".
rbanffy 9y ago
Dammit... Now I want to install CDE again...
mikhailfranco 9y ago
PEX and GLX were really quite cool, and only recently matched by WebGL. Native 3D apps really could be opened remotely, then download display lists to the local store, and use local 3D rendering hardware. There just wasn't very much PEX interoperability between different manufacturers, because of all the different extensions. Only a rare vanilla app could be remoted in a heterogeneous environment. Some vendors, like E&S, had PEX as the native graphics API. You could not write a purely local app that couldn't be opened remotely, including stereo displays (CrystalEyes) and use of dialbox or spaceball input devices.
- pjmlp 9y ago
  RDP supports networked DirectX, with the GPGPU on the server or client side. And DirectX offers so much more than downgraded OpenGL ES 3.0 (aka WebGL 2.0).
jandrese 9y ago
I'm probably one of the only people who liked the .Xresources file. Sure it's a text and you do regexes to specify objects, but I found it easy to customize and because much of it was automatic there would be a ton of the UI variables in it. You want a different color on the background of a particular text box? No problem. You want to change the font used in the app? No problem. You need to customize the contents of a menu? That might be possible! Every application used the same file so you only had to figure it out once. Granted, you would leave 99% of the variables alone, but it was nice to have the option if you needed it. Interestingly enough, I still have the file on my box, although I doubt it gets used much anymore. Looking at the file I forgot how you could do a sort of primitive themeing by specifying broad wildcards like "* MenuButton.Background" and "* Toggle.Font"[1]. That's probably a bit dangerous but I can't remember it ever exploding on me spectacularly. Probably because Athena widgets were so damn minimal to begin with. Oh, man it even still has: Netscape4*blinkingEnabled: False Netscape4*myshopping.isEnabled: False [1] The spaces aren't there in the file, they're just necessary to work around the way HN's markdown does italics.
jandrese 9y ago
Ages ago when I read this article I thought they missed the one major feature that X totally flubbed. IMHO X should have exported some way to do sound along with the graphics. Sound support on Unix was a nightmare for most of the 80s and 90s and even into the 2000s. Everything was different and broken in their own special ways and some were proprietary and very few (only Sun's halfassed network audio as the exception) worked over the network. Most of the rest of the complaints come off as someone with an axe to grind, especially all of the hand-wringing over flipping the client and server model around. It's not like X was the first system to do that, active mode FTP does exactly the same thing. Back in the days before firewalls and NAT this was a legitimate design decision, they just ended up on the wrong side of history. Besides, from a network architecture standpoint it makes sense. Your local X display doesn't know that you've started an app on a remote box until something tells it. Having it make the connection out would require some local broker to inform it that it needs to make the connection. I will agree with one point, ICCCM sucks and has been overdue for a complete rework for at least 20 years now. That said, I'm not a fan of Gnome's Ctrl-Shift-C Ctrl-Shift-V workaround either.
dgfgfdagasdfgfa 9y ago
Why is configuring displays so damn difficult? It was never clear to me why there needed to be so many tools (xrandr, xorg, X, startx, xinit, xanorama) to just get a basic display working at the max resolution when other operating systems manage to have some sane plug-and-play behavior. All of this seems to render linux pretty useless for hot-pluggable displays. I'm sure ubuntu has some sort of solution (I never use the desktop version); why can't this be integrated at the level of the X server (or hell, the graphics driver) itself? Is X too firmly baked to adjust to the needs of its users? Will wayland address this?

amelius 9y ago

I love Unix, but I have to admit there is some truth to this article.

sidlls 9y ago

"Self abuse kit" is such an appropriate way to describe Motif.

sevensor 9y ago
I haven't used Motif in almost 20 years, and I don't think I've seen more than a handful of Motif widgets in the last 10 years, but I still can't get over how incredibly ugly and hard to use Motif was. People actually paid money for Motif!
- gpjt 9y ago
  OTOH every time I use CSS to try to lay something out in a manner that can handle different window sizes, I think nostalgically of the Motif Form widget.
- rjsw 9y ago
  I'm running mwm on my desktop machine now and I build emacs against Motif too.
  - agumonkey 9y ago
    tru master. Send a screenshot please, I like motif.
    - DonHopkins 9y ago
      I don't have a running one on me, but here is an actual screen snapshot from 1990 or so, showing what happens when you resize XCalc again and again, as the layout rounding errors build up in the bounding boxes of the X Toolkit widgets used for the buttons. And Motif is based on that very same code. http://www.art.net/studios/hackers/hopkins/Don/unix-haters/x-windows/XCalc.gif http://www.art.net/studios/hackers/hopkins/Don/unix-haters/x... At one point I got frustrated and hacked the window manager (probably piewm) so I could pass it a command line parameter telling it the window ID on which to run instead of the root framebuffer, and then I ran it on the XCalc window, so I got window frames around all the buttons and could pop up menus on them, move them back to where they belonged, resize them, iconify them, etc. Yay ICCCM! How powerful! It was totally worth ICCM being that complicated and pushing all that complexity into every other toolkit and application, just in order to make that trick possible just once. http://www.freshports.org/x11-wm/piewm/ http://www.freshports.org/x11-wm/piewm/
      - agumonkey 9y ago
        Ha, I didn't even read your nick, how unsurprising :) you know what, I love http://www.crynwr.com/piewm/ http://www.crynwr.com/piewm/ screens a lot. I'm deep into a retro 8bit mindset these days. Very fitting. Alas I never had to write code for it, but I like the idea and look.
        DonHopkins 9y ago
        Some people like to configure it to not have any frames at all, and operate it with pie menus bound to alt/command keys (which if you mouse ahead through quickly, they will not appear on the screen), rendering the window manager practically invisible. Here's a version of the original X10 "uwm" window manager from which "piewm" is a distant descendent (pre-ICCCM, for X10, not X11), that I hacked to implement my original version of pie menus, and then integrated with FORTH, so you could program the window manager in FORTH (foreshadowing programming NeWS in PostScript), and even fork off light weight FORTH tasks to bounce the windows around! http://www.donhopkins.com/home/archive/piemenu/uwm1/ http://www.donhopkins.com/home/archive/piemenu/uwm1/ http://www.donhopkins.com/home/archive/piemenu/uwm1/fuwm-main.f http://www.donhopkins.com/home/archive/piemenu/uwm1/fuwm-mai... Here's the bouncy window code, including some reverse polish notation 68k assembler code for 256/ and 256*: http://www.donhopkins.com/home/archive/piemenu/uwm1/hacks.f http://www.donhopkins.com/home/archive/piemenu/uwm1/hacks.f
    - sevensor 9y ago
      Different strokes for different folks, I guess. Personally I'd rather use twm. I like the flat-looking widgets better.
kabdib 9y ago
A few years ago I found a book on Motif user interface programming in a used bookstore, and started leafing through it. The entire book had exactly ONE picture. ONE. And it was some architectural diagram describing X, depicting a network of terminals and servers and happy little cloud things. The rest of the book (asymptotically, all of the book) described APIs and widgets and protocols and whatnot, all without the benefit of showing what the user would be interacting with. That someone could write a book on UI programming and someone else would publish a book on UI programming without any actual depictions of UI is pretty much all I need to know about X and its community (although I know a lot more, and my actual exposure to X goes back to early versions that came on 9-track tapes directly from MIT and supported mostly just frame buffers on DEC Vaxen). (For years -- and this may still be true -- the software to manage the equipment in Comcast's head end datacenters was controlled by some X-based UI. Now, I ain't gonna say "Them folks surely deserve it, because they done me wrong" but that miserable train-wreck of a system goes a long way towards explaining why it's often hard for Comcast to fix their stuff. I have un-fond memories of taking down whole QAMs because I was fool enough to click some check boxes in a dialog in the wrong order...) You can write hideous UI in just about anything, but X seems to have a special place in the ecosystem.
- DonHopkins 9y ago
  It's because Motif is so ugly, they were embarrassed to include a screen snapshot. Then TCL/Tk came along and emulated Motif's look and feel, only better because its default color was bisque. "Bisque is Beautiful" http://www.ucolick.org/~de/Tcl/pictures/ http://www.ucolick.org/~de/Tcl/pictures/ "The procedure tk_bisque is provided for backward compatibility: it restores the application's colors to the light brown (“bisque”) color scheme used in Tk 3.6 and earlier versions." https://www.tcl.tk/man/tcl/TkCmd/palette.htm https://www.tcl.tk/man/tcl/TkCmd/palette.htm http://mars.cs.utu.fi/BioInfer/files/doc/public/Tkinter.Misc-class.html#tk_bisque http://mars.cs.utu.fi/BioInfer/files/doc/public/Tkinter.Misc...
- grayarea 9y ago
  Are you referring to the Motif programming manual(there are few motif programming books so I am assuming you are). If so that was a mutli volume effort with books devoted to particular subjects(ie the API would be one of them).
swiley 9y ago
I far prefer Motif to Gnome. It's much lighter, I think it's much nicer looking (Gnome's default theme is really really ugly IMO, Motif feels well defined and simple.) and seems to have far fewer dependancies. I've written software that uses both and I don't remember thinking that one was significantly easier than the other, I did dislike that they took control of the main loop, Plan9's method of synchronous event polling is much nicer IMO.
- mathw 9y ago
  GNOME isn't a toolkit, it's a full desktop environment. The toolkit is GTK+. And yeah it is heavier than Motif. It does a lot more with it, though. Whether you think those things are valuable or not presumably depends on what software you use and your own sense of aesthetics. Also when GTK+ was created, Motif was proprietary. There was Lesstif, but if I recall correctly that wasn't all that good, so there was a good incentive to develop a Free Software GUI toolkit.

maxxxxx 9y ago

I am not sure if the whole idea is considered bad or the way it has been implemented. In general I think X is very useful.

jdalgetty 9y ago

To me this is always what made linux fun.

ethbro 9y ago

I'd say that X is the foremost example of actual software evolution. In the sense that (in the words of my pathologist father when I asked him how hard drug discovery and design was), "Nature is lazy before it's intelligent. At every turn, it would rather reuse a system designed for a completely different purpose than design something new from the ground up. Which is how we end up with single pathways affecting six completely unrelated systems in the body."

krylon 9y ago
> Nature is lazy before it's intelligent. At every turn, it would rather reuse a system designed for a completely different purpose than design something new from the ground up. So we can blame all the crazy things we do with computers and software on nature? ;-) But seriously, that is a great insight. Both where evolution is concerned, and software development. (And other branches of engineering, too, I bet.)

zitterbewegung 9y ago

Reading this reminds me of people complaining about Electron for desktop apps.

pjc50 9y ago

Ah, this is entertaining to contrast with https://news.ycombinator.com/item?id=15031814 https://news.ycombinator.com/item?id=15031814 "Why did software go off the rails". The "UNIX haters handbook" is extremely old, as if you couldn't tell from the references to Reagan and the 50-MIPS workstation (roughly equivalent to a $1 Cortex-M0 in today's money). And in many ways they're not wrong: - "X has defeated us by switching the meaning of client and server" - "most computers running X run just four programs: xterm, xload, xclock, and a window manager" : the intervening 20 years have added a web browser. Almost all software run by the user is in either the xterm or the browser. - ICCCM is hilariously complicated, although cut-and-paste largely works now. It's just that there are two different cut-and-paste mechanisms in play. - client/server division of labour is still being fought over on the web - X authentication is painful to do with the original mechanism, but was eventually fixed by ssh X forwarding - Xdefaults is a great mystery, largely obsoleted by the GNOME people with their own mysterious pseudo-registries and, god help you, polkit - X still has trouble with the wide variety of graphics hardware out there, although you can usually get 2 monitors working eventually. - "NeWS an d NEXTSTEP were political failures because they suffer from the same two problems: oBNoXiOuS capitalization, and Amiga Persecution Attitude(TM)." : basically true, until they dropped the attitude and capitals and became Cocoa.

krylon 9y ago
> - "X has defeated us by switching the meaning of client and server" If you think in terms of network programming, "server" is the program that accepts incoming connections and handles requests from clients, and "client" is the program that initiates the connection and sends requests, it is not confusing at all. The security part is true, though. X authentication sucks, and using ssh might make that usable (plus, encryption), but that is kind of like saying that eMail is not a secure communication channel, but PGP solved that. But there is no alternative that solves the problems with X while keeping or improving upon its strengths (that I know of, I should add): The "mechanism not policy" part is the reason it is possible to choose from several desktop environments. Also, X has achieved something that no other current windowing environment can do: Transparent, cross-platform windowing. There are X servers available for all the free Unices, macOS, Windows, and once upon a time, I am told, for OpenVMS, too.

2sk21 9y ago

One of the amazing things about X was how easy it was to snoop on others. There was one prof at my university who appeared to be working long hours until a grad student came up with the idea of dumping out the prof's frame buffer - and it turned out he was playing Tetris! Default settings were very permissive...

sevensor 9y ago
The engineering workstation lab at my alma mater had very permissive settings. When it got late and the students got tired, they would pop up xclock on other people's workstations. There was a lab rule aginst doing anything devious, and I don't recall it ever being violated. I'm sure those Suns are long gone now, and the relaxed policy with them.
teddyh 9y ago
Dumping the frame buffer has nothing to do with X; you can’t blame X for bad permissions on the underlying device node in Unix. X didn’t create the device node, and is therefore not responsible for the permissions on it.
- emmelaich 9y ago
  Maybe the GP means the DISPLAY? People couldn't be bothered using xauth and even just had xhost + (allow anyone). When we got internet connectivity at Sydney University we used to just dump X-Windows from all over the world. One in particular was some displays in Sweden. Forget what was actually on them though.
  - buckminster 9y ago
    It worked the other way round too. You could overwrite the screen buffer of anyone on the network. Usually with something offensive. Sun even provided a command to do it. This was hilarious in 1989.
  - 2sk21 9y ago
    You are right - I did mean display not frame buffer :-) Exactly as you say, most people used to run with "host +" at my university.

fergie 9y ago

You can still use X to run a local GUI hooked up to a remote machine, and 15 years ago that was pure voodoo magic.

jandrese 9y ago
Even today that's not exactly a common feature. Usually you need to start a full desktop (RDP, VNC, etc...) to do anything similar. I still use X display forwarding regularly. Often for something like sending a Firefox window back so I can look at a page on a test network without needing a direct route to it.
- tatersolid 9y ago
  RDP has supported running single apps remotely for a decade. Windows Server 2008 had this feature.
stordoff 9y ago
That still felt like magic every time I did at university. Popping up a local UI on my Windows machine for something running on the computer lab's Linux machines was good stuff.

kronos29296 9y ago

So this means we really need Wayland. Hope that somebody puts a EOL like Flash on X. Only then will all those projects move to Wayland. Even Python 2 to 3 took well over a decade and we still haven't reached EOL.

nly 9y ago
I dunno... modern X (XCB) doesn't seem so different to Wayland. Both are asynchronous RPC protocols with bindings generated from a bunch of XML specs. Both use shared memory aggressively. Both share a lot of concepts. X just has more back-compat to deal with.
- nhaehnle 9y ago
  People over-emphasize a lot of the problems X has. A lot of the real original problems like high latency were evolved away. And while backwards compatibility can be annoying, that's just what you get for trying to do serious software engineering. So I agree with you that the differences between X and Wayland are greatly exaggerated. However, there is one significant architectural difference between X and Wayland that is quite difficult to evolve away. In modern X, there are actually three processes involved: the client (app), the X server, and the compositor. In Wayland, there are only two: the client (app) and the compositor. The X design is more fragile (state managed in 3 places instead of 2) hence ICCCM, and has more latency and overhead. However, it made a lot of sense back when the X server talked to the hardware directly and therefore needed both an integrated driver and special privileges. It'd be silly to implement drivers as part of compositors, so the separation of mechanism and policy was the right way to go back then. Since then, however, the mechanism has basically entirely moved into the kernel (DRM/KMS) and Mesa (OpenGL). This happened in bits and pieces first with the evolution of the DRI protocol and then the jump to kernel mode setting. That is the evolutionary development which lead to the move to Wayland makeing sense. I suppose this 3-to-2-process transition could have been evolved by refactoring the core of the X server source (the whole protocol handling etc.) into a library that compositors then simply link against. But that would have been a truly herculean task with not very many natural intermediate steps. Implementing something like Wayland from scratch on the modern Linux graphics stack is actually much less work -- except perhaps for transitioning all the toolkits, but then again, the X server source lends itself fairly well to writing various "X-on-something-else" servers, since people have been doing that for a while, so there's a natural if slightly awkward solution for backwards compatibility. So hacking up an initial prototype for Wayland could be done very quickly, but note that actual adoption still took a long time. But the point is that the Wayland path had more presentable intermediate steps (unlike the X server refactor), so that's the path that software evolution took. (Man, this got a lot longer than originally intended...)

bonyt 9y ago

> X has had its share of $5,000 toilet seats -- like Sun's Open Look clock tool, which gobbles up 1.4 megabytes of real memory! If you sacrificed all the RAM from 22 Commodore 64s to clock tool, it still wouldn't have enough to tell you the time. Even the vanilla X11R4 "xclock" utility consumed 656K to run. And X's memory usage is increasing. I just opened up "clocktab.com" on Chrome, the first simple clock I could find by googling "clock," and Chrome's task manager shows it using a full 42 megabytes of memory.

agumonkey 9y ago
Found a pocket calculator / timer in a drawer the other day. That thing is probably not even measured in kB. And also run with 4 thumbnail size solar tiles.
- dom0 9y ago
  Yes, these are hard-wired logic and just a handful of bytes for two to four registers (at least input and accumulator registers, everything in BCD). Only more advanced calculators use floating point.
  - exikyut 9y ago
    I've been interested in how 4-function calculators and cheap clocks work for a while. Most of the implementational details would appear to be buried in files on engineering workstations at Chinese factories. I found a calculator teardown at http://electronupdate.blogspot.com.au/2016/08/reverse-engineering-simple-four.html http://electronupdate.blogspot.com.au/2016/08/reverse-engine... a while ago. The author says it's very old but doesn't provide a ballpark (eg, 1990, 1995, 1998, 2003, etc). It does look quite hairy (and possibly not particularly compactly designed?). I would guess there's a ridiculously simple ALU somewhere in there, but I wonder what else is involved in the specific context of a high-production-volume fixed-functionality design. I hope to find something similar for a clock at some point.
chillingeffect 9y ago
My friend complained when I got my Amiga. He said, "When you put a disk in the drive, it takes up 10K!" I needed space on my phone the other day so I deleted the flashlight app, which turns an LED on and off, recovering 79 megabytes.

avolcano 9y ago

Uh, as a frontend developer, I am kind of _shocked_ I've never read this before. There's a lot of fascinating parallels to modern web development. zitterbewegung noted the similarity to complaints about Electron apps' memory consumption, for example, but: > 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. Certainly sounds a heck of a lot like how web applications work (even though we're currently terrible at sharing libraries, heh). > X gave programmers a way to display windows and pixels, but it didn't speak to buttons, menus, scroll bars, or any of the other necessary elements of a graphical user interface. Programmers invented their own. Soon the Unix community had six or so different interface standards. Now _that's_ certainly familiar. Sure, the DOM is a heck of a lot closer to a platform for displaying complex UIs than X was, but it still falls so far short of what developers need that a plethora of frameworks, UI libraries, etc. have appeared and fragmented the community. You could also stretch a bit and say things like Google's work on web components are an attempt at a Motif-like standardization around one questionable standard, but I don't know if I'm quite cynical enough to make that jump. > Even if you can get an X program to compile, there's no guarantee it'll work with your server. If an application requires an X extension that your server doesn't provide, then it fails. X applications can't extend the server themselves -- the extension has to be compiled and linked into the server. While a lot of new browser features are polyfillable, a lot of the more advanced ones (e.g. service workers) are not, and users and developers are at the mercy of their browsers, much users would be with their X servers. > Myth: X is "Device Independent" The quirks discussed in this section apply to responsive web apps too. There's actually quite a bit of nuance in making fancy canvas, WebGL, or CSS transforms that look good on retina screens, etc. I'm sure none of these comparisons truly map 1:1 to X development (having never done it myself), but damn if it doesn't remind me how cyclical software development has been over the past few decades. Not that that's a bad thing, just that some things are very, very hard :)

DonHopkins 9y ago
>Certainly sounds a heck of a lot like how web applications work (even though we're currently terrible at sharing libraries, heh). 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. https://en.wikipedia.org/wiki/NeWS https://en.wikipedia.org/wiki/NeWS

PLenz 9y ago

Excerpted from Eric S. Raymond's The Unix Hater’s Handbook, Reconsidered (2008)[http://esr.ibiblio.org/?p=538 http://esr.ibiblio.org/?p=538]: This chapter begins unfortunately, with complaints about X’s performance and memory usage that seem rather quaint when comparing it to the applications of 14 years later. It continues with a fling at the sparseness of X applications circa 1990 which is unintentionally funny when read from within evince on a Linux desktop also hosting the Emacs instance I’m writing in, a toolbar with about a dozen applets on it, and a Web browser. I judge that the authors’ rejection of mechanism/policy separation as a guiding principle of X was foundationally mistaken. I argued in The Art of Unix Programming that this principle gives X an ability to adapt to new technologies and new thinking about UI that no competitor has ever matched. I still think that’s true. But not all the feces flung in this chapter is misdirected; Motif really did suck pretty badly, it’s a good thing it’s dead. ICCCM is about as horrible as the authors describe, but that’s hard to notice these days because modern toolkits and window managers do a pretty good job of hiding the ugliness from applications. Though it’s not explicitly credited, I’m fairly sure most of this chapter was written by Don Hopkins. Don is a wizard hacker and a good man who got caught on the wrong side of history, investing a lot of effort in Sun’s NeWS just before it got steamrollered by X, and this chapter is best read as the same bitter lament for NeWS I heard from him face to face in the late 1980s. Don may have been right, architecturally speaking. But X did not win by accident; it clobbered NeWS essentially because it was open source while NeWS was not. In the 20 years after 1987 that meant enough people put in enough work that X got un-broken, notably when Keith Packard came back after 2001 and completely rewrote the rendering core. The nasty resources system is pretty much bypassed by modern toolkits. X-extension hell and the device portability problems the authors were so aggrieved by turned out to be a temporary phenomenon while people were still working on understanding the 2D-graphics problem space. That having been said, Olin Shivers’s rant about xauth is still pretty funny and I’m glad I haven’t had to use it in years.

DonHopkins 9y ago

Oh please don't bring up Eric S Raymond's name so soon after the nation is trying to recover from Nazis and White Supremacists marching and murdering in Charlottesville. Eric S Raymond has a long sordid track record of racism and climate change denial. http://rationalwiki.org/wiki/Eric_S._Raymond http://rationalwiki.org/wiki/Eric_S._Raymond An archetypical example is his mean spirited name-calling defense of Russell Nelson, who was acting as President of the Open Source Initiative, a position that Raymond had just been kicked out of because his divisive in-fighting and life-long jihad against Richard Stallman was embarrassing them and damaging their reputation -- Russell was his replacement: OOPS! After having been appointed President, Russell Nelson posted a blog entry entitled "Blacks are lazy", which of COURSE drew a lot of criticism, because it was obvious race baiting, and riddled with logical fallacies and racist bigoted presumptions. Russell expressed that it was "poor writing" and withdrew the blog posting, and resigned his position as President of the Open Source Initiative. The original blog posting can be seen in the comments section of his wikipedia page, so you can draw your own conclusions: https://en.wikipedia.org/wiki/Talk:Russ_Nelson#Blacks_are_lazy https://en.wikipedia.org/wiki/Talk:Russ_Nelson#Blacks_are_la... Russell agreed with his critics that his blog posting was wrong -- although as to HOW wrong, he still disagrees with most critics, and he's generalized his argument to "everyone is lazy" and has characterized the criticism of him as "slander": http://blog.russnelson.com/economics/blacks-are-lazy.html http://blog.russnelson.com/economics/blacks-are-lazy.html So, now that I've explained the background, I will demonstrate what I mean by how Eric Raymond typically constructs his arguments to support his political agenda, by ignoring valid criticism and turning it around on the critic by calling people names: Even though Russell agreed the article was badly written, took it down, and voluntarily resigned, Eric demanded that OSI not only SUPPORT Russell, but waste their precious money, time, energy and reputation FIGHTING a BATTLE based on his own extreme right-wing libertarian "principles" against Russell's critics (who he called "FOOLS" and "THUGS"), which had NOTHING at all to do with open source software: http://www.eweek.com/c/a/Linux-and-Open-Source/New-OSI-President-Steps-Down/#sthash.EJtgGdxJ.dpuf http://www.eweek.com/c/a/Linux-and-Open-Source/New-OSI-Presi... “The people who knew Russ as a Quaker, a pacifist and a gentleman, and no racist, but nevertheless pressured OSI to do the responsible thing and fire him in order to avoid political damage should be equally ashamed,” Raymond said. “Abetting somebody elses witch hunt is no less disgusting than starting your own.” "Personally, I wanted to fight this on principle," Raymond said. "Russ resigned the presidency rather than get OSI into that fight, and the board quite properly respected his wishes in the matter. That sacrifice makes me angrier at the fools and thugs who pulled him down." Since both Eric Raymond and Russell Nelson lost their leadership positions as President of the Open Source Initiative because of their bigoted, racist, divisive and very public beliefs, you can guess which side of the Brendan Eich controversy they came down on: "My first thought on hearing of the resignation of Brendan Eich as CEO of Mozilla: Congratulations, gay activists. You have become the bullies you hate." -Eric Raymond

gozur88 9y ago

I liked xwindows very much. Still do. What other system allows you to use your local window manager to control windows from multiple different machines?

pjmlp 9y ago
RDP does.
- Zardoz84 9y ago
  Its'n the same. With RDP, you are sharing a whole desktop. With X protocol, you can share WINDOWS! You not need to run the whole windows manager/desktop on the remote machine. You can simply launch the X11 application and allow the local client to manage the windows. It's far more efficient and far more responsive (if is compressed and cached like does NX). I remember connecting to my desktop from a computer on the university using NX protocol and running remote apps like was on local. And I don't had a superb internet connexion.
  - wbkang 9y ago
    Quick note, RDP has extensions to forward just the app. It has been able to do that for a while.
  - pjmlp 9y ago
    My first UNIX was Xenix and I used quite a few variants since then including doing X programming, I know how X works. It is called RemoteApp on Terminal Services and exists since 2008. https://technet.microsoft.com/en-us/library/cc753844(WS.10).aspx/dd401668(v=vs.85).aspx https://technet.microsoft.com/en-us/library/cc753844(WS.10)....
  - Tsiklon 9y ago
    I remember when I first did that with a unix machine, immediately my perspective on desktop computing changed. i thought it was witchcraft.

paol 9y ago

The Unix Haters Handbook is pretty interesting reading, but I remember that the chapter on X was one of the weakest. It doesn't help that it starts with the hoary old myth that X named the 'server' and 'client' backwards. More relevant however is that from the vantage point of 2017, it becomes clear that X is one of the most unreasonably successful software architectures of all time. Think about it: how many pieces of software design have remained in heavy use worldwide for 30 years. The fact that no one bothered to replace it in all that time is proof enough that whatever warts it has can't be that painful. (Now, finally, it seems like it's going to happen with Wayland, but it's not there yet.) Not only that, but computer display technology has changed massively over X's lifetime. I'm writing this in a composited window manager hardware accelerated via natively-3D hardware outputting to multiple monitors of different resolutions over as many different digital display links. How much of this was even imagined in the 1980s? Yet the X protocol via it's extension mechanisms has proven adaptable enough to take in massive changes in the technology, and still keeps on ticking.

swiley 9y ago
People hate on X quite a lot. I'm not even too fond of it personally. But it runs on /everything/ it's lighter than most display frameworks and it's very easy to program for. And to your point, there isn't a single display framework as old as it is that's still used. > I'm writing this in a composited window manager hardware accelerated via natively-3D hardware outputting to multiple monitors of different resolutions over as many different digital display links And I'm writing this from a very underpowerd netbook with no working hardware graphics and everything still works. Try that with windows 10, wayland, coaca or whatever other display framework you like.
fsloth 9y ago
"how many pieces of software design have remained in heavy use worldwide for 30 years. The fact that no one bothered to replace it in all that time is proof enough that whatever warts it has can't be that painful. " I'm not convinced modern software ecosystem optimizes for quality. Many CAD packages used today have roots as old or older. The dominant CAD format (at least in construction) is DWG which - I can tell you from experience - is about as nice to work with on programmatic level as trying to skin rotten cod. The data contained in this steaming heap of obfuscation is mostly trivial in complexity. Just because we have tools in use does not mean they could not be better - it's rather that once something is in use, social proof, sunk cost fallacy and some practical reasons kick in and development stagnates to dealing with the kinks in the established system.

Cockbrand 9y ago

It's called X Window, man. Singular, not plural.

lioeters 9y ago
From the bottom of the page: 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.
jwilk 9y ago
Actually it's called "X Window System" or simply "X".

rbanffy 9y ago

Dammit... Now I want to install CDE again...

mikhailfranco 9y ago

PEX and GLX were really quite cool, and only recently matched by WebGL. Native 3D apps really could be opened remotely, then download display lists to the local store, and use local 3D rendering hardware. There just wasn't very much PEX interoperability between different manufacturers, because of all the different extensions. Only a rare vanilla app could be remoted in a heterogeneous environment. Some vendors, like E&S, had PEX as the native graphics API. You could not write a purely local app that couldn't be opened remotely, including stereo displays (CrystalEyes) and use of dialbox or spaceball input devices.

pjmlp 9y ago
RDP supports networked DirectX, with the GPGPU on the server or client side. And DirectX offers so much more than downgraded OpenGL ES 3.0 (aka WebGL 2.0).

jandrese 9y ago

I'm probably one of the only people who liked the .Xresources file. Sure it's a text and you do regexes to specify objects, but I found it easy to customize and because much of it was automatic there would be a ton of the UI variables in it. You want a different color on the background of a particular text box? No problem. You want to change the font used in the app? No problem. You need to customize the contents of a menu? That might be possible! Every application used the same file so you only had to figure it out once. Granted, you would leave 99% of the variables alone, but it was nice to have the option if you needed it. Interestingly enough, I still have the file on my box, although I doubt it gets used much anymore. Looking at the file I forgot how you could do a sort of primitive themeing by specifying broad wildcards like "* MenuButton.Background" and "* Toggle.Font"[1]. That's probably a bit dangerous but I can't remember it ever exploding on me spectacularly. Probably because Athena widgets were so damn minimal to begin with. Oh, man it even still has: Netscape4*blinkingEnabled: False Netscape4*myshopping.isEnabled: False [1] The spaces aren't there in the file, they're just necessary to work around the way HN's markdown does italics.

jandrese 9y ago

Ages ago when I read this article I thought they missed the one major feature that X totally flubbed. IMHO X should have exported some way to do sound along with the graphics. Sound support on Unix was a nightmare for most of the 80s and 90s and even into the 2000s. Everything was different and broken in their own special ways and some were proprietary and very few (only Sun's halfassed network audio as the exception) worked over the network. Most of the rest of the complaints come off as someone with an axe to grind, especially all of the hand-wringing over flipping the client and server model around. It's not like X was the first system to do that, active mode FTP does exactly the same thing. Back in the days before firewalls and NAT this was a legitimate design decision, they just ended up on the wrong side of history. Besides, from a network architecture standpoint it makes sense. Your local X display doesn't know that you've started an app on a remote box until something tells it. Having it make the connection out would require some local broker to inform it that it needs to make the connection. I will agree with one point, ICCCM sucks and has been overdue for a complete rework for at least 20 years now. That said, I'm not a fan of Gnome's Ctrl-Shift-C Ctrl-Shift-V workaround either.

dgfgfdagasdfgfa 9y ago

Why is configuring displays so damn difficult? It was never clear to me why there needed to be so many tools (xrandr, xorg, X, startx, xinit, xanorama) to just get a basic display working at the max resolution when other operating systems manage to have some sane plug-and-play behavior. All of this seems to render linux pretty useless for hot-pluggable displays. I'm sure ubuntu has some sort of solution (I never use the desktop version); why can't this be integrated at the level of the X server (or hell, the graphics driver) itself? Is X too firmly baked to adjust to the needs of its users? Will wayland address this?