Intel marginalizing Itanium even faster than expected? - VMS

This is a discussion on Intel marginalizing Itanium even faster than expected? - VMS ; On Aug 14, 3:25 pm, moro...@world.std.spaamtrap.com (Michael Moroney) wrote: > Keith Parris writes: > >David J Dachtera wrote: > >> It now appears there never was an intent to continue VMS past Itanic. > >I've seen public statements that the ...

+ Reply to Thread
Page 2 of 4 FirstFirst 1 2 3 4 LastLast
Results 21 to 40 of 61

Thread: Intel marginalizing Itanium even faster than expected?

  1. Re: Intel marginalizing Itanium even faster than expected?

    On Aug 14, 3:25 pm, moro...@world.std.spaamtrap.com (Michael Moroney)
    wrote:
    > Keith Parris writes:
    > >David J Dachtera wrote:
    > >> It now appears there never was an intent to continue VMS past Itanic.

    > >I've seen public statements that the work done for the Itanium port
    > >makes future ports easier, and even that HP _expects_ to port to other
    > >architectures in the future -- that's just the way things go: whole new
    > >sets of CPU architectures/technology arise in the industry every decade
    > >or so.

    >
    > In the process of porting from VAX to Alpha, they designed Alpha VMS to be
    > very easy to port to something else. It worked, too. Alpha and Itanium
    > VMS are built from a common source with relatively few architecture
    > specific modules/pieces of code. It's not unreasonable to port VMS to
    > something else in the future - IF HP actually wanted to. IF.


    I think this Technical Journal article should be required reading for
    anyone discussing the Alpha->Itanium port:

    <http://h71000.www7.hp.com/openvms/journal/v6/
    porting_openvms_to_integrity.html>
    if above wraps, use:


    "Overview

    This article describes the 3.5 years of work that went into porting
    OpenVMS to Integrity Servers. A little history, the rationale behind
    the major decisions, and some technical details are combined to
    present the engineering that resulted in OpenVMS I64 V8.2. First there
    is a chronology of the major events and decisions of the project. The
    concluding sections provide details of some of the technology that we
    found the most interesting and challenging and how they came together
    to produce the preliminary and final releases.

    ...."

    You'll notice that lots of time went into tool-building, and the fact
    that *nix was already ported to IA was more than a little helpful.


  2. Re: Intel marginalizing Itanium even faster than expected?

    Keith Parris wrote:
    >
    > David J Dachtera wrote:
    > > It now appears there never was an intent to continue VMS past Itanic.

    >
    > I've seen public statements that the work done for the Itanium port
    > makes future ports easier, and even that HP _expects_ to port to other
    > architectures in the future -- that's just the way things go: whole new
    > sets of CPU architectures/technology arise in the industry every decade
    > or so.
    >
    > > HP's
    > > intent was to supplant VMS with UX and the only way to do that was to eliminate
    > > VMS's operating platforms: first Alpha as a condition of the Compaq merger, now
    > > Itanic, apparently the hidden part of agenda.

    >
    > There's a fatal flaw in this logic: HP-UX runs on Itanium too, so
    > eliminating Itanium would eliminate the HP-UX platform too. Better find
    > a better hypothesis. :-)


    Try again. See the "binary Compatibility" page:
    http://www.intel.com/cd/ids/develope...114.htm?page=4
    (URL is likely to have wrapped)

    "Interestingly, binaries for Hewlett-Packard's PA-RISC architecture
    can also be run without modification. To run these binaries, sites
    must use Aries* software that HP will bundle with all its systems.
    Aries performs two primary functions: it performs dynamic translation
    of PA-RISC binaries into native 64-bit processor instructions for
    immediate execution, and it performs interpretation of other, lesser-
    used PA-RISC commands"

    ...., ostensibly a form of "PEST" (PA-RISC Executable (S?) Translation) for
    PA-RISC executables. So, porting to EM64T is likely to not be a huge issue for
    UX, except perhaps where "endianness" is concerned. That could pose a challenge,
    I suppose, unless the difference can be made up in software without a
    significant performance hit (remember MicroVAXes and VAX floating point?).

    Since HP does not properly understand "business needs", however, the probability
    of a VMS port to EM64T is effectively nil.

    --
    David J Dachtera
    dba DJE Systems
    http://www.djesys.com/

    Unofficial OpenVMS Marketing Home Page
    http://www.djesys.com/vms/market/

    Unofficial Affordable OpenVMS Home Page:
    http://www.djesys.com/vms/soho/

    Unofficial OpenVMS-IA32 Home Page:
    http://www.djesys.com/vms/ia32/

    Unofficial OpenVMS Hobbyist Support Page:
    http://www.djesys.com/vms/support/

  3. Re: Intel marginalizing Itanium even faster than expected?

    On 08/14/07 15:55, Main, Kerry wrote:
    >> -----Original Message----- From: Ron Johnson
    >> [mailto:ron.l.johnson@cox.net] Sent: August 14, 2007 1:15 PM
    >> To: Info-VAX@Mvb.Saic.Com Subject: Re: Intel marginalizing
    >> Itanium even faster than expected?
    >>
    >> On 08/14/07 09:39, Tom Linden wrote:
    >>> On Tue, 14 Aug 2007 07:17:04 -0700, Keith Parris
    >>> wrote:
    >>>
    >>>> There's a fatal flaw in this logic: HP-UX runs on Itanium
    >>>> too, so eliminating Itanium would eliminate the HP-UX
    >>>> platform too. Better find a better hypothesis.
    >>> I imagine that it would not be too difficult to port HP-UX to
    >>> another platform

    >> I think it would be simpler to harden & add features to Linux
    >> (both kernel and userland).
    >>
    >> --

    >
    > And how would you propose that HP do this when it does not own or
    > control the kernel?


    Regarding the kernel, they'd do it the same way that IBM, Oracle,
    Intel, Red Hat, etc, etc, ad nauseum do: release the code under the
    GPL2 and get it into the mainline.

    Regarding userland code: there's no law that says that userland must
    be open source. (After all, Oracle makes a pretty penny selling
    licenses for RDBMSs that run on Linux.)

    --
    Ron Johnson, Jr.
    Jefferson LA USA

    Give a man a fish, and he eats for a day.
    Hit him with a fish, and he goes away for good!

  4. Re: Intel marginalizing Itanium even faster than expected?

    In article <46C24D98.84FDC435@spam.comcast.net>, David J Dachtera writes:
    >Keith Parris wrote:
    >>
    >> David J Dachtera wrote:
    >> > It now appears there never was an intent to continue VMS past Itanic.

    >>
    >> I've seen public statements that the work done for the Itanium port
    >> makes future ports easier, and even that HP _expects_ to port to other
    >> architectures in the future -- that's just the way things go: whole new
    >> sets of CPU architectures/technology arise in the industry every decade
    >> or so.
    >>
    >> > HP's
    >> > intent was to supplant VMS with UX and the only way to do that was to eliminate
    >> > VMS's operating platforms: first Alpha as a condition of the Compaq merger, now
    >> > Itanic, apparently the hidden part of agenda.

    >>
    >> There's a fatal flaw in this logic: HP-UX runs on Itanium too, so
    >> eliminating Itanium would eliminate the HP-UX platform too. Better find
    >> a better hypothesis. :-)

    >
    >Try again. See the "binary Compatibility" page:
    >http://www.intel.com/cd/ids/develope...114.htm?page=4
    >(URL is likely to have wrapped)
    >
    >"Interestingly, binaries for Hewlett-Packard's PA-RISC architecture
    >can also be run without modification. To run these binaries, sites
    >must use Aries* software that HP will bundle with all its systems.
    >Aries performs two primary functions: it performs dynamic translation
    >of PA-RISC binaries into native 64-bit processor instructions for
    >immediate execution, and it performs interpretation of other, lesser-
    >used PA-RISC commands"
    >

    The target for Aries is Itanium. To a first approximation think VEST/AEST.
    See

    http://devresource.hp.com/drc/STK/docs/refs/Aries.jsp

    >...., ostensibly a form of "PEST" (PA-RISC Executable (S?) Translation) for
    >PA-RISC executables. So, porting to EM64T is likely to not be a huge issue for
    >UX, except perhaps where "endianness" is concerned.


    You would first need to rewrite Aries to target EM64T.
    Also Aries does not support emulation of privileged PA instructions which are
    used by the OS.

    Saying that you could just port HP-UX to EM64T by rewriting Aries would be like
    thinking you could just port VMS to EM64T by just rewriting AEST.



    David Webb
    Security team leader
    CCSS
    Middlesex University



    >That could pose a challenge,
    >I suppose, unless the difference can be made up in software without a
    >significant performance hit (remember MicroVAXes and VAX floating point?).
    >
    >Since HP does not properly understand "business needs", however, the probability
    >of a VMS port to EM64T is effectively nil.
    >
    >--
    >David J Dachtera
    >dba DJE Systems
    >http://www.djesys.com/
    >
    >Unofficial OpenVMS Marketing Home Page
    >http://www.djesys.com/vms/market/
    >
    >Unofficial Affordable OpenVMS Home Page:
    >http://www.djesys.com/vms/soho/
    >
    >Unofficial OpenVMS-IA32 Home Page:
    >http://www.djesys.com/vms/ia32/
    >
    >Unofficial OpenVMS Hobbyist Support Page:
    >http://www.djesys.com/vms/support/


  5. RE: Intel marginalizing Itanium even faster than expected?

    > -----Original Message-----
    > From: Ron Johnson [mailto:ron.l.johnson@cox.net]
    > Sent: August 14, 2007 10:43 PM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: Re: Intel marginalizing Itanium even faster than expected?
    >
    > On 08/14/07 15:55, Main, Kerry wrote:
    > >> -----Original Message----- From: Ron Johnson
    > >> [mailto:ron.l.johnson@cox.net] Sent: August 14, 2007 1:15 PM
    > >> To: Info-VAX@Mvb.Saic.Com Subject: Re: Intel marginalizing
    > >> Itanium even faster than expected?
    > >>
    > >> On 08/14/07 09:39, Tom Linden wrote:
    > >>> On Tue, 14 Aug 2007 07:17:04 -0700, Keith Parris
    > >>> wrote:
    > >>>
    > >>>> There's a fatal flaw in this logic: HP-UX runs on Itanium
    > >>>> too, so eliminating Itanium would eliminate the HP-UX
    > >>>> platform too. Better find a better hypothesis.
    > >>> I imagine that it would not be too difficult to port HP-UX to
    > >>> another platform
    > >> I think it would be simpler to harden & add features to Linux
    > >> (both kernel and userland).
    > >>
    > >> --

    > >
    > > And how would you propose that HP do this when it does not own or
    > > control the kernel?

    >
    > Regarding the kernel, they'd do it the same way that IBM, Oracle,
    > Intel, Red Hat, etc, etc, ad nauseum do: release the code under the
    > GPL2 and get it into the mainline.
    >


    Lets get real here.

    Large vendors are very competitive and the only one who really determines
    what goes into the Linux kernel is Linus T.

    So, Oracle releases some cluster code which will allow RAC to work better
    and IBM releases some cluster code which will make WebSphere work better.

    And to play devils advocate for a second - What goes into the kernel?

    What if clustering is not as hot a topic for Linus as scalability, SMP or
    a host of other considerations? Who prioritizes what goes in because every
    release is all about trade-off between new features, compatibility and
    schedules.

    Do you really think IBM, HP, Oracle etc are all going to base their future
    directions on what one person believes should be "allowed" into the Linux
    kernel?

    Again, lets get back to reality here and drop the hype ok?

    > Regarding userland code: there's no law that says that userland must
    > be open source. (After all, Oracle makes a pretty penny selling
    > licenses for RDBMSs that run on Linux.)
    >


    Sure they do, but for them the platform does not matter as they charge the
    same for Oracle on Windows, Linux, OpenVMS, Solaris, HP-UX etc. The only
    real difference is in the area of multi-socket systems.

    The challenge is how to increase the scalability of Oracle on Linux when
    changes are required at the kernel level. That is one area where IBM (DB2/AIX)
    and Microsoft (SQL Server) have a big advantage over Oracle ie. they control
    the OS kernel and the DB.

    [sidebar note - it was stated at one time that one of the primary design
    factors that go into Windows kernel is how to make SQL Server run better.]

    Do you think this is lost on Oracle?

    No way.


    Regards


    Kerry Main
    Senior Consultant
    HP Services Canada
    Voice: 613-592-4660
    Fax: 613-591-4477
    kerryDOTmainAThpDOTcom
    (remove the DOT's and AT)

    OpenVMS - the secure, multi-site OS that just works.








  6. Re: Intel marginalizing Itanium even faster than expected?

    On 2007-08-14 21:38, "FredK" wrote:

    > [...]
    > Or POWER - noticed how IBM appears to be hiding how much they make/lose on
    > the chip business? It is very, very expensive to maintain the ability to
    > design and FAB your own chips with cutting edge processes.


    Most customers don't want to buy *chips* only -- they want to buy
    *systems* of course ...

    > [...]


    So profit is made with systems, software and services.

    Michael

    --
    Real names enhance the probability of getting real answers.
    My e-mail account at DECUS Munich is no longer valid.


  7. Re: Intel marginalizing Itanium even faster than expected?


    "Michael Unger" wrote in message
    news:5igm26F3ogoalU2@mid.individual.net...
    > On 2007-08-14 21:38, "FredK" wrote:
    >
    >> [...]
    >> Or POWER - noticed how IBM appears to be hiding how much they make/lose
    >> on
    >> the chip business? It is very, very expensive to maintain the ability to
    >> design and FAB your own chips with cutting edge processes.

    >
    > Most customers don't want to buy *chips* only -- they want to buy
    > *systems* of course ...
    >


    You'd think so, but would be confused by the focus on the chip architecture
    here. The cost of desiging and FABing cutting edge chip technology is huge
    and becomes part of the cost of the system. By having unique parts like EV7
    for example, the systems themselves are then also composed of mostly custom
    ASICs and can't be amortized.

    >> [...]

    >
    > So profit is made with systems, software and services.
    >


    Minus the cost to build the systems, and buy or make the parts, and write
    the software, and sell the systems, and perform the service, etc. Business
    101? So I'm not sure what the point is. If the parts are cheaper, and the
    systems especially at the low and mid0range begin to be able to share things
    with higher volume systems, and in fact the systems can also run all the
    common OSes (Windows, Linux) - plus your own home-grown ones (HP-UX, VMS,
    NSK)... it all makes perfect sense if you are trying to sustain a long term
    business.




  8. Re: Intel marginalizing Itanium even faster than expected?

    david20@alpha2.mdx.ac.uk wrote:
    >
    > In article <46C24D98.84FDC435@spam.comcast.net>, David J Dachtera writes:
    > >Keith Parris wrote:
    > >>
    > >> David J Dachtera wrote:
    > >> > It now appears there never was an intent to continue VMS past Itanic.
    > >>
    > >> I've seen public statements that the work done for the Itanium port
    > >> makes future ports easier, and even that HP _expects_ to port to other
    > >> architectures in the future -- that's just the way things go: whole new
    > >> sets of CPU architectures/technology arise in the industry every decade
    > >> or so.
    > >>
    > >> > HP's
    > >> > intent was to supplant VMS with UX and the only way to do that was to eliminate
    > >> > VMS's operating platforms: first Alpha as a condition of the Compaq merger, now
    > >> > Itanic, apparently the hidden part of agenda.
    > >>
    > >> There's a fatal flaw in this logic: HP-UX runs on Itanium too, so
    > >> eliminating Itanium would eliminate the HP-UX platform too. Better find
    > >> a better hypothesis. :-)

    > >
    > >Try again. See the "binary Compatibility" page:
    > >http://www.intel.com/cd/ids/develope...114.htm?page=4
    > >(URL is likely to have wrapped)
    > >
    > >"Interestingly, binaries for Hewlett-Packard's PA-RISC architecture
    > >can also be run without modification. To run these binaries, sites
    > >must use Aries* software that HP will bundle with all its systems.
    > >Aries performs two primary functions: it performs dynamic translation
    > >of PA-RISC binaries into native 64-bit processor instructions for
    > >immediate execution, and it performs interpretation of other, lesser-
    > >used PA-RISC commands"
    > >

    > The target for Aries is Itanium. To a first approximation think VEST/AEST.
    > See
    >
    > http://devresource.hp.com/drc/STK/docs/refs/Aries.jsp
    >
    > >...., ostensibly a form of "PEST" (PA-RISC Executable (S?) Translation) for
    > >PA-RISC executables. So, porting to EM64T is likely to not be a huge issue for
    > >UX, except perhaps where "endianness" is concerned.

    >
    > You would first need to rewrite Aries to target EM64T.


    O.k. What did I miss here?

    An EM64T article says, "binaries for Hewlett-Packard's PA-RISC architecture can
    also be run without modification. To run these binaries, sites must use Aries*
    software that HP will bundle with all its systems."

    (Note that the asterisk ("*") is unresolved. See the URL cited above for
    confirmation.)

    The implications are that Aries can be used to run PA-RISC binaries (privileged
    code issues were not singled out) on EM64T.

    Check article again; however, I'm not detecting any contextual ambiguities that
    would support your statement, unless the article is intentionally being
    ambiguous and misleading.

    --
    David J Dachtera
    dba DJE Systems
    http://www.djesys.com/

    Unofficial OpenVMS Marketing Home Page
    http://www.djesys.com/vms/market/

    Unofficial Affordable OpenVMS Home Page:
    http://www.djesys.com/vms/soho/

    Unofficial OpenVMS-IA32 Home Page:
    http://www.djesys.com/vms/ia32/

    Unofficial OpenVMS Hobbyist Support Page:
    http://www.djesys.com/vms/support/

  9. RE: Intel marginalizing Itanium even faster than expected?


    > > Regarding userland code: there's no law that says that userland must
    > > be open source. (After all, Oracle makes a pretty penny selling
    > > licenses for RDBMSs that run on Linux.)
    > >

    >
    > Sure they do, but for them the platform does not matter as they charge
    > the
    > same for Oracle on Windows, Linux, OpenVMS, Solaris, HP-UX etc. The
    > only
    > real difference is in the area of multi-socket systems.
    >
    > The challenge is how to increase the scalability of Oracle on Linux
    > when
    > changes are required at the kernel level. That is one area where IBM
    > (DB2/AIX)
    > and Microsoft (SQL Server) have a big advantage over Oracle ie. they
    > control
    > the OS kernel and the DB.
    >
    > [sidebar note - it was stated at one time that one of the primary
    > design
    > factors that go into Windows kernel is how to make SQL Server run
    > better.]
    >
    > Do you think this is lost on Oracle?
    >


    Well, not to belabor the point, but it is not a major exercise to add a
    module to the kernel,
    even one that makes major changes in behavior. Or to issue a special purpose
    version of Linux
    with a modified kernel.

    IBM does this with tape drivers, DB/2, etc.

    This rather makes the idea of a very stable controlled kernel attractive to
    companies
    like IBM. Especially when they sell mainframe systems because of Linux.

    -Paul



  10. Re: Intel marginalizing Itanium even faster than expected?

    In article <46C396CD.48586B11@spam.comcast.net>, David J Dachtera writes:
    >david20@alpha2.mdx.ac.uk wrote:
    >>
    >> In article <46C24D98.84FDC435@spam.comcast.net>, David J Dachtera writes:
    >> >Keith Parris wrote:
    >> >>
    >> >> David J Dachtera wrote:
    >> >> > It now appears there never was an intent to continue VMS past Itanic.
    >> >>
    >> >> I've seen public statements that the work done for the Itanium port
    >> >> makes future ports easier, and even that HP _expects_ to port to other
    >> >> architectures in the future -- that's just the way things go: whole new
    >> >> sets of CPU architectures/technology arise in the industry every decade
    >> >> or so.
    >> >>
    >> >> > HP's
    >> >> > intent was to supplant VMS with UX and the only way to do that was to eliminate
    >> >> > VMS's operating platforms: first Alpha as a condition of the Compaq merger, now
    >> >> > Itanic, apparently the hidden part of agenda.
    >> >>
    >> >> There's a fatal flaw in this logic: HP-UX runs on Itanium too, so
    >> >> eliminating Itanium would eliminate the HP-UX platform too. Better find
    >> >> a better hypothesis. :-)
    >> >
    >> >Try again. See the "binary Compatibility" page:
    >> >http://www.intel.com/cd/ids/develope...114.htm?page=4
    >> >(URL is likely to have wrapped)
    >> >
    >> >"Interestingly, binaries for Hewlett-Packard's PA-RISC architecture
    >> >can also be run without modification. To run these binaries, sites
    >> >must use Aries* software that HP will bundle with all its systems.
    >> >Aries performs two primary functions: it performs dynamic translation
    >> >of PA-RISC binaries into native 64-bit processor instructions for
    >> >immediate execution, and it performs interpretation of other, lesser-
    >> >used PA-RISC commands"
    >> >

    >> The target for Aries is Itanium. To a first approximation think VEST/AEST.
    >> See
    >>
    >> http://devresource.hp.com/drc/STK/docs/refs/Aries.jsp
    >>
    >> >...., ostensibly a form of "PEST" (PA-RISC Executable (S?) Translation) for
    >> >PA-RISC executables. So, porting to EM64T is likely to not be a huge issue for
    >> >UX, except perhaps where "endianness" is concerned.

    >>
    >> You would first need to rewrite Aries to target EM64T.

    >
    >O.k. What did I miss here?
    >
    >An EM64T article says, "binaries for Hewlett-Packard's PA-RISC architecture can
    >also be run without modification. To run these binaries, sites must use Aries*
    >software that HP will bundle with all its systems."
    >
    >(Note that the asterisk ("*") is unresolved. See the URL cited above for
    >confirmation.)
    >
    >The implications are that Aries can be used to run PA-RISC binaries (privileged
    >code issues were not singled out) on EM64T.
    >
    >Check article again; however, I'm not detecting any contextual ambiguities that
    >would support your statement, unless the article is intentionally being
    >ambiguous and misleading.
    >

    What can I say. The unresolved * probably refers to the comment on HP-UX at the
    bottom of page 2 which also has an unresolved *.
    The statement seems to be trying to imply that anything applying
    to Itanium applies to EM64T ie referring to www.hp.com
    "Most of the information there that is specific to the Itanium Processor
    Family is relevant to Intel EM64T as well.
    "
    which to my mind is a pretty bogus statement.

    As far as I can see from the HP site Aries is just targeted at Itanium.
    If you can find a HP reference to support the idea that Aries can target EM64T
    then please post it. Without a port of HP-UX to EM64T I don't see the point of
    having Aries target EM64T any more than a version of AEST targetting EM64T
    would be useful without a port of VMS to EM64T. The limitations of Aries like
    those of AEST mean that it cannot be used on it's own to port the OS.


    David Webb
    Security team leader
    CCSS
    Middlesex University



    >--
    >David J Dachtera
    >dba DJE Systems
    >http://www.djesys.com/
    >
    >Unofficial OpenVMS Marketing Home Page
    >http://www.djesys.com/vms/market/
    >
    >Unofficial Affordable OpenVMS Home Page:
    >http://www.djesys.com/vms/soho/
    >
    >Unofficial OpenVMS-IA32 Home Page:
    >http://www.djesys.com/vms/ia32/
    >
    >Unofficial OpenVMS Hobbyist Support Page:
    >http://www.djesys.com/vms/support/


  11. RE: Intel marginalizing Itanium even faster than expected?

    > -----Original Message-----
    > From: Paul Raulerson [mailtoaul@raulersons.com]
    > Sent: August 16, 2007 12:57 AM
    > To: Main, Kerry; Info-VAX@Mvb.Saic.Com
    > Subject: RE: Intel marginalizing Itanium even faster than expected?
    >
    >
    > > > Regarding userland code: there's no law that says that userland

    > must
    > > > be open source. (After all, Oracle makes a pretty penny selling
    > > > licenses for RDBMSs that run on Linux.)
    > > >

    > >
    > > Sure they do, but for them the platform does not matter as they

    > charge
    > > the
    > > same for Oracle on Windows, Linux, OpenVMS, Solaris, HP-UX etc. The
    > > only
    > > real difference is in the area of multi-socket systems.
    > >
    > > The challenge is how to increase the scalability of Oracle on Linux
    > > when
    > > changes are required at the kernel level. That is one area where IBM
    > > (DB2/AIX)
    > > and Microsoft (SQL Server) have a big advantage over Oracle ie. they
    > > control
    > > the OS kernel and the DB.
    > >
    > > [sidebar note - it was stated at one time that one of the primary
    > > design
    > > factors that go into Windows kernel is how to make SQL Server run
    > > better.]
    > >
    > > Do you think this is lost on Oracle?
    > >

    >
    > Well, not to belabor the point, but it is not a major exercise to add a
    > module to the kernel,
    > even one that makes major changes in behavior. Or to issue a special
    > purpose
    > version of Linux
    > with a modified kernel.
    >
    > IBM does this with tape drivers, DB/2, etc.
    >
    > This rather makes the idea of a very stable controlled kernel
    > attractive to
    > companies
    > like IBM. Especially when they sell mainframe systems because of Linux.
    >
    >
    > -Paul
    >


    Based on what you have stated, while adding drivers specific to your specific
    hardware or ISV package may not be that hard, the challenge is adding partsto
    the kernel which will impact more than your code e.g. clustering, SMP,
    multi-threading, scheduling, locking etc. These are the areas that typically
    get major changes when one looks to optimize a kernel for additional scalability,
    stability, new features etc.

    That's when the fun begins regarding who's wishes get priority.

    Especially when you have many different ego's with different agendas involved.

    Reference:
    http://tinyurl.com/lrecx (May, 2006)
    http://tinyurl.com/preview.php?num=lrecx (preview)

    "Andrew Morton, the lead maintainer of the Linux production kernel, is worried
    that an increasing number of defects are appearing in the 2.6 version and is
    considering drastic action to resolve it.

    "I believe the 2.6 kernel is slowly getting buggier. It seems we're adding bugs
    at a higher rate than we're fixing them," Morton said in a talk at the LinuxTag
    conference in Wiesbaden, Germany, on Friday."

    Regards


    Kerry Main
    Senior Consultant
    HP Services Canada
    Voice: 613-592-4660
    Fax: 613-591-4477
    kerryDOTmainAThpDOTcom
    (remove the DOT's and AT)

    OpenVMS - the secure, multi-site OS that just works.




  12. Re: Intel marginalizing Itanium even faster than expected?

    In article ,
    "Main, Kerry" writes:
    >> -----Original Message-----
    >> From: Paul Raulerson [mailtoaul@raulersons.com]
    >> Sent: August 16, 2007 12:57 AM
    >> To: Main, Kerry; Info-VAX@Mvb.Saic.Com
    >> Subject: RE: Intel marginalizing Itanium even faster than expected?
    >>
    >>
    >> > > Regarding userland code: there's no law that says that userland

    >> must
    >> > > be open source. (After all, Oracle makes a pretty penny selling
    >> > > licenses for RDBMSs that run on Linux.)
    >> > >
    >> >
    >> > Sure they do, but for them the platform does not matter as they

    >> charge
    >> > the
    >> > same for Oracle on Windows, Linux, OpenVMS, Solaris, HP-UX etc. The
    >> > only
    >> > real difference is in the area of multi-socket systems.
    >> >
    >> > The challenge is how to increase the scalability of Oracle on Linux
    >> > when
    >> > changes are required at the kernel level. That is one area where IBM
    >> > (DB2/AIX)
    >> > and Microsoft (SQL Server) have a big advantage over Oracle ie. they
    >> > control
    >> > the OS kernel and the DB.
    >> >
    >> > [sidebar note - it was stated at one time that one of the primary
    >> > design
    >> > factors that go into Windows kernel is how to make SQL Server run
    >> > better.]
    >> >
    >> > Do you think this is lost on Oracle?
    >> >

    >>
    >> Well, not to belabor the point, but it is not a major exercise to add a
    >> module to the kernel,
    >> even one that makes major changes in behavior. Or to issue a special
    >> purpose
    >> version of Linux
    >> with a modified kernel.
    >>
    >> IBM does this with tape drivers, DB/2, etc.
    >>
    >> This rather makes the idea of a very stable controlled kernel
    >> attractive to
    >> companies
    >> like IBM. Especially when they sell mainframe systems because of Linux.
    >>
    >>
    >> -Paul
    >>

    >
    > Based on what you have stated, while adding drivers specific to your specif=
    > ic
    > hardware or ISV package may not be that hard, the challenge is adding parts=
    > to
    > the kernel which will impact more than your code e.g. clustering, SMP,
    > multi-threading, scheduling, locking etc. These are the areas that typicall=
    > y
    > get major changes when one looks to optimize a kernel for additional scalab=
    > ility,
    > stability, new features etc.
    >
    > That's when the fun begins regarding who's wishes get priority.
    >
    > Especially when you have many different ego's with different agendas involv=
    > ed.


    All the more reason to not use Linux for a commercial venture and use
    BSD instead and then just maintain your own kernel.

    bill

    >
    > Reference:
    > http://tinyurl.com/lrecx (May, 2006)
    > http://tinyurl.com/preview.php?num=3Dlrecx (preview)
    >
    > "Andrew Morton, the lead maintainer of the Linux production kernel, is worr=
    > ied
    > that an increasing number of defects are appearing in the 2.6 version and i=
    > s
    > considering drastic action to resolve it.
    >
    > "I believe the 2.6 kernel is slowly getting buggier. It seems we're adding =
    > bugs
    > at a higher rate than we're fixing them," Morton said in a talk at the Linu=
    > xTag
    > conference in Wiesbaden, Germany, on Friday."


    And none of that comes as a surprise to me. Consider the source!!

    bill

    --
    Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
    bill@cs.scranton.edu | and a sheep voting on what's for dinner.
    University of Scranton |
    Scranton, Pennsylvania | #include

  13. RE: Intel marginalizing Itanium even faster than expected?

    > -----Original Message-----
    > From: bill@triangle.cs.uofs.edu [mailto:bill@triangle.cs.uofs.edu] On
    > Behalf Of Bill Gunshannon
    > Sent: August 16, 2007 9:38 AM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: Re: Intel marginalizing Itanium even faster than expected?
    >


    [snip]

    > >>

    > >
    > > Based on what you have stated, while adding drivers specific to your

    > specif=
    > > ic
    > > hardware or ISV package may not be that hard, the challenge is adding

    > parts=
    > > to
    > > the kernel which will impact more than your code e.g. clustering,

    > SMP,
    > > multi-threading, scheduling, locking etc. These are the areas that

    > typicall=
    > > y
    > > get major changes when one looks to optimize a kernel for additional

    > scalab=
    > > ility,
    > > stability, new features etc.
    > >
    > > That's when the fun begins regarding who's wishes get priority.
    > >
    > > Especially when you have many different ego's with different agendas

    > involv=
    > > ed.

    >
    > All the more reason to not use Linux for a commercial venture and use
    > BSD instead and then just maintain your own kernel.
    >
    > bill
    >


    But how many people have the ability to properly maintain SMP, clustering,
    drivers, multi-threading, scheduling etc kernel code?

    Also, how many companies want to risk not being able to point the finger
    at someone if there is a major issue? What if the guru who maintains this
    code leaves, is on vacation or becomes a disgruntled employee?

    Fwiw, companies today are focussing on reducing risk. They are not taking
    any more risk on that will potentially hurt them big time - especially whenthey
    are under a regulatory umbrella like FERPA, HIPPA, SOX etc.

    [snip]


    Kerry Main
    Senior Consultant
    HP Services Canada
    Voice: 613-592-4660
    Fax: 613-591-4477
    kerryDOTmainAThpDOTcom
    (remove the DOT's and AT)

    OpenVMS - the secure, multi-site OS that just works.




  14. Re: Intel marginalizing Itanium even faster than expected?

    In article ,
    "Main, Kerry" writes:
    >> -----Original Message-----
    >> From: bill@triangle.cs.uofs.edu On
    >> Behalf Of Bill Gunshannon
    >> Sent: August 16, 2007 9:38 AM
    >> To: Info-VAX@Mvb.Saic.Com
    >> Subject: Re: Intel marginalizing Itanium even faster than expected?
    >>

    >
    > [snip]
    >
    >> >>
    >> >
    >> > Based on what you have stated, while adding drivers specific to your

    >> specif=3D
    >> > ic
    >> > hardware or ISV package may not be that hard, the challenge is adding

    >> parts=3D
    >> > to
    >> > the kernel which will impact more than your code e.g. clustering,

    >> SMP,
    >> > multi-threading, scheduling, locking etc. These are the areas that

    >> typicall=3D
    >> > y
    >> > get major changes when one looks to optimize a kernel for additional

    >> scalab=3D
    >> > ility,
    >> > stability, new features etc.
    >> >
    >> > That's when the fun begins regarding who's wishes get priority.
    >> >
    >> > Especially when you have many different ego's with different agendas

    >> involv=3D
    >> > ed.

    >>
    >> All the more reason to not use Linux for a commercial venture and use
    >> BSD instead and then just maintain your own kernel.
    >>
    >> bill
    >>

    >
    > But how many people have the ability to properly maintain SMP, clustering,
    > drivers, multi-threading, scheduling etc kernel code?


    In what? HP-UX? VMS? BSD? I would bet a lot more for BSD than
    either of the others.

    >
    > Also, how many companies want to risk not being able to point the finger
    > at someone if there is a major issue? What if the guru who maintains this
    > code leaves, is on vacation or becomes a disgruntled employee?


    Apply the same logic to the ogther contenders. Again, it would be a lot
    easier to replace a BSD guru than an HO-UX or VMS guru. I guess it's not
    as big a risk as you think. Actually, BSD would be much less of a risk.

    >
    > Fwiw, companies today are focussing on reducing risk. They are not taking
    > any more risk on that will potentially hurt them big time - especially when
    > they are under a regulatory umbrella like FERPA, HIPPA, SOX etc.


    See above. Seems that the biggest risk along the lines you offered
    above are with VMS where replacing a "guru" could be nigh on impossible.
    And yet, HP happily got rid of a majority of those gurus. Guess they
    don't see it as a risk either.

    bill

    --
    Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
    bill@cs.scranton.edu | and a sheep voting on what's for dinner.
    University of Scranton |
    Scranton, Pennsylvania | #include

  15. RE: Intel marginalizing Itanium even faster than expected?

    > -----Original Message-----
    > From: bill@triangle.cs.uofs.edu [mailto:bill@triangle.cs.uofs.edu] On
    > Behalf Of Bill Gunshannon
    > Sent: August 16, 2007 12:24 PM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: Re: Intel marginalizing Itanium even faster than expected?
    >


    [snip]

    > >> All the more reason to not use Linux for a commercial venture and

    > use
    > >> BSD instead and then just maintain your own kernel.
    > >>
    > >> bill
    > >>

    > >
    > > But how many people have the ability to properly maintain SMP,

    > clustering,
    > > drivers, multi-threading, scheduling etc kernel code?

    >
    > In what? HP-UX? VMS? BSD? I would bet a lot more for BSD than
    > either of the others.
    >


    The point I was making is that it is very difficult for a company who's primary
    focus is something other than OS platform support to "maintain their own kernel"
    as you called it.

    Once you start twiddling bits in the kernel on your own, you are opening all
    sorts of potential future compatibility issues with new releases, security
    patches, custom drivers etc.

    > >
    > > Also, how many companies want to risk not being able to point the

    > finger
    > > at someone if there is a major issue? What if the guru who maintains

    > this
    > > code leaves, is on vacation or becomes a disgruntled employee?

    >
    > Apply the same logic to the ogther contenders. Again, it would be a
    > lot
    > easier to replace a BSD guru than an HO-UX or VMS guru. I guess it's
    > not
    > as big a risk as you think. Actually, BSD would be much less of a
    > risk.
    >


    Again, no one twiddles kernel bits in OpenVMS or HP-UX or AIX or z/OS on
    their own. They may apply patches from by the appropriate vendors, but if it
    does not work, then that vendor is on the hook to fix it - not the Customer..
    If the patch causes problems with a new release, the vendor is on the hook to
    find a solution.

    In your scenario, a new security fix may come out that subsequently appears
    to cause random crashing, but the Customer is on the hook to fix it
    because they have modified numerous kernel bits here and there. It could be
    timing or sequencing or any number of issues that are extremely hard to
    troubleshoot - especially when downtime is hard to come by and/or complex
    environments like clusters.

    > >
    > > Fwiw, companies today are focussing on reducing risk. They are not

    > taking
    > > any more risk on that will potentially hurt them big time -

    > especially when
    > > they are under a regulatory umbrella like FERPA, HIPPA, SOX etc.

    >
    > See above. Seems that the biggest risk along the lines you offered
    > above are with VMS where replacing a "guru" could be nigh on
    > impossible.
    > And yet, HP happily got rid of a majority of those gurus. Guess they
    > don't see it as a risk either.
    >
    > bill
    >


    Unless I have misunderstood what you mean by "maintaining your own kernel",
    you are missing the point. You are recommending maintaining your own
    kernel which is exponentially more difficult to support once you start
    twiddling SMP, Scheduling etc kernel bits on your own. Its not just
    platform SysAdmin support any more, its kernel maintenance, compatibility
    testing etc.

    Regards


    Kerry Main
    Senior Consultant
    HP Services Canada
    Voice: 613-592-4660
    Fax: 613-591-4477
    kerryDOTmainAThpDOTcom
    (remove the DOT's and AT)

    OpenVMS - the secure, multi-site OS that just works.





  16. Re: Intel marginalizing Itanium even faster than expected?

    On 08/16/07 12:04, Main, Kerry wrote:
    [snip]
    >
    > The point I was making is that it is very difficult for a company who's primary
    > focus is something other than OS platform support to "maintain their own kernel"
    > as you called it.
    >
    > Once you start twiddling bits in the kernel on your own, you are opening all
    > sorts of potential future compatibility issues with new releases, security
    > patches, custom drivers etc.


    Gah! I agree with Kerry!!!!

    (Does that mean I'm wrong?)

    --
    Ron Johnson, Jr.
    Jefferson LA USA

    Give a man a fish, and he eats for a day.
    Hit him with a fish, and he goes away for good!

  17. Re: Intel marginalizing Itanium even faster than expected?

    In article ,
    "Main, Kerry" writes:
    >> -----Original Message-----
    >> From: bill@triangle.cs.uofs.edu On
    >> Behalf Of Bill Gunshannon
    >> Sent: August 16, 2007 12:24 PM
    >> To: Info-VAX@Mvb.Saic.Com
    >> Subject: Re: Intel marginalizing Itanium even faster than expected?
    >>

    >
    > [snip]
    >
    >> >> All the more reason to not use Linux for a commercial venture and

    >> use
    >> >> BSD instead and then just maintain your own kernel.
    >> >>
    >> >> bill
    >> >>
    >> >
    >> > But how many people have the ability to properly maintain SMP,

    >> clustering,
    >> > drivers, multi-threading, scheduling etc kernel code?

    >>
    >> In what? HP-UX? VMS? BSD? I would bet a lot more for BSD than
    >> either of the others.
    >>

    >
    > The point I was making is that it is very difficult for a company
    > who's primary focus is something other than OS platform support
    > to "maintain their own kernel" as you called it.


    And the point I was making is that they already do this for both HP-UX
    and VMS. Both of which are much harder to find truly guru status kernel
    engineers for than BSD.

    >
    > Once you start twiddling bits in the kernel on your own, you are
    > opening all sorts of potential future compatibility issues with
    > new releases, security patches, custom drivers etc.


    Then why does HP do it for both HP-UX and VMS? Might be better to
    stick to their "primary focus", Windows.

    >
    >> >
    >> > Also, how many companies want to risk not being able to point the

    >> finger
    >> > at someone if there is a major issue? What if the guru who maintains

    >> this
    >> > code leaves, is on vacation or becomes a disgruntled employee?

    >>
    >> Apply the same logic to the ogther contenders. Again, it would be a
    >> lot
    >> easier to replace a BSD guru than an HO-UX or VMS guru. I guess it's
    >> not
    >> as big a risk as you think. Actually, BSD would be much less of a
    >> risk.
    >>

    >
    > Again, no one twiddles kernel bits in OpenVMS or HP-UX or AIX or
    > z/OS on their own. They may apply patches from by the appropriate
    > vendors, but if it does not work, then that vendor is on the hook
    > to fix it - not the Customer.


    Oh, I am sure that no one is doing this at home, but surely HP does it.
    SO why is it not risky and good business to do it on proprietary OSes
    and not to do the same on BSD.

    > If the patch causes problems with a new release, the vendor is on the
    > hook to find a solution.


    As they are right now with HP-UX and VMS. Why is that acceptable in
    the one case, but not in another?

    >
    > In your scenario, a new security fix may come out that subsequently appears
    > to cause random crashing, but the Customer is on the hook to fix it
    > because they have modified numerous kernel bits here and there. It could be
    > timing or sequencing or any number of issues that are extremely hard to
    > troubleshoot - especially when downtime is hard to come by and/or complex
    > environments like clusters.


    Where did I say that? I specifically said that HP would state clearly
    and absolutlely exactly what kernel their stuff works with. Another
    reason for going with BSD as opposed to Linux is you don't have to
    give the customer the source to your modifications so he can't "twiddle
    the bits" in the kernel he gets from you.

    >
    >> >
    >> > Fwiw, companies today are focussing on reducing risk. They are not

    >> taking
    >> > any more risk on that will potentially hurt them big time -

    >> especially when
    >> > they are under a regulatory umbrella like FERPA, HIPPA, SOX etc.

    >>
    >> See above. Seems that the biggest risk along the lines you offered
    >> above are with VMS where replacing a "guru" could be nigh on
    >> impossible.
    >> And yet, HP happily got rid of a majority of those gurus. Guess they
    >> don't see it as a risk either.
    >>
    >> bill
    >>

    >
    > Unless I have misunderstood what you mean by "maintaining your own kernel",


    I think you certainly have.

    > you are missing the point. You are recommending maintaining your own
    > kernel which is exponentially more difficult to support once you start
    > twiddling SMP, Scheduling etc kernel bits on your own. Its not just
    > platform SysAdmin support any more, its kernel maintenance, compatibility
    > testing etc.


    All of which HP now does for HP-UX and VMS. So using BSD instead of
    HP-UX would be no different except to open up a whole bunch of already
    written and tested applications (there's that word again!) that HP-UX
    doesn't have now. And, actually eliminate the lost guru problem as
    you would be using an OS where finding another is much easier.

    bill

    --
    Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
    bill@cs.scranton.edu | and a sheep voting on what's for dinner.
    University of Scranton |
    Scranton, Pennsylvania | #include

  18. Re: Intel marginalizing Itanium even faster than expected?

    In article <%E%wi.48364$rH6.7962@newsfe22.lga>,
    Ron Johnson writes:
    > On 08/16/07 12:04, Main, Kerry wrote:
    > [snip]
    >>
    >> The point I was making is that it is very difficult for a company who's primary
    >> focus is something other than OS platform support to "maintain their own kernel"
    >> as you called it.
    >>
    >> Once you start twiddling bits in the kernel on your own, you are opening all
    >> sorts of potential future compatibility issues with new releases, security
    >> patches, custom drivers etc.

    >
    > Gah! I agree with Kerry!!!!
    >
    > (Does that mean I'm wrong?)


    Except that I never said the customer would be "twiddling bits" in the
    kernel but actually said the exact opposite. Twiddling bits in the kernel
    would be much harder to control under Linux than under BSD because under
    the GPL you have to give them all the bits to twiddle. Under BSD, you
    don't. You can, but you don't have to. In a commercial operation, that
    can be a plus.

    bill

    --
    Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
    bill@cs.scranton.edu | and a sheep voting on what's for dinner.
    University of Scranton |
    Scranton, Pennsylvania | #include

  19. Re: Intel marginalizing Itanium even faster than expected?

    In article <5ijhj4F3p7iadU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:
    > In article <%E%wi.48364$rH6.7962@newsfe22.lga>,
    > Ron Johnson writes:
    >> On 08/16/07 12:04, Main, Kerry wrote:
    >> [snip]
    >>>
    >>> The point I was making is that it is very difficult for a company who's primary
    >>> focus is something other than OS platform support to "maintain their own kernel"
    >>> as you called it.
    >>>
    >>> Once you start twiddling bits in the kernel on your own, you are opening all
    >>> sorts of potential future compatibility issues with new releases, security
    >>> patches, custom drivers etc.

    >>
    >> Gah! I agree with Kerry!!!!
    >>
    >> (Does that mean I'm wrong?)

    >
    > Except that I never said the customer would be "twiddling bits" in the
    > kernel but actually said the exact opposite. Twiddling bits in the kernel
    > would be much harder to control under Linux than under BSD because under
    > the GPL you have to give them all the bits to twiddle. Under BSD, you
    > don't. You can, but you don't have to. In a commercial operation, that
    > can be a plus.


    But for Kerry's case of "a company whose primary focus is something
    other than OS platform support" there is no particular disincentive
    to reveal changes due to commercial competition concerns. They are
    not in the business of selling their kernel twiddling results.

  20. RE: Intel marginalizing Itanium even faster than expected?

    > -----Original Message-----
    > From: bill@triangle.cs.uofs.edu [mailto:bill@triangle.cs.uofs.edu] On
    > Behalf Of Bill Gunshannon
    > Sent: August 16, 2007 1:59 PM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: Re: Intel marginalizing Itanium even faster than expected?
    >
    > In article <%E%wi.48364$rH6.7962@newsfe22.lga>,
    > Ron Johnson writes:
    > > On 08/16/07 12:04, Main, Kerry wrote:
    > > [snip]
    > >>
    > >> The point I was making is that it is very difficult for a company

    > who's primary
    > >> focus is something other than OS platform support to "maintain their

    > own kernel"
    > >> as you called it.
    > >>
    > >> Once you start twiddling bits in the kernel on your own, you are

    > opening all
    > >> sorts of potential future compatibility issues with new releases,

    > security
    > >> patches, custom drivers etc.

    > >
    > > Gah! I agree with Kerry!!!!
    > >
    > > (Does that mean I'm wrong?)

    >
    > Except that I never said the customer would be "twiddling bits" in the
    > kernel but actually said the exact opposite. Twiddling bits in the
    > kernel
    > would be much harder to control under Linux than under BSD because
    > under
    > the GPL you have to give them all the bits to twiddle. Under BSD, you
    > don't. You can, but you don't have to. In a commercial operation,
    > that
    > can be a plus.
    >
    > bill
    >


    Bill -

    Here is your exact statement that I was responding to:

    "All the more reason to not use Linux for a commercial venture and use BSD
    instead and then just maintain your own kernel."

    The wording inferred that you were recommending Customers (not vendors) use
    BSD and simply maintain their own kernel.

    Based on your feedback, I think we are on the same page in that we both agree
    this is not what you were recommending. You seem to have been referring to
    vendors supporting their own distribution like RH does.

    Regards


    Kerry Main
    Senior Consultant
    HP Services Canada
    Voice: 613-592-4660
    Fax: 613-591-4477
    kerryDOTmainAThpDOTcom
    (remove the DOT's and AT)

    OpenVMS - the secure, multi-site OS that just works.






+ Reply to Thread
Page 2 of 4 FirstFirst 1 2 3 4 LastLast