author: Earl Lewis

subject: RH7 minicom - does it really work?

text:
I finally got a modem that will at least install in RedHat7 - the Zoom
ISA 2919. (I had to send back a Zoom PCI 2920, couldn't make it work
at all in RH7, tho it's supposed to work in RH6).

Now I can install the modem:
setserial /dev/ttyS0 uart 16550A port 0x3f8 irq 4

I can
minicom -s -c on
and issue an AT, getting back and OK
this is Zoom's test for the modem installed and working. Hooray!
However my man of minicom tells me that a Control-a and z should give
me a Help menu. It doesn't. Nor does Ctl-a work with any other combo.
I can't figure how to even get out of minicom except Alt F2, which
leaves the modem hung up somehow, so I have to reboot before it'll
work again.

Does anyone besides me have trouble with minicom in RH7? Is there a
cure? I still don't know how to dial my ISP and hookup either, maybe
you could explain that while you're at it?
Earl


subject: Re: RH7 minicom - does it really work?

text:
Hold down the control key and A key. Then letup and hit Z.

I have a Zoom 2948 external and works great in Linux.

Earl Lewis wrote:


subject: Re: RH7 minicom - does it really work?

text:
Thanks, coffee. Kinda wish I could have talked to you a month ago, I'd
have bought the external.
Earl

On Sat, 03 Mar 2001 00:49:40 GMT, coffee177 <[email]> wrote:


subject: Re: RH7 minicom - does it really work?

text:
Well, I have 2 of those zoom externals. Dont need them both. I guess Im
up for offers :)

coffee

Earl Lewis wrote:


author: Hank Nussbacher

subject: Re: WWW versus Gopher for campus info systems

text:
In article <2v1nq4$[email]>, [email] (Paul Phillips)
says:

What if 95% of your terminal base was old 3270s, VT100s, VT220s and
dialup users from home via Crosstlak/Procomm/Kermit?  Would you still
feel that WWW is the answer?  The benefit that WWW gives over Gopher
is its graphics.  Don't let anyone fool you with those cliches of
"WWW has nothing to do with graphics".  Until Mosaic came out, the Web
was just another has run in the Information SuperHighway.  Mosaic finally
gave WWW that push to be the overall winner 3 years down the road.  But
you and I who use either a high powered workstation, or an Xterminal or
a PC or Mac that has direct IP connectivity can benefit the most from
WWW via Mosaic.  Now go and do a survey what percentage of the student
population has such access.  More advanced schools might have 50%.  Others
might be as low as 10%.  Non-universities, such as businesses that want
a network presence use Gopher due to its simplicity.

Yes Lynx solves the low-end WEB access problem.  But you are once
again falling into the Unix trap.  The world is not 100% Unix systems.
If it was I would agree with you completely.  Since there are IBM
mainframes and Vax systems out there - you need low end access solutions
for them too (being worked on but about a year or two behind the Gopher
clients) in order to make WWW the solution you propose.

Too simplicistic.  Life is not black and white.

Hank Nussbacher
Israel


author: Nathan Torkington

text:
In article <[email]> Hank Nussbacher <[email]> writes:

Um, how do I break this to you.  There are VMS versions of lynx.  Am I
expected to take your article seriously when you have done no
research?

Oh sorry, this is UseNet.  My mistake.

Nat


author: John Hascall

text:
Hank Nussbacher  <[email]> wrote:
}What if 95% of your terminal base was old 3270s, VT100s, VT220s and
}dialup users from home via Crosstlak/Procomm/Kermit?  Would you still
}feel that WWW is the answer?  The benefit that WWW gives over Gopher
}is its graphics.  Don't let anyone fool you with those cliches of
}"WWW has nothing to do with graphics".

    I disagree.  So far, most of the WWW pages I've seen use
    graphics as a "gee whiz", not as useful information (notable
    exceptions: sites selling T-shirts, jewelry, etc).

    Other WWW advantages:
          * handles gopher, ftp, etc. too
          * arbitrary structure (hyperlinks) vs. gopher tree
          * mixed pages (text and "menus")
          * better searching
          * interactivity (via forms)
          * extensible (via cgi)

}            ...  Now go and do a survey what percentage of the student
}population has such access.  More advanced schools might have 50%.  Others
}might be as low as 10%.

     What do you mean "have access"?  Every single person at ISU has
     access (walk into any number of labs).  I find it hard to imagine
     any faculty wanting connectivity and not having it.  Ethernet is
     available in a growing number of the dorms.  Ethernet is $7/month,
     serial is $5.  SLIP/PPP/ARA is coming for off-campus dwellers.
     At last count, about a dozen area high schools have net connections.

     Perhaps things are different in your part of the world, but here
     in the american hinterlands, the net has arrived.

}                         Non-universities, such as businesses that want
}a network presence use Gopher due to its simplicity.

     Actually, I consult for a business that provides net-access to
     companies -- to my knowledge not a single customer has chosen
     gopher over WWW.

}Yes Lynx solves the low-end WEB access problem.  But you are once
}again falling into the Unix trap.  The world is not 100% Unix systems.
}If it was I would agree with you completely.  Since there are IBM
}mainframes and Vax systems out there - you need low end access solutions

     Lynx is not that complicated -- if there is sufficient demand
     for a VMS or MVS or VM or whatever perverted IBM OS version
     on lynx, it will appear.

John


author: Craig Nordin

text:
If you were starting on a new program and did not have gopher up,
I would consider it a mistake to target gopher.  You may specify
it as a waypoint, but not as a target.  I agree with the previous
poster that it is not black and white, but getting the whole
setup up and happy and mature will take some significant time
in a big organization.  If you target gopher now, you will end
up with gopher years later.

If I were publishing (server side) to the internet at large,
I might still select gopher because it is the least common
denominator -- so you will reach more people.  Besides,
compared to setting up clients for everyone in a big organization,
setting up a server for general use is MUCH quicker and easeier.
If you don't mind growing slower and you'd like to work with
what will be the standard, I'd say WWW.  But you lose your
reach, at least at the beginning.

If you are talking about some dumb project that expects to have
something really deep available to everyone in 3 months, I don't
care what you pick -- yours will be yet another of those dead-
end web/gopher links that is nothing but a pain to everyone...

Just my "stenkin" opinion...


author: Richard Daniel

text:
Nathan Torkington ([email]) wrote:

: Um, how do I break this to you.  There are VMS versions of lynx.  Am I
: expected to take your article seriously when you have done no
: research?

Well, so far Delphi refuses to install lynx on their VMS system
because "it's got too many bugs".  They didn't say what bugs.  Just
thought I'd pass that on.


author: Harry Flowers

text:
In article <2v6hc4$[email]>, [email] (John Hascall) writes:

I'm quite happily running Lynx on my VMS systems... it already supports
VMS as well as Unix.  The gopher client is also common code for VMS and
Unix.  Maybe there's a different Unix trap... ;-)


author: Foteos Macrides

text:
In article <2v6kjb$[email]>, [email] (Craig Nordin) writes:

	Put ALT's into your IMG tags if you want your Charm Net pages to be
more charming to a broader range of people, now.  OK, Hon!

	Just my "Lynx user" opinion...

				Fote

=========================================================================
 Foteos Macrides           Worcester Foundation for Experimental Biology
 [email]     222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================


author: Michael D. Bray

text:
In article <2v6kjb$[email]>,
Craig Nordin <[email]> wrote:
:If I were publishing (server side) to the internet at large,
:I might still select gopher because it is the least common
:denominator -- so you will reach more people.  Besides,
:compared to setting up clients for everyone in a big organization,
:setting up a server for general use is MUCH quicker and easeier.
:If you don't mind growing slower and you'd like to work with
:what will be the standard, I'd say WWW.  But you lose your
:reach, at least at the beginning.

   The University of Florida has apparently been considering these same
issues, and has made a momentous move supporting WWW.  What they have done
is set up a Gopher and a WWW server, but the GOPHER server only has three
real links...  I show the main menu for gopher.ufl.edu here:

 -->  1.  Access from a World-Wide Web browser (Mosaic, lynx, Cello, e.. <HTML>
      2.  Access from a Gopher client on a 3270 terminal (VM Gopher) <3270>
      3.  Access from all other Gopher clients <TEL>
      4.  .
      5.  Why UFINFO is *not* Gopher.

When you select either link 2 or link 3, you are put into a telnet WWW
client which accesses their WWW server.  I think this is probably one of
the best approaches I've seen, as it allows you to set up a WWW server
to maintain your information, and provide a gopher gateway to provide
access to people who are running gopher clients only.  Not only that, but
it kind of 'introduces' gopher-weenies to WWW.  8-)


author: Michael Richardson

text:
In article <2vnu78$[email]>,
Richard Daniel <[email]> wrote:

  So, Delphi shouldn't surprised if their users login to anon-lynx logins
and receive a message that "Delphi's system has too many bugs"


author: Brad Eckert

subject: Who needs DEPTH (Re: RetroForth (Re: C library interfacing in Linux))

text:
[email] (Ernie) wrote in message news:<[email]>...

\ Hayes { -> } without DEPTH

CREATE TSTRESULTS 20 CELLS ALLOT
-1415926536 CONSTANT MAGIC

: {  ( -- m )           \ mark bottom of stack
   MAGIC ;

: -> ( m ... -- m )     \ store stack contents
   TSTRESULTS BEGIN 2DUP ! CELL+ SWAP MAGIC = UNTIL DROP MAGIC ;

: }  ( m ... -- )       \ verify stack
   TSTRESULTS BEGIN OVER MAGIC <> WHILE
   DUP @ ROT <> ABORT" *** INCORRECT RESULT ***"
   CELL+ REPEAT 2DROP ;

{ 1 negate -> -1 }
{ 9 dup -> 9 9 }

----------------------

Anybody else want to demonstrate a "need" for DEPTH?

--Brad


author: Anton Ertl

subject: Re: Who needs DEPTH (Re: RetroForth (Re: C library interfacing in Linux))

text:
[email] (Brad Eckert) writes:

{ -1415926536 -> }

Your tester says that this is ok:

{ -1415926536 -> }  ok

Let's see what the original does:

{ -1415926536 -> } WRONG NUMBER OF RESULTS: { -1415926536 -> }

- anton


author: Jeff Fox

text:
[email] (Brad Eckert) wrote in message news:<[email]>...

I know this shouldn't count, but it is 'needed' and
required in every ANS Forth compliant system.

Best Wishes


author: Ernie

text:
[email] (Brad Eckert) wrote in message news:<[email]>...

Thanks  a lot for the illustration. But the Hayes code using depth
"looks" neater on paper :) and the illustration assumes the magic
value -1415926536 is an invalid value. Now one has to be "conscious"
of this magic value not appearing in all future test programs if they
used this approach ...

- Ernie.


author: Dr. Bruce R. McFarling

text:
You know, I have no problem whatever with debugging wirds using a word
that I do not use myself.

I think I understand the "just have the stacks wrap around" approach.
Its Extreme programming.  Show the top eight cells in a display that
constantly updates in the corner of the screen.  Keep debugging until
the bug is not there, and then if you have exercised all paths and all
significant boundaries and it works, proceed, and since it won't
overflow or underflow, run it naked.  Don't ever build words that go
too deep into the stack.  Where on person would write a variable
number of items to stack, build the data structure in memory and hold
a constant sized reference item on the stack.

It might be really binding as a mandate on everybody, but when it
works it can be beautiful in a Laoist kind of way.


