Sciences on Moon

[Methem]

(Sorry for hijacking your beautiful science thread for this sort of stuff, folks. )

Originally Posted by VAXman

I have EMACS on my Powerbook configured in EDT mode. I know simple commands in VI but it's really annoying to trip in and out of escape mode.

Vi isn't my cup of tea either. I use Emacs on my Linux box. I don't claim to be any sort of guru with it though -- far from it.

I've used TECO, SUMSLP, SOS, EDLINE and EDT on VMS. EDT is the most powerful editor. EVE/TPU I use when there's certain needs but mostly, I only use TPU if I need to write a text processing module.

Can't much comment on the merits of each of those, as I don't really know too much about VMS at this point. So far I've been reading about it and mainly using the machines of the Deathrow cluster to experiment with things. Going the Hobbyist route is of course a consideration and has been for quite a long while now.

The first time I've used VMS was a few years ago when I was doing some summer work in steel industry. The place was a cold-rolling mill, and it was a large annealing and pickling line that processed stainless steel strip. There was an oldish Alpha box with, I think, VMS 6.x installed on it. The box provided some mathematical models and calculations for the the general automation system that controlled the production line. Among other things, the box was used to adjust the temperatures in the large annealing furnace that processed the strip. Now, that was a safe place to experiment with the OS.


-Methem

[VAXman(Admin)]

Originally Posted by Methem

(Sorry for hijacking your beautiful science thread for this sort of stuff, folks. )


Vi isn't my cup of tea either. I use Emacs on my Linux box. I don't claim to be any sort of guru with it though -- far from it.

Like I said, I can get around in VI... not every unix box is going to have EMACS installed so best to know some rudimentary VI skills.

Originally Posted by Methem

Can't much comment on the merits of each of those, as I don't really know too much about VMS at this point. So far I've been reading about it and mainly using the machines of the Deathrow cluster to experiment with things. Going the Hobbyist route is of course a consideration and has been for quite a long while now.

TECO was available on the PDP OSs but when VMS first hit the streets, it didn't have TECO. When customers asked why their favorite editor was not included, DEC responded, "TECO is not an editor, it's a programming language". I think Andy Goldstein ported TECO from RSM-11(M+) to VMS as he was one of its avid users. It's written in Macro-11(VAX assembly). TECO is still available on VMS today and building it is one of the regression tests used to guage the Macro-11 "compilers" now available on Alpha and the Itanium.

Originally Posted by Methem

The first time I've used VMS was a few years ago when I was doing some summer work in steel industry. The place was a cold-rolling mill, and it was a large annealing and pickling line that processed stainless steel strip. There was an oldish Alpha box with, I think, VMS 6.x installed on it. The box provided some mathematical models and calculations for the the general automation system that controlled the production line. Among other things, the box was used to adjust the temperatures in the large annealing furnace that processed the strip. Now, that was a safe place to experiment with the OS.

VMS is found in many production scenarios. When and where it absolutley has to run, you're likely to find VMS.

The US Postal service uses VMS to sort and route all mail (letters, packages, flats). The USPS sorts/routes 40K times the volume of all of the other package handling services in the US daily... that's a lot of mail!

...and you wouldn't have the PeeCee either. Intel runs all of its fabs on VMS. They can't afford downtime. Even a few minutes of downtime costs $millions to Intel.

..and until recently, Micro$oft themselves ran all of the accounting for the firm on VMS. Seems even M$ didn't trust their own product when and where it mattered to them most -- the money! Only when a certain application provider HQed in .DE was able to provide a redundancy option in its app -- no longer requiring VMS to protect it -- did M$ get off of VMS. Rumor has it that it's still there for backup.

I guess I needn't mention it is secure. Here's SANS' latest list of security vulnerabilities. Note what is NOT on their list.

[Methem]

Originally Posted by VAXman

VMS is found in many production scenarios. When and where it absolutley has to run, you're likely to find VMS.

The factory I was working for also had some older Tandem systems (CLX); the platform nowadays known as NonStop, of course.

I guess I needn't mention it is secure. Here's SANS' latest list of security vulnerabilities. Note what is NOT on their list.

However, like many other VMS advocates, you fail to mention one thing: VMS isn't as popular as MS Windows or Unixes. If it were real widely used (after all, it once was), it would be inevitable for it to have vulnerabilities found at least once in a while.


-Methem

[VAXman(Admin)]

Originally Posted by Methem

The factory I was working for also had some older Tandem systems (CLX); the platform nowadays known as NonStop, of course.

Yup.

Originally Posted by Methem

However, like many other VMS advocates, you fail to mention one thing: VMS isn't as popular as MS Windows or Unixes. If it were real widely used (after all, it once was), it would be inevitable for it to have vulnerabilities found at least once in a while.

The bandwagoneering argument has never been correlated. If a hacker really wanted to make an impact, I'd think somewhere where it made a large impact would be targetted -- not mom's recipe files on her Weendoze PeeCee.

