4 ms·

UNIX Fourth Edition

114 points by dcminter 10mo ago

dcminter 10mo ago
This is the result of the tape from 1973 found at the University of Utah being sent over to the Computer History Museum for retrieval by bitsavers.org Prior discussion: https://news.ycombinator.com/item?id=45840321 https://news.ycombinator.com/item?id=45840321
zatkin 10mo ago
Has anyone managed to extract out the C source files and upload them into some browsable UI, e.g. GitHub or GitLab?
- Someone 10mo ago
  I think they’re in the Unix history repo. Browsing there, it may be https://github.com/dspinellis/unix-history-repo/commits/Research-V4-Snapshot-Development/ https://github.com/dspinellis/unix-history-repo/commits/Rese...
  - deleted 10mo ago
    [deleted]
userbinator 10mo ago
It still amazes me that even with all this functionality, it runs on a system with only 64k of RAM.
rasyidi 10mo ago
[flagged]
- Adesany 10mo ago
  [flagged]
lproven 10mo ago
Just for what it's worth, I tried to explain the context and the historical importance when I wrote about the original discovery of the tape, and about the recovery: https://www.theregister.com/2025/11/07/unix_fourth_edition_tape_rediscovered/ https://www.theregister.com/2025/11/07/unix_fourth_edition_t... https://www.theregister.com/2025/12/23/unix_v4_tape_successfully_recovered/ https://www.theregister.com/2025/12/23/unix_v4_tape_successf...
aap_ 10mo ago
Hi, this is me. I'm still hacking on it but ran into some hard to understand kernel bugs. once i mount more than the root filesystem (say /usr/man) there are issues with inode allocation/freeing. mixing and matching v4 and v5 stuff in various ways can also lead to other interesting bugs but often an allocated inode ends up on the freelist, and things break. Otoh it's so much fun to hack and fiddle with the unix kernel :) very zen
- yjftsjthsd-h 10mo ago
  > but ran into some hard to understand kernel bugs Are the bugs in the original, or somehow artifacts of how we got it? (Or, phrased differently: Were these bugs present at the University of Utah in 1974, or are they "new"?)
  - aap_ 10mo ago
    That's the puzzling thing. i find it hard to believe they sent out an operating system that can't deal with multiple file systems. yet i can't get them to work correctly. The pre-v4 nsys kernel is another piece in the puzzle. it doesn't have pipes implemented yet but aside from that (i put them in) it also shows these "busy i" bugs, but even when running on a single disk. Maybe there's more i'm doing wrong there since it's running on the fs from the v4 tape. But that i'm getting such similar bugs in different situations suggests there is something wrong that i'm not seeing yet. gotta debug more. If it turns out to be a timing-related bug it may be that the bug was much less obvious on real hardware.
    - is_taken 10mo ago
      a) Do these inode issues also happen with the supplied (v4) kernel? b) Do these inode issues also happen with a rebuilded kernel which uses the original lib1 and lib2? I once had strange effects on V6 if lib1 and/or lib2 were rebuild by me. Should be not hard to test.
      - aap_ 10mo ago
        In my experience, yes: always happens. So far i have not found a way to mount multiple disks without getting these inode errors. And this is just v4, the nsys kernel doesn't even work with a single disk. i hope i'll get to the bottom of this in the near future.
1vuio0pswjnm7 10mo ago
"There's a video of the recovery here. It's only slightly over five minutes long, but then, UNIX V4 wasn't very big yet: for instance, the kernel was some 27 kB of code." "It's very small: it contains around 55,000 lines of code, of which about 25,000 lines are in C, with under 1,000 lines of comments." Yesterday, HN front page: https://fzakaria.com/2025/12/28/huge-binaries https://fzakaria.com/2025/12/28/huge-binaries "Responses to my publication submissions often claimed such problems did not exist; however, I had observed them during my time within industry, such as at Google, but I couldn't cite it! One problem that is only present at these mega-codebases is massive binaries. What's the largest binary (ELF file) you've ever seen? I had observed binaries beyond 25GiB, including debug symbols." It's funny that he could not publish about the laughably large binary sizes at Google Meanwhile employees at the company have often published papers portraying the company's problems as interesting, perhaps as a recruiting technique

