peterk@cbmger.UUCP (Peter Kittel GERMANY) (03/25/91)
Just having scanned through the latest BYTE issue (March issue,
they seem to use rowing boats to ship here to Europe), I gathered
more confirmation for the fact that our Amiga OS really is state
of the art in OSes: There is an article describing a new operating
system named TAOS that will run on many platforms. When I read
about some of the details - object-oriented, message passing,
windowing GUI, etc. - all sounded very familiar to me. And when
reading that the creator of this OS is known as an expert Amiga
game programmer (well, also ST, etc.), then I can't avoid the
impression that this at least got some vital inspirations from
Amiga OS. But why not? Computer science is evolving, and no one
is to blame when he profits from ideas that have turned out as
efficient.
(BTW: Anyone still to blame those nasty game programmers? :-)
The way that the TAOS system achieves multi-platform compatibility
is very interesting: It uses the old concept of a virtual machine
(now of course a virtual *RISC* machine :-). But you need not fear
the slowness of old-days P-code systems, in contrast to them,
TAOS translates every code at *load* time into native processor
code, not at *run* time. I think this won't slow down a loader
more than today's scatter loader or any packer loader. Perhaps
it will be even faster because of compact code size.
And talking about such similar operating systems, another parallel
comes to my mind: Geoworks Ensemble for PCs. You know, this stems
from the people who made GEOS for the C64 which already in those
times provided tremendous performance when considering the
underlying platform. Now the same has obviously happened to the
PCs: Ensemble is *much* faster than Windows (it's even said to
run conveniently on a simple XT!), and does this with magically
compact code, again making it possible to run also on old PCs.
Now compare that to memory hogs like Windows or PM.
But what has this all to do with Amiga OS? Well, once I scanned
through the programming manual of C64 GEOS (back in 86 or so),
and I was immediately caught by the impression that they used
similar principles as the Amiga OS, mainly the object-oriented
data structures and system calls. As GEOS is of nearly the same
age as Amiga OS, you cannot say they took ideas from Amiga OS,
but they followed the same ideas as our guys.
Now, if Geoworks wouldn't already have done this, how about
someone porting the Amiga OS to the PC hardware platform???
Ok, it wouldn't be SO useful, because you couldn't provide
compatibility to run old MS-DOS programs and thus would have
to compete directly with UNIX on PCs. But as long as Microsoft
officially talks about porting their Windows (or was it OS/2?)
system to quite different platforms, I think also this idea
appears legal :-).
This all leads me to the conclusion that examples of this kind
demonstrate that Amiga OS is well up with the current state of
the art in OS design. Ok, there also exist newer developments,
like the mentioned TAOS being aimed from scratch also towards
multiprocessor platforms (a thought which was well beyond spec
in the first Amiga OS days), but I'm confident that the open
design will leave enough room for further development and
keeping track with new ideas.
--
Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions...
Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterkbarrett@jhunix.HCF.JHU.EDU (Dan Barrett) (03/26/91)
In article <1003@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >Just having scanned through the latest BYTE issue (March issue, >they seem to use rowing boats to ship here to Europe), I gathered >more confirmation for the fact that our Amiga OS really is state >of the art in OSes: 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 - Memory protection - Resource tracking - Multi-user capabilities Even if it did, these ideas are *old*, and not "state of the art". If you want to see a "state of the art" operating system, take a look at current research at places like University of Illinois (CHOICES) and AT&T (various successors to UNIX; I forget the names). >...BYTE Magazine.... I don't think BYTE knows shit about "state of the art". As a PC magazine, it's OK, but don't judge the future by it. :-) Dan //////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ | Dan Barrett, Department of Computer Science Johns Hopkins University | | INTERNET: barrett@cs.jhu.edu | | | COMPUSERVE: >internet:barrett@cs.jhu.edu | UUCP: barrett@jhunix.UUCP | \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\/////////////////////////////////////
mykes@sega0.SF-Bay.ORG (Mike Schwartz) (03/26/91)
In article <1003@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: > >Just having scanned through the latest BYTE issue (March issue, >they seem to use rowing boats to ship here to Europe), I gathered >more confirmation for the fact that our Amiga OS really is state >of the art in OSes: There is an article describing a new operating >system named TAOS that will run on many platforms. When I read >about some of the details - object-oriented, message passing, >windowing GUI, etc. - all sounded very familiar to me. And when >reading that the creator of this OS is known as an expert Amiga >game programmer (well, also ST, etc.), then I can't avoid the >impression that this at least got some vital inspirations from >Amiga OS. But why not? Computer science is evolving, and no one >is to blame when he profits from ideas that have turned out as >efficient. >(BTW: Anyone still to blame those nasty game programmers? :-) RJ Mical is a game programmer, too! He wrote the coin-op game Sinistar and also did Defender of the Crown. >-- >Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... >Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk -- ******************************************************* * Assembler Language separates the men from the boys. * *******************************************************
barrett@jhunix.HCF.JHU.EDU (Dan Barrett) (03/28/91)
>I wrote: >> For example, [the Amiga OS] doesn't have: >> - Multi-user capabilities In article <1991Mar27.062345.6622@sserve.cc.adfa.oz.au> l-tarantello@adfa.oz.au (Luke Tarantello) writes: >I agree except for the last point. I don't think that the Amiga needs to >be multi-user. As an example, a SPARC 2 is nice and fast - until 6 or so >people are logged in (ie the perceived performance per user is degraded)! That's a different issue: SIMULTANEOUS multiple users. I would still argue that, for an OS to be "state of the art" (as was claimed by the original poster), it has to have some concept of file ownership; a multiple user model in which a user "owns" a file. If my friend sits down at my Amiga and works for a while, I want reassurance that he cannot accidently delete my files, NO MATTER WHAT. This is what I mean by "multi-user capabilities" -- that several people can use the same Amiga (not necessarily at the same time) and nobody has to worry about corrupting another person's data. I claim that an OS without this feature is not "state of the art". That's all I'm claiming -- no more, no less. Dan //////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ | Dan Barrett, Department of Computer Science Johns Hopkins University | | INTERNET: barrett@cs.jhu.edu | | | COMPUSERVE: >internet:barrett@cs.jhu.edu | UUCP: barrett@jhunix.UUCP | \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\/////////////////////////////////////
kudla@rpi.edu (Robert J. Kudla) (03/28/91)
In article <7840@jhunix.HCF.JHU.EDU> barrett@jhunix.HCF.JHU.EDU (Dan Barrett) writes:
I claim that an OS without this feature is not "state of the art".
That's all I'm claiming -- no more, no less.
Okay - but I claim that a personal computer OS doesn't need
file/process ownership, security, or any of the junk Unix, VMS, etc
have to allow multiple users. A friend and I were trying to kludge
out a little bit of multiuser functionality once just for fun since we
were sharing a computer, but realized it was really pretty unnecessary
when people can't be simultaneously using it.
Once you put one in an educational or corporate environment you need
multiuser capability, but I daresay in such an environment it's no
longer a personal computer.....ckp@grebyn.com (Checkpoint Technologies) (03/28/91)
In article <7840@jhunix.HCF.JHU.EDU> barrett@jhunix.HCF.JHU.EDU (Dan Barrett) writes: > I would >still argue that, for an OS to be "state of the art" (as was claimed by the >original poster), it has to have some concept of file ownership; a multiple >user model in which a user "owns" a file. I think that the reality of file ownership on a Personal Computer is determined by who can put their finger on it. Try this: put your finger on a floppy disk, or on your hard disk drive. You own all that data. If you can touch it, it's yours. Never mind what the OS may try to prevent you from doing with it. This goes with my other philosophy, about granting user account privileges on any computer system. The user that can reach the power switch has all the privileges, and you'd better get used to that. > If my friend sits down at my Amiga and works for a while, I want >reassurance that he cannot accidently delete my files, NO MATTER WHAT. >This is what I mean by "multi-user capabilities" -- that several people can >use the same Amiga (not necessarily at the same time) and nobody has to >worry about corrupting another person's data. No "personal computer" can guarantee this. When your friend sits down to your Amiga, he can reach the power switch; see what I said about "user account privileges" above. :-) Now, I can imagine that this Amiga might be part of a network (imagining, of course, that the current state of Amiga networking improves) where there are multiple users on a network, and the network allows file sharing between network peers. In this case, it is vital that your Amiga only grant access to those files you specifically want to export. They are your files, after all. And you may even want to decide which other user is granted access. So now "file access rights" begins to have meaning, but ownership is *not* in question. They're your files if they're on your disk. -- First comes the logo: C H E C K P O I N T T E C H N O L O G I E S / / ckp@grebyn.com \\ / / Then, the disclaimer: All expressed opinions are, indeed, opinions. \ / o Now for the witty part: I'm pink, therefore, I'm spam! \/
vsolanoy@ozonebbs.UUCP (Victor Solanoy) (03/29/91)
barrett@jhunix.HCF.JHU.EDU (Dan Barrett) writes: > In article <1003@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) write > >Just having scanned through the latest BYTE issue (March issue, > >they seem to use rowing boats to ship here to Europe), I gathered > >more confirmation for the fact that our Amiga OS really is state > >of the art in OSes: > > 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 > - Memory protection > - Resource tracking > - Multi-user capabilities > > Even if it did, these ideas are *old*, and not "state of the art". > > If you want to see a "state of the art" operating system, take a > look at current research at places like University of Illinois (CHOICES) and > AT&T (various successors to UNIX; I forget the names). > > >...BYTE Magazine.... > Some of the weaknesses you mention are probably a result of the limited abilities of the 68000 processor used in 'stock' Amigas... and not the operating itself. Victor
peter@sugar.hackercorp.com (Peter da Silva) (03/30/91)
In article <1991Mar27.062345.6622@sserve.cc.adfa.oz.au> l-tarantello@adfa.oz.au (Luke Tarantello) writes: > I agree except for the last point. I don't think that the Amiga needs to > be multi-user. You don't need to have multiple users on a box to be in a multi-user environment. ANY NETWORK is a multi-user environment, and the kludges that PC network people do to deal with this (Novell actually installs a large part of a whole new O/S!) are absolutely ghastly. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (03/30/91)
In article <1991Mar28.051303.4703@grebyn.com> ckp@grebyn.com (Checkpoint Technologies) writes: > This goes with my other philosophy, about granting user account > privileges on any computer system. The user that can reach the power > switch has all the privileges, and you'd better get used to that. You can reboot the IBM-PC clone in my bedroom all you want, and unless you bring your own O/S in with you you will not be able to defeat the multiuser protection. I do not own a copy of MS-DOS. I do not have an MS-DOS disk in my entire apartment. To get that data you have to walk out with it. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
jbickers@templar.actrix.gen.nz (John Bickers) (03/30/91)
Quoted from <1991Mar29.184119.5083@sugar.hackercorp.com> by peter@sugar.hackercorp.com (Peter da Silva): > You can reboot the IBM-PC clone in my bedroom all you want, and unless > you bring your own O/S in with you you will not be able to defeat the Hm. I take a DOS disk out with me when visiting people whose machines need fiddling with at work. And a disk editor, and a binary file editor, and a couple of other things. So you should expect people to be carrying these things. You want a gadget to zap their disks as they walk in the door... or climb in the window... :) > MS-DOS disk in my entire apartment. To get that data you have to walk > out with it. The practical approach to taking data, analagous to the practical approach to cryptography, stealing people's keys (to paraphrase Mr Gwyn). > Peter da Silva. `-_-' -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Patterns multiplying, re-direct our view" - Devo. ***
david@twg.com (David S. Herron) (03/30/91)
In article <7827@jhunix.HCF.JHU.EDU> barrett@jhunix.HCF.JHU.EDU (Dan Barrett) writes: >In article <1003@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >>Just having scanned through the latest BYTE issue (March issue, >>they seem to use rowing boats to ship here to Europe), I gathered >>more confirmation for the fact that our Amiga OS really is state >>of the art in OSes: > > 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 > - Memory protection > - Resource tracking > - Multi-user capabilities 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. To have virtual memory: Obviously most Amiga's don't have MMU's, a required piece of hardware there. Regardless I've never heard of an OS with virtual memory in which all processes shared the same address space. Currently AmigaDOS processes share the same address space & who knows what will break when that is changed. Yes I know about MEMF_PUBLIC & etc. I remember reading here, however, that a lot of programmers are lazy about setting that flag "right" ... Obviously a program which needs real time response for some reason cannot be swapped out. Adding a call to lock a process in memory would be necessary. Once the kernel is in a seperate address space than the other processes then system calls and interrupts become more expensive. That is .. context (CPU registers and such) need to be saved away. If pointers passed in system calls are not in public memory (that is, accessible by every process) then the kernel has to do funny tricks with the MMU to copy bytes in & out of user memory. etc. To add memory protection: Again this requires an MMU. Same comments apply as above. Both these would be nice though.. especially memory protection for all instead of just for developers. (Aside, there's a developer tool I've heard about which adds memory protection as an aid for finding things like wild/NULL pointers). Resource tracking: Well.. obviously the kernel needs to be keeping track of what it doles out & that means more code, eh? I really do NOT understand why this isn't there and don't see that doing it in a user program versus the kernel is going to be any faster. I remember one of the cbmvax.cbm.com crowd (Randall Jessup maybe?) claiming that he thought the right way for a process to exit is to commit suicide. **SIGH**! 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! (For more OS principles, I refer you to [Raphael Finkel] _An Operating Systems Vadae Maecum_ (Hope I spelled that right... been a few years since I looked at the book)). Multi-User capabilities: ***WHY***??? This is a single user machine, why do you want others to use it?!? 'sides, there's some PD-ware about which will do that.. UUCP for instance. Again from what I understand/hear-from-the-inside/etc it is a very conscious decision to not have those capabilities. >Even if it did, these ideas are *old*, and not "state of the art". Yes.. but still AmigaDOS is a very up-to-date OS having many features which are at if not close to state of the art. > If you want to see a "state of the art" operating system, take a >look at current research at places like University of Illinois (CHOICES) and >AT&T (various successors to UNIX; I forget the names). Jeez.. he left out Mach, Sprite and a few others. David -- <- David Herron, an MMDF & WIN/MHS guy, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- "MS-DOS? Where we're going we don't need MS-DOS." --Back To The Future
u3364521@ucsvc.ucs.unimelb.edu.au (Lou Cavallo) (03/30/91)
G'day, > In comp.sys.amiga.advocacy David S. Herron (david@twg.com ) writes: >> In comp.sys.amiga.advocacy Dan Barrett (barrett@jhunix.HCF.JHU.EDU ) writes: [...] >> For example, it doesn't have: >> - Virtual memory >> - Memory protection >> - Resource tracking >> - Multi-user capabilities > 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. > > To have virtual memory: Obviously most Amiga's don't have MMU's, a > [...] > To add memory protection: Again this requires an MMU. Same comments > [...] > Resource tracking: Well.. obviously the kernel needs to be keeping > [...] Thanks for the technical tips on the difficulties here. My only comment is that I _think_ many do expect CBM to add these features in when there is a perceived market demand ... i.e. this is a question of when rather than if. > Multi-User capabilities: ***WHY***??? This is a single user > machine, why do you want others to use it?!? 'sides, > there's some PD-ware about which will do that.. UUCP > for instance. I think the justification should be "for network use in educational and business environments" *with* the caveat that the home user shouldn't be stuck with having to pay the price of code and resource bloat in the OS. I feel that PD-ware is not enough for business/educational environments. > Again from what I understand/hear-from-the-inside/etc it is > a very conscious decision to not have those capabilities. I'm persuaded by that point of view also... but I wonder and wish to ask whether features like multi-user abilities and virtual memory can be de- signed to be turned on optionally by the user willing to and equipped to take advantage of them? Any comments here? yours truly, Lou Cavallo. PS: I have a pet theory that multi-user and distributed computing features could play a key role in multi-media groupware e.g. a creative arts or video production group setup where artists and technicians could work together "live" on Amiga multimedia production. Should (or even can) CBM innovate in OS support for this sort of thing or should other companies get the lime-light for this type of innovat- ion? { Truly an advocacy type of question, no? :-) }
rblewitt@sdcc6.ucsd.edu (Richard Blewitt) (03/31/91)
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: >>In article <1003@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: > >> If you want to see a "state of the art" operating system, take a >>look at current research at places like University of Illinois (CHOICES) and >>AT&T (various successors to UNIX; I forget the names). The last I saw of CHOICES, about a year ago, it had finally reached a point where if you did nothing, it would not crash, doing anything would cause it to crash. Also, the point of CHOICES was to create a clean object-orientated operating system, much of which, the Amiga already has. Given that it works, I'd say the Amiga is more state of the art, although I agree that it needs resource tracking and memory protection. Rick
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (03/31/91)
In article <17876@sdcc6.ucsd.edu> rblewitt@sdcc6.ucsd.edu (Richard Blewitt) writes: >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: >>>In article <1003@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >> >>> If you want to see a "state of the art" operating system, take a >>>look at current research at places like University of Illinois (CHOICES) and >>>AT&T (various successors to UNIX; I forget the names). > >The last I saw of CHOICES, about a year ago, it had finally reached >a point where if you did nothing, it would not crash, doing anything >would cause it to crash. Also, the point of CHOICES was to create a >clean object-orientated operating system, much of which, the Amiga >already has. Given that it works, I'd say the Amiga is more state >of the art, although I agree that it needs resource tracking and >memory protection. > >Rick Agreed. Most applications implement the resource tracking logic over and over and over again. A couple of points though... The aims of the ROM Kernel were to provide programmers with routines which we can wrap our own stuff around. Any higher level approach would paint us into a corner and force us to do things a specific way. Remember, the initial pitch to developers was anti-evangelism (i.e. the Mac way). Secondly, resource tracking would have to be done in such a way that doesn't preclude some of the power that the OS currently has. For example, one task can create a message port for another task and can then exit without the resource going away. The same is true for messages themselves. ARexx is built around this capability. One developer I've seen has implemented a loadable library that does his resource tracking for him. Instead of calling AllocMem, he calls the AllocMem in his library and when his task exits, the memory is deallocated automatically. He does the same thing for Windows, Menus, Gadgets, and the other various resource that you normally have to keep track of in software. In addition to the resource tracking facility, the library also reimplements many of the ROM Kernel routines (friendly with the OS) so they perform better. -- ******************************************************** * Appendix A of the Amiga Hardware Manual tells you * * everything you need to know to take full advantage * * of the power of the Amiga. And it is only 10 pages! * ********************************************************
kris@tpki.toppoint.de (Kristian Koehntopp) (03/31/91)
david@twg.com (David S. Herron) writes: >To have virtual memory: Obviously most Amiga's don't have MMU's, a > required piece of hardware there. Regardless I've never > heard of an OS with virtual memory in which all processes > shared the same space. Currently AmigaDOS processes > share the same space & who knows what will break > when that is changed. Obviously virtual memory has nothing to do at all with seperated address spaces of processes The code needed to install VM on an A3000 or A2500 is below 10 KB, as was demonstrated with the Evolution HDD controller. Also the long exspected System 7 for the Apple Macintosh computer is said to provide VM without seperated address spaces. Since a true PMMU is required for VM, most vendors also chose to integrate address space protection in their systems. If you already have the PMMU on your board, design and performance penalties due to memory protection are not too high considering the gain in system stability. Mac and Amiga are systems which came originally without a PMMU. Thus their OS makes it difficult to take advantages of the ability to separate process address spaces, but VM alone can be implemented below OS level. The OS itself sees only an enlarged RAM and need not to have knowledge of the special nature of this memory. Amiga processes do not change from user to kernel mode, when making calls to libraries, because they call them by simple JSRs. There is simply no concept of operating system private data and code in the current release of Amigas OS. Also there is no defined interface for reading operating system data. This lead to the bad practice of reading operating system structures from user code (eg reading the list of screen structures to find a certain screen or reading dos libraries lock structures etc ). I know that direct reads are faster, but this code will break, if the layout of the read structure changes due to OS upgrades (as in the first releases of KS/WS 2.0). In a properly designed operating system there are calls which return the desired information to you in a well known format. This format can, but need not be identical with the operating systems internal representation of this data. I feel that adding the concept of operating system private data and the distinction of user and kernel mode will break the concept of Amigas OS. Thus we will probably never see memory protection with this system. > Yes I know about MEMF_PUBLIC & etc I remember reading > here, however, that a lot of programmers are lazy about > setting that flag "right" > Obviously a program which needs real time response for > some reason cannot be swapped out. Adding a call to > lock a process in memory would be necessary As you implied in the paragraph above, there is already a mechanism to identify memory with different properties. This mechanism (In OS/9 it is called "colored memory". I find it funny to think about a request for green ram :-) is also supported by the loader. If you had a bit MEMF_VIRTUAL added and your memory had the properties MEMF_VIRTUAL or MEMF_FAST (but not MEMF_PUBLIC), you could easily request true memory (by requesting MEMF_PUBLIC), VM (by requesting MEMF_VIRTUAL) or any type of memory (just request MEMF_FAST or even MEMF_ANY ( == 0)). Since this is also supported by the loader, you can even create a file that is loaded into real mem. Thus such call is not needed. > such) need to be saved away If pointers passed in > system calls are not in public memory (that is, accessible > by every process) then the kernel has to do funny tricks > with the MMU to copy bytes in & out of user memory etc Can you explain? Think of a user process supplying a pointer to a given location. Think of this location as paged out. The OS (or the user process, since it makes no difference) references this location and produces a page fault, that is, an exception. The exception handler pages some other page out (prefereably not the one referenced next!) and the requested page in. The exception handler terminates and operation resumes with the reexecution of the interrupted statement. Of course the exception handler for VM itself better remains in memory, but other exception handlers and interrupt handlers *can* easily be paged out, if memory and not performance is the problem. For interrupts and exceptions which are exspected to be handled in real-time (and better overall system performance) you better allocate real memory. I can see no need for funny tricks here and I believe you were still stuck with the memory protection concept, but of course I may be wrong. >To add memory protection: Again this requires an MMU. Same comments > apply as above. > Both these would be nice though, especially memory protection > for all instead of just for developers. (Aside, there's > a developer tool I've heard about which adds memory > protection as an aid for finding things like wild/NULL > pointers) Well, I guess, you are talking about the enforcer. This program protects the lowest KB of memory against anything but a longword read at loc 4. It also catches writes into ROM-areas and any references to areas without installed memory. All these references are reported and the offending task is identified, but not killed (Killing tasks is difficult with the Amiga Reason see below). Still no memory protection <sigh>. >Resource tracking: Well, obviously the kernel needs to be keeping > track of what it doles out & that means more code, eh? > I really do NOT understand why this isn't there and don't > see that doing it in a user program versus the kernel > is going to be any faster. Agreed. Ressource tracking or better the lack of it is the second _BIG_ flaw of AmigaOS (With the lack of user vs kernel mode being the first). Of course you can provide code which is called upon termination (also abnormal termination) of a process, but keeping track of any ressource ever used in a programm is a job an application programmer is not supposed to do. Think of an application opening a printer, printing something, the closing the printer. No cleanupnclose()-function will ever bother to check if the printer is still open and close it (the pointer to the printer file could also easily be local and long be gone). But your process can be killed between the open and the close of the printer, leaving the device open and locking all other processes away from the printer. Time for reboot again (For some this has also been the time to junk their Amiga and get a real computer! Pun intended!). With ressource tracking the OS knows about the owner of the open printer and can close it, if necessary, freeing the ressource for other processes. Since AmigaOS already does half-hearted ressource tracking (Well, it knows about free ressources, but not about those alloctated), when will we see the other half? This can be done without breakin the concept of the OS. >Multi-User capabilities: ***WHY*** This is a single user > machine, why do you want others to use it 'sides, > there's some PD-ware about which will do that UUCP > for instance Multi-User capabilities, especially a concept with user identification and file ownership will significantly ease the implementation of any networking environment with AmigaOS. Of course it will be somewhat ridiculous for an A500 owner to log into his 512 KB, single drive system, so one might have this optional. Also there can be no real protection of your data as long as anyone can read the address space of your processes, but file ownership will protect you against accidential deletion or modification of your files. I would like to see the file system extended in a way, that allows the attachment of an arbitrary long list of (attribute, list of values) sets to any file. This is similar to, but not as limited as, the filenotes. On top of this you can implement file ownership (and even be more specific with that than Unix). As you can see, AmigaOS has some big deficiencies. All of them but one can be repaired without forcing it. And this makes AmigaOS a good and state-of-the-art OS: It is able to grow to fit grown needs. ><- "MS-DOS Where we're going we don't need MS-DOS " --Back To The Future Kristian PS: Excuse my bad english. I find it difficult to talk about these things in this strange language, but I hope I was clear enough to bring the essence of it to you. PPS: Please keep any reply to me short, because I have to pay for incoming mail. Kristian Koehntopp, Harmsstrasse 98, 2300 Kiel, +49 431 676689 "Im uebrigen ist 'Z-NETZ-Sysops quaelen' auf Dauer weder lustig noch befriedigend." - sysop@infinet.zer.sub.org
kris@tpki.toppoint.de (Kristian Koehntopp) (04/01/91)
[ Please feel free to adjust the Followup-To:-line as appropiate ] Well, now I even following up to my own articles. I had a talk with a friend (He is an A3000 owner) on Amiga and its future. Being more the suit type than me, he said "What is going to hurt future Amiga sales more than a lack of 1280 * 1024 in true color is the lack of 320 * 200 in 256 colors." The availability of this video graphics mode makes it easy to port VGA games to the amiga without having the entire graphics repainted by an artist. In his opinion we are going to see less ports of games from IBM to Amiga, if Amiga graphics does not improve in this area. Has anyone got an idea, what the average commodore customer looks like? Is it the 15-25 year old "grown up quality-games player", if such species does indeed exist? I consider his argument quite striking, since 320 * 200 in 256 colors can be done relatively easy with only minor redesigns of the current custom chips, as far as I know. My experience in VLSI design is very limited and only theoretical, but I suggest the following (I have already tried to express this in another article "Why no 320 * 200 * 8 ?"): This is what I know: The three big Amiga custom chips are in fact one single big VLSI IC, that had to be split up due to size limitations of silicium chips. These three chips communicate via the register bus, an 8 addressbits and 16 databits wide specialized bus. This bus is the reason, why the copper can only write to custom chip locations and not into normal memory: The copper can only generate addresses on that register bus. Addresses of 8 bits, each 16 bits wide, give you 512 bytes of custom chips area. From the RKM, Hardware reference manual, I know that in low resolution mode there are 2 unused time slots per pixel. If they were used, one had 8 bitplanes available per pixel, loading the bus as if it were in hi-res/4 bitplane mode. I guess, hardware for this additional dma channels is missing. To make 320 * 200 * 8 usable one had to do at least the following: - add 2 additional dma channels (same functionality as the current 6 video dma channels) - add 2 more address lines to the internal register bus - add 256 32 bit wide color registers covering the address range from register $200 to register $400 (the back 512 register adresses) - redirect the current 32 16 bit wide color registers to the appropiate bits in the new color register bank for compatibility - fiddle with the copper instruction format and the sprite and dual playfield hardware to make it consistent. - replace the current 12 bit video d/a converters with 24 bit converters Well, rereading the list, I come to the conclusion that might not be as easy as I considered it at first thought. Perhaps one of you techies can shade some light on the particular problems one should exspect doing such an chipset upgrade. I really want to know, if it could be done! Kristian Kristian Koehntopp, Harmsstrasse 98, 2300 Kiel, +49 431 676689 Jeder Mann kann eine Frau dorthin bringen, wo sie ihn haben moechte. -- kruemel@citymail.zer.sub.org
davewt@NCoast.ORG (David Wright) (04/02/91)
In article <7840@jhunix.HCF.JHU.EDU> barrett@jhunix.HCF.JHU.EDU (Dan Barrett) writes: > That's a different issue: SIMULTANEOUS multiple users. I would >still argue that, for an OS to be "state of the art" (as was claimed by the >original poster), it has to have some concept of file ownership; a multiple >user model in which a user "owns" a file. >...... > I claim that an OS without this feature is not "state of the art". >That's all I'm claiming -- no more, no less. Name one single-user-at-a-time OS that does this (not some kind of LAN OS like Novell, but a real, optimized for one user at a time but still multitaksing OS that runs on PC class machines. Until there is one that does these things, *AND* does everything else the Amiga OS does just as well as the Amiga (shared libraries, unlimited RAM, dynamic device drivers, etc.), you can't compare it. That's like me saying that "if a car doesn't hover 500 feet off the ground, cruise at mach 2 at 4 kilometers, and come with sidewinder missiles it isn't state of the art". For something to be better than something it has to EXIST, not just be what someone comprehends COULD exist. In fact, OS/9 had almost as much as the Amiga did, for it's day, and it DID have real multi-user abilities. As did MP/M. Does that make it state of the art? Is Unix state of the art? Hardly. I have yet to see ANY Unix system that makes as much use of dynamic shared libraries as the Amiga, or provides dynamic shared libraries as SOP for things such as shells, so that even common things like regular expression matching could be done in one place instead of in each program that wan't to do it. Don't mistake something that is more "powerfull" with something that is "state of the art". The two aren't the same. Dave
davewt@NCoast.ORG (David Wright) (04/02/91)
In article <q!8fk1c@rpi.edu> kudla@rpi.edu (Robert J. Kudla) writes: > >Okay - but I claim that a personal computer OS doesn't need >file/process ownership, security, or any of the junk Unix, VMS, etc >have to allow multiple users. A friend and I were trying to kludge I agree. And if the Amiga had it it would be dead by now. The smooth optimization for single user use, and a constant search for making things smaller and more reuseable is what makes the Amiga's GUI as fast and as useable as it is on a 7Mhz 512k machine. Just try running Win3 on a 8Mhz 512k '286 or '386. >out a little bit of multiuser functionality once just for fun since we >were sharing a computer, but realized it was really pretty unnecessary >when people can't be simultaneously using it. Actually, they can, as long as you control what they do. Take for example a BBS. The Amiga is the best possible machine to run a BBS on, for the money. The native OS is multitasking, as has a lot of shared resources. It is very easy to write code to go into a shared library, so chances are that if you know how to program (and aparently the people at C-Net and Paragon don't), you can easily write a BBS that will only require ONE copy in memory no matter how many users are online at a single time. Take a look at Amiga Empire. I have personally run 4 users at a time on a 1 meg Amiga 500 (using a custom multiplexer interface and driver software I wrote), and was only limited by the number of modems I had at the time. I have also run 3 users on a 512k Amiga 500. None of the users were able to tell that anyone else was using the system. I tend to think that a properly written BBS program could do more and be more powerfull than Unix for managing files, since Unix has to be generalized for doing more than just handling the ownership of files and sending/receiving messages. The OS doesn't have to be multi-user to allow multiple users. You can put that into another layer on top of the OS, and you will be more free to optimize it to your needs, rather than a system-wide level of security that may not be enough in some cases, but too much in other cases. As a maximum test I have tried running one C= 7 port card, one ASDG 2 port card, and the built-in serial port on my 3000 (some people brought the c= board and some terminals) and running an Empire session on each of them, plus 10 on the local console, and I still didn't notice any real delays in throughput (with the obvious exception of when the server was busy with an action like flushing the buffers to disk). There is no reason that a BBS, written properly, shouldn't be able to support 3 remote users on a 2000 (with an ASDG serial port card) and 1 meg of RAM, have all the people doing something (reading messages, downloading files, uploading, etc.) without any real noticeable delays. These kinds of things just aren't CPU intensive, and even less disk intensive. Dave
peterk@cbmger.UUCP (Peter Kittel GERMANY) (04/02/91)
In article <8806@gollum.twg.com> david@twg.com (David S. Herron) writes: > (Aside, there's > a developer tool I've heard about which adds memory > protection as an aid for finding things like wild/NULL > pointers). No, not quite. It's only a tool to INDICATE memory violations, it doesn't prevent them. But it's for developers, and thus they can look through their own code and eliminate those parts that had run wild, or better correct them. -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
kdarling@hobbes.ncsu.edu (Kevin Darling) (04/03/91)
In <q!8fk1c@rpi.edu> kudla@rpi.edu (Robert J. Kudla) writes: > Okay - but I claim that a personal computer OS doesn't need > file/process ownership, security, or any of the junk Unix, VMS, etc > have to allow multiple users. True, an OS doesn't _need_ it, but then a personal computer doesn't "need" multitasking either ;-). Obviously tho, such features can be very handy. * For example, when a friend of mine loans out his multiuser system to a club for a demo, he doesn't worry about his source code and other private information still being on disk; the login and security protects him. * Other friends use the security to let their children play computer games, but not to have access to most directories... preventing accidental erasure or access of important files. Like x-rated GIFs, for one thing <grin>. * Plus the multiuser part allows use in small business; gives remote user login as standard; makes running a BBS in the background a piece of cake; lets you decode a GIF _while_ downloading instead of after it's all down. > Once you put one in an educational or corporate environment you need > multiuser capability, but I daresay in such an environment it's no > longer a personal computer..... All my above examples describe any home computer running OS-9. So... does that make say, a Tandy CoCo, "no longer a personal computer"? Maybe. But the owners still think it is :-). I suspect that people often claim something is "unnecessary" because their own system is missing it, eh? But yes, if you define "a personal computer" as a machine that no one else EVER uses or has physical/electronic access to AT ALL, then I agree with you. I wonder how common that is, tho? best - kevin <kdarling@catt.ncsu.edu>
kdarling@hobbes.ncsu.edu (Kevin Darling) (04/03/91)
u3364521@ucsvc.ucs.unimelb.edu.au (Lou Cavallo) writes: >PS: I have a pet theory that multi-user and distributed computing features > could play a key role in multi-media groupware e.g. a creative arts or > video production group setup where artists and technicians could work > together "live" on Amiga multimedia production. Bingo! The CD-I studios I've seen were highly networked, multiuser, multihardware setups where artists and A/V-data-gatherers and programmers and technicians all worked together, with gigabyte drives serving to emulate a CDROM disc during creation of a title. best - kevin <kdarling@catt.ncsu.edu>
kdarling@hobbes.ncsu.edu (Kevin Darling) (04/03/91)
In <1991Apr2.030653.10978@NCoast.ORG> davewt@NCoast.ORG (David Wright) writes: > Until there is one that does these things, *AND* does everything else > the Amiga OS does just as well as the Amiga (shared libraries, unlimited > RAM, dynamic device drivers, etc.), you can't compare it. > [...] > In fact, OS/9 had almost as much as the Amiga did, for it's day, > and it DID have real multi-user abilities. As did MP/M. ... and as did CROMIX (1980-ish), Oasys (1982-ish), and several others. Come to think of it, it very well could be that the Amiga OS was the first multitasking personal computer OS _without_ multiuser features. However, that's not what I'm here to say. I just wanted to note that rumors of OS-9's demise ("..OS/9 had..") are greatly exaggerated ;-). There are close to 100,000 owners of OS9/6809 on the CoCo3, and of course we'll be seeing lots more OS-9/68000 users fairly soon now, as the new 68K machines are about to hit the streets. Not to mention that it's also the OS used in the coming onslaught of CD-I machines. Shared libraries? Every OSK (slang for "OS-9/68K") system comes with Math and CIO (does just what it sounds like) trap libraries. Loadable drivers and file managers have been around since OS-9 was written (1980). As for all the tired arguments I've seen here about resource-tracking and parameter-checking "slowing" down a machine, well.... A) OSK's kernel is tiny, fast, totally asm code, and B) THERE IS NOTHING SLOWER THAN STOPPED, which is what you often get with slack OS's letting bogus params through ;-). OS-9 still has enormous advantages to the serious user and programmer: You can move OS-9 programs to a computer with MMU protection, and they'll work just fine. ALL OS-9 programs are "pure" code, in Amiga parlance. And you also have a heckuva lot more choice of machines to buy. Anyway, I'm not trying to flame. I believe you probably knew some of this, and that your intentions were good in mentioning OS-9. But please, write that "OS9 has" and "OS9 does" (present tense :-). Thanks! Give us a few more months of OS9 GUI development, and _then_ we'll be back to torch AmigaOS <g>. regards - kevin <kdarling@catt.ncsu.edu>
navas@cory.Berkeley.EDU (David C. Navas) (04/03/91)
In article <1003@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >And talking about such similar operating systems, another parallel >comes to my mind: Geoworks Ensemble for PCs. You know, this stems >from the people who made GEOS for the C64 which already in those >times provided tremendous performance when considering the >underlying platform. Now the same has obviously happened to the Well, I helped write that package and no longer work for them, so perhaps I can give you a good but impartial opinion. Fat chance, but... Ensemble is faster because it is smaller. IE -- the thing doesn't page to disk every half a second. Also because it doesn't have to cozy up to DOS for *any* of it's internal programs, except for disk access... Ensemble is smaller because it has an extremely well thought out kernel that has everything from DOS interfaces (which the Amiga has) to general fast WYSIWYG- capable string "gadgets" (which the Amiga doesn't have). As an example, open up those HELP boxes -- the multiple style'ed text inside a scrolling region is *one* text object. The system takes care of the scrolling, text display, etc. It is sad, but true, that the interface is better defined than the corresponding Amiga interface. It's loads richer too... :( >similar principles as the Amiga OS, mainly the object-oriented >data structures and system calls. GEOS is written in an object-oriented assembly language. We're not just talking about a quais-object-oriented system like the Amiga. >As GEOS is of nearly the same >age as Amiga OS, you cannot say they took ideas from Amiga OS, >but they followed the same ideas as our guys. There are some very good ideas in GEOS that can't be found in the Amiga. Device independence comes to mind. There are others I'm probably not allowed to discuss. >This all leads me to the conclusion that examples of this kind >demonstrate that Amiga OS is well up with the current state of >the art in OS design. Ok, there also exist newer developments, The Amiga's OS has serious defficiencies, and serious advantages. However, there is far too much redundant, multiple-interface stuff which leads not only to a horrible programmer-interface, but to a huge kernel as well. Fortunately most of it's in ROM... As an example, think of how you'd develop a CLI utility, and then develop the same utility for workbench. Question, why are they different? Because they reach different audiences or because dealing with workbench and tooltypes is so vastly different than dealing with CLI line arguments? Even 2.0, which is at least advancing the idea of TAGS seems to have a bunch of parsing code duplicated in commodities and DOS, etc. etc. Why do we have THREE separate ways to create gadgets -- Gadget/boopsi/GadTools? Why can't we have ONE call that creates/destroys ANY system structure? IE: rastport = CreateSysStruct(CSS_RASTER); I know why Exec *didn't* have it's structures protected by semaphores -- why doesn't it now? Stick the Semaphores in the Library structure for crying out loud if you have to. Of course, some structures you just *don't* want to use Semaphores for... :). And the beat goes on. >but I'm confident that the open >design will leave enough room for further development and >keeping track with new ideas. Let us all sincerely hope so :) 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
navas@cory.Berkeley.EDU (David C. Navas) (04/03/91)
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
peter@sugar.hackercorp.com (Peter da Silva) (04/03/91)
In article <1762.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: > Quoted from <1991Mar29.184119.5083@sugar.hackercorp.com> by peter@sugar.hackercorp.com (Peter da Silva): > > You can reboot the IBM-PC clone in my bedroom all you want, and unless > > you bring your own O/S in with you you will not be able to defeat the > Hm. I take a DOS disk out with me when visiting people whose machines > need fiddling with at work. And a disk editor, and a binary file > editor, and a couple of other things. I don't expect people to be carrying bootable DOS disks when they go visiting friends. I'm not one of the folks whose machines "need fiddling at work". Do you actually go visiting people at home with an MS-DOS boot disk? If so, I would suggest getting a life. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
ptoper@obelix (Andy Nagy) (04/03/91)
In article <12393@pasteur.Berkeley.EDU>, navas@cory.Berkeley.EDU (David C. Navas) writes: [stuff deleted] > >> - Resource tracking > 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. [stuff deleted] > 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. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Please keep us posted ... > David Navas navas@cory.berkeley.edu ------------------------------------------------------------------------------- Andy Nagy (ptoper@asterix.gaul.csd.uwo.ca) The University of Western Ontario, London, Canada "Dee do do do, dee da da da, thats all I want to say to you" -- The Police
dac@prolix.pub.uu.oz.au (Andrew Clayton) (04/03/91)
In article <1991Apr2.191525.26491@sugar.hackercorp.com>, Peter da Silva writes: > In article <1762.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: > > Quoted from <1991Mar29.184119.5083@sugar.hackercorp.com> by peter@sugar.hackercorp.com (Peter da Silva): > > > You can reboot the IBM-PC clone in my bedroom all you want, and unless > > > you bring your own O/S in with you you will not be able to defeat the > > > Hm. I take a DOS disk out with me when visiting people whose machines > > need fiddling with at work. And a disk editor, and a binary file > > editor, and a couple of other things. > > I don't expect people to be carrying bootable DOS disks when they go visiting > friends. I'm not one of the folks whose machines "need fiddling at work". Do > you actually go visiting people at home with an MS-DOS boot disk? If so, I > would suggest getting a life. > -- > Peter da Silva. `-_-' > <peter@sugar.hackercorp.com>. This has my vote for 'funniest posting in comp.sys.amiga.advocacy' for the week. Dac --
chip@tct.com (Chip Salzenberg) (04/04/91)
According to kdarling@hobbes.ncsu.edu (Kevin Darling): >* For example, when a friend of mine loans out his multiuser system to a > club for a demo, he doesn't worry about his source code and other private > information still being on disk; the login and security protects him. Bad example. Give me a boot disk, and I'll read anything on your hard disk, including root-only files. >* Other friends use the security to let their children play computer games, > but not to have access to most directories... >* Plus the multiuser part allows use in small business; gives remote user > login as standard; makes running a BBS in the background a piece of cake... Good examples. -- Chip Salzenberg <chip@tct.com>, <uunet!pdn!tct!chip> Brand X Industries Custodial, Refurbishing and Containment Service When You Never, Ever Want To See It Again [tm]
cg@ami-cg.UUCP (Chris Gray) (04/04/91)
In article <12390@pasteur.Berkeley.EDU> navas@cory.Berkeley.EDU (David C. Navas) writes: [talking about Geoworks Ensemble] >Why can't we have ONE call that creates/destroys ANY system structure? > > IE: rastport = CreateSysStruct(CSS_RASTER); Arrrghhh! Please, no! Strong type checking is added to programming languages for a reason - to help reduce bugs. Overly generic calls like the above require changes to the LANGUAGE to provide any protection. I'm not too keen on the TAGS stuff either - I'm still puzzling out what I can do to the Draco language to try to support them reasonably. I'm sure the same problems come up with Pascal, Modula-2, etc. -- Chris Gray alberta!ami-cg!cg or cg%ami-cg@scapa.cs.UAlberta.CA
davidm@uunet.UU.NET (David S. Masterson) (04/04/91)
>>>>> On 27 Mar 91 21:00:47 GMT, barrett@jhunix.HCF.JHU.EDU (Dan Barrett) said:
Dan> I would still argue that, for an OS to be "state of the art" (as was
Dan> claimed by the original poster), it has to have some concept of file
Dan> ownership; a multiple user model in which a user "owns" a file.
No...
That's the last thing you want to do to a state of the art, *PERSONAL*
computer operating system. This is too much like the heavy model of operating
systems like UNIX and VMS (I still say that the biggest mistake made with UNIX
was in not developing a light weight, single user version). If you need file
ownership because you are going to run many people on your system, relagate
the "multiply" owned files to a file server and set up a daemon process on
your Amiga to negotiate with the file server (for instance, each request for a
file includes a password that the daemon asks for on startup).
Don't have the money for a file server (which is difficult to understand in
that an A500 could play this file server with an adaption to NET:)? Then
simply take your "critical" files with you on floppy or tape.
--
====================================================================
David Masterson Consilium, Inc.
(415) 691-6311 640 Clyde Ct.
uunet!cimshop!davidm Mtn. View, CA 94043
====================================================================
"If someone thinks they know what I said, then I didn't say it!"peter@sugar.hackercorp.com (Peter da Silva) (04/04/91)
In article <1991Apr2.172222.27446@ncsu.edu> kdarling@hobbes.ncsu.edu (Kevin Darling) writes: > ... and as did CROMIX (1980-ish), Oasys (1982-ish), and several others. > Come to think of it, it very well could be that the Amiga OS was the > first multitasking personal computer OS _without_ multiuser features. I don't class the Cromemco Z-2 as a personal computer. Yes, it's pitifully weak by today's standards, but it was a $10K machine. To me, a personal computer that costs more than a small car is an oxymoron. Plus, it didn't really have multi-user protection if you had access to a compiler. You need more than bank-switched Z80s for that. The same is true, by the way, of OS/9 on the Color Computer. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
u3364521@ucsvc.ucs.unimelb.edu.au (Lou Cavallo) (04/04/91)
G'day, In comp.sys.amiga.advocacy Andrew Clayton writes: > In comp.sys.amiga.advocacy Peter da Silva writes: > [...posting about the carrying about of MS-DOS boot disks...] > This has my vote for 'funniest posting in comp.sys.amiga.advocacy' for > the week. I *have* to vote for Peter's other posting regarding "Amiga will bump Mac" where he (humouristically) pronounces he is a tug boat (i.e. if the other guy is a ...). {You made my night Peter!} > Dac Back to the foray! yours truly, Lou Cavallo.
nwickham@triton.unm.edu (Neal C. Wickham) (04/05/91)
In article <1991Apr4.220359.1790@ucsvc.ucs.unimelb.edu.au> u3364521@ucsvc.ucs.unimelb.edu.au (Lou Cavallo) writes: >G'day, > > >I *have* to vote for Peter's other posting regarding "Amiga will bump Mac" >where he (humouristically) pronounces he is a tug boat (i.e. if the other >guy is a ...). {You made my night Peter!} > >> Dac > >Back to the foray! > >yours truly, >Lou Cavallo. eeeesh... this sounds like 'true' love ....Peter! NCW
navas@cory.Berkeley.EDU (David C. Navas) (04/05/91)
In article <cg.8036@ami-cg.UUCP> cg@ami-cg.UUCP (Chris Gray) writes: >In article <12390@pasteur.Berkeley.EDU> navas@cory.Berkeley.EDU >(David C. Navas) writes: >> >> IE: rastport = CreateSysStruct(CSS_RASTER); > >Arrrghhh! Please, no! Strong type checking is added to programming languages >for a reason - to help reduce bugs. Overly generic calls like the above Like, malloc(), calloc(), AllocMem(), etc. etc.??? Dude, what's your point here -- allocation of most memory structures RIGHT NOW don't return system types correctly. Quick, allocate a Gadget structure -- see what I mean? The second advantage is that because the structures are allocated by the system INSTEAD of by the programmer, system structure sizes can *change* -- why don't you ask Peter Cherna why that might be a nice idea, even if it is six years too late... :( >require changes to the LANGUAGE to provide any protection. I'm not too keen >on the TAGS stuff either - I'm still puzzling out what I can do to the Draco >language to try to support them reasonably. I'm sure the same problems come >up with Pascal, Modula-2, etc. Okay, so we dump TAGS, a useful, extensible, system-independent manner for dealing with "objects" [hint, hint] so that we can support Pascal??? Put me down as fundamentally against that idea :) Programming languages are going to fundamentally change in five to ten years, but that's just my opinion. I bought my Amiga so that this type of compatibility argument wouldn't come up. Sigh, I suppose it shows the signs of a maturing market. Maybe I'll buy a NeXT :) [I'm kidding...] >Chris Gray alberta!ami-cg!cg or cg%ami-cg@scapa.cs.UAlberta.CA 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
peter@sugar.hackercorp.com (Peter da Silva) (04/05/91)
In article <1991Apr4.220359.1790@ucsvc.ucs.unimelb.edu.au> u3364521@ucsvc.ucs.unimelb.edu.au (Lou Cavallo) writes: > I *have* to vote for Peter's other posting regarding "Amiga will bump Mac" > where he (humouristically) pronounces he is a tug boat (i.e. if the other > guy is a ...). {You made my night Peter!} What do you mean humoristically? I *am* a tugboat. Had an accident with an old Warner Brothers cartoon videotape, the pyramid-configuration aethernet, and a 5 Megachant attuned quartz crystal. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
dac@prolix.pub.uu.oz.au (Andrew Clayton) (04/05/91)
In article <27FA06D4.4D68@tct.com>, Chip Salzenberg writes: > According to kdarling@hobbes.ncsu.edu (Kevin Darling): > >* For example, when a friend of mine loans out his multiuser system to a > > club for a demo, he doesn't worry about his source code and other private > > information still being on disk; the login and security protects him. > > Bad example. Give me a boot disk, and I'll read anything on your hard > disk, including root-only files. Even the ones packed with PowerPacker, or TurboImploder, or ARC with the password option? [And I mean 'get meaningful info from them', ok!] "I thort I thaw an absolute." Dac --
u3364521@ucsvc.ucs.unimelb.edu.au (Lou Cavallo) (04/05/91)
G'day, In comp.sys.amiga.advocacy Neal C. Wickham (nwickham@triton.unm.edu ) writes: > In comp.sys.amiga.advocacy I write: >>G'day, >>[..] >>guy is a ...). {You made my night Peter!} >>[...] > eeeesh... this sounds like 'true' love ....Peter! Err, harumph, harumph he said! It's a nasty wumour and I'm not that thort of boy... > NCW yours deny-ingly, Lou Cavallo.
jbickers@templar.actrix.gen.nz (John Bickers) (04/06/91)
Quoted from <1991Apr2.191525.26491@sugar.hackercorp.com> by peter@sugar.hackercorp.com (Peter da Silva): > In article <1762.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: > > Quoted from <1991Mar29.184119.5083@sugar.hackercorp.com> by peter@sugar.hackercorp.com (Peter da Silva): > > > You can reboot the IBM-PC clone in my bedroom all you want, and unless > > > you bring your own O/S in with you you will not be able to defeat the > > Hm. I take a DOS disk out with me when visiting people whose machines > > need fiddling with at work. And a disk editor, and a binary file > I don't expect people to be carrying bootable DOS disks when they go visiting > friends. I'm not one of the folks whose machines "need fiddling at work". Do Note that if I (or the average person who was interested in lifting data off it) visited the PClone in your bedroom, it would not be as a friend. My point (which is still valid), was that it is ridiculous to rely on people NOT having boot disks on their person. That is a luser's fantasy, as far as security issues go. Kind of like trusting MS-DOS to be 100% compatible up the line, or that using the R,S and H bits on MS-DOS files makes them secure. When you invite someone to trash your machine, you'll have to take better measures than this to stop them. I believe this was the original issue, right? PC security? However, I don't carry these disks to mess with people's security. The disks constitute my equivalent of a serviceman's toolbox, when I'm asked to go and visit other parts of the bank, or customers. Last thing I need to have happen when I go to modify a file is to be stuck with Word or edlin. Same thing applies to the people who install our software (except that they like edlin :), who even carry screwdrivers. > you actually go visiting people at home with an MS-DOS boot disk? If so, I > would suggest getting a life. I don't. I have nothing to do with PClones on my own time, other than that lots of bulletin boards seem to run on them. How about keeping the "life" drivel to yourself, though. I have one, it is this, and it's much nicer when Real World folks practise a bit of self- control when they feel the urge to give out amateur (though free, I guess) psychoanalysis... > Peter da Silva. `-_-' -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Patterns multiplying, re-direct our view" - Devo. ***
kdarling@hobbes.ncsu.edu (Kevin Darling) (04/06/91)
chip@tct.com (Chip Salzenberg) writes: >According to kdarling@hobbes.ncsu.edu (Kevin Darling): >>* For example, when a friend of mine loans out his multiuser system to a >> club for a demo, he doesn't worry about his source code and other private >> information still being on disk; the login and security protects him. > >Bad example. Give me a boot disk, and I'll read anything on your hard >disk, including root-only files. Yes, but in the case I was thinking about when I wrote that, his machine always boots straight from hard disk. This is more than sufficient to prevent browsers at a club demo from stumbling upon private info. Now obviously a determined and evil-minded person could get around security on almost any system, but then, you usually try not to let someone like that get physically near your computer <g>. If he gets that close, he could simply steal the hard disk and read it at leisure on his system. cheers - kevin <kdarling@catt.ncsu.edu>
peter@sugar.hackercorp.com (Peter da Silva) (04/07/91)
In article <1935.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: > Note that if I (or the average person who was interested in lifting > data off it) visited the PClone in your bedroom, it would not be as a > friend. In that case, they could walk off with the hard disk and examine it at their leisure. My point is that you need more than access to the power switch to break a properly protected system. You need tools. > > you actually go visiting people at home with an MS-DOS boot disk? If so, I > > would suggest getting a life. > I don't. I have nothing to do with PClones on my own time, other > than that lots of bulletin boards seem to run on them. My point. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
davewt@NCoast.ORG (David Wright) (04/08/91)
In article <1991Apr2.172222.27446@ncsu.edu> kdarling@hobbes.ncsu.edu (Kevin Darling) writes: >Anyway, I'm not trying to flame. I believe you probably knew some of this, >and that your intentions were good in mentioning OS-9. But please, write >that "OS9 has" and "OS9 does" (present tense :-). Thanks! Give us a few more >months of OS9 GUI development, and _then_ we'll be back to torch AmigaOS <g>. I wasn't meaning that OS/9 was dead when I used the term "had". But rather that I was refering to a time in the past (such is the wonderfully ambiguous english language). So saying "OS/9 *had* these features back in the early 80's" doesn't mean it doesn't today, just that it HAD them back then. Dave
ckp@grebyn.com (Checkpoint Technologies) (04/08/91)
In article <1991Apr7.031830.25773@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <1935.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: >> Note that if I (or the average person who was interested in lifting >> data off it) visited the PClone in your bedroom, it would not be as a >> friend. > >In that case, they could walk off with the hard disk and examine it at their >leisure. My point is that you need more than access to the power switch to >break a properly protected system. You need tools. Well, my point was originally that you only need access to the power switch to deny access to a person's files and programs, and that this is itself a serious disruption. -- First comes the logo: C H E C K P O I N T T E C H N O L O G I E S / / ckp@grebyn.com \\ / / Then, the disclaimer: All expressed opinions are, indeed, opinions. \ / o Now for the witty part: I'm pink, therefore, I'm spam! \/
davidbro@microsoft.UUCP (Dave BROWN) (04/13/91)
Before I get into this fray, let me give you some background. I AM an Amiga owner. I have a 3000UX (which I just took Unix OFF of, since 5 megs of memory leads to MUCH swapping. AmigaDOS is faster). I did wait a while before I got one -- I wanted full 32 bit support, and a better looking GUI. (It never made sense to me that the Amiga was supposed to be this hot graphics machine, and it's windowing system looked as ugly as it did. I'm glad they did 2.0.) I am friends with the person that got one of the first A1000's in Washington State (back when they just called it an Amiga -- the A1000 designation was unknown), and we played with it intensely, even though it was running AmigaDOS 1.0. So, in short, I love the Amiga. I am in the process of becoming a developer for the Amiga. Don't let the company I work for bias you against me -- I'm on your side. Now that the rationalizations are done... :-) In article <1991Apr2.030653.10978@NCoast.ORG> davewt@NCoast.ORG (David Wright) writes: > Name one single-user-at-a-time OS that does this (not some kind of LAN >OS like Novell, but a real, optimized for one user at a time but still >multitaksing OS that runs on PC class machines. I hate to say it, but the High Performance File System under OS/2 does this. Mind you, it implements this for upward compatibility with LANs, but the support for Access Control Lists and file ownership is there. > Until there is one that does these things, *AND* does everything else >the Amiga OS does just as well as the Amiga (shared libraries, unlimited >RAM, dynamic device drivers, etc.), you can't compare it. That's like me saying >that "if a car doesn't hover 500 feet off the ground, cruise at mach 2 >at 4 kilometers, and come with sidewinder missiles it isn't state of the >art". For something to be better than something it has to EXIST, not just be >what someone comprehends COULD exist. Also -- OS/2 supports Dynamically Linked Libraries... which function the same as Amiga's shared libraries. Unix supports something KIND of like this, with the "sticky bit." VMS supports it with "shared images." But -- VMS runs only on a Vax, Unix suffers from kernel bloat, and OS/2 RUNS in 2 megabytes, but not well. You really need 5+ before it performs well. > In fact, OS/9 had almost as much as the Amiga did, for it's day, >and it DID have real multi-user abilities. As did MP/M. Does that make it >state of the art? Is Unix state of the art? Hardly. I have yet to see ANY >Unix system that makes as much use of dynamic shared libraries as the Amiga, >or provides dynamic shared libraries as SOP for things such as shells, >so that even common things like regular expression matching could be done in >one place instead of in each program that wan't to do it. > Don't mistake something that is more "powerfull" with something that is >"state of the art". The two aren't the same. Remember though, that "state-of-the-art" generally does NOT make it to the consumer level until after it is no longer SotA. SotA tends to be used more as a marketing term than anything else. Besides -- If you were really concerned about having SotA machines, you'd be buying new computers about every 6 months. Not many people can afford to do that... I certainly can't. > > Dave dave, also -- Dave Brown ...!uunet!microsoft!davidbro ...ni ssendriew eht tel eW "the night doesn't like it... looks just like your face in the moon to me"