And often he's misquoted with a similar one: "the old world is dying, and the new one is late to come. And in these shadows (chiaroscuri) the monsters are born".
Anyway, it always surprises me how Gramsci seems to be more known and studied abroad than Sardinia and Italy.
Fun fact: originally "/home/NeWS" displayed "forbidden" access and I stumbled upon it by pure luck, finding the missing "operators.h" (and I told Don, since I wanted to see if there was something else missing or different, like "DumbOSI.c" which I hoped to be different from SunOSI.c). There is also an hidden file in /lib/NeWS called ".NeWS", contains the following string: "(hello) playdemo", which should kick the journal tool.
In any case, it was a "Pulcinella Secret", and anybody reading his replies on HN could easily find all his distributions, and it is replicated also on tenox.pdp-11.ru (but it's incomplete, since that there are only the contents of /home/code/NeWS".
On BitSavers there are the OpenWindows 2.0 source tapes other than the binaries (these last ones are also available inside SunOS 4.1.1 install CD, both for Sun-3 and Sun-4), but to extract them you need a specific tool, then you extract the tar dists.
He also got Parallax p/NeWS in his collection, which is super rare. I also wrote a person who has a SunDew QIC cassette, and another that has various NeWS sources (including the portable REF tree of the 1.1 version). Unfortunately they haven't released them yet, because of the unknown copyright situation.
Another person has the OpenWindows 1.0 binary tapes for Sun-3 and Sun-4, among other stuff.
For now we have the sources of NeWS 1.1 (and operators.h if you look more in depth) and X/NeWS 2.0. I also have the RBuss sources (an incomplete clone), but I have to ask the author if they can be put on the internet.
Over time much NeWS related stuff resurfaced, wheter are application binaries, sources (both application and the server itself) or documentation, so anyone could play with them on a real machine (Sun-3 or SPARC) or inside QEMU SPARC.
I'm waiting for a copy of "Portable NeWS 1.0" to be recovered, to see how much different the sources are compared to the 1.1 version.
I also hope to see resurface binaries/sources of other server implementations, Sun Symbolic Programming Environment (which includes code originally developed at Schlumberger, including LispScript), the sources of the PdB compiler, CMU Andrew wm (although is not directly related, is the ancestor of this window system, from the same authors), and whatever is related to this system.
The man behind this site is known for his skills of recoverying data from QIC tapes.
Looking at the "Software Library" section makes me always wonder if it will be released at some point, since that there is some stuff that isn't on BitSavers or other sites.
I'd like to see some code to understand what it takes to write a functioning Wayland application, a bit like David Rosenthal did in his paper "A Simple X11 Client Program -or- How hard can it really be to write ‘Hello, World’?" (USENIX 1988 Winter Proceedings).
Anyway, if I was persuaded that Wayland has a rather backwards design (here my reasons: https://news.ycombinator.com/item?id=47477083), now I have the confirmation that its philosophy is something like "put surfaces on the screen and distribute events to the clients, all the other stuff is not my business", and that exploring alternative approaches to window management is still worth it.
Having applications that manage all their resources (canvases, events, decorations) is not bad per se (for example video games), but not all of them need to.
So far this is one of the most interesting approaches to Wayland compositor implementation.
I always felt that the "monolithic design" (compositor + window manager) is a step backwards, and that many compositors neglected features like server side decorations (which make easier to have a consistent look & feel).
The NeWS book at page 35 has a picture explaining the structure of the CMU Andrew Window System: the window manager on top of the "base window system" (assuming protocol and logic), which sat on the graphic library, and applications connected to it through sockets.
A limit was that the window manager was fixed, so you couldn't change its policy/look and feel without having the sources and recompiling it (and here I wish the source code was available).
Wayland it's kinda similar, but most of the graphic layer is moved from the server into each application (where each one use its own).
Unless you have a compositor that is designed to be extensible out of the box, a set of widgets will be needed if you don't ship a desktop environment, and each one is a separate system process (for example: toolbar, clipboard manager, status bar, wallpaper).
Another limitation is its "static" protocol, in the sense that you cannot extend the compositor at runtime loading extensions (you have the XML which is used to generate the stubs for the implementation in the compositor AFAIK). This can prevent applications that use them to run on compositors that don't implement them.
On the other hand, systems like NeWS, GMW (a window system from Kyoto University, ASTEC and Omron) and the one described by Rob Pike in "A concurrent window system" are interesting for these reasons:
- runtime extension loading code: new functionalities to the server can be added when needed
- code as a protocol: instead of sending "raw data" and requests, equivalent pieces of code are sent, allowing for compression and to offload a portion of the logic to the server (or even have applications that run inside the server). This can also allow to have applications that run on remote machines, which download the code for the interface to the server.
- concurrency: their programming model is structured around "lightweight processes" (or equivalent), which allow to decompose the interaction in independent tasks, which can eventually interact by sending messages/events or sharing resources.
I think it's worth re-investigating this kind of design, considering also the technological advancement (like the evolution of graphic hardware, multicore CPUs, touchscreens, ecc) and challenges (including security).
It would be interesting something like NeWS but a bit more abstract and capable of supporting whatever graphic model you wish.
These are some screenshots of NeWS 1.1 running on SunOS 4.1.4 on QEMU that I took time ago.
Unfortunately QEMU SPARC decided to break again. Also, keyboard doesn't work yet (forcing me to use the SunView terminal emulator), but probably it's due to the keyboard script.
In any case, SunOS 4.1.4 comes with OpenWindows out of the box.
> Does it build today
In this form it won't, since that is missing the Sun PixRect library. And you also need the "operators.h"
file (which is in another directory...) and the "acceptconnect" function.
On comp.windows.news Usenet group and on the NeWS book is reported that a portable codebase (called REF) exists, and Sun ported it on Ultrix (on thr VAXstation) and System V. I read it included a version of PixRect called "Generic PixRect", which should be more portable.
BitSavers put on the net a tape dump of X/NeWS 2.0, and there are some differences: a different graphics library called SHAPES replacing CScript (and it needs the Ace preprocessor to build the device dependent portion of the library), a different memory allocator, support for X11 protocol, support for Folio F3 fonts, and other things.
Fortunately I found a copy of PixRect in the leaked sources of SunOS 4.1.4 , but it's not enough, since that device dependent routines must be rewritten.
I'm slowly porting NeWS 1.1 to NetBSD (since that wscons is easier to work with) as a proof of concept. I managed to execute code and grt my screen turn blue, but the current obstacle is decoding binary fonts: the OG routines fail completely on 64 bit machines, since that the original format assumes 32 bit machine words and big endian order. More work will be needed.
Weeks ago, while I was searching for NeWS related papers/material, I stumbled upon some japanese papers about a window system called GMW (Give More Windows).
It is pretty much obscure, and all I found is that was made at Kyoto University (who also made Kyoto Common LISP), and it used a virtual machine.
NeWS wasn't based on DPS. It's a full display server based on the PostScript Red Book with some extensions (canvases, lightweight processes and sync primitives, events, classes, garbage collection). This allows to write applications in this extended PostScript or in other programming languages, using a preprocessor, such as cps for C or lps for Scheme-48 and Allegro LISP, that generates PS snippets that get sent to the server.
Yes, it comes in bundle with SunOS, since that one part of it it's implemented in the kernel IIRC.
I've also been able to run NeWS 1.1 (which was before the X/NeWS merg) inside QEMU, although the keyboard input is not working (and for some reason the patch to add the Sun Type 4 breaks everything).