4 ms·

I think some of its criticisms (see e.g. pages numbered 20-21, PDF pages 60-61) remain valid: (1) Unlike OpenVMS/TOPS-20/LispMachines/etc, mainstream POSIX fil

I think some of its criticisms (see e.g. pages numbered 20-21, PDF pages 60-61) remain valid: (1) Unlike OpenVMS/TOPS-20/LispMachines/etc, mainstream POSIX file systems lack built-in versioning (there are a small number of POSIX systems which implemented it, e.g. SCO OpenServer's HTFS, but for whatever reason more mainstream systems like Linux or *BSD never did) (2) Directly related to (1), the fact that the unlink() system call is normally irreversible, and the rm command is (normally) a direct interface to unlink() (3) The simplicity of the interface between the shell and the commands it runs (just a list of strings, only slightly better than the DOS/Windows approach of a single string), and the potential issues induced by the fact that wildcards are implemented by the shell not the command itself. Regarding (3), OpenVMS DCL, IBM OS/400 and Microsoft PowerShell are all examples of systems where option parsing/etc happens in the shell, and the command is passed a parsed command line structure instead. However, although they are better in this regard, they have other disadvantages (the first two are super-proprietary; PowerShell is open source, but weighed down by the heaviness of .Net) I think a lot of historical issues with Unix are due to the fact that shared libraries didn't exist until much later, so seemingly obvious things like "put wildcard parsing in a shared library like getopt() is" weren't possible at the start. Also, Unix has never had any kind of standard structured data format (JSON would work, but it didn't exist for the first 30 years of Unix's existence), which is a problem for ideas like passing command arguments as structured data. > But then the terminal/TTY situation has barely changed, POSIX TTYs are a horrific pile of kludges, especially when one considers stuff like ECMA-48 (which isn't technically part of the POSIX TTY stack, but de facto is). Someone should just redo it as something more sensible, like exchanging null-terminated JSON packets. But getting everyone to agree on that is probably too hard.

Bene592 3y ago
For (1) there's stuff like BTRFS snapshots, or you could use Git on top of the FS
- skissane 3y ago
  > For (1) there's stuff like BTRFS snapshots, From what I understand, BTRFS snapshots are time-based. Whereas, in classic versioned file systems, a "snapshot" is triggered by open/close operations – each time you open a file for writing, that creates a new snapshot. > or you could use Git on top of the FS Git requires your application to have explicit support for working with Git repos, it isn't seamless. And I know some people have built FUSE-on-Git implementations (there are a few around), but (I believe) they've all got various limitations and I don't believe (I could be wrong) that any of them is quite the same experience as a true versioned filesystem
  - rini17 3y ago
    Since mmap I/O is popular, together with long lived processes like databases, snapshot on open/close might not help you much. With these caveats, using FUSE it should be easy to do, wonder why noone actually implemented it.
    - skissane 3y ago
      > Since mmap I/O is popular, together with long lived processes like databases, snapshot on open/close might not help you much. Classic versioned file systems were generally not designed for the use case of databases, they were designed for the use case of lots of small text files (config files, source code, shell scripts, etc). For something like a database file you would turn versioning off
nusuth31416 3y ago
From the point of view of an end user, I remember versioning on the Vax using EDT when I spent hours on end entering data from our local emergency department in quite large text files. Over the years, every now and then I have been looking for this functionality on Windows. Dropbox and OneDrive do this nowadays, in that I can just right click a file and see the different versions and change to a previous one. I work with long documents I write, and this functionality has saved the day a few times.
anthk 3y ago
I think the OpenVMS's DCL interface has a libre implementation. I've seen things like mpsh and the ITS debugger/shell (DDT) ported to Unix...
- skissane 3y ago
  > I think the OpenVMS's DCL interface has a libre implementation. I know about https://github.com/rroart/freevms/tree/master/dcl/src https://github.com/rroart/freevms/tree/master/dcl/src but my impression was FreeVMS is too incomplete to use in anger. > I've seen things like mpsh You mean https://cca.org/mpsh/ https://cca.org/mpsh/ ? I am wondering how close it is to DCL, in terms of the specific aspect of it I’m talking about here > and the ITS debugger/shell (DDT) ported to Unix... Do you have a link? One aspect of ITS I find fascinating is a debugged program can execute debugger commands. I actually implemented that before using a GDB Python script - have a do-nothing function passed a memory buffer containing a GDB command go run, the Python script sets a breakpoint on the function, and when that breakpoint is hit, it runs the GDB command, it can even write the results back into the buffer, and then it continues execution
  - anthk 3y ago
    Well, on OpenVMS: https://github.com/johnsonjh/PC-DCL https://github.com/johnsonjh/PC-DCL https://0x0.st/XoDG.patch https://0x0.st/XoDG.patch DDT, I think Lars Brinkoff had a port: https://github.com/larsbrinkhoff/portable-ddt https://github.com/larsbrinkhoff/portable-ddt
  - tankenmate 3y ago
    Just reading about DDT reminds me of the "WizBiz"[0] series of fantasy novels, it's funny how just the mention of something from so long ago can evoke memories. [0] https://tvtropes.org/pmwiki/pmwiki.php/Literature/WizBiz https://tvtropes.org/pmwiki/pmwiki.php/Literature/WizBiz
    - anthk 3y ago
      DDT in the 60's was a bug killing spray which soon was banned because it was toxic.
