HDTenEightyP/NetNews huggingface dataset:
From: alex@netdev.comsys.com (Alex Huppenthal)
Newsgroups: comp.unix.sysv386
Subject: Re: FAS 2.10 async driver, part 5/5
Date: 20 Aug 92 17:41:12 GMT
Organization: Communication Systems Research Corporation


 The real problem is that Jerry has to pay for news feeds. Why is this the
case? Thousands of sites here in the US don't pay for news feeds. Is it 
long distance news feeds ? Aren't there large sites which distribute to 
smaller sites, fee-free ? Has capitalizzzm gone crazzzy ? Information for the
wealthy, and keep the poor in the dark ? 

 I'm agast that the costs are so high that cross-posts of sources hurt people
like Jerry.

 What can I do to reduce the costs of information delivery to people in Jerry's
position, that obviously must pay for something many of us take for granted.

 Jerry, can you get your feed compressed ? How about 14.4K modems, do they 
solve the problem ? What about a central news site there that distributes
the cost among many leaf sites ? Are the state controls so rigid that no one
can do this ? 

 The problem isn't Jerry or the other posters, it is the cost of *receiving*
news. The FCC specifically states that reception of broadcasts cannot be
restricted - right ?  ( here ), any chance for broadcast *news*  there ?  It is
unfortunate. More freedom...!

 Any other ideas ?

 -Alex 

 
