9 ms·

If I ever need to feel good about myself as a software developer, I only ever need to read this book's chapter about the X window system.

xyzzy123 10y ago
Yeah but try and figure out how you'd do better... efficient.ly. Over the network...
- _pmf_ 10y ago
  Yes; the chapter actually made me admire the design.
  - tdsamardzhiev 10y ago
    The whole book was like that for me. I think that's what it's all about - our love/hate relationship with Unix(-like systems).
- panic 10y ago
  The contemporary windowing system NeWS is worth a look: https://en.wikipedia.org/wiki/NeWS https://en.wikipedia.org/wiki/NeWS Its architecture was more similar to modern web apps, with the UI running code and processing events on the client machine.
  - xyzzy123 10y ago
    Ohhhhhhh good answer. One day it'll win :) Actually I think we could do NEWS in JS. Somehow I don't feel that would make you happy tho :P
    - DonHopkins 10y ago
      Does AJAX make you happy? 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.
  - reacweb 10y ago
    I remember it. It was far prettier than motif at that time. And Framemaker was so pleasant to use compared to Word. Both NeWS and NeXT were using Display Postscript (https://en.wikipedia.org/wiki/Display_PostScript https://en.wikipedia.org/wiki/Display_PostScript). Do you know if NeWS was an inspiration for NeXT ?
    - arethuza 10y ago
      Other than using PostScript for 2D rendering I don't think NeWS and Display Postscript had much in common. In NeWS you could write your client applications completely in PostScript (or something compiled down to PostScript) and it had its own object-oriented, multi-threaded environment with event handling etc. NeWS was more of a predecessor for Java than NeXT.
      - david-given 10y ago
        Here's the source code for the classic PizzaTool demo (BTW, I've just looked on Google Maps, and I think that Tony & Alba's pizza place in Mountain View no longer exists): http://donhopkins.com/home/archive/NeWS/pizzatool.txt http://donhopkins.com/home/archive/NeWS/pizzatool.txt ...and here's a link to a HN thread a few months ago where Don Hopkins talks about Postscript and windowing systems; lots of good links there: https://news.ycombinator.com/item?id=13196983 https://news.ycombinator.com/item?id=13196983
        arethuza 10y ago
        I actually worked on a project that used NeWS (actually HyperNeWS) as a front end for a Lisp based AI system written in Common Lisp. HyperNeWS could do some neat things - e.g. you could draw a shape (any shape!) in the graphical editor and paste it as the shape of a window, all without writing any code. Edit: changed "uses" to "used" - was quite a long time ago!
        DonHopkins 10y ago
        I really miss HyperNeWS [1], which I worked on with Arthur van Hoff at the Turing Institute, and I used it to port SimCity to NeWS on Unix [2]. Arthur van Hoff (who developed HyperNeWS and other stuff like Java [3]) and I are working together again, this time at his 360° VR video camera company, JauntVR [4]! I'm developing a secret project called HyperJaunt, that I can't say anything about yet, but you can guess by the name that I'm pretty excited about it! ;) We are looking for a lead software engineer with leadership experience in Amsterdam! [5] [1] http://www.art.net/~hopkins/Don/hyperlook/ http://www.art.net/~hopkins/Don/hyperlook/ [2] http://www.art.net/~hopkins/Don/hyperlook/HyperLook-SimCity.gif http://www.art.net/~hopkins/Don/hyperlook/HyperLook-SimCity.... [3] https://www.linkedin.com/in/aavanhoff https://www.linkedin.com/in/aavanhoff [4] https://www.jauntvr.com/technology/ https://www.jauntvr.com/technology/ [5] https://www.jauntvr.com/careers/apply/?gh_jid=251962 https://www.jauntvr.com/careers/apply/?gh_jid=251962 LEAD SOFTWARE ENGINEER, AMSTERDAM, NETHERLANDS. The Role: This is a highly challenging and highly technical role offering the chance to define the early days of a new industry. Candidate would have to know or be willing to learn mobile 3D graphics programming (OpenGL/GLSL/Unity) with focus on interactivity, network optimization and performance tuning. Candidate should have strong leadership skills. While we are looking for prior experience as a good indicator of future success, our main criteria includes passion for VR, intelligence, creativity and strong work ethics.
  - cmrdporcupine 10y ago
    Less important and less popular there was also MGR, which treated windowing more like a terminal session, and so was more Unix-philosophy than most. It was neat, and because of its smaller profile it got ported to a lot of systems (Atari ST, etc.) that struggled under the full X11 system http://www.hack.org/mc/mgr/ http://www.hack.org/mc/mgr/
    - gonzo 10y ago
      Uhler put MGR on the Tadpole SPARCbook. It was really cool.
      - DonHopkins 10y ago
        MGR was awesome! Not extensible, but simple and clean, and efficient over a slow connection. I once saw a great demo of it by its author, Stephen A. Uhler. For some reason, from then on, I always associate MGR with great big bushy moustaches. https://media.licdn.com/mpr/mpr/shrink_150_150/p/2/000/013/318/18c8b96.jpg https://media.licdn.com/mpr/mpr/shrink_150_150/p/2/000/013/3...
- bjourne 10y ago
  You can't do opengl efficiently over the network. At least xorg can't. Most applications uses opengl these days. For me, I've been using Linux fulltime for the last 15 years and I have never, not even once, had the need to connect to a remote X11 server. ssh has always been enough for me.
  - pmontra 10y ago
    Maybe you used Synergy to share a mouse and a keyboard over multiple machines. It's a use case that partly overlaps with running remote desktop applications on your display. Or VNC.
  - zeptomu 10y ago
    > Most applications uses opengl these days. Now 'most' is a relative term, but I do not think that's true at all. There are very few applications that use OpenGL. Obviously games are an exception, but if you count in all GUIs I would say mostly target X11 (via Gnome or KDE).
    - bjourne 10y ago
      GNOME and KDE can also use opengl for some tasks if it is available. But right, most applications doesn't directly use opengl. I believe if it weren't such a pita to integrate opengl in desktop appliations (thanks to X11's bad design), many more applications would be using it. To give you an example, think about desktop effects. On Windows, several applications such as Explorer makes parts of their windows semi-transparent. It's a nice simple effect that is impossible (without tons of hackery) to replicate using X11.
      - dfox 10y ago
        https://www.x.org/releases/current/doc/compositeproto/compositeproto.txt https://www.x.org/releases/current/doc/compositeproto/compos... I don't think that this qualifies as "tons of hackery" given the fact that other contemporary UI systems with truly transparent windows implement it in same way (IIRC in pre-Vista Windows truly transparent windows are supported on the OS level but the implementation involves hacks with backing buffer and synthesized expose events).
- DonHopkins 10y ago
  As it turns out, the web eventually came around to using NeWS's extensible client/server architecture, once they rediscovered it 20 years later and called it "Ajax". (2005 [1] - 1985 [2] = 20) [1] https://en.wikipedia.org/wiki/Ajax_(programming)#History https://en.wikipedia.org/wiki/Ajax_(programming)#History [2] http://www.chilton-computing.org.uk/inf/literature/books/wm/p005.htm http://www.chilton-computing.org.uk/inf/literature/books/wm/...
  - gonzo 10y ago
    Ha! Yello, Don. Howzit?
    - DonHopkins 10y ago
      Hi Jim! As it turns out, AJAX is immensely popular in Amsterdam, because it's the name of the local soccer team [1]. But they pronounce AJAX like "ah yax", and JavaScript like "ya va schkript"! ;) [1] http://english.ajax.nl/streams/ajax-now.htm http://english.ajax.nl/streams/ajax-now.htm
- jff 10y ago
  Plan 9 did it in an interesting way. You draw to the screen by writing to files under /dev. On Plan 9, all file operations take place over 9P, a networked file protocol. So if you are connecting to a remote machine and want to run a graphical program, you mount your local /dev/draw files on the remote end (this is actually taken care of automatically by cpu(1)) and just run the program. Its graphical functions access your local machine's /dev/draw and it all Just Works. Hard to explain but very neat when you use it.
  - mej10 10y ago
    How was it efficient?
    - jff 10y ago
      I don't have numbers but in general I'd call it no less usable than X forwarding over ssh. For a long time I used to connect to a Japanese Plan 9 server using drawterm (a Windows/Linux application which essentially emulates the /dev/draw infrastructure) and it was pretty decent considering the latency--I used it to read email, follow IRC, and write code. Over a LAN, it's so fast as to be indistinguishable from something running on your local machine.
  - DonHopkins 10y ago
    Plan 9's "everything is a file" philosophy never worked for me, because it's far too low level, and I don't believe Unix's file I/O API itself is very pleasant: open, read, write, ioctl and select (gag). I'd much rather have a real API with rich app-specific functional or event interfaces to call, and to be able to pass actual typed parameters instead just a stream of bytes, including structured data like json, s-expressions or PostScript data, or even (gasp) Turing complete programs, like PostScript code! NeFS, as defined in 1990 in the infamous NFS3 proposal aka "Network extensible File System Protocol Specification" did just that, and it was actually a great idea too early for its time. So it went over like a lead balloon, and was never actually adopted. NeFS should not have been framed as a successor to NFS, because it required a revolution in how programs interacted with the file system. And of course there are the security and stability implications of running downloaded code in the kernel, which hadn't been properly addressed. ;) Take for example (shown below) the act of copying a file to a backup file in the same directory. With traditional NFS, the server would have to send each block of the file to the client, which would then send it back to the server, which would then write it to disk. That required a lot of network traffic, as well as many context switches between user and kernel space on both the client and the server (at a time in history where they were extremely expensive). Instead, the client could just send a simple PostScript program to the server (or call one that was loaded from a library or sent previously -- see the example below), which copied the file in the kernel of the server, without sending it over the network, or requiring any context switches on either the client or server. That's several orders of magnitude more efficient in terms of both CPU and network usage, and just the simplest and easiest to explain example possible of what you could do. Just imagine how much more efficient, powerful and tightly integrated together other utilities like "find" and "grep" could be, tightly woven together procedurally in the kernel instead of communicating with a stream of bytes over a pipe! http://www.donhopkins.com/home/nfs3_0.pdf http://www.donhopkins.com/home/nfs3_0.pdf Introduction The Network Extensible File System protocol(NeFS) provides transparent remote access to shared file systems over networks. The NeFS protocol is designed to be machine, operating system, network architecture, and transport protocol independent. This document is the draft specification for the protocol. It will remain in draft form during a period of public review. Italicized comments in the document are intended to present the rationale behind elements of the design and to raise questions where there are doubts. Comments and suggestions on this draft specification are most welcome. 1.1 The Network File System The Network File System (NFS™*) has become a de facto standard distributed file system. Since it was first made generally available in 1985 it has been licensed by more than 120 companies. If the NFS protocol has been so successful why does there need to be NeFS ? Because the NFS protocol has deficiencies and limitations that become more apparent and troublesome as it grows older. 1. Size limitations. The NFS version 2 protocol limits filehandles to 32 bytes, file sizes to the magnitude of a signed 32 bit integer, timestamp accuracy to 1 second. These and other limits need to be extended to cope with current and future demands. 2. Non-idempotent procedures. A significant number of the NFS procedures are not idempotent. In certain circumstances these procedures can fail unexpectedly if retried by the client. It is not always clear how the client should recover from such a failure. 3. Unix®† bias. The NFS protocol was designed and first implemented in a Unix environment. This bias is reflected in the protocol: there is no support for record-oriented files, file versions or non-Unix file attributes. This bias must be removed if NFS is to be truly machine and operating system independent. 4. No access procedure. Numerous security problems and program anomalies are attributable to the fact that clients have no facility to ask a server whether they have permission to carry out certain operations. 5. No facility to support atomic filesystem operations. For instance the POSIX O_EXCL flag makes a requirement for exclusive file creation. This cannot be guaranteed to work via the NFS protocol without the support of an auxiliary locking service. Similarly there is no way for a client to guarantee that data written to a file is appended to the current end of the file. 6. Performance. The NFS version 2 protocol provides a fixed set of operations between client and server. While a degree of client caching can significantly reduce the amount of client-server interaction, a level of interaction is required just to maintain cache consistency and there yet remain many examples of high client-server interaction that cannot be reduced by caching. The problem becomes more acute when a client’s set of filesystem operations does not map cleanly into the set of NFS procedures. 1.2 The Network Extensible File System NeFS addresses the problems just described. Although a draft specification for a revised version of the NFS protocol has addressed many of the deficiencies of NFS version 2, it has not made non-Unix implementations easier, not does it provide opportunities for performance improvements. Indeed, the extra complexity introduced by modifications to the NFS protocol makes all implementations more difficult. A revised NFS protocol does not appear to be an attractive alternative to the existing protocol. Although it has features in common with NFS, NeFS is a radical departure from NFS. The NFS protocol is built according to a Remote Procedure Call model (RPC) where filesystem operations are mapped across the network as remote procedure calls. The NeFS protocol abandons this model in favor of an interpretive model in which the filesystem operations become operators in an interpreted language. Clients send their requests to the server as programs to be interpreted. Execution of the request by the server’s interpreter results in the filesystem operations being invoked and results returned to the client. Using the interpretive model, filesystem operations can be defined more simply. Clients can build arbitrarily complex requests from these simple operations. [...] Example: Copy a File Make a copy of file (foo) called (bar). Both files exist in the same directory dfh. The request starts by looking up the filehandle for the file to be copied and creates a filehandle for the copy. The loop operator executes a procedure that copies the file using 1K reads and writes. It maintains a running count of the number of bytes yet to be copied. % Copy a file % dfh (foo) lookup /foofh exch def % get filehandle for (foo) dfh (bar) create /barfh exch def % create filehandle for (bar) /bytes foofh getattr /fsize get def % get size of (foo) so we know how much to copy /offset 0 def % initialize offset for (bar) { /data foofh offset 1024 read def % read up to 1K from (foo) barfh offset data write % write up to 1K to (bar) /bytes bytes 1024 sub def % decrement byte count by 1024 bytes 0 le { exit } if % if it’s < 0 then we’re done /offset offset 1024 add def % increment offset by 1024 } loop barfh getattr 1 encodereply sendreply % return the attributes of the new file to client.
tatoalo 10y ago
"If the designers of X Windows built cars, there would be no fewer than five steering wheels hidden about the cockpit, none of which followed the same principles—but you’d be able to shift gears with your car stereo. Useful feature, that."
pjmlp 10y ago
Everyone that dislikes Win32 should program directly with Xlib and Athena, and rejoice of the experience.
- gruez 10y ago
  Why?
  - pjmlp 10y ago
    I doubt there is any worse UI tooling available.
    - noobermin 10y ago
      Than win32!? Are you serious? Xlib is pretty bad but win32 is absolute bonkers. Or are you saying the opposite?
      - pjmlp 10y ago
        Of course I am serious. I do UI coding since Amiga 500 days and never found so borked API, with more parameters and configuration structures than Xlib, without any support for printing or proper use of fonts. The amount of wasted hours of my life using xlsfonts.... And those bare bones widgets, yet another headache.
        tankenmate 10y ago
        And yet Xlib ran happily on machines with 4MB of RAM and would only use 512K of that; mind you that was X11R3. I used to run this very config on Apollo Domain/OS machines in 1990.
        pjmlp 10y ago
        The Amiga had 512KB for the whole OS, including a GUI stack way better than X. For us targeting desktop computing, the network features of X were never relevant, what mattered was GUI toolkits for workstation usage, running on the same computer.
tragomaskhalos 10y ago
An office I worked in in the early 90's had a shelf with a ten(?) volume set of X windows books - and each individual book was a thick bugger. I'd only had fleeting experience of it, but remember thinking "how complex can this thing be ?!"
- pmontra 10y ago
  I remember them. Those were both the guides and the references for the whole X11 ecosystem. I guess many modern pieces of software would be that large if properly typesetted and printed on paper. Luckily we fit them on the web and some thousands of blog posts, stackoverflow and more.
- arethuza 10y ago
  I think a lot of those books covered stuff that most people writing applications never really had to worry about - I'm pretty sure I got by with one on Xlib and maybe one on Xt?
- david-given 10y ago
  I remember them --- they were really good. The architecture was layered, too, so you typically only ever used one book at a time. Doing raw graphics operations? All you need is the Xlib book. Xt/Xaw? There's a book for that. Motif? There's a book for that, too, but it wasn't in our set. The raw X protocol was, IIRC, documented in volume 0.
- mcguire 10y ago
  Much of the mass was printed man pages for every single API call.
- DonHopkins 10y ago
  I was on Sun's X11/NeWS beta program, and each time they came out with a new release, they'd send me an entire whole new set of X11 and Adobe PostScript manuals! I appreciated it, but had those manuals coming out of my ears! It was great having all those Red Books to pass out at parties, but nobody ever wanted the XView manuals. ;)