anthk 3y ago
OpenDCL for Unix: https://github.com/johnsonjh/PC-DCL https://github.com/johnsonjh/PC-DCL patch: https://0x0.st/XoDG.patch https://0x0.st/XoDG.patch git clone https://github.com/johnsonjh/PC-DCL cd PC-DCL wget -O corr.patch https://0x0.st/XoDG.patch git apply corr.patch make NDEBUG=1 Enjoy.
eadmund 3y ago
> Also, Unix has never had any kind of standard structured data format (JSON would work, but it didn't exist for the first 30 years of Unix's existence), which is a problem for ideas like passing command arguments as structured data. JSON is a serialisation of structured data, not structured data itself. Its data model is not great, either: maps have no inherent canonical serialisation (one has to assert things such as ‘keys are sorted in Unicode lexicographical order’), and there is no way to shadow map value. A list-based s-expression format would be preferable, as it immediately lends itself to canonicalisation and associative lists support shadowing (e.g. ((a 123) (b 456) (a 789))).
msla 3y ago
> Unlike OpenVMS/TOPS-20/LispMachines/etc, mainstream POSIX file systems lack built-in versioning We have git, which is strictly better. > Directly related to (1), the fact that the unlink() system call is normally irreversible, and the rm command is (normally) a direct interface to unlink() You'd be complaining about how a really_really_unlink_now_i_mean_it() syscall was irreversible, too. > and the potential issues induced by the fact that wildcards are implemented by the shell not the command itself. I like not having to rely on arbitrary commands implementing (or not) wildcards. (Plus, even in the best of worlds, all commands would implement wildcards by linking in the same library, which brings us back to square one.)
- tankenmate 3y ago
  Firstly, largely agree. > You'd be complaining about how a really_really_unlink_now_i_mean_it() syscall was irreversible, too. Or the converse; what file (or worse hundreds/thousands of files) is using up all my disk and what's the sane way to delete all the old versions, and which files are important to keep all the old versions of? > I like not having to rely on arbitrary commands implementing (or not) wildcards. Indeed and being able to use meta tools like xargs. "The unreasonable effectiveness of plain text".
- anthk 3y ago
  >git... No, and you know it. ITS' versioning (or VMS/TOPS-20 too I think) it's tons better. Even 9front has it.
