Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!ames!pasteur!cory.Berkeley.EDU!navas From: navas@cory.Berkeley.EDU (David C. Navas) Newsgroups: comp.sys.amiga.advocacy Subject: Re: Amiga OS *IS* state of the art Message-ID: <12393@pasteur.Berkeley.EDU> Date: 2 Apr 91 18:19:51 GMT References: <1003@cbmger.UUCP> <7827@jhunix.HCF.JHU.EDU> <8806@gollum.twg.com> Sender: news@pasteur.Berkeley.EDU Reply-To: navas@cory.Berkeley.EDU Lines: 99 In article <8806@gollum.twg.com> david@twg.com (David S. Herron) writes: >In article <7827@jhunix.HCF.JHU.EDU> barrett@jhunix.HCF.JHU.EDU (Dan Barrett) writes: >> Now now... let's not get carried away. The Amiga OS is very, very >>nice, that is true. I like it a lot. But no way is it "state of the art" >>in the 1990's! >> >> For example, it doesn't have: >> >> - Virtual memory Wouldn't mind it as an option -- useful for many applications I can think of. Probably not useful for the general "kernel" >> - Memory protection See comment next: >> - Resource tracking Resource Tracking is nice, as long as you're not always passing memory pointers between one's programs. What's that -- the Amiga does that? Horrors... As an option it's nice -- so use malloc()... Oh, yeah -- Screen's and stuff. If you *really* need resource tracking, it's a week project -- maybe three weeks for 2.0 [because there are more system structures and stuff to learn]. Just use self-identifying data structures, and free everything according to its type via library calls. Implementation is left up to the imagination of the reader. It's not quite that simple, but it ain't hard neither. >> - Multi-user capabilities For business networking we need multi-user protection -- maybe those COMMENT fields could be put to use... >Yes, BUT -- these features are not NECESSARY. Further in order >to have them you pay a performance penalty which, apparently, >Commodore is unwilling to pay. Yes each would be very nice to have. Each would be nice to have, PROVIDED they don't change the way I can already do stuff. Look, stop programming the Amiga as if it was a Unix box. THE AMIGA IS NOT UNIX. THE AMIGA IS NOT MSDOS. Thank you. If you want MS-DOS, buy an MS-DOS machine, or the Bridgeboard. If you want Unix, buy Unix. My Amiga uses Exec, and I generaly like it. This machine has some capabilities which I find completely indispensable, and they are unique to this machine. If folks would stop programming the thing as if was a single-tasking machine and use the message passing capabilities to their fullest, the Amiga would be an *innovative* work whose software could not hope to be ported to other platforms, because of the lack of fundamental Amiga kernel operations. This applies to some folks at Commodore too -- although I suspect it's a lack of time and resources. Ah well. I can't imagine Kent Polk's IPC work to be done on either the IBM or the Mac, and frankly it would be a real royal pain in the butt to implement a fast IPC protocol under Unix. Ask Prof. Ousterhout at UC Berkeley, apparently he's done it via calls to X-Windows. Icky and slower than molasses on a Sparc! Plea to fellow developers: STOP TREATING AMI LIKE A NORMAL PC. SHE AIN'T! >To have virtual memory: Obviously most Amiga's don't have MMU's, a > Currently AmigaDOS processes > share the same address space & who knows what will break > when that is changed. Everything that I think makes the Amiga both unique, and a useful machine. That's all. Of course, if shared memory was the default, maybe then we'd be talking... > Both these would be nice though.. especially memory protection > for all instead of just for developers. Don't buy software with bugs. Of course, that includes Cmdre's own kernel, so... >Resource tracking: Well.. obviously the kernel needs to be keeping > > Opion-Time: One of the jobs of an OS (or as I see it) > is to "beautify" the users/programmers environment. > That is.. make it simpler than "raw hardware". Resource > tracking is one of those boring jobs which programmers > do not do well. Especially in C where there are no > built in facilities to help out! Like I said, it's probably a week job for 1.3. malloc already does it for every memory allocation. All you need is screens, windows, etc. pointers to which are kept in a linked list which identifies the data. The rest is so simple, I might write it one of these days for kicks. David Navas navas@cory.berkeley.edu 2.0 :: "You can't have your cake and eat it too." Also try c186br@holden, c260-ay@ara and c184-ap@torus