woju@mist.UUCP (Wolfgang Jung) (06/29/90)
In article <90176.164228RXS12@psuvm.psu.edu> RXS12@psuvm.psu.edu writes: > I found myself swearing too much at TOS the other day and decided to dedicate > the next 10-20 years ;-) writing a complete Unix for the ST, not to really run > under TOS but to replace it. (eventually) > > What I need to know is this: > > 1) Has someone else done this? (No, I am not asking for gulam responses. > it is nice but I wan't *true* Unix.) It is possible (just look at MINIX ST) but a 100 % UNIX cannot be ported to the ST. There is a lack of a real MMU(Like the 68851(3) ). > 2) I don't praticularry feel like having to write the kernel ... does > anyone know of any multi-tasking kernels that have been written for > the ST? Related to this I am going to need a swapper ... same question. > 3) I will also need a C compiler that is powerful enough to understand > everything that I will need to use. Any suggestions? Just look into MINIX, and i think you will find what you need... -- ============================================================================# # Wolfgang Jung Email:a)woju@mist.UUCP # # Bang:..!tmpmbx!unlisys!image!mist!woju # ============================================================================#
buggs@cup.portal.com (William Edward JuneJr) (07/02/90)
>I want to eventually have this: >True Unix which is modeled after 4.3 BSD and (If I get some support...) >Mach with some "enhancements" Sounds killer! I too would like this, though it sounds like a dream.... Don't get me wrong, if you CAN do this, buy all means do so! I will definately want to get this! Ed June
ericco@stew.ssl.berkeley.edu (Eric C. Olson) (07/02/90)
I like Un*x. I like my Sparc 1 at work. I like X. I like NFS. Too bad that Laser C on the Atari provides a comparable compiling environment AND is faster for development. I don't know that exact nature of the speed problem on the Sparcs, but I think that its the multi-processing environment in Un*x. Start up times for processes are measure in seconds, since the kernal must create a new virtual machine for each process. The performance of such a system makes it unreasonable to associate a single window with a single process -- the time cost is too high. I recently used a flight simulator on a Sparc -- incredibly rudimentary, just like stuff you see on pcs (BTW, it also used a graphics accelerator board). I think its slow because to the multi-processing philosophy -- the sever gets the mouse events, figures out who owns them, sends them off, some computations are done, a bunch of graphic primitives are sent back, which the sever displays. Meanwhile, various processes are being swapped in and out memory. The bottom line is that the sparc machine is much more powerful than pcs, but its user interface performance is not. I've also used Lisp Machines and Xerox Interlisp machines. These guys are multi-tasking, and the interface has a much higher throughput. Multi-tasking is coming back in vogue, with top people at Sun indicating that they are interested in moving in this direction. There is much discussion about light weight processes. For the Atari ST, multi-tasking is really the only choice since it can't provide the virtual machine environment required for multi-processing. I suspect the OS/9, Minix, and MTcsh are all true multi-tasking OS. I expect that no one would be able to tell the difference between multi-processing and multi-tasking code that was well written. Of course, there is the system resource problem in multi-tasking -- usually memory violations in poorly written code. But, the underlying implementation of MTcsh seems like a very reasonable start at sharing system resources such as disk drives, etc. Use of a sophisticate language like Lisp would eliminate memory violations. In short, I think that there is a place for machines like the Atari ST in the future. But developers (and users) need to focus on computing in the 90s, not what was in fashion in the 80s. Light weight processing in a robust environment is certainly an obtainable goal for the Atari ST. Eric ericco@ssl.berkeley.edu