On Wed, Jul 30, 2003 at 02:02:57AM +0800, John Summerfield wrote:
On Tue, 29 Jul 2003, Tom Duerbusch wrote:
My take on multiple images is two fold.
But first, the disclaimer:
This assumes you have sufficient resources in the first place to do
this (normally real memory).
1. I
On Tue, Jul 29, 2003 at 08:09:46PM -0700, Jim Sibley wrote:
Alan wrote:
Its just that PC's are so cheap its
easier to use several for a job _IFF_ you can solve
the management problem.
That _IFF_ is not only non-trivial technically, but
also not not-trivial financially!
You but one
Tzfir Cohen wrote
And if you had all of those Office machines as separate images on a
giant T-Rex, those IT folks would still have to manually patch each and
every image separately, and spend 15 minutes on that.
As for cloning, patch distribution etc.: those solutions
are exactly solutions (?) to
On Wed, 30 Jul 2003, Alan Altmark wrote:
On Tuesday, 07/29/2003 at 08:55 MST, Jim Sibley [EMAIL PROTECTED]
wrote:
So my question is: What moves are afoot to reduce the
number of required images by consolidating their
functions and remove the TCP/IP communications between
applications?
On Wednesday, 07/30/2003 at 08:10 ZE8, John Summerfield
[EMAIL PROTECTED] wrote:
Alan Altmark said:
won't eliminate TCP/IP comms; it just changes the latency and CPU
consumption characteristics. Avoiding TCP/IP altogether would require
application changes that would be specific to VM.
On Mer, 2003-07-30 at 04:09, Jim Sibley wrote:
MS did it again. So it takes me 15 minutes, so what?
Well, with 300,000 in the company, thats 75,000
MANHOURS. IT security doesn't care - the manhours
doesn't come out of its budget!
Which is a different problem. Failing to budget the cost
to
Reply To: Linux on 390 Port
Sent: Wednesday, July 30, 2003 1:42 AM
To: [EMAIL PROTECTED]
Subject: Re: Whither consolidation and what then?
On Tue, Jul 29, 2003 at 08:09:46PM -0700, Jim Sibley wrote:
Alan wrote:
Its just that PC's are so cheap its
easier to use
As I see it, your
alternatives are point-to-point like PPP or CTC, or
multipoint like a
TCP/IP network or channels with lots of devices.
Assuming that each of your apps are in different
machine images, CTC is NOT the way to go on s/390 or
zSeries for Linux. Its based on an old/slow protocol.
If
I had a look at the ebay prototype and it was, well,
less than moving. What they they is a fibre cable
going into a switch, then dozens of cables going to
dozens of web serves in intel boxes in racks, then
dozens of cables going to a switch to a single fibre
to a data base server.
So, with web
than
Linux can?
It is a variation of the old arguement as to which is better, VM and
serveral VSE guests or one MVS instance.
-Original Message-
From: Jim Sibley [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 29, 2003 11:55 AM
To: [EMAIL PROTECTED]
Subject: Whither consolidation and what
-Original Message-
From: Ward, Garry [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 29, 2003 11:34 AM
To: [EMAIL PROTECTED]
Subject: Re: Whither consolidation and what then?
Philosophical question?
The heart of the matter lies in why so many images in the first place?
If I need
My take on multiple images is two fold.
But first, the disclaimer:
This assumes you have sufficient resources in the first place to do
this (normally real memory).
1. I don't know this to be true with Linux, but the Unix types have
always been leary of having multiple applications running on
:17 AM
To: [EMAIL PROTECTED]
Subject: Re: Whither consolidation and what then?
My take on multiple images is two fold.
But first, the disclaimer:
This assumes you have sufficient resources in the first place to do
this (normally real memory).
1. I don't know this to be true with Linux
What happens then? You still have dozens of copies of
Linux running in dozens of EC machines. And they're
talking to each other via TCP/IP stacks over a number
of high speed connections. Have you really advanced
the architecture and capabilities of Linux?
Yes, this is a fabulous question
On Maw, 2003-07-29 at 19:10, Fargusson.Alan wrote:
At one time I did a lot of work with Unix, and I never had any problems with
multiple processes corrupting the memory of other processes. Have there
been some bugs introduced into Unix recently?
Not that I've noticed. Multiuser has gone out
On Tue, 2003-07-29 at 13:30, Alan Cox wrote:
You can run 100 sessions on a 390 but I don't think you get the
equivalent of 300Ghz of CPU power.
Of course you don't. But you might well get enough CPU to keep your
users happy, depending on what they're doing.
Also of course, the dirty little
To: [EMAIL PROTECTED]
Subject: Re: Whither consolidation and what then?
On Maw, 2003-07-29 at 19:10, Fargusson.Alan wrote:
At one time I did a lot of work with Unix, and I never had any
problems with
multiple processes corrupting the memory of other processes. Have
there
been some bugs introduced
Alan wrote:
You can run 100 sessions on a 390 but I don't think
you get the equivalent of 300Ghz of CPU power.
With the new TREXX, you're probably talking 20-30Ghz,
assuming 1.2 Ghz engines x 32.
One of the driving factors of either the multiple
virtual machines or the multiple user model is
[mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 29, 2003 10:17 AM
To: [EMAIL PROTECTED]
Subject: Re: Whither consolidation and what then?
My take on multiple images is two fold.
But first, the disclaimer:
This assumes you have sufficient resources in the first place to do
this (normally real memory).
1
On Tue, 29 Jul 2003, Tom Duerbusch wrote:
My take on multiple images is two fold.
But first, the disclaimer:
This assumes you have sufficient resources in the first place to do
this (normally real memory).
1. I don't know this to be true with Linux, but the Unix types have
always been
I've seen this behaviour, too. I once tried to move a large number of
mp3 files from one physical drive to another with rsync, and the machine
locked up, destroyed the reiserfs file systems on both drives, and I
lost a bunch of files. That's the only time I've had a near catastrophic
failure in
Quite right. I would think, that once you have an reliable production
application running, you would just leave it alone. When you get the
next release of that application, you would put it on a current level of
Linux. And then kill off the old application and old level of Linux.
That is easy
On Maw, 2003-07-29 at 20:35, Jim Sibley wrote:
One of the driving factors of either the multiple
virtual machines or the multiple user model is that,
in most applications, most of the time, a single user
is idle and your 300Ghz of power is mostly idle.
But in the PC world cpu power is cheap.
On Maw, 2003-07-29 at 19:53, Adam Thornton wrote:
Reading email shouldn't take much CPU, although if you insist on doing
it inside UltraWhizzy
K/Gnome/Mozilla/MultiMediaMailReaderNowWithGratuitousAnimation!!! then
it can find a way, I'm sure, to burn CPU.
Even that is mostly RAM and I/O heavy
On Maw, 2003-07-29 at 20:49, Dale Strickler wrote:
Does anyone know of anyone doing this sort of research now? Anyone running
this or other crash tests like this on Linux (on or off the MVS environment?)
It is simple code to write, just generate two random numbers, treat one as
an address
On Tue, 29 Jul 2003, Michael Martin wrote:
I've seen this behaviour, too. I once tried to move a large number of
mp3 files from one physical drive to another with rsync, and the machine
locked up, destroyed the reiserfs file systems on both drives, and I
lost a bunch of files. That's the only
On Tue, 29 Jul 2003, Alan Cox wrote:
On Maw, 2003-07-29 at 19:53, Adam Thornton wrote:
Reading email shouldn't take much CPU, although if you insist on doing
it inside UltraWhizzy
K/Gnome/Mozilla/MultiMediaMailReaderNowWithGratuitousAnimation!!! then
it can find a way, I'm sure, to burn
Alan Cox wrote:
crashme is part of the Linux cerberus test suite although it goes back
many years before. Roughly speaking crashme does this
Catch every exception
Generate random data
Execute it
(catching the exception to repeat)
Its found many things, including
Alan wrote:
Its just that PC's are so cheap its
easier to use several for a job _IFF_ you can solve
the management
problem.
That _IFF_ is not only non-trivial technically, but
also not not-trivial financially!
You but one cheap PC or a hundred cheap PC's, you
still have a bunch of cheap PC's.
On Tue, 29 Jul 2003, Jim Sibley wrote:
Alan wrote:
Its just that PC's are so cheap its
easier to use several for a job _IFF_ you can solve
the management
problem.
That _IFF_ is not only non-trivial technically, but
also not not-trivial financially!
You but one cheap PC or a hundred
On Tuesday, 07/29/2003 at 08:55 MST, Jim Sibley [EMAIL PROTECTED]
wrote:
So my question is: What moves are afoot to reduce the
number of required images by consolidating their
functions and remove the TCP/IP communications between
applications?
Isn't this the next logical step?
You make
31 matches
Mail list logo