Buffer overruns executing arbitrary code? Impossible on VMS. Code and data have always been segregated. Pages in memory have protections that protect inner (privileged) modes from executing code -- malicious or otherwise. The whole "privilege" paradigm in VMS extends to all objects -- processes/jobs, memory, disk, images, etc. The image activator, once an image has been activated, keeps the code sections in mapped virtual pages that are read only. Any attempt to do/use a data overrun (one of the major mechanisms employed to breach other systems) would yield an Access Violation when it tried to write in a code region. IF it would only over write data in a process's image data space, it could NEVER be executed even if written there.

Now, if somebody wants to download malicious code from a sight, install it with privies and subsequently execute it, that will be a problem. However, it is not a security issue in the OS; that is a security issue with the idiot that installed the malicious code.

VMS development is a process. Code is reviewed by others in the group. Data integrity and security are the chief criteria for the code review. Feature parity is way down on the list. Features are not introduced if they sacrifice the aforementioned.

I could ramble on for hours. There are OS constructs that do not exist in any other OS. They are there for a reason -- data integrity and security. These things were designed into the OS from the get-go; not layered on as an after thought. If the foundation of flawed and weak, no amount of plastered on after thought security is going to prevent a breach.

[Methem]

Originally Posted by VAXman

The bandwagoneering argument has never been correlated. If a hacker really wanted to make an impact, I'd think somewhere where it made a large impact would be targetted -- not mom's recipe files on her Weendoze PeeCee.

Buffer overruns executing arbitrary code? Impossible on VMS. Code and data have always been segregated. Pages in memory have protections that protect inner (privileged) modes from executing code -- malicious or otherwise. The whole "privilege" paradigm in VMS extends to all objects -- processes/jobs, memory, disk, images, etc. The image activator, once an image has been activated, keeps the code sections in mapped virtual pages that are read only. Any attempt to do/use a data overrun (one of the major mechanisms employed to breach other systems) would yield an Access Violation when it tried to write in a code region. IF it would only over write data in a process's image data space, it could NEVER be executed even if written there.

Now, if somebody wants to download malicious code from a sight, install it with privies and subsequently execute it, that will be a problem. However, it is not a security issue in the OS; that is a security issue with the idiot that installed the malicious code.

VMS development is a process. Code is reviewed by others in the group. Data integrity and security are the chief criteria for the code review. Feature parity is way down on the list. Features are not introduced if they sacrifice the aforementioned.

I could ramble on for hours. There are OS constructs that do not exist in any other OS. They are there for a reason -- data integrity and security. These things were designed into the OS from the get-go; not layered on as an after thought. If the foundation of flawed and weak, no amount of plastered on after thought security is going to prevent a breach.

Ok, ok... understood. And I'm not knowledgeable enough to try to argue with you.

As for rambling on for hours, please do: Then I don't need to spend any time or money on obtaining the VMS internals books, as I'll get all the necessary information here.

Do you know how well NSK and z/OS are handling these same issues you've mentioned, by the way?


-Methem

[VAXman(Admin)]

Originally Posted by Methem

Ok, ok... understood. And I'm not knowledgeable enough to try to argue with you.

As for rambling on for hours, please do: Then I don't need to spend any time or money on obtaining the VMS internals books, as I'll get all the necessary information here.

If you really want to know the internals, that book is a must have.

Originally Posted by Methem

Do you know how well NSK and z/OS are handling these same issues you've mentioned, by the way?

I've only had a cursory overview of NSK. The hardware is too prohibitively priced for me to get my hands on for any academic purposes. Most of what I know about NSK deals with the kernel's use of the processor lock-step mode. Outside of that, I know little of the application environment of NSK.

[Methem]

Originally Posted by VAXman

If you really want to know the internals, that book is a must have.

Yep.

I've only had a cursory overview of NSK. The hardware is too prohibitively priced for me to get my hands on for any academic purposes. Most of what I know about NSK deals with the kernel's use of the processor lock-step mode. Outside of that, I know little of the application environment of NSK.

Ok, thanks for the info anyway.

---

In the interest of politeness, I thought it would be nice to provide a few links that shed a little light on what this thread has been about for the last 10 posts or so. For those who've been wondering what the hell is going on:

http://en.wikipedia.org/wiki/Text_Editor_and_Corrector
http://en.wikipedia.org/wiki/EDT_text_editor
http://en.wikipedia.org/wiki/Emacs

http://en.wikipedia.org/wiki/TOPS-20
http://en.wikipedia.org/wiki/RSTS/E
http://en.wikipedia.org/wiki/RSX-11
http://en.wikipedia.org/wiki/OpenVMS
http://h20223.www2.hp.com/NonStopCom...0-0-0-121.html
http://en.wikipedia.org/wiki/Z/OS

http://www.openvmshobbyist.com/
http://deathrow.vistech.net/
http://www.twenex.org


-Methem

Ps. I wonder if it would be a good idea to create a whole new section/subforum/whatever in the forums for heavily off-topic threads not related to prog. rock.