xyzzy123 10y ago

Yeah but try and figure out how you'd do better... efficient.ly. Over the network...

_pmf_ 10y ago
Yes; the chapter actually made me admire the design.
- tdsamardzhiev 10y ago
  The whole book was like that for me. I think that's what it's all about - our love/hate relationship with Unix(-like systems).
panic 10y ago
The contemporary windowing system NeWS is worth a look: https://en.wikipedia.org/wiki/NeWS https://en.wikipedia.org/wiki/NeWS Its architecture was more similar to modern web apps, with the UI running code and processing events on the client machine.
- xyzzy123 10y ago
  Ohhhhhhh good answer. One day it'll win :) Actually I think we could do NEWS in JS. Somehow I don't feel that would make you happy tho :P
  - DonHopkins 10y ago
    Does AJAX make you happy? 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.
- reacweb 10y ago
  I remember it. It was far prettier than motif at that time. And Framemaker was so pleasant to use compared to Word. Both NeWS and NeXT were using Display Postscript (https://en.wikipedia.org/wiki/Display_PostScript https://en.wikipedia.org/wiki/Display_PostScript). Do you know if NeWS was an inspiration for NeXT ?
  - arethuza 10y ago
    Other than using PostScript for 2D rendering I don't think NeWS and Display Postscript had much in common. In NeWS you could write your client applications completely in PostScript (or something compiled down to PostScript) and it had its own object-oriented, multi-threaded environment with event handling etc. NeWS was more of a predecessor for Java than NeXT.
    - david-given 10y ago
      Here's the source code for the classic PizzaTool demo (BTW, I've just looked on Google Maps, and I think that Tony & Alba's pizza place in Mountain View no longer exists): http://donhopkins.com/home/archive/NeWS/pizzatool.txt http://donhopkins.com/home/archive/NeWS/pizzatool.txt ...and here's a link to a HN thread a few months ago where Don Hopkins talks about Postscript and windowing systems; lots of good links there: https://news.ycombinator.com/item?id=13196983 https://news.ycombinator.com/item?id=13196983
      - arethuza 10y ago
        I actually worked on a project that used NeWS (actually HyperNeWS) as a front end for a Lisp based AI system written in Common Lisp. HyperNeWS could do some neat things - e.g. you could draw a shape (any shape!) in the graphical editor and paste it as the shape of a window, all without writing any code. Edit: changed "uses" to "used" - was quite a long time ago!
        DonHopkins 10y ago
        I really miss HyperNeWS [1], which I worked on with Arthur van Hoff at the Turing Institute, and I used it to port SimCity to NeWS on Unix [2]. Arthur van Hoff (who developed HyperNeWS and other stuff like Java [3]) and I are working together again, this time at his 360° VR video camera company, JauntVR [4]! I'm developing a secret project called HyperJaunt, that I can't say anything about yet, but you can guess by the name that I'm pretty excited about it! ;) We are looking for a lead software engineer with leadership experience in Amsterdam! [5] [1] http://www.art.net/~hopkins/Don/hyperlook/ http://www.art.net/~hopkins/Don/hyperlook/ [2] http://www.art.net/~hopkins/Don/hyperlook/HyperLook-SimCity.gif http://www.art.net/~hopkins/Don/hyperlook/HyperLook-SimCity.... [3] https://www.linkedin.com/in/aavanhoff https://www.linkedin.com/in/aavanhoff [4] https://www.jauntvr.com/technology/ https://www.jauntvr.com/technology/ [5] https://www.jauntvr.com/careers/apply/?gh_jid=251962 https://www.jauntvr.com/careers/apply/?gh_jid=251962 LEAD SOFTWARE ENGINEER, AMSTERDAM, NETHERLANDS. The Role: This is a highly challenging and highly technical role offering the chance to define the early days of a new industry. Candidate would have to know or be willing to learn mobile 3D graphics programming (OpenGL/GLSL/Unity) with focus on interactivity, network optimization and performance tuning. Candidate should have strong leadership skills. While we are looking for prior experience as a good indicator of future success, our main criteria includes passion for VR, intelligence, creativity and strong work ethics.
- cmrdporcupine 10y ago
  Less important and less popular there was also MGR, which treated windowing more like a terminal session, and so was more Unix-philosophy than most. It was neat, and because of its smaller profile it got ported to a lot of systems (Atari ST, etc.) that struggled under the full X11 system http://www.hack.org/mc/mgr/ http://www.hack.org/mc/mgr/
  - gonzo 10y ago
    Uhler put MGR on the Tadpole SPARCbook. It was really cool.
    - DonHopkins 10y ago
      MGR was awesome! Not extensible, but simple and clean, and efficient over a slow connection. I once saw a great demo of it by its author, Stephen A. Uhler. For some reason, from then on, I always associate MGR with great big bushy moustaches. https://media.licdn.com/mpr/mpr/shrink_150_150/p/2/000/013/318/18c8b96.jpg https://media.licdn.com/mpr/mpr/shrink_150_150/p/2/000/013/3...
bjourne 10y ago
You can't do opengl efficiently over the network. At least xorg can't. Most applications uses opengl these days. For me, I've been using Linux fulltime for the last 15 years and I have never, not even once, had the need to connect to a remote X11 server. ssh has always been enough for me.
- pmontra 10y ago
  Maybe you used Synergy to share a mouse and a keyboard over multiple machines. It's a use case that partly overlaps with running remote desktop applications on your display. Or VNC.
- zeptomu 10y ago
  > Most applications uses opengl these days. Now 'most' is a relative term, but I do not think that's true at all. There are very few applications that use OpenGL. Obviously games are an exception, but if you count in all GUIs I would say mostly target X11 (via Gnome or KDE).
  - bjourne 10y ago
    GNOME and KDE can also use opengl for some tasks if it is available. But right, most applications doesn't directly use opengl. I believe if it weren't such a pita to integrate opengl in desktop appliations (thanks to X11's bad design), many more applications would be using it. To give you an example, think about desktop effects. On Windows, several applications such as Explorer makes parts of their windows semi-transparent. It's a nice simple effect that is impossible (without tons of hackery) to replicate using X11.
    - dfox 10y ago
      https://www.x.org/releases/current/doc/compositeproto/compositeproto.txt https://www.x.org/releases/current/doc/compositeproto/compos... I don't think that this qualifies as "tons of hackery" given the fact that other contemporary UI systems with truly transparent windows implement it in same way (IIRC in pre-Vista Windows truly transparent windows are supported on the OS level but the implementation involves hacks with backing buffer and synthesized expose events).
DonHopkins 10y ago
As it turns out, the web eventually came around to using NeWS's extensible client/server architecture, once they rediscovered it 20 years later and called it "Ajax". (2005 [1] - 1985 [2] = 20) [1] https://en.wikipedia.org/wiki/Ajax_(programming)#History https://en.wikipedia.org/wiki/Ajax_(programming)#History [2] http://www.chilton-computing.org.uk/inf/literature/books/wm/p005.htm http://www.chilton-computing.org.uk/inf/literature/books/wm/...
- gonzo 10y ago
  Ha! Yello, Don. Howzit?
  - DonHopkins 10y ago
    Hi Jim! As it turns out, AJAX is immensely popular in Amsterdam, because it's the name of the local soccer team [1]. But they pronounce AJAX like "ah yax", and JavaScript like "ya va schkript"! ;) [1] http://english.ajax.nl/streams/ajax-now.htm http://english.ajax.nl/streams/ajax-now.htm
jff 10y ago
Plan 9 did it in an interesting way. You draw to the screen by writing to files under /dev. On Plan 9, all file operations take place over 9P, a networked file protocol. So if you are connecting to a remote machine and want to run a graphical program, you mount your local /dev/draw files on the remote end (this is actually taken care of automatically by cpu(1)) and just run the program. Its graphical functions access your local machine's /dev/draw and it all Just Works. Hard to explain but very neat when you use it.
- mej10 10y ago
  How was it efficient?
  - jff 10y ago
    I don't have numbers but in general I'd call it no less usable than X forwarding over ssh. For a long time I used to connect to a Japanese Plan 9 server using drawterm (a Windows/Linux application which essentially emulates the /dev/draw infrastructure) and it was pretty decent considering the latency--I used it to read email, follow IRC, and write code. Over a LAN, it's so fast as to be indistinguishable from something running on your local machine.
- DonHopkins 10y ago
  Plan 9's "everything is a file" philosophy never worked for me, because it's far too low level, and I don't believe Unix's file I/O API itself is very pleasant: open, read, write, ioctl and select (gag). I'd much rather have a real API with rich app-specific functional or event interfaces to call, and to be able to pass actual typed parameters instead just a stream of bytes, including structured data like json, s-expressions or PostScript data, or even (gasp) Turing complete programs, like PostScript code! NeFS, as defined in 1990 in the infamous NFS3 proposal aka "Network extensible File System Protocol Specification" did just that, and it was actually a great idea too early for its time. So it went over like a lead balloon, and was never actually adopted. NeFS should not have been framed as a successor to NFS, because it required a revolution in how programs interacted with the file system. And of course there are the security and stability implications of running downloaded code in the kernel, which hadn't been properly addressed. ;) Take for example (shown below) the act of copying a file to a backup file in the same directory. With traditional NFS, the server would have to send each block of the file to the client, which would then send it back to the server, which would then write it to disk. That required a lot of network traffic, as well as many context switches between user and kernel space on both the client and the server (at a time in history where they were extremely expensive). Instead, the client could just send a simple PostScript program to the server (or call one that was loaded from a library or sent previously -- see the example below), which copied the file in the kernel of the server, without sending it over the network, or requiring any context switches on either the client or server. That's several orders of magnitude more efficient in terms of both CPU and network usage, and just the simplest and easiest to explain example possible of what you could do. Just imagine how much more efficient, powerful and tightly integrated together other utilities like "find" and "grep" could be, tightly woven together procedurally in the kernel instead of communicating with a stream of bytes over a pipe! http://www.donhopkins.com/home/nfs3_0.pdf http://www.donhopkins.com/home/nfs3_0.pdf Introduction The Network Extensible File System protocol(NeFS) provides transparent remote access to shared file systems over networks. The NeFS protocol is designed to be machine, operating system, network architecture, and transport protocol independent. This document is the draft specification for the protocol. It will remain in draft form during a period of public review. Italicized comments in the document are intended to present the rationale behind elements of the design and to raise questions where there are doubts. Comments and suggestions on this draft specification are most welcome. 1.1 The Network File System The Network File System (NFS™*) has become a de facto standard distributed file system. Since it was first made generally available in 1985 it has been licensed by more than 120 companies. If the NFS protocol has been so successful why does there need to be NeFS ? Because the NFS protocol has deficiencies and limitations that become more apparent and troublesome as it grows older. 1. Size limitations. The NFS version 2 protocol limits filehandles to 32 bytes, file sizes to the magnitude of a signed 32 bit integer, timestamp accuracy to 1 second. These and other limits need to be extended to cope with current and future demands. 2. Non-idempotent procedures. A significant number of the NFS procedures are not idempotent. In certain circumstances these procedures can fail unexpectedly if retried by the client. It is not always clear how the client should recover from such a failure. 3. Unix®† bias. The NFS protocol was designed and first implemented in a Unix environment. This bias is reflected in the protocol: there is no support for record-oriented files, file versions or non-Unix file attributes. This bias must be removed if NFS is to be truly machine and operating system independent. 4. No access procedure. Numerous security problems and program anomalies are attributable to the fact that clients have no facility to ask a server whether they have permission to carry out certain operations. 5. No facility to support atomic filesystem operations. For instance the POSIX O_EXCL flag makes a requirement for exclusive file creation. This cannot be guaranteed to work via the NFS protocol without the support of an auxiliary locking service. Similarly there is no way for a client to guarantee that data written to a file is appended to the current end of the file. 6. Performance. The NFS version 2 protocol provides a fixed set of operations between client and server. While a degree of client caching can significantly reduce the amount of client-server interaction, a level of interaction is required just to maintain cache consistency and there yet remain many examples of high client-server interaction that cannot be reduced by caching. The problem becomes more acute when a client’s set of filesystem operations does not map cleanly into the set of NFS procedures. 1.2 The Network Extensible File System NeFS addresses the problems just described. Although a draft specification for a revised version of the NFS protocol has addressed many of the deficiencies of NFS version 2, it has not made non-Unix implementations easier, not does it provide opportunities for performance improvements. Indeed, the extra complexity introduced by modifications to the NFS protocol makes all implementations more difficult. A revised NFS protocol does not appear to be an attractive alternative to the existing protocol. Although it has features in common with NFS, NeFS is a radical departure from NFS. The NFS protocol is built according to a Remote Procedure Call model (RPC) where filesystem operations are mapped across the network as remote procedure calls. The NeFS protocol abandons this model in favor of an interpretive model in which the filesystem operations become operators in an interpreted language. Clients send their requests to the server as programs to be interpreted. Execution of the request by the server’s interpreter results in the filesystem operations being invoked and results returned to the client. Using the interpretive model, filesystem operations can be defined more simply. Clients can build arbitrarily complex requests from these simple operations. [...] Example: Copy a File Make a copy of file (foo) called (bar). Both files exist in the same directory dfh. The request starts by looking up the filehandle for the file to be copied and creates a filehandle for the copy. The loop operator executes a procedure that copies the file using 1K reads and writes. It maintains a running count of the number of bytes yet to be copied. % Copy a file % dfh (foo) lookup /foofh exch def % get filehandle for (foo) dfh (bar) create /barfh exch def % create filehandle for (bar) /bytes foofh getattr /fsize get def % get size of (foo) so we know how much to copy /offset 0 def % initialize offset for (bar) { /data foofh offset 1024 read def % read up to 1K from (foo) barfh offset data write % write up to 1K to (bar) /bytes bytes 1024 sub def % decrement byte count by 1024 bytes 0 le { exit } if % if it’s < 0 then we’re done /offset offset 1024 add def % increment offset by 1024 } loop barfh getattr 1 encodereply sendreply % return the attributes of the new file to client.

tatoalo 10y ago

"If the designers of X Windows built cars, there would be no fewer than five steering wheels hidden about the cockpit, none of which followed the same principles—but you’d be able to shift gears with your car stereo. Useful feature, that."

pjmlp 10y ago

Everyone that dislikes Win32 should program directly with Xlib and Athena, and rejoice of the experience.

gruez 10y ago
Why?
- pjmlp 10y ago
  I doubt there is any worse UI tooling available.
  - noobermin 10y ago
    Than win32!? Are you serious? Xlib is pretty bad but win32 is absolute bonkers. Or are you saying the opposite?
    - pjmlp 10y ago
      Of course I am serious. I do UI coding since Amiga 500 days and never found so borked API, with more parameters and configuration structures than Xlib, without any support for printing or proper use of fonts. The amount of wasted hours of my life using xlsfonts.... And those bare bones widgets, yet another headache.
      - tankenmate 10y ago
        And yet Xlib ran happily on machines with 4MB of RAM and would only use 512K of that; mind you that was X11R3. I used to run this very config on Apollo Domain/OS machines in 1990.
        pjmlp 10y ago
        The Amiga had 512KB for the whole OS, including a GUI stack way better than X. For us targeting desktop computing, the network features of X were never relevant, what mattered was GUI toolkits for workstation usage, running on the same computer.

tragomaskhalos 10y ago

An office I worked in in the early 90's had a shelf with a ten(?) volume set of X windows books - and each individual book was a thick bugger. I'd only had fleeting experience of it, but remember thinking "how complex can this thing be ?!"

pmontra 10y ago
I remember them. Those were both the guides and the references for the whole X11 ecosystem. I guess many modern pieces of software would be that large if properly typesetted and printed on paper. Luckily we fit them on the web and some thousands of blog posts, stackoverflow and more.
arethuza 10y ago
I think a lot of those books covered stuff that most people writing applications never really had to worry about - I'm pretty sure I got by with one on Xlib and maybe one on Xt?
david-given 10y ago
I remember them --- they were really good. The architecture was layered, too, so you typically only ever used one book at a time. Doing raw graphics operations? All you need is the Xlib book. Xt/Xaw? There's a book for that. Motif? There's a book for that, too, but it wasn't in our set. The raw X protocol was, IIRC, documented in volume 0.
mcguire 10y ago
Much of the mass was printed man pages for every single API call.
DonHopkins 10y ago
I was on Sun's X11/NeWS beta program, and each time they came out with a new release, they'd send me an entire whole new set of X11 and Adobe PostScript manuals! I appreciated it, but had those manuals coming out of my ears! It was great having all those Red Books to pass out at parties, but nobody ever wanted the XView manuals. ;)