On 14 Jul 2021 10:19 +0200, from angus(a)fairhaven.za.net (Angus Robinson): And all this, of course, ignoring the other issue of what might be considered a "start to the open source operating system movement", given that even development of GNU was well underway by the time the Linux kernel got started (having been worked on since early 1984), and one might even be able to argue that the early UNIX systems were also, in a sense, open source. -- Michael Kjörling • https://michael.kjorling.se • michael(a)kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”

On Wed, Jul 14, 2021 at 09:07:19AM +0000, Lars Brinkhoff wrote: X10 and X11 predate all of this and at least X11 is open source. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm

History of the MIT license first used for PC/IP in 1984 and then for X Windows (read the link, fascinating "influence" was so important and the benefits MIT got from that): https://web.mit.edu/Saltzer/www/publications/MITLicense.pdf

Michael Kjörling <michael(a)kjorling.se> writes: Ditto MINIX, of course, which was released, along with the book, in 1987. -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in computer science. --Alan Kay

IBM was (inadvertantly) giving away the source to a few of its System/360 OSes in the 1960s ...

Sigh ... Warren I am going to ask for your indulgence once here on TUHS as I try to get any *new* discussion moved to COFF, but I guess it's time to renew this history as enough people have joined the list since the last time this was all discussed ... I'll do this once -- please take any other discussion off this list. It has been argued too many times. Many of the actors in this drama are part of the list. Sadly we have lost a few, sometimes because of the silliness of the argument/trying to give people credit or not/person preferences, etc. If you want to comment, please go back and read both the TUHS and COFF archives and I suspect your point may have already been made. *If you really do have something new, please move to COFF.* On Wed, Jul 14, 2021 at 4:21 AM Angus Robinson &lt;angus(a)fairhaven.za.net&gt; wrote: A number of us, such as Larry and I have discussed this a bunch both online and in person. What would become 386BSD was actually available as early as 1988, but you needed to know the public FTP address of where to get it at UCB (which the UCB licensees had access to that FTP server). Bostic was still working on what would become the 'NET' release, but this tarball offered a bootable system and did have things in it that later AT&T would require UCB to remove. In fact, this system would have X10 ported to it and was a reasonably complete 'distro' in today's terms. By formal definition, the tarball and the rest of UNIX from Research is and always has been, '*Open Source*' in the sources were available. *But they were licensed*. This was fairly typical of much early software BTW. The binary nature only came about with the minicomputers. The tarball in question was fairly easy to find in the wild but to use the sources as a system, you technically needed an AT&T license. An practically you needed access to a BSD box to rebuild them, which took a license - although by then SunOS was probably close enough - although I do not know anyone that tried it. The sources in the tarball were not '*Free and Open Source*' -- which becomes the crux of the issue. [Sadly the OSS folks have confused this over the years and that important detail is lost]. Many people, such as myself, when the AT&T suite began got worried and started hacking on Linux at that point as the not nearly as mature but sort of works version without networking or graphics had appeared [386BSD had both and a real installer - more in a minute] FWIW: Linus could have had access to the BSD for a 386 tarball if we had asked in the right place. But as he has said later in time, he wanted to write his own OS and did not both ask the right folks at his University, or try to get permission. Although he has said he access to Sun3 and has said that was his impetus for his work. This is an important point that Larry reminds us of, many institutions kept the sources locked away like his U of Wis. Other places were like liberal about access. IIRC Larry sometimes refers to it as the "UNIX Club." In my own case, I was running what would become 386BSD on my Wyse 32:16 box at home and on an NCR 386 based system in Clemson as I was consulting for them at the time. I also helped Bill with the PC/AT disk driver[WD1003 and later WD7000/SCSI controllers], as I had access to the docs from WD which Bill did not. I think I still have a photocopy of them. What basically happened is as BSDi forked and that begets a number of things, from hurt feelings to a famous law suite. A number of us, thought the latter was about copyright (we were wrong it was about trade secret). We were worried that the AT&T copyright would cause UNIX for an inexpensive processor to disappear. We >>thought<< (incorrectly) that the copyright that Linux was using, the GPL, would save us. Turns out >>legally<< it would not have, if AT&T had won, at least in the USA and most NATO Allies - the trade secret applied to all implementations of Ken, Dennis, and the rest of the BTL folk's ideas. All of the Unix-like systems were in violation at this point. BSDi/UCB was where AT&T started. The problem is that while the court found that AT&T did create and own the >>ideas<< (note ideas are not the source code implementation of the ideas), they could not call the UNIX 'IP', trade secrets since the AT&T people published them all both academically in books like Maury Bach's, much less they had been forced by the 1956 consent decree to make the license available, they had taught an industry. BTW: It's not just software, the transistor 'gets out' of AT&T under the same type of rules. In reality, like PGP, since there was lots of UNIX-based IP in other places, it hard to see in practice how AT&T could have enforced the trade secret. But again -- remember Charlie Brown (AT&T CEO) wants to go after IBM, thinking the big money in computers in the mainframe. So they did believe that they could exert pressure on UNIX-like systems for the higher end, and they might have been able to enforce that.