text:
[email] (Ernie) wrote in message news:<[email]>...

The problem with using a magic position holder on a stack is
that there are no reserved numbers in Forth. On a 16-bit Forth
the magic number is going to come up at random as data 1/64K times.
On a 20-bit processor that's one in a million times.  So if you
are executing 200M instructions a second the mean time between
failures should be 5ms?  Ok, going to a double magic flag
reduces the average time between failures but now you still
have this problem with stack data filtering.

On F21 I have 18 data stack cells which is more than enough
for most anything.  It is sufficient to dedicate 2 cells to
a magic number that will come up only 1 in a trillion times
radomly.  And I once implemented DEPTH by dumping the stack
contents to RAM until found the magic number or got to 18
and didn't find it.  Then it would reload the stack with the
values previously there and put a count on top.  Maybe this
looks 'neat' on a blank piece of paper, but work out the
actual details and it will not look very neat.  I have done
it several times and there is no way to do it cleanly or
safely.

So one of the minor problems with requiring DEPTH is that
it is about as complicated to do a crappy job of it as
implementing the rest of ANS Forth is and it isn't really
going to work very well anyway.  Without looking at the
real issues it seems like a solution that might look neat
on paper.

Best Wishes


text:
[email] (Jeff Fox) wrote in message news:<[email]>...

Aha, but you do realise that this story will say to some
people, "its a mistake not to support DEPTH in hardware,
look at what a mess it is to support it in software".

Yes, I know, I know, if its not needed when you program
correctly then the proper solution is to dispense with
the requirement.  But people have this attraction to
certainty, and when floating on the top of a stack, it
is innately reassuring to know how far down it is before
you touch bottom.  Irrational, sure, but pure rationality
is not a viable solution either.


text:
[email] (Dr. Bruce R. McFarling) wrote in message news:<[email]>...

Yes. I am keenly aware of that error.

Very true. The programmer should always know exactly
what is going to be on the stack, all the way down.
They should have to focus on more than the top at
any given moment, but they had damned well better
know that they have below in the stacks waiting
to be used later.

The DEPTH crutch can be used to probe for the bottom
if they don't know where they are.

Rationality is not a viable solution for some people
or to some problems.  Stack usage is not one of those
problems.

Best Wishes


author: Software Architects, R Vasse,PRT

subject: Re>[2] Why not virtual TO

text:
Attn: MacApp 3 Technical Discussion
SentBy: Ron Aldrich

        Reply to:   Re>[2] Why not virtual TObject::~
Tom,

You said...

I ran into a problem with C++ in general which caused me problems when using
constructors and destructors.

When C++ is constructing an object, it dynamically changes the objects scope
as each constructor is called.  So, if I want the constructor to call a
method, and then want to override that method to change its behavior, the
overriden method won't be called.  I found this so annoying that I ended up
eliminating the use of constructors throughout most of our class library.

Does anyone have an insight as to why the designers of C++ thought that this
behaviour would be a good idea? Maybe I'm missing something...

BTW, I agree with the rest of the folks - jetisson CFront!

Regards,

Ron Aldrich
Software Architects, Inc.

ï¿½


author: Lars Farm

subject: Re: Re>[2] Why not virtual TO

text:
In article <[email]>,
[email] (Software Architects, R Vasse,PRT) wrote:

It is a good idea, for your own protection ;-) The idea is quite simple:

An object has behavior, member functions or methods if you like. Raw
memory is NOT an object and can NOT perform. Raw memory has no methods.

Constructors are not member functions. Constructors turn raw memory into a
living object. Ideally this should take no time. On a sequential computer
this "turn raw memory into a living object" must take TIME and it must be
performed in SOME order. C++ defines this order: from base to derived. As
each level in the inheritance hierarcy is constructed that part of the
object is turned into an object and can start to perform. Therefor you can
use the base member functions in a constructor, but not behavior that is
to be performed by parts that has not yet become an object. Consider:

class WindowBase {
public:
   WindowBase();
   virtual void show() = 0;                        // declare behaviour
   virtual ~WindowBase(){}
};

class MyWindow : public WindowBase {
   WindowPtr the_window;
public:
   MyWindow() { window = NewWindow(/*...*/);
   void show() { ShowWindow( the_window, ... ); }  // define behaviour
};

WindowBase::WindowBase()
{
   show();  // DANGER: if this was allowed to call MyWindow::show
            // what would MyWindow::the_window be?
            // that part has not yet become an object.
}

void WindowBase::show() { /* nop */ï¿½}

Destruction turns a living object into raw memory in the in reverse
direction derived to base.

Happy Holidays
 Lars


author: Larry Rosenstein

subject: Re: Re>[2] Why not virtual TO

text:
In article <[email]>,
[email] (Software Architects, R Vasse,PRT) wrote:

I think you have to do this because you can't reliably call a derived
class virtual function until the derived class data members are
initialized.  The most derived contructor is the last to run.

"Taligent's Guide to Designing Programs" talks about this (pp 68-71) and
suggests a couple of alternatives ranging from a separate virtual
Initialize() (essentially I-methods), to using virtual base classes to
ensure any virtual function is called from the most-derived contructor.


author: "JaGo"

subject: FotoCrop; does it work for you?

text:
Does FotoCrop work for you? Among those of you that use it, have you ever
experienced any usability issues? I'm specificically interested in any
issues with installing/using this app with Win 2000/XP/Me, and if/how you
got around them.

If you're using FotoCrop, and have installed it on one of these OS's,
whether problem-free or after lots of tweaks/work-arounds (that you can
document), or if you gave up trying to make it work, please let me know
(via email or reply here).

Happily, I've had quite a few FotoCrop downloads recently, and I've yet to
receive an installation/support question that I couldn't answer (knock
wood), but my compatibility experience is limited to my own W98 (1st Ed.).
I'd like to address OS compatibility up-front, if it proves to be an issue
for anyone.

So, if there are any questions/problems.... let me know.


author: Oddjob

subject: Re: FotoCrop; does it work for you?

text:
"JaGo" <email me@[www.pixilver.com/contact.html]> wrote in message
news:H7mc8.6074$[email]...

Hi James
I have been using Fotocrop with PSP 7.04 and Windows XP pro for 3 month now
and I did not have any installation problems and it has worked perfectly all
this time.

Cheers
Ian

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.324 / Virus Database: 181 - Release Date: 14/02/2002


author: Roy Rodieck

subject: Re: FotoCrop; does it work for you?

text:
I've been using it with Windows Me for a few months and it works fine
- no problems in either installation or usage.

Roy

On Tue, 19 Feb 2002 01:02:11 -0500, "JaGo" <email
me@[www.pixilver.com/contact.html]> wrote:

(snip)


author: Graeme Wall

subject: AntiSpam error message

text:
I am currently unable to collect email from demon, they appear to have a
problem with theor server, I can'y even get at ot via their web interface.

AntiSpam is reporting Error No 60, anyone know what this means?


author: charles

subject: Re: AntiSpam error message

text:
In article <[email]>,
   Graeme Wall <[email]> wrote:

The Demon status page is stating that mail is down & has been since 20:47
last night.


author: John Cartmell

subject: Re: AntiSpam error message

text:
In article <[email]>,
   Graeme Wall <[email]> wrote:

Demon is totally up the creek. Everything has gone slower over the week, they
have POP3 non-functioning, I've just downloaded multiple copies of stuff I
didn't get last week and the week before, I'm wading through ocean's full of
crap spam, and seem to have a thousand copies of an irrelevant e-mail from
Paul Beverley!

Normal Service will be resumed ...

.. hopefully!


author: Jeremy C B Nicoll

subject: Re: AntiSpam error message

text:
In article <[email]>,
   Graeme Wall <[email]> wrote:

The error code returned in the block is particular to the Internet
socket SWIs. The main ones you will encounter are :
Name	      	Value	Meaning

<EWOULDBLOCK>	 35	Operation would block
<EINPROGRESS>	 36	Operation now in progress
<EALREADY>   	 37	Operation already in progress
<ECONNRESET>  	54	Connection reset by peer
<EISCONN>	     56	Socket is already connected
<ENOTCONN>	    57	Socket is not connected
<ETIMEDOUT>	   60	Connection timed out     <------------
<ECONNREFUSED>	61	Connection refused


author: Dave Higton

subject: Re: AntiSpam error message

text:
In message <[email]>
          Graeme Wall <[email]> wrote:

Connection timed out.

Dave


subject: Re: AntiSpam error message

text:
In article <[email]>,
   John Cartmell <[email]> wrote:

Demon mail came back for me at about 3pm.  I've had no spam or multiple
copies of anything and certainly nothing from Paul Beverley.


subject: Re: AntiSpam error message

text:
In message <[email]>
          John Cartmell <[email]> wrote:

Has now, for a given value of normal, I'm still wondering what error no 60
means.


author: Darren Salt

subject: Re: AntiSpam error message

text:
I demand that Jeremy C B Nicoll may or may not have written...

[snip]

AntiSpam needs to translate this. I suggest sys_errlist (char*[], declared in
TCPIPLibs:h.unixlib, index it using errno).


subject: Re: AntiSpam error message

text:
In message <[email]>
          Jeremy C B Nicoll <[email]> wrote:

Many thanks.


subject: Re: AntiSpam error message

text:
In message <[email]>
          Dave Higton <[email]> wrote:

Thanks


author: Frank de Bruijn

subject: Re: AntiSpam error message

text:
In article <[email]>,
   Darren Salt <[email]> wrote:

Recent versions report 'unable to connect to host' if connection fails.
The log will also contain an entry with the actual error message
(including the number) from the socket call immediately before that
message.


author: Anthony Williams

subject: Mouse Hardware

text:
I'm trying to write a mouse driver for a microsoft mouse. If the mouse has
been initialised by another program, then I can read from the mouse, but I
am unable to initialise the mouse myself. Does anyone know how to do this?
If so, please reply by Email as well as posting, since I don't check the
newsgroups very often.

Thanks in advance :)

Anthony Williams

[email]


author: [redacted]

subject: Openssh on Solaris 10 AMD64

text:
Hello,

I have been having a heck of a time trying to get openssh-4.xp1 to
compile on a AMD64 Solaris 10 system.  All the attempts end with the
following error.

gcc -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o
sshconnect1.o sshconnect2.o -L. -Lopenbsd-compat/  -lssh
-lopenbsd-compat
-lresolv -lcrypto -lrt -lz -lsocket -lnsl
Undefined                       first referenced
 symbol                             in file
EVP_aes_192_cbc                     ./libssh.a(cipher.o)
EVP_aes_256_cbc                     ./libssh.a(cipher.o)
ld: fatal: Symbol referencing errors. No output written to ssh
collect2: ld returned 1 exit status
make: *** [ssh] Error 1

I have gone through the email archives and tried the various
suggestions
made but none worked.

I used the patches listed for acconfig.h, cipher.c and configure.ac.  I
installed the SUNWcry, SUNWcryr packages as well.  I've tried different
versions of openssl(0.9.7e, 0.9.7i 0.9.8a) as well.  Still the compile
ends with the above error.

I have tried using the vanilla gcc which comes with Solaris 10 and have
installed gcc.3.4.4 and still the same results.

./configure --enable-threads --prefix=/usr/local
[--with-ssl-dir=/usr/local/ssl]
make and gmake

Any suggestions to what I should try next?

Thanks.

Carlo


author: Per Hedeland

subject: Re: Openssh on Solaris 10 AMD64

text:
In article <[email]>
[email] writes:

