[HN Gopher] UNIX Fourth Edition
___________________________________________________________________
UNIX Fourth Edition
Author : dcminter
Score : 105 points
Date : 2025-12-23 10:28 UTC (7 days ago)
(HTM) web link (squoze.net)
(TXT) w3m dump (squoze.net)
| dcminter wrote:
| 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
| zatkin wrote:
| Has anyone managed to extract out the C source files and upload
| them into some browsable UI, e.g. GitHub or GitLab?
| Someone wrote:
| I think they're in the Unix history repo. Browsing there, it
| may be https://github.com/dspinellis/unix-history-
| repo/commits/Rese...
| userbinator wrote:
| It still amazes me that even with all this functionality, it runs
| on a system with only 64k of RAM.
| lproven wrote:
| 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_t...
|
| https://www.theregister.com/2025/12/23/unix_v4_tape_successf...
| aap_ wrote:
| 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 wrote:
| > 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_ wrote:
| 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 wrote:
| 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.
| 1vuio0pswjnm7 wrote:
| "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
|
| "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
___________________________________________________________________
(page generated 2025-12-30 23:01 UTC)