12 ms·

How sad. VMS originally ran on a VAX 11/780 which maxed out at 8 MB. Now it apparently needs almost 1000 times more memory.

Aloha 4y ago
VMS in 2020 is a vastly different beast than the VMS that ran on 11/780
- usr1106 4y ago
  So what what has fundamentally changed? I used VMS on various types of VAXen in the mid 1980s and I liked it because of its systematically designed command line interpreter. A Unix shell is a complete mess compared to that. I switched to Unix in the late 1980s and to Linux later and found it technically more powerful. Lightweight processes, pipes and many more. Is there anything in OpenVMS that Linux is fundamentally lacking?
  - lproven 4y ago
    > Is there anything in OpenVMS that Linux is fundamentally lacking? File versioning. This is bodged on in all xNixes by embedding version numbers into filenames, then writing a multi-tens-of-thousands-of-lines shell scripts to track all the versions, make loads of symlinks so programs can find them if they don't need specific revisions, occasionally add new versions and remap hundreds of links, occasionally prune old libraries, carefully manage umpteen paths to where different libraries are kept... and this is considered normal and nobody sees anything wrong with it, when in fact it's a vast ugly kludge of a hack, now fossilised as package managers and so on. All because it's a braindead filesystem.
    - usr1106 4y ago
      Linux does not have a single filesystem, but many of them. I guess you could create one that implements versioning. As a matter of fact around 2000 I used one (Unix, not Linux). It was a version control system where different file versions appeared under different POSIX paths. I liked it, but it was at least as complicated as git and most developers in our organization did not really understand it a complained when things went wrong. For system administration I use etckeeper these days. That serves nearly the same purpose. But for programming VMS was superior unless you are disciplined and commit frequently enough.
      - lproven 4y ago
        You could, but no normal Unix app will understand it or be able to use it, since this is one of the things that the Unix creators removed from the more complicated forerunners of Unix to make their smaller, simpler OS. Sadly, this simplification was, IMHO, a step too far and a bad thing to remove. But Unix's namespace is much simpler, and doesn't really understand and incorporate extensions and things either. Which is a limitation but it makes it much simpler. The fact that most Unix GUIs, from NeXTstep to KDE, put back in and use file extensions to associate files with applications shows that this is in fact important functionality. Without extensions, having version numbering doesn't make as much sense. But a Unix with file extensions and file numbers would be less like Unix than is, say, Plan 9 or Inferno.
        usr1106 4y ago
        An application does not need to understand that the filesystem keeps a copy of the previous version of a file. Also in VMS if you use a file without version number it defaults to the newest one.
        lproven 3y ago
        I know. I ran clusters of VAX boxes, in production, in the mid-1990s. An ordinary user app doesn't need to know. A file version control system does, though. Development environments need to know. IDEs and programmers' tools need to know.
    - javitron 3y ago
      The file versioning in OpenVMS is really not that powerful. It also led to it's own set of issues, specially in terms of space waste. Also VMS had their own issues when it came to it's filesystem(s).
      - lproven 3y ago
        Sure it did, yes. OTOH, the point here is that if facilities like this were available, tools like Git -- VCSes -- could be far simpler and easier to use, because a core part of the functionality they add is built into the filesystem. Disk space is less of an issue now. This is a server OS for big systems. Terabytes are cheap. All filesystems have issues. Remember, all software sucks: http://harmful.cat-v.org/software/ http://harmful.cat-v.org/software/
javitron 3y ago
Yeah, and Unix originally ran on a PDP with 256KB of RAM. Alas...

Aloha 4y ago

VMS in 2020 is a vastly different beast than the VMS that ran on 11/780

usr1106 4y ago
So what what has fundamentally changed? I used VMS on various types of VAXen in the mid 1980s and I liked it because of its systematically designed command line interpreter. A Unix shell is a complete mess compared to that. I switched to Unix in the late 1980s and to Linux later and found it technically more powerful. Lightweight processes, pipes and many more. Is there anything in OpenVMS that Linux is fundamentally lacking?
- lproven 4y ago
  > Is there anything in OpenVMS that Linux is fundamentally lacking? File versioning. This is bodged on in all xNixes by embedding version numbers into filenames, then writing a multi-tens-of-thousands-of-lines shell scripts to track all the versions, make loads of symlinks so programs can find them if they don't need specific revisions, occasionally add new versions and remap hundreds of links, occasionally prune old libraries, carefully manage umpteen paths to where different libraries are kept... and this is considered normal and nobody sees anything wrong with it, when in fact it's a vast ugly kludge of a hack, now fossilised as package managers and so on. All because it's a braindead filesystem.
  - usr1106 4y ago
    Linux does not have a single filesystem, but many of them. I guess you could create one that implements versioning. As a matter of fact around 2000 I used one (Unix, not Linux). It was a version control system where different file versions appeared under different POSIX paths. I liked it, but it was at least as complicated as git and most developers in our organization did not really understand it a complained when things went wrong. For system administration I use etckeeper these days. That serves nearly the same purpose. But for programming VMS was superior unless you are disciplined and commit frequently enough.
    - lproven 4y ago
      You could, but no normal Unix app will understand it or be able to use it, since this is one of the things that the Unix creators removed from the more complicated forerunners of Unix to make their smaller, simpler OS. Sadly, this simplification was, IMHO, a step too far and a bad thing to remove. But Unix's namespace is much simpler, and doesn't really understand and incorporate extensions and things either. Which is a limitation but it makes it much simpler. The fact that most Unix GUIs, from NeXTstep to KDE, put back in and use file extensions to associate files with applications shows that this is in fact important functionality. Without extensions, having version numbering doesn't make as much sense. But a Unix with file extensions and file numbers would be less like Unix than is, say, Plan 9 or Inferno.
      - usr1106 4y ago
        An application does not need to understand that the filesystem keeps a copy of the previous version of a file. Also in VMS if you use a file without version number it defaults to the newest one.
        lproven 3y ago
        I know. I ran clusters of VAX boxes, in production, in the mid-1990s. An ordinary user app doesn't need to know. A file version control system does, though. Development environments need to know. IDEs and programmers' tools need to know.
  - javitron 3y ago
    The file versioning in OpenVMS is really not that powerful. It also led to it's own set of issues, specially in terms of space waste. Also VMS had their own issues when it came to it's filesystem(s).
    - lproven 3y ago
      Sure it did, yes. OTOH, the point here is that if facilities like this were available, tools like Git -- VCSes -- could be far simpler and easier to use, because a core part of the functionality they add is built into the filesystem. Disk space is less of an issue now. This is a server OS for big systems. Terabytes are cheap. All filesystems have issues. Remember, all software sucks: http://harmful.cat-v.org/software/ http://harmful.cat-v.org/software/

javitron 3y ago

Yeah, and Unix originally ran on a PDP with 256KB of RAM. Alas...