The MGR Window System | Hacker News Reader

The MGR Window System

hack.org

64 pointsfloren30 comments

Very cool to learn about this bit of history.

I really enjoy how crisp and legible fonts and graphics are in that screenshot. Even the tiny terminal in the upper left is very clear. Achieving that in X was always an exercise in frustration IME, involving some obscure fontconfig incantations and specific bitmap fonts. Ultimately I couldn't live without font hinting, but there's something so appealing about that crisp bitmap look.

That font in the screen shot looks quite similar to Terminus Font[1]. If the bitmap version does not work then there is also a TTF version[2] of Terminus that works quite well.

It's one of my all time favorite fonts[3].

[1]: http://terminus-font.sourceforge.net/ [2]: https://files.ax86.net/terminus-ttf/ [3]: https://i.imgur.com/46Qxtqa.png

I created all of the original MGR bitmap fonts by hand - a pixel at a time. For much of its life MGR ran on monochrome (1 bit per pixel) bitmap displays, that tend to look more crisp than modern anti-aliased displays

The font is called Gacha.

https://hack.org/mc/fonts/

I used it in 1985/6 at UCL-CS on a sun workstation, and it was lovely. The port to sunos had some issues. Mike Lesk from Bell labs was in residence and had brought it with him on a tape. (Mike invented UUCP)

The thing is, the labs people hated time wasters (like me) They used a simple test as an entry key to investing in helping you: if you claimed to be a programmer and said there was a problem they waited for you to proffer patches..

In the mid 2000s, the wireless network infrastructure at my university authenticated your device based on SSH'ing into a server. But the specific SSH server used at that time did not support password-less logins via keys, so it required typing in a password every time you connected (and WiFi was flakey in that environment in those days, so dropped connections weren't uncommon). I asked the IT support folks about this, and they told me that I should try adding it to the software. I figured out what it would take and wrote some patches, but then they said they couldn't run something customized like that. Years on their reasoning makes sense, but at the time it was really disappointing and I dropped the effort after that.

I think this happens far more often than people realise. Part of the problem is ownership: It's so easy to become proprietorial about code. But another part is that people ideate solutions very differently and "style" is big in code.

The gap between XEmacs and Emacs is noted in the xemacs website in all it's painful glory. It's got politics, it's got lawyers, but it's also got code style and complexity.

I did a package for homebrew via git and PR, and the CI cost to make it "fit" their expectations was a multi-day iterative nightmare. I can see how it would be a barrier to entry for a lot of people.

The other side, I have managed to get one-line fixes into the hands of competent coders. There are times they will simply accept it, apply it, and move on.

Early in my career (1984) I accepted community patches for a body of code I was employed to maintain and imperilled it's IPR. It was a big deal at the time. I didn't think patches to C being used by the community was going to wind up there. I was pretty sure the patch submitters didn't mean to go there either (by stealth I mean, they would have been delighted if the entire body of code was in the public domain) -This was when we swapped code by 1200bpi tape reels in the post.

I think "too risky to accept community patches" is an excuse rather than a real reason. They just didn't want the paperwork and hassle to adopt the code. But the negative effect I can totally believe. I would have been very de-motivated by this.

Stephen Uhler's home page, some papers about MGR are there, also... https://sau.homeip.net/

I wonder if this system got any inspiration from Plan 9? It looks really similar to 8½, Rob Pike's early window manager for Plan 9 [1]. Or even the Blit [2].

I would love to try out MGR on the Linux framebuffer, though.

Edit: found an interesting 2016 HN thread on "oldschool" windowing systems that also mentions both MGR and 8½ [3].

1: http://doc.cat-v.org/plan_9/4th_edition/papers/812/8%C2%BD.f...

2: https://en.wikipedia.org/wiki/Blit_(computer_terminal)#Windo...

3: https://news.ycombinator.com/item?id=11477565

It predates Plan 9.

Another weird window system was the W system (not to be confused with the X predecessor). Mostly monochrome.

https://eerott.mbnet.fi/historical/w1r2.html

It's been a while since I read up about it (and it's a tad hard to Google for), but I almost want to put some information about AlphaWindows to share. It was an odd windowing system.

From my understanding theirs still a commerical implementation exists, though God knows who's paying for an obscure windowing system that only ran on select terminals.

