TUHS

tuhs@tuhs.org

28 participants
6556 discussions

by Nick Downing

hi all, For those who have been following my 2.11BSD conversion, I was working on this in about 2005 and I might have posted about it then, and then nothing much happened while I did a university degree and so on, but recently I picked it up again. When I left it, I was partway through an ambitious conversion of the BSD build system to my own design (a file called "defs.mk" was included in all Makefiles apparently), and I threw this out because it was too much work upfront. The important build tools like "cc" were working, but I have since reviewed all changes and done things differently. The result is I can now build the C and kernel libraries and a kernel, and they work OK. This seems like a pretty good milestone so I'm releasing the code on bitbucket. See https://bitbucket.org/nick_d2/ for the list of my repositories, there is another one there called "uzi" which is a related project, but not document so I will write about it later, in the meantime anyone is welcome to view the source and changelogs of it. The 2.11BSD repository is at the following link: https://bitbucket.org/nick_d2/211bsd There is a detailed readme.txt in the root of repository which explains exactly how I approached the conversion and gives build instructions, caveats and so forth. To avoid duplication I won't post this in the list, but I suggest people read it as a post, since it's extremely interesting to see all the porting issues laid out together. See https://bitbucket.org/nick_d2/211bsd/src/27343e0e0b273c2df1de958db2ef5528cc… Happy browsing :) cheers, Nick

8 years, 7 months

Re: [TUHS] Pipes in the Third Edition Unix

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > You might say something like: Pipe's were developed in a 3rd edition > kernel, where there was is evidence of nascent idea (its has a name and > there are subs for it), but the code to fully support it is lacking in > the 3rd release. Pipes became a completed feature in the 4th edition. To add to what others have pointed out (about the assembler and C kernels), let me add one more data-bit. In the Unix oral histories done by Michael S. Mahoney, there's this: McIlroy: .. And on-e day I came up with a syntax for the shell that went along with the piping, and Ken said, "I'm going to do it!" He was tired of hearing all this stuff, and that was - you've read about it several times, I'm sure - that was absolutely a fabulous day the next day. He said, "I'm going to do it." He didn't do exactly what I had proposed for the pipe system call; he invented a slightly better one that finally got changed once more to what we have today. He did use my clumsy syntax. He put pipes into Unix, he put this notation [Here McIlroy pointed to the board, where he had written f > g > c] into shell, all in one night. The next morning, we had this - people came in, and we had - oh, and he also changed a lot of - most of the programs up to that time couldn't take standard input, because there wasn't the real need. So they all had file arguments; grep had a file argument, and cat had a file argument, and Thompson saw that that wasn't going to fit with this scheme of things and he went in and changed all those programs in the same night. I don't know how ... And the next morning we had this orgy of one-liners. So I don't think that suggested text, that it was added slowly, is appropriate. If this account is correct, it was pretty atomic. It sounds more the correct answer to the stuff in the source is the one proposed, that it got added to the assembler version of the system before it was done in the C version. Noel

8 years, 7 months

Re: [TUHS] Pipes in the Third Edition Unix

by Norman Wilson

