You can run the PDP-7 version and an early slightly frankenstein'ed PDP-11 version in simh:
https://github.com/DoctorWkt/pdp7-unix
https://github.com/DoctorWkt/unix-jun72
Unix Edition Zero (1971)
31–40 of 61 posts
Re: Unix Edition Zero (1971)
#32TIL PDP-11 UNIX had an eight-character file/directory name limit https://retrocomputing.stackexchange.com/questions/23917/ori...
PDP-11 running RSTS/E had 6.3 filenames, and iirc no sub-directories (each user account (grouped by project) was a single directory). Remembering what “EDS023.DAT” was for could be a headache on large projects.
Re: Unix Edition Zero (1971)
#33seems extremely similar to modern unixes, though of course it's only a small subset main differences seem to be - filenames were only 8 bytes instead of 14 or 255 - devices were in the root directory instead of /dev: /ppt, /bppt, /rppt, /tty, /ctty, /tty1, /tty2, /rtty, /tap0, /tap1 (magtapes), /disk (the disk), and /system (the kernel memory) - there were no groups, just six permission bits (u+r, u+w, o+r, o+w, a+x,…
My first Unix was v6. It had seek() but no lseek(), which was introduced in v7. We converted several programs to use it.
The tape archiver in v6 was called tp. I never used tap, which was earlier. Tar was introduced in v7. It was a complete re-write and used a different on-tape format.
Re: Unix Edition Zero (1971)
#34Earlier quoted context omitted.
The first time you zero-padded a year to five digits, I thought it was an accident, but there's two more instances of it. Why do you write 1983 as 01983?
Probably due to this: https://longnow.org/ Personally I think it's a harmless but also not useful affectation (but I also think our chances of making it into the 10,000s as anything still using equivalent dates are slim at best).
It's not harmless. 1) It's annoying. 2) It's off-topic - this isn't an article about the long now, or about dating systems. 3) It's inefficient to write dates not in the standard format - it makes everyone waste mental energy trying to figure out how to parse it.
The third point is especially bad for this article, where in context, the assumption should be that 0xxxx is octal, which isn't what he's actually doing at all.
So the upshot is that, rather than efficiently communicate what he's trying to say on this topic, he'd rather grind is axe on an unrelated topic. His choice, I guess, but I think it's a bad one. And an unfortunate one - he's got really good information on this topic, and his choice has hijacked us into talking about his date format.
And, thinking about it, it's not really the "long now". It's more like the "medium now". If it were the long now, he'd have several more zeroes in front.
Re: Unix Edition Zero (1971)
#35seems extremely similar to modern unixes, though of course it's only a small subset main differences seem to be - filenames were only 8 bytes instead of 14 or 255 - devices were in the root directory instead of /dev: /ppt, /bppt, /rppt, /tty, /ctty, /tty1, /tty2, /rtty, /tap0, /tap1 (magtapes), /disk (the disk), and /system (the kernel memory) - there were no groups, just six permission bits (u+r, u+w, o+r, o+w, a+x,…
My first Unix was v6. It had seek() but no lseek(), which was introduced in v7. We converted several programs to use it. The tape archiver in v6 was called tp. I never used tap, which was earlier. Tar was introduced in v7. It was a complete re-write and used a different on-tape format.
thank you very much, i did not know these things
Re: Unix Edition Zero (1971)
#36seems extremely similar to modern unixes, though of course it's only a small subset main differences seem to be - filenames were only 8 bytes instead of 14 or 255 - devices were in the root directory instead of /dev: /ppt, /bppt, /rppt, /tty, /ctty, /tty1, /tty2, /rtty, /tap0, /tap1 (magtapes), /disk (the disk), and /system (the kernel memory) - there were no groups, just six permission bits (u+r, u+w, o+r, o+w, a+x,…
> no C yet, just B, but evidently the B compiler was already generating native code instead of stack bytecode No, B always generated interpreted/threaded code on UNIX, certainly on the PDP-7. We have the runtime and B library from that time.
the manual seems to claim otherwise when speaking about the -11, in that it says the B compiler produced a.out and n.out files just like the assembler (presumably by invoking it)
you could do this just by aggregating the interpreter (which is never mentioned) with the bytecode in a single file, but that would imply making 10 copies of the interpreter if you had 10 programs compiled with B, on a 512-kibibyte disk; a highly suboptimal tradeoff under the circumstances
but even in such a case what symbols would you put in n.out
Re: Unix Edition Zero (1971)
#37Earlier quoted context omitted.
Probably due to this: https://longnow.org/ Personally I think it's a harmless but also not useful affectation (but I also think our chances of making it into the 10,000s as anything still using equivalent dates are slim at best).
It's not harmless. 1) It's annoying. 2) It's off-topic - this isn't an article about the long now, or about dating systems. 3) It's inefficient to write dates not in the standard format - it makes everyone waste mental energy trying to figure out how to parse it. The third point is especially bad for this article, where in context, the assumption should be that 0xxxx is octal, which isn't what he's actually doing at…
the degree to which you are projecting your own antisocial behavior onto me is astounding
i decline to take responsibility for your emotions
i would appreciate it if you would stop harassing people because you don't like the date format they use, their haircut, or their clothes
Re: Unix Edition Zero (1971)
#38Earlier quoted context omitted.
Probably due to this: https://longnow.org/ Personally I think it's a harmless but also not useful affectation (but I also think our chances of making it into the 10,000s as anything still using equivalent dates are slim at best).
It's not harmless. 1) It's annoying. 2) It's off-topic - this isn't an article about the long now, or about dating systems. 3) It's inefficient to write dates not in the standard format - it makes everyone waste mental energy trying to figure out how to parse it. The third point is especially bad for this article, where in context, the assumption should be that 0xxxx is octal, which isn't what he's actually doing at…
where in context, the assumption should be that 0xxxx is octal
That's what I thought it was too. This convention carried over into C and its derivatives today.
Re: Unix Edition Zero (1971)
#39seems extremely similar to modern unixes, though of course it's only a small subset main differences seem to be - filenames were only 8 bytes instead of 14 or 255 - devices were in the root directory instead of /dev: /ppt, /bppt, /rppt, /tty, /ctty, /tty1, /tty2, /rtty, /tap0, /tap1 (magtapes), /disk (the disk), and /system (the kernel memory) - there were no groups, just six permission bits (u+r, u+w, o+r, o+w, a+x,…
Thanks for the summary! > - creat is spelled with an e You mean it was 'create'? Funny if 'creat' was a mistake that stuck. My favourite in this genre is 'makunbound'.
right
some cases of this relate to identifiers only having 6 significant characters in some object file formats (typically a 32-bit or 36-bit field using rad50) but i don't know if lisp's makunbound was such an example, and creat surely was not
Re: Unix Edition Zero (1971)
#40Earlier quoted context omitted.
It's not harmless. 1) It's annoying. 2) It's off-topic - this isn't an article about the long now, or about dating systems. 3) It's inefficient to write dates not in the standard format - it makes everyone waste mental energy trying to figure out how to parse it. The third point is especially bad for this article, where in context, the assumption should be that 0xxxx is octal, which isn't what he's actually doing at…
where in context, the assumption should be that 0xxxx is octal That's what I thought it was too. This convention carried over into C and its derivatives today.
amusingly 8 and 9 would continue to be accepted as octal digits by the c (or b) compiler until ansi c forbid them
a priori, though, '01982' is not very likely to be intended as octal either