You clearly have a problem with the OpenSSL version - those symbols
aren't in old (very old) versions of OpenSSL. Your "trying" with current
versions was not successful, i.e. the OpenSSH build didn't actually use
the new version(s).

I don't know what version of OpenSSL Solaris 10 ships with (if any), but
either way you probably don't want to *replace* it - by default OpenSSL
will install somewhere under /usr/local, and you'll need to point the
OpenSSH build there, by using the --with-ssl-dir argument to configure.

Gcc version is certainly not relevant for the above - you need the
--with-ssl-dir, and you need to make sure that configure actually finds
the OpenSSL include files and libraries there (the output should say).
If that had happened, you would have had a corresponding -L argument
on the gcc command line above - but you didn't. You may also need to
'make distclean' before re-running configure, or start with a freshly
unpacked tarball.

--Per Hedeland
[email]


author: Darren Tucker

subject: Re: Openssh on Solaris 10 AMD64

text:
On 2005-11-19, Per Hedeland <[email]> wrote:
[...]
[...]

For the record: the default libcrypto that ships with Solaris 10 does
not have the 192 or 256 bit AES functions.  Note that there is no
linker error for the 128 bit AES funcrions.

The Solaris Data Encryption Supplement (SUNWcry and SUNWcryr) packages
are supposed to provide them.  The OP has installed them, though, so
I'm not sure what's going on (I made some suggestions over on
the secureshell list where this query was also posted, but my reply does
not seem to have made it past the moderator yet.)

And I thought we'd finally outgrown those wacky crypto export laws...


author: Nico Kadel-Garcia

subject: Re: Openssh on Solaris 10 AMD64

text:
"Darren Tucker" <[email]> wrote in message
news:437fc3c6$0$30790$[email]...

No, they're still quite active. They were found unconstitutional when
handled by the Customs department, so they got transferred over to Commerce
and remain capriciously enforced. It seems vital to US federal policy to
avoid robust end-to-end encryption without the private keys stored in a
central repository with their own unmonitored access to it. The problem has
been in place for many years now.


author: B. Vermo

subject: Re: Zip250 - What's wrong with Iomega?

text:
In article <3778f7b3.485818460@news>,
[email] (Martin Nisshagen) wrote:
|
|I don't know what information you got at "Lotusphere", but already in 1997 NT
|Workstation sold much more than 10 X OS/2 clients. Since then it has only
|grown bigger and bigger (and I'm not sure that's the case for OS/2, even if I
|would have liked that as well, but it certainly hasn't passed NT WS sales).

If you include WSOD clients in total OS/2 sales, it is not at all improbable
that sales are higher than those of NT. Up to now, NT has not had the same
level of boost from preloads as Win9x has enjoyed, and IBM rarely sell
WSOD clients in smaller bunches than 100 at a time.


author: Bj|rn Christian T|rrissen

subject: Re: Problems with formula code

text:
Martin Schneider <[email]> skrev

: UNID := @Text ( @DocumentUniqueID ) ;
: " ["+ffObertitel+"]
: "
: _________

Errr... You can't have a space between the \ and the " when you want to
insert a " inside a "". So, if you just remove the spaces in \ ", so that
it becomes \" , that should help alot.

Bjï¿½rn.


author: HamNCheese

subject: using both SATA and IDE drives and booting from SATA

text:
I have a PT800CE-A motherboard and two PATA IDE drives.  I am
replacing the failing IDE boot drive with a new SATA drive.  But when
I configure the BIOS, I have to put the mobo's SATA channel into IDE
mode (the only SATA options are RAID or IDE) after which POST reports
the SATA drive as IDE Channel 2.  My question is, will the SATA drive
boot if it is set to be IDE-2, or am I forced to put my boot device on
IDE-0, meaning I can only boot from a PATA drive?


author: Timothy Daniels

subject: Re: using both SATA and IDE drives and booting from SATA

text:
"HamNCheese" wrote:

    Your question is equivalent to asking if the installer will get
the value of "x" right in "rdisk(x)" of the resulting boot.ini file
in order to boot an OS that is installed on the SATA HD.
My guess is that it will.  Right now, you probably have only
ch. 0 and ch. 1 available for PATA drives.  That accommodates
a maximum value of "3" for "x" in the event that you had 4 PATA
HDs in the system.  By assigning the 1st SATA HD to "ch. 2",
the BIOS retains the identity of any remaining PATA drives in the
HD Boot Order.  That is, if you still have 4 PATA HDs, their
corresponding values of "x" would (in the default case before
you might have reset the HD Boot Order) be:
x=0 for Master on IDE ch. 0,
x=1 for Slave on IDE ch. 0,
x=2 for Master on IDE ch. 1,
x=3 for Slave on IDE ch. 1.

     If you then toss a SATA HD into the mix, it will occupy
"IDE ch. 2" and not displace any of the PATA HDs in the
HD Boot Order.  It's possible that by enabling SATA and
thus enabling "IDE ch. 2" and "IDE ch. 3" for SATA HDs
to use, you remove the PATA IDE ch. 1 for 2 PATA HDs,
but the relative positions of the first 2 PATA HDs and the
added 2 SATA HDs would remain.

     The way to verify this is to install the OS on the SATA
HD with the PATA HD still connected, and see what the
installer does to the PATA's and SATA's boot.ini files,
looking at the values of "x" in the "rdisk(x)" parameters of
the resulting ARC paths.  The installer should set up a
dual-boot menu in the boot.ini file of one of them.  If you
install the OS on the SATA HD with the PATA HD
disconnected, it won't set up a dual-boot menu for you.
Please post your results.

*TimDaniels*


author: Andy

text:
The BIOS will boot whatever disk you place at the top of the list in
the setting Hard Disk Boot Priority under Advanced BIOS Features:

Hard Disk Boot Priority (Press Enter)
Scroll to this item and press <Enter> to view the following screen:
Phoenix-AwardBIOS CMOS Setup Utility
Hard Disk Boot Priority
1. Pri. Master:
2. Pri. Slave:
3. Sec. Master:
4. Sec. Slave:
5. USBHDD0:
6. USBHDD1:
7. USBHDD2:
8. Bootable Add-in Cards
Item Help
Menu Level ! !
Use < > or < > to select
a device, then press <+> to
move it up, or <-> to move it
down the list. Press <ESC>
to exit this menu.

On Sun, 08 Apr 2007 18:29:03 GMT, HamNCheese
<[email]> wrote:


author: Arno Wagner

text:
Previously HamNCheese <[email]> wrote:

Depends on your boot-maanager and on whether you adjust its
configuration. The BIOS is most likely able to select the SATA drive
as boot device. Both LILO and Grub can run from any device,
but need to be configured for it, either before booting or
interactively during boot (which is not persistent).

I have no idea what minimalistic boot mamagers like that of
Windows XP do.

Arno


author: Rod Speed

text:
Timothy Daniels <[email]> wrote

Nope. That isnt necessarily involved when you specify the boot drive in the bios boot order list.

You dont know that.

Or that.

Or that.

Makes more sense to not go that route in his situation.

And the last thing he need is a dual boot menu.


text:
"Rod Speed" wrote:

    You're so helpful, Rod.  Why don't you tell us how
     it works?

*TimDaniels*


author: Mike Cox

subject: Why is SUN falling so far behind IBM?

text:
For about 12,000 USD, you can buy a pSeries that has ChipKill(TM)
technology, dual CPUs that if one fails, the other takes over, a
service manager, and reduncant powersupplies and RAID disks.  Best of
all, that server will work seemlessly with my Linux desktops and
applications because it too runs linux.

SUN is going in the complete opposite direction.  It is blindly
clinging on to Solaris instead of switching to Linux OR having a Linux
affinity Solaris such as something that could be branded "SolarisLX"
that would work seemlessly with Linux.  Make Linux or Linux affinity
Solaris availible for everything from a SUNFIRE to the Ultrasparc.

The last thing that SUN is doing wrong is ruining the SUN brand by
using commodity INTEL chips.  Companies used to show their customers
and investors the IT room full of huge SUN boxes to impress them, but
now that the SUN brand has been tarnished it is not as impressive
anymore.  Customers now see sun as either a has-been or just another
OEM DELL machine.

SUN was high-end reliable computing that boasted you could write your
app on an Ultra and move it to a SUNFIRE.  IBM now has that message
because now you can write your app on Linux and run it on a Mainframe.
 Fun too how much money IBM makes from JAVA.


author: Dennis Clarke

subject: Re: Why is SUN falling so far behind IBM?

text:
I think that Mozilla is available from blastwave.org

GNOME and KDE are over at blastwave.org

Over 700 software titles are at www.blastwave.org but you need to install
the pkg-get tool and wget in order to use the package installation and
automation features.

+--------------------+---------------------------------------+
|  Dennis Clarke     |  Director and Admin for blastwave.org |
|   dclarke          |  Community Software Packages for      |
|     @blastwave.org |  The Solaris Operating Environment    |
+--------------------+---------------------------------------+


author: Rich Teer

text:
On Mon, 2 Aug 2004, Erik Magnuson wrote:

Yeah, that would do it!  :-)

Thanks for the feedback.  The old site used to have that feature,
and I agree that the new one should too.  I've got family visiting
from the UK for the next 4 weeks or so, so any changes probably
won't appear until they've gone home.

Much oblidged!  I hope the book's web site contains all the info
you need (see the comment above for an indication of when the
index will appear).


author: Andrew Gabriel

text:
In article <[email]>,
	"Benjamin Gawert" <[email]> writes:

Which is what I said in the very next bit you snipped.
However, their volumes are totally insignificant, even all added
togther.

Sure -- Opteron has very successfully taken the volume market IA64 was
aiming at. That's why Intel had to do a big U-turn and bring Yamhill/EM64T
into production, to avoid missing the volume 64 bit market completely.

Oh it most certainly was, but they now recognise that's not going to
happen! If Itanium doesn't become a high volume chip, there's no money
to pay for future development, and the chip dies when Intel decides to
stop subsidising it. The volumes which HP buys won't come close to
making it a volume chip -- after all, that was why HP-PA was not viable.

Itanium is the most expensive CPU ever developed, and by a long way.

Opteron already took almost all IA64's marketplace.


text:
In article <[email]>,
	"Benjamin Gawert" <[email]> writes:

Sorry, this isn't true. No one invests the amount Intel did in a
chip which isn't for high volume. Intel still believed it would be
a high volume chip until Opteron started shipping in volume over
the last year or so.

This is only valid if you write off the development costs. You can
only do that for high volume chips (or at least, you can partially
ignore them as they are a small part of the chip price). This isn't
true of Itanium, for which the development costs are the highest of
any chip ever designed. At current volumes, Intel will never recoup
even a small part of their development cost. That will make Itanium
the most expensive mistake in computer history. The production cost
of a low volume chip is not the significant part, but that's all
Intel can currently charge for it or it would have no sales of it.

That simply isn't true. Intel would not have waited so long to enter
the x86-64 market if it was, because by doing so, it's now playing
catch-up just to become the also-ran, not the leader.


text:
In article <[email]>,
	GreyCloud <[email]> writes:

IIRC, HP gave the Alpha development team to Intel as part of their
contribution to the Itanium effort.


text:
On Mon, 26 Jul 2004, Chris Thompson wrote:

My recently updated website, www.rite-group.com/rich, contains
a picture of my ugly mug (and my dog, Judge).  The site also
contains all the info about said forthcoming book, Solaris
Systems Programming, so I encourage everyone to have look and
buy a copy or two!