On Wed, Jul 14, 2021 at 01:40:53PM -0400, Theodore Y. Ts'o wrote: Clem was in "the club". I do remember those times, barely, I was a bit too young to have a clear view of things. But it certainly seemed like some Universities made the source pretty available. UW Madison was not one of those, I had to beg and plead to get access to the source. So Clem's memory is fine, his experience was you could get the source. But that wasn't the universal experience at all, and I agree with Ted that just getting access to the source doesn't make it remotely open source.

On 7/14/21, Michael Kjörling &lt;michael(a)kjorling.se&gt; wrote: I consider the birth of Linux to be August 25th 1991, when Linus announced it on comp.os.minix. If he had access to 386BSD in 1991 then probably he would never have started the Linux project -- that's his words. He was exposed to UNIX at uni in late 1990, and purchased 386DX33 on January 5th, 1991 -- a turning point in his life. After messing around with MS-DOS and games like Prince of Persia (still one of the best computers games ever!) for a few months, he started exploring programming tools for MS-DOS and wanted to write a UNIX clone for his home computer. The rest is literally the history... --Andy

On Wed, 14 Jul 2021, Michael Kjörling wrote: Could be; I got that news from one of those daily history sites (I don't always trust Wikipedia). That could be the source of the confusion. -- Dave

On Thu, Jul 15, 2021 at 10:33:52PM -0400, risner(a)stdio.com wrote: To be fair, Linux in 1991 was a very primitive affair; no TCP/IP, no X Windows. We had C-Kermit, and we had emacs, and we had basic shell utilities and a compiler. But not much else. So I doubt it would have been a good replacement for SVR3. The big difference was that Linus accepted patches, and turned around new releases *quickly* while Jolitz apparently sat on patches until the NetBSD and FreeBSD people finally lost patience and released a fork with their patch sets in 1993. So while Linux in 1992 was probably behind 386BSD from a feature perspective, its development velocity was much faster. I remember a friendly rivalry that I had with Bruce D. Evans in Australia, who was working on the serial driver for FreeBSD, where we would exchange tips and techniques for making the serial driver on our respective OS's more CPU efficient. (The metric was to see who could most reduce the system overhead of the serial interrupt and tty layers when running a C-Kermit file transfer over a pair of RS-232 ports connected via a loopback cable.) It was a lot of fun, and we both gained a lot from the exchange of ideas, but finally, I came up with an idea (flip buffers) that really reduced Linux's serial/tty overhead, but which Bruce couldn't match in FreeBSD, because the FreeBSD core team thought that clists were handed down from Mount Olympus by the Gods of BSD, and making that kind of change in the tty layer was tantamount to heresy. Heh. - Ted

On Thu, Jul 15, 2021 at 10:51:11PM -0700, Bakul Shah wrote: The trick that I used was two have two "flip buffers" which were dedicated for each serial port. One buffer would be filled by the interrupt handler, while the other would be buffer would be processed by the bottom half (read: software interrupt) handler. When the bottom half handler had emptied one buffer, it would check to see if there were any characters in the other buffer, and if so, flip the two and process the characters in that buffer. Exclusion was handled by a combination of disabling serial interrupts and using a spinlock (which was held just long enough to flip the pointers to the two flip buffers). With this scheme I could handle multiple pairs of 115200 baud streams at full rates before the 40 MHz CPU was saturated. No memory allocation is required on the hot paths, and the amount of processing that is done in the hardware interrupt context is the absolute minimum. I also added a bit test against 32-byte bitarray to determine whether a character could be handled via the fast path or require special handling (in case it was a ^C, ^U, ^S, etc.) but that was important only for cooked mode; it wasn't needed for raw mode. I suspect this hack would become less or even not helpful as Intel processors became more Spectre- and Meltdown-susceptible, but for the 386, it was a win. :-) - Ted

On Fri, Jul 16, 2021 at 9:57 AM Larry McVoy &lt;lm(a)mcvoy.com&gt; wrote: Yeah, it was pretty standard for networking interfaces. I think I first saw it I'm the MIT Chaos driver maybe? In many ways, Gurwitz's whole mbuf memory scheme for the ethernet controllers and the whole IP stack that lives on in BSD is based on the idea. Rob used a number of different size buffers, not just the two, but the idea is the same, never copy anything if we can avoid it. Play pointer games in the top, bottom, and middle parts of the driver/stack. A huge difference, as Ted I'm sure knows, is that you tended to have many more serial lines than network interfaces. I suspect Rob's scheme would have sucked trying to support traditional single-byte serial interfaces or really just use too much memory to be practical. ᐧ

On Jul 16, 2021, at 6:56 AM, Larry McVoy &lt;lm(a)mcvoy.com&gt; wrote: This is somewhat h/w dependent. Ideally you want the h/w to do some buffering for streaming at full speed so that you don't need to take a per char or per packet interrupt. Hence NS16550 which used a 16 char FIFO. AMD LANCE used a ring of 2^N buffer descriptors. Intel 82586 used a linked list - don't recall if you had to make it a circular buffer. The early 3COM controller didn't buffer more than a packet and you had to copy it. As a contractor I did a couple of network drivers for 3rd party hardware for SGI in late '80s & early '90s. I don't recall any details now but in both cases the h/w did buffer up a bunch. Once things are handed to s/w, you have a lot more flexibility. Though I never liked the idea of splitting a packet up in multiple mbufs!

On Fri, Jul 16, 2021 at 3:08 PM Kevin Bowling &lt;kevin.bowling(a)kev009.com&gt; wrote: Absolutely -- I believe it was Rob's undergrad project at Brown that he brought to BBN. The first use, if I saw, was the 'portable IP/TCP' stack BBN did for HP/3000 and a couple of other systems. That code seems to have been lost. I have asked about it on the Internet history mailing list. I had a copy of it one time, but sadly I don't think I still do. IIRC The original PDP-11 IP implementation which ran on a couple of dedicated systems, whose names/function I frankly do not remember) was also based on a version of this code. I think it ran something like RT-11 or DOS-11 and then started the IP code -- basically RTR style today. Later it morphed into Rob's Vax BSD 4.1 specific stack, which we ran at UCB on a couple of the systems using 3M Xerox board. This latest until 4.1A and Joy's rewrite and I want to say we switched in Interlan 10M boards then. We have a couple of the 3Com boards, but because of the lack of buffering, they were a bear to use and stopped as soon as we got the Interlan one. Anyway, all of these IP/TCP stacks used Rob's mbuf code. Which was a blessing and a curse. By writing his own, he avoids huge changes/integration into the memory system, but it also helped to make BSD such a mess under the covers because there were so many private memory managers between the network, the I/O systems etc... As discussed previously on the TUHS list, the one thing Risner really did well had a uniform memory design. Later BSD's moved to Mach and tried to clean this up a little, but the network code was by then so screwed into Rob's mbuf scheme, it stayed around a long time. Werner -- what is the state of this these days in FreeBSD is it still there? Well, ask Rob :-) I've lost track of him since Stellar, and I think he I heard he left high tech but frankly don't know. Clem ᐧ

