Any chance you could elaborate?
Perhaps I was a bit hyperbolic about it sucking more nowadays. At least you can use TCP with it and not UDP, and you can configure it so you can actually interrupt file operations when the server unexpectedly goes away and doesn't come back, instead of having to reboot your machine to clear things out. But most of what the book says is still the NFS status quo today, 30 years later.
With Kerberos a hacked client where user 1 has authenticated can't impersonate user 2 unless that user has also authenticated on the client.
With sec=sys the client is simply trusted without any per-user authentication.
- 9p+encryption on top instead of NFS, much better.
- C under plan9 it's far better and easier than POSIX. Also, we had Golang under Unix which almost made that better C philosophy into Unix with a better systems language.
- Usenet/IRC works and you'll get far more trolls under the web.
- The terminal makes things better in most cases than freezing UI's or Emacs, see my another post. But 9front doesn't use terminals, it's graphical from the start and composable.
- On security, plan9/9front uses namespaces and factotum plus decoupled servers/devices for hardware, a much better design.
- On documentation, the rest of the OSes have it far worse. But it was almost the same case with ITS and Macsyma/Maclisp, where you had a reference book and not starting guides to ease the learning of the language. GNU Texinfo made at least an Elisp intro a Maxima it's far better docummented wth on-line guides and examples.
- SystemD it's a disaster, and Wayland destroys any scriptabilily/hacks with wmctrl/xdotool/custom WM/DE's or something simple like remapping keys on broken keyboards (I use the "<>" key as "\ |" as my physical one it's broken, and I already have < and > near 'm') and it works.
NFS with IPsec for authentication and privacy seems similar in principle, with the added benefit that it's widely available.
But a total hack and duct taped together.
> with the added benefit that it's widely available.
On plan 9/ 9front 9p over TLS is out of the box. ipsec isnt.
Really? Afaik filesystems still do `rm` immediately and with no recourse. GUIs on top like Finder and Explorer do something more sane though, but that doesn't save us terminal users.
POSIX shell expansion is just as crazy as it has ever been too.
Those are the two gigantic foot guns I can recall from memory from having read this 20 years ago.
I use the former, I haven’t tried the latter. But afaict, they should be pretty much identical – they both supply `trash <path>` which could, for most intents and purposes, probably be aliased as `rm`.
One thing to note is that none of these tools seem to support the “Put Back” feature of Finder. Trashed files don’t remember their original locations. But I’ll personally still choose that over being nervous before every `rm`.
[0] – https://formulae.brew.sh/formula/trash [1] – https://formulae.brew.sh/formula/macos-trash
Broken by default is itself exactly the problem.
(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.
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.
https://github.com/johnsonjh/PC-DCL
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 NDBUG=1
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
With these caveats, using FUSE it should be easy to do, wonder why noone actually implemented it.
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
I know about 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/ ? 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
https://github.com/johnsonjh/PC-DCL
DDT, I think Lars Brinkoff had a port:
[0] https://tvtropes.org/pmwiki/pmwiki.php/Literature/WizBiz
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))).
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.)
> 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".
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.ht... / https://man.archlinux.org/man/nilfs.8.en
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
come now, they look nothing like they were 30 years ago.
I do wonder, though, if this were (re)written today, how much of it would be the same, how much of it would be outdated, and how much new stuff the haters would come up with.
The chapter on file systems is mostly no longer relevant (some file systems do still suck, but the defaults are pretty solid now). NFS still sucks (IMO it sucks more than it used to), but far fewer people need to use it nowadays. C and C++ are still unfortunately prevalent, but there are at least quite a few systems programming alternatives, and they're gaining ground. Sendmail isn't the only game in town anymore, and I expect most outfits use something else these days, and USENET is a distant memory for most people, so there go another two chapters.
But then the terminal/TTY situation has barely changed, and how all that works is just as (if not more) divorced from the reality of daily usage. Security has improved, but most people still have a god-mode root account, and most of the security improvements have come out of necessity; the world of networked computing is much more "dangerous" today than it was in the early 90s. Documentation is still often poor, and many systems still seem designed more for programmers than less-technical users.
I wonder what they'd think of systemd and Wayland!