Unix's (technical) history is mostly old now

November 24, 2022

Yesterday I wrote about how Unix swap configuration used to be simple and brute force, covering a number of cases from V7 Unix through Linux 0.92c. As I wrote that entry, it became increasingly striking to me that the most recent time I mentioned was 1992. This isn't something unique to swap handling, or new in my entries about much of the (technical) origins and evolution of Unix. Instead, it's because a lot of Unix's technical history is at least thirty years old now.

It's not quite the case that nothing has happened in Unix history since the early 1990s. Very obviously, quite a lot of important social things happened around 'Unix', such that by the end of the 1990s what Unixes people used had changed significantly (and then in the 00s the change became drastic). Less obviously, a bunch of internal kernel technology changed over that time, so that today every remaining common Unix has good SMP and in a far better place for performance.

To some degree, technical evolution has also continued in filesystems. The problem is that this evolution is very unevenly distributed, with the most advanced filesystems the least widely used. Unix has made valuable strides in commonly used filesystems, but they aren't drastic ones. And the filesystem related features visible to people using Unix haven't really changed since the early 1990s, especially in common use (there has been no large move to adopt ACLs or file attributes, for example, although file capabilities have snuck into common use on Linux systems).

Some things that were known in the early 1990s but not very adopted have become pervasive, like having a /proc or interacting with your kernel for status information and tuning through a structured API instead of ad-hoc reading (and sometimes writing) kernel memory. However, these changes at least don't feel as big as previous evolutions. It's better that ps operates by reading /proc, but it's still ps.

I think that if you took a Unix user from the early 1990s and dropped them into a 2022 Unix system via SSH, they wouldn't find much that was majorly different in the experience. Admittedly, a system administrator would have a different experience; practices and tools have shifted drastically (for the better).

(It's possible that my perspective leaves me blinded to important things in Unix's technical history and evolution in 2010s, 2000s, and 1990s.)


Comments on this page:

«a lot of Unix's technical history is at least thirty years old now.»

Well perhaps I am too much of a novelty seeker, but around 1980 I started thinking that UNIX was nice to use, but it was too much 1950s-1960s technology, so I looked for something more modern, and found MUSS from UK's Manchester University, thanks to the August 1980 issue of "Software Practice and Experience" which has several articles about it. It had a fascinating and much improved design, supporting heterogenous complexes via networking, and cleverly chosen fundamental abastractions based on IPC rather than files. But while it found modest adoption it did not spread, in part because the Manchester people were clueless as to "selling". But then other systems with more modern and flexible desings than UNIX did not spread either, from Plan 9 itself to Chorus, for example.

«To some degree, technical evolution has also continued in filesystems. The problem is that this evolution is very unevenly distributed, with the most advanced filesystems the least widely used.»

That's a sad story: tragically and I think in large part because of RedHat some decades ago the "standard" Linux filesystem became 'ext3' instead of JFS, and we are still living with the consequences. But there have been interesting developments and currently I think that F2FS is a very good direction, as it works quite well on HDDs too, as these become more "sequential" in profile.

«no large move to adopt ACLs or file attributes»

ACLs are largely unnecessary, but file attributes are widely used for "metafilesystems" like Ceph or Lustre.

Anyhow as to that the UNIX design had two very severe limitations in itself (not missing things, but things that were not complete) and one was the lack of distinction between real and effective owner and group for inodes:

http://www.sabi.co.uk/blog/13-one.html?130329#130329

Written on 24 November 2022.
« Unix swap configuration used to be rather simple and brute force
A revealing Vim addressing mistake that I made today »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Nov 24 22:49:37 2022
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.