This is looking really beautiful! For a long time I've wanted to have a nice edition of the elements in the original greek. There are some pdfs around but they look rather uninspired. Something like Byrne's edition in greek would be so lovely! Though this is not a straight translation but quite reworked to make it more graphical, so probably wouldn't work too well with the original text without some work anyway.
Love the Whirlwind! i think of it as the original microcontroller, except not very micro of course. The 2kw address space is a bit small for bigger programs unfortunately, but it's still great fun to play with anyways.
This is low-effort fantasy history. It may be directionally correct, but why bother when you don't care about the details? From analyzing the UNIX manuals and other old files we get the following (not fully complete) picture:
We'll skip PDP-7 UNIX, no hierarchical file system yet.
UNIX v1 on the PDP-11 had an RF11 fixed head disk (1mb) for / and swap, and an RK05 moving head disk (2.5mb) for /usr (the user directories)
By v2 they had added a second RK05 at /sys for things like the kernel, manual pages, and system language stuff like the c compiler and m6.
By v3 they added yet another RK05 at /crp for, well, all sorts of crap (literally), including yacc apparently. /usr/bin is mentioned here for the first time.
I don't feel like looking up when sbin was first introduced but it is not a Bell Labs thing. possibly BSD or AT&T UNIX? Binaries that one would normally not want to run were kept in /etc, which includes thing like init, mount, umount, getty, but also the second pass of the assembler (as2), or helpers like glob.
Also i don't know when /home became canonical but at Bell Labs it was never a thing (plan 9 has user directories in /usr where they had always belonged logically).
The lib situation is more difficult. Looks like it started with /usr/lib. By v3 we find the equivalent directory as /lib, where it contains the two passes of the C compiler (no optimization pass back then), C runtime and lib[abc].a (assembler, B, C libraries respectively). /usr/lib had been repurposed for non-object type libraries, think text-preparation and typesetting.
By v4 the system had escaped the labs (see the recent news) and at that point everyone modified the system to their taste anyway. Perhaps it should be noted that the v7 distribution (which is the first that is very clearly the ancestor of every modern UNIX) has no /usr/bin, only /bin. /lib and /usr/lib are split however.
These are just some rough notes and due to a lack of early material they're still not as accurate as i would like. Also UNIX ran on more than one machine even in the early days (the manuals mention the number of installations) so there must have been some variation anyway. Something I'd like to know in particular is when and where RP03 disk drives were used. These are pretty huge in comparison to the cute RK05s.
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
> 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"?)
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.
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.
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.
I find it strange that nobody has ever recreated the classic windows desktop faithfully, except for reactos i suppose. But on Linux i think there are quite a few people around who would happily use it. All sorts of themes for other interfaces aren't quite the same thing
Nobody ever considers the spinorial version. e^iπ is a 360° rotation on a spinor, and + is averaging spinors rotationally. so e^iπ + 1 = 0 means there is no way to interpolate between the identity and a twist in the spinor, because the axis of a 360° rotation is undefined.
Things get so much more fun once you embrace spinors.
I've wanted to try racket a few times but always found the "IDE" to be really unintuitive, clunky and weird. What gives? Is that by design or is it just that nothing better has been created so far?
The Racket Langserver obviously enables use in other editors that support the LSP. https://github.com/jeapostrophe/racket-langserver For editors that lack LSP support, scheme support is generally sufficient.
All that aside, DrRacket the IDE has some nice features that just don't exist in other editors. I don't know of another IDE that has an integrated macro stepper.
reply