rb@ccivax.UUCP (rex ballard) (02/25/86)
Since I've been making a lot of noise on this subject, I thought I would follow up with a different view. For those in 68K who were just included, the question has been raised as to the possibility of a "Standard OS" for the 68K machines such as Amiga, Atari, and MacIntosh. Unix and OS-9 have been proposed and discussed at length in both net.micro.amiga and net.micro.atari. Consensus thus far has been that Unix has expensive requirements (MMU, Memory, and Hard disks) which would cause prohibitive pricing. OS-9 is a "hot contender", but seems not to be well supported. Since the focus of this debate involves current and future small, graphics oriented 68K machines, followups should be made to net.micro.68k. Any and all systems should be discussed. Ideal candidates should: Be multi-tasking (True pre-emptive). Include "Virtual Device Interface" for graphics devices. Support a "generic graphics file" storage/transfer mechanism for allowing use between applications and machines. Be portable to a number of machines (particularly Mac, Amiga, and ST) preferably using the "BIOS/XBIOS" or whatever low level drivers are currently in the machines ROM. If it can run on a SUN or something big and powerful, so much the better. Other factors: Ease of use to both application programmers and end-users. Hardware requirements (no MMU, small memory, floppy disks). Expandability (adding drivers without re-linking, sharability of driver code). Modularity (Runnable with or without graphics "Desk Top"...) Language support. Price. To start, let's make it a "brainstorming session". For a given OS, tell what is good about it, where the "missing pieces" might be found, special features, third party support,etc.. Let's try to avoid shooting things down initially.
x@mit-prep.ARPA (Dean Elsner) (03/01/86)
Bias: I *LIKE* inter alia RSX-11. I realise I may be the last person in North America to do so. Idea: Could O/S hackers please make the file system detachable from the rest of the O/S? This requires treating file systems like they existed at the other end of a network, and doing remote procedure calls like "create a directory entry for file X and give it name Y". An immediate benefit of this is that when you plug a FOO-format diskette (or binary file) into a BAR-machine all your ordinary utilities keep working but they use a different name for the diskette drive in order to use a different file-system server. More: To do this, you distinguish between a "device-driver" which hides those details of hardware to horrible for ordinary mortals to behold and a "file-system" which assigns meanings to the bit ingested and egested by the device-driver. Not only is this wonderfully useful for disk file systems (eg using Un*x utilities to help manipulate CP/M disks) but the same idea fits very well with terminals. You use a "crt server" to do such things as "scroll window" and this is converted into messages for a "device driver" which tickles the screen to acheive the task. EG: DEC (perhaps to protect some marketroid's career by inventing one more artificially distinct product) sells different flavors of files-11 on different (PDP-11 based) boxes. I recently moved a lot of my file utilities (written in C) from an RSX box (where I had to use numbered, non-heirachical directories) to another PDP-11 in a terminal, which had named, heirachical directories. All my programs worked 1st time on these new directories & file names. By the way, I *ONLY TRANSFERED THE BINARIES*. No compilation was needed to let the programs work with a 'new' file system. I also moved some utilities (for which I had no sources) and they worked 1st time too. Refer: RSX-11 has "Ancillary Control Process"s (ACPs) for file systems. They mix and match with "Device Drivers" which bend the bits. (I know about "class drivers" Virginia, but this is complex enough without recursion, reliability etc issues!) Likewise they have "ACD"s for terminals. Since Vaxen are ubiquitous (and often more 'respectable' you might want to read about ACPs (same concept) on vaxen. I realise that the usual "Un*x is good enough, don't force users to learn more concepts that they need" argument applies. I suggest that the discipline of embedding remote proceedure calls into your operating system (just so it can survive the '80s) will both help you to better organise the un*x concepts and may allow you to flush certain concepts that become redundant as other concepts are generalised for a network environment. If you don't think the "un*x concepts are good enough" argument applies, I could be persuaded to post a similar rave about why I think embedded delimiters in files (eg '\n' in un*x) are a lose. My counter-examples would be based on files-11 (because so many people have access to it) but I got the idea from CDC 60-bit machines and refined it making pdp-11s emulate IBM mainframes (faster that real time!!). I trust (of course) all you O/S hackers will distribute source code to the net. This will give users enough confidence that *someone* near them will maintain the O/S that they will be happier to commit to the O/S. -- x@prep.ai.mit.edu Disclaimer: I am not me.