From blake1024 at gmail.com Wed Feb 1 00:15:29 2023 From: blake1024 at gmail.com (Blake McBride) Date: Tue, 31 Jan 2023 08:15:29 -0600 Subject: [TUHS] yet another C discussion (YACD) and: Rust is not C++ In-Reply-To: References: Message-ID: Although few will admit when their uneducated opinion is wrong, it is true that Rust and C++ are very different. They are as different as any two clearly different languages are. Their respective feature sets are quite different and do not overlap any more than any two totally different languages do. Blake McBride On Mon, Jan 30, 2023 at 11:26 AM ron minnich wrote: > I did not want to disrupt the FD 2 discussion, but I could not really let > this comment go unanswered: > > "Smells like C++ to me. Rust in essence is a re-implementation of C++ not > C. It tries to pack as much features as it possibly can. " > > It's hard for me to see how you can say this if you have done any work in > Rust and C++. > > But, short form: Rust is not C++. Full stop. > > I did not feel that comment should go unanswered, lest people believe it. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.donner at gmail.com Wed Feb 1 03:43:20 2023 From: marc.donner at gmail.com (Marc Donner) Date: Tue, 31 Jan 2023 12:43:20 -0500 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: <1be17de9-b39a-0dfe-5959-94379f93f830@mhorton.net> References: <23432965-52D6-4331-A4D8-8A6FDDB3F751@serissa.com> <1be17de9-b39a-0dfe-5959-94379f93f830@mhorton.net> Message-ID: I was a grad student at CMU at the time. Raj Reddy told me back then that it was 1 MIPS, 1 million pixels, 1 megabyte of RAM. On Mon, Jan 30, 2023, 21:04 Mary Ann Horton wrote: > On 1/25/23 17:01, Larry Stewart wrote: > > Jim Morris left PARC and went off to CMU and began talking up the idea of > the "3M" workstation. One MIPs, One Megabyte of RAM, and One Million > Pixels. > > The way I heard it, a workstation needed to have Menus, a Mouse, and a 1 > MIPS processor. It also had a megabyte of RAM, at least a megabit LAN, a > megapixel of display, and cost about a megapenny. > > Thanks, > > *Mary Ann Horton* (she/her/ma'am) > maryannhorton.com > > "This is a great book" - Monica Helms > > "Brave and Important" - Laura L. Engel > > Available on Amazon and bn.com! > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Wed Feb 1 07:27:41 2023 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 1 Feb 2023 08:27:41 +1100 (EST) Subject: [TUHS] FD 2 In-Reply-To: References: <202301300750.30U7oQTh013304@freefriends.org> <20230130150219.GD12306@mcvoy.com> <20230130152703.GE12306@mcvoy.com> <20230130154555.GF12306@mcvoy.com> Message-ID: On Mon, 30 Jan 2023, Steve Nickolas wrote: [...] > I've actually been bitten by compilers doing unexpectedly stupid things, > so I guard around them. I'll never merge two chars into a short with > > c=(a<<8)|b; I used to do just that to disambiguate commands that started with the same letter in a UT-200 driver that I (re)wrote. Of course, I was young and stupid back then... It's quite something to see things like: switch (cmd) { case 'AA': ... break; case 'AB': ... break; default: wtf(); /* no return */ } Horribly machine-dependent, but I knew the 11/40 and Ed 6 quite well. [...] > I'll never do if (a==b&&c==d), always if ((a==b)&&(c==d)). Indeed; I *always* use parentheses even if they are not necessary (for my benefit, at least). -- Dave From cmhanson at eschatologist.net Wed Feb 1 09:29:53 2023 From: cmhanson at eschatologist.net (Chris Hanson) Date: Tue, 31 Jan 2023 15:29:53 -0800 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: References: Message-ID: <506C6BDA-D11B-448B-9462-E4F662330100@eschatologist.net> On Jan 29, 2023, at 9:23 PM, Jonathan Gray wrote: > > a different writeup of these is in: > > https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V04.5.pdf > September 1982, Vol IV No V > July Usenix Abstracts I see this also has a bit for Brad Cox's "The Object Oriented Pre-Compiler: Programming Smalltalk 80 Methods in the C Language" which continues to be relevant today though I believe that presentation still used the (quite ugly) original syntax for what became Objective-C. -- Chris From steffen at sdaoden.eu Wed Feb 1 10:40:23 2023 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 01 Feb 2023 01:40:23 +0100 Subject: [TUHS] yet another C discussion (YACD) and: Rust is not C++ In-Reply-To: References: Message-ID: <20230201004023.rHE9j%steffen@sdaoden.eu> ron minnich wrote in : |That example was a simplified bit of code from a widely used code base. All |I need to do is change the function g go a pointer to function, or have it |be provided by a .so, and all bets are off. | |In any event, the important thing here is not that y should be initialized, |or should not; it's that it is not possible to get a consistent answer on |the question, from people who have been writing in C for decades. I find the syntax just terrible. (I have not programmed with it.) I mean annotations are for the better, ok, (but i luckily get away with only "const" and "volatile" (and "mutable"), and leave things like "restrict" be a good man). Johannes Lundberg i think it was who then left FreeBSD (?) but pointing to a Rust program he had written (i cannot find the reference), that was a few years ago (i looked once i composed this message first, it might even had been as early as 2017!), and i was lucky i do not have to deal with it. Even nim-lang.org that at least converted its code to plain C back in the day when it was still called Nimrod is too heavy for me now, but claims to be hard realtime aware etc. It at least tries to give programmers some syntactic sugar that makes people happy when they look at the screen for 7 hours (underpaid) or 16 hours (over-ambitioned). Like the only python thing i like, the syntax sugar. But as languages grow they get more and more "refined", and now i read things like type BinaryTree*[T] = ref object # BinaryTree is a generic type with # generic param `T` le, ri: BinaryTree[T] # left and right subtrees; may be nil data: T # the data stored in a node proc newNode*[T](data: T): BinaryTree[T] = # constructor for a node new(result) result.data = data which gets me off a bit and makes me think that "hey, maybe Objective-C is not really the worst thing" (despite the syntax). I do not know. Everything beyond a small monolithic self-contained thing is a problem per se. You can then unit test atomically, and if thousands of modules do that, you plug them to a better whole. But that also not a good answer, all those flakes that live their own life, many maybe even in remote locations out of any control. You could have a language which hard fixates all the call chain, or you could have tools which bring this to a small and simple language which does not offer it. A compiler can figure out which variables are assigned etc and could create in-object-file annotations which the linker automatically verifies. Of course there are many code paths through functions. Back in 2009 when i bought the one Apple i wanted to have i tried out their Development software, which i think required internet access. All the pop-ups and titles, i think it (later?) could compile on-the-fly and inject the new object in the running tested application, etc. And then there are semantic description languages like interface builders, where robots create the actual code. So then you could have Corba interface descriptions / DBUS and plug it all via it. Then Rob Pike says "make it a string" (more or less), and luckily i do not have dyslexia. Maybe Qt has a good answer by not only not banishing the C preprocessor, but introducing another one on top. So then the compiler can analyze the code and generate a correct variable-state-at-function-call-time state that a dynamic linker could then verify against the consumer or producer (whatever is needed) of linked modules, that link modules, that link modules, all of which are subject to replacements due to development iterations, bug patches etc, ie, new releases. As in, the library versioning that is used for ELF object files, today often even linker scripts which furtherly diversify this, offer are not enough, they do not do this. They only bundle a name to a library version, or multiple (as in 1966 FUNC GLOBAL DEFAULT 13 realpath@@GLIBC_2.3 33 FUNC GLOBAL DEFAULT 13 realpath at GLIBC_2.2.5) I do not know how Rust deals with this. Is it at all possible to fixate all the call chain over all possibly involved dynamics? What do i gain from initializing an object with a default value if that default value is not not not not one of the values that i expect after some external function is called? Sure i not rarely see patches fly by where one more memset(,0,) is used to fully initialize a struct / prevent memory address disclosures (i only track BSDs). And there are still patches that fix bugs on old code that sometimes is twenty years or more, say zlib or tzcode. And then there are compiler bugs that bring in bugs -- that is not avoidable, even if the documentation is clear and obvious like /* The application can compare zlibVersion and ZLIB_VERSION for consistency. If the first character differs, the library code actually used is not compatible with the zlib.h header file used by the application. This check is automatically made by deflateInit and inflateInit. */ That is only graspable by a human programmer that reads it. Rapid application development that surely is not. (And actually i am not sure this is really true. But i personally would hope for it. It is more earthy, and has more blood, sweat and tears.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From lm at mcvoy.com Wed Feb 1 10:49:39 2023 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 31 Jan 2023 16:49:39 -0800 Subject: [TUHS] yet another C discussion (YACD) and: Rust is not C++ In-Reply-To: <20230201004023.rHE9j%steffen@sdaoden.eu> References: <20230201004023.rHE9j%steffen@sdaoden.eu> Message-ID: <20230201004939.GB6988@mcvoy.com> Even though I participated in this thread, so I too have sinned, this definitely wants to be discussed elsewhere. comp.lang.c maybe? This discussion reminds a lot of what my career has been like. Over and over again, I got told "that won't work". I wasn't very interested in those people, if they stayed out of my way. I was way more interested in the people who said "hmm, maybe if you did it this way". I've written a ton of working C code. I've managed and guided others to do the same. I'm positive that I've written way more commercially supported C code than was present in v6/v7 kernels. Not sure about userspace, I think Unix has me beat there. The point? It's very possible to write working C code. You need good programmers and those seem to be going out of style so people are turning to Rust because it doesn't compile crappy code. I'm just happy to be retired, C worked for me for 40+ years, I feel like I dodged a learning curve bullet by getting out before I had to switch to Rust (or whatever). On Wed, Feb 01, 2023 at 01:40:23AM +0100, Steffen Nurpmeso wrote: > ron minnich wrote in > : > |That example was a simplified bit of code from a widely used code base. All > |I need to do is change the function g go a pointer to function, or have it > |be provided by a .so, and all bets are off. > | > |In any event, the important thing here is not that y should be initialized, > |or should not; it's that it is not possible to get a consistent answer on > |the question, from people who have been writing in C for decades. > > I find the syntax just terrible. (I have not programmed with it.) > I mean annotations are for the better, ok, (but i luckily get away > with only "const" and "volatile" (and "mutable"), and leave things > like "restrict" be a good man). Johannes Lundberg i think it was > who then left FreeBSD (?) but pointing to a Rust program > he had written (i cannot find the reference), that was a few years > ago (i looked once i composed this message first, it might even > had been as early as 2017!), and i was lucky i do not have to deal > with it. > > Even nim-lang.org that at least converted its code to plain C back > in the day when it was still called Nimrod is too heavy for me now, > but claims to be hard realtime aware etc. It at least tries to > give programmers some syntactic sugar that makes people happy when > they look at the screen for 7 hours (underpaid) or 16 hours > (over-ambitioned). Like the only python thing i like, the > syntax sugar. But as languages grow they get more and more > "refined", and now i read things like > > type > BinaryTree*[T] = ref object # BinaryTree is a generic type with > # generic param `T` > le, ri: BinaryTree[T] # left and right subtrees; may be nil > data: T # the data stored in a node > > proc newNode*[T](data: T): BinaryTree[T] = > # constructor for a node > new(result) > result.data = data > > which gets me off a bit and makes me think that "hey, maybe > Objective-C is not really the worst thing" (despite the syntax). > > I do not know. Everything beyond a small monolithic > self-contained thing is a problem per se. You can then unit test > atomically, and if thousands of modules do that, you plug them to > a better whole. But that also not a good answer, all those flakes > that live their own life, many maybe even in remote locations out > of any control. > > You could have a language which hard fixates all the call chain, > or you could have tools which bring this to a small and simple > language which does not offer it. A compiler can figure out which > variables are assigned etc and could create in-object-file > annotations which the linker automatically verifies. > Of course there are many code paths through functions. > > Back in 2009 when i bought the one Apple i wanted to have i tried > out their Development software, which i think required internet > access. All the pop-ups and titles, i think it (later?) could > compile on-the-fly and inject the new object in the running tested > application, etc. > > And then there are semantic description languages like interface > builders, where robots create the actual code. So then you could > have Corba interface descriptions / DBUS and plug it all via it. > > Then Rob Pike says "make it a string" (more or less), and luckily > i do not have dyslexia. > > Maybe Qt has a good answer by not only not banishing the > C preprocessor, but introducing another one on top. > So then the compiler can analyze the code and generate a correct > variable-state-at-function-call-time state that a dynamic linker > could then verify against the consumer or producer (whatever is > needed) of linked modules, that link modules, that link modules, > all of which are subject to replacements due to development > iterations, bug patches etc, ie, new releases. > > As in, the library versioning that is used for ELF object files, > today often even linker scripts which furtherly diversify this, > offer are not enough, they do not do this. They only bundle > a name to a library version, or multiple (as in > > 1966 FUNC GLOBAL DEFAULT 13 realpath@@GLIBC_2.3 > 33 FUNC GLOBAL DEFAULT 13 realpath at GLIBC_2.2.5) > > I do not know how Rust deals with this. Is it at all possible to > fixate all the call chain over all possibly involved dynamics? > What do i gain from initializing an object with a default value if > that default value is not not not not one of the values that > i expect after some external function is called? > > Sure i not rarely see patches fly by where one more memset(,0,) is > used to fully initialize a struct / prevent memory address > disclosures (i only track BSDs). > And there are still patches that fix bugs on old code that > sometimes is twenty years or more, say zlib or tzcode. > And then there are compiler bugs that bring in bugs -- that is not > avoidable, even if the documentation is clear and obvious like > > /* The application can compare zlibVersion and ZLIB_VERSION for consistency. > If the first character differs, the library code actually used is not > compatible with the zlib.h header file used by the application. This check > is automatically made by deflateInit and inflateInit. > */ > > That is only graspable by a human programmer that reads it. Rapid > application development that surely is not. > (And actually i am not sure this is really true. But i personally > would hope for it. It is more earthy, and has more blood, sweat > and tears.) > > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From will.senn at gmail.com Wed Feb 1 10:50:31 2023 From: will.senn at gmail.com (Will Senn) Date: Tue, 31 Jan 2023 18:50:31 -0600 Subject: [TUHS] Algol rules: was something about Rust is not C++ In-Reply-To: <20230201004023.rHE9j%steffen@sdaoden.eu> References: <20230201004023.rHE9j%steffen@sdaoden.eu> Message-ID: <3808a35c-2ee0-2081-4128-c8196b4732c0@gmail.com> Well, I just read this as Rust is dead... here's hoping, but seriously, if we're gonna go off and have a language vs language discussion, I personally don't think we've had any real language innovation since Algol 60, well maybe lisp... sheesh, surely we're in COFF territory. On 1/31/23 6:40 PM, Steffen Nurpmeso wrote: > ron minnich wrote in > : > |That example was a simplified bit of code from a widely used code base. All > |I need to do is change the function g go a pointer to function, or have it > |be provided by a .so, and all bets are off. > | > |In any event, the important thing here is not that y should be initialized, > |or should not; it's that it is not possible to get a consistent answer on > |the question, from people who have been writing in C for decades. > > I find the syntax just terrible. (I have not programmed with it.) > I mean annotations are for the better, ok, (but i luckily get away > with only "const" and "volatile" (and "mutable"), and leave things > like "restrict" be a good man). Johannes Lundberg i think it was > who then left FreeBSD (?) but pointing to a Rust program > he had written (i cannot find the reference), that was a few years > ago (i looked once i composed this message first, it might even > had been as early as 2017!), and i was lucky i do not have to deal > with it. > > Even nim-lang.org that at least converted its code to plain C back > in the day when it was still called Nimrod is too heavy for me now, > but claims to be hard realtime aware etc. It at least tries to > give programmers some syntactic sugar that makes people happy when > they look at the screen for 7 hours (underpaid) or 16 hours > (over-ambitioned). Like the only python thing i like, the > syntax sugar. But as languages grow they get more and more > "refined", and now i read things like > > type > BinaryTree*[T] = ref object # BinaryTree is a generic type with > # generic param `T` > le, ri: BinaryTree[T] # left and right subtrees; may be nil > data: T # the data stored in a node > > proc newNode*[T](data: T): BinaryTree[T] = > # constructor for a node > new(result) > result.data = data > > which gets me off a bit and makes me think that "hey, maybe > Objective-C is not really the worst thing" (despite the syntax). > > I do not know. Everything beyond a small monolithic > self-contained thing is a problem per se. You can then unit test > atomically, and if thousands of modules do that, you plug them to > a better whole. But that also not a good answer, all those flakes > that live their own life, many maybe even in remote locations out > of any control. > > You could have a language which hard fixates all the call chain, > or you could have tools which bring this to a small and simple > language which does not offer it. A compiler can figure out which > variables are assigned etc and could create in-object-file > annotations which the linker automatically verifies. > Of course there are many code paths through functions. > > Back in 2009 when i bought the one Apple i wanted to have i tried > out their Development software, which i think required internet > access. All the pop-ups and titles, i think it (later?) could > compile on-the-fly and inject the new object in the running tested > application, etc. > > And then there are semantic description languages like interface > builders, where robots create the actual code. So then you could > have Corba interface descriptions / DBUS and plug it all via it. > > Then Rob Pike says "make it a string" (more or less), and luckily > i do not have dyslexia. > > Maybe Qt has a good answer by not only not banishing the > C preprocessor, but introducing another one on top. > So then the compiler can analyze the code and generate a correct > variable-state-at-function-call-time state that a dynamic linker > could then verify against the consumer or producer (whatever is > needed) of linked modules, that link modules, that link modules, > all of which are subject to replacements due to development > iterations, bug patches etc, ie, new releases. > > As in, the library versioning that is used for ELF object files, > today often even linker scripts which furtherly diversify this, > offer are not enough, they do not do this. They only bundle > a name to a library version, or multiple (as in > > 1966 FUNC GLOBAL DEFAULT 13 realpath@@GLIBC_2.3 > 33 FUNC GLOBAL DEFAULT 13 realpath at GLIBC_2.2.5) > > I do not know how Rust deals with this. Is it at all possible to > fixate all the call chain over all possibly involved dynamics? > What do i gain from initializing an object with a default value if > that default value is not not not not one of the values that > i expect after some external function is called? > > Sure i not rarely see patches fly by where one more memset(,0,) is > used to fully initialize a struct / prevent memory address > disclosures (i only track BSDs). > And there are still patches that fix bugs on old code that > sometimes is twenty years or more, say zlib or tzcode. > And then there are compiler bugs that bring in bugs -- that is not > avoidable, even if the documentation is clear and obvious like > > /* The application can compare zlibVersion and ZLIB_VERSION for consistency. > If the first character differs, the library code actually used is not > compatible with the zlib.h header file used by the application. This check > is automatically made by deflateInit and inflateInit. > */ > > That is only graspable by a human programmer that reads it. Rapid > application development that surely is not. > (And actually i am not sure this is really true. But i personally > would hope for it. It is more earthy, and has more blood, sweat > and tears.) > > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) From luther at makerlisp.com Wed Feb 1 11:03:57 2023 From: luther at makerlisp.com (Luther Johnson) Date: Tue, 31 Jan 2023 18:03:57 -0700 Subject: [TUHS] yet another C discussion (YACD) and: Rust is not C++ In-Reply-To: <20230201004939.GB6988@mcvoy.com> References: <20230201004023.rHE9j%steffen@sdaoden.eu> <20230201004939.GB6988@mcvoy.com> Message-ID: I think people expect the language to do too much these days, sort of like if it compiles without warnings then likely as not it works. I suppose that can be true with some languages if you follow certain patterns cookbooks, but it's not true of C or any program I ever wrote, I think this issue is a combination of style and language mechanics. I recently had to explain to a young manager, why I couldn't look at a program and tell him definitively whether it works or not. I did explain, but I don't think he really understood me, and I'm sure he was disappointed that I wasn't "good enough" to do that. Sort of the negative proof thing - if I find something wrong, I can make a pretty convincing argument why it's broken, but if I don't see anything wrong, that doesn't mean it works, and depending on such reviews without testing (which is also incomplete, but has the benefit that it may happen upon something we don't think of) is incredibly dangerous. I think general software engineering knowledge and experience cannot be 'obsoleted' or made less relevant by better languages. If they help, great, but you have to do the other part too. As languages advance and get better at catching (certain kinds of) mistakes, I worry that engineers are not putting enough time into observation and understanding of how their programs actually work (or do not). On 01/31/2023 05:49 PM, Larry McVoy wrote: > Even though I participated in this thread, so I too have sinned, this > definitely wants to be discussed elsewhere. comp.lang.c maybe? > > This discussion reminds a lot of what my career has been like. Over and > over again, I got told "that won't work". I wasn't very interested in > those people, if they stayed out of my way. I was way more interested > in the people who said "hmm, maybe if you did it this way". > > I've written a ton of working C code. I've managed and guided others > to do the same. I'm positive that I've written way more commercially > supported C code than was present in v6/v7 kernels. Not sure about > userspace, I think Unix has me beat there. > > The point? It's very possible to write working C code. You need good > programmers and those seem to be going out of style so people are turning > to Rust because it doesn't compile crappy code. > > I'm just happy to be retired, C worked for me for 40+ years, I feel > like I dodged a learning curve bullet by getting out before I had to > switch to Rust (or whatever). > > On Wed, Feb 01, 2023 at 01:40:23AM +0100, Steffen Nurpmeso wrote: >> ron minnich wrote in >> : >> |That example was a simplified bit of code from a widely used code base. All >> |I need to do is change the function g go a pointer to function, or have it >> |be provided by a .so, and all bets are off. >> | >> |In any event, the important thing here is not that y should be initialized, >> |or should not; it's that it is not possible to get a consistent answer on >> |the question, from people who have been writing in C for decades. >> >> I find the syntax just terrible. (I have not programmed with it.) >> I mean annotations are for the better, ok, (but i luckily get away >> with only "const" and "volatile" (and "mutable"), and leave things >> like "restrict" be a good man). Johannes Lundberg i think it was >> who then left FreeBSD (?) but pointing to a Rust program >> he had written (i cannot find the reference), that was a few years >> ago (i looked once i composed this message first, it might even >> had been as early as 2017!), and i was lucky i do not have to deal >> with it. >> >> Even nim-lang.org that at least converted its code to plain C back >> in the day when it was still called Nimrod is too heavy for me now, >> but claims to be hard realtime aware etc. It at least tries to >> give programmers some syntactic sugar that makes people happy when >> they look at the screen for 7 hours (underpaid) or 16 hours >> (over-ambitioned). Like the only python thing i like, the >> syntax sugar. But as languages grow they get more and more >> "refined", and now i read things like >> >> type >> BinaryTree*[T] = ref object # BinaryTree is a generic type with >> # generic param `T` >> le, ri: BinaryTree[T] # left and right subtrees; may be nil >> data: T # the data stored in a node >> >> proc newNode*[T](data: T): BinaryTree[T] = >> # constructor for a node >> new(result) >> result.data = data >> >> which gets me off a bit and makes me think that "hey, maybe >> Objective-C is not really the worst thing" (despite the syntax). >> >> I do not know. Everything beyond a small monolithic >> self-contained thing is a problem per se. You can then unit test >> atomically, and if thousands of modules do that, you plug them to >> a better whole. But that also not a good answer, all those flakes >> that live their own life, many maybe even in remote locations out >> of any control. >> >> You could have a language which hard fixates all the call chain, >> or you could have tools which bring this to a small and simple >> language which does not offer it. A compiler can figure out which >> variables are assigned etc and could create in-object-file >> annotations which the linker automatically verifies. >> Of course there are many code paths through functions. >> >> Back in 2009 when i bought the one Apple i wanted to have i tried >> out their Development software, which i think required internet >> access. All the pop-ups and titles, i think it (later?) could >> compile on-the-fly and inject the new object in the running tested >> application, etc. >> >> And then there are semantic description languages like interface >> builders, where robots create the actual code. So then you could >> have Corba interface descriptions / DBUS and plug it all via it. >> >> Then Rob Pike says "make it a string" (more or less), and luckily >> i do not have dyslexia. >> >> Maybe Qt has a good answer by not only not banishing the >> C preprocessor, but introducing another one on top. >> So then the compiler can analyze the code and generate a correct >> variable-state-at-function-call-time state that a dynamic linker >> could then verify against the consumer or producer (whatever is >> needed) of linked modules, that link modules, that link modules, >> all of which are subject to replacements due to development >> iterations, bug patches etc, ie, new releases. >> >> As in, the library versioning that is used for ELF object files, >> today often even linker scripts which furtherly diversify this, >> offer are not enough, they do not do this. They only bundle >> a name to a library version, or multiple (as in >> >> 1966 FUNC GLOBAL DEFAULT 13 realpath@@GLIBC_2.3 >> 33 FUNC GLOBAL DEFAULT 13 realpath at GLIBC_2.2.5) >> >> I do not know how Rust deals with this. Is it at all possible to >> fixate all the call chain over all possibly involved dynamics? >> What do i gain from initializing an object with a default value if >> that default value is not not not not one of the values that >> i expect after some external function is called? >> >> Sure i not rarely see patches fly by where one more memset(,0,) is >> used to fully initialize a struct / prevent memory address >> disclosures (i only track BSDs). >> And there are still patches that fix bugs on old code that >> sometimes is twenty years or more, say zlib or tzcode. >> And then there are compiler bugs that bring in bugs -- that is not >> avoidable, even if the documentation is clear and obvious like >> >> /* The application can compare zlibVersion and ZLIB_VERSION for consistency. >> If the first character differs, the library code actually used is not >> compatible with the zlib.h header file used by the application. This check >> is automatically made by deflateInit and inflateInit. >> */ >> >> That is only graspable by a human programmer that reads it. Rapid >> application development that surely is not. >> (And actually i am not sure this is really true. But i personally >> would hope for it. It is more earthy, and has more blood, sweat >> and tears.) >> >> --steffen >> | >> |Der Kragenbaer, The moon bear, >> |der holt sich munter he cheerfully and one by one >> |einen nach dem anderen runter wa.ks himself off >> |(By Robert Gernhardt) From chet.ramey at case.edu Wed Feb 1 11:18:27 2023 From: chet.ramey at case.edu (Chet Ramey) Date: Tue, 31 Jan 2023 20:18:27 -0500 Subject: [TUHS] Algol rules: was something about Rust is not C++ In-Reply-To: <3808a35c-2ee0-2081-4128-c8196b4732c0@gmail.com> References: <20230201004023.rHE9j%steffen@sdaoden.eu> <3808a35c-2ee0-2081-4128-c8196b4732c0@gmail.com> Message-ID: <83279e5b-ff90-76a4-ac97-21a2d7853ea8@case.edu> On 1/31/23 7:50 PM, Will Senn wrote: > Well, I just read this as Rust is dead... Rust never sleeps. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From luther at makerlisp.com Wed Feb 1 11:24:02 2023 From: luther at makerlisp.com (Luther Johnson) Date: Tue, 31 Jan 2023 18:24:02 -0700 Subject: [TUHS] Algol rules: was something about Rust is not C++ In-Reply-To: <83279e5b-ff90-76a4-ac97-21a2d7853ea8@case.edu> References: <20230201004023.rHE9j%steffen@sdaoden.eu> <3808a35c-2ee0-2081-4128-c8196b4732c0@gmail.com> <83279e5b-ff90-76a4-ac97-21a2d7853ea8@case.edu> Message-ID: <38733302-0a64-e0f1-7c3e-049415ced6d2@makerlisp.com> I worry about Rust on bare metal. On 01/31/2023 06:18 PM, Chet Ramey wrote: > On 1/31/23 7:50 PM, Will Senn wrote: >> Well, I just read this as Rust is dead... > > Rust never sleeps. > From tuhs at tuhs.org Wed Feb 1 12:22:13 2023 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Wed, 1 Feb 2023 12:22:13 +1000 Subject: [TUHS] yet another C discussion (YACD) In-Reply-To: References: <20230201004023.rHE9j%steffen@sdaoden.eu> <20230201004939.GB6988@mcvoy.com> Message-ID: On Wed, Feb 01, 2023 at 01:50:05AM +0000, segaloco via COFF wrote: > COFF'd Thanks Matt. Yes please, C vs. Rust should mv to the COFF list. Cheers, Warren From will.senn at gmail.com Wed Feb 1 12:30:50 2023 From: will.senn at gmail.com (Will Senn) Date: Tue, 31 Jan 2023 20:30:50 -0600 Subject: [TUHS] Unix game origins - stories similar to Crowther's Adventure Message-ID: All, I just saw this over on dragonflydigest.com: https://0j2zj3i75g.unbox.ifarchive.org/0j2zj3i75g/Article.html It's an article from 2007 about the history and genesis of the Colossal Cave Adventure game - replete with lots of pics. What I found fascinating was that the game is based on the author's actual cave explorations vis a vis the real Colossal Cave. Gives you a whole new appreciation for the game. My question is do y'all know of any interesting backstories about games that were developed and or gained traction on unix? I like some of the early stuff (wumpus, in particular), but know nothing of origins. Or, was it all just mindless entertainment designed to wile away the time? Spacewar, I know a bit about, but not the story, if there is one... Maybe, somebody needed to develop a new program to simulate the use of fuel in rockets against gravity and... so... lunar lander was born? I dunno, as somebody who grew up playing text games, I'd like to think there was more behind the fun that mindless entertainment... So, how about it, was your officemate at bell labs tooling away nights writing a game that had the whole office addicted to playing it, while little did they know the characters were characterizations of his annoying neighbors? If you don't mind, if you take the thread off into the distance and away from unix game origins, please rename the thread quickly :). Thanks, Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Feb 1 12:58:19 2023 From: clemc at ccc.com (Clem Cole) Date: Tue, 31 Jan 2023 21:58:19 -0500 Subject: [TUHS] Unix game origins - stories similar to Crowther's Adventure In-Reply-To: References: Message-ID: Wumpus predates Unix. It was a basic game on the GE635 when I first saw it in the mid 1960s along with a horse racing game a blackjack game. I ran them on the ASR 33 in my Dads office it’s what got be interested in computers actually Many games were on different systems and reimplemented. david Ahl eventually published a book called 101 basic computer games which was a collection that he brought together from a number of systems. HP2000, TSS/8, DTSS and GCOS as well as TOPS and later RSTS all had games as well as Unix. As for Moonlander, my friend the late Jack Burness wrote it as a contractor for DEC as a demo for the GT40 and was also not of Unix origin. Originally it was DOS11 later RT11. It’s an amazing piece of code - check out his 16 bit cordic integer trig routines. He sat in the MIT library for a weekend figuring out how to write them. Hand simulating everything. Went back to Maynard and typed up his routines. Very impressive Rogue was Unix however but that was BSD. On Tue, Jan 31, 2023 at 9:32 PM Will Senn wrote: > All, > > I just saw this over on dragonflydigest.com: > > https://0j2zj3i75g.unbox.ifarchive.org/0j2zj3i75g/Article.html > > It's an article from 2007 about the history and genesis of the Colossal > Cave Adventure game - replete with lots of pics. What I found fascinating > was that the game is based on the author's actual cave explorations vis a > vis the real Colossal Cave. Gives you a whole new appreciation for the game. > > My question is do y'all know of any interesting backstories about games > that were developed and or gained traction on unix? I like some of the > early stuff (wumpus, in particular), but know nothing of origins. Or, was > it all just mindless entertainment designed to wile away the time? > Spacewar, I know a bit about, but not the story, if there is one... Maybe, > somebody needed to develop a new program to simulate the use of fuel in > rockets against gravity and... so... lunar lander was born? I dunno, as > somebody who grew up playing text games, I'd like to think there was more > behind the fun that mindless entertainment... So, how about it, was your > officemate at bell labs tooling away nights writing a game that had the > whole office addicted to playing it, while little did they know the > characters were characterizations of his annoying neighbors? > > If you don't mind, if you take the thread off into the distance and away > from unix game origins, please rename the thread quickly :). > > Thanks, > > Will > > > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Wed Feb 1 14:50:14 2023 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Tue, 31 Jan 2023 23:50:14 -0500 Subject: [TUHS] Unix game origins - stories similar to Crowther's Adventure In-Reply-To: References: Message-ID: Moo (later marketed as Master Mind) was an import from Cambridge. A moo leader board sprang up. Maintenance of a file that had to be written on behalf of any user posed a conundrum--how could you protect it against false updates? Dennis's novel solution to this and related problems was setuid, which garnered the only Unix patent. Wumpus was my preschool kids' introduction to computing. They learned the tricks of shooting crooked arrows faster than I learned that the cave is always the same, with random room numbers. Only years later did I discover by reading the code that the shape is a dodecahedron. That fact would have helped note-taking a lot. Doug On Tue, Jan 31, 2023 at 9:59 PM Clem Cole wrote: > > Wumpus predates Unix. It was a basic game on the GE635 when I first saw it in the mid 1960s along with a horse racing game a blackjack game. I ran them on the ASR 33 in my Dads office it’s what got be interested in computers actually > > Many games were on different systems and reimplemented. david Ahl eventually published a book called 101 basic computer games which was a collection that he brought together from a number of systems. > > HP2000, TSS/8, DTSS and GCOS as well as TOPS and later RSTS all had games as well as Unix. > > As for Moonlander, my friend the late Jack Burness wrote it as a contractor for DEC as a demo for the GT40 and was also not of Unix origin. Originally it was DOS11 later RT11. It’s an amazing piece of code - check out his 16 bit cordic integer trig routines. He sat in the MIT library for a weekend figuring out how to write them. Hand simulating everything. Went back to Maynard and typed up his routines. Very impressive > > Rogue was Unix however but that was BSD. > > > On Tue, Jan 31, 2023 at 9:32 PM Will Senn wrote: >> >> All, >> >> I just saw this over on dragonflydigest.com: >> >> https://0j2zj3i75g.unbox.ifarchive.org/0j2zj3i75g/Article.html >> >> It's an article from 2007 about the history and genesis of the Colossal Cave Adventure game - replete with lots of pics. What I found fascinating was that the game is based on the author's actual cave explorations vis a vis the real Colossal Cave. Gives you a whole new appreciation for the game. >> >> My question is do y'all know of any interesting backstories about games that were developed and or gained traction on unix? I like some of the early stuff (wumpus, in particular), but know nothing of origins. Or, was it all just mindless entertainment designed to wile away the time? Spacewar, I know a bit about, but not the story, if there is one... Maybe, somebody needed to develop a new program to simulate the use of fuel in rockets against gravity and... so... lunar lander was born? I dunno, as somebody who grew up playing text games, I'd like to think there was more behind the fun that mindless entertainment... So, how about it, was your officemate at bell labs tooling away nights writing a game that had the whole office addicted to playing it, while little did they know the characters were characterizations of his annoying neighbors? >> >> If you don't mind, if you take the thread off into the distance and away from unix game origins, please rename the thread quickly :). >> >> Thanks, >> >> Will >> >> > -- > Sent from a handheld expect more typos than usual From robpike at gmail.com Wed Feb 1 15:36:16 2023 From: robpike at gmail.com (Rob Pike) Date: Wed, 1 Feb 2023 16:36:16 +1100 Subject: [TUHS] Unix game origins - stories similar to Crowther's Adventure In-Reply-To: References: Message-ID: Best TUHS mail ever. I never knew that setuid was for moo. What other secrets are you hoarding? -rob On Wed, Feb 1, 2023 at 3:51 PM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > Moo (later marketed as Master Mind) was an import from Cambridge. A > moo leader board sprang up. Maintenance of a file that had to be > written on behalf of any user posed a conundrum--how could you protect > it against false updates? Dennis's novel solution to this and related > problems was setuid, which garnered the only Unix patent. > > Wumpus was my preschool kids' introduction to computing. They learned > the tricks of shooting crooked arrows faster than I learned that the > cave is always the same, with random room numbers. Only years later > did I discover by reading the code that the shape is a dodecahedron. > That fact would have helped note-taking a lot. > > Doug > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsg at jsg.id.au Wed Feb 1 16:27:41 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Wed, 1 Feb 2023 17:27:41 +1100 Subject: [TUHS] Unix game origins - stories similar to Crowther's Adventure In-Reply-To: References: Message-ID: https://www.multicians.org/moo-in-multics-1972.pdf "there is no way of saying 'a person can have access to a data base only when it is accessed through a particular program'. This is, of course, a difference between Multics and the University of Cambridge system." "Tampering occurred quite a lot in the beginning but has fallen off" http://jfwaf.net/Bulls_and_Cows.pdf The Cambridge machine was Titan. Describes more of the history. On Tue, Jan 31, 2023 at 11:50:14PM -0500, Douglas McIlroy wrote: > Moo (later marketed as Master Mind) was an import from Cambridge. A > moo leader board sprang up. Maintenance of a file that had to be > written on behalf of any user posed a conundrum--how could you protect > it against false updates? Dennis's novel solution to this and related > problems was setuid, which garnered the only Unix patent. > > Wumpus was my preschool kids' introduction to computing. They learned > the tricks of shooting crooked arrows faster than I learned that the > cave is always the same, with random room numbers. Only years later > did I discover by reading the code that the shape is a dodecahedron. > That fact would have helped note-taking a lot. > > Doug > > On Tue, Jan 31, 2023 at 9:59 PM Clem Cole wrote: > > > > Wumpus predates Unix. It was a basic game on the GE635 when I first saw it in the mid 1960s along with a horse racing game a blackjack game. I ran them on the ASR 33 in my Dads office it’s what got be interested in computers actually > > > > Many games were on different systems and reimplemented. david Ahl eventually published a book called 101 basic computer games which was a collection that he brought together from a number of systems. > > > > HP2000, TSS/8, DTSS and GCOS as well as TOPS and later RSTS all had games as well as Unix. > > > > As for Moonlander, my friend the late Jack Burness wrote it as a contractor for DEC as a demo for the GT40 and was also not of Unix origin. Originally it was DOS11 later RT11. It’s an amazing piece of code - check out his 16 bit cordic integer trig routines. He sat in the MIT library for a weekend figuring out how to write them. Hand simulating everything. Went back to Maynard and typed up his routines. Very impressive > > > > Rogue was Unix however but that was BSD. > > > > > > On Tue, Jan 31, 2023 at 9:32 PM Will Senn wrote: > >> > >> All, > >> > >> I just saw this over on dragonflydigest.com: > >> > >> https://0j2zj3i75g.unbox.ifarchive.org/0j2zj3i75g/Article.html > >> > >> It's an article from 2007 about the history and genesis of the Colossal Cave Adventure game - replete with lots of pics. What I found fascinating was that the game is based on the author's actual cave explorations vis a vis the real Colossal Cave. Gives you a whole new appreciation for the game. > >> > >> My question is do y'all know of any interesting backstories about games that were developed and or gained traction on unix? I like some of the early stuff (wumpus, in particular), but know nothing of origins. Or, was it all just mindless entertainment designed to wile away the time? Spacewar, I know a bit about, but not the story, if there is one... Maybe, somebody needed to develop a new program to simulate the use of fuel in rockets against gravity and... so... lunar lander was born? I dunno, as somebody who grew up playing text games, I'd like to think there was more behind the fun that mindless entertainment... So, how about it, was your officemate at bell labs tooling away nights writing a game that had the whole office addicted to playing it, while little did they know the characters were characterizations of his annoying neighbors? > >> > >> If you don't mind, if you take the thread off into the distance and away from unix game origins, please rename the thread quickly :). > >> > >> Thanks, > >> > >> Will > >> > >> > > -- > > Sent from a handheld expect more typos than usual > From jsg at jsg.id.au Wed Feb 1 17:09:24 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Wed, 1 Feb 2023 18:09:24 +1100 Subject: [TUHS] Unix game origins - stories similar to Crowther's Adventure In-Reply-To: References: Message-ID: Also mentioned in the UNIX Time-Sharing System CACM paper. "this protection scheme easily solves the MOO accounting problem posed by ``Aleph-null.'' [8]" 8. Aleph-null, `Computer Recreations,' Software Practice and Experience, 1 2, April-June 1971, pp. 201-204. https://onlinelibrary.wiley.com/toc/1097024x/1971/1/2 On Wed, Feb 01, 2023 at 05:27:41PM +1100, Jonathan Gray wrote: > https://www.multicians.org/moo-in-multics-1972.pdf > > "there is no way of saying 'a person can have access to a data base only > when it is accessed through a particular program'. This is, of course, a > difference between Multics and the University of Cambridge system." > > "Tampering occurred quite a lot in the beginning but has fallen off" > > http://jfwaf.net/Bulls_and_Cows.pdf > > The Cambridge machine was Titan. Describes more of the history. > > On Tue, Jan 31, 2023 at 11:50:14PM -0500, Douglas McIlroy wrote: > > Moo (later marketed as Master Mind) was an import from Cambridge. A > > moo leader board sprang up. Maintenance of a file that had to be > > written on behalf of any user posed a conundrum--how could you protect > > it against false updates? Dennis's novel solution to this and related > > problems was setuid, which garnered the only Unix patent. > > > > Wumpus was my preschool kids' introduction to computing. They learned > > the tricks of shooting crooked arrows faster than I learned that the > > cave is always the same, with random room numbers. Only years later > > did I discover by reading the code that the shape is a dodecahedron. > > That fact would have helped note-taking a lot. > > > > Doug > > > > On Tue, Jan 31, 2023 at 9:59 PM Clem Cole wrote: > > > > > > Wumpus predates Unix. It was a basic game on the GE635 when I first saw it in the mid 1960s along with a horse racing game a blackjack game. I ran them on the ASR 33 in my Dads office it’s what got be interested in computers actually > > > > > > Many games were on different systems and reimplemented. david Ahl eventually published a book called 101 basic computer games which was a collection that he brought together from a number of systems. > > > > > > HP2000, TSS/8, DTSS and GCOS as well as TOPS and later RSTS all had games as well as Unix. > > > > > > As for Moonlander, my friend the late Jack Burness wrote it as a contractor for DEC as a demo for the GT40 and was also not of Unix origin. Originally it was DOS11 later RT11. It’s an amazing piece of code - check out his 16 bit cordic integer trig routines. He sat in the MIT library for a weekend figuring out how to write them. Hand simulating everything. Went back to Maynard and typed up his routines. Very impressive > > > > > > Rogue was Unix however but that was BSD. > > > > > > > > > On Tue, Jan 31, 2023 at 9:32 PM Will Senn wrote: > > >> > > >> All, > > >> > > >> I just saw this over on dragonflydigest.com: > > >> > > >> https://0j2zj3i75g.unbox.ifarchive.org/0j2zj3i75g/Article.html > > >> > > >> It's an article from 2007 about the history and genesis of the Colossal Cave Adventure game - replete with lots of pics. What I found fascinating was that the game is based on the author's actual cave explorations vis a vis the real Colossal Cave. Gives you a whole new appreciation for the game. > > >> > > >> My question is do y'all know of any interesting backstories about games that were developed and or gained traction on unix? I like some of the early stuff (wumpus, in particular), but know nothing of origins. Or, was it all just mindless entertainment designed to wile away the time? Spacewar, I know a bit about, but not the story, if there is one... Maybe, somebody needed to develop a new program to simulate the use of fuel in rockets against gravity and... so... lunar lander was born? I dunno, as somebody who grew up playing text games, I'd like to think there was more behind the fun that mindless entertainment... So, how about it, was your officemate at bell labs tooling away nights writing a game that had the whole office addicted to playing it, while little did they know the characters were characterizations of his annoying neighbors? > > >> > > >> If you don't mind, if you take the thread off into the distance and away from unix game origins, please rename the thread quickly :). > > >> > > >> Thanks, > > >> > > >> Will > > >> > > >> > > > -- > > > Sent from a handheld expect more typos than usual > > From rich.salz at gmail.com Thu Feb 2 00:41:22 2023 From: rich.salz at gmail.com (Rich Salz) Date: Wed, 1 Feb 2023 09:41:22 -0500 Subject: [TUHS] Unix game origins - stories similar to Crowther's Adventure In-Reply-To: References: Message-ID: "Hunt the Wumpus" came from the People's Computer Company in San Francisco. Wikipedia article on him is nice; we corresponded a bit. CHM has all the old PCC newsletters, it seems, at https://www.computerhistory.org/collections/catalog/102661095 What about Peter Langston's empire? It was distributed as object code, but someone (CMU?) decompiled it to C, and we built it on Pyramid's. It created its world by having meteors smash into it to distribute the trace and heavy metals IIRC. On Tue, Jan 31, 2023 at 9:32 PM Will Senn wrote: > All, > > I just saw this over on dragonflydigest.com: > > https://0j2zj3i75g.unbox.ifarchive.org/0j2zj3i75g/Article.html > > It's an article from 2007 about the history and genesis of the Colossal > Cave Adventure game - replete with lots of pics. What I found fascinating > was that the game is based on the author's actual cave explorations vis a > vis the real Colossal Cave. Gives you a whole new appreciation for the game. > > My question is do y'all know of any interesting backstories about games > that were developed and or gained traction on unix? I like some of the > early stuff (wumpus, in particular), but know nothing of origins. Or, was > it all just mindless entertainment designed to wile away the time? > Spacewar, I know a bit about, but not the story, if there is one... Maybe, > somebody needed to develop a new program to simulate the use of fuel in > rockets against gravity and... so... lunar lander was born? I dunno, as > somebody who grew up playing text games, I'd like to think there was more > behind the fun that mindless entertainment... So, how about it, was your > officemate at bell labs tooling away nights writing a game that had the > whole office addicted to playing it, while little did they know the > characters were characterizations of his annoying neighbors? > > If you don't mind, if you take the thread off into the distance and away > from unix game origins, please rename the thread quickly :). > > Thanks, > > Will > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Thu Feb 2 01:22:29 2023 From: will.senn at gmail.com (Will Senn) Date: Wed, 1 Feb 2023 09:22:29 -0600 Subject: [TUHS] Unix game origins - stories similar to Crowther's Adventure In-Reply-To: References: Message-ID: Rich, When you mentioned empire and Peter Langston, I was confused, but then realized there were probably two empires. My dad introduced me to the other empire (Walter Bright's) way, way back when (Original version was on PDP-10). It's probably my favorite text game of all time. The c version vms-empire still builds and runs today (on my mac), these days it's all fancy ascii, back in the day it was pure text, IIRC: ------------- Choose a difficulty level where 0 is easy and 99 is hard: 99 Your city is at 1797 EMPIRE, Version 5.00 site Amdahl 1-Apr-1988 Detailed directions are in EMPIRE.DOC Cannot open saved game: No such file or directory ------------- ++.  16 +O.     R +..  18 ------------- Bright's touchy cuz folks are always taking credit for work he initially did - independently of Langston, one must note :), but the story of its development is interesting, nonetheless: http://www.classicempire.com/history.html Will On 2/1/23 8:41 AM, Rich Salz wrote: > Peter Langston's empire From steffen at sdaoden.eu Wed Feb 1 10:53:35 2023 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 01 Feb 2023 01:53:35 +0100 Subject: [TUHS] yet another C discussion (YACD) and: Rust is not C++ In-Reply-To: <20230201004023.rHE9j%steffen@sdaoden.eu> References: <20230201004023.rHE9j%steffen@sdaoden.eu> Message-ID: <20230201005335.zF5nW%steffen@sdaoden.eu> Steffen Nurpmeso wrote in <20230201004023.rHE9j%steffen at sdaoden.eu>: ... P.S.: What i will never forget, it came in the major news TV program of Germany (ARD Tagesschau, public law; iirc), was when JAVA came up. Small (Campus?) Cafe in America, two young male programmers and one young female programmer, and she was asked why JAVA, .. and she said something like "this is our opportunity". Maybe this is the thing about the name Rust that i go with. Whether it makes anything "better", i do not know. But it is maybe an opportunity for a generation to go/nim/julia their way. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From luther at makerlisp.com Thu Feb 2 02:34:45 2023 From: luther at makerlisp.com (Luther Johnson) Date: Wed, 1 Feb 2023 09:34:45 -0700 Subject: [TUHS] yet another C discussion (YACD) and: Rust is not C++ In-Reply-To: <20230201005335.zF5nW%steffen@sdaoden.eu> References: <20230201004023.rHE9j%steffen@sdaoden.eu> <20230201005335.zF5nW%steffen@sdaoden.eu> Message-ID: I think you are right, this is an important component, people joining and identifying themselves with a language movement. And planning to be there to fill the need for "Language X" programmers. On 01/31/2023 05:53 PM, Steffen Nurpmeso wrote: > Steffen Nurpmeso wrote in > <20230201004023.rHE9j%steffen at sdaoden.eu>: > ... > > P.S.: What i will never forget, it came in the major news TV > program of Germany (ARD Tagesschau, public law; iirc), was when > JAVA came up. Small (Campus?) Cafe in America, two young male > programmers and one young female programmer, and she was asked why > JAVA, .. and she said something like "this is our opportunity". > Maybe this is the thing about the name Rust that i go with. > Whether it makes anything "better", i do not know. But it is > maybe an opportunity for a generation to go/nim/julia their way. > > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) > From rich.salz at gmail.com Thu Feb 2 03:34:57 2023 From: rich.salz at gmail.com (Rich Salz) Date: Wed, 1 Feb 2023 12:34:57 -0500 Subject: [TUHS] Unix game origins - stories similar to Crowther's Adventure In-Reply-To: References: Message-ID: Walter Bright, the D, etc., guy? Neat article, thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Thu Feb 2 03:52:26 2023 From: henry.r.bent at gmail.com (Henry Bent) Date: Wed, 1 Feb 2023 12:52:26 -0500 Subject: [TUHS] Unix game origins - stories similar to Crowther's Adventure In-Reply-To: References: Message-ID: On Tue, 31 Jan 2023 at 21:32, Will Senn wrote: > All, > > I just saw this over on dragonflydigest.com: > > https://0j2zj3i75g.unbox.ifarchive.org/0j2zj3i75g/Article.html > > It's an article from 2007 about the history and genesis of the Colossal > Cave Adventure game - replete with lots of pics. What I found fascinating > was that the game is based on the author's actual cave explorations vis a > vis the real Colossal Cave. Gives you a whole new appreciation for the game. > My uncle, Richard Zopf, did extensive exploration of Mammoth Cave with Will Crowther. My understanding is that Colossal Cave was truly impressive in its ability to replicate the real situations that the cavers faced, especially given the limitations of the storage and processing abilities of the machines at the time. To my mind this stands well apart from the more rudimentary early computer games which were very math/logic driven vs. the concept of an "open world" exploration. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Thu Feb 2 04:33:11 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 01 Feb 2023 18:33:11 +0000 Subject: [TUHS] Unix game origins - stories similar to Crowther's Adventure In-Reply-To: References: Message-ID: <9rlsK1lcp2ffNj2lkBadLwVDPzGlSjgLbwwByJXMv4FDhSsmezMSUlcXw4jZjc0rM8XtULgrAv6I2g-nurUzaS_fZicDHORQVLSU0fzEydY=@protonmail.com> In the annals of UNIX gaming, have there ever been notable games that have operated as multiple processes, perhaps using formal IPC or even just pipes or shared files for communication between separate processes (games with networking notwithstanding)? Reason I ask is I've been thinking about the feasibility of such an architecture, what with perhaps a "system server" process that reads various IPC for messages from a "game" process and then internally translates those into X11 calls, OpenGL, etc. Could even be multiple servers for different concerns (display, audio, input, networking obviously). This would be similar to a multi-threaded engine except that we're using system processes and IPC rather than threads and synchronization primitives (on some implementations, these may converge pretty heavily). An added benefit I could see would be having the one server running with the ability to arbitrate multiple games through the same pipelines. Think something like SDL but running as a server taking IPC calls to do things instead of just a library being called in the same process space. This is probably a bit more Plan 9-ish that UNIX-ish, but would be an interesting use of the system architecture. A compelling argument for not doing things this way would be platform lock-in, as sure other operating systems would probably provide similar enough process and IPC mechanisms to achieve the same end result, but no such thing would exist on the preponderance of embedded platforms running no OS, such as cartridge-based consoles. Still, I could see such an architecture begetting clean separation of system interfacing from game logic which would then lend itself well to library-ization of the system server part in embedded cases where it has to be directly entered rather than IPC'd to from yonder process. There is then of course the performance hit of communicating between the different components via IPC rather than it all being self-contained, but as we all know, an increase in maintainability and code clarity sometimes makes a little performance and/or size hit worth it. Anyone know of anyone doing this back before id, Unreal, and Unity cornered the game engine market? - Matt G. ------- Original Message ------- On Wednesday, February 1st, 2023 at 9:52 AM, Henry Bent wrote: > On Tue, 31 Jan 2023 at 21:32, Will Senn wrote: > >> All, >> >> I just saw this over on dragonflydigest.com: >> >> https://0j2zj3i75g.unbox.ifarchive.org/0j2zj3i75g/Article.html >> >> It's an article from 2007 about the history and genesis of the Colossal Cave Adventure game - replete with lots of pics. What I found fascinating was that the game is based on the author's actual cave explorations vis a vis the real Colossal Cave. Gives you a whole new appreciation for the game. > > My uncle, Richard Zopf, did extensive exploration of Mammoth Cave with Will Crowther. My understanding is that Colossal Cave was truly impressive in its ability to replicate the real situations that the cavers faced, especially given the limitations of the storage and processing abilities of the machines at the time. To my mind this stands well apart from the more rudimentary early computer games which were very math/logic driven vs. the concept of an "open world" exploration. > > -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Thu Feb 2 05:09:26 2023 From: rich.salz at gmail.com (Rich Salz) Date: Wed, 1 Feb 2023 14:09:26 -0500 Subject: [TUHS] Unix game origins - stories similar to Crowther's Adventure In-Reply-To: <9rlsK1lcp2ffNj2lkBadLwVDPzGlSjgLbwwByJXMv4FDhSsmezMSUlcXw4jZjc0rM8XtULgrAv6I2g-nurUzaS_fZicDHORQVLSU0fzEydY=@protonmail.com> References: <9rlsK1lcp2ffNj2lkBadLwVDPzGlSjgLbwwByJXMv4FDhSsmezMSUlcXw4jZjc0rM8XtULgrAv6I2g-nurUzaS_fZicDHORQVLSU0fzEydY=@protonmail.com> Message-ID: On Wed, Feb 1, 2023 at 1:33 PM segaloco via TUHS wrote: > In the annals of UNIX gaming, have there ever been notable games that have > operated as multiple processes, perhaps using formal IPC or even just pipes > or shared files for communication between separate processes (games with > networking notwithstanding)? > https://www.unix.com/man-page/bsd/6/hunt/ source at http://ftp.funet.fi/pub/unix/4.3bsd/reno/games/hunt/hunt/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Thu Feb 2 05:16:33 2023 From: crossd at gmail.com (Dan Cross) Date: Wed, 1 Feb 2023 14:16:33 -0500 Subject: [TUHS] Unix game origins - stories similar to Crowther's Adventure In-Reply-To: References: <9rlsK1lcp2ffNj2lkBadLwVDPzGlSjgLbwwByJXMv4FDhSsmezMSUlcXw4jZjc0rM8XtULgrAv6I2g-nurUzaS_fZicDHORQVLSU0fzEydY=@protonmail.com> Message-ID: [TUHS to Bcc] On Wed, Feb 1, 2023 at 2:11 PM Rich Salz wrote: > On Wed, Feb 1, 2023 at 1:33 PM segaloco via TUHS wrote: >> In the annals of UNIX gaming, have there ever been notable games that have operated as multiple processes, perhaps using formal IPC or even just pipes or shared files for communication between separate processes (games with networking notwithstanding)? > > https://www.unix.com/man-page/bsd/6/hunt/ > source at http://ftp.funet.fi/pub/unix/4.3bsd/reno/games/hunt/hunt/ Hunt was the one that I thought of immediately. We used to play that on Suns and VAXen and it could be lively. There were a number of such games, as Clem mentioned; others I remember were xtrek, hearts, and various Chess and Go servers. - Dan C. From douglas.mcilroy at dartmouth.edu Thu Feb 2 06:21:42 2023 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Wed, 1 Feb 2023 15:21:42 -0500 Subject: [TUHS] Unix game origins - stories similar to Crowther's Adventure Message-ID: > In the annals of UNIX gaming, have there ever been notable games that have operated as multiple processes, perhaps using formal IPC or even just pipes or shared files for communication between separate processes I don't know any Unix examples, but DTSS (Dartmouth Time Sharing System) "communication files" were used for the purpose. For a fuller story see https://www.cs.dartmouth.edu/~doug/DTSS/commfiles.pdf > This is probably a bit more Plan 9-ish than UNIX-ish So it was with communication files, which allowed IO system calls to be handled in userland. Unfortunately, communication files were complicated and turned out to be an evolutionary dead end. They had had no ancestral connection to successors like pipes and Plan 9. Equally unfortunately, 9P, the very foundation of Plan 9, seems to have met the same fate. Doug From dave at horsfall.org Thu Feb 2 06:23:34 2023 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 2 Feb 2023 07:23:34 +1100 (EST) Subject: [TUHS] Unix game origins - stories similar to Crowther's Adventure In-Reply-To: References: Message-ID: On Wed, 1 Feb 2023, Rob Pike wrote: > Best TUHS mail ever. I never knew that setuid was for moo. What other > secrets are you hoarding? It was mentioned in the Ed 6 docs ("It solves the MOO problem" or some such); now I know what it is... -- Dave From a.phillip.garcia at gmail.com Thu Feb 2 06:41:58 2023 From: a.phillip.garcia at gmail.com (A. P. Garcia) Date: Wed, 1 Feb 2023 15:41:58 -0500 Subject: [TUHS] Unix game origins - stories similar to Crowther's Adventure In-Reply-To: References: Message-ID: > Equally unfortunately, 9P, the very foundation of Plan 9, seems to have met the same fate. Not at all. :-) Windows Subsystem for Linux uses 9P to share files between the linux and windows environments on the same box: $ ps -ef UID PID PPID C STIME TTY TIME CMD root 1 0 0 Jan30 ? 00:00:00 /init root 4 1 0 Jan30 ? 00:00:02 plan9 --control-socket 5 --log-level 4 --server-fd 6 --pipe-fd 8 --log-truncate On Wed, Feb 1, 2023 at 3:23 PM Douglas McIlroy wrote: > > > In the annals of UNIX gaming, have there ever been notable games that have operated as multiple processes, perhaps using formal IPC or even just pipes or shared files for communication between separate processes > > I don't know any Unix examples, but DTSS (Dartmouth Time Sharing > System) "communication files" were used for the purpose. For a fuller > story see https://www.cs.dartmouth.edu/~doug/DTSS/commfiles.pdf > > > This is probably a bit more Plan 9-ish than UNIX-ish > > So it was with communication files, which allowed IO system calls to > be handled in userland. Unfortunately, communication files were > complicated and turned out to be an evolutionary dead end. They had > had no ancestral connection to successors like pipes and Plan 9. > Equally unfortunately, 9P, the very foundation of Plan 9, seems to > have met the same fate. > > Doug From rminnich at gmail.com Thu Feb 2 06:47:18 2023 From: rminnich at gmail.com (ron minnich) Date: Wed, 1 Feb 2023 12:47:18 -0800 Subject: [TUHS] Unix game origins - stories similar to Crowther's Adventure In-Reply-To: References: Message-ID: The u-root cpu command uses 9p, and Eric Van Hensbergen recently submitted changes to Linux kernel 9p that boost throughput 10x. We continue to look at ways to make it faster. 9p lives on in several corners of the world :-) On Wed, Feb 1, 2023 at 12:43 PM A. P. Garcia wrote: > > Equally unfortunately, 9P, the very foundation of Plan 9, seems to > have met the same fate. > > Not at all. :-) Windows Subsystem for Linux uses 9P to share files > between the linux and windows environments on the same box: > > $ ps -ef > UID PID PPID C STIME TTY TIME CMD > root 1 0 0 Jan30 ? 00:00:00 /init > root 4 1 0 Jan30 ? 00:00:02 plan9 --control-socket > 5 --log-level 4 --server-fd 6 --pipe-fd 8 --log-truncate > > On Wed, Feb 1, 2023 at 3:23 PM Douglas McIlroy > wrote: > > > > > In the annals of UNIX gaming, have there ever been notable games that > have operated as multiple processes, perhaps using formal IPC or even just > pipes or shared files for communication between separate processes > > > > I don't know any Unix examples, but DTSS (Dartmouth Time Sharing > > System) "communication files" were used for the purpose. For a fuller > > story see https://www.cs.dartmouth.edu/~doug/DTSS/commfiles.pdf > > > > > This is probably a bit more Plan 9-ish than UNIX-ish > > > > So it was with communication files, which allowed IO system calls to > > be handled in userland. Unfortunately, communication files were > > complicated and turned out to be an evolutionary dead end. They had > > had no ancestral connection to successors like pipes and Plan 9. > > Equally unfortunately, 9P, the very foundation of Plan 9, seems to > > have met the same fate. > > > > Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Thu Feb 2 09:24:18 2023 From: crossd at gmail.com (Dan Cross) Date: Wed, 1 Feb 2023 18:24:18 -0500 Subject: [TUHS] Unix game origins - stories similar to Crowther's Adventure In-Reply-To: References: Message-ID: [TUHS to Bcc] On Wed, Feb 1, 2023 at 3:23 PM Douglas McIlroy wrote: > > In the annals of UNIX gaming, have there ever been notable games that have operated as multiple processes, perhaps using formal IPC or even just pipes or shared files for communication between separate processes > > I don't know any Unix examples, but DTSS (Dartmouth Time Sharing > System) "communication files" were used for the purpose. For a fuller > story see https://www.cs.dartmouth.edu/~doug/DTSS/commfiles.pdf Interesting. This is now being discussed on the Multicians list (which had a DTSS emulator! Done for use by SIPB). Warren Montgomery discussed communication files under DTSS for precisely this kind of thing; apparently he had a chess program he may have run under them. Barry Margolin responded that he wrote a multiuser chat program using them on the DTSS system at Grumman. Margolin suggests a modern Unix-ish analogue may be pseudo-ttys, which came up here earlier (I responded pointing to your wonderful note linked above). > > This is probably a bit more Plan 9-ish than UNIX-ish > > So it was with communication files, which allowed IO system calls to > be handled in userland. Unfortunately, communication files were > complicated and turned out to be an evolutionary dead end. They had > had no ancestral connection to successors like pipes and Plan 9. > Equally unfortunately, 9P, the very foundation of Plan 9, seems to > have met the same fate. I wonder if there was an analogy to multiplexed files, which I admit to knowing very little about. A cursory glance at mpx(2) on 7th Edition at least suggests some surface similarities. - Dan C. From douglas.mcilroy at dartmouth.edu Thu Feb 2 09:31:41 2023 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Wed, 1 Feb 2023 18:31:41 -0500 Subject: [TUHS] Unix game origins - stories similar to Crowther's Adventure In-Reply-To: References: Message-ID: > 9p lives on in several corners of the world :-) Thanks to all who set me straight. Sometimes being corrected is good news. Doug On Wed, Feb 1, 2023 at 3:47 PM ron minnich wrote: > > The u-root cpu command uses 9p, and Eric Van Hensbergen recently submitted changes to Linux kernel 9p that boost throughput 10x. We continue to look at ways to make it faster. > > 9p lives on in several corners of the world :-) > > On Wed, Feb 1, 2023 at 12:43 PM A. P. Garcia wrote: >> >> > Equally unfortunately, 9P, the very foundation of Plan 9, seems to >> have met the same fate. >> >> Not at all. :-) Windows Subsystem for Linux uses 9P to share files >> between the linux and windows environments on the same box: >> >> $ ps -ef >> UID PID PPID C STIME TTY TIME CMD >> root 1 0 0 Jan30 ? 00:00:00 /init >> root 4 1 0 Jan30 ? 00:00:02 plan9 --control-socket >> 5 --log-level 4 --server-fd 6 --pipe-fd 8 --log-truncate >> >> On Wed, Feb 1, 2023 at 3:23 PM Douglas McIlroy >> wrote: >> > >> > > In the annals of UNIX gaming, have there ever been notable games that have operated as multiple processes, perhaps using formal IPC or even just pipes or shared files for communication between separate processes >> > >> > I don't know any Unix examples, but DTSS (Dartmouth Time Sharing >> > System) "communication files" were used for the purpose. For a fuller >> > story see https://www.cs.dartmouth.edu/~doug/DTSS/commfiles.pdf >> > >> > > This is probably a bit more Plan 9-ish than UNIX-ish >> > >> > So it was with communication files, which allowed IO system calls to >> > be handled in userland. Unfortunately, communication files were >> > complicated and turned out to be an evolutionary dead end. They had >> > had no ancestral connection to successors like pipes and Plan 9. >> > Equally unfortunately, 9P, the very foundation of Plan 9, seems to >> > have met the same fate. >> > >> > Doug From jnc at mercury.lcs.mit.edu Thu Feb 2 10:43:28 2023 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 1 Feb 2023 19:43:28 -0500 (EST) Subject: [TUHS] Unix game origins - stories similar to Crowther's Adventure Message-ID: <20230202004328.8872918C073@mercury.lcs.mit.edu> > segaloco wrote: > In the annals of UNIX gaming, have there ever been notable games that > have operated as multiple processes, perhaps using formal IPC or even > just pipes or shared files for communication between separate processes > (games with networking notwithstanding)? The machine of the DSSR/RTS group at MIT-LCS, Steve Ward's group (an -11/70 running roughly PWB1) had an implementation of a form of Perquackey: https://en.wikipedia.org/wiki/Perquackey that was a multi-player game; I'm pretty sure there was a process per player, and they communicated, I'm pretty sure, through pipes, not files - there was certainly no IPC in that system. IIIRC, the way it worked was that there was a parent process, and it spawned a child process for each terminal that was playing, and the children could all communicate through pipes. (They had to communicate because in that version, all the players shared a single set of dice, and once one person had played a word, the other players couldn't play that word. So speed was important in playing; people got really addicted to it.) Alas, although their machine was very similar to CSR's (although ours was an -11/45 with an Able ENABLE and a lot of memory, making it a lot more like a /70), and we shared most code between the machines, and I have a full dump of the CSR machine, we apparently didn't have any of the games on the CSR machine, so I can't look at the source to confirm exactly how it worked. Noel From ralph at inputplus.co.uk Thu Feb 2 17:30:14 2023 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Thu, 02 Feb 2023 07:30:14 +0000 Subject: [TUHS] 9P Lives. (Was: Unix game origins - stories similar to Crowther's Adventure) In-Reply-To: References: Message-ID: <20230202073014.BD140201F7@orac.inputplus.co.uk> Hi Doug, > > 9p lives on in several corners of the world :-) > > Thanks to all who set me straight. Sometimes being corrected is good > news. Another corner where I keep spotting 9P is on small embedded devices which lack physical controls but want to give a rich interface to the outside world without going the web-server route. 9P is also used inside QEMU, the machine emulator and ‘virtualiser’. https://wiki.qemu.org/Documentation/9p -- Cheers, Ralph. From marc.donner at gmail.com Fri Feb 3 01:35:09 2023 From: marc.donner at gmail.com (Marc Donner) Date: Thu, 2 Feb 2023 10:35:09 -0500 Subject: [TUHS] Unix game origins - stories similar to Crowther's Adventure In-Reply-To: References: Message-ID: There was an enjoyable documentary "Get Lamp" about Adventure and related text adventure games released several years ago: http://www.getlamp.com/ Best, Marc ===== nygeek.net mindthegapdialogs.com/home On Wed, Feb 1, 2023 at 3:24 PM Dave Horsfall wrote: > On Wed, 1 Feb 2023, Rob Pike wrote: > > > Best TUHS mail ever. I never knew that setuid was for moo. What other > > secrets are you hoarding? > > It was mentioned in the Ed 6 docs ("It solves the MOO problem" or some > such); now I know what it is... > > -- Dave > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Fri Feb 3 05:02:32 2023 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 2 Feb 2023 14:02:32 -0500 (EST) Subject: [TUHS] Typesetter C compiler Message-ID: <20230202190232.C79D118C073@mercury.lcs.mit.edu> There was recent discussion here about the Typesetter C compiler; I don't have the energy to look through the tons of opinion posts about recent programming styles, to find the posts about actual Unix history which related to that compiler, but I seem to recall that there was interest in locating the source for it? I had strted to look, but then got distracted by some other high-pri stuff; here are a few notes that I had accumulated to reply - I hope they aren't too out-of-date by now. I have a copy of it, from the dump of the CSR machine (I can't make the whole dump public, sorry; it has personal material from a bunch of people mixed in). I was pretty sure the C compiler from Mini-Unix, here: https://minnie.tuhs.org/cgi-bin/utree.pl?file=Mini-Unix/usr/source/c was from the right timeframe to be the Typesetter C, but a quick check of c0.h, shows that it's not; that one seems to be more like the V6 one. (Ditto for LSX.) The PWB1 one: https://minnie.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/c/c seems, from a very quick look at c0.h (using that nice side-by-side compare feature on the TUHS archive - thanks, Warren!), to be somewhat close to the Typesetter C. It would be interesting to compare that one to the CSR one (which definitely is) to be sure. Also, the V7 C compiler (not pcc, but the PDP-11 one) seems to be a fairly close relative, too. Noel From jsg at jsg.id.au Fri Feb 3 07:57:14 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Fri, 3 Feb 2023 08:57:14 +1100 Subject: [TUHS] Typesetter C compiler In-Reply-To: <20230202190232.C79D118C073@mercury.lcs.mit.edu> References: <20230202190232.C79D118C073@mercury.lcs.mit.edu> Message-ID: On Thu, Feb 02, 2023 at 02:02:32PM -0500, Noel Chiappa wrote: > > There was recent discussion here about the Typesetter C compiler; I don't > have the energy to look through the tons of opinion posts about recent > programming styles, to find the posts about actual Unix history which related > to that compiler, but I seem to recall that there was interest in locating > the source for it? I had strted to look, but then got distracted by some > other high-pri stuff; here are a few notes that I had accumulated to reply - > I hope they aren't too out-of-date by now. > > I have a copy of it, from the dump of the CSR machine (I can't make the whole > dump public, sorry; it has personal material from a bunch of people mixed in). discussed in https://minnie.tuhs.org/pipermail/tuhs/2023-January/027393.html The best case would be a copy of the tape that was licensed and distributed externally. With nroff/troff/ar/stdio. > > I was pretty sure the C compiler from Mini-Unix, here: > > https://minnie.tuhs.org/cgi-bin/utree.pl?file=Mini-Unix/usr/source/c > > was from the right timeframe to be the Typesetter C, but a quick check of > c0.h, shows that it's not; that one seems to be more like the V6 one. (Ditto > for LSX.) > > The PWB1 one: > > https://minnie.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/c/c > > seems, from a very quick look at c0.h (using that nice side-by-side compare > feature on the TUHS archive - thanks, Warren!), to be somewhat close to the > Typesetter C. It would be interesting to compare that one to the CSR one > (which definitely is) to be sure. Yes, PWB/UNIX 1.0, AUSAM where READ_ME includes: "the 'C' compiler contained herein is not merely a local abheration of 'C' but is in fact a version from bell labs via indirect means the lanuage accepted by this 'C' would is identical to that accepted by the 'C' compiler distributed with PWB/UNIX also corresponds to syntax given in Kernigan and Plaugher's book on 'C'" the Interdata 7/32 tree in modified form and binaries in Tim_Shoppa_v6/unix_v6.rl02.gz as you described in http://mercury.lcs.mit.edu/~jnc/tech/ImprovingV6.html Compared to v6 the phototypesetter compiler adds: unsigned union typedef. The v7 compiler included enums and structure assignment described in "Recent Changes to C" November 15, 1978 https://www.bell-labs.com/usr/dmr/www/cchanges.pdf 2bsd includes diffs for it upgrade/c/READ_ME: "Mon Apr 16 23:33:04 PST 1979 The C compiler modifications here given as diffs will change a phototypesetter C compiler to have a larger symbol table (change to c0.h) and to generate switch code in I space (c11.c). We install the changed C compiler as -t0 and -t1; see the source for cc.c. You need make a modified C compiler only if you intend to recompile ex (-t0) or if you wish to compile with smaller data spaces per user; all code will work fine without -t1, and all programs but ex will compile with normal symbol table size." and refers to it in src/ex: /* * Since the phototypesetter v7-epsilon * C compiler doesn't have structure assignment... */ /* * Would like to use structured assignment but early * v7 compiler (released with phototypesetter for v6) * can't hack it. */ > > Also, the V7 C compiler (not pcc, but the PDP-11 one) seems to be a fairly > close relative, too. > > Noel > From crossd at gmail.com Fri Feb 3 08:36:44 2023 From: crossd at gmail.com (Dan Cross) Date: Thu, 2 Feb 2023 17:36:44 -0500 Subject: [TUHS] Proper use of TUHS (was Re: Typesetter C compiler) In-Reply-To: <20230202190232.C79D118C073@mercury.lcs.mit.edu> References: <20230202190232.C79D118C073@mercury.lcs.mit.edu> Message-ID: On Thu, Feb 2, 2023 at 2:02 PM Noel Chiappa wrote: > [snip] I don't > have the energy to look through the tons of opinion posts about recent > programming styles, to find the posts about actual Unix history which related > to that compiler, > [snip] On a semi-related note.... I have found TUHS a valuable resource, not just for discussing Unix history, but for gaining a deeper understanding of systems which informs my present and that I imagine will influence my future work as well. However, lately it has become clear that this is not always a welcome use of the list. I don't think COFF is universally appropriate for that either. So, the question becomes: what _is_ that forum, if such a thing exists at all? - Dan C. From lm at mcvoy.com Fri Feb 3 08:41:36 2023 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 2 Feb 2023 14:41:36 -0800 Subject: [TUHS] Proper use of TUHS (was Re: Typesetter C compiler) In-Reply-To: References: <20230202190232.C79D118C073@mercury.lcs.mit.edu> Message-ID: <20230202224136.GI30555@mcvoy.com> On Thu, Feb 02, 2023 at 05:36:44PM -0500, Dan Cross wrote: > On Thu, Feb 2, 2023 at 2:02 PM Noel Chiappa wrote: > > [snip] I don't > > have the energy to look through the tons of opinion posts about recent > > programming styles, to find the posts about actual Unix history which related > > to that compiler, > > [snip] > > On a semi-related note.... > > I have found TUHS a valuable resource, not just for discussing Unix > history, but for gaining a deeper understanding of systems which > informs my present and that I imagine will influence my future work as > well. > > However, lately it has become clear that this is not always a welcome > use of the list. I don't think COFF is universally appropriate for > that either. COFF lacks critical mass. It's a common problem, you have a mailing list with enough people that it is interesting and it gets too noisy so the admin creates a more chatty list and only a small subset of the people pick that up. I don't know how to fix that. > So, the question becomes: what _is_ that forum, if such a thing exists at all? Well, Hacker News was supposed to be really system-y. I tried it for a while, there was some good stuff there but it was drowned out by wannabe hackers talking about trivial stuff as if it were interesting. So I gave up. If you find a Unix/Systems sort of forum, that actually has something to say, let us know. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From jcapp at anteil.com Fri Feb 3 08:47:50 2023 From: jcapp at anteil.com (Jim Capp) Date: Thu, 2 Feb 2023 17:47:50 -0500 Subject: [TUHS] Proper use of TUHS (was Re: Typesetter C compiler) In-Reply-To: <20230202224136.GI30555@mcvoy.com> References: <20230202224136.GI30555@mcvoy.com> Message-ID: <82A9B97D-9ED2-4DFF-A1DE-765437ACCE9B@anteil.com> I love the topics and people on TUHS. But I also subscribed to COFF so I could pick up on interesting scraps not suitable for TUHS. > On Feb 2, 2023, at 5:41 PM, Larry McVoy wrote: > > On Thu, Feb 02, 2023 at 05:36:44PM -0500, Dan Cross wrote: >>> On Thu, Feb 2, 2023 at 2:02 PM Noel Chiappa wrote: >>> [snip] I don't >>> have the energy to look through the tons of opinion posts about recent >>> programming styles, to find the posts about actual Unix history which related >>> to that compiler, >>> [snip] >> >> On a semi-related note.... >> >> I have found TUHS a valuable resource, not just for discussing Unix >> history, but for gaining a deeper understanding of systems which >> informs my present and that I imagine will influence my future work as >> well. >> >> However, lately it has become clear that this is not always a welcome >> use of the list. I don't think COFF is universally appropriate for >> that either. > > COFF lacks critical mass. It's a common problem, you have a mailing list > with enough people that it is interesting and it gets too noisy so the > admin creates a more chatty list and only a small subset of the people > pick that up. I don't know how to fix that. > >> So, the question becomes: what _is_ that forum, if such a thing exists at all? > > Well, Hacker News was supposed to be really system-y. I tried it for a while, > there was some good stuff there but it was drowned out by wannabe hackers > talking about trivial stuff as if it were interesting. So I gave up. > > If you find a Unix/Systems sort of forum, that actually has something to > say, let us know. > -- > --- > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From jsg at jsg.id.au Fri Feb 3 10:43:26 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Fri, 3 Feb 2023 11:43:26 +1100 Subject: [TUHS] Typesetter C compiler In-Reply-To: References: <20230202190232.C79D118C073@mercury.lcs.mit.edu> Message-ID: On Fri, Feb 03, 2023 at 08:57:14AM +1100, Jonathan Gray wrote: > On Thu, Feb 02, 2023 at 02:02:32PM -0500, Noel Chiappa wrote: > > > > There was recent discussion here about the Typesetter C compiler; I don't > > have the energy to look through the tons of opinion posts about recent > > programming styles, to find the posts about actual Unix history which related > > to that compiler, but I seem to recall that there was interest in locating > > the source for it? I had strted to look, but then got distracted by some > > other high-pri stuff; here are a few notes that I had accumulated to reply - > > I hope they aren't too out-of-date by now. > > > > I have a copy of it, from the dump of the CSR machine (I can't make the whole > > dump public, sorry; it has personal material from a bunch of people mixed in). > > discussed in > https://minnie.tuhs.org/pipermail/tuhs/2023-January/027393.html > > The best case would be a copy of the tape that was licensed and > distributed externally. With nroff/troff/ar/stdio. > > > > > I was pretty sure the C compiler from Mini-Unix, here: > > > > https://minnie.tuhs.org/cgi-bin/utree.pl?file=Mini-Unix/usr/source/c > > > > was from the right timeframe to be the Typesetter C, but a quick check of > > c0.h, shows that it's not; that one seems to be more like the V6 one. (Ditto > > for LSX.) > > > > The PWB1 one: > > > > https://minnie.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/c/c > > > > seems, from a very quick look at c0.h (using that nice side-by-side compare > > feature on the TUHS archive - thanks, Warren!), to be somewhat close to the > > Typesetter C. It would be interesting to compare that one to the CSR one > > (which definitely is) to be sure. > > Yes, PWB/UNIX 1.0, AUSAM where READ_ME includes: > "the 'C' compiler contained herein is > not merely a local abheration of > 'C' but is in fact a version from bell > labs via indirect means > the lanuage accepted by this 'C' > would is identical to that accepted by the 'C' > compiler distributed with PWB/UNIX > also corresponds to syntax given in > Kernigan and Plaugher's book on 'C'" > > the Interdata 7/32 tree in modified form > > and binaries in Tim_Shoppa_v6/unix_v6.rl02.gz as you described in > http://mercury.lcs.mit.edu/~jnc/tech/ImprovingV6.html > > Compared to v6 the phototypesetter compiler adds: > unsigned union typedef. > > The v7 compiler included enums and structure assignment > described in "Recent Changes to C" November 15, 1978 > https://www.bell-labs.com/usr/dmr/www/cchanges.pdf As you mentioned in https://minnie.tuhs.org/pipermail/tuhs/2014-October/006834.html there is also a (Miller modified?) "New C Compiler Features" document https://minnie.tuhs.org/cgi-bin/utree.pl?file=Interdata732/usr/doc/cdoc/newstuff.nr a different, earlier? version of this is "C Changes" https://minnie.tuhs.org/cgi-bin/utree.pl?file=AUSAM/source/c_compiler/newstuff.doc another version of "C Changes" in https://minnie.tuhs.org/cgi-bin/utree.pl?file=32V/usr/doc/ctour/newstuff the C Reference Manual, May 1, 1977 in Documents for the PWB/UNIX Time-Sharing System, Edition 1.0 https://bitsavers.org/pdf/att/unix/PWB_UNIX/Documents_for_the_PWB_UNIX_Time-Sharing_System_Edition_1.0_197710.pdf (44M) notes: "Warning: The data type name short is not recognized by the version of the C compiler that is distributed as part of PWB/UNIX Edition 1.0." but otherwise seems quite close to the C Reference Manual text in tuhs/Documentation/Books/Draft-KandR-C-Book.pdf From dave at horsfall.org Fri Feb 3 11:44:58 2023 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 3 Feb 2023 12:44:58 +1100 (EST) Subject: [TUHS] Proper use of TUHS (was Re: Typesetter C compiler) In-Reply-To: References: <20230202190232.C79D118C073@mercury.lcs.mit.edu> Message-ID: On Thu, 2 Feb 2023, Dan Cross wrote: [...] > However, lately it has become clear that this is not always a welcome > use of the list. I don't think COFF is universally appropriate for that > either. As the perp responsible for the name "COFF", could I mayhaps suggest: Computer Retro Admin Perps ? Best I could do on the spur of the moment... > So, the question becomes: what _is_ that forum, if such a thing exists > at all? A new list? Social media is for the birds; Usenet is dead, film at 11. -- Dave From athornton at gmail.com Fri Feb 3 12:15:37 2023 From: athornton at gmail.com (Adam Thornton) Date: Thu, 2 Feb 2023 19:15:37 -0700 Subject: [TUHS] Unix game origins - stories similar to Crowther's Adventure In-Reply-To: References: Message-ID: Hey, I'm in _Get Lamp_! It's a cool documentary. On Thu, Feb 2, 2023 at 8:36 AM Marc Donner wrote: > There was an enjoyable documentary "Get Lamp" about Adventure and related > text adventure games released several years ago: > > http://www.getlamp.com/ > > Best, > > Marc > ===== > nygeek.net > mindthegapdialogs.com/home > > > On Wed, Feb 1, 2023 at 3:24 PM Dave Horsfall wrote: > >> On Wed, 1 Feb 2023, Rob Pike wrote: >> >> > Best TUHS mail ever. I never knew that setuid was for moo. What other >> > secrets are you hoarding? >> >> It was mentioned in the Ed 6 docs ("It solves the MOO problem" or some >> such); now I know what it is... >> >> -- Dave >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Fri Feb 3 16:36:34 2023 From: lars at nocrew.org (Lars Brinkhoff) Date: Fri, 03 Feb 2023 06:36:34 +0000 Subject: [TUHS] Proper use of TUHS (was Re: Typesetter C compiler) In-Reply-To: (Dan Cross's message of "Thu, 2 Feb 2023 17:36:44 -0500") References: <20230202190232.C79D118C073@mercury.lcs.mit.edu> Message-ID: <7wv8kj6yrx.fsf@junk.nocrew.org> Dan Cross wrote: > So, the question becomes: what _is_ that forum, if such a thing > exists at all? Some options: - Cctalk email list. - ClassicCMP Discord. - Retrocomputingforum.com. - Various Facebook groups. From ads at salewski.email Fri Feb 3 23:17:24 2023 From: ads at salewski.email (Alan D. Salewski) Date: Fri, 03 Feb 2023 08:17:24 -0500 Subject: [TUHS] Proper use of TUHS (was Re: Typesetter C compiler) In-Reply-To: References: <20230202190232.C79D118C073@mercury.lcs.mit.edu> Message-ID: <2c576b87-05fc-4ba2-8854-bc7b90809303@app.fastmail.com> On Thu, Feb 2, 2023, at 20:44, Dave Horsfall wrote: [...] > A new list? Social media is for the birds; Usenet is dead, film at 11. > > -- Dave Usenet is dead. Long live Usenet! -- a l a n d. s a l e w s k i ads at salewski.email salewski at att.net https://github.com/salewski From lm at mcvoy.com Fri Feb 3 23:55:41 2023 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 3 Feb 2023 05:55:41 -0800 Subject: [TUHS] Proper use of TUHS (was Re: Typesetter C compiler) In-Reply-To: <2c576b87-05fc-4ba2-8854-bc7b90809303@app.fastmail.com> References: <20230202190232.C79D118C073@mercury.lcs.mit.edu> <2c576b87-05fc-4ba2-8854-bc7b90809303@app.fastmail.com> Message-ID: <20230203135541.GR30555@mcvoy.com> On Fri, Feb 03, 2023 at 08:17:24AM -0500, Alan D. Salewski wrote: > > > On Thu, Feb 2, 2023, at 20:44, Dave Horsfall wrote: > [...] > > A new list? Social media is for the birds; Usenet is dead, film at 11. > > > > -- Dave > > Usenet is dead. Long live Usenet! I do miss comp.* - that was pleasant, a bunch of technical places divided by topic. I had many a fine discussion in comp.arch. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From chet.ramey at case.edu Sat Feb 4 00:11:35 2023 From: chet.ramey at case.edu (Chet Ramey) Date: Fri, 3 Feb 2023 09:11:35 -0500 Subject: [TUHS] Proper use of TUHS (was Re: Typesetter C compiler) In-Reply-To: References: <20230202190232.C79D118C073@mercury.lcs.mit.edu> Message-ID: <73d0b98b-ae3f-428d-1b2e-feada7fc98a1@case.edu> On 2/2/23 8:44 PM, Dave Horsfall wrote: >> So, the question becomes: what _is_ that forum, if such a thing exists >> at all? > > A new list? Social media is for the birds; Usenet is dead, film at 11. A new list, if it serves its purpose of providing interesting content, will eventually undergo the same thing. It's always going end up being some variant of Yogi Berra's famous "nobody goes there anymore, it's too crowded." -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From lm at mcvoy.com Sat Feb 4 00:15:40 2023 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 3 Feb 2023 06:15:40 -0800 Subject: [TUHS] Proper use of TUHS (was Re: Typesetter C compiler) In-Reply-To: <73d0b98b-ae3f-428d-1b2e-feada7fc98a1@case.edu> References: <20230202190232.C79D118C073@mercury.lcs.mit.edu> <73d0b98b-ae3f-428d-1b2e-feada7fc98a1@case.edu> Message-ID: <20230203141540.GS30555@mcvoy.com> On Fri, Feb 03, 2023 at 09:11:35AM -0500, Chet Ramey wrote: > On 2/2/23 8:44 PM, Dave Horsfall wrote: > > >>So, the question becomes: what _is_ that forum, if such a thing exists > >>at all? > > > >A new list? Social media is for the birds; Usenet is dead, film at 11. > > A new list, if it serves its purpose of providing interesting content, will > eventually undergo the same thing. It's always going end up being some > variant of Yogi Berra's famous "nobody goes there anymore, it's too > crowded." In my opinion, Warren has been threading the needle nicely. He lets stuff go into the weeds a bit but has a pretty good sense of when it is annoying people that we all want to keep around. He's very understated about it all but he keeps this list pretty sane. If you haven't joined COFF, maybe consider it, if that got big enough then the other stuff could be done over there. From crossd at gmail.com Sat Feb 4 02:39:38 2023 From: crossd at gmail.com (Dan Cross) Date: Fri, 3 Feb 2023 11:39:38 -0500 Subject: [TUHS] Proper use of TUHS (was Re: Typesetter C compiler) In-Reply-To: <20230203141540.GS30555@mcvoy.com> References: <20230202190232.C79D118C073@mercury.lcs.mit.edu> <73d0b98b-ae3f-428d-1b2e-feada7fc98a1@case.edu> <20230203141540.GS30555@mcvoy.com> Message-ID: On Fri, Feb 3, 2023 at 9:16 AM Larry McVoy wrote: > On Fri, Feb 03, 2023 at 09:11:35AM -0500, Chet Ramey wrote: > > On 2/2/23 8:44 PM, Dave Horsfall wrote: > > >>So, the question becomes: what _is_ that forum, if such a thing exists > > >>at all? > > > > > >A new list? Social media is for the birds; Usenet is dead, film at 11. > > > > A new list, if it serves its purpose of providing interesting content, will > > eventually undergo the same thing. It's always going end up being some > > variant of Yogi Berra's famous "nobody goes there anymore, it's too > > crowded." > > In my opinion, Warren has been threading the needle nicely. He lets stuff > go into the weeds a bit but has a pretty good sense of when it is annoying > people that we all want to keep around. He's very understated about it > all but he keeps this list pretty sane. > > If you haven't joined COFF, maybe consider it, if that got big enough > then the other stuff could be done over there. Some folks have given good suggestions, which I appreciate, but perhaps it would help to explain exactly what I'm looking for. I think that new system designs remain important, but without a historical perspective, they run the risk of repeating old mistakes, ignoring prior art, etc. Something I appreciate about TUHS is how one has access to so many of the key players in Unix as well as other systems: the perspective those people bring to the discussion is illuminating. But TUHS is clearly meant to be a Unix history list, not a "list about new systems where we can ask about history because that helps us build those new systems". In that sense, I'm not looking for COFF or a retro or classic computer list, either, but for something explicitly modern yet informed by history. I don't believe such a thing actually exists. - Dan C. From lm at mcvoy.com Sat Feb 4 02:54:20 2023 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 3 Feb 2023 08:54:20 -0800 Subject: [TUHS] Proper use of TUHS (was Re: Typesetter C compiler) In-Reply-To: References: <20230202190232.C79D118C073@mercury.lcs.mit.edu> <73d0b98b-ae3f-428d-1b2e-feada7fc98a1@case.edu> <20230203141540.GS30555@mcvoy.com> Message-ID: <20230203165420.GB19745@mcvoy.com> On Fri, Feb 03, 2023 at 11:39:38AM -0500, Dan Cross wrote: > On Fri, Feb 3, 2023 at 9:16 AM Larry McVoy wrote: > > On Fri, Feb 03, 2023 at 09:11:35AM -0500, Chet Ramey wrote: > > > On 2/2/23 8:44 PM, Dave Horsfall wrote: > > > >>So, the question becomes: what _is_ that forum, if such a thing exists > > > >>at all? > > > > > > > >A new list? Social media is for the birds; Usenet is dead, film at 11. > > > > > > A new list, if it serves its purpose of providing interesting content, will > > > eventually undergo the same thing. It's always going end up being some > > > variant of Yogi Berra's famous "nobody goes there anymore, it's too > > > crowded." > > > > In my opinion, Warren has been threading the needle nicely. He lets stuff > > go into the weeds a bit but has a pretty good sense of when it is annoying > > people that we all want to keep around. He's very understated about it > > all but he keeps this list pretty sane. > > > > If you haven't joined COFF, maybe consider it, if that got big enough > > then the other stuff could be done over there. > > Some folks have given good suggestions, which I appreciate, but > perhaps it would help to explain exactly what I'm looking for. > > I think that new system designs remain important, but without a > historical perspective, they run the risk of repeating old mistakes, > ignoring prior art, etc. Something I appreciate about TUHS is how one > has access to so many of the key players in Unix as well as other > systems: the perspective those people bring to the discussion is > illuminating. > > But TUHS is clearly meant to be a Unix history list, not a "list about > new systems where we can ask about history because that helps us build > those new systems". In that sense, I'm not looking for COFF or a retro > or classic computer list, either, but for something explicitly modern > yet informed by history. Well, be careful listening to gray beards too much. Much of my knowledge comes from working with rotating disks and all of those instincts are wrong when you can get a 1TB SSD (Samsun no less) for $104 at Best Buy. The old guys who held sway in some of the jobs I had, fell into the trap of "we tried that and it didn't work". Well, yeah, trying to write AI programs in Prolog in 1985, yeah, that didn't work, the CPUs were nowhere near fast enough. Today we have machine learning that seems to work, self driving cars that sort of work, ChatGPT that literally scares me, the old rules don't apply. Some things will never go away, like keep your fingers off of my L1 cache lines. I think it's mostly lost because of huge memories, but one of the things I love about early Unix is how small everything was. Most people don't care, but if you want to go really fast, there is no replacement for small. Personally, I'm fine with some amount of "list about new systems where we can ask about history because that helps us build those new systems". Might be just me, I love systems discussions. From crossd at gmail.com Sat Feb 4 03:08:02 2023 From: crossd at gmail.com (Dan Cross) Date: Fri, 3 Feb 2023 12:08:02 -0500 Subject: [TUHS] Proper use of TUHS (was Re: Typesetter C compiler) In-Reply-To: <20230203165420.GB19745@mcvoy.com> References: <20230202190232.C79D118C073@mercury.lcs.mit.edu> <73d0b98b-ae3f-428d-1b2e-feada7fc98a1@case.edu> <20230203141540.GS30555@mcvoy.com> <20230203165420.GB19745@mcvoy.com> Message-ID: On Fri, Feb 3, 2023 at 11:54 AM Larry McVoy wrote: > Well, be careful listening to gray beards too much. Hey now, my own beard has more grey than brown at this point. > [snip] > the old rules don't apply. That's precisely why I think it's important to think about new directions in systems. But there's so much reinvention of the square wheel, it at least makes sense to be _aware_ of the history. > [snip] > Personally, I'm fine with some amount of "list about new systems where > we can ask about history because that helps us build those new systems". > Might be just me, I love systems discussions. Agreed. But TUHS is not that list, I don't think. - Dan C. From usotsuki at buric.co Sat Feb 4 03:11:42 2023 From: usotsuki at buric.co (Steve Nickolas) Date: Fri, 3 Feb 2023 12:11:42 -0500 (EST) Subject: [TUHS] Proper use of TUHS (was Re: Typesetter C compiler) In-Reply-To: <20230203165420.GB19745@mcvoy.com> References: <20230202190232.C79D118C073@mercury.lcs.mit.edu> <73d0b98b-ae3f-428d-1b2e-feada7fc98a1@case.edu> <20230203141540.GS30555@mcvoy.com> <20230203165420.GB19745@mcvoy.com> Message-ID: On Fri, 3 Feb 2023, Larry McVoy wrote: > Some things will never go away, like keep your fingers off of my L1 > cache lines. I think it's mostly lost because of huge memories, but > one of the things I love about early Unix is how small everything was. > Most people don't care, but if you want to go really fast, there is no > replacement for small. > > Personally, I'm fine with some amount of "list about new systems where > we can ask about history because that helps us build those new systems". > Might be just me, I love systems discussions. I find a lot of my own stuff is like this - kindasorta fits and kindasorta doesn't for similar reasons. (Since a lot of what I've been doing lately is creating a SysV-flavored rewrite of Unix from my own perspective as a 40-something who actually got most of my experience coding for 16-bits and MS-DOS, and speaks fluent but non-native C. I'm sure it comes out in my coding style.) -uso. From will.senn at gmail.com Sat Feb 4 03:26:40 2023 From: will.senn at gmail.com (Will Senn) Date: Fri, 3 Feb 2023 11:26:40 -0600 Subject: [TUHS] move to COFF Re: Re: Proper use of TUHS (was Re: Typesetter C compiler) In-Reply-To: References: <20230202190232.C79D118C073@mercury.lcs.mit.edu> <73d0b98b-ae3f-428d-1b2e-feada7fc98a1@case.edu> <20230203141540.GS30555@mcvoy.com> <20230203165420.GB19745@mcvoy.com> Message-ID: <057be760-5f24-6274-c4b4-97ee8c439615@gmail.com> We're in COFF territory again. I am enjoying the conversation, but let's self monitor. Perhaps, a workflow for this is that when we drift off into non-unix history discussion, we cc: COFF and tell folks to continue there? As a test I cced it on this email, don't reply all to this list. Just let's talk about it over in coff. If you aren't on coff join it. If you aren't sure or think most folks on the list want to discuss it. Post it on COFF, if you don't get any traction, reference the COFF thread and tease it in TUHS. This isn't at all a gripe - I heart all of our discussions, but I agree that it's hard to keep it history related here with no outlet for tangential discussion - so, let's put coff to good use and try it for those related, but not quite discussions. Remember, don't reply to TUHS on this email :)! - will On 2/3/23 11:11 AM, Steve Nickolas wrote: > On Fri, 3 Feb 2023, Larry McVoy wrote: > >> Some things will never go away, like keep your fingers off of my L1 >> cache lines.  I think it's mostly lost because of huge memories, but >> one of the things I love about early Unix is how small everything was. >> Most people don't care, but if you want to go really fast, there is no >> replacement for small. >> >> Personally, I'm fine with some amount of "list about new systems where >> we can ask about history because that helps us build those new systems". >> Might be just me, I love systems discussions. > > I find a lot of my own stuff is like this - kindasorta fits and > kindasorta doesn't for similar reasons. > > (Since a lot of what I've been doing lately is creating a > SysV-flavored rewrite of Unix from my own perspective as a > 40-something who actually got most of my experience coding for 16-bits > and MS-DOS, and speaks fluent but non-native C.  I'm sure it comes out > in my coding style.) > > -uso. From will.senn at gmail.com Sat Feb 4 03:31:44 2023 From: will.senn at gmail.com (Will Senn) Date: Fri, 3 Feb 2023 11:31:44 -0600 Subject: [TUHS] move to COFF Re: Re: Proper use of TUHS (was Re: Typesetter C compiler) In-Reply-To: <057be760-5f24-6274-c4b4-97ee8c439615@gmail.com> References: <20230202190232.C79D118C073@mercury.lcs.mit.edu> <73d0b98b-ae3f-428d-1b2e-feada7fc98a1@case.edu> <20230203141540.GS30555@mcvoy.com> <20230203165420.GB19745@mcvoy.com> <057be760-5f24-6274-c4b4-97ee8c439615@gmail.com> Message-ID: <5000bf66-4ae0-710f-c613-3bed61fb5f91@gmail.com> Oh, and of course I would cc the old address! Reply on the correct COFF address Sheesh. On 2/3/23 11:26 AM, Will Senn wrote: > We're in COFF territory again. I am enjoying the conversation, but > let's self monitor. Perhaps, a workflow for this is that when we drift > off into non-unix history discussion, we cc: COFF and tell folks to > continue there? As a test I cced it on this email, don't reply all to > this list. Just let's talk about it over in coff. If you aren't on > coff join it. > > If you aren't sure or think most folks on the list want to discuss it. > Post it on COFF, if you don't get any traction, reference the COFF > thread and tease it in TUHS. > > This isn't at all a gripe - I heart all of our discussions, but I > agree that it's hard to keep it history related here with no outlet > for tangential discussion - so, let's put coff to good use and try it > for those related, but not quite discussions. > > Remember, don't reply to TUHS on this email :)! > > - will > > On 2/3/23 11:11 AM, Steve Nickolas wrote: >> On Fri, 3 Feb 2023, Larry McVoy wrote: >> >>> Some things will never go away, like keep your fingers off of my L1 >>> cache lines.  I think it's mostly lost because of huge memories, but >>> one of the things I love about early Unix is how small everything was. >>> Most people don't care, but if you want to go really fast, there is no >>> replacement for small. >>> >>> Personally, I'm fine with some amount of "list about new systems where >>> we can ask about history because that helps us build those new >>> systems". >>> Might be just me, I love systems discussions. >> >> I find a lot of my own stuff is like this - kindasorta fits and >> kindasorta doesn't for similar reasons. >> >> (Since a lot of what I've been doing lately is creating a >> SysV-flavored rewrite of Unix from my own perspective as a >> 40-something who actually got most of my experience coding for >> 16-bits and MS-DOS, and speaks fluent but non-native C.  I'm sure it >> comes out in my coding style.) >> >> -uso. > From bakul at iitbombay.org Sat Feb 4 03:45:59 2023 From: bakul at iitbombay.org (Bakul Shah) Date: Fri, 3 Feb 2023 09:45:59 -0800 Subject: [TUHS] Proper use of TUHS (was Re: Typesetter C compiler) In-Reply-To: References: Message-ID: On Feb 3, 2023, at 8:41 AM, Dan Cross wrote: > > But TUHS is clearly meant to be a Unix history list, not a "list about > new systems where we can ask about history because that helps us build > those new systems". In that sense, I'm not looking for COFF or a retro > or classic computer list, either, but for something explicitly modern > yet informed by history. > > I don't believe such a thing actually exists. I’m not aware of one. May be comp.arch comes close. Any new list will have difficulty attracting the right kind of people. TUHS, COFF are rather unix oriented. If you mean *software systems*, I suspect the field is still too green to have a proper systematic analysis or established engineering principles. We still seem to be in the “Cambrian explosion” phase where every new complex system is a new species. From flexibeast at gmail.com Sat Feb 4 14:10:26 2023 From: flexibeast at gmail.com (Alexis) Date: Sat, 04 Feb 2023 15:10:26 +1100 Subject: [TUHS] Initial uses of the '-d' convention for daemons? Message-ID: <87zg9udpt2.fsf@ada> Hi all, Firstly, thanks to Warren for adding me to the list! The 6th Edition manual refers to 'cron', not 'crond' (even though cron was indeed referred to as a 'daemon'). By 4.2BSD, however, we have things like 'telnetd' and 'tftpd'. Does anyone have any pointers as to when and where the '-d' convention started to be used? Thanks in anticipation, Alexis. From jsg at jsg.id.au Sat Feb 4 15:02:16 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Sat, 4 Feb 2023 16:02:16 +1100 Subject: [TUHS] Initial uses of the '-d' convention for daemons? In-Reply-To: <87zg9udpt2.fsf@ada> References: <87zg9udpt2.fsf@ada> Message-ID: On Sat, Feb 04, 2023 at 03:10:26PM +1100, Alexis wrote: > > Hi all, > > Firstly, thanks to Warren for adding me to the list! > > The 6th Edition manual refers to 'cron', not 'crond' (even though cron was > indeed referred to as a 'daemon'). By 4.2BSD, however, we have things like > 'telnetd' and 'tftpd'. > > Does anyone have any pointers as to when and where the '-d' convention > started to be used? The 2nd edition manual has: dpd(I) spawn data-phone daemon by the 5th edition, there was also: lpd(VIII) line printer daemon The term dates back to CTSS and Multics. From flexibeast at gmail.com Sat Feb 4 15:51:17 2023 From: flexibeast at gmail.com (Alexis) Date: Sat, 04 Feb 2023 16:51:17 +1100 Subject: [TUHS] Initial uses of the '-d' convention for daemons? In-Reply-To: References: <87zg9udpt2.fsf@ada> Message-ID: <87v8kidli5.fsf@ada> Jonathan Gray writes: > The 2nd edition manual has: > dpd(I) spawn data-phone daemon > > by the 5th edition, there was also: > lpd(VIII) line printer daemon > > The term dates back to CTSS and Multics. Excellent, thank you! Alexis. From ralph at inputplus.co.uk Sat Feb 4 18:03:20 2023 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Sat, 04 Feb 2023 08:03:20 +0000 Subject: [TUHS] A List for New Systems Influenced by History. (Was: Proper use of TUHS) In-Reply-To: References: <20230202190232.C79D118C073@mercury.lcs.mit.edu> <73d0b98b-ae3f-428d-1b2e-feada7fc98a1@case.edu> <20230203141540.GS30555@mcvoy.com> Message-ID: <20230204080320.3628621C9A@orac.inputplus.co.uk> Hi Dan, > a "list about new systems where we can ask about history because that > helps us build those new systems". https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff says The Computer Old Farts Forum provides a place for people to discuss the history of computers and their future. That seems to align well to me. Yet another list seems a bad idea; the interested parties would be spread more thinly. Just as a worldwide Usenet group was weakened when anyone could start a forum on a topic and many did. -- Cheers, Ralph. From lm at mcvoy.com Sat Feb 4 23:56:03 2023 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 4 Feb 2023 05:56:03 -0800 Subject: [TUHS] A List for New Systems Influenced by History. (Was: Proper use of TUHS) In-Reply-To: <20230204080320.3628621C9A@orac.inputplus.co.uk> References: <20230202190232.C79D118C073@mercury.lcs.mit.edu> <73d0b98b-ae3f-428d-1b2e-feada7fc98a1@case.edu> <20230203141540.GS30555@mcvoy.com> <20230204080320.3628621C9A@orac.inputplus.co.uk> Message-ID: <20230204135603.GA27395@mcvoy.com> On Sat, Feb 04, 2023 at 08:03:20AM +0000, Ralph Corderoy wrote: > Hi Dan, > > > a "list about new systems where we can ask about history because that > > helps us build those new systems". > > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff says > > The Computer Old Farts Forum provides a place for people to discuss > the history of computers and their future. > > That seems to align well to me. > > Yet another list seems a bad idea; the interested parties would be > spread more thinly. Just as a worldwide Usenet group was weakened when > anyone could start a forum on a topic and many did. Seems like the rest of the world, well, the good parts, need to learn about COFF. We need as much mass as we can get from tuhs and then we advertise on stackoverflow and hacker news and ? -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From ama at ugr.es Sun Feb 5 03:31:01 2023 From: ama at ugr.es (Angel M Alganza) Date: Sat, 04 Feb 2023 18:31:01 +0100 Subject: [TUHS] A List for New Systems Influenced by History. In-Reply-To: <20230204135603.GA27395@mcvoy.com> References: <20230202190232.C79D118C073@mercury.lcs.mit.edu> <73d0b98b-ae3f-428d-1b2e-feada7fc98a1@case.edu> <20230203141540.GS30555@mcvoy.com> <20230204080320.3628621C9A@orac.inputplus.co.uk> <20230204135603.GA27395@mcvoy.com> Message-ID: On 2023-02-04 14:56, Larry McVoy wrote: > We need as much mass as we can get from tuhs and then we > advertise on stackoverflow and hacker news and ? On nostr, maybe? There are tons of technical people there celebrating how cool it's having the same feelings they had 25-30 years ago when they discovered the Internet first, when it was still full of hope of being decentralized and free. I think tuhs and, probably even more, coff might be the perfect fit for them. Cheers, Ángel From rtomek at ceti.pl Sun Feb 5 08:38:26 2023 From: rtomek at ceti.pl (Tomasz Rola) Date: Sat, 4 Feb 2023 23:38:26 +0100 Subject: [TUHS] Proper use of TUHS (was Re: Typesetter C compiler) In-Reply-To: <7wv8kj6yrx.fsf@junk.nocrew.org> References: <20230202190232.C79D118C073@mercury.lcs.mit.edu> <7wv8kj6yrx.fsf@junk.nocrew.org> Message-ID: On Fri, Feb 03, 2023 at 06:36:34AM +0000, Lars Brinkhoff wrote: > Dan Cross wrote: > > So, the question becomes: what _is_ that forum, if such a thing > > exists at all? > > Some options: > > - Cctalk email list. (cc-ed to coff, of coffse...) I use to hang out on IBM-MAIN mailing list, too. While they are, mostly, dealing with modern mainframes and current problems, they also occasionally mention old story or two. Actually, since mainframe is such a living fossil thing, the whole talk sometimes feels as if it was about something upgraded continuously from the 1960-ties. Most of it is uncomprehensible to me (never had proper mainframe training, or unproper one, and they deal with stuff in unique way, have their own acronyms for things, there are some intro books but there is not enough time*energy), but also a bit educating - a bit today, a bit next week etc. > - ClassicCMP Discord. > - Retrocomputingforum.com. > - Various Facebook groups. Web stuff, requiring Javascript to work, ugh, ugh-oh. Mostly, it boils down to the fact that one cannot easily curl the text from those other places (AFAICT). So it is hard to awk this text into mbox format and read it comfortably. -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola at bigfoot.com ** From sjenkin at canb.auug.org.au Sun Feb 5 20:42:31 2023 From: sjenkin at canb.auug.org.au (steve jenkin) Date: Sun, 5 Feb 2023 21:42:31 +1100 Subject: [TUHS] Proper use of TUHS (was Re: Typesetter C compiler) In-Reply-To: References: Message-ID: > On 4 Feb 2023, at 04:45, Bakul Shah wrote: > > We still seem to be in the “Cambrian explosion” phase > where every new complex system is a new species. You just perfectly described the computing world before 1965 & IBM’s 360. A range with 10x - 20x (? recall failure) of compatible models. This was repeated with microprocessors - at each ‘process step’, one clock frequency option for many years. Can’t recall who invented the range of CPU options we now have: server, desktop, laptop, tablet and ‘embedded’ Might’ve been two variants of 486, can’t recall. There was a tower of babel with Networking for decades, first the physical layer, then the packet layer, then network / protocol layer. We ended up with cat-5/6 twisted pair as the most common physical layer (with RJ-45’), async packets framed with Ethernet, running IP protocols over the network layer. “Internetwork” is a give away in the name “I.P.”. This, despite IBM & Microsoft’s (& others) considerable efforts otherwise. Mature markets require “Standard” parts / services, so consumers can mix-n-match as they wish. Standards facilitate “substitutes” & competition necessary to generate low-margin, high-volume commodity markets. By definition, commodity markets trade “fungible goods” destined for consumers. So many of these, hard to list. Standards - where manufacturers agree on common designs - only appear when manufacturers agree they’ve a common interest in building “volume”, not locking customers in. This happened very early with bipolar TTL logic. Smart phones are mostly Linux / Android, with Apple still able to sell non-commodity designs at premium prices. Remember Microsoft’s foray, via Nokia, into Mobiles? “Pocket PC” and “Windows Mobile” / Windows Phone: Crashed and burned. Even Nokia, then largest phone seller, with the proven Symbian O/S, failed against Android. -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin From jsg at jsg.id.au Mon Feb 6 17:01:49 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Mon, 6 Feb 2023 18:01:49 +1100 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: References: Message-ID: On Mon, Jan 30, 2023 at 12:20:52AM +0100, Paul Ruizendaal via TUHS wrote: > > Herewith some interesting (somewhat) contemporary papers on early windowing systems: > > 1. There was a conference in the UK early in 1985 discussing the state of window systems on Unix. Much interesting discussion and two talks by James Gosling, one about NeWS (then still called SunDew), and one about what seems to be SunWindows. It would seem then that these were developed almost in parallel. > > http://www.chilton-computing.org.uk/inf/literature/books/wm/contents.htm Another window system was Whitechapel Computer Works' Oriel. "During 1985 major developments took place, mainly on the software front. A factor of 6 improvement in graphics performance was obtained, and the Oriel state-of-the-art window manager developed. The Newcastle Connection and SUN's NFS have also been announced as products, available on 42NIX, the Whitechapel release of Berkeley BSD 4.2." http://www.chilton-computing.org.uk/acd/sus/perq_papers/perq_external/p003.htm http://www.cpu-ns32k.net/Whitechapel.html has a photo of the GUI running on a MG-1 with NS32016. https://www.youtube.com/watch?v=JMQ9EvZLSos "Booting 42nix 2.5 on a Whitechapel Computer Works MG-1" from Tom Stepleton who also maintained https://web.archive.org/web/20210625124716/http://mg-1.uk/ https://archive.org/details/byte-magazine-1985-02/1985_02_BYTE_10-02_Computing_and_the_Sciences/page/n378/mode/1up has an article on Whitechapel Computer Works and the MG-1, before they changed from Genix to 42nix "The operating system is Genix, a Berkeley 4.1 UNIX customized by WCW to support the MG-1's graphics abilities" http://web.archive.org/web/20030205212745/http://www.galactic.co.uk/iainf/mg1.html "The WCW MG-1 was launched in September 1984 .. The monitor was a large (17 inch) 1024x800 bit-mapped monochrome screen, and there was hardware support for up to 16 mask-shift raster operations at once, modelled after the 3RCC/ICL PERQ raster-ops. ... It ran a kernel based window system called ORIEL (and a SunTools like graphics library called ANGEL), which took full advantage of the raster-op hardware." From jsg at jsg.id.au Mon Feb 6 18:39:42 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Mon, 6 Feb 2023 19:39:42 +1100 Subject: [TUHS] Earliest UNIX Workstations? In-Reply-To: References: Message-ID: On Mon, Feb 06, 2023 at 06:01:49PM +1100, Jonathan Gray wrote: > On Mon, Jan 30, 2023 at 12:20:52AM +0100, Paul Ruizendaal via TUHS wrote: > > > > Herewith some interesting (somewhat) contemporary papers on early windowing systems: > > > > 1. There was a conference in the UK early in 1985 discussing the state of window systems on Unix. Much interesting discussion and two talks by James Gosling, one about NeWS (then still called SunDew), and one about what seems to be SunWindows. It would seem then that these were developed almost in parallel. > > > > http://www.chilton-computing.org.uk/inf/literature/books/wm/contents.htm > > Another window system was Whitechapel Computer Works' Oriel. further described in: Dominic Sweetman - A Modular Window System for Unix http://www.chilton-computing.org.uk/inf/literature/books/wm/p007.htm Later there were MIPS machines, such as the R2000 based Hitech 10 which ran UMIPS (4.3BSD) with a choice of X11 and NeWS. http://web.archive.org/web/20030205212745/http://www.galactic.co.uk/iainf/mg1.html http://www.umips.net/riscos/index.html Dominic Sweetman and Nigel Stephens of Whitechapel would later go on to be involved in Algorithmics, which was acquired by MIPS Technologies in 2002 and became MIPS UK. https://cgi.cse.unsw.edu.au/~cs3231/doc/R3000.pdf https://www.linux-mips.org/wiki/Algorithmics From jsg at jsg.id.au Mon Feb 6 20:03:54 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Mon, 6 Feb 2023 21:03:54 +1100 Subject: [TUHS] window systems (was Re: Earliest UNIX Workstations?) In-Reply-To: References: Message-ID: On Mon, Feb 06, 2023 at 07:39:42PM +1100, Jonathan Gray wrote: > On Mon, Feb 06, 2023 at 06:01:49PM +1100, Jonathan Gray wrote: > > On Mon, Jan 30, 2023 at 12:20:52AM +0100, Paul Ruizendaal via TUHS wrote: > > > > > > Herewith some interesting (somewhat) contemporary papers on early windowing systems: > > > > > > 1. There was a conference in the UK early in 1985 discussing the state of window systems on Unix. Much interesting discussion and two talks by James Gosling, one about NeWS (then still called SunDew), and one about what seems to be SunWindows. It would seem then that these were developed almost in parallel. > > > > > > http://www.chilton-computing.org.uk/inf/literature/books/wm/contents.htm > > > > Another window system was Whitechapel Computer Works' Oriel. > > further described in: > Dominic Sweetman - A Modular Window System for Unix > http://www.chilton-computing.org.uk/inf/literature/books/wm/p007.htm there is a survey of various window systems SunWindows, Oriel, Andrew, X, in: http://reports-archive.adm.cs.cmu.edu/anon/itc/CMU-ITC-045.pdf Tutorial Materials Usenix Technical Conference Denver, Colorado January 15-17, 1986 #7 Windowing Systems Implementations David S. H. Rosenthal also mentions "Other Kernel-Based Systems The window system developed at LucasFilm by Sam Leffler and Mike Hawley, and described at the Portland Usenix, is another example of a kernel-based system. It supports an impressive user interface toolkit, similar to that on the Blit." Michael J. Hawley, Samuel J. Leffler - Windows for UNIX at Lucasfilm https://archive.org/details/1985-proceedings-summer-portland/page/392/mode/2up paper has some pictures of it From cmhanson at eschatologist.net Tue Feb 7 06:02:05 2023 From: cmhanson at eschatologist.net (Chris Hanson) Date: Mon, 6 Feb 2023 12:02:05 -0800 Subject: [TUHS] Proper use of TUHS (was Re: Typesetter C compiler) In-Reply-To: <20230203135541.GR30555@mcvoy.com> References: <20230202190232.C79D118C073@mercury.lcs.mit.edu> <2c576b87-05fc-4ba2-8854-bc7b90809303@app.fastmail.com> <20230203135541.GR30555@mcvoy.com> Message-ID: <55840C1E-FA74-4D98-B040-3B467139B579@eschatologist.net> On Feb 3, 2023, at 5:55 AM, Larry McVoy wrote: > > I do miss comp.* - that was pleasant, a bunch of technical places divided > by topic. I had many a fine discussion in comp.arch. I still skim Usenet a few times a month, via eternal-september.org . There are still people posting to comp.* and related alt.* groups though not nearly as many as there once were. -- Chris From will.senn at gmail.com Thu Feb 9 04:58:35 2023 From: will.senn at gmail.com (Will Senn) Date: Wed, 8 Feb 2023 12:58:35 -0600 Subject: [TUHS] history of community help for unix users everywhere Message-ID: Hi all, Today, as I was tooling around on stack overflow, I decided to ask a question on meta. For those of you who don't know, stack overflow is supposedly a q&a site. There are zillions of answers to quite a few "how to do i do x" style questions. Folks upvote and downvote the answers and the site is a goto for a lot of developers. I've used it  since it came online - back in the late 2000's. I have a love hate relationship with the site. When there's a good answer to a question that I have, I love it. When they downvote fringe cases that I care about to the point where they effectively become gray literature that is near on impossible to locate - I hate it. Meta is supposedly where you go to ask questions about the stack. Yesterday, I asked this question: Do you know of any studies that have been done around downvoted content, specifically on stack overflow or stack exchange? By way of background - I find any questions or answers that are on the border (+1, 0, -1) as dubiously helpful, but when the downvotes pile up, much like upvotes, the answers become interesting to me again as they give me insights I might miss otherwise. After a slew of why would you think that was interesting, there's no value with upvotes and downvotes, and your question is unclear responses along with, as of now, 31 downvotes net, the question was closed for lack of clarity. My answer, which was informed by some of the comments was: There don't appear to be any papers on downvoting specific to Stack Overflow. You can find a good list of known academic papers using Stack Exchange data in the list hosted on Stack Exchange Meta (link). It is an attempt to keep a current list of works up to date. The Stack Exchange Data Explorer (link) is an open API for doing data research, if you want to dig into the data yourself. Which was quickly downvoted 9 times net. To see the entire debacle: https://meta.stackoverflow.com/questions/423080/are-there-any-serious-studies-on-the-value-of-downvoting Anyhow, other than what I perceive to be a decidely hostile environment for asking questions, it is still actually a useful resource. Wow, have times changed though on the hostility front. So, it got me thinking... What was it like in the very beginning of  things (well, ok, maybe not the very beginning, but around and after the advent of v6 and when it was at or around 50 sites) for folks needing answers to questions related to unix? The questions... and for the love of Pete, don't downvote me anymore today, I'm a fragile snowflake, and I might just cry... What was the mechanism - phone, email, dropbox of questions, snail mail, saint bernardnet, what? What was the mood - did folks quickly tire of answering questions and get snippy, or was it all roses? When did those individual inquiries get too much and what change was made to aggregate things? I'm thinking there may have been overlap between unix users and usenet... Also, I remember using fidonet for some of my early question about linux, but that was 1991, many years after the rise of unix. Thanks, Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Thu Feb 9 05:39:05 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 08 Feb 2023 19:39:05 +0000 Subject: [TUHS] history of community help for unix users everywhere In-Reply-To: References: Message-ID: <1MaFvhLAILpLyAwHtHDIbStw0NbhQMzAT5VPAEEK0OO8DorBQinSCTKb9Efh4RHxt69dgbyl8l7xgvwlVguSGG34F-AvUIq3HaJ3jH187gg=@protonmail.com> At least as far as I can glean from manuals, there is the "trouble" command circa UNIX/TS 4.0 which was "a front end for the Piscataway Change Management Tracking System (CMTS)". This was used to report issues over uucp to Piscataway where they would then be transformed into Modification Requests, examples of which in the form of the request form *and* a list of 1980-1983 changes are in Sys V literature I've scanned. The utility would request: - The user name - Their location - Phone number - Type of request: Hardware, software, documentation, enhancement, and unknown - System: Product in need of support (usually unix) - Release (can be N/A) - Severity: 1 - highest 4 - lowest - Date - Abstract/Summary - Detailed Description There is a note here too that unless stated otherwise, reports may be selected for publication in the "Mini-System Newsletter". I've never heard of this Mini-System Newsletter. It sounds like among other things it had a digest of significant trouble reports to notify the network of known issues. The UNIX System Error Message Manual refers to two "Support Organizations" in the Bell system: - Field service representatives that support the hardware - Local software support and "UNIX System Customer Service" The manual goes on to mention the preferred group for many of the errors encounterable I suppose this means there was usually a local guru pertinent to the type of machinery (PDP, VAX, 3B-20) and then maybe some local software folks and then the man support group. Looks like for BTL-specific extensions, Division 452 was point of contact on that one. In the notes for the Release 5.0 manuals (troff comments) Lab The System V modification request form lists "UNIX System Support Center" in Lisle, Illinois as the point of contact for these forms. The 4.0 documentation roadmap mentions getting documentation resources from the Computer Information Service Library. The 5.0 BTL-specific manual has a second trouble page listing "UNIX Computer Center Support" instead of Piscataway as the recipient of trouble reports. In the same manual is also "wwbmail", an application that would send help requests directly to the "Writers Workbench" group. I haven't checked this manual exhaustively yet so there could be other nuggets in there. Of course, going back in the history of UNIX, in the early days, man pages listed the application author/maintainer with the implication they should be directly contacted with questions. This changed in V3 I think, which is around the time SCCS would've been playing around with what would become CB-UNIX. I dunno when USG and the PWB groups first formally start to tinker on things, but I recall reading around 1973 being a likely backstop. I assume USG handled a lot of this traffic until the 80s and the formalization of a bunch of these other groups. So all in all from various manuals, this is the picture I can glean from early 80s: Support Groups: - USG Proper - UNIX System Customer Service - UNIX System Support Center - UNIX Computer Center Support - Piscataway (USG? PWB?) - WWB Direct Mailing List Documentation: - Computer Information Service Library - Might be the same group but there is a trifold (I can't find right now) that lists the User's Manual along with the two falling blocks guides circa UNIX/TS 4.0 that could be requested from some doc group - Various labs and divisions that maintained their own manual versions - Mini-System Newsletter Granted, this is all based on manuals, doesn't consider any activities of USENIX or what BSD folks were doing for their help and support. Hopefully I haven't misrepresented anything, happy to illuminate any references that may be dubious. - Matt G. ------- Original Message ------- On Wednesday, February 8th, 2023 at 10:58 AM, Will Senn wrote: > Hi all, > > Today, as I was tooling around on stack overflow, I decided to ask a question on meta. For those of you who don't know, stack overflow is supposedly a q&a site. There are zillions of answers to quite a few "how to do i do x" style questions. Folks upvote and downvote the answers and the site is a goto for a lot of developers. I've used it since it came online - back in the late 2000's. I have a love hate relationship with the site. When there's a good answer to a question that I have, I love it. When they downvote fringe cases that I care about to the point where they effectively become gray literature that is near on impossible to locate - I hate it. Meta is supposedly where you go to ask questions about the stack. > > Yesterday, I asked this question: > >> Do you know of any studies that have been done around downvoted content, specifically on stack overflow or stack exchange? >> >> By way of background - I find any questions or answers that are on the border (+1, 0, -1) as dubiously helpful, but when the downvotes pile up, much like upvotes, the answers become interesting to me again as they give me insights I might miss otherwise. > > After a slew of why would you think that was interesting, there's no value with upvotes and downvotes, and your question is unclear responses along with, as of now, 31 downvotes net, the question was closed for lack of clarity. My answer, which was informed by some of the comments was: > >> There don't appear to be any papers on downvoting specific to Stack Overflow. You can find a good list of known academic papers using Stack Exchange data in the list hosted on Stack Exchange Meta (link). It is an attempt to keep a current list of works up to date. >> >> The Stack Exchange Data Explorer (link) is an open API for doing data research, if you want to dig into the data yourself. > > Which was quickly downvoted 9 times net. > > To see the entire debacle: > > https://meta.stackoverflow.com/questions/423080/are-there-any-serious-studies-on-the-value-of-downvoting > > Anyhow, other than what I perceive to be a decidely hostile environment for asking questions, it is still actually a useful resource. > > Wow, have times changed though on the hostility front. > > So, it got me thinking... > > What was it like in the very beginning of things (well, ok, maybe not the very beginning, but around and after the advent of v6 and when it was at or around 50 sites) for folks needing answers to questions related to unix? > > The questions... and for the love of Pete, don't downvote me anymore today, I'm a fragile snowflake, and I might just cry... > > What was the mechanism - phone, email, dropbox of questions, snail mail, saint bernardnet, what? > What was the mood - did folks quickly tire of answering questions and get snippy, or was it all roses? > When did those individual inquiries get too much and what change was made to aggregate things? > > I'm thinking there may have been overlap between unix users and usenet... Also, I remember using fidonet for some of my early question about linux, but that was 1991, many years after the rise of unix. > > Thanks, > > Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Thu Feb 9 05:56:17 2023 From: will.senn at gmail.com (Will Senn) Date: Wed, 8 Feb 2023 13:56:17 -0600 Subject: [TUHS] history of community help for unix users everywhere In-Reply-To: <1MaFvhLAILpLyAwHtHDIbStw0NbhQMzAT5VPAEEK0OO8DorBQinSCTKb9Efh4RHxt69dgbyl8l7xgvwlVguSGG34F-AvUIq3HaJ3jH187gg=@protonmail.com> References: <1MaFvhLAILpLyAwHtHDIbStw0NbhQMzAT5VPAEEK0OO8DorBQinSCTKb9Efh4RHxt69dgbyl8l7xgvwlVguSGG34F-AvUIq3HaJ3jH187gg=@protonmail.com> Message-ID: <2d89bce4-4ac2-df63-ab79-4558899a825e@gmail.com> On 2/8/23 1:39 PM, segaloco wrote: > At least as far as I can glean from manuals, there is the "trouble" > command circa UNIX/TS 4.0 which was "a front end for the Piscataway > Change Management Tracking System (CMTS)". > > This was used to report issues over uucp to Piscataway where they > would then be transformed into Modification Requests, examples of > which in the form of the request form *and* a list of 1980-1983 > changes are in Sys V literature I've scanned. > > The utility would request: > - The user name > - Their location > - Phone number > - Type of request: Hardware, software, documentation, enhancement, and > unknown > - System: Product in need of support (usually unix) > - Release (can be N/A) > - Severity: 1 - highest 4 - lowest > - Date > - Abstract/Summary > - Detailed Description > > There is a note here too that unless stated otherwise, reports may be > selected for publication in the "Mini-System Newsletter". Fascinating. Thanks for the details. I did a quick search in the source archive and all I could find were these: NetBSD-5.0.2/external/bsd/openldap/dist/doc/guide/admin/troubleshooting.sdf OpenBSD-4.6/gnu/usr.bin/gcc/gcc/doc/trouble.texi OpenBSD-4.6/usr.bin/sudo/TROUBLESHOOTING V10/cmd/icon/docs/trouble.roff pdp11v/usr/man/a_man/man8/trouble.8 pdp11v/usr/man/u_man/man1/trouble.1 Anybody know what pdp11v is? or where the source code for the utility is? Did it send email, or what? Thanks, Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Feb 9 05:57:29 2023 From: clemc at ccc.com (Clem Cole) Date: Wed, 8 Feb 2023 14:57:29 -0500 Subject: [TUHS] history of community help for unix users everywhere In-Reply-To: References: Message-ID: Will, For those of us outside of BTL, i.e. the Academic users, "Unix News" was created - which became ';login" - We started to meet informally at a few universities and talk to each other. Those of us on the ArpaNet that email/FTP and the like, started to share patches - but mostly things were shared when we got together via magtape. When they were held in NYC, we might be lucky and someone from Research might come (and even accidentally spill a few bits on the floor that mix fix something). Eventually, USENIX was formed, and we met twice a year formally. That was so popular, USENIX started having specialty conferences such as the one for C and C++, LISA, Networking, Linux and Free Software, etc. Similarly, with V7, UUCP was given to use a USENET was started by Tom Truscott and his famous "auto-dialler" that he hacked with a 12v relay, a DR-11C and described at the Bolder USENIX conference. Netnews was not far behind - which sadly became net.noise when the signal-to-noise ratio disappeared. Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Feb 9 06:00:06 2023 From: clemc at ccc.com (Clem Cole) Date: Wed, 8 Feb 2023 15:00:06 -0500 Subject: [TUHS] history of community help for unix users everywhere In-Reply-To: References: Message-ID: BTW: dates for this is starting in the early-mid 1970s for ArpaNet/UNIX News/USENIX, V7 arrives 79, and Truscott does his talk I believe winter 1980. ᐧ On Wed, Feb 8, 2023 at 2:57 PM Clem Cole wrote: > Will, > > For those of us outside of BTL, i.e. the Academic users, "Unix News" was > created - which became ';login" - We started to meet informally at a few > universities and talk to each other. Those of us on the ArpaNet that > email/FTP and the like, started to share patches - but mostly things were > shared when we got together via magtape. When they were held in NYC, we > might be lucky and someone from Research might come (and even accidentally > spill a few bits on the floor that mix fix something). Eventually, USENIX > was formed, and we met twice a year formally. That was so popular, USENIX > started having specialty conferences such as the one for C and C++, LISA, > Networking, Linux and Free Software, etc. Similarly, with V7, UUCP was > given to use a USENET was started by Tom Truscott and his famous > "auto-dialler" that he hacked with a 12v relay, a DR-11C and described at > the Bolder USENIX conference. Netnews was not far behind - which sadly > became net.noise when the signal-to-noise ratio disappeared. > > Clem > ᐧ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Thu Feb 9 06:01:48 2023 From: henry.r.bent at gmail.com (Henry Bent) Date: Wed, 8 Feb 2023 15:01:48 -0500 Subject: [TUHS] history of community help for unix users everywhere In-Reply-To: <2d89bce4-4ac2-df63-ab79-4558899a825e@gmail.com> References: <1MaFvhLAILpLyAwHtHDIbStw0NbhQMzAT5VPAEEK0OO8DorBQinSCTKb9Efh4RHxt69dgbyl8l7xgvwlVguSGG34F-AvUIq3HaJ3jH187gg=@protonmail.com> <2d89bce4-4ac2-df63-ab79-4558899a825e@gmail.com> Message-ID: On Wed, 8 Feb 2023 at 14:57, Will Senn wrote: > ... > > pdp11v/usr/man/a_man/man8/trouble.8 > pdp11v/usr/man/u_man/man1/trouble.1 > > Anybody know what pdp11v is? or where the source code for the utility is? > Did it send email, or what? > > I believe it is SVR1, which targeted the PDP-11. No idea where the source is, though note that the man page says that trouble is a frontend to what appears to be an internal Bell Labs logging system. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Feb 9 06:02:27 2023 From: clemc at ccc.com (Clem Cole) Date: Wed, 8 Feb 2023 15:02:27 -0500 Subject: [TUHS] history of community help for unix users everywhere In-Reply-To: <1MaFvhLAILpLyAwHtHDIbStw0NbhQMzAT5VPAEEK0OO8DorBQinSCTKb9Efh4RHxt69dgbyl8l7xgvwlVguSGG34F-AvUIq3HaJ3jH187gg=@protonmail.com> References: <1MaFvhLAILpLyAwHtHDIbStw0NbhQMzAT5VPAEEK0OO8DorBQinSCTKb9Efh4RHxt69dgbyl8l7xgvwlVguSGG34F-AvUIq3HaJ3jH187gg=@protonmail.com> Message-ID: FYI - UNIX is about 10-12 years old by the time Matt is describing - there are thousands of sites by then. I was describing what it was like when it 30-50 sites. Clem ᐧ On Wed, Feb 8, 2023 at 2:39 PM segaloco via TUHS wrote: > At least as far as I can glean from manuals, there is the "trouble" > command circa UNIX/TS 4.0 which was "a front end for the Piscataway Change > Management Tracking System (CMTS)". > > This was used to report issues over uucp to Piscataway where they would > then be transformed into Modification Requests, examples of which in the > form of the request form *and* a list of 1980-1983 changes are in Sys V > literature I've scanned. > > The utility would request: > - The user name > - Their location > - Phone number > - Type of request: Hardware, software, documentation, enhancement, and > unknown > - System: Product in need of support (usually unix) > - Release (can be N/A) > - Severity: 1 - highest 4 - lowest > - Date > - Abstract/Summary > - Detailed Description > > There is a note here too that unless stated otherwise, reports may be > selected for publication in the "Mini-System Newsletter". > > I've never heard of this Mini-System Newsletter. It sounds like among > other things it had a digest of significant trouble reports to notify the > network of known issues. > > The UNIX System Error Message Manual refers to two "Support Organizations" > in the Bell system: > > - Field service representatives that support the hardware > - Local software support and "UNIX System Customer Service" > > The manual goes on to mention the preferred group for many of the errors > encounterable > > I suppose this means there was usually a local guru pertinent to the type > of machinery (PDP, VAX, 3B-20) and then maybe some local software folks and > then the man support group. > > Looks like for BTL-specific extensions, Division 452 was point of contact > on that one. In the notes for the Release 5.0 manuals (troff comments) Lab > > The System V modification request form lists "UNIX System Support Center" > in Lisle, Illinois as the point of contact for these forms. > > The 4.0 documentation roadmap mentions getting documentation resources > from the Computer Information Service Library. > > The 5.0 BTL-specific manual has a second trouble page listing "UNIX > Computer Center Support" instead of Piscataway as the recipient of trouble > reports. > > In the same manual is also "wwbmail", an application that would send help > requests directly to the "Writers Workbench" group. I haven't checked this > manual exhaustively yet so there could be other nuggets in there. > > Of course, going back in the history of UNIX, in the early days, man pages > listed the application author/maintainer with the implication they should > be directly contacted with questions. This changed in V3 I think, which is > around the time SCCS would've been playing around with what would become > CB-UNIX. I dunno when USG and the PWB groups first formally start to tinker > on things, but I recall reading around 1973 being a likely backstop. I > assume USG handled a lot of this traffic until the 80s and the > formalization of a bunch of these other groups. > > So all in all from various manuals, this is the picture I can glean from > early 80s: > > Support Groups: > > - USG Proper > - UNIX System Customer Service > - UNIX System Support Center > - UNIX Computer Center Support > - Piscataway (USG? PWB?) > - WWB Direct Mailing List > > > Documentation: > > - Computer Information Service Library > > > - Might be the same group but there is a trifold (I can't find right > now) that lists the User's Manual along with the two falling blocks guides > circa UNIX/TS 4.0 that could be requested from some doc group > - Various labs and divisions that maintained their own manual versions > > > - Mini-System Newsletter > > > Granted, this is all based on manuals, doesn't consider any activities of > USENIX or what BSD folks were doing for their help and support. Hopefully I > haven't misrepresented anything, happy to illuminate any references that > may be dubious. > > - Matt G. > ------- Original Message ------- > On Wednesday, February 8th, 2023 at 10:58 AM, Will Senn < > will.senn at gmail.com> wrote: > > Hi all, > > Today, as I was tooling around on stack overflow, I decided to ask a > question on meta. For those of you who don't know, stack overflow is > supposedly a q&a site. There are zillions of answers to quite a few "how to > do i do x" style questions. Folks upvote and downvote the answers and the > site is a goto for a lot of developers. I've used it since it came online - > back in the late 2000's. I have a love hate relationship with the site. > When there's a good answer to a question that I have, I love it. When they > downvote fringe cases that I care about to the point where they effectively > become gray literature that is near on impossible to locate - I hate it. > Meta is supposedly where you go to ask questions about the stack. > > Yesterday, I asked this question: > > Do you know of any studies that have been done around downvoted content, > specifically on stack overflow or stack exchange? > > By way of background - I find any questions or answers that are on the > border (+1, 0, -1) as dubiously helpful, but when the downvotes pile up, > much like upvotes, the answers become interesting to me again as they give > me insights I might miss otherwise. > > > After a slew of why would you think that was interesting, there's no value > with upvotes and downvotes, and your question is unclear responses along > with, as of now, 31 downvotes net, the question was closed for lack of > clarity. My answer, which was informed by some of the comments was: > > There don't appear to be any papers on downvoting specific to Stack > Overflow. You can find a good list of known academic papers using Stack > Exchange data in the list hosted on Stack Exchange Meta (link). It is an > attempt to keep a current list of works up to date. > > The Stack Exchange Data Explorer (link) is an open API for doing data > research, if you want to dig into the data yourself. > > > Which was quickly downvoted 9 times net. > > To see the entire debacle: > > > https://meta.stackoverflow.com/questions/423080/are-there-any-serious-studies-on-the-value-of-downvoting > > Anyhow, other than what I perceive to be a decidely hostile environment > for asking questions, it is still actually a useful resource. > > Wow, have times changed though on the hostility front. > > So, it got me thinking... > > What was it like in the very beginning of things (well, ok, maybe not the > very beginning, but around and after the advent of v6 and when it was at or > around 50 sites) for folks needing answers to questions related to unix? > > The questions... and for the love of Pete, don't downvote me anymore > today, I'm a fragile snowflake, and I might just cry... > > What was the mechanism - phone, email, dropbox of questions, snail mail, > saint bernardnet, what? > What was the mood - did folks quickly tire of answering questions and get > snippy, or was it all roses? > When did those individual inquiries get too much and what change was made > to aggregate things? > > I'm thinking there may have been overlap between unix users and usenet... > Also, I remember using fidonet for some of my early question about linux, > but that was 1991, many years after the rise of unix. > > Thanks, > > Will > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Thu Feb 9 06:17:55 2023 From: henry.r.bent at gmail.com (Henry Bent) Date: Wed, 8 Feb 2023 15:17:55 -0500 Subject: [TUHS] history of community help for unix users everywhere In-Reply-To: References: Message-ID: On Wed, 8 Feb 2023 at 14:59, Clem Cole wrote: > > Netnews was not far behind - which sadly became net.noise when the > signal-to-noise ratio disappeared. > > What timeframe do you consider that as having happened in? Post-renaming, I assume? -Henry > ᐧ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Thu Feb 9 06:48:26 2023 From: imp at bsdimp.com (Warner Losh) Date: Wed, 8 Feb 2023 13:48:26 -0700 Subject: [TUHS] history of community help for unix users everywhere In-Reply-To: References: Message-ID: On Wed, Feb 8, 2023 at 12:59 PM Clem Cole wrote: > For those of us outside of BTL, i.e. the Academic users, "Unix News" was > created - which became ';login" - We started to meet informally at a few > universities and talk to each other. Those of us on the ArpaNet that > email/FTP and the like, started to share patches - but mostly things were > shared when we got together via magtape. When they were held in NYC, we > might be lucky and someone from Research might come (and even accidentally > spill a few bits on the floor that mix fix something). Eventually, USENIX > was formed, and we met twice a year formally. That was so popular, USENIX > started having specialty conferences such as the one for C and C++, LISA, > Networking, Linux and Free Software, etc. Similarly, with V7, UUCP was > given to use a USENET was started by Tom Truscott and his famous > "auto-dialler" that he hacked with a 12v relay, a DR-11C and described at > the Bolder USENIX conference. Netnews was not far behind - which sadly > became net.noise when the signal-to-noise ratio disappeared. > Yea, reading both the early usenix news letters and the early AUUG newsletters carefully shows more community action as well. I'm not sure what netnews was like in the 74-79 time frame before UUCP was wisely available, so I can't comment on that, but there's reports from names you'd recognize, and reports about USENIX conferences, reports about local gatherings... and then all kinds of crazy stuff: letters on university letter head that had bug fixes in it for this or that problem... Addresses where you write and send photocopies of AT&T and DEC licenses and get FORTRAN or MARCO-11 or other such things where people had used their DEC source license to hack in unix I/O routines into the FORTRAN compiler. And there were all kinds of 'user shared' programs that ranged from 'trivial problem, poorly executed' to 'really cool DEC OS emulators' depending on the era.. The bas.s that is in V6 and V7 (V5 too?) is an early version fo DEC's BASIC that was hacked for unix and some I/O devices that were specific to the labs... there were also advice for what versions of unix to use, and what versions were available to license. References to things that you can't google for anymore (or if you do all you find is the google index of the login issues / auus issues). There's also a number of country SIGs under DECUS that were for unix in the 77 or so time frame that might be good to search newsletters for... bitsavers has a bunch, but not sure they are early enough (I didn't come across the references to them until long after I looked at what bitsavers had). The community aspect of open source was there in spades as well, with people helping other people and sharing fixes. But it was complicated by restrictive license agreements and somewhat (imho) overzealous protection of 'rights' at times that hampered things and would have echos in later open source licenses and attitudes that would develop in response. Even though the term 'open source' wasn't coined until 1998, the open source ethos were present in many of the early computer users groups, not least the unix ones. USENET amplified it, plus let in the unwashed masses who also had useful contributions (in addition to a lot of noise)... then things got really crowded with noise when AOL went live... And I'm sure there's a number of other BBS and/or compuserve communities I'm giving short-shrift here because I wasn't part of them in real time. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Thu Feb 9 07:28:41 2023 From: crossd at gmail.com (Dan Cross) Date: Wed, 8 Feb 2023 16:28:41 -0500 Subject: [TUHS] history of community help for unix users everywhere In-Reply-To: References: Message-ID: [TUHS to Bcc: and +COFF] On Wed, Feb 8, 2023 at 3:50 PM Warner Losh wrote: > [snip] > The community aspect of open source was there in spades as well, with people helping other people and sharing fixes. But it was complicated by restrictive license agreements and somewhat (imho) overzealous protection of 'rights' at times that hampered things and would have echos in later open source licenses and attitudes that would develop in response. Even though the term 'open source' wasn't coined until 1998, the open source ethos were present in many of the early computer users groups, not least the unix ones. Don't forget SHARE! Honestly, I think the IBM mainframe community doesn't get its due. There was actually a lot of good stuff there. > USENET amplified it, plus let in the unwashed masses who also had useful contributions (in addition to a lot of noise)... then things got really crowded with noise when AOL went live... And I'm sure there's a number of other BBS and/or compuserve communities I'm giving short-shrift here because I wasn't part of them in real time. The phenomenon of "September" being the time when all the new undergrads got their accounts and discovered USENET and the shenanigans that ensued was well-known. Eternal September when AOL got connected was a serious body blow. As for BBSes...I'd go so far as to say that the BBS people were the AOL people before the AOL people were the AOL people. A takeaway from both was that communities with established norms but no way beside social pressure to enforce them have a hard time scaling. USENET worked when the user population was small and mostly amenable to a set of shared goals centered around information exchange (nevermind the Jim Flemings and other well-known cranks of the world). But integrating someone into the fold took effort both on the community's part as well as the user; when it wasn't obvious that intrinsic motivation was required, or hordes of users just weren't interested, it didn't work very well. I think this is something we see over and over again with social networks. - Dan C. From heinz at osta.com Thu Feb 9 07:34:36 2023 From: heinz at osta.com (Heinz Lycklama) Date: Wed, 8 Feb 2023 13:34:36 -0800 Subject: [TUHS] history of community help for unix users everywhere In-Reply-To: References: Message-ID: <1522ddce-f2cc-7639-a17c-d0f9b87ef395@osta.com> The "open source" term may have been coined in 1998, but the term "open systems" was in use well before in the mid to late 1980's when we started the /usr/group and POSIX standards efforts. That was one of the reasons why I named my high tech consultancy service with the name "Open Systems Technology Associates" (OSTA) in 1992. Heinz On 2/8/2023 12:48 PM, Warner Losh wrote: > > > On Wed, Feb 8, 2023 at 12:59 PM Clem Cole wrote: > > For those of us outside of BTL, i.e. the Academic users, "Unix > News" was created - which became ';login" - We started to meet > informally at a few universities and talk to each other.   Those > of us on the ArpaNet that email/FTP and the like, started to share > patches - but mostly things were shared when we got together via > magtape. When they were held in NYC, we might be lucky and someone > from Research might come (and even accidentally spill a few bits > on the floor that mix fix something).  Eventually, USENIX was > formed, and we met twice a year formally. That was so popular, > USENIX started having specialty conferences such as the one for C > and C++, LISA, Networking, Linux and Free Software, etc. > Similarly, with V7, UUCP was given to use a USENET was started by > Tom Truscott and his famous "auto-dialler" that he hacked with a > 12v relay, a DR-11C and described at the Bolder USENIX > conference.   Netnews was not far behind - which sadly became > net.noise when the signal-to-noise ratio disappeared. > > >  Yea, reading both the early usenix news letters and the early AUUG > newsletters carefully shows more community action as well. I'm not > sure what netnews was like in the 74-79 time frame before UUCP was > wisely available, so I can't comment on that, but there's reports from > names you'd recognize, and reports about USENIX conferences, reports > about local gatherings... and then all kinds of crazy stuff: letters > on university letter head that had bug fixes in it for this or that > problem... Addresses where you write and send photocopies of AT&T and > DEC licenses and get FORTRAN or MARCO-11 or other such things where > people had used their DEC source license to hack in unix I/O routines > into the FORTRAN compiler. And there were all kinds of 'user shared' > programs that ranged from 'trivial problem, poorly executed' to > 'really cool DEC OS emulators' depending on the era..  The bas.s that > is in V6 and V7 (V5 too?) is an early version fo DEC's BASIC that was > hacked for unix and some I/O devices that were specific to the labs... > there were also advice for what versions of unix to use, and what > versions were available to license. References to things that you > can't google for anymore (or if you do all you find is the google > index of the login issues / auus issues). There's also a number of > country SIGs under DECUS that were for unix in the 77 or so time frame > that might be good to search newsletters for... bitsavers has a bunch, > but not sure they are early enough (I didn't come across the > references to them until long after I looked at what bitsavers had). > > The community aspect of open source was there in spades as well, with > people helping other people and sharing fixes. But it was complicated > by restrictive license agreements and somewhat (imho) overzealous > protection of 'rights' at times that hampered things and would have > echos in later open source licenses and attitudes that would develop > in response. Even though the term 'open source' wasn't coined until > 1998, the open source ethos were present in many of the early computer > users groups, not least the unix ones. USENET amplified it, plus let > in the unwashed masses who also had useful contributions (in addition > to a lot of noise)... then things got really crowded with noise when > AOL went live... And I'm sure there's a number of other BBS and/or > compuserve communities I'm giving short-shrift here because I wasn't > part of them in real time. > > Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsg at jsg.id.au Thu Feb 9 08:12:28 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Thu, 9 Feb 2023 09:12:28 +1100 Subject: [TUHS] project athena (was Re: Setting up an X Development Environment for Mac OS) In-Reply-To: References: <3e272d72-b77a-d347-b5c3-7ed19482e5af@gmail.com> <3h5FEAegoTs6FrhHODiW-rBdB59dt_Rmr4G0PIw7flqaJLsmorgPsilm4f2aJkDud-qEljDjnCJcE1uY05Iw4HNQcyNG4W3wzVlLD0UZfLg=@protonmail.com> Message-ID: On Wed, Jan 25, 2023 at 02:53:30PM -0500, Theodore Ts'o wrote: > On Wed, Jan 25, 2023 at 11:41:12AM -0500, Rich Salz wrote: > > > Aa for the questions of the UNIX-ness of X, it started in Athena, which as > > > I understand it was supposed to be relatively OS-agnostic distributed > > > computing? In any case, the predecessor ran on a different OS, not sure how > > > significant that is to the genesis of what would be called X or what OS it > > > "started" on. > > > > Athena was about scaling up Unix workstations. It was started with grants > > from IBM and Digital. It was never OS-agnostic. > > Well..... technically Athena was about computing in higher ed. If you > go far back enough, at the very beginning, we used VAX 750's and IBM > PC/AT's running DOS. As soon as the Microvax 2's and IBM PC/RT's came > in, about 2 or so years in, Project Athena switched to Unix > workstations, but in the earliest days (which would have been pre-X > Windows), Project Athena had not yet standardized on Unix or > workstations for that matter. Before the PC/RT machines and AOS, there was also an attempt at PC/XT machines with Genix running on a add-in card. "IBM, which has recently established an IBU called Academic Information Systems (ACIS) to address colleges, universities, and schools, will use the Genix32 operating system from National Semiconductor. Genix32, still under development, is based on 4.2BSD (Berkeley's demand-paged Unix system) and runs on the NS32032 32-bit MPU. A previous Genix version was based on 4.1BSD and ran on the NS16032. IBM is likely to use the system on the IAWS (Interim Advanced Workstation, a PC equipped with an NS32032 board, probably also from Sritek." Unix World Vol01.05 https://archive.org/details/Unix_World_Vol01_05.pdf/page/n30/mode/1up "IBM SHIPS XT'S WITH 16032 COPROCESSORS IBM will soon ship 150 XTs containing plug-in National Semiconductor 16032 16-bit microprocessor-based CPU cards to Massachusetts Institute of Technology for use on its large networking development project (described previously in this column). The boards are made by Sritek and include the National Semiconductor floating point math co-processor ICs. IBM will also provide its new video controller board with high density graphics capability and the Berkeley version of the UNIX operating system. The 16032 is a 32-bit microprocessor with 16-bit I/O clocked at 10MHz. It supports a demand-paged virtual-memory environment similar to the DEC VAX. The networking research project, funded by Digital Equipment Corp. ($40 million), IBM ($10 million), and MIT ($12 million), is expected, within five years, to tie together 6,000 personal computers, 63 DEC VAX minicomputers, and 150 DEC VAX microcomputers. All the systems will run various versions of UNIX. It is expected that most of the personal computer workstations will be Sun Microsystems and new DEC units similar to the Sun systems. MIT is expected to develop an enhanced version of UNIX (which was designed only to be a multi-user time sharing system) to operate in a shared resource network environment with enhanced graphics user interfaces utilizing windows and mice. It will probably be called the MIT version of Unix." PC Tech Journal, June 1984, Vol 1, No 9 https://archive.org/details/PC_Tech_Journal_vol01_n09/page/n29/mode/2up "The IBM PC/XT was to be a shell within which the IBM Athena workstation was to be built. High-speed co-processor cards and high-resolution graphics boards were to be piggybacked onto the IBM PCs. These plans fell through because of problems with the co-processor card. ... The project awaits the delivery of 80 IBM PC/ATs. These machines will run XENIX" Simson L. Garfinkel - Athena at MIT The Tech, Vol 105, No 3, Feb 12, 1985 https://thetech.com/issues/105/3/pdf Http://tech.mit.edu:8080/V105/N3/athena.03n.html (cached) From crossd at gmail.com Thu Feb 9 08:39:39 2023 From: crossd at gmail.com (Dan Cross) Date: Wed, 8 Feb 2023 17:39:39 -0500 Subject: [TUHS] Unix "Multiplexed Files" Message-ID: The subject of Communication Files on DTSS came up recently, and Doug linked to this wonderful note: https://www.cs.dartmouth.edu/~doug/DTSS/commfiles.pdf Over on the Multicians list, I raised a question about the history of the DTSS emulator on Multics in response to that, which sadly broke down into antagonism, the details of which aren't terribly interesting. But Barry Margolin suggested that the closest modern Unix analogue of Communication Files were pseudo-TTYs, that had generated a dustup here. Doug's note suggests that Plan 9's userspace filesystems, aided and abetted by mutable namespaces and 9P as a common sharing mechanism, were a closer analogy. But I wonder if multiplexed files were perhaps an earlier analogue; my cursory examination of mpx(2) shows some similarities to the description of the DTSS mechanism. But I confess that I know very little about these, other than that they seem to be an evolutionary dead end (they don't survive in any modern Unix that I'm aware of, at any rate). I don't see much about them in my archives; Paul Ruizendaal mentioned them tangentially in 2020 in relation to non-blocking IO: they are, apparently, due to Chessen? Does anyone have the story here? - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Thu Feb 9 09:40:32 2023 From: robpike at gmail.com (Rob Pike) Date: Thu, 9 Feb 2023 10:40:32 +1100 Subject: [TUHS] Unix "Multiplexed Files" In-Reply-To: References: Message-ID: Not really an answer, but related. When I arrived at Bell Labs mid-1980, Greg Chesson was hard at work on mpx. When the Jerq/Blit work started up shortly after, we thought mpx would be the answer. I even wrote two different window systems using mpx as the controller, one of which was even itself called mpx, but the bugs in the kernel implementation were just too disruptive, and soon dmr's streams (not STREAMS - that was a shouty USG rename) proved the better, more robust mechanism. Other than some simple networking experiments, mpx(2) wasn't used much more as far as I know, and the Jerq effort demonstrated why. -rob On Thu, Feb 9, 2023 at 9:41 AM Dan Cross wrote: > The subject of Communication Files on DTSS came up recently, and Doug > linked to this wonderful note: > https://www.cs.dartmouth.edu/~doug/DTSS/commfiles.pdf > > Over on the Multicians list, I raised a question about the history of the > DTSS emulator on Multics in response to that, which sadly broke down into > antagonism, the details of which aren't terribly interesting. But Barry > Margolin suggested that the closest modern Unix analogue of Communication > Files were pseudo-TTYs, that had generated a dustup here. Doug's note > suggests that Plan 9's userspace filesystems, aided and abetted by mutable > namespaces and 9P as a common sharing mechanism, were a closer analogy. > > But I wonder if multiplexed files were perhaps an earlier analogue; my > cursory examination of mpx(2) shows some similarities to the description of > the DTSS mechanism. > > But I confess that I know very little about these, other than that they > seem to be an evolutionary dead end (they don't survive in any modern Unix > that I'm aware of, at any rate). I don't see much about them in my > archives; Paul Ruizendaal mentioned them tangentially in 2020 in relation > to non-blocking IO: they are, apparently, due to Chessen? > > Does anyone have the story here? > > - Dan C. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at eric.allman.name Thu Feb 9 09:52:34 2023 From: tuhs at eric.allman.name (Eric Allman) Date: Wed, 8 Feb 2023 15:52:34 -0800 Subject: [TUHS] Unix "Multiplexed Files" In-Reply-To: References: Message-ID: <217e7cf8-cc0e-ffb4-efb8-d7ea6edf5b4d@neophilic.com> As it turns out, the first implementation of syslog used mpx files, albeit arguably abusing them. I don't remember the details. mpx files have long since been replaced by modern alternatives. eric On 2023-02-08 14:39 , Dan Cross wrote: > The subject of Communication Files on DTSS came up recently, and Doug > linked to this wonderful note: > https://www.cs.dartmouth.edu/~doug/DTSS/commfiles.pdf > > Over on the Multicians list, I raised a question about the history of > the DTSS emulator on Multics in response to that, which sadly broke > down into antagonism, the details of which aren't terribly > interesting. But Barry Margolin suggested that the closest modern Unix > analogue of Communication Files were pseudo-TTYs, that had generated a > dustup here. Doug's note suggests that Plan 9's userspace filesystems, > aided and abetted by mutable namespaces and 9P as a common sharing > mechanism, were a closer analogy. > > But I wonder if multiplexed files were perhaps an earlier analogue; my > cursory examination of mpx(2) shows some similarities to the > description of the DTSS mechanism. > > But I confess that I know very little about these, other than that > they seem to be an evolutionary dead end (they don't survive in any > modern Unix that I'm aware of, at any rate). I don't see much about > them in my archives; Paul Ruizendaal mentioned them tangentially in > 2020 in relation to non-blocking IO: they are, apparently, due to Chessen? > > Does anyone have the story here? > >         - Dan C. > From tuhs at tuhs.org Thu Feb 9 11:32:21 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 09 Feb 2023 01:32:21 +0000 Subject: [TUHS] UNIX/TS 4.x Findings Message-ID: Good day everyone, I'm emailing to start a thread on part of my larger UNIX/TS 4.x project that is coming to a conclusion. Lots of info here, so pardon the lack of brevity. Over the course of the past month or so I've been diffing all of the manual pages between System III and System V to produce a content-accurate set of typesetter sources for the UNIX Release 4.1 (3B20S) manual I found a while back. I've completed my shallow pass of everything (all pages accounted for, generally complete, except the permuted index) and am now about halfway through my second pass (detailed, three-way diffs, documenting changes) and thought I'd share a few findings to kick off what will likely be more exposition of the 3.x->4.x->5.x->SysV time-period vis-a-vis available documentation. Most analysis here will center specifically around the contents of the 4.1 3B20S manual and later Documents For UNIX 4.0 as those are the only documents I've found for 4.x. I mention that as there are whole subsystems excluded from this manual that show back up in my 5.0 manual, so I suspect they were pieces that weren't ready for 3B-20 at the time but were in other installations. Fortran, SNOBOL, Honeywell 6000 communication, and the old lpr print system are absent, for instance. Anywho, as I wrap up what I can prove, then I'll probably swoop through and compare these SysIII to SysV to at least document what may have happened in that timeframe, if anything. If I'm lucky there are no visible changes in the man pages meaning they were nominally identical between the various versions. We'll see. Also a disclaimer, this is entirely documentation based. I have not yet cross-referenced changes I see in manuals with changes observed between code revisions. A later phase of my project will be doing this sort of analysis to try and reconstruct some idea of what code changes were 3-to-4 and which ones were 4-to-5, but that's quite a ways away. All that to say, a manual page could entirely be updated much later than a change it describes, so if something in code contradicts anything in the manuals, the code is obviously what the system was actually doing at the time. The manual is just how well someone bothered to document it. The sections I've finished thus far are 2 - System Calls, 5 - Miscellaneous Facilities, and 6 - Games, and the frontmatter/intro section. Here's a bit of digest on what I've gone over with a fine toothed comb thus far: 3.x->4.x: --------- There is a general trend towards platform-independence that already started with merging of PDP-11 and VAX support into a single-ish codebase ala 3.x. This trend continues with indicating that machine discrepancies (and obsolescence) will be noted in the mast head of pertinent manual entries. References to adb are dropped from this intro section. Additionally, a new section numbering is applied to the User's and Administrator's Manuals (which are split by the way). This starts the numbering/split scheme we continue to see in 5.0 and SysV a year or so later, where sections 4, 5, and 7 are shuffled to stick device files in section 7 and in turn split off 1M, 7, and 8 into a separate Administrator's Manual (a_man vs u_man). Unfortunately, since this split did occur at 4.x, I don't have the 1M, 7, and 8 sections to compare with, the copy of the manual I nabbed was just the User's Manual. If someone has a UNIX Administrator's Manual Release 4.x that they'd be willing to offer up for scanning/analysis, that would definitely help complete the circle. Other frontmatter changes imply a move more towards commercialize-able literature. The Editors are commented out as indicated by the SysV manual sources later on. Unfortunately this means my goal of documenting authorship remains unattainable at present, but in any case, somewhere along the way the responsibility was shifted from Lab 364 (3.x) to Lab 4542 (5.x). An acknowledgement from the Lab 364 folks in the 3.x manual is dropped entirely, not even commented out. This acknowledgement thanks the efforts of those who assembled the V6, V7, PWB/2.0, and UNIX/TS 1.1 manuals (what I wouldn't give for the latter two...). Another change regarding commercialized literature is the reference to UNIX for Beginners in the intro section is replaced with a reference the "UNIX User's Guide". This manual does show up by SysV, but I don't know if this implies they were running those sets this way by the time of 4.1. Arnold Robbins provided Documents for UNIX 4.0 last year which is very much still the old /usr/doc *roff documents, so either they were pre-empting the material they would start to produce with 5.x, or there is yet another set of potential 4.x documents floating around out there. In any case, there are a handful of changes to 2 - system calls: - intro reflects that error.h has been renamed to errno.h - The "SysV" IPC shows up here in 4.1. I forget who mentioned it but someone has mentioned in the past 4.0 and 4.1 had different IPC systems, so this isn't that illuminating unfortunately. - A minimum of 1 character for filenames is noted. I suppose around this time someone won the "well it doesn't *say* you can't have a zero character file name" pedantic argument. - Various areas where groups are referred to, text is updated to ensure it is understood the author means "effective" group - brk, exec, exit, and fork pages all now have verbiage concerning how they interact with IPC - brk clarifies that added space is initialized to zero - exec adds verbiage about argc, argv, envp, and environ, and notes that ENOEXEC doesn't apply to execlp and execvp - fork adds a thorough description of which attributes of the parent process are passed down - kill elaborates that real or effective user (and group) can influence permissions - ptrace updates adb references to sdb and adds 3B-20 verbiage - setuid consolidates explanations of setuid and setgid, no noticed change to functionality - signal now defers to exit(2) to describe termination actions and changes header references from signal.h to sys/signal.h - sys3b is added for 3B-20-specific system calls - utsname gains the machine field (for -m) - wait now stashes the signal number causing a return in the upper byte of the status word And then under 5 - misc: - Many pages used a .so directive to directly populate a given header. By SysV this has been changed to include the text in the pages directly. Unsure exactly what 4.x did but I went with the latter - eqnchar loses the scrL, less-than-or-equal-to, and greater-than-or-equal-to character replacements - ldfcn is added, this is the general description page for what will become the COFF library, at this stage it is very 3B-20 oriented in description - man adds the \*(Tm trademark indicator - mosd and mptx macro pages are added - mv's macro page is pretty much rewritten to include the actual macros, the version in 3.x simply referred to there being macros and a manual coming soon - types in 3.0 has variable sizes for cnt_t and label_t depending on VAX or not. 4.x seems to remove this discrepancy and always present the VAX sizes And finally under 6 - games: - A note about using cron to restrict access has been removed, unknown if this is a stylistic choice or because cron is a 1M and therefore no longer in this manual - chess and sky both have their FILES sections removed - jotto is added - ttt gains a note that the cubic variant does not work on VAX - wump is no longer PDP-11 only as of 4.1 Other stuff not fully digested yet: - It appears what would become COFF (Common Object File Format) had its beginnings as the 3B-20 object file format for UNIX/TS 4.x. The 3B-20 object-related stuff becomes the more general versions in 5.x. - The LP print service has its start in 4.x. - SysV IPC appears to be largely there by 4.1, with only icprm missing as far as I could tell. - 4.x introduces the termio system. - 4.1 may signal the start of distributing guidance material as "Guides" rather than "Documents For UNIX". There are a number of tech report citations that have been updated to reflect this. 4.x->5.x: --------- As for the 4.x->5.x for these same items (I'll mention 4.x->5.x and 5.x->SysV both): - Sys V adds a notice that the manual describes features of the 3B20S which is not out. No such notice is in the 5.0 manuals, so this was specifically for outside consumption - The BTL version of the 5.0 manual features the return of the acknowledgements page as well as a preface describing the manual and DIV 452's involvement. If there was a BTL version of 4.x manuals, I suspect they may have also included this as it was in the 3.0 manual. - Sys V begins the "The UNIX System" nomenclature in earnest. - Otherwise the frontmatter seems pretty much unchanged from 4.x to 5.x, the only discrepancies arise in the BTL and SysV variants In 2 - system calls: - adds a few required headers - shmop appears to have changed headers slightly, requiring ipc.h and shm.h instead of shmem.h - signal states that apparently SIGCLD is now reset when caught - sys3b adds syscalls 3, 9, and 10, for attaching to an address translation buffer, changing the default field test set utility-id, and changing FPU flag bits respectively - times switches to the tms struct from the tbuffer struct. Same fields but slight change in names. Times also notes that times are given in 1/100th of a second for WECo processors (1/60th for DEC). In 5 - misc: - ldfcn is moved to section 4 and drops 3B-20 specificity, signaling the start of COFF in earnest - term adds names for TELETYPE 40/4 and 4540 as well as IBM Model 3270 terminals - types adds the uint (unsigned int) and key_t (long) types And there are actually no noteworthy changes to section 6. So general takeaways thus far on the 4->5 transition: - COFF becomes formalized here rather than being the 3B-20 format that might get extended to things - "The UNIX System" nomenclature begins with System V - 3B20S starts showing up in external literature but isn't openly available yet - 3B-20 support is still growing and being used as a model for "generic" components, especially COFF and SGS - CB-UNIX init is moved over starting with 5.0 --------- There'll definitely be more to come as I do my second pass of sections 1, 3, and 4. As things begin to wrap up I also intend to upload the manual restoration somewhere, probably archive.org. I still intend to scan the physical copy sometime later this year, but this'll get info out so people can research things, and of course if any discrepancy ever arises I'll happily pull the original manual page and scan it as proof of anything odd. My biggest takeaway from what I've covered thus far is this clarifies the history of COFF a bit. Wikipedia states that COFF was a System V innovation, which commercially, it very well was. However, this documentation demonstrates that it began life likely as a 3B-20-specific format that was then applicable to others. This now places, COFF, LP, *and* IPC all as things credited to System V that really started with at most UNIX/TS 4.1. The more I look at things, the more 5.0 appears to actually be a minor release compared to what all was going on in the 4.x era. From 4.1 to 5.0 the largest changes I see thus far are the addition of CB-UNIX init, generalization of COFF from a 3B-20 object format, and otherwise just clerical, marketing, and accuracy improvements to the literature. This statement will be qualified much better as I turn over more ground on this, but that's the general gist I've been gathering as I go through this: 3.x->4.x saw the introduction of a great number of soon-to-be-ubiquitous parts of UNIX and then 4.x->5.x and on to System V saw those components being tuned and the release being shepherded along into a viable commercial solution. As with anything, this is of course, all based on analysis of documents, so if there are any inaccuracies in anything, I apologize and welcome corrections/clarifications. Hopefully by the end of all of this there'll be enough content to draft up a proper Wikipedia article on the "System IV" that never was and correct what truly was a System V innovation vs what just finally popped out of USL with that version. If you made it all the way here, thanks for reading! - Matt G. From tytso at mit.edu Thu Feb 9 12:51:15 2023 From: tytso at mit.edu (Theodore Ts'o) Date: Wed, 8 Feb 2023 21:51:15 -0500 Subject: [TUHS] project athena (was Re: Setting up an X Development Environment for Mac OS) In-Reply-To: References: <3e272d72-b77a-d347-b5c3-7ed19482e5af@gmail.com> <3h5FEAegoTs6FrhHODiW-rBdB59dt_Rmr4G0PIw7flqaJLsmorgPsilm4f2aJkDud-qEljDjnCJcE1uY05Iw4HNQcyNG4W3wzVlLD0UZfLg=@protonmail.com> Message-ID: On Thu, Feb 09, 2023 at 09:12:28AM +1100, Jonathan Gray wrote: > > Before the PC/RT machines and AOS, there was also an attempt at PC/XT > machines with Genix running on a add-in card. It's possible that there were some IBM'ers at MIT Building E40 (where Project Athena was headquartered) that were playing with a PC/XT with a co-processor board, but as far as I know that was never deployed in the field --- at least, I never saw them. The only I saw were PC/AT's (that is, the ones with the '286 CPU) that ran DOS and which were essentially used only to telnet to the Vax 750's (or supdup to the MIT AI / LCS lab machines, but most undergraduates didn't have access to those computers; connecting to MIT Multics was also possible, via a 3270 emulator, but again, most undergrduates didn't have access, although MIT's Student Information Processing Board could give out limited accounts for undergraduates to experiment with Multics.) - Ted From jsg at jsg.id.au Fri Feb 10 12:54:26 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Fri, 10 Feb 2023 13:54:26 +1100 Subject: [TUHS] UNIX/TS 4.x Findings In-Reply-To: References: Message-ID: On Thu, Feb 09, 2023 at 01:32:21AM +0000, segaloco via TUHS wrote: > Good day everyone, I'm emailing to start a thread on part of my larger > UNIX/TS 4.x project that is coming to a conclusion. Lots of info > here, so pardon the lack of brevity. according to Pirzada's thesis there was no UNIX/TS 4.x nov 1978 UNIX/TS 1.0 feb 1979 UNIX/TS 1.1 sep 1979 UNIX/TS 1.2 (VAX) early 1980 PWB and USG groups combine into "Microsystems and UNIX Development Laboratory" jun 1980 UNIX Release 3.0 sep 1980 UNIX Release 3.1 mar 1981 UNIX Release 4.0 aug 1981 UNIX Release 4.1.1 for 3B-20 dec 1981 UNIX Release 4.1.2 jan 1982 System III, based on Release 3.0.1 feb 1982 UNIX Release 4.2 may 1982 UNIX Release 4.2.1 oct 1982 UNIX Release 5.0 jan 1983 System V, based on Release 5.0 "In August 1981, UNIX (denoted: 4.1.1[14]) was released for the WECo 3B-20s processor. It was meant only for the 3B machine and was basically 4.0 with hardware related changes. This release also marked the point where WECo became the official UNIX release agent (aking over from Bell Labs). An update (4.1.2) was released in December containing some memory management fixes and added on-line diagnostics. 14. Release 4.1 never making it out of the door as it was not meant for floating point hardware." > somewhere along the way the responsibility was shifted from Lab 364 (3.x) > to Lab 4542 (5.x). "A Bell Laboratories -wide reorganisation in January 1981 resulted in the UNIX Lab being renumbered. Release 4.0 was launched from this organization in March." > SysV IPC appears to be largely there by 4.1, with only icprm missing > as far as I could tell. further changed in 4.2: "Release 4.2 was launched in February 1982 for both the 3B & the DEC machines. It contained improvements to the data communications and networking software and more mature IPC." > From 4.1 to 5.0 the largest changes I see thus far are the addition of > CB-UNIX init, generalization of COFF from a 3B-20 object format, and > otherwise just clerical, marketing, and accuracy improvements to the literature. "Much improved performance, a new file system, new init and getty (from CB/UNIX) and networking with other bits from BSD/UNIX were the main features of Release 5.0" quotes from: Shamim Sharifuddin Pirzada A Statistical Examination of The Evolution of the UNIX System September 1988 https://spiral.imperial.ac.uk/bitstream/10044/1/7942/1/Shamim_Sharfuddin_Pirzada-1988-PhD-Thesis.pdf referenced in https://www.tuhs.org/Archive/Documentation/Emails/dmr_wkt.html From imp at bsdimp.com Fri Feb 10 13:07:45 2023 From: imp at bsdimp.com (Warner Losh) Date: Thu, 9 Feb 2023 20:07:45 -0700 Subject: [TUHS] UNIX/TS 4.x Findings In-Reply-To: References: Message-ID: On Thu, Feb 9, 2023 at 6:30 PM segaloco via TUHS wrote: > The more I look at things, the more 5.0 appears to actually be a minor > release compared to what all was going on in the 4.x era. From 4.1 to 5.0 > So let's look at release dates: 4.2BSD released August 1983 4.3BSD released May 1986 System V released sometime in 1983 (so TS 5.0 was 1982 by convention?) 5.0 felt like a minor release... (even after TS 4.2) Sure sounds like it was rebranded to 5.0 to avoid confusion with 4.2BSD which was released around... as well as to have a '.0' zero feel to it but neatly avoiding that by calling it V... Anybody here know for sure? I have a vague memory of Dr McKusick mentioning this off hand in one of his informal talks or maybe it was over dinner at a conference... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Fri Feb 10 13:15:33 2023 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 9 Feb 2023 19:15:33 -0800 Subject: [TUHS] UNIX/TS 4.x Findings In-Reply-To: References: Message-ID: <20230210031533.GC10634@mcvoy.com> On Thu, Feb 09, 2023 at 08:07:45PM -0700, Warner Losh wrote: > On Thu, Feb 9, 2023 at 6:30 PM segaloco via TUHS wrote: > > > The more I look at things, the more 5.0 appears to actually be a minor > > release compared to what all was going on in the 4.x era. From 4.1 to 5.0 > > > > So let's look at release dates: > > 4.2BSD released August 1983 > 4.3BSD released May 1986 Pretty sure his 4.1 was USG's 4.1, not BSD's 4.1. From jsg at jsg.id.au Fri Feb 10 13:22:01 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Fri, 10 Feb 2023 14:22:01 +1100 Subject: [TUHS] UNIX/TS 4.x Findings In-Reply-To: References: Message-ID: On Thu, Feb 09, 2023 at 08:07:45PM -0700, Warner Losh wrote: > On Thu, Feb 9, 2023 at 6:30 PM segaloco via TUHS wrote: > > > The more I look at things, the more 5.0 appears to actually be a minor > > release compared to what all was going on in the 4.x era. From 4.1 to 5.0 > > > > So let's look at release dates: > > 4.2BSD released August 1983 > 4.3BSD released May 1986 > > System V released sometime in 1983 (so TS 5.0 was 1982 by convention?) > > 5.0 felt like a minor release... (even after TS 4.2) Sure sounds like it > was rebranded to 5.0 to avoid confusion with 4.2BSD which was released > around... as well as to have a '.0' zero feel to it but neatly avoiding > that by calling it V... > > Anybody here know for sure? I have a vague memory of Dr McKusick mentioning > this off hand in one of his informal talks or maybe it was over dinner at a > conference... It was the other way around. "The original intent had been to call it the 5BSD release; however, there were objections from AT&T that there would be customer confusion between their commercial Unix release, System V, and a Berkeley release named 5BSD. So, to resolve the issue, Berkeley agreed to change the naming scheme for future releases to stay at 4BSD and just increment the minor number." https://www.oreilly.com/openbook/opensources/book/kirkmck.html From imp at bsdimp.com Fri Feb 10 13:22:39 2023 From: imp at bsdimp.com (Warner Losh) Date: Thu, 9 Feb 2023 20:22:39 -0700 Subject: [TUHS] UNIX/TS 4.x Findings In-Reply-To: <20230210031533.GC10634@mcvoy.com> References: <20230210031533.GC10634@mcvoy.com> Message-ID: On Thu, Feb 9, 2023, 8:15 PM Larry McVoy wrote: > On Thu, Feb 09, 2023 at 08:07:45PM -0700, Warner Losh wrote: > > On Thu, Feb 9, 2023 at 6:30 PM segaloco via TUHS wrote: > > > > > The more I look at things, the more 5.0 appears to actually be a minor > > > release compared to what all was going on in the 4.x era. From 4.1 to > 5.0 > > > > > > > So let's look at release dates: > > > > 4.2BSD released August 1983 > > 4.3BSD released May 1986 > > Pretty sure his 4.1 was USG's 4.1, not BSD's 4.1. > I'm sure it was too. My comment was about At&T's marketing... Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsg at jsg.id.au Fri Feb 10 13:47:46 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Fri, 10 Feb 2023 14:47:46 +1100 Subject: [TUHS] UNIX/TS 4.x Findings In-Reply-To: References: Message-ID: On Fri, Feb 10, 2023 at 02:22:01PM +1100, Jonathan Gray wrote: > On Thu, Feb 09, 2023 at 08:07:45PM -0700, Warner Losh wrote: > > On Thu, Feb 9, 2023 at 6:30 PM segaloco via TUHS wrote: > > > > > The more I look at things, the more 5.0 appears to actually be a minor > > > release compared to what all was going on in the 4.x era. From 4.1 to 5.0 > > > > > > > So let's look at release dates: > > > > 4.2BSD released August 1983 > > 4.3BSD released May 1986 > > > > System V released sometime in 1983 (so TS 5.0 was 1982 by convention?) > > > > 5.0 felt like a minor release... (even after TS 4.2) Sure sounds like it > > was rebranded to 5.0 to avoid confusion with 4.2BSD which was released > > around... as well as to have a '.0' zero feel to it but neatly avoiding > > that by calling it V... > > > > Anybody here know for sure? I have a vague memory of Dr McKusick mentioning > > this off hand in one of his informal talks or maybe it was over dinner at a > > conference... > > It was the other way around. > > "The original intent had been to call it the 5BSD release; however, > there were objections from AT&T that there would be customer confusion > between their commercial Unix release, System V, and a Berkeley release > named 5BSD. So, to resolve the issue, Berkeley agreed to change the > naming scheme for future releases to stay at 4BSD and just increment the > minor number." > https://www.oreilly.com/openbook/opensources/book/kirkmck.html "we started referring to this stuff as 5BSD, because we were sure that the next release would be 5BSD. We made a dump tape and Bill packed up and went back to California. Shannon and I took the disk pack and copied it and brought it up on decvax—a 780, our main system. Bill Joy called a couple of days later and said, "Hey, there's going to be a lot of hassle with the license if we do another release. So why don't we call it 4.1BSD?" Armando Stettner in QCU, pg 182 'Releases of Berkeley software remain labeled as "4.X BSD" even though the differences between them are dramatic. Berkeley wanted to relabel 4.2 as "5.0" except that university regulations would have forced it to relicense all of its "customers." As it turned out, Berkeley had to do it anyway because of code that was included from a new release of the AT&T software.' Life with UNIX, pg 18 tuhs/Documentation/Books/Life_with_Unix_v2.pdf From tuhs at tuhs.org Fri Feb 10 14:38:35 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 10 Feb 2023 04:38:35 +0000 Subject: [TUHS] UNIX/TS 4.x Findings In-Reply-To: References: Message-ID: <2XyFQMdNqMtF1Mr0uR7953_hlXtegijahATtyjqGWWCLPbLmDGDJMVneA7OOB9TeY1ww6N5b7cJy8u4ceemZqdumwM4jrlzmd0KDJQuVMXA=@protonmail.com> Thank you for the corrections and additions. I've been back and forth on the naming, I hear it called USG UNIX 4 in some contexts, the literature just says "UNIX" until SysV which gets "UNIX System". UNIX/TS is at the top of low.s in SysIII and SysV, but this could just be left over. In one school of thought, calling it PWB 4 might be more accurate than any of these. I recall reading elsewhere here in the mailing list that the name System III was chosen because it was believed Programmers WorkBench wouldn't be an appealing name marketing-wise. If strictly documentation is to be followed, then this manual and my analysis represent "UNIX Release 4.1" for the 3B20S as dated June 1981. Anything not directly pertaining to this, of course, is speculation and postulation. - Matt G. ------- Original Message ------- On Thursday, February 9th, 2023 at 6:54 PM, Jonathan Gray wrote: > On Thu, Feb 09, 2023 at 01:32:21AM +0000, segaloco via TUHS wrote: > > > Good day everyone, I'm emailing to start a thread on part of my larger > > UNIX/TS 4.x project that is coming to a conclusion. Lots of info > > here, so pardon the lack of brevity. > > > according to Pirzada's thesis there was no UNIX/TS 4.x > nov 1978 UNIX/TS 1.0 > feb 1979 UNIX/TS 1.1 > sep 1979 UNIX/TS 1.2 (VAX) > early 1980 PWB and USG groups combine into > "Microsystems and UNIX Development Laboratory" > jun 1980 UNIX Release 3.0 > sep 1980 UNIX Release 3.1 > mar 1981 UNIX Release 4.0 > aug 1981 UNIX Release 4.1.1 for 3B-20 > dec 1981 UNIX Release 4.1.2 > jan 1982 System III, based on Release 3.0.1 > feb 1982 UNIX Release 4.2 > may 1982 UNIX Release 4.2.1 > oct 1982 UNIX Release 5.0 > jan 1983 System V, based on Release 5.0 > > "In August 1981, UNIX (denoted: 4.1.1[14]) was released for the > WECo 3B-20s processor. It was meant only for the 3B machine and was > basically 4.0 with hardware related changes. This release also marked > the point where WECo became the official UNIX release agent (aking over > from Bell Labs). An update (4.1.2) was released in December containing > some memory management fixes and added on-line diagnostics. > > 14. Release 4.1 never making it out of the door as it was not meant for > floating point hardware." > > > somewhere along the way the responsibility was shifted from Lab 364 (3.x) > > to Lab 4542 (5.x). > > > "A Bell Laboratories -wide reorganisation in January 1981 resulted in > the UNIX Lab being renumbered. Release 4.0 was launched from this > organization in March." > > > SysV IPC appears to be largely there by 4.1, with only icprm missing > > as far as I could tell. > > > further changed in 4.2: > > "Release 4.2 was launched in February 1982 for both the 3B & the DEC > machines. It contained improvements to the data communications and > networking software and more mature IPC." > > > From 4.1 to 5.0 the largest changes I see thus far are the addition of > > CB-UNIX init, generalization of COFF from a 3B-20 object format, and > > otherwise just clerical, marketing, and accuracy improvements to the > > literature. > > "Much improved performance, a new file system, new init and getty (from > CB/UNIX) and networking with other bits from BSD/UNIX were the main > features of Release 5.0" > > quotes from: > Shamim Sharifuddin Pirzada > A Statistical Examination of The Evolution of the UNIX System > September 1988 > https://spiral.imperial.ac.uk/bitstream/10044/1/7942/1/Shamim_Sharfuddin_Pirzada-1988-PhD-Thesis.pdf > > referenced in > https://www.tuhs.org/Archive/Documentation/Emails/dmr_wkt.html From ggm at algebras.org Fri Feb 10 14:48:27 2023 From: ggm at algebras.org (George Michaelson) Date: Fri, 10 Feb 2023 14:48:27 +1000 Subject: [TUHS] UNIX/TS 4.x Findings In-Reply-To: <2XyFQMdNqMtF1Mr0uR7953_hlXtegijahATtyjqGWWCLPbLmDGDJMVneA7OOB9TeY1ww6N5b7cJy8u4ceemZqdumwM4jrlzmd0KDJQuVMXA=@protonmail.com> References: <2XyFQMdNqMtF1Mr0uR7953_hlXtegijahATtyjqGWWCLPbLmDGDJMVneA7OOB9TeY1ww6N5b7cJy8u4ceemZqdumwM4jrlzmd0KDJQuVMXA=@protonmail.com> Message-ID: I hesitate to throw this into the mix, but I would observe in those days, people were a bit less formal about release versions and I have a suspicion (but only a suspicion) that from time to time what shipped on a 1200bpi tape was not some canonical 'this is the release as of 3 months ago' but more 'this is a sh scripted product of the checked out state as I understood it, on the box I had available to me, to cut a tape. The tape had to have boot blocks up front. You got told to do mt fsf stuff. So.. I accept *some* of the tape structure was a bit more formally policed: giving people the wrong architecture and bootblocks would be bad. But when it comes to what was unpacked for runtime? I think it wasn't quite as 'reproducible build' formal as it is now, for some people. The version numbers were not mutable. What was stamped with them? Perhaps it was. G From tuhs at tuhs.org Fri Feb 10 14:58:07 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 10 Feb 2023 04:58:07 +0000 Subject: [TUHS] UNIX/TS 4.x Findings In-Reply-To: References: <2XyFQMdNqMtF1Mr0uR7953_hlXtegijahATtyjqGWWCLPbLmDGDJMVneA7OOB9TeY1ww6N5b7cJy8u4ceemZqdumwM4jrlzmd0KDJQuVMXA=@protonmail.com> Message-ID: That's all the more reason to be precise, with all the uncertainty there is at least the fact that I can say this is what the documentarian in charge of the manual had approved to live in /usr/man/u_man on the particular box they had hooked up to the typesetter when they cut the plates that eventually printed the book I hold. No amount of printed material will ever capture reality, but it does give a darn good window into it in a more precise way. On the note of precision, to add fuel to the USG fire, there is also the USG Program Generic line, which has numbers distinct from this stuff too. So many branches... - Matt G. ------- Original Message ------- On Thursday, February 9th, 2023 at 8:48 PM, George Michaelson wrote: > I hesitate to throw this into the mix, but I would observe in those > days, people were a bit less formal about release versions and I have > a suspicion (but only a suspicion) that from time to time what shipped > on a 1200bpi tape was not some canonical 'this is the release as of 3 > months ago' but more 'this is a sh scripted product of the checked out > state as I understood it, on the box I had available to me, to cut a > tape. > > The tape had to have boot blocks up front. You got told to do mt fsf > stuff. So.. I accept some of the tape structure was a bit more > formally policed: giving people the wrong architecture and bootblocks > would be bad. > > But when it comes to what was unpacked for runtime? I think it wasn't > quite as 'reproducible build' formal as it is now, for some people. > > The version numbers were not mutable. What was stamped with them? > Perhaps it was. > > G From tuhs at tuhs.org Fri Feb 10 15:36:55 2023 From: tuhs at tuhs.org (Christian Dreier via TUHS) Date: Fri, 10 Feb 2023 06:36:55 +0100 Subject: [TUHS] Circuit design tool mentioned in AT&T Unix promotion Message-ID: <854dfba0-6cf2-57a4-3995-c57571205d1f@googlemail.com> Hello there, I recently watched an old Unix promotion video by AT&T on YouTube (AT&T Archives: The UNIX Operating System: https://youtu.be/tc4ROCJYbm0) and they mention a design tool for integrated circuits (apparently named L-Gen or lgen; timestamped link: https://youtu.be/tc4ROCJYbm0?t=1284). Part of this software is a language implemented with YACC that appears to describe the behavior of digital logic, like modern hardware description languages, i.e. Verilog and VHDL. Does anyone have information about this, in particular: - Documentation - Which projects were realized with this? - Source code, if possible I asked this question on retrocomputing.stackexchange.com (see https://retrocomputing.stackexchange.com/q/26301/26615) but so far there is no satisfying answer. A "Circuit Design Language" (CDL) is mentioned and there is some good information about it but it has another syntax (as shown in the video vs. the documentation about CDL) and apparently another purpose (description of board wiring vs. logic behavior). Best regards, Christian From douglas.mcilroy at dartmouth.edu Fri Feb 10 22:56:29 2023 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Fri, 10 Feb 2023 07:56:29 -0500 Subject: [TUHS] Circuit design tool mentioned in AT&T Unix promotion In-Reply-To: <854dfba0-6cf2-57a4-3995-c57571205d1f@googlemail.com> References: <854dfba0-6cf2-57a4-3995-c57571205d1f@googlemail.com> Message-ID: CDL was for designing wired circuit boards, not integrated circuits.. It was used to design the Datakit switch, the Belle chess machine and other hardware. I suspect the cited IC-design tool was one that Steve Johnson created for use in a short course that Carver Mead taught at Bell Labs. I am not aware that it saw use outside of that course. Doug On Fri, Feb 10, 2023 at 12:37 AM Christian Dreier via TUHS wrote: > > Hello there, > > I recently watched an old Unix promotion video by AT&T on YouTube (AT&T > Archives: The UNIX Operating System: https://youtu.be/tc4ROCJYbm0) and > they mention a design tool for integrated circuits (apparently named > L-Gen or lgen; timestamped link: https://youtu.be/tc4ROCJYbm0?t=1284). > > Part of this software is a language implemented with YACC that appears > to describe the behavior of digital logic, like modern hardware > description languages, i.e. Verilog and VHDL. > > Does anyone have information about this, in particular: > - Documentation > - Which projects were realized with this? > - Source code, if possible > > I asked this question on retrocomputing.stackexchange.com (see > https://retrocomputing.stackexchange.com/q/26301/26615) but so far there > is no satisfying answer. A "Circuit Design Language" (CDL) is mentioned > and there is some good information about it but it has another syntax > (as shown in the video vs. the documentation about CDL) and apparently > another purpose (description of board wiring vs. logic behavior). > > Best regards, > Christian From jpl.jpl at gmail.com Fri Feb 10 23:02:35 2023 From: jpl.jpl at gmail.com (John P. Linderman) Date: Fri, 10 Feb 2023 08:02:35 -0500 Subject: [TUHS] Sandy Fraser memorial Message-ID: This from Pat Parseghian. Yes, Sandy died many months ago, but the memorial is new. https://www.cst.cam.ac.uk/news/sandy-fraser-memorial-his-achievements -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Fri Feb 10 23:20:56 2023 From: clemc at ccc.com (Clem Cole) Date: Fri, 10 Feb 2023 08:20:56 -0500 Subject: [TUHS] Circuit design tool mentioned in AT&T Unix promotion In-Reply-To: References: <854dfba0-6cf2-57a4-3995-c57571205d1f@googlemail.com> Message-ID: FYI: The sources to CDL are in the TUHS archives. On Fri, Feb 10, 2023 at 7:56 AM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > CDL was for designing wired circuit boards, not integrated circuits.. > It was used to design the Datakit switch, the Belle chess machine and > other hardware. > > I suspect the cited IC-design tool was one that Steve Johnson created > for use in a short course that Carver Mead taught at Bell Labs. I am > not aware that it saw use outside of that course. > > Doug > > On Fri, Feb 10, 2023 at 12:37 AM Christian Dreier via TUHS > wrote: > > > > Hello there, > > > > I recently watched an old Unix promotion video by AT&T on YouTube (AT&T > > Archives: The UNIX Operating System: https://youtu.be/tc4ROCJYbm0) and > > they mention a design tool for integrated circuits (apparently named > > L-Gen or lgen; timestamped link: https://youtu.be/tc4ROCJYbm0?t=1284). > > > > Part of this software is a language implemented with YACC that appears > > to describe the behavior of digital logic, like modern hardware > > description languages, i.e. Verilog and VHDL. > > > > Does anyone have information about this, in particular: > > - Documentation > > - Which projects were realized with this? > > - Source code, if possible > > > > I asked this question on retrocomputing.stackexchange.com (see > > https://retrocomputing.stackexchange.com/q/26301/26615) but so far there > > is no satisfying answer. A "Circuit Design Language" (CDL) is mentioned > > and there is some good information about it but it has another syntax > > (as shown in the video vs. the documentation about CDL) and apparently > > another purpose (description of board wiring vs. logic behavior). > > > > Best regards, > > Christian > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Feb 11 01:03:40 2023 From: clemc at ccc.com (Clem Cole) Date: Fri, 10 Feb 2023 10:03:40 -0500 Subject: [TUHS] Circuit design tool mentioned in AT&T Unix promotion In-Reply-To: References: <854dfba0-6cf2-57a4-3995-c57571205d1f@googlemail.com> Message-ID: I had to get off my mobile and to real network connection - here is the URL: https://www.tuhs.org/Archive/Applications/Circuit_Design/ ᐧ On Fri, Feb 10, 2023 at 8:20 AM Clem Cole wrote: > FYI: The sources to CDL are in the TUHS archives. > > On Fri, Feb 10, 2023 at 7:56 AM Douglas McIlroy < > douglas.mcilroy at dartmouth.edu> wrote: > >> CDL was for designing wired circuit boards, not integrated circuits.. >> It was used to design the Datakit switch, the Belle chess machine and >> other hardware. >> >> I suspect the cited IC-design tool was one that Steve Johnson created >> for use in a short course that Carver Mead taught at Bell Labs. I am >> not aware that it saw use outside of that course. >> >> Doug >> >> On Fri, Feb 10, 2023 at 12:37 AM Christian Dreier via TUHS >> wrote: >> > >> > Hello there, >> > >> > I recently watched an old Unix promotion video by AT&T on YouTube (AT&T >> > Archives: The UNIX Operating System: https://youtu.be/tc4ROCJYbm0) and >> > they mention a design tool for integrated circuits (apparently named >> > L-Gen or lgen; timestamped link: https://youtu.be/tc4ROCJYbm0?t=1284). >> > >> > Part of this software is a language implemented with YACC that appears >> > to describe the behavior of digital logic, like modern hardware >> > description languages, i.e. Verilog and VHDL. >> > >> > Does anyone have information about this, in particular: >> > - Documentation >> > - Which projects were realized with this? >> > - Source code, if possible >> > >> > I asked this question on retrocomputing.stackexchange.com (see >> > https://retrocomputing.stackexchange.com/q/26301/26615) but so far >> there >> > is no satisfying answer. A "Circuit Design Language" (CDL) is mentioned >> > and there is some good information about it but it has another syntax >> > (as shown in the video vs. the documentation about CDL) and apparently >> > another purpose (description of board wiring vs. logic behavior). >> > >> > Best regards, >> > Christian >> > -- > Sent from a handheld expect more typos than usual > -------------- next part -------------- An HTML attachment was scrubbed... URL: From heinz at osta.com Sat Feb 11 01:22:22 2023 From: heinz at osta.com (Heinz Lycklama) Date: Fri, 10 Feb 2023 07:22:22 -0800 Subject: [TUHS] Circuit design tool mentioned in AT&T Unix promotion In-Reply-To: References: <854dfba0-6cf2-57a4-3995-c57571205d1f@googlemail.com> Message-ID: <675e6f22-93a7-cbd2-df50-17e713574b22@osta.com> Speaking about Datakit, some old timers may be interested in this online memorial for Sandy Fraser and his achievements being held in the UK on February 15: https://www.cst.cam.ac.uk/news/sandy-fraser-memorial-his-achievements Heinz On 2/10/2023 7:03 AM, Clem Cole wrote: > > I had to get off my mobile and to real network connection - here is > the URL: https://www.tuhs.org/Archive/Applications/Circuit_Design/ > ᐧ > > On Fri, Feb 10, 2023 at 8:20 AM Clem Cole wrote: > > FYI: The sources to CDL are in the TUHS archives. > > On Fri, Feb 10, 2023 at 7:56 AM Douglas McIlroy > wrote: > > CDL was for designing wired circuit boards, not integrated > circuits.. > It was used to design the Datakit switch, the Belle chess > machine and > other hardware. > > I suspect the cited IC-design tool was one that Steve Johnson > created > for use in a short course that Carver Mead taught at Bell > Labs. I am > not aware that it saw use outside of that course. > > Doug > > On Fri, Feb 10, 2023 at 12:37 AM Christian Dreier via TUHS > wrote: > > > > Hello there, > > > > I recently watched an old Unix promotion video by AT&T on > YouTube (AT&T > > Archives: The UNIX Operating System: > https://youtu.be/tc4ROCJYbm0) and > > they mention a design tool for integrated circuits > (apparently named > > L-Gen or lgen; timestamped link: > https://youtu.be/tc4ROCJYbm0?t=1284). > > > > Part of this software is a language implemented with YACC > that appears > > to describe the behavior of digital logic, like modern hardware > > description languages, i.e. Verilog and VHDL. > > > > Does anyone have information about this, in particular: > > - Documentation > > - Which projects were realized with this? > > - Source code, if possible > > > > I asked this question on retrocomputing.stackexchange.com > (see > > https://retrocomputing.stackexchange.com/q/26301/26615) but > so far there > > is no satisfying answer. A "Circuit Design Language" (CDL) > is mentioned > > and there is some good information about it but it has > another syntax > > (as shown in the video vs. the documentation about CDL) and > apparently > > another purpose (description of board wiring vs. logic > behavior). > > > > Best regards, > > Christian > > -- > Sent from a handheld expect more typos than usual > -------------- next part -------------- An HTML attachment was scrubbed... URL: From srb at unixsh.com Sat Feb 11 02:44:09 2023 From: srb at unixsh.com (Steve) Date: Fri, 10 Feb 2023 11:44:09 -0500 Subject: [TUHS] CDL & UCDS Message-ID: <6af20c95-7b9f-8a06-b930-e1d8e74101d4@unixsh.com> Sandy wrote the original CDL tool set.  It had a graphical front end that provided for chips , pins, wires etc and generated a connectivity list which was then consumed by wire wrap and other back end tools.  We had Tek 4014 terminals at the time (late 70s is what I recall) which made all this reasonable. I took it over the code base at some point and among other things added macros so that repeated wire to chip connection patterns and names could be generated without the labor intensive one wire at a time e.g. wire[0-7] connects to pin[0-7].  The macro would be expanded so that wire0 connected to pin0 etc.  This later system was call UCDS - Unix Circuit Design System. UCDS was used by Joe Condon for the chess machine that he and Ken built.  Ken may remember more about this.  It was also one of the reasons that BTL got a $1B Navy contract. Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sat Feb 11 03:47:56 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 10 Feb 2023 17:47:56 +0000 Subject: [TUHS] UNIX Release 4 Findings In-Reply-To: References: <2XyFQMdNqMtF1Mr0uR7953_hlXtegijahATtyjqGWWCLPbLmDGDJMVneA7OOB9TeY1ww6N5b7cJy8u4ceemZqdumwM4jrlzmd0KDJQuVMXA=@protonmail.com> Message-ID: <7weCqnTEIBgsU9T-WuEz5AJvNsb13t44eGSWu7rG27IcoT6oDkEYg0kHi1NGb9fZzVDTsvVC3fOXXlyMevdLZeAcpvDooMtBPNJbb38XBBM=@protonmail.com> So as of this morning less progress report-y messaging going forward. Finally got access to the TUHS Wiki so I will be accumulating this and other info there, along with links to emails from the list illuminating various bits. Clem and I will hopefully be talking nomenclature soon and can get a better handle on not potentially misrepresenting anything. So without further ado, follow:https://wiki.tuhs.org/doku.php?id=systems:unixts4 Any updates will show up there. Eventually will re-slug it as something different, but the page slug still reflects the TS nomenclature. The thread referenced in the article aligns more with reality. Less email updates on discoveries going forward, you can probably RSS to the Wiki for any particular areas of interest. - Matt G. ------- Original Message ------- On Thursday, February 9th, 2023 at 8:58 PM, segaloco via TUHS wrote: > That's all the more reason to be precise, with all the uncertainty there is at least the fact that I can say this is what the documentarian in charge of the manual had approved to live in /usr/man/u_man on the particular box they had hooked up to the typesetter when they cut the plates that eventually printed the book I hold. No amount of printed material will ever capture reality, but it does give a darn good window into it in a more precise way. > > On the note of precision, to add fuel to the USG fire, there is also the USG Program Generic line, which has numbers distinct from this stuff too. So many branches... > > - Matt G. > > ------- Original Message ------- > On Thursday, February 9th, 2023 at 8:48 PM, George Michaelson ggm at algebras.org wrote: > > > > > I hesitate to throw this into the mix, but I would observe in those > > days, people were a bit less formal about release versions and I have > > a suspicion (but only a suspicion) that from time to time what shipped > > on a 1200bpi tape was not some canonical 'this is the release as of 3 > > months ago' but more 'this is a sh scripted product of the checked out > > state as I understood it, on the box I had available to me, to cut a > > tape. > > > > The tape had to have boot blocks up front. You got told to do mt fsf > > stuff. So.. I accept some of the tape structure was a bit more > > formally policed: giving people the wrong architecture and bootblocks > > would be bad. > > > > But when it comes to what was unpacked for runtime? I think it wasn't > > quite as 'reproducible build' formal as it is now, for some people. > > > > The version numbers were not mutable. What was stamped with them? > > Perhaps it was. > > > > G From stewart at serissa.com Sat Feb 11 05:08:55 2023 From: stewart at serissa.com (Lawrence Stewart) Date: Fri, 10 Feb 2023 14:08:55 -0500 Subject: [TUHS] Circuit design tool mentioned in AT&T Unix promotion In-Reply-To: References: <854dfba0-6cf2-57a4-3995-c57571205d1f@googlemail.com> Message-ID: CAD Tools FTW! When I started designing hardware at MIT in 1973 we had logic templates and drew on vellum with rapidograph pencils. Copies were made, and the wire-wrapper would color each line as it was wired. Sometime around 1974 the Architecture Machine Group acquired a CADD3 (IIRC) 2-D design system with its own minicomputer for which you could make 2D templates with connection points. This thing was so hard to use that I went back to logic templates and rapidographs for my senior thesis project. In the later ‘70s at PARC, Chuck Thacker had written SIL (Simple Illustrator) for the Alto, which is described in https://xeroxalto.computerhistory.org/Thacker-SIL-John_Wiley_and_Sons-1983.pdf Thacker-SIL-John_Wiley_and_Sons-1983 PDF Document · 346 KB SIL was easy to use, and easy to make new templates for, and it was used for all hardware designs at PARC. There was a tool flow that extracted wirelists and component locations and would automatically drive the “Stitchweld” machine to make prototypes. PC Boards I think were sent out to local Bay Area shops or possibly to Xerox El Segundo. As usual, PARC operated in near ignorance of what the Labs were doing, but it seems that these 2D cad tools and automated tool flows were a fairly parallel evolution. Later at Digital Western Research Lab there was yet another set of X windows based GUIs for logic, and associated simulators and wire list generators that the Digital research groups all used. No doubt Digital main engineering had all sorts of CAD but it was VMS based and no one in research used it. So it seems every group reinvented more or less the same suite of illustrators for logic design, with varying sets of tool flows. I didn’t know that BTL won a big contract partly on the strengh of the Unix tools though! That is entirely proper and awesome. Regarding IC Design, Carver Mead came to PARC for a while and collaborated with Lynn Conway. We started with red, green, and blue colored pencils for NMOS, but soon after someone wrote an Alto based layout program to directly draw mask layers. These were used for the first MOSIS runs. Somewhere in the cellar I have my carry-save adder chip :) -Larry -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: preview.png Type: image/png Size: 190088 bytes Desc: not available URL: From bakul at iitbombay.org Sat Feb 11 05:31:36 2023 From: bakul at iitbombay.org (Bakul Shah) Date: Fri, 10 Feb 2023 11:31:36 -0800 Subject: [TUHS] CDL & UCDS In-Reply-To: <6af20c95-7b9f-8a06-b930-e1d8e74101d4@unixsh.com> References: <6af20c95-7b9f-8a06-b930-e1d8e74101d4@unixsh.com> Message-ID: <35DBD3F6-12C1-4EDD-A546-AC3343329F7B@iitbombay.org> On Feb 10, 2023, at 8:44 AM, Steve wrote: > > I took it over the code base at some point and among other things added macros so that repeated wire to chip connection patterns and names could be generated without the labor intensive one wire at a time e.g. wire[0-7] connects to pin[0-7]. The macro would be expanded so that wire0 connected to pin0 etc. For specifying wirewrap lists compactly, at Fortune Systems we used some syntax Rob Warnock had picked up elsewhere. Basically lists in all angle brackets would expand in parallel and then lists in all square brackets. So for example U[0:1].P<3:0> = U[2:3].P<1,2,4:5> would expand as U0.P3 = U2.P1 U0.P2 = U2.P2 U0.P1 = U2.P4 ... U1.P0 = U3.P5 This turns out to be an interesting programming exercise. Its grammar is clearly not context-free because the number of items in all bracketed lists of give type and at a given level had to match. [Program for this also happened to be the first C program I wrote for pay -- and spent a week debugging because coming from Pascal I used "=" when I should've used "=="] -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry at henare.com Sat Feb 11 10:13:41 2023 From: henry at henare.com (Henry Mensch) Date: Fri, 10 Feb 2023 19:13:41 -0500 Subject: [TUHS] project athena (was Re: Setting up an X Development Environment for Mac OS) In-Reply-To: References: <3e272d72-b77a-d347-b5c3-7ed19482e5af@gmail.com> <3h5FEAegoTs6FrhHODiW-rBdB59dt_Rmr4G0PIw7flqaJLsmorgPsilm4f2aJkDud-qEljDjnCJcE1uY05Iw4HNQcyNG4W3wzVlLD0UZfLg=@protonmail.com> Message-ID: <1863dd20b08.2952.27ce34798ec5af9926fa49424fa0531c@henare.com> that would have happened before I arrived in April of 1986. my first job at Athena was to. get folks off those XTs and (mostly) ATs. This was wildly unsuccessful and unpopular because the replacement hardware wouldn't be similarly capable... and also because, even then, there were more things that could be plugged into XTs and ATs. The old platform was perceived as more versatile. - Henry On February 9, 2023 20:30:47 "Theodore Ts'o" wrote: > On Thu, Feb 09, 2023 at 09:12:28AM +1100, Jonathan Gray wrote: >> >> Before the PC/RT machines and AOS, there was also an attempt at PC/XT >> machines with Genix running on a add-in card. > > It's possible that there were some IBM'ers at MIT Building E40 (where > Project Athena was headquartered) that were playing with a PC/XT with > a co-processor board, but as far as I know that was never deployed in > the field --- at least, I never saw them. The only I saw were PC/AT's > (that is, the ones with the '286 CPU) that ran DOS and which were > essentially used only to telnet to the Vax 750's (or supdup to the MIT > AI / LCS lab machines, but most undergraduates didn't have access to > those computers; connecting to MIT Multics was also possible, via a > 3270 emulator, but again, most undergrduates didn't have access, > although MIT's Student Information Processing Board could give out > limited accounts for undergraduates to experiment with Multics.) > > - Ted From henry at henare.com Sat Feb 11 10:23:45 2023 From: henry at henare.com (Henry Mensch) Date: Fri, 10 Feb 2023 19:23:45 -0500 Subject: [TUHS] project athena (was Re: Setting up an X Development Environment for Mac OS) In-Reply-To: References: <3e272d72-b77a-d347-b5c3-7ed19482e5af@gmail.com> <3h5FEAegoTs6FrhHODiW-rBdB59dt_Rmr4G0PIw7flqaJLsmorgPsilm4f2aJkDud-qEljDjnCJcE1uY05Iw4HNQcyNG4W3wzVlLD0UZfLg=@protonmail.com> Message-ID: <1863ddb4268.2952.27ce34798ec5af9926fa49424fa0531c@henare.com> On February 8, 2023 17:12:50 Jonathan Gray wrote: > "IBM SHIPS XT'S WITH 16032 COPROCESSORS > > The project awaits the delivery of 80 IBM PC/ATs. These machines will > run XENIX" AFAIK, this (XENIX) never happened, except perhaps in a very rudimentsry way by someone evaluating things. The PC/ATs shipped with PGA graphics cards and PGA wasn't compatible with anything that wasn't IBM produced. it died just a few years later when VGA started to become a thing. From lm at mcvoy.com Sat Feb 11 10:53:22 2023 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 10 Feb 2023 16:53:22 -0800 Subject: [TUHS] project athena (was Re: Setting up an X Development Environment for Mac OS) In-Reply-To: <1863dd20b08.2952.27ce34798ec5af9926fa49424fa0531c@henare.com> References: <3e272d72-b77a-d347-b5c3-7ed19482e5af@gmail.com> <3h5FEAegoTs6FrhHODiW-rBdB59dt_Rmr4G0PIw7flqaJLsmorgPsilm4f2aJkDud-qEljDjnCJcE1uY05Iw4HNQcyNG4W3wzVlLD0UZfLg=@protonmail.com> <1863dd20b08.2952.27ce34798ec5af9926fa49424fa0531c@henare.com> Message-ID: <20230211005322.GF28037@mcvoy.com> On Fri, Feb 10, 2023 at 07:13:41PM -0500, Henry Mensch wrote: > that would have happened before I arrived in April of 1986. my first job at Athena was to. get folks off those XTs and (mostly) ATs. > > This was wildly unsuccessful and unpopular because the replacement hardware wouldn't be similarly capable... and also because, even then, there were more things that could be plugged into XTs and ATs. The old platform was perceived as more versatile. > > - Henry So the "old platform" was the National 32016 addon cards that somehow ran a Unix? I'd love to learn more about that, I really liked the 320xx architecture, seemed like a winner but my memory is they were buggy. Still would like to get some idea of what it was like to run on an XT/AT with that card plugged in. Did you boot DOS and that somehow booted Unix or what? --lm From jsg at jsg.id.au Sat Feb 11 13:51:55 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Sat, 11 Feb 2023 14:51:55 +1100 Subject: [TUHS] project athena (was Re: Setting up an X Development Environment for Mac OS) In-Reply-To: <20230211005322.GF28037@mcvoy.com> References: <3e272d72-b77a-d347-b5c3-7ed19482e5af@gmail.com> <3h5FEAegoTs6FrhHODiW-rBdB59dt_Rmr4G0PIw7flqaJLsmorgPsilm4f2aJkDud-qEljDjnCJcE1uY05Iw4HNQcyNG4W3wzVlLD0UZfLg=@protonmail.com> <1863dd20b08.2952.27ce34798ec5af9926fa49424fa0531c@henare.com> <20230211005322.GF28037@mcvoy.com> Message-ID: On Fri, Feb 10, 2023 at 04:53:22PM -0800, Larry McVoy wrote: > On Fri, Feb 10, 2023 at 07:13:41PM -0500, Henry Mensch wrote: > > that would have happened before I arrived in April of 1986. my first job at Athena was to. get folks off those XTs and (mostly) ATs. > > > > This was wildly unsuccessful and unpopular because the replacement hardware wouldn't be similarly capable... and also because, even then, there were more things that could be plugged into XTs and ATs. The old platform was perceived as more versatile. > > > > - Henry > > So the "old platform" was the National 32016 addon cards that somehow > ran a Unix? It seems that configuration wasn't used. "Phase I: The off-the-shelf system ... The closest approximation to the intended workstation environment economically feasible on available Digital hardware at the time the project began was minicomputer time-sharing systems. Approximately 50 VAX 11/750 minicomputers have been installed, each with six to eight graphics-capable terminals. ... The closest approximation to the eventual workstation configuration available in the IBM catalog for Phase I was the PC/AT personal computer, with a Professional Graphics Display and 3COM Ethernet interface. Approximately 160 PC/AT's have been installed. The software environment consists of PC/DOS, plus a set of higher level languages and application packages chosen to simplify moving to an eventual UNIX environment. In addition, 105 PC/XT personal computers, mostly with Color Graphics Display, have been installed, primarily for use as laboratory experiment controllers and also as cluster print servers for the PC/AT's." Evolution to the Athena Workstation Model: An Overview of the Development Plan http://web.mit.edu/saltzer/www/publications/athenaplan/d.pdf > > I'd love to learn more about that, I really liked the 320xx architecture, > seemed like a winner but my memory is they were buggy. Still would like > to get some idea of what it was like to run on an XT/AT with that card > plugged in. Did you boot DOS and that somehow booted Unix or what? > > --lm Multiple companies made these kinds of cards. Some are mentioned in an ad: https://archive.org/details/bitsavers_MiniMicroS_110087111/page/20/mode/2up http://www.cpu-ns32k.net/Defhard.html http://www.cpu-ns32k.net/Opus.html http://bitsavers.org/pdf/opusSystems/32k/800-00237-000_Opus_100pm_User_Manual_1987.pdf The DSI-32 Coprocessor Board, Part 1: The Hardware https://archive.org/details/BYTE_Vol_10-08_1985-08_The_Amiga/page/n127/mode/2up The DSI-32 Coprocessor Board, Part 2: The Software https://archive.org/details/byte-magazine-1985-09/page/n103/mode/2up From tuhs at tuhs.org Sat Feb 11 18:06:34 2023 From: tuhs at tuhs.org (Christian Dreier via TUHS) Date: Sat, 11 Feb 2023 09:06:34 +0100 Subject: [TUHS] Circuit design tool mentioned in AT&T Unix promotion In-Reply-To: References: <854dfba0-6cf2-57a4-3995-c57571205d1f@googlemail.com> Message-ID: <11602ca6-eca7-f4b1-7202-619d971557da@googlemail.com> Thanks for mentioning Carver Mead. After entering his name in Google, I stumbled across a paper "Introduction to VLSI Systems" by Lynn Conway and him. https://ai.eecs.umich.edu/people/conway/VLSI/VLSIText/PP-V2/V2.pdf This paper mentions a software "ICARUS" (Integrated Circuit ARtwork Utility System) that also appears to be a pioneering EDA tool. But clearly not the particular thing, I'm asking for and it is for Xerox computers. Hopefully, someone has some more information about this "L-Gen" software. :) Regards, Christian Am 10.02.23 um 13:56 schrieb Douglas McIlroy: > CDL was for designing wired circuit boards, not integrated circuits.. > It was used to design the Datakit switch, the Belle chess machine and > other hardware. > > I suspect the cited IC-design tool was one that Steve Johnson created > for use in a short course that Carver Mead taught at Bell Labs. I am > not aware that it saw use outside of that course. > > Doug > > On Fri, Feb 10, 2023 at 12:37 AM Christian Dreier via TUHS > wrote: >> >> Hello there, >> >> I recently watched an old Unix promotion video by AT&T on YouTube (AT&T >> Archives: The UNIX Operating System: https://youtu.be/tc4ROCJYbm0) and >> they mention a design tool for integrated circuits (apparently named >> L-Gen or lgen; timestamped link: https://youtu.be/tc4ROCJYbm0?t=1284). >> >> Part of this software is a language implemented with YACC that appears >> to describe the behavior of digital logic, like modern hardware >> description languages, i.e. Verilog and VHDL. >> >> Does anyone have information about this, in particular: >> - Documentation >> - Which projects were realized with this? >> - Source code, if possible >> >> I asked this question on retrocomputing.stackexchange.com (see >> https://retrocomputing.stackexchange.com/q/26301/26615) but so far there >> is no satisfying answer. A "Circuit Design Language" (CDL) is mentioned >> and there is some good information about it but it has another syntax >> (as shown in the video vs. the documentation about CDL) and apparently >> another purpose (description of board wiring vs. logic behavior). >> >> Best regards, >> Christian From lm at mcvoy.com Sun Feb 12 00:48:32 2023 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 11 Feb 2023 06:48:32 -0800 Subject: [TUHS] project athena (was Re: Setting up an X Development Environment for Mac OS) In-Reply-To: References: <3e272d72-b77a-d347-b5c3-7ed19482e5af@gmail.com> <3h5FEAegoTs6FrhHODiW-rBdB59dt_Rmr4G0PIw7flqaJLsmorgPsilm4f2aJkDud-qEljDjnCJcE1uY05Iw4HNQcyNG4W3wzVlLD0UZfLg=@protonmail.com> <1863dd20b08.2952.27ce34798ec5af9926fa49424fa0531c@henare.com> <20230211005322.GF28037@mcvoy.com> Message-ID: <20230211144832.GA6858@mcvoy.com> On Sat, Feb 11, 2023 at 02:51:55PM +1100, Jonathan Gray wrote: > http://bitsavers.org/pdf/opusSystems/32k/800-00237-000_Opus_100pm_User_Manual_1987.pdf That gave me the best "feel" for what it was like. Still would like to hear from someone that ran on this on a day to day basis. It looks pretty cool but either it happened a little too late for me (by 1987 I was working for Lachman porting Unix to the ETA-10 and I was running on Sun3/50 as my desktop and Sun3/260 as the file server) or I missed it. I owned an AT&T Unix PC in college (I think, or I used Rob Netzer's but I think we had 2 of them) and it would be interesting to know how the 320xx on an AT stacked up against that. From jsg at jsg.id.au Sun Feb 12 12:26:38 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Sun, 12 Feb 2023 13:26:38 +1100 Subject: [TUHS] project athena (was Re: Setting up an X Development Environment for Mac OS) In-Reply-To: <20230211144832.GA6858@mcvoy.com> References: <3e272d72-b77a-d347-b5c3-7ed19482e5af@gmail.com> <3h5FEAegoTs6FrhHODiW-rBdB59dt_Rmr4G0PIw7flqaJLsmorgPsilm4f2aJkDud-qEljDjnCJcE1uY05Iw4HNQcyNG4W3wzVlLD0UZfLg=@protonmail.com> <1863dd20b08.2952.27ce34798ec5af9926fa49424fa0531c@henare.com> <20230211005322.GF28037@mcvoy.com> <20230211144832.GA6858@mcvoy.com> Message-ID: On Sat, Feb 11, 2023 at 06:48:32AM -0800, Larry McVoy wrote: > On Sat, Feb 11, 2023 at 02:51:55PM +1100, Jonathan Gray wrote: > > http://bitsavers.org/pdf/opusSystems/32k/800-00237-000_Opus_100pm_User_Manual_1987.pdf > > That gave me the best "feel" for what it was like. Still would like to > hear from someone that ran on this on a day to day basis. It looks > pretty cool but either it happened a little too late for me (by 1987 > I was working for Lachman porting Unix to the ETA-10 and I was running > on Sun3/50 as my desktop and Sun3/260 as the file server) or I missed > it. Not sure when the Sritek 16032 card was announced. It was discussed in the June 1983 issue of Byte Sudha Kavuru Modular Architecture, Designing a modular computer around the IBM PC https://archive.org/details/byte-magazine-1983-06-rescan/page/n195/mode/2up and shown at the January 1984 UniForum: "Sritek manufactures high-performance coprocessors and advanced operating systems for the IBM PC and XT. The Xenix System 3.0 for the Sritek 68000 coprocessor offers paged-memory management which can support up to 16 users. For the 16032 coprocessor we offer the Berkeley 4.1 BSD which supports 32-bit demand-paged virtual memory management and floating-point hardware. We will soon offer the 4.2 BSD version with networking facilities. UNIX System V will be available on the 68000, 16032 and 80286 coprocessors during the second quarter of 1984." https://archive.org/details/1984-proceedings-uni-forum-dc/page/n30/mode/2up For the 68000 card, an interesting writeup is in the April 1983 issue of InfoWorld. Sritek cards were offered to both MIT and CMU while they were waiting for the RT PCs. "CMU will use Sritek coprocessor boards Sritek, of Cleveland, Ohio, and Carnegie-Mellon University, located in Pittsburgh, Pennsylvania, have agreed that Sritek will supply the university with several hundred of its 68000 coprocessor boards with XENIX software for the IBM PC XT. According to a Carnegie-Mellon spokesman, the school will use the enhanced computer as a transition work station until its new system, under development in cooperation with IBM, is ready. The university and IBM are working on a 32-bit microcomputer with one megabyte of RAM and high-resolution bit-mapped graphics that will be used in a campus network of 7500 work stations. The machine is not expected to be ready until 1991, however. CMU also plans to offer the enhanced IBM XT to faculty, students and CMU employees for purchase at a discount. Sritek hardware will be included in this plan." From arnold at skeeve.com Sun Feb 12 17:20:48 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 12 Feb 2023 00:20:48 -0700 Subject: [TUHS] CDL & UCDS In-Reply-To: <6af20c95-7b9f-8a06-b930-e1d8e74101d4@unixsh.com> References: <6af20c95-7b9f-8a06-b930-e1d8e74101d4@unixsh.com> Message-ID: <202302120720.31C7Km0C032250@freefriends.org> Steve wrote: > UCDS was used by Joe Condon for the chess machine that he and Ken built.  Ken may remember more > about this.  It was also one of the reasons that BTL got a $1B Navy contract. This sounds like an interesting story. Can you give more details? Thanks, Arnold From jsg at jsg.id.au Mon Feb 13 00:05:31 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Mon, 13 Feb 2023 01:05:31 +1100 Subject: [TUHS] Cadmus CadMac Toolbox Message-ID: I found mention of Cadmus CadMac Toolbox/PCSMac when reading more about the RT PC. It is interesting that this would later be sold to Apple. Something not often mentioned in histories of PCS, Cadmus Computer Systems or Apple. "Cadmus Computer Systems had created the CadMac Toolbox, a Macintosh Toolbox implemented in C on a UNIX base), and under a special agreement with Cadmus, we received a license to port the CadMac code from their hardware base to the RT" Norman Meyrowitz - Intermedia: The Architecture and Construction of an Object-Oriented Hypermedia System and Applications Framework https://dl.acm.org/doi/10.1145/28697.28716 A video presentation of Intermedia and CadMac running on IBM ACIS' port of 4.2BSD for the RT PC, with kernel changes https://vimeo.com/20578352 they later moved to A/UX on the Macintosh II InfoWorld 13 Jun 1988 https://books.google.com/books?id=-T4EAAAAMBAJ&pg=PT11 'Meyrowitz: It was before Apple Unix. There was a workstation company called Cadmus that was producing workstations largely for CAD and Tom Stambaugh took the Macintosh APIs and reprogrammed them to run on Unix workstations. We went up to Cadmus and convinced them to license that to us for the university. We were using Mac APIs on Unix systems because we wanted systems that supported the network file system, that had virtual memory, that had bigger disks. So we did that and it was a beautiful system. Eventually, convinced Apple to create a A/UX [Apple Unix] which was a Unix system and we ran on that. Cadmus went out of business, and we had the only license to CadMac, and Apple wasn't that happy to have it around. We had actually convinced them that they should release it to universities, because having that API around, especially if they could sell it to other companies to put it on their workstations, could actually be lucrative. We almost convinced them to do that. We were actually having a celebratory dinner at McArthur Park in Palo Alto to celebrate this and then Jean-Louis Gassée walked in and said, "The deal is off."' Oral History of Norman Meyrowitz http://archive.computerhistory.org/resources/access/text/2015/05/102658326-05-01-acc.pdf "we chose the Apple Macintosh front-end, or rather our local version thereof (CadMac, now PCSMac) which was available on the Cadmus 9000 computers." https://quod.lib.umich.edu/cgi/p/pod/dod-idx/development-of-an-intelligent-composers-assistant.pdf?c=icmc;idno=bbp2372.1986.029;format=pdf "Apple Workstation Efforts Get Boost from Cadmus Although Apple Computer Inc, won't say so, industry analysts believe the company's acquisition of software technology from Unix workstation maker Cadmus Computer Systems may speed up the introduction of high-end Unix workstations from Apple. ... At Apple's analysts' meeting April 23, chairman John Sculley said Apple had acquired the rights to the technology from Cadmus of Lowell, Massachusetts, to use in long-term advanced product development efforts for the Macintosh. He said the Cadmus software would help the company develop a workstation for the engineering community and federal government markets, which use Unix-based systems, according to Apple's transcripts. Although Sculley has not detailed what Apple will do with the Cadmus technology, Cadmus introduced last summer a graphics workstation equipped with Cadmac, a graphics environment that is compatible with Apple's Macintosh graphics routines." InfoWorld 19 May 1986 https://books.google.com/books?id=SS8EAAAAMBAJ&pg=PA3 From henry at henare.com Mon Feb 13 07:35:19 2023 From: henry at henare.com (Henry Mensch) Date: Sun, 12 Feb 2023 16:35:19 -0500 Subject: [TUHS] project athena (was Re: Setting up an X Development Environment for Mac OS) In-Reply-To: <20230211144832.GA6858@mcvoy.com> References: <3e272d72-b77a-d347-b5c3-7ed19482e5af@gmail.com> <3h5FEAegoTs6FrhHODiW-rBdB59dt_Rmr4G0PIw7flqaJLsmorgPsilm4f2aJkDud-qEljDjnCJcE1uY05Iw4HNQcyNG4W3wzVlLD0UZfLg=@protonmail.com> <1863dd20b08.2952.27ce34798ec5af9926fa49424fa0531c@henare.com> <20230211005322.GF28037@mcvoy.com> <20230211144832.GA6858@mcvoy.com> Message-ID: <185a01d93f29$e893a720$b9baf560$@henare.com> I don't think you will find that. These systems were, pretty much, out in the world and not particularly managed by anyone except the people who were using them (largely educators and researchers). While the PC/ATs were deployed by Project Athena, they were not managed. By the time I landed there the RT devices were the focus of future activity since they more closely fit into the plan and folks like Ted were in a better position to do what was needed to build a platform that was uniform. -----Original Message----- From: Larry McVoy Sent: 11 February 2023 09:49 To: Jonathan Gray Cc: Larry McVoy ; Henry Mensch ; Theodore Ts'o ; tuhs at tuhs.org Subject: Re: [TUHS] Re: project athena (was Re: Setting up an X Development Environment for Mac OS) On Sat, Feb 11, 2023 at 02:51:55PM +1100, Jonathan Gray wrote: > http://bitsavers.org/pdf/opusSystems/32k/800-00237-000_Opus_100pm_User > _Manual_1987.pdf That gave me the best "feel" for what it was like. Still would like to hear from someone that ran on this on a day to day basis. It looks pretty cool but either it happened a little too late for me (by 1987 I was working for Lachman porting Unix to the ETA-10 and I was running on Sun3/50 as my desktop and Sun3/260 as the file server) or I missed it. I owned an AT&T Unix PC in college (I think, or I used Rob Netzer's but I think we had 2 of them) and it would be interesting to know how the 320xx on an AT stacked up against that. From tuhs at tuhs.org Mon Feb 13 19:22:43 2023 From: tuhs at tuhs.org (Christian Dreier via TUHS) Date: Mon, 13 Feb 2023 10:22:43 +0100 Subject: [TUHS] Circuit design tool mentioned in AT&T Unix promotion In-Reply-To: <854dfba0-6cf2-57a4-3995-c57571205d1f@googlemail.com> References: <854dfba0-6cf2-57a4-3995-c57571205d1f@googlemail.com> Message-ID: Hello Steven, I have questions about a logic design tool mentioned in an old Unix promotion by AT&T and apparently presented by you. Do you have some information about this software? See below for further details about my question. See also TUHS mailing list: https://minnie.tuhs.org/pipermail/tuhs/2023-February/thread.html#27724 Best regards, Christian Am 10.02.23 um 06:36 schrieb Christian Dreier: > Hello there, > > I recently watched an old Unix promotion video by AT&T on YouTube (AT&T > Archives: The UNIX Operating System: https://youtu.be/tc4ROCJYbm0) and > they mention a design tool for integrated circuits (apparently named > L-Gen or lgen; timestamped link: https://youtu.be/tc4ROCJYbm0?t=1284). > > Part of this software is a language implemented with YACC that appears > to describe the behavior of digital logic, like modern hardware > description languages, i.e. Verilog and VHDL. > > Does anyone have information about this, in particular: > - Documentation > - Which projects were realized with this? > - Source code, if possible > > I asked this question on retrocomputing.stackexchange.com (see > https://retrocomputing.stackexchange.com/q/26301/26615) but so far there > is no satisfying answer. A "Circuit Design Language" (CDL) is mentioned > and there is some good information about it but it has another syntax > (as shown in the video vs. the documentation about CDL) and apparently > another purpose (description of board wiring vs. logic behavior). > > Best regards, > Christian From ken.unix.guy at gmail.com Fri Feb 17 00:13:37 2023 From: ken.unix.guy at gmail.com (KenUnix) Date: Thu, 16 Feb 2023 09:13:37 -0500 Subject: [TUHS] Unix V7 updates Message-ID: I was wondering if there are any fixes for Unix V7 to use years beyond 2000? -- WWL 📚 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.unix.guy at gmail.com Fri Feb 17 00:24:57 2023 From: ken.unix.guy at gmail.com (KenUnix) Date: Thu, 16 Feb 2023 09:24:57 -0500 Subject: [TUHS] 'more' command for Unix V7 Message-ID: Here is a simplified 'more' command for Unix V7: /********************************************************************* * UNIX pager (v7 compatible) Chipmaster and KenUnix * * cc -o more more.c * * Usage examples: * man wall | more * more xyz * more abc def xyz * * Started February 15th, 2023 YeOlPiShack.net * * This is the ultimately dumbest version of more I have experienced. * Its main purpose is to illustrate the use of /dev/tty to interact * with the user while in a filter role (stdin -> stdout). This also * leaves stderr clear for actual errors. * * * NOTES on Antiquity: * * - The early C syntax didn't allow for combining type information * in the parenthesized argument list only the names were listed. * Then a "variable" list followed the () and preceded the { that * declared the types for the argument list. * * - There is no "void", specifically there is no distinction * between a function that returns an int or nothing at all. * * - Many of the modern day header files aren't there. * * - Apparently "/dev/tty" couldn't be opened for both reading and * writing on the same FD... at least not in our VM. * * - Apparently \a wasn't defined yet either. So I use the raw code * \007. * * - Modern compilers gripe if you do an assignment and comparison in * the same statement without enclosing the assignment in (). The * original compilers did not. So if it looks like there are too * many ()s it's to appease the modern compiler gods. * * - I'm not sure where they hid errno if there was one. I'd think * there had to be. Maybe Kernighan or Pike knows... * *********************************************************************/ #include /*** Let's make some assumptions about our terminal columns and lines. ***/ #define T_COLS 80 #define T_LINES 24 /*** Let's set up our global working environment ***/ FILE *cin; /* TTY (in) */ FILE *cout; /* | (out) */ int ct = 0; /*** message to stderr and exit with failure code ***/ err(msg) char *msg; { fputs(msg, stderr); exit(1); } /*** A poor man's CLear Screen *** * * Yup! This is how they used to do it, so says THE Kenrighan & Pike! * termcap?!?! What's that? */ cls() { int x; for(x=0; x1) { er = 0; for(x=1; x2) { if(!er) cls(); er = 0; /* remember all user interaction is on /dev/tty (cin/cout) */ fprintf(cout, ">>> %s <<<\n", argv[x]); pause(); } /* - is tradition for stdin */ if(strcmp("-", argv[x])==0) { pg(stdin); /* it must be a file! */ } else if((in=fopen(argv[x], "r"))) { pg(in); fclose(in); } else { /* errors go on stderr... JIC someone want to log */ fprintf(stderr, "Could not open '%s'!\n", argv[x]); fflush(stderr); er = 1; /* this prevents cls() above. */ } } /*** no args - read and page stdin ***/ } else { pg(stdin); } return 0; } End... -- WWL 📚 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hellwig.geisse at mni.thm.de Fri Feb 17 01:06:15 2023 From: hellwig.geisse at mni.thm.de (Hellwig Geisse) Date: Thu, 16 Feb 2023 16:06:15 +0100 Subject: [TUHS] 'more' command for Unix V7 In-Reply-To: References: Message-ID: <1676559975.2425.172.camel@mni.thm.de> On Do, 2023-02-16 at 09:24 -0500, KenUnix wrote: > >  *   - I'm not sure where they hid errno if there was one. I'd think >  *     there had to be. Maybe Kernighan or Pike knows... It's a .comm variable, as you can see, e.g., in /usr/src/libc/crt/cerror.s in Keith Bostic's V7. Hellwig From ken.unix.guy at gmail.com Fri Feb 17 01:08:34 2023 From: ken.unix.guy at gmail.com (KenUnix) Date: Thu, 16 Feb 2023 10:08:34 -0500 Subject: [TUHS] 'more' typo Message-ID: In 'more.c' there is a typo Line 154 replace fprnntf(stderr, "Could not open '%s'!\n", argv[x]); with fprintf(stderr, "Could not open '%s'!\n", argv[x]); -- WWL 📚 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.unix.guy at gmail.com Fri Feb 17 01:23:04 2023 From: ken.unix.guy at gmail.com (KenUnix) Date: Thu, 16 Feb 2023 10:23:04 -0500 Subject: [TUHS] 'more' command for Unix V7 In-Reply-To: <1676559975.2425.172.camel@mni.thm.de> References: <1676559975.2425.172.camel@mni.thm.de> Message-ID: Helwig, $ cd /usr/src $ ls -al total 2 drwxrwxr-x 2 bin 224 Sep 25 1980 . drwxr-xr-x 17 root 304 Feb 15 19:30 .. $ These are the disks I am using Interdata Unix V7 iu7_dp0.dsk 10MB disk image containing / and /usr iu7_dp1.dsk 10MB disk for swap and /tmp Both dated 23 Feb, 2003. If there is a better set let me know. I could not get Unix V7 to run under PDP-11 so I am using Interdata-32. Thanks On Thu, Feb 16, 2023 at 10:06 AM Hellwig Geisse wrote: > On Do, 2023-02-16 at 09:24 -0500, KenUnix wrote: > > > > * - I'm not sure where they hid errno if there was one. I'd think > > * there had to be. Maybe Kernighan or Pike knows... > > It's a .comm variable, as you can see, e.g., in > /usr/src/libc/crt/cerror.s in Keith Bostic's V7. > > Hellwig > -- End of line JOB TERMINATED -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Fri Feb 17 01:36:23 2023 From: imp at bsdimp.com (Warner Losh) Date: Thu, 16 Feb 2023 08:36:23 -0700 Subject: [TUHS] Unix V7 updates In-Reply-To: References: Message-ID: Several different people have made them. I grabbed V7 date and added the canonical hack to have years < 70 be 20xx and built it on my Venix box. I've not done an extensive audit, but it's the only thing I've noticed. Warner P.S. It's short: commit 25485e099491fd1ae867c26043a798e47f7983ad Author: Warner Losh Date: Thu Nov 15 23:51:59 2018 -0700 Apply Y2K fix to date Treat all two digit dates < 70 as 20xx and >= 70 as 19xx. diff --git a/src/cmd/date.c b/src/cmd/date.c index a005765..643f7e7 100644 --- a/src/cmd/date.c +++ b/src/cmd/date.c @@ -133,7 +133,10 @@ gtime() if (hour<0 || hour>23) return(1); timbuf = 0; - year += 1900; + if (year < 70) + year += 2000; + else + year += 1900; for(i=1970; i wrote: > I was wondering if there are any fixes for Unix V7 to > use years beyond 2000? > > -- > WWL 📚 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hellwig.geisse at mni.thm.de Fri Feb 17 02:20:40 2023 From: hellwig.geisse at mni.thm.de (Hellwig Geisse) Date: Thu, 16 Feb 2023 17:20:40 +0100 Subject: [TUHS] 'more' command for Unix V7 In-Reply-To: References: <1676559975.2425.172.camel@mni.thm.de> Message-ID: <1676564440.2425.199.camel@mni.thm.de> Ken, years ago, when I ported V7 to my own microprocessor ECO32, I wanted to have a stable reference running on a (simulated) PDP-11 in order to better understand some difficult corners of the original implementation. The set of files I used can be found here (and the archive's docs say "This set of files from Keith Bostic looks like the original tape records from the 7th Edition distribution tape."): https://www.tuhs.org/Archive/Distributions/Research/Keith_Bostic_v7/ I had a few minor difficulties to get it running in simh, mostly centered around the tape format and the configuration of the simulator, but finally I was able to install V7 exactly as advised in the manual ("Setting Up UNIX"). I packaged the whole adventure (original files, simh, scripts) together with a HOWTO: https://homepages.thm.de/~hg53/pdp11-unix/ On this site, you can also find all files extracted from the V7 file system to the host (Linux in my case). If you have questions, I will be glad to help. Hellwig From ken.unix.guy at gmail.com Fri Feb 17 10:19:23 2023 From: ken.unix.guy at gmail.com (KenUnix) Date: Thu, 16 Feb 2023 19:19:23 -0500 Subject: [TUHS] 'more' command for Unix V7 In-Reply-To: <1676564440.2425.199.camel@mni.thm.de> References: <1676559975.2425.172.camel@mni.thm.de> <1676564440.2425.199.camel@mni.thm.de> Message-ID: I am stuck here: PDP-11 simulator V3.6-0 Disabling XQ PDP-11 simulator configuration CPU, 11/45, FPP, autoconfiguration on, 256KB SYSTEM RHA, address=17776700-17776753, vector=254 RHB, disabled PTR, address=17777550-17777553, vector=70, not attached PTP, address=17777554-17777557, vector=74, not attached TTI, address=17777560-17777563, vector=60, 7b TTO, address=17777564-17777567, vector=64, 7b CR, address=17777160-17777167, vector=230, 285 cards per minute, translation 029, not attached, CR11, auto EOF, unknown format LPT, address=17777514-17777517, vector=200, not attached CLK, 60Hz, address=17777546-17777547, vector=100 PCLK, disabled DZ, address=17760100-17760137*, vector=300-334, lines=32, not attached, 8b VH, address=17760500-17760577*, vector=340-374, lines=32, 4 units VH0, not attached, DHU mode VH1, not attached, DHU mode VH2, not attached, DHU mode VH3, not attached, DHU mode RK, address=17777400-17777417, vector=220, 8 units RK0, 1247KW, not attached, write enabled RK1, 1247KW, not attached, write enabled RK2, 1247KW, not attached, write enabled RK3, 1247KW, not attached, write enabled RK4, 1247KW, not attached, write enabled RK5, 1247KW, not attached, write enabled RK6, 1247KW, not attached, write enabled RK7, 1247KW, not attached, write enabled RL, address=17774400-17774411, vector=160, 4 units RL0, 2621KW, not attached, write enabled, autosize RL1, 2621KW, not attached, write enabled, autosize RL2, 2621KW, not attached, write enabled, autosize RL3, 2621KW, not attached, write enabled, autosize HK, address=17777440-17777477, vector=210, 8 units HK0, 6944KW, not attached, write enabled, autosize HK1, 6944KW, not attached, write enabled, autosize HK2, 6944KW, not attached, write enabled, autosize HK3, 6944KW, not attached, write enabled, autosize HK4, 6944KW, not attached, write enabled, autosize HK5, 6944KW, not attached, write enabled, autosize HK6, 6944KW, not attached, write enabled, autosize HK7, 6944KW, not attached, write enabled, autosize RX, address=17777170-17777173*, vector=264, 2 units RX0, 256KB, not attached, write enabled RX1, 256KB, not attached, write enabled RY, disabled RP, Massbus adapter 0, 8 units RP0, 43MW, attached to system.hp, write enabled, RP04 RP1, 33MW, not attached, write enabled, autosize RP2, 33MW, not attached, write enabled, autosize RP3, 33MW, not attached, write enabled, autosize RP4, 33MW, not attached, write enabled, autosize RP5, 33MW, not attached, write enabled, autosize RP6, 33MW, not attached, write enabled, autosize RP7, 33MW, not attached, write enabled, autosize RQ, address=17772150-17772153*, no vector, 4 units RQ0, 159MB, not attached, write enabled, RD54 RQ1, 159MB, not attached, write enabled, RD54 RQ2, 159MB, not attached, write enabled, RD54 RQ3, 409KB, not attached, write enabled, RX50 RQB, disabled RQC, disabled RQD, disabled TC, disabled TM, address=17772520-17772533, vector=224, 8 units TM0, attached to unix_v7.tm, write locked, SIMH format, unlimited capacity TM1, not attached, write enabled, SIMH format, unlimited capacity TM2, not attached, write enabled, SIMH format, unlimited capacity TM3, not attached, write enabled, SIMH format, unlimited capacity TM4, not attached, write enabled, SIMH format, unlimited capacity TM5, not attached, write enabled, SIMH format, unlimited capacity TM6, not attached, write enabled, SIMH format, unlimited capacity TM7, not attached, write enabled, SIMH format, unlimited capacity TS, disabled TQ, TK50 (94MB), address=17774500-17774503, no vector, 4 units TQ0, not attached, write enabled, SIMH format TQ1, not attached, write enabled, SIMH format TQ2, not attached, write enabled, SIMH format TQ3, not attached, write enabled, SIMH format TU, disabled XQ, disabled XQB, disabled XU, disabled XUB, disabled 100000: 012700 100002: 172526 100004: 010040 100006: 012740 100010: 060003 100012: 000777 sim> run 100000 Simulation stopped, PC: 100012 (BR 100012) sim> run 0 Boot : tm(0,4) Tape? tm(0,5) Disk? hp(0,0) Last chance before scribbling on disk. Out of space <==== Exit called Boot : Simulation stopped, PC: 010762 (BEQ 10754) sim> run 0 <==== HALT instruction, PC: 000174 (HALT) sim> run 100000 <==== HALT instruction, PC: 100002 (HALT) sim> Ken On Thu, Feb 16, 2023 at 11:20 AM Hellwig Geisse wrote: > Ken, > > years ago, when I ported V7 to my own microprocessor ECO32, > I wanted to have a stable reference running on a (simulated) > PDP-11 in order to better understand some difficult corners > of the original implementation. The set of files I used can > be found here (and the archive's docs say "This set of files > from Keith Bostic looks like the original tape records from > the 7th Edition distribution tape."): > > https://www.tuhs.org/Archive/Distributions/Research/Keith_Bostic_v7/ > > I had a few minor difficulties to get it running in simh, > mostly centered around the tape format and the configuration > of the simulator, but finally I was able to install V7 exactly > as advised in the manual ("Setting Up UNIX"). I packaged the > whole adventure (original files, simh, scripts) together with > a HOWTO: > > https://homepages.thm.de/~hg53/pdp11-unix/ > > On this site, you can also find all files extracted from the > V7 file system to the host (Linux in my case). > > If you have questions, I will be glad to help. > > Hellwig > > -- End of line JOB TERMINATED -------------- next part -------------- An HTML attachment was scrubbed... URL: From hellwig.geisse at mni.thm.de Fri Feb 17 16:55:41 2023 From: hellwig.geisse at mni.thm.de (Hellwig Geisse) Date: Fri, 17 Feb 2023 07:55:41 +0100 Subject: [TUHS] 'more' command for Unix V7 In-Reply-To: References: <1676559975.2425.172.camel@mni.thm.de> <1676564440.2425.199.camel@mni.thm.de> Message-ID: <1676616941.2425.214.camel@mni.thm.de> On Do, 2023-02-16 at 19:19 -0500, KenUnix wrote: > I am stuck here: > > PDP-11 simulator V3.6-0 > Disabling XQ > PDP-11 simulator configuration > [...] > Simulation stopped, PC: 100012 (BR 100012) > sim> run 0 > Boot > : tm(0,4) > Tape? tm(0,5) > Disk? hp(0,0) > Last chance before scribbling on disk.  > Out of space  <==== > Exit called You skipped step 5 from the manual, which runs mkfs. Without an empty file system, trying restor (": tm(0,4)") is bound to fail. I suggest continuing our mail exchange off-list, if you don't mind. The old hands here don't need any further discussion of boot procedures... ;-) Hellwig From tuhs at tuhs.org Mon Feb 20 07:31:58 2023 From: tuhs at tuhs.org (Christian Dreier via TUHS) Date: Sun, 19 Feb 2023 22:31:58 +0100 Subject: [TUHS] Circuit design tool mentioned in AT&T Unix promotion In-Reply-To: <854dfba0-6cf2-57a4-3995-c57571205d1f@googlemail.com> References: <854dfba0-6cf2-57a4-3995-c57571205d1f@googlemail.com> Message-ID: I got an answer from Steve Johnson himself. He didn't keep up with the TUHS mailing list and is not sure whether he could post here currently -- so he asked me to post his answer here. He wrote an outline of what he remembers. Without some archived data from 40 years ago, this might be all, which could be known about this "L-Gen" tool. Thank you, Steve! Steve Johnson's answer >>>>> The Bell Labs Mead Conway Course Steve Johnson In the early 1980’s, semiconductor technology was a very hot topic. At that time I was a department head and recruited at CalTech, where Carver Mead taught a class that allowed students to design nMOS chips and get them fabricated and then test the hardware. My boss, Sandy Fraser, had a lot of hardware experience, and many of us were curious to see what this new chip technology could make possible. After some negotiation, Carver agreed to visit the labs for 6 weeks and teach the class. Sandy pulled some strings and negotiated some aid from the AT&T chip makers. We would design a wafer with multiple different designs, and then the wafer would be sliced apart and each of us would get a few (3-5) chips they designed. Having written the portable C compiler, and also one of the more enthusiastic supporters of this visit, I found myself “nominated” to write the software to support the design. We had just got our first VAX computer, which seemed to be powerful enough to support a dozen or so designers. I had about six weeks to throw together the software to support the chip design class. To our surprise, there were roughly 30 people who signed up for the class. So, what kind of design should we provide. The Mead/Conway “method” involved laying out the chip by hand following certain design rules. There were three kinds of wires: red, green, and black. The red and green wires were special: if a red wire crossed over a green wire, it made a transistor. The black wires carried the power and some of the data signals. In addition to the transistors, there were Vias – these allowed signals to cross between the red, green and black layers. The whole circuit was included in a “box” made up of pads, where the circuit would be connected to the pins of the fabricated chip. There were also design rules. Transistors cannot be to close to other transistors or vias. To make logic circuits we needed to provide voltage and ground using the black wires. The whole circuit was designed on graph paper. It quickly became clear to me that the design language should, as much as possible, hide the design rules so we could concentrate on the geometry. So the design language allowed you to define transistors and vias, and connect the wires to one of the four sides of the transistors or vias or pads. I don’t remember the exact syntax, but the design was a series of statements. Some statements defined names of transistors or vias or pads, without saying how they were connected. Then the heart of the language was doing the interconnections. The active elements had connection points U, D, L or R (for up, down, left, right). If V was a via, we might connect it to a transistor T by writing something like T.RU = V.D Which connected the right port of the transistor T with a wire that goes to the right and then up, and is connected to the down port of the via. Then the program would determine from the design rules how long the wire needed to go to the right and then upwards to hit V. The design language also allowed you to design functional blocks like adders and treat them the same way as the builtin basic elements. The design compiler became an exercise in finding the smallest layout that satisfies all the design rules. There were a variety of quirks that needed to be handled, especially regarding power and ground. When transcribing a design with a few hundred wires it was remarkably easy to confuse left and right or up and down when describing the wire. This led to a cycle that could not be satisfied. To salvage something, hopefully, when there was a cycle, I deleted one of the constraints in the cycle, and tried again. Unfortunately, if the cycle had, say, 6 constraints I had less than a 20% chance of removing the bad one. So a large design with a single flaw could collapse into a murky mudball of elements with occasional wires and transistors sticking out of it. It was most demoralizing. To add to the problems, when our VAX was delivered, apparently at some point something rolled over one of the cables, creating an intermittent fault. So for the first two weeks the VAX would take a very long time to get through all the designs. A frantic week’s work allowed me to package the design rule checker to draw a map of part of the circuit in 24x80 characters. You could zoom in to the site of the design rule error with a few keystrokes. It quickly became the preferred way to design. I remember giving a talk at MIT about the language and the design rule checker that was well received, but I doubt that it was recorded. We produced, I think, 5 multiproject chips, roughly 2 a year. A sixth try was a failure: I had changed the checker to describe the elements by its center rather than the edges, which sped up the checker quite a bit. But when the design went to fab, the guy who usually checked the design for sanity was unavailable and the flaw was missed. Some very interesting chips were produced in the course. Dave Ditzel implemented some ideas in silicon that later showed up in the AT&T Hobbit chip. There were also several network chips. For the third chip, I implemented a real silicon compiler. You could write a logic expression and it would compile it and produce output that could be used in the design. I generated a circuit that could take 16 binary inputs and produce the signals to drive five numerical outputs—a binary to decimal converter. The logic was complicated, but the program laid it out and the chip worked. There were two reasons why the Silicon impulse petered out, in my opinion. One was, we didn’t have a good way to install the chips into any of the computers running Unix. And, if we had managed to do it, the chip would have to have some notion of which process it should respond to — it got complicated… For me personally, I realized that the next step would be to dive into the physics of the system, and I had just accepted a transfer to the AT&T computer company spinoff, managing the language products for System V. This included the portable C compiler, the first commercial C++ compiler, Ada, FORTRAN and Pascal, and a debugger that worked with all of these, so I had my hands full with that. <<<<< Am 10.02.23 um 06:36 schrieb Christian Dreier: > Hello there, > > I recently watched an old Unix promotion video by AT&T on YouTube (AT&T > Archives: The UNIX Operating System: https://youtu.be/tc4ROCJYbm0) and > they mention a design tool for integrated circuits (apparently named > L-Gen or lgen; timestamped link: https://youtu.be/tc4ROCJYbm0?t=1284). > > Part of this software is a language implemented with YACC that appears > to describe the behavior of digital logic, like modern hardware > description languages, i.e. Verilog and VHDL. > > Does anyone have information about this, in particular: > - Documentation > - Which projects were realized with this? > - Source code, if possible > > I asked this question on retrocomputing.stackexchange.com (see > https://retrocomputing.stackexchange.com/q/26301/26615) but so far there > is no satisfying answer. A "Circuit Design Language" (CDL) is mentioned > and there is some good information about it but it has another syntax > (as shown in the video vs. the documentation about CDL) and apparently > another purpose (description of board wiring vs. logic behavior). > > Best regards, > Christian From ken.unix.guy at gmail.com Mon Feb 20 10:01:18 2023 From: ken.unix.guy at gmail.com (KenUnix) Date: Sun, 19 Feb 2023 19:01:18 -0500 Subject: [TUHS] Unix V7 Questions booting and date/time Message-ID: Was an upgrade for ethernet TCP/IP for Unix V7 ever done when running under SIMH? Was an upgrade ever done for Unix V7 when running under SIMH to read and set the date/time? I have a work around but it doesn't work because when running the sim it inserts boot code then when the 'run 2002' is issued further startup commands in the 'conf' file are ignored. System was built from unix_v7.tm dated 20 June 2006. run.conf contents: echo echo Unix V7 startup 2-19-2023 KenUnix echo set cpu 11/45 set cpu 256k set rp0 rp04 attach rp0 system.hp d cpu 2000 042102 d cpu 2002 012706 d cpu 2004 002000 d cpu 2006 012700 d cpu 2010 000000 d cpu 2012 012701 d cpu 2014 176700 d cpu 2016 012761 d cpu 2020 000040 d cpu 2022 000010 d cpu 2024 010061 d cpu 2026 000010 d cpu 2030 012711 d cpu 2032 000021 d cpu 2034 012761 d cpu 2036 010000 d cpu 2040 000032 d cpu 2042 012761 d cpu 2044 177000 d cpu 2046 000002 d cpu 2050 005061 d cpu 2052 000004 d cpu 2054 005061 d cpu 2056 000006 d cpu 2060 005061 d cpu 2062 000034 d cpu 2064 012711 d cpu 2066 000071 d cpu 2070 105711 d cpu 2072 100376 d cpu 2074 005002 d cpu 2076 005003 d cpu 2100 012704 d cpu 2102 002020 d cpu 2104 005005 d cpu 2106 105011 d cpu 2110 005007 echo echo To boot type boot enter then hp(0,0)unix enter after 'mem =' press ctrl-d echo To cancel press ctrl-e then at sim> type exit enter echo At login: type root enter at password type root enter echo To shutdown sync;sync wait 5 then press ctrl-e then at sim> type exit enter echo echo Copy / paste date at # echo DATE 2302191116 run 2002 Thanks, Ken/-- WWL 📚 -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Mon Feb 20 10:36:59 2023 From: clemc at ccc.com (Clem Cole) Date: Sun, 19 Feb 2023 19:36:59 -0500 Subject: [TUHS] Unix V7 Questions booting and date/time In-Reply-To: References: Message-ID: On Sun, Feb 19, 2023 at 7:01 PM KenUnix wrote: > Was an upgrade for ethernet TCP/IP for Unix V7 ever > done when running under SIMH? > Yes, the BSD 2.9/10/11 stream include the UCB Networking stack - it runs just fine on SIMH. In fact one Oscar's PiDP-11 [which used simh for the simulator] its one of the systems that is automatically loaded. > > Was an upgrade ever done for Unix V7 when running > under SIMH to read and set the date/time? > Where would you read the clock? SIMH emulates real HW - V7 was distributed for DEC HW through 1979 on the 11 and DEC had nothing. That said, could you create something sure - I bet you could. Maybe the easiest way would be to use a virtual DL/DC/DZ/DH serial port and have V7 read the clock from a 'serial line.' when it boots. Then set up a process on the SIMH Host system to source the data that V7 read. That said, you probably could rewrite what you are starting in your example to SIMH's expect/send command system to do something for you - but I'd have to think about it. FWIW: all those deposit commands should be unnecessary. Just make sure you have a proper boot block on the disk, as dmr tells you in the 'setting up Unix' document in /usr/doc and SIMH can boot from the controllers. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Thu Feb 23 01:49:50 2023 From: crossd at gmail.com (Dan Cross) Date: Wed, 22 Feb 2023 10:49:50 -0500 Subject: [TUHS] Open sourcing SunOS? Message-ID: Has anyone tried talking to anyone at Oracle about possibly getting the SunOS code released under an open source license? There can't be any commercial value left in it. - Dan C. From fuz at fuz.su Thu Feb 23 02:23:46 2023 From: fuz at fuz.su (Robert Clausecker) Date: Wed, 22 Feb 2023 17:23:46 +0100 Subject: [TUHS] Open sourcing SunOS? In-Reply-To: References: Message-ID: That's what OpenSolaris was. The bits that weren't open sourced were the bits they weren't allowed to for licensing reasons, such as the C compiler. Yours, Robert Clausecker Am Wed, Feb 22, 2023 at 10:49:50AM -0500 schrieb Dan Cross: > Has anyone tried talking to anyone at Oracle about possibly getting > the SunOS code released under an open source license? There can't be > any commercial value left in it. > > - Dan C. -- () ascii ribbon campaign - for an 8-bit clean world /\ - against html email - against proprietary attachments From crossd at gmail.com Thu Feb 23 02:30:31 2023 From: crossd at gmail.com (Dan Cross) Date: Wed, 22 Feb 2023 11:30:31 -0500 Subject: [TUHS] Open sourcing SunOS? In-Reply-To: References: Message-ID: On Wed, Feb 22, 2023 at 11:23 AM Robert Clausecker wrote: > That's what OpenSolaris was. The bits that weren't open sourced > were the bits they weren't allowed to for licensing reasons, such > as the C compiler. No. OpenSolaris was the SVR4-based Solaris 2. I'm referring to the BSD-based SunOS (e.g., 4.1.4, 4.1.3U1, etc). - Dan C. From mj at broniarz.net Thu Feb 23 02:48:50 2023 From: mj at broniarz.net (Maciej Jan Broniarz) Date: Wed, 22 Feb 2023 17:48:50 +0100 Subject: [TUHS] Help needed with some old VAX Machines Message-ID: Hello Everyone, Our local Hackroom acquired some VAX Station machines. The problem is, we have absolutely no docs or knowledge how to run the machine or how to test if it is working properly. Any help would be appreciated All best, -- Maciej Jan Broniarz -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Feb 23 03:17:38 2023 From: clemc at ccc.com (Clem Cole) Date: Wed, 22 Feb 2023 12:17:38 -0500 Subject: [TUHS] Help needed with some old VAX Machines In-Reply-To: References: Message-ID: Bitsavers in your friends: https://archive.org/details/dec-manuals A small suggestion .. you might go to the Open SIMH website, and you'll find several pointers to tutorials. The VAXStation is one of the systems that SIMH can emulate, so you might want to practice a bit on virtual hardware, which will be less fragile and easier to start over if you make an error. ᐧ On Wed, Feb 22, 2023 at 11:49 AM Maciej Jan Broniarz wrote: > Hello Everyone, > > Our local Hackroom acquired some VAX Station machines. The problem is, we > have absolutely no docs or knowledge how to run the machine or how to test > if it is working properly. Any help would be appreciated > > All best, > > -- > Maciej Jan Broniarz > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at ultimate.com Thu Feb 23 03:28:18 2023 From: phil at ultimate.com (Phil Budne) Date: Wed, 22 Feb 2023 12:28:18 -0500 Subject: [TUHS] Help needed with some old VAX Machines In-Reply-To: References: Message-ID: <202302221728.31MHSIsP047608@ultimate.com> For documentation I'd also suggest bitsavers (which archive.org sometimes copies and disorganizes): http://www.bitsavers.org/pdf/dec/vax/ For people who fiddle with actual hardware, The ClassicCmp Mailing list and archive: https://classiccmp.org/lists.html From jnc at mercury.lcs.mit.edu Thu Feb 23 04:08:57 2023 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 22 Feb 2023 13:08:57 -0500 (EST) Subject: [TUHS] Help needed with some old VAX Machines Message-ID: <20230222180857.AA50318C09D@mercury.lcs.mit.edu> > From: Maciej Jan Broniarz > Our local Hackroom acquired some VAX Station machines. Exactly what sort of VAXstations? There are several different kinds; one: http://gunkies.org/wiki/VAXstation_100 doesn't even include a VAX; it's just a branding deal from DEC Marketing. Start with finding out exactly which kind(s) of VAXstation you have. Noel From tuhs at tuhs.org Thu Feb 23 05:41:35 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 22 Feb 2023 19:41:35 +0000 Subject: [TUHS] [COFF] Re: Help needed with some old VAX Machines (moved from TUHS) Message-ID: COFF transfer, TUHS Bcc'd to know where this thread went. Between the two if you're not doing UNIX-specific things but just trying to resurrect/restore these, COFF will probably be the better place for further discussion. @OP if you're not a member of COFF already, you should be able to reach out to Warren Toomey regarding subscription. If you're feeling particularly adventurous, NetBSD still supports VAX in some manner: http://wiki.netbsd.org/ports/vax/ YMMV, but I've had some success with NetBSD on some pretty oddball stuff. As the old saying goes, "Of course it runs NetBSD". You might be able to find some old VMS stuff for them as well, but I wouldn't know where to point you other than bitsavers. There's some other archival site out there with a bunch of old DEC stuff but I can never seem to find it when I search for it, only by accident. Best of luck! - Matt G. ------- Original Message ------- On Wednesday, February 22nd, 2023 at 10:08 AM, jnc at mercury.lcs.mit.edu wrote: > > From: Maciej Jan Broniarz > > > > Our local Hackroom acquired some VAX Station machines. > > > Exactly what sort of VAXstations? There are several different kinds; one: > > http://gunkies.org/wiki/VAXstation_100 > > doesn't even include a VAX; it's just a branding deal from DEC Marketing. > Start with finding out exactly which kind(s) of VAXstation you have. > > Noel From dave at horsfall.org Thu Feb 23 05:52:12 2023 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 23 Feb 2023 06:52:12 +1100 (EST) Subject: [TUHS] Open sourcing SunOS? In-Reply-To: References: Message-ID: On Wed, 22 Feb 2023, Dan Cross wrote: > No. OpenSolaris was the SVR4-based Solaris 2. I'm referring to the > BSD-based SunOS (e.g., 4.1.4, 4.1.3U1, etc). I'd love to see the magic behind 4.1.4... Best OS I'd ever used. -- Dave From imp at bsdimp.com Thu Feb 23 06:04:37 2023 From: imp at bsdimp.com (Warner Losh) Date: Wed, 22 Feb 2023 13:04:37 -0700 Subject: [TUHS] Open sourcing SunOS? In-Reply-To: References: Message-ID: On Wed, Feb 22, 2023, 8:50 AM Dan Cross wrote: > Has anyone tried talking to anyone at Oracle about possibly getting > the SunOS code released under an open source license? There can't be > any commercial value left in it. > SunOS 4 has a lot of encumbered code in it, especially for i386 drivers. Bits of the network stack as well. It was hopeless to try to open source. There was a lot of bits and pieces that Sun had done with contracts that were, at best, ambiguous for what to do should they want to open source it. At least that's the story I've heard from people at Sun, both engineers and management. I know when Solbourne did their OS/MP 4.0 and 4.1 SunOS MP system, there was a lot of back and forth between Solbourne's and Sun's lawyers to get all the pieces needed to build the system. For example, initially SunView was not included in the offering, so my group was formed to write our clone for it (This would become OI (Object Interface) and uib (User Interface Builder) that we did in C++ to allow it to present in either Motif or OpenLook). I also know that Sun tried to donate their VM system to Berkeley btween BSD4.3 and BSD4.4. Had the support of Scott McNeely and was almost a done deal. However, the lawyers said that the company would need to take a 'write down' loss on the donation, which would likely tank the stock price of Sun, so it was nixed. So instead, Berkeley did the next best thing (really the only available thing) and went with the MachVM. One can find the sources to 4.1.4 and 4.1.3 online (though not the earlier 4.1.1 or 4.0.x which have the i386 port in it). The newer sources do have i386 bits, but from my cursory investigation, it's mostly remnants of the support. Of course, if one were to modify this, and try to distribute it, you'd likely be asking for trouble. At least two of the abandonware sites have copies. There's also something purporting to the the SCCS files for the system, but alas, they are not actually there. Having talked to the VPs that got OpenSolaris released about doing SunOS (after they'd left Sun, I worked for them), it was clear that OpenSolaris was hard enough. SunOS 4 was too old by even the point to get all the successors in interest to agree to modifications of the old contracts to allow source distribution without significant restrictions to agree to make enough of the system available for it to be interesting to people. Oracle has pulled back from OpenSolaris, fired all the Solaris engineers and has all that on basically life support. I doubt they'd want to do anything for even that modern code base, let alone something that's ancient history, would be hard to find, would be difficult to find the old paperwork for it to clear legal, etc. So, I'm not at all optimistic this could ever happen prior to the expiration of the copyrights of the original code. Warner - Dan C. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Thu Feb 23 06:12:33 2023 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 22 Feb 2023 12:12:33 -0800 Subject: [TUHS] Open sourcing SunOS? In-Reply-To: References: Message-ID: <20230222201233.GY7194@mcvoy.com> On Wed, Feb 22, 2023 at 01:04:37PM -0700, Warner Losh wrote: > On Wed, Feb 22, 2023, 8:50 AM Dan Cross wrote: > > > Has anyone tried talking to anyone at Oracle about possibly getting > > the SunOS code released under an open source license? There can't be > > any commercial value left in it. > > > > SunOS 4 has a lot of encumbered code in it, especially for i386 drivers. There is SunOS as in everything shipped, kernel and userspace, and there is the kernel. So far as I remember, the i386 stuff was never integrated into the source tree that Sun shipped from. There was the roadrunner stuff but I don't think that ever made it in to the official tree. If it did, nobody paid attention to it. All people cared about at the time as SPARC and I don't think there was any outsourced hacking for SPARC, that was all in house. The networking stack in SunOS 4.x was BSD derived. You might be thinking of Solaris, that took the Lachman STREAMS stack but that was 5.x, not 4.x. As the only guy, that I'm aware of, who took all the encumbered stuff out of the kernel, put back the BSD tty drivers and a few other small things that resulted in a kernel that we could freely open source, I beg to differ with: > Bits of the > network stack as well. It was hopeless to try to open source. There was a > lot of bits > and pieces that Sun had done with contracts that were, at best, ambiguous > for > what to do should they want to open source it. From tuhs at tuhs.org Thu Feb 23 06:16:29 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 22 Feb 2023 20:16:29 +0000 Subject: [TUHS] Origins of the SGS (System Generation Software) and COFF (Common Object File Format) Message-ID: Good day all, figured I'd start a thread on this matter as I'm starting to piece enough together to articulate the questions arising in my research. So based on my analysis of the 3B20S UNIX 4.1 manual I've been working through, all evidence points to the formalized SGS package and COFF originating tightly coupled to the 3B-20 line, then growing legs to support VAX, but never quite absorbing PDP-11 in entirety. That said, there are bits and pieces of the manual pages for the object format libraries that suggest there was some providence for PDP-11 in the development of COFF as well. Where this has landed though is a growing curiosity regarding: - Whether SGS and COFF were tightly coupled to one another from the outset, with SGS being supported by the general library routines being developed for the COFF format - Whether COFF was envisioned as a one-size-fits-all object format from its inception or started as an experiment in 3B-20 development that wound up being general enough for other platforms - If, prior to this format, there were any other efforts to produce a unifying binary format and set of development tools, or if COFF was a happy accident from what were a myriad of different architectural toolset streams One of the curious things is how VAX for a brief moment did have its own set of tools and a.out particulars before SGS/COFF. For instance, many of the VAX-targeted utilities in 3.0/System III bear little in common option/manual-wise with the general common SGS utilities in System V. The "not on PDP-11" pages for various SGS components in System V much more closely resemble the 3B-20 utilities in 4.1 than any of the non PDP-11/VAX-only bits in System III. Some examples: - The VAX assembler in System III contains a -dN option indicating the number of bytes to set aside for forward/external references for the linker to fill in. - The VAX assembler in System V contains among others the -n and -m options from 4.1 which indicate to disable address optimization and use m4 respectively - The System V assembler goes on to also include -R (remove input file after completion) -r (VAX only, add .data contents to .text instead) and options -b, -w, and -l to replace the -d1, -d2, and -d4 options indicated in the previous VAX assembler - System V further adds a -V to all the SGS software indicating the version of the software. This is new circa 5.0, absent from the 4.1 manual like the R, r, b, w, and l options - The 4.1 manual's singular ar(1) entry still agrees with the System III version. No arcv(1) is listed, implying the old ar format never made it to 3B-20 - The System V manual has both this ar(1) version as well as the new COFF-supporting version. Not sure if this implies the VAX ar format was expanded to support the COFF stuff for a little while until they decided on a new one or what. - The System III ld (which is implied to support PDP and VAX) survives in System V, but is cut down to supporting PDP-11 only - The COFF-ish ld shows up in 4.1, is then extended to VAX presumably in the same breath as the other COFF-supporting bits by Sys V, leading to two copies like many others, PDP-11-specific stuff and then COFF-specific stuff The picture that starts to form in the context of all of this is, for a little while in the late 70s/early 80s, the software development environments for PDP-11, VAX-11, and 3B-20 were interplaying with each other in often times inconsistent ways. Taking a peek at the 32V manuals, the VAX tools in System III appear to originate with that project, which makes sense. If I'm understanding the timeline, COFF starts to emerge from the 3B-20 project and USG probably decides that's the way to go, a unified format, but with PDP-11 pretty much out the door support wise already, there was little reason to apply that to PDP-11 as well, so the PDP-11 tools get their swan song in System V, original VAX-11 tools from 32V are likely killed off in 4.x, and the stuff that started with the 3B-20 group goes on to dominate the object file format and development software stuff until ELF comes along some time later. I guess other questions this raises are: - Were the original VAX tools built with any attention to compatibility with the PDP-11 bits Ken and Dennis wrote many years prior (based on some option discrepancies, possibly not?) - Do the VAX utilities derive from the Interdata 8/32 work or if there was actually another stream of tools as part of that project? - Was there any interplay between the existing tool streams (original PDP-11, 32V's VAX utilities, possibly Interdata 8/32) and the eventual COFF/SGS stuff, or was the latter pretty well siloed in 3B-20 land until deployment with 4.1? - Matt G. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad at anduin.eldar.org Thu Feb 23 06:44:30 2023 From: brad at anduin.eldar.org (Brad Spencer) Date: Wed, 22 Feb 2023 15:44:30 -0500 Subject: [TUHS] Open sourcing SunOS? In-Reply-To: <20230222201233.GY7194@mcvoy.com> (message from Larry McVoy on Wed, 22 Feb 2023 12:12:33 -0800) Message-ID: Larry McVoy writes: > On Wed, Feb 22, 2023 at 01:04:37PM -0700, Warner Losh wrote: >> On Wed, Feb 22, 2023, 8:50 AM Dan Cross wrote: >> >> > Has anyone tried talking to anyone at Oracle about possibly getting >> > the SunOS code released under an open source license? There can't be >> > any commercial value left in it. >> > >> >> SunOS 4 has a lot of encumbered code in it, especially for i386 drivers. > > There is SunOS as in everything shipped, kernel and userspace, and there > is the kernel. So far as I remember, the i386 stuff was never integrated > into the source tree that Sun shipped from. There was the roadrunner > stuff but I don't think that ever made it in to the official tree. If > it did, nobody paid attention to it. All people cared about at the > time as SPARC and I don't think there was any outsourced hacking for > SPARC, that was all in house. > > The networking stack in SunOS 4.x was BSD derived. You might be thinking > of Solaris, that took the Lachman STREAMS stack but that was 5.x, not > 4.x. > > As the only guy, that I'm aware of, who took all the encumbered stuff > out of the kernel, put back the BSD tty drivers and a few other small > things that resulted in a kernel that we could freely open source, > I beg to differ with: > >> Bits of the >> network stack as well. It was hopeless to try to open source. There was a >> lot of bits >> and pieces that Sun had done with contracts that were, at best, ambiguous >> for >> what to do should they want to open source it. There may have been other parallel efforts in one form or the other. I know that there existed a patch to SunOS 4.1.3 that updated the network stack to a newer version from Berkeley that gained a couple of new features over the one Sun delivered. The patch was source code, but it was possible with this patch to apply it to a binary copy of SunOS and recompile / compile a new kernel that had the new stack in it, that is, you didn't need the full source to the kernel. It was a long time ago and I don't remember the details exactly, but I did use it on a file / build / NIS server we had in the department at AT&T/Lucent where I was at. My point mostly being that hacking on SunOS 4.x appears to have happened here and there. It certainly would have been nice to have a open source SunOS 4.x around although the userland may have presented its own trouble. -- Brad Spencer - brad at anduin.eldar.org - KC8VKS - http://anduin.eldar.org From imp at bsdimp.com Thu Feb 23 06:46:53 2023 From: imp at bsdimp.com (Warner Losh) Date: Wed, 22 Feb 2023 13:46:53 -0700 Subject: [TUHS] Open sourcing SunOS? In-Reply-To: <20230222201233.GY7194@mcvoy.com> References: <20230222201233.GY7194@mcvoy.com> Message-ID: On Wed, Feb 22, 2023 at 1:12 PM Larry McVoy wrote: > On Wed, Feb 22, 2023 at 01:04:37PM -0700, Warner Losh wrote: > > On Wed, Feb 22, 2023, 8:50 AM Dan Cross wrote: > > > > > Has anyone tried talking to anyone at Oracle about possibly getting > > > the SunOS code released under an open source license? There can't be > > > any commercial value left in it. > > > > > > > SunOS 4 has a lot of encumbered code in it, especially for i386 drivers. > > There is SunOS as in everything shipped, kernel and userspace, and there > is the kernel. So far as I remember, the i386 stuff was never integrated > into the source tree that Sun shipped from. There was the roadrunner > stuff but I don't think that ever made it in to the official tree. If > it did, nobody paid attention to it. All people cared about at the > time as SPARC and I don't think there was any outsourced hacking for > SPARC, that was all in house. > I know there's i386 source kits for the Roadrunner, and that's really the only thing that SunOS ever supported, at least that was sold. I'd been told that it had been poorly integrated by people that had worked on it here in Boulder, so I believe that. In the 4.1.3 sources there's a number of i386 ifdefs, and at least a math library for i386. But no kernel bits, except for a bunch of ifdefs for i386 that I've not looked at closely. Maybe this is what is meant by 'poorly integrated' :) > The networking stack in SunOS 4.x was BSD derived. You might be thinking > of Solaris, that took the Lachman STREAMS stack but that was 5.x, not > 4.x. > I was thinking of the streams stuff that's in 4.x BSD. There's AT&T copyrights on it. There's also, strangely, rfs sources included with some of the stuff one can find online. But it looks to be imported nearly verbatim from System V of some flavor with very few edits, judging by the 1.1 versions in many of the files. > As the only guy, that I'm aware of, who took all the encumbered stuff > out of the kernel, put back the BSD tty drivers and a few other small > things that resulted in a kernel that we could freely open source, > I beg to differ with: > > > Bits of the > > network stack as well. It was hopeless to try to open source. There was a > > lot of bits > > and pieces that Sun had done with contracts that were, at best, ambiguous > > for > > what to do should they want to open source it. > I'm just reporting what my VP told me... Grepping through the source I can find online, the evidence is closer to what you say than what Glen told me. Either he or I must have confused Solaris 2 with SunOS 4. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Thu Feb 23 06:54:40 2023 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 22 Feb 2023 12:54:40 -0800 Subject: [TUHS] Open sourcing SunOS? In-Reply-To: References: <20230222201233.GY7194@mcvoy.com> Message-ID: <20230222205440.GB7194@mcvoy.com> On Wed, Feb 22, 2023 at 01:46:53PM -0700, Warner Losh wrote: > On Wed, Feb 22, 2023 at 1:12 PM Larry McVoy wrote: > > The networking stack in SunOS 4.x was BSD derived. You might be thinking > > of Solaris, that took the Lachman STREAMS stack but that was 5.x, not > > 4.x. > > > > I was thinking of the streams stuff that's in 4.x BSD. There's AT&T > copyrights > on it. There's also, strangely, rfs sources included with some of the stuff > one > can find online. But it looks to be imported nearly verbatim from System V > of some flavor with very few edits, judging by the 1.1 versions in many of > the > files. I ripped out the STREAMS stuff (it was STREAMS, not dmr's streams). And I ripped out RFS. There was more than 1.1 versions in some version of SunOS, my former office mate, Howard Chartok, did a pile of work on RFS. > > As the only guy, that I'm aware of, who took all the encumbered stuff > > out of the kernel, put back the BSD tty drivers and a few other small > > things that resulted in a kernel that we could freely open source, > > I beg to differ with: > > > > > Bits of the > > > network stack as well. It was hopeless to try to open source. There was a > > > lot of bits > > > and pieces that Sun had done with contracts that were, at best, ambiguous > > > for > > > what to do should they want to open source it. > > I'm just reporting what my VP told me... Grepping through the source I can > find online, the evidence is closer to what you say than what Glen told me. > Either he or I must have confused Solaris 2 with SunOS 4. Like I said, in 1992 or 1993, I had a BSD licensed SunOS 4.1.something, I think 4.1.3, kernel. No STREAMS, no RFS, no STREAMS based tty drivers, it was what lots of people called SunOS: "A bugfixed and improved BSD". I shopped it around inside Sun and there were plenty of people who wanted a reason to say it wasn't open source ready and they couldn't find one. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From clemc at ccc.com Thu Feb 23 08:20:05 2023 From: clemc at ccc.com (Clem Cole) Date: Wed, 22 Feb 2023 17:20:05 -0500 Subject: [TUHS] Origins of the SGS (System Generation Software) and COFF (Common Object File Format) In-Reply-To: References: Message-ID: below are some thoughts/hopefully answers to your questions.... On Wed, Feb 22, 2023 at 3:16 PM segaloco via TUHS wrote: > Good day all, figured I'd start a thread on this matter as I'm starting to > piece enough together to articulate the questions arising in my research. > > So based on my analysis of the 3B20S UNIX 4.1 manual I've been working > through, all evidence points to the formalized SGS package and COFF > originating tightly coupled to the 3B-20 line, then growing legs to support > VAX, but never quite absorbing PDP-11 in entirety. That said, there are > bits and pieces of the manual pages for the object format libraries that > suggest there was some providence for PDP-11 in the development of COFF as > well. > > Where this has landed though is a growing curiosity regarding: > > 1. Whether SGS and COFF were tightly coupled to one another from the > outset, with SGS being supported by the general library routines being > developed for the COFF format > > @scj - any enlightenment -- your team in USG must have been part of all that. > > 1. Whether COFF was envisioned as a one-size-fits-all object format > from its inception or started as an experiment in 3B-20 development that > wound up being general enough for other platforms > > That I can not say, but I can say that to the UNIX source licenses (i.e. not the Universities in the Research system or inside of the Bell Systems) - it was used in the "consider it standard" campaign that AT&T marketing in NC was starting to push. This was around the time that PCC2 was coming out to replace the original PCC but I remember getting PCC2 was extra cost. Most of the BSD based kernels (DEC, HP, etc..) were originally using a modified a.out of their own flavor but I think almost all them switched to COFF post the System III license. What I have forgotten, and it may have been a requirement/mixed up in the license. I do remember this was right around when gcc first starts coming out, and they had a tool called robitussin to "cure coffs" as they were using a.out wen they could. > 1. > > > 1. If, prior to this format, there were any other efforts to produce a > unifying binary format and set of development tools, or if COFF was a happy > accident from what were a myriad of different architectural toolset streams > > MIT had a modified a.out format for the NU machine ports - that might have been called b.out. CMU had macho which again was an extended a.out but even more flexible. > > 1. One of the curious things is how VAX for a brief moment did have > its own set of tools and a.out particulars before SGS/COFF. > > Why is that curious - all original Vax development was just using the original PCC stream from V7 (and pre-Judge Green more in a minute). What I don't remember is if PCC2 was COFF when introduced, or COFF can first but I think they were separate things - again someone like scj would be authoritative. The three tools that have to care are the assembler (as), the linker (ld) program loading code in the kernel itself. > For instance, many of the VAX-targeted utilities in 3.0/System III bear > little in common option/manual-wise with the general common SGS utilities > in System V. The "not on PDP-11" pages for various SGS components in System > V much more closely resemble the 3B-20 utilities in 4.1 than any of the non > PDP-11/VAX-only bits in System III. > > Some examples: > > - The VAX assembler in System III contains a -dN option indicating the > number of bytes to set aside for forward/external references for the linker > to fill in. > - The VAX assembler in System V contains among others the -n and -m > options from 4.1 which indicate to disable address optimization and use m4 > respectively > - The System V assembler goes on to also include -R (remove input file > after completion) -r (VAX only, add .data contents to .text instead) and > options -b, -w, and -l to replace the -d1, -d2, and -d4 options indicated > in the previous VAX assembler > - System V further adds a -V to all the SGS software indicating the > version of the software. This is new circa 5.0, absent from the 4.1 manual > like the R, r, b, w, and l options > > > > - The 4.1 manual's singular ar(1) entry still agrees with the System > III version. No arcv(1) is listed, implying the old ar format never made it > to 3B-20 > > Hmm this is confusing old v[456] ar format to new ar format was during Research V6 to Research V7. By the time of any Vax development the old format had pretty much been killed. I'd look at check what PWB 1.0 and 2.0 used. The new ar format was independent of what it was in it. i.e. V7: man 5 ar AR(5) AR(5) NAME ar - archive (library) file format SYNOPSIS #include DESCRIPTION The archive command ar is used to combine several files into one. Archives are used mainly as libraries to be searched by the link-editor ld. A file produced by ar has a magic number at the start, fol- lowed by the constituent files, each preceded by a file header. The magic number and header layout as described in the include file are: #define ARMAG 0177545 struct ar_hdr { char ar_name[14]; long ar_date; char ar_uid; char ar_gid; int ar_mode; long ar_size; }; > > - The System V manual has both this ar(1) version as well as the new > COFF-supporting version. > > Why would ar(1) care? > > - Not sure if this implies the VAX ar format was expanded to support > the COFF stuff for a little while until they decided on a new one or what. > > > > - The System III ld (which is implied to support PDP and VAX) survives > in System V, but is cut down to supporting PDP-11 only > - The COFF-ish ld shows up in 4.1, is then extended to VAX presumably > in the same breath as the other COFF-supporting bits by Sys V, leading to > two copies like many others, PDP-11-specific stuff and then COFF-specific > stuff > > > The picture that starts to form in the context of all of this is, for a > little while in the late 70s/early 80s, the software development > environments for PDP-11, VAX-11, and 3B-20 were interplaying with each > other in often times inconsistent ways. Taking a peek at the 32V manuals, > the VAX tools in System III appear to originate with that project, which > makes sense. If I'm understanding the timeline, COFF starts to emerge from > the 3B-20 project and USG probably decides that's the way to go, a unified > format, but with PDP-11 pretty much out the door support wise already, > there was little reason to apply that to PDP-11 as well, so the PDP-11 > tools get their swan song in System V, original VAX-11 tools from 32V are > likely killed off in 4.x, and the stuff that started with the 3B-20 group > goes on to dominate the object file format > That makes sense - but be careful - the 3B and WE32000 ISA may have been the driver but I would expect that compiler folk in Summit were more in the driver seat. The 3B20 kernel would use what they were getting from the tools team and core kernel team in USG. Remember the politic at the time is Judge Green has unleashed AT&T and they are now allowed to be in the biz, and the sales/marketing folks AT&T was pushing the 3B20 and the WE32000 - so there are big forces behind the scenes that are not obvious/clear. > and development software stuff until ELF comes along some time later. > Yep - never quite understood what the push for ELF was over COFF after all the effort to drive COFF down people's throat. Note Microsoft "embraced and extended" COFF as their format -- originally because of Xenix I believe. Someone like Paul W may have some insights on this and that was before the 3B20. What was the format that the original Xenix used - when it was targeting PDP-11, 68000, x86 and Z8000? Again I'm fuzzy on the details here. But I do remember during the license discussions that would lead to System III, that one of things the Microsoft team was worried about -- IIRC it was Bob Greenberg pushing all that. I lost contact with Bob a few years ago, but if we can find him, I would expect Bob to know what Xenix was doing. And again that negotiation>>starts<< all pre-Judge Green, but finishes up soon afterwards. > > I guess other questions this raises are: > > 1. Were the original VAX tools built with any attention to > compatibility with the PDP-11 bits Ken and Dennis wrote many years prior > (based on some option discrepancies, possibly not?) > > hrmph... folks started with the PDP-11 tools and changed them as needed. I'm not sure compatibility is the right term. They were retargeted nad moved forward by people trying support a new machine they got and did not want run DEC's OS. > > 1. Do the VAX utilities derive from the Interdata 8/32 work or if > there was actually another stream of tools as part of that project? > > I guess I don't understand the question. The original V7 tools were retargeted. When useful features were added, they might be offered/returned to other folks, but remember, Research is not "supporting" UNIX. USG is where things start to think in terms of multiple targets >>before Judge Green<< and then after Judge Green, there was a push to stop using non-AT&T based equipment or chips in the Bell System and make what Western Electric was selling be attractive [which sometimes was a little bit of putting lipstick on porcine as it were]. For instance, Rob and Barts's original JERQ is 68000 based, but by the time it becomes a product as 5620 it has to be refactored as a WE32000. > > 1. Was there any interplay between the existing tool streams (original > PDP-11, 32V's VAX utilities, possibly Interdata 8/32) and the eventual > COFF/SGS stuff, or was the latter pretty well siloed in 3B-20 land until > deployment with 4.1? > > I think you are putting too much on the 3B program itself. The 3B was the task at hand at the time and a solid opportunity to bring to bear business choices being made. You need to look at the greater business to understand a lot of the choices. A lot of things were happening in parallel in the market that had other impacts on technology and how it was delivered -- the 3B program was the "technology train" leaving the station that some of them got attached to/delivered using. But, I as I said to you when we chatted, you really can not underestimate what was happening (or not happening) as AT&T changed its business focus - pre/post-Judge Green. It was a large company with lots of different spheres of interest (read - different executives), each being measured with different things that they might value. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gingell at computer.org Thu Feb 23 10:12:23 2023 From: gingell at computer.org (Rob Gingell) Date: Wed, 22 Feb 2023 16:12:23 -0800 Subject: [TUHS] Open sourcing SunOS? In-Reply-To: References: Message-ID: <170a8b0c-4fcb-9069-aeac-5dda72a7eeea@computer.org> On 2/22/23 12:04 PM, Warner Losh wrote: > SunOS 4 has a lot of encumbered code in it, ... SunOS had a complicated set of license encumbrances. I can't claim to have fully understood them even at the time. In the mid-1980s, the notion of "open sourcing" as we understand it today wasn't a goal or even considered and so never entered into the terms of the technologies Sun used. These might have been overcome with effort but in the context of the time it didn't seem important. Things Sun licensed widely, like source kits for NFS/VFS, were things we routinely and repeatedly sanitized as they evolved. As part of the SPARC partners program SunOS was licensed to people building SPARC-based products but as Warner notes in the Solbourne experience, especially early on, there wasn't a "product" so much as a "process" that disseminated it. > I also know that Sun tried to donate their VM system to Berkeley btween > BSD4.3 > and BSD4.4. It would be more correct to say that Sun was willing to donate the VM system back to Berkeley, but my recollection is that CSRG planned to get to that functionality through a different implementation path and didn't want it. We expected "everyone" to eventually get the VM system, as it was in SVR4 before SunOS 4.0 even shipped, and so "everyone" (even the people who otherwise offered BSD systems) would have access to it, just like we did. (Of course that notion of "everyone" is pretty limited but at the time it was just The Way It Was.) We did donate all the shared library work to Berkeley, probably the closest to what we'd now call "open source" that Sun did in that era. At the time, Berkeley didn't plan on migrating off of the a.out object file format and so it was useful to them to have the a.out-based implementation. > Had the support of Scott McNeely and was almost a done deal. However > the lawyers said that the company would need to take a 'write down' loss > on the > donation, which would likely tank the stock price of Sun, so it was > nixed. While I am confident he would have supported it, I doubt Scott ever knew about the donations and discussions. The organization-chart-local VP signed off on it and I had a 10 minute phone conversation (no part of which involved balance sheets or stock values) with the lawyer who wrote the letter of transmittal that accompanied the code. From tuhs at tuhs.org Thu Feb 23 10:17:18 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 23 Feb 2023 00:17:18 +0000 Subject: [TUHS] Origins of the SGS (System Generation Software) and COFF (Common Object File Format) In-Reply-To: References: Message-ID: Thanks for the insights as always Clem! Mea culpa on not looking at the ar situation a little more broadly, was pretty hyperfocused on 3B-20 stuff. As for compatibility between development tools, I was mainly referring to available option switches (the kind of thing that could potentially trip up someone's scripting). Once SGS hits it seems like everything moving forward from that endeavored to keep comparable command-line switches, but just to further compare: - PDP as(1) uniquely has the '-' option to treat all undefined labels as globals (as opposed to the much more common "this arg is stdin" that a lone '-' would give elsewhere.) VAX as(1) drops this and adds -dN to define the size reservation for undefined symbols. SGS as(1) keeps neither of these, opting to drop '-' entirely and implement the -dN functionality as -b, -w, and -l instead. - Things are a bit better for ld(1). SGS ld(1) drops the -X option of the earlier version (pertains to cc behavior regarding internal labels, maybe irrelevant with pcc in the picture). Also presumably the -n and -i options are dropped as their actions are already default on VAX or otherwise only pertain to PDP. Old ld(1) had a -V option to store a version string in the resulting object. This becomes -VS in SGS ld(1) to accommodate -V being a standard "report my version" flag. SGS ld(1) then goes on to add -e to explicitly denote the entry point, -f to provide a short int fill value for sections needing it. We also pick up the now common -L for adding library paths. So all in all, more commonality with pre-SGS ld(1) but still technically some breaking option changes. - Looks like nm(1) may have some appreciable changes. The -g (only print globals), -p (print in symbol table order), -r (print in reverse order), and -s (sort by size) option values are removed. A few are replaced by different options: -n was originally sort numerically instead of alphabetically (presumably by value rather than name), but in the SGS version, this is reversed, -n being the print by name order option instead (alphabetical is default in old nm(1)). The -o option morphs from meaning to include the name of the source file in the output to print the symbol value as octal. For SGS nm(1), we see the addition of -x (print in hex), -h (suppress headers), -v (sort by value, presumably replaces the old -n meaning), -e (only print statics and externals), -f ("full" output), and -V (version). This presents breaking changes for all but one of the switches to the earlier version of nm(1). For the record, V7, 32V, and System III all appear to have a comparable version. This utility is particularly interesting because a perusal of the current SUS https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/utilities/nm.html shows a mishmash of options, with -g and -u surviving all the way from V7, whereas -e, -f, -o, -v, -x derive from the SGS behavior. Then there are the -A, -P, and -t options which are explained in the rationale section of the standard; basically these are POSIX additions to avoid using conflicting option types where possible. - As for size(1) and strip(1), the SGS versions only add options. - Finally, a few utilities are added. System III features a dump(1) command that is some sort of tape dump utility, but this name repurposed at least as of 4.1 into an object file section dumper, a role it retains. The list(1) utility is also added in 4.1. So in detailed review, as(1), ld(1), and nm(1) had the most changes between the research versions and what eventually landed in SGS, with nm(1) especially being wildly incompatible from a command-line option standpoint. As for as(1), one PDP-11 option drops and one VAX option changes switches (but not functionality as far as I can tell). Finally, ld(1) seems to drop a few options that aren't needed in a non-PDP world and adjusts the version-assignment option to allow -V to be a universal version request of the various object utilities. - Matt G. ------- Original Message ------- On Wednesday, February 22nd, 2023 at 2:20 PM, Clem Cole wrote: > below are some thoughts/hopefully answers to your questions.... > > On Wed, Feb 22, 2023 at 3:16 PM segaloco via TUHS wrote: > >> Good day all, figured I'd start a thread on this matter as I'm starting to piece enough together to articulate the questions arising in my research. >> >> So based on my analysis of the 3B20S UNIX 4.1 manual I've been working through, all evidence points to the formalized SGS package and COFF originating tightly coupled to the 3B-20 line, then growing legs to support VAX, but never quite absorbing PDP-11 in entirety. That said, there are bits and pieces of the manual pages for the object format libraries that suggest there was some providence for PDP-11 in the development of COFF as well. >> >> Where this has landed though is a growing curiosity regarding: >> >> - Whether SGS and COFF were tightly coupled to one another from the outset, with SGS being supported by the general library routines being developed for the COFF format > > @scj - any enlightenment -- your team in USG must have been part of all that. > >> - Whether COFF was envisioned as a one-size-fits-all object format from its inception or started as an experiment in 3B-20 development that wound up being general enough for other platforms > > That I can not say, but I can say that to the UNIX source licenses (i.e. not the Universities in the Research system or inside of the Bell Systems) - it was used in the "consider it standard" campaign that AT&T marketing in NC was starting to push. This was around the time that PCC2 was coming out to replace the original PCC but I remember getting PCC2 was extra cost. > > Most of the BSD based kernels (DEC, HP, etc..) were originally using a modified a.out of their own flavor but I think almost all them switched to COFF post the System III license. What I have forgotten, and it may have been a requirement/mixed up in the license. > > I do remember this was right around when gcc first starts coming out, and they had a tool called robitussin to "cure coffs" as they were using a.out wen they could. > >> - >> >> - If, prior to this format, there were any other efforts to produce a unifying binary format and set of development tools, or if COFF was a happy accident from what were a myriad of different architectural toolset streams > > MIT had a modified a.out format for the NU machine ports - that might have been called b.out. > CMU had macho which again was an extended a.out but even more flexible. > >> - One of the curious things is how VAX for a brief moment did have its own set of tools and a.out particulars before SGS/COFF. > > Why is that curious - all original Vax development was just using the original PCC stream from V7 (and pre-Judge Green more in a minute). > > What I don't remember is if PCC2 was COFF when introduced, or COFF can first but I think they were separate things - again someone like scj would be authoritative. > > The three tools that have to care are the assembler (as), the linker (ld) program loading code in the kernel itself. > >> For instance, many of the VAX-targeted utilities in 3.0/System III bear little in common option/manual-wise with the general common SGS utilities in System V. The "not on PDP-11" pages for various SGS components in System V much more closely resemble the 3B-20 utilities in 4.1 than any of the non PDP-11/VAX-only bits in System III. >> >> Some examples: >> >> - The VAX assembler in System III contains a -dN option indicating the number of bytes to set aside for forward/external references for the linker to fill in. >> - The VAX assembler in System V contains among others the -n and -m options from 4.1 which indicate to disable address optimization and use m4 respectively >> - The System V assembler goes on to also include -R (remove input file after completion) -r (VAX only, add .data contents to .text instead) and options -b, -w, and -l to replace the -d1, -d2, and -d4 options indicated in the previous VAX assembler >> - System V further adds a -V to all the SGS software indicating the version of the software. This is new circa 5.0, absent from the 4.1 manual like the R, r, b, w, and l options >> >> - The 4.1 manual's singular ar(1) entry still agrees with the System III version. No arcv(1) is listed, implying the old ar format never made it to 3B-20 > > Hmm this is confusing old v[456] ar format to new ar format was during Research V6 to Research V7. By the time of any Vax development the old format had pretty much been killed. I'd look at check what PWB 1.0 and 2.0 used. The new ar format was independent of what it was in it. > > i.e. V7: man 5 ar > > [AR(5)](http://man.cat-v.org/unix_7th/5/AR) > > [AR(5)](http://man.cat-v.org/unix_7th/5/AR) > NAME > ar - archive (library) file format > > SYNOPSIS > #include > > DESCRIPTION > The archive command ar is used to combine several files into > one. Archives are used mainly as libraries to be searched > by the link-editor ld. > > A file produced by ar has a magic number at the start, fol- > lowed by the constituent files, each preceded by a file > header. The magic number and header layout as described in > the include file are: > >>> #define ARMAG 0177545 >> >>> struct ar_hdr { > >>>> char ar_name[14]; >> >>>> long ar_date; >> >>>> char ar_uid; >> >>>> char ar_gid; >> >>>> int ar_mode; >> >>>> long ar_size; > >>> }; > >> - The System V manual has both this ar(1) version as well as the new COFF-supporting version. > > Why would ar(1) care? > >> - Not sure if this implies the VAX ar format was expanded to support the COFF stuff for a little while until they decided on a new one or what. >> >> - The System III ld (which is implied to support PDP and VAX) survives in System V, but is cut down to supporting PDP-11 only >> - The COFF-ish ld shows up in 4.1, is then extended to VAX presumably in the same breath as the other COFF-supporting bits by Sys V, leading to two copies like many others, PDP-11-specific stuff and then COFF-specific stuff >> >> The picture that starts to form in the context of all of this is, for a little while in the late 70s/early 80s, the software development environments for PDP-11, VAX-11, and 3B-20 were interplaying with each other in often times inconsistent ways. Taking a peek at the 32V manuals, the VAX tools in System III appear to originate with that project, which makes sense. If I'm understanding the timeline, COFF starts to emerge from the 3B-20 project and USG probably decides that's the way to go, a unified format, but with PDP-11 pretty much out the door support wise already, there was little reason to apply that to PDP-11 as well, so the PDP-11 tools get their swan song in System V, original VAX-11 tools from 32V are likely killed off in 4.x, and the stuff that started with the 3B-20 group goes on to dominate the object file format > > That makes sense - but be careful - the 3B and WE32000 ISA may have been the driver but I would expect that compiler folk in Summit were more in the driver seat. The 3B20 kernel would use what they were getting from the tools team and core kernel team in USG. > > Remember the politic at the time is Judge Green has unleashed AT&T and they are now allowed to be in the biz, and the sales/marketing folks AT&T was pushing the 3B20 and the WE32000 - so there are big forces behind the scenes that are not obvious/clear. > >> and development software stuff until ELF comes along some time later. > > Yep - never quite understood what the push for ELF was over COFF after all the effort to drive COFF down people's throat. Note Microsoft "embraced and extended" COFF as their format -- originally because of Xenix I believe. Someone like Paul W may have some insights on this and that was before the 3B20. > > What was the format that the original Xenix used - when it was targeting PDP-11, 68000, x86 and Z8000? Again I'm fuzzy on the details here. But I do remember during the license discussions that would lead to System III, that one of things the Microsoft team was worried about -- IIRC it was Bob Greenberg pushing all that. I lost contact with Bob a few years ago, but if we can find him, I would expect Bob to know what Xenix was doing. And again that negotiation>>starts<< all pre-Judge Green, but finishes up soon afterwards. > >> I guess other questions this raises are: >> >> - Were the original VAX tools built with any attention to compatibility with the PDP-11 bits Ken and Dennis wrote many years prior (based on some option discrepancies, possibly not?) > > hrmph... folks started with the PDP-11 tools and changed them as needed. I'm not sure compatibility is the right term. They were retargeted nad moved forward by people trying support a new machine they got and did not want run DEC's OS. > >> - Do the VAX utilities derive from the Interdata 8/32 work or if there was actually another stream of tools as part of that project? > > I guess I don't understand the question. The original V7 tools were retargeted. When useful features were added, they might be offered/returned to other folks, but remember, Research is not "supporting" UNIX. USG is where things start to think in terms of multiple targets >>before Judge Green<< and then after Judge Green, there was a push to stop using non-AT&T based equipment or chips in the Bell System and make what Western Electric was selling be attractive [which sometimes was a little bit of putting lipstick on porcine as it were]. For instance, Rob and Barts's original JERQ is 68000 based, but by the time it becomes a product as 5620 it has to be refactored as a WE32000. > >> - Was there any interplay between the existing tool streams (original PDP-11, 32V's VAX utilities, possibly Interdata 8/32) and the eventual COFF/SGS stuff, or was the latter pretty well siloed in 3B-20 land until deployment with 4.1? > > I think you are putting too much on the 3B program itself. The 3B was the task at hand at the time and a solid opportunity to bring to bear business choices being made. You need to look at the greater business to understand a lot of the choices. A lot of things were happening in parallel in the market that had other impacts on technology and how it was delivered -- the 3B program was the "technology train" leaving the station that some of them got attached to/delivered using. > > But, I as I said to you when we chatted, you really can not underestimate what was happening (or not happening) as AT&T changed its business focus - pre/post-Judge Green. It was a large company with lots of different spheres of interest (read - different executives), each being measured with different things that they might value. -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Thu Feb 23 12:14:16 2023 From: imp at bsdimp.com (Warner Losh) Date: Wed, 22 Feb 2023 19:14:16 -0700 Subject: [TUHS] Open sourcing SunOS? In-Reply-To: <170a8b0c-4fcb-9069-aeac-5dda72a7eeea@computer.org> References: <170a8b0c-4fcb-9069-aeac-5dda72a7eeea@computer.org> Message-ID: On Wed, Feb 22, 2023 at 5:12 PM Rob Gingell wrote: > On 2/22/23 12:04 PM, Warner Losh wrote: > > SunOS 4 has a lot of encumbered code in it, ... > > SunOS had a complicated set of license encumbrances. I can't claim to > have fully understood them even at the time. In the mid-1980s, the > notion of "open sourcing" as we understand it today wasn't a goal or > even considered and so never entered into the terms of the technologies > Sun used. These might have been overcome with effort but in the context > of the time it didn't seem important. > > Things Sun licensed widely, like source kits for NFS/VFS, were things we > routinely and repeatedly sanitized as they evolved. > > As part of the SPARC partners program SunOS was licensed to people > building SPARC-based products but as Warner notes in the Solbourne > experience, especially early on, there wasn't a "product" so much as a > "process" that disseminated it. > Process is a good word here :). > > I also know that Sun tried to donate their VM system to Berkeley btween > > BSD4.3 > > and BSD4.4. > > It would be more correct to say that Sun was willing to donate the VM > system back to Berkeley, but my recollection is that CSRG planned to get > to that functionality through a different implementation path and didn't > want it. > I got my story from Kirk McKusick who was very clear that it was going to happen, but didn't due to some hold up at the highest levels. It was only then that the decided to go with Mach after they couldn't get it... We expected "everyone" to eventually get the VM system, as it was in > SVR4 before SunOS 4.0 even shipped, and so "everyone" (even the people > who otherwise offered BSD systems) would have access to it, just like we > did. (Of course that notion of "everyone" is pretty limited but at the > time it was just The Way It Was.) > Yea, all proper licensees :). > We did donate all the shared library work to Berkeley, probably the > closest to what we'd now call "open source" that Sun did in that era. At > the time, Berkeley didn't plan on migrating off of the a.out object file > format and so it was useful to them to have the a.out-based implementation. > Yea, BSD didn't migrate off of a.out until the fission into FreeBSD and NetBSD since they did things slightly differently... > > Had the support of Scott McNeely and was almost a done deal. However > > the lawyers said that the company would need to take a 'write down' loss > > on the > > donation, which would likely tank the stock price of Sun, so it was > > nixed. > While I am confident he would have supported it, I doubt Scott ever knew > about the donations and discussions. The organization-chart-local VP > signed off on it and I had a 10 minute phone conversation (no part of > which involved balance sheets or stock values) with the lawyer who wrote > the letter of transmittal that accompanied the code. > I don't doubt that. I certainly wasn't there. I've heard the story from Kirk several times though... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Thu Feb 23 16:30:17 2023 From: lars at nocrew.org (Lars Brinkhoff) Date: Thu, 23 Feb 2023 06:30:17 +0000 Subject: [TUHS] Origins of the SGS (System Generation Software) and COFF (Common Object File Format) In-Reply-To: (Clem Cole's message of "Wed, 22 Feb 2023 17:20:05 -0500") References: Message-ID: <7wcz60x5ae.fsf@junk.nocrew.org> Clem Cole wrote: > MIT had a modified a.out format for the NU machine ports - that might > have been called b.out. CMU had macho which again was an extended > a.out but even more flexible. Digital Research's GEMDOS also used a modified a.out format (at least as found on the Atari ST), pretty much the original PDP-11 format with 32-bit addresses. [Shouldn't this go to the COFF mailing list... oh sorry.] From gingell at computer.org Thu Feb 23 17:22:35 2023 From: gingell at computer.org (Rob Gingell) Date: Wed, 22 Feb 2023 23:22:35 -0800 Subject: [TUHS] Open sourcing SunOS? In-Reply-To: References: <170a8b0c-4fcb-9069-aeac-5dda72a7eeea@computer.org> Message-ID: <5366f54d-d2f9-04a6-b761-f37e2c83f8c0@computer.org> On 2/22/23 6:14 PM, Warner Losh wrote: >  I don't doubt that. I certainly wasn't there. I've heard the story > from Kirk several times though... On the "it would tank the stock" story, it's certainly a much better story than the boring one I have. I'm thinking legs are getting pulled somewhere on that. Though were it true it would have the pleasant property of making our engineering efforts be reflected in the business in a much more inflated way, which, as several people have pointed out in the past isn't how it usually works. On 2/22/23 6:14 PM, Warner Losh wrote: > I got my story from Kirk McKusick who  was very clear that it was going > to happen, but didn't due to some hold up at the highest levels. While I'm confident the "tank the stock" story isn't true, that Kirk remembers there being a hold up makes me concerned that I'm not remembering everything. Perhaps my memories are too rosy based on what we were able to do, such that I'm overlooking some consideration that would have made the VM system different. Kirk (and Mike Karels) had been involved in the work early on so it benefited from their help and they were certainly able to evaluate it in the context of what they wanted to do with BSD. Guess I need to dig and reconstruct the story better... From jbglaw at lug-owl.de Thu Feb 23 17:37:11 2023 From: jbglaw at lug-owl.de (Jan-Benedict Glaw) Date: Thu, 23 Feb 2023 08:37:11 +0100 Subject: [TUHS] [COFF] Re: Help needed with some old VAX Machines (moved from TUHS) In-Reply-To: References: Message-ID: <20230223073711.5ztisknhpol3lzp2@lug-owl.de> Hi! On Wed, 2023-02-22 19:41:35 +0000, segaloco via TUHS wrote: > COFF transfer, TUHS Bcc'd to know where this thread went. Not yet subscribed there, sorry. But on the way! > If you're feeling particularly adventurous, NetBSD still supports VAX in some manner: http://wiki.netbsd.org/ports/vax/ I regularly build NetBSD HEAD (on NetBSD amd64 and also as a cross-build from Linux amd64). Sometimes (rarely) I start it on regular desktop VAX hardware, and always in SIMH. Works well! > YMMV, but I've had some success with NetBSD on some pretty oddball stuff. As the old saying goes, "Of course it runs NetBSD". You might be able to find some old VMS stuff for them as well, but I wouldn't know where to point you other than bitsavers. There's some other archival site out there with a bunch of old DEC stuff but I can never seem to find it when I search for it, only by accident. Best of luck! Many pkgsrc packages are missing due to compiler bugs in the GCC version that NetBSD ships. However, Maciej recently did some great work on GCC's VAX backend and that will fix most of the issues. Right now, it usually helps to have CFLAGS+=-O0 to not run into issues. MfG, JBG -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From ken.unix.guy at gmail.com Fri Feb 24 00:25:04 2023 From: ken.unix.guy at gmail.com (KenUnix) Date: Thu, 23 Feb 2023 09:25:04 -0500 Subject: [TUHS] Origins of the SGS (System Generation Software) and COFF (Common Object File Format) In-Reply-To: <7wcz60x5ae.fsf@junk.nocrew.org> References: <7wcz60x5ae.fsf@junk.nocrew.org> Message-ID: Point of interest. In the mid 80's Northern Telecom had a product called the DV-1. It was a motorola based system on the 68010. At the end of its life it was able to run GEM with a floppy. The DV-1 terminal was 68000 based. See some snaps at: https://www.flickr.com/photos/9479603 at N02/1814557731/in/album-72157602824219250/ https://www.flickr.com/photos/9479603 at N02/1814548075/in/album-72157602824219250/ https://www.flickr.com/photos/9479603 at N02/1814557771/in/album-72157602824219250/ https://www.flickr.com/photos/9479603 at N02/1814557653/in/album-72157602824219250/ https://www.flickr.com/photos/9479603 at N02/albums/72157602824219250/page2 My complete photo/movie history is at: https://www.flickr.com/photos/9479603 at N02/albums If you have any to add please pass them along. Ken On Thu, Feb 23, 2023 at 1:30 AM Lars Brinkhoff wrote: > Clem Cole wrote: > > MIT had a modified a.out format for the NU machine ports - that might > > have been called b.out. CMU had macho which again was an extended > > a.out but even more flexible. > > Digital Research's GEMDOS also used a modified a.out format (at least as > found on the Atari ST), pretty much the original PDP-11 format with > 32-bit addresses. > > [Shouldn't this go to the COFF mailing list... oh sorry.] > -- End of line JOB TERMINATED -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Fri Feb 24 01:13:27 2023 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 23 Feb 2023 10:13:27 -0500 (EST) Subject: [TUHS] Origins of the SGS (System Generation Software) and COFF (Common Object File Format) Message-ID: <20230223151327.8B2C818C0A5@mercury.lcs.mit.edu> > From: Clem Cole > MIT had a modified a.out format for the NU machine ports - that might > have been called b.out. Yes. Here's the man page output: http://ana-3.lcs.mit.edu/~jnc/tech/unix/help/b.out.lpt (I don't have the source for that, alas.) It's basically just a.out with 32-bit fields instead of 16-bit. I have a .h file for the format too, if anyone has any interest in it. It's all part of the MIT 68K workbench that used PCC (the source for all of which I do have). Noel From paul.winalski at gmail.com Fri Feb 24 02:49:29 2023 From: paul.winalski at gmail.com (Paul Winalski) Date: Thu, 23 Feb 2023 11:49:29 -0500 Subject: [TUHS] Origins of the SGS (System Generation Software) and COFF (Common Object File Format) In-Reply-To: References: Message-ID: On 2/22/23, Clem Cole wrote: >> >> - The System V manual has both this ar(1) version as well as the new >> COFF-supporting version. >> >> Why would ar(1) care? >> >> - Not sure if this implies the VAX ar format was expanded to support >> the COFF stuff for a little while until they decided on a new one or >> what. I can't think of any reason why ar(1) would care about the file format or internal contents of any of the modules it archives. ar(1) is a general archiving tool and can archive anything. It happens that the designers of ld(1) decided to use ar(1) to provide searchable object file libraries. ranlib(1) is a different matter. In order to index global symbols it has to understand the object file format(s) of the modules it is indexing. ranlib(1) most certainly would have to be taught to understand COFF. But not ar(1). >> and development software stuff until ELF comes along some time later. >> > Yep - never quite understood what the push for ELF was over COFF after all > the effort to drive COFF down people's throat. Note Microsoft "embraced > and extended" COFF as their format -- originally because of Xenix I > believe. > Someone like Paul W may have some insights on this and that was before > the 3B20. a.out was, as object file formats go, a throwback to the stone age from the get-go. Even the most primitive of IBM's link editors for System/360 supported arbitrary naming of object file sections and the ability for the programmer to arrange them in whatever order they wished. a.out's restriction to three sections (.text, .data, .bss) did manage to get the job done, and even (with ZMAGIC) could support demand-paged virtual memory, but only just. It became pretty clear in the 1980s that an object file format more powerful and flexible than a.out was needed. CMU developed their own object file format (MACH-O) for their MACH microkernel-based OS. It had up to 8 object file sections, and the section properties (e.g., read vs. read/wrkte; executable vs. data) were not tied to the section name as in a.out. A big step forward, although still primitive compared to the object formats of VAX/VMS and the IBM S/370 OSes. Apple MacOS X still uses MACH-O for object files and executables. Whatever its origins, what we now know as COFF (Common Object File Format) is, as its name implies, intended to be OS- and machine-independent. It still has a relatively small number of sections, albeit more than MACH-O. When Microsoft developed Windows NT, they needed to replace their own MZ executable format with something that could support shareable images and they decided to go with COFF for both object files and for executables. In typical Microsoft embrace-and-extend fashion, their Portable Executable and Common Object File Format (PECOFF) is a heavily modified version of COFF with lots of MS-specific extensions. When DEC's GEM back end was chosen as the optimizer and code generator for Microsoft C/C++ on Windows NT for the DEC Alpha chip, I had to add PECOFF support to GEM's existing COFF support (which was used by DEC's commercially sold compilers for Ultrix). My original idea was to put the PECOFF support under conditional compilation (#ifdef PECOFF), but the two formats were sufficiently different that I abandoned that Idea, cloned the existing COFF module, and then modified that to create a separate PECOFF module. ELF is far more flexible than either COFF, PECOFF, or MACH-O. Those three make a distinction between sections (the bits that eventually end up in memory) and the metadata pieces of an object file or executable (program headers, symbol table, debug information, etc.). In ELF, everything is a section, including the symbol table and the tables that direct the program loader in mapping shareable images into a process's memory. ELF was originally limited to 64K sections (section numbers were unsigned 16-bit), but there is now a scheme for 32-bit section numbers. The essentially unlimited number of sections is a big boon to languages such as C++, where grouped sections with a name-decoration convention provide a convenient way to support sharing of class definitions without requiring language-specific tweaks to the software development toolset. Contrast this with the Ada implementations I'm aware of, which have their own software development library systems layered on top of the conventional compiler/linker/archiver to insure that program modules are compiled and linked in the correct order. I don't know what the timeline for the invention of COFF was. It was already called COFF and in widespread use by the time I encountered it when we added Ultrix support to GEM. I think MACH-O predated COFF; it's certainly more primitive than COFF. MACH-O was probably early to mid-1980s. OS kernel bloat was a recognized problem at the time and microkernel-based OSes were all the rage. At DEC, Dave Cutler wrote a microkernel-based OS called VAXeln to replace VAX/VMS for real-time applications. A lot of concepts from VAXeln found their way into Windows NT when Cutler left DEC for Microsoft. -Paul W. From tuhs at tuhs.org Fri Feb 24 04:38:25 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 23 Feb 2023 18:38:25 +0000 Subject: [TUHS] Origins of the SGS (System Generation Software) and COFF (Common Object File Format) In-Reply-To: References: Message-ID: For the sake of timelines: June 1980 - Publication date on the front page of the 3.0 manual in which the utilities are still very much research for PDP-11 and 32V-ish for VAX where distinctions matter. June 1981 - Publication date on the front page of the 4.1 manual in which the man-pages very much refer to all of this as the "3B-20 object format" June 1982 - Publication date on the front page of the 5.0 manual by which point these same pages had been edited and extended to describe the "common object file format" Additions at the 1981 release include dump(1), list(1), and the ld-prefixed library routines for managing these object files. These likewise persist in 5.0, SysV, and beyond as COFF-related tools. So this puts the backstop of what would become COFF at at least '81. - Matt G. ------- Original Message ------- On Thursday, February 23rd, 2023 at 8:49 AM, Paul Winalski wrote: > On 2/22/23, Clem Cole clemc at ccc.com wrote: > > > > - The System V manual has both this ar(1) version as well as the new > > > COFF-supporting version. > > > > > > Why would ar(1) care? > > > > > > - Not sure if this implies the VAX ar format was expanded to support > > > the COFF stuff for a little while until they decided on a new one or > > > what. > > > I can't think of any reason why ar(1) would care about the file format > or internal contents of any of the modules it archives. ar(1) is a > general archiving tool and can archive anything. It happens that the > designers of ld(1) decided to use ar(1) to provide searchable object > file libraries. > > ranlib(1) is a different matter. In order to index global symbols it > has to understand the object file format(s) of the modules it is > indexing. ranlib(1) most certainly would have to be taught to > understand COFF. But not ar(1). > > > > and development software stuff until ELF comes along some time later. > > > > Yep - never quite understood what the push for ELF was over COFF after all > > the effort to drive COFF down people's throat. Note Microsoft "embraced > > and extended" COFF as their format -- originally because of Xenix I > > believe. > > Someone like Paul W may have some insights on this and that was before > > the 3B20. > > > a.out was, as object file formats go, a throwback to the stone age > from the get-go. Even the most primitive of IBM's link editors for > System/360 supported arbitrary naming of object file sections and the > ability for the programmer to arrange them in whatever order they > wished. a.out's restriction to three sections (.text, .data, .bss) > did manage to get the job done, and even (with ZMAGIC) could support > demand-paged virtual memory, but only just. > > It became pretty clear in the 1980s that an object file format more > powerful and flexible than a.out was needed. CMU developed their own > object file format (MACH-O) for their MACH microkernel-based OS. It > had up to 8 object file sections, and the section properties (e.g., > read vs. read/wrkte; executable vs. data) were not tied to the section > name as in a.out. A big step forward, although still primitive > compared to the object formats of VAX/VMS and the IBM S/370 OSes. > Apple MacOS X still uses MACH-O for object files and executables. > > Whatever its origins, what we now know as COFF (Common Object File > Format) is, as its name implies, intended to be OS- and > machine-independent. It still has a relatively small number of > sections, albeit more than MACH-O. When Microsoft developed Windows > NT, they needed to replace their own MZ executable format with > something that could support shareable images and they decided to go > with COFF for both object files and for executables. In typical > Microsoft embrace-and-extend fashion, their Portable Executable and > Common Object File Format (PECOFF) is a heavily modified version of > COFF with lots of MS-specific extensions. When DEC's GEM back end was > chosen as the optimizer and code generator for Microsoft C/C++ on > Windows NT for the DEC Alpha chip, I had to add PECOFF support to > GEM's existing COFF support (which was used by DEC's commercially sold > compilers for Ultrix). My original idea was to put the PECOFF support > under conditional compilation (#ifdef PECOFF), but the two formats > were sufficiently different that I abandoned that Idea, cloned the > existing COFF module, and then modified that to create a separate > PECOFF module. > > ELF is far more flexible than either COFF, PECOFF, or MACH-O. Those > three make a distinction between sections (the bits that eventually > end up in memory) and the metadata pieces of an object file or > executable (program headers, symbol table, debug information, etc.). > In ELF, everything is a section, including the symbol table and the > tables that direct the program loader in mapping shareable images into > a process's memory. ELF was originally limited to 64K sections > (section numbers were unsigned 16-bit), but there is now a scheme for > 32-bit section numbers. The essentially unlimited number of sections > is a big boon to languages such as C++, where grouped sections with a > name-decoration convention provide a convenient way to support sharing > of class definitions without requiring language-specific tweaks to the > software development toolset. Contrast this with the Ada > implementations I'm aware of, which have their own software > development library systems layered on top of the conventional > compiler/linker/archiver to insure that program modules are compiled > and linked in the correct order. > > I don't know what the timeline for the invention of COFF was. It was > already called COFF and in widespread use by the time I encountered it > when we added Ultrix support to GEM. I think MACH-O predated COFF; > it's certainly more primitive than COFF. MACH-O was probably early to > mid-1980s. OS kernel bloat was a recognized problem at the time and > microkernel-based OSes were all the rage. At DEC, Dave Cutler wrote a > microkernel-based OS called VAXeln to replace VAX/VMS for real-time > applications. A lot of concepts from VAXeln found their way into > Windows NT when Cutler left DEC for Microsoft. > > -Paul W. From imp at bsdimp.com Fri Feb 24 05:37:33 2023 From: imp at bsdimp.com (Warner Losh) Date: Thu, 23 Feb 2023 12:37:33 -0700 Subject: [TUHS] Origins of the SGS (System Generation Software) and COFF (Common Object File Format) In-Reply-To: <7wcz60x5ae.fsf@junk.nocrew.org> References: <7wcz60x5ae.fsf@junk.nocrew.org> Message-ID: On Wed, Feb 22, 2023 at 11:30 PM Lars Brinkhoff wrote: > Clem Cole wrote: > > MIT had a modified a.out format for the NU machine ports - that might > > have been called b.out. CMU had macho which again was an extended > > a.out but even more flexible. > > Digital Research's GEMDOS also used a modified a.out format (at least as > found on the Atari ST), pretty much the original PDP-11 format with > 32-bit addresses. > MIT's PCC ports to various micros, especailly x86, also used b.out that was quite similar to a.out. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Fri Feb 24 06:40:30 2023 From: paul.winalski at gmail.com (Paul Winalski) Date: Thu, 23 Feb 2023 15:40:30 -0500 Subject: [TUHS] Origins of the SGS (System Generation Software) and COFF (Common Object File Format) In-Reply-To: References: Message-ID: One property of a.out is that the format of an executable image is identical to that of an object file. One could write an assembly program that was self-contained and did not need to be linked to any other modules, run that through as(1). The resulting a.out file would be executable. No need to involve ld(1). MACH-O retained this concept of supporting self-contained object files as executables. COFF departed from that tradition. A COFF (or PECOFF) executable requires a data structure in the file called the optional header that contains important instructions to the program loader. This second header is "optional" only in the sense that non-executable object files do not have one. The optional header is created by ld(1). I'm almost certain that versions of as(1) that generate COFF output do not generate an optional header. In ELF, executable images have several sections such as the program header table section that contain the information present in COFF's optional header. Traditionally, operating systems such as IBM's OS for System/360/370/Z and DEC's VMS have very different formats for object files and executable programs. OpenVMS for Itanium and x86-64 use ELF for both objects and executables--a departure from the practice used on VAX and Alpha. -Paul W. From pnr at planet.nl Fri Feb 24 07:37:50 2023 From: pnr at planet.nl (Paul Ruizendaal) Date: Thu, 23 Feb 2023 22:37:50 +0100 Subject: [TUHS] Origins of the SGS (System Generation Software) and COFF (Common Object File Format) Message-ID: <76DBD7F1-0419-4CF6-9249-866B0E11C73E@planet.nl> > Date: Thu, 23 Feb 2023 18:38:25 +0000 > Subject: [TUHS] Re: Origins of the SGS (System Generation Software) > and COFF (Common Object File Format) > > For the sake of timelines: > > June 1980 - Publication date on the front page of the 3.0 manual in which the utilities are still very much research for PDP-11 and 32V-ish for VAX where distinctions matter. > > June 1981 - Publication date on the front page of the 4.1 manual in which the man-pages very much refer to all of this as the "3B-20 object format" > > June 1982 - Publication date on the front page of the 5.0 manual by which point these same pages had been edited and extended to describe the "common object file format" > > Additions at the 1981 release include dump(1), list(1), and the ld-prefixed library routines for managing these object files. These likewise persist in 5.0, SysV, and beyond as COFF-related tools. > > So this puts the backstop of what would become COFF at at least '81. > > - Matt G. The surviving source code for SysV R2 supports this timeline: - The header files (start from https://github.com/ryanwoodsmall/oldsysv/blob/master/sysvr2-vax/src/head/a.out.h) have dates of late ’82, early ’83. - The source for exec() has a comment that refers to the 4xx magic formats as “pre 5.0 stuff”. - The COFF format headers are #ifdef’ed for the 3B series. Interestingly, the lowest magic numbers in the 5xx series are not for the 3B, but for the “Basic-16” and for the “x86”. That led me to this paper: https://www.bell-labs.com/usr/dmr/www/otherports/newp.pdf It seems that the roots of COFF go back to the initial portability effort for V7 and in particular the 8086 port (which was done in 1978 according to the paper). From tuhs at tuhs.org Fri Feb 24 08:11:31 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 23 Feb 2023 22:11:31 +0000 Subject: [TUHS] Origins of the SGS (System Generation Software) and COFF (Common Object File Format) In-Reply-To: <76DBD7F1-0419-4CF6-9249-866B0E11C73E@planet.nl> References: <76DBD7F1-0419-4CF6-9249-866B0E11C73E@planet.nl> Message-ID: <1dhgF9hHhWQpilH7FnvrLre83BKzisxzxjZYUJKw00-xBa7PStIxJNFrO_zoGobWMPLBHTacFioWqbqPXGbEeWHXw-GTmTq5MeKEyiA38iE=@protonmail.com> Basic-16......augh I feel like I actually saw a Basic-16 eval board of some kind pop up in auctions in my documentation search the past few years. I thought about bidding but I didn't, could've had some cool hardware to reply back with pictures of. Lesson learned, if something catches my attention enough I should probably research it more closely. Thanks for the article link, that pretty much captures the sort of "origin story" I was seeking out on both the tools and format. I now realize I could've known this already but didn't read far enough in the '84 Bell journal, I've got copies of that and the '78 one, I forget how many juicy details are in there that didn't make it into manuals and technical reports. All the more reason to go back through and take some notes... - Matt G. ------- Original Message ------- On Thursday, February 23rd, 2023 at 1:37 PM, Paul Ruizendaal wrote: > > Date: Thu, 23 Feb 2023 18:38:25 +0000 > > Subject: [TUHS] Re: Origins of the SGS (System Generation Software) > > and COFF (Common Object File Format) > > > > For the sake of timelines: > > > > June 1980 - Publication date on the front page of the 3.0 manual in which the utilities are still very much research for PDP-11 and 32V-ish for VAX where distinctions matter. > > > > June 1981 - Publication date on the front page of the 4.1 manual in which the man-pages very much refer to all of this as the "3B-20 object format" > > > > June 1982 - Publication date on the front page of the 5.0 manual by which point these same pages had been edited and extended to describe the "common object file format" > > > > Additions at the 1981 release include dump(1), list(1), and the ld-prefixed library routines for managing these object files. These likewise persist in 5.0, SysV, and beyond as COFF-related tools. > > > > So this puts the backstop of what would become COFF at at least '81. > > > > - Matt G. > > > > The surviving source code for SysV R2 supports this timeline: > - The header files (start from https://github.com/ryanwoodsmall/oldsysv/blob/master/sysvr2-vax/src/head/a.out.h) have dates of late ’82, early ’83. > - The source for exec() has a comment that refers to the 4xx magic formats as “pre 5.0 stuff”. > - The COFF format headers are #ifdef’ed for the 3B series. > > Interestingly, the lowest magic numbers in the 5xx series are not for the 3B, but for the “Basic-16” and for the “x86”. That led me to this paper: > > https://www.bell-labs.com/usr/dmr/www/otherports/newp.pdf > > It seems that the roots of COFF go back to the initial portability effort for V7 and in particular the 8086 port (which was done in 1978 according to the paper). From tuhs at tuhs.org Fri Feb 24 10:07:33 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 24 Feb 2023 00:07:33 +0000 Subject: [TUHS] Origins of the SGS (System Generation Software) and COFF (Common Object File Format) In-Reply-To: <1dhgF9hHhWQpilH7FnvrLre83BKzisxzxjZYUJKw00-xBa7PStIxJNFrO_zoGobWMPLBHTacFioWqbqPXGbEeWHXw-GTmTq5MeKEyiA38iE=@protonmail.com> References: <76DBD7F1-0419-4CF6-9249-866B0E11C73E@planet.nl> <1dhgF9hHhWQpilH7FnvrLre83BKzisxzxjZYUJKw00-xBa7PStIxJNFrO_zoGobWMPLBHTacFioWqbqPXGbEeWHXw-GTmTq5MeKEyiA38iE=@protonmail.com> Message-ID: Correction, I was able to track it down, this is what I was thinking of, not a Basic-16 board: https://www.ebay.com/itm/225277136492?hash=item3473904e6c:g:Mx8AAOSwxl9jiPUr&amdata=enc%3AAQAHAAAAoD7DdgbGGFS1yXoVSRPovN62X0RChnzorSRATDa223OYNsLVsFrfS6CoAzjlT18M5o6A4V2IGayHcmBqXNMyu8Y3vmiprgMCbbc%2BnNocVmkV6Z2qy83ys05tFWKt2GONSWjerKYUdn1l8n%2BhjfD2sCK0qT6Yk02OMv8jr0YZJN22ghLXovR5IC8q%2BqmgcJWXgjK0jH9H%2FGwMHRVAyTTXC9A%3D%7Ctkp%3ABk9SR8ie24vQYQ I didn't expect to see that still up, for those who don't want to follow the link, this is a link to a Bell Labs MAC-8 "Mactutor". Still tempting, if it's still bumping around on eBay after my move I might just have to spring for it. - Matt G. ------- Original Message ------- On Thursday, February 23rd, 2023 at 2:11 PM, segaloco via TUHS wrote: > Basic-16......augh I feel like I actually saw a Basic-16 eval board of some kind pop up in auctions in my documentation search the past few years. I thought about bidding but I didn't, could've had some cool hardware to reply back with pictures of. Lesson learned, if something catches my attention enough I should probably research it more closely. > > Thanks for the article link, that pretty much captures the sort of "origin story" I was seeking out on both the tools and format. I now realize I could've known this already but didn't read far enough in the '84 Bell journal, I've got copies of that and the '78 one, I forget how many juicy details are in there that didn't make it into manuals and technical reports. All the more reason to go back through and take some notes... > > - Matt G. > > ------- Original Message ------- > On Thursday, February 23rd, 2023 at 1:37 PM, Paul Ruizendaal pnr at planet.nl wrote: > > > > > > Date: Thu, 23 Feb 2023 18:38:25 +0000 > > > Subject: [TUHS] Re: Origins of the SGS (System Generation Software) > > > and COFF (Common Object File Format) > > > > > > For the sake of timelines: > > > > > > June 1980 - Publication date on the front page of the 3.0 manual in which the utilities are still very much research for PDP-11 and 32V-ish for VAX where distinctions matter. > > > > > > June 1981 - Publication date on the front page of the 4.1 manual in which the man-pages very much refer to all of this as the "3B-20 object format" > > > > > > June 1982 - Publication date on the front page of the 5.0 manual by which point these same pages had been edited and extended to describe the "common object file format" > > > > > > Additions at the 1981 release include dump(1), list(1), and the ld-prefixed library routines for managing these object files. These likewise persist in 5.0, SysV, and beyond as COFF-related tools. > > > > > > So this puts the backstop of what would become COFF at at least '81. > > > > > > - Matt G. > > > > The surviving source code for SysV R2 supports this timeline: > > - The header files (start from https://github.com/ryanwoodsmall/oldsysv/blob/master/sysvr2-vax/src/head/a.out.h) have dates of late ’82, early ’83. > > - The source for exec() has a comment that refers to the 4xx magic formats as “pre 5.0 stuff”. > > - The COFF format headers are #ifdef’ed for the 3B series. > > > > Interestingly, the lowest magic numbers in the 5xx series are not for the 3B, but for the “Basic-16” and for the “x86”. That led me to this paper: > > > > https://www.bell-labs.com/usr/dmr/www/otherports/newp.pdf > > > > It seems that the roots of COFF go back to the initial portability effort for V7 and in particular the 8086 port (which was done in 1978 according to the paper). From kevin.bowling at kev009.com Fri Feb 24 10:10:55 2023 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Thu, 23 Feb 2023 17:10:55 -0700 Subject: [TUHS] X Windows System Design Principles, a lecture by Jim Gettys Message-ID: https://www.youtube.com/watch?v=KdmNHM9BKY0 From will.senn at gmail.com Fri Feb 24 10:23:13 2023 From: will.senn at gmail.com (Will Senn) Date: Thu, 23 Feb 2023 18:23:13 -0600 Subject: [TUHS] X Windows System Design Principles, a lecture by Jim Gettys In-Reply-To: References: Message-ID: <300901d7-b49a-42a0-1550-c31f03b4717e@gmail.com> On 2/23/23 6:10 PM, Kevin Bowling wrote: > https://www.youtube.com/watch?v=KdmNHM9BKY0 Nice. It's fun to see the dual monitor CRT setup - gives me flashbacks to when I dropped on on my leg. Thankfully, we're doing LEDs and whatnot these days, no big whoop dropping them on your leg and the missing laserbeams gotta be healthier. Thanks for the timely post. I've been studying X of late and was wondering what a Dec windows setup looked like compared to Motif and twm which are available still. I remember liking Sun's WM, but it's been ages (1995-1996) since I used it. I see he was rockin' the fuschia yuck, techies shouldn't be allowed to set colors. I don't think the Sun had color, or if it did, it was pretty tame - shades of muted tones or something. -will -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Fri Feb 24 16:01:18 2023 From: lars at nocrew.org (Lars Brinkhoff) Date: Fri, 24 Feb 2023 06:01:18 +0000 Subject: [TUHS] X Windows System Design Principles, a lecture by Jim Gettys In-Reply-To: (Kevin Bowling's message of "Thu, 23 Feb 2023 17:10:55 -0700") References: Message-ID: <7wo7pjvbyp.fsf@junk.nocrew.org> Speaking of which, I recently made a VAXstation 100 emulator. Jim Gettys caught wind of it and says he has an archive of old X versions, and he'd like to see them run on the emulator. So far, the oldest available online is X10R3. Quick recap of X prehistory: Stanford's VGTS on V -> W on V -> W ported to VS100 at DEC -> W adopted by CLU group at MIT -> W hacked into X -> X adpoted by Project Athena -> X adopted by DEC and workstation vendors. From arnold at skeeve.com Fri Feb 24 22:45:16 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 24 Feb 2023 05:45:16 -0700 Subject: [TUHS] Origins of the SGS (System Generation Software) and COFF (Common Object File Format) In-Reply-To: References: Message-ID: <202302241245.31OCjGrb015310@freefriends.org> Paul Winalski wrote: > I can't think of any reason why ar(1) would care about the file format > or internal contents of any of the modules it archives. ar(1) is a > general archiving tool and can archive anything. It happens that the > designers of ld(1) decided to use ar(1) to provide searchable object > file libraries. > > ranlib(1) is a different matter. In order to index global symbols it > has to understand the object file format(s) of the modules it is > indexing. ranlib(1) most certainly would have to be taught to > understand COFF. But not ar(1). You are correct that ar(1) was originally just an archiver. However, the System V people built ranlib into it; the .a file for a library has a sort of hidden extra member that is the list of symbols in the archive. With tar and cpio, ar apparently fell out of use as a general archiver, and today it's only used for libraries of relocatable object files. Arnold From tuhs at tuhs.org Fri Feb 24 23:13:45 2023 From: tuhs at tuhs.org (Arno Griffioen via TUHS) Date: Fri, 24 Feb 2023 14:13:45 +0100 Subject: [TUHS] Origins of the SGS (System Generation Software) and COFF (Common Object File Format) In-Reply-To: <202302241245.31OCjGrb015310@freefriends.org> References: <202302241245.31OCjGrb015310@freefriends.org> Message-ID: On Fri, Feb 24, 2023 at 05:45:16AM -0700, arnold at skeeve.com wrote: > With tar and cpio, ar apparently fell out of use as a general > archiver, and today it's only used for libraries of relocatable > object files. 'ar' is alive and well as the archive format for .deb files though, so it could be argued that it's actually hugely in use as an archiver all across the world :) Bye, Arno. From skogtun at gmail.com Sat Feb 25 00:01:04 2023 From: skogtun at gmail.com (Harald Arnesen) Date: Fri, 24 Feb 2023 15:01:04 +0100 Subject: [TUHS] Origins of the SGS (System Generation Software) and COFF (Common Object File Format) In-Reply-To: <202302241245.31OCjGrb015310@freefriends.org> References: <202302241245.31OCjGrb015310@freefriends.org> Message-ID: arnold at skeeve.com [24/02/2023 13.45]: > With tar and cpio, ar apparently fell out of use as a general > archiver, and today it's only used for libraries of relocatable > object files. And Debian/Devuan .deb packages. -- Hilsen Harald Слава Україні! From rich.salz at gmail.com Sat Feb 25 03:01:28 2023 From: rich.salz at gmail.com (Rich Salz) Date: Fri, 24 Feb 2023 12:01:28 -0500 Subject: [TUHS] Origins of the SGS (System Generation Software) and COFF (Common Object File Format) In-Reply-To: References: <7wcz60x5ae.fsf@junk.nocrew.org> Message-ID: > MIT's PCC ports to various micros, especailly x86, also used b.out that > was quite similar to a.out. > That was a cross-compiler, right? If so, I remember going over to MIT-LCS and picking up a copy of the sources for the compiler and the MIT PC/IP implementation. I had to show a copy of my ATT source license to the secretary, who made a copy of a 9track tape for me.She was a hoot: dressed like a punk, and we takled about not working for defense companies. We were then able to build and install various TCP/IP utilities on our PC-AT machines running early Windows releases. This was probably early 1980's. I think the PC/IP code was based on David Clark's upcalls idea[1]. It later became the basis for FTP software, which then died when Microsoft added TCP to windows. [1] https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=e7c6da568d15a3ea50854dbd951c1d6394502a15 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Sat Feb 25 12:07:01 2023 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 25 Feb 2023 13:07:01 +1100 (EST) Subject: [TUHS] Origins of the SGS (System Generation Software) and COFF (Common Object File Format) In-Reply-To: References: Message-ID: On Thu, 23 Feb 2023, Paul Winalski wrote: > a.out was, as object file formats go, a throwback to the stone age from > the get-go. Even the most primitive of IBM's link editors for > System/360 supported arbitrary naming of object file sections and the > ability for the programmer to arrange them in whatever order they > wished. a.out's restriction to three sections (.text, .data, .bss) did > manage to get the job done, and even (with ZMAGIC) could support > demand-paged virtual memory, but only just. That may be so, but those guys didn't exactly have the resources of IBM behind them... And I wonder how many people here know the significance of the "407" magic number? -- Dave From lars at nocrew.org Sat Feb 25 17:24:37 2023 From: lars at nocrew.org (Lars Brinkhoff) Date: Sat, 25 Feb 2023 07:24:37 +0000 Subject: [TUHS] Early X (or W?) sighting from 1984 Message-ID: <7w1qmeus0a.fsf@junk.nocrew.org> I found this 1984 video about MIT's Project Athena. A few VAXstation 100 are visible running some demos in a windowing system. Nothing exciting unfortunately, just a few seconds and no details visible. Since X was started in 1984, it could be a very early version we see here. I asked Jim Gettys, and he suggested it could also be W since it was apparently used before X in Project Athena. https://youtu.be/tG7i7HCD9g0?t=28 I checked the xdemo director in X10R3 (earliest available so far) for a match against the circle demo, but all samples are written in CLU... From clemc at ccc.com Sun Feb 26 01:30:25 2023 From: clemc at ccc.com (Clem Cole) Date: Sat, 25 Feb 2023 10:30:25 -0500 Subject: [TUHS] Origins of the SGS (System Generation Software) and COFF (Common Object File Format) In-Reply-To: References: Message-ID: On Fri, Feb 24, 2023 at 9:07 PM Dave Horsfall wrote: > On Thu, 23 Feb 2023, Paul Winalski wrote: > > > a.out was, as object file formats go, a throwback to the stone age from > > the get-go. Even the most primitive of IBM's link editors for > > System/360 supported arbitrary naming of object file sections and the > > ability for the programmer to arrange them in whatever order they > > wished. a.out's restriction to three sections (.text, .data, .bss) did > > manage to get the job done, and even (with ZMAGIC) could support > > demand-paged virtual memory, but only just. > > That may be so, but those guys didn't exactly have the resources of > IBM behind them... > A reasonable point, but it was more Ken, Dennis, and the team did what >>they needed<< and it was good enough for a long time. The IBM link editors needed all that back in the day. As more and more "modern" languages came into being, it was not until about 6th editions that difficulties of not having an expandable object format and better linker began to show, and as Paul says, until the support for demand paging that a.out was really stressed. Please correct me if I'm misinformed, but Paul, of course, had to support the DEC language tools on Unix, which had come from systems that had a more flexible format (the solution for Ultrix IICR was to move a flavor of the VMS linker to UNIX for object file and just a.out for execution). So he lived the difficulties/shortcomings. A valid argument is Tanndenbaum's compiler toolkit survived with a.out, and he supported many of the same language targets that DEC did. Andy and crew did their own assemblers, does anyone remember if they supplied a new linker and object format? That would make Paul's point more powerful -> the languages people wanted something more. My point, the UNIX developers built what they needed and built that well. Their format worked with their development primary language/tool (a.k.a. C) and they even made it work with an f77 implementation. So it is a little hard to knock them too much -- it was not part of the original design spec. But as Matt has discussed in his digging through things, it does look like as the AT&T languages team started to run into some of the same barriers, they started to move to a new format. And I wonder how many people here know the significance of the "407" magic > number? > Today, few and fewer I fear. For those do not, please see page 4-33 of the 1975/76 DEC PDP-11 Processor Handbook and think about boot blocks. 🍺 ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Sun Feb 26 03:29:15 2023 From: paul.winalski at gmail.com (Paul Winalski) Date: Sat, 25 Feb 2023 12:29:15 -0500 Subject: [TUHS] Origins of the SGS (System Generation Software) and COFF (Common Object File Format) In-Reply-To: References: Message-ID: On 2/25/23, Clem Cole wrote: > > The IBM link > editors needed all that back in the day. One of the complications of executable images was the address space layout for OS/360. There was no virtual memory. The low part of the address space was where the operating system kernel (supervisor, in IBM-speak) lived. Each of what we now call processes was assigned a contiguous portion of the remaining address space (this was called a partition). As executable program retained the relocations that had been applied by the linker so that the program loader could adjust the addresses in the executable depending on which partition it was being loaded into. This made things more complicated for the link editor. The OS/360 link editor also doubled as a patch tool. The link editor was capable of taking an executable and a set of new versions for some object modules, un-linking those modules, and replacing them with the new versions, adjusting all relocations accordingly. > Please correct me if I'm misinformed, but Paul, of course, had to support > the DEC language tools on Unix, which had come from systems that had a more > flexible format (the solution for Ultrix IICR was to move a flavor of the > VMS linker to UNIX for object file and just a.out for execution). VAX Fortran for Ultrix was a port of the VAX/VMS Fortran compiler and runtime to Ultrix. There were two big problems, object-file-wise. First, VAX Fortran used many of the advanced features of the VMS object language. To generate a.out directly, those chores would have to be done in the compiler's code generator. The runtime library had an even worse problem. One innovative feature of VMS was that it had a very robust ABI that could support every programming language then known, and the compiler development teams were required to adhere to this ABI and to provide language extensions were necessary to support all of the ABI's features. The result was that calling subroutines written in a different language was dead easy. It didn't matter which programming language you used. The developers of the Fortran runtime took full advantage of that, and it contained routines written in several languages. This meant that we would either need to add a.out support to the code generators of all of those compilers (there was no common back end in those days) or write a VMS .obj-to-a.out translator. In the end we decided that the easiest solution to both problems was to add a.out support to the VMS linker and to port it to Ultrix. The result was lk(1), a linker that accepted either VMS .obj or a.out as input and generated an a.out executable. > My point, the UNIX developers built what they needed and built that well. Amen to that. That observation applies to a lot of the design of Unix. > Their format worked with their development primary language/tool (a.k.a. C) > and they even made it work with an f77 implementation. So it is a little > hard to knock them too much -- it was not part of the original design spec. They did what was right given their circumstances and resources. I know of two major operating system development efforts at DEC, OFIS and MICA, that illustrate what happens if you try to take the opposite tack. Their thinking was, "Gee, we have a lot to do and a short schedule. I know--let's invent a new programming language and write a compiler for it." Both ended up being disastrous examples of Second System Syndrome. > And I wonder how many people here know the significance of the "407" magic >> number? >> > Today, few and fewer I fear. For those do not, please see page 4-33 of the > 1975/76 DEC PDP-11 Processor Handbook and think about boot blocks. 🍺 > ᐧ Cute. -Paul W. From arnold at skeeve.com Sun Feb 26 05:28:33 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sat, 25 Feb 2023 12:28:33 -0700 Subject: [TUHS] Origins of the SGS (System Generation Software) and COFF (Common Object File Format) In-Reply-To: References: <202302241245.31OCjGrb015310@freefriends.org> Message-ID: <202302251928.31PJSXc1004140@freefriends.org> Arno Griffioen via TUHS wrote: > On Fri, Feb 24, 2023 at 05:45:16AM -0700, arnold at skeeve.com wrote: > > With tar and cpio, ar apparently fell out of use as a general > > archiver, and today it's only used for libraries of relocatable > > object files. > > 'ar' is alive and well as the archive format for .deb files though, so it > could be argued that it's actually hugely in use as an archiver all across > the world :) > > Bye, Arno. I wasn't aware of that. Thanks. From steffen at sdaoden.eu Sun Feb 26 05:34:09 2023 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Sat, 25 Feb 2023 20:34:09 +0100 Subject: [TUHS] Origins of the SGS (System Generation Software) and COFF (Common Object File Format) In-Reply-To: <202302251928.31PJSXc1004140@freefriends.org> References: <202302241245.31OCjGrb015310@freefriends.org> <202302251928.31PJSXc1004140@freefriends.org> Message-ID: <20230225193409.wspfB%steffen@sdaoden.eu> arnold at skeeve.com wrote in <202302251928.31PJSXc1004140 at freefriends.org>: |Arno Griffioen via TUHS wrote: |> On Fri, Feb 24, 2023 at 05:45:16AM -0700, arnold at skeeve.com wrote: |>> With tar and cpio, ar apparently fell out of use as a general |>> archiver, and today it's only used for libraries of relocatable |>> object files. |> |> 'ar' is alive and well as the archive format for .deb files though, \ |> so it |> could be argued that it's actually hugely in use as an archiver all \ |> across |> the world :) |> |> Bye, Arno. | |I wasn't aware of that. Thanks. It is also used during the build phase of some programs (groff last i looked). Ie they build their support objects, and instead of having make rules with $(OBJ) they simply link against the library. (I have not looked whether they build with -fPIC / -fPIE, to outrule your "relocatable", that is.) --End of <202302251928.31PJSXc1004140 at freefriends.org> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From tuhs at tuhs.org Sun Feb 26 05:48:45 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sat, 25 Feb 2023 19:48:45 +0000 Subject: [TUHS] Any Bell 8-bit UNIX Efforts? Message-ID: So in working on an unrelated 6502 project, I got to wondering about UNIX on it and other 8-bits. Did some Googling, and while I was able to turn up some attempts at UNIX-likes on 6502 as well as Z80, the only one I found that might have some Bell connection is "uNIX" as documented here: https://bitsavers.org/pdf/uNIX/uNIX_Jan82.pdf A forum post I read suggested those involved were some former Bell folks from NJ. In any case, this begs the question for me: Were there ever any serious attempts at an 8-bit UNIX in the labs or Bell System at large? Certainly it would've provided quite the challenge without much return compared with 16 and 32-bit efforts, but does anyone know if, say, an LSX/Mini-UNIX-ish attempt was ever made at the 6502, Z80, or other 8-bits? Thanks all! - Matt G. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at cuzuco.com Sun Feb 26 06:14:51 2023 From: tuhs at cuzuco.com (Brian Walden) Date: Sat, 25 Feb 2023 15:14:51 -0500 (EST) Subject: [TUHS] Origins of the SGS (System Generation Software) and COFF (Common Object File Format) Message-ID: <202302252015.31PKEpDi026986@cuzuco.com> It was originaly 205. See A.OUT(V) (the first page) at https://www.bell-labs.com/usr/dmr/www/man51.pdf it was documented as to why. The header always contains 6 words: 1 "br .+14" instruction (205(8)) 2 The size of the program text 3 The size of the symbol table 4 The size of the relocation bits area 5 The size of a data area 6 A zero word (unused at present) I always found this so elegant in it's simplicity. Just load and start execution at the start (simplifies exec(2) in the kernel) I always wondered if this has done anywhere else before, or invenetd first in unix. Theres was also a recent discussion of ar(1). That pdf also explains its magic number a few pages later. It was simply choosen because it seemed unique. A file produced by ar has a "magic number" at the start, followed by the constituent files, each preceded by a file header. The magic number is -147(10), or 177555(8) (it was chosen to be unlikely to occur anywhere else). -Brian On Sat, 25 Feb 2023, Dave Horsfall wrote: > On Thu, 23 Feb 2023, Paul Winalski wrote: > > > a.out was, as object file formats go, a throwback to the stone age from > > the get-go. Even the most primitive of IBM's link editors for > > System/360 supported arbitrary naming of object file sections and the > > ability for the programmer to arrange them in whatever order they > > wished. a.out's restriction to three sections (.text, .data, .bss) did > > manage to get the job done, and even (with ZMAGIC) could support > > demand-paged virtual memory, but only just. > > That may be so, but those guys didn't exactly have the resources of > IBM behind them... > > And I wonder how many people here know the significance of the "407" magic > number? > > -- Dave From pnr at planet.nl Sun Feb 26 07:31:22 2023 From: pnr at planet.nl (Paul Ruizendaal) Date: Sat, 25 Feb 2023 22:31:22 +0100 Subject: [TUHS] Early GUI on Linux Message-ID: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> I think discussion of early Linux is in scope for this list, after all that is 30 years ago. Warren, if that is a mis-assumption please slap my wrist. Following on from the recent discussion of early workstations and windowing systems, I’m wondering about early windowing on Linux. I only discovered Linux in the later nineties (Red Hat 4.x I think), and by that time Linux already seemed to have settled on Xfree86. At that time svgalib was still around but already abandoned. By 1993 even student class PC hardware already outperformed the workstations of the early/mid eighties, memory was much more abundant and pixels were no longer bits but bytes (making drawing easier). Also, early Linux was (I think) more local machine oriented, not LAN oriented. Maybe a different system than X would have made sense. In short, I could imagine a frame buffer device and a compositor for top-level windows (a trail that had been pioneered by Oriel half a decade before), a declarative widget set inspired by the contemporary early browsers and the earlier NeWS, etc. Yet nothing like that happened as far as I know. I vaguely recall an OS from the late 90’s that mixed Linux with a partly in-kernel GUI called “Berlin” or something like that, but I cannot find any trace of that today, so maybe I misremember. So here are a few things that I am interested in and folks on this list might remember: - were there any window systems popular on early Linux other than X? - was there any discussion of alternatives to X? - was there any discussion of what kernel support for graphics was appropriate? From crossd at gmail.com Sun Feb 26 08:49:36 2023 From: crossd at gmail.com (Dan Cross) Date: Sat, 25 Feb 2023 17:49:36 -0500 Subject: [TUHS] Early GUI on Linux In-Reply-To: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> Message-ID: On Sat, Feb 25, 2023 at 4:31 PM Paul Ruizendaal wrote: > I think discussion of early Linux is in scope for this list, after all that is 30 years ago. Warren, if that is a mis-assumption please slap my wrist. > > Following on from the recent discussion of early workstations and windowing systems, I’m wondering about early windowing on Linux. I only discovered Linux in the later nineties (Red Hat 4.x I think), and by that time Linux already seemed to have settled on Xfree86. At that time svgalib was still around but already abandoned. > > By 1993 even student class PC hardware already outperformed the workstations of the early/mid eighties, memory was much more abundant and pixels were no longer bits but bytes (making drawing easier). Also, early Linux was (I think) more local machine oriented, not LAN oriented. Maybe a different system than X would have made sense. > > In short, I could imagine a frame buffer device and a compositor for top-level windows (a trail that had been pioneered by Oriel half a decade before), a declarative widget set inspired by the contemporary early browsers and the earlier NeWS, etc. Yet nothing like that happened as far as I know. I vaguely recall an OS from the late 90’s that mixed Linux with a partly in-kernel GUI called “Berlin” or something like that, but I cannot find any trace of that today, so maybe I misremember. > > So here are a few things that I am interested in and folks on this list might remember: > > - were there any window systems popular on early Linux other than X? Not really. The context at the time was that a lot of folks (well, me) wanted a workstation-like experience, but on a machine we could individually afford. That basically meant bringing over most of the staples one was used to on a (Sun|DEC|HP|SGI) machine, which almost universally implied X as a prerequisite. Folks wanted to be able to use their customized shell startup files and so on, but also their window manager configurations and the like. That said, it was my impression that it took a year or two for X on Linux to really get going, and further that it was really flakey for a while afterwards; you had to have just the right combination of video adapter, monitor, mouse, etc. Before that, I'm sure people played around with mgr and stuff like that, but I don't think anyone really _wanted_ anything substantially different. > - was there any discussion of alternatives to X? Not really. Again, the context is very important here: when Linux started to become a thing, a lot of people who started working with it already had experience with "real" computers, but those machines were not cheap. It was rare, but some people could afford workstation-class hardware at home; most could not. If you weren't independently wealthy, you made do with a PC or something. But the idea that you could replicate your work or research computing environment home was tremendously exciting. Again, more often than not, that meant X. > - was there any discussion of what kernel support for graphics was appropriate? I have a vague memory that most people wanted to keep this out of the kernel to the extent possible. X did most of the heavy lifting in userspace, writing to a memory-mapped framebuffer; if you could do the minimum to set that up and mmap it into the X server process, you were good to go. But I may be wrong on this. - Dan C. From imp at bsdimp.com Sun Feb 26 10:39:13 2023 From: imp at bsdimp.com (Warner Losh) Date: Sat, 25 Feb 2023 17:39:13 -0700 Subject: [TUHS] Early GUI on Linux In-Reply-To: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> Message-ID: On Sat, Feb 25, 2023, 2:31 PM Paul Ruizendaal wrote: > > I think discussion of early Linux is in scope for this list, after all > that is 30 years ago. Warren, if that is a mis-assumption please slap my > wrist. > > Following on from the recent discussion of early workstations and > windowing systems, I’m wondering about early windowing on Linux. I only > discovered Linux in the later nineties (Red Hat 4.x I think), and by that > time Linux already seemed to have settled on Xfree86. At that time svgalib > was still around but already abandoned. > > By 1993 even student class PC hardware already outperformed the > workstations of the early/mid eighties, memory was much more abundant and > pixels were no longer bits but bytes (making drawing easier). Also, early > Linux was (I think) more local machine oriented, not LAN oriented. Maybe a > different system than X would have made sense. > > In short, I could imagine a frame buffer device and a compositor for > top-level windows (a trail that had been pioneered by Oriel half a decade > before), a declarative widget set inspired by the contemporary early > browsers and the earlier NeWS, etc. Yet nothing like that happened as far > as I know. I vaguely recall an OS from the late 90’s that mixed Linux with > a partly in-kernel GUI called “Berlin” or something like that, but I cannot > find any trace of that today, so maybe I misremember. > > So here are a few things that I am interested in and folks on this list > might remember: > > - were there any window systems popular on early Linux other than X? No. Mgr was available but harder to setup than X. This is from like 0.98pl5 or so days, so very early on... - was there any discussion of alternatives to X? > Discussions yes. But not much more than talk. There were vgalib apps that ran graphics on the console, but I never used them. - was there any discussion of what kernel support for graphics was > appropriate? > Some. But mostly it was to switch graphics modes between x11 and console apps. Very little beyond that. By the time Linux arrived, x11 had already won in the workstation space, so the quick push was to get x11 going. It wasn't long before everything was XFree86 (or XFree98 if you were in Japan). Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Sun Feb 26 11:14:16 2023 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Sun, 26 Feb 2023 02:14:16 +0100 Subject: [TUHS] Early GUI on Linux In-Reply-To: References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> Message-ID: <20230226011416.v_YEz%steffen@sdaoden.eu> Warner Losh wrote in : |On Sat, Feb 25, 2023, 2:31 PM Paul Ruizendaal wrote: ... |> - were there any window systems popular on early Linux other than X? ... |No. Mgr was available but harder to setup than X. This is from like 0.98pl5 |or so days, so very early on... | |- was there any discussion of alternatives to X? | |Discussions yes. But not much more than talk. | |There were vgalib apps that ran graphics on the console, but I never used |them. There was (and is) directfb. It seems it never really started over, but i actually track its successor [1] due to interest. It was one of my plans, over twenty years ago (there was an article in either German Linux Magazine or German computer magazine c't on it), to have nothing but myself, it and the kernel. (And PDF viewer and image viewer that existed and i think exist. Graphical browser was not soo much necessary by then.) (That sprung into existence when after a Halloween Linux Red Hat clone update i suddenly found myself in a graphical framebuffer. My "desktop" is a full-window screen->tmux session with multiple windows, and sometimes firefox beside it; rxvt-unicode earlier, but basically the same.) [1] https://github.com/directfb2/DirectFB2.git --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From lm at mcvoy.com Sun Feb 26 11:27:54 2023 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 25 Feb 2023 17:27:54 -0800 Subject: [TUHS] Early GUI on Linux In-Reply-To: References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> Message-ID: <20230226012753.GA12775@mcvoy.com> On Sat, Feb 25, 2023 at 05:49:36PM -0500, Dan Cross wrote: > > - were there any window systems popular on early Linux other than X? > > Not really. The context at the time was that a lot of folks (well, me) > wanted a workstation-like experience, but on a machine we could > individually afford. That basically meant bringing over most of the > staples one was used to on a (Sun|DEC|HP|SGI) machine, which almost > universally implied X as a prerequisite. Folks wanted to be able to > use their customized shell startup files and so on, but also their > window manager configurations and the like. Yep, this exactly. I was the weird who carried around an X10 tape, then an X11 tape, and built all that so it ran on (Sun|DEC|HP|SGI). I despised all those fancy guis that $VENDOR built, I just wanted to get work done and I wanted to do it as much as possible the same way on each box. So when Linux came around, hello X! --lm From jsg at jsg.id.au Sun Feb 26 12:21:00 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Sun, 26 Feb 2023 13:21:00 +1100 Subject: [TUHS] Early GUI on Linux In-Reply-To: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> Message-ID: On Sat, Feb 25, 2023 at 10:31:22PM +0100, Paul Ruizendaal wrote: > > I think discussion of early Linux is in scope for this list, after all that is 30 years ago. Warren, if that is a mis-assumption please slap my wrist. > > Following on from the recent discussion of early workstations and windowing systems, I’m wondering about early windowing on Linux. I only discovered Linux in the later nineties (Red Hat 4.x I think), and by that time Linux already seemed to have settled on Xfree86. At that time svgalib was still around but already abandoned. > > By 1993 even student class PC hardware already outperformed the workstations of the early/mid eighties, memory was much more abundant and pixels were no longer bits but bytes (making drawing easier). Also, early Linux was (I think) more local machine oriented, not LAN oriented. Maybe a different system than X would have made sense. > > In short, I could imagine a frame buffer device and a compositor for top-level windows (a trail that had been pioneered by Oriel half a decade before), a declarative widget set inspired by the contemporary early browsers and the earlier NeWS, etc. Yet nothing like that happened as far as I know. I vaguely recall an OS from the late 90’s that mixed Linux with a partly in-kernel GUI called “Berlin” or something like that, but I cannot find any trace of that today, so maybe I misremember. The Berlin project started incorporating code from the earlier Fresco project, and then renamed to Fresco. The earlier Fresco was not a window system, and was at one point distributed by the X Consortium and Fujitsu's Advanced Software Lab (faslab) http://web.archive.org/web/20020807002842/http://wiki.fresco.org/index.cgi/ArchitectureQuestions http://web.archive.org/web/19980121223254/http://www.iuk.tu-harburg.de/fresco/ The kernel parts seem more along the lines of mode setting than a GUI. > > So here are a few things that I am interested in and folks on this list might remember: > > - were there any window systems popular on early Linux other than X? > > - was there any discussion of alternatives to X? > > - was there any discussion of what kernel support for graphics was appropriate? > > > From will.senn at gmail.com Sun Feb 26 12:27:03 2023 From: will.senn at gmail.com (Will Senn) Date: Sat, 25 Feb 2023 20:27:03 -0600 Subject: [TUHS] Early GUI on Linux In-Reply-To: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> Message-ID: <2f10af1e-8380-3f6f-4f07-278d493af056@gmail.com> Hi Paul, I remember downloading SLS with X ( a bunch of floppy images) over a 300 baud connection via a VMS gateway to the internet somewhere in late 1991 or early 1992. I think this might have been less than a year after the 0.9 kernel was released. So, if there was something prior to X, it was extremely short lived. Slackware took SLS and bundled it with X providing that as a basis for a Linux kit, so to speak, and I seem to remember everybody I know using that until Redhat came along and Debian, etc. Of course there were others, but SLS/X and Slackware were early, early days. Will On 2/25/23 3:31 PM, Paul Ruizendaal wrote: > I think discussion of early Linux is in scope for this list, after all that is 30 years ago. Warren, if that is a mis-assumption please slap my wrist. > > Following on from the recent discussion of early workstations and windowing systems, I’m wondering about early windowing on Linux. I only discovered Linux in the later nineties (Red Hat 4.x I think), and by that time Linux already seemed to have settled on Xfree86. At that time svgalib was still around but already abandoned. > > By 1993 even student class PC hardware already outperformed the workstations of the early/mid eighties, memory was much more abundant and pixels were no longer bits but bytes (making drawing easier). Also, early Linux was (I think) more local machine oriented, not LAN oriented. Maybe a different system than X would have made sense. > > In short, I could imagine a frame buffer device and a compositor for top-level windows (a trail that had been pioneered by Oriel half a decade before), a declarative widget set inspired by the contemporary early browsers and the earlier NeWS, etc. Yet nothing like that happened as far as I know. I vaguely recall an OS from the late 90’s that mixed Linux with a partly in-kernel GUI called “Berlin” or something like that, but I cannot find any trace of that today, so maybe I misremember. > > So here are a few things that I am interested in and folks on this list might remember: > > - were there any window systems popular on early Linux other than X? > > - was there any discussion of alternatives to X? > > - was there any discussion of what kernel support for graphics was appropriate? > > From will.senn at gmail.com Sun Feb 26 12:30:30 2023 From: will.senn at gmail.com (Will Senn) Date: Sat, 25 Feb 2023 20:30:30 -0600 Subject: [TUHS] Early GUI on Linux In-Reply-To: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> Message-ID: <32bb4782-29fc-e720-49ab-f3feeeb59327@gmail.com> Oh and lest we forget, Yggdrasil, in Nov. 1992 did X on Linux. Will On 2/25/23 3:31 PM, Paul Ruizendaal wrote: > I think discussion of early Linux is in scope for this list, after all that is 30 years ago. Warren, if that is a mis-assumption please slap my wrist. > > Following on from the recent discussion of early workstations and windowing systems, I’m wondering about early windowing on Linux. I only discovered Linux in the later nineties (Red Hat 4.x I think), and by that time Linux already seemed to have settled on Xfree86. At that time svgalib was still around but already abandoned. > > By 1993 even student class PC hardware already outperformed the workstations of the early/mid eighties, memory was much more abundant and pixels were no longer bits but bytes (making drawing easier). Also, early Linux was (I think) more local machine oriented, not LAN oriented. Maybe a different system than X would have made sense. > > In short, I could imagine a frame buffer device and a compositor for top-level windows (a trail that had been pioneered by Oriel half a decade before), a declarative widget set inspired by the contemporary early browsers and the earlier NeWS, etc. Yet nothing like that happened as far as I know. I vaguely recall an OS from the late 90’s that mixed Linux with a partly in-kernel GUI called “Berlin” or something like that, but I cannot find any trace of that today, so maybe I misremember. > > So here are a few things that I am interested in and folks on this list might remember: > > - were there any window systems popular on early Linux other than X? > > - was there any discussion of alternatives to X? > > - was there any discussion of what kernel support for graphics was appropriate? > > From tytso at mit.edu Sun Feb 26 12:40:34 2023 From: tytso at mit.edu (Theodore Ts'o) Date: Sat, 25 Feb 2023 21:40:34 -0500 Subject: [TUHS] Early GUI on Linux In-Reply-To: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> Message-ID: I think it's fair to say that in the very early days of Linux, most of the people who were using it were people who kernel hackers; and so we didn't have all that many people who were interested in developing new windowing systems. We just wanted to be able to have multiple xterms and Emacs windows. In fact, support for X Windows predated the development of a networking stack; we had Unix domain sockets, so that was enough for X, but we didn't have a working networking stack at that point! I would be running X, and then running C-Kermit to download files from MIT over a dialup modem. At that point, X windows wasn't *flaky* per se, but remember that back then monitors were very persnicky about exactly what resolutions and frequences they would accept. And this was before monitors supported EDID (Extended Display Identification Data), which allowed the X server to figure out what the parameters were of the monitor. So that meant that configuring the X server with the correct resolution, frequencies, etc., was tricky. There were long and complex documents explaining how to do it, and it was a very manual process. If you got the calculations wrong, the image might not be stable, but that wasn't a software bug so much as it was a configuration error. There were programs (for example, the most famous was the graphical game "Tuxracer") which wrote directly to the frame buffer, but there wasn't anyone who was interested in developing their own compositor. We just wanted xterms and (later) Firefox to work! As far as discussion about what should and shouldn't go into the kernel, most people agreed that as much as possible, especially in graphics land, should be out of the kernel. The fact that we didn't have a lot of graphics specialists in the kernel development community, and that in those early days the vast majority of Linux boxen where single user machines just sealed the deal. - Ted From crossd at gmail.com Sun Feb 26 13:28:20 2023 From: crossd at gmail.com (Dan Cross) Date: Sat, 25 Feb 2023 22:28:20 -0500 Subject: [TUHS] Early GUI on Linux In-Reply-To: References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> Message-ID: On Sat, Feb 25, 2023 at 9:40 PM Theodore Ts'o wrote: > I think it's fair to say that in the very early days of Linux, most of > the people who were using it were people who kernel hackers; and so we > didn't have all that many people who were interested in developing new > windowing systems. We just wanted to be able to have multiple xterms > and Emacs windows. This is another important thing to bear in mind: this predates the explosion of the world wide web; most people back then paradoxically ran a lot more local software on their machines (applications weren't de facto mediated by a web browser), but a lot of that software was simpler. xterm and a text editor and a lot of folks were good to go. > In fact, support for X Windows predated the development of a > networking stack; we had Unix domain sockets, so that was enough for > X, but we didn't have a working networking stack at that point! I > would be running X, and then running C-Kermit to download files from > MIT over a dialup modem. !! > At that point, X windows wasn't *flaky* per se, but remember that back > then monitors were very persnicky about exactly what resolutions and > frequences they would accept. And this was before monitors supported > EDID (Extended Display Identification Data), which allowed the X > server to figure out what the parameters were of the monitor. So that > meant that configuring the X server with the correct resolution, > frequencies, etc., was tricky. There were long and complex documents > explaining how to do it, and it was a very manual process. If you got > the calculations wrong, the image might not be stable, but that wasn't > a software bug so much as it was a configuration error. Yeah, this: once you got something configured and working it wasn't like it crashed all the time or anything like that. But getting it working in the first place was challenging; it was a _far_ cry from today, where it seems like most of the time, X "just works" out of the box. Or even from most workstations of the era, which largely worked with little or no tedious configuration (because the vendor had done the hard work to bring X up on their hardware already). But on x86, I recall that even slight perturbations in a system could keep X from running. For example, one might have the right model of xfree86-supported video card, but from a manufacturing run of cards that did not work (because they used rev B of an internal component instead of A, perhaps). Or the card might not work on a different motherboard, etc. Getting it working could be a real exercise in frustration. > There were programs (for example, the most famous was the graphical > game "Tuxracer") which wrote directly to the frame buffer, but there > wasn't anyone who was interested in developing their own compositor. > We just wanted xterms and (later) Firefox to work! Firefox? Wow, talk about a Johnny Come Lately. :-) I can still remember compiling NCSA Mosaic on a SPARCstation 2. Those were the days...very painful days.... - Dan C. > As far as discussion about what should and shouldn't go into the > kernel, most people agreed that as much as possible, especially in > graphics land, should be out of the kernel. The fact that we didn't > have a lot of graphics specialists in the kernel development > community, and that in those early days the vast majority of Linux > boxen where single user machines just sealed the deal. From imp at bsdimp.com Sun Feb 26 13:45:04 2023 From: imp at bsdimp.com (Warner Losh) Date: Sat, 25 Feb 2023 20:45:04 -0700 Subject: [TUHS] Early GUI on Linux In-Reply-To: References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> Message-ID: On Sat, Feb 25, 2023, 8:29 PM Dan Cross wrote: > On Sat, Feb 25, 2023 at 9:40 PM Theodore Ts'o wrote: > > I think it's fair to say that in the very early days of Linux, most of > > the people who were using it were people who kernel hackers; and so we > > didn't have all that many people who were interested in developing new > > windowing systems. We just wanted to be able to have multiple xterms > > and Emacs windows. > > This is another important thing to bear in mind: this predates the > explosion of the world wide web; most people back then paradoxically > ran a lot more local software on their machines (applications weren't > de facto mediated by a web browser), but a lot of that software was > simpler. xterm and a text editor and a lot of folks were good to go. > The graphical www... Lynx was a thing for a long time... spent a lot of time looking for info on how too boot Linux to get it going. Usenet archives and mailing lists searching for clues. www and gopher and wais.. > In fact, support for X Windows predated the development of a > > networking stack; we had Unix domain sockets, so that was enough for > > X, but we didn't have a working networking stack at that point! I > > would be running X, and then running C-Kermit to download files from > > MIT over a dialup modem. > > !! > > > At that point, X windows wasn't *flaky* per se, but remember that back > > then monitors were very persnicky about exactly what resolutions and > > frequences they would accept. And this was before monitors supported > > EDID (Extended Display Identification Data), which allowed the X > > server to figure out what the parameters were of the monitor. So that > > meant that configuring the X server with the correct resolution, > > frequencies, etc., was tricky. There were long and complex documents > > explaining how to do it, and it was a very manual process. If you got > > the calculations wrong, the image might not be stable, but that wasn't > > a software bug so much as it was a configuration error. > > Yeah, this: once you got something configured and working it wasn't > like it crashed all the time or anything like that. But getting it > working in the first place was challenging; it was a _far_ cry from > today, where it seems like most of the time, X "just works" out of the > box. Or even from most workstations of the era, which largely worked > with little or no tedious configuration (because the vendor had done > the hard work to bring X up on their hardware already). > > But on x86, I recall that even slight perturbations in a system could > keep X from running. For example, one might have the right model of > xfree86-supported video card, but from a manufacturing run of cards > that did not work (because they used rev B of an internal component > instead of A, perhaps). Or the card might not work on a different > motherboard, etc. > > Getting it working could be a real exercise in frustration. > Taught me patience as I brute forced a solution... then worked backwards to make the next one work faster.... front porches and backporches seemed concrete when reading the svga howtos... that died a flaming death when I read data sheets... wasn't until I read video demystified that I started to get it... and only then because I was working with video engineers that explained the differences... so yea.. super frustrating... > There were programs (for example, the most famous was the graphical > > game "Tuxracer") which wrote directly to the frame buffer, but there > > wasn't anyone who was interested in developing their own compositor. > > We just wanted xterms and (later) Firefox to work! > > Firefox? Wow, talk about a Johnny Come Lately. :-) I can still > remember compiling NCSA Mosaic on a SPARCstation 2. Those were the > days...very painful days.... > Yes... lots of pain and patches and rebuilding... on slow machines... Warner > - Dan C. > > > > As far as discussion about what should and shouldn't go into the > > kernel, most people agreed that as much as possible, especially in > > graphics land, should be out of the kernel. The fact that we didn't > > have a lot of graphics specialists in the kernel development > > community, and that in those early days the vast majority of Linux > > boxen where single user machines just sealed the deal. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Sun Feb 26 15:24:17 2023 From: cowan at ccil.org (John Cowan) Date: Sun, 26 Feb 2023 00:24:17 -0500 Subject: [TUHS] Early GUI on Linux In-Reply-To: References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> Message-ID: On Sat, Feb 25, 2023 at 9:40 PM Theodore Ts'o wrote: > We just wanted to be able to have multiple xterms > and Emacs windows. > In fact that's pretty much what I do to this day: I do everything in terminals and do browsing etc. elsewhere. At that point, X windows wasn't *flaky* per se, but rem If you got > the calculations wrong, the image might not be stable, but that wasn't > a software bug so much as it was a configuration error. > However, most configuration errors can't reduce your hardware to a useless pile of junk, whereas older CRT monitors could definitely be destroyed if the configuration was too far off nominal. -------------- next part -------------- An HTML attachment was scrubbed... URL: From usotsuki at buric.co Sun Feb 26 15:36:27 2023 From: usotsuki at buric.co (Steve Nickolas) Date: Sun, 26 Feb 2023 00:36:27 -0500 (EST) Subject: [TUHS] Early GUI on Linux In-Reply-To: References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> Message-ID: On Sun, 26 Feb 2023, John Cowan wrote: > On Sat, Feb 25, 2023 at 9:40 PM Theodore Ts'o wrote: > >> We just wanted to be able to have multiple xterms >> and Emacs windows. > > In fact that's pretty much what I do to this day: I do everything in > terminals and do browsing etc. elsewhere. I always keep at least one xterm (actually mate-terminal) open and do a lot of my work from it. When I run GUI apps, they're almost always maximized on either one or the other of my two displays (exception for emulators, sometimes). I have the desktop icons completely disabled. -uso. From leah at vuxu.org Mon Feb 27 01:50:34 2023 From: leah at vuxu.org (Leah Neukirchen) Date: Sun, 26 Feb 2023 16:50:34 +0100 Subject: [TUHS] Early GUI on Linux In-Reply-To: (Warner Losh's message of "Sat, 25 Feb 2023 17:39:13 -0700") References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> Message-ID: <878rgks9x1.fsf@vuxu.org> Warner Losh writes: > - was there any discussion of alternatives to X? >> > > Discussions yes. But not much more than talk. > > There were vgalib apps that ran graphics on the console, but I never used > them. I have some first hand experience with svgalib programs around 1999. Back then I didn't have enough disk space to install X11 and TeX at the same time, so I mostly worked on the 80x25 console and used dvisvga as a previewer, which ran MetaFont in the background and then rendered a quite readable preview of your DVI file. I also remember using zgv, an image display program that used svgalib. The fractal renderer XaoS also could do svgalib. IIRC, my screen could only display 1024x768, not 1280x1024. AFAIU, svgalib directly poked the graphics card memory on x86, so all programs using it had to be SUID to allow this. There was no kernel-provided framebuffer, this came a bit later (2.1.109 says Wikipedia; I used kernel 2.0.36 back then), but by then I had switched to X11 already. hth, -- Leah Neukirchen https://leahneukirchen.org/ From paul.winalski at gmail.com Mon Feb 27 01:51:12 2023 From: paul.winalski at gmail.com (Paul Winalski) Date: Sun, 26 Feb 2023 10:51:12 -0500 Subject: [TUHS] Origins of the SGS (System Generation Software) and COFF (Common Object File Format) Message-ID: On 2/25/23, Brian Walden wrote: > It was originaly 205. See A.OUT(V) (the first page) at > https://www.bell-labs.com/usr/dmr/www/man51.pdf it was documented as to > why. > > > The header always contains 6 words: > 1 "br .+14" instruction (205(8)) > 2 The size of the program text > 3 The size of the symbol table > 4 The size of the relocation bits area > 5 The size of a data area > 6 A zero word (unused at present) > > I always found this so elegant in it's simplicity. Just load and start > execution at the start (simplifies exec(2) in the kernel) I always wondered > if this has done anywhere else before, or invenetd first in unix. IBM's Basic Program Support (BPS) for System/360 was a set of stand-alone utilities for developing and running stand-alone programs. BPS/360 wasn't really an operating system because there wasn't any resident kernel. You just IPLed (Initial Program Load; IBM-speak for "boot") your application directly. So the executable format for BPS had a bootstrap loader as the "program header". Not quite the same thing as a.out's 205(8) magic number, but similar in concept. I don't know of any other OS ABI that uses this trick to transfer control to application programs. Microsoft uses something similar in PECOFF. A PECOFF executable for x86 or X86-64 starts with a bit of code in MS-DOS MZ executable format that prints the message "This program cannot be run in DOS mode". -Paul W. From lm at mcvoy.com Mon Feb 27 02:13:13 2023 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 26 Feb 2023 08:13:13 -0800 Subject: [TUHS] Early GUI on Linux In-Reply-To: <878rgks9x1.fsf@vuxu.org> References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> <878rgks9x1.fsf@vuxu.org> Message-ID: <20230226161313.GV12775@mcvoy.com> On Sun, Feb 26, 2023 at 04:50:34PM +0100, Leah Neukirchen wrote: > Warner Losh writes: > > > - was there any discussion of alternatives to X? > >> > > > > Discussions yes. But not much more than talk. > > > > There were vgalib apps that ran graphics on the console, but I never used > > them. > > Back then I didn't have enough disk space to install X11 and TeX at > the same time, so I mostly worked on the 80x25 console screen(1) was my go to back in the days of limited resources. Especially screen -r so you could detach, come back the next day and have all your setup right there. Wasn't that fancy but oh so useful. I'm with Ted in that we just wanted a bunch of terminal windows. From leah at vuxu.org Mon Feb 27 02:23:21 2023 From: leah at vuxu.org (Leah Neukirchen) Date: Sun, 26 Feb 2023 17:23:21 +0100 Subject: [TUHS] Early GUI on Linux In-Reply-To: <20230226161313.GV12775@mcvoy.com> (Larry McVoy's message of "Sun, 26 Feb 2023 08:13:13 -0800") References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> <878rgks9x1.fsf@vuxu.org> <20230226161313.GV12775@mcvoy.com> Message-ID: <874jr8s8ee.fsf@vuxu.org> Larry McVoy writes: > On Sun, Feb 26, 2023 at 04:50:34PM +0100, Leah Neukirchen wrote: >> Warner Losh writes: >> >> > - was there any discussion of alternatives to X? >> >> >> > >> > Discussions yes. But not much more than talk. >> > >> > There were vgalib apps that ran graphics on the console, but I never used >> > them. >> >> Back then I didn't have enough disk space to install X11 and TeX at >> the same time, so I mostly worked on the 80x25 console > > screen(1) was my go to back in the days of limited resources. Especially > screen -r so you could detach, come back the next day and have all your > setup right there. > > Wasn't that fancy but oh so useful. I'm with Ted in that we just wanted > a bunch of terminal windows. Curiously, I learned about screen only way later, when I used remote systems. But I made getty spawn on 12 ttys, so that worked as well to multitask. -- Leah Neukirchen https://leahneukirchen.org From imp at bsdimp.com Mon Feb 27 02:32:10 2023 From: imp at bsdimp.com (Warner Losh) Date: Sun, 26 Feb 2023 09:32:10 -0700 Subject: [TUHS] Early GUI on Linux In-Reply-To: <874jr8s8ee.fsf@vuxu.org> References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> <878rgks9x1.fsf@vuxu.org> <20230226161313.GV12775@mcvoy.com> <874jr8s8ee.fsf@vuxu.org> Message-ID: On Sun, Feb 26, 2023, 9:23 AM Leah Neukirchen wrote: > Larry McVoy writes: > > > On Sun, Feb 26, 2023 at 04:50:34PM +0100, Leah Neukirchen wrote: > >> Warner Losh writes: > >> > >> > - was there any discussion of alternatives to X? > >> >> > >> > > >> > Discussions yes. But not much more than talk. > >> > > >> > There were vgalib apps that ran graphics on the console, but I never > used > >> > them. > >> > >> Back then I didn't have enough disk space to install X11 and TeX at > >> the same time, so I mostly worked on the 80x25 console > > > > screen(1) was my go to back in the days of limited resources. Especially > > screen -r so you could detach, come back the next day and have all your > > setup right there. > > > > Wasn't that fancy but oh so useful. I'm with Ted in that we just wanted > > a bunch of terminal windows. > > Curiously, I learned about screen only way later, when I used remote > systems. But I made getty spawn on 12 ttys, so that worked as well to > multitask. > That's a trick that dates back to the 80s. Different Unixes did that. I first saw it on the DEC Rainbow running an enhanced Venix (V7) in like 1987 where you had 4 consoles, but no job control.... SCO System V did it in the late 80s too. I think the pre system V Xenix did too. Warner -- > Leah Neukirchen https://leahneukirchen.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Mon Feb 27 02:39:04 2023 From: will.senn at gmail.com (Will Senn) Date: Sun, 26 Feb 2023 10:39:04 -0600 Subject: [TUHS] Early GUI on Linux In-Reply-To: <874jr8s8ee.fsf@vuxu.org> References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> <878rgks9x1.fsf@vuxu.org> <20230226161313.GV12775@mcvoy.com> <874jr8s8ee.fsf@vuxu.org> Message-ID: <78FBC005-1DA2-4D08-89A2-5E8DE30436C5@gmail.com> Same here. The virtual terminals worked for me (and still do) until I start doing ssh, then screen and tmux are lifesavers. Will Sent from my iPhone > On Feb 26, 2023, at 10:23 AM, Leah Neukirchen wrote: > > Larry McVoy writes: > >>> On Sun, Feb 26, 2023 at 04:50:34PM +0100, Leah Neukirchen wrote: >>> Warner Losh writes: >>> >>>> - was there any discussion of alternatives to X? >>>>> >>>> >>>> Discussions yes. But not much more than talk. >>>> >>>> There were vgalib apps that ran graphics on the console, but I never used >>>> them. >>> >>> Back then I didn't have enough disk space to install X11 and TeX at >>> the same time, so I mostly worked on the 80x25 console >> >> screen(1) was my go to back in the days of limited resources. Especially >> screen -r so you could detach, come back the next day and have all your >> setup right there. >> >> Wasn't that fancy but oh so useful. I'm with Ted in that we just wanted >> a bunch of terminal windows. > > Curiously, I learned about screen only way later, when I used remote > systems. But I made getty spawn on 12 ttys, so that worked as well to > multitask. > > -- > Leah Neukirchen https://leahneukirchen.org From dave at horsfall.org Mon Feb 27 05:58:13 2023 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 27 Feb 2023 06:58:13 +1100 (EST) Subject: [TUHS] Early GUI on Linux In-Reply-To: <20230226161313.GV12775@mcvoy.com> References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> <878rgks9x1.fsf@vuxu.org> <20230226161313.GV12775@mcvoy.com> Message-ID: On Sun, 26 Feb 2023, Larry McVoy wrote: > screen(1) was my go to back in the days of limited resources. > Especially screen -r so you could detach, come back the next day and > have all your setup right there. And the ability to copy'n'paste between screens... > Wasn't that fancy but oh so useful. I'm with Ted in that we just wanted > a bunch of terminal windows. Yep; even on my Mac I don't use the Finder, just multiple Terminals. -- Dave From ken.unix.guy at gmail.com Mon Feb 27 07:00:10 2023 From: ken.unix.guy at gmail.com (KenUnix) Date: Sun, 26 Feb 2023 16:00:10 -0500 Subject: [TUHS] Unix v7 vi Message-ID: Was work ever done for v7 Unix to support 'vi' when using a tek or vt05 terminal? And, is it available? Thanks, Ken -- WWL 📚 -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Mon Feb 27 07:33:40 2023 From: will.senn at gmail.com (Will Senn) Date: Sun, 26 Feb 2023 15:33:40 -0600 Subject: [TUHS] Unix v7 vi In-Reply-To: References: Message-ID: <83CA8F6D-555B-4CBB-99A5-CEC102B30E4B@gmail.com> Probably, but I have found that to be a black hole of time and effort. Perhaps you’ll figure it out and post! I tried several times to get vi working and was only ever able to get it partially working... at best. I didn’t try it for a trek window though. Sent from my iPhone > On Feb 26, 2023, at 3:00 PM, KenUnix wrote: > > Was work ever done for v7 Unix to support 'vi' when using a > tek or vt05 terminal? > > And, is it available? > > Thanks, > Ken > > -- > WWL 📚 > > From will.senn at gmail.com Mon Feb 27 07:35:21 2023 From: will.senn at gmail.com (Will Senn) Date: Sun, 26 Feb 2023 15:35:21 -0600 Subject: [TUHS] Unix v7 vi In-Reply-To: <83CA8F6D-555B-4CBB-99A5-CEC102B30E4B@gmail.com> References: <83CA8F6D-555B-4CBB-99A5-CEC102B30E4B@gmail.com> Message-ID: <3BD99B54-61E2-41B1-AADD-DBF072190B3A@gmail.com> Oh and even though I’d love it in a trek window, I meant Tek :). Either way, I hope somebody posts a solution. Sent from my iPhone > On Feb 26, 2023, at 3:33 PM, Will Senn wrote: > > Probably, but I have found that to be a black hole of time and effort. Perhaps you’ll figure it out and post! I tried several times to get vi working and was only ever able to get it partially working... at best. I didn’t try it for a trek window though. > > Sent from my iPhone > >> On Feb 26, 2023, at 3:00 PM, KenUnix wrote: >> >> Was work ever done for v7 Unix to support 'vi' when using a >> tek or vt05 terminal? >> >> And, is it available? >> >> Thanks, >> Ken >> >> -- >> WWL 📚 >> >> From clemc at ccc.com Mon Feb 27 08:14:57 2023 From: clemc at ccc.com (Clem Cole) Date: Sun, 26 Feb 2023 17:14:57 -0500 Subject: [TUHS] Unix v7 vi In-Reply-To: <3BD99B54-61E2-41B1-AADD-DBF072190B3A@gmail.com> References: <83CA8F6D-555B-4CBB-99A5-CEC102B30E4B@gmail.com> <3BD99B54-61E2-41B1-AADD-DBF072190B3A@gmail.com> Message-ID: The 2BSD tape on TUHS (web interface: https://www.tuhs.org/cgi-bin/utree.pl?file=2BSD) has the original ex source -- remember vi is the visual command for ex. It includes binaries that will run on v6 in the tape - you need to build it for v7. I also don't know if the VT05 is in the termcap file. Plus, a Tek 4014 in the termcap is likely to be not very useful for vi mode as it's a DVST (storage terminal), but I think there may be a Tek 4025 definition in there (as I wrote it back in the day and sent it Mary Ann who was the collector of them). That said ex is big and it needs a separate I/D (11/45 class) system, so a while ago, I got Webb Miller's s (mini vi) to compile a while back: https://github.com/udo-munk/s which has much more modest requirements (it is known to have been ported to 8-bit micros under CP/M) but it assumes ANSI sequences so there is no termcap. ᐧ On Sun, Feb 26, 2023 at 4:35 PM Will Senn wrote: > Oh and even though I’d love it in a trek window, I meant Tek :). Either > way, I hope somebody posts a solution. > > Sent from my iPhone > > > On Feb 26, 2023, at 3:33 PM, Will Senn wrote: > > > > Probably, but I have found that to be a black hole of time and effort. > Perhaps you’ll figure it out and post! I tried several times to get vi > working and was only ever able to get it partially working... at best. I > didn’t try it for a trek window though. > > > > Sent from my iPhone > > > >> On Feb 26, 2023, at 3:00 PM, KenUnix wrote: > >> > >> Was work ever done for v7 Unix to support 'vi' when using a > >> tek or vt05 terminal? > >> > >> And, is it available? > >> > >> Thanks, > >> Ken > >> > >> -- > >> WWL 📚 > >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Mon Feb 27 10:16:17 2023 From: athornton at gmail.com (Adam Thornton) Date: Sun, 26 Feb 2023 17:16:17 -0700 Subject: [TUHS] Early GUI on Linux In-Reply-To: References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> <878rgks9x1.fsf@vuxu.org> <20230226161313.GV12775@mcvoy.com> Message-ID: Back in...1993, I think (maybe 92), I ran mgr for a while on Linux because X required a Tseng ET4000 video card, which I did not have. Eventually X got a generic SVGA driver and I was able to start using it. Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Mon Feb 27 13:55:24 2023 From: imp at bsdimp.com (Warner Losh) Date: Sun, 26 Feb 2023 20:55:24 -0700 Subject: [TUHS] Any Bell 8-bit UNIX Efforts? In-Reply-To: References: Message-ID: On Sat, Feb 25, 2023 at 12:49 PM segaloco via TUHS wrote: > So in working on an unrelated 6502 project, I got to wondering about UNIX > on it and other 8-bits. Did some Googling, and while I was able to turn up > some attempts at UNIX-likes on 6502 as well as Z80, the only one I found > that might have some Bell connection is "uNIX" as documented here: > https://bitsavers.org/pdf/uNIX/uNIX_Jan82.pdf > > A forum post I read suggested those involved were some former Bell folks > from NJ. In any case, this begs the question for me: Were there ever any > serious attempts at an 8-bit UNIX in the labs or Bell System at large? > Certainly it would've provided quite the challenge without much return > compared with 16 and 32-bit efforts, but does anyone know if, say, an > LSX/Mini-UNIX-ish attempt was ever made at the 6502, Z80, or other 8-bits? > Thanks all! > FUZIX is one that I'm aware of, but it's a rewrite, not a port: https://hackaday.com/2017/04/16/z80-fuzix-is-like-old-fashioned-unix/ Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralph at inputplus.co.uk Mon Feb 27 20:09:39 2023 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Mon, 27 Feb 2023 10:09:39 +0000 Subject: [TUHS] Early GUI on Linux In-Reply-To: <20230226161313.GV12775@mcvoy.com> References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> <878rgks9x1.fsf@vuxu.org> <20230226161313.GV12775@mcvoy.com> Message-ID: <20230227100939.D3BC3220B4@orac.inputplus.co.uk> Hi, Larry wrote: > screen(1) was my go to back in the days of limited resources. > Especially screen -r so you could detach, come back the next day and > have all your setup right there. A beefed up version today is to vncviewer(1) over SSH into a desktop on a beefy CPU server where vncserver has been set running for a particular user. Everything is as it was left and modern X is happy to adjust on the fly to the screen dimensions of the current viewer. Doesn't have Plan 9's elegance, but still gives utility. -- Cheers, Ralph. From jsg at jsg.id.au Mon Feb 27 20:57:20 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Mon, 27 Feb 2023 21:57:20 +1100 Subject: [TUHS] Any Bell 8-bit UNIX Efforts? In-Reply-To: References: Message-ID: On Sat, Feb 25, 2023 at 07:48:45PM +0000, segaloco via TUHS wrote: > So in working on an unrelated 6502 project, I got to wondering about > UNIX on it and other 8-bits. Did some Googling, and while I was > able to turn up some attempts at UNIX-likes on 6502 as well as Z80, > the only one I found that might have some Bell connection is "uNIX" > as documented here: https://bitsavers.org/pdf/uNIX/uNIX_Jan82.pdf > > A forum post I read suggested those involved were some former Bell > folks from NJ. In any case, this begs the question for me: Were > there ever any serious attempts at an 8-bit UNIX in the labs or > Bell System at large? Certainly it would've provided quite the > challenge without much return compared with 16 and 32-bit efforts, > but does anyone know if, say, an LSX/Mini-UNIX-ish attempt was ever > made at the 6502, Z80, or other 8-bits? Thanks all! > > - Matt G. If by Bell connection you mean people. Plauger left in 1975, joined Yourdon Inc in 1975, started Whitesmiths Ltd in 1978[1]. Whitesmiths created Idris, a clone of Unix. "Idris can run comfortably where UNIX can't event fit: On an MC68000 with no memory management hardware, for example. On a bank-switched 8080 or Z80. Or on any LS-11 or PDP-11 with memory management." Whitesmiths advertisement in Computerworld, Mar 1983 [2]. Yourdon Inc, announced Omnix in 1980, a Unix-like system for Z80[3]. By 1981 it "had to be withdrawn when Yourdon were let down by its developers" [4]. [1] https://indico.cern.ch/event/318305/attachments/612388/842557/PJPlauger-ITSeminar-Fifty_years.pdf [2] https://books.google.com/books?id=RAe4jAHXAgwC&pg=PA50 [3] https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V02.3.pdf [4] https://dl.acm.org/doi/pdf/10.1145/1164679.1164681 The last article is "UNIX on a Micro" by Cornelia Boldyreff. It briefly mentions other 8-bit Unix-likes: Cromemco's Cromix, Thinker Toys/Morrow's Micronix, Technical Systems Consultants' UniFLEX. From tuhs at tuhs.org Tue Feb 28 03:22:09 2023 From: tuhs at tuhs.org (Paul Ruizendaal via TUHS) Date: Mon, 27 Feb 2023 18:22:09 +0100 Subject: [TUHS] Early GUI on Linux In-Reply-To: References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> Message-ID: Thanks all for the insights. Let me attempt a summary. What it boils down to is that X arrived on Linux very early, because what the Linux hackers needed/wanted was a familiar terminal multiplexer. It seems that the pattern persists till the present day (and yes, it matches with my own dev setup/needs). I wonder to what extent this is a generational thing though. Maybe today’s twenty-somethings spend their days in front of Xcode, VStudio, Eclipse, etc. more than using multiple terminals. This ties in with another observation on early window systems. The earliest Unix window system that I could find (i.e. documented) was NUnix from 1981/82. Its desktop was designed around the idea of a dozen or so top level windows, each one being either a shell window or a graphics canvas, with no real concept of a widget set, dialogs, etc., or even of sub-windows. This paradigm seems to have been more or less the same in the Blit terminal, and carried through in MGR, Mux and even as late as 8 1/2. In the context where this serves the needs of core user group, such makes sense. === It is in stark contrast with developments at the lower/consumer end of the market. The original Mac, GEM and Windows all placed much more emphasis on being a graphical user interface, with standard widgets and UI design elements. On Unix and X it remained a mess. It seems that this was both for technical reasons (X not imposing a standard) and for economic reasons (the Unix wars). Linux then inherited the mess and the core user/developer demographic had no need/wish/time to fix it. It makes me wonder when true graphical applications started to appear for X / Unix / Linux (other than stuff like terminal, clock, calculator, etc.). The graphical browser certainly is one (1993). StarOffice and Applix seem to have arrived around 1995. Anything broadly used before that? From pnr at planet.nl Tue Feb 28 03:22:59 2023 From: pnr at planet.nl (Paul Ruizendaal) Date: Mon, 27 Feb 2023 18:22:59 +0100 Subject: [TUHS] Early GUI on Linux In-Reply-To: References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> Message-ID: <525A3F51-DAAA-4D90-9817-B3EB30CB4D6E@planet.nl> > On 26 Feb 2023, at 03:21, Jonathan Gray wrote: > > On Sat, Feb 25, 2023 at 10:31:22PM +0100, Paul Ruizendaal wrote: >> >> I vaguely recall an OS from the late 90’s that mixed Linux with a partly in-kernel GUI called “Berlin” or something like that, but I cannot find any trace of that today, so maybe I misremember. > > The Berlin project started incorporating code from the earlier Fresco > project, and then renamed to Fresco. Thank you for those links, that refreshed my memory. Yes, this was the project that I had lingering my mind. At the time I had the impression it was dependent on the GGI (General Graphics Interface) project and its kernel part (KGI, Kernel Graphics Interface). It would seem to me that there was a fair amount of complaining about X in the 1998-2004 time frame, beyond the complexity of getting it configured. The key complaints seem to have been: - The XShm is a poor fix for fast local operations (it opened the door for X as a compositor though) - There is no standard widget set (too many credible runners: Gtk, Qt, Tk, FLTK, etc.) - The server should handle basic widget interaction, not the client. - There is no alpha blending The proposed fixes include Berlin/GGI/KGI, DirectFB and Y-windows (http://www.y-windows.org); probably there are others. None of these seem to have had much traction (with the possible exception of DirectFB). Am I missing major initiatives in this space? From tuhs at tuhs.org Tue Feb 28 03:59:21 2023 From: tuhs at tuhs.org (Arno Griffioen via TUHS) Date: Mon, 27 Feb 2023 18:59:21 +0100 Subject: [TUHS] Early GUI on Linux In-Reply-To: References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> Message-ID: On Mon, Feb 27, 2023 at 06:22:09PM +0100, Paul Ruizendaal via TUHS wrote: > It is in stark contrast with developments at the lower/consumer end of the > market. The original Mac, GEM and Windows all placed much more emphasis on > being a graphical user interface, with standard widgets and UI design > elements. In my experience, compared to the above, many AmigaOS users would use the Workbench environment a lot more like the X windows setup. Aka. with several concurrent 'shell' windows open and having access on later versions to native scripting langauges like REXX and such to even automate 'windowed' applications. And even though AmigaOS also had lots of built-in libraries and style guide stuff, many programmers would still do things s lot more their own way as far as look&feel went than for instance on MacOS. (and yes... it often was a bit of mess like X can be ;) ) Not sure if the fact that things like Windows and MacOS were basically single-tasking or at best cooperative multitasking also influenced the use (enforcement?) of their standardised look&feel and code. Aka. breaking the mould just wasn't useful for programmers on these platforms or was perhaps even detrimental to the user? Bye, Arno. From imp at bsdimp.com Tue Feb 28 04:07:15 2023 From: imp at bsdimp.com (Warner Losh) Date: Mon, 27 Feb 2023 11:07:15 -0700 Subject: [TUHS] Early GUI on Linux In-Reply-To: References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> Message-ID: On Mon, Feb 27, 2023 at 10:22 AM Paul Ruizendaal via TUHS wrote: > > Thanks all for the insights. Let me attempt a summary. > > What it boils down to is that X arrived on Linux very early, because what > the Linux hackers needed/wanted was a familiar terminal multiplexer. It > seems that the pattern persists till the present day (and yes, it matches > with my own dev setup/needs). I wonder to what extent this is a > generational thing though. Maybe today’s twenty-somethings spend their days > in front of Xcode, VStudio, Eclipse, etc. more than using multiple > terminals. > > This ties in with another observation on early window systems. The > earliest Unix window system that I could find (i.e. documented) was NUnix > from 1981/82. Its desktop was designed around the idea of a dozen or so top > level windows, each one being either a shell window or a graphics canvas, > with no real concept of a widget set, dialogs, etc., or even of > sub-windows. This paradigm seems to have been more or less the same in the > Blit terminal, and carried through in MGR, Mux and even as late as 8 1/2. > In the context where this serves the needs of core user group, such makes > sense. > > === > > It is in stark contrast with developments at the lower/consumer end of the > market. The original Mac, GEM and Windows all placed much more emphasis on > being a graphical user interface, with standard widgets and UI design > elements. On Unix and X it remained a mess. It seems that this was both for > technical reasons (X not imposing a standard) and for economic reasons (the > Unix wars). Linux then inherited the mess and the core user/developer > demographic had no need/wish/time to fix it. > > It makes me wonder when true graphical applications started to appear for > X / Unix / Linux (other than stuff like terminal, clock, calculator, etc.). > The graphical browser certainly is one (1993). StarOffice and Applix seem > to have arrived around 1995. Anything broadly used before that? > ParcPlace produced the OI/uib linux port in 93 as well, even made standard floppies for it. Sadly, it didn't turn into sales, so we walked away form the Linux port, at least outside the building... OI/uib was an attempt to write your UI apps once, and use them with whatever look and feel the end user wanted... It was cool for the time, but things have evolved since then away from both OpenLook and Motif... and while the look and most of the feel was the same, X was, and continues to be, a mess because there's no standard cut and paste keys.... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Tue Feb 28 04:32:32 2023 From: imp at bsdimp.com (Warner Losh) Date: Mon, 27 Feb 2023 11:32:32 -0700 Subject: [TUHS] Early GUI on Linux In-Reply-To: <525A3F51-DAAA-4D90-9817-B3EB30CB4D6E@planet.nl> References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> <525A3F51-DAAA-4D90-9817-B3EB30CB4D6E@planet.nl> Message-ID: On Mon, Feb 27, 2023 at 10:23 AM Paul Ruizendaal wrote: > Am I missing major initiatives in this space? > Key bindings are not unified. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Tue Feb 28 06:04:36 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 27 Feb 2023 13:04:36 -0700 Subject: [TUHS] Generational development [was Re: Re: Early GUI on Linux] In-Reply-To: References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> Message-ID: <202302272004.31RK4aGG001510@freefriends.org> Paul Ruizendaal via TUHS wrote: > I wonder to what extent this is a generational thing though. Maybe > today’s twenty-somethings spend their days in front of Xcode, VStudio, > Eclipse, etc. more than using multiple terminals. For sure. And it's also the 30- and 40-somethings. In my experience over the past 18 years, almost nobody in those age groups is comfortable with a terminal or screen editor, even though they often work in environments where a command line is all they have (ssh, and/or docker exec). The IDE is for coding and searching files, and maybe Notepad++ for finding stuff in non-code files (log output). IMHO the dependence upon IDEs is crippling; they cut & paste to the almost total exclusion of the keyboard, including when shell completion would be faster. It's terribly sad. Arnold From chet.ramey at case.edu Tue Feb 28 06:08:32 2023 From: chet.ramey at case.edu (Chet Ramey) Date: Mon, 27 Feb 2023 15:08:32 -0500 Subject: [TUHS] Generational development [was Re: Re: Early GUI on Linux] In-Reply-To: <202302272004.31RK4aGG001510@freefriends.org> References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> <202302272004.31RK4aGG001510@freefriends.org> Message-ID: <2f6faeb4-5e73-cf18-b0ff-edc3e1658f72@case.edu> On 2/27/23 3:04 PM, arnold at skeeve.com wrote: > IMHO the dependence upon IDEs is crippling; they cut & paste to the > almost total exclusion of the keyboard, including when shell completion > would be faster. Don't forget cargo-culting by pasting shell commands they got from the web and barely understand, if at all. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From arnold at skeeve.com Tue Feb 28 06:22:16 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 27 Feb 2023 13:22:16 -0700 Subject: [TUHS] Generational development [was Re: Re: Early GUI on Linux] In-Reply-To: <2f6faeb4-5e73-cf18-b0ff-edc3e1658f72@case.edu> References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> <202302272004.31RK4aGG001510@freefriends.org> <2f6faeb4-5e73-cf18-b0ff-edc3e1658f72@case.edu> Message-ID: <202302272022.31RKMG2L004091@freefriends.org> Chet Ramey wrote: > On 2/27/23 3:04 PM, arnold at skeeve.com wrote: > > > IMHO the dependence upon IDEs is crippling; they cut & paste to the > > almost total exclusion of the keyboard, including when shell completion > > would be faster. > > Don't forget cargo-culting by pasting shell commands they got from the web > and barely understand, if at all. Yeah, really. I do what I can, but it's a very steep uphill battle, as most don't even understand that they're missing something, or that they could learn it if they wanted to. I think I'll stop ranting before I really get going. :-) Arnold From crossd at gmail.com Tue Feb 28 06:30:14 2023 From: crossd at gmail.com (Dan Cross) Date: Mon, 27 Feb 2023 15:30:14 -0500 Subject: [TUHS] Early GUI on Linux In-Reply-To: References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> Message-ID: On Mon, Feb 27, 2023 at 12:22 PM Paul Ruizendaal via TUHS wrote: > Thanks all for the insights. Let me attempt a summary. > > What it boils down to is that X arrived on Linux very early, because what the Linux hackers needed/wanted was a familiar terminal multiplexer. While that was literally true, I think it was a little more nuanced. I'd perhaps put it that people wanted their familiar environments. Many people were used to running a lot of xterms on their workstations, of course, but there were other X applications people used regularly. Some I remember where `gv` to look at PostScript documents, `xv` to view image files, `gnuplot` could generate plots in a window, `xdvi` to look at TeX/LaTeX output, and text editors like `emacs` had X front-ends that offered syntax highlighting and the like; some folks I knew liked `nedit`. `exmh` was my preferred email client for a while, and things like `xman` (was there a `tkman`, too?) was nice. Some system monitoring tools `xload` were considered essentials; `xbiff` could be useful (I could have sworn there was a `tkbiff`, too). A clock like `xclock` or `oclock` or something was also nice. Some folks liked graphical newsreaders, chat programs (I guess IRC was a thing back then, and I believe some `talk` client had an X front-end). There was a fractal viewer that I thought was fun, but I don't remember it much anymore (even the name...). Oh, and lots of games; I had a nice Solitaire version that I can no longer recall the name of. `xeyes` was cute, and running `xroach` was a popular (?) prank for an unsuspecting (but amenable) colleague. A lot of us spent a lot of time customizing our environments, and many eschewed the vendor-standard environment. For instance, a lot of people I knew used `twm` and derivatives (`ctwm` and `tvtwm` were popular), and spent a lot of time tweaking menus and stuff to set things up the way we liked. A lot of folks also wrote custom tools using `tk` or `expectk`. Giving all of that up to run on Linux was a bitter pill to swallow, so there was a real impetus to get X running quickly. Personally, I kept my `tvtwm`-based environment going until I switched to plan9 and then to the Mac as a daily driver. I'm not sure I miss it, but at the time it was head-and-shoulders above anything you could get on Windows or (classic) MacOS. So it wasn't just that people wanted a "familiar terminal multiplexor" as that people wanted the environments they had put a lot of time and energy into building up for themselves, and again, that often meant X. > It seems that the pattern persists till the present day (and yes, it matches with my own dev setup/needs). I wonder to what extent this is a generational thing though. Maybe today’s twenty-somethings spend their days in front of Xcode, VStudio, Eclipse, etc. more than using multiple terminals. I think it probably depends on what people are doing. I more or less switched to using VS Code for my editor, and I'm using a Mac Studio to write this, but my desktop is still littered with terminal windows, I've got a `drawterm` session open to my local Plan 9 network, and am logged into a bunch of old systems (Multics, TOPS-20, VMS, an IBM mainframe, CDC Cyber, RSTS/E, PR1ME), etc. But the way we write software has changed pretty dramatically in the last 3 or so decades. I used to start with an empty C file and write my stuff. Things like linked-lists? Mostly implemented by hand. These days, there are other languages and vast collections of libraries for almost anything imaginable; much of what "programming" is today is glueing together different libraries and making them interact in sophisticated, often quite complex ways. I don't know that it's better, nor that it's always worse, but it is qualitatively different. So almost necessarily the toolsets and environment have changed accordingly. > This ties in with another observation on early window systems. The earliest Unix window system that I could find (i.e. documented) was NUnix from 1981/82. Its desktop was designed around the idea of a dozen or so top level windows, each one being either a shell window or a graphics canvas, with no real concept of a widget set, dialogs, etc., or even of sub-windows. This paradigm seems to have been more or less the same in the Blit terminal, and carried through in MGR, Mux and even as late as 8 1/2. In the context where this serves the needs of core user group, such makes sense. It may be instructive to look at the early X window managers in this regard. One I remember was `uwm` (I think); I recall being struck that it reminded me of rio when I saw it. > It is in stark contrast with developments at the lower/consumer end of the market. The original Mac, GEM and Windows all placed much more emphasis on being a graphical user interface, with standard widgets and UI design elements. On Unix and X it remained a mess. It seems that this was both for technical reasons (X not imposing a standard) and for economic reasons (the Unix wars). Linux then inherited the mess and the core user/developer demographic had no need/wish/time to fix it. I remember the X mantra was, "mechanism, not policy." Which was fine, except that there wasn't much of even a default policy, which made X (IMHO) a bit of a bear to program and meant that interfaces were pretty wildly inconsistent across programs. By contrast, writing simple programs to draw lines on the Mac was easy. Interestingly, frustration with this caused an almost cambrian explosion of new windowing environments within a few years of Linux's arrival on the scene. From larger efforts like Gtk (and then GNOME), KDE, GNUStep (which I guess might predate Linux, but not by much...), etc, to less ambitious things components like fvwm and Enlightenment, we kind of went from "OpenWindows or Motif or roll your own stuff around twm or something" to a whole plethora of things. It's still a bit of a mess, though. > It makes me wonder when true graphical applications started to appear for X / Unix / Linux (other than stuff like terminal, clock, calculator, etc.). The graphical browser certainly is one (1993). StarOffice and Applix seem to have arrived around 1995. Anything broadly used before that? Lots! See above. - Dan C. From tuhs at tuhs.org Tue Feb 28 06:46:10 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 27 Feb 2023 20:46:10 +0000 Subject: [TUHS] Generational development [was Re: Re: Early GUI on Linux] In-Reply-To: <202302272022.31RKMG2L004091@freefriends.org> References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> <202302272004.31RK4aGG001510@freefriends.org> <2f6faeb4-5e73-cf18-b0ff-edc3e1658f72@case.edu> <202302272022.31RKMG2L004091@freefriends.org> Message-ID: I see the wisdom in your last line there, I've typed and deleted a response to this email 4 times, each one more convoluted than the last. The short of my stance though is, as a younger programmer (29), I am certainly not a fan of these trends that are all too common in my generation. That said, I've set foot in one single softare-related class in my life (highschool Java class) and so I don't really know what is being taught to folks going the traditional routes. All I know from my one abortive semester of college is that I didn't see a whole lot of reliance on individual exploration of concepts in classes, just everyone working to a one-size-fits-all understanding of how to be a good employee in a given subject area. Of course, this is also influenced by my philosophy and biases and such, and only represents 4-5 months of observation, but if my minimal experience with college is to be believed, I have little faith that educational programs are producing much more than meat filters between StackOverflow and . No offense to said meat filters, people gotta work, but there is something lost when the constant march of production torpedoes individual creativity. Then again, do big firms want sophisticated engineers or are we too far gone into assembly line programming with no personal connection to any of the products? I'm glad I'm as personally involved in the stuff I work with, I could see myself slipping into the same patterns of apathy if I was a nameless face in a sea of coders on some project I don't even know the legal name of any given day. - Matt G. ------- Original Message ------- On Monday, February 27th, 2023 at 12:22 PM, arnold at skeeve.com wrote: > Chet Ramey chet.ramey at case.edu wrote: > > > On 2/27/23 3:04 PM, arnold at skeeve.com wrote: > > > > > IMHO the dependence upon IDEs is crippling; they cut & paste to the > > > almost total exclusion of the keyboard, including when shell completion > > > would be faster. > > > > Don't forget cargo-culting by pasting shell commands they got from the web > > and barely understand, if at all. > > > Yeah, really. > > I do what I can, but it's a very steep uphill battle, as most > don't even understand that they're missing something, or that > they could learn it if they wanted to. > > I think I'll stop ranting before I really get going. :-) > > Arnold From chet.ramey at case.edu Tue Feb 28 06:50:23 2023 From: chet.ramey at case.edu (Chet Ramey) Date: Mon, 27 Feb 2023 15:50:23 -0500 Subject: [TUHS] Generational development [was Re: Re: Early GUI on Linux] In-Reply-To: <202302272022.31RKMG2L004091@freefriends.org> References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> <202302272004.31RK4aGG001510@freefriends.org> <2f6faeb4-5e73-cf18-b0ff-edc3e1658f72@case.edu> <202302272022.31RKMG2L004091@freefriends.org> Message-ID: <16241ceb-fe92-7f25-bda0-0b327847728d@case.edu> On 2/27/23 3:22 PM, arnold at skeeve.com wrote: > Chet Ramey wrote: > >> On 2/27/23 3:04 PM, arnold at skeeve.com wrote: >> >>> IMHO the dependence upon IDEs is crippling; they cut & paste to the >>> almost total exclusion of the keyboard, including when shell completion >>> would be faster. >> >> Don't forget cargo-culting by pasting shell commands they got from the web >> and barely understand, if at all. > > Yeah, really. > > I do what I can, but it's a very steep uphill battle, as most > don't even understand that they're missing something, or that > they could learn it if they wanted to. > > I think I'll stop ranting before I really get going. :-) Or the horror show that is wget -O - https://some-random-place/random-script.sh | bash (or worse, | sudo bash). Seriously, people, just stop depending so completely on the kindness of strangers. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From bakul at iitbombay.org Tue Feb 28 06:55:58 2023 From: bakul at iitbombay.org (Bakul Shah) Date: Mon, 27 Feb 2023 12:55:58 -0800 Subject: [TUHS] Generational development [was Re: Re: Early GUI on Linux] In-Reply-To: <16241ceb-fe92-7f25-bda0-0b327847728d@case.edu> References: <16241ceb-fe92-7f25-bda0-0b327847728d@case.edu> Message-ID: On Feb 27, 2023, at 12:50 PM, Chet Ramey wrote: > > Or the horror show that is > > wget -O - https://some-random-place/random-script.sh | bash > > (or worse, | sudo bash). > > Seriously, people, just stop depending so completely on the kindness of > strangers. Beware of geeks bearing gifts! From will.senn at gmail.com Tue Feb 28 06:56:57 2023 From: will.senn at gmail.com (Will Senn) Date: Mon, 27 Feb 2023 14:56:57 -0600 Subject: [TUHS] Early GUI on Linux In-Reply-To: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> Message-ID: <808dd3e1-3706-18d7-8109-4271a328d1c0@gmail.com> Paul, While the background information on X alternatives is interesting, I think there's some conflation going on. The distance in time between the linux kernel being posted and X being available on it was an eyeblink, even back then. There was no serious effort to look at other windowing systems in between "hey, what do y'all think of my new kernel - it runs gnu stuff" to "here it is with X and X apps". That said, it was a pain to configure, required just the right mix of video hardware and other hardware, and wasn't for the faint of heart. As X was becoming available on linux licketysplit, some folks either couldn't get it running or didn't have the hardware - those folks were probably the first to go looking at alternatives, but that didn't precede the x on linux effort. Will On 2/25/23 3:31 PM, Paul Ruizendaal wrote: > I think discussion of early Linux is in scope for this list, after all that is 30 years ago. Warren, if that is a mis-assumption please slap my wrist. > > Following on from the recent discussion of early workstations and windowing systems, I’m wondering about early windowing on Linux. I only discovered Linux in the later nineties (Red Hat 4.x I think), and by that time Linux already seemed to have settled on Xfree86. At that time svgalib was still around but already abandoned. > > By 1993 even student class PC hardware already outperformed the workstations of the early/mid eighties, memory was much more abundant and pixels were no longer bits but bytes (making drawing easier). Also, early Linux was (I think) more local machine oriented, not LAN oriented. Maybe a different system than X would have made sense. > > In short, I could imagine a frame buffer device and a compositor for top-level windows (a trail that had been pioneered by Oriel half a decade before), a declarative widget set inspired by the contemporary early browsers and the earlier NeWS, etc. Yet nothing like that happened as far as I know. I vaguely recall an OS from the late 90’s that mixed Linux with a partly in-kernel GUI called “Berlin” or something like that, but I cannot find any trace of that today, so maybe I misremember. > > So here are a few things that I am interested in and folks on this list might remember: > > - were there any window systems popular on early Linux other than X? > > - was there any discussion of alternatives to X? > > - was there any discussion of what kernel support for graphics was appropriate? > > From tuhs at tuhs.org Tue Feb 28 07:01:14 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 27 Feb 2023 21:01:14 +0000 Subject: [TUHS] Generational development [was Re: Re: Early GUI on Linux] In-Reply-To: References: <16241ceb-fe92-7f25-bda0-0b327847728d@case.edu> Message-ID: The official Rust book lists a blind script grab from a website piped into a shell as their "official" install mechanism. To make matters worse, you can't "-O" it with curl as it is the root of its host, so no filename... - Matt G. ------- Original Message ------- On Monday, February 27th, 2023 at 12:55 PM, Bakul Shah wrote: > On Feb 27, 2023, at 12:50 PM, Chet Ramey chet.ramey at case.edu wrote: > > > Or the horror show that is > > > > wget -O - https://some-random-place/random-script.sh | bash > > > > (or worse, | sudo bash). > > > > Seriously, people, just stop depending so completely on the kindness of > > strangers. > > > Beware of geeks bearing gifts! From crossd at gmail.com Tue Feb 28 07:04:59 2023 From: crossd at gmail.com (Dan Cross) Date: Mon, 27 Feb 2023 16:04:59 -0500 Subject: [TUHS] Generational development [was Re: Re: Early GUI on Linux] In-Reply-To: References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> <202302272004.31RK4aGG001510@freefriends.org> <2f6faeb4-5e73-cf18-b0ff-edc3e1658f72@case.edu> <202302272022.31RKMG2L004091@freefriends.org> Message-ID: [Redirecting to COFF; TUHS to Bcc:] On Mon, Feb 27, 2023 at 3:46 PM segaloco via TUHS wrote: > I see the wisdom in your last line there, I've typed and deleted a response to this email 4 times, each one more convoluted than the last. > > The short of my stance though is, as a younger programmer (29), I am certainly not a fan of these trends that are all too common in my generation. That said, I've set foot in one single softare-related class in my life (highschool Java class) and so I don't really know what is being taught to folks going the traditional routes. All I know from my one abortive semester of college is that I didn't see a whole lot of reliance on individual exploration of concepts in classes, just everyone working to a one-size-fits-all understanding of how to be a good employee in a given subject area. Of course, this is also influenced by my philosophy and biases and such, and only represents 4-5 months of observation, but if my minimal experience with college is to be believed, I have little faith that educational programs are producing much more than meat filters between StackOverflow and . No offense to said meat filters, people gotta work, but there is something lost when the constant march of production torpedoes individual creativity. Then again, do big firms want sophisticated engineers or are we too far gone into assembly line programming with no personal connection to any of the products? I'm glad I'm as personally involved in the stuff I work with, I could see myself slipping into the same patterns of apathy if I was a nameless face in a sea of coders on some project I don't even know the legal name of any given day. This is an extraordinarily complicated subject, and it's really full of nuance. In general, I think your categorization is unfair. It sounds like you had a bad experience in your first semester of college. I can sympathize; I did too. But a thing to bear in mind is that in the first year, universities are taking kids (and yes, they are kids...sorry young folks, I don't mean that as a pejorative, but consider the context! For most young people this is their first experience living on their own, their first _real_ taste of freedom, and the first where they're about to be subject to rigorous academic expectations without a lot of systemic support) with wildly uneven academic and social backgrounds and preparing them for advanced study in a particular field...one that most haven't even identified for themselves yet. For the precocious student, this will feel stifling; for many others it will be a struggle. What, perhaps, you see as lack of intellectual curiosity may have in fact been the outward manifestations of that struggle. That said...Things are, legitimately, very different today than they were when Unix was young. The level of complexity has skyrocketed in every dimension, and things have gotten to the point where hack upon hack has congealed into a system that's nearly bursting at the seams. It's honestly amazing that anything works at all. That said, good things have been invented since 1985, and the way many of us "grew up" thinking about problems doesn't always apply anymore. The world changes; c'est la vie. - Dan C. > ------- Original Message ------- > On Monday, February 27th, 2023 at 12:22 PM, arnold at skeeve.com wrote: > > > > Chet Ramey chet.ramey at case.edu wrote: > > > > > On 2/27/23 3:04 PM, arnold at skeeve.com wrote: > > > > > > > IMHO the dependence upon IDEs is crippling; they cut & paste to the > > > > almost total exclusion of the keyboard, including when shell completion > > > > would be faster. > > > > > > Don't forget cargo-culting by pasting shell commands they got from the web > > > and barely understand, if at all. > > > > > > Yeah, really. > > > > I do what I can, but it's a very steep uphill battle, as most > > don't even understand that they're missing something, or that > > they could learn it if they wanted to. > > > > I think I'll stop ranting before I really get going. :-) > > > > Arnold From chet.ramey at case.edu Tue Feb 28 07:15:55 2023 From: chet.ramey at case.edu (Chet Ramey) Date: Mon, 27 Feb 2023 16:15:55 -0500 Subject: [TUHS] Generational development [was Re: Re: Early GUI on Linux] In-Reply-To: References: <16241ceb-fe92-7f25-bda0-0b327847728d@case.edu> Message-ID: <735c811e-62ce-5384-b83f-a3887baac89d@case.edu> On 2/27/23 4:01 PM, segaloco wrote: > The official Rust book lists a blind script grab from a website piped into a shell as their "official" install mechanism. Well, I suppose if it's from a trustworthy source... (Sorry, my eyes rolled so hard they're bouncing on the floor right now.) -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From crossd at gmail.com Tue Feb 28 07:22:04 2023 From: crossd at gmail.com (Dan Cross) Date: Mon, 27 Feb 2023 16:22:04 -0500 Subject: [TUHS] Generational development [was Re: Re: Early GUI on Linux] In-Reply-To: <735c811e-62ce-5384-b83f-a3887baac89d@case.edu> References: <16241ceb-fe92-7f25-bda0-0b327847728d@case.edu> <735c811e-62ce-5384-b83f-a3887baac89d@case.edu> Message-ID: [COFF] On Mon, Feb 27, 2023 at 4:16 PM Chet Ramey wrote: > On 2/27/23 4:01 PM, segaloco wrote: > > The official Rust book lists a blind script grab from a website piped into a shell as their "official" install mechanism. > > Well, I suppose if it's from a trustworthy source... > > (Sorry, my eyes rolled so hard they're bouncing on the floor right now.) I find this a little odd. If I go back to O'Reilly books from the early 90s, there was advice to do all sorts of suspect things in them, such as fetching random bits of pieces from random FTP servers (or even using email fetch tarballs [!!]). Or downloading shell archives from USENET. And of course you _can_ download the script and read through it if you want. And no one forces anyone to use `rustup`. Most vendors ship some version of Rust through their package management system these days. - Dan C. From luvisi at gmail.com Tue Feb 28 08:14:21 2023 From: luvisi at gmail.com (Andru Luvisi) Date: Mon, 27 Feb 2023 14:14:21 -0800 Subject: [TUHS] Early GUI on Linux In-Reply-To: <808dd3e1-3706-18d7-8109-4271a328d1c0@gmail.com> References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> <808dd3e1-3706-18d7-8109-4271a328d1c0@gmail.com> Message-ID: "A pain to configure" indeed! I bought my first PC in '94 or '95 for the purpose of running Linux on it. My roommate and I bought the exact same model, a no name custom build from a local shop, so we could work with each other on figuring it out. They did not have any video mode lines already written for our monitor model, so we needed to construct them manually. I remember spending hours with pencil and paper and calculator and the manual for my monitor trying to create an adequate mode line. And then, when you finally got something close enough to what the monitor would support that you got an image, you had to keep tweaking the numbers and restarting the X server in order to get the image appropriately sized and centered, and avoid it wrapping around one of the edges. Even all these years later, I still remember with deep fondness how elated I was when I learned about xvidtune. I also remember the excitement of finding a Windows tool that could generate a mode line from the current video settings in Windows, but I cannot remember the name or find it right now online. This program is similar, but the initial release date is too late for it to be the one I used. https://www.geocities.ws/podernixie/htpc/modeline-en.html It was the best of times, it was the worst of times. Andru On Mon, Feb 27, 2023, 12:57 PM Will Senn wrote: > Paul, > While the background information on X alternatives is interesting, I > think there's some conflation going on. The distance in time between the > linux kernel being posted and X being available on it was an eyeblink, > even back then. There was no serious effort to look at other windowing > systems in between "hey, what do y'all think of my new kernel - it runs > gnu stuff" to "here it is with X and X apps". > > That said, it was a pain to configure, required just the right mix of > video hardware and other hardware, and wasn't for the faint of heart. As > X was becoming available on linux licketysplit, some folks either > couldn't get it running or didn't have the hardware - those folks were > probably the first to go looking at alternatives, but that didn't > precede the x on linux effort. > > Will > > On 2/25/23 3:31 PM, Paul Ruizendaal wrote: > > I think discussion of early Linux is in scope for this list, after all > that is 30 years ago. Warren, if that is a mis-assumption please slap my > wrist. > > > > Following on from the recent discussion of early workstations and > windowing systems, I’m wondering about early windowing on Linux. I only > discovered Linux in the later nineties (Red Hat 4.x I think), and by that > time Linux already seemed to have settled on Xfree86. At that time svgalib > was still around but already abandoned. > > > > By 1993 even student class PC hardware already outperformed the > workstations of the early/mid eighties, memory was much more abundant and > pixels were no longer bits but bytes (making drawing easier). Also, early > Linux was (I think) more local machine oriented, not LAN oriented. Maybe a > different system than X would have made sense. > > > > In short, I could imagine a frame buffer device and a compositor for > top-level windows (a trail that had been pioneered by Oriel half a decade > before), a declarative widget set inspired by the contemporary early > browsers and the earlier NeWS, etc. Yet nothing like that happened as far > as I know. I vaguely recall an OS from the late 90’s that mixed Linux with > a partly in-kernel GUI called “Berlin” or something like that, but I cannot > find any trace of that today, so maybe I misremember. > > > > So here are a few things that I am interested in and folks on this list > might remember: > > > > - were there any window systems popular on early Linux other than X? > > > > - was there any discussion of alternatives to X? > > > > - was there any discussion of what kernel support for graphics was > appropriate? > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davida at pobox.com Tue Feb 28 08:31:21 2023 From: davida at pobox.com (David Arnold) Date: Tue, 28 Feb 2023 09:31:21 +1100 Subject: [TUHS] Early GUI on Linux In-Reply-To: <808dd3e1-3706-18d7-8109-4271a328d1c0@gmail.com> References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> <808dd3e1-3706-18d7-8109-4271a328d1c0@gmail.com> Message-ID: I think this has its roots in the goals for the system. Linux was developed (let’s say, in the pre 2.x era) as a way to make the PCs that many people could afford into the workstation they couldn't. There was very little effort to make Linux a better operating system, let alone a better Unix: it was “is it good enough to do what I can/could do on Solaris at work/college?” And so, it moved through a pragmatic subset of V7/Minix to a rough POSIX/Solaris syscall interface, and grew an ecosystem of cobbled-together userland that enabled that goal. For the vast majority of its users, X11 was a pre-requisite for serious use: there was more-or-less zero impetus for a competing UI. Perhaps the closest thing to it was GNUstep, which to this day, limps along with very little use (and is implemented over X11 anyway). Look at how drawn-out the adoption of Wayland has been as evidence of how little interest there has been in alternative graphical models. None of that is a bad thing, per se — give me Ubuntu 23.04 over Solaris 2.4 (or even 11) any day: mostly libre, mostly gratis, cheap hardware, and it just works. d > On 28 Feb 2023, at 07:56, Will Senn wrote: > > Paul, > While the background information on X alternatives is interesting, I think there's some conflation going on. The distance in time between the linux kernel being posted and X being available on it was an eyeblink, even back then. There was no serious effort to look at other windowing systems in between "hey, what do y'all think of my new kernel - it runs gnu stuff" to "here it is with X and X apps". > > That said, it was a pain to configure, required just the right mix of video hardware and other hardware, and wasn't for the faint of heart. As X was becoming available on linux licketysplit, some folks either couldn't get it running or didn't have the hardware - those folks were probably the first to go looking at alternatives, but that didn't precede the x on linux effort. > > Will > > On 2/25/23 3:31 PM, Paul Ruizendaal wrote: >> I think discussion of early Linux is in scope for this list, after all that is 30 years ago. Warren, if that is a mis-assumption please slap my wrist. >> >> Following on from the recent discussion of early workstations and windowing systems, I’m wondering about early windowing on Linux. I only discovered Linux in the later nineties (Red Hat 4.x I think), and by that time Linux already seemed to have settled on Xfree86. At that time svgalib was still around but already abandoned. >> >> By 1993 even student class PC hardware already outperformed the workstations of the early/mid eighties, memory was much more abundant and pixels were no longer bits but bytes (making drawing easier). Also, early Linux was (I think) more local machine oriented, not LAN oriented. Maybe a different system than X would have made sense. >> >> In short, I could imagine a frame buffer device and a compositor for top-level windows (a trail that had been pioneered by Oriel half a decade before), a declarative widget set inspired by the contemporary early browsers and the earlier NeWS, etc. Yet nothing like that happened as far as I know. I vaguely recall an OS from the late 90’s that mixed Linux with a partly in-kernel GUI called “Berlin” or something like that, but I cannot find any trace of that today, so maybe I misremember. >> >> So here are a few things that I am interested in and folks on this list might remember: >> >> - were there any window systems popular on early Linux other than X? >> >> - was there any discussion of alternatives to X? >> >> - was there any discussion of what kernel support for graphics was appropriate? >> >> > From jsg at jsg.id.au Tue Feb 28 11:08:53 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Tue, 28 Feb 2023 12:08:53 +1100 Subject: [TUHS] Early GUI on Linux In-Reply-To: References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> Message-ID: On Mon, Feb 27, 2023 at 06:22:09PM +0100, Paul Ruizendaal via TUHS wrote: > > Thanks all for the insights. Let me attempt a summary. > > What it boils down to is that X arrived on Linux very early, because what the Linux hackers needed/wanted was a familiar terminal multiplexer. It seems that the pattern persists till the present day (and yes, it matches with my own dev setup/needs). I wonder to what extent this is a generational thing though. Maybe today’s twenty-somethings spend their days in front of Xcode, VStudio, Eclipse, etc. more than using multiple terminals. > > This ties in with another observation on early window systems. The earliest Unix window system that I could find (i.e. documented) was NUnix from 1981/82. Its desktop was designed around the idea of a dozen or so top level windows, each one being either a shell window or a graphics canvas, with no real concept of a widget set, dialogs, etc., or even of sub-windows. This paradigm seems to have been more or less the same in the Blit terminal, and carried through in MGR, Mux and even as late as 8 1/2. In the context where this serves the needs of core user group, such makes sense. > > === > > It is in stark contrast with developments at the lower/consumer end of the market. The original Mac, GEM and Windows all placed much more emphasis on being a graphical user interface, with standard widgets and UI design elements. On Unix and X it remained a mess. It seems that this was both for technical reasons (X not imposing a standard) and for economic reasons (the Unix wars). Linux then inherited the mess and the core user/developer demographic had no need/wish/time to fix it. > > It makes me wonder when true graphical applications started to appear for X / Unix / Linux (other than stuff like terminal, clock, calculator, etc.). The graphical browser certainly is one (1993). StarOffice and Applix seem to have arrived around 1995. Anything broadly used before that? When did Interleaf and Framemaker have X based versions? "Framemaker was the main application everybody would run to prove that their X box actually worked" Andrew McRae - Sun, Surf and X in California AUUGN, Volume 10, Number 4, August 1989 https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V10.4.pdf From flexibeast at gmail.com Tue Feb 28 11:10:02 2023 From: flexibeast at gmail.com (Alexis) Date: Tue, 28 Feb 2023 12:10:02 +1100 Subject: [TUHS] Early GUI on Linux In-Reply-To: References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> Message-ID: <87k0027fs0.fsf@ada> Dan Cross writes: > There > was a fractal viewer that I thought was fun, but I don't > remember it > much anymore (even the name...) My guess is that it was probably 'xaos'? Certainly i had fun with it: https://xaos-project.github.io/ (My first Unix-like system was RedHat 5.2 'Apollo', in the late 90s.) Alexis. From clemc at ccc.com Tue Feb 28 11:15:47 2023 From: clemc at ccc.com (Clem Cole) Date: Mon, 27 Feb 2023 20:15:47 -0500 Subject: [TUHS] Early GUI on Linux In-Reply-To: References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> Message-ID: I believe Ken Keller wrote the original framemaker using X10 - (maybe 11 but I thought it was 10) running on a Sun3 - I’ll try ask him. He was trying to keep it systems independent and at the time X was the most promising way to do that. On Mon, Feb 27, 2023 at 8:09 PM Jonathan Gray wrote: > On Mon, Feb 27, 2023 at 06:22:09PM +0100, Paul Ruizendaal via TUHS wrote: > > > > Thanks all for the insights. Let me attempt a summary. > > > > What it boils down to is that X arrived on Linux very early, because > what the Linux hackers needed/wanted was a familiar terminal multiplexer. > It seems that the pattern persists till the present day (and yes, it > matches with my own dev setup/needs). I wonder to what extent this is a > generational thing though. Maybe today’s twenty-somethings spend their days > in front of Xcode, VStudio, Eclipse, etc. more than using multiple > terminals. > > > > This ties in with another observation on early window systems. The > earliest Unix window system that I could find (i.e. documented) was NUnix > from 1981/82. Its desktop was designed around the idea of a dozen or so top > level windows, each one being either a shell window or a graphics canvas, > with no real concept of a widget set, dialogs, etc., or even of > sub-windows. This paradigm seems to have been more or less the same in the > Blit terminal, and carried through in MGR, Mux and even as late as 8 1/2. > In the context where this serves the needs of core user group, such makes > sense. > > > > === > > > > It is in stark contrast with developments at the lower/consumer end of > the market. The original Mac, GEM and Windows all placed much more emphasis > on being a graphical user interface, with standard widgets and UI design > elements. On Unix and X it remained a mess. It seems that this was both for > technical reasons (X not imposing a standard) and for economic reasons (the > Unix wars). Linux then inherited the mess and the core user/developer > demographic had no need/wish/time to fix it. > > > > It makes me wonder when true graphical applications started to appear > for X / Unix / Linux (other than stuff like terminal, clock, calculator, > etc.). The graphical browser certainly is one (1993). StarOffice and Applix > seem to have arrived around 1995. Anything broadly used before that? > > When did Interleaf and Framemaker have X based versions? > > "Framemaker was the main application everybody would run to prove that > their X box actually worked" > Andrew McRae - Sun, Surf and X in California > AUUGN, Volume 10, Number 4, August 1989 > https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V10.4.pdf > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Tue Feb 28 11:27:18 2023 From: crossd at gmail.com (Dan Cross) Date: Mon, 27 Feb 2023 20:27:18 -0500 Subject: [TUHS] Early GUI on Linux In-Reply-To: <87k0027fs0.fsf@ada> References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> <87k0027fs0.fsf@ada> Message-ID: On Mon, Feb 27, 2023 at 8:14 PM Alexis wrote: > Dan Cross writes: > > There > > was a fractal viewer that I thought was fun, but I don't > > remember it > > much anymore (even the name...) > > My guess is that it was probably 'xaos'? Certainly i had fun with > it: > > https://xaos-project.github.io/ I believe that's it. Thanks, Alexis! - Dan C. From tuhs at tuhs.org Tue Feb 28 11:40:38 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 28 Feb 2023 01:40:38 +0000 Subject: [TUHS] UNIX 4.1 User's Manual Restoration Message-ID: Got a little present for folks today. Been working on this for a little while now, and while there'll probably be some edits here and there, I believe it to be quite accurate. After the link is a manpage restoration of the UNIX 4.1 User's Manual (3B20S) that I bought a little while ago: https://gitlab.com/segaloco/pwb4u_man The permuted index is the only significant piece that isn't done, but that shouldn't impact the informational value. Note this is just u_man, I haven't found a complimentary a_man copy yet. I hope one will turn up one of these days, but I plan on at least analyzing the gap between System III and System V with regards to those pages as a future project. My process involved diff'ing the available III and V manpage sources and reconciling differences between the two and 4.1 with some copy-paste here and some restoration there. Where differences couldn't be resolved, I simply removed content to match the physical pages. One minute detail that is also not filled in is the page count in M.folio. So I didn't count the pages. Maybe someday. In any case, I appreciate the opportunity this has given me to learn the manpage macros pretty well. Anywho, in the second pass of verifying the changes I took some notes on noteworthy mentions. This list is not an exhaustive analysis but represents some of the areas where significant developments shine through in the text: System III->4.1 (No claims are made as to what occurred at 4.0): - The documentation is cleaned up quite a bit in general, in what seems like a push towards commercial-ready manuals. Many sections are edited to be more clear and descriptive. There is also a notable shift towards gender neutral language. The editors and acknowledgements info are removed, casting an anonymous shadow over the manual maintainers and their muses alike. - The tty manpage is renamed termio, reflecting the shifting terminal interface landscape at this time. - This release adds IPC with a familiar interface to what is in System V. According to various accounts the IPC was under heavy development at this time, but while the underlying components may have been shifting and changing, the documentation changes suggest a relatively stable programmer API by this point. The only IPC-related piece System V adds is icprm(1). - The LP print service is added here. The old lpr system is still there in the background; it is in System V. However, it is relegated to DEC only status. - SGS and COFF development components show up with 4.1 3B-20. No telling what else they officially supported in the 4.x timeframe. The System V pages as described below indicate a number of supported platforms. - The shell gets the $CDPATH and ulimit features - Many system features show a trend towards portability (except the PDP-11, the system appears to be moving away from it) - The Virtual Protocol Machine (VPM) seems to go from targeting KMC11 to UN53 and V.35. Haven't researched what these are yet, but VPM is on the move. - As of 4.1, 3B-20 does *not* support: Fortran, BASIC, Honeywell/GCOS 6000 connectivity, lpr printing, SNOBOL, standalone C - Added pages include cflow(1), cprs(1), cxref(1), dis(1), dump(1) (was a tape dump (1m), now a SGS tool), enable(1), hpio(1), ipcs(1), list(1), lp(1), lpstat(1), newform(1), sadp(1), trouble(1), x25pvc(1), msgctl(2), msgget(2), msgop(2), plock(2), semctl(2), semget(2), semop(2), shmctl(2), shmget(2), shmop(2), sys3b(2), drand48(3c), getcwd(3c), hsearch(3c), ld*(3x) (COFF library), setbuf(3s), stdipc(3c), strtol(3c), termio(4) (renamed from tty(4)), ldfcn(5), mosd(5), mptx(5), jotto(6) - Removed pages include cref(1), dump(1m), fget.odemon(1c), odpd(1c), orjestat(1c), reform(1), tp(1), typo(1), xref(1), tp(4), tty(4) (renamed to termio(4)) - Some pages were skipped and show back up in System V with minimal changes, meaning they were probably in 4.x: adb(1), arcv(1), bs(1), dpd(1c), dpr(1c), efl(1), f77(1), factor(1), fget(1c), fget.demon(1c), fsend(1c), gcat(1c), gcosmail(1c), kas(b)/kun(b)(1), lpd(1c), lpr(1), ratfor(1), scc(1), sno(1), vpr(1) 4.1->System V (Likewise, there was at least a 4.2): - Documentation is cleaned up and edited some more. Almost everywhere that the name "UNIX" occurs, it has been replaced with some variation on "The UNIX System" with a capital S. This is lower case in my 5.0 manual which I have not combed for differences with System V yet. Still, the "system" following is standard by 5.0 it seems. This is right around the time of dashing Bell associations too, so variations of this manual exist with and without the Bell logo on the front, and with varying degrees of modification to explain the legal landscape involved. - Section 3 in particular sees a pretty significant rewrite effort. This coincides with MR 1055 here: https://archive.org/details/unix-system-release-description-system-v/I%20-%20UNIX%20System%20Modification%20Requests%20Resolved%20in%20UNIX%20System%20V/page/n35/mode/2up - A new portable archive format is introduced. By the sounds of it, this introduces a new header type into the ar(4) format. - A new 1024-block filesystem is introduced, along with necessary support. - A new synchronous terminal interface is added. - VAX is supported by SGS/COFF now. Additional platforms as suggested by formatting marks in the pages include: Basic-16, Bellmac 32, and 8086, in addition to the already supported 3B-20. Unknown whether these platforms found any support with USG releases. - ex(1) is added (along with vi(1) and edit(1)). There is also the se(1) editor which I don't know much about. - CB-init is added, shaking up the /etc/inittab format and many login-related features. MAUS also steps in from CB for shared memory on PDP-11. - Added pages include asa(1), convert(1), cpp(1), edit(1), ex(1), fsplit(1), ipcrm(1), machid(1), makekey(1), net(1c), nscstat(1c), nsctorje(1c), nusend(1c), scat(1), se(1), stlogin(1), ststat(1), vi(1), maus(2), clock(3c), dial(3c), erf(3m), getut(3c), matherr(3m), memory(3c), sputl(3x), ttyslot(3c), x25*(3c), filehdr(4), gettydefs(4), issue(4), linenum(4), reloc(4), scnhdr(4), syms(4) - Removed pages include vpmc(1c), vpmsave(1c), vpmset(1c), x25pvc(1c), fptrap(3x) That's all I've got. As time goes on I'll start documenting worthwhile tidbits in the Wiki. If there's any question of the contents of any of the pages, I'll happily consult the original and make corrections, and can scan any page to verify the contents if needed. I'll eventually be scanning the whole thing, just not right now. Feel free to open a pull request if you think something needs to change. - Matt G. From dave at horsfall.org Tue Feb 28 13:35:09 2023 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 28 Feb 2023 14:35:09 +1100 (EST) Subject: [TUHS] Early GUI on Linux In-Reply-To: References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> Message-ID: On Sun, 26 Feb 2023, John Cowan wrote: > However, most configuration errors can't reduce your hardware to a > useless pile of junk, whereas older CRT monitors could definitely be > destroyed if the configuration was too far off nominal. Not to mention MS-DOS malware that used to set the horizontal deflection rate really high and creating massive inductive spikes, or the vertical deflection to zero and burning out the phosphor... -- Dave From akosela at andykosela.com Tue Feb 28 17:48:55 2023 From: akosela at andykosela.com (Andy Kosela) Date: Tue, 28 Feb 2023 08:48:55 +0100 Subject: [TUHS] Unix/Linux games [was Re: Early GUI on Linux] Message-ID: On Monday, February 27, 2023, Dan Cross wrote: > On Mon, Feb 27, 2023 at 12:22 PM Paul Ruizendaal via TUHS > wrote: > > Thanks all for the insights. Let me attempt a summary. > > > > Oh, and lots of games; I had a nice > Solitaire version that I can no longer recall the name of. > > Coming from the 8-bit microcomputer world (Atari 8-bit, C64), and then upgrading to 16-bit (Amiga and PC MS-DOS) I experienced a myriad of unforgettable games on those platforms. They were mostly commercial but they were very much different from modern games. It was the era of innovation and pouring all your soul into the games you produce. I still think that some of them have not been surpassed in quality and playability. I still play them on period correct hardware as they are still extremely fun and challenging. This is my top 10 list (sorted by year): * Prince of Persia * The Secret of Monkey Island * Civilization * Dune II * Master of Orion * Reunion * Warcraft * Ascendancy * Quake * Half-Life As I started to play with Linux in the mid 90s I remember a port of Doom and then Quake, but not that many other games. Can you elaborate more on what Unix afficionados played in the late 80s/early 90s? --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Tue Feb 28 17:59:55 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 28 Feb 2023 00:59:55 -0700 Subject: [TUHS] Generational development [was Re: Re: Early GUI on Linux] In-Reply-To: References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> <202302272004.31RK4aGG001510@freefriends.org> <2f6faeb4-5e73-cf18-b0ff-edc3e1658f72@case.edu> <202302272022.31RKMG2L004091@freefriends.org> Message-ID: <202302280759.31S7xt4e001399@freefriends.org> As Dan said, this is nuanced. While I'm sure there's lots of mediocre programmers writing mediocre code, (a) there probably always has been [think COBOL on mainframes] and (b) it is not universal. I have generally been fortunate to find interesting and challenging work in a fairly long career; there's lots of interesting problems out there that need solving which can't be dealt with by just stringing together existing class libraries using an IDE on autopilot. You have to look for it, and then hope you're qualified enough that they'll hire you. HTH, Arnold segaloco wrote: > I see the wisdom in your last line there, I've typed and deleted a > response to this email 4 times, each one more convoluted than the last. > > The short of my stance though is, as a younger programmer (29), > I am certainly not a fan of these trends that are all too common in > my generation. That said, I've set foot in one single softare-related > class in my life (highschool Java class) and so I don't really know > what is being taught to folks going the traditional routes. All I > know from my one abortive semester of college is that I didn't see a > whole lot of reliance on individual exploration of concepts in classes, > just everyone working to a one-size-fits-all understanding of how to > be a good employee in a given subject area. Of course, this is also > influenced by my philosophy and biases and such, and only represents 4-5 > months of observation, but if my minimal experience with college is to be > believed, I have little faith that educational programs are producing > much more than meat filters between StackOverflow and editor here>. No offense to said meat filters, people gotta work, but > there is something lost when the constant march of production torpedoes > individual creativity. Then again, do big firms want sophisticated > engineers or are we too far gone into assembly line programming with no > personal connection to any of the products? I'm glad I'm as personally > involved in the stuff I work with, I could see myself slipping into the > same patterns of apathy if I was a nameless face in a sea of coders on > some project I don't even know the legal name of any given day. > > - Matt G. > > ------- Original Message ------- > On Monday, February 27th, 2023 at 12:22 PM, arnold at skeeve.com wrote: > > > > Chet Ramey chet.ramey at case.edu wrote: > > > > > On 2/27/23 3:04 PM, arnold at skeeve.com wrote: > > > > > > > IMHO the dependence upon IDEs is crippling; they cut & paste to the > > > > almost total exclusion of the keyboard, including when shell completion > > > > would be faster. > > > > > > Don't forget cargo-culting by pasting shell commands they got from the web > > > and barely understand, if at all. > > > > > > Yeah, really. > > > > I do what I can, but it's a very steep uphill battle, as most > > don't even understand that they're missing something, or that > > they could learn it if they wanted to. > > > > I think I'll stop ranting before I really get going. :-) > > > > Arnold From lars at nocrew.org Tue Feb 28 20:44:37 2023 From: lars at nocrew.org (Lars Brinkhoff) Date: Tue, 28 Feb 2023 10:44:37 +0000 Subject: [TUHS] Unix/Linux games [was Re: Early GUI on Linux] In-Reply-To: (Andy Kosela's message of "Tue, 28 Feb 2023 08:48:55 +0100") References: Message-ID: <7wbklet6ga.fsf@junk.nocrew.org> Andy Kosela wrote: > Can you elaborate more on what Unix afficionados played in the late > 80s/early 90s? Dungeon/Zork Rogue Nethack Mazewar XPilot From tuhs at tuhs.org Tue Feb 28 21:02:28 2023 From: tuhs at tuhs.org (Arno Griffioen via TUHS) Date: Tue, 28 Feb 2023 12:02:28 +0100 Subject: [TUHS] Unix/Linux games [was Re: Early GUI on Linux] In-Reply-To: <7wbklet6ga.fsf@junk.nocrew.org> References: <7wbklet6ga.fsf@junk.nocrew.org> Message-ID: On Tue, Feb 28, 2023 at 10:44:37AM +0000, Lars Brinkhoff wrote: > Andy Kosela wrote: > > Can you elaborate more on what Unix afficionados played in the late > > 80s/early 90s? > > Dungeon/Zork > Rogue > Nethack > Mazewar > XPilot Also quite a few multiplayer ones like xpilot.. 'Hunt' (terminal/ASCII) Spellcast (X11) Crossfire (X11) Not really a game, but hugely fun at the time 'xspringies' Bye, Arno. From dam at opencsw.org Tue Feb 28 21:06:50 2023 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 28 Feb 2023 12:06:50 +0100 Subject: [TUHS] Unix/Linux games [was Re: Early GUI on Linux] In-Reply-To: <7wbklet6ga.fsf@junk.nocrew.org> References: <7wbklet6ga.fsf@junk.nocrew.org> Message-ID: <7F070CC2-410C-4DDA-A9E4-05FC207A276B@opencsw.org> Hi, > Am 28.02.2023 um 11:44 schrieb Lars Brinkhoff : > > Andy Kosela wrote: >> Can you elaborate more on what Unix afficionados played in the late >> 80s/early 90s? > > Dungeon/Zork > Rogue > Nethack > Mazewar > XPilot xBattle, which was a multiplayer game to be run on one workstation which opened windows for each player on different X displays - at that time (early 90s) there was no network mode. -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896