olle@isagel.sunet.se (Olle Nilsson at ISAGEL.SUNET.SE) (07/20/88)
I have done some work with 4D (Fourth Dimension) for the Mac and found some
features/bugs and suggestions for improvement. I think this database handler
is excellent, but there are still a few things to fix...
(By the way, I have version 1.0.4, and use it on MacII/SE/+ machines with 1
meg RAM under system release 5.0)
1. Included layouts. Database structure: I have one file with two or more sub-
files. Application: I want to display two different included layouts from two
different subfiles in one parent layout. This is not possible. 4D will only
show the layout and its data for the currently selected included layout. The
other included layouts on the parent layout are all erased from data and even
erased from the layout itself. Only a blank rectangular space gives you a
painful reminder that there should have been more data on the screen then is
actually displayed...
I don't like this. It can be considered a bug or a feature but I would really
like to have it fixed. I can't see any reason for displaying only one included
layout at a time. Limitations in programs annoy me, and limitations in develop-
ers packages gives me an *outburst* of anger.
Perhaps is it possible to solve the problem by changing the structure of the
database and use linked fields, but as I said, I hate limitations.
2. Speed of picture handling. It's PAINFULLY slow! Is this going to be speeded
up? I sure hope so, because just to move a reasonably sized picture in a picture
data field takes some 1 sec (!!!) between screen updates even on a MacII.
3. Memory limitations. On the MacII I have noticed that if you set the mapping
of your colour screen to 256 bits, every now and then you get "Memory Almost
Full, Please Quit As Soon As Possible" messages. This is fixed if you turn the
mapping to 2 bits. Why is this? Bug to correct?
I have also noticed that this memory problem occurs with a few other programs,
and what bothers me is that I don't understand it. The picture memory is
separate from the 1 meg RAM - right? (The capsules for the screen memory is
on the video card.) So why does a larger screen bit mapping cause RAM memory
problems? My intuition tells me that perhaps is some data (that grows larger
with the number of colours to display) needed to be stored in the 1meg RAM to
"configure" the video card. (Excuase my somewhat unclear "model" for the pheno-
menon) - Can anyone comment on this?
4. Global Procedures (speed of). Can thay be made to run faster? Optimizations?
One solution is of course to use external procedures, but life sure would be
simpler if this was unneccessary. My major problem, is to read data files with
"4D-Talk" (4D's programming language) and this is really slow. (I have enorm-
ousely large data files, and many of them too...)
5. Importing pictures to 4D. How is this done in a smart way? Say that I have
some 20 picures to store in my database. I don't want to cut and past in all
these pictures manually via the clipboard. So what do I do? Has anyone done
anything about this problem? Perhaps written an extarnal procedure that reads
pictures form the clipboard or a file and puts them into picture fields in some
predefined 4D-database? Postings please!?!
* * * * * And NOW to some serious FLWAS in 4D! * * * * *
* * * * * Saving the best part to the end, eh? * * * * *
6. Text fields. Really annoying in one of my applications! You cannot use more
then one font at a time with text field data. (Defined in your output layout)
But I HAVE to enter/store/display more then one type of font in a text field,
and furtermore I have to be able to itlicize, boldface, (and preferably even
shift up and down) parts of the text. In other words do some basic(?) word
processing with the text and then store it with all its "features" in a 4D-text
field.
(Yes, I want all text in one text field without having to add mark-characters
for italics e.t.c. for words or characters that are supposed to have these
"features".) and then do a lot of text 4D-Talk processing/displaying in the
layout. It should be (made) possible to do this without having to do tons of
work, don't you agree? I mean we're really talking Mac here, WYSIWYG, The Human
Interface e.t.c. You should be able to create database applications that are so
similar to ordianary Mac programs that the end user couldn't see any difference.
I really NEED this. Perhaps can it for some sordid reason not be done with
"normal" text fields? But then, perhaps is it time to create a new field type
in 4D for this purpose? Why not an EDIT-field or a WORDPROC-field?
Can this perhaps be implemented in an update? (How about it Laurent Ribardiere
ACIUS?) Any suggestions to circumvent this problem until then?
* * * * * This item concerns not only 4D * * * * *
7. Run-Time modules. Why stick to this "by one at a time" model? Can one get
an unlimited Run-Time Module licence for 4D? Whitout paying MegaBucks? I think
the cost for a module is ridiculously high here in Sweden. Some +100$ a piece.
Far too high. I believe in selling reasonably priced software. An application
should not have to cost more then maximum some 100$ even if it is complex, and
100$ - 100$ = 0$ (No profit = I starve to Death)
If the prices are too high, pirate copying will flourish. That's my view of
realities.
Can one get a Free licence for distribution of non profit scientific databases
using 4D?
________________________________________________________________________________
____ . Olle Nilsson
/ / . Dept. of Molecular Biology, University of Stockholm, Sweden
/___/ o . OLLE@ISAGEL.SUNET.SE (@SEKTH.BITNET)
________________________________________________________________________________chuq@plaid.Sun.COM (Chuq Von Rospach) (07/24/88)
>(By the way, I have version 1.0.4, and use it on MacII/SE/+ machines with 1 >meg RAM under system release 5.0) The current version is 1.0.6. Registered users can get a free upgrade from Acius. >1. Included layouts. Database structure: I have one file with two or more sub- >files. Application: I want to display two different included layouts from two >different subfiles in one parent layout. This is not possible. Acius acknowledges this as a limitation they want to fix. >2. Speed of picture handling. It's PAINFULLY slow! Is this going to be speeded >up? Speed and optimization are primary factors behind the 1.1 release scheduled for sometime this fall. >3. Memory limitations. On the MacII I have noticed that if you set the mapping >of your colour screen to 256 bits, every now and then you get "Memory Almost >Full, Please Quit As Soon As Possible" messages. This is fixed if you turn the >mapping to 2 bits. Why is this? Bug to correct? How much memory in the Mac 2? 256 bits takes a LOT of memory. It's kind of hard to 'fix' in software a problem that's caused by a lack of hardware resources....w3 >So why does a larger screen bit mapping cause RAM memory >problems? My intuition tells me that perhaps is some data (that grows larger >with the number of colours to display) While screen memory is stored on the video board, where do you think all those 256bit deep bitmaps are created and stored before they get slogged onto the screen? >4. Global Procedures (speed of). See my 1.1 comment above. 1.1 will be faster. Much faster, by reports. >5. Importing pictures to 4D. How is this done in a smart way? I'd find someone with a CompuServe account and drop by the APPDEV SIG, where ACIUS on-line support hangs out. I'm sure someone has resolved this, but I haven't researched it personally because I don't need it (yet). >6. Text fields. Really annoying in one of my applications! You cannot use more >then one font at a time with text field data. I think this is more a TextEdit limitation than a 4D limitation, because each style change requires a new TextEdit record to be generated. In a word processor, you have to do this. In a single field in a database, you're talking about a lot of programming and overhead. >I really NEED this. Are you sure? I thought I really needed this, too. Some reasonable re-design and re-thinking let me get rid of the requirement without sacrificing anything. >7. Run-Time modules. Why stick to this "by one at a time" model? Contact Acius. They have volume discount programs. I think there may also be a site license program, but I'm not sure. >Some +100$ a piece. In the U.S., list is $75. Mail-order is even cheaper. I'd talk to your local distributors about that... And if you think about it, 4D, even at $100 for a run-time, is pretty cheap compared to some databases. I was looking at one project to see if I wanted to use FileMaker4 or 4D for it. It turns out that while the full 4D package is rather expensive, I only need one copy. With FileMaker4, I need to buy multiple copies of the full thing, which means that at between three and four active copies, 4D suddenly becomes cheaper to use. -- Chuq Von Rospach chuq@sun.COM Delphi: CHUQ I don't work for no 'Toon!
alexis@dasys1.UUCP (Alexis Rosen) (07/25/88)
Recently, Olle Nilsson (OLLE@ISAGEL.SUNET.SE) wrote: > [general praise for 4D, and some complaints] >1. Included layouts. Database structure: I have one file with two or more sub- >files. Application: I want to display two different included layouts from two >different subfiles in one parent layout. This is not possible. 4D will only >show the layout and its data for the currently selected included layout. The >other included layouts on the parent layout are all erased from data and even >erased from the layout itself. Only a blank rectangular space gives you a >painful reminder that there should have been more data on the screen then is >actually displayed... > >I don't like this. It can be considered a bug or a feature but I would really >like to have it fixed. I can't see any reason for displaying only one included >layout at a time. Limitations in programs annoy me, and limitations in >developers packages gives me an *outburst* of anger. You sound just like me. The problem with 4D is that the entire program is riddled with limitations like that: Things which ought to work, but don't. Sometimes, you get a tech note three months after figuring out the problem saying "Don't do that since it won't work." For example, "Don't delete records within sub-layouts," or, "Don't change the current record selection within 'Modify Selection'." This is not what I call good technical support! What's worse, many of these limitations are actually bugs, in that they were supposed to work, but didn't (the modify selection one is a good example). >2. Speed of picture handling. It's PAINFULLY slow! Is this going to be speeded >up? I sure hope so, because just to move a reasonably sized picture in a >picture data field takes some 1 sec (!!!) between screen updates even on a >MacII. Welcome to the wonderful slow-motion world of 4D. The word 'fast' isn't in Acius' vocabulary. In fact, if Acius ever comes through with it's upgrade to 1.1, or whatever they call it, and even if it IS six times faster, it will still be pathetically slow at most things. I could bitch about this for days, but I'll let it speak for itself. >3. Memory limitations. On the MacII I have noticed that if you set the mapping >of your colour screen to 256 bits, every now and then you get "Memory Almost >Full, Please Quit As Soon As Possible" messages. This is fixed if you turn the >mapping to 2 bits. Why is this? Bug to correct? > [ and shouldn't all the bitmaps be in the video card? ] No, this is one thing you can't fault them on. It is a property of the Mac II. While the screen pixmap is on the video card, everything else is in system RAM. The background graphics of your screens are probably kept in an off-screen pixmap in order to facilitate speedy screen refreshing. Many other programs have problems running in 8-bit mode on a 1MB Mac II for the same reason. Furthermore, you are storing pixmaps in your datafile, and those are kept in memory too when they are on an active screen. >4. Global Procedures (speed of). Can thay be made to run faster? Optimization? >One solution is of course to use external procedures, but life sure would be >simpler if this was unneccessary. My major problem, is to read data files with >"4D-Talk" (4D's programming language) and this is really slow. (I have enorm- >ousely large data files, and many of them too...) If you have medium or large files (over 10K records), don't use 4D. If you do any table-level manipulation of your data regularly, you'll die of old age waiting for it to process your data. Import and Export are particulary outrageous. >5. Importing pictures to 4D. How is this done in a smart way? Say that I have >some 20 picures to store in my database. I don't want to cut and past in all >these pictures manually via the clipboard. So what do I do? Has anyone done >anything about this problem? Perhaps written an extarnal procedure that reads >pictures form the clipboard or a file and puts them into picture fields in >some predefined 4D-database? Postings please!?! Nobody has really dealt with this well, yet. The FoxBase people are working on some neat things, but they are not quite as automatic as what you want. >6. Text fields. Really annoying in one of my applications! You cannot use more >then one font at a time with text field data. (Defined in your output layout) >[i.e. he wants the new textedit stuff to work] Well, I agree that it would be really nice, but I also know that most people don't have significant need for this (read, 'most database-buying businesspeople'). This may change in the future, but for now it is true. However, it would not be so difficult to do (Chuq says otherwise, but he may have forgotten that the new TextEdit will handle most of that automagically). That doesn't mean it would be _easy_ to do, and there are probably many things that are higher on most peoples' most-wanted-features list. >7. Run-Time modules. Why stick to this "by one at a time" model? Can one get >an unlimited Run-Time Module licence for 4D? Whitout paying MegaBucks? I think >the cost for a module is ridiculously high here in Sweden. Some +100$ a piece. >Far too high. I believe in selling reasonably priced software. An application >should not have to cost more then maximum some 100$ even if it is complex, and >100$ - 100$ = 0$ (No profit = I starve to Death) Why? Because they make more money that way. They think. I just switch to a company with a more reasonable pricing scheme. (Who? Fox, of course :-) --- Someday when I have time, I will post an article where I really trash 4D. Not a flamefest, just a point-by-point analysis describing why I think it's a miserable product for most uses. (There are some cases where it works decently well.) For now, I will just suggest that people compare 4D with programs like FileMaker 4 or FoxBase+/Mac. {Mini-flame} I really trusted Kawasaki. I paid them $700 for a product in early Beta. Then I sent them a 12 page typed memo with about 50 documented and reproduceable bugs and numerous suggestions. Two months later they release the product. It is now a year later and they have fixed ONE bug. There have been no serious upgrades. The V1.0.4 upgrade form I sent in three months ago vanished into some pit at Acius, so I have yet to see even that feeble revision. Acius is using its name to sell a product that could not long survive on its own merits anymore. The situation was different a year ago and they could afford to be lazy. Today it's a different story. {Bunsen burner off} Dropping 4D was one of the smartest moves Apple ever made. I know there are many people out there who love 4D. Some of them will probably accuse me of slandering {Acius, Kawasaki, 4D, motherhood & apple pie}. Flame all you want, but note that I use (or have used) all of these products, professionally. It's what I do to make a living. If you manage a mailing list with 4D, there's nothing wrong with that. But that's not the type of application that 4D was meant for, and that's not the kind of thing that will show 4D's flaws. I have no affiliation with Acius except as an utterly dissatisfied customer. I have no affiliation with Fox Software except as a very satisfied customer. ---- Alexis Rosen {allegra,philabs,cmcl2}!phri\ Writing from {harpo,cmcl2}!cucard!dasys1!alexis The Big Electric Cat {portal,well,sun}!hoptoad/ Public UNIX if mail fails: ...cmcl2!cucard!cunixc!abr1 Best path: uunet!dasys1!alexis
chuq@plaid.Sun.COM (Chuq Von Rospach) (07/26/88)
>However, it would not be so difficult to do (Chuq says otherwise, but he may >have forgotten that the new TextEdit will handle most of that automagically). No, I didn't forget. But to build in the new TextEdit means deciding to remove compatiblity from all the folks who haven't upgraded yet. I'm sure it'll happen down the road, but is it worth cutting off a large part of teh market for a feature that's of marginal interest? >{Mini-flame} >It is now >a year later and they have fixed ONE bug. There have been no serious upgrades. I've gotten a bunch of upgrades, including multiple copies of V1.0.6. >The V1.0.4 upgrade form I sent in three months ago vanished into some pit at >Acius, so I have yet to see even that feeble revision. Why are you bitching about it here? It amy not even be Acius' fault, you know. Occasionally, the Post Office has been known to eat mail. If you didn't get it, why didn't you call Acius and ask about it instead of doing nothing about it except getting pissed at them? It sounds to me like your looking for reasons to hate 4D. -- Chuq Von Rospach chuq@sun.COM Delphi: CHUQ I don't work for no 'Toon!
alexis@dasys1.UUCP (Alexis Rosen) (07/27/88)
In article <61371@sun.uucp> chuq@sun.UUCP (Chuq Von Rospach) writes: >>However, it would not be so difficult to do (Chuq says otherwise, but he may >>have forgotten that the new TextEdit will handle most of that automagically). > >No, I didn't forget. But to build in the new TextEdit means deciding to >remove compatiblity from all the folks who haven't upgraded yet. I'm sure >it'll happen down the road, but is it worth cutting off a large part of teh >market for a feature that's of marginal interest? You are absolutely correct. As I said, it's just not worth it now. I am not sure about the people who haven't upgraded, though. For all that we hear about system incompatibilities, most people who upgrade don't find major problems. It's not unreasonable to demand that your customers run a recent System, especially for a high-end product like 4D. >>{Mini-flame} >>It is now >>a year later and they have fixed ONE bug. There have been no serious upgrades. > >I've gotten a bunch of upgrades, including multiple copies of V1.0.6. Right. But I said, "serious upgrade." That implies changes in functionality, better speed, support for new system features, or SOMETHING nice. What did they fix in V1.0.4? Four Bugs. Three MINOR bugs and one _really nasty_ bug in the file-repair utility that they should have nailed long ago. What did V1.0.6 fix? Incompatibility with System 6.0. Certain other databases were not only compatible with 6.0, but were able to use features like the Notification Manager long before System 6.0 actually shipped. Why did they take so long to announce 1.0.6? They could have had it ready a week _before_ 6.0 arrived. I wouldn't be so annoyed if they were improving the product in any way, but they are just so lazy! >>The V1.0.4 upgrade form I sent in three months ago vanished into some pit at >>Acius, so I have yet to see even that feeble revision. > >Why are you bitching about it here? It amy not even be Acius' fault, you >know. Occasionally, the Post Office has been known to eat mail. If you >didn't get it, why didn't you call Acius and ask about it instead of doing >nothing about it except getting pissed at them? I'm too busy to fill out more of their damn forms. As a beta site, the most I should have had to do was call and ask for it. Instead, I have to wait two weeks for the upgrade request form, mail it in, prove I own a copy (they lost the ownership records for early purchasers)... And then they lose my upgrade? Forget it. I just copied someone else's upgrade. >It sounds to me like your looking for reasons to hate 4D. Nah... I've got more of those than I know what to do with: Alexis's Top Ten Reasons To Hate 4D (if D. Letterman can do it, why not I?) 1) S L O W speed. Pathetically slow, everywhere. 2) Keeps all logical files in one physical file (can't distribute over net) 3) Report Footers cover up detail lines. This is a really nasty bug. 4) Modality. Why can't I have code and data on screen at the same time??? 5) Screen refresh bugs. Lots of them. 6) Lousy reports. Needs too much code. Headers, detail, footers each have a constant, unchangeable length. 7) No run-time indexing. In fact, no programmable modification of the database structure at all. No permanent sorts. 8) Fragile language. Many reasonable-seeming things are arbitrarily forbidden, like deleteing from an included layout, or modifying the selection in 'Modify Selection' 9) No multiple active windows under program control. Other arbitrary restrictions. 10) Poor control with atomic data-entry commands. ... plus about a hundred more that didn't make the list today. It is true that there are a few good things about 4D, and a few applications for which it is quite good (but other products are quickly catching up). However, I'm so disgusted with the product that I'll leave the job of praising it to other people... >-- >Chuq Von Rospach chuq@sun.COM Delphi: CHUQ ---- Alexis Rosen {allegra,philabs,cmcl2}!phri\ Writing from {harpo,cmcl2}!cucard!dasys1!alexis The Big Electric Cat {portal,well,sun}!hoptoad/ Public UNIX if mail fails: ...cmcl2!cucard!cunixc!abr1 Best path: uunet!dasys1!alexis
spector@vx2.GBA.NYU.EDU (David HM Spector) (07/31/88)
Well, I can't go all the way in bashing 4D, but the level of ACIUS
worship that goes on on CompuServe, and elsewhere isn't warranted either.
Their Tech support is very responsive, and they seem to get quite a workout
from their customers (myself included), but this would suggest to me that there
are a number of shortcomings in a product that needs so much technical support,
and with which people have a hard time getting started with. The 4D manuals
are of very little use. They are badly written and offer very little helpful
advise and almost no information about writing custom applications.
4D, if you have the time to spend, can be used to develope some _very_
impressive applications. MiniFans is a good example. But, unless you are Dave
Dell'Aquila, time unfortunately is measured here in geologic scale..
I have been working with 4D for quite a few months, and I am not overly fond of
it... but ACIUS has the advantage in that they are the only game in town right
now, no one else offers a database system with as many features or capabilities
as 4D... but the development time will kill you (see above) if you have dead-
lines.
I will agree about the ACIUS attitude though. I regularly use CompuServe to
read things in the ACIUS forum, and I get really P.O.'d when I see
things marked "IMPORT ACIUS DEVELOPER NOTICE" in files and messages that when
downloaded turn out to be forms to send in to ACIUS to register for the latest
ACIUS ski trip or cook out. I would hate to think that all of the $695 I spent
on 4D is being spent on partying... instead of fixing the problems and
shortcomings in 4D. Then there's the ACIUS "Radio Controlled Car Fund"
which Guy Kawasaki _himself_ said in MacWeek was being used to buy radio
controlled cars for the staff to play with...
...gee, I hope they're not doing that instead of answering the phones.
4th Dimension will (may be) be a better product one day. As it stands now, its
very useful if you 1) are good using development environments with bad document
-ation 2) Don't have to work under time pressure or deadlines and/or
3) can put up with an incomplete system.
DHMS
-------------------------------------------------------------------------------
David HM Spector New York University
Senior Systems Programmer Graduate School of Business
Arpa: SPECTOR@GBA.NYU.EDU Academic Computing Center
UUCP:...!{allegra,rocky,harvard}!cmcl2!spector 90 Trinity Place, Rm C-4
HamRadio: N2BCA MCIMail: DSpector New York, New York 10006
AppleLink: D1161 CompuServe: 71260,1410 (212) 285-6080
"What computer puts out work like this?" "Hire us and we'll tell you."
XYZZYGLORPalexis@dasys1.UUCP (Alexis Rosen) (08/05/88)
In article <578@lindy.Stanford.EDU> liemandt@lindy.Stanford.EDU (Joe Liemandt) writes: >Well, Mr. Rosen (aka "the Basher") strikes again. First it was >Hypercard (unusable in its current state), then SUM (not only was >the product unusable but the programmer should be shot) and now 4th >Dimension (bad product and Acius sucks too). I guess that FoxBase is >the only good program in the whole world. I never said that HyperCard was unusable. Read the posting again. I like HC a lot. It does have some problems, though. I never said SUM was unusable either. I said that if you use the partition utility, you'll lose data. >[says he likes 4D] >I take some exception to a few (well, most actually) of your >complaints and or "suggestions". Most of them fall into the category >of not using a product like it was meant to be. Sort of like >complaining that the disk optimizer in SUM didn't work like the one >in Disk Express. [etc.] I never said anything about the disk optimizer. To paraphrase Rich Siegel (who was flaming me at the time) If you're going to flame, aim at the target... >Your complaints: > >1) Acius is lazy - This is probably the one that ticked me off >enough to write this response. Their tech support is the best I have >ever seen. They routinely work seven days a week, [etc.] They have to do so much tech support because their product is so weak and their manuals are worse than any DB manuals I have ever seen (I've seen many). Even worse than Omnis 3+'s, which were the previous champs. >You also indicated that they are not improving the product. This is >an attack on Laurent (the 23-year old genius behind 4d) and probably >stems from the fact that they have not shown you the new version >under development (I wonder why?) This new version (no release date >set) will blow you away. Has almost everything. Stop by their booth >at MacWorld and see it. I'm not attacking Laurent. I'm attacking the insane notion that one man can do all the coding to make 4D a good product. Look what happened with Blyth, trying to keep Omnis current with only one programmer in England working on it. In fact, the parallels are interesting... I'm not interested in the new version until I have it. They won't ship it because it's not ready. They promised it eight months ago. THAT's what bothers me. >3) Slow speed - This seems to be the first thing out of everyone's >mouth. 4D is slow at importing. But in everyday use, 4D is fine. It >is always nicer if a program is faster, but for entering, modifying, >and searching for data 4D is acceptable on the speed front. Acceptible? By who's standards? 4D is one of the slowest, most inefficient programs I have ever seen on ANY machine. If you disagree, tell me why. I know that my clients, no matter how much they like the Mac, will take a PC running paradox (or RBase, or Condor, or...) over a Mac running 4D, because for roughly equivalent machines, 4D is ten to a hundred times slower that the others. That's my real-world benchmark... >As far as programming, 4D's interpreter is very fast, and if for >some reason it isn't you can easily link in some C or Pascal >routines you wrote. Fast? It's about the same speed as Omnis. That makes it a couple hundred times slower than my Apple II running interpreted basic. That's rediculous! At any rate, Pascal and C cannot be used to manipulate the database. >The rest of your complaints fall into the "why doesn't 4d work like >Foxbase" category. Use 4d the way it was supposed to, work with the >product instead of fighting it and you will see its power. > >Joe Liemandt >Stanford University This is really the crux of the matter. I didn't pay $700 to program their way! I want to do it the right way. If you think I've got the time to fight with a product guess again. I will do things logically and if the program fails to perform in a reasonable manner, I've got no time to mess around (after all, I'm too busy reading netnews! :-) Instead of blind worship, try to make 4D do something really interesting. Something which involves more than a trivial amount of code and data. You can do it, if you're clever enough. But I can write ten interesting applica- tions in the same time in a better environment, such as FoxBase. They'll run better, too, and ten or a hundred times quicker. Before charging off to 4D's defense, you might also take a look at the alternatives. FoxBase is by no means perfect... but in comparison to 4D, it often feels that way... I have no affiliation with FoxBase or Acius (in case anyone has forgotten :-) ---- Alexis Rosen {allegra,philabs,cmcl2}!phri\ Writing from {harpo,cmcl2}!cucard!dasys1!alexis The Big Electric Cat {portal,well,sun}!hoptoad/ Public UNIX if mail fails: ...cmcl2!cucard!cunixc!abr1 Best path: uunet!dasys1!alexis