In article <RAYMOND.92Aug20100322@cobra.es.ele.tue.nl> raymond@es.ele.tue.nl (Raymond Nijssen) writes:
>In article <103.2423@incc.com> jerry@incc.com (Jerry Rocteur) writes:
>
>>   In article <1992Aug18.180159.9122@telesys.tnet.com>, kreed@telesys.tnet.com (Kevin W. Reed) writes:
>>> davidsen@ariel.crd.GE.COM (william E Davidsen) writes:
>>> 
>>> >In article <102.26574@incc.com>, jerry@incc.com (Jerry Rocteur) writes:
>>> >| Who is the irresponsible bastard who posts large files in a non source
>>> >| newsgroup.
>
>>   First of all let me apologize for posting my complaint to alt.sources,
>>   I was so upset at the time that I did not realize that I cross posted :-(
>
>Now you see how easily humans can do things which upset other humans.
>
>>   [...] some of you who were abusive
>>   and offensive really shine the light on what I can only describe as pimply
>Now who do you think you are? You just can't stop, can you? Even so, I would
>I didn't expect you to apologize for calling Uwe a 'bastard', but I thought
>Do you never make mistakes?
>>   I just ingnored your waffle.
>Your mistakes however (insulting, crossposting) are much worse.
>The difference is that you, Jerry Rocteur, never, nowhere, no way, nohow 


-- 

Alex Huppenthal			CSR Corp.
alex@netdev.comsys.com		Dallas, Texas 75252
texsun!netdev!alex
Newsgroups: comp.unix.sysv386
From: chip@chinacat.unicom.com (Chip Rosenthal)
Subject: Re: 60nSec memory - Will 486/33 be faster?
Organization: Unicom Systems Development, Austin, TX
Date: Thu, 20 Aug 1992 06:13:22 GMT

In article <Bt91F2.2KJ@encore.com> mpalmer@encore.com (Mike Palmer) writes:
>Will a 486/33 be faster with 60nSec memory over 70 or 80nSec memory, assuming
>the data required is not in cache memory.

When the system needs to fetch information from main memory, it sends
out the memory address, tells the memory that it needs to read, and
at some time later it snarfs up the information provided by the memory.

That `some time later' is the interval in which the memory must respond.
Simply throwing in different RAM chips does not change that time.
You must assure that the RAM is fast enough to respond by that time.
If you buy RAM which is faster and responds before that time, you have
bought nothing.

>How does the CPU wait state tie into this?

This is how you define how long `some time later' is.  The more wait
states you insert, the more time you allow the memory to respond.

[warning - lots of simplification and handwaving follows]

A wait state is achieved by asserting the READY/ pin on the processor.
When asserted, the CPU simply idles along waiting for the signal to
go inactive.  This signal is used to tell the CPU to `wait up a moment'
to give slower memory a chance to respond.

When the system is configured for two wait states, the time for memory
access is stretched by two bus cycles.  That is, with zero wait states,
`some time later' is equal to one bus cycle.  With two wait states it
becomes three bus cycles.

I don't recall offhand whether a 486 bus cycle corresponds to one or
two clock cycles -- I believe it is one.  This means that with a 33MHz
clock, the bus cycle would be about 30ns.  A 486/33 system typically
runs at two wait states.  Two wait states would stretch the access
time from 30ns to 90ns.

If you cut this down to one wait state you get 60ns.  This means that
you probably cannot run the machine reliably at one wait state unless
you get 50ns or better DRAM.  Good luck!  I'd suggest sticking with
70ns DRAM and two wait states.

Note that a good motherboard design can use banked interleaving, page
mode access, and caching to mitigate the delays due to wait states.
These things don't reduce the amount of wait delays, but instead work
to reduce the number of times you invoke the penalty of wait state
delays.  Unfortunately, this is the stuff which is never documented,
and is one of the best reasons to go with some of the name brand
motherboards (e.g. Micronics) which seem to do some serious engineering
in their memory subsystems.  From what I hear, the folks at Dell also
do a good job at peecee memory architectures.

-- 
Chip Rosenthal  512-482-8260 | The secret to a long life is
Unicom Systems Development   | knowing when it's time to go.
<chip@chinacat.Unicom.COM>   |  - Michelle Shocked
Newsgroups: comp.unix.sysv386
From: kdenning@portal.hq.videocart.com (Karl Denninger)
Subject: Re: Dell SVR4 (and Dell hardware)
Summary: INTEL 486 and SPARC systems
Organization: VideOcart Inc.
Date: Tue, 18 Aug 1992 17:46:16 GMT

In article <1992Aug16.172215.17587@unixland.natick.ma.us> bill@unixland.natick.ma.us (Bill Heiser) writes:
>larry@gator.rn.com (Larry Snyder) writes:
>>grant@bluemoon.rn.com (Grant DeLorean) writes:
>>> Betcha couldn't guess what I am now running (SPARC 2)... :-}  Want
>>>to buy some ISC UNIX?
>>Don't be so quick to judge Intel based UNIX.  With the proper hardware
>>and OS an Intel machine could out do your Sparc.
>
>I think the Sparc technology is advancing faster than the PC technology.
>My 486/33 is about twice as fast as a Sun/386i and about comparable with
>a Sun Sparc/IPC (except slower on scrolling since I'm using VGA - I agree
> the proper hardware could make the 486 faster).  However using a Sun
>Sparc/*IPX* makes the 486/33 seem downright doggy!  Just compare the loading
>of a large mailbox in elm to see what I mean.

My Intel machine (486/33) is subjectively as fast if not faster than the 
Sparc 1+ I used to have on my desk at Nielsen.  It >definately< sheds load 
better with more than one user signed on.  The Sparc was a dog once you 
got more than one person going on it.

However, the Sparc can eat the Intel machine's lunch on Ethernet.  It is 
unfortunate that no one makes "real" Ethernet adapters for ISA-bus machines 
(except RACAL, and there aren't any drivers for those available for SVR4 
Unices).  The new DELL release is significantly better than before (about 
1/2 the Sparc's speed on Ethernet) but they still have a good way to go here.

I'd love to get a driver for the RACAL boards; they're busmastering, and
damn fast.  But of course you need something to talk to the OS for them to
do you any good.

This is with the same RAM (16MB) in both machines.  I have an S3-based
video board.  If you're running an ATI Ultra you'll get even better
performance (video is one of the big bottlenecks).

>Of course once the Sparc/10 (80+ mips (per processor)) hits the street,
>the INTEL line will be eating lots of dust!

Yeah, but you can't get a Sparc/10 for under $5k configured and ready to go!

--
Karl Denninger 		Inet:  kdenning@hq.videocart.com
VideOcart Inc.		Voice: (312) 987-5022
Xref: sparky comp.unix.sysv386:13390 comp.os.linux:8707
From: callison@uokmax.ecn.uoknor.edu (James P. Callison)
Newsgroups: comp.unix.sysv386,comp.xenix.misc,comp.os.linux
Subject: Re: Xenix (tm) emulation for Linux almost works :-)
Date: 20 Aug 92 17:56:16 GMT
Organization: Engineering Computer Network, University of Oklahoma, Norman, OK, USA

In article <714153102.23809@zooid.guild.org> vid@zooid.guild.org (David Mason) writes:
>From: umisef@mcshh.Hanse.DE (Bernd Meyer)
>>Well, guys, just a thought of mine - should be somhow more stable than an 
>>messy-dos emulation. MS-Windows-programs just have to use the system-calls.
>>No direct fussing around with VGA-cards, serial ports, printers and that 
>>stuff....
>>And wouldn't it be fun, just running MS-Winword withhout MS-Windows (Hehe,
>>Bill, here we smile :-)))
>>
>
>Hey! I'd pay for that!
>

how 'bout $79.00 + Windows Manual title page + shipping? You can get OS/2 2.0
direct from IBM for that price...and it runs Windows apps without Windows...:-)
And you get a nice Boot Manager, too. :-)

		
				James

James P. Callison       Microcomputer Coordinator        OU Law Library 
Callison@aardvark.ucs.uoknor.edu   /\        Callison@uokmax.ecn.uoknor
	constellation!biglaw!callison@mailhost.ecn.uoknor.edu
DISCLAIMER: I'm not an engineer, but I play one at work...
	Here's to all the soldiers who have ever died in vain,
	The insane locked up in themselves, the homeless down on Main
	To those who stand on empty shores, and spit against the wind
	And those who wait forever for ships that don't come in
		--Joe Diffee, "Ships That Don't Come In"
Newsgroups: comp.unix.sysv386
From: feoh@hal.gnu.ai.mit.edu (Chris Patti)
Subject: BSD compatibility libraries/modules for System V (3.2)
Organization: /etc/organization
Date: Wed, 19 Aug 1992 00:38:41 GMT

	Hello.

	I'm currently doing a port from BSD 4.3 to SysV 3.2 and I've run up 
against a brick wall: ftruncate().. The code I use desperately needs this call
and there's no easy SysV r3.2 equivalent.

	If anyone knows a workaround for this, or (even better) knows of any
compatibility source/libs I'd be quite grateful if you'd fill me in...

	Thanks in advance.
	-Chris Patti
	root@madmax.interlan.com
	chrisp@interlan.com
	chrisp@summit.interlan.com
	feoh@gnu.ai.mit.edu
-- 
-------------------------------------------------------------------------------
Chris Patti | feoh@gnu.ai.mit.edu: A guest of the Free Software Foundation
=========#include <gratuitous_witty_quotes_section_to_waste_bandwidth>=========
"War is a symphony of destruction, orchestrated by few, paid for by many."
From: jdc3538@ultb.isc.rit.edu (J.D. Cronin )
Newsgroups: comp.unix.sysv386
Subject: What 'stune' parameters do you use for X386?
Date: 19 Aug 92 11:26:43 GMT
Organization: Rochester Institute of Technology
Originator: jdc3538@ultb


When we started using the X386 X-window server it quickly crashed.
After bumping up tuneable parameters with 'idtune' it runs for much
longer periods of time.  We are looking for other people's experience
with idtune parameters for X386.  The goal is to have the minimum
settings for fast, reliable performance.  Here's what we have in
/etc/conf/cf.d/stune for a Gateway 2000 486 with 8 meg of memory:

*ident  "@(#)master:stune       1.1"
MAXUP   60
MAXMINOR        0x3ffff
NPROC   400
MAXUMEM 32768
SVMMLIM 0x8000000
HVMMLIM 0x8000000
NSTREAM 128
NQUEUE  512
NBLK4096        4
NBLK2048        32
NBLK1024        32
NBLK512 32
NBLK256 64
NBLK128 256
NBLK64  256
NBLK16  256
NBLK4   128
SHLBMAX 6

Thanks...Jim
Newsgroups: comp.unix.sysv386
From: websterm@uproar.enet.dec.com (Mike Webster)
Subject: Serial Line mode question.
Reply-To: Mike.Webster@ime.mts.dec.com
Organization: Digital Equipment Corporation
Distribution: usa
Date: Thu, 13 Aug 1992 15:58:12 GMT



 A question for SVR4/Interactive Unix experts.

 I'm working on Interactive 386 boxes with specialix cards. I need
 to connect some specialix ports on the UNIX box to the serial 
 mouse port on various DOS boxes.

 I have had some success, but have one serious problem. I cannot
 reboot the DOS boxes unless a real mouse is connected to them.
 This is because the DOS box toggles the CTS line and the mouse
 responds before DOS loads the mouse driver.

 How can I spot the CTS line toggle from the unix box so I can
 send the mouse style response ?

 Is this a job for a streams module ? ( that respnse has to be
 quick or the DOS box assumes there is no mouse present and fails
 to load the driver ).

 Any ideas would be appreciated.

 thanks. Mike Webster London UK.
Newsgroups: comp.unix.sysv386
From: slangley@constant.demon.co.uk (Simon Langley)
Subject: Re: setuid problem on SCOUnix v 3.2.2
Organization: Home
X-Newsreader: Tin 1.1 PL5
Distribution: ca
Date: Sun, 16 Aug 1992 23:03:58 GMT

Arturo Vega (arturo@informix.com) wrote:
: Hi,
: 
: 	I have the following problem on SCOUnix V/386 v 3.2.2:
: 
: 	Setuid programs revert to normal executables after any
: update, e.g. running "strip" on such a program will convert it
: back from setuid to normal.
: 
My SVR4 system does the same thing.  It also does this if I copy a suid
program (but not move).  Although I don't know for sure, I would have thought
that this was a security feature.  If you could copy a suid program into your
own directory and then edit it to create you own suid program this would be a
serious security hole; this would be a faff with a binary program on a system
that didn't allow suid shell scripts but it would be perfectly possible.

-- 
   Simon Langley                   (preferred)   slangley@constant.demon.co.uk
   Hampstead, London                             slangley@cix.compulink.co.uk
From: karl@ttank.ttank.com (Karl Bunch)
Newsgroups: comp.unix.sysv386
Subject: X386 1.2 & Paradise Professional -w- NEC Multisync II
Date: 15 Aug 92 01:21:23 GMT
Organization: Think Tank Software, Norwalk, CA

Before I try too hard, has anyone else figured out how to
get the "best" out of the above combination using X386?

Everything I try seems to be too much flicker or the monitor
doesn't seem to keep up.  I know I can do 640x480x256 I've
done it with the DOS BIOS's help.  And I can reproduce it
by loading the registers under unix (Dell SysVR4) etc. 

I would really love to get a 800x540 (Max on the old II not
the IIa) with 256 colors working.  I know the Paradise only
has clocks 25, 28 & 36

Thanks in advance,
Karl
-- 
% ----------------------------------------------------------------------------
% Karl Bunch                        ||| UUCP: ..!uunet!cerritos.edu!ttank!karl
% Think Tank Software               ||| INTERNET: karl@ttank.com
% 42.5% of all quoted statistics are made up, of those 23.185% are right. :-)
Newsgroups: comp.unix.sysv386,comp.os.linux
From: beirne@rtsg.mot.com (Michael G Beirne)
Subject: Re: What the 17" monitor reviews never tell you
Organization: Motorola Inc., Cellular Infrastructure Group
Date: Tue, 18 Aug 1992 23:40:00 GMT

In article <Bt0Evo.Ho0@well.sf.ca.us> nlane@well.sf.ca.us (Nathan D. Lane) writes:
>>I get the same patterns on a NEC MultiSync II at 800x600, with any color
>>that has red in it.  Just the way it goes, I guess.  Probably easier to
>>see on a 17"
>>  - Patrick Taylor
>>
>>    Ericsson Network Systems
>>    exuptr@exu.ericsson.se                       
>
>I have an IBM (aka Sony) 6091/016 monitor (the only HONEST vendor - saying
>that their 17 is really a 16 in VIEWABLE area).  The tube is a trinitron and
>is run at 1280x1024 (NOT on PC Unix by far, or on a PC at all).  However,
>text that hits the line and not terribly obtrusive, but notable.)

Try using each of the bitmap images with xsetroot and then banging on the
side of the monitor lightly. The Sony trinitron is more susceptible to
vibration when vertical lines are displayed because it has a rectangular
holes in the shadow mask. This makes the pixels blend together easier but
there is less support for the mask as there is less metal there and
in a room with a lot of vibration that background wavering can make
your eyes hurt after several hours of looking at it.


Mike Beirne

-- 
Michael G. Beirne |845 W. Washington #2D,Oak Park,IL 60302-3821,(708)386-2415
beirne@limerick.chi.il.us or beirne@gold.rtsg.mot.com
From: jackn@caspianc.ism.isc.com (Jack Neman)
Newsgroups: comp.unix.sysv386
Subject: Re: how to write 525MB to Wangtek 525ES on Dell 2.1?
Date: 21 Aug 92 22:07:29 GMT
Organization: SunSoft Inc., Los Angeles, Ca.
NNTP-Posting-Host: caspianc.west.sun.com

In article <rvdp.714254499@yam.sow.econ.vu.nl> rvdp@sow.econ.vu.nl (Ronald van der Pol) writes:
>grog@adagio.UUCP (Greg Lehey) writes:
>
>>In article <rvdp.714046351@yam> rvdp@sow.econ.vu.nl (Ronald van der Pol) writes:
>>>larry@gator.rn.com (Larry Snyder) writes:
>>>
>>>>rvdp@sow.econ.vu.nl (Ronald van der Pol) writes:
>>>
>>>>>We have a Wangtek 525ES SCSI cartridge tape drive which should be
>>>>>able to write various formats (525, 250, 150 MB). But how do you
>>>>>choose the format? There don't seem to be different special files
>>>>>for different formats. So how should it be done?
>>>
>>>>I belive the tape and drive determine this -- ie: put a 150 meg tape
>>>>in the drive will yield 250 megs, a 60 meg will yield 120 megs
>>>
>>>I used the Wangtek 5525ES tape drive and a DC6525 tape. The script
>>>wrote 9 25MB files and 13 records of the 10th file. So about 238 MB
>>>was written (with 9 FileMarks?). After a 'mt rewind' and a 'mt fsf 9'
>>>the tape looks to be  positioned at the end of the media. So how much
>>>is written to the tape, 250 MB or 525 MB?

From the information I got so far on this problem, it proves to me that the
UNIX driver you are using has a bug. If you were not able to write 525 mb
of data on a DC6525 tape on a Wangtek 525ES SCSI tape drive, then it proves
to me that the UNIX driver is setting the tape blocksize via the SCSI
mode select command to 512 bytes/block instead of 1024 bytes/block. 
Wangtek 525ES, Archive 2525, and Tandberg 3820 1/4 inch SCSI cartridge 
tape drives, are all capable of writing and reading variable blocksizes.
It means that the driver can set the tape blocksize to 512 bytes and/or
1024 bytes. If the UNIX driver sets the tape blocksize to 512 bytes/block
via the SCSI Mode Select command, then you are not able to write 525
mega bytes using a DC6525 on one the above mentioned tape drives. You will
probably able to write about 250 mega bytes on this tape. If on the other hand
the UNIX driver set the tape blocksize to 1024 bytes/block then you must be
able to write 525 mega bytes of data on the DC 6525 tape using one of the
above mentioned tape drives.
Now, In order to prove if your UNIX driver is using 512 bytes/block not 1024
bytes/block, put the tape that you created on the Wangtek 525ES, into a 
Wangtek 150 mega bytes cartridge tape drive. If you are able to read back
your tape on the QIC150 tape drive, then it proves to me that the UNIX
driver that you are using is not setting the tape blocksize to 1024. A
Wangtek QIC150 should not be able to read a tape with 1024 bytes/block.
If you notice this, you should call the company who wrote the driver and
tell them that they are not setting the tape blocksize to 1024 on Wangtek
525ES drive. Basically the driver must issue SCSI READBLOCKLIMIT first
to find out if the drive is capable of writing variable blocksizes,
and then issue SCSI MODE SELECT command.
From: mcneild@Software.Mitel.COM (Doug McNeil)
Newsgroups: comp.unix.sysv386
Subject: swap partition
Date: 11 Aug 92 17:03:38 GMT
Distribution: na
Organization: MITEL Public Switching, Kanata, Ontario, Canada


Hello,

Does anyone know how to move the swap partition from disk 0 to another
disk under Interactive SVR3 3.0? I have three SCSI disks on my system
and I'd like to put the swap partition on the last drive (disk 2).

I'm not a real sysadm type, but I have used _mkpart_ and _mkfs_
before. I've also fooled around with _/dev/swap_, but that doesn't
seem to work.

Thanks

Doug
--
----------------------------------------------------------------------------->
"Smokin" Doug McNeil			| mcneild@Software.Mitel.COM
Mitel Corporation, Kanata, Ontario	| (613)592-2122
"Sssh. Be vewy vewy quite, I'm hunting wabbit" -- E.Fudd
Xref: sparky comp.unix.sysv386:13413 comp.os.linux:8800
From: brians@rigel.cs.pdx.edu (Brian Smith)
Newsgroups: comp.unix.sysv386,comp.os.linux
Subject: Re: What the 17" monitor reviews never tell you
Date: 21 Aug 92 17:15:13 GMT
Article-I.D.: pdxgate.6015

In article <yPgiPB1w165w@questor.wimsey.bc.ca> sp@questor.wimsey.bc.ca (Steve Pershing) writes:
>exuptr@exu.ericsson.se (Patrick Taylor) writes:
>
>=> >I have an Eizo (which is the nanao in german) 9080i with the same
>=> >symptoms. I gave it back to get a new monitor, but got a letter from
>=> >Eizo, which said, that these 'moire' (thats the word with 'm' :-) )
>=> >pattern are a characteristic for 17" monitors. My solution is to have
>=> >a 'cornflowerblue' root window...
>
>I wonder if "moire" patterns are also visible on Sony's large (trinitron)
>monitors?  Anybody??

I hate to add noise to an overflowing group, but I have to mention that
the NEC 5FG is *wonderful* at 17 inches.  There is no moire patterning,
and there is almost no deviation at the corners (forgot the technical
term).  This is a good monitor.  At $1300, I consider it well worth the
money for all the eye strain that it saves me.

Brian

/---------------------------------------|------------------------------------\
| #include <std/disclaim.h>             | Inet: brians@rigel.cs.pdx.edu      |
| #include <human/erors.h>              |       brians@protools.com          |
|---------------------------------------|------------------------------------|
| Behold the warranty.. the bold print giveth and the fine print taketh away.|
\----------------------------------------------------------------------------/
Newsgroups: comp.unix.sysv386
Subject: Re: Streams FAS drivers
From: bmyers@mcopn3.dseg.ti.com
Date: 13 Aug 92 08:59:10 CST
Organization: Texas Instruments Defense Systems & Electronics Group

In article <856@admin.mport.COM>, root@admin.mport.COM (Admin administration) writes:
> Does anybody know where to get SAS - the streams version of the FAS
> serial drivers.  I'm not positive it even exists, someone here believes
> he has seen it mentioned though.
> 
> An ftp archive site would be preferable, but any source source would be
> appreciated.
> 
>   Thank You
> Richard Ducoty
> 
> duc@mport.com



try going onto rapfast.unibase.sk.ca, in the /pub/drivers area....

-bob

Newsgroups: comp.unix.sysv386
From: bill@unixland.natick.ma.us (Bill Heiser)
Subject: Re: FAS 2.10 async driver, part 5/5
Organization: Unixland Public Access Unix  (508) 655-3848
Date: Sat, 22 Aug 1992 16:28:33 GMT

adb@geac.com (Anthony DeBoer) writes:
>In article <102.26574@incc.com> jerry@incc.com (Jerry Rocteur) writes:
>>What is the ruling regarding posting large files like this?
>The ruling is that your .signature should be no more than 4 lines long.

Hehe!  He's obviously one of those "calling the kettle black" people :-)
I wonder how many megabytes of disk space and modem time he's used by 
transmitting that useless signature around the world.  Not to mention all
this garbage he's stimulated :-)

-- 
bill@unixland.natick.ma.us                      ESIX Mailing List Moderator
Public Access UNIX/USENET/E-MAIL!  UUCP Accounts Available!  (508) 655-3848
5 lines  -  Located in Natick, MA   USA    Supporting V.32/PEP/V.42bis, etc.
Newsgroups: comp.unix.sysv386
From: x03@sun0.urz.uni-heidelberg.de (A. Stegmeier)
Subject: Re: Help needed on Destiny
Organization: University of Heidelberg (Germany)
Date: Fri, 21 Aug 92 13:10:03 GMT

In article <4780@daily-planet.concordia.ca> venkat@cs.concordia.ca (VENKATESH) writes:
>Hi,
>	I would like to know the following:
>		Are Dell's sv4 2.2 and USL's Destiny are the same or different?
>		If different, from whom one can buy Destiny.
>Thanks in advance,
>Venkatesh.

Novell is going to sell Destiny trough it's authorized dealers.


Achim Stegmeier                    EARN: X03@DHDURZ1
Unirechenzentrum Heidelberg        E-Mail: x03@sun0.urz.uni-heidelberg.de