HDTenEightyP/NetNews huggingface dataset:
From: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Subject: Re: Voice Recog. on Desktop
Reply-To: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Organization: Snake Island Research Inc, Toronto
Date: Thu, 16 Apr 92 16:05:21 GMT

In article <1992Apr15.172528.30412@alliant.com> tj@alliant.com (Tom Jaskiewicz) writes:
>In article <GLEW.92Apr14153132@pdx007.intel.com>, glew@pdx007.intel.com (Andy Glew) writes:
>|> Give me voice for entering mass quantities of text.
>
>In article <sfu1jINNjc6@agate.berkeley.edu> jbuck@forney.berkeley.edu (Joe Buck) writes:
>>  I don't think that voice is a reasonable
>>way to enter mass quantities of text except maybe to use a telephone when
>>you're away from your machine.  Speech is a low-bandwidth way of communicating
>>lots of text.
>
>Yabut . . .
>
>I don't need (or want) voice recognition on my desktop.  But I want voice
>recognition:
>
>I have an hour of "dead" time every working day.  It's called commuting.
>I want a computer I can use while driving a car.  I don't see any alternative
>to a totally audio interface.
>
>The first company with the hardware/software to allow a driver to "write"
>memoes is going to make a lot of money.

The first company with the hardware/software to eliminate the dumb 
automobile/commute is going to make a lot more money.




Robert Bernecky      rbe@yrloc.ipsa.reuter.com  bernecky@itrchq.itrc.on.ca 
Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694 
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9 
Canada
From: YOUNG@tattoo.cs.widener.edu (Rob Young)
Newsgroups: comp.arch
Subject: Chip timing issues
Date: 9 Apr 92 17:27:56 GMT
Organization: Widener University Department of Computer Science, Chester PA
NNTP-Posting-Host: tattoo.cs.widener.edu
X-News-Reader: VMS NEWS 1.20


I am a software person (understanding little or nothing of actual
chip design techniques) so if my terminology or wording is incorrect
please feel free to correct me.

With that intro... I have been pondering a statement one of the
Alpha architects (Dick Sites) made:
	" We did a number of design/philosophy things up front.
	There are almost no magic numbers in the architecture-
	you know, 20 microseconds or something - because every
	time we've seen an architecture with magic numbers 
	written into it, 10 years later those numbers look absurd."
			Digital News 1/6/92
Speculating... does any current architecture come to mind that Dick
may be referring to?  (Here is where I get in trouble)  From 3 years
ago I remember reading that the SPARC architecture uses "overlapping
registers" as a technique.  What exactly are overlapping registers?  
Are overlapping registers timing dependent?  

                                                     young@tattoo.cs.widener.edu
"Any escape might help to smooth the unattractive truth but the suburbs have 
 no charm to soothe the restless dreams of youth."   -- Neil Peart"    
From: crd@otter.hpl.hp.com (Chris Dalton)
Date: Wed, 8 Apr 1992 09:23:03 GMT
Subject: Re: Re: Is there a way of generating code for x/const without division?
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Newsgroups: comp.arch

See "Integer Multiplication and Division on the HP Precision Architecture"
Magenheimer, Peters, Pettis, Zuras, IEEE Trans on Computers, Aug 1988
pp 980-990.
Newsgroups: comp.arch
From: sdm7g@aemsun.med.Virginia.EDU (Steven D. Majewski)
Subject: Re: Ideas for new LISP Machines
Organization: University of Virginia
Date: Thu, 16 Apr 1992 19:59:51 GMT

In article <1034@armltd.uucp> abaum@armltd.uucp (Allen Baum) writes:
>firth@sei.cmu.edu (Robert Firth) writes:
>
>(re: SPARC being register rich/poor)
>>In case you haven't guessed it, the trick is very simple: get rid of
>>those stupid register windows.  You also have the satisfaction of
>>knowing that 40% of your memory traffic isn't being wasted in saving
>>and restoring empty registers.
>
>I always though it was obvious that if windows were a bad idead, then
>you could still run on a Sparc by not using them. I don't think there
>is anything forcing you to do so. Still, I have a few questions:
>
>-is it Sparc's implementation that is a bad idea, or the whole
> concept of overlapped, automatically pushed windows? For example,
> what if the overlap size was variable (i.e. you push exactly what
> you need)? Does the fixed set of globals still make this a bad
> idea?
>

