ebr@io.UUCP (Evan B. Ross) (02/26/88)
Is anybody using my FaccII patch to make it work with harddisks?
--
There's sparks a comin' outa' my head!!!
...!{mid-eddit,bbn}!ileaf!ebr Evan B. Ross, Interleaf, Cambridge, Ma
...!sun!sunne!ileaf!ebr (617)577-9813 x5570eric@hector.UUCP (Eric Lavitsky) (02/27/88)
In article <555@io.UUCP> ebr (Evan B. Ross) writes: > > Is anybody using my FaccII patch to make it work with harddisks? >-- > There's sparks a comin' outa' my head!!! > >...!{mid-eddit,bbn}!ileaf!ebr Evan B. Ross, Interleaf, Cambridge, Ma > ...!sun!sunne!ileaf!ebr (617)577-9813 x5570 We really wish you wouldn't keep hyping this because: a) Your patch overwrites the FaccII Copyright string this is a bad thing. it will most certainly find it's way to pirates and then to unsuspecting honest folks... b) The patch will most definitely not work with the Fast File System and... c) We certainly don't wan't calls and complaints about b since we didn't generate the patch. Use Facc for what it was intended to be - a *Floppy* Accellerator Eric ARPA: eric@topaz.rutgers.edu "Lithium is no longer available UUCP: ...{wherever!}ulysses!eric on credit..." ...{wherever!}rutgers!topaz!eric - from Buckaroo Banzai SNAIL: 34 Maplehurst Ln, Piscataway, NJ 08854
ali@polya.STANFORD.EDU (Ali Ozer) (02/27/88)
In article <10116@ulysses.homer.nj.att.com> eric@hector (Eric Lavitsky) writes: >Use Facc for what it was intended to be - a *Floppy* Accellerator What do you call a hard disk accelarator created by patching Facc? A hacc. Not in any way promoting patching Facc, Ali Ozer, ali@polya.stanford.edu
mp1u+@andrew.cmu.edu (Michael Portuesi) (03/03/88)
eric@hector.UUCP (Eric Lavitsky) writes: > Use Facc for what it was intended to be - a *Floppy* Accellerator Of course, this begs the question...Does ASDG intend to produce a FaccIII that will provide hard disk support, or a separate product (Hacc?) that is specificially intended to cache hard disk drives? Inquiring minds want to know. --M Michael Portuesi / Carnegie Mellon University ARPA/UUCP: mp1u+@andrew.cmu.edu BITNET: rainwalker@drycas "Paradise is exactly like where you are right now...only much, much better" --Laurie Anderson, "Language is a Virus"
eric@hector.UUCP (Eric Lavitsky) (03/04/88)
In article <AW=6c-y00Xo8A4y1oY@andrew.cmu.edu> mp1u+@andrew.cmu.edu.UUCP writes: > >eric@hector.UUCP (Eric Lavitsky) writes: > >> Use Facc for what it was intended to be - a *Floppy* Accellerator > >Of course, this begs the question...Does ASDG intend to produce a FaccIII that >will provide hard disk support, or a separate product (Hacc?) that is >specificially intended to cache hard disk drives? > >Inquiring minds want to know. > > --M > >Michael Portuesi / Carnegie Mellon University >ARPA/UUCP: mp1u+@andrew.cmu.edu BITNET: rainwalker@drycas With the advent of FFS it seems that such a product would be wasted effort. For most people's purposes (single fairly slow drive, few multiple task disk access and FFS with buffers), FFS will be fine. A product written for the slow file system (SFS) would not work under the FFS. If it's the ultimate in speed and preformance you want, I assume you would not hesitate to shell out the bucks for an SDP - it'll be the best choice for an Amiga network server, top end animation system etc. With the date that you can effectively run FFS on floppies being fairly far in the future, FaccII still provides an effective means of speeding up floppies and will for some time to come. Eric ARPA: eric@topaz.rutgers.edu "Lithium is no longer available UUCP: ...{wherever!}ulysses!eric on credit..." ...{wherever!}rutgers!topaz!eric - from Buckaroo Banzai SNAIL: 34 Maplehurst Ln, Piscataway, NJ 08854
ebr@io.UUCP (Evan B. Ross) (03/05/88)
In article <10132@ulysses.homer.nj.att.com> eric@hector (Eric Lavitsky) writes: >If it's the ultimate in speed and preformance you want, I assume you would not >hesitate to shell out the bucks for an SDP - it'll be the best choice for an >Amiga network server, top end animation system etc. > Two points: 1) I was under the impression that there's a 'no commercial' policy on usenet. It seems to me that most postings from the asdg folks are nothing more THAN commercials. (reminiscent of Isuzu's, I might add. ;-) 2) I've been hearing about sdp for a long time, but I haven't heard that it's ever been seen. -- There's sparks a comin' outa' my head!!! ...!{mid-eddit,bbn}!ileaf!ebr Evan B. Ross, Interleaf, Cambridge, Ma ...!sun!sunne!ileaf!ebr (617)577-9813 x5570
steveb@cbmvax.UUCP (Steve Beats) (03/07/88)
In article <10132@ulysses.homer.nj.att.com> eric@hector (Eric Lavitsky) writes: > >With the advent of FFS it seems that such a product would be wasted effort. >For most people's purposes (single fairly slow drive, few multiple task >disk access and FFS with buffers), FFS will be fine. A product written for >the slow file system (SFS) would not work under the FFS. ........ > >Eric > I beg your pardon? ANY application written for the old file system will work with FFS. Applications don't give a toss about the disk layout, they just ask for files from the disk via the filesystem. Since FFS supports all of the old packet types and returns the same results there are no compatibility problems. (Except maybe the packets come back too fast :-) Steve
eric@hector.UUCP (Eric Lavitsky) (03/08/88)
In article <558@io.UUCP> ebr@chip.UUCP (Evan B. Ross) writes: >In article <10132@ulysses.homer.nj.att.com> eric@hector (Eric Lavitsky) writes: >>If it's the ultimate in speed and preformance you want, I assume you would not >>hesitate to shell out the bucks for an SDP - it'll be the best choice for an >>Amiga network server, top end animation system etc. > >Two points: > 1) I was under the impression that there's a 'no commercial' policy > on usenet. It seems to me that most postings from the asdg folks > are nothing more THAN commercials. (reminiscent of Isuzu's, I > might add. ;-) Give me a bloody break! Pay attention to both the context and the content of the message. I was responding to questions about ASDG products - do you expect me not to take advantage of such an opportunity? I stand behind my words, the SDP is the controller most capable of dealing with multiple devices and multiple accesses, and will provide the highest throughput possible through the new FFS. Next thing you'll be telling me that Commodore can't tell you on the net how to get 1.3 when it comes out! If you want to refute or balance my message with some useful information about another product go ahead. I've never heard any information from you before - I created this bloody group, and I keep up the quality of my postings - I don't fill the net with drivel messages like "me too", or "so and so sucks", and I intend it to stay that way. > 2) I've been hearing about sdp for a long time, but I haven't heard > that it's ever been seen. It's been physically shown at both AmiExpos (NYC and LA) - the software is under way now. >-- > There's sparks a comin' outa' my head!!! It would seem so... >...!{mid-eddit,bbn}!ileaf!ebr Evan B. Ross, Interleaf, Cambridge, Ma > ...!sun!sunne!ileaf!ebr (617)577-9813 x5570 Why are people always picking on me? Eric ARPA: eric@topaz.rutgers.edu "Lithium is no longer available UUCP: ...{wherever!}ulysses!eric on credit..." ...{wherever!}rutgers!topaz!eric - from Buckaroo Banzai SNAIL: 34 Maplehurst Ln, Piscataway, NJ 08854
eric@hector.UUCP (Eric Lavitsky) (03/10/88)
In article <3422@cbmvax.UUCP> steveb@cbmvax.UUCP (Steve Beats) writes: <In article <10132@ulysses.homer.nj.att.com> eric@hector (Eric Lavitsky) writes: <> <>With the advent of FFS it seems that such a product would be wasted effort. <>For most people's purposes (single fairly slow drive, few multiple task <>disk access and FFS with buffers), FFS will be fine. A product written for <>the slow file system (SFS) would not work under the FFS. ........ <> <>Eric <> < <I beg your pardon? ANY application written for the old file system will work <with FFS. Applications don't give a toss about the disk layout, they just <ask for files from the disk via the filesystem. Since FFS supports all of <the old packet types and returns the same results there are no compatibility <problems. (Except maybe the packets come back too fast :-) < < Steve Steve - By saying "A product written for", I was referring to a "Facc product", which does give a toss about the disk layout. Sorry if there was any confusion here, I didn't mean to knock FFS in any way - looks like you did a good job with it. Eric ARPA: eric@topaz.rutgers.edu "Lithium is no longer available UUCP: ...{wherever!}ulysses!eric on credit..." ...{wherever!}rutgers!topaz!eric - from Buckaroo Banzai SNAIL: 34 Maplehurst Ln, Piscataway, NJ 08854
ericb@athertn.Atherton.COM (Eric Black) (03/11/88)
In article <3422@cbmvax.UUCP> steveb@cbmvax.UUCP (Steve Beats) writes: >In article <10132@ulysses.homer.nj.att.com> eric@hector (Eric Lavitsky) writes: >> >>For most people's purposes (single fairly slow drive, few multiple task >>disk access and FFS with buffers), FFS will be fine. A product written for >>the slow file system (SFS) would not work under the FFS. ........ > >I beg your pardon? ANY application written for the old file system will work >with FFS. Applications don't give a toss about the disk layout, they just >ask for files from the disk via the filesystem. Since FFS supports all of >the old packet types and returns the same results there are no compatibility >problems. (Except maybe the packets come back too fast :-) Hey, c'mon now! He said "product", not "application", meaning that any FaccII written to intercept calls from "SFS" won't work under FFS. Yes, applications should not know the difference. Yes, filesystem-flavored programs (such as FaccII) could reasonably be expected to be aware of the difference. This has nothing to do with whether or not the new (and breathlessly-anticipated) Fast File System is backwardly-compatible with normal user-level programs. It could very well be that Facc, lacking any special knowledge of the AmigaDOS file system, would work just fine, but FaccII knows about directory layout and such, and takes advantage of that information to make things even faster than they would be doing just a straightforward cacheing of tracks. (I'm certainly looking fo