The comment about how X is really just a distributed database system with occasional visual side effects that could be reduced down to 10 or so API calls gives us a glimpse as to what life could have been.
It's a shame that all of the X replacements on the horizon also ditch the network transparency part, even though that's been a killer feature for me. I hate how much of a hack Remote Desktop is on Windows machines.
> It's a shame that all of the X replacements on the horizon also ditch the network transparency part, even though that's been a killer feature for me.
I've used ssh -X many times in my life, but at the same time, I understand why network transparency doesn't make as much sense anymore.
Classically, the X protocol kept a huge amount of state on the server, and clients would just send small requests to manipulate that data. Drawing would take place server-side, and it was relatively simple drawing at that, since UI needs were fairly modest. Text rendering occurred on the server with small strings sent from the client. And overall, it made sense to send a small amount of data to produce a large amount of graphics.
These days, however, rendering occurs almost exclusively on a combination of the client and the GPU. Everything takes place via large memory buffers, and compositing. And pushing those over the wire doesn't work nearly as well; if you're going to do that, you need protocols designed for it, with compression and delta-encoding, much like modern video codecs (but optimized for remote-desktop).
So I think it makes sense that network transparency is being rethought, in favor of protocols that look a lot more like remote-video (and remote-audio).
People not familiar with X reading the above (which is correct) might miss that client/server is reversed from the way most people think about it. For X, the server is the system where the display/keyboard/UI is physically attached and the client is the host (remote host for this discussion) where the application is actually running.
Ah, fair point. I've been around X for so long that I'd forgotten that being a point of confusion. I do think it makes sense in the sense that the "server" provides the resources and the client connects to them and uses them, but it definitely takes a bit of getting used to.
Except that DLNA has that third controller role that's usually taken over by either the client or the server, plus the confusion added by openhome servers with playlists (made even more confusing/annoying for me, since mine is provided by a fourth service/proxy, BubbleUPnP).
Standard DLNA is easy to remember, however, as long as you know the terms--[file]server, renderer, and controller. It even uses http for the fileserver (not sure if that's part of the standard or not though)
I don't know why this is confusing to people, at least if they understand sockets. The display server does listen(2). The application does connect(2). Why is that hard?
Windows and Mac use similar terminology to "display server" too, but I guess those are proprietary components that few people look into...
I understand sockets and I understand how X works, and I think it's confusing and stupid. It places unnecessary emphasis on an implementation detail that is unimportant to the end user.
Then say "app" or "program" instead of "x client" and nobody is harmed ... If people say "x client" it's usually in a more architectural, less colloquial context to begin with.
Both web client/server and X client/server nomenclature define what client and server mean in very specific (but opposite) technical ways, but I think both definitions limit how people think about what's really going on -- it's not so asymmetrical.
Actually, I think of the client/server relationship as a higher level abstraction above the mechanics of the actual socket connection, which can go either way, or both, or many relationships at the same time in different directions and between different sites.
All sites can offer any number of different asynchronous message based services to each other at all times.
It shouldn't matter who was listening, who connected first or how they connected, just that all sites can send messages back and forth on the same channel. It could be UDP, multicast, WebRTC, distributed peer to peer, or a central message dispatcher.
A (web client / X server) site with the display and GPU and mouse offers presentation and rendering and input services to different (web server / X client) sites, which themselves offer database and storage and computing services the other way, at the same time over the same channels.
> Both web client/server and X client/server nomenclature define what client and server mean in very specific (but opposite) technical ways
That's just false. A web server listen(2)s/accept(2)s. A web browser or other HTTP client connect(2)s. An X server listen(2)s/accept(2)s. An X client connect(2)s.
In either case it would not make sense to invert this relationship. In both cases a server is an endpoint that serves its resources to multiple clients. Are people advocating conceptually that the graphics card connect to its programs, and not the program request access to it? That makes very little sense. Just like a web server would not proactively connect to its end user web browsers. The requests happen in the other direction.
I'm saying that client/server has a meaning that's independent of who initiates the connection, or what kind of connection it is.
For example, whether you weed dealer "Dave" calls you on the phone and tells you he can drop by if you're interested, or if you call "Dave" and ask him to drop by, "Dave" is still the server, and you're still the client.
You and your drug dealer are not computer programs operating over a socket. You are using a different definition of "client" to mean "purchaser". You may find that to be a useful description in that context but in a computer context it sounds like you are being intentionally vague.
I thought I was being intentionally pretty specific that client/server relationships can go both ways, at the same time, regardless of which side initiated the connection. Once you have a connection, no matter which side initiated it, or even if they both just randomly met in Linda tuple space like ships in the night, each side can offer services to and consume services from each other.
https://www.xpra.org/ is an example of the video-codec style approach, it is per application/window like X11 and it is extremely usable even over very poor network conditions, and handles 60fps audio and video brilliantly.
xpra is my favored tool out of plain X forwarding / vnc / (free)nx / x2go / etc, but one issue I have with it (at least last time I used it) is that it requires the version string to be identical on both client and server. This, combined with it being written in python, means that every distro packages it differently, has a different version number, and if you want to just clone it and run it yourself, now you have to deal with python / virtualenv / whatever hell.
If you believe the README.txt files of downloads from The Pirate Bay, there exist some amazing video codecs that are so new and advanced that they can actually play episodes of Rick and Morty that haven't even been released yet! It's almost as good as inter-dimensional cable TV. And they are totally free: you just have to download and install some binary codecs from some Russian web site before watching the video.
> I've used ssh -X many times in my life, but at the same time, I understand why network transparency doesn't make as much sense anymore.
ssh -X is useful for something like clipboard forwarding from your local desktop to remote server (and back). You can work in something like nvim remotely, and have a nice clipboard integration. What will happen with such functionality after the switch to Wayland?
This is an unpopular opinion, but using vi over ssh - or any editor - has always struck me as a hack. You get high keystroke latency if the server is far away, which seems to bother me more than most people (in part because it’s unnecessary). You don’t have your settings and bindings by default, so you have to either get used to the default experience or copy your settings onto every server you use. Similarly, you get some random version of vim by default (not nvim), so if you want the latter, or any other editor, you have to install it. If the device you’re SSHing into is an embedded system like a router, that may be difficult or impossible or at least waste valuable disk space. And you’re stuck with a terminal, no GUI (even vim has some enhancements in GUI mode) - that is, unless you use X forwarding, but that’s an even bigger wasteful installation, given that most servers have no business having the X libraries installed.
In theory, a saner approach is using a local editor to edit remote files.
But people don’t do that. Why? Because the available implementations suck. NFS sucks because it’s slow and hangs your programs; sshfs is the same but worse. Vim has native remote file support in the form of scp://, which invokes the scp command every time you open or save a file - synchronously, so even if you’re saving you have to wait. This might be vaguely tolerable if you configure ssh to share connections, but in general it sucks. And with any of those, you have to set up a separate connection to the server and re-find the directory you’re in, which may or may not be time consuming. By contrast, typing vi into the SSH prompt usually just works, so that’s what people do.
But there’s no fundamental technical limitation here. Imagine if you could type ‘edit foo.conf’ on the server and have it pop open a native editor on the client side. File transfer would be tunneled through the existing SSH connection, with no setup time or need for re-authentication; it would be fully asynchronous, so the editor would never hard-block waiting for an operation to complete, but it would still indicate when saves have been completed, so you know when it’s safe to run commands on the server that use the new files. Thing is, none of what I just said is especially complex or challenging from a technical perspective; it’s just that it would require changes to a bunch of components (ssh on the client and server; vim) that weren’t designed with that use case in mind.
Anyway, I’m getting a little off topic here - but I think the point generalizes. In my ideal world, the future of X forwarding would be fixing the most common use cases so you don’t need X forwarding. For the rest, well, the ‘server sets up a tunnel over SSH’ approach could work just as well for VNC, or for an improved remote display protocol that uses a video codec.
In the real world, I suppose things will just fester, remote display support will get worse, and remote editing will continue to suck. But I can dream. Or maybe implement something myself, but there are so many other things to do…
Are you sure? I don’t have any experience with Emacs, but…
> Yes, this is the basis of the very popular and widely used TRAMP component in Emacs.
I’m sure TRAMP is better than vim’s netrw, but at least according to [1] it’s not fully asynchronous. It also seems to require a separate SSH invocation; I know you can configure SSH to reuse physical connections, but at least when I once tried it, it didn’t work very well…
> Yes, this is possible with emacsclient.
Judging by [2], it doesn’t seem to work well for that use case (talking to emacs over an SSH tunnel)… Assuming you can get it to work, can you make it work with multiple SSH connections to arbitrary servers, without any per-server configuration? If so, that’s quite interesting and maybe I should check it out. If not, then it still may be quite useful, but it wouldn’t be versatile enough to truly render editor-over-SSH unnecessary.
>Can you make it work with multiple SSH connections to arbitrary servers, without any per-server configuration?
Certainly, of course. Depending on your level of hackery, you can:
- Make ssh automatically copy an emacsclient wrapper script over which does the correct thing
- Use OpenSSH's Unix socket forwarding on each connection to connect emacsclient to your local Emacs server
- Use https://github.com/magit/with-editor
I've never bothered, though, because I run all my shells on remote hosts via TRAMP within Emacs, so when I am in a shell, I can just use open the remote files through the normal Emacs keybindings, rather than typing "emacsclient filename". Thanks to with-editor, this also extends automatically to commands invoked on the remote host which run $EDITOR.
>I don’t have any experience with Emacs, but…
It's not surprising. :) You said "using vi over ssh - or any editor - has always struck me as a hack", "is an unpopular opinion". In fact, it's the consensus in Emacs land. :) Though perhaps that doesn't prevent it from being an unpopular opinion, these days. :)
I would suggest taking a look at https://nuclide.io/docs/features/remote/ for imo, best in class for what you're talking about. Most editing at Facebook is done on a remote server, so the infrastructure people at FB have done a pretty good job on shoring up a lot of the issues.
It has a lot of what you're talking about. Typing `atom foo.conf` to open up files locally. Keeping the same connection open and reconnecting without needing to reauthenticate with SSH.
There's also a lot of other stuff that needs to be handled. File searching needs to be hooked up a reasonable way. Language services do as well.
Facebook has done a great job with remote editing (although I don't think the open source version of Nuclide is a priority).
What you have described here for text editing holds true for any other action on files that you intend to do while remote logged onto that other box. Why use the local ls, less, etc, while you have better versions at home? Indeed, why would you use the remote default bash instead of your properly configured zsh, to begin with?
It seems when you connect on a remote box many times what you really want is to import its files. But despite there have been a lot of network shared file systems none seams to have become the obvious solution, supposedly because it's hard to fix that problem efficiently in the general case, especially for an operation system, Unix, that attach to files an API that have not been designed for this.
If you use an old enough editor, they've designed around limited bandwidth for screen updates, and they tend to work ok with high latency. Usually, when I'm doing editing, I don't necessarily need to see the screen update until I'm done typing a line (although getting the cursor in the right place can be painful beyond maybe 100ms roundtrip, especially if it's inconsistent)
A split editor, with a local ui and filesystem remote can be made to work, but you do have to install something on the remote end, which brings you back to the remote end doesn't have the environment you want, so you just suffer with whatever is there problem.
I agree, that local editing of remote files would be better, but as you said, current options are pretty bad. Latency is still there, except it's in the filesystem level and file operations, rather than interaction with the editor itself.
I.e. both methods have their trade-offs. I find using remote nvim easier, even if you have to install and configure it first. At least if we are talking about some stable commonly used environment, and not about ad-hoc editing, in which case remote mounting might be a better option.
Nice idea, but there are occasions when I find myself on a Windows box (which I normally never use) using putty, or my iPad using vSSH and I have no local editor (or editor that I would use, in the case of Windows).
And you may find yourself
Behind the wheel of a large Microsoft Mouse
And you may find yourself on a beautiful PC
With a beautiful Window
And you may ask yourself, well
How did I get here?
Network transparency lets headless compute servers in distant datacenters take advantage of the powerful GPU under my desk. To me one monitor per GPU makes a lot more sense than n cores per GPU plus the extra bandwidth for live video.
X also makes all these very low level assumptions that crosscut all parts of the API, that simply don't apply any more (and didn't actually apply in the first place).
"Mechanism not policy" my ass. X window borders are an archetypal example of the hollowness of that oft-repeated slogan. The slogan should have been "We must strengthen our borders to protect our precious bodily fluids!" ;)
X windows all have a bunch of properties and messages and parameters relating to how to draw window borders in the server.
They have a border width, and a pixel value. They can even have a border pixmap that is tiled with the same origin as the background tile origin (hope that works for you!).
The rationale was that the server could instantly draw window borders and backgrounds before the client refreshed, to give you a bunch of stippled rectangles to look at while you waited for the client to send some drawing commands.
While NeWS's solution was simply for the server to call a PostScript procedure to instantly draw whatever kind of elaborate border plus anything else it wants the user to see (and interact with), without waiting for the client.
Nobody, but NOBODY uses window borders any more. Only the earliest ugliest toolkits like Athena (Anathema) widgets did. It was a terrible idea to build borders into the window system at that level (POLICY!!!), because nobody ever wants to draw borders in a special but extremely limited way built into the window system at a low level, and then draw the rest of the user interface some other way.
X window borders were totally useless for drawing the brutal beveled edges that were fashionable at the time, or even rounded rectangles. Supporting that would be policy! But go to town and express yourself with tiled pixmap borders, that's pure mechanism baby!
You'd think it would be straightforward to make an extension that lets you simply set the shape of a window by defining a region somehow.
But no, thanks to borders, each window's shape is defined by TWO regions: the smaller inner client clipping region and the larger outer border bounding region. Well actually it's more than two -- a lot more: There's also their rectangular default core protocol size (both with and without borders), which can be totally different than either of those two other regions's sizes, and modify the effective region.
In summary there are bounding, clip, default bounding, default clip, client bounding, client clip, effective bounding, and effective clip regions. Got it?
Of course all of those regions will almost always be the same since nobody actually uses borders, but thanks to the borders on every window that nobody uses, the SHAPE extension is an order of magnitude more complicated than it needs to be, and even includes a handy glossary and travel guide to all of its various regions.
The extension allows defining the shape of two separate regions: the clipping and the bounding regions. These two areas are defined even for windows not using the shape extension: the clipping region is the area that can be used for drawing, the bounding region is the total area covered by the window (that is, the clipping region plus the border). The shape extension allows defining two independent shapes for these two regions.
Both the clipping and bounding are associated, in the shape extension, two areas: a default rectangular region and a possibly non-rectangular client region, defined and changed by the client as specified above. The effective region, which is the actual shape of the window, is the intersection of these two areas. This intersection is performed every time either region is changed: for example, if the client regions contains parts that are outside the default region but the default region is then enlarged, the effective region will include these parts.
Status XShapeQueryExtents(Display display, Window window, Bool bounding_shaped, int x_bounding, int y_bounding, unsigned int w_bounding, unsigned int h_bounding, Bool clip_shaped, int x_clip, int y_clip, unsigned int w_clip, unsigned int *h_clip);
The border of a window is defined to be the difference between the effective bounding region and the effective clip region. If this region is empty, no border is displayed. If this region is nonempty, the border is filled using the border-tile or border-pixel of the window as specified in the core protocol. Note that a window with a nonzero border width will never be able to draw beyond the default clip region of the window. Also note that a zero border width does not prevent a window from having a border, since the clip shape can still be made smaller than the bounding shape.
Glossary
bounding region:
The area of the parent window that this window will occupy. This area is divided into two parts: the border and the interior.
clip region:
The interior of the window, as a subset of the bounding region. This region describes the area that will be painted with the window background when the window is cleared, will contain all graphics output to the window, and will clip any subwindows.
default bounding region:
The rectangular area, as described by the core protocol window size, that covers the interior of the window and its border.
default clip region:
The rectangular area, as described by the core protocol window size, that covers the interior of the window and excludes the border.
client bounding region:
The region associated with a window that is directly modified via this extension when specified by ShapeBounding This region is used in conjunction with the default bounding region to produce the effective bounding region.
client clip region:
The region associated with a window that is directly modified via this extension when specified by ShapeClip This region is used in conjunction with the default clip region and the client bounding region to produce the effective clip region.
effective bounding region:
The actual shape of the window on the screen, including border and interior (but excluding the effects of overlapping windows). When a window has a client bounding region, the effective bounding region is the intersection of the default bounding region and the client bounding region. Otherwise, the effective bounding region is the same as the default bounding region.
effective clip region:
The actual shape of the interior of the window on the screen (excluding the effects of overlapping windows). When a window has a client clip region or a client bounding region, the effective clip region is the intersection of the default clip region, the client clip region (if any) and the client bounding region (if any). Otherwise, the effective clip region is the same as the default clip region.
With X, the roles of the client and the server are reversed: the client with the GPU connecting over ssh -X is the X11 server, so your point is, well, beside the point.
In the old days it was convenient to be able to run a SunOS binary on a remote server and display on a Linux machine -- but this can't be as common today.
The way X clients can be forwarded over SSH implies that network transparency doesn't need to be built in to the window system, there just needs to be a "seam" at which it can be interposed. Obviously any kind of direct access to graphics hardware makes this impractical.
Plan 9's window system uses the 9p file system protocol to cross the network; another Bell Labs trick (used in Rob Pike's Sam editor) is for the app to be split into two parts with their own internal interface. They can run on different hosts. The internal protocol/interface can be tailored to the app (and can potentially be very simple and/or efficient).
Once you've created a seam (possibly a unix socket, many of my designs rely on those) exposing the same socket over TCP becomes relatively trivial and now you effectively have network transparency anyway (see also spiped).
But, yeah, so long as the client is a separate process, getting it transited over the network can be done separately.
I prefer every other OSes remote desktop, because I can detach and reattach them in different computers.
Rightly or wrongly, modern GUIs tend to be sufficiently graphical that X turns into effectively sending bitmaps anyway, so in my experience a lightly compressed VNC is more responsive.
It is nice that in X individual windows can live independently, but adding that to your windowing manager feels like less work, and is how for example windows works nowadays (don't know other windowing systems well enough).
I made the X11 SimCity code that updates the small map (which usually has only a few pixels changed, but sometimes has many pixels changed) compare the "before" and "after" images and count the differences, and if there were few enough differences, it would sort the changed pixels by color, then send batches of XDrawPoints of each color.
In X11 it is just as expensive to change the foreground color as to draw one dot (since all the overhead is sending the command), but you could efficiently draw a lot of dots of the same color with XDrawPoints, so it was worth it to sort the pixels by color and then draw them in a few same-colored batches, instead of switching colors between each pixel you draw.
I disabled that crazy code for the OLPC port since it was always running locally and XPutImage would always always use the shared memory extension, but in the days when you wanted to run remotely over a slow network, or the local server didn't support the shared memory extension, it was well worth doing all the work of comparing and sorting individual pixels to incrementally update the map!
(I'm sure that code used to work on old 8 bit displays, but for some reason I never bothered to figure out, it was buggy on the OLPC's 24 bit visual, so I #if'ed it out of its misery. That's X11 for you.)
It's a shame that all of the X replacements on the horizon also ditch the network transparency part, even though that's been a killer feature for me.
Don't worry, in time everything will be re-invented on the web. With WebGL, the browser becomes just like an X server, only with a far richer feature set for malware authors.
> I hate how much of a hack Remote Desktop is on Windows machines.
People just don't seem to get this. If I can't alt-tab between windows, remote GUI apps are next to useless for me. It breaks my workflow. I hit this speebump all the time when working with VMs and RDP.
"Had he done some real design work and looked at what others were doing he might
have realized that at its core, X was a distributed database system in which
operations on some of the databases have visual side-effects. I forget the
exact number, but X includes around 20 different databases: atoms, properties,
contexts, selections, keymaps, etc. each with their own set of API calls. As
a result, the X API is wide and shallow like the Mac, and full of interesting
race conditions to boot. The whole thing could have been done with less than
a dozen API calls."
To that end, one of the weirder and cooler re-implementations of NeWS was Cogent's PIX for transputers. It was basically a NeWS-like multiprocessing PostScript interpreter for Transputers, with Linda "tuple spaces" as an interprocess communication primitive:
The Cogent Research XTM is a desktop parallel computer based on the INMOS T800 transputer. Designed to expand from two to several hundred processors, the XTM provides a transparent distributed computing environment both within a single workstation and among a collection of workstations. Using Linda tuple spaces as the basis for interprocess communication and synchronization, a Unix-compatible, server-based OS was constructed. A graphic user interface is provided by an interactive PostScript window server called PIX. All processors see the same set of system services, and within protection limits, programs capable of using many processors can spread out over a network of workstations and resource servers, acquiring the services of unused processors.
> I have a section in the book that I'm writing where I talk about how to design a good API. I pose the question of why none of the original Apple Mac API published in 1985 taking about 1,200 pages is in use today whereas almost all of the UNIX V6 API published in 1975 taking 321 pages is still in use and has been copied by many other systems. I'm sure that everyone on this list knows the answer.
I'm not sure I do. But it does seem like a good question.
My guess is that the original Mac OS provided a great GUI, but not much of an OS. It loaded a single application at a time that had access to all of memory. That's why it had desk accessories, to give you apps you could use without quitting the main application. It had handle based memory management so the OS could move memory blocks more contagiously to create enough open space for new memory allocations.
Over time they added cooperative multitasking, which meant the foreground app had to consciously give time to let background apps do stuff.
But they could never build a real OS with security and memory protection out of it. So Apple bought NeXT to get industrial strength unix as their core OS, and switched all Apple development to NeXTStep, or at least the modern derivative of it, called Cocoa.
My dust covered Inside Mac volumes were made useless nearly 20 years ago.
It helped that he had intimate knowledge of the Mac operating system’s internals, but many of them were documented in Inside Macintosh, and others could have been found with (quite) a bit of effort; one didn’t have to be at Apple or even have access to the system’s source code to implement that.
And those volumes aren’t useless; they are reminders of about the last time hacking an OS was fun :-;
What is fun is the Switcher/Multi-Mac debacle. Notice that it was mentioned that "I knew that releasing it would have me having to keep up with all the new ROM releases from Apple in the future." At the time, even with the 128K ROM I think they still had to put special code to support Switcher into there (Andy was also working on the Font Manager at the time).
Great story. What jumped at me was Andy's reaction to Steve's 100K offer. Mine was to counter with "I already have one client lined up, and their lawyers will be happy to deal with any 'confidential information' issues". I suspect mere mention of Microsoft would make Jobs mad and at least double the offer.
Then people started using Desk Accessories for things far beyond what was originally intended, then they became Desk Excessories.
In the days that your Mac-power-user-penis-length was measured every time you boot by how many extension icons plopped out along the bottom of the screen (and wrapped up to the next line), there was actually a coveted viagra-like meta-penis-extension that you could paste a bunch of ICON's into with ResEdit.
When you booted, it would sequentially plop all those icons out one by one, so it looked like you had as many extensions as you wanted, whatever you wanted them to look like! It would slow down your boot a bit, but it sure was worth it.
I actually wrote a commercial screen saver for a best selling utilities package when extensions became a thing. Nothing like mixing C with assembly in order to patch system traps.
Except most of the Inside Mac APIs were brought forward in OS X as Carbon. Carbon only went away relatively recently. So the APIs could support a reasonable OS, it's just Apple couldn't accomplish it for some reason (I waited for Copland for a long time).
I said most. Having worked on carbon apps, I can say that substantial portions went through with no changes. You could add menus and item to iTunes with AppendMenu() and InsertMenu() from visualization plugins until they rewrote it in Cocoa roughly 5 years ago.
Obviously they dumped a lot of the OS level APIs for stuff like Control Panels and Desk Accessories, but the standard app APIs were largely unchanged.
There's no fundamental reason they couldn't have made their own OS with the same Carbon APIs that made it into Mac OS X (not that I think they should have—the NeXTStep stuff was much better).
The early Macs were basically wide open, as I recall.
I was working in a group next to the systems software group at Apple when some of the early malware was discovered. After a few days of secrecy, with people being pulled into labs and conference rooms under spooky circumstances, the software managers sent out word that some malware had been found and that people were working on mitigations. They also said something like "Look guys, we know that writing malware is really easy, so don't do it, because we'll fire you immediately if we find out." I distinctly recall that this was in verbal instruction, not a memo, and that the words "really easy" and "really, don't do it" were used.
Naturally my response was to go back to my desk and write a proof of concept. Half an hour and a hundred lines of code later I had something that would replicate a payload whenever you inserted a floppy disk. It was indeed dead easy to do. I exercised my toy for a little while . . . then deleted every trace. I'm sure I wasn't the only engineer who was curious and did this.
So while you couldn't change the ROM, you could definitely muck with the system software, and that's all that really mattered. Zero thought had been given to MacOS security.
- no memory protection.
- system support for patching OS calls.
- no distinction in privileges between application and OS code.
- when mounting any disk, the OS opened a resource file on it
and kept it open. Side effect was that the OS would look for
code fragments defining windows, menus, and controls in that
file. That file normally didn’t contain any, but adding a
malevolent one to that file would mean the OS would run your
code as soon as any program created a standard window, menu
or control.
(That last part was fixed after a virus exploiting it was found)
With a description like that, he's got one confirmed pre-sale of that book. I'd pay up to $50 for it. Especially if he tells us what are the dozen core API calls that could replace X.
This is also an important example of how limiting an anti-social attitude can be when trying to collaborate and have a large affect on the world. As brilliant as Jon is, he wasted an inordinate amount of time making up for constantly insulting people, places, and approaches. (Even today he couldn't avoid insulting all of Tulsa OK).
Imagine where windowing systems could be if his brilliant work, API thoughts, and insights weren't delivered with insults, arrogance and vitriol.
At the end it is sad that he was proud of being right even though he was an _hole (his word). It could have been that he was right and his best ideas were in common use.
> how limiting an anti-social attitude can be when trying to collaborate
There are those of us who see collaboration as orthogonal to innovation and thus don't put any effort into it. Fortunately, there's a good mix of talent and dispositions out there to make up for it.
> Imagine where windowing systems could be if his brilliant work, API thoughts, and insights weren't delivered with insults, arrogance and vitriol.
Imagine a world where everyone is the same and has the same set of values. That may seem like paradise to some, but it sounds like doom to me.
> At the end it is sad that he was proud of being right
He was proud that he didn't compromise, even though that would've been easier, and no one would've faulted him for it.
I didn't realize people were so sensitive in the field. Compared to Linus, Theo de Raadt, Richard Stallman, etc, Jon seemed to be cruising at a comfortable level of Germanic straight-forward truth-telling, no real aholishness I could detect. Guess I should reset my etiquette and politeness filters.
I've read some of Don Hopkins' comments about all the cool things that were done with PostScript running in the NeWS server. I wonder, if NeWS had survived long enough that Sun had to add accessibility for people with disabilities (to sell to governments and schools if nothing else), how would they have done it? Today, the current state of the art is very chatty IPC (meaning tens of microseconds per cross-process call), partially assisted by bulk fetching and caching. To appreciate how bad that can be, think about a screen reader making at least one IPC call per word when reading text, to ask the application about word boundaries and bounding rectangles. That's a problem I hope to solve someday. In a parallel universe, though, maybe the screen reader is running inside the NeWS server, in the same address space as a PostScript-based UI toolkit.
I've written up some thoughts and discussions about accessibility and JavaScript, and discussed them a few times here!
I discovered the great work of Morgan Dixon and James Fogarty, which proves that you can do some amazing things with screen scraping, pattern matching, visual deconstruction, augmentation and reconstruction! His work needs to be combined with platform specific accessibility APIs via JavaScript.
I'm proposing "aQuery", a high level scriptable accessibility tool that is to native user interface components like jQuery is to DOM, for selecting and querying components, matching visual patterns, handing events, abstracting platform dependencies and high level service interfaces, building and scripting higher level widgets and applications, etc.
Morgan Dixon's and James Fogarty's work is truly breathtaking and eye opening, and I would love for that to be a core part of a scriptable hybrid Screen Scraping / Accessibility API approach.
Screen scraping techniques are very powerful, but have limitations. Accessibility APIs are very powerful, but have different limitations. But using both approaches together, screencasting and re-composing visual elements, and tightly integrating it with JavaScript, enables a much wider and interesting range of possibilities.
Think of it like augmented reality for virtualizing desktop user interfaces. The beauty of Morgan's Prefab is how it works across different platforms and web browsers, over virtual desktops, and how it can control, sample, measure, modify, augment and recompose guis of existing unmodified applications, even dynamic language translation, so they're much more accessible and easier to use!
Prefab: The Pixel-Based Reverse Engineering Toolkit Prefab is a system for reverse engineering the interface structure of graphical interfaces from their pixels. In other words, Prefab looks at the pixels of an existing interface and returns a tree structure, like a web-page's Document Object Model, that you can then use to modify the original interface in some way. Prefab works from example images of widgets; it decomposes those widgets into small parts, and exactly matches those parts in screenshots of an interface. Prefab does this many times per second to help you modify interfaces in real time. Imagine if you could modify any graphical interface? With Prefab, you can explore this question!
Imagine if every interface was open source. Any of us could modify the software we use every day. Unfortunately, we don't have the source.
Prefab realizes this vision using only the pixels of everyday interfaces. This video shows how we advanced the capabilities of Prefab to understand interface content and hierarchy. We use Prefab to add new functionality to Microsoft Word, Skype, and Google Chrome. These demonstrations show how Prefab can be used to translate the language of interfaces, add tutorials to interfaces, and add or remove content from interfaces solely from their pixels. Prefab represents a new approach to deploying HCI research in everyday software, and is also the first step toward a future where anybody can modify any interface.
Fascinating! What are some of the limitations of screen scraping that are addressed by accessibility APIs? Is it primarily the unreliability? Do you envision using an accessibility API as the primary source of information, with screen scraping as a fallback?
Accessibility APIs expose lots of rich high level information like associating a label with a widget (to name one simple example, but it gets MUCH more complex than that). And of course the position and meaning and state of each object on the screen.
There needs to be a higher level scriptable way to get a handle on all that complexity, like jQuery helps automate the creation and manipulation and abstraction of HTML DOM and events and handlers.
PhoneGap/Cordova plugins and NativeScript both take a similar approach: they have a generic Objective C / Java / Whatever <=> JavaScript bridge that lets you directly call all (or most) of the native APIs, including accessibility, directly on each platform. Then you write higher level platform independent APIs on top of the native APIs in JavaScript, a different one for each platform, but the same high level interface to JavaScript programmers.
I would try to use the native API as much as possible since they're precise yet tedious. It should have a platform-independent accessibility-specific selector language like xpath or jQuery selectors, which should be implemented efficiently in native code like querySelector. The pattern matching engine would send asynchronous events back to JavaScript. You could write JavaScript handlers for patterns of pixels as well as accessibility path patterns appearing and disappearing, like jQuery lets you bind handlers to patterns of DOM elements that don't exist yet, instead of concrete existing elements. Those handlers would create higher level widgets that could manage those existing pixels and widgets. (Like recognizing a youtube video player in any web browser window, and wrapping it in an aQuery widget implementing an abstract VideoPlayer interface, for example.)
Of course calling the native accessibility API is lighter weight than screen scraping and pixel matching, and you could use the native API to drill down to just the region of pixels you want to match or screencast, to minimize the amount of screen scraping and pixel matching required.
"A couple of decades ago I bough a Sun Ultra-60 and asked whether it was worth paying for the dual processor version.
The answer that I got was "Yes. You need one processor to run X and another for everything else."
People cursed with diskless Sun 3/50's would run xterms and emacs's across the net on each other's workstations instead of locally. It was noticeably less sluggish, because you didn't get hit with all the heavyweight process context switching between X clients and server every keystroke.
> The only really worthwhile thing about X was the distributed extension registration mechanism. All of the input, graphics and other crap should be moved to extension #1. That way, it won't be mandatory in conforming implementations once that stuff was obsolete. As you probably know, that's where we are today; nobody uses that stuff but it's like the corner of an Intel chip that implements the original instruction set.
On the other hand, all of the input, graphics and "other crap" being mandatory means that as a developer you can pretty much guarantee that they are there and if you care about having your stuff work everywhere (well, everywhere X is available anyway) you can simply rely on that without having to support a bunch of different APIs that may or may not be there (see the audio situation a few years ago in Linux).
(also FWIW a lot of people use the X primitives, not everyone uses Gtk or Qt)
I'm not quite sure I believe that a lot of people use the X primitives. The alternative to Gtk and Qt is most often not raw Xlib. There are alternative toolkits such as Motif, Xt. And then graphics abstractions such as SDL. Obviously all of these (including Gtk and Qt) use at least some of the X primitives in their rendering or themeing engines, but direct use of Xlib primitives is quite rare. And I think the whole point of the argument is that the commonly used primitives today are things like XRENDER, which aren't really primitives since they are an extension. Precisely the point being made.
Basically, name me an app that uses solely X11 primitives without the use of any extensions and no overlying library over libX11 (and no, xclock doesn't count)
Of course i include using toolkits that themselves use X primitives, not only using Xlib directly :-).
For example my own Little Forms library [0] uses the X server's drawing and text operations (you can use Xft instead, it is a build option, but you can also make a static library for binaries that rely only on xlib and nothing else).
Using X primitives means not using X extensions. Using toolkits like Motif remains a simple use of Xlib primitives and most of the code of a Motif application involves direct Xlib primitives.
Yes, the 2d primitives in X are actually fine -- a bunch of dumb obvious primitives of the kind that just about every graphics system has.
Where it fell down was all the complication about XVisuals and colours etc. Those things were solving real problems for the era but doing so with an unnecessarily complicated interface that tied the 2d-primitives and much else into the assumptions of that era.
Thus as things developed, whole new APIs like XRender had to be invented in order to do the dumb basic primitives again.
I beg to differ. X11 2D primitives are "actually fine" in the same sense that there were "very fine people" marching in Charlottesville. By which I mean "not actually very fine". ;)
But I totally agree with you about colors (the X approach to device independence is to treat everything like a MicroVAX framebuffer on acid), and xRender (which was wonderful work that transcended X11 and led to Cairo and html's canvas).
And don't get me started about window borders, and the SHAPES extension, and their fractally complex interactions!
A task as simple as filing and stroking shapes is quite complicated because of X's bizarre pixel-oriented imaging rules. When you fill a 10x10 square with XFillRectangle, it fills the 100 pixels you expect. But you get extra "bonus pixels" when you pass the same arguments to XDrawRectangle, because it actually draws an 11x11 square, hanging out one pixel below and to the right!!! If you find this hard to believe, look it up in the X manual yourself: Volume 1, Section 6.1.4. The manual patronizingly explains how easy it is to add 1 to the x and y position of the filled rectangle, while subtracting 1 from the width and height to compensate, so it fits neatly inside the outline. Then it points out that "in the case of arcs, however, this is a much more difficult proposition (probably impossible in a portable fashion)." This means that portably filling and stroking an arbitrarily scaled arc without overlapping or leaving gaps is an intractable problem when using the X Window System. Think about that. You can't even draw a proper rectangle with a thick outline, since the line width is specified in unscaled pixel units, so if your display has rectangular pixels, the vertical and horizontal lines will have different thicknesses enen though you scaled the rectangle corner coordinates to compensate for the aspect ratio.
I beg to differ. X11 2D primitives are "actually fine" in the same sense that there were "very fine people" marching in Charlottesville. By which I mean "not actually very fine". ;)
Probably we are agreeing past each-other. I meant they were OK in a very board sense that you want primitives for drawing lines, drawing polygons, filling things, blitting things etc. I think you agree with me about that.
And I also think we both agree that the details of those primitives in X11 were a disaster.
Yeah the details are kinda weird (although i wonder if there is some reasoning behind that because Windows also has the same off-by-one-pixel thing - and even more confusingly it is done through the same API call but it is a special case when you use a null pen) but for me the most important thing is that they are there and you can safely rely on that they are there despite the weirdness.
Off-by-one pixel stuff is not surprising in world where your API deals explicitly with individual pixels. Newer systems are a bit simpler here because they treat the screen as continuous plane that only gets mapped to pixels at the last moment.
The flip side is that you have to worry about weird aliasing (or anti-aliasing!) artifacts, such as black lines turning grey.
I don't know where to begin, or when to stop, so I'll pick something at random and jump around.
NeWS 1.1 was layered on top of PixRects (the graphics library that SunView was built on top of), which gave it the weird limitation that sub-windows could not be positioned above or to the left of their parents (sub-window coordinates were unsigned), which was a huge pain in the ass for making all kinds of user interfaces.
X11/NeWS solved that problem by having a much nicer PostScript graphics renderer and compositor, but it came with its own set of problems, many having to do with being nailed together with a X11 server with a totally different graphics model and approach to life.
But there were some really cool things you could do with X11 and NeWS together, like managing X11 windows with NeWS frames (which could have non-rectangular windows like jutting title tabs, round pie menus, panning virtual desktops, rooms, etc).
Another important point is that running the window manager in the same heavy weight Unix process as the window server saves an astronomical number of costly context switches, and results in much smoother user interface with silky local feedback. Plus it's extensible and customizable and drawn in PostScript.
Here's a demo of NeWS window frames with tabs and pie menus. We used those to made an ICCCM X11 window manager written in PostScript (that Sun never released) that let you use those tabbed window frames and pie menus and other NeWS components to manage all of your X11 windows (and use them as your default frame for NeWS apps too, of course), seamlessly integrating X11 and NeWS apps together.
Here are some flames and notes I wrote years ago about X11 and NeWS window management -- the "OWM" section is about the NeWS X11 window manager. It covers some of the political and technical problems we had integrating X11 and NeWS. Window management is a surprisingly contentious issue! Everybody wants to be on top.
Basically, we didn't want to put our round NeWS pie menus and pizza windows inside of their rectangular X11 ICCCM window frames, because it would have been better for everyone the other way around.
Josh Siegel wrote this beautiful PostScript tour de force swan song for X11/NeWS, an ICCCM window manager that actually worked quite well, with special window subclasses to support all the OPEN LOOK dialog types and window frame features through their standard X11 ICCCM properties! Check out "ClassX11ManagerMixin", which is what it sounds like. It's mixed into FavoriteBaseWindow, which can be redefined to the custom ClassTabBaseWindow supporting tabs and pie menus, shown in the above video, or any other kind of frame you want to wrap around X11 windows:
It was a proof of concept, which we wanted to take a lot further by implementing a HyperCard-like user customizable persistent window manager with HyperLook. So users can edit and build their own custom window frames by copying, pasting and configuring scriptable components from object warehouses, edit and extend the user interfaces of running apps, and make high level task-oriented interfaces by composing widgets and apps into "cards", "backgrounds", "stacks" and optional network "clients". But that's not how things turned out. ;/
I'll excerpt the relevant parts of the i39l flames:
Who Should Manage the Windows, X11 or NeWS?
This is a discussion of ICCCM Window Management for X11/NeWS. One of the horrible problems of X11/NeWS was window management. The X people wanted to wrap NeWS windows up in X frames (that is, OLWM). The NeWS people wanted to do it the other way around, and prototyped an ICCCM window manager in NeWS (mostly object oriented PostScript, and a tiny bit of C), that wrapped X windows up in NeWS window frames.
Why wrap X windows in NeWS frames? Because NeWS is much better at window management than X. On the surface, it was easy to implement lots of cool features. But deeper, NeWS is capable of synchronizing input events much more reliably than X11, so it can manage the input focus perfectly, where asynchronous X11 window managers fall flat on their face by definition.
Our next step (if you'll pardon the allusion) was to use HyperNeWS (renamed HyperLook, a graphical user interface system like HyperCard with PostScript) to implemented a totally customizable X window manager!
Some notes about OWM
OWM is the "Open Window Manager" we prototyped in NeWS. We enhanced the NeWS window frames so they sported indexing tabs, pie menus, rooms, and a scrolling virtual desktop. Many of our enhancements were separatly developed, and plugged together orthogonally like legos. All NeWS applications could use these fancy frames, and the Open Window Manager wrapped X clients in the same frames that NeWS windows got!
This way, factoring the window frames out as a part of the toolkit, and implementing the X window manager separately, NeWS applications don't have to know a thing about X window management, and X clients can go on doing the same nasty things they've always done, and everybody get the benefits of dynamic extensibility, and a consistent user interface, by using the default window class!
X11 window managers must grab the server in order to animate rubber-band feedback over the screen when resizing and moving windows. This grabbing causes many problems with NeWS synchronous interests, that can be demonstrated by pressing the "Help" key while dragging out a rectangle on the root background. NeWS can do a much better job at managing global resources in the server because it is in the same address space and it has facilities like the overlay plane specifically designed to implement such window management functions, without even grabbing the server. This antisocial server grabbing behavior is just one symptom of a general class of problems with external X window management, including other important issues such as keyboard and colomap focus.
Don, thank you for all the details. I've enjoyed your writings since I found your website in 2000. Too bad NeWS didn't take off. What would it take to revive it? Is the Linux framebuffer stable enough to have another go at it?
> X11 window managers must grab the server in order to animate rubber-band feedback over the screen when resizing and moving windows.
I wonder how the comparison between X11 & NeWS works once when switches to tiling window managers, which require much less work & chrome from the WM.
If tiling WMs favour the X model, I wonder if the real reason so many of us like them is that they are faster, rather than tiling being a better paradigm. I suspect that's not the case — at this point, tiling really feels better to me — but maybe it is?
I think the benefits of extensibility far outweigh any differences from whether the window manager supports tiling or overlapping windows. Ideally it should be general purpose enough to support both.
Having an extensible window server enables you to use simpler but powerful primitives (X windows -vs- NeWS canvases, or server grabs + XOR RasterOps -vs- overlay canvases and hardware overlay planes), then implement the higher level stuff flexibly in software: see my other message about the complexity of X window borders, backgrounds and shapes, and how it makes shaped windows unbelievably complicated, even though nobody actually ever needs to use that complexity.
NeWS canvases don't need special built-in borders, because the PostScript interpreter and stencil-paint graphics model's clipping path elegantly solves the problem that X window borders were trying to solve (but didn't solve well enough for anyone to ever use), and solve many more problems in a much more general way.
NeWS had an overlay canvas for non-destructively drawing rubber band feedback over the desktop, which used hardware graphics planes if available, or fell back to using a display list and XOR RaserOps on monochrome or simple 8 bit displays.
Some of the popular Sun color framebuffers (cgsix and gx maybe?) had 8 bits of color pixles and a two bits of overlay planes for cursors and black-and-white windows. SunView knew how to use it for the cursor and light weight monochrome windows, and NeWS used it for the overlay plane, which was perfect for window management and rubber band feedback.
Drawing the cursor in the overlay plane actually sped up graphics performance a surprising amount, since the drawing code didn't have to always check if the cursor was overlapping where it was about to draw, then hiding and redrawing it before and after drawing anything on the screen under the cursor.
NeWS could directly open framebuffers on the overlay plane (1 bit black and white) and overlay enable plane (1 bit that switches between the showing the black and white overlay plane, or showing through to the color framebuffer). Then you could draw on the overlay enable plane to flip between the black and white and color framebuffers on a per-pixel bases (useful for making rubber bands, text labels, 50% checkerboard shadows and highlights, etc).
SGI's 4Sight (their own port of NeWS 1.1 that they integrated with X11 and GL, before Sun's X11/NeWS) also supported hardware overlay planes, and used them for the pop-up menus, so it didn't have to repaint the thick 24 bit graphics underneath the thin monochrome menus when they popped down. My NeWS pie menu code "just worked" in the overlay plane with only a little modification, except that I had to special-case the color wheel pie menu to not use the overlay plane, because the overlay planes weren't allowed more than three colors (black, white, one user defined color, and transparent).
If you're into the history of window management, here's some fascinating stuff about the evolution of window managers, including Andrew, which is a tiling window manager that Gosling and Rosenthal worked on at CMU before NeWS. It also discusses and compares PERQ PNX, APOLLO, SunWindows, MG-1, Sapphire, BLIT, Smalltalk, DLISP, Interlisp-D, Tajo/Mesa, Cedar Docs and Viewers, Star, Viewpoint, and even SunDew (NeWS).
By F R A Hopgood, D A Duce, E V C Fielding, K Robinson, A S Williams. 29 April 1985. This is the Proceedings of the Alvey Workshop at Cosener's House, Abingdon that took place from 29 April 1985 until 1 May 1985. It was input into the planning for the MMI part of the Alvey Programme. The Proceedings were later published by Springer-Verlag in 1986.
Here is some of the ui working group discussion specifically about tiling windows:
17.2 INTERFACE TECHNIQUES
Some of the issues supplied to the Working Group were felt not to be issues at all; as an example, tiled and overlapped windows were seen to be merely options that the user interface designer could use if appropriate. Indeed, a user connected to more than one host, one providing a tiling environment and the other not. might well have both mechanisms to interact with at the same time.
Window grouping and subwindows received some attention. A subwindow is not necessarily identical to a window: for example a subwindow receiving input it does not understand refers it to the parent for treatment, and if a parent window is deleted then so are its subwindows. Subwindows in some systems can overlap. while others permit only tiling. Title lines, which can be considered as a form of subwindow. may need to be accessible to the application.
With X11/NeWS, you were running two window systems at the same time on one machine, right out of the box!
Even with NeWS 1.1, you were still running parts of SunView underneath.
One cool thing that X11/NeWS could do was that X11 clients could transparently use scalable PostScript fonts, including the nice hinted "Folio" fonts, and even "user defined fonts" written in PostScript like the Hershey and Dijkstra fonts. The X11 server could call back into the NeWS PostScript interpreter to render the font at any point size!
Through most of that article I was thinking "Yep, that's the kind of train-wreck you get when you design by committee, or worse by political need".
But toward the end, he says that the particular kind of technical train-wreck that they got was similar to the Mac API (presumably the this means the pre-OS X OS). "[As a resulting of accidentally being lots of databases] the X API is wide and shallow like the Mac, and full of interesting race conditions to boot."
Anyway, I didn't think that design by committee was one of Apples weaknesses.
I doubt it will come as a surprise to anyone that X was fundamentally ill conceived from the very beginning. It’s one of those unfortunate side effects of unintended consequences that Unix history saddled us with it for twenty years longer than we’d ideally have wanted.
It fascinates me that something so widely regarded as Bad and Wrong, proved so hard to replace when it’s baked into a system. I think there’s a cautionary tale about the necessity of getting your core APIs right, because you might never be able to get rid of them.
For starters having been written in C, after the Assembly and B rewrites, when we already had safer systems programming languages in the early 60's.
IBM for example did most of their RISC research with an OS written in PL/8, where they prototyped many ideas about modular compilers, a few of them visible in how LLVM works.
Then by being a plain CLI based OS versus what was being done at Xerox PARC with Xerox Star and Pilot (done in Mesa).
NeXTSTep was probably the only variant that got close of the Mac, Amiga and Atari multimedia capabilities, and even it wasn't a pure UNIX, rather used it as a means to bring applications into the NeXT world.
Many mainframe ideas about OS security are still not part of any UNIX clone, as another example.
Thank you for explaining. I disagree, but then, I started with the Commodore 64 and BASIC, and have missed them ever since. C and LISP version 1 sort of fit in the same space. I hate any language that hides the machine from me. Also don't really like clicky gooey stuff. Text and typing is where it is at. Matter of taste really. But newLISP is a good mix of hardware access with safety.
The comment about how X is really just a distributed database system with occasional visual side effects that could be reduced down to 10 or so API calls gives us a glimpse as to what life could have been.
It's a shame that all of the X replacements on the horizon also ditch the network transparency part, even though that's been a killer feature for me. I hate how much of a hack Remote Desktop is on Windows machines.
> It's a shame that all of the X replacements on the horizon also ditch the network transparency part, even though that's been a killer feature for me.
I've used ssh -X many times in my life, but at the same time, I understand why network transparency doesn't make as much sense anymore.
Classically, the X protocol kept a huge amount of state on the server, and clients would just send small requests to manipulate that data. Drawing would take place server-side, and it was relatively simple drawing at that, since UI needs were fairly modest. Text rendering occurred on the server with small strings sent from the client. And overall, it made sense to send a small amount of data to produce a large amount of graphics.
These days, however, rendering occurs almost exclusively on a combination of the client and the GPU. Everything takes place via large memory buffers, and compositing. And pushing those over the wire doesn't work nearly as well; if you're going to do that, you need protocols designed for it, with compression and delta-encoding, much like modern video codecs (but optimized for remote-desktop).
So I think it makes sense that network transparency is being rethought, in favor of protocols that look a lot more like remote-video (and remote-audio).
People not familiar with X reading the above (which is correct) might miss that client/server is reversed from the way most people think about it. For X, the server is the system where the display/keyboard/UI is physically attached and the client is the host (remote host for this discussion) where the application is actually running.
Ah, fair point. I've been around X for so long that I'd forgotten that being a point of confusion. I do think it makes sense in the sense that the "server" provides the resources and the client connects to them and uses them, but it definitely takes a bit of getting used to.
Like in DLNA, which repeatedly confuses-slash-aggravates me for no good reason.
Except that DLNA has that third controller role that's usually taken over by either the client or the server, plus the confusion added by openhome servers with playlists (made even more confusing/annoying for me, since mine is provided by a fourth service/proxy, BubbleUPnP).
Standard DLNA is easy to remember, however, as long as you know the terms--[file]server, renderer, and controller. It even uses http for the fileserver (not sure if that's part of the standard or not though)
Yes. Server is used to mean serving graphics visually, the display server, not in the sense of remote processing.
I don't know why this is confusing to people, at least if they understand sockets. The display server does listen(2). The application does connect(2). Why is that hard?
Windows and Mac use similar terminology to "display server" too, but I guess those are proprietary components that few people look into...
I understand sockets and I understand how X works, and I think it's confusing and stupid. It places unnecessary emphasis on an implementation detail that is unimportant to the end user.
Then say "app" or "program" instead of "x client" and nobody is harmed ... If people say "x client" it's usually in a more architectural, less colloquial context to begin with.
Both web client/server and X client/server nomenclature define what client and server mean in very specific (but opposite) technical ways, but I think both definitions limit how people think about what's really going on -- it's not so asymmetrical.
Actually, I think of the client/server relationship as a higher level abstraction above the mechanics of the actual socket connection, which can go either way, or both, or many relationships at the same time in different directions and between different sites.
All sites can offer any number of different asynchronous message based services to each other at all times.
It shouldn't matter who was listening, who connected first or how they connected, just that all sites can send messages back and forth on the same channel. It could be UDP, multicast, WebRTC, distributed peer to peer, or a central message dispatcher.
A (web client / X server) site with the display and GPU and mouse offers presentation and rendering and input services to different (web server / X client) sites, which themselves offer database and storage and computing services the other way, at the same time over the same channels.
> Both web client/server and X client/server nomenclature define what client and server mean in very specific (but opposite) technical ways
That's just false. A web server listen(2)s/accept(2)s. A web browser or other HTTP client connect(2)s. An X server listen(2)s/accept(2)s. An X client connect(2)s.
In either case it would not make sense to invert this relationship. In both cases a server is an endpoint that serves its resources to multiple clients. Are people advocating conceptually that the graphics card connect to its programs, and not the program request access to it? That makes very little sense. Just like a web server would not proactively connect to its end user web browsers. The requests happen in the other direction.
I'm saying that client/server has a meaning that's independent of who initiates the connection, or what kind of connection it is.
For example, whether you weed dealer "Dave" calls you on the phone and tells you he can drop by if you're interested, or if you call "Dave" and ask him to drop by, "Dave" is still the server, and you're still the client.
You and your drug dealer are not computer programs operating over a socket. You are using a different definition of "client" to mean "purchaser". You may find that to be a useful description in that context but in a computer context it sounds like you are being intentionally vague.
I thought I was being intentionally pretty specific that client/server relationships can go both ways, at the same time, regardless of which side initiated the connection. Once you have a connection, no matter which side initiated it, or even if they both just randomly met in Linda tuple space like ships in the night, each side can offer services to and consume services from each other.
https://www.xpra.org/ is an example of the video-codec style approach, it is per application/window like X11 and it is extremely usable even over very poor network conditions, and handles 60fps audio and video brilliantly.
Well worth checking out.
xpra is my favored tool out of plain X forwarding / vnc / (free)nx / x2go / etc, but one issue I have with it (at least last time I used it) is that it requires the version string to be identical on both client and server. This, combined with it being written in python, means that every distro packages it differently, has a different version number, and if you want to just clone it and run it yourself, now you have to deal with python / virtualenv / whatever hell.
Other than that, it's pretty great.
If you believe the README.txt files of downloads from The Pirate Bay, there exist some amazing video codecs that are so new and advanced that they can actually play episodes of Rick and Morty that haven't even been released yet! It's almost as good as inter-dimensional cable TV. And they are totally free: you just have to download and install some binary codecs from some Russian web site before watching the video.
> I've used ssh -X many times in my life, but at the same time, I understand why network transparency doesn't make as much sense anymore.
ssh -X is useful for something like clipboard forwarding from your local desktop to remote server (and back). You can work in something like nvim remotely, and have a nice clipboard integration. What will happen with such functionality after the switch to Wayland?
This is an unpopular opinion, but using vi over ssh - or any editor - has always struck me as a hack. You get high keystroke latency if the server is far away, which seems to bother me more than most people (in part because it’s unnecessary). You don’t have your settings and bindings by default, so you have to either get used to the default experience or copy your settings onto every server you use. Similarly, you get some random version of vim by default (not nvim), so if you want the latter, or any other editor, you have to install it. If the device you’re SSHing into is an embedded system like a router, that may be difficult or impossible or at least waste valuable disk space. And you’re stuck with a terminal, no GUI (even vim has some enhancements in GUI mode) - that is, unless you use X forwarding, but that’s an even bigger wasteful installation, given that most servers have no business having the X libraries installed.
In theory, a saner approach is using a local editor to edit remote files.
But people don’t do that. Why? Because the available implementations suck. NFS sucks because it’s slow and hangs your programs; sshfs is the same but worse. Vim has native remote file support in the form of scp://, which invokes the scp command every time you open or save a file - synchronously, so even if you’re saving you have to wait. This might be vaguely tolerable if you configure ssh to share connections, but in general it sucks. And with any of those, you have to set up a separate connection to the server and re-find the directory you’re in, which may or may not be time consuming. By contrast, typing vi into the SSH prompt usually just works, so that’s what people do.
But there’s no fundamental technical limitation here. Imagine if you could type ‘edit foo.conf’ on the server and have it pop open a native editor on the client side. File transfer would be tunneled through the existing SSH connection, with no setup time or need for re-authentication; it would be fully asynchronous, so the editor would never hard-block waiting for an operation to complete, but it would still indicate when saves have been completed, so you know when it’s safe to run commands on the server that use the new files. Thing is, none of what I just said is especially complex or challenging from a technical perspective; it’s just that it would require changes to a bunch of components (ssh on the client and server; vim) that weren’t designed with that use case in mind.
Anyway, I’m getting a little off topic here - but I think the point generalizes. In my ideal world, the future of X forwarding would be fixing the most common use cases so you don’t need X forwarding. For the rest, well, the ‘server sets up a tunnel over SSH’ approach could work just as well for VNC, or for an improved remote display protocol that uses a video codec.
In the real world, I suppose things will just fester, remote display support will get worse, and remote editing will continue to suck. But I can dream. Or maybe implement something myself, but there are so many other things to do…
>A saner approach would be based on a local editor editing remote files.
Yes, this is the basis of the very popular and widely used TRAMP component in Emacs.
>Imagine if you could type ‘edit foo.conf’ on the server and have it pop open a native editor on the client side.
Yes, this is possible with emacsclient.
Are you sure? I don’t have any experience with Emacs, but…
> Yes, this is the basis of the very popular and widely used TRAMP component in Emacs.
I’m sure TRAMP is better than vim’s netrw, but at least according to [1] it’s not fully asynchronous. It also seems to require a separate SSH invocation; I know you can configure SSH to reuse physical connections, but at least when I once tried it, it didn’t work very well…
> Yes, this is possible with emacsclient.
Judging by [2], it doesn’t seem to work well for that use case (talking to emacs over an SSH tunnel)… Assuming you can get it to work, can you make it work with multiple SSH connections to arbitrary servers, without any per-server configuration? If so, that’s quite interesting and maybe I should check it out. If not, then it still may be quite useful, but it wouldn’t be versatile enough to truly render editor-over-SSH unnecessary.
[1] https://www.reddit.com/r/emacs/comments/23dm4c/is_it_possibl...
[2] https://emacs.stackexchange.com/questions/15144/emacsclient-...
TRAMP reuses ssh connections. It's straightforward to configure OpenSSH to reuse its connection, see e.g. https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Multiplexing and that is what TRAMP does.
>Can you make it work with multiple SSH connections to arbitrary servers, without any per-server configuration?
Certainly, of course. Depending on your level of hackery, you can: - Make ssh automatically copy an emacsclient wrapper script over which does the correct thing - Use OpenSSH's Unix socket forwarding on each connection to connect emacsclient to your local Emacs server - Use https://github.com/magit/with-editor
I've never bothered, though, because I run all my shells on remote hosts via TRAMP within Emacs, so when I am in a shell, I can just use open the remote files through the normal Emacs keybindings, rather than typing "emacsclient filename". Thanks to with-editor, this also extends automatically to commands invoked on the remote host which run $EDITOR.
>I don’t have any experience with Emacs, but…
It's not surprising. :) You said "using vi over ssh - or any editor - has always struck me as a hack", "is an unpopular opinion". In fact, it's the consensus in Emacs land. :) Though perhaps that doesn't prevent it from being an unpopular opinion, these days. :)
I would suggest taking a look at https://nuclide.io/docs/features/remote/ for imo, best in class for what you're talking about. Most editing at Facebook is done on a remote server, so the infrastructure people at FB have done a pretty good job on shoring up a lot of the issues.
It has a lot of what you're talking about. Typing `atom foo.conf` to open up files locally. Keeping the same connection open and reconnecting without needing to reauthenticate with SSH.
There's also a lot of other stuff that needs to be handled. File searching needs to be hooked up a reasonable way. Language services do as well.
Facebook has done a great job with remote editing (although I don't think the open source version of Nuclide is a priority).
What you have described here for text editing holds true for any other action on files that you intend to do while remote logged onto that other box. Why use the local ls, less, etc, while you have better versions at home? Indeed, why would you use the remote default bash instead of your properly configured zsh, to begin with?
It seems when you connect on a remote box many times what you really want is to import its files. But despite there have been a lot of network shared file systems none seams to have become the obvious solution, supposedly because it's hard to fix that problem efficiently in the general case, especially for an operation system, Unix, that attach to files an API that have not been designed for this.
If you use an old enough editor, they've designed around limited bandwidth for screen updates, and they tend to work ok with high latency. Usually, when I'm doing editing, I don't necessarily need to see the screen update until I'm done typing a line (although getting the cursor in the right place can be painful beyond maybe 100ms roundtrip, especially if it's inconsistent)
A split editor, with a local ui and filesystem remote can be made to work, but you do have to install something on the remote end, which brings you back to the remote end doesn't have the environment you want, so you just suffer with whatever is there problem.
I agree, that local editing of remote files would be better, but as you said, current options are pretty bad. Latency is still there, except it's in the filesystem level and file operations, rather than interaction with the editor itself.
I.e. both methods have their trade-offs. I find using remote nvim easier, even if you have to install and configure it first. At least if we are talking about some stable commonly used environment, and not about ad-hoc editing, in which case remote mounting might be a better option.
Isn't that the use case for sshfs? NFS but secure.
NFS stands for No File Security.
Nice idea, but there are occasions when I find myself on a Windows box (which I normally never use) using putty, or my iPad using vSSH and I have no local editor (or editor that I would use, in the case of Windows).
Network transparency lets headless compute servers in distant datacenters take advantage of the powerful GPU under my desk. To me one monitor per GPU makes a lot more sense than n cores per GPU plus the extra bandwidth for live video.
Split the pie into three pieces:
You want 1,2 to run on compute servers and 3 to run locally.Some other people want 1 to run on compute servers and 2,3 to run locally.
I really don't think it matters where 2 runs as long as 1 is fast and 3 is responsive.
X also makes all these very low level assumptions that crosscut all parts of the API, that simply don't apply any more (and didn't actually apply in the first place).
"Mechanism not policy" my ass. X window borders are an archetypal example of the hollowness of that oft-repeated slogan. The slogan should have been "We must strengthen our borders to protect our precious bodily fluids!" ;)
X windows all have a bunch of properties and messages and parameters relating to how to draw window borders in the server.
They have a border width, and a pixel value. They can even have a border pixmap that is tiled with the same origin as the background tile origin (hope that works for you!).
The rationale was that the server could instantly draw window borders and backgrounds before the client refreshed, to give you a bunch of stippled rectangles to look at while you waited for the client to send some drawing commands.
While NeWS's solution was simply for the server to call a PostScript procedure to instantly draw whatever kind of elaborate border plus anything else it wants the user to see (and interact with), without waiting for the client.
Nobody, but NOBODY uses window borders any more. Only the earliest ugliest toolkits like Athena (Anathema) widgets did. It was a terrible idea to build borders into the window system at that level (POLICY!!!), because nobody ever wants to draw borders in a special but extremely limited way built into the window system at a low level, and then draw the rest of the user interface some other way.
X window borders were totally useless for drawing the brutal beveled edges that were fashionable at the time, or even rounded rectangles. Supporting that would be policy! But go to town and express yourself with tiled pixmap borders, that's pure mechanism baby!
https://tronche.com/gui/x/xlib/window/attributes/border.html
https://tronche.com/gui/x/xlib/window/XSetWindowBorder.html
https://tronche.com/gui/x/xlib/window/XSetWindowBorderPixmap...
Then along came the SHAPE extension.
You'd think it would be straightforward to make an extension that lets you simply set the shape of a window by defining a region somehow.
But no, thanks to borders, each window's shape is defined by TWO regions: the smaller inner client clipping region and the larger outer border bounding region. Well actually it's more than two -- a lot more: There's also their rectangular default core protocol size (both with and without borders), which can be totally different than either of those two other regions's sizes, and modify the effective region.
In summary there are bounding, clip, default bounding, default clip, client bounding, client clip, effective bounding, and effective clip regions. Got it?
Of course all of those regions will almost always be the same since nobody actually uses borders, but thanks to the borders on every window that nobody uses, the SHAPE extension is an order of magnitude more complicated than it needs to be, and even includes a handy glossary and travel guide to all of its various regions.
https://en.wikipedia.org/wiki/Shape_extension
The extension allows defining the shape of two separate regions: the clipping and the bounding regions. These two areas are defined even for windows not using the shape extension: the clipping region is the area that can be used for drawing, the bounding region is the total area covered by the window (that is, the clipping region plus the border). The shape extension allows defining two independent shapes for these two regions.
Both the clipping and bounding are associated, in the shape extension, two areas: a default rectangular region and a possibly non-rectangular client region, defined and changed by the client as specified above. The effective region, which is the actual shape of the window, is the intersection of these two areas. This intersection is performed every time either region is changed: for example, if the client regions contains parts that are outside the default region but the default region is then enlarged, the effective region will include these parts.
https://www.x.org/releases/current/doc/libXext/shapelib.html
Status XShapeQueryExtents(Display display, Window window, Bool bounding_shaped, int x_bounding, int y_bounding, unsigned int w_bounding, unsigned int h_bounding, Bool clip_shaped, int x_clip, int y_clip, unsigned int w_clip, unsigned int *h_clip);
The border of a window is defined to be the difference between the effective bounding region and the effective clip region. If this region is empty, no border is displayed. If this region is nonempty, the border is filled using the border-tile or border-pixel of the window as specified in the core protocol. Note that a window with a nonzero border width will never be able to draw beyond the default clip region of the window. Also note that a zero border width does not prevent a window from having a border, since the clip shape can still be made smaller than the bounding shape.
Glossary
bounding region: The area of the parent window that this window will occupy. This area is divided into two parts: the border and the interior.
clip region: The interior of the window, as a subset of the bounding region. This region describes the area that will be painted with the window background when the window is cleared, will contain all graphics output to the window, and will clip any subwindows.
default bounding region: The rectangular area, as described by the core protocol window size, that covers the interior of the window and its border.
default clip region: The rectangular area, as described by the core protocol window size, that covers the interior of the window and excludes the border.
client bounding region: The region associated with a window that is directly modified via this extension when specified by ShapeBounding This region is used in conjunction with the default bounding region to produce the effective bounding region.
client clip region: The region associated with a window that is directly modified via this extension when specified by ShapeClip This region is used in conjunction with the default clip region and the client bounding region to produce the effective clip region.
effective bounding region: The actual shape of the window on the screen, including border and interior (but excluding the effects of overlapping windows). When a window has a client bounding region, the effective bounding region is the intersection of the default bounding region and the client bounding region. Otherwise, the effective bounding region is the same as the default bounding region.
effective clip region: The actual shape of the interior of the window on the screen (excluding the effects of overlapping windows). When a window has a client clip region or a client bounding region, the effective clip region is the intersection of the default clip region, the client clip region (if any) and the client bounding region (if any). Otherwise, the effective clip region is the same as the default clip region.
With X, the roles of the client and the server are reversed: the client with the GPU connecting over ssh -X is the X11 server, so your point is, well, beside the point.
In the old days it was convenient to be able to run a SunOS binary on a remote server and display on a Linux machine -- but this can't be as common today.
The way X clients can be forwarded over SSH implies that network transparency doesn't need to be built in to the window system, there just needs to be a "seam" at which it can be interposed. Obviously any kind of direct access to graphics hardware makes this impractical.
Plan 9's window system uses the 9p file system protocol to cross the network; another Bell Labs trick (used in Rob Pike's Sam editor) is for the app to be split into two parts with their own internal interface. They can run on different hosts. The internal protocol/interface can be tailored to the app (and can potentially be very simple and/or efficient).
Once you've created a seam (possibly a unix socket, many of my designs rely on those) exposing the same socket over TCP becomes relatively trivial and now you effectively have network transparency anyway (see also spiped).
But, yeah, so long as the client is a separate process, getting it transited over the network can be done separately.
Agreed, though exposing/using a bare TCP socket comes with security responsibilities that you are forced to address -- it's good to devolve those.
See also: spiped
Heh, reminded me of running Internet Explorer and Outlook Express on a university Solaris box and had it displaying at home on an OpenBSD laptop...
(yes, IE & Outlook had UNIX versions: https://en.wikipedia.org/wiki/Internet_Explorer_for_UNIX)
I prefer every other OSes remote desktop, because I can detach and reattach them in different computers.
Rightly or wrongly, modern GUIs tend to be sufficiently graphical that X turns into effectively sending bitmaps anyway, so in my experience a lightly compressed VNC is more responsive.
It is nice that in X individual windows can live independently, but adding that to your windowing manager feels like less work, and is how for example windows works nowadays (don't know other windowing systems well enough).
I made the X11 SimCity code that updates the small map (which usually has only a few pixels changed, but sometimes has many pixels changed) compare the "before" and "after" images and count the differences, and if there were few enough differences, it would sort the changed pixels by color, then send batches of XDrawPoints of each color.
In X11 it is just as expensive to change the foreground color as to draw one dot (since all the overhead is sending the command), but you could efficiently draw a lot of dots of the same color with XDrawPoints, so it was worth it to sort the pixels by color and then draw them in a few same-colored batches, instead of switching colors between each pixel you draw.
I disabled that crazy code for the OLPC port since it was always running locally and XPutImage would always always use the shared memory extension, but in the days when you wanted to run remotely over a slow network, or the local server didn't support the shared memory extension, it was well worth doing all the work of comparing and sorting individual pixels to incrementally update the map!
https://github.com/SimHacker/micropolis/blob/master/micropol...
(I'm sure that code used to work on old 8 bit displays, but for some reason I never bothered to figure out, it was buggy on the OLPC's 24 bit visual, so I #if'ed it out of its misery. That's X11 for you.)
https://github.com/SimHacker/micropolis/blob/master/micropol...
> I prefer every other OSes remote desktop, because I can detach and reattach them in different computers.
You can do that on various Linux distros with xpra [1].
[1] https://www.xpra.org/
And before that there were always xmove...
https://en.wikipedia.org/wiki/Xmove
It's a shame that all of the X replacements on the horizon also ditch the network transparency part, even though that's been a killer feature for me.
Don't worry, in time everything will be re-invented on the web. With WebGL, the browser becomes just like an X server, only with a far richer feature set for malware authors.
> I hate how much of a hack Remote Desktop is on Windows machines.
People just don't seem to get this. If I can't alt-tab between windows, remote GUI apps are next to useless for me. It breaks my workflow. I hit this speebump all the time when working with VMs and RDP.
"Had he done some real design work and looked at what others were doing he might have realized that at its core, X was a distributed database system in which operations on some of the databases have visual side-effects. I forget the exact number, but X includes around 20 different databases: atoms, properties, contexts, selections, keymaps, etc. each with their own set of API calls. As a result, the X API is wide and shallow like the Mac, and full of interesting race conditions to boot. The whole thing could have been done with less than a dozen API calls."
To that end, one of the weirder and cooler re-implementations of NeWS was Cogent's PIX for transputers. It was basically a NeWS-like multiprocessing PostScript interpreter for Transputers, with Linda "tuple spaces" as an interprocess communication primitive:
http://ieeexplore.ieee.org/document/301904/
The Cogent Research XTM is a desktop parallel computer based on the INMOS T800 transputer. Designed to expand from two to several hundred processors, the XTM provides a transparent distributed computing environment both within a single workstation and among a collection of workstations. Using Linda tuple spaces as the basis for interprocess communication and synchronization, a Unix-compatible, server-based OS was constructed. A graphic user interface is provided by an interactive PostScript window server called PIX. All processors see the same set of system services, and within protection limits, programs capable of using many processors can spread out over a network of workstations and resource servers, acquiring the services of unused processors.
http://wiki.c2.com/?TupleSpace
https://en.wikipedia.org/wiki/Tuple_space
> I have a section in the book that I'm writing where I talk about how to design a good API. I pose the question of why none of the original Apple Mac API published in 1985 taking about 1,200 pages is in use today whereas almost all of the UNIX V6 API published in 1975 taking 321 pages is still in use and has been copied by many other systems. I'm sure that everyone on this list knows the answer.
I'm not sure I do. But it does seem like a good question.
Also:
http://www.art.net/~hopkins/Don/unix-haters/x-windows/disast...
My guess is that the original Mac OS provided a great GUI, but not much of an OS. It loaded a single application at a time that had access to all of memory. That's why it had desk accessories, to give you apps you could use without quitting the main application. It had handle based memory management so the OS could move memory blocks more contagiously to create enough open space for new memory allocations.
Over time they added cooperative multitasking, which meant the foreground app had to consciously give time to let background apps do stuff.
But they could never build a real OS with security and memory protection out of it. So Apple bought NeXT to get industrial strength unix as their core OS, and switched all Apple development to NeXTStep, or at least the modern derivative of it, called Cocoa.
My dust covered Inside Mac volumes were made useless nearly 20 years ago.
”Over time they added cooperative multitasking”
You may know, but for readers who don’t: ”they” didn’t, Andy Hertzfeld did (https://www.folklore.org/StoryView.py?story=Switcher.txt)
It helped that he had intimate knowledge of the Mac operating system’s internals, but many of them were documented in Inside Macintosh, and others could have been found with (quite) a bit of effort; one didn’t have to be at Apple or even have access to the system’s source code to implement that.
And those volumes aren’t useless; they are reminders of about the last time hacking an OS was fun :-;
What is fun is the Switcher/Multi-Mac debacle. Notice that it was mentioned that "I knew that releasing it would have me having to keep up with all the new ROM releases from Apple in the future." At the time, even with the 128K ROM I think they still had to put special code to support Switcher into there (Andy was also working on the Font Manager at the time).
Great story. What jumped at me was Andy's reaction to Steve's 100K offer. Mine was to counter with "I already have one client lined up, and their lawyers will be happy to deal with any 'confidential information' issues". I suspect mere mention of Microsoft would make Jobs mad and at least double the offer.
Then people started using Desk Accessories for things far beyond what was originally intended, then they became Desk Excessories.
In the days that your Mac-power-user-penis-length was measured every time you boot by how many extension icons plopped out along the bottom of the screen (and wrapped up to the next line), there was actually a coveted viagra-like meta-penis-extension that you could paste a bunch of ICON's into with ResEdit.
When you booted, it would sequentially plop all those icons out one by one, so it looked like you had as many extensions as you wanted, whatever you wanted them to look like! It would slow down your boot a bit, but it sure was worth it.
I actually wrote a commercial screen saver for a best selling utilities package when extensions became a thing. Nothing like mixing C with assembly in order to patch system traps.
Except most of the Inside Mac APIs were brought forward in OS X as Carbon. Carbon only went away relatively recently. So the APIs could support a reasonable OS, it's just Apple couldn't accomplish it for some reason (I waited for Copland for a long time).
That is not correct. Over a thousand APIs were dropped or substantially modified to be “carbon clean”.
Even Multi-Finder was a lot of work because apps happily poked OS globals.
The original Mac OS was more like an embedded app toolkit than an OS. The original implementations were all ROM!
I said most. Having worked on carbon apps, I can say that substantial portions went through with no changes. You could add menus and item to iTunes with AppendMenu() and InsertMenu() from visualization plugins until they rewrote it in Cocoa roughly 5 years ago.
Obviously they dumped a lot of the OS level APIs for stuff like Control Panels and Desk Accessories, but the standard app APIs were largely unchanged.
There's no fundamental reason they couldn't have made their own OS with the same Carbon APIs that made it into Mac OS X (not that I think they should have—the NeXTStep stuff was much better).
And Woz has mused that this is why it got a reputation for malware resilience.
The early Macs were basically wide open, as I recall.
I was working in a group next to the systems software group at Apple when some of the early malware was discovered. After a few days of secrecy, with people being pulled into labs and conference rooms under spooky circumstances, the software managers sent out word that some malware had been found and that people were working on mitigations. They also said something like "Look guys, we know that writing malware is really easy, so don't do it, because we'll fire you immediately if we find out." I distinctly recall that this was in verbal instruction, not a memo, and that the words "really easy" and "really, don't do it" were used.
Naturally my response was to go back to my desk and write a proof of concept. Half an hour and a hundred lines of code later I had something that would replicate a payload whenever you inserted a floppy disk. It was indeed dead easy to do. I exercised my toy for a little while . . . then deleted every trace. I'm sure I wasn't the only engineer who was curious and did this.
So while you couldn't change the ROM, you could definitely muck with the system software, and that's all that really mattered. Zero thought had been given to MacOS security.
Wide open, indeed. For those who don’t know:
(That last part was fixed after a virus exploiting it was found)With a description like that, he's got one confirmed pre-sale of that book. I'd pay up to $50 for it. Especially if he tells us what are the dozen core API calls that could replace X.
This is also an important example of how limiting an anti-social attitude can be when trying to collaborate and have a large affect on the world. As brilliant as Jon is, he wasted an inordinate amount of time making up for constantly insulting people, places, and approaches. (Even today he couldn't avoid insulting all of Tulsa OK).
Imagine where windowing systems could be if his brilliant work, API thoughts, and insights weren't delivered with insults, arrogance and vitriol.
At the end it is sad that he was proud of being right even though he was an _hole (his word). It could have been that he was right and his best ideas were in common use.
> how limiting an anti-social attitude can be when trying to collaborate
There are those of us who see collaboration as orthogonal to innovation and thus don't put any effort into it. Fortunately, there's a good mix of talent and dispositions out there to make up for it.
> Imagine where windowing systems could be if his brilliant work, API thoughts, and insights weren't delivered with insults, arrogance and vitriol.
Imagine a world where everyone is the same and has the same set of values. That may seem like paradise to some, but it sounds like doom to me.
> At the end it is sad that he was proud of being right
He was proud that he didn't compromise, even though that would've been easier, and no one would've faulted him for it.
Imagine if the creator of the ideal windowing system wasn't aborted in the 1960s.
I didn't realize people were so sensitive in the field. Compared to Linus, Theo de Raadt, Richard Stallman, etc, Jon seemed to be cruising at a comfortable level of Germanic straight-forward truth-telling, no real aholishness I could detect. Guess I should reset my etiquette and politeness filters.
People are sensitive in every field. Even if they weren't, there is very little to be gained by needlessly insulting them.
Working hard to build great stuff and arguing/fighting for what is right can be forceful without being debasing, divisive, or insulting.
I note that the people you name all built their communities through work they did well outside the corporate world.
And at least two of them have a undeserved reputation.
You mean Theo and Linus? Yes.
Theo's reputation is very well deserved.
I've read some of Don Hopkins' comments about all the cool things that were done with PostScript running in the NeWS server. I wonder, if NeWS had survived long enough that Sun had to add accessibility for people with disabilities (to sell to governments and schools if nothing else), how would they have done it? Today, the current state of the art is very chatty IPC (meaning tens of microseconds per cross-process call), partially assisted by bulk fetching and caching. To appreciate how bad that can be, think about a screen reader making at least one IPC call per word when reading text, to ask the application about word boundaries and bounding rectangles. That's a problem I hope to solve someday. In a parallel universe, though, maybe the screen reader is running inside the NeWS server, in the same address space as a PostScript-based UI toolkit.
I've written up some thoughts and discussions about accessibility and JavaScript, and discussed them a few times here!
I discovered the great work of Morgan Dixon and James Fogarty, which proves that you can do some amazing things with screen scraping, pattern matching, visual deconstruction, augmentation and reconstruction! His work needs to be combined with platform specific accessibility APIs via JavaScript.
I'm proposing "aQuery", a high level scriptable accessibility tool that is to native user interface components like jQuery is to DOM, for selecting and querying components, matching visual patterns, handing events, abstracting platform dependencies and high level service interfaces, building and scripting higher level widgets and applications, etc.
http://donhopkins.com/mediawiki/index.php/AQuery
https://news.ycombinator.com/item?id=11520967
Morgan Dixon's and James Fogarty's work is truly breathtaking and eye opening, and I would love for that to be a core part of a scriptable hybrid Screen Scraping / Accessibility API approach.
Screen scraping techniques are very powerful, but have limitations. Accessibility APIs are very powerful, but have different limitations. But using both approaches together, screencasting and re-composing visual elements, and tightly integrating it with JavaScript, enables a much wider and interesting range of possibilities.
Think of it like augmented reality for virtualizing desktop user interfaces. The beauty of Morgan's Prefab is how it works across different platforms and web browsers, over virtual desktops, and how it can control, sample, measure, modify, augment and recompose guis of existing unmodified applications, even dynamic language translation, so they're much more accessible and easier to use!
https://news.ycombinator.com/item?id=12425668
This link has the most up-to-date links to Morgan's work, and his demo videos!
https://news.ycombinator.com/item?id=14182061
https://prefab.github.io/
Prefab: The Pixel-Based Reverse Engineering Toolkit Prefab is a system for reverse engineering the interface structure of graphical interfaces from their pixels. In other words, Prefab looks at the pixels of an existing interface and returns a tree structure, like a web-page's Document Object Model, that you can then use to modify the original interface in some way. Prefab works from example images of widgets; it decomposes those widgets into small parts, and exactly matches those parts in screenshots of an interface. Prefab does this many times per second to help you modify interfaces in real time. Imagine if you could modify any graphical interface? With Prefab, you can explore this question!
https://www.youtube.com/watch?v=w4S5ZtnaUKE
Imagine if every interface was open source. Any of us could modify the software we use every day. Unfortunately, we don't have the source.
Prefab realizes this vision using only the pixels of everyday interfaces. This video shows how we advanced the capabilities of Prefab to understand interface content and hierarchy. We use Prefab to add new functionality to Microsoft Word, Skype, and Google Chrome. These demonstrations show how Prefab can be used to translate the language of interfaces, add tutorials to interfaces, and add or remove content from interfaces solely from their pixels. Prefab represents a new approach to deploying HCI research in everyday software, and is also the first step toward a future where anybody can modify any interface.
More Prefab demos:
https://prefab.github.io/videos.html
Fascinating! What are some of the limitations of screen scraping that are addressed by accessibility APIs? Is it primarily the unreliability? Do you envision using an accessibility API as the primary source of information, with screen scraping as a fallback?
Accessibility APIs expose lots of rich high level information like associating a label with a widget (to name one simple example, but it gets MUCH more complex than that). And of course the position and meaning and state of each object on the screen.
There needs to be a higher level scriptable way to get a handle on all that complexity, like jQuery helps automate the creation and manipulation and abstraction of HTML DOM and events and handlers.
PhoneGap/Cordova plugins and NativeScript both take a similar approach: they have a generic Objective C / Java / Whatever <=> JavaScript bridge that lets you directly call all (or most) of the native APIs, including accessibility, directly on each platform. Then you write higher level platform independent APIs on top of the native APIs in JavaScript, a different one for each platform, but the same high level interface to JavaScript programmers.
https://docs.nativescript.org/core-concepts/accessing-native...
I would try to use the native API as much as possible since they're precise yet tedious. It should have a platform-independent accessibility-specific selector language like xpath or jQuery selectors, which should be implemented efficiently in native code like querySelector. The pattern matching engine would send asynchronous events back to JavaScript. You could write JavaScript handlers for patterns of pixels as well as accessibility path patterns appearing and disappearing, like jQuery lets you bind handlers to patterns of DOM elements that don't exist yet, instead of concrete existing elements. Those handlers would create higher level widgets that could manage those existing pixels and widgets. (Like recognizing a youtube video player in any web browser window, and wrapping it in an aQuery widget implementing an abstract VideoPlayer interface, for example.)
Of course calling the native accessibility API is lighter weight than screen scraping and pixel matching, and you could use the native API to drill down to just the region of pixels you want to match or screencast, to minimize the amount of screen scraping and pixel matching required.
"A couple of decades ago I bough a Sun Ultra-60 and asked whether it was worth paying for the dual processor version. The answer that I got was "Yes. You need one processor to run X and another for everything else."
People cursed with diskless Sun 3/50's would run xterms and emacs's across the net on each other's workstations instead of locally. It was noticeably less sluggish, because you didn't get hit with all the heavyweight process context switching between X clients and server every keystroke.
> The only really worthwhile thing about X was the distributed extension registration mechanism. All of the input, graphics and other crap should be moved to extension #1. That way, it won't be mandatory in conforming implementations once that stuff was obsolete. As you probably know, that's where we are today; nobody uses that stuff but it's like the corner of an Intel chip that implements the original instruction set.
On the other hand, all of the input, graphics and "other crap" being mandatory means that as a developer you can pretty much guarantee that they are there and if you care about having your stuff work everywhere (well, everywhere X is available anyway) you can simply rely on that without having to support a bunch of different APIs that may or may not be there (see the audio situation a few years ago in Linux).
(also FWIW a lot of people use the X primitives, not everyone uses Gtk or Qt)
I'm not quite sure I believe that a lot of people use the X primitives. The alternative to Gtk and Qt is most often not raw Xlib. There are alternative toolkits such as Motif, Xt. And then graphics abstractions such as SDL. Obviously all of these (including Gtk and Qt) use at least some of the X primitives in their rendering or themeing engines, but direct use of Xlib primitives is quite rare. And I think the whole point of the argument is that the commonly used primitives today are things like XRENDER, which aren't really primitives since they are an extension. Precisely the point being made.
Basically, name me an app that uses solely X11 primitives without the use of any extensions and no overlying library over libX11 (and no, xclock doesn't count)
Of course i include using toolkits that themselves use X primitives, not only using Xlib directly :-).
For example my own Little Forms library [0] uses the X server's drawing and text operations (you can use Xft instead, it is a build option, but you can also make a static library for binaries that rely only on xlib and nothing else).
[0] http://runtimeterror.com/rep/lforms
Using X primitives means not using X extensions. Using toolkits like Motif remains a simple use of Xlib primitives and most of the code of a Motif application involves direct Xlib primitives.
Yes, the 2d primitives in X are actually fine -- a bunch of dumb obvious primitives of the kind that just about every graphics system has.
Where it fell down was all the complication about XVisuals and colours etc. Those things were solving real problems for the era but doing so with an unnecessarily complicated interface that tied the 2d-primitives and much else into the assumptions of that era.
Thus as things developed, whole new APIs like XRender had to be invented in order to do the dumb basic primitives again.
I beg to differ. X11 2D primitives are "actually fine" in the same sense that there were "very fine people" marching in Charlottesville. By which I mean "not actually very fine". ;)
But I totally agree with you about colors (the X approach to device independence is to treat everything like a MicroVAX framebuffer on acid), and xRender (which was wonderful work that transcended X11 and led to Cairo and html's canvas).
And don't get me started about window borders, and the SHAPES extension, and their fractally complex interactions!
http://www.art.net/~hopkins/Don/unix-haters/x-windows/disast...
A task as simple as filing and stroking shapes is quite complicated because of X's bizarre pixel-oriented imaging rules. When you fill a 10x10 square with XFillRectangle, it fills the 100 pixels you expect. But you get extra "bonus pixels" when you pass the same arguments to XDrawRectangle, because it actually draws an 11x11 square, hanging out one pixel below and to the right!!! If you find this hard to believe, look it up in the X manual yourself: Volume 1, Section 6.1.4. The manual patronizingly explains how easy it is to add 1 to the x and y position of the filled rectangle, while subtracting 1 from the width and height to compensate, so it fits neatly inside the outline. Then it points out that "in the case of arcs, however, this is a much more difficult proposition (probably impossible in a portable fashion)." This means that portably filling and stroking an arbitrarily scaled arc without overlapping or leaving gaps is an intractable problem when using the X Window System. Think about that. You can't even draw a proper rectangle with a thick outline, since the line width is specified in unscaled pixel units, so if your display has rectangular pixels, the vertical and horizontal lines will have different thicknesses enen though you scaled the rectangle corner coordinates to compensate for the aspect ratio.
I beg to differ. X11 2D primitives are "actually fine" in the same sense that there were "very fine people" marching in Charlottesville. By which I mean "not actually very fine". ;)
Probably we are agreeing past each-other. I meant they were OK in a very board sense that you want primitives for drawing lines, drawing polygons, filling things, blitting things etc. I think you agree with me about that.
And I also think we both agree that the details of those primitives in X11 were a disaster.
Yeah the details are kinda weird (although i wonder if there is some reasoning behind that because Windows also has the same off-by-one-pixel thing - and even more confusingly it is done through the same API call but it is a special case when you use a null pen) but for me the most important thing is that they are there and you can safely rely on that they are there despite the weirdness.
Off-by-one pixel stuff is not surprising in world where your API deals explicitly with individual pixels. Newer systems are a bit simpler here because they treat the screen as continuous plane that only gets mapped to pixels at the last moment.
The flip side is that you have to worry about weird aliasing (or anti-aliasing!) artifacts, such as black lines turning grey.
DonHopkins is on HN from time to time, he's always full of things to say about this. Waiting for the wall of history :)
John Steinhart is outstanding in his field!
Sometimes he's even out driving a tractor in his field! ;)
In that thread, it mentiond that NeWS had "problems". Can you tell us what those problems were?
I don't know where to begin, or when to stop, so I'll pick something at random and jump around.
NeWS 1.1 was layered on top of PixRects (the graphics library that SunView was built on top of), which gave it the weird limitation that sub-windows could not be positioned above or to the left of their parents (sub-window coordinates were unsigned), which was a huge pain in the ass for making all kinds of user interfaces.
X11/NeWS solved that problem by having a much nicer PostScript graphics renderer and compositor, but it came with its own set of problems, many having to do with being nailed together with a X11 server with a totally different graphics model and approach to life.
But there were some really cool things you could do with X11 and NeWS together, like managing X11 windows with NeWS frames (which could have non-rectangular windows like jutting title tabs, round pie menus, panning virtual desktops, rooms, etc).
Another important point is that running the window manager in the same heavy weight Unix process as the window server saves an astronomical number of costly context switches, and results in much smoother user interface with silky local feedback. Plus it's extensible and customizable and drawn in PostScript.
Here's a demo of NeWS window frames with tabs and pie menus. We used those to made an ICCCM X11 window manager written in PostScript (that Sun never released) that let you use those tabbed window frames and pie menus and other NeWS components to manage all of your X11 windows (and use them as your default frame for NeWS apps too, of course), seamlessly integrating X11 and NeWS apps together.
https://www.youtube.com/watch?v=tMcmQk-q0k4
Here are some flames and notes I wrote years ago about X11 and NeWS window management -- the "OWM" section is about the NeWS X11 window manager. It covers some of the political and technical problems we had integrating X11 and NeWS. Window management is a surprisingly contentious issue! Everybody wants to be on top.
http://www.donhopkins.com/home/catalog/unix-haters/x-windows...
Basically, we didn't want to put our round NeWS pie menus and pizza windows inside of their rectangular X11 ICCCM window frames, because it would have been better for everyone the other way around.
http://www.donhopkins.com/home/catalog/images/pizzatool.gif
Josh Siegel wrote this beautiful PostScript tour de force swan song for X11/NeWS, an ICCCM window manager that actually worked quite well, with special window subclasses to support all the OPEN LOOK dialog types and window frame features through their standard X11 ICCCM properties! Check out "ClassX11ManagerMixin", which is what it sounds like. It's mixed into FavoriteBaseWindow, which can be redefined to the custom ClassTabBaseWindow supporting tabs and pie menus, shown in the above video, or any other kind of frame you want to wrap around X11 windows:
http://www.donhopkins.com/home/archive/NeWS/owm.ps.txt
It was a proof of concept, which we wanted to take a lot further by implementing a HyperCard-like user customizable persistent window manager with HyperLook. So users can edit and build their own custom window frames by copying, pasting and configuring scriptable components from object warehouses, edit and extend the user interfaces of running apps, and make high level task-oriented interfaces by composing widgets and apps into "cards", "backgrounds", "stacks" and optional network "clients". But that's not how things turned out. ;/
http://www.donhopkins.com/home/catalog/hyperlook/index.html
http://www.donhopkins.com/home/catalog/hyperlook/Warehouse1....
http://www.donhopkins.com/home/catalog/hyperlook/ButtonIdeas...
http://www.donhopkins.com/home/catalog/hyperlook/TalkInterfa...
http://www.donhopkins.com/home/catalog/hyperlook/TalkRunTime...
I'll excerpt the relevant parts of the i39l flames:
Who Should Manage the Windows, X11 or NeWS?
This is a discussion of ICCCM Window Management for X11/NeWS. One of the horrible problems of X11/NeWS was window management. The X people wanted to wrap NeWS windows up in X frames (that is, OLWM). The NeWS people wanted to do it the other way around, and prototyped an ICCCM window manager in NeWS (mostly object oriented PostScript, and a tiny bit of C), that wrapped X windows up in NeWS window frames.
Why wrap X windows in NeWS frames? Because NeWS is much better at window management than X. On the surface, it was easy to implement lots of cool features. But deeper, NeWS is capable of synchronizing input events much more reliably than X11, so it can manage the input focus perfectly, where asynchronous X11 window managers fall flat on their face by definition.
Our next step (if you'll pardon the allusion) was to use HyperNeWS (renamed HyperLook, a graphical user interface system like HyperCard with PostScript) to implemented a totally customizable X window manager!
Some notes about OWM
OWM is the "Open Window Manager" we prototyped in NeWS. We enhanced the NeWS window frames so they sported indexing tabs, pie menus, rooms, and a scrolling virtual desktop. Many of our enhancements were separatly developed, and plugged together orthogonally like legos. All NeWS applications could use these fancy frames, and the Open Window Manager wrapped X clients in the same frames that NeWS windows got!
This way, factoring the window frames out as a part of the toolkit, and implementing the X window manager separately, NeWS applications don't have to know a thing about X window management, and X clients can go on doing the same nasty things they've always done, and everybody get the benefits of dynamic extensibility, and a consistent user interface, by using the default window class!
X11 window managers must grab the server in order to animate rubber-band feedback over the screen when resizing and moving windows. This grabbing causes many problems with NeWS synchronous interests, that can be demonstrated by pressing the "Help" key while dragging out a rectangle on the root background. NeWS can do a much better job at managing global resources in the server because it is in the same address space and it has facilities like the overlay plane specifically designed to implement such window management functions, without even grabbing the server. This antisocial server grabbing behavior is just one symptom of a general class of problems with external X window management, including other important issues such as keyboard and colomap focus.
Don, thank you for all the details. I've enjoyed your writings since I found your website in 2000. Too bad NeWS didn't take off. What would it take to revive it? Is the Linux framebuffer stable enough to have another go at it?
> X11 window managers must grab the server in order to animate rubber-band feedback over the screen when resizing and moving windows.
I wonder how the comparison between X11 & NeWS works once when switches to tiling window managers, which require much less work & chrome from the WM.
If tiling WMs favour the X model, I wonder if the real reason so many of us like them is that they are faster, rather than tiling being a better paradigm. I suspect that's not the case — at this point, tiling really feels better to me — but maybe it is?
I think the benefits of extensibility far outweigh any differences from whether the window manager supports tiling or overlapping windows. Ideally it should be general purpose enough to support both.
Having an extensible window server enables you to use simpler but powerful primitives (X windows -vs- NeWS canvases, or server grabs + XOR RasterOps -vs- overlay canvases and hardware overlay planes), then implement the higher level stuff flexibly in software: see my other message about the complexity of X window borders, backgrounds and shapes, and how it makes shaped windows unbelievably complicated, even though nobody actually ever needs to use that complexity.
NeWS canvases don't need special built-in borders, because the PostScript interpreter and stencil-paint graphics model's clipping path elegantly solves the problem that X window borders were trying to solve (but didn't solve well enough for anyone to ever use), and solve many more problems in a much more general way.
NeWS had an overlay canvas for non-destructively drawing rubber band feedback over the desktop, which used hardware graphics planes if available, or fell back to using a display list and XOR RaserOps on monochrome or simple 8 bit displays.
Some of the popular Sun color framebuffers (cgsix and gx maybe?) had 8 bits of color pixles and a two bits of overlay planes for cursors and black-and-white windows. SunView knew how to use it for the cursor and light weight monochrome windows, and NeWS used it for the overlay plane, which was perfect for window management and rubber band feedback.
Drawing the cursor in the overlay plane actually sped up graphics performance a surprising amount, since the drawing code didn't have to always check if the cursor was overlapping where it was about to draw, then hiding and redrawing it before and after drawing anything on the screen under the cursor.
NeWS could directly open framebuffers on the overlay plane (1 bit black and white) and overlay enable plane (1 bit that switches between the showing the black and white overlay plane, or showing through to the color framebuffer). Then you could draw on the overlay enable plane to flip between the black and white and color framebuffers on a per-pixel bases (useful for making rubber bands, text labels, 50% checkerboard shadows and highlights, etc).
SGI's 4Sight (their own port of NeWS 1.1 that they integrated with X11 and GL, before Sun's X11/NeWS) also supported hardware overlay planes, and used them for the pop-up menus, so it didn't have to repaint the thick 24 bit graphics underneath the thin monochrome menus when they popped down. My NeWS pie menu code "just worked" in the overlay plane with only a little modification, except that I had to special-case the color wheel pie menu to not use the overlay plane, because the overlay planes weren't allowed more than three colors (black, white, one user defined color, and transparent).
If you're into the history of window management, here's some fascinating stuff about the evolution of window managers, including Andrew, which is a tiling window manager that Gosling and Rosenthal worked on at CMU before NeWS. It also discusses and compares PERQ PNX, APOLLO, SunWindows, MG-1, Sapphire, BLIT, Smalltalk, DLISP, Interlisp-D, Tajo/Mesa, Cedar Docs and Viewers, Star, Viewpoint, and even SunDew (NeWS).
"Methodology of Window Management": http://www.chilton-computing.org.uk/inf/literature/books/wm/...
By F R A Hopgood, D A Duce, E V C Fielding, K Robinson, A S Williams. 29 April 1985. This is the Proceedings of the Alvey Workshop at Cosener's House, Abingdon that took place from 29 April 1985 until 1 May 1985. It was input into the planning for the MMI part of the Alvey Programme. The Proceedings were later published by Springer-Verlag in 1986.
My favorite chapters:
"A Comparison of Some Window Managers" by Tony Williams: http://www.chilton-computing.org.uk/inf/literature/books/wm/...
"Ten Years of Window Systems - A Retrospective View" by Warren Teitelman: http://www.chilton-computing.org.uk/inf/literature/books/wm/...
"SunDew - A Distributed and Extensible Window System" by Games Gosling: http://www.chilton-computing.org.uk/inf/literature/books/wm/...
"User Interface Working Group Discussions": http://www.chilton-computing.org.uk/inf/literature/books/wm/...
"User Interface Working Group Final Report": http://www.chilton-computing.org.uk/inf/literature/books/wm/...
Here is some of the ui working group discussion specifically about tiling windows:
17.2 INTERFACE TECHNIQUES
Some of the issues supplied to the Working Group were felt not to be issues at all; as an example, tiled and overlapped windows were seen to be merely options that the user interface designer could use if appropriate. Indeed, a user connected to more than one host, one providing a tiling environment and the other not. might well have both mechanisms to interact with at the same time.
Window grouping and subwindows received some attention. A subwindow is not necessarily identical to a window: for example a subwindow receiving input it does not understand refers it to the parent for treatment, and if a parent window is deleted then so are its subwindows. Subwindows in some systems can overlap. while others permit only tiling. Title lines, which can be considered as a form of subwindow. may need to be accessible to the application.
IIRC, it was much slower than other window systems running on the same machine.
With X11/NeWS, you were running two window systems at the same time on one machine, right out of the box!
Even with NeWS 1.1, you were still running parts of SunView underneath.
One cool thing that X11/NeWS could do was that X11 clients could transparently use scalable PostScript fonts, including the nice hinted "Folio" fonts, and even "user defined fonts" written in PostScript like the Hershey and Dijkstra fonts. The X11 server could call back into the NeWS PostScript interpreter to render the font at any point size!
Through most of that article I was thinking "Yep, that's the kind of train-wreck you get when you design by committee, or worse by political need".
But toward the end, he says that the particular kind of technical train-wreck that they got was similar to the Mac API (presumably the this means the pre-OS X OS). "[As a resulting of accidentally being lots of databases] the X API is wide and shallow like the Mac, and full of interesting race conditions to boot."
Anyway, I didn't think that design by committee was one of Apples weaknesses.
still better than web apps.
I doubt it will come as a surprise to anyone that X was fundamentally ill conceived from the very beginning. It’s one of those unfortunate side effects of unintended consequences that Unix history saddled us with it for twenty years longer than we’d ideally have wanted.
It fascinates me that something so widely regarded as Bad and Wrong, proved so hard to replace when it’s baked into a system. I think there’s a cautionary tale about the necessity of getting your core APIs right, because you might never be able to get rid of them.
Having used a multitude of OSes since the 80's and having digital archeology as one of my hobbies, I think it applies to everything in UNIX's design.
I would like to hear more. The Unix core API is pretty simple and durable; what was better than it? Other than Plan9? SmallTalk doesn't really count.
For starters having been written in C, after the Assembly and B rewrites, when we already had safer systems programming languages in the early 60's.
IBM for example did most of their RISC research with an OS written in PL/8, where they prototyped many ideas about modular compilers, a few of them visible in how LLVM works.
Then by being a plain CLI based OS versus what was being done at Xerox PARC with Xerox Star and Pilot (done in Mesa).
NeXTSTep was probably the only variant that got close of the Mac, Amiga and Atari multimedia capabilities, and even it wasn't a pure UNIX, rather used it as a means to bring applications into the NeXT world.
Many mainframe ideas about OS security are still not part of any UNIX clone, as another example.
Thank you for explaining. I disagree, but then, I started with the Commodore 64 and BASIC, and have missed them ever since. C and LISP version 1 sort of fit in the same space. I hate any language that hides the machine from me. Also don't really like clicky gooey stuff. Text and typing is where it is at. Matter of taste really. But newLISP is a good mix of hardware access with safety.
Perfect is the enemy of good, as the saying goes.
Worse is better, as the saying goes.