I don't know if it's *good* or *bad*, but it is certainly less RICSy. 
IF you agree that the essence of RISC is dumb+fast hardware ( see 
the RISC == Direct Exectution of MicroCode thread... ) + smart compilers.
The SPARC register windows commits the same 'sin' that CISC designers
were accused of, namely, casting a particular *software* implementation
into silicon.
  If you can turn it off, then the sin is not too mortal, but:

>-are there compilers for the Sparc that don't use the windows?



>-Sun would claim that deep call/return structures are infrequent,
> i.e. you tend to hover around some stack depth, and hysteresis
> would tend to keep register spilling to/from memory
> infrequent. So, I'm not sure where your 40% of memory traffic
> is coming from- could you explain?

 The question is: From what mix of code were those statistics gathered ? 
 From a (casual) look at the literature, I think compiled C and Fortran
 code was perhaps over-represented, and interpreted ( LISP, POSTSCRIPT, 
 et.al) was under-represented. I would expect Memory/Register/Stack useage
 patterns to be quite different. 

 [ And the numbers I HAVE seen for CISC vs RISC on LISP ( say that 5 times
 real fast! :-) look like ( unless I'm misreading them ) there is less 
 of a performance advantage for RISC processors. [ It's hard to extract 
 a definite answer because there are a lot of other variables mixed in 
 there, but it looks to me like RISC does better than CISC, but not as 
 MUCH better as when compared to the sort of typical C compiled benchmarks
 that the RISC machines were optimised for. ]  


 - Steve

======== "If you have a hammer, find a nail" - George Bush,'91  =========
 Steven D. Majewski		University of Virginia Physiology Dept.
 sdm7g@Virginia.EDU		Box 449 Health Sciences Center
 Voice: (804)-982-0831/32	1300 Jefferson Park Avenue
 FAX:   (804)-982-1616		Charlottesville, VA 22908
Xref: sparky comp.arch:4787 comp.sys.dec:2467
From: mash@mips.com (John Mashey)
Newsgroups: comp.arch,comp.sys.dec
Subject: Re: Use of "crashme"
Date: 7 Apr 1992 17:09:03 GMT
Organization: MIPS Computer Systems, Inc.
NNTP-Posting-Host: winchester.mips.com

In article <00348@meph.UUCP> gsarff@meph.UUCP writes:
>In article <1992Apr1.054901.2534@spcvxb.spc.edu>, terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.) writes:
>fixed them.  Nealy every company that came out with a machine running unix,
>ported the code, bugs and all, and presumably did not fix the bugs because of
>the fear of being struck by a lightning bolt from the unix gods.  Or possibly
>if they fixed the bugs it would not be "compatible".  This kind of thing has
>been happening for years, and it is instead amazing to see that there manages
>to be any progress at all.  Assuming the reader believes SVR4 _is_ progress.
>    (insert 0.4 8-)'s) 8-(

I don't think this has much to do with comp.arch; however, let's
fix this impression:
	a) There are plenty of responsible computer companies who want to
	produce high-quality products.
	b) However, they also respond to customer priorities.
	c) Please compare the price or expected volumes for:
		1) We've fixed the bugs that bother most people, and we've
		not bothered to fix the myriads of odd cases (like
		fixing ls to defend against every weird input) that are
		there in the stands distributions.
	vs
		2) We've fixed *all* of those weird bugs.
How much more money do you get for 2)?
A: customers have voted: $0.
	Hence, companies would rather spend their money on thigns they
	can sell, rather than spending money cleaning this stuff up
	when what will happen is that on the *next* release, they'll
	probably have to refix it again....
	Companies are *much* more interested in features, performance,
	and in fixing the kind of bug that causes occasional failures
	of correct code.