yjftsjthsd-h 3y ago
> (1) Unlike OpenVMS/TOPS-20/LispMachines/etc, mainstream POSIX file systems lack built-in versioning (there are a small number of POSIX systems which implemented it, e.g. SCO OpenServer's HTFS, but for whatever reason more mainstream systems like Linux or *BSD never did) Linux does have that in NILFS2, it's just that almost nobody cares to use it: https://www.kernel.org/doc/html/latest/filesystems/nilfs2.html https://www.kernel.org/doc/html/latest/filesystems/nilfs2.ht... / https://man.archlinux.org/man/nilfs.8.en https://man.archlinux.org/man/nilfs.8.en
- skissane 3y ago
  > Linux does have that in NILFS2, it's just that almost nobody cares to use it I don’t believe that NILFS2 is quite the same thing. In HTFS, you turn versioning on or off on a per-directory basis, and then each individual file in that directory is versioned independently. NILFS2 looks more like whole filesystem snapshotting, which is further away from the classic versioned filesystem approach

Bene592 3y ago

For (1) there's stuff like BTRFS snapshots, or you could use Git on top of the FS

skissane 3y ago
> For (1) there's stuff like BTRFS snapshots, From what I understand, BTRFS snapshots are time-based. Whereas, in classic versioned file systems, a "snapshot" is triggered by open/close operations – each time you open a file for writing, that creates a new snapshot. > or you could use Git on top of the FS Git requires your application to have explicit support for working with Git repos, it isn't seamless. And I know some people have built FUSE-on-Git implementations (there are a few around), but (I believe) they've all got various limitations and I don't believe (I could be wrong) that any of them is quite the same experience as a true versioned filesystem
- rini17 3y ago
  Since mmap I/O is popular, together with long lived processes like databases, snapshot on open/close might not help you much. With these caveats, using FUSE it should be easy to do, wonder why noone actually implemented it.
  - skissane 3y ago
    > Since mmap I/O is popular, together with long lived processes like databases, snapshot on open/close might not help you much. Classic versioned file systems were generally not designed for the use case of databases, they were designed for the use case of lots of small text files (config files, source code, shell scripts, etc). For something like a database file you would turn versioning off

nusuth31416 3y ago

From the point of view of an end user, I remember versioning on the Vax using EDT when I spent hours on end entering data from our local emergency department in quite large text files. Over the years, every now and then I have been looking for this functionality on Windows. Dropbox and OneDrive do this nowadays, in that I can just right click a file and see the different versions and change to a previous one. I work with long documents I write, and this functionality has saved the day a few times.

anthk 3y ago

I think the OpenVMS's DCL interface has a libre implementation. I've seen things like mpsh and the ITS debugger/shell (DDT) ported to Unix...

skissane 3y ago
> I think the OpenVMS's DCL interface has a libre implementation. I know about https://github.com/rroart/freevms/tree/master/dcl/src https://github.com/rroart/freevms/tree/master/dcl/src but my impression was FreeVMS is too incomplete to use in anger. > I've seen things like mpsh You mean https://cca.org/mpsh/ https://cca.org/mpsh/ ? I am wondering how close it is to DCL, in terms of the specific aspect of it I’m talking about here > and the ITS debugger/shell (DDT) ported to Unix... Do you have a link? One aspect of ITS I find fascinating is a debugged program can execute debugger commands. I actually implemented that before using a GDB Python script - have a do-nothing function passed a memory buffer containing a GDB command go run, the Python script sets a breakpoint on the function, and when that breakpoint is hit, it runs the GDB command, it can even write the results back into the buffer, and then it continues execution
- anthk 3y ago
  Well, on OpenVMS: https://github.com/johnsonjh/PC-DCL https://github.com/johnsonjh/PC-DCL https://0x0.st/XoDG.patch https://0x0.st/XoDG.patch DDT, I think Lars Brinkoff had a port: https://github.com/larsbrinkhoff/portable-ddt https://github.com/larsbrinkhoff/portable-ddt
- tankenmate 3y ago
  Just reading about DDT reminds me of the "WizBiz"[0] series of fantasy novels, it's funny how just the mention of something from so long ago can evoke memories. [0] https://tvtropes.org/pmwiki/pmwiki.php/Literature/WizBiz https://tvtropes.org/pmwiki/pmwiki.php/Literature/WizBiz
  - anthk 3y ago
    DDT in the 60's was a bug killing spray which soon was banned because it was toxic.

anthk 3y ago

OpenDCL for Unix: https://github.com/johnsonjh/PC-DCL https://github.com/johnsonjh/PC-DCL patch: https://0x0.st/XoDG.patch https://0x0.st/XoDG.patch git clone https://github.com/johnsonjh/PC-DCL cd PC-DCL wget -O corr.patch https://0x0.st/XoDG.patch git apply corr.patch make NDEBUG=1 Enjoy.

eadmund 3y ago

> Also, Unix has never had any kind of standard structured data format (JSON would work, but it didn't exist for the first 30 years of Unix's existence), which is a problem for ideas like passing command arguments as structured data. JSON is a serialisation of structured data, not structured data itself. Its data model is not great, either: maps have no inherent canonical serialisation (one has to assert things such as ‘keys are sorted in Unicode lexicographical order’), and there is no way to shadow map value. A list-based s-expression format would be preferable, as it immediately lends itself to canonicalisation and associative lists support shadowing (e.g. ((a 123) (b 456) (a 789))).

msla 3y ago

> Unlike OpenVMS/TOPS-20/LispMachines/etc, mainstream POSIX file systems lack built-in versioning We have git, which is strictly better. > Directly related to (1), the fact that the unlink() system call is normally irreversible, and the rm command is (normally) a direct interface to unlink() You'd be complaining about how a really_really_unlink_now_i_mean_it() syscall was irreversible, too. > and the potential issues induced by the fact that wildcards are implemented by the shell not the command itself. I like not having to rely on arbitrary commands implementing (or not) wildcards. (Plus, even in the best of worlds, all commands would implement wildcards by linking in the same library, which brings us back to square one.)

tankenmate 3y ago
Firstly, largely agree. > You'd be complaining about how a really_really_unlink_now_i_mean_it() syscall was irreversible, too. Or the converse; what file (or worse hundreds/thousands of files) is using up all my disk and what's the sane way to delete all the old versions, and which files are important to keep all the old versions of? > I like not having to rely on arbitrary commands implementing (or not) wildcards. Indeed and being able to use meta tools like xargs. "The unreasonable effectiveness of plain text".
anthk 3y ago
>git... No, and you know it. ITS' versioning (or VMS/TOPS-20 too I think) it's tons better. Even 9front has it.

yjftsjthsd-h 3y ago

> (1) Unlike OpenVMS/TOPS-20/LispMachines/etc, mainstream POSIX file systems lack built-in versioning (there are a small number of POSIX systems which implemented it, e.g. SCO OpenServer's HTFS, but for whatever reason more mainstream systems like Linux or *BSD never did) Linux does have that in NILFS2, it's just that almost nobody cares to use it: https://www.kernel.org/doc/html/latest/filesystems/nilfs2.html https://www.kernel.org/doc/html/latest/filesystems/nilfs2.ht... / https://man.archlinux.org/man/nilfs.8.en https://man.archlinux.org/man/nilfs.8.en

skissane 3y ago
> Linux does have that in NILFS2, it's just that almost nobody cares to use it I don’t believe that NILFS2 is quite the same thing. In HTFS, you turn versioning on or off on a per-directory basis, and then each individual file in that directory is versioned independently. NILFS2 looks more like whole filesystem snapshotting, which is further away from the classic versioned filesystem approach