1 INFO-VAX	Wed, 22 Dec 2004	Volume 2004 : Issue 708       Contents:  Re: An advertising lesson for HP  Re: An advertising lesson for HP9 Re: Can 80 pin UltraSCSI drives be used on Alpha systems? 9 Re: Can 80 pin UltraSCSI drives be used on Alpha systems? ) Re: HP pulls out of IA64 chip development ) Re: HP pulls out of IA64 chip development ) Re: HP pulls out of IA64 chip development ) Re: HP pulls out of IA64 chip development ) Re: HP pulls out of IA64 chip development ) Re: HP pulls out of IA64 chip development ) Re: HP pulls out of IA64 chip development ) Re: HP pulls out of IA64 chip development ) Re: HP pulls out of IA64 chip development ) Re: HP pulls out of IA64 chip development 6 Re: Java Runtime Exec. Limit on Parameter String size?F MntVerifyTimeout, (remote shadow member), clustering, volume shadowing' Re: Needed graphical Driver information   Re: New Features in OpenVMS V8.2* Re: Older StorageWorks Parts Not Available* Re: Older StorageWorks Parts Not Available* Re: Older StorageWorks Parts Not Available+ Re: OT: Display technology at euro stadiums & pscp, psftp problem with MULTINET V5.0 Re: SAN-based cluster traffic? SMTP problem with MULTINET v5.0 1 SSH Keys: MULTINET SSH Client to TCPIP SSH Server $ Support on the AppMind OpenVMS Agent Re: tick, tick, tick Re: tick, tick, tick Re: tick, tick, tick Re: Time to revive Emerald?  Re: VESA/VGA BIOS emulation   Re: Yet another Inquirer article  Re: Yet another Inquirer article. You will find your answer on the Appmind forum@ Re: [Nomex on]: Security research suggests Linux has fewer flaws  F ----------------------------------------------------------------------   Date: 21 Dec 2004 20:48:05 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)) Subject: Re: An advertising lesson for HP , Message-ID: <32rgg5F3p3nr7U2@individual.net>  , In article <7sadnTbPHOefRSPcRVn-2w@igs.net>,& 	"John Smith" <a@nonymous.com> writes:H > It's long overdue that HP 'polish' VMS in Corporate America's eyes.... >  > > > http://www.nytimes.com/2004/12/14/business/media/14adco.html >  > December 14, 2004 
 > ADVERTISING . > Kiwi Shoe Polish Aims to Escape Invisibility   F The big difference is that Kiwi is being pro-active.  They can alreadyG see a major loss of business coming with the changing of the times (the E oldest bastion of "spit and polish", the US Army is moving from those G well recognized black boots to brown, suedish, non-polished boots. This A has to be a major loss of business for them in the near future.)  D HP will wait till there is no market left and then wonder why things look so bleak.   bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  % Date: Tue, 21 Dec 2004 20:53:39 -0500 # From: "John Smith" <a@nonymous.com> ) Subject: Re: An advertising lesson for HP , Message-ID: <zO6dnTsK59nXSVXcRVn-uw@igs.net>   Bill Gunshannon wrote:. > In article <7sadnTbPHOefRSPcRVn-2w@igs.net>,' > "John Smith" <a@nonymous.com> writes: @ >> It's long overdue that HP 'polish' VMS in Corporate America's >> eyes....  >> >>? >> http://www.nytimes.com/2004/12/14/business/media/14adco.html  >> >> December 14, 2004 >> ADVERTISING/ >> Kiwi Shoe Polish Aims to Escape Invisibility  > H > The big difference is that Kiwi is being pro-active.  They can alreadyD > see a major loss of business coming with the changing of the timesF > (the oldest bastion of "spit and polish", the US Army is moving fromC > those well recognized black boots to brown, suedish, non-polished E > boots. This has to be a major loss of business for them in the near 
 > future.)F > HP will wait till there is no market left and then wonder why things > look so bleak.    & I don't think that HP is that curious.   ------------------------------  # Date: Tue, 21 Dec 2004 18:57:01 GMT # From: hoff@hp.nospam (Hoff Hoffman) B Subject: Re: Can 80 pin UltraSCSI drives be used on Alpha systems?2 Message-ID: <1m_xd.4847$lk2.2270@news.cpqcorp.net>  _ In article <1103652863.679071.201470@f14g2000cwb.googlegroups.com>, tadamsmar@yahoo.com writes: D :We need to upgrade some disks in our old Alphas and my hardware guyD :tells me that the 80 UltraSCSI drives are a lot cheaper than 50 pin :drives. : C :Is it possible to use an adapter to allow us to use 80 pin drives.   :If so, what adapters will work?  C   You can often mix newer and older SCSI drives in a configuration, B   but not always.  Older SCSI devices that are not "wide-friendly"E   can and will cause, um, "configurational grief", for instance.  :-)   D   Without more details, it is not possible to say if this particularC   configuration will work -- the host SCSI controller, the cabling, D   and other SCSI devices present on the bus are key here, of course.  D   Which old Alpha system(s), and which SCSI controller(s), and which-   OpenVMS Alpha version(s) are involved here?   A   Various StorageWorks enclosures can mix and match devices, too.   A   Another aspect is thermal -- some of the older systems may not  C   provide sufficient cooling for various newer devices.  (I've been A   shouted down on this comment in the past, but I've also toasted D   some disks with this problem.  Make certain whatever enclosure you@   install the newer disks into has sufficient cooling for device@   requirements.  There are SCSI disks of certain vintages and of3   certain designs that run very hot, for instance.)   N  ---------------------------- #include <rtfaq.h> -----------------------------K     For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq N  --------------------------- pure personal opinion ---------------------------E         Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[at]hp.com    ------------------------------  % Date: Tue, 21 Dec 2004 10:53:22 -0800 * From: "Jack Peacock" <peacock@simconv.com>B Subject: Re: Can 80 pin UltraSCSI drives be used on Alpha systems?2 Message-ID: <IsGdncnHwafQ7VXcRVn-sw@mpowercom.net>  ' <tadamsmar@yahoo.com> wrote in message  = news:1103652863.679071.201470@f14g2000cwb.googlegroups.com... E > We need to upgrade some disks in our old Alphas and my hardware guy E > tells me that the 80 UltraSCSI drives are a lot cheaper than 50 pin 	 > drives.  > L Bear in mind those cheap SCA 80pin drives on Ebay are likely surplused from L RAID arrays after they've exceeded their MTBF.  Chances are they have a lot L of life left, I buy them from time to time for testbeds, but I wouldn't use - them in a high reliability production system.   M On the 50 to 80 adapters the problem area is how well the adapter locks onto  < the SCA connector.  Some are very loose and come off easily.   Jack Peacock     ------------------------------  % Date: Tue, 21 Dec 2004 13:49:41 -0500 ( From: "Hein" <hein.nomail@hp.nomail.com>2 Subject: Re: HP pulls out of IA64 chip development, Message-ID: <41c87366$1@usenet01.boi.hp.com>  4 "Neil Rieck" <n.rieck@sympatico.ca> wrote in message4 news:YBYxd.13379$GK5.889359@news20.bellglobal.com... : H > But I do have one additional question to ask. You stated that you saidL > "hello to him in the cafeteria". Your email account is at hp.com while hisG > is at intel.com. Are Intel people and HP people working side-by-side?   > Eating side by side mostly, and working side by side at times.  J When Intel picked up Alpyha, they also picked up a bunch of great compiler engineers in Nashua NH. H Those were moved/concentrated into a special area in the 'ZK2' building.K A large "Intell Inside" sticker was slapped onto a new wall to sperate them  some. L By and large they still park in the same spots, and share the same cafeteriaH sitting down pretty much on the same lunchroom table they were using 10+
 years ago.B Plus ca change... plus ca reste la meme chose  (pardon my french).   Cheers,      HeinL     (who just walked away from a lunch table with John, and Forrest and Mark
 H and... )   ------------------------------    Date: 21 Dec 2004 13:56:34 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) 2 Subject: Re: HP pulls out of IA64 chip development3 Message-ID: <NGq+6hFmYXdn@eisner.encompasserve.org>   Z In article <xMZxd.4843$Yc2.952@news.cpqcorp.net>, John Reagan <john.reagan@hp.com> writes: > Neil Rieck wrote:  >  >>  J >> But I do have one additional question to ask. You stated that you said N >> "hello to him in the cafeteria". Your email account is at hp.com while his M >> is at intel.com. Are Intel people and HP people working side-by-side? (or   >> was he just visiting?). >>   > I > The Intel folks reside in a dedicated, secured area in ZKO2.  We share  K > common areas like the cafeteria.  I tend to see Steve there several days  	 > a week.   L So you deny all those vicious rumors that Intel forbids them to have lunch ?  ( There goes my story for the Inquirer :-)   ------------------------------  + Date: Tue, 21 Dec 2004 20:16:38 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)2 Subject: Re: HP pulls out of IA64 chip development$ Message-ID: <cqa0b5$f93$2@online.de>  3 In article <NGq+6hFmYXdn@eisner.encompasserve.org>, 0 Kilgallen@SpamCop.net (Larry Kilgallen) writes:   L > >> But I do have one additional question to ask. You stated that you said P > >> "hello to him in the cafeteria". Your email account is at hp.com while his O > >> is at intel.com. Are Intel people and HP people working side-by-side? (or   > >> was he just visiting?). > > K > > The Intel folks reside in a dedicated, secured area in ZKO2.  We share  M > > common areas like the cafeteria.  I tend to see Steve there several days   > > a week.   , That would be in SYS$COMMON, I suppose.  :-)  N > So you deny all those vicious rumors that Intel forbids them to have lunch ? > * > There goes my story for the Inquirer :-)  7 Is the non-paged pool still visible through the window?    ------------------------------  % Date: Tue, 21 Dec 2004 17:36:07 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 2 Subject: Re: HP pulls out of IA64 chip development, Message-ID: <41C8A555.CFD0A934@teksavvy.com>   John Reagan wrote:H > The Intel folks reside in a dedicated, secured area in ZKO2.  We share# > common areas like the cafeteria.    I What's the point of putting the Intel people in a secured and undisclosed F location if they can still share all their secrets with employees of a) different corporation during lunch time ?  :-) :-) :-)    ------------------------------    Date: 21 Dec 2004 17:15:26 -06004 From: kaplow_r@encompasserve.org.TRABoD (Bob Kaplow)2 Subject: Re: HP pulls out of IA64 chip development3 Message-ID: <UKl3EiTfArk4@eisner.encompasserve.org>   Z In article <4QFxd.4792$Px1.544@news.cpqcorp.net>, John Reagan <john.reagan@hp.com> writes: > Bob Kaplow wrote:  >  >>  G >> The real crown jewel that Intel got from DEC/Compaq in the alphacide M >> announcement was the compiler technology and people. Without that compiler I >> technology EPIC would be as useful as a first generation Pentium doing  >> double precision FP divides.  > K > Uh, what compiler technology?  Sure, I believe that Intel got permission  C > to look at or use existing GEM technology, but to the best of my  I > knowledge they didn't take and use any of it (I'm guessing they didn't  F > want any BLISS code inside their compiler system).  Now some of the K > ex-GEM developers may have "reimplemented" algorithms or interfaces from  I > GEM inside the Intel compiler system, I don't know that.  The existing  B > Intel code generate generates reasonable code and in many cases 5 > generates better code that what GEM currently does.   E In addition to the EV8 team, didn't Intel get the compiler people and < intellectual property? Who does Steve Lionel work for today?  1 	Bob Kaplow	NAR # 18L	TRA # "Impeach the TRA BoD" & 		>>> To reply, remove the TRABoD! <<<K Kaplow Klips & Baffle:	http://nira-rocketry.org/LeadingEdge/Phantom4000.pdf L     www.encompasserve.org/~kaplow_r/    www.nira-rocketry.org    www.nar.org  K         This is a country which stands tallest in troubled times, a country K         that clings to fundamental principles, cherishes its constitutional I         heritage, and rejects simple solutions that compromise the values H         that lie at the roots of our democratic system. -- Supreme Court(         Justice Thurgood Marshall, 1972    ------------------------------   Date: 21 Dec 2004 23:59:52 GMT! From: Lee Witten <lw99@yahoo.com> 2 Subject: Re: HP pulls out of IA64 chip development/ Message-ID: <Xns95C7C15DCA516nn48@199.125.85.9>   0 Kilgallen@SpamCop.net (Larry Kilgallen) wrote in, news:NGq+6hFmYXdn@eisner.encompasserve.org: F > So you deny all those vicious rumors that Intel forbids them to have
 > lunch ?  > * > There goes my story for the Inquirer :-)  E No, the real story should be that Intel forces them to eat in the ZK  H cafeteria!  That is the truly vicious part!  That's one nasty cafeteria!   --lw--   ------------------------------  % Date: Tue, 21 Dec 2004 15:59:30 -0800 * From: "Jack Peacock" <peacock@simconv.com>2 Subject: Re: HP pulls out of IA64 chip development2 Message-ID: <INidnWO0Q4qRJVXcRVn-pg@mpowercom.net>  ; "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message  & news:41C8A555.CFD0A934@teksavvy.com...K > What's the point of putting the Intel people in a secured and undisclosed H > location if they can still share all their secrets with employees of a+ > different corporation during lunch time ?  > L Which begs the question, who is keeping secrets from whom?  "Secured areas" G are a great way to keep people in the dark...less likely to notice the  " thinning out of occupied cubicles.   Jack Peacock     ------------------------------  % Date: Tue, 21 Dec 2004 20:52:23 -0500 # From: "John Smith" <a@nonymous.com> 2 Subject: Re: HP pulls out of IA64 chip development, Message-ID: <4fmdnedkXou7SVXcRVn-iw@igs.net>   Bob Kaplow wrote: ? > In article <4QFxd.4792$Px1.544@news.cpqcorp.net>, John Reagan  > <john.reagan@hp.com> writes: >> Bob Kaplow wrote: >> >>> H >>> The real crown jewel that Intel got from DEC/Compaq in the alphacideE >>> announcement was the compiler technology and people. Without that E >>> compiler technology EPIC would be as useful as a first generation . >>> Pentium doing double precision FP divides. >>@ >> Uh, what compiler technology?  Sure, I believe that Intel gotC >> permission to look at or use existing GEM technology, but to the ? >> best of my knowledge they didn't take and use any of it (I'm A >> guessing they didn't want any BLISS code inside their compiler G >> system).  Now some of the ex-GEM developers may have "reimplemented" F >> algorithms or interfaces from GEM inside the Intel compiler system,A >> I don't know that.  The existing Intel code generate generates D >> reasonable code and in many cases generates better code that what >> GEM currently does. > G > In addition to the EV8 team, didn't Intel get the compiler people and > > intellectual property? Who does Steve Lionel work for today?  H Answer: A company that knows which business it's in better than HP knows which business it's in.    ------------------------------    Date: 21 Dec 2004 18:39:07 -0800 From: ranjit_mathews@yahoo.com2 Subject: Re: HP pulls out of IA64 chip developmentC Message-ID: <1103683147.838978.307990@f14g2000cwb.googlegroups.com>    icerq4a@spray.se wrote:  >  No,D > they don't have to be recompiled. In simulation tests, an OOO IA64 had 6 > twice the performance of a similar in-order version.  G Can't an in-order SMT IA64 attain similar results, when running several  threads?   > Having compiler ? > scheduling and hardware scheduling is not mutually exclusive.    ------------------------------    Date: 21 Dec 2004 22:43:06 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) 2 Subject: Re: HP pulls out of IA64 chip development3 Message-ID: <7nUcX4cNuS1V@eisner.encompasserve.org>   S In article <Xns95C7C15DCA516nn48@199.125.85.9>, Lee Witten <lw99@yahoo.com> writes: 2 > Kilgallen@SpamCop.net (Larry Kilgallen) wrote in. > news:NGq+6hFmYXdn@eisner.encompasserve.org: G >> So you deny all those vicious rumors that Intel forbids them to have  >> lunch ?   >>  + >> There goes my story for the Inquirer :-)  > G > No, the real story should be that Intel forces them to eat in the ZK  J > cafeteria!  That is the truly vicious part!  That's one nasty cafeteria!  E My impression is that it is pretty good compared to other New England < industrial cafeterias.  And what a classy name - Chez Zeke !   ------------------------------    Date: 21 Dec 2004 14:28:23 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) ? Subject: Re: Java Runtime Exec. Limit on Parameter String size? 3 Message-ID: <soNh0j1teAMA@eisner.encompasserve.org>   r In article <5VZxd.44341$Z14.20835@news.indigo.ie>, "Andoni" <no_spam_please@andoni-at-ireland-dot-com.com> writes:  ! > Child creation error: error 412   
    $ exit 412 7    %SYSTEM-F-MBTOOSML, mailbox is too small for request   D    Look through the Java notes for VMS and see if there is a logicalC    name that allows you to control the size of the mailbox, I don't     think there is.  F    If not, try looking at your process BYTLM quota and messing around I    with SYSGEN DEFMBXBUFQUO and DEFMBXMXMSG.  Beware the latter may have  J    affects on other processes.  Since DEFMBXMXMSG defaults to 256, that's F    the most likely culprit.  Since it's dynamic you can raise it for aB    trial and put it right back until you work out the consquences.       F    Also, DCL has some built in limits that are getting larger in laterB    versions of VMS.  I don't think this is the problem because theE    number is so small.  IIRC they get huge next month when 8.2 ships.    ------------------------------  + Date: Tue, 21 Dec 2004 20:14:30 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)O Subject: MntVerifyTimeout, (remote shadow member), clustering, volume shadowing $ Message-ID: <cqa076$f93$1@online.de>  F I've got a bizarre problem.  Perhaps someone can point me in the right direction.    ) Please don't reply via email (see below).   F I have a three-node cluster.  Node ELIJAH crashed (and for some reasonG didn't reboot, even though the console parameters should be set so that A it reboots automatically).  Nodes GLADIA and DANEEL remained up.  F DISK$USER is a shadow set consisting of two SEAGATE SCSI-2 disks, one D member with a direct connection to ELIJAH and another with a direct F connection to DANEEL.  This shadow set is mounted on all nodes during I startup.  All disks are MSCP served to all nodes.  Cluster communication  > is over a 10 Mb/s LAN.  This shadow set has been in operation 5 continuously for almost three years with no problems.   C I would have expected that the crash of ELIJAH would simply leave a H one-member DISK$USER shadow set.  (This is what has happened when nodes H have crashed in the past.)  However, the situation is now the following:G DISK$USER is mounted and working on GLADIA (note that no member of this G shadow set has a direct connection to GLADIA) while on DANEEL it shows  0 up in MntVerifyTimeout with an error count of 3.  F GLADIA is an ALPHA at 7.3-1, DANEEL and ELIJAH are VAXes at 7.3.  All  patches applied.  F The cluster is 500 km away.  I am connected to it via TELNET over DSL G connections at both ends.  I use the TCPIP cluster alias and point all  F incoming traffic at that address.  Thus, the TELNET connection always D connects to the node with the cluster alias.  I can then use LAT or I TELNET (no DECnet installed) to connect to other nodes once I am in.  (I  G have experimented with port forwarding, letting, say, port 50123 point  I to an address other than the cluster alias, allowing a direct connection  I to a node other than that with the cluster alias.  However, probably due  F to a problem with the router software, this has proved unreliable and 9 since I don't need the feature, I haven't been using it.)   H I noticed something was wrong when my connection hung: I was in MAIL andG it didn't react, though CONTROL-T was OK.  Also, new TELNET connections H hung between accepting the username and prompting for the password.  TheF reason is that SYSUAF and friends are on DISK$USER, which on DANEEL isG now in MntVerifyTimeout.  However, I could connect with LAT from DANEEL G to GLADIA since there SYSUAF is accessible.  I have an internal-access  F only account with SETPRV, so I am hoping that I can solve the problem  from that account.  F What I want to do is get DISK$USER mounted on DANEEL again.  I issued 7 the MOUNT command which normally occurs during startup:   ' $    MOUNT/CLUSTER/NOASSIST/NOREBUILD - 3       DSA510:/SHADOW=($22$DKA500:,$44$DKA400:) USER   F This takes a while, complains that $44$DKA400: is not software enabledG (it is the member connected to ELIJAH) then completes without errors or G warnings, but with an informational message saying that $22$DKA500: has E been added to the shadow set.  That is, just what I expect.  However, G after this command the shadow set is still mounted only on GLADIA (even ? though I used the /CLUSTER qualifier) and on DANEEL is still in  MntVerifyTimeout.   D Is there any way I can get DISK$USER mounted on DANEEL?  Note that IA cannot issue any commands from a priviledged account there; since E SYSUAF.DAT is on DISK$USER, I can't log in (the account in which I am H logged in from 500 km away is non-priviledged) and SYSMAN isn't working:   SYSMAN> SET ENVIRONMENT/CLUSTER + %SYSMAN-I-ENV, current command environment: $         Clusterwide on local cluster<         Username XXXXX        will be used on nonlocal nodes  " SYSMAN> SET PROFILE/PRIVILEGES=ALL1 %SYSMAN-I-NODERR, error returned from node DANEEL " -RMS-E-ACC, ACP file access failed1 %SYSMAN-I-NODERR, error returned from node DANEEL = -SMI-E-PROTOCOL, remote protocol error - data packet w/o INIT  SYSMAN> do show time2 %SYSMAN-I-OUTPUT, command execution on node DANEEL1 %SYSMAN-I-NODERR, error returned from node DANEEL = -SMI-E-PROTOCOL, remote protocol error - data packet w/o INIT 2 %SYSMAN-I-OUTPUT, command execution on node GLADIA   21-DEC-2004 21:03:57  E I would expect that a reboot of DANEEL would solve the problem (since H ELIJAH needs to be rebooted as well, I might as well do a cluster rebootD while I'm at it).  However, first I would like to know whether I canD solve the problem without a reboot (assuming that there are no other@ problems than the ones I have mentioned above) and also how thisF situation could possibly arise (as mentioned above, I would expect theC loss of ELIJAH to result in a one-member shadow set, but mounted on ; GLADIA and DANEEL; in other words, what is the cause of the  MntVerifyTimeout on DANEEL).    E Since DANEEL has the TCPIP cluster alias, I cannot receive email, so   please reply to the newsgroup!  F A related problem: Is there any way, in the current situation, that I I can move the TCPIP cluster alias from DANEEL to GLADIA?  Note again that  H I cannot issue any commands from a priviledged account on DANEEL.  (The G brute-force method, I suppose, would be to kill all relevant processes  D and hope that GLADIA would then pick up the cluster alias, but that  doesn't sound very elegant.)   ------------------------------    Date: 21 Dec 2004 14:13:47 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) 0 Subject: Re: Needed graphical Driver information3 Message-ID: <CvKOuPXkSlSg@eisner.encompasserve.org>   _ In article <USYxd.4837$4f2.3174@news.cpqcorp.net>, "FredK" <fred.nospam@nospam.dec.com> writes: E > I don't remember their ever being a "GAADRIVER".  GADRIVER was if I M > remember, the GPX driver for VAX.  I think there was also a GABDRIVER (from N > some distant memory) from the Open3D Alpha software, but perhaps there was a" > GAA, my memory is getting stale.   On my VAX (VMS 6.2):   $ dir sys$loadable_images:ga*    Directory SYS$COMMON:[SYS$LDR]  # GAADRIVER.EXE;1     GABDRIVER.EXE;1    Total of 2 files.    ------------------------------  % Date: Tue, 21 Dec 2004 14:48:52 -0500 # From: "John Smith" <a@nonymous.com> ) Subject: Re: New Features in OpenVMS V8.2 , Message-ID: <od-dnSXG6O-941XcRVn-qg@igs.net>   Michael Unger wrote: > @ > AFAIK, DVD will be the *only* distribution medium for *Itanic*
 > systems;G > CD will be the medium for Alpha (and VAX) for the foreseeable future.     J HP should consider providing a Java implementation of a Bit Torrent client, ( http://bittorrent.com/introduction.html ).  I Since you still need a PAK for LMF (or whatever), this is at least a fast K solution to getting the binaries out to the 411,000 systems allegedly still 
 in the field.    ------------------------------    Date: 21 Dec 2004 17:07:00 -06004 From: kaplow_r@encompasserve.org.TRABoD (Bob Kaplow)3 Subject: Re: Older StorageWorks Parts Not Available 3 Message-ID: <5ddtA1cotDLv@eisner.encompasserve.org>   c In article <g+qED$RV1d$J@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes: c > In article <MMz5kOC+PLES@eisner.encompasserve.org>, young_r@encompasserve.org (Rob Young) writes: c >> In article <41C615E8.FDEC0030@comcast.net>, David J Dachtera <djesys.nospam@comcast.net> writes:  > G >>> Specifically, our local folks have been unable to produce a working ? >>> replacement for a DS-RZ1ED-VW. We've had three DOAs so far.  > ? >> 	Hard drives have a service lifetime of 5 years, that is how   >> 	long they are warranted for. > K > But if that is the _service_ life, the clock has not even started ticking 0 > on the three replacement drives that were DOA.  L In all likelyhood the replacements were used tradeins from someone upgrading to more current technology.   1 	Bob Kaplow	NAR # 18L	TRA # "Impeach the TRA BoD" & 		>>> To reply, remove the TRABoD! <<<K Kaplow Klips & Baffle:	http://nira-rocketry.org/LeadingEdge/Phantom4000.pdf L     www.encompasserve.org/~kaplow_r/    www.nira-rocketry.org    www.nar.org  K         This is a country which stands tallest in troubled times, a country K         that clings to fundamental principles, cherishes its constitutional I         heritage, and rejects simple solutions that compromise the values H         that lie at the roots of our democratic system. -- Supreme Court(         Justice Thurgood Marshall, 1972    ------------------------------  % Date: Tue, 21 Dec 2004 20:56:27 -0600 2 From: David J Dachtera <djesys.nospam@comcast.net>3 Subject: Re: Older StorageWorks Parts Not Available + Message-ID: <41C8E25B.FCC1E6D2@comcast.net>    Rob Young wrote: > [snip]E >         Hard drives have a service lifetime of 5 years, that is how & >         long they are warranted for.  G Well, then we still have a problem. One of our systems has an RA8000 in - it - it was purchased *NEW* TWO(2) years ago!    So, that one's out the window.  H ...and no, there is no budget to update the hardware. (Welcome (back) to the real world, Neo!)    --   David J Dachtera dba DJE Systems  http://www.djesys.com/  ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/    ------------------------------    Date: 22 Dec 2004 00:26:44 -0600+ From: young_r@encompasserve.org (Rob Young) 3 Subject: Re: Older StorageWorks Parts Not Available 3 Message-ID: <QFnmwce2h$W8@eisner.encompasserve.org>   ` In article <41C8E25B.FCC1E6D2@comcast.net>, David J Dachtera <djesys.nospam@comcast.net> writes: > Rob Young wrote:	 >> [snip] F >>         Hard drives have a service lifetime of 5 years, that is how' >>         long they are warranted for.  > I > Well, then we still have a problem. One of our systems has an RA8000 in / > it - it was purchased *NEW* TWO(2) years ago! 7 > ...and no, there is no budget to update the hardware.   G 	Your 18 gig drives should still have quite a bit of life left in them  C 	if they are only 2 years old.  But you may be seeing after market  @ 	drives much longer in the tooth.  After all, the DS-RZ1ED-VW is- 	up to 6.5+ in years old.  Who knows when the B 	last date of manufacture was.  Maybe your best bet is to buy them 	with warranty:   * http://www.ipdstorage.com/detail.aspx?ID=6  C 	If you aren't already.  Pay a little more but maybe it is worth it , 	perhaps avoiding a debate on return if DOA.   				Rob    ------------------------------   Date: 21 Dec 2004 21:09:29 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)4 Subject: Re: OT: Display technology at euro stadiums, Message-ID: <32rho8F3p3nr7U4@individual.net>  , In article <41BFF7F0.B7EC5B83@teksavvy.com>,0 	JF Mezei <jfmezei.spamnot@teksavvy.com> writes: > O > I find it interesting that they can scale the displays to such an extent that O > they can horizontally scroll contents across the whole length of the display.   C That's no trick.  Somewhere around here I still have a cute program B that had a plane towing a message banner that could be made to flyI around the room smoothly passing from one workstation display to another.    bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  # Date: Tue, 21 Dec 2004 23:00:55 GMT / From: "Hans Jivesten" <hans.jivesten@telia.com> / Subject: pscp, psftp problem with MULTINET V5.0 5 Message-ID: <HW1yd.124991$dP1.448799@newsc.telia.net>    Hi,   I As I had problems running pscp and psftp from my PC to get files from my  F Hobbyist OpneVMS running TCIP Services 5.4 I changed to Multinet v5.0.  @ This was even worse. Now I can't even do pscp -ls to list files.  G I get no errors or warnings when running pscp or psftp they just don't   transfer anything.   PuTTY works fine though.   Any thoughts, anyone?   
 best regards,  Hans Jivesten    ------------------------------  % Date: Tue, 21 Dec 2004 17:39:35 -0500 - From: "John E. Malmberg" <wb8tyw@qsl.network> ' Subject: Re: SAN-based cluster traffic? 1 Message-ID: <YNGdnXK70s-1O1XcRVn-ig@adelphia.com>    Jilly wrote:   > Ed Wilts wrote:  > F >>I recall reading a while ago in a roadmap far, far away that VMS wasG >>going to support SCS traffic over SAN connections.  Has this happened C >>yet?  My systems are currently in 2 data centers joined via FDDI, F >>Gigaswitches & ATM, but my SAN has multiple 1Gbps ISLs.  I'd like toG >>eliminate the FDDI cards and have my cluster traffic go over the SAN. I >>I know it can go over the existing Ethernet connections, but I trust my B >>ISLs more than I trust my netowork group with their clouds.  I'm7 >>currently at 7.3-2 (AXP only).  Keith, you out there? 	 >>Thanks,   ? > AFAIK it will not happen due to developments in Fibre routers B > (Brocade multi-protocol or 2122-2 router) that make it much less8 > expensive both  in cpu overhead and development costs.  H To be a bit more precise, the Fiber SAN protocols have too much latency F for efficient use for encapsulating a network or specifically in this 7 case the SCS transport.  This showed up during testing.   I This makes it more practical to route SAN traffic over Gigabit or TCP/IP  G connections than to try and route the LAN traffic through the SAN.  It  I is also the direction that the network hardware vendors seem to be going.    -John  wb8tyw@qsl.network Personal Opinion Only    ------------------------------  # Date: Tue, 21 Dec 2004 23:08:04 GMT / From: "Hans Jivesten" <hans.jivesten@telia.com> ( Subject: SMTP problem with MULTINET v5.05 Message-ID: <o12yd.124993$dP1.448786@newsc.telia.net>   K I just installed Multinet 5.0 and I can't seem to get my SMTP config right.   J All outgoing SMTP must go through a server, smtprelay1.telia.com, that my 	 ISP runs.   M I've tried to set it up but it just doesn't work and, honestly, I'm not sure   I'm doing it right.    Here's some data:  $ MULTINET CONFIG/MAIL4 Process Software Mail Configuration Utility V5.0(28)L [Reading in configuration from MULTINET_ROOT:[MULTINET]START_SMTP_LOCAL.COM] [Reading in configuration from  . MULTINET_COMMON_ROOT:[MULTINET]START_SMTP.COM] MAIL-CONFIG>SHOWI SMTP host name:                              none (will use IP host name) 1 Host name alias file:                        none G Postmaster userid:                           none (will use POSTMASTER) 1 Forwarder:                                   nones1 DECnet mail domain:                          nonea- Failed local mail will be returned to sender.e7 Retry Interval:                              30 minutess5 Return Interval:                             96 hours 5 VMS Mail REPLY control:                      REPLY-TOt2 VMS Mail header control:                     MAJOR1 Use RFC822 To: header as VMS Mail To:        TRUEe1 Lowercase username on outgoing VMS Mail:     TRUEn2 Disallow user Reply-To's:                    FALSE2 Delivery Receipts enabled:                   FALSE2 PSImail delivery disabled:                   FALSE1 Include Resent Headers on VMS MAIL forwards: TRUEtC Alias file name:                             MULTINET:SMTP_ALIASES. / SEND broadcast class:                        16l1 Start queue manager:                         TRUE8   SMTP gateways:!  Pattern                  Gatewayl!  -------                  -------e.  .se                      smtprelay1.telia.com  = "Local" domains that bypass forwarder and gateway processing:i     jikonhome.se   Number of SMTP server queues:M  Node name          Count.  ---------          -----C     ALPHA1            1   (default)            1O   No queue groupings.  Start RFC 2789 MIB agent: FALSE  MAIL-CONFIG>  3 $ MAIL/SUBJECT="TEST" WELCOME.TXT SMTP%"XXX@YYY.SE" 2 %MAIL-E-ERRACTRNS, error activating transport SMTP( %LIB-E-ACTIMAGE, error activating image ( ALPHA1$DKA0:[SYS0.SYSCOMMON.][SYSLIB]SMT P_MAILSHR.EXE; -RMS-E-FNF, file not found $w   $ SHO QUE/FULL" Generic server queue MULTINET_SMTPF   /GENERIC=(SMTP_ALPHA1) /OWNER=[SYSTEM] /PROTECTION=(S:M,O:D,G:R,W:S)  A Server queue SMTP_ALPHA1, idle, on ALPHA1::, mounted form DEFAULTf?   /BASE_PRIORITY=4 /DEFAULT=(FEED,FORM=DEFAULT) /OWNER=[SYSTEM]eA   /PROCESSOR=MULTINET_SMTP_SYMBIONT /PROTECTION=(S:M,O:D,G:R,W:S)w  ( Batch queue SYS$BATCH, idle, on ALPHA1::0   /BASE_PRIORITY=4 /JOB_LIMIT=3 /OWNER=[SYSTEM]  /PROTECTION=(S:M,O:D,G:R,W:S)/ $i  $ $ MULTINET PING SMTPRELAY1.TELIA.COM6 PING SMTPRELAY1.TELIA.COM (81.228.8.92): 56 data bytes0 64 bytes from 81.228.8.92: icmp_seq=0 time=17 ms0 64 bytes from 81.228.8.92: icmp_seq=1 time=17 ms  Cancels      , ----SMTPRELAY1.TELIA.COM PING Statistics----9 2 packets transmitted, 2 packets received, 0% packet losso' round-trip (ms)  min/avg/max = 17/17/17o $    Any ideas, anyone?  
 best regards,T Hans Jivesten    ------------------------------    Date: 21 Dec 2004 11:01:58 -0800( From: TFTAJLLYMXZP@spammotel.com (Alder): Subject: SSH Keys: MULTINET SSH Client to TCPIP SSH Server= Message-ID: <a6840bf2.0412211101.10bb7f33@posting.google.com>   F Has anyone here had occasion to configure a Multinet 4.4 SSH client toF use public key authentication when connecting to an HP TCPIP (5.4) SSH Server?e  E I created my public/private DSA key pair on the Multinet host, copied3? the public key to my [.SSH2] directory on the TCPIP server, and B referenced the new key in the TCPIP server's AUTHENTICATION file. F From what I understand of the TCPIP SSH docs, the format of the publicA key file is a single (long) line, beginning with the key type andd  followed by the key value, e.g.:  /    ssh-dss AAAAB3NzaC1kc...sf5C4quB5GaOVn+zogU=y  C So after I copied my public key to the TCPIP host, I edited it with0A EVE to get it into the format shown above.  Was this my mistake?  7 Shuold I have used another method to make these two SSHv implementations compatible?   C On the Multinet client, the same public key appears in this format:d  "    ---- BEGIN SSH2 PUBLIC KEY ----    Subject: <username>    AAAAB3NzaC1kc...e    ...    sf5C4quB5GaOVn+zogU=n     ---- END SSH2 PUBLIC KEY ----  E To make the SSH connection, I entered this command on the MU host and ! received the following responses:n  > $ SSH/USER=<host2username>/IDENT=<private key filename> <host>  E warning: <MUhostdev:[dir.SSH2]<private-key>.: 4: parsing line failed.eE warning: <MUhostdev:[dir.SSH2]<private-key>.: 5: parsing line failed.:E warning: <MUhostdev:[dir.SSH2]<private-key>.: 6: parsing line failed._E warning: <MUhostdev:[dir.SSH2]<private-key>.: 7: parsing line failed.4E warning: <MUhostdev:[dir.SSH2]<private-key>.: 8: parsing line failed.dE warning: <MUhostdev:[dir.SSH2]<private-key>.: 9: parsing line failed. F warning: <MUhostdev:[dir.SSH2]<private-key>.: 10: parsing line failed.F warning: <MUhostdev:[dir.SSH2]<private-key>.: 11: parsing line failed.F warning: <MUhostdev:[dir.SSH2]<private-key>.: 12: parsing line failed.F warning: <MUhostdev:[dir.SSH2]<private-key>.: 13: parsing line failed.F warning: <MUhostdev:[dir.SSH2]<private-key>.: 14: parsing line failed. <TCPIPhostusername>'s password:   A Any hints on how to get public key authentication working in this ! environment would be appreciated.    Thanks,l   Alderc   ------------------------------    Date: 21 Dec 2004 13:14:33 -0800+ From: youtho@thorin.biz (youtho@thorin.biz)w- Subject: Support on the AppMind OpenVMS Agentl< Message-ID: <c4ca1a5.0412211314.2805afad@posting.google.com>  B To Darren and all of you who have AppMind related questions pleaseB post all your questions in the AppMind forum that you will find on http://forum.appmind.com   Regards, Jonas Thorinu   ------------------------------    Date: 21 Dec 2004 17:09:52 -06004 From: kaplow_r@encompasserve.org.TRABoD (Bob Kaplow) Subject: Re: tick, tick, tickk3 Message-ID: <Gpu$j3$im+yQ@eisner.encompasserve.org>n  q In article <M5K2QxR8W5RZ@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:-^ > In article <1103557606.052749.165150@c13g2000cwb.googlegroups.com>, icerq4a@spray.se writes:H >> It surprises me that people writing on c.o.v. don't seem to have muchJ >> contact with the VMS people at HP. HP/VMS has for some time been saying' >> that it will be available at 15-FEB.f > G >    I have lots of contact with HP.  Up until today all I heard was Q43F >    2004.  The last time I think was when Andy Goldstein came to the : >    ESILUG just 3 weeks ago.  Previous messages were NDA.  / Heard Q4 from local HP folks just this month...m  1 	Bob Kaplow	NAR # 18L	TRA # "Impeach the TRA BoD"7& 		>>> To reply, remove the TRABoD! <<<K Kaplow Klips & Baffle:	http://nira-rocketry.org/LeadingEdge/Phantom4000.pdf L     www.encompasserve.org/~kaplow_r/    www.nira-rocketry.org    www.nar.org  K         This is a country which stands tallest in troubled times, a countrydK         that clings to fundamental principles, cherishes its constitutional I         heritage, and rejects simple solutions that compromise the valuesdH         that lie at the roots of our democratic system. -- Supreme Court(         Justice Thurgood Marshall, 1972    ------------------------------    Date: 21 Dec 2004 23:22:59 -0500/ From: brooks@cuebid.zko.dec.nospam (Rob Brooks)- Subject: Re: tick, tick, tick2- Message-ID: <ohxhZODej641@cuebid.zko.dec.com>n  6 kaplow_r@encompasserve.org.TRABoD (Bob Kaplow) writes:? > koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:N >> icerq4a@spray.se writes:.I >>> It surprises me that people writing on c.o.v. don't seem to have much K >>> contact with the VMS people at HP. HP/VMS has for some time been saying ( >>> that it will be available at 15-FEB. >> cH >>    I have lots of contact with HP.  Up until today all I heard was Q4G >>    2004.  The last time I think was when Andy Goldstein came to the i; >>    ESILUG just 3 weeks ago.  Previous messages were NDA.o > 1 > Heard Q4 from local HP folks just this month...u  B It ain't gonna be Q4, obviously; mid-February is much more likely.   -- n  M Rob Brooks    VMS Engineering -- I/O Exec Group     brooks!cuebid.zko.dec.com    ------------------------------  % Date: Wed, 22 Dec 2004 01:14:04 -0500c- From: Jf Mezei <jfmezei.spamnot@teksavvy.com>l Subject: Re: tick, tick, tick1, Message-ID: <41C9108C.2A4E08F9@teksavvy.com>   Rob Brooks wrote:d3 > > Heard Q4 from local HP folks just this month...a > D > It ain't gonna be Q4, obviously; mid-February is much more likely.  L Actually, The VMS engineers have found a way to slow down all of the world'sN clock (using the code used to control speed of the VMS system clock), and thisM will stretch significantly the amount of time between now and end of 2004. SoM there is still hope :-) :-).  N And Carly has struck a deal with Santa to distribute the new CDs to all of the* VMS sites worldwide in less than 24 hours.  J This isn't as bad as Boeing which, just this week, keeps promising it willR sell 200 of its new 7E7 planes be end of this year. It has sold only 52 so far :-)   ------------------------------  % Date: Tue, 21 Dec 2004 21:08:58 -0600e2 From: David J Dachtera <djesys.nospam@comcast.net>$ Subject: Re: Time to revive Emerald?+ Message-ID: <41C8E54A.A0924A51@comcast.net>    JF Mezei wrote:  >  > David J Dachtera wrote: I > > "x86" is typiclaly used to refer to the 80x86 family (JF usualy dropshG > > the "x", thus raising confusion between 8/16 bit CPUs and 16/32 bit4
 > > CPUs), > < > Au contraire. 8086 is a generic term for the architecture.  H As you use it, yes. That would make it a superset of "x86" including the 8/16 bit CPUs/   > IA32 refers to aO > specific iteration(s) of the 8086 during its evolution. And with the 8086 now O > scaled up to 64 bits, you can't call it IA64 because that is reserved for theY > itanium thing.  ( Sort of. There's now "x86-64", remember.   > [snip]H > > important is what is out there in the thousands and millions of rack > > spaces around the world. > M > Yes and no. Yes in the sense that people buy industry standard, and that isi8 > defined by what is out there in the milliosn of racks.  G Au contraire. Commonness does not make anything an *INDUSTRY* standard, E commonness makes *DE FACTO* (literally, "from (the) fact") standards.h  H "Industry" standards are not dictated by any vendor, as most BGisms are,F rather they are negotiated, usually internationally, and industry-wide0 to ensure maximum flexibility and applicability.  M > No because what is already installed are 32 bit 8086s and those are not thes	 > future.   A 8086 is an 8/16 bit CPU. There never was a 32-bit 8086. The firstA. 32-bits Intels were in the 80x86 product line.  9 > You want to adopt what will sell. With 64 bit on the 80O x  >86 horizon,N > there will be a fairly big cycle of server renewall the minute Linux/Windows/ > have some application that requires 64 bit 80c xs" >86. (Similar to what happened forY > windows 95 requiring 386/486 machines, and with Y2K, requiring more powerful machines).-  G Trouble is, nothing at that scale "requires" 64-bit computing, with ther' possible exception of image processing.H  9 > If the next wave will see massive upgrades to 64 bit 80k xi >86s, then this is what ; > VMS shoudl adopt and ride the wave along with the others.a  D ...as most of us (and a fair chunk of the industry and market ) have been saying for decades.   -- o David J Dachtera dba DJE Systemsa http://www.djesys.com/  ) Unofficial OpenVMS Hobbyist Support Page:i" http://www.djesys.com/vms/support/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/e   ------------------------------  % Date: Tue, 21 Dec 2004 16:31:00 -0500 2 From: Chip Coldwell <coldwell@physics.harvard.edu>$ Subject: Re: VESA/VGA BIOS emulationE Message-ID: <Pine.LNX.4.61.0412211623110.27727@localhost.localdomain>M  ! On Tue, 21 Dec 2004, FredK wrote:a  M > I'm not sure who I could direct your question to.  Most of the guys who didnN > this work have long ago moved on to other companies.  The callbacks were putK > in, in part, due to a request I made.  However, they didn't show up untildK > too late for me to use them (I had moved on to other things).  It's quitelM > likely that they have never been fully tested.  I'll poke around and see if E > I have anything still around that spells out how to use parameters.K  % Thanks a lot, I really appreciate it.e  < Like I said, I have been using the BIOS_EMUL callback to setF VESA-standard video modes, including the extended modes defined in theA VBE 3.0 document, and that does work.  I would guess that the SRMgF itself must be using the BIOS emulation in order to set a text mode soC it can use the video device for the operator console.  (Although in D principle it could set up the VGA registers without using the BIOS.)   Chip   -- h Charles M. "Chip" Coldwell System Administrator Harvard Physics Department 617-495-3388   ------------------------------    Date: 21 Dec 2004 17:12:04 -06004 From: kaplow_r@encompasserve.org.TRABoD (Bob Kaplow)) Subject: Re: Yet another Inquirer articley3 Message-ID: <cbg1kyfTibtx@eisner.encompasserve.org>a  \ In article <41C74C28.6516D6FD@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes:P > I think that it makes way too much from legal wranglings between HP and Intel.M > Once both agree that IA64 isn't viable (which I think was done some time in P > early 2004), then it is a question of plotting an exit strategy, and they willO > use the contracts to their own personal advantage, hoping the other gets more> > egg on face.  K Makes the song-and-dance that was the 2001 justification for alphacide seemr
 pretty bogus.    Liar Liar Pants on Fire!  1 	Bob Kaplow	NAR # 18L	TRA # "Impeach the TRA BoD"t& 		>>> To reply, remove the TRABoD! <<<K Kaplow Klips & Baffle:	http://nira-rocketry.org/LeadingEdge/Phantom4000.pdfsL     www.encompasserve.org/~kaplow_r/    www.nira-rocketry.org    www.nar.org  K         This is a country which stands tallest in troubled times, a country?K         that clings to fundamental principles, cherishes its constitutionaltI         heritage, and rejects simple solutions that compromise the values-H         that lie at the roots of our democratic system. -- Supreme Court(         Justice Thurgood Marshall, 1972    ------------------------------  % Date: Tue, 21 Dec 2004 23:42:52 -0500n- From: JF Mezei <jfmezei.spamnot@teksavvy.com>e) Subject: Re: Yet another Inquirer articlen, Message-ID: <41C8FB32.4D8D3711@teksavvy.com>   david20@alpha2.mdx.ac.uk wrote: K > As far as VMS customers are concerned it would be better to kill IA64 nowe9 > before any customers have purchased production systems.   K Let me just say that I won't be surprised if HP announces something betweentL now and the time VMS is now expected to ship, or that the shipping date will again be pushed back.   G But then again, shipping delays for software are not uncommon in the IT F industry and nobody sees any conspiracy theories when Microsoft delaysG shipments of Windows. Proeblem is that whil we see incompetance and low)K quality software riddle with bugs at Microsoft, we have high esteem for VMS I engineers and the sofwtare they write, so when seeking to explain delays,hF incompetante and bad software quality aren't high on the list for VMS.   ------------------------------    Date: 21 Dec 2004 12:45:16 -0800+ From: youtho@thorin.biz (youtho@thorin.biz)n7 Subject: You will find your answer on the Appmind forum?< Message-ID: <c4ca1a5.0412211245.7f519bb6@posting.google.com>   Hello Darren  K I have added your question to the Appmind forum at http://forum.appmind.com-M you will your question find on http://forum.appmind.com/viewtopic.php?p=22#22o     Regards, Jonas Thorin    ------------------------------   Date: 21 Dec 2004 21:01:26 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)I Subject: Re: [Nomex on]: Security research suggests Linux has fewer flaws , Message-ID: <32rh95F3p3nr7U3@individual.net>  ; In article <5o1wd.8911$nE7.520@newssvr17.news.prodigy.com>,4( 	"John Vottero" <John@mvpsi.com> writes:1 > "John Smith" <a@nonymous.com> wrote in message a( > news:0bKdnUNj_tV6E13cRVn-rA@igs.net... >> FredK wrote:-G >>> Hmmm.  Lets see.  From the article it appears that they have a toollE >>> that puports to find certain classes of bugs in C/C++ code.  TheyhD >>> can't run it against proprietary OS kernels, but they can run itF >>> against the Linux kernel (which is only a tiny part of what peopleD >>> think of as Linux).  So they take an analysis of some particularI >>> types of bugs that *can be inferred by automatic inspection* by theiroC >>> tool on Linux, against some random set of "commercial SW" - andeB >>> conclude that the Linux kernel has fewer bugs than other OS's? >>>e! >>> People get *paid* to do this?h >> >>M >> Not only do they get paid to do this but they also get paid while speakingyL >> with reporters who know nothing. Said reporters, assigned by editors who  >> dotI >> no checking, write articles which are published under lurid headlines.- >>F >> May as well write articles with headlines like, "Two-headed Martian. >> Programmers Find Flaws in zOS". Film at 11. >> > O > It's down right comical that only hours later, the trade rags are trumpeting e > this headline: > , > New Set Of Linux Security Flaws Discovered > I > A security researcher has uncovered a set of security flaws in an imagerG > component which could put Linux users at risk of system compromise ifm( > they view a maliciously crafted image. > F > http://www.computerworld.com/newsletter/0,4902,98120,00.html?nlid=OS  rD I just read one article singing the praises of VMS claimed the MotifD bug doesn't count cause X and Motif aren't part of the OS and yet, aE bug in some obscure application library (unless you figure images areaF processed by the kernel) counts as a "serious security flaw" in Linux.  - Sure is nice to be able to have it both ways.o   bill s  t   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>   I   ------------------------------   End of INFO-VAX 2004.708 ************************