shadow@pawl.rpi.edu (Deven T. Corzine) (08/02/89)
*sigh* Here I go again. On 1 Aug 89 12:54:54 GMT, lofaso@titan.tsd.arlut.utexas.edu (Bernie Lofaso) said: In article <195@VAX1.CC.UAKRON.EDU>, benton@VAX1.CC.UAKRON.EDU (Kevin Benton) writes: Kevin> I'll agree with you that AmigaDOS is half way decent for the Kevin> user interface, although from a programmer's standpoint, the Kevin> operating system itself is about the buggiest thing I have ever Kevin> seen. When my Amiga crashes CLI's for no apparent reason, I Kevin> would tend to think there must be something better out there, Kevin> especially since Minix comes with SOURCE CODE!!!! First, I think AmigaDOS's UI sucks. But that depends to a degree on what you're used to. I'm used to Unix, and I find AmigaDOS annoying and clumsy, and often frustratingly limiting. From a programmer's standpoint, AmigaDOS itself isn't notably buggy. Many of the PD/Shareware/Freeware utilities and programs you need to make the damn UI halfway decent ARE, but that's another issue. What IS poor is the BCPL shit showing up in the programming interface. Also arbitrary limitation of functionality. I can understand time pressure forcing C-A to give in and use outside help and BCPL to implement the file system. HOWEVER, the "official" languages for the Amiga were (and are) primarily Assembly and C. Both share stack, pointer and string conventions. BCPL does not. To use BPTRs and BSTRs in the programming *interface* is simply unforgivable. All the dos.library functions should have internally converted the passed arguments to BCPL crap. This way, everyone could have been saved *much* irritation, bugginess and hassle, and the BCPL code could be later cleanly replaced with C or Assembly code. Furthermore, using a nonstandard jump table for dos.library was equally stupid. Being unable to SetFunction() calls in dos.library is simply a ridiculous and unnecessary restriction. Doubly unforgivable is crippling the *Exec* OpenLibrary() and OpenDevice() functions. How are they crippled, you ask? An Exec Task can not safely run them. Why not? If the library or device isn't found, *AmigaDOS* butts in and tries to load them out of LIBS: or DEVS:. Now, this isn't unreasonable, until you consider that it will *fail* unless the Task is also an AmigaDOS Process. You'd think the damn thing could just create temporary data structures it needs, but NOOOO. Some things, like needing to be a Process to call dos.library's Delay() function are annoying and silly, but understandable and acceptable. [besides, it belongs in timer.device as Sleep()] Then there's the stupid 20 CLI limit... CATS-folx: Sorry to be so caustic, but things like this just strike me as SO inconceivably *stupid* that I have real difficulty understanding why anyone would do it. *sigh* Well, on with the show. Bernie> I have a very difficult time with the part about "the buggiest Bernie> thing I have ever seen". This is simply hog wash. AmigaDOS Bernie> is no more buggy than most other operating systems. I'll buy that. Bernie> My guess is that Mr. Benton may be running much PD software Bernie> which, as one might expect, does not live up to more rigorous Bernie> programming standards that some of us might expect. There are Bernie> several issues, which Mr. Benson's message alludes to, as have Bernie> others posted on the net, which nobody seems to have Bernie> addressed. Ah, but the PD software is virtually _necessary_ to maintain a reasonable environment. (the stock configuration is virtually unusable, in my opinion.) [particularly the CLI] Bernie> How many people who have OS source (to Minix or anything else) Bernie> would actually do anything with it? Arguably few would attempt to *change* things in the operating system, but many programmers would be interested in seeing how things work, and it allows programmers to analyze how they need to write a program to have it mesh properly with the OS. [I've found the Exec disassembly to be of great usefulness...] (program to generate it is on a Fish disk.) Bernie> While there are plenty of good programmers who might could do Bernie> something with it, would they have the time or care? The Bernie> number of those who would are statistically insignificant Bernie> compared to the number of those who wouldn't know what to do Bernie> with the code. Typically systems of this magnitude are either Bernie> incomprehesible or trivial. Minix is designed to be reasonably comprehensible, though it is quite large, of course. As for whether it would be used... even if the source *isn't* used [which I doubt] it hardly hurts to have it available. I don't see Commodore distributing commented source for all THEIR code. [not that I'm saying they SHOULD, but it would be nice.] Bernie> Why do you want Minix (Unix, etc.) on your Amiga? I suspect Bernie> many people voice a desire because it's extremely popular and Bernie> they are used to it. Excellent reasons, but are you also used Bernie> to the system administration headaches that can come along Bernie> with it? I don't see that Minix/Unix on an Amiga need be any more of a headache for system maintenance and administration than AmigaDOS itself is. Yes, Unix is multiuser, but that doesn't need to complicate things much. Managing an AmigaDOS system well can be a lot of work as well. [unless you LIKE using only the stock configuration...] Bernie> (Since only a C= Unix would ever become popular, when you add Bernie> devices to Minix, etc. guess who gets to write the device Bernie> drivers. :-) I don't see how that necessarily follows. True, C-A Unix [Amix] gives instant name-recognition, and some expectation of support and service. However, I consider it to be a stretch to claim ONLY a C-A environment could thrive. Consider ARexx. Bernie> There are also other disadvantages to Unix-like systems. I've Bernie> not seen one yet that had decent real-time response. And how often do you run across Unix systems without MMUs? Virtual memory can slow a system way down. (So much easier on the Amiga, it just crashes.) Real-time Unix systems DO exist. Most are not. The Amiga Exec OS achieves excellent response by not supporting VM, message-passing by reference, strict task prioritizing and other such little tricks. They can work nicely and attain impressive speed and response time, but there ARE clear drawbacks. Bernie> Well, some are decent, but the response of AmigaDos is in my Bernie> opinion superior. The responsiveness of Exec is excellent. AmigaDOS isn't always so hot. Consider directory scans, a VERY common operation, which is slow as all hell. [and don't bother to mention FFS -- it's backpatching to make the file system what it should've been to begin with.] Bernie> There is also a more elegance of design to the AmigaDos Bernie> system. AmigaDOS? More elegant than Unix? Don't make me laugh. Bernie> (That might be good for a few flames.) Big surprise. Bernie> I wouldn't want to do without the ASSIGN command and logical Bernie> volumes in general. I could go on. Logical volumes are among the few _good_ things about AmigaDOS. Take a gander at dos.library sometime, however. Elegant? Ha. Kevin> I don't know if you have ever used Unix before, but there's a Kevin> lot more for Unix than just Multiple Users... (not to mention Kevin> 2000 times more pd software, interprocess communication, etc.) Bernie> Now you've hit the nail on the head... it's not that you're in Bernie> love with Unix's process communications (which incidently Bernie> aren't as good as AmigaDos except on newer systems like Bernie> SunOS), Oh? So you're saying the brilliant PIPE: AmigaDOS device is better (and more elegant!) than Unix's pipe() system call? How about fork() and exec()? [execve() for purists.] Or are you thinking of Exec's message-passing? It has advantages and disadvantages, but is decent overall, and none to AmigaDOS's credit. Maybe you're thinking of the AmigaDOS packets for asynchronous I/O? [granted, elegant in concept, but ugly in implementation.] Bernie> but it's the utilities! Damn right. Unix tends to be a far more constructive environment. I'd much rather spend my time wrestling with a problem I'm trying to solve than wrestling with the poor tools I have available to use. Bernie> Life is not worth living if I can come in early in the morning Bernie> and grep a few files to start my day. With make, diff, awk, Bernie> etc. etc. etc. life is so much easier. Yes. Bernie> But, since most of these have been ported to the Amiga, Bernie> including some impressive user shells to replace the CLI Bernie> (don't like CLI... only dirty three letter word I know), Bernie> what's the advantage? Well, now. Here you are bringing up the same PD (/Free/Shareware) software you were condemning before as the bugginess culprit. You can't have it both ways. These ports (which are usually not as good as the real thing) are NOT part of AmigaDOS. Many excellent utilities ARE part of Unix. (generally speaking.) The advantage? They usually WORK, as documented, without crashing the entire machine if somethign goes wrong. Bernie> I think that if people consider arguments like these, there Bernie> would be much less desire to run Unix on the Amiga. If people believe faulty arguments, then maybe so. I, for one, don't agree. Bernie> (Did I also mention disk and memory requirements for Unix. Bernie> Hardware vendors love it I'm sure.) For standard System V Unix, the system requirements are a bit much. Same for BSD. Not so for Unix Version 7. It's small and elegant. All current versions of Unix are derived from it. It has most of the major concepts that make Unix so successful. Minix is a complete reimplementation (a much cleaner one) of Unix V7, distributed with source code. [As Unix itself was, long ago.] {My Amigix project will also use Unix V7 as a base. But that's a subject for other articles.} Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2214 12th Street, Troy, NY 12180 Phone: (518) 271-0750 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.
papa@pollux.usc.edu (Marco Papa) (08/02/89)
In article <SHADOW.89Aug2040433@pawl.rpi.edu> shadow@pawl.rpi.edu (Deven T. Corzine) writes: > >{My Amigix project will also use Unix V7 as a base. But that's a >subject for other articles.} The "Amigix project" has won the comp.sys.amiga.tech "vaporware" prize for 1989. Congratulations! :^) And, by the way, try to use less derogatory language, thank you. I guess it's time to add to my KILL file :-) -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma, Diga and Caligari!" -- Rick Unland -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
shadow@pawl.rpi.edu (Deven T. Corzine) (08/03/89)
On 2 Aug 89 16:45:50 GMT, papa@pollux.usc.edu (Marco Papa) said: In article <SHADOW.89Aug2040433@pawl.rpi.edu> shadow@pawl.rpi.edu (Deven T. Corzine) writes: Deven> {My Amigix project will also use Unix V7 as a base. But that's Deven> a subject for other articles.} Marco> The "Amigix project" has won the comp.sys.amiga.tech Marco> "vaporware" prize for 1989. Congratulations! :^) I won't argue that. It falls under the category of vaporware until I get something done on it. My life's been a little complicated recently, which makes it difficult to try to develop code. But as far as vaporware goes, it's pretty good, eh? :-) Seriously, I *do* expect to get *something* useful done and working, when I can. There may yet be a delay of a month or three before I can get anything significant (in the way of code instead of just design work) done. [hopefully, I'll have my life more in order by then.] Marco> And, by the way, try to use less derogatory language, thank Marco> you. I normally do try, but I was tired of the whole situation (not to mention just plain tired)... it's the first (and hopefully last) article I've crossposted to alt.flame from comp.sys.amiga.tech... [first time I've bothered to crosspost to alt.flame at all, for that matter.] These things happen when I post at times like that... *sigh* Marco> I guess it's time to add to my KILL file :-) Now, now. Don't be so touchy. You find most of my articles to be useless and unhelpful, and full of misinformation? Yes, I have on a few occasions lashed out at perceived stupidity, but I usually stay with constructive articles, for the most part. [overreactions... *sigh*] Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2214 12th Street, Troy, NY 12180 Phone: (518) 271-0750 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.
vkr@osupyr.mps.ohio-state.edu (Vidhyanath K. Rao) (08/03/89)
In article <SHADOW.89Aug2040433@pawl.rpi.edu> shadow@pawl.rpi.edu (Deven T. Corzine) writes: >On 1 Aug 89 12:54:54 GMT, >lofaso@titan.tsd.arlut.utexas.edu (Bernie Lofaso) said: >Bernie> There is also a more elegance of design to the AmigaDos system. Deven>AmigaDOS? More elegant than Unix? Don't make me laugh. I would say that AmigaDOS looks like a project from a B student: A good concept, but implementation shows lack of imagination and more importantly, inability to adapt to a different evoirment: Relying on BCPL thruout is only one instance of it. Another example [why I would give the implementation a B rather than an A] is packets implemented to support only co-routines, hijacking of the Message.Node.Name field etc. But I side with Bernie: Conceptually, AmigaDOS is more evolved than Unix. But then, it did come latter. -- It is the man, not the method, that Nath solves the problem. vkr@osupyr.mps.ohio-state.edu -Poincare. (614)-366-9341
papa@pollux.usc.edu (Marco Papa) (08/03/89)
In article <SHADOW.89Aug2141201@pawl.rpi.edu| shadow@pawl.rpi.edu (Deven T. Corzine) writes: |On 2 Aug 89 16:45:50 GMT, papa@pollux.usc.edu (Marco Papa) said: |Marco| And, by the way, try to use less derogatory language, thank you. |I normally do try, but I was tired of the whole situation (not to |mention just plain tired)... it's the first (and hopefully last) |article I've crossposted to alt.flame from comp.sys.amiga.tech... |[first time I've bothered to crosspost to alt.flame at all, for that |matter.] These things happen when I post at times like that... |*sigh* As the recommendations from usenet go: "don't post when you're tired, intoxicated, stoned, angry, etc.." :^) |Marco| I guess it's time to add to my KILL file :-) |Now, now. Don't be so touchy. You find most of my articles to be |useless and unhelpful, and full of misinformation? Yes, I have on a |few occasions lashed out at perceived stupidity, but I usually stay |with constructive articles, for the most part. |[overreactions... *sigh*] Using derogatory language lowers the quality and content of your postings. Keep it technical and you can't lose. Take it easy. Losen up. I am trying to do that myself. Life is hard enough. -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma, Diga and Caligari!" -- Rick Unland -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
shadow@pawl.rpi.edu (Deven T. Corzine) (08/03/89)
On 2 Aug 89 18:26:15 GMT, vkr@osupyr.mps.ohio-state.edu (Vidhyanath K. Rao) said: In article <SHADOW.89Aug2040433@pawl.rpi.edu> shadow@pawl.rpi.edu (Deven T. Corzine) writes: On 1 Aug 89 12:54:54 GMT, lofaso@titan.tsd.arlut.utexas.edu (Bernie Lofaso) said: Bernie> There is also a more elegance of design to the AmigaDos system. Deven> AmigaDOS? More elegant than Unix? Don't make me laugh. vkr> I would say that AmigaDOS looks like a project from a B student: vkr> A good concept, but implementation shows lack of imagination and vkr> more importantly, inability to adapt to a different evoirment: vkr> Relying on BCPL thruout is only one instance of it. Another vkr> example [why I would give the implementation a B rather than an vkr> A] is packets implemented to support only co-routines, hijacking vkr> of the Message.Node.Name field etc. But I side with Bernie: vkr> Conceptually, AmigaDOS is more evolved than Unix. But then, it vkr> did come latter. Ah, yes. But though Unix far predated AmigaDOS, the developers of AmigaDOS seem to have thrown away many of the good ideas of Unix. [I don't know why they didn't use more Unix-like things (real pipes, a hierarchical filesystem without backpointers, filesystem links, fork/exec, file descriptor handling, etc.) but I have heard [unsubstantiated] rumors of a prejudice against Unix by the developers. Exec, on the other hand, I would qualify as superior to Unix in a number of ways. [call it an A for design and an A- for implementation.] AmigaDOS has some good ideas, but a lot of things done in a very poor fashion. [B+ for design, C- for implementation.] Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2214 12th Street, Troy, NY 12180 Phone: (518) 271-0750 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.
shadow@pawl.rpi.edu (Deven T. Corzine) (08/03/89)
On 2 Aug 89 18:45:14 GMT, papa@pollux.usc.edu (Marco Papa) said: In article <SHADOW.89Aug2141201@pawl.rpi.edu| shadow@pawl.rpi.edu (Deven T. Corzine) writes: On 2 Aug 89 16:45:50 GMT, papa@pollux.usc.edu (Marco Papa) said: Marco> And, by the way, try to use less derogatory language, thank Marco> you. Deven> I normally do try, but I was tired of the whole situation (not Deven> to mention just plain tired)... it's the first (and hopefully Deven> last) article I've crossposted to alt.flame from Deven> comp.sys.amiga.tech... [first time I've bothered to crosspost Deven> to alt.flame at all, for that matter.] These things happen Deven> when I post at times like that... *sigh* Marco> As the recommendations from usenet go: "don't post when you're Marco> tired, intoxicated, stoned, angry, etc.." :^) Ah, yes. Being as how your judgement's the first thing to go. And now that your judgement's toast, what's to stop you from doing something stupid, like POSTING? :-) Marco> I guess it's time to add to my KILL file :-) Deven> Now, now. Don't be so touchy. You find most of my articles to Deven> be useless and unhelpful, and full of misinformation? Yes, I Deven> have on a few occasions lashed out at perceived stupidity, but Deven> I usually stay with constructive articles, for the most part. Deven> [overreactions... *sigh*] Marco> Using derogatory language lowers the quality and content of Marco> your postings. Keep it technical and you can't lose. Take it Marco> easy. Losen up. I am trying to do that myself. Life is hard Marco> enough. I could create an alternate identity for flaming, so you can easily filter out the low-quality posts. [and so they couldn't be traced to me! :-)] Naah... Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2214 12th Street, Troy, NY 12180 Phone: (518) 271-0750 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.
mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (08/03/89)
In article <SHADOW.89Aug2040433@pawl.rpi.edu> shadow@pawl.rpi.edu (Deven T. Corzine) writes:
<*sigh* Here I go again.
Yup, there you went again. With all the accuracy of the person usually
associated with that statement. If I had more sense, I'd ignore it,
but you've hogwashed out my horsesense.
<First, I think AmigaDOS's UI sucks. But that depends to a degree on
<what you're used to. I'm used to Unix, and I find AmigaDOS annoying
<and clumsy, and often frustratingly limiting.
This, of course, is a matter of taste. Graphical interfaces pretty much
all suck. On the other hand, if I could find a command line interface
for Unix as nice as the one I've got on my Amiga, I'd be using it in
an instant.
<Then there's the stupid 20 CLI limit...
Right. However, that can be fixed without having PD software running
on your machine. You only have to run it once...
<Ah, but the PD software is virtually _necessary_ to maintain a
<reasonable environment. (the stock configuration is virtually
<unusable, in my opinion.) [particularly the CLI]
That's odd - I run PD software to make the grahical interface more
useable. I use commercial software to make the CLI useable. Of course,
if you want a CLI that looks like Unix, you have to use PD software.
On the other hand, if you want a system that looks like Unix, you
should have bought one that ran Unix, not an OS that's superior to
Unix (see below).
<I don't see that Minix/Unix on an Amiga need be any more of a headache
<for system maintenance and administration than AmigaDOS itself is.
You obviously haven't tried adminstering a Unix machine. The entire
system is much more fragile than AmigaDOS. That getting a usable
system on a single floppy (or even two) is nearly impossible doesn't
help much.
Minix may be a vast improvement on Unix (i.e. - almost tolerable),
though. I haven't tried to run such a system.
<Bernie> There are also other disadvantages to Unix-like systems. I've
<Bernie> not seen one yet that had decent real-time response.
<
<And how often do you run across Unix systems without MMUs? Virtual
<memory can slow a system way down.
Key word: "can". It doesn't have to. Last time I looked, the hardware
people were still debating whether you could build a faster system
without virtual memory than with.
BTW, the big conventional boys (Cray, CDC) all have virtual memory (in
the sense of address mapped, not in the sense of demand paged).
Question: can anyone demonstrate that AmigaDOS is really a real-time
system? If so, what's the lower limit on response time to external
events (remember: that response has to hold no matter _what_ else is
running) if I set up a task for real-time work.
<(So much easier on the Amiga, it just crashes.)
You want a Unix box, you should buy a Unix box. Remember, the Amiga
doesn't compete (in price, anyway) with Unix, It competes with things
like the 8086 based IBMs and the Mac I. That it gets compared to Unix
boxes (even unfavorably) is a major complement all by itself.
<Real-time Unix systems DO exist. Most are not.
Quite correct. This is because designing a real-time system is not
easy, and has only a small market. Most people just don't need the
ability to responed to external events in a fixed amount of time.
<The Amiga Exec OS achieves excellent response by not supporting VM,
<message-passing by reference, strict task prioritizing and other such
<little tricks.
This is bullshit. Those are things the AmigaOS _does_. There are other
OSs that are fast that don't do those things (v6 Unix comes to mind).
There are OS's that do any of those things that are slow.
The Amiga OS is fast because some sharp people worked hard to make it
fast. That's about the only way an OS gets to be fast. And that may
not be enough.
<Bernie> There is also a more elegance of design to the AmigaDos
<Bernie> system.
<
<AmigaDOS? More elegant than Unix? Don't make me laugh.
Why should you laugh? Are you really that unschooled in OS design?
Unix follows the monolithic monitor model for OS design. The only good
reason for that is that it was written 20 years ago, when nobody knew
any better.
Unix also chose the wrong basic object for IO operations, the file.
AmigaDOS (among other OSs) got it right, and chose tasks for basic IO
objects. If you don't think this is right, I'll write a task that uses
a disk and acts like a file. You write a file that acts like a task
(using whatever hardware you need).
BTW, the same logic applies: when Unix was written, nobody knew which
was right.
Most Unices still don't have a mechanism to allow seperate control
threads to share an address space. As a result, things that need such
a facility either have to share data (making them bigger & slower), or
to implement the control sharing themselves (ditto). AmigaDOS doesn't
have a way to force processes into seperate address spaces, but that's
not something you have to code around.
Unix _was_ very simple and elegant when it was first introduced,
having a very large number of good ideas in it. However, that was 20
years ago, and now everybody and their brother has those things. Plus
being able to profit from the last 20 years of OS theory.
Of course, one thing all those people haven't picked up is how this
translates into commands the user types. Most software that was
written by people who don't understand this doesn't produce output
that could usefully be fed back to itself. Most commercial AmigaDOS
software (but not all of it) suffers from this, and takes some
processing before it can be fed to the next command down the line.
However, that's not a flaw in the OS or the Exec; that's a flaw in the
commands. That can be fixed by replacing the commands.
<Logical volumes are among the few _good_ things about AmigaDOS. Take
<a gander at dos.library sometime, however. Elegant? Ha.
Comapred to what Unix does to do DOS calls? Yes, it is. Compared to
the rest of AmigaDOS? No, it isn't.
<Oh? So you're saying the brilliant PIPE: AmigaDOS device is better
<(and more elegant!) than Unix's pipe() system call?
You haven't looked inside of a modern pipe() system call, have you?
Elegant is hardly the word. Of course, if you just want a "here's a
pair of fd's" type interface, that's not hard to build on top of
PIPE:. You wanna try and do the opposite? I'd like to know how you're
going to escape pipe()'s need for communicating processes to have a
cooperating common ancester.
<How about fork() and exec()?
What about them? The versions in my Amiga library are slightly
different than the ones on Unix, but not enough to cause any problems.
<Or are you thinking of Exec's message-passing? It has advantages and
<disadvantages, but is decent overall, and none to AmigaDOS's credit.
Sorry, but that's not quite true. That AmigaDOS could be quickly
integrated into the Exec message-passing is to it's credit. You just
flat couldn't do that with Unix.
<Bernie> (don't like CLI... only dirty three letter word I know),
What about IBM? DEC? Sun? (aka the greater devil and the two lesser
devils). I think those are all dirty words. On the other hand, I also
support or used to support software from them.
<Many excellent utilities ARE part of Unix. (generally speaking.)
No, many excellent utilities are generally shipped with Unix. They
aren't part of Unix. Those vendors that tried to unbundle the
utilities got pretty quickly trashed by their customers. That's about
the only reason the utililities generally are bundled in with the OS.
Note that the Amiga doesn't come with a C compiler, or very many other
real applications. Like most OS's meant to be used by people (as
opposed to programmers), it's a platform to put applications on, not a
platform for an application. Unix is generally viewed as a platform
for programming on. If you want to program on an Amiga, you need to
get the tools to do that, just like anything else. If you want to do
things other than program on Unix, you have to get the tools to do it.
Of course, that Unix is a programing platform means there are lots of
tools for doing things other than programming, built as programmers
needed to do them. These tools are invariably inadequate.
<For standard System V Unix, the system requirements are a bit much.
<Same for BSD. Not so for Unix Version 7. It's small and elegant.
So, where do you buy a v7 system? Oh, BTW, did you know that the v7
kernel is much larger & slower than v6, and only added one new kernel
facility?
<All current versions of Unix are derived from it.
Not so. System V is derived from PWB 1.0 (-> PWB 2.0 -> Unix 3 (aka
System III) -> Unix 4 -> System V). PWB 1.0 is dervied from a pre-v7
Unix that was never released outside of AT&T.
<It has most of the major concepts that make Unix so successful.
Actaully, the only thing that's missing is networking. Unlike
AmigaDOS, which was designed from the start with networking in mind
(see "TRIPOS--A portable Operating System for Mini-computers",
in Software P&E vol 9, pgs 513-526).
<Minix is a complete reimplementation (a much cleaner one) of Unix V7,
<distributed with source code.
It's not complete (even I know that much). It's missing mpx files and
ptrace. The former was mostly useful for crashing systems. The latter
was a bad idea poorly implemented, and nobody will miss it.
<mike
--
Tell me how d'you get to be Mike Meyer
As beautiful as that? mwm@berkeley.edu
How did you get your mind ucbvax!mwm
To tilt like your hat? mwm@ucbjade.BITNETjesup@cbmvax.UUCP (Randell Jesup) (08/03/89)
In article <1332@osupyr.mps.ohio-state.edu> Vidhyanath K. Rao <vkr@cis.ohio-state.edu> writes: >In article <SHADOW.89Aug2040433@pawl.rpi.edu> >Deven>AmigaDOS? More elegant than Unix? Don't make me laugh. > >I would say that AmigaDOS looks like a project from a B student: A good >concept, but implementation shows lack of imagination and more importantly, >inability to adapt to a different evoirment: Relying on BCPL thruout is only >one instance of it. Another example [why I would give the implementation >a B rather than an A] is packets implemented to support only >co-routines, hijacking of the Message.Node.Name field etc. But I side with >Bernie: Conceptually, AmigaDOS is more evolved than Unix. But then, it did >come latter. Two things to remember: 1) Tripos (aka AmigaDOS) was developed at Cambridge University; 2) BCPL is _the_ language at Cambridge, much in the way C is in most US unversities (lately). The C-style interfaces on top of AmigaDOS were dropped onto an OS designed for BCPL. That's changing now, of course, since we have little reason to want to encourage BCPL on the Amiga. AmigaDOS's design includes features that only recently appeared in any Unix variant, such as user-process filesystems, etc. Unix has been fine-tuned and revised many, many times. It still carries the results of some less pretty design decisions, though, and it shows it's age, for all the improvements and tweaks added over the years. AmigaDOS is much less refined, and currently has some implementation oddities, but the basic design is arguably a bit cleaner and more modern. Hopefully we'll have the chance to clean up and refine the desing and implementation over the years as Unix has done. We are a bit more beholden to the great god compatiblity than most Unix developers are, though. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
limonce@pilot.njin.net (Tom Limoncelli) (08/03/89)
Are you people trying to say that there is no "best OS" and that every
operating system has it's good points and bad points?
Damn. That blows my whole weekend.
-Tom
:-)
--
Tom Limoncelli -- tlimonce@drunivac.Bitnet -- limonce@pilot.njin.net
Drew University -- Box 1060, Madison, NJ -- 201-408-5389
Standard Disclaimer: I am not the mouth-piece of Drew University
:) Is it my imagination or are a lot of people posting everything twice?
(: ...or is this some new rule that I don't know about?jimm@amiga.UUCP (Jim Mackraz) (08/03/89)
In article <1332@osupyr.mps.ohio-state.edu> Vidhyanath K. Rao <vkr@cis.ohio-state.edu> writes:
)I would say that AmigaDOS looks like a project from a B student: A good
)concept, but implementation shows lack of imagination and more importantly,
)inability to adapt to a different evoirment: Relying on BCPL thruout is only
)one instance of it.
I think it looks more like a project that no student and few faculty
can understand: one with real world pressure and economics. "Inability
to adapt to a different environment," indeed. If you don't know the
history, you are then only showing a "lack of imagination" for the
things that can happen when you try the "business thing" for real.
You don't think people really sat down in a classroom and said, "Screw that
boring C stuff, let's do half the thing in BCPL! We'll still get an 'A'."
Have you got any preferred system that's running on over a million machines?
jimm
Is this stuff going to be on the test?
--
Jim Mackraz, I and I Computing "... the signs are very ominous,
{cbmvax,well,oliveb}!amiga!jimm and a chill wind blows."
- Justice Blackmun
Opinions are my own. Comments are not to be taken as Commodore official policy.papa@pollux.usc.edu (Marco Papa) (08/03/89)
Deven T. Corzine writes: >I could create an alternate identity for flaming, so you can easily >filter out the low-quality posts. [and so they couldn't be traced to >me! :-)] Naah... Naah, you're too ignorant to be able to do that. Now that you point this out, you're right: you have definitely written some of the lowest quality postings. And, by the way, people were making fun of you at DevCon (calling you the "latest jerk" of c.s.a.t.). I guess they were right. Goodbye, Deven ... I am joining a large group: one more line in my KILL file ... :^) -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma, Diga and Caligari!" -- Rick Unland -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
csuwk@warwick.ac.uk (Ade Lovett) (08/03/89)
shadow@pawl.rpi.edu (Deven T. Corzine) writes:
Bernie> (Did I also mention disk and memory requirements for Unix.
Bernie> Hardware vendors love it I'm sure.)
For standard System V Unix, the system requirements are a bit much.
Same for BSD. Not so for Unix Version 7. It's small and elegant.
All current versions of Unix are derived from it. It has most of the
major concepts that make Unix so successful. Minix is a complete
reimplementation (a much cleaner one) of Unix V7, distributed with
source code. [As Unix itself was, long ago.]
And you don't need a reasonable amount of disk/memory to make AmigaDOS
useable??? Hah! Next time you can work *PROPERLY* with less than 1meg and
a 20meg HD let me know, I'd be interested in how you did it..
aDehans@nlgvax.UUCP (Hans Zuidam) (08/03/89)
>In article <1332@osupyr.mps.ohio-state.edu> Vidhyanath K. Rao <vkr@cis.ohio-state.edu> writes: [A lot of silly remarks regarding AmigaDOS] jimm@amiga.UUCP (Jim Mackraz) writes: >You don't think people really sat down in a classroom and said, "Screw that >boring C stuff, let's do half the thing in BCPL! We'll still get an 'A'." "A mind is such a wonderful thing to acquire. Try it. You'll like it." (as borrowed from Larry Phillips) He is probably trying ;-). Anyway this discussion (is it one?) doesn't belong here. Hans Onions, where? In my soup? -- Hans Zuidam E-Mail: hans@pcg.philips.nl Philips Telecommunications and Data Systems, Tel: +31 40 892288 Project Centre Geldrop, Building XR Willem Alexanderlaan 7B, 5664 AN Geldrop The Netherlands
usenet@cps3xx.UUCP (Usenet file owner) (08/04/89)
In article <3352@sol.warwick.ac.uk> csuwk@warwick.ac.uk (Ade Lovett) writes: > >And you don't need a reasonable amount of disk/memory to make AmigaDOS >useable??? Hah! Next time you can work *PROPERLY* with less than 1meg and >a 20meg HD let me know, I'd be interested in how you did it.. Well a gee, since my external 3.5" floppy died, I have been doing everthing on one 3.5", 512k A1000. This includes word processing, terminal emulation, programming in C, and even a little database development. Of course I cant do all these at once, but any one of them at once is ok. Usually I can terminal emulate with any of the others. REAL NAME: Joe Porkka jap@frith.cl.msu.edu
lofaso@titan.tsd.arlut.utexas.edu (Bernie Lofaso) (08/04/89)
Yes, I'll agree with some of what you have to say. First, let me remotivate
my previous post. Its primary purpose was to point out that many people
advocate using Unix or Unix-like systems on the Amiga without any mention of
potential pitfalls. For some users these systems will be very desirable, but
others may find out the hard way that there are some serious drawbacks. I
myself am eager to see what the C= supported Unix looks like. But without
looking at the disadvantages first, it might be easy to make some ugly
mistakes. I think there are some strong arguments that the Amiga operating
system (I shall refer to as AmigaDos though I suppose technically that is just
the filing system portion), with some PD (or perhaps non-PD) utilities is as
good or better environment to work in as compared to a unix OS run on the
amiga.
Your comments regarding exec peculiarities, BCPL stuff ,etc. are noted
and I would tend to agree with nearly all of them. But that is not the level
that most users would deal with the system. For you it is a strong argument
but even amongst people who use the Amiga primarily for programming (like
myself) this is probably only a minor drawback.
With regard to Unix maintenance, a typical Unix system (whether one
user or multi-user) has files that periodically need clearing (or they grow
until your disk is full), and much system information is needed for set-up.
Printer set-up is a good example. Ever deal with printcap entries? Yuch-pui!
Being able to drop in a new driver in some directory as on the Amiga is much
easier and usually gives better results. Having a single set of printer
controls commands (from programmers prospective) is one of the features I was
considering when I said AmigaDos has a more elegant design than Unix systems.
Yes you can find Unix features that show a more elegant approach to
certain system aspects, but vice versa is more often true. I offer as an
example a comparison between SunOS and AmigaDos. The latest SunOS has
virtually all the best features from BSD and SYSV plus some addition that Sun
created. Some of these new state-of-the-art features are things that existed
in the Amiga from the start. Some aren't as good as the Amigas. Dynamically
loadable (and sharable) libraries - new feature - recognize the Amiga
counterpart? Named sockets - not too new, but nice. Often times pipes just
don't cut it (this is what I meant by IPC being worse on some Unix systems
than on the Amiga. Some Unix's only support pipes). Named message ports on
the Amiga are an approximate equivalent to this. Something like ARexx could
not exist without this OS supported feature. These are a few examples of how
the Amiga software designers developed an elegant OS based on some of the
better existing OS features at the time. True, there are some awkward
"features" in the OS, but the overall design is (my opinion of course) very
elegant.
Getting back to PD utilities, I have had good luck with some pretty
nice PD stuff on both machines. Yes Unix has a lot more, and fortunately
people are spending time to port much of it to the Amiga. Try to find a Unix
telecommunications programs and I'm afraid you'll be quite frustrated. My
Amiga environment is very much Unixized due to PD utilities and some other
unix-like utilities from my C compiler. But when all arguments are
considered, I have created a better programming environment on my Amiga than I
have on my Unix system at work and sacrificed nothing as far as deviating from
Amiga "norms". You may disagree with some of my arguments, but you can't
ignore them as they are pertinent to many of the Amiga users and their needs.
Disclaimer: My opinions are my own, except for those I have stolen from
others.peter@sugar.hackercorp.com (Peter da Silva) (08/05/89)
In article <26900@agate.BERKELEY.EDU>, mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes: > You obviously haven't tried adminstering a Unix machine. The entire > system is much more fragile than AmigaDOS. I guess that depends on whether you're administering a relatively clean commercial UNIX, like System V or Xenix, or a fancied-up PD-quality system, like BSD. I've been doing some really horrible things to various 68000- and 80386-based System-V systems, as well as the 80286-based Xenix boxes that are the main development machines, and the biggest problem's I've had have been with various third-party device drivers. Even having the source to them hasn't helped much. > Minix may be a vast improvement on Unix (i.e. - almost tolerable), > though. I haven't tried to run such a system. Minix has a long way to go. > <AmigaDOS? More elegant than Unix? Don't make me laugh. > Why should you laugh? Are you really that unschooled in OS design? Because unlike you he understands that AmigaDOS is the name of the Tripos derived file system. The rest of the system, the Exec, drivers, etc..., are together called AmigaOS. > Unix also chose the wrong basic object for IO operations, the file. The claim can be made, and in fact has been made, that so long as you choose a single object and stick to it it will work just fine. > AmigaDOS (among other OSs) got it right, and chose tasks for basic IO > objects. If you don't think this is right, I'll write a task that uses > a disk and acts like a file. You write a file that acts like a task > (using whatever hardware you need). Actually, every part of AmigaOS *except* AmigaDOS uses tasks as the basic object. AmigaDOS uses a task interface, but the basic object is the lock or file handle. Mixing models like this is a bad idea, and the main reason people get frustrated with AmigaDOS. > AmigaDOS doesn't > have a way to force processes into seperate address spaces, but that's > not something you have to code around. Rubbish. Every AmigaOS program has to have a substantial amount of code devoted to resource tracking... a job better assigned to the O/S. If you don't want to call that "coding around" the problems, then you're just playing games with words. > <Logical volumes are among the few _good_ things about AmigaDOS. Take > <a gander at dos.library sometime, however. Elegant? Ha. > Comapred to what Unix does to do DOS calls? Yes, it is. But in UNIX the program doesn't have to *know* what goes on inside the kernel. You have to dig around in internal AmigaDOS data structures to do all sorts of vitally important things... like getting a list of devices, an operation that comes for free with UNIX. > <Oh? So you're saying the brilliant PIPE: AmigaDOS device is better > <(and more elegant!) than Unix's pipe() system call? > You haven't looked inside of a modern pipe() system call, have you? Who cares what's inside. UNIX isolates the programmer from that junk. AmigaDOS forces the programmer to be aware of it. > Elegant is hardly the word. Of course, if you just want a "here's a > pair of fd's" type interface, that's not hard to build on top of > PIPE:. If you want it transparent to the programs being piped, it sure is. The only decent implementation of *that* is Bill Hawes' PIP device, which uses a non-standard call to get a pair of file handles that really do work like UNIX pipes. It's a botch. > You wanna try and do the opposite? I'd like to know how you're > going to escape pipe()'s need for communicating processes to have a > cooperating common ancester. Look at modern UNIX, Mike. "mknod p /pdev/mypipe". > <How about fork() and exec()? > What about them? The versions in my Amiga library are slightly > different than the ones on Unix, but not enough to cause any problems. Unless you want to port reasonably sophisticated UNIX software, such as ASH. > Sorry, but that's not quite true. That AmigaDOS could be quickly > integrated into the Exec message-passing is to it's credit. You just > flat couldn't do that with Unix. What part of UNIX? The only part that matters is the program interface. What's on the other side varies widely. Compare and contrast Mach (the basic object is an address space) or Minix (tasks and message ports) to conventional UNIX (co-routines) or Eunice (emulation on top of VMS). They're all UNIX as far as the program's concerned. > So, where do you buy a v7 system? Prentice-hall. It's called Minix 1.3. > Oh, BTW, did you know that the v7 > kernel is much larger & slower than v6, and only added one new kernel > facility? Which one are you talking about? Environment variables? The relatively more robust file system? Process accounting? The improved terminal driver? Long offsets to seek (lseek)? Multiplexed files (removed in 2BSD, returned within the streams system for SysV, or as ptys in 4BSD)? Improved fstat()? Umask()? Did you ever actually use V6? Are you aware that V6 was much bigger than V5, which still had substantial amounts of assembly code? -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U`
Vidhyanath.K..Rao@mamab.FIDONET.ORG (Vidhyanath K. Rao) (08/05/89)
-- Fidonet: Vidhyanath K. Rao via 1:363/9 Internet: Vidhyanath.K..Rao@mamab.FIDONET.ORG Usenet: ...!peora!rtmvax!libcmp!mamab!Vidhyanath.K..Rao
Deven.T..Corzine@mamab.FIDONET.ORG (Deven T. Corzine) (08/06/89)
-- Fidonet: Deven T. Corzine via 1:363/9 Internet: Deven.T..Corzine@mamab.FIDONET.ORG Usenet: ...!peora!rtmvax!libcmp!mamab!Deven.T..Corzine
shadow@pawl.rpi.edu (Deven T. Corzine) (08/06/89)
In article <SHADOW.89Aug2040433@pawl.rpi.edu> shadow@pawl.rpi.edu (Deven T. Corzine) writes: Deven> *sigh* Here I go again. On 3 Aug 89 00:38:07 GMT, mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) said: Mike> Yup, there you went again. With all the accuracy of the person Mike> usually associated with that statement. If I had more sense, I'd Mike> ignore it, but you've hogwashed out my horsesense. Accuracy? I find no lack of accuracy. Deven> First, I think AmigaDOS's UI sucks. But that depends to a Deven> degree on what you're used to. I'm used to Unix, and I find Deven> AmigaDOS annoying and clumsy, and often frustratingly limiting. Mike> This, of course, is a matter of taste. Graphical interfaces Mike> pretty much all suck. On the other hand, if I could find a Mike> command line interface for Unix as nice as the one I've got on Mike> my Amiga, I'd be using it in an instant. Of course it's a matter of taste. I acknowledged that, in case you didn't notice. Deven> Then there's the stupid 20 CLI limit... Mike> Right. However, that can be fixed without having PD software Mike> running on your machine. You only have to run it once... That there is a workaround does not change the fact that it is a flaw in the design. Deven> Ah, but the PD software is virtually _necessary_ to maintain a Deven> reasonable environment. (the stock configuration is virtually Deven> unusable, in my opinion.) [particularly the CLI] Mike> That's odd - I run PD software to make the grahical interface Mike> more useable. I use commercial software to make the CLI useable. Mike> Of course, if you want a CLI that looks like Unix, you have to Mike> use PD software. On the other hand, if you want a system that Mike> looks like Unix, you should have bought one that ran Unix, not Mike> an OS that's superior to Unix (see below). I don't consider "you should've gotten a Unix box then" to be a valid argument. I want an Amiga, but with the major functionality of Unix. They are NOT necessarily mutually exclusive. [and I didn't even buy an Amiga; I'm poor these days. When I can afford it I will. Until then, I can only use friends' Amigas.] Deven> I don't see that Minix/Unix on an Amiga need be any more of a Deven> headache for system maintenance and administration than Deven> AmigaDOS itself is. Mike> You obviously haven't tried adminstering a Unix machine. The Mike> entire system is much more fragile than AmigaDOS. That getting a Mike> usable system on a single floppy (or even two) is nearly Mike> impossible doesn't help much. Strike one. I have, and I am a capable sysadmin. And I still don't see that a small Unix system can't coexist with Exec and AmigaDOS. [and getting a usable AmigaDOS system on a single floppy is no small task, either.] I'm not suggesting running SysV. I propose a variant of Unix V7, as Minix is. Mike> Minix may be a vast improvement on Unix (i.e. - almost Mike> tolerable), though. I haven't tried to run such a system. Then don't attack it out of hand. You appear to be biased against Unix. So be it. Bernie> There are also other disadvantages to Unix-like systems. I've Bernie> not seen one yet that had decent real-time response. Deven> And how often do you run across Unix systems without MMUs? Deven> Virtual memory can slow a system way down. Mike> Key word: "can". It doesn't have to. Last time I looked, the Mike> hardware people were still debating whether you could build a Mike> faster system without virtual memory than with. Mike> BTW, the big conventional boys (Cray, CDC) all have virtual Mike> memory (in the sense of address mapped, not in the sense of Mike> demand paged). Fine. So I should have stipulated demand paged VM. Address mapping is easy to do in real time; it's just a lookup table in hardware. It's paging that can kill system performance. Mike> You want a Unix box, you should buy a Unix box. Remember, the Mike> Amiga doesn't compete (in price, anyway) with Unix, It competes Mike> with things like the 8086 based IBMs and the Mac I. That it gets Mike> compared to Unix boxes (even unfavorably) is a major complement Mike> all by itself. The Amiga is a fine machine. And cheaper than an equivalent Unix box. And more useful. Actually, placing the Amiga in a class with PClones and Macs sounds more like an insult to the Amiga to me. Deven> The Amiga Exec OS achieves excellent response by not supporting Deven> VM, message-passing by reference, strict task prioritizing and Deven> other such little tricks. Mike> This is bullshit. Those are things the AmigaOS _does_. There are Mike> other OSs that are fast that don't do those things (v6 Unix Mike> comes to mind). There are OS's that do any of those things that Mike> are slow. Yes, but these are optimizations which ARE significant. The whole design of Exec is centered around efficiency and flexibility. [excellent goals] Mike> The Amiga OS is fast because some sharp people worked hard to Mike> make it fast. That's about the only way an OS gets to be fast. Mike> And that may not be enough. AmigaDOS's implementation is somewhat of a crippling effect. Bernie> There is also a more elegance of design to the AmigaDos Bernie> system. Deven> AmigaDOS? More elegant than Unix? Don't make me laugh. Mike> Why should you laugh? Are you really that unschooled in OS Mike> design? Hardly. Mike> Unix follows the monolithic monitor model for OS design. The Mike> only good reason for that is that it was written 20 years ago, Mike> when nobody knew any better. I understand the traditional internal structure of Unix, and I tell you it's not as important. AmigaDOS forces C programmers to deal with (explicitly) BCPL conventions. Unix does not force awareness of its monolithic design. And Minix is structured entirely different internally, with user process devices, message passing, etc. The interface remains consistent and clean. The same can not be said for AmigaDOS. Mike> Unix also chose the wrong basic object for IO operations, the Mike> file. _ ^ You say tomato, I say tomato. Mike> AmigaDOS (among other OSs) got it right, and chose tasks for Mike> basic IO objects. If you don't think this is right, I'll write a Mike> task that uses a disk and acts like a file. You write a file Mike> that acts like a task (using whatever hardware you need). Unix /dev/* devices. They are "special files" with associated code. No specific task; they're part of that monolithic kernal. (in the traditional Unix implementation) But they act with the same effect as AmigaDOS's tasks. Strike two. Mike> BTW, the same logic applies: when Unix was written, nobody knew Mike> which was right. Ah, it's the old "the poor idiots don't know what's good for them" routine. Mike> Most Unices still don't have a mechanism to allow seperate Mike> control threads to share an address space. As a result, things Mike> that need such a facility either have to share data (making them Mike> bigger & slower), or to implement the control sharing themselves Mike> (ditto). AmigaDOS doesn't have a way to force processes into Mike> seperate address spaces, but that's not something you have to Mike> code around. No, you just have to pray every program running is well-written, so it doesn't bring down the entire system. Mike> Unix _was_ very simple and elegant when it was first introduced, Mike> having a very large number of good ideas in it. However, that Mike> was 20 years ago, and now everybody and their brother has those Mike> things. Plus being able to profit from the last 20 years of OS Mike> theory. AmigaDOS ignores many of the good examples Unix sets forth. Pipes are a prime example. Mike> Of course, one thing all those people haven't picked up is how Mike> this translates into commands the user types. Most software that Mike> was written by people who don't understand this doesn't produce Mike> output that could usefully be fed back to itself. Most Mike> commercial AmigaDOS software (but not all of it) suffers from Mike> this, and takes some processing before it can be fed to the next Mike> command down the line. That's because the design philosophy differs from that of Unix. Under Unix, in most circumstances, the preferred approach is to act on the assumption that the output from your program will be the input to another program. Mike> However, that's not a flaw in the OS or the Exec; that's a flaw Mike> in the commands. That can be fixed by replacing the commands. The commands are an integral part of the environment, and help shape and define that environment. Deven> Logical volumes are among the few _good_ things about AmigaDOS. Deven> Take a gander at dos.library sometime, however. Elegant? Ha. Mike> Comapred to what Unix does to do DOS calls? Yes, it is. Compared Mike> to the rest of AmigaDOS? No, it isn't. AmigaDOS ignores many design goals of Exec. And what's wrong with the way Unix handles FS syscalls? Deven> Oh? So you're saying the brilliant PIPE: AmigaDOS device is Deven> better (and more elegant!) than Unix's pipe() system call? Mike> You haven't looked inside of a modern pipe() system call, have Mike> you? Elegant is hardly the word. Of course, if you just want a Mike> "here's a pair of fd's" type interface, that's not hard to build Mike> on top of PIPE:. You wanna try and do the opposite? I'd like to Mike> know how you're going to escape pipe()'s need for communicating Mike> processes to have a cooperating common ancester. PIPE: is a poor excuse for a generalized networking solution. TCP/IP, Unix-domain sockets and SysV named pipes all escape the need for a common ancestor. As for the internals of the pipe() call, it's irrelevant. The internals are INTERNAL, and can be left that way. AmigaDOS prefers for force you to deal with it. Deven> How about fork() and exec()? Mike> What about them? The versions in my Amiga library are slightly Mike> different than the ones on Unix, but not enough to cause any Mike> problems. Strike three. "Slightly different?" You can't get the same functionality. You can't open files for the child process, you can't dup() a filehandle, you can't do any process environment setup after forking but BEFORE execing. About all you can do is spawn a new process. Far less flexible. Deven> Or are you thinking of Exec's message-passing? It has Deven> advantages and disadvantages, but is decent overall, and none Deven> to AmigaDOS's credit. Mike> Sorry, but that's not quite true. That AmigaDOS could be quickly Mike> integrated into the Exec message-passing is to it's credit. You Mike> just flat couldn't do that with Unix. The reason AmigaDOS adapted easily to Amiga message-passing was that TRIPOS was already based on message passing. Couldn't do what with Unix? Message passing? Try UDP. Implement AmigaDOS? Who would WANT to? [actually, you could emulate an Amiga in a single Unix process.] Deven> Many excellent utilities ARE part of Unix. (generally Deven> speaking.) Mike> No, many excellent utilities are generally shipped with Unix. Mike> They aren't part of Unix. Those vendors that tried to unbundle Mike> the utilities got pretty quickly trashed by their customers. Mike> That's about the only reason the utililities generally are Mike> bundled in with the OS. Pay attention. The "generally speaking" was because technically the utilities are not integral to Unix itself, but they ARE integral to the environment, and normally found together. Mike> These tools are invariably inadequate. Sounds like another biased opinion. Deven> For standard System V Unix, the system requirements are a bit Deven> much. Same for BSD. Not so for Unix Version 7. It's small Deven> and elegant. Mike> So, where do you buy a v7 system? Oh, BTW, did you know that the Mike> v7 kernel is much larger & slower than v6, and only added one Mike> new kernel facility? Oh, yes. The pipes. Oh, no. Pipes aren't an important part of Unix. Wake up. Deven> All current versions of Unix are derived from it. Mike> Not so. System V is derived from PWB 1.0 (-> PWB 2.0 -> Unix 3 Mike> (aka System III) -> Unix 4 -> System V). PWB 1.0 is dervied from Mike> a pre-v7 Unix that was never released outside of AT&T. I don't know about internal to AT&T, but System V was derived from System III which was derived from Unix V7. [as far as releases go.] On the other side, it went V7 -> V32 [Vax] -> BSD 4.0 -> 4.1 -> 4.2 -> 4.3, and now SysVr3 & BSD 4.3 will merge into SysVr4 and OSF will help make sure we still have two major versions. Deven> It has most of the major concepts that make Unix so successful. Mike> Actaully, the only thing that's missing is networking. Unlike Mike> AmigaDOS, which was designed from the start with networking in Mike> mind (see "TRIPOS--A portable Operating System for Mike> Mini-computers", in Software P&E vol 9, pgs 513-526). No. Ported from TRIPOS, a networking OS, into AmigaDOS, with no native networking support. (true, hacking the message-passing facility would not be difficult, but AmigaDOS has no networking.) So, why not an Amiga with Unix V7 and networking added? Deven> Minix is a complete reimplementation (a much cleaner one) of Deven> Unix V7, distributed with source code. Mike> It's not complete (even I know that much). It's missing mpx Mike> files and ptrace. The former was mostly useful for crashing Mike> systems. The latter was a bad idea poorly implemented, and Mike> nobody will miss it. Ever try using SunOS 4.0 trace(1)? Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2214 12th Street, Troy, NY 12180 Phone: (518) 271-0750 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.
Tom.Limoncelli@mamab.FIDONET.ORG (Tom Limoncelli) (08/06/89)
-- Fidonet: Tom Limoncelli via 1:363/9 Internet: Tom.Limoncelli@mamab.FIDONET.ORG Usenet: ...!peora!rtmvax!libcmp!mamab!Tom.Limoncelli
shadow@pawl.rpi.edu (Deven T. Corzine) (08/06/89)
On 4 Aug 89 13:33:23 GMT, lofaso@titan.tsd.arlut.utexas.edu (Bernie Lofaso) said: Bernie> I think there are some strong arguments that the Amiga Bernie> operating system with some PD (or perhaps non-PD) utilities is Bernie> as good or better environment to work in as compared to a unix Bernie> OS run on the amiga. Now, why need that be? How about a Unix-like system built on top of Exec, but not AmigaDOS, that can coexist with AmigaDOS? [C-A's Amix can't.] Bernie> But that is not the level that most users would deal with the Bernie> system. No, but it will carry an effect to the level that most users DO deal with... Bernie> Printer set-up is a good example. Ever deal with printcap Bernie> entries? Yuch-pui! A Unix system built on Exec could use the Exec printer.device instead of a printcap entry... Bernie> Being able to drop in a new driver in some directory as on the Bernie> Amiga is much easier and usually gives better results. Having Bernie> a single set of printer controls commands (from programmers Bernie> prospective) is one of the features I was considering when I Bernie> said AmigaDos has a more elegant design than Unix systems. Harder to create new drivers, though. Bernie> Dynamically loadable (and sharable) libraries - new feature - Bernie> recognize the Amiga counterpart? Certainly, and that's a place where the Amiga _Exec_ operating system is superior to Unix. Bernie> True, there are some awkward "features" in the OS, but the Bernie> overall design is (my opinion of course) very elegant. I completely agree that Exec is elegant, well-designed, and basically excellent all around. It's AmigaDOS I dislike. Bernie> But when all arguments are considered, I have created a better Bernie> programming environment on my Amiga than I have on my Unix Bernie> system at work and sacrificed nothing as far as deviating from Bernie> Amiga "norms". Ah, but if you have Unix and AmigaDOS running concurrently, you have the best of both worlds available to you. Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2214 12th Street, Troy, NY 12180 Phone: (518) 271-0750 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.
shadow@pawl.rpi.edu (Deven T. Corzine) (08/06/89)
Deven> AmigaDOS? More elegant than Unix? Don't make me laugh. In article <26900@agate.BERKELEY.EDU>, mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes: Mike> Why should you laugh? Are you really that unschooled in OS design? On 5 Aug 89 13:21:11 GMT, peter@sugar.hackercorp.com (Peter da Silva) said: Peter> Because unlike you he understands that AmigaDOS is the name of Peter> the Tripos derived file system. The rest of the system, the Peter> Exec, drivers, etc..., are together called AmigaOS. Indeed. Actually, you can legitimately call it "Exec" collectively, while "exec.library" is the more specific portion. Besides, "Exec" is harder to confuse with "AmigaDOS"... :-) -- Mike> Elegant is hardly the word. Of course, if you just want a Mike> "here's a pair of fd's" type interface, that's not hard to build Mike> on top of PIPE:. Peter> If you want it transparent to the programs being piped, it sure Peter> is. The only decent implementation of *that* is Bill Hawes' PIP Peter> device, which uses a non-standard call to get a pair of file Peter> handles that really do work like UNIX pipes. It's a botch. Basically, it's a kludge to workaround the fact that it was left out from the beginning. Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2214 12th Street, Troy, NY 12180 Phone: (518) 271-0750 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.
mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (08/07/89)
In article <SHADOW.89Aug6000125@pawl.rpi.edu> shadow@pawl.rpi.edu (Deven T. Corzine) writes: <In article <SHADOW.89Aug2040433@pawl.rpi.edu> shadow@pawl.rpi.edu <(Deven T. Corzine) writes: < <Deven> *sigh* Here I go again. < <On 3 Aug 89 00:38:07 GMT, <mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) said: < <Mike> Yup, there you went again. With all the accuracy of the person <Mike> usually associated with that statement. If I had more sense, I'd <Mike> ignore it, but you've hogwashed out my horsesense. < <Accuracy? I find no lack of accuracy. Of course you don't find any lack of accuracy - you don't have any accuracy in your searching. You did make some correct statements again, but mostly, your accuracy hasn't improved. However, this time I'm going to listen to my good sense, and not bother correcting you. To almost everyone else - I apologize for starting the Unix<->Amiga mess all over again. <mike -- Look at my hopes, Mike Meyer Look at my dreams. mwm@berkeley.edu The currency we've spent, ucbvax!mwm I love you. You pay my rent. mwm@ucbjade.BITNET
mks@cbmvax.UUCP (Michael Sinz - CATS) (08/07/89)
>In article <3352@sol.warwick.ac.uk> csuwk@warwick.ac.uk (Ade Lovett) writes: >> >>And you don't need a reasonable amount of disk/memory to make AmigaDOS >>useable??? Hah! Next time you can work *PROPERLY* with less than 1meg and >>a 20meg HD let me know, I'd be interested in how you did it.. Gee, I was working on an Amiga 1000, with 1.5meg RAM and 2 floppy drives. I guy named Bill Hawes (ARexx, WShell, ConMan, PathMan, etc.) is still working on an A1000 with two floppies (but with 2.5 meg of RAM) -- /----------------------------------------------------------------------\ | /// Michael Sinz -- CATS/Amiga Software/Support Engineer | | /// PHONE 215-431-9422 UUCP ( uunet | rutgers ) !cbmvax!mks | | /// | |\\\/// ...and then, just as all was in kaos, someone said: | | \XX/ "Let there be ... what was that!? ... An Amiga? ... light!" | \----------------------------------------------------------------------/
ez004559@pollux.ucdavis.edu (0040;0000002347;0;250;143;) (08/07/89)
Who in their right mind would want Minix on the Amiga anyway!` If I remember correctly, this is an Amiga section and thus, everyone probably has an Amiga. Now remember, the Amiga is a multitasking, windowing environment that's usually friendly and EASY to use. Unix is a monstrous Goliath... And it don't have windows. If you want Minix, you can get an IBM clone. I think I've read enough stuff about Minix and Unix to last me a lifetime. OUt of curiousity, how many of you brain damaged puppies out there use some incarnation of VI on your Amiga? Get a life! Haven't any of you heard of windows? Try Texed. You can spawn new Texed windows at will, and cut and paste from any Texted. It's easy to use, intuitive, doesn't take any more than 2 hours to master. Anyone who uses vi on the amiga is going to Unix hell after they die. Satan will personally tie you up to an ancient vt52 terminal hooked up to a pdp11 with a load average of 60 and force you to work on vi for hours on end. ______________________________________________________ Quantum _\/_ | 545 Sycamore Suite 207 |Frank Kuan | |\ Duck ( 0 0) | Davis, Ca 95616 |Quantum Duck Software, | |\ \______/ / \\\ | 916-757-2925 |ez004559@pollux.ucdavis.edu | |\ < < | \/ |________________________|____________________________| \ \___// / Quark! "Let them eat Spam!" - Marie Antoinspam \________/ QUARK!
shadow@pawl.rpi.edu (Deven T. Corzine) (08/08/89)
On 7 Aug 89 10:07:34 GMT, mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) said: Mike> Of course you don't find any lack of accuracy - you don't have Mike> any accuracy in your searching. You did make some correct Mike> statements again, but mostly, your accuracy hasn't improved. Mike> However, this time I'm going to listen to my good sense, and not Mike> bother correcting you. It's not worth arguing about. Mike> To almost everyone else - I apologize for starting the Mike> Unix<->Amiga mess all over again. Same here. Enough of this. Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2214 12th Street, Troy, NY 12180 Phone: (518) 271-0750 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.
rtczegledi@crocus.waterloo.edu (Richard Czegledi) (08/08/89)
Hi. I can't seem to figure out a way to, through an AREXX (script? program? Macro?) to allow a dos command to get any input from me. er.... I mean: I wish to execute 1.3's more (pathname sys:utilities/More) from an arexx application through the aux: port. The trouble is that if I do: Address Command "sys:utilities/more" morefile The more decides it can't get access to (raw keyboard events?. Explain it to me if you can) so it opens up in it's own console window (no amazing use over aux:). The same happens with any command that requires input. I am using Arexx 1.06 on a 2 meg a1000. If anyone could mail some ideas on how I could fix my problem, or code examples, I'd love it and bless your first born. --- thankyou thankyouverymuch
grr@cbmvax.UUCP (George Robbins) (08/08/89)
In article <5067@ucdavis.ucdavis.edu> ez004559@pollux.ucdavis.edu (Down with Unix!) writes: > Who in their right mind would want Minix on the Amiga anyway!` ... > OUt of curiousity, how many of you brain damaged puppies out there use some > incarnation of VI on your Amiga? Get a life! ... Come on, this is comp.sys.amiga.*tech* - there's a nice rwars/editors discussion over in alt.religion.computers if you want to discuss such. If you want technical content, please try to keep the cruft and flame wars down. As much fun as it is, it doesn't accomplish much and can drive away people who you might want to communicate with. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
jesup@cbmvax.UUCP (Randell Jesup) (08/08/89)
In article <4084@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >Because unlike you he understands that AmigaDOS is the name of the Tripos >derived file system. The rest of the system, the Exec, drivers, etc..., are >together called AmigaOS. There's more than just the filesystem. It includes a load of BCPL library routines used by the dos calls and bcpl programs (and filesystems). >> AmigaDOS (among other OSs) got it right, and chose tasks for basic IO >> objects. If you don't think this is right, I'll write a task that uses >> a disk and acts like a file. You write a file that acts like a task >> (using whatever hardware you need). > >Actually, every part of AmigaOS *except* AmigaDOS uses tasks as the basic >object. AmigaDOS uses a task interface, but the basic object is the lock or >file handle. Mixing models like this is a bad idea, and the main reason people >get frustrated with AmigaDOS. Actually, the filehandle is not the basic object: the coroutine is (for OFS/FFS). The filehandle is a handle on the coroutine in the FS. The FS is full of coroutines. Makes some things very clean, makes others very tough to add. >Rubbish. Every AmigaOS program has to have a substantial amount of code >devoted to resource tracking... a job better assigned to the O/S. If you >don't want to call that "coding around" the problems, then you're just playing >games with words. Many requests for what people call "resource tracking" are actually requests for memory protection. I consider any program on ANY os that doesn't free what it allocates (memory, file locks, whatever) to be at best poorly written. Not to say some resource tracking wouldn't be a bad idea. However, in a multitasking, lightweight process machine you have to be careful: many programs pass off resources (permanently) to other processes (or to no one: public structures, for example.) One can't merely add freeing of resources on program exit to current programs; they'll break. >But in UNIX the program doesn't have to *know* what goes on inside the kernel. >You have to dig around in internal AmigaDOS data structures to do all sorts of >vitally important things... like getting a list of devices, an operation that >comes for free with UNIX. Hmm, ps seems to know a lot..., and what's the purpose of /dev/kmem, eh? :-) I agree about the AmigaDOS structures. Personally I prefer modules closer to Abstract Data Types (ADT's): access should be mostly by functions, all reasonable operations supported, as many data structures as possible _totally_ hidden. I particularily abhor applications allocating system data structures and passing them to the system. >> Elegant is hardly the word. Of course, if you just want a "here's a >> pair of fd's" type interface, that's not hard to build on top of >> PIPE:. > >If you want it transparent to the programs being piped, it sure is. The >only decent implementation of *that* is Bill Hawes' PIP device, which >uses a non-standard call to get a pair of file handles that really do >work like UNIX pipes. It's a botch. You don't need to do that. Named pipes can work quite nicely in place of Unix pipes; most of the work in using pipes is in the shell. I know, I've written shells that do unix piping ('|') and pipe-handlers before (before I came to commodore). I see no need for Bill's special packets. >> What about them? The versions in my Amiga library are slightly >> different than the ones on Unix, but not enough to cause any problems. > >Unless you want to port reasonably sophisticated UNIX software, such as >ASH. Suprise! AmigaDos is not Unix! It doesn't claim to be. What's going on here is most C compilers in most systems try to provide a bunch of fairly standard Unix functions to make porting Unix programs easier. Note the word "easier". Since the OS they run on top of is not Unix, the library routines often aren't 101% Unix XYZZY compatible. This doesn't mean you can't do the things you want to in AmigaDos: just that you may have to do them a different way (the fork() and exec() calls were not given to DMR on a stone tablet). I also don't mean to say all the functionality that should be is in the current DOS. It isn't. I'm working to correct this; I think you'll like what you see. :-) >What part of UNIX? The only part that matters is the program interface. >What's on the other side varies widely. Compare and contrast Mach (the >basic object is an address space) or Minix (tasks and message ports) to >conventional UNIX (co-routines) or Eunice (emulation on top of VMS). Spoken like a true portable Unix application writer. :-) Seriously, most Uni are still using the ancient 'monolithic monitor' model for their kernel. There are some _small_, hesitant steps away from it, but not very fast, and not mainstream. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
doug@xdos.UUCP (Doug Merritt) (08/08/89)
In article <5067@ucdavis.ucdavis.edu> ez004559@pollux.ucdavis.edu (Down with Unix!) writes: Your byline above is enough to start a flame war by itself. >Unix is a monstrous Goliath... And it don't have windows. If you want Minix, >you can get an IBM clone. I think I've read enough stuff about Minix and >Unix to last me a lifetime. Unix has its faults. AmigaDOS has its faults. I also fault your flaming posting. I use Sun OS at work, and it does in fact have windows. >OUt of curiousity, how many of you brain damaged puppies out there use some >incarnation of VI on your Amiga? Get a life! Haven't any of you heard of >windows? Try Texed. You can spawn new Texed windows at will, and cut and paste >from any Texted. It's easy to use, intuitive, doesn't take any more than 2 >hours to master. A rude and immature question like this doesn't really deserve a response, but just for the hell of it: I've been using vi for 10 or 11 years, and its commands are hardwired into my fingertips. This allows me to do complex editing operations *extremely* fast. If I switched to a better editor, such as an emacs or possibly texted, it would slow me down due to the need to *think* about the commands. Currently I edit by reflex, and that's much faster than any conscious action possibly could be. Look up "conditioned reflex" in a good psychology text to see a numeric timing comparison. Or watch a martial arts demo, and note the difference between the intermediate and advanced students. A great deal of the improvement comes from turning the various motions into conditioned reflexes. Furthermore there is one very important area of complex commands that *do* require conscious thought, where vi is superior to all existing editors... its global/range search-and-replace command set surpasses even Gnu Emacs. vi-haters never seem to be aware of just how powerful it is, but once you learn the entire set, it's a very hard set of capabilities to give up. Sometimes I think it'd be worth it to switch to get e.g. more powerful macros, the ability to window, etc. But not just yet; it'd take several years to turn the new commands into conditioned reflexes. The lack of windowing is less important on a system that itself supports windows, since you can use multiple system windows as a substitute. Cut and paste is supported in vi in a way painful to vi-novices and less elegant than e.g. emacs, yet again seems perfectly convenient when it happens by conditioned reflex. >Anyone who uses vi on the amiga is going to Unix hell after >they die. Satan will personally tie you up to an ancient vt52 terminal hooked >up to a pdp11 with a load average of 60 and force you to work on vi for hours >on end. Pretty funny...the one redeeming part of your posting. And I shudder to think of the kind of hell reserved for narrow minded people who flame about their own limited understandings. Doug -- Doug Merritt {pyramid,apple}!xdos!doug Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary
swarren@eugene.uucp (Steve Warren) (08/08/89)
In article <5067@ucdavis.ucdavis.edu> ez004559@pollux.ucdavis.edu (Down with Unix!) writes: >Who in their right mind would want Minix on the Amiga anyway!` [...] >Unix is a monstrous Goliath... And it don't have windows. If you want Minix, [...] >OUt of curiousity, how many of you brain damaged puppies out there use some >incarnation of VI on your Amiga? Get a life! Haven't any of you heard of [...] >to master. Anyone who uses vi on the amiga is going to Unix hell after they die. [...] If you've been following the discussion and reading the posts from our friends in Germany who are doing the port, then you know who & why and realise they have a very good reason for the port. It is a lot of work, and they surely are not doing it in order to provide flame topics on comp.sys.amiga. If you've not followed the discussion, then shame on you for flaming in ignorance. Also, please let's not start a "my editor is better than yours" flamefest. Nobody is going to change their minds because of it, and everyone is going to get red-faced and angry over a matter of opinion. Why do you care what editor I use (not vi :-)? --Steve ------------------------------------------------------------------------- {uunet,sun}!convex!swarren; swarren@convex.COM
shadow@pawl.rpi.edu (Deven T. Corzine) (08/08/89)
On 5 Aug 89 17:01:09 GMT, in articles
<154.24DDB52A@mamab.FIDONET.ORG>, <154.24DDB52D@mamab.FIDONET.ORG> and
<154.24DD527@mamab.FIDONET.ORG> some stupid jerk posts some of the
worst forgeries I've seen to date:
"Deven"> Path: rpi!crdgw1!ge-dab!peora!tarpit!libcmp!mamab!Deven.T..Corzine
"Deven"> From: Deven.T..Corzine@mamab.FIDONET.ORG (Deven T. Corzine)
"Deven"> Newsgroups: comp.sys.amiga.tech
"Deven"> Subject: Re: Minix, Unix on the Amiga, and flames on AmigaDOS braindamage...
"Deven"> Message-ID: <154.24DDB52A@mamab.FIDONET.ORG>
"Deven"> Date: 5 Aug 89 17:01:09 GMT
"Deven"> Organization: MaMaB--the Machine in Mark's Bedroom
^^^^
Who's this "Mark"? The jerk posting these forgeries?
"Deven"> Lines: 6
"Deven">
"Deven">
"Deven">
"Deven"> --
"Deven"> Fidonet: Deven T. Corzine via 1:363/9
"Deven"> Internet: Deven.T..Corzine@mamab.FIDONET.ORG
"Deven"> Usenet: ...!peora!rtmvax!libcmp!mamab!Deven.T..Corzine
Don't believe it. I am the one and only Deven Thomas Corzine. For
better or worse.
Deven
--
Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu
Snail: 2214 12th Street, Troy, NY 12180 Phone: (518) 271-0750
Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven
Simple things should be simple and complex things should be possible.ejkst@unix.cis.pittsburgh.edu (Eric J. Kennedy) (08/09/89)
In article <5067@ucdavis.ucdavis.edu> ez004559@pollux.ucdavis.edu (Down with Unix!) writes:
<OUt of curiousity, how many of you brain damaged puppies out there use some
<incarnation of VI on your Amiga? Get a life! Haven't any of you heard of
<windows? Try Texed. You can spawn new Texed windows at will, and cut and paste
<from any Texted. It's easy to use, intuitive, doesn't take any more than 2 hours
<to master. Anyone who uses vi on the amiga is going to Unix hell after they die.
<Satan will personally tie you up to an ancient vt52 terminal hooked up to
<a pdp11 with a load average of 60 and force you to work on vi for hours on end.
I use an incarnation of vi on my Amiga. It uses the mouse, emacs-style
windows, cut-and-paste, etc.
Now please go away.
--
Eric Kennedy
ejkst@cisunx.UUCPderaadt@enme3.ucalgary.ca (Theo Deraadt) (08/09/89)
In article <154.24DDB52A@mamab.FIDONET.ORG> Deven.T..Corzine@mamab.FIDONET.ORG (Deven T. Corzine) writes: > > >-- >Fidonet: Deven T. Corzine via 1:363/9 >Internet: Deven.T..Corzine@mamab.FIDONET.ORG >Usenet: ...!peora!rtmvax!libcmp!mamab!Deven.T..Corzine Certainly, Deven, one of your best messages lately. Not a lot less information than some previous ones.. <tdr. Theo de Raadt (403) 289-5894 Calgary, Alberta, Canada
jesup@cbmvax.UUCP (Randell Jesup) (08/09/89)
Not really wanting to start a flame war, but... In article <439@xdos.UUCP> doug@xdos.UUCP (Doug Merritt) writes: >The lack of windowing is less important on a system that itself supports >windows, since you can use multiple system windows as a substitute. Cut >and paste is supported in vi in a way painful to vi-novices and less >elegant than e.g. emacs, yet again seems perfectly convenient when it >happens by conditioned reflex. BTW, what do VI users do when they want to cut and paste _between_ files?? I never though of that before; it must be a pain. Editors are a religous issue, anyone who wants to flame about them go to alt.computers.religion, please. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
shadow@pawl.rpi.edu (Deven T. Corzine) (08/09/89)
On 8 Aug 89 15:44:03 GMT, doug@xdos.UUCP (Doug Merritt) said: Doug> Furthermore there is one very important area of complex commands Doug> that *do* require conscious thought, where vi is superior to all Doug> existing editors... its global/range search-and-replace command Doug> set surpasses even Gnu Emacs. *That* I find hard to believe. GNU Emacs has not only query-replace (a very nice function) but also query-replace-regexp. [not bound to any key by default.] An incremental search is a useful and impressive beast... [A regexp I-search would be pretty incredible...] Tell me what vi's got that GNU Emacs hasn't... [Email unless you actually think it's of general interest; this is already questionable.] Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2214 12th Street, Troy, NY 12180 Phone: (518) 271-0750 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.
rachamp@mbunix.mitre.org (Richard A. Champeaux) (08/10/89)
In article <439@xdos.UUCP> doug@xdos.UUCP (Doug Merritt) writes: >A rude and immature question like this doesn't really deserve a response, >but just for the hell of it: I've been using vi for 10 or 11 years, and >its commands are hardwired into my fingertips. This allows me to do complex >editing operations *extremely* fast. If I switched to a better editor, >such as an emacs or possibly texted, it would slow me down due to the >need to *think* about the commands. Currently I edit by reflex, and that's >much faster than any conscious action possibly could be. Look up "conditioned >reflex" in a good psychology text to see a numeric timing comparison. > >Doug Merritt {pyramid,apple}!xdos!doug I agree that VI isn't all that bad once you get used to it. I've been forced to use it at work for the past couple of months, but I'm still a novice user. The thing that really annoys me is that it's beginning to become second nature. When I go home and use UEdit, I end up inserting h's,j's,k's, and l's all over the place. I've gotten into the habit of pressing ESC every time I want to move the cursor, and I get confused when I try to exit the file with :x. Two more weeks and I get to become a one editor person again. Rich Champeaux (rachamp@mbunix.mitre.org)
peter@sugar.hackercorp.com (Peter da Silva) (08/10/89)
In article <7570@cbmvax.UUCP>, jesup@cbmvax.UUCP (Randell Jesup) writes: > In article <4084@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: > >Because unlike you he understands that AmigaDOS is the name of the Tripos > >derived file system. The rest of the system, the Exec, drivers, etc..., are > >together called AmigaOS. > There's more than just the filesystem. It includes a load of BCPL > library routines used by the dos calls and bcpl programs (and filesystems). (dismissively waves hands) comes down to the same thing. The DOS is in BCPL. > >> AmigaDOS (among other OSs) got it right, and chose tasks for basic IO > >> objects. > >Actually, every part of AmigaOS *except* AmigaDOS uses tasks as the basic > >object. AmigaDOS uses a task interface, but the basic object is the lock or > >file handle. Mixing models like this is a bad idea, and the main reason > >people get frustrated with AmigaDOS. > > Actually, the filehandle is not the basic object: the coroutine is > (for OFS/FFS). The filehandle is a handle on the coroutine in the FS. Programmer interface is what's important here. What goes on on the other side of dos.library is irrelevant. A program talks to DOS by making library calls using a filehandle as the basic object. There are a few programs that explicitly pass messages to handlers (browser is one of them), but unless you do it strictyly synchronously this way is fraught with danger. Locks and file handles are the basic objects in DOS. Messages and message ports are the basic objects in the rest of the system. > Many requests for what people call "resource tracking" are actually > requests for memory protection. I consider any program on ANY os that doesn't > free what it allocates (memory, file locks, whatever) to be at best poorly > written. What I'm talking about is resource tracking. My buddy Karl has written a nice tracking library that tattles on you if you foul up. It's kind of hard to track everything, though... you have to put a wrapper around just about every call you make... The biggest problem with the lack of resource tracking is that you can't easily do a standard UNIX-type shell, because you HAVE to watch all your children so you can close (or not close) their standard input and output file handles when they exit. It's a royal pain. If these were properly tracked, it would not be a problem. > Not to say some resource tracking wouldn't be a bad idea. However, > in a multitasking, lightweight process machine you have to be careful: many > programs pass off resources (permanently) to other processes (or to no one: > public structures, for example.) One can't merely add freeing of resources > on program exit to current programs; they'll break. No, it has to be in the system from the start. If there had been a "release" call, that programs used to let the system know they weren't using a given resource, a lot of things would be easier now. I'm not asking for enhancements, just pointing out some advantages to UNIX. Listening to some people here you'd think there weren't any. > >But in UNIX the program doesn't have to *know* what goes on inside the kernel. > >You have to dig around in internal AmigaDOS data structures to do all sorts of > >vitally important things... like getting a list of devices, an operation that > >comes for free with UNIX. > Hmm, ps seems to know a lot..., and what's the purpose of /dev/kmem, > eh? :-) PS is a special case, which is highlighted by the fact that it's setuid. User programs don't need to mess around in kmem, and in fact don't have permission to. > >Unless you want to port reasonably sophisticated UNIX software, such as > >ASH. > Suprise! AmigaDos is not Unix! It doesn't claim to be. No, but to hear Mike talk all you need is a fancy library. 'tain't so. Mild gritch: > (the fork() and exec() > calls were not given to DMR on a stone tablet). You mean KT, no? > I also don't mean to say all the functionality that should be is > in the current DOS. It isn't. I'm working to correct this; I think you'll > like what you see. :-) Details, details! > Spoken like a true portable Unix application writer. :-) That's me. It's NOT that hard to write programs that run on a wide variety of UNIX systems without a mass of #ifdef spaghetti. > Seriously, most Uni are still using the ancient 'monolithic monitor' model > for their kernel. There are some _small_, hesitant steps away from it, but > not very fast, and not mainstream. Mach isn't mainstream? Ah, just you wait... there are more things in heaven and earth than a dreamt of in your philosophy. -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U`
chas@gtss.gatech.edu (Charles Cleveland) (08/10/89)
In article <1677@cs-spool.calgary.UUCP> deraadt@enme3.UUCP (Theo Deraadt) writes: )In article <154.24DDB52A@mamab.FIDONET.ORG> Deven.T..Corzine@mamab.FIDONET.ORG (Deven T. Corzine) writes: )> )> )>-- )>Fidonet: Deven T. Corzine via 1:363/9 )>Internet: Deven.T..Corzine@mamab.FIDONET.ORG )>Usenet: ...!peora!rtmvax!libcmp!mamab!Deven.T..Corzine ) ) )Certainly, Deven, one of your best messages lately. Not a lot less )information than some previous ones.. ) <tdr. ) )Theo de Raadt (403) 289-5894 Calgary, Alberta, Canada Since some people are apparently still unaware of it, forgeries are spewing out of mamab all over the net. I suggest you respond to nothing from that site. Deven has already been hit three times by this character, who has been very busy lately. The "Machine in Mark's Bedroom" gets a uucp feed from libcmp, it looks like. Perhaps some of the offended parties should get in touch with the postmaster there. If these posting are really coming from libcmp!mamab, he ought to have his wires cut. Same for FIDONET, but I don't know how that works. Until then, ignore the creep. -- "Our vision is to speed up time, eventually eliminating it." -- Alex Schure Charles Cleveland Georgia Tech School of Physics Atlanta, GA 30332-0430 UUCP: ...!gatech!gtss!chas INTERNET: chas@gtss.gatech.edu
charles@hpcvca.CV.HP.COM (Charles Brown) (08/11/89)
>> Rubbish. Every AmigaOS program has to have a substantial amount of code >> devoted to resource tracking... a job better assigned to the O/S. If you >> don't want to call that "coding around" the problems, then you're >> just playing games with words. > Many requests for what people call "resource tracking" are actually > requests for memory protection. I consider any program on ANY os > that doesn't free what it allocates (memory, file locks, whatever) > to be at best poorly written. > -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. I try to write my programs in standard C so that they are portable between Unix and Amiga. I told a friend of mine (who doesn't own an Amiga but who knows a great deal about Unix) that I planned to change my programming style to explicitely free all memory that I had malloced. He said that under Unix that was a bad idea because the OS can free the memory much faster than my explicit calls. Hence I would be slowing down my program (as well as making it larger) and would get no benefit. As far as I know, that criticism applys to all operating systems except the Amiga's. It is not clear to me that slowing down the code and making it larger on all systems is better when there is only one system which requires it. (Fortunately C provides #ifdef.) -- Charles Brown charles@cv.hp.com or charles%hpcvca@hplabs.hp.com or hplabs!hpcvca!charles or "Hey you!" Not representing my employer.
shadow@pawl.rpi.edu (Deven T. Corzine) (08/11/89)
On 10 Aug 89 13:43:16 GMT, chas@gtss.gatech.edu (Charles Cleveland) said: Charles> Summary: forgery alert Charles> Since some people are apparently still unaware of it, Charles> forgeries are spewing out of mamab all over the net. I Charles> suggest you respond to nothing from that site. Deven has Charles> already been hit three times by this character, who has been Charles> very busy lately. Three times? I've only noticed the one in comp.sys.amiga.tech here. Where else? [email] Charles> The "Machine in Mark's Bedroom" gets a uucp feed from libcmp, Charles> it looks like. Perhaps some of the offended parties should Charles> get in touch with the postmaster there. If these posting are Charles> really coming from libcmp!mamab, he ought to have his wires Charles> cut. Same for FIDONET, but I don't know how that works. It has been suggested that it could be messed up gateway software causing the messages, and not intentional forgeries. Whether this is true or not, I don't know, but regardless, I don't like it. (To mung messages that badly would take some *seriously* broken software...) Charles> Until then, ignore the creep. Agreed. Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2214 12th Street, Troy, NY 12180 Phone: (518) 271-0750 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.
rokicki@polya.Stanford.EDU (Tomas G. Rokicki) (08/12/89)
charles@hpcvca.CV.HP.COM (Charles Brown) writes: > I told a friend of mine (who doesn't own an > Amiga but who knows a great deal about Unix) that I planned to change > my programming style to explicitely free all memory that I had > malloced. He said that under Unix that was a bad idea because the OS > can free the memory much faster than my explicit calls. Hence I would > be slowing down my program (as well as making it larger) and would get > no benefit. Depends on the style program you write. First, the program won't be much larger, typically, as the `free' stuff is a simple traversal of a linked list. Secondly, even under Unix in *many* cases freeing memory is crucial. The virtual address space of a process is limited, and you can easily run out if all you do is malloc() with no free's. Even without this, though, if you don't free(), your usage of malloc()'d memory may become fragmented, distributing your `working set' over a much larger number of memory pages, causing swapping and other bad behavior. If your program runs for a while, possibly over several jobs in the same invocation, and you must malloc() memory, please free() it when appropriate. If all you want is Unix/Amiga compatibility, might as well use the malloc() functions supplied by the various compiler vendors, as they are compatible . . . -tom
grr@cbmvax.UUCP (George Robbins) (08/12/89)
In article <1410023@hpcvca.CV.HP.COM> charles@hpcvca.CV.HP.COM (Charles Brown) writes: > >> Rubbish. Every AmigaOS program has to have a substantial amount of code > >> devoted to resource tracking... a job better assigned to the O/S. If you > >> don't want to call that "coding around" the problems, then you're > >> just playing games with words. > > I try to write my programs in standard C so that they are portable > between Unix and Amiga. I told a friend of mine (who doesn't own an > Amiga but who knows a great deal about Unix) that I planned to change > my programming style to explicitely free all memory that I had > malloced. He said that under Unix that was a bad idea because the OS > can free the memory much faster than my explicit calls. To some extent this may be true, especially if it's a simple case of malloc whatever you use once and then run with it. If you malloc stuff on an ongoing basis or have a program that runs for an arbitrary length of time, then even in a "free on termination" environment, you should be tracking and freeing memory. The alternative is known as "memory leaks". In most cases, the amount of code/time to free allocated memory should be quite trivial. If it bothers your efficiency experts, then #ifdef the code... -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
jesup@cbmvax.UUCP (Randell Jesup) (08/12/89)
In article <1410023@hpcvca.CV.HP.COM> charles@hpcvca.CV.HP.COM (Charles Brown) writes: >> Many requests for what people call "resource tracking" are actually >> requests for memory protection. I consider any program on ANY os >> that doesn't free what it allocates (memory, file locks, whatever) >> to be at best poorly written. >> -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. > >I try to write my programs in standard C so that they are portable >between Unix and Amiga. I told a friend of mine (who doesn't own an >Amiga but who knows a great deal about Unix) that I planned to change >my programming style to explicitely free all memory that I had >malloced. He said that under Unix that was a bad idea because the OS >can free the memory much faster than my explicit calls. Hence I would >be slowing down my program (as well as making it larger) and would get >no benefit. As far as I know, that criticism applys to all operating >systems except the Amiga's. Well, if you use the C library routines malloc() and free(), there is no _need_ to free everything, since the library implementation and exit() code takes care of freeing malloc()ed memory. Doesn't mean I like the practice: it places more reliance on the malloc to be unix-compatible, and precludes replacing malloc (easily) with lower-level memory calls with less overhead than malloc (such as AllocMem, or something like it). Doing something like that saved me over 1K, by dumping malloc, and made my program run faster. Another reason I prefer a style where everything is freed is that it makes the code more reusable: you can take a subroutine and use it, and not have to worry about using immense mounts of virtual space that you are no longer using. (Since you may use it repeatedly in a loop without exiting, if it drops memory every time it can add up quickly.) As you might guess, I'm not a big fan of garbage collection. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
phils@tekigm2.MEN.TEK.COM (Philip E Staub) (08/12/89)
In article <63189@linus.UUCP> rachamp@mbunix (Champeaux) writes: >In article <439@xdos.UUCP> doug@xdos.UUCP (Doug Merritt) writes: [ comments about 'vi becoming second nature' deleted] >> >>Doug Merritt {pyramid,apple}!xdos!doug > >I agree that VI isn't all that bad once you get used to it. I've been forced >to use it at work for the past couple of months, but I'm still a novice user. >The thing that really annoys me is that it's beginning to become second nature. >When I go home and use UEdit, I end up inserting h's,j's,k's, and l's all over >the place. I've gotten into the habit of pressing ESC every time I want to >move the cursor, and I get confused when I try to exit the file with :x. Two >more weeks and I get to become a one editor person again. ^^^^^^^^^^^^^^^^^ > >Rich Champeaux (rachamp@mbunix.mitre.org) This is precisely why I switched to MicroEMACS 3.10. I have occasion to use 4 different operating systems on a regular basis (BSD, VMS (Uggh!), MS-DOS(GAAK!), and AmigaDOS), and I have MicroEMACS on all of them, and they all work the same way. I used vi for much the same reason for a long time (until I started having to grovel around in VMS), though I was never completely satisfied with the minor differences between the clones. I was also envious of the people with editors which could handle multiple windows on screen at once. MicroEMACS was a good solution, but it wasn't until version 3.10 that I was happy enough with it to switch to it completely. Regards, Phil -- ------------------------------------------------------------------------------ Phil Staub, phils@tekigm2.MEN.TEK.COM Definition: BUG: A feature (present or absent) which is (at best) inconvenient.
mcp@ziebmef.uucp (Marc Plumb) (08/12/89)
In article <3352@sol.warwick.ac.uk> csuwk@warwick.ac.uk (Ade Lovett) writes: > And you don't need a reasonable amount of disk/memory to make AmigaDOS > useable??? Hah! Next time you can work *PROPERLY* with less than 1meg and > a 20meg HD let me know, I'd be interested in how you did it.. I don't know what "properly" is, but I develop on a 2-floppy 512K A1000. It's getting to the point where I want more memory and a HD (I have an unpopulated ASDG 8M board plugged into Amy waiting for a really good deal on some slow 1Meg x 1 parts), but I'm surviving. -- -Colin Plumb
karl@sugar.hackercorp.com (Karl Lehenbauer) (08/13/89)
In article <5067@ucdavis.ucdavis.edu>, ez004559@pollux.ucdavis.edu (0040;0000002347;0;250;143;) writes: > Unix ... don't have windows. False. > OUt of curiousity, how many of you brain damaged puppies out there use some > incarnation of VI on your Amiga? Get a life! OUt of curiosity, can you do anything besides flame? Get a life! -- -- uunet!sugar!karl "Have you debugged your wolf today?" -- free Usenet access: (713) 438-5018
karl@sugar.hackercorp.com (Karl Lehenbauer) (08/13/89)
In article <7570@cbmvax.UUCP>, jesup@cbmvax.UUCP (Randell Jesup) writes: > I consider any program on ANY os that doesn't > free what it allocates (memory, file locks, whatever) to be at best poorly > written. Careful, Randall, I think you've been using your Amiga too long. There is no reason a program should have to free its memory if the operating system does it. Programs written for such an OS cannot be considered "at best poorly written" if their authors did not choose to gratuitously add that redundant capability. Few multitasking operating systems have not done tracked memory, because memory leaks can crash them (cf AmigaDOS). Protection, priveledge instructions and such were created to keep rogue programs from doing in themselves, other programs and the OS. However, we have learned to live with this unprotected system, and there are certain advatages, like intertask communication is easy and high-performance, there are a million of these multitasking machines out there and people can buy them for $500. So when people come to bash, comparing the Amiga unfavorably to stripped $12,000 workstations, it gets kind of ridiculous. Anyway, the Mac's in the same boat, as is every DOS/Windows user (an absurdity considering how long the 286, with its built-in MMU, has been out.) -- -- uunet!sugar!karl "Have you debugged your wolf today?" -- free Usenet access: (713) 438-5018
karl@sugar.hackercorp.com (Karl Lehenbauer) (08/13/89)
In article <SHADOW.89Aug9002631@pawl.rpi.edu>, shadow@pawl.rpi.edu (Deven T. Corzine) writes: > Tell me what vi's got that GNU Emacs hasn't... Uh, a version for AmigaDOS? -- -- uunet!sugar!karl "Have you debugged your wolf today?" -- free Usenet access: (713) 438-5018
shadow@pawl.rpi.edu (Deven T. Corzine) (08/13/89)
In article <SHADOW.89Aug9002631@pawl.rpi.edu>, shadow@pawl.rpi.edu (Deven T. Corzine) writes: Deven> Tell me what vi's got that GNU Emacs hasn't... On 12 Aug 89 19:25:55 GMT, karl@sugar.hackercorp.com (Karl Lehenbauer) said: Karl> Uh, a version for AmigaDOS? Neither does. Vi has poor clones, Emacs has incomplete (some poor, some good) clones. mg{2,3}a is much better than any vi clone I've seen on the Amiga... Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2214 12th Street, Troy, NY 12180 Phone: (518) 271-0750 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.
usenet@cps3xx.UUCP (Usenet file owner) (08/14/89)
In article <4107@sugar.hackercorp.com> karl@sugar.hackercorp.com (Karl Lehenbauer) writes: >In article <7570@cbmvax.UUCP>, jesup@cbmvax.UUCP (Randell Jesup) writes: >> I consider any program on ANY os that doesn't >> free what it allocates (memory, file locks, whatever) to be at best poorly >> written. > >Careful, Randall, I think you've been using your Amiga too long. > >There is no reason a program should have to free its memory if the operating >system does it. Programs written for such an OS cannot be considered Even worse, even in UNIX, is programs that fail to check if they are out on memory. Most UNIX programs *do not* ever check this. UNIX programmers assume a blissful computer with plenty enough VM to get by. Well, we have a Sun386i here. With several messydos windows open, it does run out of memory (im not sure exactly what the problem is, but it has something to do with the fact that DOS emultions run in real memory and is not subject to VM). When this happens, most thing will segmentation-fault, since they don't check for NULLs returned by malloc. Of course no Amiga programmer ever forgets to check such things :-) REAL NAME: Joe Porkka jap@frith.cl.msu.edu
darin@nova.laic.uucp (Darin Johnson) (08/15/89)
In article <63189@linus.UUCP> rachamp@mbunix (Champeaux) writes: >Two more weeks and I get to become a one editor person again. Right now, I use 3 editors regularly. More if you count the differences between GNU Emacs, MG2A, ZEmacs, etc. On VMS, I use TPU/EVE almost exsclusively (EVE+ with my own extensions, actually). EDT when I am forced to. Occasionally I use GNU Emacs on VMS, but EVE is much more convenient. On UNIX, I usually just log in for a few minutes (I am only a part time sysadmin) so VI is handy in that it starts up almost immediately. When I program on UNIX, I stick with GNU Emacs, even though my silly terminal doesn't have an escape, ^S is gobbled up, etc. On the Amiga, MG2A exclusively. I've tried others, but I usually end up deleting everything and have to read the manuals to find out how to undo. In 3 or 4 weeks, it's back to 1 editor only, hurrah! Darin Johnson (leadsv!laic!darin@pyramid.pyramid.com) We now return you to your regularly scheduled program.
jesup@cbmvax.UUCP (Randell Jesup) (08/15/89)
In article <4148@cps3xx.UUCP> porkka@frith.UUCP (Joe Porkka) writes: >In article <4107@sugar.hackercorp.com> karl@sugar.hackercorp.com (Karl Lehenbauer) writes: >>In article <7570@cbmvax.UUCP>, jesup@cbmvax.UUCP (Randell Jesup) writes: >>> I consider any program on ANY os that doesn't >>> free what it allocates (memory, file locks, whatever) to be at best poorly >>> written. >> >>Careful, Randall, I think you've been using your Amiga too long. >> >>There is no reason a program should have to free its memory if the operating >>system does it. Programs written for such an OS cannot be considered > >Even worse, even in UNIX, is programs that fail to check if >they are out on memory. > >Most UNIX programs *do not* ever check this. UNIX programmers assume >a blissful computer with plenty enough VM to get by. Plus, as I said, even in unix it can be advantageous to free things you allocate, both from performance and ability to run in a (relatively) tight VM system. I used to free everything even when programming in Ada, though it was fairly standard just to drop things and forget them. I was told Ada assumed the memory would be recovered via garbage collection, or some such, but no one had ever written a compiler/run-time-package that did it. (my memory could be foggy on this.) -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
peter@sugar.hackercorp.com (Peter da Silva) (08/16/89)
In article <4148@cps3xx.UUCP>, usenet@cps3xx.UUCP (Usenet file owner) writes: > Most UNIX programs *do not* ever check this. UNIX programmers assume > a blissful computer with plenty enough VM to get by. This is pure garbage. I don't think I've seen any ordinary UNIX programs that do this. Now things might be different in the X-windows world, where they have a rather cavalier attitude towards resource usage. You did mention that you're using a Sun... (speaking of Suns, we just got one at work. *This* is supposed to be a better product than System V? It's sure got more bells and whistles, but the amount of integration and productizing is virtually nil) If you want to point a finger at UNIX programs, there is a problem with the assumption that disk space is effectively infinite... but I've not seen too many Amiga programs that check for this, either. A few, yes, so it shows a bit more care... but most still ignore error returns from Write. Now Amiga programmers, on the other hand, do tend to leave dead file locks lying around... -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U`
walker@sas.UUCP (Doug Walker) (08/18/89)
In article <7661@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: >In article <4148@cps3xx.UUCP> porkka@frith.UUCP (Joe Porkka) writes: >>In article <4107@sugar.hackercorp.com> karl@sugar.hackercorp.com (Karl Lehenbauer) writes: >>>In article <7570@cbmvax.UUCP>, jesup@cbmvax.UUCP (Randell Jesup) writes: >>>There is no reason a program should have to free its memory if the operating >>>system does it. Programs written for such an OS cannot be considered I disagree. Programs that rely on the OS to free their memory in the normal case probably are missing some bets that would allow them to free up some unused storage. Sure, rely on the OS to clean up after you if you abort or end early, but doing memory maintenance as-you-go generally isn't that expensive and can give better performance, even on VM systems. --Doug