text:
On Sun, 1 Aug 2004, GreyCloud wrote:

Thanks; I don't know how I'd cope without Judge and my twin
21" Sun monitors!

As for the former, how about "My dashing good looks can be
seen from my new website"?  :-)


text:
On Wed, 28 Jul 2004, GreyCloud wrote:

I've not seen one in the flesh, but they do look VERY interesting,
the V2100z more so.

Perhaps someone from Sun will be kind enough to send me one,
so that I can review it?  ;-)


text:
In article <[email]>,
	GreyCloud <[email]> writes:

HP have ended up with lots of OS's, but mostly with far too little
market share to be viable. HP-UX is the one with the largest market
share of the bunch, and the theory was that all the others would
just move across making HP-UX more viable and reducing HP's support
costs. HP overlooked the fact that none of their non-HP-UX customers
would dream of moving to HP-UX, although this seemed obvious to
everyone else.

They are in the same mess with chips as they are with OS's, actually
probably even slightly worse. Volumes of HP-PA and Alpha were too low
to sustain development, so the idea was to switch to a cheap comodity
high volume processor, Itanium. The trouble is itanium has failed to
become a cheap comodity high volume processor -- actually, just about
everyone else other than HP has abandoned it (certainly everyone who
might have made it cheap comodity high volume). So, take HP's original
processor sales of Alpha and HP-PA which were too low to sustain the
chip development, and spead them across more processor families,
Alpha, HP-PA, Itanium, and you can see they're really in a mess with
even lower volumes on each processor making them all less viable.
Not to mention they are now pushing Opteron too, which although safe
in itself, further dilutes the viability of their low volume processors.
Now isn't a good time for HP customers, most of whom are being pushed
from one non-viable processor to another non-viable processor -- HP
has gone to a lot of effort to drive them up a No-Through-Road.

I don't think there's any chance of Alpha being restarted. The last
processor in the range was just released EV7z and that's it. HP no
longer has the Alpha development team anyway.


text:
On Thu, 29 Jul 2004, GreyCloud wrote:

How would I do that - I don't work for Sun!  Suitably lucretive
offers are welcome, though...  :-)

I haven't the faintest idea.  But considering that Sun had Solaris
running on an Itanic simulation a few years ago, I guess it wouldn't
be that hard, especially if it (Itanic2) is very similar to Opteron.
And if ISN'T similar to Opteron, I'd question the thinking behind
supporting Itanic2, given it's miniscule market size.  The only
possible reason I can think of would be so that Sun can say they have
a migration path for HP users if/when HP-UX is EOLed.


text:
On Wed, 28 Jul 2004, Chris Cox wrote:

I believe it already is (HP-SUX too, IIRC).


text:
On Mon, 26 Jul 2004, Gavin Maltby wrote:

Excellent - all that cash spent of self-portrait art classes
wasn't wasted!  :-)


author: Don Davis

text:
[email] (Mike Cox) wrote in message news:<[email]>...

I think everyone is missing the point. Hardware and operating systems
are necessary evil's in providing an environment for an application to
run.

Applicatons are where businesses make their money. Until vendors stop
charging on a per processor basis, (real or virtual if using LPAR,
micro partitioning, VMWare... etc) the cost of the app is what
matters. In the meantime, from a cost standpoint, I want the world's
fastest one-way processor. If that's not fast enough to run the app,
the next best alternative is the world's fastest two-way.... etc.

It makes no sense to acquire a low cost hardware platform (choose your
vendor),
a free or low cost operating system, (choose your OS), then fork over
several hundred thousand dollars for an enterprise class database
product. (Other software products are also moving to number of CPU
based pricing, or charging by the client, if client/server)

What I would really like to see is an open source database (like
MySQL) with
advanced features, like triggers, stored procedures.. etc. This would
take most
of the price gouging out of software sales, and make hardware and OS
software important again. Right now, the harware/OS software component
is such a small fraction of the total costs of ownership, I'm not sure
it really matters. Both have reached commidity status. Just my
opinion, comments welcome.


text:
On Mon, 26 Jul 2004, Don Davis wrote:

It's already here, and it's called PostgreSQL.


text:
On Mon, 26 Jul 2004, Chris Cox wrote:

Well, we obviously have different inside contacts, and I don't
recall hearing your voice on various NDA conference calls discussing
this matter I've been party to...

JDS will soon be available on Solaris - both SPARC and x86.  It is
NOT tied to a Linuc kernel.

I think your sources are dated.  Yes, Linux is supported in and
by Sun, but they are refocussing their priorities on Solaris
(SPARC and x86).

I disagree.  Sun fully supports Linux, yes, but their focus
is on Solaris.  I see that message becoming even louder and
clearer when S10 hits FCS...


text:
On Mon, 26 Jul 2004, Chris Thompson wrote:

Thankfully, the cover DOESN'T have my photo on it.  I'm an ugly
bugger, and I didn't want to put off potential purchasers!  :-)

My ugly mug will viewable by all and sundry when I upload my
new, improved web site, in the next few days.  The new-look
site will also contain the book's official site, wherein all
the usual goodies (example source code, Preface, and sample
chapter) will be found.

To paraphrase Scott and Jonathan, this is not an announcement.
That will be in a few days, when there's actually something
to look at...  :-)


author: UNIX admin

text:
Allow me to be blunt: you're trippin'.

Why would Sun dump a reliable, robust OS whose functionality Linux has yet
to achieve?  That would not be prudent, to say the least.  Some of Sun's
biggest customers are largest banks in the world, and when you mention Linux
to them, their hair stands up on their heads (first hand experience).
That's just one example.  There are many.
Linux isn't even close in robustness and functionality of Solaris, and it'll
be "a while" before it gets there.  But who knows how far ahead will Solaris
be then?


author: Richard L. Hamilton

text:
In article <[email]>,
	[email] (Don Davis) writes:
[...]
[...]

http://firebird.sourceforge.net/

http://www.ibphoenix.com/

http://www.ibphoenix.com/main.nfs?a=ibphoenix&s=1090876179:23108&page=vul_development

(the latter a major rewrite by the original developer to provide 64-bit SMP
support)

etc.


text:
On Mon, 26 Jul 2004, Chris Cox wrote:

No, but there's a big gap between "Linux sucks" and "Linux rules,
and is preferred over Solaris".

Heh - by the time an official response got vetted by SUn's
land sharks, we'd have moved onto something else!  :-)

I see.  I must have mis-read my invitation to JDS on Solaris Beta,
then.  Nope, it clearly says Solaris.  Last I checked, Solaris was
not Linux (I think Linus would have a word or two to say if Sun
tried to claim that!).

I guess time will tell, either way...


author: The Ghost In The Machine

text:
In comp.os.linux.advocacy, Mike Cox
<[email]>
 wrote
on 25 Jul 2004 18:01:22 -0700
<[email]>:

[snip]

Erm, don't you mean Intel or Microsoft?  (And even Intel
is suspect; Intel chips may run Microsoft Windows (and
be the only chips that run Microsoft Windows), but Intel
doesn't like Microsoft, IIRC.)


text:
On Mon, 26 Jul 2004, Chris Cox wrote:

The best I can do using easy-to-find publically available
info is this (from http://wwws.sun.com/software/javadesktopsystem/faq.html ):

	1. Q. What is the Sun Java Desktop System?

	   A. [...]
		  Future releases of Java Desktop System are planned to
		  support workstations and Sun Ray thin clients running
		  the Solaris Operating System.

and more definately:

	4. Q. What is the Future Product Roadmap?

	   A. Q3CY2004:
		  Java Desktop System, Release 2 for the Solaris x86
		  platform for Sun Opteron-based Workstations only

		  Q4CY2004:
		  Java Desktop System, Release 3 introduces the following features:
		  * Support for the Solaris Operating System
		  [...]

I wouldn't be surprised if the release of JDSv3 coincided
with S10 FCS...

Not quite.  JDS will eventually run on top of Linux as well as
Solaris, in much the same way that StarOffice does today.  I
guess Linux was the easier target (presumably, many components
have various Linuxisms that make a straight port a bit problematic),
which is why it got released first.

I think the ultimate goal is to support JDS equally on Linux
and Solaris (both SPARC and x86), the customer making the
final choice.


author: Chris Cox

text:
Mike Cox wrote:

Actually... I have word from the inside of Sun that Sun is "full tilt"
favoring Linux right now.  Solaris will be an additional offering,
but after it is completely open sourced, users will have a choice
between FULLY Sun supported LINUX (e.g. JDS - which is built on
Novell SUSE Linux Enterprise Server v8), or FULLY Sun supported
Solaris.

Your information is wrong.  Though many in the newsgroup will likely
support the idea of Sun NOT going after Linux, my inside sources
say that Linux has become king at Sun currently.

Where's IBM's Linux desktop offering?  While Sun has the Java
Desktop System, IBM pretty much only support Linux on the server
side.  Sun is actively pushing both server and client side Linux.

You'll find the Opteron a better price/performance target than
the IBM offerings currently.... saying that, IBM also offers an
Opteron line... so I guess maybe I don't fully understand the
issue here.  Sparc, will live on for a while.. possibly even with
another upgrade or two... but you don't have to use Sparc anymore,
and IMHO, that's a good thing.

Probably won't see Sun (anything) on the mainframe.  But since the
mainframe now runs Linux and since Sun fully supports and encourages
the use of Linux now, all IBM is doing is providing another
fully Sun compatible platform to Sun.

Sunfire will continue to live on since there isn't a reasonable
"cheap" platform alternative.  Again, the high end is where Sparc
will continue to live on for a while.  As commodity x86 platforms
become available with hundreds of processors, I'm sure Sun will
change.  But.. when you consider that high end SMP is somewhat
of a niche market nowadays, perhaps it doesn't matter too much
what happens to the Sunfire line.

If you had written this post a year ago... it would have
been somewhat valid.  But as of today, Sun is a Linux company.
Somebody from Sun may feel free to provide more details
on Sun's current Linux strategy.  In many ways, Sun is a much
bigger supporter of Linux than IBM.  If you doubt that, I
encourage you to call Sun and ask them.


author: Scrubbing Bubbles

subject: WHY is MIKE COX harassing nice smart SUN EMPLOYEES !?!

text:
Mike Cox wrote:

Huh?  They see the need for a high end Unix OS that is proprietary.  Good
for them.  Diversity is good.

Why ?

That's only for cheap workstations.  They need cheap JDS stations to be a
full service company.  They get clobbered when they try to 'work together'
with deceitful people like Micro$haft, so, now they have a fully complete
system.  They can do cheap workstations, servers, Linux, java, desktop,
high performance computing, Unix *and* Linux. And, of course, they own
java.

Old news.  This is the year 2004, Rip van Winkle.  Read on:

http://www.forbes.com/technology/feeds/infoimaging/2004/07/23/infoimagingbhsuper_2004_07_23_INHT_0000-1828-KEYWORD.Missing.html?partner=yahoo&referrer=

Infoimaging
 Sun Posts Modest Sales Gains (Folo) STMicro Profit Nearly Doubles As Chief
Forecasts Strong Demand
 The New York Times, 07.23.04, 5:00 PM ET

 Sun, the Santa Clara, California, computer hardware and software company,
said its revenue for the quarter that ended on June 30 was $3.11 billion,
up 4.3 percent.

 Net income was $795 million, against a loss of $1.04 billion a year
earlier. But the figure for the most recent quarter included $1.6 billion
that Microsoft paid to settle a suit. Without special gains and charges,
Sun lost $169 million.

 International Herald Tribune

 (C) 2004 International Herald Tribune. via ProQuest Information and
Learning Company; All Rights Reserved


author: Gregory Toomey

text:
Mike Cox wrote:

Sun owns Cobalt, which makes linux servers.

In the past sun had to comete with IBM & HP. Sun now has to compete with the
$0 (or near to $0) linux alternative.

Where big money is concerned (eg banks), buying a "solution", reliability
and service is more important than cost. Sun still makes lots of money
selling services.

But you are right in Sun & solaris getting squeezed. Linux & bsd lack some
functionality of solaris but cost near $0 . Its what happens when operating
systems become commodities.

gtoomey


author: CJT

text:
Mike Cox wrote:

<snip>

$12K can buy some pretty nice Sun gear, too.


text:
On Sun, 25 Jul 2004, Mike Cox wrote:

[Pro-Linux drivel snipped.]

                                  ___________________
                          /|  /|  |                  |
                          ||__||  |      Please do   |
                         /   O O\__         NOT      |
                        /          \     feed the    |
                       /      \     \     trolls     |
                      /   _    \     \ ______________|
                     /    |\____\     \     ||
                    /     | | | |\____/     ||
                   /       \|_|_|/   \    __||
                  /  /  \            |____| ||
                 /   |   | /|        |      --|
                 |   |   |//         |____  --|
          * _    |  |_|_|_|          |     \-/
       *-- _--\ _ \     //           |
         /  _     \\ _ //   |        /
       *  /   \_ /- | -     |       |
         *      ___ c_c_c_C/ \C_c_c_c____________


author: Beardy

text:
Rich Teer wrote:

I suspect that you are just a ghost-writer for Judge ;-) And is "Solaris
Systems Programming, Prentice Hall, 2005" a presumption/portent of
forthcoming sales? ;-) I hope so!