(I speak as someone who has learned this from practical experience,
and who has actually been willing to allocate scarce resources to
nothing but fixing this kind of bug ... and has gotten the $0 response
from customers ... so this is not theoretical.)
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	 mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash 
DDD:  	408-524-7015, 524-8253 or (main number) 408-720-1700
USPS:	MIPS Computer Systems M/S 5-03, 950 DeGuigne, Sunnyvale, CA 94086-3650
From: Lubomir Bic <bic@cj2.ICS.UCI.EDU>
Subject: Workshops at ISCA'92 -- Australia
Organization: Clemson University
Date: 6 Apr 92 20:23:12 GMT

A series of Workshops will be held at the Architecture Symposium
(ISCA'92) this May. If you would like to attend, please contact me to
receive travel and other information.

Lubomir Bic, Workshops Chair
University of California, Irvine
bic@ics.uci.edu
(714) 856-5248


                          ISCA'92

            INFORMATION ON ARCHITECTURE WORKSHOPS

DATES

There will be three 2-day workshops and 1 one day workshop. The
dates are May 24-25, 1992.

LOCATION

All Workshops will be held on Hamilton Island (a part of the
Whitsunday Island group), which is a very popular vacation resort on
the Great Barrier Reef.


LIST OF WORKSHOPS AND ORGANIZERS

1. Dataflow Computing

Guang Gao
McGill University
514-398-4446
gao@andy.cs.mcgill.ca

Jean-Luc Gaudiot
Univeristy of Southern California
(213) 740-4484
gaudiot@usc.edu

Lubomir Bic, University of California, Irvine
(714) 856-5248
bic@ics.uci.edu


2. Future Multicomputers: Beyond Minimalist Multiprocessors?

Andrew A. Chien
University of Illinois
(217) 333-6844
achien@cs.uiuc.edu

Daniel Reed
University of Illinois
(217) 333-3807
reed@cs.uiuc.edu

Justin Rattner
Intel


3. Graphics Architectures & Algorithms

David Mizell
Boeing Computer Services
Research & Technology
(206) 865-2705
mizell@espresso.boeing.com

Fred Kitson
c/o Carmen Ramos
Hewlett Packard Labs
(415) 857-3604
ramos@hplabs.hp.com


4. Optical Computing Systems: Architectures and Algorithms

THIS WORKSHOP HAS BEEN CANCELED


5. High Performance Special-Purpose Architectures

Heiko Schroder, Univeristy of Newcastle, AUS
heiko@venus.newcastle.edu.au

David Abramson, Commonwealth Scientific and Research Organisation, AUS
davida@mel.dit.csiro.au
61 3 282 2666




Newsgroups: comp.arch
From: clc5q@hemlock.cs.Virginia.EDU (Clark L. Coleman)
Subject: Re: Who will have the next killer micro?
Organization: University of Virginia Computer Science Department
Date: Tue, 14 Apr 1992 15:49:39 GMT

In article <JINX.92Apr14095957@chamarti.ai.mit.edu> jinx@zurich.ai.mit.edu writes:
>
>The HP-PA 1.1 instruction set includes a multiply-and-add instruction
>(and multiply-and-subtract) that can initiate two flops per cycle.
>This is already true with the current generation of processors.

But the pipelining in the floating point unit only allows you to initiate
a new multiply and add instruction every TWO cycles, not every cycle.
They take three cycles to complete. So, TWO FLOPS every TWO cycles gives
a peak of 100 MFLOPS on the PA 7100 at 100 MHz, unless it has more pipelining
than PA-RISC 1.1.

Any comments from HP? Does the PA 7100 increase the pipelining in the FP
unit?


-- 
-----------------------------------------------------------------------------
"It is seldom that any liberty is lost all at once." David Hume
|||  clc5q@virginia.edu (Clark L. Coleman)
From: osyjm@coe.montana.edu (Jaye Mathisen)
Newsgroups: comp.arch
Subject: Re: Any FTP Sites for DEC Alpha (ps) documents?
Date: 9 Apr 92 15:01:33 GMT
Distribution: usa
Organization: Montana State University, College of Engineering, Bozeman MT, 59717

In article <ku6q3hINNn8a@priam.usc.edu> barroso@priam.usc.edu (Luiz Andre' Barroso) writes:
>Could anybody send me the ftp site where one can get DEC Alpha postscript
>documents. I know that this has been posted already but I cannot find it 
>among my files.

gatekeeper.dec.com, and I think the directory is /pub/DEC/Alpha, or 
pub/DEC/ALPHA, or something like that.  

If you can't find it, I have all the stuff and could probably be persuaded
to e-mail it.
-- 
 Jaye Mathisen, COE Systems Manager                (406) 994-4780
 410 Roberts Hall,Dept. of Computer Science
 Montana State University,Bozeman MT 59717	osyjm@{cs,coe}.montana.edu
Newsgroups: comp.arch
From: sysmgr@king.eng.umd.edu (Doug Mohney)
Subject: Voice Recog. on Desktop
Date: Thu, 09 Apr 92 13:58:34 GMT
Organization: Computer Aided Design Lab, U. of Maryland College Park
Reply-To: sysmgr@king.eng.umd.edu

"Multimedia" seems to be the latest goalpost of "Better, More More More" in
the Personal Computing Arena. 

As a part of this, we can equip PCs to record and playback sound. 

How many years before speech recognition is a stock "feature" and bundled/wired
into the OS? 

I'm thinking it's going to take 2-3 years for first solutions, and another 1-2
on top of that before we have "good" solutions. 

Speech recognitizion solutions do exist today, but they're not "mainstream" and
cost much bucks, when compared to the cost of a PC....


  For a country which has exported more comedians to the States than any
  other place on earth, the Canadians have very humorless grad students.
  -- >                  SYSMGR@CADLAB.ENG.UMD.EDU                        < --
From: ulf@stare.dit.lth.se (Ulf Andersson)
Newsgroups: comp.arch
Subject: DEC Alpha ISPS ?
Date: 12 Apr 92 23:47:07 GMT
Reply-To: ulf@dit.lth.se
Distribution: comp
Organization: Lund Institute of Technology, Sweden

Excuse me for asking this again if aready asked.

Is there an ISP description of the DEC Alpha architecture
avaliable somewhere. If there is, who wrote it, how can i
get a copy of it and what does it cost?

Thanks.

------------------------------------------------------------------------------
Ulf Andersson  	Student, Computer Engineering	 Ack ja, livet er svaert,
	     	Lund University  (LTH)		 men matematik er svaerere.
		Lund, SWEDEN			                 (Storm P)

Phone:          No, I don't have any.
Snail mail:     Magistratsvaegen 55R:304         E mail:   ulf@dit.lth.se
		222 44 LUND
------------------------------------------------------------------------------
--
------------------------------------------------------------------------------
Ulf Andersson  	Student, Computer Engineering	 Ack ja, livet er svfrt,
	     	Lund University  (LTH)		 men matematik er svfrere.
		Lund, SWEDEN			                 (Storm P)

Phone:          No, I don't have any.
Snail mail:     Magistratsvdgen 55R:304          E mail:   ulf@dit.lth.se
		222 44 LUND
------------------------------------------------------------------------------
From: hyatt@cis.uab.edu (Robert Hyatt)
Newsgroups: comp.arch
Subject: Re: Who will have the next killer micro?
Date: 6 Apr 92 13:09:11 GMT
Organization: University of Alabama at Birmingham

In article <0105010F.0a5d4g@mpr.mpr.com> mslater@mpr.com (Michael Slater) writes:
>In article <8840068@hpfcso.FC.HP.COM> (comp.arch), maf@hpfcso.FC.HP.COM (Mark Forsyth) writes:
>> In comp.arch, mslater@mpr.com (Michael Slater) writes:
>> 
>> > indeed provide better cache performance. There are, however, some
>> > costs. First, the system design is tough; this is part of why HP has
>> > not offered its chips on the merchant market. 
>> 
>>   This sounds like pure F.U.D.  Who told you this ?  It seems like 
>>   connecting on the order of 20 commodity memory chips together on a
>>   standard PC board is hardly rocket science.  It has been done for 
>>   years in SPARC and MIPs systems (and in PCs).  Just because the 
>>   frequency is higher doesn't make it harder - the cycle time reductions 
>>   come mostly from the VLSI design and improved SRAMs, not from the "wires".  
>
>Mark should know, so perhaps my sources are wrong, but it is people
>within HP who have told me that one reason the chips have not been
>offered on the merchant market is that it isn't so simple to put them
>together into a system.  And I thought that the higher clock frequency
>DOES make it harder, with board layout, terminations, trace lengths,
>and so forth become more critical.

I'm not sure where this is coming from or where it's heading.  However, to the
best of my limited knowledge the MHZ problem is REAL.  What works at 1Mhz 
DOES NOT work at 100Mhz due to a multitude of different RF-type problems.
Minimal capacitance between traces has little effect at 1Mhz, but massive
effect at 100-200Mhz.  Same for trace lengths.  I recall seing many of the
original Cray-1 modules that had lots of "zigzags" on them to equalize trace
lengths and/or effect delays where they were needed.

I can only assume that this is a serious problem based on what the Cray-3
guys have been fighting at 500Mhz.  Did I overlook something here?

-- 
!Robert Hyatt                    Computer and Information Sciences   !
!hyatt@cis.uab.edu               University of Alabama at Birmingham !
From: davidsen@yeti.crd.GE.COM (william E Davidsen)
Newsgroups: comp.arch
Subject: Re: Cyrix 486
Date: 13 Apr 92 19:49:41 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <id.M2SO.7G6@ferranti.com>, peter@ferranti.com (Peter da Silva) writes:
|  In article <1992Apr9.150513.29297@crd.ge.com> davidsen@crd.ge.com (bill davidsen) writes:
|  >   The things which distinguish the 486 from 386 are (a) slightly
|  > diferent instruction set, and (b) integral FPU.
|  
|  So, the 486SX isn't a 486? It's a 386DX on steroids?

  The discussion in the rest of my posting was mainly about the DX,
sorry I confused you. And yes, you could use that description, although
I prefer the term "capon" for the 486SX.
-- 
	- bill davidsen (davidsen@crd.ge.com)
	GE Corp. R&D Center; Box 8; Schenectady NY 12345
By analysis of usenet source, the hardest part of C to use is the comment
Newsgroups: comp.arch
From: danb@gaff.physci.psu.edu (Dan Babcock)
Subject: Re: Cyrix 486
Organization: Penn State University, Physical Sciences
Date: Wed, 8 Apr 1992 01:36:07 GMT

In article <1992Apr7.224947.19354@cis.uab.edu> hyatt@cis.uab.edu (Robert Hyatt) writes:
>In article <id.2WOO.KHD@ferranti.com> peter@ferranti.com (Peter da Silva) writes:
>>In article <1992Apr6.131334.22658@cis.uab.edu> hyatt@cis.uab.edu (Robert Hyatt) writes:
>>> Does this mean that AMD has built
>>> a 486-compatible chip with only a 16mb real memory addressing capability?
>>
>Peter's right of course.  The idea is great.  it's the calling it a 486
>that sucks with two straws.  I mean, is a 486 a 486 or is it a 16bit-wide
>buss superfast 386sx....  They should have used another number... it;s

PC Magazines had an editorial a while ago that recommended its readers
buy only 486's (similar to how they advocated the 386 a few years
ago - except this time they're nuts). As a result I would expect all
chip clones from now on to use the "486" number to please the
ignorant consumers and magazines.

Dan

Newsgroups: comp.arch
From: melling@cs.psu.edu (Michael D Mellinger)
Subject: Re: Voice Recog. on Desktop
Organization: Penn State Computer Science
Date: Fri, 10 Apr 1992 04:06:22 GMT


In article <ku9pnmINNhhf@exodus.Eng.Sun.COM> limes@straylight.Eng.Sun.COM (Greg Limes) writes:

   In article <1992Apr09.135834.15056@eng.umd.edu> sysmgr@king.eng.umd.edu writes:
   >How many years before speech recognition is a stock "feature" and bundled/wired
   >into the OS? 

   >Speech recognitizion solutions do exist today, but they're not "mainstream" and
   >cost much bucks, when compared to the cost of a PC....

   Limited speech recognition is available for the PC for well under
   two hundred bucks. Keyword recognition, and only sixteen active
   templates at a time, but it works ... call Covox for info, or
   drop by your local Hacker Heaven.

   Why can't we do this on our workstations? The audio is there, the
   processing power is there ...

You can.  SimonSays on the NeXT.

-Mike
From: torbenm@diku.dk (Torben AEgidius Mogensen)
Newsgroups: comp.arch
Subject: Re: Condition Codes and RISC arch.
Date: 9 Apr 92 09:31:41 GMT
Distribution: comp
Organization: Department of Computer Science, U of Copenhagen

se@IKP.Uni-Koeln.DE (Stefan Esser) writes:

>Does the ARM processor set the flags after each instruction, or after 
>each arithmetik operation (like intel processors) or after operations 
>working on 'data' registers (like the 68k family) ?

All instructions that can affect the flags (move, arithmetic, load
multiple registers) have bits that controls whether or not the flags
are affected.

In the ARM2 and ARM3 processors, the flags are contained in the 4 most
significant bits of the PC register. Some operations on the PC
affect/use all bits, some only the PC bits. If the PC is the
destination register, the flag control bit will normally determone
this.

>Is there any processor that has a general 'set condition codes' bit
>in each instruction ?

See above.

	Torben Mogensen (torbenm@diku.dk)
Newsgroups: comp.arch,comp.ai
From: hollombe@soldev.tti.com (The Polymath)
Newsgroups: comp.arch,comp.sys.dec,alt.folklore.computers
Subject: Re: Use of "crashme"
Date: 14 Apr 92 01:57:38 GMT
Organization: The Cat Factory

In article <1992Apr3.213010.23294@schaefer.math.wisc.edu> wilson@schaefer.UUCP (Bob Wilson) writes:
}In article <1992Apr2.215945.6571@cs.hw.ac.uk> sfleming@cs.hw.ac.uk writes:
}>Chuq von Rospach reported a few years ago that he used to
}>test Mac programs by allowing his pet cockatoo to walk on
}>the keyboard.  It is quite amazing what random input will
}>do to "solid" utilities.
}>
}At one place we had a person in tech support who was good at finding
}bugs in the terminal I/O routines of our UNIX product. It turned out
}that she was literally rolling her fists back and forth over a
}terminal keyboard to see what would happen. The down side of this kind
}of testing is that, even if it does find that SOMETHING went wrong, it
}is frequently impossible to recreate what it was. ...

