richard@pnet02.UUCP (06/04/87)
Yeah, this discussion has been raging in the comp.sys.apollo group for a
while, Re: is an Apollo a UN*X box. Apollo has an AEGIS (their OS, not the
company) kernal, on top of which support bith BSD4.2 and SYS5.
Apollo has taken some flak for not being more 'real' UN*X (Gee, just like
XENIX :-) which seems to come from two areas: 1) People who have used only
UN*X and hav'nt taked the trouble to learn UN*X, and 2) People who have
heterogeneous networks (Suns, Vaxen, Aliiants ...) and want to be ablr to
administer these things the same way. I think only 2) is valid.
To this end, Apolo (in SR.10) will have a new kernal that will run AEGIS,
BDS4.2 and SYS5, in a more 'real' manner, ie some of the UN*X components like
/etc/password act more like 'real' UN*X.
Aegis is much more usefull for Apollos, because it knows about distributed
systems at its lowest level; it's not just tacked on. Plus is has a really
neat user interface. After using UN*X for about 12 yearss, I havn't noticed
any real advances in it.
Sooo, I for one would not like to see Amiga become UN*X boxes. Thay can do
better than that. But if they had a common kernal that could support the
current OS and UN*X, it might make everyone happy.
But I still would'nt use UN*X.
Cheers,
UUCP: {ihnp4!crash, hplabs!hp-sdd!crash}!gryphon!pnet02!richard
INET: richard@pnet02.CTS.COMbarnett@vdsvax.UUCP (06/04/87)
In article <600@gryphon.CTS.COM> richard@pnet02.CTS.COM (Richard Sexton) writes: >Sooo, I for one would not like to see Amiga become UN*X boxes. Thay can do >better than that. But if they had a common kernal that could support the >current OS and UN*X, it might make everyone happy. > >But I still would'nt use UN*X. Everyone to their own opinion. I use UN*X a lot. I don't have a home computer (yet :-). I am waiting for a machine with: 32-bit backplane Slots to grow Ability to add UN*X The Mac II is the first machine that is a real possibility. Now if only I could afford it. Mild flame to C-A: [Note - I believe the Zorro slots are not 32 bits address and 32 bits data. If I am wrong - please forgive. Let's not swamp the newsgroup with flames.] The A2000 is a 16 bit machine that can support a 32 bit CPU card. If I buy a home computer, I would like to have a system that can be used for 5 - 10 years (sounds foolish - doesn't it :-). I mean, I don't want to upgrade the chassis and motherboard every other year. I want to buy a machine that is useful as is, then add memory and disks in the years to come, when they drop in price. I can only afford a major purchase in computing power ONCE. Look at the Mac II: The floppy disk controller can handle double density floppys. The CPU motherboard can support 128MBytes (with the right chips). The system can support Parallel Processors, with any CPU becomming the master. So I can add a 68030 (or whatever) board, and use the original CPU board as an I/O handler. Or vice versa. UN*X is available Real Soon Now. Video board is upgradable! Seven 32 bit Slots! Clearly - the Mac II was designed for a long useful future. Yes it is expensive - but perhaps it is worth it in the long run. How much will the A3000 cost assuming you started with an A1000? The same as a Mac II? I know that when I want to upgrade the Mac, some of the boards will be REAL CHEAP five years from now. :-) I think the Amiga is a great machine. I would rather buy an Amiga than a Mac. You guys must be having a great time. I do envy you. But I don't want to buy a system, and then be frustrated with it two or three years later. How much will it cost me to add UN*X in three years? In that time, RAM and disk will be cheap. Richard, you may not like UN*X. I do. Not only can I quickly develop scripts and programs, but I can port them to a large number of machines. I can develop software to run on Vaxes, Suns, Apollos, and Xenix machines. One of the advantages of having a personal workstation is the ability to develop applications for commercial use. This is one way to lower the cost of ownership. There are two directions to go here. MSDOS and UNIX. As for your opinion on Unix, I guess you are critical with the user interface. The ADVANTAGE of UN*X is that you can change pieces of it easily. It is also well understood. Maybe a whiz-bang kernal would make you happy, but unless it was widely available, the advantage would be limited. Sorry guys, but I don't see the Amiga taking over the world. Maybe a nitch. I would rather put my person time into understanding UN*X better, than learning a strange OS. No matter how Great and Wonderful it is, it won't help my daytime job. -- Bruce G. Barnett (barnett@ge-crd.ARPA) (barnett@steinmetz.UUCP) -- "The difference between a Buddha and an ordinary man is that one knows the difference and the other does not."
mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (06/05/87)
In article <1705@vdsvax.steinmetz.UUCP> barnett@ge-crd.arpa (Bruce G Barnett) writes:
< The A2000 is a 16 bit machine that can support a 32 bit
<CPU card. If I buy a home computer, I would like to have
<a system that can be used for 5 - 10 years (sounds foolish - doesn't it :-).
Yeah, it sounds foolish. Anything you buy now will be in the "toy"
class four years from now. Including the Mac ][. I plan on buying a
new machine in the $3 to $5K price range every four years, and
probably haveing to start from scratch on software. If you plan on
those kinds of upgrades, it's amazing how easy it is to afford them.
On the other hand, when I get around to buying a car, I'll expect it
to run for 10-15 years :-).
<I can only afford a major purchase in computing power ONCE.
Once, ever? You mean when NeXT starts on their third-generation
machine, you expect to be using a machine you bought in the next 6
month or so? Or do you mean "only at infrequent intervals?" The two
make a *lot* of difference.
< The floppy disk controller can handle double density floppys.
< The CPU motherboard can support 128MBytes (with the right chips).
< The system can support Parallel Processors, with any CPU
< becomming the master. So I can add a 68030 (or whatever)
< board, and use the original CPU board as an I/O handler.
< Or vice versa.
< UN*X is available Real Soon Now.
< Video board is upgradable!
< Seven 32 bit Slots!
<Clearly - the Mac II was designed for a long useful future.
Gee, except for the 32-bit data paths and massive memory, that sounds
like my second system. Of course, I had a *lot* more slots (22) than
that. I sold it for scrap a while back. Oddly enough, the amiga that
replaced has the same data paths, and 1/2 the memory capacity.
<Richard, you may not like UN*X. I do. Not only can I quickly develop
<scripts and programs, but I can port them to a large number of machines.
<I can develop software to run on Vaxes, Suns, Apollos, and Xenix
<machines.
You loose on Unix-compatable scripts on the Amiga. AmigaDOS provides
a lot more power for scripts than the Amiga (pipes in the file name
space is a *major* win. Unfortunately, the tools that come with
AmigaDOS aren't nearly as nice as the tools that usually come with
Unix. But porting programs to/from real Unix turns out to be
straightforward, so longs as you avoid fancy terminal I/O and use the
directory library (anyone out there want the 4BSD directory library
for the Amiga? I got one), and watch out for libraries that aren't on
one system or another. Gee, those are the *exact* same things you have
to deal with in going from one Unix system to a different flavor (4BSD
vs. v7 vs. SysV).
And even now, I'm learning the joys of porting software from 4.2BSD to
Ultrix 2.0.
<As for your opinion on Unix, I guess you are critical with the user
<interface. The ADVANTAGE of UN*X is that you can change pieces of it
<easily. It is also well understood.
You can't change Unix as easily as you can change AmigaDOS. The
message-passing pardigm internally gives you *lots* of flexibility.
For instance, adding NFS to AmigaDOS should be simple (Bob? Chuck?
What did Ameristar have you add - one driver?). But to Unix? Well -
Sun says NFS is a drop-in. Well, it is. But it makes a big
splash.
-- Mike Karels
At the user level, about the only thing missing is the ability to put
in your own shell. You have to run one on top of the CLI. BFD.
<I would rather put my person time into understanding UN*X better, than
<learning a strange OS. No matter how Great and Wonderful it is, it
<won't help my daytime job.
That's a personal decision, and one I can't fault. I just don't agree
with you. I understand Unix far better than I'd like to. Maybe that's
why it makes me ill.
<mike
--
How many times do you have to fall Mike Meyer
While people stand there gawking? mwm@berkeley.edu
How many times do you have to fall ucbvax!mwm
Before you end up walking? mwm@ucbjade.BITNETmichael@stb.UUCP (Michael) (06/07/87)
In article <1705@vdsvax.steinmetz.UUCP> barnett@ge-crd.arpa (Bruce G Barnett) writes: >In article <600@gryphon.CTS.COM> richard@pnet02.CTS.COM (Richard Sexton) writes: > The A2000 is a 16 bit machine that can support a 32 bit >CPU card. If I buy a home computer, I would like to have >a system that can be used for 5 - 10 years (sounds foolish - doesn't it :-). No. My model 1 is still useful. >I mean, I don't want to upgrade the chassis and motherboard every >other year. I want to buy a machine that is useful as is, then add >memory and disks in the years to come, when they drop in price. >I can only afford a major purchase in computing power ONCE. Then when will you add CPU boards? 68030's will be expen$ive. > >Look at the Mac II: > > The floppy disk controller can handle double density floppys. The amiga does it in software and blitter. More per floppy, too. > The CPU motherboard can support 128MBytes (with the right chips). Huh? 4Mbit chips? (still need 256 of them) If you mean addon cards, the amiga does too (if you get a 020) > The system can support Parallel Processors, with any CPU > becomming the master. So I can add a 68030 (or whatever) > board, and use the original CPU board as an I/O handler. > Or vice versa. I may be wrong, but isn't that how the CSA 020 board works? > >As for your opinion on Unix, I guess you are critical with the user >interface. The ADVANTAGE of UN*X is that you can change pieces of it >easily. It is also well understood. Really??? My complaints with un*x are safely locked in the kernel where I can't get at them. First, I'm speaking of a home system right now. Mostly floppy based, with a hard disk for the system. Un$x is an absolute PAIN to use floppies with. EVERY TIME you switch them, you have TWO commands to give. If you forget and switch, you may not even be able to switch back and then umount -- the system may have accessed the disk in between. Worse, they are root only--you have to su to use them. The file system is not safe. In particular, writes to the disk are buffered for an arbitrarily long time. I'd love to see the system changed to a write through disk cache, or else a small maximum delay (no more than 1 second). /etc/update just doesn't cut it -- the super block is not properly updated (at least not on the unix I'm using right now). Programs do not have sufficient control over serial ports. I have yet to see a terminal program for un*x that even matches, not beats but matches, the terminal programs for a trs-80 model 1. Programs cannot even guarantee sufficient response time. Although sys5 does have a terminal driver with all the features needed, each time you access it you have to switch from user to kernel space, which takes significant time. Want to write any extensions (such as network support over a serial port)? Good luck making it work, let alone making it transparent. Finally, the swapper has a very poor algorithm for it. A 512K un*x machine is limited by the swapper. A 512K Amiga is cramped, but usable. A 1Meg un*x machine still swaps. A 1Meg Amiga is bliss. (2 meg runs out of chip memory before it runs out of programs to run) The amiga's dos may be unplesent, but A. Auto recognition of changed floppies (slow, but sure) B. Safe (?) file system (replacable, too) C. Total control over parts of the system D. Guaranteed good response time, if you want it (set your priority high) E. Transparent extension of the dos. Now, thats just the kernel. If you want to talk about system programs, let me know. In general, one big complaint I have with un*x is its design philosophy. Its job is to regulate several competing, hostile programs, limiting each individual process, and double checking everything they want to do. I can do with less hand holding. I program in C :-) >learning a strange OS. No matter how Great and Wonderful it is, it >won't help my daytime job. My daytime job is a student. My night time job is a student. My summer job is an amiga hacker. (starts next week, oh glory day) >Bruce G. Barnett (barnett@ge-crd.ARPA) (barnett@steinmetz.UUCP) -- : Michael Gersten seismo!scgvaxd!stb!michael : The above is the result of being educated at a school that discriminates : against roosters.
barnett@vdsvax.steinmetz.UUCP (Bruce G Barnett) (06/11/87)
In article <1576@stb.UUCP> michael@stb.UUCP (Michael) writes: >In article <1705@vdsvax.steinmetz.UUCP> barnett@ge-crd.arpa (Bruce G Barnett) writes: >>I mean, I don't want to upgrade the chassis and motherboard every >>other year. I want to buy a machine that is useful as is, then add >>memory and disks in the years to come, when they drop in price. >>I can only afford a major purchase in computing power ONCE. > > Then when will you add CPU boards? 68030's will be expen$ive. Maybe not in 5 years >> The CPU motherboard can support 128MBytes (with the right chips). > Huh? 4Mbit chips? (still need 256 of them) No 16M chips - talk about long range planning. :-) > >> The system can support Parallel Processors, with any CPU >> becomming the master. So I can add a 68030 (or whatever) >> board, and use the original CPU board as an I/O handler. >> Or vice versa. > > I may be wrong, but isn't that how the CSA 020 board works? I may be wrong, but I don't understand how the csa 020 board can have 32 bit wide data access to the backplane. I would eventually like the ability to have a 32 bit wide backplane machine with 32-bit DMA etc. >Un$x is an absolute PAIN to use floppies with. No argument. >The file system is not safe. In particular, writes to the disk are buffered >for an arbitrarily long time. Partially an implementation problem. The Berkeley file system is very nice. Files in the same directory are keep on the same cylider group for faster access. Also the BSD kernal has atomic mkdir and rename, which helps to eliminate corrupted disks. Also the superblock is duplicated in a spiral across the disk cylinders, so a head crash will only wipe out a portion of the disk, making the rest recoverable. [deleted comments about advanages of AmigaDOS vs. unix] > >In general, one big complaint I have with un*x is its design philosophy. Its >job is to regulate several competing, hostile programs, limiting each >individual process, and double checking everything they want to do. > >I can do with less hand holding. I program in C :-) I see nothing wrong with having a wonderful operating system for home hacking. I want to have FUN with my home computer too. But if I want to justify the purchase of a computer, I need a machine that can be used to develop commercial applications. Perhaps porting AmigaDOS <-> Un*X is easy. I don't know. I am not talking porting C, but porting code based on library and kernal features, networking, graphics, X-windows, NeWS, etc. I cannot afford to buy a high-tech `toy'. (I have no interest in developing video applications). Just call me over-cautious. >: Michael Gersten seismo!scgvaxd!stb!michael -- Bruce G. Barnett (barnett@ge-crd.ARPA) (barnett@steinmetz.UUCP) -- "The difference between a Buddha and an ordinary man is that one knows the difference and the other does not."
hah@isum.intel.com (Hans Hansen) (06/12/87)
In article <1765@vdsvax.steinmetz.UUCP> barnett@ge-crd.arpa (Bruce G Barnett) writes: >> I may be wrong, but isn't that how the CSA 020 board works? > >I may be wrong, but I don't understand how the csa 020 board can have >32 bit wide data access to the backplane. I would eventually like the >ability to have a 32 bit wide backplane machine with 32-bit DMA etc. > I believe you will find that the CSA board uses a 32 bit expansion bus that starts at 16M (0x0000010000000000). Hans
barnett@vdsvax.UUCP (06/13/87)
In article <3862@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) writes: >In article <1705@vdsvax.steinmetz.UUCP> I (Bruce G Barnett) wrote: >< The A2000 is a 16 bit machine that can support a 32 bit ><CPU card. If I buy a home computer, I would like to have ><a system that can be used for 5 - 10 years (sounds foolish - doesn't it :-). > >Yeah, it sounds foolish. Anything you buy now will be in the "toy" >class four years from now. Including the Mac ][. Let me clarify why I raised this point, and possible head of the noise level. Commodore: I would like the next Amiga to have a better path towards future systems. My foolish assumption is: it is cheaper to exchange one board than exchange a complete system. A Mac II can be upgraded because better video boards can be added, faster processors can be added, disk controllers, etc. The expensive part is upgrading to a new system, and finding out all of your old boards won't fit. Let's look at the limiting factor: the bus. You can only go so far with 16 bits. We are now hearing the last gasps of the 16 bit machines. (I don't think the PC users know this yet :-). Now if I had a backplane that really supported 32 bits of address and data, (fill in the good buzzwords of bus architecture), and a low initial entry Amiga, I would buy one, and, as I save up my bucks, add More memory hard disk More memory Faster CPU MMU UNIX (please - no flames) More memory Bigger video more Disk More goodies tape system Faster disk more memory .etc Now suppose I bought an A2000. What is the upgrade policy? Well, there isn't one now. We could GUESS. But nothing is sure. Suppose I want to buy a A3000. What do I do with my old boards? Adapter cards? An extra chassis? Using the A2000 chassis as an expansion box? I shudder to think of THAT! How much would it cost me to convert all of my memory, and peripherals over to a new backplane? What? you need four backplanes on the Amiga 3000? for AT's, Zorro, IBM's PS/2 and the next Amiga bus? Maybe the next Amiga should have the new IBM PS/2 bus. Or the NUbus. VME? > I plan on buying a >new machine in the $3 to $5K price range every four years, and >probably haveing to start from scratch on software. I don't plan to have the fastest CPU on the block. I would wait until the prices drop on the peripherals. 80Megs for $400 - yeah! that's the ticket! ><I can only afford a major purchase in computing power ONCE. > >Once, ever? You mean when NeXT starts on their third-generation >machine, you expect to be using a machine you bought in the next 6 >month or so? Or do you mean "only at infrequent intervals?" The two >make a *lot* of difference. yeah, I guess I wasn't thinking about 10 years later. I suppose I could buy something then - a 64 bit CPU!! :-) maybe I ought to wait for a 64 bit bus :-) :-) :-) :-). -- Bruce G. Barnett (barnett@ge-crd.ARPA) (barnett@steinmetz.UUCP) -- "The difference between a Buddha and an ordinary man is that one knows the difference and the other does not."
peter@sugar.UUCP (Peter DaSilva) (06/13/87)
> Un$x is an absolute PAIN to use floppies with. EVERY TIME you switch them, > you have TWO commands to give. Part of the solution to this is a write-through cache. The other... well with 3.25" disks you can mount them transparently. That is basically what the Amiga does, you know? > The file system is not safe. In particular, writes to the disk are buffered > for an arbitrarily long time. I'd love to see the system changed to a write > through disk cache, or else a small maximum delay (no more than 1 second). That's an implementation detail. There are version of UNIX with write-through caches. The system remains the same, you just take a performance hit. I would like to see AmigaDOS with a UNIX-type cache & a "sync" entry in the menu, it would cut seeking incredibly. At least you could use it for non-removable media like hard disks. > Programs do not have sufficient control over serial ports. I have yet to see > a terminal program for un*x that even matches, not beats but matches, the > terminal programs for a trs-80 model 1. I have yet to see a terminal program for UNIX, period. Terminal emulation is a matter for the terminal you're on. There are plenty of *modem* programs for UNIX, however. Some are quite good. > Programs cannot even guarantee sufficient response time. Although sys5 does > have a terminal driver with all the features needed, each time you access it > you have to switch from user to kernel space, which takes significant time. UNIX is generally not a real-time system. This is correct. It could be made one, but once again you would take a performance hit for CPU-intensive and shell-type interactive use. REAL-time UNIXes do exist. > Want to write any extensions (such as network support over a serial port)? > Good luck making it work, let alone making it transparent. You can make it semi-transparent (translucent) with either sockets or named pipes. I think AmigaDOS has a number of advantages over UNIX here. I particularly like the Amigados file naming conventions, which can be slightly modified to become a transparent superset of UNIX's. > Finally, the swapper has a very poor algorithm for it. A 512K un*x machine > is limited by the swapper. A 512K Amiga is cramped, but usable. A 1Meg un*x > machine still swaps. A 1Meg Amiga is bliss. (2 meg runs out of chip memory > before it runs out of programs to run) Have you ever used a UNIX machine single user? So long as you don't put gross stuff into crontab you swap infrequently or not at all... but the ability is still there. You're sounding like the ATARI-ST people claiming that multitasking is a problem because of what happens if you misuse it. > I can do with less hand holding. I program in C :-) I want as much resource tracking as you can afford. I have used UNIX systems with considerably less hardware than an Amiga and they ran quite well, so obviously the 68000 can afford as much. I can do with more bounds checking. I program in C. **** Now then. I don't think you need UNIX on the Amiga for a simple reason: AmigaDOS is already so good. It's not perfect, and there is a lot of stuff I would like to change, but it's good enough that it's not worth the effort of replacing it completely. On the other hand, there's no need to slam UNIX, which isn't an O/S so much as a family of operating systems with a common programmer and user interface: some of which are not appropriate for a machine of the Amiga's capacity, and some of which are.
jerem@tekgvs.UUCP (06/15/87)
In article <785@omepd> hah@isum.UUCP (Hans Hansen) writes: >In article <1765@vdsvax.steinmetz.UUCP> barnett@ge-crd.arpa (Bruce G Barnett) writes: >>> I may be wrong, but isn't that how the CSA 020 board works? >> >>I may be wrong, but I don't understand how the csa 020 board can have >>32 bit wide data access to the backplane. I would eventually like the >>ability to have a 32 bit wide backplane machine with 32-bit DMA etc. >> >I believe you will find that the CSA board uses a 32 bit expansion bus >that starts at 16M (0x0000010000000000). The CSA board uses the standard Zorro I backplane (16-bits) and the 32-bit bus is physically separate and not part of the backplane. My 1 Meg of 32-bit memory starts at 7f000000 and ends at 7f0fffff. The 32-bit address space lies above the 24-bit address space of the 68000. Thus, DMA chip access to this address space will require some cleverness on C-A's part. While I have y'all on the horn, I have a question. I thought about further expansions of my memory with, say, a Zorro I board from, say, ASDG. But then I thought: Hmm. I would have no control over where code and data are loaded in a program. I would guess that MEMF_FAST would mean either the 16 or the 32-bit memory. Since there is a factor of four in execution speed in the 32-bit memory, I would want to selectively use it. Maybe I should save my, uh, pennies for more 32-bit RAM. -Jere Jere M. Marrs Tektronix, Inc. Beaverton, Oregon {U-name-it}!tektronix!tekgvs!jerem
flocchini@deneb.UUCP (06/16/87)
> In article <785@omepd> hah@isum.UUCP (Hans Hansen) writes: > >In article <1765@vdsvax.steinmetz.UUCP> barnett@ge-crd.arpa (Bruce G Barnett) writes: > >>> I may be wrong, but isn't that how the CSA 020 board works? > >> > >>I may be wrong, but I don't understand how the csa 020 board can have > >>32 bit wide data access to the backplane. I would eventually like the > >>ability to have a 32 bit wide backplane machine with 32-bit DMA etc. > >> > > >I believe you will find that the CSA board uses a 32 bit expansion bus > >that starts at 16M (0x0000010000000000). > > The CSA board uses the standard Zorro I backplane (16-bits) and > the 32-bit bus is physically separate and not part of the backplane. My > 1 Meg of 32-bit memory starts at 7f000000 and ends at 7f0fffff. The 32-bit > address space lies above the 24-bit address space of the 68000. Thus, DMA > chip access to this address space will require some cleverness on C-A's > part. > > While I have y'all on the horn, I have a question. I thought about > further expansions of my memory with, say, a Zorro I board from, say, ASDG. > But then I thought: Hmm. I would have no control over where code and data > are loaded in a program. I would guess that MEMF_FAST would mean either > the 16 or the 32-bit memory. Since there is a factor of four in execution > speed in the 32-bit memory, I would want to selectively use it. Maybe I > should save my, uh, pennies for more 32-bit RAM. > > -Jere > I ran the ramspeed program that appears on Fish Disk #31 with the following results. CSA Memory Off 6MByte ASDG RAM Chip Speed 24.66 seconds Fast Speed 22.96 seconds I then turned on the CSA memory boards. I also have 1MByte of this 32 bit ram. with the following results. CSA Memory On 6MByte ASDG RAM Chip Speed 24.36 seconds Fast Speed 6.63 seconds I would assume that the 32-bit memory has priority when both 16 bit and 32 bit memory are in the system. Bob Flocchini ucdavis!deneb!flocchini > Jere M. Marrs > Tektronix, Inc. > Beaverton, Oregon > {U-name-it}!tektronix!tekgvs!jerem *** REPLACE THIS LINE WITH YOUR MESSAGE ***
mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (06/17/87)
In article <165@sugar.UUCP> peter@sugar.UUCP (Peter DaSilva) writes:
<> Un$x is an absolute PAIN to use floppies with. EVERY TIME you switch them,
<> you have TWO commands to give.
<
<Part of the solution to this is a write-through cache. The other... well with
<3.25" disks you can mount them transparently. That is basically what the
<Amiga does, you know?
Ok, I can see a disk change causing the kernel parts of mount and
unmount to hapen. You could even flush /etc/mtab, and make everything
that uses it wade around in the kernel to get that data. I think
changes to /etc/fstab can be ignored, but programs that use it are
going to be much less usefull. The result won't be pretty, in any
case. But there are lots of other things that could be done to Unix
with less effort to make it work better on an Amiga.
<> Programs do not have sufficient control over serial ports. I have yet to see
<> a terminal program for un*x that even matches, not beats but matches, the
<> terminal programs for a trs-80 model 1.
<
<I have yet to see a terminal program for UNIX, period. Terminal emulation is
<a matter for the terminal you're on. There are plenty of *modem* programs for
<UNIX, however. Some are quite good.
You haven't been looking hard enough. There's at least one ANSI
emulator that runs through termcap. X comes with vt00 and TEK
emulators, and there's a PD vt100 emulator for Suntools. NeWS claims
to emulate bitgraph, vt100, h19, and tvi925 termminals (at least).
And the original point still stands. For some reason, Unix modem
programs don't get very good throughput. Nuts - Unix terminals don't
get very good throughput. My CP/M-68K system came closer to pushing
9600 baud out it's serial port than Unix does.
<> Want to write any extensions (such as network support over a serial port)?
<> Good luck making it work, let alone making it transparent.
<
<You can make it semi-transparent (translucent) with either sockets or named
<pipes. I think AmigaDOS has a number of advantages over UNIX here. I
<particularly like the Amigados file naming conventions, which can be
<slightly modified to become a transparent superset of UNIX's.
SLIP is in BSD 4.3, and can be gotten from seismo.css.gov for free.
Any program that expects to speak IP over ethernets won't have any
problems talking over serial lines with this code. I can't think of
any way to make it transparent, other than to try making it go at the
10Mbit speeds you find on ethernets.
<Have you ever used a UNIX machine single user? So long as you don't put gross
<stuff into crontab you swap infrequently or not at all... but the ability is
<still there. You're sounding like the ATARI-ST people claiming that
<multitasking is a problem because of what happens if you misuse it.
I use single-user Unix systems all the time, with little or nothing in
crontab. They swap quite a bit, too (something about *large* window
managers and tools).
The multitasking analogy isn't quite right. Multitasking gives you
some basic abilities you didn't have before. Swapping just means you
get to run more and bigger applications before you run out of memory.
Of course, the typical Unix swapping strategy crocked for a small
system (two floppies). Or a large (Cray) one, for that matter.
<I want as much resource tracking as you can afford. I have used UNIX systems
<with considerably less hardware than an Amiga and they ran quite well, so
<obviously the 68000 can afford as much. I can do with more bounds checking.
<
<I program in C.
You program in C and want bounds checking? Make up your mind :-).
Have you ever run real Unix (not the AT&T mini-Unix for the PDP-11/10
& kin) without either an MMU, or segment registers? If so, I'd like to
know what it was on.
<****
<
<Now then. I don't think you need UNIX on the Amiga for a simple reason:
<AmigaDOS is already so good. It's not perfect, and there is a lot of stuff
<I would like to change, but it's good enough that it's not worth the effort
<of replacing it completely. On the other hand, there's no need to slam UNIX,
<which isn't an O/S so much as a family of operating systems with a common
<programmer and user interface: some of which are not appropriate for a machine
<of the Amiga's capacity, and some of which are.
Very well put. The only really major problem (as in - this is the one
that really hurts and can't be replaced by something that runs faster
but does the same job) is resource tracking so I can kill runaway
procs.
<mike
--
How many times do you have to fall Mike Meyer
While people stand there gawking? mwm@berkeley.edu
How many times do you have to fall ucbvax!mwm
Before you end up walking? mwm@ucbjade.BITNEThadeishi@husc4.HARVARD.EDU (mitsuharu hadeishi) (06/17/87)
In article <580@ucdavis.UUCP> flocchini@ucdavis.UUCP (flocchini) writes: >I would assume that the 32-bit memory has priority when both 16 bit and 32 bit >memory are in the system. I believe the memory priority is somehow determined by the order in which the boards are added to the FAST memory list. I'm not sure whether the autoconfig standard has a way for a board to ensure that it gets added at the highest priority or not. Carolyn? -Mitsu
dragon@trwspf.UUCP (06/18/87)
In article <1771@vdsvax.steinmetz.UUCP> barnett@ge-crd.arpa (Bruce G Barnett) writes:
*Suppose I want to buy a A3000. What do I do with my old boards?
*Adapter cards? An extra chassis? Using the A2000 chassis as an
*expansion box? I shudder to think of THAT!
*
*yeah, I guess I wasn't thinking about 10 years later. I suppose
*I could buy something then - a 64 bit CPU!! :-) maybe I ought to wait
*for a 64 bit bus :-) :-) :-) :-).
Last week, a couple of guys from a new startup walked into my office offering
to sell me the equivalent of a Cray and a Pixar in 40" of rack space for
something less than $100K. The design included 512-bit wide internal data
paths moving data at 640 megabytes/sec and approximately 45 ASICs. Sorta
reminded me of an Amiga. Hang tough, gang, 10 years may get here sooner
than you think :-).
--
-- Roger A. Vossler
TRW, Bldg O2-1395, One Space Park, Redondo Beach, CA 90278
BIX: rvossler UseNet: dragon@trwspf.UUCP
...!sdcrdc!trwrb!trwspf!dragonrichard@pnet02.CTS.COM (Richard Sexton) (06/19/87)
Was it a Dana ? Steller ? Or can't you say ?
UUCP: {ihnp4!crash, hplabs!hp-sdd!crash}!gryphon!pnet02!richard
INET: richard@pnet02.CTS.COMdillon@CORY.BERKELEY.EDU (Matt Dillon) (06/19/87)
>yeah, I guess I wasn't thinking about 10 years later. I suppose >I could buy something then - a 64 bit CPU!! :-) maybe I ought to wait >for a 64 bit bus :-) :-) :-) :-). Oh No! You're thinking about it all wrong. The trend of the future is to have multi-processor machines to get the power. For instance, a real live machine in existance right now is the CONNECTION machine, made up of a large number (65536) single bit processors. This baby outperforms a Cray II! -Matt
walton@tybalt.caltech.edu (Steve Walton) (06/21/87)
In article <8706191429.AA20219@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >>yeah, I guess I wasn't thinking about 10 years later. I suppose >>I could buy something then - a 64 bit CPU!! :-) maybe I ought to wait >>for a 64 bit bus :-) :-) :-) :-). > > Oh No! You're thinking about it all wrong. The trend of the future >is to have multi-processor machines to get the power. For instance, a real >live machine in existance right now is the CONNECTION machine, made up of >a large number (65536) single bit processors. This baby outperforms a >Cray II! > > -Matt While, as an employee of AMETEK Computer Research Division, I agree that multiprocessors have great potential (we make hypercubes, aka Cosmic Cubes), the power of the Connection Machine is greatly exaggerated. Its speed is as high as Matt says only when all 64K processors are running at the same time. Most problems only run a few hundred of them at a time (there's only a few K of memory per processor, so they can't run anything very sophisticated). The Intel iPSC hypercube, the NCUBE, and the FPS T series all run faster than the CM on real problems, notwithstanding the recent article in SciAm by the president and founder of the company which makes the CM. I've directed followups to comp.arch. Steve Walton, guest as walton@tybalt.caltech.edu AMETEK Computer Research Division, ametek!walton@csvax.caltech.edu "Long signatures are definitely frowned upon"--USENET posting rules
mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (06/22/87)
< Oh No! You're thinking about it all wrong. The trend of the future <is to have multi-processor machines to get the power. For instance, a real <live machine in existance right now is the CONNECTION machine, made up of <a large number (65536) single bit processors. This baby outperforms a <Cray II! < < -Matt Aren't you making your statements just a *little* bit broad, Matt :-). After all, lots of things outperform a Cray II, including a Cray XM/P-48. But only at the things they are good at, not the things the II is good at (vectorizable problems that want a Gigabyte or so of memory to run in). The CM will outperform a II (or the XM/P-48) at what it's good at - cellular automata, twiddling bitmaps, and other things that want to do the same simple things to a lot of small data elements. But outside of that area, it don't do so well. The interesting problem is determing what is really *outside* of that area (fluid dynamics and full-text document retrieval are known to be inside!!!). <mike -- How many times do you have to fall Mike Meyer While people stand there gawking? mwm@berkeley.edu How many times do you have to fall ucbvax!mwm Before you end up walking? mwm@ucbjade.BITNET
peter@sugar.UUCP (Peter DaSilva) (06/22/87)
Mike (My watch has windows) Meyer writes: > <I have yet to see a terminal program for UNIX, period. Terminal emulation is > <a matter for the terminal you're on. There are plenty of *modem* programs for > <UNIX, however. Some are quite good. > > You haven't been looking hard enough. There's at least one ANSI > emulator that runs through termcap. X comes with vt00 and TEK > emulators, and there's a PD vt100 emulator for Suntools. NeWS claims > to emulate bitgraph, vt100, h19, and tvi925 termminals (at least). Well, la-de-da. Most UNIX systems don't support bit-mapped displays and windows at all, and I belong to the unprivileged masses who have never used such a beast. I wrote an H-19 emulator that ran through termcap once, but that was just to attach to the standard output of some programs written without TERMCAP. I wouldn't expect much in the way of speed from such a beast... > And the original point still stands. For some reason, Unix modem > programs don't get very good throughput. Nuts - Unix terminals don't > get very good throughput. My CP/M-68K system came closer to pushing > 9600 baud out it's serial port than Unix does. We get 19200 and even 38400 out of the Unisys 5000 at work... and it's only got 2 68000s to serve typically 15-25 users. It's frowned upon, but it's possible. > I use single-user Unix systems all the time, with little or nothing in > crontab. They swap quite a bit, too (something about *large* window > managers and tools). Once again, most small UNIX systems don't have gross window managers and tools. > The multitasking analogy isn't quite right. Multitasking gives you > some basic abilities you didn't have before. Swapping just means you > get to run more and bigger applications before you run out of memory. That is a new basic ability: the ability to ignore memory limitations to a great extent. I often want to "swap" deluxe paint to disk while I run something else. Gobs of memory would do as well, but I don't have it. Of course swapping on the Amiga is a pretty problematical thing... and, also of course, nobody says that AmigaUNIX has to support it. Minix doesn't, for example, and it's a pretty close implementation of V7 UNIX.
jxc@rayssd.RAY.COM (Jeffrey J. Clesius) (06/22/87)
In article <306@trwspf.TRW.COM>, dragon@trwspf.TRW.COM (Roger Vossler) writes: > > Hang tough, gang, 10 years may get here sooner > than you think :-). > > -- Roger A. Vossler > TRW, Bldg O2-1395, One Space Park, Redondo Beach, CA 90278 > BIX: rvossler UseNet: dragon@trwspf.UUCP > ...!sdcrdc!trwrb!trwspf!dragon Yeah, the things were looking for in 10 years will be here in 3, the things in 5 will be here in 1... heck, if this keeps up, maybe soon the stuff we need yesterday, we'll get the day before! ______________________________________________________________ | Jeffrey Jay Clesius, Raytheon Submarine Signal Division | | 1847 West Main Road, Mail Stop 188 | | Portsmouth, RI 02871-1087 (401) 847-8000 (X4015) | | { allegra | gatech | mirror | raybed2 } -----\ | | { linus | ihnp4 | uiucdcs } --------------->!rayssd!jxc | |______________________________________________________________| -- "Regression tests are a thing of the past!"
mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (07/03/87)
In article <214@sugar.UUCP> peter@sugar.UUCP (Peter DaSilva) writes:
<Well, la-de-da. Most UNIX systems don't support bit-mapped displays and
<windows at all, and I belong to the unprivileged masses who have never used
<such a beast.
Of course, you're ignoring that the terminal emulator that I mentioned
which ran on anything which was more than a glass TTY that you could
write a termcap entry for. Naturally there are more terminal emulators
for bitmapped displays than for terminals. After all, why emulate a
terminal if you've already got one?
<> And the original point still stands. For some reason, Unix modem
<> programs don't get very good throughput. Nuts - Unix terminals don't
<> get very good throughput. My CP/M-68K system came closer to pushing
<> 9600 baud out it's serial port than Unix does.
<
<We get 19200 and even 38400 out of the Unisys 5000 at work... and it's only got
<2 68000s to serve typically 15-25 users. It's frowned upon, but it's possible.
So? I can set unix serial lines to 19200 and 38400, and they sure go
faster than the same lines set to 9600. But the "9600 baud" lines
aren't going 9600 baud, and the 1200 baud lines aren't going 1200
baud. If you stack your 38400 serial lines next to something simple
generating 38400, and they actually go the same speed, then you've got
a point.
<> I use single-user Unix systems all the time, with little or nothing in
<> crontab. They swap quite a bit, too (something about *large* window
<> managers and tools).
<
<Once again, most small UNIX systems don't have gross window managers and
<tools.
But we're talking about what to put on a system with a bitmapped
display and a mouse. If it don't got a window manager & tools, forget
it. I might as well by a Stride & a z39. So how many small Unix
systems with bitmapped displace and rodents don't have gross window
managers and tools (like X, or Suntools, or NeWS)?
Of course, it doesn't take much *without* the window manager to make an
Amiga class machine running Unix (even something as small as v7) go
into agonies. Get a Fortune 32:16 with 1/2 meg, and try running
Unipress Emacs on it.
<> The multitasking analogy isn't quite right. Multitasking gives you
<> some basic abilities you didn't have before. Swapping just means you
<> get to run more and bigger applications before you run out of memory.
<
<That is a new basic ability: the ability to ignore memory limitations
<to a great extent.
No, it doesn't. Any single application must still be smaller than
physical memory. So any application that runs on your swapping system
will almost certainly run on a non-swapping system. If you'd been
arguing about virtual memory instead of swapping, your initial
assumption (the ability to ignore memory limitations) would have been
true. But the conclusion is still false.
The ability to ignore memory limitation just leads to lots of
programmers who ignore memory limitations. The result is usually
larger, slower code to do the same thing that a non-vm system would
do, and enormous code with lots-and-lots of features.
There are programmers - and programming environments - that can really
benefit from vm. But they tend to be few and far between, and capable
of doing things with small memories that are beyond mere mortals and
simple programming environments.
<Of course swapping on the Amiga is a pretty problematical thing... and, also
<of course, nobody says that AmigaUNIX has to support it. Minix doesn't, for
<example, and it's a pretty close implementation of V7 UNIX.
Right, an Amiga unix port doesn't have to swap. But if you throw out
the nifty message-passing exec for the unix monolithic monitor, I
don't really want the result. The Minix approach is much better. Build
a good OS, using what the last 15 years have taught us about OS
design, and put libraries on top of that to emulate Unix.
<I often want to "swap" deluxe paint to disk while I run
<something else. Gobs of memory would do as well, but I don't have it.
So the Unix approach to high performance (throw resources at it until
it's fast) would work on the Amiga. But that works on anything.
<mike
--
ICUROK2C, ICUROK2. Mike Meyer
ICUROK2C, ICWR2. mwm@berkeley.edu
URAQT, I WANT U2. ucbvax!mwm
OO2EZ, I WANT U2. mwm@ucbjade.BITNETfnf@mcdsun.UUCP (Fred Fish) (07/04/87)
In article <4237@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) writes: >The ability to ignore memory limitation just leads to lots of >programmers who ignore memory limitations. The result is usually >larger, slower code to do the same thing that a non-vm system would >do, and enormous code with lots-and-lots of features. I have a direct counter-example. A couple months ago, as part of an internal research project where we needed to have the Unix linker do something that it was never intended to do, I completely rewrote the COFF SVR3 linker from scratch. One of the basic assumptions was a virtual memory environment were I could just suck all the required files into memory at once, do the link (and our other stuff) and write out the executable (single read/write calls for each file). The resulting linker is four times smaller than the standard COFF linker and anywhere between 4-10 times faster depending upon the sizes and number of the files linked. The original COFF linker (written for a non-vm environment) is far too feature laden, complex, and slow. -Fred -- = Drug tests; just say *NO*! = Fred Fish Motorola Computer Division, 3013 S 52nd St, Tempe, Az 85282 USA = seismo!noao!mcdsun!fnf (602) 438-5976
mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (07/06/87)
In article <330@mcdsun.UUCP> fnf@mcdsun.UUCP (Fred Fish) writes: <In article <4237@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) writes: <>The ability to ignore memory limitation just leads to lots of <>programmers who ignore memory limitations. The result is usually <>larger, slower code to do the same thing that a non-vm system would <>do, and enormous code with lots-and-lots of features. < <I have a direct counter-example. Which just goes to show that you're one of the exceptional programmers I mentioned, who can put that ability to good use. Of course, on a modern OS (as opposed to 4BFD or V the System) - like, say, Multic - you could have made it even smaller and faster. Just map the files into memory and deal with them. None of this silly stuff about reading them into memory. BTW, is there any truth to the rumor that the Cornocupia of Amiga software now has a Mac ][? Or is that just jealous Mackers spreading false rumors? <mike -- The handbrake penetrates your thigh. Mike Meyer A tear of petrol is in your eye. mwm@berkeley.edu Quick, let's make love before we die. ucbvax!mwm On warm leatherette. mwm@ucbjade.BITNET
andy@cbmvax.UUCP (Andy Finkel) (07/18/87)
In article <2334@husc6.UUCP> hadeishi@husc4.UUCP (mitsuharu hadeishi) writes: >In article <580@ucdavis.UUCP> flocchini@ucdavis.UUCP (flocchini) writes: >>I would assume that the 32-bit memory has priority when both 16 bit and 32 bit >>memory are in the system. > > I believe the memory priority is somehow determined by the order >in which the boards are added to the FAST memory list. I'm not sure >whether the autoconfig standard has a way for a board to ensure that it >gets added at the highest priority or not. I think they get added to the memory list in the order that they are found. (no priority in other words, depends on location in the card cage). Of course, you can shuffle the memory list however you want, which is the secret behind SlowMemLast, a program found on the A500/A2000 Workbench. andy -- andy finkel {ihnp4|seismo|allegra}!cbmvax!andy Commodore-Amiga, Inc. "The goal of Computer Science is to build something that will last at least until we've finished building it." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.