BTW: I recommend a bushy beard to mask the mug ;-) I am using it
currently.....

Beardy.


author: Thomas Dehn

text:
"Andrew Gabriel" <[email]> wrote:

Yep, but seeing whats coming, quite a few of the Alpha developers
had left HP earlier.

Thomas


author: Benjamin Gawert

text:
Andrew Gabriel wrote:

Sure, they realized that putting some 64Bit extensions to a 32bit CPU is
more than enough for the mass market.

When the IA64 project was started years ago it indeed was aimed at the mass
market and as a replacement for x86. However, intel and HP realized very
fast that the Itanium will be too expensive for mass market, and changed
their target at the HPC market and the traditional RISC market (servers and
workstations). This directional change has been made long ago, even long
before the first Itanium(1)s were shipped 1999...

Nope. The 1.5GHz Itanium2 for example is still much cheaper per unit than
the (much slower) PA-8800 or even the older PA-8700+, or even an UltraSPARC
III. Of course it's much more expensive than an Opteron CPU, or an Athlon64
or Xeon. But this isn't joe home users market, and the CPU cost are only a
small fraction of the overall system costs. Of course no system vendor gives
up a complete platform that sells at least somewhat ok only because other
CPUs are cheaper.

Definitely no. IA64 has a strong stand within the HPC and Highend market
(the market of PA-RISC, SGI MIPS, Sun UltraSPARC III and IBM POWER), and
that's where it has been targeted at since shortly after project start.
Opterons on the other side are clearly aimed at the x86 multiprocessor
market and more competitors of the XEONs instead of Itanium. Perfectly
reflected btw by price and performance of the current mass of opteron
systems.

Benjamin


author: Bigdakine

text:
I've seen worse.

(and my dog, Judge).  The site also

No freebies?

drats

Stuart
Dr. Stuart A. Weinstein
Ewa Beach Institute of Tectonics
"To err is human, but to really foul things up requires a creationist"

"Creationists aren't impervious to Logic: They're oblivious to it."


author: Erik Magnuson

text:
Rich Teer <[email]> wrote in message news:<[email]>...

Surprisingly enough, my monitor survived the strain of rendering
the image of your mug - might have to do something with it being
seismically reinforced to withstand the So Cal earthquakes...

Nice use of whitespace in your website. One thing I did miss was
a link to the site's homepage from the underlying links - my
suggestion would be embedding it in the site logo (click on the
logo to get back to home).

Looking forward to your book as well and will be bugging San
Diego Tech Books to stock it.

-Erik


author: GreyCloud

text:
Rich Teer wrote:

Hey, don't be hard on yourself.  Nice dog too and nice displays.


text:
Rich Teer wrote:

:-))

I could certainly not brag about my looks.
I could break a mirror with my looks.
That's why I don't look in them.


text:
Andrew Gabriel wrote:

Oh, it definitely is. At the beginning IA64 was intended to replace x86 but
shortly after the project started intel realized that this wasn't possible.

You clearly forget that Itanium is not only intel's baby. It's a
co-development by intel and HP, and for HP it never was a volume market chip
but a replacement for their PA-RISC processors which also were no high
volume processors. With HP sharing the investment intel realized very fast
that it won't be selling in high numbers but on the other side is a perfect
way to get a foot into the High Performance Computing area.

Nope. We got our first Itanium systems 1999, and I got my personal machine
mid-2001. Even at that time no-one at intel was talking about Itanium being
a mass-market CPU but a high end solution...

The fact that it also runs Windowsxp (and this in 64bit since 2001!) doesn't
mean it is competing with PCs...

No. For HP (which had to carry a big bunch of the development costs) the
Itanium is around 40% cheaper than a PA-8800, and this includes the
development costs...

Wrong. Even in low-volume markets the CPU price also carries the development
costs. That's one reason CPUs like MIPS R16000A, Sun UltraSPARC III or
POWER5 are that expensive.

Nope. As I said often enough Itanium isn't a mass-market product, and like
other CPUs that are not mass-market products won't follow the rules You know
from Your average Athlon PC.

I don't see why Itanium should be the most expensive mistake in computer
history. Such statements are pure BS and mostly come from people that never
even touched an Itanium machine (forget about having worked with it). You
won't hear such statements from people with at least a fraction of
competence in the high end area. IA64 had a difficult start but it's still a
great platform for certain applications (as are all the other
non-mass-market platforms like Sun and such). For our company's demands
Itanium on HP-UX gives us the best bang for the buck for our applications.
But then, we buy complete solutions based on a certain platform, and in the
overall machine price the CPU costs are just a small fraction that simply
doesn't matter...

intel waited that long simply for two reasons: the lack of 64Bit operating
systems for x86-64, and the fact that most applications usually served by
x86 machines don't really need 64Bit at all. Now, with Linux doing x86-64
quite well and Windowsxp and Windows 2003 server for x86-64 being close to
appear on the scene it finally made sense for intel to participate with
64Bit extensions for their 32Bit CPUs. Especially with more and more PC
kiddies rushing out for a 64Bit Athlon because 64Bit make their games faster
;-)

Benjamin


author: Joerg Schilling

text:
In article <[email]>,
Rich Teer  <[email]> wrote:

I would guess that Itanic2 is more or less Itanic compatible.

While 64 bit graphic card drivers, ... could be reused to 100%,
trap handling, MMU support, the linker (ld.so), mdb, kmdb, ....
need to be completely different.


text:
Rich Teer wrote:

 From what I've read over in cov, HP-UX is pushing out Tru64-UNIX for
some reason or other.  They are porting OpenVMS to Itanium2 and it seems
to be in testing for now, but the reports coming back in aren't all that
good.  It seems that the port shows some areas of performance is pretty
bad, but I don't know which area.  Some are speculating that the EV line
of Alphas may have to be restarted again if this port doesn't work well.
  This is HPs chip design from the start so its hard to say what they'll do.


text:
Andrew Gabriel wrote:

That makes sense.  It seems that the way things are going that the only
processor left will be either the Intel family or IBM family.  Suns
Sparc will be about the only one on its own.

Did the Alpha development disappear?
Or did the people migrate to other companies?


text:
Rich Teer wrote:

Itanium is totally different from the Opteron.

Or that Sun users have a migration path with their current hardware if/when
Solaris would get EOL'd ;-)

Benjamin


text:
Andrew Gabriel wrote:

Definitely no. There are more IA64 vendors than HP. Companies like SGI, NEC,
etc...

Certainly not. HPs Opteron targets a much different market than the
PA-RISC/IA64 systems...

Not really. The transition from PA-RISC to IA64 was not trouble-free but
quite smooth after all. IA64 is the way to go for HP. Even if Itanium
doesn't get a high volume chip (which isn't really HPs or intels intention)
it is still way cheaper than the older PA-RISC development. And the new
PA-8800 uses the same system components (i.e. chipsets) like Itanium2.

Opteron is in no way considered as a replacement for IA64 but placed below
the IA64 line.

Benjamin


text:
Rich Teer wrote:

Of course.  After you review it then you can add me to their discount
list.  Is there any truth to the rumours that Sun is porting Solaris to
the Itanium2 chip?


text:
Rich Teer wrote:

What do you think of the new Sun Opteron box that was just released?
Priced around $2k.


author: Alan Coopersmith

text:
Chris Cox <[email]> writes in comp.unix.solaris:
|Actually... I have word from the inside of Sun that Sun is "full tilt"
|favoring Linux right now.  Solaris will be an additional offering,
|but after it is completely open sourced, users will have a choice
|between FULLY Sun supported LINUX (e.g. JDS - which is built on
|Novell SUSE Linux Enterprise Server v8), or FULLY Sun supported
|Solaris.
|
|Your information is wrong.  Though many in the newsgroup will likely
|support the idea of Sun NOT going after Linux, my inside sources
|say that Linux has become king at Sun currently.

Your inside sources must not know most of the people I work with or for
(admittedly in the Solaris division), nor do they listen to the same
executive comments that caused this article to be written:
    http://www.vnunet.com/news/1156903


author: Paul Eggert

text:
At Fri, 30 Jul 2004 05:01:18 -0700, Frank Cusack <[email]> writes:

Well, more accurately, Postgres itself worked fine for his example but
the PerlDBI interface to Postgres was lacking.

Personally, I've found that "Oracle is great" is true only if you
already have an Oracle wizard around to make your installation act
great on your problem.  We've had our fair share of problems porting
applications to Oracle.  If you're used to Oracle, it's great, yes.


author: Leon Workman

text:
"UNIX admin" <[email]> wrote in message news:<41055b9c$0$1954$[email]>...

I've been seeing an alarming trend in the marketplace with companies
that embrace Linux (with one of them, at least).  HP was one of the
first vendors to jump on the Linux bandwagon (and Microsoft
interoperability bandwagon nearly simultaneously), and their unix
isn't what it once was.  They had to cut costs somewhere due to the
slump in the economy, and I believe that unix and unix middleware R&D
took some real hits.  The company was more focused on Linux (and
printing and digital photography and Microsoft garbage and scooping up
other flailing companies) than its own OS, and as a result, they've
lagged a bit behind their competition.
To embrace Linux at the expense of wasting all of your R&D $'s that
you've already put into a more reliable OS is just plain retarded.
Sure, Linux is cheap.  Sure, Linux seems to do a whole hell of a lot
better than Windows in the reliability area, but it's all open source.
 All of these companies are eating up what amounts to freeware,
putting their sticker on it, and reselling it without even knowing
what a lot of the underlying code is.  It's going to bite them hard
somewhere in the future.  Not everyone that contributes freeware has
altruistic intentions.  Some disgruntled troll somewhere has probably
already put the next Y2K into some obscure Linux code.
Nothing's free.

