- COFF - www.tuhs.org

The Third Ronnie's SDI's embedded systems

by Wesley Parish

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

5 years, 4 months

2
1
0 0

Book about the Sprint/Spartan ("Safeguard") hardware/software

by Arrigo Triulzi

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

5 years, 4 months

1
1
0 0

Re: [COFF] [TUHS] Apollo Domain/OS

by Clem Cole

moving to COFF On Wed, Jan 22, 2020 at 1:06 PM Pete Wright <pete(a)nomadlogic.org> 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.

5 years, 4 months

2
1
0 0

Re: [COFF] [TUHS -> COFF] Distributed systems, was: On the origins of Linux - "an academic question"

by Andrew Warkentin

On 1/17/20, Rob Pike <robpike(a)gmail.com> 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).

5 years, 4 months

1
0
0 0

Troff usage

by Nemo Nusquam

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.

5 years, 4 months

1
0
0 0

Glenn Henry's Museum

by Rudi Blom

>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

5 years, 5 months

1
0
0 0

Glenn Henry's Museum

by Charles H Sauer

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(a)technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/Skype/Twitter: CharlesHSauer

5 years, 5 months

1
0
0 0

Re: [COFF] [TUHS] Tech Sq elevator [ really type-checking ]

by Dan Cross

-TUHS, +COFF, in line with Warren's wishes. On Sun, Jan 12, 2020 at 7:36 PM Bakul Shah <bakul(a)bitblocks.com> 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.

5 years, 5 months

2
1
0 0

Re: [COFF] [TUHS] Tech Sq elevator [ really type-checking ]

by Warren Toomey

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 :-)

5 years, 5 months

1
0
0 0

Re: [COFF] [TUHS] Tech Sq elevator

by Lars Brinkhoff

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.

5 years, 5 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

COFF