Live data from Hacker News

The Unix-Haters Handbook (1994) [pdf]

web.mit.edu

311–316 of 316 posts

Re: The Unix-Haters Handbook (1994) [pdf]

#311
post #237

Earlier quoted context omitted.

I dont see a world in 100 years where anything is unix derived - but that doesnt mean it wont be Unix compatible.

Why not? We still have software that was written 50+ years ago for IBM System/360's running on a derived architecture today (System z.)

Of course, there are good reasons for running legacy software, and likely some of that will still be around.

How about, I don't see Unix-like systems as the end-all be-all of operating systems such that these systems will be the basis of anything in 100 years. To extend the timeframe indefinitely, is this system the one to last the ages?

Re: The Unix-Haters Handbook (1994) [pdf]

#312

Earlier quoted context omitted.

ITS is often mentioned and I suppose PR1MOS (which was descended from ITS)

I'm familiar with ITS, but haven't heard this before, and am highly skeptical of any connexion with PRIMOS. The Wikipedia article on PRIMOS says "Legend has it that the unusual choice of FORTRAN for the OS programming language had to do with its history. Allegedly, the founders of Prime had worked for Honeywell on a NASA project. However, Honeywell at that time was uninterested in minicomputers, so they left and foun…

It seems more likely that PRIMOS would have been influenced by Multics.

Re: The Unix-Haters Handbook (1994) [pdf]

#313

Earlier quoted context omitted.

Alright, I'll bite. What's missing? I ask as I type from my Dell XPS 13" DE (aka Sputnik).

It's mostly hardware support still. As an example, try using a Baytrail/CherryTrail laptop with Windows 10. Now try in Ubuntu. Oh you need Linux 4.11. Oh that's not out yet, so you need to run a bleeding edge kernel directly from git. Even Ubuntu 17.04 is supposed to ship with 4.10 so you'll have to wait until Ubuntu 17.10 before your hardware might be usable.

As a counter-example, try buying a Baytrail/CherryTrail laptop with Windows 10. Now try to install OS X. Oh, you can't since it's not a Mac.

All the time the argument is given that OS X has much better hardware support than Linux, which is just not true. It might be true for OS X on a Mac compared to Linux on unspecified hardware. However, if you constrain the hardware choices even half as much as you do for OS X, that's not the case anymore.

Re: The Unix-Haters Handbook (1994) [pdf]

#314
post #3

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

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

I was on Sun's X11/NeWS beta program, and each time they came out with a new release, they'd send me an entire whole new set of X11 and Adobe PostScript manuals! I appreciated it, but had those manuals coming out of my ears! It was great having all those Red Books to pass out at parties, but nobody ever wanted the XView manuals. ;)

Re: The Unix-Haters Handbook (1994) [pdf]

#315
post #307

Earlier quoted context omitted.

Hm right. That is indeed possible because the client asks xorg for a surface with an alpha channel. What I don't think clients can do is doing the transparency effects themselves. Because that involves using opengl and doesn't work (very well) in a networked context.

Clients doing transparency themselves is the hackish solution to this problems because it involves the client sohehow knowing what it paints over. And in all this has nothing to do with OpenGL except that GLX_EXT_texture_from_pixmap is particularly efficient way to implement it on OpenGL supporting hardware. For simple transparency, the compositor can do the blending completely in software (which involves getting the…

At Sun we experimented with implementing an X11 window manager in NeWS. We didn't have transparency at the time (1992), but we did support shaped windows!

The NeWS window manager supported cool stuff (for both X11 and NeWS windows!) like rooms, virtual scrolling desktops, tabbed windows, pie menus, was easily extensible and deeply customisable in PostScript, and ran locally in the window server so it could respond instantly to input events, lock the input queue and provide feedback and manipulate windows immediately without causing any context switches or dealing with asynchronous locking, unlocking and event handling. You'd never lose a keystroke or click when switching between applications, for example.

I touched on some of those ideas in this ancient window manager flamey-poo:

http://www.art.net/~hopkins/Don/unix-haters/x-windows/i39l.h...

Also on that topic (I can't believe I still love flaming about this stuff so many years later! Sorry if I sound like a broken record.):

https://news.ycombinator.com/item?id=5861229

https://news.ycombinator.com/item?id=5844345

https://news.ycombinator.com/item?id=8039156

https://news.ycombinator.com/item?id=13198492

https://news.ycombinator.com/item?id=11520680

https://news.ycombinator.com/item?id=11319498

https://news.ycombinator.com/item?id=11319783

https://news.ycombinator.com/item?id=9977226

https://news.ycombinator.com/item?id=13196983

https://news.ycombinator.com/item?id=11481604

And here's how I think you should design a programmable "window manager" these days -- but it would be much more than just a window manager! It would be great for integrating legacy desktop and mobile applications into VR, for example!

aQuery -- Like jQuery for Accessibility

http://donhopkins.com/mediawiki/index.php/AQuery

Don asks Peter Korn: Hey I would love to bounce an idea off of you! I didn't realize how much work you've done in accessibility.

There is a window manager for the Mac called Slate, that is extensible in JavaScript -- it makes a hidden WebView and uses its JS interpreter by extending it with some interfaces to the app to do window management, using the Mac Accessibility API.

So I wanted to make pie menus for it, and thought of a good approach: make the hidden WebView not so hidden, but in the topmost layer of windows, covering all the screens, with a transparent background, that shows the desktop through anywhere you don't draw html.

Then just make pie menus with JavaScript, which I've done. Works like a charm!

THEN the next step I would like to do is this:

aQuery -- like jQuery, but for selecting, querying and manipulating Mac app user interfaces via the Accessibility framework and protocols.

So you can write jQuery-like selectors that search for and select Accessibility objects, and then it provides a convenient high level API for doing all kinds of stuff with them. So you can write higher level plugin widgets with aQuery that use HTML with jQuery, or even other types of user interfaces like voice recognition/synthesis, video tracking, augmented reality, web services, etc!

For example, I want to click on a window and it will dynamically configure jQuery Pie Menus with the commands in the menu of a live Mac app. Or make a hypercard-like user interface builder that lets people drag buttons or commands out of Mac apps into their own stacks, and make special purpose simplified guis for controlling and integrating Mac apps.

Does that sound crazy? I think it just might work! Implement the aQuery "selector engine" and heavy lifting in Objective C so that it runs really fast, and presents a nice high level useful interface to JavaScript.

Here is an issue I opened about it on the Slate github page, describing what I've done, but I haven't written up the "aQuery" idea yet. That's the next step!

http://www.donhopkins.com/home/archive/piemenu/uwm1/hacks.f

That's the FORTH source code from 1987 of a programmable multi threaded X10 window manager that lets you throw windows around so they bounce off of the edge of the screen!

Re: The Unix-Haters Handbook (1994) [pdf]

#316
post #253

Earlier quoted context omitted.

Less important and less popular there was also MGR, which treated windowing more like a terminal session, and so was more Unix-philosophy than most. It was neat, and because of its smaller profile it got ported to a lot of systems (Atari ST, etc.) that struggled under the full X11 system http://www.hack.org/mc/mgr/

Uhler put MGR on the Tadpole SPARCbook. It was really cool.

MGR was awesome! Not extensible, but simple and clean, and efficient over a slow connection.

I once saw a great demo of it by its author, Stephen A. Uhler. For some reason, from then on, I always associate MGR with great big bushy moustaches.

https://media.licdn.com/mpr/mpr/shrink_150_150/p/2/000/013/3...

Post reply on HN