Stepping off of my soap box...

Leon


text:
Rich Teer wrote:
...

Rich,
Do you know of anything on the web that explains better the
position of Sun on this?  If things are really as you
have said, I need to get some hard data to certain
folks around here (so as to not mislead them).

Sounds like JDS on Linux was a stop gap measure until
their true JDS on Solaris product could be developed (???).

I really need to know this.  Don't want folks to go
down the Linux trail needlessly.  If the ultimate goal
is JDS on Solaris... I want to know for sure.


text:
At Sat, 31 Jul 2004 18:48:48 -0600, "Timothy J. Bogart" <[email]> writes:

It's kind of hard to tell from the blog.  Postgres has cursors, but
there are some restrictions on their use.  It didn't appear to me
that his needs would run afoul of those restrictions, but his needs
were stated pretty vaguely and scatteredly so it's hard to tell.
It was clear that the Perl DBI interface to Postgres did some
suboptimal things in response to some of those restrictions, but
that's a different matter.

The quote that caught my attention was:

  The reason I originally looked as Postgres was precisely because of
  it's good support for SQL99, it's just the Perl DBI interface which
  isn't up to the job.

  --  Posted by Alan Burlison on July 24, 2004 at 12:32 AM PDT


author: Greg Copeland

text:
On Mon, 26 Jul 2004 22:21:46 +0000, Richard L. Hamilton wrote:

http://www.postgresql.org

A native windows port should be out in the next couple of months.  Alphas
of the port have been available for some time.  I believe they are now
officially considered to be betas at this point.

Just FYI, from the SP perspective, with PostgreSQL, you can write stored
procedures in Perl, Python, TCL, C/C++, Java (I think, I know they've been
working on it), and it's own native, Oracle-like, langauge.  I'm sure I'm
missing several language options there too.

Cheers,

Greg


text:
At Thu, 29 Jul 2004 17:07:03 +1000, "Alan Hargreaves - Product Technical Support (APAC)" <[email]> writes:

Here's what I got, just now.  The "elbonian_database_technology"
dig is cute, but it'd be cuter if the blog itself worked....

   Internal Server Error

   The server encountered an internal error or misconfiguration and was
   unable to complete your request.

   Please contact the server administrator, [name removed]@sun.com and
   inform them of the time the error occurred, and anything you might
   have done that may have caused the error.

   More information about this error may be available in the server error log.
   Apache/2.0.49 (Unix) mod_jk2/2.0.4 Server at blogs.sun.com Port 80


text:
Rich Teer <[email]> wrote in message news:<[email]>...

I would hazard a guess that Linux was supported first due to a more
diverse set of drivers available for Linux - basing JDS on Solaris x86
would require some major scrambling on Sun's part to broaden the HCL for
Solaris. I wouldn't be surprised if Linuxisms were also an issue.

I'm hoping that one fall-out of porting Solaris to AMD64 is a broader
range of drivers for Solaris Sparc whether written by Sun or the device
manufacturer.

-Erik


text:
Rich Teer wrote:
...

Thanks Rich... but I think you know that Sun will favor
one or the other eventually.  Can't imagine them leaving
Solaris and Linux on equal footing.  Just my opinion.


author: JEDIDIAH

text:
["Followup-To:" header set to comp.os.linux.advocacy.]
On 2004-07-26, Don Davis <[email]> wrote:
[deletia]

Sure it does. The low cost operating system may be optimized by the
high cost application vendor to operate best with the application with
minimial extra cost.

This is where Free Beer and Free-as-in-speech converge.

Oracle can contribute to the Linux kernel in an effort to get more
of shrinking IT budgets for themselves. They can push out Sun and
they can push out Veritas giving their customers an apparent bargain
while still getting their usual arm+leg.

If you think triggers and stored procedures are what make an enterprise
RDBMS advanced then you have no real understanding of the problem domain.


author: Gavin Maltby

text:
Rich Teer wrote:

Hey Rich - the grin looks remarkably as I remember you!

Gavin


author: Robert Mazur

text:
Don Davis wrote:

Off topic, but for the record MySQL's version 5, currently in alpha, has
stored procedures and *I believe* triggers.

Rob


author: Alan Hargreaves - Product Technical Support (APAC

text:
Rich Teer wrote:

Have a read of Alan Burlinson's experiences with databases at
http://blogs.sun.com/roller/comments/alanbur/Weblog/elbonian_database_technology
and the comments to his blog. I found it informative.

alan.


author: Frank Cusack

text:
[aix and linux ng stripped]

On Thu, 29 Jul 2004 10:14:40 -0600 GreyCloud <[email]> wrote:

Well, on S9 /usr/include/sys/elf_ia64.h exists ... and sys/proc.h has
  #define      _ISA_IA64       1
so I'd say it's reasonable to assume at least some work has been going
on here.

/fc


author: Chris Cox

text:
Rich Teer wrote:

So... you're NDS info says that Sun says "Linux sucks??"  Probably
not.  Certainly not the message being communicated internally
at Sun and certainly not the message being communicated outside
of Sun.

Though I did expect you to respond to my comments... shame it
wasn't somebody officially from Sun though.

Actually JDS is more tied to a Linux distribution (which is JDS).
JDS is a Linux distribution.  Not some kind of wrapper on top
of *ix. Those are Sun's words...

This information is approximately 1-2 weeks old now.  I suppose
that's a long time in technology.

So we are at an impasse.  Rich says Sun is the same ole Sun
focusing on Solaris.  Sun executives (via Sun employees to me) say
otherwise.  Who is right?  Anyone else have better info than this?

The reason I posted like I did is that I made a post in another
forum basically saying EXACTLY what you've said here and I was
contacted directly by someone from Sun who set me straight
on the matter.  I didn't want to believe them either.


author: Richard D. Latham

text:
Chris Cox <[email]> writes:

< snip >

 ... "high end SMP is somewhat of a niche market nowadays" ...

I wish I had enough money that I could consider a multi-billion dollar
a year market was a "niche market" :-)


text:
On Mon, 26 Jul 2004 19:36:46 GMT Rich Teer <[email]> wrote:

Indeed, JDS has nothing (zilch, zero, nada) to do with Linux other
than that happens to be an OS it runs *on top of*.

I think it's really funny that you folks are arguing about whether or
not JDS is a Linux distro, with "Linux" not being part of the name,
whereas the more interesting (in the laffable and dare I say
embarrasing Sun marketing way) conflict is that it has nothing to do
with "Java" which is the "J"!

Especially ironic because I'm sure Sun would sue anyone else trying
to distribute a non-Java product that carried Java in the title.  Didn't
Sun already sue MicroSoft for just such a thing?

Let's rebrand FreeBSD as javaOS and just make sure tomcat is part of
the base install.  That'd be pretty close to the JDS in terms of name
misuse.

/fc


author: [redacted]

text:
In comp.unix.solaris Chris Cox <[email]> wrote:

[deletia]

Er, that's one heck of a big "niche," then.

Kurt


text:
On Fri, 30 Jul 2004 00:16:28 -0700 Paul Eggert <[email]> wrote:

Worked for me, earlier today.  The summary is, Oracle is great, all
open source db's are missing features one takes for granted in a "real"
database.

Like Solaris vs. Linux.

/fc


text:
Thomas Dehn wrote:

This news really isn't what I was expecting.  Actually, I find it a bit
disturbing that a shakeout of some kind is taking place and we are left
with one or two processor chip makers left.


text:
On Tue, 27 Jul 2004 21:52:29 -0400 Tim <[email]> wrote:

I'm glad to pay just for the man pages alone.  I mostly use Linux, and
I *must* keep a Solaris box around for the man pages.  It's a sad state
of affairs.

Here are 2 examples that make you jump for joy at Solaris:

RHL9 has 3 different versions of sync() man pages, each of them
disagreeing with the others.  sigh.  I haven't checked new RHL (FC2
or AS3) but I'm sure it's no different.

RHL9's printf(3) man page is truncated.

Lots of man pages fail to render.

I love the Linux trick of using a file in /proc instead of a program.
This guarantees lack of a man page.  No documentation for /proc/mdstat?
hahahaha ready for the enterprise yah right!

God I hate linux.

/fc


text:
GreyCloud wrote:

Seems to be in the news:

http://www.forbes.com/technology/feeds/general/2004/07/29/generalvnunet_2004_07_29_eng-vnunet_eng-vnunet_082546_5103390150074986821.html?partner=yahoo&referrer=

Has a quote from JS saying Sun is looking at this (so it must be true).

Gavin


text:
Gregory Toomey wrote:

My once-yearly excursion into advocacy arguments.  Slow learner.
I'm sure this has been discussed countless times before.  Nonetheless,
I foolishly hit a few dictionary sites ...

Commodity:

  1. A generic, mostly unprocessed, good that can be processed and resold
  2. A useful item that can be used to commercial or other advantage
  3. Something affording convenience, advantage or profit
  4. advantage, or benefit
  5. a class of economic goods

Now I'd suggest that the quote above is using the first form, suggesting that
operating systems have become generic - differing little from version to
version, offering much the same set of functionality, same quality, same
this that and everything.  I'd agree that if OS were commodities in this narrow
sense that there'd be little room for Solaris or any other OS to
distinguish itself from others.

But I can't buy in to that narrowminded definition.  I'd say that OS have
become commodities in the sense that they're a class of economic goods,
lots of people have one, they all have a similar set of core features to
create an application runtime environment etc.  But there is still plenty
of room for operating systems to distinguish themselves: quality, testing,
reputation, stability, features, binary compatability across releases/patches,
ease of maintenance, ease of installation/configuration, tuning,
debugging, facilitation of development environment, availability
features, scalability, price, performance, licensing model,
open source, hardware support, available applications, ease of
administration, support, etc etc (I'm sure I've left out some key ones,
the point is there are many areas).

