Unix Fourth Edition

dcminter · 2025-12-23T10:28:40.000Z

Discussion: UNIX Fourth Edition

Posted11 days agoActive1d ago

dcminter

95 points

9 comments

squoze.netTech Discussionstory

informativeneutral

Debate

0/100

Command Line ToolFreebsdRetro Computing

Key topics

Command Line Tool

Freebsd

Retro Computing

Discussion Activity

Moderate engagement

First comment

Peak period

Day 8

Avg / period

3.5

Key moments

01Story posted
Dec 23, 2025 at 5:28 AM EST
11 days ago
Step 01
02First comment
Dec 23, 2025 at 5:32 AM EST
4m after posting
Step 02
03Peak activity
7 comments in Day 8
Hottest window of the conversation
Step 03
04Latest activity
Jan 1, 2026 at 9:05 AM EST
1d ago
Step 04

Generating AI Summary...

Analyzing up to 500 comments to identify key contributors and discussion patterns

Discussion (9 comments)

Showing 14 comments

zatkin

4d ago

1 reply

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

Someone

4d ago

1 reply

[delayed]

topspin

3d ago

It is interesting to note that that github repo may be the first time the code in question has ever been version controlled.

rasyidi

4d ago

1 reply

Respons

Adesany

4d ago

Okay

aap_

3d ago

1 reply

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.

yjftsjthsd-h

3d ago

1 reply

> 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_

3d ago

1 reply

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

3d ago

1 reply

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_

1d 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.

lproven

4d 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_t...

https://www.theregister.com/2025/12/23/unix_v4_tape_successf...

userbinator

4d ago

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

1vuio0pswjnm7

3d 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

"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

dcminterAuthor

11 days ago

[delayed]

View full discussion on Hacker News

ID: 46364136Type: storyLast synced: 12/30/2025, 6:30:30 PM

Want the full context?

Jump to the original sources

Read the primary article or dive into the live Hacker News thread when you're ready.

Open link View on HN