Minix for the Amiga ???
Jon Wahlmann
running on an Amiga (specifically 2000). I have heard of some one having
limited success on a 1000. I would like to do some experimentation on the
implementation of such an operating system and since it may be a while before
UNIX is available to the general amiga public, I think that MINIX would be the
way to go for now. Any information would be greatly appreciated. Thanks.
Jon Wahlmann
j...@bpdsun1.uucp
jrw1...@uxa.cso.uiuc.edu
Kristian Wedberg
communication program. Trouble is, here in Sweden some folks have 75/1200
modems instead of the more normal 1200/1200.
As it is, I have no idea how to support 75/1200, or indeed, if it's at all
possible.
Altzo, is it possible to transmit 75 bit/s and receive 1200 bit/s over
the serial port? At the same time? Or would you need some kind of transformer?
wonders kitte d5k...@dtek.chalmers.se
Dave Fetrow
According to 3rd hand sources: Alpha version is up and running somewhere
in Europe and an official release should be out in a couple months.
-dave fetrow- fet...@bones.biostat.washington.edu
dfetrow@uwalocke (bitnet) {uunet}!uw-beaver!uw-entropy!fetrow
"It's 1989! I'm supposed to take a language with `cards' in it seriously?"
Jason Coughlin
68k chip does it use? Is Amiga Minix going to have the same process
switch kludge that Atari Minix has to have? How much mem can the thing
handle? Does Commodore produce a REAL hard-disk yet or do Amiga
users still suffer from Commodore peripheral kludges?
Please email responces. If there is enough interest then I'll post a
summary to these newsgroupS. No need to start an entire discussion :-).
--
Jason Coughlin
( j...@sun.soe.clarkson.edu , j...@clutx.BITNET )
--
--
Jason Coughlin
( j...@sun.soe.clarkson.edu , jk0@clutx )
Gert Kanis
>I've written a Videotex program (Prestel type) for the Amiga, a kind of
>communication program. Trouble is, here in Sweden some folks have 75/1200
>
>possible.
Problem you will have is that the rs232 port of the Amiga can only be
set to 100 baud (bits per sec. probably this time) as the LOWEST speed!
(It one of the little things the Amiga designers forgot :=) )
If you use a 75/1200 modem with an interspeeder the modem would take care
of the speed conversion. However those modems are much more expensive.
>
>Altzo, is it possible to transmit 75 bit/s and receive 1200 bit/s over
>the serial port? At the same time?
>
> wonders kitte d5k...@dtek.chalmers.se
usualy in such cases (software) switching has to be done when changing
from receiving to sending and vice versa.
+-----------------------------------------------------------------+
| The smoker you drink,| Gert Kanis, SWP |
| the W.C. | Nixdorf Computer BV, Postbus 29 |
|----------------------| 4130 EA Vianen, Netherlands. |
| I do not represent | E-mail : targon!ge...@nluug.nl |
| anyone elses opinion.| or ..!mcvax!targon!gert |
+-----------------------------------------------------------------+
Christian Balzer
In article <1989Jul13.1...@sun.soe.clarkson.edu>, j...@image.soe.clarkson.edu (Jason Coughlin) writes...
>What are the specs on the Amiga?
about the Amiga isn't a major crime, nor should it be. But going on
happily with unsubstantiated (sp?) drivel and rumors is at least a
minor one.
>Like, does it have a real MMU, which 68k chip does it use?
^^^^
I wasn't aware of anything like a "false" MMU, would you care to
enlightem me? :-)
Base Amigas (A1000, A500, A2000) come with a plain 68000 CPU and no MMU
or FPU. There are boards available for a specially designed CPU slot on
the A2000 by Commodore and third party developers, which feature
anything from a 68020/68881 combo to a 68030/68882 board with 4 MB of
onboard 32 bit wide RAM like the CBM A2630. An Amiga 2000 with this
board beats a Mac-IIx using the Dhrystone test by about 40% (very
conservative figure).
>Is Amiga Minix going to have the same process switch kludge that Atari
>Minix has to have?
I don't know nothing on Minix or the ST implementation, so I keep my
mouth shut.
It might be however of interest to you and the audience in comp.os.minix,
that the Amiga comes with a very powerfull native multitasking OS,
whose kernal functions might be helpful in the implementation of Minix.
Since the basic Amigas (see above) don't have a MMU, I can foresee
certain limitations on the elegance of such an implementation, though.
>How much mem can the thing handle?
A basic Amiga (see above) allows for up to 9.5 MB of 16 bit memory,
systems with the "right" CPU-cards can address whatever the CPU will
handle, ie. 4 GB - 16 MB of 32 bit memory plus 9.5 MB of 16 bit memory.
>Does Commodore produce a REAL hard-disk yet or do Amiga users still
^^^^---- Not again! :-)
>suffer from Commodore peripheral kludges?
This really drove me mad. First you claim to know nothing about the
Amiga (FYI, it wasn't even developed by CBM), but feel free to make
"educated" guesses judging on old CBM hardware. I _assume_ that you had
things like the C64 in mind when you wrote that statement above.
And yes, Commodore and a large number of third party developers produce
_REAL_ HD controllers, but I don't think that anyone of them
manufactures hard disks.:-) The best of those controllers with onboard
DMA deliver with drives like the CDC Wren, Maxtor XT-3380S or similar
SCSI units sustained transfer rates of 1.2 MB/s and higher.
Fast enough?
For comparison, most of the UNIX systems I used delivered data in the
500-600 KB/s range.
>Please email responces. If there is enough interest then I'll post a
>summary to these newsgroupS. No need to start an entire discussion :-).
I was thinking about being sensible and sending Email, etc. for some
time, but if there's one such uneducated being out there, chances are
there are more where that came from.
But I agree, further discussion should happen in EMail, alt.flame or
comp.sys.amiga.tech, depending on it's contents.
There's really nothing I want to see less than another stoopid(tm)
flamewar.
Regards,
- <CB>
-- _ _
/ / | \ \ <CB> aka Christian Balzer - The Software Brewery -
< < |-< > UUCP : decwrl!frambo.dec.com!CB | E-Net: FRAMBO::BALZER
\ \_ |_/ / I-Net: C...@frambo.dec.com -OR- C...@frambo.enet.dec.com
------------ PMail: Im Wingertsberg 45, D-6108 Weiterstadt, F.R.G.
Checkpoint Technologies
It's not possible to run it any slower. Secondly, the Amiga serial port
does not allow split baud rates, that is, running transmit and receive
at different speeds. The serial chip we use on our dual port serial card
allows both the 75 baud speed, and split rate operation, though the
driver we've written does not support split baud rates; and it plugs
into a Zorro slot, and I imagine you're really talking about the A500.
It's not possible to bang the bits on the Amiga serial port manually, so
I don't know how to solve your problem, sorry.
--
First comes the logo: C H E C K P O I N T T E C H N O L O G I E S / /
\\ / /
Then, the disclaimer: All expressed opinions are, indeed, factual. \ / o
Now for the witty part: I'm pink, therefore, I'm spam! \/
Andy Tanenbaum
>
> According to 3rd hand sources: Alpha version is up and running somewhere
>in Europe and an official release should be out in a couple months.
Two of my students did the port to the Amiga. They seem to have done an
excellent job, and it is now being tested. If and when there will be an
official release is another story. Neither P-H nor Commodore is interested.
I am working on that one, however.
Andy Tanenbaum
Andy Tanenbaum
>What are the specs on the Amiga? Like, does it have a real MMU,
>which 68k chip does it use? Is Amiga Minix going to have the same process
>switch kludge that Atari Minix has to have?
Yes. Without an MMU there isn't much choice. It really isn't so bad though.
>How much mem can the thing handle?
As much as you have.
>Does Commodore produce a REAL hard-disk yet or do Amiga
>users still suffer from Commodore peripheral kludges?
We don't have hard disk support. Nobody here has a hard disk.
You forgot to ask the real question: "How do you write an operating system
for a computer that doesn't have a disk controller, but watches the bits
come off the drive one at a time, in software?"
Answer: You watch the bits come off the drive one at a time, in software.
Three guesses whether the CRC is done in hardware or software. This doesn't
make it go real fast. On the other hand, it is no worse than the normal
Amiga OS, and the Amiga has other features that compensate to some degree.
Andy Tanenbaum (a...@cs.vu.nl)
Tomas G. Rokicki
about the Amiga, lest further misinformation spread . . .
> You forgot to ask the real question: "How do you write an operating system
> for a computer that doesn't have a disk controller, but watches the bits
> come off the drive one at a time, in software?"
First of all, Andy's referring to the floppies only, not hard disks.
Secondly, the Amiga does indeed have a DMA channel associated with the
floppy drives, so the processor does not watch the bits come off the
drive one at a time; the processor goes off and works on another task.
On the other hand, the bits which are loaded by DMA are pretty raw,
consisting of clock and data bits interspersed. Luckily, the blitter
can decode the MFM data quite rapidly.
The Amiga floppy drives are not slow. The organization of the file
system makes listing directories slower than other operating systems,
but makes locating and opening files somewhat faster. And were Andy
and his students to become familiar with the hard drive controllers
for the Amiga, they would be pleasantly surprised with the speed.
This is not a flame; I have a lot of respect for Andy Tanenbaum and
his work, of which Minix is a very fine example.
-tom
M}rten Norman
>
> Altzo, is it possible to transmit 75 bit/s and receive 1200 bit/s over
> the serial port? At the same time? Or would you need some kind of transformer?
As 1200/75=16 it _should_ be possible, if you are willing to fiddle with the
hardware registers. Just send 16 "1200-speed-bits" to represent a "75-bit".
The Hardware serial output register should agree with this, but i _dont_
think it's supported in standard software :-)
---
M}rten Norman EMAIL: mar...@kuling.uucp
Christian Motz
>We don't have hard disk support. Nobody here has a hard disk.
I would be interested in getting that fixed :-). Anyway, any chance
of getting my greedy little hands on the modified sources for the
Amiga? I do have an A2090A, and could probably hack up a harddisk
driver.
--
Christian Motz uucp: ...!uunet!mcvax!unido!pfm!nadia!dialog!root
"Trust me, I know what I'm doing!" -- Sledge Hammer Bix: cmotz
Randell Jesup
>>How much mem can the thing handle?
>As much as you have.
Good, then it supports the expansion auto-config? (Assigning addresses
to baords according to their requirements).
>We don't have hard disk support. Nobody here has a hard disk.
With lots of A590's being shipped to Europe, hopefully that should
change. Maybe you should get in touch with one of the European Commdore
Sales companies. They might give you a loaner, or some such (Minix being
a Good Thing :-). Disclaimer: I don't know much about how the European
parts of commodore work.
>You forgot to ask the real question: "How do you write an operating system
>for a computer that doesn't have a disk controller, but watches the bits
>come off the drive one at a time, in software?"
>Answer: You watch the bits come off the drive one at a time, in software.
>Three guesses whether the CRC is done in hardware or software. This doesn't
>make it go real fast. On the other hand, it is no worse than the normal
>Amiga OS, and the Amiga has other features that compensate to some degree.
True, but only if you want to use IBM/ST format. Amiga format is
supported directly by the hardware, and unburdens the processor from most of
the encoding/decoding work. It also stores about 20% more per disk.
Then again, the IBM/ST format means Amiga/Minix can exchange disks
with ST/Minix and IBM/Minix.
From what Dr. Tanenbaum's students told me, their disk routines
(from a cat /bin/* >/dev/null) are almost as fast as the ST (floppies spin
SO slowly).
>Andy Tanenbaum (a...@cs.vu.nl)
I hope you find a publisher.
--
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, je...@cbmvax.cbm.commodore.com BIX: rjesup
Common phrase heard at Amiga Devcon '89: "It's in there!"
Robert R. Burns
Use the serial port itself to receive 1200 baud. Wire up the transmit
to some other Amiga output and generate it yourself -- 75 baud is slow
enough to get right even with the latency noticing CIA time events.
Note that this is a comp.sys.amiga.tech reply: it requires some
programming expertise on your part :-)
- Kodiak
--
Bob Burns, amiga!kodiak _
| /_ _|. _ | Commodore __ |_) _ |_ _ )'
|<(_)(_)|(_\|< /\ | ||| _` /\ |_)(_\| )(_\ |
| \ Software ___/..\|\/|||__|/..\___ Faith
Joe Smith
>As 1200/75=16 it _should_ be possible, if you are willing to fiddle with the
>hardware registers. Just send 16 "1200-speed-bits" to represent a "75-bit".
>The Hardware serial output register should agree with this, but i _dont_
>think it's supported in standard software :-)
When you send 8 bits to an async line, the hardware sends 10 bits by
adding a start bit and a stop bit. Although one byte at 75 baud takes
the same amount of time to transmit as 16 bytes at 1200 baud (160 bit times
total), you can only specify 128 of the 160 bits. The remaining 32 bits
will screw up the receiver at the far end.
--
Joe Smith (408)922-6220 | SMTP: J...@F74.TYMNET.COM or j...@tymix.tymnet.com
McDonnell Douglas FSCO | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms
PO Box 49019, MS-D21 | PDP-10 support: My car's license plate is "POPJ P,"
San Jose, CA 95161-9019 | narrator.device: "I didn't say that, my Amiga did!"
Doug Lee
>official release is another story. Neither P-H nor Commodore is interested.
How about a release to usenet and Fred Fish.
<<<Doug Lee>>>
>Andy Tanenbaum
Doug Merritt
>In article <10...@kuling.UUCP> mar...@kuling.UUCP (M}rten Norman) writes:
>When you send 8 bits to an async line, the hardware sends 10 bits by
>adding a start bit and a stop bit. Although one byte at 75 baud takes
>the same amount of time to transmit as 16 bytes at 1200 baud (160 bit times
>total), you can only specify 128 of the 160 bits. The remaining 32 bits
>will screw up the receiver at the far end.
I would think there's a chance that they wouldn't screw it up, since
we're basically talking about what would look like a glitch in 1/16th
of the received waveform. Would depend on how the receiver hardware was
designed, wouldn't it? Might still be worth a try.
Doug
--
Doug Merritt {pyramid,apple}!xdos!doug
Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary
Eddy Carroll
Hi there,
You will find it exceedingly difficult, if not impossible, to support
75/1200 directly on the Amiga, because the Amiga does not support split
baud rates. 1200/75 on the other hand (as might be offered by a comms
package) is much easier. I wrote a routine to do just that (i.e. send at
75 baud, receive at 1200 baud) for use with the Compunet Terminal software
(Compunet is a Commodore/Atari Quantum-Link type system in the UK), to allow
people to use the cheap "dumb" modems available in the UK to access Compunet.
It works by expanding each character to be sent at 75 baud into 16 characters
which are transmitted at 1200 baud, the 16 characters being chosen to produce
as close a copy as possible of the desired 75 baud signal. It works pretty
well, and it doesn't need to access the serial hardware directly (unlike some
other methods I've seen). It should also work with any other computer that can
send consecutive bytes over the serial line with no delay.
I have a 12K file describing the theory, and giving example C code to show
how it's used. I'm about to mail it to you, but if anyone else is interested
(the reason for this reply) send me some mail to get a copy.
-- Eddy
--
Eddy Carroll ----* Genuine MUD Wizard | "You haven't lived until
INTER: ecar...@cs.tcd.ie | you've died in MUD!"
UUCP: {..uunet}!mcvax!ukc!cs.tcd.ie!csvax1!ecarroll | -- Richard Bartle
Kristian Wedberg
on the Amiga is possible, but I will outline the major ideas:
1. NO, it's not possible.
2. Well, no, but if you use the serial port for receiving and hook up
transmitting to some other port on the Amiga doing the 75-baud part,
it should work fine.
3. Use a 75/1200 modem with 1200/1200 buffering. [Ok, so you loose the part
about it being cheap, but it does work...]
4. Try just what you said: software; when transmitting, send 16 MARK-bits or
16 SPACE-bits for every real bit you want to send. Stop-bits MIGHT foul
this up, but there you are...
5. By-pass the serial.device to get rid of start/stop-bits, then as in 4.
6. As in 4, but I know, it will work like a charm!
Well, I will defenitely try the last three. First, though, I must get my hands
on one of these modems, but it shouldn't be too hard, since there are quite
a few of them here in Sweden. Again, thanks!
kitte d5k...@dtek.chalmers.se
PS
I lost a letter from somebody in Canada asking about the mentioned videotex-
program. If you'll just mail me again, I'll get back to you.
Nick Lawes
From what Dr. Tanenbaum's students told me, their disk routines
(from a cat /bin/* >/dev/null) are almost as fast as the ST (floppies spin
SO slowly).
But surely /bin is on the RAM disk, so that makes the routines rather
slow :-) Besides the ST disk drives spin at the same speed as all other
disk drives, there's nothing special about them. The slow speed is due
to the poor implementation of the BIOS. (It doesn't buffer the FATs
properly). TOS 1.4 fixes this.
A friend of mine has an Amiga... Now THERE's a strange disk system...
no real directories etc... YUCK. (No flames please, I remember the wars
of a few years back... :-) Nice hardware, shame about the firmware...
-- Nick
--
[ Nick Lawes, Systems Programmer | voice: +44 1 353 6723 ]
[ Technical Marketing, Quotnet (UK) Ltd. | email: ni...@quotnet.co.uk ]
[ 12 Norwich Street, London. EC4a 1BP | email: ..!mcvax!ukc!qtnet!nick ]
[ | ham : G8ZHR @ GB7UWS ]
Larry Phillips
>A friend of mine has an Amiga... Now THERE's a strange disk system...
>no real directories etc... YUCK. (No flames please, I remember the wars
>of a few years back... :-) Nice hardware, shame about the firmware...
A mind is such a wonderful thing to acquire. Try it. You'll like it.
-larry
--
"So what the hell are we going to do with a Sun?" - Darlene Phillips -
+-----------------------------------------------------------------------+
| // Larry Phillips |
| \X/ lphi...@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips |
| COMPUSERVE: 76703,4322 -or- 76703...@compuserve.com |
+-----------------------------------------------------------------------+
M}rten Norman
> In article <10...@kuling.UUCP> mar...@kuling.UUCP (M}rten Norman) writes:
>>As 1200/75=16 it _should_ be possible, if you are willing to fiddle with the
>>hardware registers. Just send 16 "1200-speed-bits" to represent a "75-bit".
>>The Hardware serial output register should agree with this, but i _dont_
>>think it's supported in standard software :-)
>
> When you send 8 bits to an async line, the hardware sends 10 bits by
> adding a start bit and a stop bit. Although one byte at 75 baud takes
> the same amount of time to transmit as 16 bytes at 1200 baud (160 bit times
> total), you can only specify 128 of the 160 bits. The remaining 32 bits
> will screw up the receiver at the far end.
>
You are _so_ right! I overlooked the START/STOP-bit "feature"...
Think I _should_ have done a double-check _before_ I launched some fake
hope :-)
---
M}rten Norman Email:mar...@kuling.UUCP
Doug Merritt
>A friend of mine has an Amiga... Now THERE's a strange disk system...
>no real directories etc... YUCK. (No flames please, I remember the wars
>of a few years back... :-) Nice hardware, shame about the firmware...
No flames, he says. He remembers the wars, he says.
But he starts a war by posting untrue slander. "No real directories"???
Regardless of what he thought he meant by that, it's untrue. The Amiga
has a hierarchical file system based on "real" files and "real"
directories.
Perhaps he's thinking of the "40 folder limit" bug on Atari ST's, but
there's no such problem with Amiga's. The Amiga file system is very
much like that of Unix in overall characteristics.
Or maybe he heard a distorted version of the fact that the older
file system (there's a newer, functionally compatible but optimized
"fast file system" also) was optimized for file opens, at the expense
of somewhat slow directory scans.
If so, there's a huge difference between "slow directory scans" (but
extremely fast file opens) and "no real directories".
Anyone who's been through some flame wars and still doesn't have sense
enough to check their facts before slandering someone's favorite
system deserves to have their mailbox charred by white heat.
Repeating bad-mouthing rumors is bad manners and bad sense.
Gordon W. Ross
>I've written a Videotex program (Prestel type) for the Amiga, a kind of
>communication program. Trouble is, here in Sweden some folks have 75/1200
>modems instead of the more normal 1200/1200.
>[...] is it possible to transmit 75 bit/s and receive 1200 bit/s over the
>serial port? At the same time? Or would you need some kind of transformer?
> wonders kitte d5k...@dtek.chalmers.se
Yes, it should be possible to transmit at a low speed using a
serial port capable only of matched transmit and receive rates.
The best way to do it is probably to write a special driver which
generates each bit of the 75 bps data under software control.
This is made relatively easy if the UART (Universal Asynchronous
Receiver/Transmitter) can be programmed to generate a "break" signal
of any desired length or to generate a "continuous break" until
software tells it otherwise. Most UART's can do this.
A software driver would have to handle timing for the 75 bps output
and generate a "break" of the correct length for each zero bit
to be transmitted (the start bit is also a zero bit).
If the UART cannot generate "break" signals as described above,
one could use some other, controllable output signal for the TD
(Transmitted Data) line to the modem. A special, non-standard cable
would be required to connect (for example) DTR to the modem TD pin.
Again the driver software would have to handle the timing and
generation of each bit in the 75 bps transmitted data, and would
generate the transmitted data on the (for example) DTR line.
Are these dual-rate modems very common?
Gordon W. Ross g...@gomez.mitre.org (617) 271-3205 (daytime)
The MITRE Corp. (M/S E025) Burlington Road, Bedford, MA 01730
Deven T. Corzine
*sigh* Here I go again.
On 1 Aug 89 12:54:54 GMT,
lof...@titan.tsd.arlut.utexas.edu (Bernie Lofaso) said:
In article <1...@VAX1.CC.UAKRON.EDU>, ben...@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: de...@rpi.edu, sha...@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.
Marco Papa
>
>{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!pa...@oberon.usc.edu
"There's Alpha, Beta, Gamma, Diga and Caligari!" -- Rick Unland
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Deven T. Corzine
On 2 Aug 89 16:45:50 GMT, pa...@pollux.usc.edu (Marco Papa) said:
In article <SHADOW.89...@pawl.rpi.edu> sha...@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*]
Vidhyanath K. Rao
>On 1 Aug 89 12:54:54 GMT,
>lof...@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. v...@osupyr.mps.ohio-state.edu
-Poincare. (614)-366-9341
Marco Papa
In article <SHADOW.89...@pawl.rpi.edu| sha...@pawl.rpi.edu (Deven T. Corzine) writes:
|On 2 Aug 89 16:45:50 GMT, pa...@pollux.usc.edu (Marco Papa) said:
|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.
Deven T. Corzine
On 2 Aug 89 18:26:15 GMT,
v...@osupyr.mps.ohio-state.edu (Vidhyanath K. Rao) said:
In article <SHADOW.89...@pawl.rpi.edu>
sha...@pawl.rpi.edu (Deven T. Corzine) writes:
On 1 Aug 89 12:54:54 GMT,
lof...@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.]
Claudio Nieder
oscilloscope and attached it to that Amiga to see how the 1200/75 bps are
produced there. What that program does is, it produces from every
character a stream of character in such way, that when you send them
out at 1200 bps it will result in a waveform very similar to that
required by a 75 bps output. Of course there remain some spikes, because
the start and stop bits are not under the programmers control, but
probably they don't disturb, or you can filter them out.
claudio
Deven T. Corzine
On 2 Aug 89 18:45:14 GMT, pa...@pollux.usc.edu (Marco Papa) said:
In article <SHADOW.89...@pawl.rpi.edu| sha...@pawl.rpi.edu
(Deven T. Corzine) writes:
On 2 Aug 89 16:45:50 GMT, pa...@pollux.usc.edu (Marco Papa) said:
Marco> And, by the way, try to use less derogatory language, thank
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...
Mike (I'll think of something yet) Meyer
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? m...@berkeley.edu
How did you get your mind ucbvax!mwm
To tilt like your hat? m...@ucbjade.BITNET
Randell Jesup
>In article <SHADOW.89...@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.
Tom Limoncelli
operating system has it's good points and bad points?
Damn. That blows my whole weekend.
-Tom
:-)
--
Tom Limoncelli -- tlim...@drunivac.Bitnet -- lim...@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?
Jim Mackraz
)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.
Marco Papa
>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 ... :^)
Ade Lovett
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..
aDe
Hans Zuidam
ji...@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: ha...@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 file owner
>
>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 j...@frith.cl.msu.edu
Bernie Lofaso
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 da Silva
> 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 pe...@sugar.hackercorp.com 'U`
Vidhyanath K. Rao
--
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
--
Fidonet: Deven T. Corzine via 1:363/9
Internet: Deven.T..Corzine@mamab.FIDONET.ORG
Usenet: ...!peora!rtmvax!libcmp!mamab!Deven.T..Corzine
Valentin Pepelea
>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.
I don't know what propted you to insult an individual on the net like this.
As a regular in here, I have not seen any poster from Deven which could draw
such personal insults from you.
If you insist in sending such abusing messages, I suggest you do so through
E-mail. I am tired of seeing puerile posters like yours scrolling under my
nose.
Valentin
_________________________________________________________________________
"An operating system without Name: Valentin Pepelea
virtual memory is an operating Phonet: (613) 231-7476
system without virtue." Bitnet: 451...@Uottawa.bitnet
Usenet: Use cunyvm.cuny.edu gate
- Ancient Inca Proverb Planet: 451...@acadvm1.UOttawa.CA
Deven T. Corzine
Deven> *sigh* Here I go again.
On 3 Aug 89 00:38:07 GMT,
m...@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)?
Tom Limoncelli
--
Fidonet: Tom Limoncelli via 1:363/9
Internet: Tom.Lim...@mamab.FIDONET.ORG
Usenet: ...!peora!rtmvax!libcmp!mamab!Tom.Limoncelli
Deven T. Corzine
On 4 Aug 89 13:33:23 GMT,
lof...@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 T. Corzine
Deven> AmigaDOS? More elegant than Unix? Don't make me laugh.
In article <26...@agate.BERKELEY.EDU>, m...@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,
pe...@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.
Mike (I'll think of something yet) Meyer
<In article <SHADOW.89...@pawl.rpi.edu> sha...@pawl.rpi.edu
<(Deven T. Corzine) writes:
<
<Deven> *sigh* Here I go again.
<
<On 3 Aug 89 00:38:07 GMT,
<m...@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. m...@berkeley.edu
The currency we've spent, ucbvax!mwm
I love you. You pay my rent. m...@ucbjade.BITNET
Michael Sinz - CATS
>>
>>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!" |
\----------------------------------------------------------------------/
0040;0000002347;0;250;143;
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 |ez00...@pollux.ucdavis.edu | |\ < < | \/
|________________________|____________________________| \ \___// / Quark!
"Let them eat Spam!" - Marie Antoinspam \________/ QUARK!
Deven T. Corzine
On 7 Aug 89 10:07:34 GMT,
m...@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.
Richard Czegledi
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
George Robbins
> 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
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!g...@uunet.uu.net
Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
Randell Jesup
>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.
Doug Merritt
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
Steve Warren
>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; swa...@convex.COM
Deven T. Corzine
On 5 Aug 89 17:01:09 GMT, in articles
<154.24...@mamab.FIDONET.ORG>, <154.24...@mamab.FIDONET.ORG> and
<154.2...@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.24...@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.
Eric J. Kennedy
<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
ej...@cisunx.UUCP
Theo Deraadt
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
Randell Jesup
In article <4...@xdos.UUCP> do...@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.
Deven T. Corzine
On 8 Aug 89 15:44:03 GMT,
do...@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.]
Hans Zuidam
je...@cbmvax.UUCP (Randell Jesup) writes:
>In article <4...@xdos.UUCP> do...@xdos.UUCP (Doug Merritt) writes:
>>... Cut and paste is supported in vi in a way painful to vi-novices
> 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.
Just for your (and other peoples') curiosity:
When vi switches files it throws away its delete and undo buffers.
Therefore you have to yank a piece of text to a named buffer, switch
files and put it back from the named buffer. So:
[file a] "ayw Yank the current word to buffer 'a'
:n^M Next file
[file b] "ap Put the text from buffer 'a'
Note that the 'w' is a text selector. Thus you can also use '2w' for
'two words', '/regexp' for everything upto 'regexp', '2j' for 'this
and the next two lines' and so on.
Last week Maarten Litmaath posted a handy reference chart to comp.editors
msgid <29...@solo12.cs.vu.nl> dated august 1. Included is (was?) a nice
tutorial on writing macros. I can mail you a copy if you like ;-).
Hans
Checkpoint Technologies
>
> 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.
>
Well let me register myself as one who really wants resource
tracking, complete and unabridged. By this I mean more than memory
protection, I mean the ability to have a process fault and the system
clean up all the resources it held at the time - file locks, semaphores,
allocated memory, windows, screens, devices... everything. And then the
system continues to run. This is what I mean by resource tracking. To
me, memory protection is just a way to decide *when* to fault a program
(when it treads on unowned memory), just as would an illegal instruction
trap or address error.
--
First comes the logo: C H E C K P O I N T T E C H N O L O G I E S / /
\\ / /
Then, the disclaimer: All expressed opinions are, indeed, opinions. \ / o
Now for the witty part: I'm pink, therefore, I'm spam! \/
Doug Merritt
>>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? :-)
Yes, ps effectively goes rooting around in the kernel, so in a sense
Unix commits the same sin on that one subject. But aside from it (and
its newer brothers like renice), that's the only exception. In almost
all other ways, Unix very consistently treats everything like a file.
And even with ps, Unix is nominally within the boundaries of that
consistency, for it reads a symbol table from a file (/unix or /vmunix)
to find the offsets in files of what it wants (/dev/mem and /dev/kmem).
There is no poking directly around in memory. I agree that this is a
grey area and that it is inelegant on an absolute scale, but it is
relatively elegant compared with the AmigaDOS method of directly accessing
device/task data structures in your address space without any benefit
of any consistency metaphor.
Both Unix and AmigaDOS would benefit from extensions that put the
list of tasks (apparently) into a directory where they could be listed
(and perhaps deleted, etc) using standard utilities. Unlike AmigaDOS, this
ability *is* about to appear in a mainstream Unix: V5.4.
Another easy example is kernel patches on disk. With Unix you can patch
a file, /vmunix. Under AmigaDOS there's no supporting metaphor, you have
to patch absolute disk locations. Much as Unix'es metaphor of a file
is derided, it has many advantages over most other operating systems
that do not have *any* consistent metaphor. AmigaDOS's areas of superiority
over Unix would be far more overwhelming if it did have such a *consistent*
metaphor, regardless of what it was.
Everyone always says, well, it *could* be better than Unix in that area
too...such-and-such *could* be accessible from the CLI rather than being
accessible only to programs. But the lesson from history (of Unix) that
is most important, yet most widely disregarded, is that it *is* consistent,
and the user *can* do all that stuff from the command line, and that
all those utilities *do* behave well e.g. with piped input/output.
Unix has, compared with everything but the Smalltalk kernel, the greatest
degree of consistency of application of its underlying metaphor, and that
*inherently* makes it more powerful *overall* than any system with a
lesser consistency. Don't even bother to criticize it until you've got
a system that beats it in this respect. If you can set up message passing
ports between tasks purely via the CLI in AmigaDOS, and if all standard
utilities support this, then you've got something that might start making
Unix look like a toy. But meanwhile, pretending that e.g. AmigaDos is
*already* far better than Unix simply prevents learning from history.
To update Wirth:
(standard data-protocol utilities) + (universal CLI-configurable IPC) > programs
In other words the combination of the first two usually supercedes the
need for writing programs. By now I would hope that everyone has noticed
that this is an emerging metaphor of software design for the 90's.
Richard A. Champeaux
>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.
>
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 (rac...@mbunix.mitre.org)
Peter da Silva
> In article <40...@sugar.hackercorp.com> pe...@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 pe...@sugar.hackercorp.com 'U`
Charles Cleveland
)In article <154.24...@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: ch...@gtss.gatech.edu
Stanley Chow
>all other ways, Unix very consistently treats everything like a file.
It is not clear (at least to me) that this is a good thing. Why do you
want everything to look like a file? A file has a very limiting structure.
Why would you want to force complicated data structure into a file? I think
appropiate use of linked data structure is entirely correct.
>
>And even with ps, Unix is nominally within the boundaries of that
>consistency, for it reads a symbol table from a file (/unix or /vmunix)
>to find the offsets in files of what it wants (/dev/mem and /dev/kmem).
>There is no poking directly around in memory. I agree that this is a
>grey area and that it is inelegant on an absolute scale, but it is
>relatively elegant compared with the AmigaDOS method of directly accessing
>device/task data structures in your address space without any benefit
>of any consistency metaphor.
^^^^^^^^
This is perhaps the key. I look on metaphor as an aid to learning something.
Once I know the subject, *it* becomes the metaphor for learning something
else. Why is it good to tie everything forever to a bad metaphor (files)?
>
>Both Unix and AmigaDOS would benefit from extensions that put the
>list of tasks (apparently) into a directory where they could be listed
>(and perhaps deleted, etc) using standard utilities. Unlike AmigaDOS, this
>ability *is* about to appear in a mainstream Unix: V5.4.
Again, my question: why should deleting a task be the same as deleting an
entry from a directory? The code gets more complicated since the delete
command now must know to call the delete-task routine. The user still has to
know that a task is involved so there is no hope of 'undo'.
Perhaps what you want is a 'consistant' interface where command names and
syntax for different commands follow a consistant convention. This is
very differnt from having the 'same' command do it in the same way.
> [...] But the lesson from history (of Unix) that
>is most important, yet most widely disregarded, is that it *is* consistent,
>and the user *can* do all that stuff from the command line, and that
>all those utilities *do* behave well e.g. with piped input/output.
Not meaning to start another Unix flame war, but I think you mean that *you*
have found *a set* of utilities that fit well together with *your* style of
computer usage. The default set(s) of utilities from the variouse vendors
are by no means 'consistant'. Including all the freebies and bought S/W in
any description of 'consistant' is at best inconsistant.
>
>Unix has, compared with everything but the Smalltalk kernel, the greatest
>degree of consistency of application of its underlying metaphor, and that
>*inherently* makes it more powerful *overall* than any system with a
>lesser consistency. Don't even bother to criticize it until you've got
>a system that beats it in this respect. If you can set up message passing
>ports between tasks purely via the CLI in AmigaDOS, and if all standard
>utilities support this, then you've got something that might start making
>Unix look like a toy. But meanwhile, pretending that e.g. AmigaDos is
>*already* far better than Unix simply prevents learning from history.
>
I know almost nothing about any Unix-type kernal, so I cannot comment on the
kernal internals. I do, however have strong views about the consistancy
as seen by the *user*. In my view, Mac is more consistant than Amiga and
Amiga is more consistant than Unix.
Stanley Chow BitNet: sc...@BNR.CA
BNR UUCP: ..!psuvax1!BNR.CA.bitnet!schow
(613) 763-2831 ..!utgpu!bnr-vpa!bnr-fos!schow%bnr-public
Me? Represent other people? Don't make them laugh so hard.
Doug Merritt
was surprised:
In article <SHADOW.89...@pawl.rpi.edu> sha...@pawl.rpi.edu (Deven T. Corzine) writes:
>*That* I find hard to believe. GNU Emacs has not only query-replace
>(a very nice function) but also query-replace-regexp.
Correction, I was wrong. I hadn't used any version of emacs very much
since about 1981 or so; I speaking on the basis of conversations with emacs
fans. Turns out I was misinformed. GNU emacs adopted all of vi's regular
expression features, plus egrep alternation, long ago (and yes, vi was
the influence). I found this out when I actually checked the GNU Emacs Manual
this morning.
I disagree with the default bindings (no default binding backward search),
but what else is new...easy enough to customize.
> [A regexp I-search would be pretty incredible...]
The manual says it's supported: "isearch-forward-regexp".
So given that, only my conditioned reflexes stand in the way of my
switching, and I've been trying to talk myself into taking the hit
for about a year now. Someday soon...Hmmm. I wonder if any of the
Amiga Emacs' support as full a regexp set as full Gnu Emacs?
Charles Brown
>> 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 cha...@cv.hp.com or charles%hpc...@hplabs.hp.com
or hplabs!hpcvca!charles or "Hey you!"
Not representing my employer.
Deven T. Corzine
On 10 Aug 89 13:43:16 GMT,
ch...@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 T. Corzine
On 10 Aug 89 19:26:08 GMT,
do...@xdos.UUCP (Doug Merritt) said:
Doug> Summary: Oops! I was wrong.
Doug> I had said that vi's global search-and-replace surpasses emacs. Deven
Doug> was surprised:
In article <SHADOW.89...@pawl.rpi.edu> sha...@pawl.rpi.edu
(Deven T. Corzine) writes:
Deven> *That* I find hard to believe. GNU Emacs has not only
Deven> query-replace (a very nice function) but also
Deven> query-replace-regexp.
Doug> Correction, I was wrong. I hadn't used any version of emacs very
Doug> much since about 1981 or so; I speaking on the basis of
Doug> conversations with emacs fans. Turns out I was misinformed. GNU
Doug> emacs adopted all of vi's regular expression features, plus
Doug> egrep alternation, long ago (and yes, vi was the influence). I
Doug> found this out when I actually checked the GNU Emacs Manual this
Doug> morning.
The one particular bit about vi regexps I had pointed out to me was the
substitution of text which matched certain parts of the searching
regexp when doing a replace. Whether GNU Emacs has this when you do a
query-replace-regexp, I don't know. [quite possibly] Certainly, it
is quite capable of it.
Doug> I disagree with the default bindings (no default binding
Doug> backward search), but what else is new...easy enough to
Doug> customize.
C-r [control-r] is normally bound to isearch-backward.
Deven> [A regexp I-search would be pretty incredible...]
Doug> The manual says it's supported: "isearch-forward-regexp".
Indeed. Someone Emailed and pointed that out to me. I had thought I
had looked, but if I did, it must have been long ago when I had no
clue how to effectively search within Emacs for a specific
functionality...
And yes, a Regexp I-Search is very neat...
Doug> So given that, only my conditioned reflexes stand in the way of
Doug> my switching, and I've been trying to talk myself into taking
Doug> the hit for about a year now. Someday soon...
Yeah, it took me about a year to switch to Emacs from vi... but it
was well worth it. (Now, I mess myself up if I try to use vi... my
reflexes are now conditioned for Emacs.)
For an intermediate step, check out vip-mode... it's a major mode in
Emacs which emulates (closely) vi... to start it, type M-x vip-mode.
[M-x is Meta-x, Alt-x or Esc-x as appropriate.] There is also
"vi-mode", but it is not as close emulation of vi.
Doug> Hmmm. I wonder if any of the Amiga Emacs' support as full a
Doug> regexp set as full Gnu Emacs?
I should hope so. Maybe in mg3a, Mike? ;-)
Richard Czegledi
give the amiga the ability to put 'files' under 'files'. Waterloo Port
does something like that.
It could function just like a directory, but could contain a text file.
If something like this was implemnted, it could really clean up our
directories. No more 'read.me read.me1st dist' etc.. files. Some of them
could act like the directory, and have the files they refer to 'underneath'
them. Also, .info files wouldn't clutter up the directories anymore.
.info files could be placed under their executables, and when you wish
to copy the file, you just do a normal copy, and the .info file will
go with it.
All little files that are support files for the executable could also
be contained underneath the executable. This would mean that instaling
programs and copying certain things to certain directories would essentialy
become pointless, and from a user standpoint, the system would be simpler
to understand. If you did a dir, you could have a display like this:
+ise JRCOMM +ie Preferences (or something like that)
That would mean that the file JRCOMM is an executable, has support files
under it, and has an info file for workbench. Preferences is an executable
has info files for workbench, but doesn't requrie support files.
It would make the amiga much simpler to maintain, give it prettier un-
cluttered directories. And if wb1.4 decides to let the user list files
by text (instead of just icons), you could have a little icon beside the
filename, indicating what, if anything is underneath it.
possibilities possibilities possibilities!
e
Tomas G. Rokicki
> 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
George Robbins
> >> 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.
>
> 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...
Randell Jesup
>> 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.
Philip E Staub
>In article <4...@xdos.UUCP> do...@xdos.UUCP (Doug Merritt) writes:
>>
>>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 (rac...@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, ph...@tekigm2.MEN.TEK.COM
Definition: BUG: A feature (present or absent) which is (at best) inconvenient.
Marc Plumb
> 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 Lehenbauer
> 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 Lehenbauer
> 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.)
Karl Lehenbauer
> Tell me what vi's got that GNU Emacs hasn't...
Uh, a version for AmigaDOS?
Deven T. Corzine
Deven> Tell me what vi's got that GNU Emacs hasn't...
On 12 Aug 89 19:25:55 GMT,
ka...@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 T. Corzine
On 11 Aug 89 16:09:41 GMT,
rtcze...@crocus.waterloo.edu (Richard Czegledi) said:
Richard> Something that I feel would be very useful (not to mention
Richard> nice) is to give the amiga the ability to put 'files' under
Richard> 'files'. Waterloo Port does something like that.
4 months ago, I posted to comp.sys.amiga.tech about this very idea,
albeit somewhat more thought out. I'm afraid I don't have a copy of
the article I posted; only replies to it. (I have all articles I've
posted since 6/28/89.) The article I posted was "Subject: An
IFF-based filesystem?", posted to comp.sys.amiga.tech, message ID
<SHADOW.89A...@pawl20.pawl.rpi.edu>. If anyone has a copy of
the article, please email it to me?
Part of what I wrote: [was included in a reply]
Deven> I've got an idea to bounce off the net here... In considering
Deven> design and implementation of a file system for Amigix, I have
Deven> been contemplating the idea of designing a filesystem which is
Deven> structurally similar to Unix, but which has library support for
Deven> manipulating IFF files, and which actually uses IFF files for
Deven> object files, executables and any other filesystem-specific
Deven> formats.
I went on to describe how documentation, manual pages, readme files,
icons, startup screens, etc. could all be imbedded in the same file as
the executable.
Also:
In article <1149.AA1149@geo-works> br...@geo-works.UUCP
(Bryan Ford) writes:
Bryan> Good idea. Too bad the Amiga's executable file formats aren't
Bryan> forward compatible like IFF. Hmmm...I wonder if it would be
Bryan> feasible to create a new executable file format that uses an
Bryan> IFF standard for executables. Maybe 'X68K'? Who knows.
Bryan> Probably wouldn't be practical, unless C-A is planning to put
Bryan> IFF stuff in ROM.
In <SHADOW.89J...@pawl.rpi.edu> on 6/27/89, I wrote:
Deven> This is exactly the idea I have been contemplating using for
Deven> the standard executable format for Amigix. (Amigix is a
Deven> (major) project based in part on implementing Unix V7 on the
Deven> Amiga... Email for more info, or check comp.sys.amiga.tech if
Deven> the old threads haven't expired.)
Deven> The idea is you could put other things, like an icon, startup
Deven> screen, the actual source code, stack size, whatever, all with
Deven> the binary. It could be a very flexible format. I haven't had
Deven> time to work extensively on it, however. :-(
Deven> As for putting it in ROM, the amigix.library (containing IFF
Deven> support code and loader, along with Unix syscalls and other
Deven> stuff) would be in RAM, but shared, so it could do well
Deven> enough... thoughts/comments?
Bryan> Oh well, nice idea while it lasted...
Deven> Oh, it's still a nice idea... I haven't dropped it yet.
It's a good idea, which I've thought a lot about. I wish I had the
time and resources to *do* something about it... Someday...
Richard Czegledi
>
>On 11 Aug 89 16:09:41 GMT,
>rtcze...@crocus.waterloo.edu (Richard Czegledi) said:
>
>Richard> Something that I feel would be very useful (not to mention
>Richard> nice) is to give the amiga the ability to put 'files' under
>Richard> 'files'. Waterloo Port does something like that.
>
>4 months ago, I posted to comp.sys.amiga.tech about this very idea,
>albeit somewhat more thought out. I'm afraid I don't have a copy of
>the article I posted; only replies to it. (I have all articles I've
>posted since 6/28/89.) The article I posted was "Subject: An
>IFF-based filesystem?", posted to comp.sys.amiga.tech, message ID
><SHADOW.89A...@pawl20.pawl.rpi.edu>. If anyone has a copy of
>the article, please email it to me?
I can think of a few problems with your idea. Most are 'how 'ard is it to
implement and have work effectively' type. The main drawback to your
iff based file system is that the executable will have to modify itself,
thereby messing up many resident/ares/rez type programs.
Also, every single last program for the amiga will essentialy have to be
re-written. Now, if I left it at that, you would mail me saying,
"it would all be handled by the os, and transparent to the software".
But what about software like the (which I can not live without) disksalv,
and things like BAD (I like it), which think they 'know' about the file
systems. They will probably have to go. And the size/complexity of the OS
might just be too much to handle.
With a simple files under files approach like I mentioned, the os would not
have to be significantly changed. A file could be treated like a directory,
and you could directly load files/under the main file.
It's sort of like directories being files as well. The advantages would
be numerous. Hard drive maintenance, software instalation, and the general
look of the system would be pretty great.
When you mention, 'my system was a lot more thought out than yours', you
obviously did more thinking about your method (which is neat, cool, and
rather boffo, but tough to implement). The system I'm refering to
is already sort of implemented in other operating systems. It would offer
about the same functionality as your system too (I think). Also, I have
used this files under files approach, and find it to be quite flexable
powerful, and fun.
Usenet file owner
>In article <75...@cbmvax.UUCP>, je...@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 j...@frith.cl.msu.edu
Darin Johnson
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!da...@pyramid.pyramid.com)
We now return you to your regularly scheduled program.
Chuck McManis
> 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.
Rewriting malloc to be faster is an old game, lots of people play. This whole
bit about memory usage and calls are a religious argument but the two sides
can be pretty clearly defined :
The Package Argument : I use a memory management package that keeps track of
what I allocate and free, when I exit the program I call the deallocate
everything entry point and everything gets freed. I like this because
I don't have to worry about what is and isn't freed.
The System Call Argument : I use the system calls for allocating and freeing
memory because I want to be absolutely sure I'm only using the memory
I need, and don't like the overhead of memory management packages.
I have to write some extra code in my exit routine to make sure I've
taken care everything but the benefit is extra flexibility.
Both are valid arguments, and they often depend on what you are trying to do.
I tend to use a mixture because of the way in which the Amiga must have Chip
ram for some things and my programs tend to build gadgetry and such on the
fly.
> 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.)
This, on the other hand, is specious. If one writes a subroutine that has a
memory leak then that is a bug in any system. If you are building data
structures and returning them to your client that's one thing, but losing
memory is just a bug.
> As you might guess, I'm not a big fan of garbage collection.
>--
>Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
You're comment implies that memory management packages have to be large
cumbersome beasts that lose memory and must be scavenged periodically to
defragment them. This is demonstrably untrue, so you must mean something
else. The true advantage to memory management packages over system calls
is that one can port them, and then all of your code works, rather than
having to go into the code and find all occurrances of AllocMem() or what
have you. In the case of malloc/free it just happens to be a defacto
standard package because it works that way on UNIX. That means that you
might not even have to port it when you get to the destination, and that
saves time and energy.
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcm...@sun.com
These opinions are my own and no one elses, but you knew that didn't you.
"A most excellent barbarian ... Genghis Kahn!"
Randell Jesup
>In article <41...@sugar.hackercorp.com> ka...@sugar.hackercorp.com (Karl Lehenbauer) writes:
>>In article <75...@cbmvax.UUCP>, je...@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.
Randell Jesup
>Rewriting malloc to be faster is an old game, lots of people play. This whole
>bit about memory usage and calls are a religious argument but the two sides
>can be pretty clearly defined :
>
>The Package Argument : I use a memory management package that keeps track of
>The System Call Argument : I use the system calls for allocating and freeing
Quite true (btw, my replacement gave both: smaller and faster than
malloc, and it released everything for me if I hadn't when I exited.)
>>if it drops memory every time it can add up quickly.)
>
>This, on the other hand, is specious. If one writes a subroutine that has a
>memory leak then that is a bug in any system. If you are building data
>structures and returning them to your client that's one thing, but losing
>memory is just a bug.
Maybe, but I've seen LARGE professional systems that do this.
Admittedly, some of the people who do this are used to systems that garbage
collect for them. For example, to quote from the Ada green reference manual
(old, but all I have on me):
"An object created by the execution of an allocator remains allocated
for as long as this object is accessible directly or indirectly,
that is, as long as it can be designated by some name. When such an
object becomes inaccessible, the storage it occupies can be reclaimed
(but need not be), depending on implementation."
page 4-23, section 4.8
Ada has NO way to free allocated memory. BTW, I haven't seen an
Ada compiler that did garbage collection yet (though having said that, I'm
sure someone will point out that I'm wrong.) Can you say "VM Hog"? better
learn if you run Ada.
I believe (though I'm more likely to be wrong here) that LISPM's
have the same sort of problem, when programmed in lisp (though they do have
garbage collectors, and they make themselves known frequently.)
--
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
Francois Kuan
working great except for a few things that I haven't been quite able
to figure out yet. Sometimes when you use the p and ps commands
to print the values of arrays and strings, it seems to chop it off
prematurely.
Does anyone know exactly why it does this? Is there any way I can
avoid that? I suspect that it stops printing an array (of shorts
or whatever) as soon as it finds a 0, but I'm not sure. What can I
do to fix it?
______________________________________________________ Quantum _\/_
| 545 Sycamore Suite 207 |Frank Kuan | |\ Duck ( 0 0)
| Davis, Ca 95616 |Quantum Duck Software, | |\ \______/ / \\\
| 916-757-2925 |ku...@iris.ucdavis.edu | |\ < < | \/
|________________________|____________________________| \ \___// / Quark!
"The game is in the refrigerator, the butter's getting \___ ___//
hard, the eggs are cooling, and the lights are out." - Chicky Baby
Peter da Silva
> 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...
Doug Walker
>>In article <41...@sugar.hackercorp.com> ka...@sugar.hackercorp.com (Karl Lehenbauer) writes:
>>>In article <75...@cbmvax.UUCP>, je...@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
Dana B Bourgeois
other computer can do. Let's get this straight right now.
However, it is also true that the stock Amiga can be quickly and easily
upgraded into a very friendly and easy to use machine with PD and
commercial software, with more ram and with more hardware.
There are those who are unhappy with the stock Amiga. They feel many
of the utilities available from third parties should come standard with
the machine. And these feelings are shared by the large number of
programmers who create those utilities and the large number of users
who utilize them (like me! :> ).
So lets avoid name-calling and loaded words. You got a gripe, send it
out as a flame. You got a suggestion or a question or a report or some
news then put it here. And you can always send email to CATS.
Dana
Deven T. Corzine
On 17 Aug 89 20:12:30 GMT, Felin...@cup.portal.com (Dana B Bourgeois) said:
Dana> It is *not* true that a stock Amiga cannot be used to do any job
Dana> any other computer can do. Let's get this straight right now.
The stock Amiga has strikingly limited command-line functionality when
compared to a Unix system. To a large degree, that CAN be remedied,
yes.
Dana> However, it is also true that the stock Amiga can be quickly and
Dana> easily upgraded into a very friendly and easy to use machine
Dana> with PD and commercial software, with more ram and with more
Dana> hardware.
Not always a "quick and easy" proposition, but certainly doable.
Dana> Dana
Deven T. Corzine
Richard> Something that I feel would be very useful (not to mention
Richard> nice) is to give the amiga the ability to put 'files' under
Richard> 'files'. Waterloo Port does something like that.
Deven> 4 months ago, I posted to comp.sys.amiga.tech about this very
Deven> idea, albeit somewhat more thought out. I'm afraid I don't
Deven> have a copy of the article I posted; only replies to it. (I
Deven> have all articles I've posted since 6/28/89.) The article I
Deven> posted was "Subject: An IFF-based filesystem?", posted to
Deven> comp.sys.amiga.tech, message ID
Deven> <SHADOW.89A...@pawl20.pawl.rpi.edu>. If anyone has a
Deven> copy of the article, please email it to me?
Richard> I can think of a few problems with your idea. Most are 'how
Richard> 'ard is it to implement and have work effectively' type. The
Richard> main drawback to your iff based file system is that the
Richard> executable will have to modify itself, thereby messing up
Richard> many resident/ares/rez type programs.
No, you misunderstood. The *loader* will use a different format than
LoadSeg() does, but it would be able to be loaded and installed in a
resident list. (maybe not with the Resident and Ares programs
specifically, but you would be able to do it.)
Richard> Also, every single last program for the amiga will essentialy
Richard> have to be re-written. Now, if I left it at that, you would
Richard> mail me saying, "it would all be handled by the os, and
Richard> transparent to the software".
True. :-)
Richard> But what about software like the (which I can not live
Richard> without) disksalv, and things like BAD (I like it), which
Richard> think they 'know' about the file systems. They will probably
Richard> have to go.
They could still be used on AmigaDOS disks. I would probably write a
utility similar to disksalv, (and also an undelete utility) and I have
no idea what BAD does.
Richard> And the size/complexity of the OS might just be too much to
Richard> handle.
An unknown, but it doesn't seem like it would need to be too bad.
Richard> With a simple files under files approach like I mentioned,
Richard> the os would not have to be significantly changed. A file
Richard> could be treated like a directory, and you could directly
Richard> load files/under the main file.
I'm already looking at rewriting major pieces of the OS.
Richard> It's sort of like directories being files as well. The
Richard> advantages would be numerous. Hard drive maintenance,
Richard> software instalation, and the general look of the system
Richard> would be pretty great.
I've also considered the approach of all filesystem objects being both
files and directories. How to integrate it, I'm not sure. If you do
a cp, does it only copy the file portion, or the file and the entire
directory subtree? Should rm act on the file or both? etc.
Richard> When you mention, 'my system was a lot more thought out than
Richard> yours', you obviously did more thinking about your method
Richard> (which is neat, cool, and rather boffo, but tough to
Richard> implement). The system I'm refering to is already sort of
Richard> implemented in other operating systems. It would offer about
Richard> the same functionality as your system too (I think). Also, I
Richard> have used this files under files approach, and find it to be
Richard> quite flexable powerful, and fun.
IFF is recursive. Any IFF file can be a part of another. IFF is
already somewhat established as a standard file format on the Amiga,
and integrating that at the system level could help promote that. It
is an excellent format, well thought out and well executed. And it
can be extended beyond graphics and sound...
Kent Paul Dolan
omitted in the interests of retaining sanity.]
Computer science hasn't stopped progressing just because Unix(tm) was
invented. The plaudits for the Unix "file" metaphor are not meant to
denigrate later developments, but to compare it to the systems existing
when Unix was created.
If you go back and look at the '60's operating systems (OS 360, GCOS, etc.),
you find that the OS was responsible for knowing the structure of the
bytes in a file. The result was the JCL nightmares of fixed, varying, varying
spanned, and so on record structures, each of which was built into the OS,
and all of which had to be describable by the system user in JCL.
The glory of Unix is the realization that the OS has no business knowing the
internal structure of a file; a file is just a stream of bytes. It is the
responsibility of the program accessing those bytes to interpret some
structure into them.
This paradigm, mapped to devices, allowed a console to be treated as a file
too, since all that ever goes to or from it is also a stream of bytes.
Most subsequent progress has been built on the base furnished by Unix of
making the OS (relatively) smaller, simpler and cleaner, since it only
has to deal with one file type, the stream of bytes.
Of course, within it's own files, the OS knows the structure, but it is
amazing how much of other OS's internal code became separate, non-OS
programs under Unix.
Somewhere in there, the idea of bundling the process and its data became
the concept of an abstract data type so dear to the object oriented
programmers of today.
Not too scruffy from a beginning of "keep it simple, stupid." ;-)
well!xanthian
Kent, the man from xanth, now just another echo from The Well.
Robert Eachus
>If you go back and look at the '60's operating systems (OS 360, GCOS, etc.),
>you find that the OS was responsible for knowing the structure of the
>bytes in a file. The result was the JCL nightmares of fixed, varying, varying
>spanned, and so on record structures, each of which was built into the OS,
>and all of which had to be describable by the system user in JCL.
>The glory of Unix is the realization that the OS has no business knowing the
>internal structure of a file; a file is just a stream of bytes. It is the
>responsibility of the program accessing those bytes to interpret some
>structure into them....
If the idea of "unstructured" files came originally from Unix, or
if the reason that Unix originally treated files the way it does had
anything to do with your reasons, or if the files in Unix were "just a
stream of bytes", I probably wouldn't have commented. But...THAT
ISN'T THE WAY IT HAPPENED, THAT ISN'T WHY IT HAPPENDED, and finally
THAT ISN'T WHAT FILES ARE IN UNIX! Please don't rewrite history,
especially where it is important like here!
Unix was written to be a small single user system by people
who had been part of the Multics effort before Bell Labs pulled out.
One of the key principles of Multics was that there was no distinction
between disk (or originally drum) files and main memory (back then
core). Dynamic linking, segment tables, snapping of links, packed
pointers and unpacked pointers, and a hierarchical memory structure
were all tools devloped to make that user abstraction work. (There
were other principles, and other innovations to support them, involved
in the design of Multics, but that is another story.)
Multics users (and at that time all such users were developers)
quickly became used to the programming paradigm that the way to change
a file was to operate on it in random access fashion, in memory. The
fact that Multics used demand paged virtual memory to make that
efficient in all cases was hidden. (Maybe that wasn't entirely
another story. :-)
The developers of Unix wanted to work in the same fashion, and
having internal structure to files was an unnecessary nuisance. So
the file system was designed so that the internal structure of files
was hidden from the users. (But files had structure, and programmers
needed to understand it, unlike on Multics.) The "new" file system
had different structure, and it is what Unix systems commonly use
today, but boy was it a porting nightmare.
Note that Multics files have structure normally (very well) hidden
from the user, Unix files also have a hidden (but not so well
originally) structure, and AmigaDOS learned the lesson well. (So
well, in fact that I can't remember ANY tools, programs, or files
which wouldn't work with the 1.0 files system, the Old File System,
and the Fast File System. (The incorrect reporting of file sizes in
earlier releases of info and list to my mind was a bug.) There is
good documentation for how all of those file systems work, and if you
really believe that those file systems are unstructured, go read it!
>Somewhere in there, the idea of bundling the process and its data became
>the concept of an abstract data type so dear to the object oriented
>programmers of today.
Huh? There are lots of definitions of abstract data types
floating around, so someone, somewhere, must have proposed one like
yours, but you missed the mark again. The idea of an abstract data
type is to combine the definition of the type with the operations on
the type, so that the details are hidden from the user. That is a
good fit with modern file systems.
>Not too scruffy from a beginning of "keep it simple, stupid." ;-)
This is a real insult, however you are probably, based on the
above comments, unaware of just how insulting it is. There are
SHELVES of papers, almost all of which make interesting reading today,
on the design details you dismiss so glibly. Making these things have
a simple appearing paradigm, and what that paradigm should be, were a
decade of labor for hundreds of people who thought that there was a
better model of computer human interaction than was embodied in the
early 360's. (Note that I probably should have said IBM 704, but the
IBM 704 was the ancestor of the 7094, which was the predecessor of the
GE 635... The announcement of the 360 series was the step that
caused MIT to turn to GE for the processor to run Multics, but I digress.)
Minicomputers, and CRT terminals, and interactive computing, and
the box that you have on your desk were the product of a lot of
visionary people who saw how good it could be, and spent years in the
wilderness making it happen. Some eventually got rich, but a lot of
people who could have deserted the cause, stuck through good times and
bad, to the idea that batch processing on mainframes was NOT the way
to use computers. The first computer I programmed was an IBM 650. I
still have a copy of the first assembler manual at home (GP for the
Univac I). I played Spacewar on the PDP-1 and MIT in 1964. I worked
on debugging the first time sharing systems. WHERE WERE YOU?
Robert I. Eachus
with STANDARD_DISCLAIMER;
use STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...
If thare are people who want to reminisce about the old days,
I'd love to, but lets keep it to e-mail. I only posted this because I
don't want young programmers kept in the dark. Santayanna, got it
right, and I remember seeing a column (in Datamation I think, eight or
ten years ago when it was still worth reading) about visiting a
microcomputer show in the Z80 days, and recognizing a lot of the old
mistakes being repeated.
Kent Paul Dolan
[Screenfuls of completely missing the point omitted.]
Sure, I you, and everyone else in the civilized universe knows that there
_IS_ a complex structure of inodes, block accessing, and whatever hidden
down under the apparently simple interface to Unix files. The point,
which escaped you to the point of near apoplexy, is that applications
programmers from the student beginner can completely ignore that complex
structure and treat the file as a stream of (randomly accessible) bytes.
All the blurb about Multix is also wide of the mark. I was responding
to a series of articles all claiming in essence "Unix isn't so great,
look at this (long-after-Unix-developed) much nicer way to chose a
metaphor of device access"; and I attempted to provide a bit of historical
context to the discussion. This does not require me to trace the concepts
back to Babbage, and frankly, except for being the predecessor that drove
the Unix developers away to do things better, Multics was a dinosaur, however
nice the ideas incorporated. Don't believe me? Check its market share
versus Unix or even the OS-360's children. ;-)
I even have my very own History of Programming Languages; I'm not at all
unaware of the history; in fact, in some small parts, I was a part of it.
>>Not too scruffy from a beginning of "keep it simple, stupid." ;-)
>
> This is a real insult, however you are probably, based on the
>above comments, unaware of just how insulting it is.
a) That funny looking thing is a smily face. Welcome to the net, BIFF!
It is exactly the ideas that make a complicated subject simple that
improve the world. The Unix file as a stream of bytes paradigm made a
horrendously complicated process in every other file system much easier
to comprehend. And no, that god-awful segmented mess that was Multics
idea of a file doesn't begin to compare.
b) The insult is in your own mind, not the text you read. When you
take the time to read what is in front of you, perhaps your written
responses will contain a bit more light and less heat.
>The first computer I programmed was an IBM 650. I
>still have a copy of the first assembler manual at home (GP for the
>Univac I). I played Spacewar on the PDP-1 and MIT in 1964. I worked
>on debugging the first time sharing systems. WHERE WERE YOU?
Looks like by the time you got started, youngster, I was already on
my fourth or fifth programming language.
> Robert I. Eachus
>
Who has certainly had better days than that one!
>
> If thare are people who want to reminisce about the old days,
>I'd love to, but lets keep it to e-mail. I only posted this because I
>don't want young programmers kept in the dark. Santayanna, got it
>right, and I remember seeing a column (in Datamation I think, eight or
>ten years ago when it was still worth reading) about visiting a
>microcomputer show in the Z80 days, and recognizing a lot of the old
>mistakes being repeated.
We have the same goals; wonder how come your approach fails to meet the
need? Think, then type and you'll surely do better.