Now you can take any OS and hold it against those categories, and I guess
anyone so doing should also weight the categories in advance according
to what is important to them.  Across the category scores there is no
one OS today that is a clear leader in all;  even when weighted I'm
certain there is no one winner for all situations.  Thinking just of
Solaris for a moment I can see some (I'd say many) areas where it's the
leader or right up there, and others where it's less good or perhaps not
at all good.  Whether it is the correct choice for a particular
application depends on whether its stronger features align with
your requirements ratings, and it's weaker points are only a detractor
of those aspects are important to you.  It's up to the OS vendor to
realize their strengths and appropriate markets, and their weaknesses
and corresponding missed market opportunities.

Another underlying assertion in quotes such as the above would also
seem to be that lists of features/categories etc as above are
either achieved or not achieved by a particular OS - there are no stages
in between, and suggesting there's no way beyond the state-of-the-art.
It's almost as if the underlying belief is that "how to write an OS"
or "how to introduce feature X to an OS" used to be well kept
commercial secrets with the accompanying assumption that these things
were really really difficult/complex, yet now these secrets have been
divulged and the real truth - that it's dead easy and everyone can
do it - has been exposed.  The truth is that it's generally not
trivial to do well, that it is complex, that maturity and evolution
really do count, that feature quality really isn't a boolean quantity,
not everybody can do it (or if they do they don't do it even nearly
equally well) etc.

Now I hope that anyone who has bothered to read this far has noticed that
I've not chosen to explicitly sing the praises or highlight the
deficiencies of any one OS distribution.  They all have their
strengths and weaknesses.  My beef is against the implication that
OS being a "commodity" even begins to suggest that all OS are
approximately equal or can be easily made so.  But to come off the
fence a little, I do very firmly believe that Solaris 10 (or Solaris Express
for the time being) is a very strong performer in many of the categories and
makes itself a particularly worthy contender in many (but not all) markets.
But I do recognise that there are areas where others lead the way or
are on a par - we won't be staying still in all those areas, either.

Gavin

Speaking for myself and not necessarily for Sun


text:
["Followup-To:" header set to comp.os.linux.advocacy.]
On 2004-07-26, Richard D. Latham <[email]> wrote:

	That's what? 1000 machines?

	That's pretty much a niche.


author: CJT

text:
Richard D. Latham wrote:

I wish I had enough money to afford one of those high end SMP machines.
I'd happily admit to being a niche if that's all it took.


text:
["Followup-To:" header set to comp.os.linux.advocacy.]
On 2004-07-31, Benjamin Gawert <[email]> wrote:

Well, if you design the 32bit processor right you will only need "extensions"
in order for it to support larger operands. The 64bit processor shouldn't
be doing things fundementally different from the 32bit ones.

[deletia]


text:
Benjamin Gawert wrote:

This is a new viewpoint to me.  How much different is the performance
between the Itanium2 and the amd64 at a corporate level?  Or is this
question not really answerable yet?


text:
Frank Cusack wrote:

Now that is funny!  Unfortunately true though (for the most part).

Redirected followup to the solaris and linux groups.  Let's not
abuse the bsd folks.


author: Timothy J. Bogart

text:
Paul Eggert wrote:

Did I get it wrong, or was the real point that an update to the PerlDBI
was needed to get around what was alleged to be a fundamental lack in
Postgres - the lack of cursor support.  Including, in the dialog, a
message from Postgres folks indicating it wasn't going to be addressed
anytime soon.


text:
[email] (Erik Magnuson) writes in comp.unix.solaris:
|I would hazard a guess that Linux was supported first due to a more
|diverse set of drivers available for Linux - basing JDS on Solaris x86
|would require some major scrambling on Sun's part to broaden the HCL for
|Solaris.

Especially since at the time JDS was begun, Solaris x86 was
"indefinitely delayed" and all the engineers who could have
written those drivers had been reassigned to other tasks.


author: Brian Utterback

text:
Chris Cox wrote:

It's two mints in one.

Sun is a very large company. There are a large number of people that are focused
on Linux as a product. There are a large number of people focused on Linux as
a platform among others. And there are a large number of people focused on
Solaris.

There is a lot going on in the Solaris front, what with all the innovations
in Solaris 10 and the open sourcing project. Of course there is more focus
on Solaris, since just about all the Solaris kernel developers are here. Linux
doesn't directly require so many resource directly, even if the plans are large.


text:
Chris Cox wrote:

The goal is JDS on the desktop. Not Linux on the desktop, not Solaris on
the desktop, JDS on the desktop. Sun doesn't want a Solaris shop or a
Linux shop; we want a Sun shop!


author: John D Groenveld

text:
In article <[email]>,
Erik Magnuson <[email]> wrote:

Hazardous guess.

If you Google Peder Ulander you'll find a better guess why MadHatter for
Solaris on the SunRay and Blade 2000 was an after-thought for the
Cobalt Networks alumni.

John
[email]


author: Chris Thompson

text:
In article <ce340t$3v1$[email]>,
Gavin Maltby  <g_a_v_i_n.m_a_l_t_b_y@s_u_n.com> wrote:

The snapshot of the author in Rich's forthcoming book should be
really interesting ... :-)

Chris Thompson
Email: cet1 [at] cam.ac.uk


author: Alan Coopersmith

text:
Frank Cusack <[email]> writes in comp.unix.solaris:
|On Thu, 29 Jul 2004 10:14:40 -0600 GreyCloud <[email]> wrote:
|> Of course.  After you review it then you can add me to their discount
|> list.  Is there any truth to the rumours that Sun is porting Solaris
|> to the Itanium2 chip?
|
|Well, on S9 /usr/include/sys/elf_ia64.h exists ... and sys/proc.h has
|  #define      _ISA_IA64       1
|so I'd say it's reasonable to assume at least some work has been going
|on here.

That happened years ago, before the Sun/Intel partnership to port
Solaris to what was then called "Merced" came to an unglorious end.
You can probably still find reports from that time in google.


author: Joerg Schilling

text:
In article <ce4qhj$iop$[email]>,
Alan Coopersmith  <[email]> wrote:


author: GreyCloud

text:
Gavin Maltby wrote:

Hmmm... the Itanium line won't be cheap tho.


author: Benjamin Gawert

text:
GreyCloud wrote:

It depends on the applications. Itaniums are not slow. The first generation
wasn't really fast at integer operations but flew on fp-Performance (at the
time the first Itanium came out it's fp-Performance outnumbered almost all
CPUs except the POWER4 if I remember correctly). With Itanium2, the integer
performance also made a big step forward.

Performance-wise both Opteron and Itanium are somewhat close, but CPU
performance is just one part of system performance. Opteron for example with
its integrated memory controller is NUMA technology, and in multiprocessor
environments You'll find that the memory performance is very fast if the CPU
needs data from the memory connected to its own memory controller but quite
slow when having to access data residing in memory that's connected to
another CPU.

Besides all technical things You should never forget that You usually don't
buy "an Itanium CPU", "a PA-RISC CPU" or "a UltraSPARC CPU". Usually You buy
a complete package containing hardware and software to solve a certain
problem. Different software runs at different efficiency on different
platforms. Benchmarks like the SPEC can just give You a general overview of
the capabilities, the only thing that counts in professional computing is
the resulting performance on the needed applications.

