1 INFO-VAX	Sat, 25 Feb 2006	Volume 2006 : Issue 111       Contents: Re: Blade vs Superdome Re: Blade vs Superdome Re: Blade vs Superdome& Re: Building SSL support on VMS V7.3-2& Re: Building SSL support on VMS V7.3-2 DCL: REPLY/DISABLE/NONOTIFY  Re: DCL: REPLY/DISABLE/NONOTIFY % DS10 466 Mhz EV6 upgrade 617 Mhz EV67 ) Re: DS10 466 Mhz EV6 upgrade 617 Mhz EV67 ; ECP VMSDSK Disk Statistics Dara Record - disk busy question K Re: Entry-level Integrity Servers? (was: Itanium still not on alpha level!)  Error message help?  Re: Error message help? & Re: F$GETSYI suggestion (IP addresses), Re: Here it is: OpenVMS/Alpha on a simulator+ Re: IA64 VMS V8.2-1: SYSTEM-F-VA_NOTPAGALGN  Re: Mosaic v3.9 compile  Re: need help with Flakey VLC  Re: need help with Flakey VLC  OpenVMS screenshots?1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! # Re: question about VMS732_LMF-V0200 , Re: Rich Marcello in VMS mention shocker :-), Re: Rich Marcello in VMS mention shocker :-), Re: Rich Marcello in VMS mention shocker :-), Re: Rich Marcello in VMS mention shocker :-), Re: Rich Marcello in VMS mention shocker :-), Re: Rich Marcello in VMS mention shocker :-)2 Re: Rocky Mountain Local Users Group March Meeting SYS and EXE file specs?  Re: SYS and EXE file specs? - Re: What is going on with VAX prices on ebay? & Whats MORE Secure? OpenVMS or OpenBSD?* Re: Whats MORE Secure? OpenVMS or OpenBSD?  F ----------------------------------------------------------------------  % Date: Fri, 24 Feb 2006 15:58:04 -0600 2 From: David J Dachtera <djesys.nospam@comcast.net> Subject: Re: Blade vs Superdome + Message-ID: <43FF816C.EC990949@comcast.net>    FredK wrote: > M > Let me agree with Andrew.  Blades will displace large scale SMP systems for M > many customers.  Efficiently scaling a single system image and applications M > to take advantage of very large CPU counts is hard to do - and we have more G > than a few who have the need and the abilty to do so.  But many large M > systems are effectively (if not really) partitioned into smaller subsets of  > CPUs.  > K > From a VMS perspective, I would consider a blade system as a cluster in a L > box with better interconnect technology and packaging.  It's a pretty goodL > technology fit.  It plays well into how VMS clusters are managed, and as a > high-reliabilty solution.   ) That really sparks the imagination, Fred.   @ Imagine four or five ES47(EV7z)-equivalent "blades" comprising aD "cluster in a box". Not bad: "midrange", yet "horizontally"-scalable) without expanding the physical footprint.    --   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/   ------------------------------  % Date: Fri, 24 Feb 2006 17:32:29 -0500 * From: "FredK" <fred.nospam@nospam.dec.com> Subject: Re: Blade vs Superdome , Message-ID: <43ff897e$1@usenet01.boi.hp.com>  ? "David J Dachtera" <djesys.nospam@comcast.net> wrote in message % news:43FF816C.EC990949@comcast.net...  > FredK wrote: > > K > > Let me agree with Andrew.  Blades will displace large scale SMP systems  for B > > many customers.  Efficiently scaling a single system image and applicationsJ > > to take advantage of very large CPU counts is hard to do - and we have moreI > > than a few who have the need and the abilty to do so.  But many large L > > systems are effectively (if not really) partitioned into smaller subsets of	 > > CPUs.  > > K > > From a VMS perspective, I would consider a blade system as a cluster in  a I > > box with better interconnect technology and packaging.  It's a pretty  goodL > > technology fit.  It plays well into how VMS clusters are managed, and as a  > > high-reliabilty solution.  > + > That really sparks the imagination, Fred.  > B > Imagine four or five ES47(EV7z)-equivalent "blades" comprising aF > "cluster in a box". Not bad: "midrange", yet "horizontally"-scalable+ > without expanding the physical footprint.  >   L Scale up or scale out.  If your app needs to scale up - GS1280 or Superdome.L Scale out - any combo of small boxes and SAN storage (a rack or ex2620's forJ example).  Blades just makes the packaging for scale out much cooler.  VMSG will do both, but which one meets your applications performance and RAS  requirements will vary.    ------------------------------    Date: 24 Feb 2006 17:48:56 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)  Subject: Re: Blade vs Superdome 3 Message-ID: <CdttERXFMvaZ@eisner.encompasserve.org>   ` In article <43FF816C.EC990949@comcast.net>, David J Dachtera <djesys.nospam@comcast.net> writes: > FredK wrote: >>  N >> Let me agree with Andrew.  Blades will displace large scale SMP systems forN >> many customers.  Efficiently scaling a single system image and applicationsN >> to take advantage of very large CPU counts is hard to do - and we have moreH >> than a few who have the need and the abilty to do so.  But many largeN >> systems are effectively (if not really) partitioned into smaller subsets of >> CPUs. >>  L >> From a VMS perspective, I would consider a blade system as a cluster in aM >> box with better interconnect technology and packaging.  It's a pretty good M >> technology fit.  It plays well into how VMS clusters are managed, and as a  >> high-reliabilty solution. > + > That really sparks the imagination, Fred.  > B > Imagine four or five ES47(EV7z)-equivalent "blades" comprising aF > "cluster in a box". Not bad: "midrange", yet "horizontally"-scalable+ > without expanding the physical footprint.   C As many of us said back in the days before Alpha, SMP is the answer , for some problems and Clustering for others.   ------------------------------   Date: 24 Feb 2006 21:28:06 GMT& From: Frank da Cruz <fdc@columbia.edu>/ Subject: Re: Building SSL support on VMS V7.3-2 7 Message-ID: <slrndvuuj6.g9j.fdc@sesame.cc.columbia.edu>   7 On 2006-02-24, Dave Harrold <DHarrold@wi.rr.com> wrote:   ) (Referring to the latest C-Kermit build:)   -   http://www.columbia.edu/kermit/ckdaily.html   G : We have a requirment an FTP connection over SSL from our system to an B : external provider.  I pulled the latest daily build kit down and : rebuilt using the SSL option.  : # : @ckvker.com s D "CK_SSL, NODEBUG"  : + : Which resulted in this version of kermit:  : 8 : C-Kermit 8.0.212 Dev.13, 9 Feb 2006, for OpenVMS Alpha :  Copyright (C) 1985, 2006,< :   Trustees of Columbia University in the City of New York. : Type ? or HELP for help.# : UTILITY:[KERMIT.SOURCE] C-Kermit>  : A : Following the examples in the security guide, I am running into > : problems.  The SET FTP commands do not seem to exist in this : executable I built.  : B Right, as noted on the website the FTP client is available only in. the Unix version of C-Kermit and in Kermit 95.  C : UTILITY:[KERMIT.SOURCE] C-Kermit>set ftp ?No keywords match - ftp & : UTILITY:[KERMIT.SOURCE] C-Kermit>set : / : So, can anyone help me get past this problem?  : C Only by adapting the FTP module (ckcftp.c) to VMS.  This would be a F rather major undertaking, even by someone who would know how to do it:    . DEC C programmer 6  . RMS programming for accessing the local file system9  . Familiarity with the various TCP/IP stacks used in VMS .  . Familiarity with FTP and security protocols.  . Familiarity with VMS-specific FTP protocols  J Over the last few years I've spoken to almost everyone who has this set ofL skills, but none of them has time to work on it, although everyone agrees itH would be a great addition to the VMS toolbag, if it were done: a secure, scriptable FTP client for VMS.   - Frank    ------------------------------  % Date: Fri, 24 Feb 2006 17:10:58 -0600 2 From: David J Dachtera <djesys.nospam@comcast.net>/ Subject: Re: Building SSL support on VMS V7.3-2 + Message-ID: <43FF9282.DF9231A8@comcast.net>    Frank da Cruz wrote: > 9 > On 2006-02-24, Dave Harrold <DHarrold@wi.rr.com> wrote:  > + > (Referring to the latest C-Kermit build:)  > / >   http://www.columbia.edu/kermit/ckdaily.html  > I > : We have a requirment an FTP connection over SSL from our system to an D > : external provider.  I pulled the latest daily build kit down and! > : rebuilt using the SSL option.  > : % > : @ckvker.com s D "CK_SSL, NODEBUG"  > : - > : Which resulted in this version of kermit:  > : : > : C-Kermit 8.0.212 Dev.13, 9 Feb 2006, for OpenVMS Alpha > :  Copyright (C) 1985, 2006,> > :   Trustees of Columbia University in the City of New York. > : Type ? or HELP for help.% > : UTILITY:[KERMIT.SOURCE] C-Kermit>  > : C > : Following the examples in the security guide, I am running into @ > : problems.  The SET FTP commands do not seem to exist in this > : executable I built.  > : D > Right, as noted on the website the FTP client is available only in0 > the Unix version of C-Kermit and in Kermit 95. > E > : UTILITY:[KERMIT.SOURCE] C-Kermit>set ftp ?No keywords match - ftp ( > : UTILITY:[KERMIT.SOURCE] C-Kermit>set > : 1 > : So, can anyone help me get past this problem?  > : E > Only by adapting the FTP module (ckcftp.c) to VMS.  This would be a H > rather major undertaking, even by someone who would know how to do it: >  >  . DEC C programmer   # I thought those were fairly common.   8 >  . RMS programming for accessing the local file system   Use the C built-ins?  ; >  . Familiarity with the various TCP/IP stacks used in VMS   H Use the UCX specifications. PSC products provide "UCX emulation", if I'm not too badly mistaken.   0 >  . Familiarity with FTP and security protocols  # I thought those were fairly common.   0 >  . Familiarity with VMS-specific FTP protocols  H I wasn't aware there were any, since TCP/IP is a layered product and notG so much "built into" the kernel, as in UN*X-land. ...unless, of course, D you're talking about file naming conventions and trying to translate? between VMS and platforms where filespecs are more "free form".   1 (DBT: Please relate this to my off-group e-mail.)    --   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/   ------------------------------    Date: 24 Feb 2006 15:51:57 -0800  From: "mrlama" <starkh@saic.com>$ Subject: DCL: REPLY/DISABLE/NONOTIFYB Message-ID: <1140825117.044272.66710@u72g2000cwu.googlegroups.com>  F Curious, what is the purpose of the /NONOTIFY qualifier for REPLY when/ used with /DISABLE during an interactive login?    ------------------------------    Date: 24 Feb 2006 18:38:11 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) ( Subject: Re: DCL: REPLY/DISABLE/NONOTIFY3 Message-ID: <iyG7meXsqSp6@eisner.encompasserve.org>   e In article <1140825117.044272.66710@u72g2000cwu.googlegroups.com>, "mrlama" <starkh@saic.com> writes: H > Curious, what is the purpose of the /NONOTIFY qualifier for REPLY when1 > used with /DISABLE during an interactive login?   D To be able to disable operator status without indicating that change< to the person logged in, such as within a command procedure.   ------------------------------    Date: 24 Feb 2006 18:58:16 -0800 From: shofu_au@yahoo.com.au . Subject: DS10 466 Mhz EV6 upgrade 617 Mhz EV67C Message-ID: <1140836296.468594.168860@t39g2000cwt.googlegroups.com>   	 Hi Group,   G Is it possible to upgrade a DS10 466 Mhz EV6 to 617 Mhz EV67 system via  CPU replacement?  G >From the AlphaServer DS10 / DS10L, AlphaStation DS10 Console Reference G guide in Appendix A it appears that it is just a set of jumper settings  with the new CPU.    Is this correct?  6 Anyone done the upgrade?  How complicated is it to do?  E How hard is it to find a CPU to use for the replacement and what sort  of cost is invovled?  ! This is for my hobbyist system.      Thanks   Mark   ------------------------------  # Date: Sat, 25 Feb 2006 04:49:57 GMT  From: dittman@dittman.net 2 Subject: Re: DS10 466 Mhz EV6 upgrade 617 Mhz EV67' Message-ID: <VlRLf.161$pE4.70@trnddc04>    shofu_au@yahoo.com.au wrote: > Hi Group,   I > Is it possible to upgrade a DS10 466 Mhz EV6 to 617 Mhz EV67 system via  > CPU replacement?  I > >From the AlphaServer DS10 / DS10L, AlphaStation DS10 Console Reference I > guide in Appendix A it appears that it is just a set of jumper settings  > with the new CPU.    > Is this correct?  8 > Anyone done the upgrade?  How complicated is it to do?  > The CPU is soldered on the motherboard so the upgrade would be somewhat difficult without the proper equipment.   E I've also heard that the cache may be faster on the 600MHz DS10/DS10L B motherboard.  If so, you'd have to replace the cache as well (also soldered on the motherboard).   G > How hard is it to find a CPU to use for the replacement and what sort  > of cost is invovled?   I've seen CPUs on eBay.  --   Eric Dittman dittman@dittman.net    ------------------------------  % Date: Fri, 24 Feb 2006 14:51:59 -0600 + From: brandon@dalsemi.com (BRANDON, JOHN M) D Subject: ECP VMSDSK Disk Statistics Dara Record - disk busy question1 Message-ID: <06022414515962@dscis6-0.dalsemi.com>   G I am using ECP to collect statistical data for performance tracking and 	 trending.   M I am currently researching a performance problem with one of the disk drives.   H My suspicion is that the disk, $1$DGA3:, is over-burdened with activity.  A In the ECP VMSDSK record there is a field for "Disk utilization".   M In question is the "Percentage of time disk was busy from perspective of this  node."  L The aforementioned disk is cluster mounted (SAN) and the values for the busyN state are 100% for NODE1, 30% for NODE2, and 55% for NODE3.  When combined all three nodes never exceed 300%.  M My question, how can the aforementioned disk be 100% on one node and not 100%  on the others?  1 Are there limits associated with the disk in ECP?    How is 100% determined?        John "REBOOT" Brandon  VMS Systems Administrator * firstname.lastname.spam.me.not@dalsemi.com   ------------------------------  % Date: Fri, 24 Feb 2006 17:27:41 -0500 * From: "FredK" <fred.nospam@nospam.dec.com>T Subject: Re: Entry-level Integrity Servers? (was: Itanium still not on alpha level!), Message-ID: <43ff885e$1@usenet01.boi.hp.com>  L "Phillip Helbig---remove CLOTHES to reply" <helbig@astro.multiCLOTHESvax.de>/ wrote in message news:dtnjg5$81c$3@online.de...  > In articleC > <rdeininger-2302061823060001@user-uinj4ma.dialup.mindspring.com>, 9 > rdeininger@mindspringdot.com (Robert Deininger) writes:  > K > > HP still makes and sells single-CPU Integrity systems, and VMS supports  them. 7 > > They are not particularly hard to find or purchase. @ > > They are a lot less expensive than single-CPU Alpha systems.? > > They are significantly faster for almost every application.  > G > What is the list price, approximately, of the least expensive Itanium 8 > system, including the following essential ingredients: > 2 >    o  twice the supported-minimum-for-VMS memory >  >    o  SCSI >  >    o  ethernet > 7 >    o  device to boot from (if non-SCSI-device needed)  >  >    o  bootable OS media  > ) >    o  documentation media (CD, DVD etc)  >   G Dunno the price.  Go to HP.COM and configure a rx1620.  The base system I comes with 1 CPU, built in SCSI, built in ethernet, built in DVD.  As for I memory... don't know the minimum offhand, but I'd put at least 1gb in it. 3 Configure it with a single 36gb (or whatever) disk.    ------------------------------  % Date: Fri, 24 Feb 2006 14:20:18 -0500 , From: "Display Name" <someone@microsoft.com> Subject: Error message help?= Message-ID: <er-dnTBWjfjuwWLeRVn-iA@metrocastcablevision.com>   D Have recently begun seeing the following, on an ES-45 with VMS7.3-2.K Not sure what might be generating the error. No 'obvious' correlated events  ... > Event: Too Few Servers Detected from: Node LOCAL:.LRHLTH DTSS,  -         at: 2006-02-24-09:02:01.973-05:00Iinf            Number Detected=0,           Number Required=1   7         eventUid   3815C084-A514-11DA-BD59-4C52484C5448   7         entityUid  8D8C275F-A47A-11DA-85AE-AA0004000C8C   7         streamUid  8D5CC569-A47A-11DA-8588-AA0004000C8C    ------------------------------  % Date: Sat, 25 Feb 2006 06:16:31 +0100 2 From: martin@radiogaga.harz.de (Martin Vorlaender)  Subject: Re: Error message help?; Message-ID: <43ffe82f.524144494f47414741@radiogaga.harz.de>     noone <noone@nowhere.com> wrote:G > I do not recall how to shut down DTSS unless you do a stop/id on any   > dtss-related processes.   	 $ MCR NCL  NCL> disable dtss  NCL> delete dtss   cu,    Martin --  >                        |  Martin Vorlaender  |  OpenVMS rules!1   OpenVMS: When you    |  work: mv@pdv-systeme.de D   KNOW where you want  |    http://www.pdv-systeme.de/users/martinv/8   to go today.         |  home: martin@radiogaga.harz.de   ------------------------------  % Date: Fri, 24 Feb 2006 16:20:52 -0600 2 From: David J Dachtera <djesys.nospam@comcast.net>/ Subject: Re: F$GETSYI suggestion (IP addresses) + Message-ID: <43FF86C3.1664CFA3@comcast.net>    JF Mezei wrote:  >  > David J Dachtera wrote: J > > I'd have to go with the others, but I'd suggest a service/lexical nameL > > such as (SYS)$GETUCX and F$GETUCX() to avoid possible confusion on those, > > sites running third-party TCP/IP stacks. >  > WRONG. > J > What do you think is the best solution: for the VMS and Multinet/TCPWareG > engineers to have lunch together and agree on a standard interface to I > some SYS$GETTCPIP service and have applications be totally oblivious to I > the colour of the TCPIP stack under them, or continue to have disparate F > calling standards which prevent applicatiosn from using them becauseF > they are not garanteed to work, forcing application writers to write: > more complex code and re-invent the wheel all the time ? > H > The value to customers of a unified interface is worth far more than a > few hours of engineers' time.   D I don't quite understand that response, since it seems to contradict itself.   F Multinet has had "UCX emulation" since years. That suggests some level> of agreement between the involved parties. Extending that to aG documented API so that Multinet or TCPware would would work identically F to UCX with respect to the proposed system calls seems to me a logical& extension of the existing arrangement.  D Lacking that, however, (SYS)$GETUCX vs. PSC_GETTCPIP draws a clearer@ line between the products, however inconvenient it may be. WhereD Mutlinet overlaps with UCX through emulation, the (SYS)$GETUCX callsG should function transparently regardless of which product is installed. , That's the part which requires co-operation.   --   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/   ------------------------------  % Date: Fri, 24 Feb 2006 16:22:31 -0600 2 From: David J Dachtera <djesys.nospam@comcast.net>5 Subject: Re: Here it is: OpenVMS/Alpha on a simulator + Message-ID: <43FF8727.9C9DAC98@comcast.net>    Galen wrote: > F > No flames from this direction. But the tone of the e-mail I receivedD > was that reaching the hobbyist world, at least the lower end of itB > where I live, was not on their list of things to do. And I don't' > dispute their right to [not] do this.   : I don't dispute their right, but I do question the wisdom.   --   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/   ------------------------------  # Date: Fri, 24 Feb 2006 20:11:46 GMT & From: John Reagan <john.reagan@hp.com>4 Subject: Re: IA64 VMS V8.2-1: SYSTEM-F-VA_NOTPAGALGN2 Message-ID: <6MJLf.3666$YJ5.3222@news.cpqcorp.net>   Albrecht Schlosser wrote:    > Will there also be a patch?  > 
 > Albrecht  ) I was afraid you'd ask that question. :-)   A Not to speak for the linker/image-activator person, but I will...   B There have been several changes in this area for V8.3.  Trying to F extract the bug fix and backport it would be awkward and hard to test G (if we had complete testing, we would have found this ourselves, yes?).   @ So I'll say "No, we aren't planning a patch unless it is really < critical."  Can you work around it in your real application?   --   John Reagan / HP Pascal/{A|I}MACRO for OpenVMS Project Leader  Hewlett-Packard Company    ------------------------------  % Date: Fri, 24 Feb 2006 16:09:51 -0600 2 From: David J Dachtera <djesys.nospam@comcast.net>  Subject: Re: Mosaic v3.9 compile+ Message-ID: <43FF842F.DC3C83EC@comcast.net>    JF Mezei wrote:  >  > David J Dachtera wrote: K > > > If there is conditional compilation (for instance, whether to support  > > > HTTPS: > > L > > At this stage of software development evolution, I'd expect that to be a7 > > configurable option, not conditionally compiled-in.  > J > The linker will complain if the object files or shareable images for SSLH > support are not present. If if you prepare pre-linked kits, then it isG > the image activator that will complain when the customer tries to run ? > that image even if that customer doesn't intend to use HTTPS:   . I understand the point you're trying to make.   H Still, Without HTTPS, I couldn't access webmail on any of ISPs. So, that& browser wouldn't be very useful to me.   > [snip]   --   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/   ------------------------------    Date: 24 Feb 2006 19:28:58 -08003 From: "rsponholtz@gmail.com" <rsponholtz@gmail.com> & Subject: Re: need help with Flakey VLCC Message-ID: <1140838138.072905.280230@j33g2000cwa.googlegroups.com>   A Well, I swapped out the SIMMs, and the machine still didn't work. A After sitting (unplugged) for another day, the machine worked for F another couple of hours, but now I'm back to the 1111 1011 error.  I'mB kind of at a loss - I'm wondering if the motherboard is bad, or ifG there is something else I could do.  It doesn't seem like there are any 0 components that I could replace on the machine..   ------------------------------    Date: 24 Feb 2006 22:43:10 -06004 From: cornelius@encompasserve.org (George Cornelius)& Subject: Re: need help with Flakey VLC3 Message-ID: <PumRUkd4$L0I@eisner.encompasserve.org>   C In article <1140838138.072905.280230@j33g2000cwa.googlegroups.com>, 5 "rsponholtz@gmail.com" <rsponholtz@gmail.com> writes: C > Well, I swapped out the SIMMs, and the machine still didn't work. C > After sitting (unplugged) for another day, the machine worked for H > another couple of hours, but now I'm back to the 1111 1011 error.  I'mD > kind of at a loss - I'm wondering if the motherboard is bad, or ifI > there is something else I could do.  It doesn't seem like there are any 2 > components that I could replace on the machine..  D I once had some odd problems with a VLC for which it turned out thatA there was an engineering bulletin about memory SIMMs being placed C so close to the internal HDD that, strangely enough, stray magnetic 1 fields during drive activity could affect memory.   E As I recall, the solution was to shift to a newer model of hard drive B (an RZ25, perhaps?), with an alternative approach being to go to a  different manufacturer's SIMM's.  C I do not know if this matches your symptoms, but I thought it might B be something to keep in mind.  You should be able to test this outA by using an external hard drive and disconnecting or removing the  internal drive.    --9 George Cornelius              cornelius@encompasserve.org 0                               cornelius@mayo.edu   ------------------------------    Date: 24 Feb 2006 21:19:02 -0800$ From: "as400" <vin42and99@yahoo.com> Subject: OpenVMS screenshots? B Message-ID: <1140844741.961897.71030@j33g2000cwa.googlegroups.com>  < Since I now know that OpenVMS may be the most secure UNIX OSC around...Can anyone please provide me with a link to view some nice  screenshots of OpenVMS? Please?    Thanks   ------------------------------   Date: 24 Feb 2006 19:06:36 GMT( From: bill@cs.uofs.edu (Bill Gunshannon): Subject: Re: Plain truth is that unix/linux is NOT secure!+ Message-ID: <4693psF9vrosU1@individual.net>   3 In article <0OodBIaeVOXm@eisner.encompasserve.org>, > 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:[ > In article <ReednZUH0fz0KmbeRVn-gQ@libcom.com>, Dave Froble <davef@tsoft-inc.com> writes: I >> It's not that Unix has a 'root' user.  The issue is how easy it is to   >> get 'root' login/privs. >>H >> Are you going to tell me that BYPASS is any less of a security issue   >> than the 'root' user on Unix? > G >    No the problem is that the mail program on UNIX runs as root.  The 2 >    mail program on VMS does not run with BYPASS.  D Don't know how to break this to you, but the mail program on my mailC server does not run as root.  Once again, we compare unix as it was @ 10 years ago with current versions of other OSes.  Granted, someB people still run sendmail and still run it as root, but that is byA choice and not something the Unix somehow forces on the sysadmin.    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: 24 Feb 2006 19:30:53 GMT( From: bill@cs.uofs.edu (Bill Gunshannon): Subject: Re: Plain truth is that unix/linux is NOT secure!+ Message-ID: <46957dFa07h8U1@individual.net>   3 In article <0Vlnvu2C1VEY@eisner.encompasserve.org>, 0 	Kilgallen@SpamCop.net (Larry Kilgallen) writes:X > In article <46931tFa1foeU1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:6 >> In article <U8qfPVN$TOfM@eisner.encompasserve.org>,3 >> 	Kilgallen@SpamCop.net (Larry Kilgallen) writes: u >>> In article <+gaKOvOZgMEC@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: h >>>> In article <TPWtKC6$jOOC@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:q >>>>> In article <43fc37de$0$67256$157c6196@dreader2.cybercity.dk>, Karsten Nyblad <nospam@nospam.nospam> writes:  >>>>> L >>>>>> Getting the password for root on *NIX is just as easy as getting the H >>>>>> password for OpenVMS.  Besides, people are putting more and more O >>>>>> security into Linux.  I am far from certain that OpenVMS is more secure  4 >>>>>> by design than newer Linux any Unix variants. >>>>> L >>>>> How does Unix handle users attempting to overflow the password history >>>>> buffer ? >>>>  L >>>>   As in all things UNIX, it depends on the UNIX.  What you can count onD >>>>    is a very good chance of not even having a password history. >>> M >>> Oh I know there are lots of insecure Unix variants out there.  I was just K >>> waiting for one of those people who claim (some) Unix is secure to step J >>> up the the plate and explain how their best-in-class Unix handles this >>> particular problem.  >>  H >> I guess the big problem is that no unix users to date have thought itI >> was useful enough to ask for.  Considering that all the code to handle G >> password history would be within one program that doesn't run inside I >> the kernel at all, it would be fairly trivial to add any form of pass-  > D > So I gather no Unix has a callable entrypoint to set the password.  D If you mean an entry point in the kernel, of course not.  It's not aC kernel function.  The password is contained in a file, you change a C password by changing the entry in the file.  thus, there is nothing A to stop a sysadmin from writing his own password changing program D implementing whatever additional policies he sees fit.  It's part of* the flexibility of the Unix paradigm.  :-)   > F >> word history you wanted.  But, like most things, if no one wants it; >> no one is going to put forth the effort to implement it.  > C > Well, the US Government wants it.  Search for "password reuse" in   A And yet while NSA spent all that time and research securing Linux ? they never even bothered doing something as trivial as password  history.  Go figure.   > @ > http://csrc.nist.gov/publications/nistpubs/800-53/SP800-53.pdf > F > FIPS 200 is scheduled to make that mandatory for all federal systemsI > when signed by the Secretary of Commerce later this month, implementing ? > the 2002 Federal Information Security Management Act (FISMA).   D And we al know what "mandatory" means in government.  Hmmmm....  LetE me see.  Wasn't there a FIPS that made the use of Ada mandatory?  And F the service that was most responsible for foisting it on the computingG world was the first one to refuse to abide by that rule.  Never confuse  government with reality.   > H >> Just out of curiosity, define for me what you consider a proper pass-E >> word history scheme.  Maybe I'll implement it in my spare time and G >> release it to the world.  Then we can watch and see if anyone really  >> cares.  :-) > D > A proper password history scheme handles users who try to overloadK > the history space with some method other than minimum password lifetimes. F > The Microsoft approach of minimum password lifetimes leaves one openE > to an attack whereby a user is observed changing their password and F > upon discovering they were observed is unable to change the password/ > again until the minimum lifetime has expired.   ? How about one that let's you change your password as many times > as you want whenever you want but keeps track of the last time@ you used a cetain password and won't let you reuse it for either> a cetain calendar period or possibly forever.  Include in this@ the usual variant checking.  The biggest drawback to this is the= space to save all the old passwords, but that's not much of a  drawback today.   C By the way, the solution to your theoretical danger above is called @ the sysadmin who can either change your password or allow you to$ change it if a threat is identified.   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: 24 Feb 2006 13:22:15 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) : Subject: Re: Plain truth is that unix/linux is NOT secure!3 Message-ID: <IlcNeqU4$uOH@eisner.encompasserve.org>   V In article <4693psF9vrosU1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: > F > Don't know how to break this to you, but the mail program on my mail > server does not run as root.  J    You and Andrew have the same problem.  You site one up to date counter I    example as if that means it isn't so on any curent UNIX.  UNIX is not  K    one OS.  What is so on current UNIX is so on all current UNIX, not just  ,    on current Solaris, or current HP-UX, ...  H    Whereas I cite what is so on current VMS, and it is so on all current    VMS.   ;    And I still haven't seen the answer to Larry's question.    ------------------------------    Date: 24 Feb 2006 13:13:37 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) : Subject: Re: Plain truth is that unix/linux is NOT secure!3 Message-ID: <WaOZhwShP3a8@eisner.encompasserve.org>   c In article <U8qfPVN$TOfM@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:  > K > Oh I know there are lots of insecure Unix variants out there.  I was just I > waiting for one of those people who claim (some) Unix is secure to step H > up the the plate and explain how their best-in-class Unix handles this > particular problem.  > * > Bob, I guess you are not that person :-)  D     I was really disapointed when I got my first digital UNIX system)    and it didn't have a password history.       Sigh.   ------------------------------    Date: 24 Feb 2006 13:10:57 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) : Subject: Re: Plain truth is that unix/linux is NOT secure!3 Message-ID: <0Vlnvu2C1VEY@eisner.encompasserve.org>   V In article <46931tFa1foeU1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:5 > In article <U8qfPVN$TOfM@eisner.encompasserve.org>, 2 > 	Kilgallen@SpamCop.net (Larry Kilgallen) writes:t >> In article <+gaKOvOZgMEC@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:g >>> In article <TPWtKC6$jOOC@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes: p >>>> In article <43fc37de$0$67256$157c6196@dreader2.cybercity.dk>, Karsten Nyblad <nospam@nospam.nospam> writes: >>>>  K >>>>> Getting the password for root on *NIX is just as easy as getting the  G >>>>> password for OpenVMS.  Besides, people are putting more and more  N >>>>> security into Linux.  I am far from certain that OpenVMS is more secure 3 >>>>> by design than newer Linux any Unix variants.  >>>>  K >>>> How does Unix handle users attempting to overflow the password history 
 >>>> buffer ?  >>> K >>>   As in all things UNIX, it depends on the UNIX.  What you can count on C >>>    is a very good chance of not even having a password history.  >>  L >> Oh I know there are lots of insecure Unix variants out there.  I was justJ >> waiting for one of those people who claim (some) Unix is secure to stepI >> up the the plate and explain how their best-in-class Unix handles this  >> particular problem. > G > I guess the big problem is that no unix users to date have thought it H > was useful enough to ask for.  Considering that all the code to handleF > password history would be within one program that doesn't run insideH > the kernel at all, it would be fairly trivial to add any form of pass-  B So I gather no Unix has a callable entrypoint to set the password.  E > word history you wanted.  But, like most things, if no one wants it : > no one is going to put forth the effort to implement it.  A Well, the US Government wants it.  Search for "password reuse" in   > http://csrc.nist.gov/publications/nistpubs/800-53/SP800-53.pdf  D FIPS 200 is scheduled to make that mandatory for all federal systemsG when signed by the Secretary of Commerce later this month, implementing = the 2002 Federal Information Security Management Act (FISMA).   G > Just out of curiosity, define for me what you consider a proper pass- D > word history scheme.  Maybe I'll implement it in my spare time andF > release it to the world.  Then we can watch and see if anyone really
 > cares.  :-)   B A proper password history scheme handles users who try to overloadI the history space with some method other than minimum password lifetimes. D The Microsoft approach of minimum password lifetimes leaves one openC to an attack whereby a user is observed changing their password and D upon discovering they were observed is unable to change the password- again until the minimum lifetime has expired.    ------------------------------    Date: 24 Feb 2006 13:25:54 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) : Subject: Re: Plain truth is that unix/linux is NOT secure!3 Message-ID: <wfwXjDu9Ifwx@eisner.encompasserve.org>   V In article <468rr4F9nok6U2@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: > I > That has nothing to do with wether or not Unix has a root or superviser G > user it has to do with the design of the shell.  If it was desired by K > Unix users the capabilty to define variables that can be seen system wide J > could be implemented.  But the fact is, even after all these years, Unix+ > users don't see it as anything they need.   G    On the contrary, it's something they've already been told they can't F    have.  Of course, it was only one example of what's wrong with the F    UNIX shell approach.  Some of the others are too closely related to/    security issues for me to discuss them here.    ------------------------------   Date: 24 Feb 2006 19:37:06 GMT( From: bill@cs.uofs.edu (Bill Gunshannon): Subject: Re: Plain truth is that unix/linux is NOT secure!+ Message-ID: <4695j2Fa07h8U2@individual.net>   3 In article <wfwXjDu9Ifwx@eisner.encompasserve.org>, > 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:X > In article <468rr4F9nok6U2@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: >>  J >> That has nothing to do with wether or not Unix has a root or superviserH >> user it has to do with the design of the shell.  If it was desired byL >> Unix users the capabilty to define variables that can be seen system wideK >> could be implemented.  But the fact is, even after all these years, Unix , >> users don't see it as anything they need. > I >    On the contrary, it's something they've already been told they can't  >    have.    3 Who told them that?  And when?  AT&T 20 yeaars ago?   G >          Of course, it was only one example of what's wrong with the  H >    UNIX shell approach.  Some of the others are too closely related to1 >    security issues for me to discuss them here.    E The "UNIX shell approach" could easily be changed if there was a real D reason 9and a desire by the user community) to do it.  It serves itsE users well enough.  When it no longer does, it will change.  How easy E is it to get changes in VMS when only one or two users are interested C in them?  Can I have a fully functuional fork() call tomorrow?  :-) B But then, the VMS user community has never seen a need for fork(), at least not til now.....    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: 24 Feb 2006 19:51:30 GMT( From: bill@cs.uofs.edu (Bill Gunshannon): Subject: Re: Plain truth is that unix/linux is NOT secure!+ Message-ID: <4696e2Fa07h8U3@individual.net>   3 In article <IlcNeqU4$uOH@eisner.encompasserve.org>, > 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:X > In article <4693psF9vrosU1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: >>  G >> Don't know how to break this to you, but the mail program on my mail  >> server does not run as root.  > L >    You and Andrew have the same problem.  You site one up to date counter K >    example as if that means it isn't so on any curent UNIX.  UNIX is not  M >    one OS.  What is so on current UNIX is so on all current UNIX, not just  . >    on current Solaris, or current HP-UX, ... > J >    Whereas I cite what is so on current VMS, and it is so on all current	 >    VMS.   C But that is the difference between proprietary and non-proprietary. ? You are right, there is no one true Unix.  But people, (here in C particular) are perfectly comfortable to say "Unix does X" and when A they get called on it, they say, "Well, all Unixes are differnt." E Nice when you can have it both ways.  Just because VMS does not allow F the flexibility that Unix allows doesn't make Unix wrong.  Many peopleA (and there are very likely more Unix users than VMS users) prefer 6 that flexibility.  Otherwise, they would be VMS users.  : > And I still haven't seen the answer to Larry's question.  , Well, the only question I see of Larry's is:A   "How does Unix handle users attempting to overflow the password     history buffer ?"H and, being as at this point in time I am only familiar with Solaris 10's> system and I don't see where it does.  How does VMS handle it?  @ By the way, VMS passwords still mono-case.  How do you reconcileE that with the government requirement that passwords contain a certain E number of upper and lower case characters?  I believe that's probably > a FIPS mandate too, although at this point it may only be DOD.   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: 24 Feb 2006 14:26:27 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) : Subject: Re: Plain truth is that unix/linux is NOT secure!3 Message-ID: <dV1FDCshdhts@eisner.encompasserve.org>   V In article <46957dFa07h8U1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:5 > In article <0Vlnvu2C1VEY@eisner.encompasserve.org>, 2 > 	Kilgallen@SpamCop.net (Larry Kilgallen) writes:  E >> So I gather no Unix has a callable entrypoint to set the password.  > F > If you mean an entry point in the kernel, of course not.  It's not aE > kernel function.  The password is contained in a file, you change a E > password by changing the entry in the file.  thus, there is nothing C > to stop a sysadmin from writing his own password changing program F > implementing whatever additional policies he sees fit.  It's part of, > the flexibility of the Unix paradigm.  :-)  D AU-2 of 800-53 does allow the organization the flexibility to chooseH what is an auditable event, but expecting local password change programsG to do their own file access greatly increases the chance they will fail G to do the auditing, just as they will likely fail to honor the password 
 history, etc.   G >>> word history you wanted.  But, like most things, if no one wants it < >>> no one is going to put forth the effort to implement it. >>  D >> Well, the US Government wants it.  Search for "password reuse" in > C > And yet while NSA spent all that time and research securing Linux A > they never even bothered doing something as trivial as password  > history.  Go figure.  E I did not realize you were such a Linux fan, but my interpretation of E their Secure Linux effort was that they saw Linux security was so far = behind other operating systems that they had to do something.   A >> http://csrc.nist.gov/publications/nistpubs/800-53/SP800-53.pdf  >>  G >> FIPS 200 is scheduled to make that mandatory for all federal systems J >> when signed by the Secretary of Commerce later this month, implementing@ >> the 2002 Federal Information Security Management Act (FISMA). > 6 > And we al know what "mandatory" means in government.    " The public draft of FIPS 200 says:       11. Waivers.  ;     No provision is provided under FISMA for waivers to the ;     Federal Information Processing Standards made mandatory !     by the Secretary of Commerce.   I >>> Just out of curiosity, define for me what you consider a proper pass- F >>> word history scheme.  Maybe I'll implement it in my spare time andH >>> release it to the world.  Then we can watch and see if anyone really >>> cares.  :-)  >>  E >> A proper password history scheme handles users who try to overload L >> the history space with some method other than minimum password lifetimes.G >> The Microsoft approach of minimum password lifetimes leaves one open F >> to an attack whereby a user is observed changing their password andG >> upon discovering they were observed is unable to change the password 0 >> again until the minimum lifetime has expired. > A > How about one that let's you change your password as many times @ > as you want whenever you want but keeps track of the last timeB > you used a cetain password and won't let you reuse it for either@ > a cetain calendar period or possibly forever.  Include in thisB > the usual variant checking.  The biggest drawback to this is the? > space to save all the old passwords, but that's not much of a  > drawback today.   D Counting on the inability of a rulebreaker to mount a massive effort@ (to include automating it) is not wise.  That is the whole issueF being discussed - how to prevent such an attack without using infiniteD storage.  Even Microsoft understands the bit about infinite storage.  E > By the way, the solution to your theoretical danger above is called B > the sysadmin who can either change your password or allow you to& > change it if a threat is identified.  A That certainly counts on the attacker being slow to exploit their 
 knowledge.   ------------------------------    Date: 24 Feb 2006 14:05:46 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) : Subject: Re: Plain truth is that unix/linux is NOT secure!3 Message-ID: <UIzC9b2x6KFQ@eisner.encompasserve.org>   V In article <4696e2Fa07h8U3@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:5 > In article <IlcNeqU4$uOH@eisner.encompasserve.org>, @ > 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:  ; >> And I still haven't seen the answer to Larry's question.  > . > Well, the only question I see of Larry's is:C >   "How does Unix handle users attempting to overflow the password  >    history buffer ?"J > and, being as at this point in time I am only familiar with Solaris 10's@ > system and I don't see where it does.  How does VMS handle it?  4 It throws the attacker into generated password mode.  , > By the way, VMS passwords still mono-case.  8 Search SYS$LIBRARY:LIB.REQ on VMS V8.2 for UAF$V_PWDMIX.  < The same logic as looking at 10-years-ago Unix should apply.   ------------------------------  % Date: Fri, 24 Feb 2006 21:21:18 +0100 + From: Karsten Nyblad <nospam@nospam.nospam> : Subject: Re: Plain truth is that unix/linux is NOT secure!= Message-ID: <43ff6aba$0$78288$157c6196@dreader1.cybercity.dk>    Bob Koehler wrote:X > In article <4693psF9vrosU1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: > F >>Don't know how to break this to you, but the mail program on my mail >>server does not run as root. >  > L >    You and Andrew have the same problem.  You site one up to date counter K >    example as if that means it isn't so on any curent UNIX.  UNIX is not  M >    one OS.  What is so on current UNIX is so on all current UNIX, not just  . >    on current Solaris, or current HP-UX, ... > J >    Whereas I cite what is so on current VMS, and it is so on all current	 >    VMS.   E That point of view does not make sense to me.  Once you use features  I that are only present in one Unix dialect, you are have additional costs  A when you want to move to a new platform, and of course that is a  I problem.  Yes, *nix is primitive and outdated when you stick to what you  D can expect to find on many *nix dialects.  However, even if you use F features present on only a few *Unix dialects, porting an application H from one *nix platform to an other is by far simpler that moving a none # trivial application to or from VMS.   H To me you are making a common error:  Because the solution to a problem I is far from perfect, you chose not to use the solution even if it may be  I a big help.  In this case the problem is that you want independence from  G hardware and software vendors and because of that you want portability   of your applications.   E Oh. and don't tell me that you do not care about potability, because  G then each Unix dialect is just and OS of its own right and restricting  ? your self to what is common to many Unixes does not make sense.    ------------------------------   Date: 24 Feb 2006 20:59:08 GMT( From: bill@cs.uofs.edu (Bill Gunshannon): Subject: Re: Plain truth is that unix/linux is NOT secure!+ Message-ID: <469acsF9psoqU1@individual.net>   3 In article <dV1FDCshdhts@eisner.encompasserve.org>, 0 	Kilgallen@SpamCop.net (Larry Kilgallen) writes:X > In article <46957dFa07h8U1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:6 >> In article <0Vlnvu2C1VEY@eisner.encompasserve.org>,3 >> 	Kilgallen@SpamCop.net (Larry Kilgallen) writes:  > F >>> So I gather no Unix has a callable entrypoint to set the password. >>  G >> If you mean an entry point in the kernel, of course not.  It's not a F >> kernel function.  The password is contained in a file, you change aF >> password by changing the entry in the file.  thus, there is nothingD >> to stop a sysadmin from writing his own password changing programG >> implementing whatever additional policies he sees fit.  It's part of - >> the flexibility of the Unix paradigm.  :-)  > F > AU-2 of 800-53 does allow the organization the flexibility to chooseJ > what is an auditable event, but expecting local password change programsI > to do their own file access greatly increases the chance they will fail I > to do the auditing, just as they will likely fail to honor the password  > history, etc.   F If you can't trust the sysadmin to do what is called for by SOP or lawG or just plain local whim, then how can oyu trust the system at all?  I, H as the sysadmin, install whatever password changing program I wish.  TheJ users can't change that and they can't circumvent it (at least not withoutH seriously hacking the system in which case the password changing programI is likely the least of your worries.)  I was merely saying that the flex- E ibility of Unix makes it fairly trivial (depending on your ability to L write code or willingness to pay someone else to do it for you) to implement1 whatever you want in a password changing program.    > H >>>> word history you wanted.  But, like most things, if no one wants it= >>>> no one is going to put forth the effort to implement it.  >>> E >>> Well, the US Government wants it.  Search for "password reuse" in  >>  D >> And yet while NSA spent all that time and research securing LinuxB >> they never even bothered doing something as trivial as password >> history.  Go figure.  > / > I did not realize you were such a Linux fan,    D I am not a Linux fan at all.  I never understood why they didn't useC one of the BSD's for their project as the code would have been more E usable in the real world as there are more serious (read proprietary) F systems that are BSD based than Linux based.  I think Linux is a totalF waste of time and effort.  But I will admit if anything needed help it
 was Linux.  H >                                               but my interpretation ofG > their Secure Linux effort was that they saw Linux security was so far ? > behind other operating systems that they had to do something.   E Well, having read all the early papers what I saw a  real interest in G showing that Unix could be secured.  Unfortunately they decided to ride F the same hype wave as the rest of the world and chose Linux instead of a real Unix.   > B >>> http://csrc.nist.gov/publications/nistpubs/800-53/SP800-53.pdf >>> H >>> FIPS 200 is scheduled to make that mandatory for all federal systemsK >>> when signed by the Secretary of Commerce later this month, implementing A >>> the 2002 Federal Information Security Management Act (FISMA).  >>  7 >> And we al know what "mandatory" means in government.  >  > " The public draft of FIPS 200 says: >  >     11. Waivers. > = >     No provision is provided under FISMA for waivers to the = >     Federal Information Processing Standards made mandatory # >     by the Secretary of Commerce.   C Like I said, we all know what "mandatory" means in government.  :-)    > J >>>> Just out of curiosity, define for me what you consider a proper pass-G >>>> word history scheme.  Maybe I'll implement it in my spare time and I >>>> release it to the world.  Then we can watch and see if anyone really  >>>> cares.  :-) >>> F >>> A proper password history scheme handles users who try to overloadM >>> the history space with some method other than minimum password lifetimes. H >>> The Microsoft approach of minimum password lifetimes leaves one openG >>> to an attack whereby a user is observed changing their password and H >>> upon discovering they were observed is unable to change the password1 >>> again until the minimum lifetime has expired.  >>  B >> How about one that let's you change your password as many timesA >> as you want whenever you want but keeps track of the last time C >> you used a cetain password and won't let you reuse it for either A >> a cetain calendar period or possibly forever.  Include in this C >> the usual variant checking.  The biggest drawback to this is the @ >> space to save all the old passwords, but that's not much of a >> drawback today. > F > Counting on the inability of a rulebreaker to mount a massive effort+ > (to include automating it) is not wise.     F Maybe I have misunderstood the problem.  We are talking about inputingG enough passwords to get us back to our favorite one, right?  If so, how . can you automate a calendar based re-use rule?    A >                                         That is the whole issue H > being discussed - how to prevent such an attack without using infiniteF > storage.  Even Microsoft understands the bit about infinite storage.  E One could include logic that after say 10,000 password changes we are F no longer dealing with a human being with a favorite password and justF start throwing all attemtps into the bit bucket.  Of course, you don'tD need infinite storage.  Long before you reach infinity you will haveE used every possible combination of the characterset and at that point % there is no valid new password.   :-)   G Sometimes (often) there is no technical solution to a social problem.      > F >> By the way, the solution to your theoretical danger above is calledC >> the sysadmin who can either change your password or allow you to ' >> change it if a threat is identified.  > C > That certainly counts on the attacker being slow to exploit their  > knowledge.  F There are no guarentees in life.  I have been taught to not let peopleH watch me change my password.  I do not watch other people change theirs,E (probably comes from my military security background, some old habits G are hard, if not impossible, to break) but I have never had anyone tell E me to look away.  I think it unlikely the scenario would arise as the H average person would not be aware that someone had shoulder-surfed their> new password until they found their account had been accessed.   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: 24 Feb 2006 21:06:58 GMT( From: bill@cs.uofs.edu (Bill Gunshannon): Subject: Re: Plain truth is that unix/linux is NOT secure!+ Message-ID: <469ariF9psoqU2@individual.net>   3 In article <UIzC9b2x6KFQ@eisner.encompasserve.org>, 0 	Kilgallen@SpamCop.net (Larry Kilgallen) writes:X > In article <4696e2Fa07h8U3@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:6 >> In article <IlcNeqU4$uOH@eisner.encompasserve.org>,A >> 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:  > < >>> And I still haven't seen the answer to Larry's question. >>  / >> Well, the only question I see of Larry's is: D >>   "How does Unix handle users attempting to overflow the password >>    history buffer ?" K >> and, being as at this point in time I am only familiar with Solaris 10's A >> system and I don't see where it does.  How does VMS handle it?  > 6 > It throws the attacker into generated password mode.  H Which accomplishes what?  It still has to tell the attacker the passwordG and I don't see where that wold stop someone from repeatedly generating F new paswordds and thus overflowing the password history buffer anyway.H Unless it then takes sysadmin intervention to turn it back off, in whichF case you have come up with a whole new way to annoy the sysadmin.  :-)   > - >> By the way, VMS passwords still mono-case.  > : > Search SYS$LIBRARY:LIB.REQ on VMS V8.2 for UAF$V_PWDMIX.  J Sorry, 8.2 doesn't run on my VAX.  And I have been repeatedly assured that9 the government is still one of the biggest VAX/VMS users.   L Remember what I said earlier about what "mandatory" means to the government.   > > > The same logic as looking at 10-years-ago Unix should apply.  F What about 10 years ago Unix?  The character set hasn't changed in allF the time I have been using Unix.  Unix passwords have always supportedG mixed-case primarily because pretty much any character except the erase E and kill character can be used in password.  The only real difference H I know of in the last 10 years is password length and sadly, most peopleB continue to leave it at 8 characters even though that is no longer necessary (or wise!)   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: Fri, 24 Feb 2006 21:50:17 +0100 + From: Karsten Nyblad <nospam@nospam.nospam> : Subject: Re: Plain truth is that unix/linux is NOT secure!= Message-ID: <43ff7185$0$78282$157c6196@dreader1.cybercity.dk>    Bob Koehler wrote:X > In article <468rr4F9nok6U2@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: > I >>That has nothing to do with wether or not Unix has a root or superviser G >>user it has to do with the design of the shell.  If it was desired by K >>Unix users the capabilty to define variables that can be seen system wide J >>could be implemented.  But the fact is, even after all these years, Unix+ >>users don't see it as anything they need.  >  > I >    On the contrary, it's something they've already been told they can't H >    have.  Of course, it was only one example of what's wrong with the H >    UNIX shell approach.  Some of the others are too closely related to1 >    security issues for me to discuss them here.  >   I Well we were only discussing the security aspects of the *nix design vs.  F the VMS design of how the command language interpreter interacts with F the user applications.  Assume you are designing a captive account on E VMS.  If your applications can set logical names or command language  F symbols, then you had better make sure that setting a symbol does not D make the script execute a malicious program in stead of what you as F programmer intended.  You also have to make sure that setting logical K names does not make it possible to access files none of the users business.   G When programming the login script of a captive account it is very easy  H to make an error such that there is a security bug.  Unix does not have H that problem because you can replace the shell with a program, and that F program can be written in a language without the many pitfalls of the  VMS command language.    ------------------------------   Date: 24 Feb 2006 22:04:45 GMT( From: bill@cs.uofs.edu (Bill Gunshannon): Subject: Re: Plain truth is that unix/linux is NOT secure!+ Message-ID: <469e7tFa07jvU1@individual.net>   3 In article <vMKrYDOaxotW@eisner.encompasserve.org>, > 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:X > In article <4696e2Fa07h8U3@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: >   - >> By the way, VMS passwords still mono-case.  > % >    Your information is out of date.   D Not information.  I am running a VAX here for the students under theF EDU program and I just tested it and it is still monocase.  As I said,G I have been told on numerous occaisions that the governement in general I and DOD in particular are still VAX/VMS users.  So, if the latest version E of VMS for the VAX does not support mixed-case passwords and there is H a mandate by various government agencies that passwords be mixed-case...> Well, I leave it to the imagination of the reader.  As I said,G "mandatory" does  not necessarily mean the same thing to the governemnt  that it means to you and me.   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: 24 Feb 2006 15:59:51 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) : Subject: Re: Plain truth is that unix/linux is NOT secure!3 Message-ID: <vMKrYDOaxotW@eisner.encompasserve.org>   V In article <4696e2Fa07h8U3@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:   . > Well, the only question I see of Larry's is:C >   "How does Unix handle users attempting to overflow the password  >    history buffer ?"J > and, being as at this point in time I am only familiar with Solaris 10's@ > system and I don't see where it does.  How does VMS handle it?  F    VMS simply forces the user into using generated passwords until theE    retention time of the oldest password expires.  Of course when the B    user discovers this he will probably plead with the nice system+    manager for relief, and NOT do it again.   , > By the way, VMS passwords still mono-case.  #    Your information is out of date.    ------------------------------    Date: 24 Feb 2006 16:05:48 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) : Subject: Re: Plain truth is that unix/linux is NOT secure!3 Message-ID: <SAFIqHFPw3u9@eisner.encompasserve.org>   k In article <43ff6aba$0$78288$157c6196@dreader1.cybercity.dk>, Karsten Nyblad <nospam@nospam.nospam> writes:  > / > That point of view does not make sense to me.   4    It fits perfectly with the argument I was making.   >  Once you use features  K > that are only present in one Unix dialect, you are have additional costs  C > when you want to move to a new platform, and of course that is a  K > problem.  Yes, *nix is primitive and outdated when you stick to what you  - > can expect to find on many *nix dialects.     D    The two mode OS is a primitive and outdated (late 1960's) design.@    I haven't even heard Andrew claim Solaris has gotten past it.   > J > To me you are making a common error:  Because the solution to a problem K > is far from perfect, you chose not to use the solution even if it may be  
 > a big help.   /    No, I don't have those problems.  I use VMS.     ? >  In this case the problem is that you want independence from  I > hardware and software vendors and because of that you want portability   > of your applications.   *    No, I want reliable and secure systems.   G > Oh. and don't tell me that you do not care about potability, because  I > then each Unix dialect is just and OS of its own right and restricting  A > your self to what is common to many Unixes does not make sense.   C    OK, I'll take "potability" as a typo.  In real life my customers C    have never ported a single UNIX application.  The last time they 3    did a port it was from IBM OS/360 to VAX-11/VMS.   B    When porting a UNIX application comes up the standard answer is     "that will be too expensive".  A    Meanwhile our VMS applications march on with no more real life F    portability issues than the UNIX applications, but with reliability-    and security that no UNIX has yet matched.    ------------------------------    Date: 24 Feb 2006 16:12:33 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) : Subject: Re: Plain truth is that unix/linux is NOT secure!3 Message-ID: <mBhdXZ9fxYFf@eisner.encompasserve.org>   k In article <43ff7185$0$78282$157c6196@dreader1.cybercity.dk>, Karsten Nyblad <nospam@nospam.nospam> writes:   I > When programming the login script of a captive account it is very easy  J > to make an error such that there is a security bug.  Unix does not have J > that problem because you can replace the shell with a program, and that H > program can be written in a language without the many pitfalls of the  > VMS command language.        You suggst maybe C?    ------------------------------    Date: 24 Feb 2006 16:15:23 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) : Subject: Re: Plain truth is that unix/linux is NOT secure!3 Message-ID: <UX4o25uBAXo5@eisner.encompasserve.org>   V In article <469acsF9psoqU1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:  H > If you can't trust the sysadmin to do what is called for by SOP or lawF > or just plain local whim, then how can oyu trust the system at all?   H    And just what great experts do you think write SOP in the real world?   ------------------------------    Date: 24 Feb 2006 16:19:26 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) : Subject: Re: Plain truth is that unix/linux is NOT secure!3 Message-ID: <UR+vJTWV7kQ6@eisner.encompasserve.org>   V In article <469ariF9psoqU2@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: > J > Which accomplishes what?  It still has to tell the attacker the passwordI > and I don't see where that wold stop someone from repeatedly generating H > new paswordds and thus overflowing the password history buffer anyway.J > Unless it then takes sysadmin intervention to turn it back off, in whichH > case you have come up with a whole new way to annoy the sysadmin.  :-)  D    1)  it prevents them from re-using a password, which is what they9       were trying to accomplish by overflowing the buffer D    2)  the hacker is now forced to guess a new password, not the one3       he read over the user's shoulder this morning H    3)  the password history buffer is no longer modified since generated5       passwords don't repeat in any usefull timeframe G    4)  it annoys the user, who then learns to behave in a more security A       conscious manner on at least this item because he has to be +       nice to the sysadmin to get out of it         ------------------------------    Date: 24 Feb 2006 16:07:09 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) : Subject: Re: Plain truth is that unix/linux is NOT secure!3 Message-ID: <3FJGzdzxKxUH@eisner.encompasserve.org>   V In article <4695j2Fa07h8U2@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: > 5 > Who told them that?  And when?  AT&T 20 yeaars ago?   +    Every "Advanced UNIX" programming class.    ------------------------------    Date: 24 Feb 2006 16:11:03 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) : Subject: Re: Plain truth is that unix/linux is NOT secure!3 Message-ID: <7pV15b3LmHZ8@eisner.encompasserve.org>   V In article <46957dFa07h8U1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: > F > If you mean an entry point in the kernel, of course not.  It's not aE > kernel function.  The password is contained in a file, you change a E > password by changing the entry in the file.  thus, there is nothing C > to stop a sysadmin from writing his own password changing program F > implementing whatever additional policies he sees fit.  It's part of, > the flexibility of the Unix paradigm.  :-)  B    And then your customer finds out you're not using a comerciallyD    supported password program.  But, of course, you claim it's good.F    And said program has to be setuid root to modify the password file.   > E > By the way, the solution to your theoretical danger above is called B > the sysadmin who can either change your password or allow you to& > change it if a threat is identified.  D    And at 2:00 in the morning the good sysadmin has the sense not toH    sleep near his phone?  24x7 support isn't justified in every location    where 24x7 security is.   ------------------------------    Date: 24 Feb 2006 16:42:04 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) : Subject: Re: Plain truth is that unix/linux is NOT secure!3 Message-ID: <7osss8Yrw1tm@eisner.encompasserve.org>   V In article <469acsF9psoqU1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:5 > In article <dV1FDCshdhts@eisner.encompasserve.org>, 2 > 	Kilgallen@SpamCop.net (Larry Kilgallen) writes:Y >> In article <46957dFa07h8U1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: 7 >>> In article <0Vlnvu2C1VEY@eisner.encompasserve.org>, 4 >>> 	Kilgallen@SpamCop.net (Larry Kilgallen) writes: >>  G >>>> So I gather no Unix has a callable entrypoint to set the password.  >>> H >>> If you mean an entry point in the kernel, of course not.  It's not aG >>> kernel function.  The password is contained in a file, you change a G >>> password by changing the entry in the file.  thus, there is nothing E >>> to stop a sysadmin from writing his own password changing program H >>> implementing whatever additional policies he sees fit.  It's part of. >>> the flexibility of the Unix paradigm.  :-) >>  G >> AU-2 of 800-53 does allow the organization the flexibility to choose K >> what is an auditable event, but expecting local password change programs J >> to do their own file access greatly increases the chance they will failJ >> to do the auditing, just as they will likely fail to honor the password >> history, etc. > H > If you can't trust the sysadmin to do what is called for by SOP or lawI > or just plain local whim, then how can oyu trust the system at all?  I,   G I _might_ be able to trust the system administrator to do what the boss 9 says, and that is most typically "get it done by date X".   8 >>> And we al know what "mandatory" means in government. >>   >>  $ > The public draft of FIPS 200 says: >>   >>     11. Waivers.  >>  > >>     No provision is provided under FISMA for waivers to the> >>     Federal Information Processing Standards made mandatory$ >>     by the Secretary of Commerce. > E > Like I said, we all know what "mandatory" means in government.  :-)   J The exceptions to the former (DoD-only) Ada mandate were called "waivers".C They were allowed throughout the life of the Ada mandate.  Congress D has seemingly seen the folly of mandates that can be waived, and set up tighter rules for FISMA.   G >> Counting on the inability of a rulebreaker to mount a massive effort , >> (to include automating it) is not wise.   > H > Maybe I have misunderstood the problem.  We are talking about inputingI > enough passwords to get us back to our favorite one, right?  If so, how 0 > can you automate a calendar based re-use rule?  A We are talking about making enough changes to exhaust intolerable ? amounts of space.  That is not just measured by disk space, but 6 also by processing requirements for such a large file.  B >>                                         That is the whole issueI >> being discussed - how to prevent such an attack without using infinite G >> storage.  Even Microsoft understands the bit about infinite storage.  > G > One could include logic that after say 10,000 password changes we are H > no longer dealing with a human being with a favorite password and just2 > start throwing all attemtps into the bit bucket.  E That is exactly it.  How do you "throw attempts into the bit bucket". C What is the remaining password on the username?  How do you prevent E the over-the-shoulder attack discussed earlier in this circumstance ?    ------------------------------    Date: 24 Feb 2006 17:45:00 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) : Subject: Re: Plain truth is that unix/linux is NOT secure!3 Message-ID: <ES+q6JdxYSek@eisner.encompasserve.org>   V In article <469ariF9psoqU2@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:5 > In article <UIzC9b2x6KFQ@eisner.encompasserve.org>, 2 > 	Kilgallen@SpamCop.net (Larry Kilgallen) writes:Y >> In article <4696e2Fa07h8U3@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: 7 >>> In article <IlcNeqU4$uOH@eisner.encompasserve.org>, B >>> 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: >>  = >>>> And I still haven't seen the answer to Larry's question.  >>> 0 >>> Well, the only question I see of Larry's is:E >>>   "How does Unix handle users attempting to overflow the password  >>>    history buffer ?"L >>> and, being as at this point in time I am only familiar with Solaris 10'sB >>> system and I don't see where it does.  How does VMS handle it? >>  7 >> It throws the attacker into generated password mode.  > J > Which accomplishes what?  It still has to tell the attacker the passwordI > and I don't see where that wold stop someone from repeatedly generating H > new paswordds and thus overflowing the password history buffer anyway.  6 Generated passwords do not go into the history buffer.D The purpose the attackers see in this case is to get a password they* "like".  They will never get one that way.   ------------------------------   Date: 25 Feb 2006 01:12:56 GMT( From: bill@cs.uofs.edu (Bill Gunshannon): Subject: Re: Plain truth is that unix/linux is NOT secure!+ Message-ID: <469p8oFa5varU1@individual.net>   3 In article <3FJGzdzxKxUH@eisner.encompasserve.org>, > 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:X > In article <4695j2Fa07h8U2@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: >>  6 >> Who told them that?  And when?  AT&T 20 yeaars ago? > - >    Every "Advanced UNIX" programming class.   D The only "Advanced UNIX" classes I ever saw were those $1000 not forD credit things run at the local convention center.  They are constantC proof that "you get what you pay for" isn't now and never was true.   E If there had been a desire for that kind of functionality at the time = I have no doubt the CSRG could have written a shell to do it.    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: 25 Feb 2006 01:15:34 GMT( From: bill@cs.uofs.edu (Bill Gunshannon): Subject: Re: Plain truth is that unix/linux is NOT secure!+ Message-ID: <469pdmFa5varU2@individual.net>   3 In article <7osss8Yrw1tm@eisner.encompasserve.org>, 0 	Kilgallen@SpamCop.net (Larry Kilgallen) writes: > E >                                                  How do you prevent G > the over-the-shoulder attack discussed earlier in this circumstance ?   C That is a social problem and there is no technical solution for it.  But then, I already said that.   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: 25 Feb 2006 01:23:44 GMT( From: bill@cs.uofs.edu (Bill Gunshannon): Subject: Re: Plain truth is that unix/linux is NOT secure!+ Message-ID: <469pt0Fa5varU3@individual.net>   3 In article <7pV15b3LmHZ8@eisner.encompasserve.org>, > 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:X > In article <46957dFa07h8U1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: >>  G >> If you mean an entry point in the kernel, of course not.  It's not a F >> kernel function.  The password is contained in a file, you change aF >> password by changing the entry in the file.  thus, there is nothingD >> to stop a sysadmin from writing his own password changing programG >> implementing whatever additional policies he sees fit.  It's part of - >> the flexibility of the Unix paradigm.  :-)  > D >    And then your customer finds out you're not using a comerciallyF >    supported password program.  But, of course, you claim it's good.H >    And said program has to be setuid root to modify the password file.  E I see I can't win this one, you want it both ways.  You say there has G to be certain standards for the password changing program but you can't D write a program to do it.  Using your methods of making VMS come outC on top reminds me of the procurement I once helped bid on where the D head of the buying organization said; "I don't really care which oneG wins the bid as long as it says VAX on the front."  Those of us bidding F other (much better) systems just withdrew. Hmmm....  Maybe what I need# to do is make my systems print out: C       "Welcome to The OpenVMS (TM) Operating System, Version V7.3 "  when people try to login.  :-)   >  >>  F >> By the way, the solution to your theoretical danger above is calledC >> the sysadmin who can either change your password or allow you to ' >> change it if a threat is identified.  > F >    And at 2:00 in the morning the good sysadmin has the sense not toJ >    sleep near his phone?  24x7 support isn't justified in every location >    where 24x7 security is.    Social problem, not technical.      F You can obviously change the rules faster than I can challenge them so% this is no win situation.  I give up.    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: 24 Feb 2006 19:28:21 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) : Subject: Re: Plain truth is that unix/linux is NOT secure!3 Message-ID: <95pUgxn4rvgy@eisner.encompasserve.org>   V In article <469pt0Fa5varU3@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:5 > In article <7pV15b3LmHZ8@eisner.encompasserve.org>, @ > 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:Y >> In article <46957dFa07h8U1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:   G >>> By the way, the solution to your theoretical danger above is called D >>> the sysadmin who can either change your password or allow you to( >>> change it if a threat is identified. >>  G >>    And at 2:00 in the morning the good sysadmin has the sense not to K >>    sleep near his phone?  24x7 support isn't justified in every location  >>    where 24x7 security is.  > " > Social problem, not technical.    D The technical problem is those password history mechanisms that relyE upon a minimum password lifetime.  There is no such problem with VMS.    ------------------------------   Date: 25 Feb 2006 01:35:10 GMT( From: bill@cs.uofs.edu (Bill Gunshannon): Subject: Re: Plain truth is that unix/linux is NOT secure!+ Message-ID: <469qieFa5varU4@individual.net>   3 In article <95pUgxn4rvgy@eisner.encompasserve.org>, 0 	Kilgallen@SpamCop.net (Larry Kilgallen) writes:X > In article <469pt0Fa5varU3@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:6 >> In article <7pV15b3LmHZ8@eisner.encompasserve.org>,A >> 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: Z >>> In article <46957dFa07h8U1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: > H >>>> By the way, the solution to your theoretical danger above is calledE >>>> the sysadmin who can either change your password or allow you to ) >>>> change it if a threat is identified.  >>> H >>>    And at 2:00 in the morning the good sysadmin has the sense not toL >>>    sleep near his phone?  24x7 support isn't justified in every location >>>    where 24x7 security is. >>  # >> Social problem, not technical.    > F > The technical problem is those password history mechanisms that relyG > upon a minimum password lifetime.  There is no such problem with VMS.   B All the password history in the world won't stop shoulder-surfing.  J By the way, that reminds me.  For those who are so in love with terminals,C we used to have a lot of problems in the terminal rooms (VT100's on F DECServers) with students leaving behind programs that faked the loginD prompts with a failed attempt each time thus capturing the passwordsB of other unsuspecting istudents who would never notice the lack ofC "failed login" notices when they finally got on.  What was that you 2 said about no way to hack into a VMS machine?  :-)   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: 24 Feb 2006 20:50:00 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) : Subject: Re: Plain truth is that unix/linux is NOT secure!3 Message-ID: <K8L7na+jDmJg@eisner.encompasserve.org>   V In article <469qieFa5varU4@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:  L > By the way, that reminds me.  For those who are so in love with terminals,E > we used to have a lot of problems in the terminal rooms (VT100's on H > DECServers) with students leaving behind programs that faked the loginF > prompts with a failed attempt each time thus capturing the passwordsD > of other unsuspecting istudents who would never notice the lack ofE > "failed login" notices when they finally got on.  What was that you 4 > said about no way to hack into a VMS machine?  :-)  7 Control SC-11 of NIST 800-53 calls that "Trusted Path".   C The corresponding VMS feature is called "Secure Server", and it has " been available since VAX/VMS V4.4.   ------------------------------   Date: 25 Feb 2006 03:04:20 GMT( From: bill@cs.uofs.edu (Bill Gunshannon): Subject: Re: Plain truth is that unix/linux is NOT secure!+ Message-ID: <469vpkFa1723U1@individual.net>   3 In article <K8L7na+jDmJg@eisner.encompasserve.org>, 0 	Kilgallen@SpamCop.net (Larry Kilgallen) writes:X > In article <469qieFa5varU4@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: > M >> By the way, that reminds me.  For those who are so in love with terminals, F >> we used to have a lot of problems in the terminal rooms (VT100's onI >> DECServers) with students leaving behind programs that faked the login G >> prompts with a failed attempt each time thus capturing the passwords E >> of other unsuspecting istudents who would never notice the lack of F >> "failed login" notices when they finally got on.  What was that you5 >> said about no way to hack into a VMS machine?  :-)  > 9 > Control SC-11 of NIST 800-53 calls that "Trusted Path".  > E > The corresponding VMS feature is called "Secure Server", and it has $ > been available since VAX/VMS V4.4.  C And how would it stop a stupid user from typing into a program left B running that faked all the right prompts?  Is it psychic?  All the> new user has to do is force a disconect so that he knows he isC talking to the real DECServer but we are talking typical dumb users @ who have no idea how any of it works and thus are easily fooled.C Short of haveing real short inactivity timeouts (some places do not B allow inactivity timeouts at all as policy) how do you prevent it?   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: 24 Feb 2006 21:21:04 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) : Subject: Re: Plain truth is that unix/linux is NOT secure!3 Message-ID: <uF$YuV9hBmjr@eisner.encompasserve.org>   V In article <469vpkFa1723U1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:5 > In article <K8L7na+jDmJg@eisner.encompasserve.org>, 2 > 	Kilgallen@SpamCop.net (Larry Kilgallen) writes:Y >> In article <469qieFa5varU4@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:  >>  N >>> By the way, that reminds me.  For those who are so in love with terminals,G >>> we used to have a lot of problems in the terminal rooms (VT100's on J >>> DECServers) with students leaving behind programs that faked the loginH >>> prompts with a failed attempt each time thus capturing the passwordsF >>> of other unsuspecting istudents who would never notice the lack ofG >>> "failed login" notices when they finally got on.  What was that you 6 >>> said about no way to hack into a VMS machine?  :-) >>  : >> Control SC-11 of NIST 800-53 calls that "Trusted Path". >>  F >> The corresponding VMS feature is called "Secure Server", and it has% >> been available since VAX/VMS V4.4.  > E > And how would it stop a stupid user from typing into a program left + > running that faked all the right prompts?   K The users are trained that the _only_ way to login is to hit the Break key. G So long as that is the only way they have ever been able to get a login F prompt (and carriage-return does not work), users adapt quite well and> are not tempted to do anything other than hit break to log in.   ------------------------------   Date: 25 Feb 2006 04:52:30 GMT( From: bill@cs.uofs.edu (Bill Gunshannon): Subject: Re: Plain truth is that unix/linux is NOT secure!+ Message-ID: <46a64eF9qlvkU1@individual.net>   3 In article <uF$YuV9hBmjr@eisner.encompasserve.org>, 0 	Kilgallen@SpamCop.net (Larry Kilgallen) writes:X > In article <469vpkFa1723U1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:6 >> In article <K8L7na+jDmJg@eisner.encompasserve.org>,3 >> 	Kilgallen@SpamCop.net (Larry Kilgallen) writes: Z >>> In article <469qieFa5varU4@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: >>> O >>>> By the way, that reminds me.  For those who are so in love with terminals, H >>>> we used to have a lot of problems in the terminal rooms (VT100's onK >>>> DECServers) with students leaving behind programs that faked the login I >>>> prompts with a failed attempt each time thus capturing the passwords G >>>> of other unsuspecting istudents who would never notice the lack of H >>>> "failed login" notices when they finally got on.  What was that you7 >>>> said about no way to hack into a VMS machine?  :-)  >>> ; >>> Control SC-11 of NIST 800-53 calls that "Trusted Path".  >>> G >>> The corresponding VMS feature is called "Secure Server", and it has & >>> been available since VAX/VMS V4.4. >>  F >> And how would it stop a stupid user from typing into a program left, >> running that faked all the right prompts? > M > The users are trained that the _only_ way to login is to hit the Break key.   6 Users!  Trained!!!  Hahahahahahahahahahaha............  I > So long as that is the only way they have ever been able to get a login H > prompt (and carriage-return does not work), users adapt quite well and@ > are not tempted to do anything other than hit break to log in.  I Hydrogen is not the most plentiful element in the universe, stupidity is.    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: Fri, 24 Feb 2006 21:52:53 -0500 2 From: "Stanley F. Quayle" <squayle@insight.rr.com>, Subject: Re: question about VMS732_LMF-V0200. Message-ID: <43FF8035.5774.100130AB@localhost>  = On 24 Feb 2006 at 18:22, Phillip Helbig---remove CLOTH wrote: F > By the way, has it been decided yet whether 7.3 will remain the last > version of VMS for VAX?   B It was decided some time ago that 7.3 is the last VAX version.  I  suspect that decision is final.   
 --Stan Quayle  Quayle Consulting Inc.  
 ----------8 Stanley F. Quayle, P.E. N8SQ  Toll free: 1-888-I-LUV-VAX3 8572 North Spring Ct., Pickerington, OH  43147  USA 0 stan-at-stanq-dot-com       http://www.stanq.com) "OpenVMS, when downtime is not an option"    ------------------------------  % Date: Fri, 24 Feb 2006 14:35:25 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 5 Subject: Re: Rich Marcello in VMS mention shocker :-) , Message-ID: <43FF5FFB.1F295ADF@teksavvy.com>   bob@instantwhip.com wrote: > I > vms should be a huge growth market for them, but it is being mismanaged ' > either on purpose or by stupidity ...   G If Marcello says that VMS is not a growth potential, then it is a given G that HP will not lift a finger to make it grow. And when the time comes B to make staff cuts, guess where they come from ? Non growth areas.  9 I am quite fearful that VMS may follow in MPEs footsteps.    ------------------------------  % Date: Fri, 24 Feb 2006 22:07:06 +0100 + From: Karsten Nyblad <nospam@nospam.nospam> 5 Subject: Re: Rich Marcello in VMS mention shocker :-) = Message-ID: <43ff7576$0$67264$157c6196@dreader2.cybercity.dk>    JF Mezei wrote:  > bob@instantwhip.com wrote: > I >>vms should be a huge growth market for them, but it is being mismanaged ' >>either on purpose or by stupidity ...  >  > I > If Marcello says that VMS is not a growth potential, then it is a given I > that HP will not lift a finger to make it grow. And when the time comes D > to make staff cuts, guess where they come from ? Non growth areas. > ; > I am quite fearful that VMS may follow in MPEs footsteps.   F You cannot conclude that from what he said.  I doubt they will try to I make VMS grow, but as I read the statements, Marcello intend to continue  E to make money on VMS by selling machines at high prices, and that he  I expects to be capable of doing that for a long period of time.  Thus, HP  F will be happy to sell you VMS products in the foreseeable future, but I you had better assume that the platform will continue to be as expensive   as it is today.    ------------------------------    Date: 24 Feb 2006 20:44:39 -0600+ From: young_r@encompasserve.org (Rob Young) 5 Subject: Re: Rich Marcello in VMS mention shocker :-) 3 Message-ID: <J8rm+rQ5o86P@eisner.encompasserve.org>   \ In article <43FF5FFB.1F295ADF@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes: > bob@instantwhip.com wrote: >>  J >> vms should be a huge growth market for them, but it is being mismanaged( >> either on purpose or by stupidity ... > I > If Marcello says that VMS is not a growth potential, then it is a given I > that HP will not lift a finger to make it grow. And when the time comes D > to make staff cuts, guess where they come from ? Non growth areas. > ; > I am quite fearful that VMS may follow in MPEs footsteps.   # 	Towards death?  Not murder, right?   R http://groups.google.com/group/comp.os.vms/msg/d44241b7929c670e?dmode=source&hl=en  < 	Come on purse your lips... give us a "death of VMS."   JustN         for old times sake.   The good old days of "VMS death", ah... I harken
         back:   M =============================================================================   5 From: mezei...@eisner.decus.org (Jean-Francois Mezei)  Date: 1996/02/044 customers who were already fearing the death of VMS.  M =============================================================================   - From: JF Mezei <jfmezei.spam...@videotron.ca> % Date: Thu, 19 Jul 2001 10:17:04 -0400   K  current VMS customers would know that VMS's death was impending and switch  vendors   M =============================================================================   - From: JF Mezei <jfmezei.spam...@videotron.ca> % Date: Fri, 17 May 2002 05:01:22 -0400   M VMS's death has been predicted by many, including Palmer et all, and Gartner,  for a long long time.     3 [ Can't resist - isn't this Generallisimo Francisco 2 Franco all over again?  I mean talk about deja vu:  I The death of Spanish dictator Francisco Franco during the first season of J Saturday Night Live in 1975 served as the source of one of the first catch. phrases from SNL to enter the general lexicon.  L Franco lingered near death for weeks before dying. On slow news days, UnitedL States network television news casters sometimes noted that Franco was stillL alive, or not yet dead. The imminent death of Franco was a headline story onE the NBC news for a number of weeks prior to his death on November 20.   <         VMS - The Generallisimo Francisco Franco of OSes!  ]  M =============================================================================   - From: JF Mezei <jfmezei.spam...@videotron.ca> % Date: Thu, 22 Nov 2001 11:40:07 -0500   N Since it is pretty well a known fact that Compaq or HP will eventually annouce the death of VMS,   M =============================================================================   0 From: JF Mezei <jfmezei.spam...@vl.videotron.ca> Date: 2000/03/12  K to newsgroups and continue to complain that Compaq is not doing anything to " help VMS escape its death warrant.  M =============================================================================   1 From: jf mezei <"[non-spam]jfmezei"@videotron.ca>  Date: 1997/08/20  D (even if DEC doesn't make much money on them) would go a long way to) kill the rumour of VMS's impending death.   N =============================================================================   > 	[Need I say: etc. etc.?  There is a virtual treasure trove ofH         "JF death on VMS" favs - come on kids, join the fun!  Or act nowF         and send $9.95 and I'll rush you my top 20 , "JF death on VMS"%         You'll laugh, you'll cry... ]   C         I actually prefer the "impendendings" and the creativity of C         "death warrant."  Each with their own flavor of weightiness F         (as if death itself isn't a weighty subject.)  But with "deathE         warrant" you almost visualize that leftist favorite "Dead Man G         Walking" and the touching acting by Penn/Sarandon, et al.  Talk          about weight!   $                                 Rob    ------------------------------  % Date: Fri, 24 Feb 2006 22:03:09 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 5 Subject: Re: Rich Marcello in VMS mention shocker :-) , Message-ID: <43FFC8DD.9DF9D697@teksavvy.com>   Rob Young wrote:E >         Come on purse your lips... give us a "death of VMS."   Just P >         for old times sake.   The good old days of "VMS death", ah... I harken >         back:       G You may have quotes stuff from archives out of context, and some text I G don't ever recall ever having typed. But guess what is more important :   " JF ramblings and interpretations ?   OR    E Rich Marcello announcing that HP doesn't see any growth potential for 9 VMS and is only keeping it for remaining installed base ?       D Rich Marcello's statement is authoritative of HP policies, just likeB Stallard stating that HP expected VMS customer to migrate to HP-UXA (later changed to HP helping VMS customers who want to migrate to E HP-UX), or Winkler's "Windows will eviscerate the underbelly... "????     E When HP officially annoucnes it sees no growth potential for VMS, and E when information was recently let out that the installed bas had been C "consolidated" from 400k down to 300k systems,  guess what the bean - counters at HP will start calculating ???????    ------------------------------  % Date: Fri, 24 Feb 2006 23:03:05 -0500 * From: "FredK" <fred.nospam@nospam.dec.com>5 Subject: Re: Rich Marcello in VMS mention shocker :-) * Message-ID: <43ffd6fa@usenet01.boi.hp.com>  : "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message& news:43FFC8DD.9DF9D697@teksavvy.com... > Rob Young wrote:G > >         Come on purse your lips... give us a "death of VMS."   Just K > >         for old times sake.   The good old days of "VMS death", ah... I  harken > >         back:  >  >  > I > You may have quotes stuff from archives out of context, and some text I I > don't ever recall ever having typed. But guess what is more important :  > $ > JF ramblings and interpretations ? >   	 Vote now.    Wait.  Was this rhetorical?    ------------------------------    Date: 24 Feb 2006 20:54:57 -0800$ From: "AEF" <spamsink2001@yahoo.com>5 Subject: Re: Rich Marcello in VMS mention shocker :-) C Message-ID: <1140843297.304419.112720@i39g2000cwa.googlegroups.com>    JF Mezei wrote:  > bob@instantwhip.com wrote: > > K > > vms should be a huge growth market for them, but it is being mismanaged ) > > either on purpose or by stupidity ...  > I > If Marcello says that VMS is not a growth potential, then it is a given I > that HP will not lift a finger to make it grow. And when the time comes D > to make staff cuts, guess where they come from ? Non growth areas. > ; > I am quite fearful that VMS may follow in MPEs footsteps.     - Uh, let's look at that quote again, shall we?   : "And we think that we will now begin to start selling moreD Superdome-class boxes running OpenVMS now, too," says Marcello. "ButF don't get me wrong. This is not a huge growth business for us, but the@ people who are on OpenVMS pretty much want to be there forever."  D He said "this is not a HUGE [my emphasis] growth business for us..."  D Did you see that? HUGE. The meaning is quite different if you removeD the HUGE like you did in your paraphrase. And he explicitly opens byD saying that they expect to start selling more boxes running OpenVMS.F GROWTH IS EXPECTED [my emphasis]. Not being huge combined with sellingD more means small or medium growth, not impending doom. I'll take it!  B No, this isn't our dream come true of HP going full swing with VMSC marketing and such, but it isn't disaster either. Management didn't A pull the plug on VMS as it shrank over the years; therefore, this E expected growth, all other things being equal, is a plus, not a cause  for gloom and doom.   A Not only that, even a HUGE growth market has to level off at some B point. Not everything a company sells can be part of a HUGE growth8 market. Modest growth is not a reason to kill a product.   AEF    ------------------------------  % Date: Fri, 24 Feb 2006 14:52:50 -0500 C From: "David Turner, Island Computers US Corp" <dbturner@icusc.com> ; Subject: Re: Rocky Mountain Local Users Group March Meeting 9 Message-ID: <YlJLf.36998$X7.10086@bignews7.bellsouth.net>   > I heard they'll be serving Rocky Montain Oysters at luncheon !   ;0)    --     David B Turner Island Computers US Corp 2700 Gregory St, Suite 180 Savannah GA 31404  Tel: 912 447 6622 X201 Cell: 912 447 6622 X252  Fax: 912 201 0402  Email: dbturner@icusc.com  Web: http://www.islandco.com% ===================================== < All orders are subject to the following terms and conditions. of sale. These should be read before ordering.% http://www.islandco.com/warranty.html   ( <lmcgaughey@parsec.com> wrote in message< news:1140801095.861203.57340@u72g2000cwu.googlegroups.com... > Greetings! > I > PARSEC Group would like to invite you to the next meeting for the Rocky H > Mountain Local Users Group (RMLUG) here at our NEW offices in downtown	 > Denver.  > F > RMLUG exists for the VMS community to have a chance to come togetherG > and discuss issues, as well as to advance the platform. Whatever your C > level of experience, it is our hope that this group will help you + > learn, grow, and network with each other.  >  > When: Thursday, March 9, 2006  > H > Where: PARSEC Group, 999 18th Street, Suite 1725 (in the North Tower), > Denver, CO 80202 >  > Time: 6:30 p.m. - 8:30 p.m.  > F > RSVP: Please let us know to expect you by calling Laura McGaughey atH > 720-962-9583 or by emailing her at lmcgaughey@parsec.com no later than > noon on Friday, March 3. > D > Snacks will be served and we will be discussing the recent OpenVMSD > Ambassadors meeting in Nashua, NH, as well as the Integrity Server% > Users Conference in Richardson, TX.  > % > We look forward to seeing you here!  >  > PARSEC Group > 888-4-PARSEC > 999 18th Street, Suite 1725  > Denver, CO 80202 > www.parsec.com > www.openvmsplanet.org  >    ------------------------------  % Date: Sat, 25 Feb 2006 00:20:55 -0500 2 From: "Timothy Stark" <fsword7_nospam@comcast.net>  Subject: SYS and EXE file specs?: Message-ID: <ztednaNVQdutdGLenZ2dnUVZ_sKdnZ2d@comcast.com>   Hello folks,  M Does anyone know about SYS and EXE file specs for programming (compilers and  C loader, etc)?  Which OpenVMS manuals that provides information for   programmig?   K About SYS files, I reviewed a few dumps of SYS files on OpenVMS system.  I  K noticed that each SYS files hold first 512 bytes for header section before  G starting binary image (rest of files).  Each SYS files are almost same  B execpt a few bytes difference in both VAX and Alpha binary format.  M About EXE files, Alpha and VAX has very different header formats (1024-bytes  ; header) execpt system files like VMB.EXE (no headers), etc.    Thanks!  Tim    ------------------------------    Date: 24 Feb 2006 23:43:53 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) $ Subject: Re: SYS and EXE file specs?3 Message-ID: <LSZW8qwiIaVf@eisner.encompasserve.org>   o In article <ztednaNVQdutdGLenZ2dnUVZ_sKdnZ2d@comcast.com>, "Timothy Stark" <fsword7_nospam@comcast.net> writes:  > Hello folks, > O > Does anyone know about SYS and EXE file specs for programming (compilers and  E > loader, etc)?  Which OpenVMS manuals that provides information for  
 > programmig?   C The .EXE format is not in the documentation.  You might learn a bit C from the Internals and Data Structures book in combination with the  source listings kit.  F There is no format for .SYS files -- each one has a different purpose., The same resources might tell you something.   ------------------------------  % Date: Fri, 24 Feb 2006 16:06:17 -0600 2 From: David J Dachtera <djesys.nospam@comcast.net>6 Subject: Re: What is going on with VAX prices on ebay?+ Message-ID: <43FF8359.FCA6D22E@comcast.net>    Mike wrote:  > 7 > David J Dachtera <djesys.nospam@comcast.net> wrote in % > news:43FA902C.8C74A6ED@comcast.net:  >  > > Mike wrote:  > >>D > >> tomarsin2015@comcast.net wrote in news:1140228322.379320.224610# > >> @g47g2000cwa.googlegroups.com:  > >>< > >> > Most of the VAXes on ebay (for now) are being sold byI > >> > companies. A couple of weeks ago there was a 3100 SPX that started H > >> > out at 9.95. I had a 3100-85 that I just sold for 300.00 but thenH > >> > it was loaded 3 Seagate 18gb drives, a dds-3 tape drive and a ton > >> > of software. phill  > >> > > >>> > >> So, should I put my MVII Worldbox with ka655 CPU on ebay? > >  > > Isn't that a MVIII?  > >  > I > No/Yes.  The BA123 is a MVII box; the KA650 is a MVIII CPU... whatever. 
 > Want it?  G Dunno. Contact me off the list with the electrical spec.'s off the back F of the machine. I was thinking about spinning up a MicroVAX-3100, even1 though I don't really do much with VAXes anymore.   - How to demung the reply-to should be obvious.    --   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/   ------------------------------    Date: 24 Feb 2006 21:15:48 -0800$ From: "as400" <vin42and99@yahoo.com>/ Subject: Whats MORE Secure? OpenVMS or OpenBSD? B Message-ID: <1140844548.307730.87790@e56g2000cwe.googlegroups.com>  E I really thought that the UNIX-like OS called OpenBSD www.openbsd.org C was the most secure unix-like operating system in the world....And,  maybe even the MacOS-X also...  E Can someone here please provide me on what makes OpenVMS so secure? I G know that OpenBSD by dfault comes very secure by default out of the box D with alot of system services being disabled....But I dont know aboutF what makes OpenVMS unhackable....Please explain the difference between' OpenVMS, OpenBSD, or even the MACOSX???   8 I though the MOST secure OS would be like this in order:   1. Mac-OS-X   
 2. OpenBSD  A OpenVMS???? Well.....I dont know about this...Care to explain how 
 secure it is?    ------------------------------    Date: 24 Feb 2006 23:41:26 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) 3 Subject: Re: Whats MORE Secure? OpenVMS or OpenBSD? 3 Message-ID: <+xNT2PgChO3C@eisner.encompasserve.org>   i In article <1140844548.307730.87790@e56g2000cwe.googlegroups.com>, "as400" <vin42and99@yahoo.com> writes:   G > I really thought that the UNIX-like OS called OpenBSD www.openbsd.org @ > was the most secure unix-like operating system in the world...   Perhaps it is.  G > Can someone here please provide me on what makes OpenVMS so secure? I   E It is hard to get into details without information regarding how much  you know about VMS.   I > know that OpenBSD by dfault comes very secure by default out of the box F > with alot of system services being disabled....But I dont know aboutH > what makes OpenVMS unhackable....Please explain the difference between) > OpenVMS, OpenBSD, or even the MACOSX???   > At the simplest level, OpenBSD and MacOS-X are both Unix-style operating systems.  VMS is not.   : > I though the MOST secure OS would be like this in order: > 
 > 1. Mac-OS-X  >  > 2. OpenBSD > C > OpenVMS???? Well.....I dont know about this...Care to explain how  > secure it is?   D The fact that you omit MVS and OS400 from this list of possibilitiesE makes me think you have not looked very far.  Certainly both of those ; going to be more secure than a Unix-style operating system.    ------------------------------   End of INFO-VAX 2006.111 ************************