If I can find a supported terminal and some sort of spec (or possibly some level of reverse engineering, but I don't have the patience), I'd love to work on my own implementation. There was one HP 700 series terminal that might be easiest to get my hands on.

There's a rather sparse Wikipedia page: https://en.m.wikipedia.org/wiki/AlphaWindows

Note: Article author has since moved to Wayland.

https://hack.org/mc/blog/no-more-x11.html

Of all the apps in the upper left, I still to this day use xload and xclock. Xeyes was always kind of pointless to me. And xbiff is meaningless in today's world of email saturation.

Xeyes was occasionally useful for telling you when the machine it's running on has gone down or is too overloaded to be usable. In today's world of nested window systems it's also helpful for telling you if your mouse cursor movement is being delivered to a nested screen.

Mostly, though, xeyes was "pointless" in the same sense that fine art is "pointless", like xneko, window manager themes, xshostakovich, or screensavers. It doesn't have a point; it is itself the point.

Huh. Today I learned about Xeyes. Thanks!

For me, xeyes can be useful on multiple high-DPI monitors where I occasionally lose the mouse.

I still use xbiff.

I'm fascinated by the note about older versions MGR working on the Macintosh. I may have to poke at the TUHS mailing list to see if anyone knows more.

From reading the article, I think MGR was available for Coherent OS prior to its X implementation. I never used it myself but if I could go back....

> If you want to compare MGR to the X Window System, you might consider the MGR server as something like a combination of an X server + window manager + xterm

Sounds like a nightmare of in band signalling vulnerabilities.

Edit: your downvote is invalid. you literally just did it because i wrote something negative about the topic of the thread. it's still true and a good point. this is similar to how youtube downvotes worked. i still upvoted the article because it was useful to me. i am rational you are not.

I always wondered about this, but I never dug into MGR enough to find out if they defended against it. Maybe the multiplexers rmgr and mtx were perfectly secure, and restricted the programs they ran to only manipulating their own window (which X11 doesn't succeed at, or even attempt), but it seems like some kinds of compositions of programs might not play well with this.

Also there were plenty of terminals that had escape-sequence vulnerabilities of the flavor "sending escape sequence X to the terminal will cause it to (immediately or later) send character sequence Y back to the host [which the host will interpret as a command]", like cross-site scripting. As I understand it, this kind of send-escape-sequence-X-to-bind-an-event-to-character-sequence-Y is exactly how MGR worked, and I wonder if it also had this vulnerability.

This is usually, but not always, a matter of running one program after another; for example, write(1) (and I think wall(8) if enabled) would allow you to send arbitrary escape sequences to anybody's terminal at any time.

Trusted path issues also seem like they could be a problem, though it's kind of a problem with Unix shells in terminals in general: when you hit ^Z to suspend a process and it drops you back to your shell, how do you know that it really suspended and that what you're typing to is really your shell? This could matter if you use "sudo". (It doesn't matter that much because by virtue of running the program in the first place you are giving all your authority to that program, unlike in capability-based systems.)

You might want to remove your complaints about downvotes and boasts of rationality so people don't downvote you for them.

Every single concern you just listed is valid and are indeed being used in real exploits, the output into input is just one way to exploit terminals, there are several more. I'm sitting here laughing because usually when we bring up these issues about doing insanely insecure bad ideas, a UN*X diehard will come over and talk about how we don't know anything and "PoC or GTFO", as opposed to putting any effort into stopping the insecure bad idea. A prime lesson every hacker ("cracker") learns quickly is that anything that looks insecure will likely actually later turn out to be extremely insecure, even if you can't immediately figure out a way to exploit it.

I discovered wall and write at some point and was amazed how stupid that was. At some point some distros started getting rid of them but I gave up trying to understand UN*X long before that point as it was clearly a joke OS.

> This could matter if you use "sudo".

The most common concerning use case I think is SSHing into something. There's no way to tell if you got out. This perhaps has limited exploitability, but still should not be a thing, and is easily solved with a real UI instead of terminal hacks. Sudo is usually only used to run stuff as root - under the pretense that requiring this will somehow stop malware from getting root - which itself is a misconception (which indeed capability based systems avoid).

>You might want to remove your complaints about downvotes and boasts of rationality so people don't downvote you for them.

Nah it's funny.

I don't think there are several more ways to exploit terminals, although there are certainly several more ways to exploit terminal emulators. Maybe your definition of "exploit" is broader than mine, though.

> I discovered wall and write at some point and was amazed how stupid that was.

write(1) strips escape characters out, and wall(1) represents them as ^[; they protect your terminal against this particular vulnerability since last millennium. wall also escapes bytes above 126, which would be a pain if you weren't speaking English, and write seems to strip at least byte 0x9b, although I don't know if I have a terminal handy that responds to 0x9b.

> The most common concerning use case I think is SSHing into something. There's no way to tell if you got out.

The easiest way to be sure you got out is to close the terminal emulator, but an alternative is just closing ssh, using ^M~. It's possible to flub that by, say, accidentally typing ^M`. or ^M~,. I agree that better UI would help.

A different problem with ssh is that it leaks your keystroke timing to passive listeners who don't have the session key. This isn't a concern for using ssh with password authentication but it is a concern if you're running sudo or gpg on the server you sshed into.

I agree that unrestricted sudo isn't an effective defense against malware, just against accidentally hosing your system.

X had various security extensions like XACE to restrict what clients can do.

https://www.x.org/archive/X11R7.5/doc/security/XACE-Spec.htm...

>Edit: your downvote is invalid. you literally just did it because i wrote something negative about the topic of the thread. it's still true and a good point. this is similar to how youtube downvotes worked. i still upvoted the article because it was useful to me. i am rational you are not.

Oh grow up. Your edit is longer than the post.

It was a blog post, which I will link to pretty much every time someone downvotes me from now on, as it's a pattern I've noticed here.

Yes and I'm calling that neurotic, illogical behavior. If someone down votes you, they don't care what you have to say. So posting that edit will get you more downvotes.

This is true motivation to keep me working out the ideal desktop environment for Linux on the Web. The idea of "a message passing facility enabling client programs to rendezvous and exchange messages" is in particular the kind of thing I want to continue to iterate upon, albeit in a more abstract sense than the kinds of windowing events that are referred to.

https://lotw.site/desk

Reply on news.ycombinator.com