You don't just buy a CPU but a platform, and with Your platform decision You
also fixate Yourself in terms of service and upgradeability. Sun has it's
market, IBM pSeries (sorry, of course it's p5 now) also has its market, as
have Opteron and the Itanium - despite the bad press. Itanium is a very
powerful platform. We have a bunch of HP Superdomes upgraded from PA-RISC to
Itanium, and we are very satisfied with their crunching capabilities.

Benjamin


text:
CJT wrote:

Hmmm... how many companies have an E10K, E15K??  While these units
do sell... it's still a small number of companies who actually
need this kind of high end powerhouse.

Similary, how many companies have a mainframe??  Same arguments.

Don't confuse "niche market" with an unprofitable one.  IMHO,
always higher margins to be had with the niche markets.  It's
not a bad business to be in.


text:
Paul Eggert wrote:

I guess I said that badly because I wasn't paying enough attention.

You are right, there is cursor support of sorts, but the author contacts
the postgress guys with this linked correspondence:

"Leon Brocard wrote:

You can iterate over large sets in batches using SELECT queries with
LIMIT and OFFSET clauses inside a loop. I don't know if this will help
you, but I have used it in the past.

Work is being committed to the postgress core at this moment to provide
for nested transactions, so cursors might be more useful in future, but
for now you need to take care with large data sets.

cheers

andrew"

Though I think the fundamental issue remains the same - the two OSS
databases tried (MySql and Postgress) do not handle cursors according to
his needs.  It would seem this sort of thing is customary on commercial
databases.

I wish I were a bit more up on the actual coding involved ...


text:
Brian Utterback wrote:
...

I hear what you are saying, and perhaps Sun is actively trying to
pursuade folks to both strategies.  I've seen stranger things.

Hmmm.. my problem is trying to figure out what the TRUE direction
is.  Even is Sun is seemingly 100% Linux and 100% Solaris, eventually,
one will out favor the other.  What I think I hear you saying is
that Solaris is favored.... but that's certainly not what
Sun's marketing and sales folks are saying.... well at least
not from what I've been told.

I haven not been told that Sun isn't Solaris anymore... but
certainly I have been told that Sun is totally behind their
JDS LINUX (emphasis on LINUX) product.  If JDS is migrating
to a Solaris based version, this could make a huge difference
with regards to software and hardware choices being made.
Not sure if Sun understands that.


text:
Brian Utterback wrote:
...snip...

Does this imply more of a shift away from hardware and OS's for
Sun?  Will JES be on Linux as well as Solaris?  Just curious.


author: peder

text:
Actually John, Erik's guess is far closer to reality than your slanted
assumption.  There were a number of factors that pushed out the Sol
x86 delivery to be later than Linux.  That said, it was always
communicated from day one that JDS was a solution that ran on
Solaris/SPARC, Sol x86 and Linux.  I hate to let you down John, but my
coming from Cobalt is irrelevant to the desktop strategy.

JDS was/is actually delivered on Solaris as an integrated set of
applications (GNOME, Mozilla, Evo, Star, etc.) well over a year before
the first packaged JDS for Linux shipped in December.  Sun has had
great success with the Sun Rays and Sun Blades running the JDS stack.
The Linux play was an extension to the Sun Desktop strategy, enabling
us to go after CIOs that were already preferring Linux/OSS and
interested in desktop solutions.

-peder


author: Thomas Dehn

text:
"GreyCloud" <[email]> wrote:

Well, for the next few years we still have
- the x86 family (Intel, AMD, and VIA)
- PowerPC (IBM)
- Sparc (Sun, TI, Fujitsu)
Plus a few smaller ones in niche markets such as supercomputers.
We also have billions of processor chips in other devices, such
as mobile telephones, smartcards, and even in cars. As these have
other demands than computers, it is quite possible
that different hardware architectures prosper there.

Thomas


author: Erik Magnuson

text:
[email] (John D Groenveld) wrote in message news:<cebt6g$l4j$[email]>...

I was referring to why using Linux was preferable to using Solaris x86
for the initial OS for JDS. It seems obvious that Sun would have more
luck winning converts to JDS if there was a way of using existing
machines - especially as an escape from MS's new license plan.

Knowing a little about the history of Cobalt, it would be natural to
port to Linux first. Sun's buying Cobalt was not as smart a move as
when they bought FPS/Cray from SGI.

Ultimately, it would make sense to use a thin client and server
combination when the existing PC hardware wears out.

- Erik


author: Arthur Corliss

text:
["Followup-To:" header set to comp.unix.aix.]
On 2004-07-31, Thomas Dehn <[email]> wrote:
Bdd

Don't forget the MIPS family, the foundation of the SGI/IRIX platform.
There are certainly less choices than there used to be, but there's still
a lot of competitive innovation going on between the remaining players.


text:
In comp.unix.solaris Chris Cox <[email]> wrote:

[high-end SMP == "niche" market]

Boatloads. I've been in a lot of datacenters and machine rooms since
1993. *Every* one of them had a least one piece of traditional big
iron or one or more "high-end SMP UNIX systems, where "high-end"
means >8 CPUs. Most of these datacenters and machine rooms had
multiple mainframes, multiple SMP UNIX systems, or both. One even
had four SP/2s, in addition to assorted traditional SMP systems
and the odd mainframes. The point being, of course, that it's more
common than you might think.

Indeed.

Kurt


text:
Benjamin Gawert wrote:

Thnx for the heads up.  A good report.


text:
[email] (peder) writes in comp.unix.solaris:
|JDS was/is actually delivered on Solaris as an integrated set of
|applications (GNOME, Mozilla, Evo, Star, etc.) well over a year before
|the first packaged JDS for Linux shipped in December.

Except for Evolution, which Sun has never released for Solaris, and for
the integration between the other ones, which isn't really much to speak
of.  (You can't even save your Mozilla windows as part of your GNOME
session, since they don't speak the same session saving protocol.)


text:
In article <[email]>,
peder <[email]> wrote:

Besides the killing of StarOffice for Solaris x86 by Desktop Software
in 2003, what other factors pushed out Solaris x86 delivery later
than Linux?

What are the differences between the Enterprise Linux Client stack
for Solaris delivered over a year before the first packaged JDS for
Linux shipped in December and Desktop Software's Project Wells?

John
[email]


text:
[email] (peder) wrote in message news:<[email]>...

Thanks for affirming my guess. The guess was based on experience with
Linux and Solaris (both Sparc and x86), with Linux having a
substantial lead over Solaris in the x86 world.

My hope is that work on the AMD64 port of Solaris will increase
availability of drivers for both AMD64 and Sparc. This may be made
easier by most add-on devices being either 1394 or USB based rather
than PCI based.

Sun was touting Solaris x86 in 2001 as being suitable for for many
home and small office tasks, using StarOffice and Netscape. Don't
think that passed the giggle test, though. Going back 10 years, HP was
putting quite a bit of effort into making HP-UX suitable for general
desktops, having Lotus 123 ported in late 1991 and AmiPro ported a
couple of years later (this was obviously not for generic PC's).

A lot of companies have been adverse to using non-x86 hardware, even
when a higher performance hardware would pay for itself in a few
months (e.g. a machine to support a $25,000 FEA package). The usual
line is that once the machine is too slow to use as a workstation, it
can then be assigned to a secretary (I have yet to see that happen).
With that kind of mindset, JDS would be an easier sell to CIO's if it
could run on generic PC hardware.

One further Linux vs Solaris comment. Sun has been under a lot of
pressure to abandon Solari in favor of linux (particularly from the
"investment community). What most of these folks don't understand is
that most of what goes into a Linux distro can be ported to Solaris
without too much difficulty.


text:
Arthur Corliss wrote:

Well, SGI is working on getting rid of them and concentrating on Itanium and
Linux, so I wouldn't take the MIPS/IRIX systems to have somewhat like a
future. No wonder when looking on the low performance of their current MIPS
line...

Benjamin


text:
In article <[email]>,
Erik Magnuson <[email]> wrote:

Ultimately? If Sun was selling to a CTO ripping out her call center
of a thousand 5 year old ThinkCenters running OS/2, allowing the
sales rep to sell the JDS on Sun Ray solution makes more cents.

Oh wait, the reason the MadHatters were porting Sun Ray Server to
Linux was to support Enterpise Linux Client.

John
[email]


text:
Benjamin Gawert wrote:
...
I'm certainly not disagreeing with that.  Niche volumes don't
mean low margins even if we're talking low volumes.

Even though the last comment was somewhat IBM related, I'm adjusting
followups to just the solaris and linux groups.


author: JEDIDIAH

text:
["Followup-To:" header set to comp.os.linux.advocacy.]
On 2004-07-27, <[email]> <[email]> wrote:

It's probably getting less common. As the big application vendors
(like Oracle) for machines such as those push clustering more and
more, such beasts may go the way of the dinosaurs.

NUMA boxes are much more expensive per MIP than their smaller cousins.

This expense is enough to motivate change.

Sure, it's a lucrative niche. Therein lies the problem.


text:
Chris Cox wrote:

You'd be surprised how many E15ks (E10k is old, slow and outdated) are
around, or IBM p690's, or HP Superdomes...

Not that small as You might think...

Well, from what I know IBM still makes most of its money from Mainframes...

Benjamin


text:
Chris Cox wrote:

The government buys them and they aren't profitable. :-))


text:
On 2004-08-02, Benjamin Gawert <[email]> wrote:

;-) Don't you have some anti-Linux/x86 zealots to poke in comp.sys.sgi.*?
I disagree with how much engineering SGI has put into MIPS, to be sure, but
it's still a much better architecture than x86/VILW crap.  MIPS has been
pretty consistent over the years in getting more ops executed per clock
cycle than just about everyone, including RISC vendors.  Great family, it's
just unfortunate that SGI has chosen to not push it like they should have.

And don't diss IRIX too much -- like AIX, IRIX is another OS that offers a
lot of features that I wish Linux would get.  Linux is a good OS, but it has
a long ways to go before it can rival either of them in functionality and
robustness.


text:
[email] (John D Groenveld) wrote in message news:<cep2o1$n18$[email]>...

Sun never "killed" Star for Sol x86. At the point in time that
StarOffice 7 went into development and testing, Sol x86 was in it's
"indefinitely delayed" period.  When Sol x86 was put back on the
priority list, the engineering team jumped on creating a supported
Star 7 package.  It takes more than a day or a couple of weeks to
build and test software.

The factors that actually had a huge impact on JDS Sol x86 include
HCL, drivers for cameras, printers, graphics cards, etc. The most
important thing that had impact here was that there was no support for
the latest versions of Mozilla, Evolution, GNOME, etc. in Sol x86 -
meaning that Sun needed to develop and manage the ports.  All of this
stuff being readily available in Linux, gave the Linux kit a faster
TTM.  Rather than holding the release up of JDS  v1, we launched it to
make sure that we had first mover advantage in the alternative
enterprise client space.

It was an enterprise client stack for Solaris (not Linux) that was
first introduced a while back.  It ran GNOME 2.0, Mozilla, Star and
there is a beta version of Evo that was available.  Wells is the
updated integration of the tools.

-peder


text:
Arthur Corliss wrote:

In what regards is MIPS better than x86 or IA64 (I assume You are targeting
Itanium with "VLIW")?

Well, MIPS _is_ RISC. And besides that, Your statement is wrong. POWER,
PA-RISC and Itanium do more OPS/clock cycle than even the R16k.

And not to forget that this is just a theoretical view. The only thing that
counts is real world performance. It doesn't count if MIPS does more
instructions per clock cycle if the absolute system performance is behind of
all the competitors...

SGI made a wise decision to look for something different. Something that's
more up to date. Something SGI can make some money. Something software
vendors are willing to write software for (which isn't the case for IRIX).
Looks they are very successful with their Itanium-based Altix...

Benjamin


text:
On 2004-08-05, Benjamin Gawert <[email]> wrote:

In that the RISC set isn't just downright strange and awkward.  Consider this,
Intel made the following decisions with their VLIW implementation:
You get fourteen bits for opcodes in each 41 bit instruction.  That's a hell
of a lot of room for instruction sets, and yet they decided that opcodes
weren't going to be universally unique, instead they're going to mean different
things depending on the target execution unit.  And if that isn't bad enough,
instructions are delivered in three op bundles, and *that* bundle has five
bits reserved to help route the embedded ops -- but not directly, but
according to a instruction "template" (which is what the five bits actually
designate).  And given that a lot of op combinations across multiple
execution units are not covered by the templates, that makes them illegal
altogether, so you can very well end up with either poorly optimised
instructions grouped in a bundled, or even noops.

To compound these potential shortfalls, you have to rely specifically on
the compiler to group instructions correctly to get maximum simultaeous
execution.  The processor has no support for internal optimisations of
those groups.

I'm sorry, but that's a pretty convoluted setup with too much potential for
wasted bandwidth.  I'd rather contend with a large number of shallow
pipelines with decent branch-prediction logic.

I should have been more clear:  I meant that even compared to *other* RISC
vendors MIPS comes up well.   In any event, you're only partly right.  The
Power4 core can do (theoretically) 8 IPCs, but that's only eight fetch/issue,
it can only retire five.  You also get hit with a 10 cycle misprediction
penalty every time due to deeper pipelines.  The R14k (I don't have the stats
on the R16k, so this isn't entirely a fair comparison) only has six stages,
and can retire as many as it can fetch/issue (which I think is five).  In
practice, this means that it can consistently hit closer to its theoretical
IPC than the Power4 can.

So, now reality sets in:  comparing SPEC CPU 2000 for a 1.7GHz Power4 and
a 600MHz R14k I see that the Power4 scores a little more than twice the R14k
for almost three times the clock rate on CINT2000.  CFP2000 shows a bit more
than three times, so the processors are about on par there.  Let's see, the
only scores for Itanium from the same time frame as SGI's most recent reported
scores show it coming up short.  Scores from 2003 - current for Itanium are
better, but I have no doubt that system architecture improvements for the
Origin are also improved.  PA-8700 comes up short on both as well.

So, based on that I doubt the R16k would look worse against these processors.
Futhermore, I could compare the Power4's 680 million transistors and 50+ watts
of power consumption to the R14k's 7 million transistors and 17+ watts draw.
Taken holistically, I'd say MIPS has one of the most efficient architectures
out there.

That's a whole other ball of wax, then.  There's a damned good reason why
SGI is still in business, just like Cray and their vector processors.  In the
real world clock rate isn't as important as memory and disk I/O, and NUMAflex
is a damned good architecture when you need to scale to the thousands of
processors.  And they still support twice the number of processors per SSI
nodes than they can on Altix/Linux.

SGI hasn't abandoned MIPS yet, though they may have to.  As good as the tech
is, they're a lot like DEC.  Bad marketing can kill the best tecnology.


text:
In article <[email]>,
peder <[email]> wrote:

It looked that way from customers' perspective: no longer supporting
the Solaris x86 version of the Star Office 6.0 product by distributing
patches in 2002 and then not including a Solaris x86 build in the
StarOffice 6.1 (7) Early Access program in 2003, well after Solaris x86
was resurrected.

Was that "false" impression Desktop Software Marketing's or Curtis
Sasaki's [1] bug?

Did Geoff Baysinger mis-speak when at SunNetwork 2003 in San Francisco
he explained that the lack of support for StarOffice for Solaris x86
was the "principle problem" in getting JDS for Solaris x86?

How did John Loiacono get the "false" impression [2] that the ELC product
that Desktop Solutions was hawking was actually Enterprise Linux Client?

If the client stack has long been available for Solaris (SPARC)
why did Jonathan Schwartz fail to mention that it ran at the time
on Sun's SunRay systems when he demo'd the client stack on that
Linux white box at the Project MadHatter unveiling at SunNetwork 2002?

Why does Dan Baigent's December 11th SJDS 2003 Technical Overview
presentation list Sun Ray Server for Linux as higher confidence for
CY2004 than Project Wells: "Solaris SPARC Only!" ?

Why is JDS for Solaris (SPARC) and the Sun Ray still not available
for purchase from SunStore [3]?

1. <URL:http://www.save-solaris.org/sasaki.html>

2. <URL:http://www.theregister.co.uk/2003/03/29/suns_linux_distro_is_dead/>
| Interestingly, John Loiacono, vice president of operating platforms at
| Sun said that the company now defines the ELC (Enterprise Linux
| Client) as "software" rather than "hardware". A hint that Sun really,
| really doesn't want to be in the box-shifting business when the Client
| launches in the middle of this year.

3. <URL:http://store.sun.com/CMTemplate/Catalog/PartDescPopup.jsp?pm_id=3b1d04:fe2ef9c06f:-5d26&FamOID=4AD8A261D21DB211AF6DD75BED4369F8>
| Operating System      Java Desktop System includes the operating
| environment, which is Linux.

John
[email]


text:
In article <[email]>,
peder <[email]> wrote:

Correct - they cannot ;-)

Star is available since 1985 (at this time only for SunOS-2.x) I did never
announce a kill for any of the of the supported platforms...

Source:
	ftp://ftp.berlios.de/pub/star/
	ftp://ftp.berlios.de/pub/star/alpha/

Solaris binary install packages:
	http://www.blastwave.org/packages.php