We (I, in fact) do similar testing here, with a twist.  It's done under
programmed control with a random number generator and it keeps a log file
of every random keystroke.  We've found a lot of errors that way and they
could all be easily reproduced from the logs.

The Polymath (aka: Jerry Hollombe, M.A., CDP, aka: hollombe@polymath.tti.com)
Head Robot Wrangler at Citicorp                   Turn the rascals out!
3100 Ocean Park Blvd.   (310) 450-9111, x2483     No incumbents in '92!
Santa Monica, CA  90405 {rutgers|pyramid|philabs|psivax}!ttidca!hollombe
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.arch
Subject: Re: chip-on-chip technology
Date: 16 Apr 92 22:52:08 GMT
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA

staylor@fudd.rtp.dg.com (Steve Taylor) writes:
>>As near as I can tell, flip-chip (solder bump technology) has pretty much
>
>Isn't Flip-Chip still a registered trademark of Digital Equipment for
>their convenient line of logic-functions-on-a-circuit-board products, 
>introduced in the early sixties?

	Certainly it was.  They were great fun.  I used the RPI-ACM's PDP-8
ser. #165 for a while, and it was entirely built from Flip-Chips.  No IC's
in sight.  For amusement (since this _was_ 1982 or so) I designed a high-
speed line printer interface for it using flip chips to run DMA (programmed
IO wasn't fast enough).  These things were _positive_ logic, BTW.

	There was even a pulse-amplifier hooked to a small speaker to output
"music".

-- 
"Thus spake the Master Ninjei: If your application does not run correctly,
do not blame the operating system." - The Zen of Programming
-
Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
Disclaimer: Nothing I say is anything other than my personal opinion.