Intel marginalizing Itanium even faster than expected? - VMS

This is a discussion on Intel marginalizing Itanium even faster than expected? - VMS ; On 08/16/07 12:56, Bill Gunshannon wrote: > In article , > "Main, Kerry" writes: [snip] > > Then why does HP do it for both HP-UX and VMS? Might be better to > stick to their "primary focus", Windows. Ooooooo. ...

+ Reply to Thread
Page 3 of 4 FirstFirst 1 2 3 4 LastLast
Results 41 to 60 of 61

Thread: Intel marginalizing Itanium even faster than expected?

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

    On 08/16/07 12:56, Bill Gunshannon wrote:
    > In article ,
    > "Main, Kerry" writes:

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


    Ooooooo. That hurt.

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


    Double standard.

    [snip]
    >
    > 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.


    And re-start the Unix War.

    [snip]
    >
    > 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


    Especially because FreeBSD has a Linux-compatibility module.

    > doesn't have now. And, actually eliminate the lost guru problem as
    > you would be using an OS where finding another is much easier.



    --
    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!

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

    Main, Kerry wrote:

    > What if the guru who maintains this
    > code leaves, is on vacation or becomes a disgruntled employee?



    You really shouldn't be bringing this argument up because VMS is far
    more vulnerable than Linux in the current context.

    What if FredK leaves and there is nobody else left to handle all the X
    windows issues, the drivers to interface to the various video cards
    (which had to be reverse engineered with a lot of talent) etc etc ????
    (And I have to assume FredK has done far more work than I know about).
    And many other experienced folks have already left.

    Since VMS is in a downward trend in terms of staffing, and the more
    talented/experienced gurus are generally the first to leave, VMS is far
    more vulnerable.

    In an open source community, when one person leaves, others can jump in
    more easily because of the community aspect where many peole have seen
    the work of the guru that has left.

    You can easily teach a monkey to access source code and press a PF key
    to start the build process and deliver an executable. But you can't
    teach a young newbie indian how to start to reverse engineer a windows
    video drivers and build an equivalent Alpha/IA64 driver that feeds 8086
    code to the hardware.

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

    Ron Johnson wrote:
    > Gah! I agree with Kerry!!!!



    Don't worry. That is not as bad/dangerous as "agreeing with JF". The
    former is just an oddity. The latter has the potential to cause
    disruptions in the fabric of space/time :-)

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

    JF Mezei wrote:
    the more
    > talented/experienced gurus are generally the first to leave, VMS is far
    > more vulnerable.
    >


    I think I was just insulted! :-) :-) :-)

    --
    John Reagan
    OpenVMS Pascal/Macro-32/COBOL Project Leader
    Hewlett-Packard Company

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

    On 08/17/07 13:42, JF Mezei wrote:
    > Ron Johnson wrote:
    >> Gah! I agree with Kerry!!!!

    >
    >
    > Don't worry. That is not as bad/dangerous as "agreeing with JF". The
    > former is just an oddity. The latter has the potential to cause
    > disruptions in the fabric of space/time :-)


    Then what happens when one agrees with Boob?

    --
    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!

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

    On 08/17/07 13:42, John Reagan wrote:
    > JF Mezei wrote:
    > the more
    >> talented/experienced gurus are generally the first to leave, VMS is
    >> far more vulnerable.
    >>

    >
    > I think I was just insulted! :-) :-) :-)


    Worse: I agree with JF.

    Do you hear The Fabric ripping?

    --
    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!

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

    > -----Original Message-----
    > From: JF Mezei [mailto:jfmezei.spamnot@vaxination.ca]
    > Sent: August 17, 2007 2:39 PM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: Re: Intel marginalizing Itanium even faster than expected?
    >
    > Main, Kerry wrote:
    >
    > > What if the guru who maintains this
    > > code leaves, is on vacation or becomes a disgruntled employee?

    >
    >
    > You really shouldn't be bringing this argument up because VMS is far
    > more vulnerable than Linux in the current context.
    >


    The note was in reference to Bill inferring (or my understanding of his reference)
    that a Customer "maintain their own kernel".. Since he made that statement,he has
    clarified that he was not talking about Customers maintaining their own kernel code.

    Nobody twiddles OpenVMS kernel code except VMS Engineering and the same goes for
    HP-UX, AIX, Solaris 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.



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



    > -----Original Message-----
    > From: Main, Kerry [mailto:Kerry.Main@hp.com]
    > Sent: Thursday, August 16, 2007 8:27 AM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: 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
    > 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
    > 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."
    >


    Same is often true in any fast developing system. More and more hardware
    specific drivers are added every day to Linux, and every one of them has the
    potential to wreak havoc on the system.

    This is not true on systems like VMS or z/OS; hardware that goes in either
    uses existing drivers, or most
    often, it does not go in at all.

    -Paul

    > 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.
    >
    >




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



    > -----Original Message-----
    > From: Ron Johnson [mailto:ron.l.johnson@cox.net]
    > Sent: Thursday, August 16, 2007 12:18 PM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: 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
    >


    Naw- just coming to your senses.


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


    "JF Mezei" wrote in message
    news:70003$46c5eb36$cef8887a$24194@TEKSAVVY.COM...
    > Main, Kerry wrote:
    >
    >> What if the guru who maintains this
    >> code leaves, is on vacation or becomes a disgruntled employee?

    >
    >
    > You really shouldn't be bringing this argument up because VMS is far more
    > vulnerable than Linux in the current context.
    >
    > What if FredK leaves and there is nobody else left to handle all the X
    > windows issues, the drivers to interface to the various video cards (which
    > had to be reverse engineered with a lot of talent) etc etc ???? (And I
    > have to assume FredK has done far more work than I know about). And many
    > other experienced folks have already left.
    >
    > Since VMS is in a downward trend in terms of staffing, and the more
    > talented/experienced gurus are generally the first to leave, VMS is far
    > more vulnerable.
    >
    > In an open source community, when one person leaves, others can jump in
    > more easily because of the community aspect where many peole have seen the
    > work of the guru that has left.
    >
    > You can easily teach a monkey to access source code and press a PF key to
    > start the build process and deliver an executable. But you can't teach a
    > young newbie indian how to start to reverse engineer a windows video
    > drivers and build an equivalent Alpha/IA64 driver that feeds 8086 code to
    > the hardware.


    Golly. On the one hand I appear untaleted/unexperienced (since I haven't
    left) and on the other hand I can't be replaced.

    The one thing I have noticed in the last 30 years of working in the computer
    industry - many people think they are unique and can't be replaced - they
    are invariably wrong.

    FredK has done many things and knows many things and likes to think he is
    irreplaceable - but he knows deep down that it isn't true. A 20-something
    who doesn't know any better can pick up and take over his code. Sure.
    FredK has a lot of historical knowledge - but in fact sometimes a clean
    slate can be very useful.

    VMS is less vulnerable from loss of engineers, than from people who spend
    their time spreading FUD about Integrity just because they are POed about
    Alpha.



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

    Ron Johnson wrote:
    >
    > On 08/17/07 13:42, JF Mezei wrote:
    > > Ron Johnson wrote:
    > >> Gah! I agree with Kerry!!!!

    > >
    > >
    > > Don't worry. That is not as bad/dangerous as "agreeing with JF". The
    > > former is just an oddity. The latter has the potential to cause
    > > disruptions in the fabric of space/time :-)

    >
    > Then what happens when one agrees with Boob?


    See the Book of Revelation.

    --
    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/

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

    On 08/18/07 12:00, FredK wrote:
    [snip]
    >
    > Golly. On the one hand I appear untaleted/unexperienced (since I haven't
    > left) and on the other hand I can't be replaced.
    >
    > The one thing I have noticed in the last 30 years of working in the computer
    > industry - many people think they are unique and can't be replaced - they
    > are invariably wrong.


    Sure you can be instantly replaced. By someone who is equally
    knowledgeable and talented.

    > FredK has done many things and knows many things and likes to think he is
    > irreplaceable - but he knows deep down that it isn't true. A 20-something
    > who doesn't know any better can pick up and take over his code.


    That's just a big steaming pile of poo.

    A *good* 30yo developer could pick it up with 6-12 months of
    mentoring (and I'm taking about the deep internals, not cloning and
    modifying SCSI drivers).

    A *good* humble 25yo developer who realizes he doesn't know every-
    thing and that what he was taught in school was usually wrong, could
    also pick it up with 6-12 months of mentoring.

    But how many of those are there?

    > Sure.
    > FredK has a lot of historical knowledge - but in fact sometimes a clean
    > slate can be very useful.


    But not with the ton of legacy that is VMS.

    Rdb seems to be suffering a similar fate, and bugs are slipping in
    at a rate that I don't remember happening before.

    > VMS is less vulnerable from loss of engineers, than from people who spend
    > their time spreading FUD about Integrity just because they are POed about
    > Alpha.


    --
    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!

  13. 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. :-)



    It would have been better to have ported Tru64 and not PH-UX.



    --
    OpenVMS - The never-advertised operating system with the dwindling ISV
    base.



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

    FredK wrote:
    > "Tom Linden" wrote in message
    > newsp.tw2c4utdhv4qyg@murphus.linden...
    >> On Tue, 14 Aug 2007 10:33:17 -0700, FredK
    >> wrote:
    >>
    >>> Golly. OK. So should it be POWER? Or SPARC? That HP-UX ports to?

    >>
    >> I was only thinking about the technical aspect, having myself ported
    >> similar styled Unix (BSD4.x) a couple of times before.
    >>
    >> But you are quite right they really don't have any options. It would
    >> appear HP really did bet the farm on IA64. X86 doesn't have support
    >> beyond the
    >> byte swap instructions?
    >>

    >
    > Yup. That is my point. Without reviving Alpha or PA RISC and going
    > back into the FAB business to stay competetive - HP-UX needs to use
    > Itanium *or* one of HPs competetors chips. SPARC which is well on
    > its way to the grave. 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.
    >
    > For various degrees of difficulty and performance - VMS "could" run
    > on any of the 64-bit chips out there... at a considerable expense and
    > time cost.



    You no doubt have seen the Sun announcement this past week of a Solaris port
    for Power.

    That makes Solaris run now on Sparc, Power, x86



    --
    OpenVMS - The never-advertised operating system with the dwindling ISV
    base.



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

    In article , "Main, Kerry" writes:
    >
    > Nobody twiddles OpenVMS kernel code except VMS Engineering and the same goe=
    > s for
    > HP-UX, AIX, Solaris etc.


    Then what do you call it when I add routines to the kernel or patch
    existing kernel code on my VMS systems?


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


    > -----Original Message-----
    > From: Bob Koehler [mailto:koehler@eisner.nospam.encompasserve.org]
    > Sent: August 20, 2007 8:32 AM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: RE: Intel marginalizing Itanium even faster than expected?
    >
    > In article
    > > t>, "Main, Kerry" writes:
    > >
    > > Nobody twiddles OpenVMS kernel code except VMS Engineering and the

    > same goe=
    > > s for
    > > HP-UX, AIX, Solaris etc.

    >
    > Then what do you call it when I add routines to the kernel or patch
    > existing kernel code on my VMS systems?


    An unsupported system?

    Just to clarify - I was referring to OS kernel code (Scheduler, cluster etc),
    not user or App code that calls or executes in kernel mode.

    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.




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

    In article , "Main, Kerry" writes:
    >
    > An unsupported system?


    Nope, I had to support it, DEC didn't have to.

    >
    > Just to clarify - I was referring to OS kernel code (Scheduler, cluster etc=
    > ),
    > not user or App code that calls or executes in kernel mode.


    And I haven't had to patch kernel code since VMS 4.x, but I did
    have to write a substitute routine for my driver to call when
    I found a bug in 6.x.


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

    John Smith wrote:
    >
    > FredK wrote:
    > > "Tom Linden" wrote in message
    > > newsp.tw2c4utdhv4qyg@murphus.linden...
    > >> On Tue, 14 Aug 2007 10:33:17 -0700, FredK
    > >> wrote:
    > >>
    > >>> Golly. OK. So should it be POWER? Or SPARC? That HP-UX ports to?
    > >>
    > >> I was only thinking about the technical aspect, having myself ported
    > >> similar styled Unix (BSD4.x) a couple of times before.
    > >>
    > >> But you are quite right they really don't have any options. It would
    > >> appear HP really did bet the farm on IA64. X86 doesn't have support
    > >> beyond the
    > >> byte swap instructions?
    > >>

    > >
    > > Yup. That is my point. Without reviving Alpha or PA RISC and going
    > > back into the FAB business to stay competetive - HP-UX needs to use
    > > Itanium *or* one of HPs competetors chips. SPARC which is well on
    > > its way to the grave. 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.
    > >
    > > For various degrees of difficulty and performance - VMS "could" run
    > > on any of the 64-bit chips out there... at a considerable expense and
    > > time cost.

    >
    > You no doubt have seen the Sun announcement this past week of a Solaris port
    > for Power.
    >
    > That makes Solaris run now on Sparc, Power, x86


    ....while VMS languishes on the foundering Itanic...

    "There are none so blind as those who will not see." (not sure of the source)

    --
    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/

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

    Bob Koehler wrote:
    >
    > In article , "Main, Kerry" writes:
    > >
    > > An unsupported system?

    >
    > Nope, I had to support it, DEC didn't have to.
    >
    > >
    > > Just to clarify - I was referring to OS kernel code (Scheduler, cluster etc=
    > > ),
    > > not user or App code that calls or executes in kernel mode.

    >
    > And I haven't had to patch kernel code since VMS 4.x, but I did
    > have to write a substitute routine for my driver to call when
    > I found a bug in 6.x.


    Did you have the source and the build environment to build a new (unsupported)
    VMS kernel, or did you just include kernel-mode code in a routine that could be
    LINKed to your driver code, bypassing the kernel code you were replacing?

    --
    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/

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

    On 08/20/07 13:17, David J Dachtera wrote:
    [snip]
    >
    > "There are none so blind as those who will not see." (not sure of the source)


    John Heywood, 1546, then Jonathan Swift, paraphrasing Jeremiah 5:21.

    Hear now this, O foolish people, and without understanding;
    which have eyes, and see not; which have ears, and hear not.

    Google is a wonderful thing.

    --
    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!

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