114 points by dcminter 10mo ago

This is the result of the tape from 1973 found at the University of Utah being sent over to the Computer History Museum for retrieval by bitsavers.org Prior discussion: https://news.ycombinator.com/item?id=45840321 https://news.ycombinator.com/item?id=45840321

zatkin 10mo ago

Has anyone managed to extract out the C source files and upload them into some browsable UI, e.g. GitHub or GitLab?

Someone 10mo ago
I think they’re in the Unix history repo. Browsing there, it may be https://github.com/dspinellis/unix-history-repo/commits/Research-V4-Snapshot-Development/ https://github.com/dspinellis/unix-history-repo/commits/Rese...
- deleted 10mo ago
  [deleted]

userbinator 10mo ago

It still amazes me that even with all this functionality, it runs on a system with only 64k of RAM.

rasyidi 10mo ago

[flagged]

Adesany 10mo ago
[flagged]

lproven 10mo ago

Just for what it's worth, I tried to explain the context and the historical importance when I wrote about the original discovery of the tape, and about the recovery: https://www.theregister.com/2025/11/07/unix_fourth_edition_tape_rediscovered/ https://www.theregister.com/2025/11/07/unix_fourth_edition_t... https://www.theregister.com/2025/12/23/unix_v4_tape_successfully_recovered/ https://www.theregister.com/2025/12/23/unix_v4_tape_successf...

aap_ 10mo ago

Hi, this is me. I'm still hacking on it but ran into some hard to understand kernel bugs. once i mount more than the root filesystem (say /usr/man) there are issues with inode allocation/freeing. mixing and matching v4 and v5 stuff in various ways can also lead to other interesting bugs but often an allocated inode ends up on the freelist, and things break. Otoh it's so much fun to hack and fiddle with the unix kernel :) very zen

yjftsjthsd-h 10mo ago
> but ran into some hard to understand kernel bugs Are the bugs in the original, or somehow artifacts of how we got it? (Or, phrased differently: Were these bugs present at the University of Utah in 1974, or are they "new"?)
- aap_ 10mo ago
  That's the puzzling thing. i find it hard to believe they sent out an operating system that can't deal with multiple file systems. yet i can't get them to work correctly. The pre-v4 nsys kernel is another piece in the puzzle. it doesn't have pipes implemented yet but aside from that (i put them in) it also shows these "busy i" bugs, but even when running on a single disk. Maybe there's more i'm doing wrong there since it's running on the fs from the v4 tape. But that i'm getting such similar bugs in different situations suggests there is something wrong that i'm not seeing yet. gotta debug more. If it turns out to be a timing-related bug it may be that the bug was much less obvious on real hardware.
  - is_taken 10mo ago
    a) Do these inode issues also happen with the supplied (v4) kernel? b) Do these inode issues also happen with a rebuilded kernel which uses the original lib1 and lib2? I once had strange effects on V6 if lib1 and/or lib2 were rebuild by me. Should be not hard to test.
    - aap_ 10mo ago
      In my experience, yes: always happens. So far i have not found a way to mount multiple disks without getting these inode errors. And this is just v4, the nsys kernel doesn't even work with a single disk. i hope i'll get to the bottom of this in the near future.

1vuio0pswjnm7 10mo ago

"There's a video of the recovery here. It's only slightly over five minutes long, but then, UNIX V4 wasn't very big yet: for instance, the kernel was some 27 kB of code." "It's very small: it contains around 55,000 lines of code, of which about 25,000 lines are in C, with under 1,000 lines of comments." Yesterday, HN front page: https://fzakaria.com/2025/12/28/huge-binaries https://fzakaria.com/2025/12/28/huge-binaries "Responses to my publication submissions often claimed such problems did not exist; however, I had observed them during my time within industry, such as at Google, but I couldn't cite it! One problem that is only present at these mega-codebases is massive binaries. What's the largest binary (ELF file) you've ever seen? I had observed binaries beyond 25GiB, including debug symbols." It's funny that he could not publish about the laughably large binary sizes at Google Meanwhile employees at the company have often published papers portraying the company's problems as interesting, perhaps as a recruiting technique