User:ChristTrekker/NouveAUX
 |
Private Essay |
| This is a private essay. If you would like to contribute, please add your comments and suggestions on the talk page, and let the owner review them. | |
| Contribute |
Contents |
What is the NouveAUX project?
From the unofficial comp.unix.aux FAQ: "NouveAUX was an idea proposed on comp.unix.aux in early 2003 to resurrect A/UX, in spirit, if not in fact. This would be done by integrating a Mac OS emulator (such as Basilisk II) tightly with an open-source Unix (such as NetBSD). By doing this, "A/UX" could run on newer machines, such as PowerMacs. The idea never got any further than discussion, mostly because of a lack of clear direction and programmers interested in doing the work."
This document is an attempt at providing that direction. I will discount the arguments that running a System 7 style desktop on a Unix is no longer "really A/UX" or is "boring". Unless you have access to Apple's source repositories, you'll never have a true updated version of A/UX, so something like it is better than nothing at all.
Executive Summary
Essentially, the goal of this project is to build an A/UX workalike. A blend of Unix stability and classic Mac user-friendliness that Mac OS X has forgotten somewhat.
The product of the NouveAUX Project will be the "NouveAUX Desktop Environment", or simply "NouveAUX".
Goals
- Provide an A/UX (i.e. classic Macintosh GUI) interface to Unix.
That's it. I believe that by starting small, with realistic goals, this project might actually gain traction. Besides, with two major architecture transitions (and over 10 years) since A/UX was left to die, I believe it's naïve to think that many people are interested in integrated 68k Mac emulation or running System 7 apps, and Nickster (7/jan/2003) seems to agree. Besides, boon (16/feb/2003) and Nickster (5/mar/2003, 7/mar/2003) make some very good points regarding the difficulties of implementing a "true" Mac environment. Thus, this is Nickster's #5 (14/feb/2003) approach. Even calling it an "alternative OS" is a bit of a stretch.
Nickster's fourth (3/jan/2003) and Rimas' first (3/feb/2003) points are satisfied by selecting virtually any Unix kernel. Since we are not forking a new OS, but only developing a more Mac-like GUI, this is obvious.
If we were developing a new OS, the only two serious contenders to start from are NetBSD and Linux, due to Rimas' second point (3/feb/2003), which I interpret to mean we should support 68k Macs even if for no other reason than nostalgia. OpenBSD/mac68k exists, but I don't think it receives even the small level of attention that the others do. Additionally, more software exists in binary form for these platforms. We can't expect users (yes, I know it's unlikely we'll get many mainstream users, but shouldn't we endeavor to think like Apple engineers?) to compile everything from source.
Rimas' seventh (3/feb/2003) point is satisfied by going with NetBSD, which Karsten supports (15/jul/2003). The base NetBSD is very lean, and far less bloated than Linux. This should be our "target platform", though since we're essentially limiting ourselves to developing a Mac-like window manager/file manager/desktop environment, that work ought to be quite portable to any Unix. It would be awesome if it could be run on A/UX itself!
I don't think we need to go so far into supporting Classic Mac functionality/compatibility as the renaming (or parallel recreation) of directory structure like OS X has done, and Rimas considers (15/feb/2003). Perhaps we could provide a patch that would create "long name" symlinks, but what's the point? Like him, I reject the need for supporting ":" as the filepath separator — but we're not writing a new OS, are we? I disagree that users should have to use the command line sometimes (though I think it's good to have the option), but the goal of NouveAUX (at this time) doesn't extend so far as to eliminate its necessity.
I agree with Antoni (14/jan/2003) and Rimas (6/feb/2003) that we can begin our work by forking from an existing window manager. Here we leverage the power of open source, by standing on the shoulders of those who came before us. I don't know if MLVWM is the best starting point, as it hasn't been actively developed in years. I also don't know if gtk2 is the best toolkit to base it on just because it supports UTF8, though supporting UTF8 is probably a good idea. For one thing, it is very large—gtk1 and fltk are smaller. I have successfully built all three on NetBSD/mac68k though. I've heard/read good things about fltk and wxWidgets. However, I'm not sure that wxWidgets would work for this purpose. Maybe GNUstep would be a good option. Maybe a completely new toolkit is needed.
Actually, the problem isn't so much the window manager or the toolkit. The problem is the fundamental design of how X apps interact with the window manager. In X, it is assumed that the application handles all it's own details, including menus. "Handing off" that duty to something outside the application area is a challenge. What might actually be required is a library that could be compiled into applications to make them able to send/receive the menu information and events to the window manager. This means that for the wm to run correctly, one would need special builds of the apps used. I have no idea if this could be done and maintain the network transparency feature of X, since the client (where the application runs) and server (where the wm runs) could be in different places. It may well be that the decision to support network transparency drove the UI model. But keep in mind I really don't have any idea what I'm talking about here...
Subprojects
There are other "nice to have" things that, while not central to the success of NouveAUX as defined, I'd be willing to extend the NouveAUX project umbrella over if someone was willing to work on them. Sort of like making this project the "A/UX revival central clearinghouse". A short (and incomplete) list:
- a BSD-licensed HFS/HFS+ driver
- additional work on A/UX ports of software (particularly gcc)
- any work toward Mac-emulator integration
- a SWIM floppy driver