Richard Salz &lt;rich.salz(a)gmail.com&gt; wrote: I think it was "my dog Biff..." Wasn't that Heidi Stetner's dog or something? Apparently he used to bark whenever the mailman showed up, inspiring the BSD biff(1) command. I had that calendar, and kept it for many years. There was a lovely picture of a shepherd boy trying to herd cats. I don't remember the rest, other than that they were amusing. I think I finally tossed it though. Arnold

On 7/18/21 6:13 AM, arnold(a)skeeve.com wrote: I just turned up a copy, it's from 1993 I'll have it on bitsavers under pdf/mtXinu later today

On 7/18/21 6:43 AM, Al Kossow wrote: the coincidence was asking about it on exactly that year it's up now under http://bitsavers.org/pdf/mtXinu is supposed to be pronouced zee new or zeye new ?

On Jul 18, 2021, at 9:45 AM, Al Kossow &lt;aek(a)bitsavers.org&gt; wrote: Don't know how it is supposed to be pronounced but I have always pronounced it as 'zai-noo, with xi the way the greek letter ξ is pronounced in English.

Hi. Al Kossow &lt;aek(a)bitsavers.org&gt; wrote: Thanks! It's not the calendar Rich and I remember, but it's still worth having. :-) I always pronounced it zee new. Arnold

On Sun, 18 Jul 2021 09:44:53 -0700 Al Kossow &lt;aek(a)bitsavers.org&gt; wrote: Thanks, Al!!! Lyle -- 73 NM6Y Bickley Consulting West https://bickleywest.com "Black holes are where God is dividing by zero"