Warren: Can anybody help explain the "not in assembler" comment? ==== I think it means `as(1) has predefined symbols with the numbers of many system calls, but not this one.' Norman Wilson Toronto ON

8 years, 7 months

Looking for two papers someone may have

by ron minnich

I recall reading a long time ago a sentence in a paper Dennis wrote which went something like "Unix is profligate with processes". The word profligate sticks in my mind. This is a 30+-year-old memory of a probably 35+-year-old paper, from back in the day when running a shell as a user level process was very controversial. I've scanned the papers (and BSTJ) I can find but can't find that quote. Geez, is my memory that bad? Don't answer that! Rob Pike did a talk in the early 90s about right and wrong ways to expose the network stack in a synthetic file system. I'd like to find those slides, because people keep implementing synthetics for network stacks and they always look like the "wrong" version from Rob's slides. I've asked him but he can't find it. I've long since lost the email with the slides, several jobs back ... thanks ron

8 years, 7 months

Re: [TUHS] Unix stories

by Doug McIlroy

> In one of his books, Wirth laments about programmers proudly > showing him terrible code written in Pascal For your amusement, here's Wirth himself committing that sin: http://www.cs.dartmouth.edu/~doug/wirth.pdf

8 years, 7 months

Another Unix hacker passes

by Larry McVoy

Mr /proc. RIP, Roger. He would have loved this list. http://thenewstack.io/remembering-roger-faulkner/ https://news.ycombinator.com/item?id=13293596

8 years, 7 months

Re: [TUHS] Unix stories

by jnc＠mercury.lcs.mit.edu

> From: Nick Downing > way overcomplicated and using a very awkward structure of millions of > interdependent C++ templates and what-have-you. > ... > the normal standard use cases that his group have tested and made to > work by extensive layers of band-aid fixes, leaving the code in an > incomprehensible state. Which just goes to provide support for my long-term contention, that language features can't help a bad programmer, or prevent them from writing garbage. Sure, you can take away 'goto' and other dangerous things, and add a lot of things that _can_ be used to write good code (e.g. complete typing and type checking), but that doesn't mean that a user _will_ write good code. I once did a lot of work with an OS written in a macro assembler, done by someone really good. (He'd even created macros to do structure declarations!) It was a joy to work with (very clean and simple), totally bug-free; and very easy to change/modify, while retaining those characteristics. (I modified the I/O system to use upcalls to signal asynchronous I/O completion, instead of IPC messages, and it was like falling off a log.) Thinking we can provide programming tools/languages which will make good programmers is like thinking we can provide sculpting equipment which will make good sculptors. I don't, alas, have any suggestions for what we _can_ do to make good programmers. It may be impossible (like making good sculptors - they are born, not made). I do recall talking to Jerry Saltzer about system architects, and he said something to the effect of 'we can run this stuff past students, and some of them get it, and some don't, and that's about all we can do'. Noel

8 years, 7 months

Re: [TUHS] Another Unix hacker passes

by Berny Goodheart

Very sad news. RIP Roger.

8 years, 7 months

Historic Linux versions not on kernel.org

by Warner Losh

I have a ImageMagic CD that I got back in 1994 that I found in my garage. It has a bunch of versions of linux that aren't on kernel.org. The 0.99 series, the 0.98 series and what looks like 1.0 alpha pl14 and pl15. Is anybody here interested in them? I have fallen out of contact with the Linux folks, so don't know if anybody on kernel.org would be interested in these. Does anybody care? Warner

8 years, 7 months

Re: [TUHS] 2.11BSD on a Z180 (was: merry christmas)

by Johnny Billquist

On 2016-12-29 03:00, Nick Downing <downing.nick(a)gmail.com> wrote: > I will let you know when I get > it working :) It's not a current focus, but I will return to it someday. > In the meantime, I'm putting it on bitbucket, so others will be able to > pick it up if they wish. However, this also isn't my current focus, it's > there, but it's not documented. > > The IAR compiler on the Z180 supports a > memory model similar to the old "medium" memory model that we used to > use with Microsoft or Turbo C on DOS machines, that is, multiple code > segments with a single data segment. Yes, the Z180 compiled C code is > larger than the PDP-11 compiled C code, but luckily you can have > multiple code segments, which you cannot (easily) have on the PDP-11. > > Unfortunately code and data segments share the same 64 kbyte logical > address space, so what I did was to partition the address space into 4 > kbytes (always mapped, used for interrupt handlers, bank switching > routines, IAR compiler helper routines, etc), 56 kbytes (kernel or > current process data and stack) and 4 kbytes (currently executing > function). The currently executing function couldn't be more than 4 > kbytes and couldn't cross a physical 4 kbyte boundary due to the > hardware mapping granularity, but this was acceptable in practice. > > I got > the Unix V7 clone working OK under this model and then added the > networking, so although it was a bit of a dogs breakfast, it proves the > concept works. My memory management left a fair bit to be desired (too > much work to fix) however I think porting 2.11BSD would solve this > problem since it works in the PDP-11 under split I/D, which has similar > constraints except the 4 kbyte code constraint. My understanding is > 2.11BSD is actually a cut down 4.3BSD running on the HAL from 2.xxBSD, I > would like to audit each change from 4.3BSD to make sure I agree with > it, so essentially my project would be porting 4.3BSD rather than > 2.11BSD. But I'd take the networking stack and possibly a lot more code > from 2.11BSD, since it is simplified, for instance the networking stack > does not use SYN cookies. cheers, Nick Having written quite some code on the Z180, as well as god knows how much code on the PDP-11, I'm going to agree with Peter Jeremy in that I do not believe 2.11BSD can be made to run on a Z180. (Well, of course, anything is possible, you could just write a 68000-emulator, for example, but natively... no.) Unix V7 is miles from 2.11BSD. Unix V7 can run on very modest PDP-11 models. 2.11BSD cannot be made to run on a PDP-11 without split I/D space, which effectively gives you 128K of address space to play with, in addition to the overlaying done with the MMU remappings. The MMU remappings might be possible to emulate enough with the segment registers of the Z180 for the Unix needs, but the split I/D space just won't happen. 2.9BSD was the last version (I believe) which ran on non split-I/D machines. Johnny > > On Wed, Dec 28, 2016 at 6:14 PM, Peter Jeremy <peter(a)rulingia.com> wrote: >> On 2016-Dec-25 17:21:31 -0500, Steve Nickolas <usotsuki(a)buric.co> wrote: >>> On Mon, 26 Dec 2016, Nick Downing wrote: >>>> I became frustrated with the limitations of both UZI and NOS and decided to >>>> port 2.11BSD to the cash register as the next step, my goal was (a) make it >>>> cross compile from Linux to PDP-11, (b) check it can build an identical >>>> release tape through cross compilation, (c) port it to Z80 using my >>>> existing cross compiler. >>> A Z180 is powerful enough to run 2.11BSD? o.o; >> I suspect shoe-horning 2.11BSD onto a Z180 would be difficult - 2.11BSD >> on a PDP-11 requires split I+D and has kernel and userland in separate >> address spaces. Even with that, keeping the non-overlay part of the >> kernel in 64KB is difficult. Equivalent Z180 code is going to be much >> larger than PDP-11 code. >> >> I'd be happy to be proved wrong. >> >> -- >> Peter Jeremy -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

8 years, 7 months

Other people I'd like to see on this list

by Arnold Robbins

Since Larry started the wish-listing of people we'd like to see on the list, I'll add mine: * Doug Gwynn * Chris Torek * Guy Harris Anyone know how to track down any of these folks? My two cents. :-) Happy New Year everyone, Arnold

8 years, 7 months

merry christmas

by Larry McVoy

As Neil Young said when he played with the band, it's been of one of the great joys of my life to be here with you (yeah, I paraphrased). As a kid who wanted to be at Bell Labs, a student who got the troff manual and used it for the next 30 years, a student who got an account on the vax 11/750 that had the BSD source on it and learned so much, I just want to thank all of the Bell Labs people for being here and Warren for putting this list together and for Unix teaching me so much. If I could have one thing for Christmas it would be bwk joining the list. I did some extensions to awk and asked him about it and he tarred up ~bwk/awk and sent it to me. I've got the awk source and the book source in english and french (I think). Brian is awesome, it would be cool to have him on this list. All that said, I super grateful to be here amongst the people who were there when you got an image from Ken. You guys are lucky. --lm

8 years, 7 months

Musings on PDP-7 Unix

by Warren Toomey

[ This whole article is just a flight of fancy; feel free to ignore it or at least treat it as the whimsy that it is. ] The PDP-7 Unix system is the first step on the evolution of Unix as we know it. We have a snapshot of the system around the end of 1970/beginning of 1971 at http://www.tuhs.org/Archive/PDP-11/Distributions/research/McIlroy_v0/ and a reconstructed and working partial system at https://github.com/DoctorWkt/pdp7-unix PDP-7 Unix was a playground for Ken, Dennis and others to try out ideas and implementations, and it was quickly superseded by 1st Edition PDP-11 Unix. Details of how it evolved are at https://www.bell-labs.com/usr/dmr/www/hist.html and https://www.bell-labs.com/usr/dmr/www/chist.html All fine and good. However, I keep wondering, how far could they have taken Unix on the PDP-7 platform? The Kernel ---------- The reconstructed kernel only occupies 3070 words of 4096 words available, so there is room left for more code. There is already an alternative reconstruction where the "dd" concept has been replaced with the ".." concept (see https://github.com/DoctorWkt/pdp7-unix/tree/master/src/alt) PDP-7 Unix doesn't have the concept of absolute or relative filenames (e.g. /usr/bin/ls or a/b/c or ../../file), Could the nami kernel function be modified to do this? It would probably mean changing from two characters packed into a word to a single character per word (to make searching for '/' easier), and this would turn it into something more recognisable as Unix. What about pipes? They should not be too hard to implement. Even sixteen pipes with a 16-word buffer each would only be 256+ extra data words in the kernel. And a hundred words of code? There are only a few special devices in the kernel: ttyin, ttyout, keyboard, display, pptin, pptout. What about a disk block device? Was there a PDP-7 tape device, and if so, why not a tape driver and block device? Filesystem ---------- The implementation of the filesystem is, in some places, quite inefficient. The free block list is implemented as follows. In each block, there are 10 free block numbers then a pointer to the next part of the free list. However, each block can hold 64 block numbers, so why are only 10 free block numbers stored in each block? By using the whole of a block to store free block numbers, there would actually be more free blocks to use! Each i-node (size 12 words, 7 of which are direct or indirect pointers) has one word which holds a unique value. This doesn't seem to be used at all. If it was reused as a block pointer, this would allow files to be up to 8*64=512 (small) or 8*64*64=32768 (large) words in length, instead of 7*64=448 words (small) or 7*64*64=28672 (large) words. The system is set up to only use one side of the two-sided disk device. It looks like the other side was used to backup (snapshot) a working system in case of catastrophic filesystem corruption: they could simply copy the blocks from the "snapshot" side back to the working side. We could double the size of the filesystem quite easily. Macro Assembler --------------- The kernel is written using fairly tight assembly code, and there probably isn't a way to translate it into a high-level language. The PDP-7 has an arcane instruction set, and the existing assembler syntax is nothing special. What about a macro assembler that makes it easier to write code, especially readable code? Here are some ideas based on the existing kernel: u.rq := 8 ==> lac 8; dac u.rq function swap ==> swap: 0 { return; jmp swap i } subroutine .fork ==> fork: line 1 // i.e. not a function { line 1 } loop ==> 1: { } jmp 1b if (sad dm1) ==> sad dm1 { jmp 1f code1 code1 } else { 1: code2 code2 } betwen(o101,o132) ==> jms betwen; o101; o132 There are probably a bunch more that could be added. The aim is to make the control structures easier to read and write. The programmer still has to grok the PDP-7 instruction set. B (or other) Language --------------------- PDP-7 Unix has a B compiler while compiles source down to a virtual instruction set which is interpreted by the B interpreter. We have the B interpreter code, and Robert Swierczek managed to rewrite the B compiler, see https://github.com/DoctorWkt/pdp7-unix/blob/master/src/other/b.b At first glance, the PDP-7 architecture is not that amenable to high level languages, but it turns out that it is indeed possible to write a compiler for a C subset that targets the PDP-7, see https://github.com/DoctorWkt/a-compiler. So, could the B compiler be modified to actually output PDP-7 assembly code? If so, we could rewrite the utilities (cp, mv, ls etc.) in a high-level language and make the system easier to maintain. I would recommend treating int and char as the same and only storing one char per word. And then, even though the PDP-7 architecture doesn't support it, how hard would it be to add int/char types and bring the language one step closer to C? Conclusion ---------- All of this is pie in the sky. It can certainly be done, but a) who has the time and b) it would be a "tour de force", nothing really useful. But imagine if, at the beginning of 1970, Unix had a proper B or C compiler, utilities written in this high-level language, a kernel written in a semi-high level language, and a system with pipes and proper pathnames. Cheers, Warren

8 years, 7 months

Leap Second

by Dave Horsfall

Let me be the first to say that the International Earth Rotation Service has announced that there will be a Leap Second inserted at 23:59:59 UTC on the 31st December, due to the earth slowly slowing down. It's fun to listen to see how the time beeps handle it; will your GPS clock display 23:59:60, or will it go nuts like my last one did (I had to power cycle the thing)? My recording of the last one: horsfall.org/leapsecond.webm . -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

8 years, 8 months

tuhs@minnie.tuhs.org Re: User maintained programs in the Second Edition

by Doug McIlroy

> So was "/usr/bin" initially only for user-contributed binaries, or was it from its inception a place for binaries that were not essential for system boot and could not fit in the root partition? The latter is my understanding, but early on the two interpretations would have been nearly coextensive. Remember, though, that even Ken wrote some "user-contributed" code. Doug

8 years, 8 months

Re: [TUHS] phototypesetter C (was nm on Third Edition .o files)

by jnc＠mercury.lcs.mit.edu

> I don't think I ever heard the appellation "phototypesetter C" > before. Interesting data point; thanks for passing that along. > Certainly C and the phottypesetter developed independently, though in > the same room. But the explanation that they got linked by appearing in > the same tape release makes perfect sense. I have this vague memory of being told, or reading somewhere, that many of the changes from 'vanilla V6' C to 'phototypsetter' C were added because they were needed for that project, hence the name. Alas, I have no idea where I might have gotten that from (I had a quick look at a few likely documentary sources, but no joy). It's quite possible that this was a supposition on someone outside Bell's part (or perhaps inside Bell, but outside the Unix group), because the two came out in the same tape. Reading the notes about the upgrades (in particular, "newstuff.nr") makes it seem like a more likely driver of _some_ of the changes was the Interdata port (which was also happening at around the same time, if I have the timeline correct). And of course some might have been driven by general utility (e.g. the ability to initialize structures). It would be interesting to see if anyone remembers why these changes were made. Noel

8 years, 8 months

Validating the s2-bits tape epoch

by Diomidis Spinellis

The document http://www.tuhs.org/Archive/PDP-11/Distributions/research/1972_stuff/Readme discusses the uncertainty regarding the epoch used for the file timestamps. "The biggest problem here is to pin down the epoch for the files. In the early version of UNIX, timestamps were in 1/60th second units. A 32-bit counter using these units overflows in 2.5 years, so the epoch had to be changed periodically, and I believe 1970, 1971, 1972 and 1973 were all epochs at one stage or another." "Given that the C compiler passes, and the library, are dated in June of the epoch year, and that Dennis has said ``1972-73 were the truly formative years in the development of the C language'', it's therefore unlikely that the epoch for the s2 tape is 1971: it is more likely to be 1972. The tape also contains several 1st Edition a.out binaries, which also makes it unlikely to be 1973." "Therefore, Warren's decoding of the s2-bits file, in s2-bits.tar.gz, uses 1972 as the epoch. However, Dennis decoding in s2.tar.gz uses 1973." "Finally, the date(1) a.out on the tape uses 1971 as its archive. How annoying! After a bit of discussion, Dennis and Warren have agreed that 1972 is the most probable epoch for s2-bits." I thought I could validate the epoch by looking at the distribution of weekdays for the three alternative years (1971 to 1973). Here are the results. wget http://www.tuhs.org/Archive/PDP-11/Distributions/research/1972_stuff/Readme for guess in 1971 1972 1973 ; do echo $guess EPOCH=$(date +'%s' -d "$guess/01/01 00:00 UTC") awk '/\/core/,/\/etc\/init/ { if ($9) print strftime("%a", '$EPOCH' + $9 / 60)}' Readme | sort | uniq -c | sort -n done 1971 1 Sat 6 Mon 8 Thu 8 Tue 17 Fri 21 Wed 34 Sun 1972 1 Sun 6 Tue 8 Fri 8 Wed 17 Sat 21 Thu 34 Mon 1973 1 Tue 6 Thu 8 Fri 8 Sun 17 Mon 21 Sat 34 Wed As you can see, unless weekends at the Bell Labs were highly atypical, 1972 has the most probable distribution of work among the days of the week.

8 years, 8 months

Utility of C changes (Was: phototypesetter C)

by jnc＠mercury.lcs.mit.edu

> of course some [of the changes to C in this time period] might have been > driven by general utility (e.g. the ability to initialize structures). I was thinking about this, with my memory of the changes refreshed by re-reading those 'changes to C' notes, and it's interested how many of them were ones I personally (and most of the people working with me) didn't use. Here is a list of the changes described in those 3 documents: 'newstuff': - Longs - Unsigneds - Blocks (locals declared inside a non-top-level {} pair) - Initialization of structures - Initialization of automatic variables - Bit fields - Macro functions - Macro conditionals (#ifdef) - Arguments in registers - Typedefs - 'Static' scope 'Changes': - Multi-line macros - Undefine - Conditional expressions (#if) - Unions - Casts - Sizeof() on abstractions - '=' in initializations - Change binary operators from trailing to leading - 'extern' does not allocate storage (This note also includes unsigneds, blocks, and structure initializations, from the earlier? note.) 'cchanges': - Structure assignment and argument/return-value - Enum Of these, I never really used quite a few: blocks, automatic initializations, typedefs, unions, structure assignment/etc, or enum. I'm not sure if I ever used bit fields, either. Some of these are understandable; e.g. automatic initializations are just syntactic sugar (as are register arguments, but I did use those). Typedef is also effectively syntactic sugar; you can always use a macro and get almost (entirely?) the same result. In fact, I devised an entire system of types to make the code I was working on (almost entirely networking code, so lots of packet headers from other machines, etc) more rigorous - and later it turned out it had made it much more portable; it all used macros, not typedef. I don't think I ever used typedef... (The details of that might be of some interest: instead of int, long, etc we had things of the form {type}{len}, where {type}pe} was 'int', 'uns', 'bit', etc and length was 'b', 's', 'l', or two other interesting ones 'w' and 'f' - 'w' meant the machine's native word length, and 'f' meant whatever was fastest on the machine. So 'unsl' mean '32-bit unsigned'. Depending on the machine, the compiler couldn't always produce them all - e.g. the PDP-11 didn't have unsl - so sometimes you had to live with non-optimal replacements. There were also un-typed types, i.e. 'byte', 'swrd', 'lwrd' - 8, 16 and 32 bits - and 'word' - the machine's native length.) Unions didn't get used much either, in our stuff, although one would think it would be useful in network code - you get a packet with a pile of bits inside it, which can be one of N different formats, seems like a perfect application for a union. The problemis that it tied two different subsystems intimately together. If you have protocol A and protocol B, if you use a union to define the header format, the union has to have both A and B in it. Now if you want to add protocol C, that requires modifying that union definition. It was much easier to just take a pointer to the outer packet's data area, and assign (with cast) it to a new pointer variable which was of the correct type for the header you were trying to process. Some of the new things were incredibly useful, though - or, in fact, one couldn't get by without them. Casts were incredibly useful once the compiler got pickier. Initialization of structures was huge - other than 'bdevsw'-like hacks, there was just no other way to do that. Noel

8 years, 8 months

Re: [TUHS] User maintained programs in the Second Edition

by Doug McIlroy

> Does anyone remember whether at the time these were installed in the > system-wide /bin directory, Those that I remember were in /usr/bin. Doug

8 years, 8 months

Re: [TUHS] Dennis' Draft of the Unix Timesharing System: not so draft?

by jnc＠mercury.lcs.mit.edu

> From: Warren Toomey > Ritchie, D.M. The UNIX Time Sharing System. MM 71-1273-4. > which makes me think that the draft version Doug McIlroy found Not really a response to your question, but I'd looked at that 'UnixEditionZero' and was very taken with this line, early on: "the most important features of UNIX are its simplicity [and] elegance" and had been meaning for some time to send in a rant. The variants of Unix done later by others sure fixed that, didn't they? :-( On a related note, great as my respect is for Ken and Doug for their work on early Unix (surely the system with the greatest bang/buck ratio ever), I have to disagree with them about Multics. In particular, if one is going to have a system as complex as modern Unices have become, one might as well get the power of Multics for it. Alas, we have the worst of both worlds - the size, _without_ the power. (Of course, Multics made some mistakes - primarly in thinking that the future of computing lay in large, powerful central machines, but other aspects of the system - such as the single-level store - clearly were the right direction. And wouldn't it be nice to have AIM boxes to run our browers and mail-readers in - so much for malware!) Noel

8 years, 8 months

User maintained programs in the Second Edition

by Diomidis Spinellis

The Second Edition manual has a section titled "User Maintained Programs" listing the following utilities and games: basic, bc, bj, cal, chash, cre, das, dli, dpt, moo, ptx, tmg, and ttt. In the Introduction, the reader is asked to consult their authors for more information. Does anyone remember whether at the time these were installed in the system-wide /bin directory, or whether they were only available in their owners' home directories?

8 years, 8 months

14 new TUHS members

by Warren Toomey

All, I've just got back from a few days away to find 14 new subscription requests to the TUHS mailing list. Welcome aboard to you all. Normally I only get one request a month, so I have some concerns about the legitimacy of all these requests, so accept my apologies in advance if there is any off-topic e-mails in the next few days. P.S The mail while I was away was very interesting. Noel, you might also be interested in the B interpreter and Robert Swierczick's B compiler the PDP-7 Unix. The original B compiler doesn't exist, so Robert took the 11/20 C compiler and "undid" the code that does types so that it "became" a B compiler. https://github.com/DoctorWkt/pdp7-unix/tree/master/src/other Cheers all Warren

8 years, 8 months

Happy birthday, Tommy Flowers!

by Dave Horsfall

Tommy Flowers MBE was born on this day in 1905; amongst other things he designed Colossus, the world's first programmable electronic computer, which was used to break the German Lorenz cipher (not Enigma, as some think). Relevance to Unix? Well, without the world's first usable computer we would not have the world's first usable OS, and M$ would probably reign supreme by now... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

8 years, 8 months

Re: [TUHS] nm on Third Edition .o files?'

by jnc＠mercury.lcs.mit.edu

> More here: > http://minnie.tuhs.org/pipermail/tuhs/2014-October/005218.html Which sez: There is a second document, untitled, no date, which I have not been able to locate online at all. .. From the content, it seems to be from shortly after the previous one, so say, circa 1977. I poked around in a dump of the CSR Unix which I now have available to me, and found a copy of it. I just checked the Internet (using the canonical search engine) for various phrases from it, but I still could not turn it up. So, here it is in machine-readable form: http://ana-3.lcs.mit.edu/~jnc/history/unix/CChanges.txt Hope this is some use to someone... :-) Noel

8 years, 8 months

phototypesetter C (was nm on Third Edition .o files)

by Doug McIlroy

Amusing, I don't think I ever heard the appellation "phototypesetter C" before. Certainly C and the phottypesetter developed independently, though in the same room. But the explanation that they got linked by appearing in the same tape release makes perfect sense. Thanks for the tidbit. Doug

8 years, 8 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS