d87-khd@sm.luth.se (Karl-Gunnar Hultland) (07/12/90)
I've finally gotten my hands on a 3000 (borrowed until my own arrives)
but I have some problems with it.
1) Does it exist a utility to DISABLE that cache memory?
Some old (and not very well written) utilities just breaks
even under 1.3 on the 3000.
2) Were can I get the NEW autodocs that should exist for 2.0
3) I MISS the GURU I've heard of a patch that'll give me my
old faithful Guru back.If it exists were can I get it.
4) If I get an old kickdisk (i.e. 1.2) will it work?
5) The final question UNIX is said to exist for A2000 but
when will it be available for the 3000.
(that ROM socket with 1.3 should be great for a UNIX ROM)
Karl
---
Karl Hultland,(d87-khd@sm.luth.se)
University of Lulea,Sweden
All political parties die at last of swallowing their own lies.
- J. Arbuthnot (1667-1735)jesup@cbmvax.commodore.com (Randell Jesup) (07/13/90)
In article <1027@tau.sm.luth.se> Karl-Gunnar Hultland <d87-khd@sm.luth.se> writes: >I've finally gotten my hands on a 3000 (borrowed until my own arrives) >but I have some problems with it. Warning: If this is a preproduction (dealer-demo) model it will not have a release version of 2.0, it will have Beta 5 (probably). The release version is signifigantly better than Beta 5, in general. >1) Does it exist a utility to DISABLE that cache memory? > Some old (and not very well written) utilities just breaks > even under 1.3 on the 3000. The caches are on the CPU (same as the 2500/030). Use SetCPU, or the 2.0 command CPU. >2) Were can I get the NEW autodocs that should exist for 2.0 Contact your local developer support manager, or ESCO. >4) If I get an old kickdisk (i.e. 1.2) will it work? I doubt it, but I don't know. >5) The final question UNIX is said to exist for A2000 but > when will it be available for the 3000. > (that ROM socket with 1.3 should be great for a UNIX ROM) Unix has not been released, nor has any date been set. In any case, it's highly unlikely to be in ROM (Unix is not small). -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
valentin@cbmvax.commodore.com (Valentin Pepelea) (07/13/90)
In article <1027@tau.sm.luth.se> Karl-Gunnar Hultland <d87-khd@sm.luth.se> writes: > >I've finally gotten my hands on a 3000 (borrowed until my own arrives) >but I have some problems with it. > >1) Does it exist a utility to DISABLE that cache memory? > Some old (and not very well written) utilities just breaks > even under 1.3 on the 3000. In the c: directory, the "cpu" command allows you to do just that. >2) Were can I get the NEW autodocs that should exist for 2.0 Contact CATS if you are a resident of Canada or the US, or your country's technical support manager if you are residing in Europe. >3) I MISS the GURU I've heard of a patch that'll give me my > old faithful Guru back. If it exists were can I get it. I have not seen one yet, but I do have a guru program written in C which displays simulated guru's on demand. It is particularly amusing to install cron and this guru generated on a colleague's machine, and see it pop up at predetermined times. :-) >4) If I get an old kickdisk (i.e. 1.2) will it work? There is no way for you to install it. >5) The final question UNIX is said to exist for A2000 but when will it be > available for the 3000. (that ROM socket with 1.3 should be great for a > UNIX ROM) Unix System V Release 4 will be available for the A3000 at the same time, it comes out for the A2500/30. No ROM socket will be needed for it. Valentin -- The Goddess of democracy? "The tyrants Name: Valentin Pepelea may distroy a statue, but they cannot Phone: (215) 431-9327 kill a god." UseNet: cbmvax!valentin@uunet.uu.net - Ancient Chinese Proverb Claimer: I not Commodore spokesman be
schur@venera.isi.edu (Sean Schur) (07/14/90)
In article <1027@tau.sm.luth.se> Karl-Gunnar Hultland <d87-khd@sm.luth.se> writes: >I've finally gotten my hands on a 3000 (borrowed until my own arrives) >but I have some problems with it. > >1) Does it exist a utility to DISABLE that cache memory? > Some old (and not very well written) utilities just breaks > even under 1.3 on the 3000. Yes, use the command "cpu" with the argument "nocache" > > Karl > >---
d87-khd@sm.luth.se (Karl-Gunnar Hultland) (07/15/90)
In article <13183@cbmvax.commodore.com> jesup@cbmvax (Randell Jesup) writes: >In article <1027@tau.sm.luth.se> Karl-Gunnar Hultland <d87-khd@sm.luth.se> writes: >>I've finally gotten my hands on a 3000 (borrowed until my own arrives) >>but I have some problems with it. > > Warning: If this is a preproduction (dealer-demo) model it will not >have a release version of 2.0, it will have Beta 5 (probably). The release >version is signifigantly better than Beta 5, in general. Beta 5???? the version command gives 36.141 and 36.68 If this is Beta when will the REAL stuff come out? I've been promised my own machine in mid August and I sure hope I'll not get a Beta version, 'cause It'll take time and money to get the final version. > >>1) Does it exist a utility to DISABLE that cache memory? >> Some old (and not very well written) utilities just breaks >> even under 1.3 on the 3000. > > The caches are on the CPU (same as the 2500/030). Use SetCPU, or >the 2.0 command CPU. Sorry if I didn't express myself clearly but I want a utility that works AFTER a boot so I can load those programs which have those crazy copy/protections that uses selfmodifying code. > >>2) Were can I get the NEW autodocs that should exist for 2.0 > > Contact your local developer support manager, or ESCO. I've called Commodore Sweden to get papers to registrate as a certified developer , so that one is solved. > >>5) The final question UNIX is said to exist for A2000 but >> when will it be available for the 3000. >> (that ROM socket with 1.3 should be great for a UNIX ROM) > > Unix has not been released, nor has any date been set. In any case, >it's highly unlikely to be in ROM (Unix is not small). > Well I've heard that the UNIX package would include hardware to restrain illegal copying. And then 512 kB ROM wouldn't be such a bad copyprotection. ( this one is from my dealer ) Karl --- Karl Hultland,(d87-khd@sm.luth.se) University of Lulea,Sweden All political parties die at last of swallowing their own lies. - J. Arbuthnot (1667-1735)
pomeroy@refine.enet.dec.com (Robert Pomeroy) (07/16/90)
In article <1028@tau.sm.luth.se>, d87-khd@sm.luth.se (Karl-Gunnar Hultland) writes... >In article <13183@cbmvax.commodore.com> jesup@cbmvax (Randell Jesup) writes: >Well I've heard that the UNIX package would include hardware >to restrain illegal copying. And then 512 kB ROM wouldn't be >such a bad copyprotection. ( this one is from my dealer ) Perhaps the 512K ROM could be used for the copy protection, but UNIX will most likely require a new Hard Drive. A friend of mine saw UNIX running on an A2000. The OS was stored on a dedicated 80 meg Quantum. bob
jesup@cbmvax.commodore.com (Randell Jesup) (07/17/90)
In article <1028@tau.sm.luth.se> Karl-Gunnar Hultland <d87-khd@tau.luth.se> writes: >In article <13183@cbmvax.commodore.com> jesup@cbmvax (Randell Jesup) writes: >>In article <1027@tau.sm.luth.se> Karl-Gunnar Hultland <d87-khd@sm.luth.se> writes: >>>I've finally gotten my hands on a 3000 (borrowed until my own arrives) >>>but I have some problems with it. >> >> Warning: If this is a preproduction (dealer-demo) model it will not >>have a release version of 2.0, it will have Beta 5 (probably). The release >>version is signifigantly better than Beta 5, in general. > >Beta 5???? >the version command gives 36.141 and 36.68 >If this is Beta when will the REAL stuff come out? 36.141 and 26.68 are the release version of 2.0. I wasn't certain what a dealer would have in Europe, since they haven't started shipping A3000's yet. >> The caches are on the CPU (same as the 2500/030). Use SetCPU, or >>the 2.0 command CPU. > >Sorry if I didn't express myself clearly but I want a utility that >works AFTER a boot so I can load those programs which have those >crazy copy/protections that uses selfmodifying code. I know of no such tool, though they could be written. >> Unix has not been released, nor has any date been set. In any case, >>it's highly unlikely to be in ROM (Unix is not small). > >Well I've heard that the UNIX package would include hardware >to restrain illegal copying. And then 512 kB ROM wouldn't be >such a bad copyprotection. ( this one is from my dealer ) Any Unix will require lots of hardware to make it useful (you need ~100 Meg of disk, ~200 is better, and a SCSI tape drive for loading release tapes, etc). As to hardware to explicitly limit copying, this seems unlikely, given the Unix market and the hardware the most Unixes require. I've never seen a Unix with explicit hardware protection. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
baeder@cadence.com (D. Scott Baeder; x299) (07/17/90)
In article <13236@cbmvax.commodore.com> jesup@cbmvax (Randell Jesup) writes: > > As to hardware to explicitly limit copying, this seems unlikely, given >the Unix market and the hardware the most Unixes require. I've never seen >a Unix with explicit hardware protection. > By hardware protection, what do you mean...For example, the SUN computers generate a UNIQUE, machine specific 32-bit number when you use the "hostid" function. While this is certainly not forced by UNIX, (ie the man page for hostid just says it should be unique on a network) this philosophy of causing the hostid to be fixed by the boot rom was also adopted by NeXT when the went from rev 0.9 to 1.0 - specifically to allow an easy way for vendors to license their software. Scott Baeder baeder@cadence.com .standard disclaimer.
peter@sugar.hackercorp.com (Peter da Silva) (07/18/90)
In article <13236@cbmvax.commodore.com> jesup@cbmvax (Randell Jesup) writes: > Any Unix will require lots of hardware to make it useful (you need > ~100 Meg of disk, ~200 is better, and a SCSI tape drive for loading > release tapes, etc). 40 Meg is plenty for UNIX, a swap device, and a small (say, 5 meg) user area. 80 Meg is nicer. Loading software from floppies and backing up to same is no more of a pain than loading or backing up a similar amount on (say) AmigaOS. Now if you're talking about what *Commodore's* UNIX requires, that's fine, but I've done plenty of useful work with System V.3.2 on a single 40 Meg drive. If AMIX needs more than that you'll have a hell of a time competing with the 386 clone world. Older versions have been quite frugal. I remember a PC/XT with a 20 Meg under Xenix Version 7... I had nearly half the disk free for user files. > I've never seen a Unix with explicit hardware protection. For*Pro on the Fortune 32/16. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
daveh@cbmvax.commodore.com (Dave Haynie) (07/19/90)
In article <6055@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <13236@cbmvax.commodore.com> jesup@cbmvax (Randell Jesup) writes: >> Any Unix will require lots of hardware to make it useful (you need >> ~100 Meg of disk, ~200 is better, and a SCSI tape drive for loading >> release tapes, etc). >40 Meg is plenty for UNIX, a swap device, and a small (say, 5 meg) user area. What can you really do in 5 Megs? Sure, that's enough space for a bit of wordprocessing, but certainly not enough for serious Desktop Publishing. Not to mention any CAD work, or even programming on a medium sized C program. As long as your programs aren't very large. The NeXT folk, who do seem to run pretty large executable/data spaces, are using a 40 Meg drive just for swap space. >80 Meg is nicer. That's about minimally acceptible for a system that's actually going to be used. >Now if you're talking about what *Commodore's* UNIX requires, that's fine, but >I've done plenty of useful work with System V.3.2 on a single 40 Meg drive. If >AMIX needs more than that you'll have a hell of a time competing with the 386 >clone world. However, I have yet to play with a System V.4 on a Clone, either. Most of them are V.3.2 and very little else. Certainly these vendors will _sell_ you NFS, X and Motif, some Berkeley tools, etc. to bring you up to the level of a V.4, but then you're not running on a 40 Meg drive with 2 Meg of RAM anymore. Randell's thinking of the full system here, not a subset. Modern UNIX ain't small. >Older versions have been quite frugal. I remember a PC/XT with a 20 Meg under >Xenix Version 7... I had nearly half the disk free for user files. And I have this rather smallish AmigaOS here on my office system, with 180 megs, and have about 80 megs free at the moment. And I'm not working with video stuff or anything like that. What does the actual OS part of this really take up, 2 megs or so. But then you add in the good PD stuff, a couple of commercial applications, NFS, custom applications, some source code directories, the chip simulation data I'm working on now, etc. and little old AmigaOS starts eating disk space. It's not going to be any different under UNIX, only the OS (which of course includes things I don't have in the AmigaOS right now like on-line documentation) is larger. If all you're using the system for is a bit of wordprocessing, then a small hard disk will be just dandy. But if that's it, why even bother with UNIX. A small disk only makes sense in a network environment, where the central file server has a large disk to make up for it. >Peter da Silva. `-_-' ><peter@sugar.hackercorp.com>. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "I have been given the freedom to do as I see fit" -REM
xrtnt@amarna.gsfc.nasa.gov (Nigel Tzeng) (07/19/90)
In article <6055@sugar.hackercorp.com>, peter@sugar.hackercorp.com (Peter da Silva) writes... ^In article <13236@cbmvax.commodore.com> jesup@cbmvax (Randell Jesup) writes: ^> Any Unix will require lots of hardware to make it useful (you need ^> ~100 Meg of disk, ~200 is better, and a SCSI tape drive for loading ^> release tapes, etc). ^ ^40 Meg is plenty for UNIX, a swap device, and a small (say, 5 meg) user area. ^80 Meg is nicer. Loading software from floppies and backing up to same is no ^more of a pain than loading or backing up a similar amount on (say) AmigaOS. Here's a question: What kind of improvement in speed would you expect to get from using 2 40 meg drives over one 80 meg drive (drive speeds being equal)? How much disk contention occurs and would there be an easy way to check this? It would seem that sticking the swap space by itself (how much is needed?) would be best and put your system and user space on another. It may also help you juggle your budget and buy a superfast drive for the critical operations. I was curious since I may end up with a A2000 with a 2091A and a Trumpcard which will let me have a total of 4 SCSI devices (I think). I figure 1 system disk, 1 user disk, 1 Tape drive and a 44 meg syquest (or a WORM) drive should be great for UNIX. Is the 2091A a DMA type controller? ^ [descriptions of other systems deleted] ^ ^-- ^Peter da Silva. `-_-' ^<peter@sugar.hackercorp.com>. NT -------------------------------------------------------------------------------- // | Nigel Tzeng - STX Inc - NASA/GSFC COBE Project \X/ | xrtnt@amarna.gsfc.nasa.gov | Amiga | Standard Disclaimer Applies: The opinions expressed are my own.
peter@sugar.hackercorp.com (Peter da Silva) (07/19/90)
In article <2831@dftsrv.gsfc.nasa.gov> xrtnt@amarna.gsfc.nasa.gov writes: > Here's a question: What kind of improvement in speed would you expect to get > from using 2 40 meg drives over one 80 meg drive (drive speeds being equal)? I've found that 2 40 meg drives can be quite zippy, if you tune them right. You will have to do the installation a couple of times and run something that does a lot of disk I/O (compiling a few big comp.sources.unix distributions) and see what works best for you... change in I/O and CPU speed can change the balance quite a bit. In general, though, putting swap and tmp on different disks helps a lot. > It would seem that sticking the swap space by itself (how much is needed?) With 4 Meg of RAM, 8 Meg of swap was plenty. > you juggle your budget and buy a superfast drive for the critical operations. The EE/CS 11/70 at Berkeley did this, with fixed head drives. 65 users was possible, but pretty slow even for 1980. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
harald@boink.UUCP (Harald Milne) (07/20/90)
In article <13190@cbmvax.commodore.com>, valentin@cbmvax.commodore.com (Valentin Pepelea) writes: > > Unix System V Release 4 will be available for the A3000 at the same time, it > comes out for the A2500/30. No ROM socket will be needed for it. > Just out of curiosity, will unix be available for the A2500/20? I get nervous everytime I see this omission. > Valentin -- Harald Milne RISCy business uunet!ccicpg!boink!harald
lancelot@spock.UUCP (Thor Lancelot Simon) (07/21/90)
In article <13283@cbmvax.commodore.com> daveh@cbmvax (Dave Haynie) writes: >In article <6055@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >>In article <13236@cbmvax.commodore.com> jesup@cbmvax (Randell Jesup) writes: >>> Any Unix will require lots of hardware to make it useful (you need >>> ~100 Meg of disk, ~200 is better, and a SCSI tape drive for loading >>> release tapes, etc). > >>40 Meg is plenty for UNIX, a swap device, and a small (say, 5 meg) user area. > >What can you really do in 5 Megs? Sure, that's enough space for a bit of >wordprocessing, but certainly not enough for serious Desktop Publishing. >Not to mention any CAD work, or even programming on a medium sized C program. >As long as your programs aren't very large. The NeXT folk, who do seem to >run pretty large executable/data spaces, are using a 40 Meg drive just for >swap space. > And on my desk at work, I am using 48 meg for swap. DEC suggests, actually, that I use *67* meg for swap on their workstations running X. Unfortunately, they shipped our machines with a single 104-meg drive, not enough for their operating system alone. We had to jump up and down just to get 208 meg drives to hold the OS and some other niceties. And I *work* there. This does not mean that this is _A Good Thing_. I can run V7 on a PDP with a single RL02 - about 10 meg. I don't mind V7, it's rather nice after SYS V and BSD monsters. >>80 Meg is nicer. > >That's about minimally acceptible for a system that's actually going to be >used. > Oh, come on. Mark Williams Co. sells a UNIX clone called "Coherent". It has a 64K kernel. They recommend 10 meg of disk. I don't believe it'll be too useful in 10 meg, but I plan to put it on my dad's laptop with 40. UNIX is beautiful because it's SMALL. I should NOT have to pay 1/2 the cost of the machine for disk to run the OS. Shared libraries are a step in the right direction, as are streams, but a SunOS kernel has those and is 600K - I suppose V.4 comes in around there somewhere. What is the world coming to? (1/4 ;-) >>Now if you're talking about what *Commodore's* UNIX requires, that's fine, but >>I've done plenty of useful work with System V.3.2 on a single 40 Meg drive. If >>AMIX needs more than that you'll have a hell of a time competing with the 386 >>clone world. > >However, I have yet to play with a System V.4 on a Clone, either. Most of >them are V.3.2 and very little else. Certainly these vendors will _sell_ >you NFS, X and Motif, some Berkeley tools, etc. to bring you up to the level >of a V.4, but then you're not running on a 40 Meg drive with 2 Meg of RAM >anymore. Randell's thinking of the full system here, not a subset. Modern >UNIX ain't small. > Then "Modern UNIX" ain't UNIX. UNIX = small. LARGE = something else. Swap doesn't count, and neither does X windows or applications for this purpose, but today's UNIXes take up far too much disk space for just the heart of the system. Where's a AMIX system come in with and without the manuals? I bet it's about 30 meg or so without, and 40 with? Am I way too high? I hope so. Am I way too low? Please, I hope not. I had hoped Commodore, who could fit most of the functionality of UNIX into AmigaDOS, could squeeze the beast down to size some. But That's nto really fair, I suppose. >>Older versions have been quite frugal. I remember a PC/XT with a 20 Meg under >>Xenix Version 7... I had nearly half the disk free for user files. > >And I have this rather smallish AmigaOS here on my office system, with 180 >megs, and have about 80 megs free at the moment. And I'm not working with >video stuff or anything like that. What does the actual OS part of this >really take up, 2 megs or so. But then you add in the good PD stuff, a >couple of commercial applications, NFS, custom applications, some source code >directories, the chip simulation data I'm working on now, etc. and little old >AmigaOS starts eating disk space. It's not going to be any different under >UNIX, only the OS (which of course includes things I don't have in the AmigaOS >right now like on-line documentation) is larger. If all you're using the >system for is a bit of wordprocessing, then a small hard disk will be just >dandy. But if that's it, why even bother with UNIX. A small disk only makes >sense in a network environment, where the central file server has a large >disk to make up for it. > Because disks cost a lot of money. And using or managing a large, ponderous system like UNIX could well become is unpleasant. UNIX is called UNix because it is MULTics made simple. I wish it had stayed that way. I don't fault Commodore for offering UNIX - I applaud them, I like UNIX, even its oversized modern incarnations. I just wih they could have cut it down to size a bit. And the reason that people still use UNIX when they're cramped for space or are only doing a bit of wordprocessing is because enough of its original personality remains to make it fun to use. >>Peter da Silva. `-_-' >><peter@sugar.hackercorp.com>. > > >-- >Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" > {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy > "I have been given the freedom to do as I see fit" -REM ******************************************************************************* *Thor Simon * Okay, just a little pin-prick...There'll be no more-* *lancelot@spock.UUCP * Aieeeeaaaugh!-but you may feel a little _sick_. * *uunet!hsi!yale!lancelot* ---Pink Floyd *
daveh@cbmvax.commodore.com (Dave Haynie) (07/21/90)
In article <1990Jul20.234155.27729@spock.UUCP> lancelot@spock.UUCP (Thor Lancelot Simon) writes: >In article <13283@cbmvax.commodore.com> daveh@cbmvax (Dave Haynie) writes: >>In article <6055@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >>>In article <13236@cbmvax.commodore.com> jesup@cbmvax (Randell Jesup) writes: >>>> Any Unix will require lots of hardware to make it useful (you need >>>> ~100 Meg of disk, ~200 is better, and a SCSI tape drive for loading >>>> release tapes, etc). >>>40 Meg is plenty for UNIX, a swap device, and a small (say, 5 meg) user area. >>What can you really do in 5 Megs? ... The NeXT folk, who do seem to >>run pretty large executable/data spaces, are using a 40 Meg drive just for >>swap space. >And on my desk at work, I am using 48 meg for swap. DEC suggests, actually, >that I use *67* meg for swap on their workstations running X. When my A3000 comes in, I may opt for 50 Megs of Real Memory. Of course, AmigaOS isn't doing virtual stuff yet. But based on practical virtual memory swap spaces, I don't see a problem. But that would just be for kicks anyway; I have yet to run out of the 9 or so megs in my A2500 setup here... >We had to jump up and down just to get 208 meg drives to hold the OS and >some other niceties. And I *work* there. But isn't that always the case. I've been trying to order an A3000 for my office for two months, and they always seem to be out of stock. All the goodies go to the customers, once the thing is finished. >I can run V7 on a PDP with a single RL02 - about 10 meg. I don't mind V7, >it's rather nice after SYS V and BSD monsters. And of course, there are V7-alikes that work just dandy on 8086s or 68000s. Which is why I always say "modern UNIX" in conjunctions with the phrase "memory pig". >>>80 Meg is nicer. >>That's about minimally acceptible for a system that's actually going to be >>used. >Oh, come on. Mark Williams Co. sells a UNIX clone called "Coherent". Yeah, we played around with that at one point. GRR could tell some real stories. The Commodore Coherent Machine, or C900, was a Z8000-based computer with monochrome megapixel display, vintage 1985 and earlier. It lost out to the Amiga, which given the growth of Zilog vs. Motorola in retrospect is a good thing. But at the time, the C900 was definitely a workstation class machine, while the original Amiga was a kick-butt personal computer. >It has a 64K kernel. They recommend 10 meg of disk. I don't believe it'll >be too useful in 10 meg, but I plan to put it on my dad's laptop with 40. >UNIX is beautiful because it's SMALL. I should NOT have to pay 1/2 the cost >of the machine for disk to run the OS. I don't think anyone's claiming that a plain UNIX is a pig. After all, UNIX did run on really expensive machines that are extremely primitive by today's high end personal computer standards. Really, a PDP-11 was almost as bad as an 80286 machine. But modern UNIX includes stuff that goes far beyond the basic kernel. Most OSs do. IMHO, UNIX gets a bit carried away. After all, just how many varients of the "cat" or "grep" command do you really need? The on-line docs also eat a bit of disk space. X is a cool idea, but it's also big. So the full-blown modern UNIX needs lots of disk space, and lots of memory. That's not to say that a stripped version needs that much more space than a V7, its just that we're all expecting it to do things that V7 never did. I mean, SVR4 incorporates a GUI. V7 never had smart terminal support at the system level. >Shared libraries are a step in the right direction, as are streams, but a >SunOS kernel has those and is 600K - I suppose V.4 comes in around there >somewhere. What is the world coming to? Remember back in the 70s, when you played with a 16K or 32K computer, and the law that any program will expand to use all available memory applied? It still does, only they've had to get really clever about this, since it's a heck of a lot easier to eat up 32K of memory than it is to eat up 4 or 8MB. But we've had some of the best minds in the computer industry working on this problem. And thank the random factors we have! Hardware designers like me would be out of work if the software wasn't constantly outgrowing the available hardware. >Then "Modern UNIX" ain't UNIX. UNIX = small. LARGE = something else. Well, modern UNIX is UNIX, by definition -- AT&T sez it is. Of course, that's marketing talking, not philosophers. We tend to think UNIX is large and the Amiga OS is small, fast, and clever. Depends on your frame of reference. And both OSs have their place. >Where's a AMIX system come in with and without the manuals? I bet it's >about 30 meg or so without, and 40 with? Am I way too high? I hope so. Am >I way too low? Please, I hope not. I had hoped Commodore, who could fit >most of the functionality of UNIX into AmigaDOS, could squeeze the beast down >to size some. But That's nto really fair, I suppose. It isn't fair, but perhaps for other reasons. One of the main points of SVR4 is binary compatibility. So Commodore has very little choice in what they implement, because that's such a tremendous advantage that whatever it takes to run this OS, it's probably worth it if you really need UNIX over AmigaOS. >I wish it had stayed that [simple] way. Remember the Amoeba? Evolution, basically, just ain't going in the direction of _simple_, be it organisms or OSs. Can you think of any OS that has been growing smaller instead of larger? UNIX has a certain amount of architectural baggage it must carry, based on 70s thinking, in order to still be considered UNIX. Something like AmigaOS can be smaller, in some ways through more recent ideas, in other ways through optimizations that favor single users over multiple users, and that kind of thing. >And the reason that people still use UNIX when they're cramped for space or >are only doing a bit of wordprocessing is because enough of its original >personality remains to make it fun to use. That's true. My friend Ed MacK has had an Amiga for several years, programmed under AmigaOS, and still is looking for Amiga UNIX. I've been using UNIX for more years than anything else, though more at the "smart user" level than the "programmer/wizard" level. I don't have any serious complaints, and I do like some of the features, but I really prefer AmigaOS at this point. And I do have the free and clear choice. Of course, there is definitely the "big fish in a little pond" factor -- I can be a reasonable expert on a point or two of the AmigaOS and still be a hardware guy, while there's far too much competition in the race toward UNIX wizardhood. >>>Peter da Silva. `-_-' >>Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" >*Thor Simon * Okay, just a little pin-prick...There'll be no more-* If only that trip to Germany had been for this weekend instead of last... -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy The Dave Haynie branch of the New Zealand Fan Club
peter@sugar.hackercorp.com (Peter da Silva) (07/21/90)
In article <13283@cbmvax.commodore.com> daveh@cbmvax (Dave Haynie) writes: > What can you really do in 5 Megs? Sure, that's enough space for a bit of > wordprocessing, but certainly not enough for serious Desktop Publishing. > Not to mention any CAD work, or even programming on a medium sized C program. Well, I suppose C-News doesn't count as a "medium sized C program" because it *does* run in small model on an 8086. But the whole C news package is pretty big. Sure you can't run X on a 40 Meg drive, but given the sort of hoggishness that X involves that's practically a feature. > However, I have yet to play with a System V.4 on a Clone, either. Most of > them are V.3.2 and very little else. In practical terms, what does V.4 give you that V.3.2 doesn't? TCP/IP, X, and a bunch of BSD compatibility. X is a bug, not a feature, and all the TCP/IP packages come with a socket library. The rest of BSD I'd rather live without. Not to mention that I have yet to play with V.4 on an Amiga either. So far, V.4 is still only available in beta... for Commodore *or* Intel. You guys at the computer companies get to play, but you're all still vaporware. Intel keeps trying to tell us that we don't need bugs fixed: they'll be fixed in V.4. I'm beginning to think of it as an excuse instead of a release. > Randell's thinking of the full system here, not a subset. Modern > UNIX ain't small. Well that's the point, isn't it? -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
daveh@cbmvax.commodore.com (Dave Haynie) (07/24/90)
In article <6071@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >So far, V.4 is still only available in beta... for Commodore *or* Intel. You >guys at the computer companies get to play, but you're all still vaporware. Sure, we do get to play. But that's a Good Thing; if we didn't, there would all these extra bugs once the thing is released... >Intel keeps trying to tell us that we don't need bugs fixed: they'll be fixed >in V.4. I'm beginning to think of it as an excuse instead of a release. We have much the same situation with 1.3 vs. 2.0 as well. Sure, there are lots of 1.3 bugs that folks would like to see fixed. If we spend time working on the old (obselete, unsupported, antiquated, whatever) OS, the new one doesn't get written. Same problem they have with UNIX -- at some point, they have to stop most of the support of the OS that's about to be replaced to get the new one out. That's apparently why you can't get the AMIX SVR3.2 release; it would have been too difficult to launch a new (from Commodore's viewpoint) OS knowing it would be replaced within the year anyway. >> Randell's thinking of the full system here, not a subset. Modern >> UNIX ain't small. >Well that's the point, isn't it? You don't see it running on my machine, do you. I have no use for SVR3.2, either. And the lack of X (or at least some kind of graphics subsystem) isn't considered a feature if you're doing hardware work; we work in symbols, not text! >Peter da Silva. `-_-' ><peter@sugar.hackercorp.com>. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy The Dave Haynie branch of the New Zealand Fan Club
peter@sugar.hackercorp.com (Peter da Silva) (07/25/90)
In article <13386@cbmvax.commodore.com> daveh@cbmvax (Dave Haynie) writes: > Sure, we do get to play. But that's a Good Thing; if we didn't, there would > all these extra bugs once the thing is released... Makes sense. Still, you shouldn't go around saying "ours is real because I've seen it and I haven't seen Intel's". They can say the same thing about you, you know. > >Intel keeps trying to tell us that we don't need bugs fixed: they'll be fixed > >in V.4. I'm beginning to think of it as an excuse instead of a release. > We have much the same situation with 1.3 vs. 2.0 as well. Yeh, but we're not paying for a support contract with you guys. > And the lack of X (or at least some kind of graphics subsystem) isn't ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > considered a feature if you're doing hardware work; we work in symbols, not > text! I didn't say graphics were a bug. I said X was a bug. Not only is it big, but it's primitive. ALL the windows are SIMPLEREFRESH! And putting window management in the application program is just plain *sick*. It's like making the STDIO library do erase and kill processing. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
nsw@cbnewsm.att.com (Neil Weinstock) (07/26/90)
In article <6091@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: [ ... ] >I didn't say graphics were a bug. I said X was a bug. Not only is it big, but >it's primitive. ALL the windows are SIMPLEREFRESH! [ ... ] I've been educating myself about Xlib lately, and this seems like one of the really grossest things in X. I wonder how many applications know how to properly update just the damaged areas? My "favorite" thing is when you scroll a partially obscured region of a window. Blech! Why bother to scroll at all? Here's to SMARTREFRESH, - Neil --==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==-- Neil Weinstock @ AT&T Bell Labs // What was sliced bread att!edsel!nsw or nsw@edsel.att.com \X/ the greatest thing since?
nmm@apss.ab.ca (Neil McCulloch) (07/26/90)
In article <13386@cbmvax.commodore.com>, daveh@cbmvax.commodore.com (Dave Haynie) writes: > If we spend time working on > the old (obselete, unsupported, antiquated, whatever) OS, the new one doesn't > get written. I'll buy unsupported only. 1.3 is neither obselete nor antiquated. While one can argue the semantics (let's have another flame fest...) back and forth, calling an upgraded OS like 1.3 obselete and antiquated is plain rhetoric, probably to justify the fact that it is probably no longer cost effective to support it. Since 2.0 only runs on the 3000 as yet, I have to wonder how all those 2[05]00 owners feel about having an obselete, unsupported and antiquated OS? Seriously, I'm concerned that this all or nothing approach to upgrades might become prevalent. It implies that design decisions may be taken that ignore optimum life-cycle for the small system owner. To whit: the investment of 4-5 K over 3-5 years. neil
daveh@cbmvax.commodore.com (Dave Haynie) (07/27/90)
In article <1990Jul25.224140.24184@cbnewsm.att.com> nsw@cbnewsm.att.com (Neil Weinstock) writes: >In article <6091@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >>I didn't say graphics were a bug. I said X was a bug. Not only is it big, but >>it's primitive. ALL the windows are SIMPLEREFRESH! >I've been educating myself about Xlib lately, and this seems like one of the >really grossest things in X. I wonder how many applications know how to >properly update just the damaged areas? >My "favorite" thing is when you scroll a partially obscured region of a window. >Blech! Why bother to scroll at all? >Here's to SMARTREFRESH, Well, that flaw in X is certainly a flaw. Its also a flaw in the Macintosh windowing system, which also handles only SIMPLEREFRESH windows (unless they have fixed that recently). Something that needs to be updated in both of these systems. However, at least X has something that we don't have; a client-server model. So, for example, my X client on my Amiga here can talk to an X program though the server on a VAX or Apollo. What this means is that, while the actual program runs on the VAX or Apollo, my Amiga is doing all the display work. This is why you have X Terminals in the first place; X can work over a network just like smart terminals (eg, VTxxx, Concept, that ilk) work over a serial line. If the basic Amiga display system worked like X does, you wouldn't worry about things like AUX: for dialing it; you could dial in or direct connect to your A2500, A3000, or whatever high speed server and still do all the display work on that puny A500 on your desk, for example. I think, as you look over most areas of reasonably new technology, each particular instance has a better idea than most others (the Mac's area of strength is its fast, device independent graphics kernel), but tends to miss the strengths of the competing systems. But as far as graphics goes, we're still at best at the second generation of GUIs, perhaps still the first PC-based generation. I really don't know how you calculate generations, only that we're only NOW at the point where different GUIs are picking up ideas from one another. And Graphics isn't everything. Let's think about system-level mathematics for a moment. Most systems are at generation 1. The Amiga might be at generation 2, but the alternate systems (FFP vs. IEEE) has held this back. We still aren't at generation 3, which, like the Mac graphics subsystem, supports device independent mathematics at a high enough level for this to actually work. If you sit down for a moment, you can probably think of all kinds of stuff that's still pretty primitive on "modern" PC operating systems. All it takes is suspension of "The Programmer" in you for a moment or two; "The Programmer" is the guy who's happy with The Way Things Are and just wants to use these things. Me, I'm never happy with computers. Humanity does seem to have Beer pretty well nailed down, but computer; forget it. They're just starting to get usable.... > - Neil -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy The Dave Haynie branch of the New Zealand Fan Club
rimajpuz@watsol.uwaterloo.ca (Rick I. Majpruz) (07/27/90)
In article <6100@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes:
Do does NeWS, *without* forcing the application to duplicate 300K of what
should be server code. I know about the X/NeWS bit, but would it be too much
to ask to be able to dump the X half of it if you don't want it?
With shared libraries the object code can be loaded at runtime. And a
given piece of object code is loaded only once no matter how many
applications use it.
I have been using the Athena widgets on the Sun/4 which has sharable
libraries. The `hello world' program using the Athena widgets is only a
half a dozen lines of code but is 560K when all the library object code
is loaded by the cc linker. But by compiling with sharable libraries,
the executable is only 48K. This compares with 32K for the stdio `hello
world': apparently Sun O/S uses 16K segments in the executables.
I haven't done any programming on the Amiga yet, but I am told that it
too has sharable libraries. Hopefully the person porting X to the Amiga
will take advantage of this fact. So my question to people using X on
the Amiga is: how big is the executable of the hello world program
(using, I assume, the Motif widgets)? Is it a tiny 50 bytes or so?
Could you post the X hello world for the Amiga so that I can compare it
to what I'm using now?peter@sugar.hackercorp.com (Peter da Silva) (07/27/90)
In article <13456@cbmvax.commodore.com> daveh@cbmvax (Dave Haynie) writes: > However, at least X has something that we don't have; a client-server model. Do does NeWS, *without* forcing the application to duplicate 300K of what should be server code. I know about the X/NeWS bit, but would it be too much to ask to be able to dump the X half of it if you don't want it? > Humanity does seem > to have Beer pretty well nailed down, but computer; forget it. Humanity may have Beer nailed down, but America is *just* starting to figure it out. Yank beer is so bad that even Fosters seems good by comparison. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
dale@cbmvax.commodore.com (Dale Luck - Amiga) (07/28/90)
In article <13456@cbmvax.commodore.com> daveh@cbmvax (Dave Haynie) writes: >In article <1990Jul25.224140.24184@cbnewsm.att.com> nsw@cbnewsm.att.com (Neil Weinstock) writes: >>In article <6091@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >>>I didn't say graphics were a bug. I said X was a bug. Not only is it big, but >>>it's primitive. ALL the windows are SIMPLEREFRESH! NOT TRUE! > >>I've been educating myself about Xlib lately, and this seems like one of the >>really grossest things in X. I wonder how many applications know how to >>properly update just the damaged areas? >>Here's to SMARTREFRESH, > >Well, that flaw in X is certainly a flaw. Its also a flaw in the Macintosh >windowing system, which also handles only SIMPLEREFRESH windows (unless they >have fixed that recently). Something that needs to be updated in both of >these systems. > Most X implementations do support SMARTREFRESH like capabilities. MIT only says you can't depend on it being there if you want your product to be completely transportable to all other servers. However if your applications depend on COLOR or other capabilities of X11 that are not universally available on all machines (another one is speed) then you have the same problem. SMARTREFRESH is a very nice feature and applications may depend on it. All they need to do is say so in the sales literature so that the customer makes sure their Xterminals/workstations have the required set of features to support that application. Dale Luck GfxBase (moving back to California this weekend)
soh@shiva.trl.oz (kam hung soh) (07/31/90)
In article <6091@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >I didn't say graphics were a bug. I said X was a bug. Not only is it big, but >it's primitive. ALL the windows are SIMPLEREFRESH! And putting window >management in the application program is just plain *sick*. It's like making >the STDIO library do erase and kill processing. Duuh ... don't want to start a big argument, but I believe all X applications have to cater for a redraw in case the X server cannot find enough backing store to save the obscured part of the window. Sure, it's a real pain doing your own redraw; if your friendly system operator can optimise the server, fine. Else, you have to provide redraw facilities. Soh, Kam Hung email: h.soh@trl.oz.au tel: +61 03 541 6403 Telecom Research Laboratories, P.O. Box 249, Clayton, Victoria 3168, Australia
peter@sugar.hackercorp.com (Peter da Silva) (08/02/90)
In article <13489@cbmvax.commodore.com> dale@cbmvax (Dale Luck - Amiga) writes: > Most X implementations do support SMARTREFRESH like capabilities. ^^^^ vvvvvvvvvvvvvvvvvv ^^^^ <--- important words > MIT only says you can't depend on it being there if you want your > product to be completely transportable to all other servers. Or even reliably on a given server, since it is legal for any server to ignore the backing-store hint if it starts getting low on RAM. SO, your program has to redundantly include all the simple-refresh-style code to handle expose events anyway. And that is really dumb: a window should be able to be treated as a virtual screen. Expecting a program to handle its own expose events is like expecting it to handle its own page faults. It's a nice option to have available, but it sure adds a lot of un-needed complexity. Expecting a program to handle its own menus is like expecting it to handle erase and kill. Important to have available, but do you want to put all that code in "cat"? X requires this as well. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (08/04/90)
In article <RIMAJPUZ.90Jul27102316@watsol.uwaterloo.ca> rimajpuz@watsol.uwaterloo.ca (Rick I. Majpruz) writes: > With shared libraries the object code can be loaded at runtime. And a > given piece of object code is loaded only once no matter how many > applications use it. Well, with a minimum of one copy per client node. And the application on the client is still responsible for managing update events, menus, and so on. Must be fun in a compute-intensive program. > But by compiling with sharable libraries, > the executable is only 48K. This compares with 32K for the stdio `hello > world': apparently Sun O/S uses 16K segments in the executables. So the stdio "hello world" would be smaller if it didn't use shared libraries? What an odd result, but I suppose it makes sense. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
dac@runxtsa.runx.oz.au (Andrew Clayton) (08/10/90)
Ok, I know people are loath to speculate on things that go 'whir' in a machine, but I've got this problem, and would like some advice. A few days ago, I did a RENAME operation on a file, and my Miniscribe 71Mb HD went into never never land. The drive access light went through a cycle of three short flickers, and one hard on light, for about a second, repeated ad nauseum. I thought it was verifying the disk or something, after some unexplained error. I left it alone for 15 minutes, but on return, it was still doing it. The mouse pointer still moved, but I couldn't initiate other tasks from the meny bar, nor did the Popcli spawn off a shell when I requested it. Effectively, I had a dead system. I gave it the three finger salute [Ctrl Amiga-Amiga] *and the drive kept on being accessed*. I then turned off the machine, and waited 15 seconds, and turned it back on - instead of the characteristic Miniscribe 'whirr, whirr, clunk' initialisation it went straight into the previously described 'flick flick flick, hard on' cycle of activation. As far as I could tell, there was no HD head movement occuring [with the A2000's fan, and two hard drives running, its hard to hear the phone, never mind a single seek operation in a HD! :-)]. The machine would not boot from the Rodime, and I started to panic. I turned it off again, waited 30 seconds, turned it on, and still no joy. I said a few rude words, in a loud voice. After leaving it off for five or so minutes, I tried again, and was greeted with the familiar 'whirr whirr clunk' Miniscribe initialisation sequence, and everything is fine. The machine booted up of the Rodime, and on accessing FH1: I got no verification error. I read all the files [copy #? to Null:] and got no read errors on the device. I'm at a loss to explain what happened. The file I attempted to rename was not renamed, and to avoid any problems, I just deleted it. Now, two days later, the drive has started to make seemingly random 'head seek's' without any HD activation light showing. There is no cycle, it just goes 'whirr' every now and again. The first two times, I checked the drive with 'dir fh1: all', with no problems. It's happened twice since then, in the past two hours, and I'm hoping if I ignore it, it will go away. This is a ST506 Miniscribe 3085 71M MFM drive, running off a 2090A commodore HD SCSI/ST506 disk controller, which also supports a Rodime 44Mb drive. I have been using the Miniscribe without any problems at all for the past 18 months or so, when it was suitably interfaced to my A1000. On the A1000 it was positioned sideways [drive on edge], in the A2000 it is positioned horizontally in the 5.25" bay provided. Has anyone got any clues as to what is occurring [esp. people with Miniscribe drives who know what I mean by my cutesy 'whirr whirr clunk' initialisation description] I checked for virii. Multiple ways. I would greatly appreciate some advice. Addendum: This evening the drive spontaneously went into remission. With its 'flick flick HARD' activity light going. I was sure nothing was being done - my Amiga was sitting still, whilst I was reading all about Un*x so that I could get up to speed on using RUNX and ACSnet. Since I hadn't been doing anything to the drive, I tried a few 'dirs' and things, but only succeeded in getting the stuff from some drive buffers. When I attempted to write something to the drive, my machine locked up. [Mouse pointer moves, but no I/O possible on either hard drive, or floppie.] After turning my Amiga off and back on again, I was back in action. On a wild hunch [and this is totally unsubstantiated, so don't accuse me of rumour mongering - yet! :-)], I decided to remove the MSH Messyfilehandler and messyfilesystem as well as the MSH mountlist entry, and reboot. That was something like three hours ago. My Miniscribe drive hasn't been making any random 'seek' noises since then, and it seems to have fixed the problem. So: Conjecture would point to MSH, as the variable which caused this weird and wonderful circumstance to occur. File under 'weird', eh! Salient information. A2500/20 2Mb 32bit wide memory. 4Mb of Fast memory on Microbotics 8UP! card, 1Mbyte CHIP ram, software running at time of crash: Workbench, Popcli III, FleetCheck, Cygnus Ed Professional, Amiga_shell [NEWCON: device]. Any explanations welcome. _l _ _ Andrew Clayton. I post . (_](_l(_ Canberra. Australia. . . I am.
mrr@mrsoft.Newport.RI.US (Mark Rinfret) (08/14/90)
>In article <2152@runxtsa.runx.oz.au> dac@runxtsa.runx.oz.au (Andrew Clayton) writes: > >Ok, I know people are loath to speculate on things that go 'whir' >in a machine, but I've got this problem, and would like some >advice. > >A few days ago, I did a RENAME operation on a file, and my >Miniscribe 71Mb HD went into never never land. The drive access >light went through a cycle of three short flickers, and one hard ^^^^^^^^^^^^ >on light, for about a second, repeated ad nauseum. ^^^^^^^^ It's quite obvious, you caused your disk drive to experience "sexual overload". :-) Mark -- ################################################################# # Mark R. Rinfret, MRSoft Home: 401-846-7639 # # mrr@mrsoft, galaxia!mrsoft!mrr Work: 401-849-9930 x301 # #################################################################