From clemc at ccc.com Thu Jan 9 02:02:41 2020 From: clemc at ccc.com (Clem Cole) Date: Wed, 8 Jan 2020 11:02:41 -0500 Subject: [COFF] [TUHS -> moving to COFF] # and the Preprocessor Message-ID: below... -- warning veering a little from pure UNIX history, but trying to clarify what I can and then moving to COFF for follow up. On Wed, Jan 8, 2020 at 12:23 AM Brian Walden wrote: > .... > > - CMU's ALGOL68S from 1978 list all these ways -- > co comment > comment comment > pr pragmat > pragmat pragmat > # (comment symbol) comment > :: (pragmat symbol) pragmat > (its for UNIX v6 or v7 so not surprising # is a comment) > http://www.softwarepreservation.org/projects/ALGOL/manual/a68s.txt/view Be careful of overthinking here. The comment in that note says was it was for* PDP-11's *and lists V6 and V7 was *a possible target*, but it did not say it was. Also, the Speach and Vision PDP-11/40e based systems ran a very hacked v6 (which a special C compiler that supported CMU's csv/cret instructions in the microcode), which would have been the target systems. [1] To my knowledge/memory, the CMU Algol68 compiler never ran anywhere but Hydra (and also used custom microcode). IIRC there was some talk to move it to *OS (Star OS for CM*) I've sent a note to dvk to see if he remembers it otherwise. I also ask Liebensperger what he remembers, he was hacking on *OS in those days. Again, IIRC Prof. Peter Hibbard was the mastermind behind the CMU Algol68 system. He was a Brit from Cambridge (and taught the parallel computing course which I took from him at the time). FWIW: I also don't think the CMU Algol68 compiler was ever completely self-hosting, and like BLISS, required the PDP-10 to support it. As to why it was not moved to the Vax, I was leaving/had left by that time, but I suspect the students involved graduated and by then the Perq's had become the hot machine for language types and ADA would start being what the gvt would give research $s too. > > > ... > > But look! The very first line of that file! It is a single # sitting all > by itself. Why? you ask. Well this is a hold over from when the C > preprocessor was new. C orginally did not have it and was added later. > PL/I had a %INCLUDE so Ritchie eventaully made a #include -- but pre 7th > Edition the C preprocessor would not be inkoved unless the very first > character of the C source file was an # > That was true of V7 and Typesetter C too. It was a separate program ( /lib/cpp) that the cc command called if needed. > Since v7 the preprocessor always run on it. The first C preprocessor was > Ritchie's work with no nested includes and no macros. v7's was by John > Reiser which added those parts. > Right, this is what I was referring too last night in reference to Sean comments. As I said, the /bin/cc command was a shell script and it peaked at the first character to see if it was #. I still find myself starting all C programs with a # on a line by itself ;-) Note that the Ritchie cpp was influenced by Brian's Ratfor work, so using # is not surprising. This leads to a question/thought for this group, although I think needs to move to COFF (which I have CC'ed for follow up). I have often contended, that one of the reasons why C, Fortran, and PL/1 were so popular as commercial production languages were because they could be preprocessed. For a commercial place where lots of different targets is possible, that was hugely important. Pascal, for instance, has semantics that makes writing a preprocessor like cpp or Ratfor difficult (which was one of the things Brian talks about in his "*Why Pascal is not my favorite Programming Language *" paper). [2] So, if you went to commercial ISV's and looked at what they wrote in. It was usually some sort of preprocessed language. Some used Ratfor like a number of commercial HPC apps vendors, Tektronix wrote PLOT10 in MORTRAN. I believe it was Morgan-Stanley had a front-end for PL/1, which I can not recall the name. But you get the point ... if you had to target different runtime environments, it was best for your base code to not be specific. However ... as C became the system programming language, the preprocessor was important. In fact, it even gave birth the other tools like autoconfig to help control them. Simply, the idiom: #ifdef SYSTEMX #define SOME_VAR (1) ... do something specific #endif /* SYSTEMX */ While loathsome to read, it actually worked well in practice. That fact is I hate the preprocessor in many ways but love it for what it for the freedom it actually gave us to move code. Having programmed since the 1960s, I remember how hard it was to move things, even if the language was the same. Today, modern languages try to forego the preprocessor. C++'s solution is to throw the kitchen sink into the language and have 'frameworks', none of which work together. Java's and its family tries to control it with the JVM. Go is a little too new to see if its going to work (I don't see a lot of production ISV code in it yet). Note: A difference between then and now, is 1) we have few target architectures and 2) we have fewer target operating environments, 3) ISV don't like multiple different versions of their SW, they much prefer very few for maintenance reasons so they like # 1 and #2 [i.e. Cole's law of economics in operation here]. So ... my question, particularly for those like Doug who have programmed longer and at least as long as I, what do you think? You lived the same time I did and know the difficulties we faced. Is the loss of a preprocessor good or bad? Clem [1] Historical footnote about CMU. I was the person that brought V7 into CMU and I never updated the Speach or Vision systems and I don't think anyone did after I left. We ran a CMU V7 variant mostly on the 11/34s (and later on a couple of 11/44s I believe) that had started to pop up. Although later if it was a DEC system, CS was moving to Vaxen when they could get the $s (but the Alto's and Perq's had become popular with the CMU SPICE proposal). Departments like bio-engineering, mech ee, ran the cheaper systems on-site and then networked over the Computer Center's Vaxen and PDP-20's when they needed address space). [2] Note: Knuth wrote "Web" to handle a number of the issues, Kernighan talks about - but he had to use an extended Pascal superset and his program was notable for not being portable (he wrote for it for the PDP-10 Pascal). [BTW: Ward Cunningham, TW Cook and I once counted over 8 different 'Tek Pascal' variants and 14 different 'HP Basics']. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Fri Jan 10 01:54:44 2020 From: clemc at ccc.com (Clem Cole) Date: Thu, 9 Jan 2020 10:54:44 -0500 Subject: [COFF] [TUHS] screen editors In-Reply-To: <202001090423.0094NooZ379407@darkstar.fourwinds.com> References: <20200109012830.GC16808@mcvoy.com> <20200109020720.GG16808@mcvoy.com> <202001090423.0094NooZ379407@darkstar.fourwinds.com> Message-ID: Answering, but CCing COFF if folks want to continue. This is less about UNIX and more about how we all got to where we are. On Wed, Jan 8, 2020 at 11:24 PM Jon Steinhart wrote: > Clem, this seems like an unusual position for you to take. vim is > backwards > compatible with vi (and also ed), so it added to an existing ecosystem. > No, really unusually when you think about it. vim is backward compatible except when it's not (as Bakul points out) - which is my complaint. It's *almost* compatible and those small differences are really annoying when you expect one thing and get something else (*i.e.* the least astonishment principle). The key point here is for *some people*, those few differences are not an issue and are not astonished by them. But for *some of the rest of us* (probably people like me that have used the program since PDP-11 days) that only really care about the original parts, the new stuff is of little value and so the small differences are astonishing. Which comes back to the question of good and best. It all depends on one what you value/where you put the high order bit. I'm not willing to "pay" for the it; as it gives me little value. Doug started this thread with his observation that ex/vi was huge compared to other editors. * i.e.* value: small simple easy to understand (Rob's old "*cat -v considered harmful*" argument if you will). The BSD argument had always been: "the new stuff is handy." The emacs crew tends to take a similar stand. I probably don't go quite as far as Rob, but I certainly lean in that direction. I generally would rather something small and new that solves a different (set of) problem(s), then adding yet another wart on to an older program, *particularly when you change the base functionality *- which is my vi *vs. *vim complaint*.* [i.e. 'partial credit' does not cut it]. To me, another good example is 'more', 'less' and 'pg'. Eric Schienbrood wrote the original more(ucb) to try to duplicate the ITS functionality (he wrote it for the PDP-11/70 in Cory Hall BTW - Ernie did not exist and 4.1BSD was a few years in the future - so small an simple of a huge value). It went out in the BSD tapes, people loved it and were happy. It solved a problem as we had it. Life was good. Frankly, other than NIH, I'm not sure why the folks at AT&T decided to create pg a few years later since more was already in the wild, but at least it was a different program (Mary Ann's story of vi *vs*. se if probably in the same vein). But because of that behavior, if someone like me came to an AT&T based system with only pg installed, so those of us that liked/were used to more(ucb) could install it and life was good. Note pg was/is different in functionality, it's similar, but not finger compatible. But other folks seem to have thought neither was 'good enough' -- thus later less(gnu) was created adding a ton of new functionality to Eric's program. The facts are clear, some (ney many) people >>love<< that new functionality, like going backward. I >>personally<< rarely care/need for it, Eric's program was (is) good enough for me. Like Doug's observation of ed *vs.* ex/vi; less is huge compared to the original more (or pg for that matter). But if you value the new features, I suspect you might think that's not an issue. Thanks to Moore's law, the size in this case probably does not matter too much (other than introducing new bugs). At least, when folks wrote did Gnu's less, the basic more(ucb) behavior was left along and if you set PAGER=more less(gnu) pretty much works as I expect it too. So I now don't bring Eric's program with me, the same way Bakul describes installing nvi on new systems (an activiity I also do). Back to vi *vs.* nvi *vs.* vim *et. al.* Frankly, in my own case, I do >>occaisonally<< use split screens, but frankly, I can get most of the same from having a window manager, different iterm2 windows and cut/paste. So even that extension to nvi, is of limited value to me. vim just keeps adding more and more cruft and its even bigger. I personally don't care for the new functionality, and the size of it all is worrisome. What am I buying? That said, if the new features do not hurt me, then I don't really care. I might even use some of the new functionality - hey I run mac OS not v7 or BSD 4.x for my day to day work and I do use the mac window manager, the browser *et al*, but as I type this message I have 6 other iterm2 windows open with work I am doing in other areas. Let me take a look at this issue in a different way. I have long been a 'car guy' and like many of those times in my youth spent time and money playing/racing etc. I've always thought electric was a great idea/but there has been nothing for me. Note: As many of you know my work in computers has been in HPC, and I've been lucky to spend a lot of time with my customers, in the auto and aerospace industry (*i.e.* the current Audi A6 was designed on one of my supercomputer systems). The key point is have tended to follow technology in their area and tend to "in-tune" with a lot of developments. The result, except for my wife's minivan (that she preferred in the years when our kids were small), I've always been a die-hard German-engineered/performance car person. But when Elon announced the Model 3 (like 1/2 the techie world), I put down a deposit and waited. Well why I was waiting, my techie daughter (who also loves cars), got a chance to drive one. She predicted I would hate it!!! So when my ticket finally came up, I went to drive them. She was right!!! With the Model 3, you get a cool car, but it's about the size of a Corrolla. Coming from Germans cars for the last 35 years, the concept of spending $60K US in practice for a Corrolla just did not do it for me. I ended up ordering the current Unixmobile, my beloved Tesla Model S/P100D. The truth is, I paid a lot of money for it but I *value *what I got for my money. A number of people don't think it's worth it. I get that, but I'm still happy with what I have. Will there someday be a $20K electric car like my Model S? While I think electric cars will get there (I point out the same price curve on technology such microwave ovens from the 1970so today), but I actually doubt that there will be a $20K electric vehicle like my Model S. The reason is that to sell this car because it as to be expensive for technology-based reasons, so Tesla had to add a lot of 'luxury' features like other cars in the class, other sports cars, Mercedes, *et al*. As they removed them (*i.e.* the Model 3) you still get a cool car, but it's not at all the same as the Model S. So the point is, if I wanted an electric car, I had to choose between a performance/luxury *vs*. size/functionality. I realized I valued the former (and still do), but I understand not everyone does or will. Coming back to our topic, I really don't think this is a 'get my lawn' issue as much, as asking someone what they really value/what they really need. If you place a high-value you something, you will argue that its best; if it has little value you will not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Fri Jan 10 06:01:34 2020 From: clemc at ccc.com (Clem Cole) Date: Thu, 9 Jan 2020 15:01:34 -0500 Subject: [COFF] [TUHS] screen editors In-Reply-To: <20200109190219.bdHOi%steffen@sdaoden.eu> References: <20200109012830.GC16808@mcvoy.com> <20200109020720.GG16808@mcvoy.com> <202001090423.0094NooZ379407@darkstar.fourwinds.com> <20200109190219.bdHOi%steffen@sdaoden.eu> Message-ID: Steffen - I think your reply just proved my point. I am as asking people what they really value/what they really need. Clearly, you and I value different things. And that is fine. You can disagree with my choices, but accept it is what *I value*, and I understand *you value something different*. FWIW: I will not identify who sent it me because he sent it to me privately, but someone else commented to me on my post that I had nailed it. He observed "I see this sort of not respecting other people's choices as a general trend these days. We want tolerance for our *views* but at the same time, we are becoming more intolerant of *other* people's views!" For a smile, this was yesterdays comic and expresses the issue well: https://www.comicskingdom.com/brilliant-mind-of-edison-lee/2020-01-08 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Sat Jan 11 03:45:51 2020 From: lars at nocrew.org (Lars Brinkhoff) Date: Fri, 10 Jan 2020 17:45:51 +0000 Subject: [COFF] [TUHS] Tech Sq elevator In-Reply-To: <20200110172747.90BDE18C09E@mercury.lcs.mit.edu> (Noel Chiappa's message of "Fri, 10 Jan 2020 12:27:47 -0500 (EST)") References: <20200110172747.90BDE18C09E@mercury.lcs.mit.edu> Message-ID: <7wd0brmchc.fsf@junk.nocrew.org> Noel Chiappa writes: > The code is still extant, in 'SYSTEM; TV >'. It only worked (I think) > from Knight TV keyboards (This isn't TUHS material, but I can't resist. CC to COFF.) There is also a Chaosnet service to call for the elevator or open the door, so it can be used remotely. The ITS program ESCE uses this service. I suppose there must have been something for the Lisp machines too, maybe even a Super-Hyper-Cokebottle keyboard command. From wkt at tuhs.org Mon Jan 13 10:49:12 2020 From: wkt at tuhs.org (Warren Toomey) Date: Mon, 13 Jan 2020 10:49:12 +1000 Subject: [COFF] [TUHS] Tech Sq elevator [ really type-checking ] In-Reply-To: <202001130044.00D0ilcV616661@darkstar.fourwinds.com> References: <202001122225.00CMPc9S085970@tahoe.cs.Dartmouth.EDU> <202001122340.00CNeef0604557@darkstar.fourwinds.com> <202001130044.00D0ilcV616661@darkstar.fourwinds.com> Message-ID: <20200113004912.GA27610@minnie.tuhs.org> All, can we move this not-really-Unix discussion to COFF? Thanks, Warren P.S A bit more self-regulation too, please. You shouldn't need me to point out when the topic has drifted so far :-) From crossd at gmail.com Mon Jan 13 11:23:11 2020 From: crossd at gmail.com (Dan Cross) Date: Sun, 12 Jan 2020 20:23:11 -0500 Subject: [COFF] [TUHS] Tech Sq elevator [ really type-checking ] In-Reply-To: References: <202001122225.00CMPc9S085970@tahoe.cs.Dartmouth.EDU> <202001122340.00CNeef0604557@darkstar.fourwinds.com> Message-ID: -TUHS, +COFF, in line with Warren's wishes. On Sun, Jan 12, 2020 at 7:36 PM Bakul Shah wrote: > There is similar code in FreeBSD kernel. Embedding head and next ptrs > reduces > memory allocation and improves cache locality somewhat. Since C doesn't > have > generics, they try to gain the same functionality with macros. See > > https://github.com/freebsd/freebsd/blob/master/sys/sys/queue.h > > Not that this is the same as what Linux does (which I haven't dug into) but > I suspect they may have had similar motivation. > I was actually going to say, "blame Berkeley." As I understand it, this code originated in BSD, and the Linux implementation is at least inspired by the BSD code. There was code for singly and doubly linked lists, queues, FIFOs, etc. I can actually understand the motivation: lists, etc, are all over the place in a number of kernels. The code to remove an element from a list is trivial, but also tedious and repetitive: if it can be wrapped up into a macro, why not do so? It's one less thing to mess up. I agree it's gone off the rails, however. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at bitblocks.com Mon Jan 13 11:41:06 2020 From: bakul at bitblocks.com (Bakul Shah) Date: Sun, 12 Jan 2020 17:41:06 -0800 Subject: [COFF] [TUHS] Tech Sq elevator [ really type-checking ] In-Reply-To: Your message of "Sun, 12 Jan 2020 20:23:11 -0500." References: <202001122225.00CMPc9S085970@tahoe.cs.Dartmouth.EDU> <202001122340.00CNeef0604557@darkstar.fourwinds.com> Message-ID: <20200113014113.DB51E156E42E@mail.bitblocks.com> On Sun, 12 Jan 2020 20:23:11 -0500 Dan Cross wrote: > > -TUHS, +COFF, in line with Warren's wishes. > > On Sun, Jan 12, 2020 at 7:36 PM Bakul Shah wrote: > > > There is similar code in FreeBSD kernel. Embedding head and next ptrs > > reduces > > memory allocation and improves cache locality somewhat. Since C doesn't > > have > > generics, they try to gain the same functionality with macros. See > > > > https://github.com/freebsd/freebsd/blob/master/sys/sys/queue.h > > > > Not that this is the same as what Linux does (which I haven't dug into) but > > I suspect they may have had similar motivation. > > > > I was actually going to say, "blame Berkeley." As I understand it, this > code originated in BSD, and the Linux implementation is at least inspired > by the BSD code. There was code for singly and doubly linked lists, queues, > FIFOs, etc. > > I can actually understand the motivation: lists, etc, are all over the > place in a number of kernels. The code to remove an element from a list is > trivial, but also tedious and repetitive: if it can be wrapped up into a > macro, why not do so? It's one less thing to mess up. In late '90s when I first came across code in the FreebSD kernel, as a Scheme-phile I instinctively disliked it. But upon reflection and considering doing it the lisp way -- car,cdr, where car points to a data stucture, I realized this was better, The list way wouldn't have helped and made things worse. Now you may have to either cast the car (whose type would've been void*, which loses type safety) or define data structure specific types and you are back to needing lots of very similar functions. In addition you may now have to lock more data structures to manage these lists. Then consider what happens when an object is on multiple lists. Now you need O(n) operations to remove it from all the lists. And so on. > I agree it's gone off the rails, however. Well, this is "historic unix code" :-) From sauer at technologists.com Wed Jan 15 05:29:52 2020 From: sauer at technologists.com (Charles H Sauer) Date: Tue, 14 Jan 2020 13:29:52 -0600 Subject: [COFF] Glenn Henry's Museum Message-ID: <96ef1017-7f57-046a-620e-7e4cfbc88850@technologists.com> A post in a Facebook IBM retirees group of an IBM PC museum (in Germany?) made be follow up with reference to Glenn's museum. Glenn showed me around the museum last time I saw him at Centaur, but I did not know until today about the Web presence at http://www.glennsmuseum.com/. Rise of the Centaur (https://www.imdb.com/title/tt5690958/) includes Glenn discussing some of the museum. Charlie -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/Skype/Twitter: CharlesHSauer From rudi.j.blom at gmail.com Wed Jan 15 16:09:40 2020 From: rudi.j.blom at gmail.com (Rudi Blom) Date: Wed, 15 Jan 2020 13:09:40 +0700 Subject: [COFF] Glenn Henry's Museum Message-ID: >From the museum pages via the KG-84 picture to wiki. Reading a bit on crypto devices, stumbling over M-209 and "US researcher Dennis Ritchie has described a 1970s collaboration with James Reeds and Robert Morris on a ciphertext-only attack on the M-209 that could solve messages of at least 2000–2500 letters.[3] Ritchie relates that, after discussions with the NSA, the authors decided not to publish it, as they were told the principle was applicable to machines then still in use by foreign governments.[3]" https://en.wikipedia.org/wiki/M-209 The paper https://cryptome.org/2015/12/ReedsTheHagelinCipherBellLabs1978.pdf ends with "The program takes about two minutes to produce a solution on a DEC PDP-11/70." No info on the program coding. More info around the story from Richie himself https://www.bell-labs.com/usr/dmr/www/crypt.html From cym224 at gmail.com Sat Jan 18 08:09:37 2020 From: cym224 at gmail.com (Nemo Nusquam) Date: Fri, 17 Jan 2020 17:09:37 -0500 Subject: [COFF] Troff usage Message-ID: Originally, I meant to reply to the Linux-origins thread by pointing to AST's take on the matter but I failed to find it. So, instead, here is something to warm the cockles of troff users: From https://www.cs.vu.nl/~ast/home/faq.html Q: What typesetting system do you use? A: All my typesetting is done using troff. I don't have any need to see what the output will look like. I am quite convinced that troff will follow my instructions dutifully. If I give it the macro to insert a second-level heading, it will do that in the correct font and size, with the correct spacing, adding extra space to align facing pages down to the pixel if need be. Why should I worry about that? WYSIWYG is a step backwards. Human labor is used to do that which the computer can do better. Also, using troff means that the text is in ASCII, and I have a bunch of shell scripts that operate on files (whole chapters) to do things like produce a histogram by year of all the references. That would be much harder and slower if the text were kept in some manufacturer's proprietary format. Q: What's wrong with LaTeX? A: Nothing, but real authors use troff. N. From andreww591 at gmail.com Sat Jan 18 17:30:09 2020 From: andreww591 at gmail.com (Andrew Warkentin) Date: Sat, 18 Jan 2020 00:30:09 -0700 Subject: [COFF] [TUHS -> COFF] Distributed systems, was: On the origins of Linux - "an academic question" In-Reply-To: References: Message-ID: On 1/17/20, Rob Pike wrote: > I am convinced that large-scale modern compute centers would be run very > differently, with fewer or at least lesser problems, if they were treated > as a single system rather than as a bunch of single-user computers ssh'ed > together. > > But history had other ideas. > [moving to COFF since this isn't specific to historic Unix] For applications (or groups of related applications) that are already distributed across multiple machines I'd say "cluster as a single system" definitely makes sense, but I still stand by what I said earlier about it not being relevant for things like workstations, or for server applications that are run on a single machine. I think clustering should be an optional subsystem, rather than something that is deeply integrated into the core of an OS. With an OS that has enough extensibiity, it should be possible to have an optional clustering subsystem without making it feel like an afterthought. That is what I am planning to do in UX/RT, the OS that I am writing. The "core supervisor" (seL4 microkernel + process server + low-level system library) will lack any built-in network support and will just have support for local file servers using microkernel IPC. The network stack, 9P client filesystem, 9P server, and clustering subsystem will all be separate regular processes. The 9P server will use regular read()/write()-like APIs rather than any special hooks (there will be read()/write()-like APIs that expose the message registers and shared buffer to make this more efficient), and similarly the 9P client filesystem will use the normal API for local filesystem servers (which will also use read()/write() to send messages). The clustering subsystem will work by intercepting process API calls and forwarding them to either the local process server or to a remote instance as appropriate. Since UX/RT will go even further than Plan 9 with its file-oriented architecture and make process APIs file-oriented, this will be transparent to applications. Basically, the way that the file-oriented process API will work is that every process will have a special "process server connection" file descriptor that carries all process server API calls over a minimalist form of RPC, and it will be possible to redirect this to an intermediary at process startup (of course, this redirection will be inherited by child processes automatically). From clemc at ccc.com Wed Jan 22 07:52:04 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 21 Jan 2020 16:52:04 -0500 Subject: [COFF] [TUHS] Unix on Zilog Z8000? In-Reply-To: References: Message-ID: Moving to COFF On Tue, Jan 21, 2020 at 12:53 PM Jon Forrest wrote: > As I remember the Z8000 was going to be the great white hope that > would continue Zilog's success with the Z80 into modern times. > But, it obviously didn't happen. > > Why? > A really good question. I will offer my opinion as someone that lived through the times. The two contemporary chips of that time were the Intel 8086 and Z8000. Certainly, between those two, the Zilog chip was a better chip from a software standpoint. The funny part was that Moto had been pushing the 6809 against those two. The story of the IBM/PC and Moto is infamous. Remember the 68K is a skunkworks project and is not something they were talking about it. Why IBM picked 8086/8088 over Z8000 I do not know. I'm >>guessing<< total system cost and maybe vendor preference. The tea, that developed the PC had been using the 8085 for another project, so the jump of vendors to Zilog would have been more difficult (Moto and IBM corporate had been tight for years, MECL was designed by Moto for IBM for the System 360). I do know they picked Intel over the 6809, even though they had the X-series device in Yorktown (just like we had it at Tektronix) and had wanted to use what would become the 68000. In the end, other than Forest's scheme, none of them could do VM without a lot of help. If I had not known about the X-series chip (or had been given a couple of them), I think Roger and I would have used the Z8000 for Magnolia. But I know Roger and I liked it better; as did most of our peeps in Tek Labs at the time. IIRC Our thinking was that Z8000 has an "almost" good enough instruction set, but since many of the processors's addressing modes are missing on some/most of the instructions, it makes writing a compiler more difficult (Bill Wulf used to describe this as an 'irregular' instruction set). And even though the address space was large, you still had to contend with a non-linear segmented address scheme. So I think once the 68000 came on the scene for real, it had the advantage if the best instructions set (all instructions worked as expected, was symmetric) and looked pretty darned near a PDP-11. The large linear address was a huge win and even though it was built as a 16-bit chip internally (i.e. 16-bit barrel shifter and needing 2 ticks for all 32-bit ops), all the registers were defined as 32-bits wide. I think we saw it as becoming a full 32-bit device the soonest and with the least issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wobblygong at gmail.com Wed Jan 22 14:39:17 2020 From: wobblygong at gmail.com (Wesley Parish) Date: Wed, 22 Jan 2020 17:39:17 +1300 Subject: [COFF] The Third Ronnie's SDI's embedded systems Message-ID: Hi This isn't precisely Unix-related, but I'm wondering about the Third Ronnie's SDI's embedded systems. Is there anyone alive who knows just what they were? I'm also wondering, since the "Star Wars" program seemed to go off the boil at the end of the "Cold War", and the embedded systems were made with the US taxpayer's dollar, whether or not they are now public domain - since iirc, US federal law mandates that anything made with the taxpayer's dollar is owned by the taxpayer and is thus in the public domain. I'm wondering about starting a Freedom of Information request to find all of that out, but I don't quite know how to go about it. (FWVLIW, I'm a fan of outer space exploration (and commercial use) and a trove of realtime, embedded source code dealing with satellites would be a treasure indeed. It'd raise the bar and lower the cost of entry into that market.) Also, more Unixy, what status at the time were the POSIX realtime standards, and what precise relation did they have to Unix? Thanks Wesley Parish From clemc at ccc.com Thu Jan 23 04:42:34 2020 From: clemc at ccc.com (Clem Cole) Date: Wed, 22 Jan 2020 13:42:34 -0500 Subject: [COFF] [TUHS] Apollo Domain/OS In-Reply-To: <25618b7a-d831-fd56-80fb-41da1f65887f@nomadlogic.org> References: <20200121230025.GL15860@mit.edu> <25618b7a-d831-fd56-80fb-41da1f65887f@nomadlogic.org> Message-ID: moving to COFF On Wed, Jan 22, 2020 at 1:06 PM Pete Wright wrote: > I also seem to remember him telling me about working on the patriot > missile system, although i am not certain if i am remembering correctly > that this was something he did at apollo or at another company in the > boston area. > The Patriot was/is Raytheon in Andover, MA not Apollo (Chelmsford - two towns west). Cannot speak for today, but when it was developed the source code was in Ada. I knew the Chief Scientist/PI for the original Patriot system (who died of a massive stroke a few years back -- my wife used to take care of his now 30-40 yo kids when they were small and she was a tad younger). During the first Gulf War, he basically did not sleep the whole first month. As I understand it, Raytheon normally took 3-6 months per SW release. During the war, they put out an update every couple of days and Willman once said they were working non-stop on the codebase, dealing with issues they have never seen or have been simulated. I gather it was quite exciting ... sigh. We got him to give a couple of talks at some local IEEE functions describing the SW engineering process they had used. Willman was one of the people that got me to respect Ada and the job his folks had to do. To once told me, that at some point, Raytheon had a contract supporting the Polaris System for the US Navy. The Navy had long ago lost the source. They had disassembled and were patching what they had. Yeech!!!! He also once made another comment to me ( in the late 1980s IIRC) that the DoD wanted Ada because they want the source to be part of the specifications and wanted a language that was more explicit that they could use for those specs. I have no idea how much that has proven to be true. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arrigo at alchemistowl.org Thu Jan 23 04:55:19 2020 From: arrigo at alchemistowl.org (Arrigo Triulzi) Date: Wed, 22 Jan 2020 19:55:19 +0100 Subject: [COFF] Book about the Sprint/Spartan ("Safeguard") hardware/software In-Reply-To: <414C850D-093F-47CA-A6E3-12EF9F01D511@alchemistowl.org> References: <414C850D-093F-47CA-A6E3-12EF9F01D511@alchemistowl.org> Message-ID: <0B3DD4D1-26E0-4774-8CEB-E38D4556CF70@alchemistowl.org> Quoting myself.. sorry > On 22 Jan 2020, at 19:47, Arrigo Triulzi wrote: > > Does anyone know if there is a book or in-depth article about the Sprint/Spartan system, named Safeguard, hardware and software? > > There is very little about it available online (see http://www.nuclearabms.info/Computers.html) but it was apparently an amazing programming effort running on UNIVAC. I should have added that there is some material online here: https://www.srmsc.org/dps2010.html Linking to this Bell Labs history paper: https://www.srmsc.org/ref1040.html (and some contributions from specific authors about their subsystems). Arrigo From arrigo at alchemistowl.org Thu Jan 23 04:47:12 2020 From: arrigo at alchemistowl.org (Arrigo Triulzi) Date: Wed, 22 Jan 2020 19:47:12 +0100 Subject: [COFF] Book about the Sprint/Spartan ("Safeguard") hardware/software Message-ID: <414C850D-093F-47CA-A6E3-12EF9F01D511@alchemistowl.org> Does anyone know if there is a book or in-depth article about the Sprint/Spartan system, named Safeguard, hardware and software? There is very little about it available online (see http://www.nuclearabms.info/Computers.html) but it was apparently an amazing programming effort running on UNIVAC. Arrigo From krewat at kilonet.net Thu Jan 23 05:41:56 2020 From: krewat at kilonet.net (Arthur Krewat) Date: Wed, 22 Jan 2020 14:41:56 -0500 Subject: [COFF] The Third Ronnie's SDI's embedded systems In-Reply-To: References: Message-ID: I highly doubt sensitive or classified military information would be given to the public, just because they "own" it. ;) Somewhat SDI related side-story: My only experience with Apollo/Domain OS systems was at a defense contractor I was consulting for back in the mid-to-late 90's. I was the Sun system administrator for the Mechanical and Electrical Engineering departments, and because I knew VMS somewhat, I also took on some VAX work from them too... Mostly keeping old systems running like VAXstations and a micro-VAX or two, plus an 8350. Anyway, one day, an older wizened engineer came to me to ask if I could take a look at something. He was very agitated. They had an old Apollo setup, a few diskless workstations, plus a "file server" that actually had one or two disk drives in it. But still, basically a workstation. They had more workstations "back in the day" but they all died one by one, and were not on support so they just threw them away. The file server had died years back, and the workstations were of course useless, but the older engineers held onto them for some reason, mostly nostalgia I think. Checking out the file server, the power supply was obviously dead, so I pulled a power supply from one of the remaining workstations, and it fired right up. After figuring out the token ring wiring, and jumping wires where workstations had been removed, I powered on one of the workstations, and it booted and ran just fine. The old engineering wizard went back to his notes, found his password and everything else he needed, and proceeded to find a few files that were obviously very important to him. I don't remember the transfer method, maybe it was floppies... The system certainly wasn't hooked up to any other network in the building. Anyway, he was very happy. He explained the files were PCB layouts for some old project they were involved in, and needed the files to prove the work they did, so they could get paid. It was an SDI project. ;) Moral of the story, defense contractors were still reaping the rewards of SDI, at least 10-15 years later. This was at Loral Fairchild Systems in Syosset, NY, an east-coast division (and originally corporate headquarters ) of Fairchild Systems of California, which used to be Fairchild Imaging. Bought by Lockheed Martin a few years later. And then sold off to BAE after that. I only stuck around until 2000 or so, just before the sell-off to BAE. When I first went to interview for the consulting gig back in 1993, I was shown around to meet all the engineers. They all had drawings of PCBs on their cubicle walls... they were all round boards. I hit it off with one of the electrical engineers right away, and I asked him what they were. He looked around, and said in a low voice: "They fit into a missile". Later on I came to realize they were working on proposals for THAADS. One of their hurdles was calibrating CCDs for IR use. Every cell in their CCDs were slightly different in terms of light response. The engineer I had hit it off with was the principal engineer responsible for coming up with a method of calibrating IR CCDs all in hardware. art k. On 1/21/2020 11:39 PM, Wesley Parish wrote: > Hi > > This isn't precisely Unix-related, but I'm wondering about the Third > Ronnie's SDI's embedded systems. Is there anyone alive who knows just > what they were? I'm also wondering, since the "Star Wars" program > seemed to go off the boil at the end of the "Cold War", and the > embedded systems were made with the US taxpayer's dollar, whether or > not they are now public domain - since iirc, US federal law mandates > that anything made with the taxpayer's dollar is owned by the taxpayer > and is thus in the public domain. I'm wondering about starting a > Freedom of Information request to find all of that out, but I don't > quite know how to go about it. (FWVLIW, I'm a fan of outer space > exploration (and commercial use) and a trove of realtime, embedded > source code dealing with satellites would be a treasure indeed. It'd > raise the bar and lower the cost of entry into that market.) > > Also, more Unixy, what status at the time were the POSIX realtime > standards, and what precise relation did they have to Unix? > > Thanks > > Wesley Parish > _______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff > From pete at nomadlogic.org Thu Jan 23 04:51:21 2020 From: pete at nomadlogic.org (Pete Wright) Date: Wed, 22 Jan 2020 10:51:21 -0800 Subject: [COFF] [TUHS] Apollo Domain/OS In-Reply-To: References: <20200121230025.GL15860@mit.edu> <25618b7a-d831-fd56-80fb-41da1f65887f@nomadlogic.org> Message-ID: On 2020-01-22 10:42, Clem Cole wrote: > moving to COFF > > On Wed, Jan 22, 2020 at 1:06 PM Pete Wright > wrote: > > I also seem to remember him telling me about working on the patriot > missile system, although i am not certain if i am remembering > correctly > that this was something he did at apollo or at another company in the > boston area. > > The Patriot was/is Raytheon in Andover, MA not Apollo (Chelmsford - > two towns west).   Cannot speak for today, but when it was developed > the source code was in Ada.   I knew the Chief Scientist/PI for the > original Patriot system (who died of a massive stroke a few years back > -- my wife used to take care of his now 30-40 yo kids when they were > small and she was a tad younger). > > During the first Gulf War, he basically did not sleep the whole first > month.   As I understand it, Raytheon normally took 3-6 months per SW > release.  During the war, they put out an update every couple of days > and Willman once said they were working non-stop on the codebase, > dealing with issues they have never seen or have been simulated.  I > gather it was quite exciting ... sigh.   We got him to give a couple > of talks at some local IEEE functions describing the SW > engineering process they had used. > > Willman was one of the people that got me to respect Ada and the job > his folks had to do. To once told me, that at some point, Raytheon had > a contract supporting the Polaris System for the US Navy.   The Navy > had long ago lost the source.  They had disassembled and were patching > what they had. Yeech!!!!  He also once made another comment to me ( in > the late 1980s IIRC) that the DoD wanted Ada because they want the > source to be part of the specifications and wanted a language that was > more explicit that they could use for those specs.   I have no idea > how much that has proven to be true. Thanks Clem - that's really insightful.  I remember him telling me that during testing they would have to shut down one of the main highways through Arizona and how stressful it was trying to get software and hardware to play nice while produce was literally rotting on the highway.  I'm sure he told me more stories but that image of a bunch of engineering sweating it out in the desert really stood out in my mind. -pete -- Pete Wright pete at nomadlogic.org @nomadlogicLA -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at rulingia.com Thu Jan 23 15:27:02 2020 From: peter at rulingia.com (Peter Jeremy) Date: Thu, 23 Jan 2020 16:27:02 +1100 Subject: [COFF] [TUHS] Unix quix In-Reply-To: <20200122184244.14CBB18C083@mercury.lcs.mit.edu> References: <20200122184244.14CBB18C083@mercury.lcs.mit.edu> Message-ID: <20200123052702.GA83898@server.rulingia.com> => coff since it's non-Unix On 2020-Jan-22 13:42:44 -0500, Noel Chiappa wrote: >Pretty interesting machine, if you study its instruction set, BTW; with no >stack, subroutines are 'interesting'. "no stack" was fairly standard amongst early computers. Note the the IBM S/360 doesn't have a stack.. The usual approach to subroutines was to use some boilerplate as part of the "call" or function prologue that stashed a return address in a known location (storing it in the word before the function entry or patching the "return" branch were common aproaches). Of course this made recursion "hard" (re-entrancy typically wasn't an issue) and Fortran and Cobol (at least of that vintage) normally don't support recursion for that reason. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From clemc at ccc.com Fri Jan 24 00:08:24 2020 From: clemc at ccc.com (Clem Cole) Date: Thu, 23 Jan 2020 09:08:24 -0500 Subject: [COFF] [TUHS] Unix quix In-Reply-To: <20200123052702.GA83898@server.rulingia.com> References: <20200122184244.14CBB18C083@mercury.lcs.mit.edu> <20200123052702.GA83898@server.rulingia.com> Message-ID: FWIW: System 360 uses what was called the 'push down save area' as part of the function calling convention. Each routine declared and creates local storage for the registers. Being reentrant was certainly possible and many languages such as the Algol and APL families were. It's funny since S/360 was the first architecture I knew deeply (*i.e.* got paid to program), and working on support for York/APL at the time (and began learning the Univac 1100 too), I just thought this was natural until I began to learn about other processors ISA's like the PDP-11 family that had an SP. I remember, thinking -- this is so cool. But as you said, originally early Fortran and Cobol didn't require same. The typical calling conventions was something like this was pretty standard for the S/360: WORKAREA DSECT , Reentrant work area (stack like function) DS 18F Save area FIELD1 DS F Some variable FIELD2 DS F Another variable WORKLEN EQU *-WORKAREA Length of reentrant work area SUBRTN1 RSECT , HLASM will perform reentrant checking STM R14,R12,12(R13) Save registers at entry LR R12,R15 Set code base register USING SUBRTN1,R12 Establish code addressability LGHI R0,WORKLEN Get length of reentrant work area STORAGE OBTAIN, Obtain reentrant work area X LENGTH=(0) ..Length is in R0 ST R1,8(,R13) Forward chain in prev save area ST R13,4(,R1) Backward chain in next save area L R14,20(,R13) Get R1 at entry (parameters) LR R13,R1 Set up new save area/reentrant workarea USING WORKAREA,R13 Establish work area addressability LM R2,R3,0(R14) Get addresses of parameters STM R2,R3,FIELD1 Save parameter addresses for later … *** Subroutine Logic goes here … LR R1,R13 Address to be released L R13,4(,R13) Address of prior save area LGHI R0,WORKLEN Length of storage to release STORAGE RELEASE, Release reentrant work area X ADDRESS=(1), ..Address in R1 X LENGTH=(0) ..Length in R0 LM R14,R12,12(R13) Restore registers OI 15(R13),X'01' This bit on means this save area is inactive BR R14 Return to caller On Thu, Jan 23, 2020 at 12:47 AM Peter Jeremy wrote: > => coff since it's non-Unix > > On 2020-Jan-22 13:42:44 -0500, Noel Chiappa > wrote: > >Pretty interesting machine, if you study its instruction set, BTW; with no > >stack, subroutines are 'interesting'. > > "no stack" was fairly standard amongst early computers. Note the the IBM > S/360 doesn't have a stack.. > > The usual approach to subroutines was to use some boilerplate as part of > the > "call" or function prologue that stashed a return address in a known > location (storing it in the word before the function entry or patching the > "return" branch were common aproaches). Of course this made recursion > "hard" (re-entrancy typically wasn't an issue) and Fortran and Cobol (at > least of that vintage) normally don't support recursion for that reason. > > -- > Peter Jeremy > _______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Fri Jan 24 00:31:10 2020 From: clemc at ccc.com (Clem Cole) Date: Thu, 23 Jan 2020 09:31:10 -0500 Subject: [COFF] [TUHS] Unix quix In-Reply-To: References: <20200122184244.14CBB18C083@mercury.lcs.mit.edu> <20200123052702.GA83898@server.rulingia.com> Message-ID: BTW: Not to bring up a new rat hole/new argument, but rather remind people of one of the arguments of the day. Because of SP or no SP style of calling, in those days the question came out language design of how the stack or register call area was maintained: Was it/should it be the responsibility of the calling routine or the called subroutine. Things like Fortran's entry statement and other non-local goto's, co-routines/setjmp/longjmp added fuel to the fire in the argument. As a language designer/implementor at the time, someone like Steve Johnson and Doug McIlroy were undoubtedly mixed up in the argument and had opinions. I was certainly too inexperienced then to understand what the fight was about. But I do remember the fight and how the issues were taught/discussed at CMU when I was a student. I admit I was quickly sucked into C's way of handling things, as it seemed simple/clear/understandable to me, but not being a language person I probably did not (maybe still do not) value some the arguments for the other side. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfawcus+lists-coff at employees.org Fri Jan 24 09:50:59 2020 From: dfawcus+lists-coff at employees.org (Derek Fawcus) Date: Thu, 23 Jan 2020 23:50:59 +0000 Subject: [COFF] Y8002 - modern Z8002 clone (was Re: Unix on Zilog Z8000?) In-Reply-To: References: Message-ID: <20200123235059.GA61719@clarinet.employees.org> Of all weird things, I just happened to stumble across this: http://www.systemyde.com/proc_tab.html specifically: http://www.systemyde.com/pdf/y8002.pdf Someone has reimplemented the Z8002 in Verilog HDL, and I'd guess run it in an FPGA. Which rather suggests there is a market for it as an embedable macro-block in some devices, which the existing sources of Z16C01/Z16C02 are unable to satisfy. DF From krewat at kilonet.net Fri Jan 24 11:18:51 2020 From: krewat at kilonet.net (Arthur Krewat) Date: Thu, 23 Jan 2020 20:18:51 -0500 Subject: [COFF] [TUHS] Unix quix In-Reply-To: <20200123052702.GA83898@server.rulingia.com> References: <20200122184244.14CBB18C083@mercury.lcs.mit.edu> <20200123052702.GA83898@server.rulingia.com> Message-ID: On 1/23/2020 12:27 AM, Peter Jeremy wrote: > "no stack" was fairly standard amongst early computers. Note the the IBM > S/360 doesn't have a stack.. You can make a stack out of anything ;) From doug at cs.dartmouth.edu Fri Jan 24 01:51:31 2020 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Thu, 23 Jan 2020 10:51:31 -0500 Subject: [COFF] [TUHS] Unix quix In-Reply-To: References: <20200122184244.14CBB18C083@mercury.lcs.mit.edu> <20200123052702.GA83898@server.rulingia.com> Message-ID: <202001231551.00NFpVU4033383@tahoe.cs.Dartmouth.EDU> Clem wrote, " the question came out language design of how the stack or register call area was maintained: Was it/should it be the responsibility of the calling routine or the called subroutine. Things like Fortran's entry statement and other non-local goto's, co-routines/setjmp/longjmp added fuel to the fire in the argument." I don't remember much prospective discussion of the subject, but lots of retrospective discussion of techniques that didn't quite work, going right back to Lisp's A-list and the ensuing "funarg problem". The first PL/I out of Hursley got it wrong, too, but they were able to correct it before the bad way became ingrained. In C, which had no need for closures (thunks), efficiency was the main concern in choice of stack protocol. The only delicate situation, longjump, was sidestepped by doing it via library rather than language. Doug From bakul at bitblocks.com Sat Jan 25 10:09:12 2020 From: bakul at bitblocks.com (Bakul Shah) Date: Fri, 24 Jan 2020 16:09:12 -0800 Subject: [COFF] [TUHS] Unix quix In-Reply-To: <202001231551.00NFpVU4033383@tahoe.cs.Dartmouth.EDU> References: <202001231551.00NFpVU4033383@tahoe.cs.Dartmouth.EDU> Message-ID: <071C340F-3494-4B8D-98FD-29BF79731DB5@bitblocks.com> I read that thunks came about as an implementation of call by name for Algol. They were basically argument-less closures. Where as a general closure may accept args as well as refer to values in its environment (including those in its lexically enclosing function). I believe at one point gcc used (argument-less) thunks when it added support for nested functions so as to continue using a single ptr as a function argument. A proper closure representation needs a pair (a fun ptr & a ptr to env). The code for all this was stored on the stack & the thunk address actually pointed to this stacked code. I guess that had to be abandoned when storing code on stack was found to be a huge security hole (all because of C’s lax type system & stacks growing down to smaller addresses). Nicklaus Wirth carefully limited the scope of functional arguments in Pascal so as to avoid the “funarg problem” and GC. I think at least by 1975 (when I first studied software) it was clear how to implement “reentrant” functions; It is just that not everyone was convinced of the value of it. Even modern RISC processors don’t actually provide any support for stacks and it is just their “calling convention” that designates a specific GPR to be a stack ptr! No one questions the value of subroutines (even though the register to memory access ratio is soooo much worse now!) but closures and GC are still not so well accepted. On Jan 24, 2020, at 2:07 PM, Doug McIlroy wrote: > > Clem wrote, " the question came out language design of how the > stack or register call area was maintained: Was it/should it be the > responsibility of the calling routine or the called subroutine. Things > like Fortran's entry statement and other non-local goto's, > co-routines/setjmp/longjmp added fuel to the fire in the argument." > > I don't remember much prospective discussion of the subject, but > lots of retrospective discussion of techniques that didn't > quite work, going right back to Lisp's A-list and the ensuing > "funarg problem". The first PL/I out of Hursley got it wrong, too, > but they were able to correct it before the bad way became > ingrained. In C, which had no need for closures (thunks), > efficiency was the main concern in choice of stack protocol. > The only delicate situation, longjump, was sidestepped by > doing it via library rather than language. > > Doug > _______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff From dave at horsfall.org Wed Jan 29 08:18:20 2020 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 29 Jan 2020 09:18:20 +1100 (EST) Subject: [COFF] The MOO problem and set-uid Message-ID: I recall reading in an old manpage that the (patented) set-uid bit was to solved the MOO problem. I've searched around, but cannot find anything relevant. Anyone know? -- Dave From bakul at bitblocks.com Wed Jan 29 09:01:31 2020 From: bakul at bitblocks.com (Bakul Shah) Date: Tue, 28 Jan 2020 15:01:31 -0800 Subject: [COFF] The MOO problem and set-uid In-Reply-To: References: Message-ID: <84453220-427A-45B0-9861-DC63AFFDEF9A@bitblocks.com> The orig. ref. was in the Unix Time Sharing paper. See Section 3.5 near the end. https://people.eecs.berkeley.edu/~brewer/cs262/unix.pdf The paper referenced above is behind a paywall (you can see the first page *free of charge*!) https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.4380010210 One place the problem is described in some detail: https://www.cs.unm.edu/~cris/481/gordon-moo.txt : > On Jan 28, 2020, at 2:18 PM, Dave Horsfall wrote: > > I recall reading in an old manpage that the (patented) set-uid bit was to solved the MOO problem. I've searched around, but cannot find anything relevant. Anyone know? > > -- Dave > _______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff -------------- next part -------------- An HTML attachment was scrubbed... URL: From dot at dotat.at Thu Jan 30 00:50:59 2020 From: dot at dotat.at (Tony Finch) Date: Wed, 29 Jan 2020 14:50:59 +0000 Subject: [COFF] The MOO problem and set-uid In-Reply-To: <84453220-427A-45B0-9861-DC63AFFDEF9A@bitblocks.com> References: <84453220-427A-45B0-9861-DC63AFFDEF9A@bitblocks.com> Message-ID: Bakul Shah wrote: > > The paper referenced above is behind a paywall (you can see the first > page *free of charge*!) > https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.4380010210 That article mentions Frank King and Barry Landy who are still around in Cambridge. > One place the problem is described in some detail: > https://www.cs.unm.edu/~cris/481/gordon-moo.txt A correction: Titan was not a Unix system :-) It was a variant of the Ferranti Atlas, with its own timesharing operating system. But it has some second-hand Unix connections: it was the first system to have hashed passwords, which Unix later adopted. Stephen Bourne used Titan when developing Algol 68C. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: West backing southwest later, 5 to 7. Moderate or rough. Occasional rain. Good, occasionally moderate. From jpl.jpl at gmail.com Thu Jan 30 07:17:19 2020 From: jpl.jpl at gmail.com (John P. Linderman) Date: Wed, 29 Jan 2020 16:17:19 -0500 Subject: [COFF] Huffman - What did he do when he wasn't coding? Message-ID: I despair of getting an attachment through. Let's hope a link survives. https://www.dropbox.com/s/2lfmrkp34j9z68n/Huffman.jpg?dl=0 The NYC Math Museum (MoMath) had/has an origami exhibit. Seems David Huffman was interested in origami as well as compression. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Fri Jan 31 06:25:59 2020 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 31 Jan 2020 07:25:59 +1100 (EST) Subject: [COFF] The MOO problem and set-uid In-Reply-To: References: Message-ID: Thanks, all, for the responses; it was driving me nuts! I know the game as "cows and bulls" (or perhaps that's because I'm of British origin). I like Dennis' observation: "On the other hand, suid these days seems to be a fairly blunt and dangerous instrument". I've often believed that if you thought you needed set-uid (esp. to root!) you can probably get away with set-gid instead. -- Dave From bakul at bitblocks.com Fri Jan 31 07:51:03 2020 From: bakul at bitblocks.com (Bakul Shah) Date: Thu, 30 Jan 2020 13:51:03 -0800 Subject: [COFF] The MOO problem and set-uid In-Reply-To: References: Message-ID: On Jan 30, 2020, at 12:25 PM, Dave Horsfall wrote: > > Thanks, all, for the responses; it was driving me nuts! I know the game as "cows and bulls" (or perhaps that's because I'm of British origin). > > I like Dennis' observation: "On the other hand, suid these days seems to be a fairly blunt and dangerous instrument". I've often believed that if you thought you needed set-uid (esp. to root!) you can probably get away with set-gid instead. Capabilities[1] (Dennis, Van Horn, 1966) would have solved the MOO problem. And the CAP computer project had already started in Cambridge! [1] https://www.princeton.edu/~rblee/ELE572Papers/Fall04Readings/ProgramSemantics_DennisvanHorn.pdf Re-reading this papers decades later it is interesting to see that the modern object caps are basically not very different from the original concept! Also interesting to see fork() here.