From rodrigosloop at gmail.com Thu Aug 1 02:49:29 2019 From: rodrigosloop at gmail.com (=?UTF-8?Q?Rodrigo_G=2E_L=C3=B3pez?=) Date: Wed, 31 Jul 2019 18:49:29 +0200 Subject: [TUHS] Who's behind the UNIX filesystem permission implementation In-Reply-To: References: Message-ID: Multics had modes per file (https://multicians.org/fjcc4.html) but i don't know about the origins. the simpler approach of owner/group/other is a purely Unix creation and i would bet Ken Thompson is behind it all. i would love to know more. -rodri On Wed, Jul 31, 2019, 12:00 PM Stephan Han. wrote: > Hello Unix enthusiasts. > > I'd like to know who or the group of people behind implementing this > filesystem permission system. > Since we are using this system for nearly 40 years and it addresses all > the aspects of the permission matter without any hustle. > I'm inspired to know who/how came up with this theory? > Also if it derived from somewhere else or If there's an origin story about > this, it would be worth to share. > > Cheers. > Stephan > > -- > No When > -------------- next part -------------- An HTML attachment was scrubbed... URL: From toby at telegraphics.com.au Thu Aug 1 03:00:21 2019 From: toby at telegraphics.com.au (Toby Thain) Date: Wed, 31 Jul 2019 13:00:21 -0400 Subject: [TUHS] Who's behind the UNIX filesystem permission implementation In-Reply-To: References: Message-ID: On 2019-07-31 5:59 a.m., Stephan Han. wrote: > Hello Unix enthusiasts. > > I'd like to know who or the group of people behind implementing this > filesystem permission system. > Since we are using this system for nearly 40 years and it addresses all > the aspects of the permission matter without any hustle. It may not address "all aspects" since it has been necessary for some purposes to extend the permission model substantially over time, such as ACLs, SELinux, etc. --Toby > I'm inspired to know who/how came up with this theory? > Also if it derived from somewhere else or If there's an origin story > about this, it would be worth to share. > > Cheers. > Stephan > > -- > No When From imp at bsdimp.com Thu Aug 1 03:18:08 2019 From: imp at bsdimp.com (Warner Losh) Date: Wed, 31 Jul 2019 12:18:08 -0500 Subject: [TUHS] Who's behind the UNIX filesystem permission implementation In-Reply-To: References: Message-ID: On Wed, Jul 31, 2019, 12:09 PM Toby Thain wrote: > On 2019-07-31 5:59 a.m., Stephan Han. wrote: > > Hello Unix enthusiasts. > > > > I'd like to know who or the group of people behind implementing this > > filesystem permission system. > > Since we are using this system for nearly 40 years and it addresses all > > the aspects of the permission matter without any hustle. > > It may not address "all aspects" since it has been necessary for some > purposes to extend the permission model substantially over time, such as > ACLs, SELinux, etc. > He did say they solved the problem without hassle. All those other things introduced hassle. :) There is also all the various capacity frameworks to self limit what you are allowed to do as any easy to administer exploits... Warner --Toby > > > > I'm inspired to know who/how came up with this theory? > > Also if it derived from somewhere else or If there's an origin story > > about this, it would be worth to share. > > > > Cheers. > > Stephan > > > > -- > > No When > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From krewat at kilonet.net Thu Aug 1 03:29:16 2019 From: krewat at kilonet.net (Arthur Krewat) Date: Wed, 31 Jul 2019 13:29:16 -0400 Subject: [TUHS] Who's behind the UNIX filesystem permission implementation In-Reply-To: References: Message-ID: On 7/31/2019 12:49 PM, Rodrigo G. López wrote: > Multics had modes per file (https://multicians.org/fjcc4.html) but i > don't know about the origins. the simpler approach of > owner/group/other is a purely Unix creation and i would bet Ken > Thompson is behind it all. TOPS-10 had a 3 octal digit file protection code: - - Logins are PPNs - [Project, Programmer] - So if I was [76,5], another user with [76,10] was in the same project. Much like UNIX groups. Owner Protection Codes 7*, 6* - You can execute, read, or change the protection code of the file. 5* - You have unlimited access to the file, except for renaming it. 4* - You have unlimited access to the file. 3 - You can execute, read, or change the protection code of the file. 2 - You have unlimited access to the file, except for renaming it. 1, 0 - You have unlimited access. * The File Daemon is called on a protection failure on this file (my memory is a little fuzzy on this, but I believe it allowed finer grained protections). Protection Codes for Fields 2 and 3 7 - The user cannot access the file. 6 - The user can only execute the file. 5 - The user can execute or read the file. 4 - The user can execute, read, or append to the file. 3 - The user can execute, read, append to, or update the file. 2 - The user can execute, read, append to, update, and write to the file. 1 - The user can execute, read, append to, update, write to, and rename the file. 0 - Unlimited access, including changing the protection code of the file. The name TOPS-10 was first used in 1970, but the monitor itself dates back to 1964. I'm not sure when these protection codes came into being, though. From clemc at ccc.com Thu Aug 1 03:58:40 2019 From: clemc at ccc.com (Clem Cole) Date: Wed, 31 Jul 2019 13:58:40 -0400 Subject: [TUHS] Who's behind the UNIX filesystem permission implementation In-Reply-To: References: Message-ID: FWIW: Before TOPS, there was MIT's CTSS. The DEC Project, Programmer Number (a.k.a. PPN) idea seems to have been similar to the People and *Problem Number* idea of CTSS, which allowed for directories of your own files and as well as your group (shared problem number). As Rodrigo pointed out Multics also had a form of ACLs (UNIX used ACL's just very simplified ones). So I'm not sure where to pin this specific idea. I think it was a bit like a lot of CS ideas, different people were playing with different aspects of different ideas at the time, and brillance of Ken and Dennis was putting some of the *best ideas *of the day *together* and adding a few of their own into a simple implementation that was good enough to do real work. Clem On Wed, Jul 31, 2019 at 1:29 PM Arthur Krewat wrote: > On 7/31/2019 12:49 PM, Rodrigo G. López wrote: > > Multics had modes per file (https://multicians.org/fjcc4.html) but i > > don't know about the origins. the simpler approach of > > owner/group/other is a purely Unix creation and i would bet Ken > > Thompson is behind it all. > > TOPS-10 had a 3 octal digit file protection code: > > - - Logins are PPNs - [Project, > Programmer] - So if I was [76,5], another user with [76,10] was in the > same project. Much like UNIX groups. > > Owner Protection Codes > 7*, 6* - You can execute, read, or change the protection code of the file. > 5* - You have unlimited access to the file, except for renaming it. > 4* - You have unlimited access to the file. > 3 - You can execute, read, or change the protection code of the file. > 2 - You have unlimited access to the file, except for renaming it. > 1, 0 - You have unlimited access. > * The File Daemon is called on a protection failure on this file (my > memory is a little fuzzy on this, but I believe it allowed finer grained > protections). > > Protection Codes for Fields 2 and 3 > 7 - The user cannot access the file. > 6 - The user can only execute the file. > 5 - The user can execute or read the file. > 4 - The user can execute, read, or append to the file. > 3 - The user can execute, read, append to, or update the file. > 2 - The user can execute, read, append to, update, and write to the file. > 1 - The user can execute, read, append to, update, write to, and rename > the file. > 0 - Unlimited access, including changing the protection code of the file. > > The name TOPS-10 was first used in 1970, but the monitor itself dates > back to 1964. I'm not sure when these protection codes came into being, > though. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cbbrowne at gmail.com Thu Aug 1 04:03:33 2019 From: cbbrowne at gmail.com (Christopher Browne) Date: Wed, 31 Jul 2019 14:03:33 -0400 Subject: [TUHS] Who's behind the UNIX filesystem permission implementation In-Reply-To: References: Message-ID: On Wed, 31 Jul 2019 at 13:29, Arthur Krewat wrote: > On 7/31/2019 12:49 PM, Rodrigo G. López wrote: > > Multics had modes per file (https://multicians.org/fjcc4.html) but i > > don't know about the origins. the simpler approach of > > owner/group/other is a purely Unix creation and i would bet Ken > > Thompson is behind it all. > > TOPS-10 had a 3 octal digit file protection code: > > - - Logins are PPNs - [Project, > Programmer] - So if I was [76,5], another user with [76,10] was in the > same project. Much like UNIX groups. > > Owner Protection Codes > 7*, 6* - You can execute, read, or change the protection code of the file. > 5* - You have unlimited access to the file, except for renaming it. > 4* - You have unlimited access to the file. > 3 - You can execute, read, or change the protection code of the file. > 2 - You have unlimited access to the file, except for renaming it. > 1, 0 - You have unlimited access. > * The File Daemon is called on a protection failure on this file (my > memory is a little fuzzy on this, but I believe it allowed finer grained > protections). > > Protection Codes for Fields 2 and 3 > 7 - The user cannot access the file. > 6 - The user can only execute the file. > 5 - The user can execute or read the file. > 4 - The user can execute, read, or append to the file. > 3 - The user can execute, read, append to, or update the file. > 2 - The user can execute, read, append to, update, and write to the file. > 1 - The user can execute, read, append to, update, write to, and rename > the file. > 0 - Unlimited access, including changing the protection code of the file. > > The name TOPS-10 was first used in 1970, but the monitor itself dates > back to 1964. I'm not sure when these protection codes came into being, > though. > Interesting; similar, though not identical to some material I captured back in the 1990s on TOPS-10 FILDAE in a discussion about Linux filesystem permission semantics... It seemed interesting, so I added it to a web page: linuxfinances.info/info/fs.html The claim is that there would be a fildae control file like the following: # anything in a directory named "private" is off limits */private/*:*:*:*: # people in group "foo" get full (create, delete, read, write, # execute) access to everything in the foo project directory ~/projects/foo/*:*:foo:*:cdrwx # people playing mygame can update the high score file ~/mygame/score.dat:*:*: ~/mygame/bin/mygame:rw # some friends have access to the RCS files for mygame ~/mygame/src/RCS/*:dennis,kevin,josh:*: /usr/bin/ci:rw ~/mygame/src/RCS/*:dennis,kevin,josh:*: /usr/bin/co:rw # I'll put stuff I want everyone to read in my ~/public directory # I'll make the public directory 744, so no one will actually have # to check .access_list, but I'll still put in this entry for completeness ~/public/*:*:*:*:r# anything left over gets no access*:*:*:*: -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?" -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Thu Aug 1 04:46:02 2019 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 31 Jul 2019 12:46:02 -0600 Subject: [TUHS] Who's behind the UNIX filesystem permission implementation In-Reply-To: References: Message-ID: On 7/31/19 11:00 AM, Toby Thain wrote: > It may not address "all aspects" since it has been necessary for some > purposes to extend the permission model substantially over time, such > as ACLs, SELinux, etc. I thought that ACLs acted as additional gates / restriction points beyond what standard Unix file system permissions allowed. Meaning that ACLs couldn't /add/ permission, but they could /remove/ permission. I think SELinux behaves similarly. It blocks (removes) existing permissions. Beyond that, I think SELinux is filtering (removing) permissions when comparing what (who) is running combined with what is being run further combined with what it is being run against. So again, removing existing permissions. The only thing that I'm aware of that actually /adds/ permissions is the capability subsystem. It can give an unprivileged user the ability to run a binary that can bind to a port below 1024. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From clemc at ccc.com Thu Aug 1 05:01:30 2019 From: clemc at ccc.com (Clem Cole) Date: Wed, 31 Jul 2019 15:01:30 -0400 Subject: [TUHS] Who's behind the UNIX filesystem permission implementation In-Reply-To: References: Message-ID: On Wed, Jul 31, 2019 at 2:46 PM Grant Taylor via TUHS wrote: > I thought that ACLs acted as additional gates / restriction points > beyond what standard Unix file system permissions allowed. > It's really how strict you want to be in the definition of an ACL. UNIX uses the same basic/simple model but traditional UNIX style ACLs of 3 options of 3 modes are implemented are just more coarsely defined than say VMS or later NT or SELinux, uses for their file systems. It's arguable that the extra granularity of the others actually adds a great deal in actual day to day use cases. At one time, I will admit that I had thought VMS style ACLs might be more helpful to UNIX and we added them to one of our file systems, but when I look back on 40 years of using anything beyond UNIX style ACLs its been pretty rare when I actually needed much more (*i.e.* theory vs. practice). The problem is the programming interface tends to get more difficult when you add some of the extra features. To me the brilliance to UNIX has always been getting down to a very simple interface that was "good enough" to get the *job done* and not so full of *extra stuff *that it gets in the way (which tends to be a complaint by way with Linux -- which does have a lot of new/rich features, but so full of some many different features theses days you have to wonder is/was it worth it). To me, it's arguable that ACL's beyond R/W/E and U/G/E is really needed in practice. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at cogs.com Thu Aug 1 05:34:44 2019 From: ben at cogs.com (Ben Greenfield) Date: Wed, 31 Jul 2019 15:34:44 -0400 Subject: [TUHS] Who's behind the UNIX filesystem permission implementation In-Reply-To: References: Message-ID: <22C0158A-6731-4CA4-BC5A-3CDD3F76F4F9@cogs.com> In the Sun System Administration class you got to bring a system up from nothing which included mucking with inodes. I believe I was taught that Sun implemented ACLS by assigning to inodes to a file. The first inode was assigned the unix permissions and the second inode was assigned the acls permissions and there was some backend mechanism that kept both inodes referring to a single file. It was a week long class and I found it the best unix experience. I all machine and no users:) Ben > On Jul 31, 2019, at 2:46 PM, Grant Taylor via TUHS wrote: > > On 7/31/19 11:00 AM, Toby Thain wrote: >> It may not address "all aspects" since it has been necessary for some purposes to extend the permission model substantially over time, such as ACLs, SELinux, etc. > > I thought that ACLs acted as additional gates / restriction points beyond what standard Unix file system permissions allowed. Meaning that > ACLs couldn't /add/ permission, but they could /remove/ permission. > > I think SELinux behaves similarly. It blocks (removes) existing permissions. Beyond that, I think SELinux is filtering (removing) permissions when comparing what (who) is running combined with what is being run further combined with what it is being run against. So again, removing existing permissions. > > The only thing that I'm aware of that actually /adds/ permissions is the capability subsystem. It can give an unprivileged user the ability to run a binary that can bind to a port below 1024. > > > > -- > Grant. . . . > unix || die > From krewat at kilonet.net Thu Aug 1 06:16:25 2019 From: krewat at kilonet.net (Arthur Krewat) Date: Wed, 31 Jul 2019 16:16:25 -0400 Subject: [TUHS] Who's behind the UNIX filesystem permission implementation In-Reply-To: References: Message-ID: <6d2955e3-c77b-fbd0-6e9e-bcdf3a58d45e@kilonet.net> Sorry to reply to myself, but I wanted to add one note to this, and didn't, which pertains to the "rename" versus "update" part of file protections in TOPS-10, and perhaps was a bug that was never fixed, or it was, and I didn't know it. In TOPS-10, you use the monitor call ENTER to update (write to) an existing file. It uses a common argument list with LOOKUP and I think a few other calls, that include the file name and extension. If a file had a 4 protection code for you, you could LOOKUP the file, then ENTER it with a different filename, and the filename would change, effectively renaming the file which you would think required a 1 protection code. You could also, if I recall correctly, specify a different protection. The significance of this? Many installations put files in SYS: ([1,4]) that had a 4 protection code so they could be written to by various applications users ran, or it was an oversight by a system administrator. Using DDT, one could easily whip up a short piece of code to rename any file in SYS: that had a 4 protection code, rename it to a .SAV or .SHR (if it needed a highseg) and basically "hide" behind another program, such as LOGIN.EXE (When EXE was introduced, I think in version 6, TOPS-10 still supported .SAV, .SHR, and .HGH but would attempt to run the .EXE first if you didn't specify an extension). Certain programs in SYS: like LOGIN had JACCT privileges - full rights to everything, including device I/O. So, find a writable file in SYS:, rename it to LOGIN.SAV, copy PIP over it, or something you cobbled up yourself, and take over the system without causing any other issues except that missing writable file. JACCT priv was much like "setuid" in UNIX - except it was a hardcoded list of filenames in the monitor (I think mostly or exclusively in SYS:) that would get carte blanche access to everything. I believe by version 7, some programs had been deprecated out of SYS, but they still existed in the JACCT list in the monitor. And boy, there were a lot of systems out there on Telenet or the ARPANET that had files in SYS: protected with a 4. Side note: Telenet was BBN's attempt to create a private sector ARPANET. https://en.wikipedia.org/wiki/Telenet - A late night dumpster dive at Radio Shack in the very early 80's got me a local dialin number. Sorry for the lengthy dissertation :) On 7/31/2019 1:29 PM, Arthur Krewat wrote: > TOPS-10 had a 3 octal digit file protection code: > > - - Logins are PPNs - [Project, > Programmer] - So if I was [76,5], another user with [76,10] was in the > same project. Much like UNIX groups. > > Owner Protection Codes > 7*, 6* - You can execute, read, or change the protection code of the > file. > 5* - You have unlimited access to the file, except for renaming it. > 4* - You have unlimited access to the file. > 3 - You can execute, read, or change the protection code of the file. > 2 - You have unlimited access to the file, except for renaming it. > 1, 0 - You have unlimited access. > * The File Daemon is called on a protection failure on this file (my > memory is a little fuzzy on this, but I believe it allowed finer > grained protections). > > Protection Codes for Fields 2 and 3 > 7 - The user cannot access the file. > 6 - The user can only execute the file. > 5 - The user can execute or read the file. > 4 - The user can execute, read, or append to the file. > 3 - The user can execute, read, append to, or update the file. > 2 - The user can execute, read, append to, update, and write to the file. > 1 - The user can execute, read, append to, update, write to, and > rename the file. > 0 - Unlimited access, including changing the protection code of the file. > > The name TOPS-10 was first used in 1970, but the monitor itself dates > back to 1964. I'm not sure when these protection codes came into > being, though. > From wlc at jctaylor.com Thu Aug 1 08:24:11 2019 From: wlc at jctaylor.com (William Corcoran) Date: Wed, 31 Jul 2019 22:24:11 +0000 Subject: [TUHS] Who's behind the UNIX filesystem permission implementation In-Reply-To: References: , Message-ID: <91450743-C517-4F04-9E0A-DA3CDA2234D0@jctaylor.com> No filesystem permission discussion would be complete without mentioning United States Patent US 4135240. Set user ID! setuid setgid (Hmmmm, I believe there is an Et al. missing after the inventors name, Dennis Ritchie, on the face of this patent, right?) Bill Corcoran On Jul 31, 2019, at 1:18 PM, Warner Losh > wrote: On Wed, Jul 31, 2019, 12:09 PM Toby Thain > wrote: On 2019-07-31 5:59 a.m., Stephan Han. wrote: > Hello Unix enthusiasts. > > I'd like to know who or the group of people behind implementing this > filesystem permission system. > Since we are using this system for nearly 40 years and it addresses all > the aspects of the permission matter without any hustle. It may not address "all aspects" since it has been necessary for some purposes to extend the permission model substantially over time, such as ACLs, SELinux, etc. He did say they solved the problem without hassle. All those other things introduced hassle. :) There is also all the various capacity frameworks to self limit what you are allowed to do as any easy to administer exploits... Warner --Toby > I'm inspired to know who/how came up with this theory? > Also if it derived from somewhere else or If there's an origin story > about this, it would be worth to share. > > Cheers. > Stephan > > -- > No When -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggm at algebras.org Thu Aug 1 08:49:09 2019 From: ggm at algebras.org (George Michaelson) Date: Thu, 1 Aug 2019 08:49:09 +1000 Subject: [TUHS] Who's behind the UNIX filesystem permission implementation In-Reply-To: <91450743-C517-4F04-9E0A-DA3CDA2234D0@jctaylor.com> References: <91450743-C517-4F04-9E0A-DA3CDA2234D0@jctaylor.com> Message-ID: The "useful layer of indirection" story carries the seeds of its own problem, if you consider xattr on files. They always prove harder to deal with, lie in cat -v extended options, cannot be invoked without bigger wetware cache memory than I hold, which requires a retreat to the man page, and crop up at the worst possible times, such as when you are doing buildworld installworld sequences, they blow up, and you have xattr locked files with setuid bit littering the FS tree. chmod can't do them with octal bit settings or they lie in octal spaces I don't understand further up from 777 Necessary but evil. What I like about user/group/other is that the group memberships list is independent, but maps into the tested space in the flags for chmod. If I want to grant somebody permission in group sense, I make sure we share a group and I arrange for the group to be set. If I cannot make the dir be group the same, I use --x permissions on other to give them transitive rights down into the file. It would be possible to argue creat(e) was a distinct permission from write. I think I heard Dennis say he regretted some aspects of the model around "is write the same as create" at an AUUG once, (I mean more than just his joke about calling it creat() not create() -he actually said there were arguments both sides to breaking out more modes of behaviour on things, and modifying the contents of a created named entity is not the same as naming it) And Microslop and xattr and I think VMS do indeed go to the "I can make things as well as change things" place. So yes, write permissions on the directory are the "proper" place to say "you can make things" but then you're in an indirection: the dir block is not the file, the file name is in the dir block, oh dear, so maybe we mean we want Apples resource fork and the data fork, a model I could never understand? No please.. but.. then again.. Oh dear. Its just a projection into a UNIX FS to make this a file and a .attr file, thats not how Apple "Ideated" it, but still. All designs come with costs. I guess if you like apple pie, you can dream about peaches, but peaches aren't apples. On Thu, Aug 1, 2019 at 8:36 AM William Corcoran wrote: > > No filesystem permission discussion would be complete without mentioning United States Patent US 4135240. > > Set user ID! > setuid > setgid > > (Hmmmm, I believe there is an Et al. missing after the inventors name, Dennis Ritchie, on the face of this patent, right?) > > Bill Corcoran > > > > On Jul 31, 2019, at 1:18 PM, Warner Losh wrote: > > > > On Wed, Jul 31, 2019, 12:09 PM Toby Thain wrote: >> >> On 2019-07-31 5:59 a.m., Stephan Han. wrote: >> > Hello Unix enthusiasts. >> > >> > I'd like to know who or the group of people behind implementing this >> > filesystem permission system. >> > Since we are using this system for nearly 40 years and it addresses all >> > the aspects of the permission matter without any hustle. >> >> It may not address "all aspects" since it has been necessary for some >> purposes to extend the permission model substantially over time, such as >> ACLs, SELinux, etc. > > > He did say they solved the problem without hassle. All those other things introduced hassle. :) There is also all the various capacity frameworks to self limit what you are allowed to do as any easy to administer exploits... > > Warner > >> --Toby >> >> >> > I'm inspired to know who/how came up with this theory? >> > Also if it derived from somewhere else or If there's an origin story >> > about this, it would be worth to share. >> > >> > Cheers. >> > Stephan >> > >> > -- >> > No When >> From doug at cs.dartmouth.edu Thu Aug 1 22:35:25 2019 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Thu, 01 Aug 2019 08:35:25 -0400 Subject: [TUHS] Who's behind the UNIX filesystem permission Message-ID: <201908011235.x71CZP2B035023@tahoe.cs.Dartmouth.EDU> Read and write permission were common ideas--even part of the Atlas paging hardware that was described before 1960. The original concept of time-sharing was to give a virtual computer to each user. When it became clear that sharing was an equally important aspect, owner/other permissions arose. I believe that was the case with Multics. Owner/other permissions were in PDP-11 Unix from the start. Group permissions arose from the ferment of daily talk in the Unix lab. How might the usual protections be extended to collaborative projects? Ken and Dennis deserve credit for the final implementation. Yet clean as the idea of groups was, it has been used only sporadically (in my experience). Execute permission (much overloaded in Unix) also dates back to the dawn of paging. One Unix innovation, due to Dennis, was the suid bit--the only patented feature in the Research system. It was instantly adopted for maintaining the Moo (a game now sold under the name "Master Mind") league standings table. One trouble with full-blown ACLs as required by NSA's Orange Book, is obscurity. It is hard (possibly NP- complete) to analyze the actual security of an ACL configuration. A common failing of Unix administration was a proliferation of suid-root programs, e.g. mail(1). I recall one system that had a hundred such programs. Sudo provided a way station between suid and ACLs. Doug From jpl.jpl at gmail.com Fri Aug 2 02:22:35 2019 From: jpl.jpl at gmail.com (John P. Linderman) Date: Thu, 1 Aug 2019 12:22:35 -0400 Subject: [TUHS] Who's behind the UNIX filesystem permission In-Reply-To: <201908011235.x71CZP2B035023@tahoe.cs.Dartmouth.EDU> References: <201908011235.x71CZP2B035023@tahoe.cs.Dartmouth.EDU> Message-ID: *Yet clean as the idea of groups was, it has been used only sporadically (in my experience).* As I recall it, the original "basic groups" were essentially "us" and "them". "Us" was everyone in the "in crowd", "them" was everyone else. Since the basic groups were rather extensive, it was prudent to turn group write permission off in your default umask. But that made groups rather clunky. You were in only one group at a time, so you had to "chgrp" to a select group, and then remember to set your umask to allow group write permission so others in the group could modify files. This changed when you could be in multiple groups at the same time (a BSD invention?), and your primary group automatically changed to the group owning your current working directory (iff you belonged to that group). This made it unnecessary to do an explicit chgrp in most cases. Having group write permission off in your default umask was now a nuisance. We fixed that by giving everyone an unshared primary group id, typically the same as the uid. It then became safe to make group write permission on by default. This made groups much more useful. Anyone in a group (but only those members) could create a directory owned by that group, and group members working in that directory defaulted to creating files (and subdirectories) group-owned by and writable by all the members of the group. It just worked. On Thu, Aug 1, 2019 at 8:36 AM Doug McIlroy wrote: > Read and write permission were common ideas--even part of > the Atlas paging hardware that was described before 1960. > The original concept of time-sharing was to give a virtual > computer to each user. When it became clear that sharing > was an equally important aspect, owner/other permissions > arose. I believe that was the case with Multics. > > Owner/other permissions were in PDP-11 Unix from the start. > Group permissions arose from the ferment of daily talk in > the Unix lab. How might the usual protections be extended > to collaborative projects? Ken and Dennis deserve credit > for the final implementation. Yet clean as the idea of groups > was, it has been used only sporadically (in my experience). > > Execute permission (much overloaded in Unix) also dates > back to the dawn of paging. One Unix innovation, due to > Dennis, was the suid bit--the only patented feature in > the Research system. It was instantly adopted for > maintaining the Moo (a game now sold under the name > "Master Mind") league standings table. > > One trouble with full-blown ACLs as required by NSA's > Orange Book, is obscurity. It is hard (possibly NP- > complete) to analyze the actual security of an ACL > configuration. > > A common failing of Unix administration was a proliferation > of suid-root programs, e.g. mail(1). I recall one system > that had a hundred such programs. Sudo provided a way > station between suid and ACLs. > > Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From krewat at kilonet.net Fri Aug 2 02:35:29 2019 From: krewat at kilonet.net (Arthur Krewat) Date: Thu, 1 Aug 2019 12:35:29 -0400 Subject: [TUHS] Who's behind the UNIX filesystem permission In-Reply-To: References: <201908011235.x71CZP2B035023@tahoe.cs.Dartmouth.EDU> Message-ID: <6bdbf145-7bd3-971b-0ced-3ad1cae8b33d@kilonet.net> There's also the setgid bit on directories, that when files are created, they will be in the group that the parent directory has on it. Also, I don't think it's been mentioned, but there's the setuid bit on directories - otherwise known as the sticky bit. When set, even if you have rights to "write" the directory (meaning, delete files), you can't delete those owned by other users. Useful for /tmp I have no idea what the timeline is for either of these features :) On 8/1/2019 12:22 PM, John P. Linderman wrote: > > *Yet clean as the idea of groups was, it has been used only > sporadically (in my experience).* > > > As I recall it, the original "basic groups" were essentially "us" and > "them". "Us" was everyone in the "in crowd", "them" was everyone else. > Since the basic groups were rather extensive, it was prudent to turn > group write permission off in your default umask. But that made groups > rather clunky. You were in only one group at a time, so you had to > "chgrp" to a select group, and then remember to set your umask to > allow group write permission so others in the group could modify > files. This changed when you could be in multiple groups at the same > time (a BSD invention?), and your primary group automatically changed > to the group owning your current working directory (iff you belonged > to that group). This made it unnecessary to do an explicit chgrp in > most cases. Having group write permission off in your default umask > was now a nuisance. We fixed that by giving everyone an unshared > primary group id, typically the same as the uid. It then became safe > to make group write permission on by default. This made groups much > more useful. Anyone in a group (but only those members) could create a > directory owned by that group, and group members working in that > directory defaulted to creating files (and subdirectories) group-owned > by and writable by all the members of the group. It just worked. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cym224 at gmail.com Fri Aug 2 03:01:46 2019 From: cym224 at gmail.com (Nemo Nusquam) Date: Thu, 1 Aug 2019 13:01:46 -0400 Subject: [TUHS] Who's behind the UNIX filesystem permission In-Reply-To: <201908011235.x71CZP2B035023@tahoe.cs.Dartmouth.EDU> References: <201908011235.x71CZP2B035023@tahoe.cs.Dartmouth.EDU> Message-ID: On 08/01/19 08:35, Doug McIlroy wrote (in part): > Yet clean as the idea of groups > was, it has been used only sporadically (in my experience). Interesting... we used groups extensively (qa, staging, dev, research, release, ...) but never ACLs. N. From krewat at kilonet.net Fri Aug 2 04:26:37 2019 From: krewat at kilonet.net (Arthur Krewat) Date: Thu, 1 Aug 2019 14:26:37 -0400 Subject: [TUHS] Who's behind the UNIX filesystem permission In-Reply-To: References: <201908011235.x71CZP2B035023@tahoe.cs.Dartmouth.EDU> Message-ID: On 8/1/2019 1:01 PM, Nemo Nusquam wrote: > On 08/01/19 08:35, Doug McIlroy wrote (in part): >> Yet clean as the idea of groups >> was, it has been used only sporadically (in my experience). > Interesting... we used groups extensively (qa, staging, dev, research, > release, ...) but never ACLs. I've had occasion to use groups extensively in various places I've consulted. Defense Contractors, educational institutions, etc. That, and quotas. I've used Solaris ZFS ACLs, and Linux ACLs to solve many problems. There's always an exception to the UNIX rule when it comes to owner/group/world, and trying to corral users into that paradigm is not always fruitful. Although, in one case, a common storage area with both the setgid and setuid bit on the parent, and various Engineering departments writing files and directories to it, was a really cool solution to a problem although it used secondary groups as well. art k. From lyndon at orthanc.ca Fri Aug 2 06:14:07 2019 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Thu, 01 Aug 2019 13:14:07 -0700 Subject: [TUHS] Who's behind the UNIX filesystem permission In-Reply-To: References: <201908011235.x71CZP2B035023@tahoe.cs.Dartmouth.EDU> Message-ID: <40c91f7f89cb3ea5@orthanc.ca> Two things killed off the adoption of groups as a widely-deployed ACL mechanism: 1) NFS, specifically its limits on the number of supplimentary groups the protocol supported, 2) Kernel limits on the number of supplimentary groups associated with a process (e.g. NGROUPS_MAX) --lyndon From dave at horsfall.org Fri Aug 2 07:23:25 2019 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 2 Aug 2019 07:23:25 +1000 (EST) Subject: [TUHS] Who's behind the UNIX filesystem permission In-Reply-To: <201908011235.x71CZP2B035023@tahoe.cs.Dartmouth.EDU> References: <201908011235.x71CZP2B035023@tahoe.cs.Dartmouth.EDU> Message-ID: On Thu, 1 Aug 2019, Doug McIlroy wrote: > A common failing of Unix administration was a proliferation of suid-root > programs, e.g. mail(1). I recall one system that had a hundred such > programs. Sudo provided a way station between suid and ACLs. I've always maintained that if you think you need setuid root (which is a gaping chest wound), you can invariably get away with setgid instead. ObTrivia: Back in the 80s, some third-party software needed to be installed under "root". I was suspicious, but I had little choice but to allow it (manager's orders; that company went under shortly after I left them). Eventually I discovered why, when I had to clean up the mess: it actually *unlinked* directories; yes, you read that right... -- Dave From jnc at mercury.lcs.mit.edu Fri Aug 2 09:43:51 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 1 Aug 2019 19:43:51 -0400 (EDT) Subject: [TUHS] Who's behind the UNIX filesystem permission Message-ID: <20190801234351.04A9118C0A1@mercury.lcs.mit.edu> > From: Dave Horsfall > it actually *unlinked* directories Maybe the application was written by a LISP programmer? :-) (Not really, of course; it was probably just someone who didn't know much about Unix. They had a list of system calls, and 'unlink' probably said ' only works on directories when the caller is root', so...) Speaking of LISP and GC, it's impressive how GC is not really a big issue any more. At one point people were even building special CPUs that had hardware support for GC; now it seems to be a 'solved problem' on ordinary CPUs. Noel From davida at pobox.com Fri Aug 2 11:03:34 2019 From: davida at pobox.com (David Arnold) Date: Fri, 2 Aug 2019 11:03:34 +1000 Subject: [TUHS] Who's behind the UNIX filesystem permission In-Reply-To: <20190801234351.04A9118C0A1@mercury.lcs.mit.edu> References: <20190801234351.04A9118C0A1@mercury.lcs.mit.edu> Message-ID: On 2 Aug 2019, at 09:43, Noel Chiappa wrote: > Speaking of LISP and GC, it's impressive how GC is not really a big issue any > more. At one point people were even building special CPUs that had hardware > support for GC; now it seems to be a 'solved problem' on ordinary CPUs. I think it’s mostly a side effect of modern hardware speeds. For applications that care about latency (and especially latency jitter) it’s still an issue. For example, writing low latency trading software in Java requires some fairly silly hoop-jumping to avoid triggering a collection pass. These apps genuinely care about nanoseconds, but the tooling ecosystem and development time advantages of Java seem to entice a decent number of people to embark on the work-arounds. In most areas though you’re absolutely right — it’s a non-issue now. d From robpike at gmail.com Fri Aug 2 14:36:47 2019 From: robpike at gmail.com (Rob Pike) Date: Fri, 2 Aug 2019 14:36:47 +1000 Subject: [TUHS] Who's behind the UNIX filesystem permission In-Reply-To: References: <20190801234351.04A9118C0A1@mercury.lcs.mit.edu> Message-ID: In Go we "just" dedicate a core to GC, problem solved. The arrival of universal multi-CPU hardware made than option. Some tremendous technical work required (for which I take zero credit; see https://blog.golang.org/ismmkeynote) but yeah. -rob On Fri, Aug 2, 2019 at 11:11 AM David Arnold wrote: > On 2 Aug 2019, at 09:43, Noel Chiappa wrote: > > > Speaking of LISP and GC, it's impressive how GC is not really a big > issue any > > more. At one point people were even building special CPUs that had > hardware > > support for GC; now it seems to be a 'solved problem' on ordinary CPUs. > > I think it’s mostly a side effect of modern hardware speeds. For > applications that care about latency (and especially latency jitter) it’s > still an issue. > > For example, writing low latency trading software in Java requires some > fairly silly hoop-jumping to avoid triggering a collection pass. > > These apps genuinely care about nanoseconds, but the tooling ecosystem and > development time advantages of Java seem to entice a decent number of > people to embark on the work-arounds. > > In most areas though you’re absolutely right — it’s a non-issue now. > > > > d > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Fri Aug 2 18:35:30 2019 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 02 Aug 2019 02:35:30 -0600 Subject: [TUHS] Additional groups and additional directory permissions In-Reply-To: References: <201908011235.x71CZP2B035023@tahoe.cs.Dartmouth.EDU> Message-ID: <201908020835.x728ZUal026532@freefriends.org> [Subject line changed] Hi. Doug McIlroy: > Yet clean as the idea of groups was, it has been used only sporadically > (in my experience). I suspect this was true mainly at Research, where the whole place was not large. Other people, as pointed out, found groups to be very useful. "John P. Linderman" wrote: > This changed when you > could be in multiple groups at the same time (a BSD invention?), Yes, at 4.2 BSD. The so-called group set. > and your > primary group automatically changed to the group owning your current > working directory (iff you belonged to that group). No. Your process simply carried around a bunch of groups with it, and if the group of the directory matched the primary group or a member of the group set, you got group permission. Arthur Krewat : > There's also the setgid bit on directories, that when files are created, > they will be in the group that the parent directory has on it. IIRC this was a Sun invention. It was in SunOS 4.x, and may even have been in SunOS 3.x. > Also, I don't think it's been mentioned, but there's the setuid bit on > directories - otherwise known as the sticky bit. When set, even if you > have rights to "write" the directory (meaning, delete files), you can't > delete those owned by other users. Useful for /tmp Also a SunOS invention, IIRC. > I have no idea what the timeline is for either of these features :) Timeline is late 80s, SunOS 4.0, I believe. (Larry? :-) These ideas later propogated into SVR4 / Solaris, Linux and most (if not all) the other proprietary Unixes. HTH, Arnold From dot at dotat.at Fri Aug 2 21:18:30 2019 From: dot at dotat.at (Tony Finch) Date: Fri, 2 Aug 2019 12:18:30 +0100 Subject: [TUHS] Additional groups and additional directory permissions In-Reply-To: <201908020835.x728ZUal026532@freefriends.org> References: <201908011235.x71CZP2B035023@tahoe.cs.Dartmouth.EDU> <201908020835.x728ZUal026532@freefriends.org> Message-ID: arnold at skeeve.com wrote: > Arthur Krewat : > > There's also the setgid bit on directories, that when files are created, > > they will be in the group that the parent directory has on it. > > IIRC this was a Sun invention. It was in SunOS 4.x, and may even have > been in SunOS 3.x. When Bill Joy added the "multi-group stuff" to BSD all directories became implicitly set-gid: https://svnweb.freebsd.org/csrg/sys/ufs/ffs/ffs_inode.c?r1=4818&r2=5855 This is in SCCS revision 4.8 so I think it appeared in 4.2BSD As I understand it, when group support was improved in System V they did not change creat() to match BSD but instead used the directory set-gid bit to provide opt-in BSD semantics. I don't know if this was in Solaris or earlier? > > Also, I don't think it's been mentioned, but there's the setuid bit on > > directories - otherwise known as the sticky bit. When set, even if you > > have rights to "write" the directory (meaning, delete files), you can't > > delete those owned by other users. Useful for /tmp > > Also a SunOS invention, IIRC. BSD again :-) SCCS revision 6.6 so I think it appeared in 4.3BSD https://svnweb.freebsd.org/csrg/sys/ufs/ffs/ufs_lookup.c?r1=15809&r2=16046 Tony. -- f.anthony.n.finch http://dotat.at/ Mull of Galloway to Mull of Kintyre including the Firth of Clyde and North Channel: Variable 1 to 3, becoming easterly or southeasterly 2 to 4 later. Smooth, occasionally slight at first in North Channel. Showers for a time near shore. Good. From krewat at kilonet.net Fri Aug 2 22:45:51 2019 From: krewat at kilonet.net (Arthur Krewat) Date: Fri, 2 Aug 2019 08:45:51 -0400 Subject: [TUHS] Additional groups and additional directory permissions In-Reply-To: <201908020835.x728ZUal026532@freefriends.org> References: <201908011235.x71CZP2B035023@tahoe.cs.Dartmouth.EDU> <201908020835.x728ZUal026532@freefriends.org> Message-ID: <290b6d92-2e4a-248f-63b0-ab663f49ea65@kilonet.net> On 8/2/2019 4:35 AM, arnold at skeeve.com wrote: > [Subject line changed] > > Hi. > > Arthur Krewat : >> There's also the setgid bit on directories, that when files are created, >> they will be in the group that the parent directory has on it. > IIRC this was a Sun invention. It was in SunOS 4.x, and may even have > been in SunOS 3.x. > >> Also, I don't think it's been mentioned, but there's the setuid bit on >> directories - otherwise known as the sticky bit. When set, even if you >> have rights to "write" the directory (meaning, delete files), you can't >> delete those owned by other users. Useful for /tmp > Also a SunOS invention, IIRC. > >> I have no idea what the timeline is for either of these features :) > Timeline is late 80s, SunOS 4.0, I believe. (Larry? :-) > > These ideas later propogated into SVR4 / Solaris, Linux and most (if not all) > the other proprietary Unixes. > Makes a lot of sense. I just fired up my Consensys SVR4.2 VirtualBox guest, and sure enough, neither the sticky bit, nor setgid work on directories. My first commercial experience with UNIX as a consultant was SunOS. I had worked on Version 6 earlier, but that was purely personal and never more than messing around with a uVAX a friend had brought home from work. thanks for the info! art k. From clemc at ccc.com Fri Aug 2 23:06:57 2019 From: clemc at ccc.com (Clem Cole) Date: Fri, 2 Aug 2019 09:06:57 -0400 Subject: [TUHS] Additional groups and additional directory permissions In-Reply-To: <201908020835.x728ZUal026532@freefriends.org> References: <201908011235.x71CZP2B035023@tahoe.cs.Dartmouth.EDU> <201908020835.x728ZUal026532@freefriends.org> Message-ID: On Fri, Aug 2, 2019 at 4:36 AM wrote: > Arthur Krewat : > > Also, I don't think it's been mentioned, but there's the setuid bit on > > directories - otherwise known as the sticky bit. When set, even if you > > have rights to "write" the directory (meaning, delete files), you can't > > delete those owned by other users. Useful for /tmp > > Also a SunOS invention, IIRC. > Nope, much older. It was a BSDism -- Cory Hall 11/70 actually (V6 originally) - wnj probably, but it may have been somebody like Asa Romberger or Bob Kriddle who were the admins. VAXen distributions picked it up and Sun got it from there. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Fri Aug 2 23:28:18 2019 From: clemc at ccc.com (Clem Cole) Date: Fri, 2 Aug 2019 09:28:18 -0400 Subject: [TUHS] Additional groups and additional directory permissions In-Reply-To: <201908020835.x728ZUal026532@freefriends.org> References: <201908011235.x71CZP2B035023@tahoe.cs.Dartmouth.EDU> <201908020835.x728ZUal026532@freefriends.org> Message-ID: The best I can tell/remember is that groups went through 4 phases: 1.) No groups (earliest UNIX) [ I personally never used this except in the V0 retrocomputing] 2.) First group implementation (Thompson) [My first UNIX introduction was with this implementation] 3.) PWB 1.0 (Mashey version) [then saw this post PWB] 4.) BSD 4.2 (wnj version) [and lived this transistion] Each was a little different in semantics. As Doug mentioned, many sites (like Research) really did not need much and groups were really not used that widely. Thompson added something like the Project number of TOPS and some earlier systems. Truth is, it did not help much IMO. It was useful for grouping things like the binaries and keeping some more privileged programs from having to be setuid root. Mashey added features in PWB, primarily because of the RJE/Front end to the Mainframes and the need to have better protections/collections of certain items. But they still were much more like the DEC PPN, were you were running as a single group (i.e. the tuple UID/GID). This lasted a pretty long time, as it worked reasonably well for larger academic systems, where you had a user and were assigned a group, say for a course or class, you might be talking. If you looked at big 4.1 BSN Vaxen like at Purdue/Penn State, *etc.*, that how they were admin'd. But as Doug said, if you were still a small site, the use of groups was still pretty shallow. But, as part of the CSRG support for DARPA, there was a push from the community to have a list of groups that a user could be a part and you carried that list around in a more general manner. The big sites, in particular, were pushing for this because they were using groups as a major feature. wnj implemented same and it would go out widely in 4.2, although >>by memory<< that was in 4.1B or 4.1C first. It's possible Robert Elz may have brought that to Bill with his quota changes, but frankly I've forgotten. There was a lot of work being done to the FS at that point, much less Kirk's rewrite. But as UNIX went back to workstations, the need for a more general group system dropped away until the advent widely used distributed file systems like CMU's AFS and Sun's NFS. Then the concept of a user being in more than one group became much more de rigeur even on a small machine. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Sat Aug 3 00:35:31 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 2 Aug 2019 10:35:31 -0400 (EDT) Subject: [TUHS] Who's behind the UNIX filesystem permission Message-ID: <20190802143531.96D4218C096@mercury.lcs.mit.edu> > From: Arthur Krewat > there's the setuid bit on directories - otherwise known as the sticky > bit. Minor nit; in V6 at least (not sure about later), the 'sticky' bit was a separate bit from SUID and SGID. (When set on a pure/split object file, it told the OS to retain the text image on the swap device even when no active process was using it. Hence the name...) Noel From clemc at ccc.com Sat Aug 3 01:01:22 2019 From: clemc at ccc.com (Clem Cole) Date: Fri, 2 Aug 2019 11:01:22 -0400 Subject: [TUHS] Who's behind the UNIX filesystem permission In-Reply-To: <20190802143531.96D4218C096@mercury.lcs.mit.edu> References: <20190802143531.96D4218C096@mercury.lcs.mit.edu> Message-ID: On Fri, Aug 2, 2019 at 10:58 AM Noel Chiappa wrote: > Minor nit; in V6 at least (not sure about later), the 'sticky' bit was > a > separate bit from SUID and SGID. (When set on a pure/split object file, it > told the OS to retain the text image on the swap device even when no active > process was using it. Hence the name...) > Indeed, nice catch, Noel. -------------- next part -------------- An HTML attachment was scrubbed... URL: From krewat at kilonet.net Sat Aug 3 01:17:31 2019 From: krewat at kilonet.net (Arthur Krewat) Date: Fri, 2 Aug 2019 11:17:31 -0400 Subject: [TUHS] Who's behind the UNIX filesystem permission In-Reply-To: <20190802143531.96D4218C096@mercury.lcs.mit.edu> References: <20190802143531.96D4218C096@mercury.lcs.mit.edu> Message-ID: On 8/2/2019 10:35 AM, Noel Chiappa wrote: > > From: Arthur Krewat > > > there's the setuid bit on directories - otherwise known as the sticky > > bit. > > Minor nit; in V6 at least (not sure about later), the 'sticky' bit was a > separate bit from SUID and SGID. (When set on a pure/split object file, it > told the OS to retain the text image on the swap device even when no active > process was using it. Hence the name...) > Ah yes, I remember that now... sorry. Sticky bit is the low-order bit on the first octet which is usually left off and assumed to be zero. So to set it, it would be 1755. 4755 would be setuid. Woops. art k. From thomas.paulsen at firemail.de Sat Aug 3 05:00:12 2019 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Fri, 02 Aug 2019 21:00:12 +0200 Subject: [TUHS] Additional groups and additional directory permissions In-Reply-To: References: <201908011235.x71CZP2B035023@tahoe.cs.Dartmouth.EDU> <201908020835.x728ZUal026532@freefriends.org> Message-ID: <76a8b8144de199f3ef3234fae998566e@firemail.de> isn't Kirk McKusic a member of our group? Guess he can contribute a lot on this issue. --- Ursprüngliche Nachricht --- Von: Clem Cole Datum: 02.08.2019 15:28:18 An: Aharon Robbins , Doug McIlroy Betreff: Re: [TUHS] Additional groups and additional directory permissions > The best I can tell/remember is that groups went through 4 phases: > 1.) No groups (earliest UNIX) [ I personally never used this except in the > > V0 retrocomputing] > 2.) First group implementation (Thompson) [My first UNIX introduction was > > with this implementation] > 3.) PWB 1.0 (Mashey version) [then saw this post PWB] > 4.) BSD 4.2 (wnj version) [and lived this transistion] > > Each was a little different in semantics. > > As Doug mentioned, many sites (like Research) really did not need much and > > groups were really not used that widely. Thompson added something like > > the Project number of TOPS and some earlier systems. Truth is, it did not > > help much IMO. It was useful for grouping things like the binaries and > > keeping some more privileged programs from having to be setuid root. > > Mashey added features in PWB, primarily because of the RJE/Front end to the > > Mainframes and the need to have better protections/collections of certain > > items. But they still were much more like the DEC PPN, were you were > running as a single group (i.e. the tuple UID/GID). This lasted a pretty > > long time, as it worked reasonably well for larger academic systems, where > > you had a user and were assigned a group, say for a course or class, you > > might be talking. If you looked at big 4.1 BSN Vaxen like at Purdue/Penn > > State, *etc.*, that how they were admin'd. But as Doug said, if you were > > still a small site, the use of groups was still pretty shallow. > > But, as part of the CSRG support for DARPA, there was a push from the > community to have a list of groups that a user could be a part and you > carried that list around in a more general manner. The big sites, in > particular, were pushing for this because they were using groups as a major > > feature. wnj implemented same and it would go out widely in 4.2, although > > >>by memory<< that was in 4.1B or 4.1C first. It's possible > Robert Elz > may have brought that to Bill with his quota changes, but frankly I've > forgotten. There was a lot of work being done to the FS at that point, > > much less Kirk's rewrite. > > But as UNIX went back to workstations, the need for a more general group > > system dropped away until the advent widely used distributed file systems > > like CMU's AFS and Sun's NFS. Then the concept of a user being in more > than one group became much more de rigeur even on a small machine. > > Clem > From norman at oclsc.org Sat Aug 3 05:44:53 2019 From: norman at oclsc.org (Norman Wilson) Date: Fri, 02 Aug 2019 15:44:53 -0400 Subject: [TUHS] Additional groups and additional directory permissions Message-ID: <1564775096.13771.for-standards-violators@oclsc.org> Thomas Paulsen: isn't Kirk McKusic a member of our group? ==== Kirk is a member of many groups, all at the same time. Norman Wilson Toronto ON From wkt at tuhs.org Sat Aug 3 06:14:48 2019 From: wkt at tuhs.org (Warren Toomey) Date: Sat, 3 Aug 2019 06:14:48 +1000 Subject: [TUHS] Video of PDP-7 with Graphics-2? Message-ID: <20190802201448.GA5889@minnie.tuhs.org> Hi all, I'm chasing the Youtube video of the PDP-7 at Bell Labs where people are using it to draw circuit schematics. This seems to show the Graphics-2 module that, I believe, was built at the Labs. Can someone e-mail the URL? I've done some grepping but I haven't found it yet. Thanks, Warren From dave at horsfall.org Sat Aug 3 07:23:12 2019 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 3 Aug 2019 07:23:12 +1000 (EST) Subject: [TUHS] Who's behind the UNIX filesystem permission In-Reply-To: References: <20190802143531.96D4218C096@mercury.lcs.mit.edu> Message-ID: On Fri, 2 Aug 2019, Arthur Krewat wrote: > Sticky bit is the low-order bit on the first octet which is usually left > off and assumed to be zero. So to set it, it would be 1755. 4755 would > be setuid. That's why I use the symbolic modes on "chmod" instead of the octal ones :-) -- Dave From wkt at tuhs.org Sat Aug 3 09:03:48 2019 From: wkt at tuhs.org (Warren Toomey) Date: Sat, 3 Aug 2019 09:03:48 +1000 Subject: [TUHS] Video of PDP-7 with Graphics-2? In-Reply-To: References: <20190802201448.GA5889@minnie.tuhs.org> Message-ID: <20190802230348.GA22981@minnie.tuhs.org> On Fri, Aug 02, 2019 at 06:49:19PM -0400, Jim Carpenter wrote: > On 8/2/19 4:14 PM, Warren Toomey wrote: > > Hi all, I'm chasing the Youtube video of the PDP-7 at Bell Labs where > > people are using it to draw circuit schematics. > > A Bell Labs video? The only Bell Labs video I remember seeing that had > someone doing circuit schematics had it being done on a PDP-5. The -7 was > shown later doing music stuff. (That's the -7 that I thought maybe Unix > started life on.) Thanks Jim, Is it this one? https://www.youtube.com/watch?v=iwVu2BWLZqA They mention a Graphics-1 device, so maybe I'm getting this confused with the PDP-7 and the Graphics-2. Cheers, Warren From wkt at tuhs.org Sat Aug 3 10:33:36 2019 From: wkt at tuhs.org (Warren Toomey) Date: Sat, 3 Aug 2019 10:33:36 +1000 Subject: [TUHS] An Excellent Unix YouTube Video Message-ID: <20190803003336.GA32125@minnie.tuhs.org> https://www.youtube.com/watch?v=g3jOJfrOknA National Inventors Hall of Fame - NIHF Published on Feb 18, 2019 Bell Labs colleagues Ken Thompson and Dennis Ritchie developed UNIX, a multi-tasking, multi-user operating system alternative to the batch processing systems then dominating the computer industry. Not sure why I hadn't seen this before :) Cheers, Warren From cym224 at gmail.com Sat Aug 3 22:51:32 2019 From: cym224 at gmail.com (Nemo) Date: Sat, 3 Aug 2019 08:51:32 -0400 Subject: [TUHS] Who's behind the UNIX filesystem permission In-Reply-To: References: <20190802143531.96D4218C096@mercury.lcs.mit.edu> Message-ID: On 02/08/2019, Dave Horsfall wrote: > That's why I use the symbolic modes on "chmod" instead of the octal ones +1 > :-) > > -- Dave > From clemc at ccc.com Sun Aug 4 01:28:13 2019 From: clemc at ccc.com (Clem Cole) Date: Sat, 3 Aug 2019 11:28:13 -0400 Subject: [TUHS] An Excellent Unix YouTube Video In-Reply-To: <20190803003336.GA32125@minnie.tuhs.org> References: <20190803003336.GA32125@minnie.tuhs.org> Message-ID: Thanks, Warren - that was wonderful to watch. Clem On Fri, Aug 2, 2019 at 8:34 PM Warren Toomey wrote: > https://www.youtube.com/watch?v=g3jOJfrOknA > > National Inventors Hall of Fame - NIHF > Published on Feb 18, 2019 > Bell Labs colleagues Ken Thompson and Dennis Ritchie developed UNIX, > a multi-tasking, multi-user operating system alternative to the batch > processing systems then dominating the computer industry. > > Not sure why I hadn't seen this before :) > > Cheers, Warren > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at kdbarto.org Sun Aug 4 03:35:56 2019 From: david at kdbarto.org (David) Date: Sat, 3 Aug 2019 10:35:56 -0700 Subject: [TUHS] An Excellent Unix YouTube Video In-Reply-To: References: <20190803003336.GA32125@minnie.tuhs.org> Message-ID: <74D3057C-2F84-4551-B2B0-BBBC27833F20@kdbarto.org> Short and wonderful as a complement to 2 very good people. David > On Aug 3, 2019, at 8:28 AM, Clem Cole wrote: > > Thanks, Warren - that was wonderful to watch. Clem > > On Fri, Aug 2, 2019 at 8:34 PM Warren Toomey > wrote: > https://www.youtube.com/watch?v=g3jOJfrOknA > > National Inventors Hall of Fame - NIHF > Published on Feb 18, 2019 > Bell Labs colleagues Ken Thompson and Dennis Ritchie developed UNIX, > a multi-tasking, multi-user operating system alternative to the batch > processing systems then dominating the computer industry. > > Not sure why I hadn't seen this before :) > > Cheers, Warren -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sun Aug 4 03:49:17 2019 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 3 Aug 2019 10:49:17 -0700 Subject: [TUHS] An Excellent Unix YouTube Video In-Reply-To: <74D3057C-2F84-4551-B2B0-BBBC27833F20@kdbarto.org> References: <20190803003336.GA32125@minnie.tuhs.org> <74D3057C-2F84-4551-B2B0-BBBC27833F20@kdbarto.org> Message-ID: <20190803174917.GI27132@mcvoy.com> Couldn't agree more. And the description of Dennis was spot on and matches my own interactions with him. Hell of a nice guy and willing to help you if you demonstated cluefullness (and from what I've heard, even without cluefulness). Thanks Ken and Dennis, it's been one hell of a ride and it is still going! On Sat, Aug 03, 2019 at 10:35:56AM -0700, David wrote: > Short and wonderful as a complement to 2 very good people. > > David > > > On Aug 3, 2019, at 8:28 AM, Clem Cole wrote: > > > > Thanks, Warren - that was wonderful to watch. Clem > > > > On Fri, Aug 2, 2019 at 8:34 PM Warren Toomey > wrote: > > https://www.youtube.com/watch?v=g3jOJfrOknA > > > > National Inventors Hall of Fame - NIHF > > Published on Feb 18, 2019 > > Bell Labs colleagues Ken Thompson and Dennis Ritchie developed UNIX, > > a multi-tasking, multi-user operating system alternative to the batch > > processing systems then dominating the computer industry. > > > > Not sure why I hadn't seen this before :) > > > > Cheers, Warren > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From arnold at skeeve.com Sun Aug 4 16:40:47 2019 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 04 Aug 2019 00:40:47 -0600 Subject: [TUHS] Additional groups and additional directory permissions In-Reply-To: References: <201908011235.x71CZP2B035023@tahoe.cs.Dartmouth.EDU> <201908020835.x728ZUal026532@freefriends.org> Message-ID: <201908040640.x746elpl029042@freefriends.org> > arnold at skeeve.com wrote: > > Arthur Krewat : > > > There's also the setgid bit on directories, that when files are created, > > > they will be in the group that the parent directory has on it. > > > > IIRC this was a Sun invention. It was in SunOS 4.x, and may even have > > been in SunOS 3.x. Tony Finch wrote: > When Bill Joy added the "multi-group stuff" to BSD all directories became > implicitly set-gid: Yes. But the commercial world had backwards compatibility to worry about. Thus the setgid bit on directories. I'm no longer sure who first came up with it. > As I understand it, when group support was improved in System V they did > not change creat() to match BSD but instead used the directory set-gid bit > to provide opt-in BSD semantics. I don't know if this was in Solaris or > earlier? Correct, but not sure when it was first done. > > > Also, I don't think it's been mentioned, but there's the setuid bit on > > > directories - otherwise known as the sticky bit. When set, even if you > > > have rights to "write" the directory (meaning, delete files), you can't > > > delete those owned by other users. Useful for /tmp > > > > Also a SunOS invention, IIRC. > > BSD again :-) SCCS revision 6.6 so I think it appeared in 4.3BSD That sounds right. I stand corrected. Thanks, Arnold From dave at horsfall.org Sun Aug 4 17:36:44 2019 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 4 Aug 2019 17:36:44 +1000 (EST) Subject: [TUHS] Set-uid shell scripts Message-ID: Is it just me, or did someone actually implement set-uid scripts? I've proposed some silly things over the decades (my favourite is stty() working on things other than terminals, and guess what, we got ioctl() etc) but I have a vague recollection of this... The trouble is, I've worked with dozens of Unix-based vendors over the years (some good, some not so much) and so I've lost track of all the stupidity that I've seen. ObAnecdote: Just about every Unix vendor went belly-up shortly after I left them (under various circumstances), because the waste-of-space middle managers simply did not appreciate the importance of having a Unix guru on board if you're in the game of selling Unix boxen. I'd happily name them, but I think the principals are still alive :-) -- Dave From alec.muffett at gmail.com Sun Aug 4 17:43:24 2019 From: alec.muffett at gmail.com (Alec Muffett) Date: Sun, 4 Aug 2019 08:43:24 +0100 Subject: [TUHS] Set-uid shell scripts In-Reply-To: References: Message-ID: On Sun, 4 Aug 2019 at 08:37, Dave Horsfall wrote: > Is it just me, or did someone actually implement set-uid scripts? Yes, they were a thing for a while, until someone realised that you could do: ln -s /bin/scriptname ./-i "-i" # assuming that "." is already in your path ...and get a root shell. Source: I did this on (ISTR) 4.1 or 4.2BSD. -a -- http://dropsafe.crypticide.com/aboutalecm -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Sun Aug 4 17:46:17 2019 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 04 Aug 2019 01:46:17 -0600 Subject: [TUHS] Set-uid shell scripts In-Reply-To: References: Message-ID: <201908040746.x747kHsu004735@freefriends.org> Dave Horsfall wrote: > Is it just me, or did someone actually implement set-uid scripts? I think it worked in the early Unixen (V7, 4.1 time frame, more or less by accident) but after that the implications were recognized and only compiled binaries could be run setuid. > The trouble is, I've worked with dozens of Unix-based vendors over the > years (some good, some not so much) and so I've lost track of all the > stupidity that I've seen. It's not just Unix vendors. It's software (and hardware) companies in general. Arnold From jnc at mercury.lcs.mit.edu Mon Aug 5 01:58:54 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 4 Aug 2019 11:58:54 -0400 (EDT) Subject: [TUHS] Set-uid shell scripts Message-ID: <20190804155854.C22CA18C096@mercury.lcs.mit.edu> > From: Alec Muffett > until someone realised that you could do: > ln -s /bin/scriptname ./-i > "-i" # assuming that "." is already in your path > ...and get a root shell. I'm clearly not very awake this morning, because I don't understand how this works. Can you break it down a little? Thanks! Noel From michael at kjorling.se Mon Aug 5 02:30:00 2019 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Sun, 4 Aug 2019 16:30:00 +0000 Subject: [TUHS] Set-uid shell scripts In-Reply-To: <20190804155854.C22CA18C096@mercury.lcs.mit.edu> References: <20190804155854.C22CA18C096@mercury.lcs.mit.edu> Message-ID: <20190804163000.GB19836@h-178-80.A328.priv.bahnhof.se> On 4 Aug 2019 11:58 -0400, from jnc at mercury.lcs.mit.edu (Noel Chiappa): >> until someone realised that you could do: >> ln -s /bin/scriptname ./-i >> "-i" # assuming that "." is already in your path >> ...and get a root shell. > > I'm clearly not very awake this morning, because I don't understand how this > works. Can you break it down a little? Thanks! I'm guessing a little here, but could it be related to poor command line argument parsing in some shell, where "-i" forces the shell to start in interactive mode and the shell looks for parameters _anywhere_ in its argv[] (including argv[0]), not just at argv[1] and later? That would match the result described by Alec, and my modern dash's man page does give that meaning for "-i", but it also feels like a trivial bug to fix in the shell without prohibiting setuid scripts... -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “The most dangerous thought that you can have as a creative person is to think you know what you’re doing.” (Bret Victor) From alec.muffett at gmail.com Mon Aug 5 02:48:44 2019 From: alec.muffett at gmail.com (Alec Muffett) Date: Sun, 4 Aug 2019 17:48:44 +0100 Subject: [TUHS] Set-uid shell scripts In-Reply-To: <20190804163000.GB19836@h-178-80.A328.priv.bahnhof.se> References: <20190804155854.C22CA18C096@mercury.lcs.mit.edu> <20190804163000.GB19836@h-178-80.A328.priv.bahnhof.se> Message-ID: The cited filename is passed as argv[1] If the filename is "-i" then the command is "/bin/sh -i" This forces an interactive shell. Hence the important of not invoking it as "./-i" -a -------------- next part -------------- An HTML attachment was scrubbed... URL: From rp at servium.ch Mon Aug 5 02:50:32 2019 From: rp at servium.ch (Rico Pajarola) Date: Sun, 4 Aug 2019 09:50:32 -0700 Subject: [TUHS] Set-uid shell scripts In-Reply-To: <20190804155854.C22CA18C096@mercury.lcs.mit.edu> References: <20190804155854.C22CA18C096@mercury.lcs.mit.edu> Message-ID: when running a shell script, what's actually executed is the first line of the script (after #!) + the name of the script. If your script is named "-i", and in your path, just enter "-i", and /bin/sh -i is executed which gives you an interactive shell. There are probably half a dozen other ways to trick the shell into executing arbitrary code that is not contained in the script (more if the script actually does anything non-trivial, like e.g. an installer of some sort). So instead of trying to fix them all (and most likely missing a few), everybody just agreed that it was a terrible idea and removed the feature. On Sun, Aug 4, 2019 at 9:00 AM Noel Chiappa wrote: > > From: Alec Muffett > > > until someone realised that you could do: > > ln -s /bin/scriptname ./-i > > "-i" # assuming that "." is already in your path > > ...and get a root shell. > > I'm clearly not very awake this morning, because I don't understand how > this > works. Can you break it down a little? Thanks! > > Noel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at kjorling.se Mon Aug 5 03:48:09 2019 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Sun, 4 Aug 2019 17:48:09 +0000 Subject: [TUHS] Set-uid shell scripts In-Reply-To: References: <20190804155854.C22CA18C096@mercury.lcs.mit.edu> <20190804163000.GB19836@h-178-80.A328.priv.bahnhof.se> Message-ID: <20190804174809.GC19836@h-178-80.A328.priv.bahnhof.se> On 4 Aug 2019 17:48 +0100, from alec.muffett at gmail.com (Alec Muffett): > The cited filename is passed as argv[1] Well, that's even more obvious, and a little harder to "just fix" indeed. I stand corrected. -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “The most dangerous thought that you can have as a creative person is to think you know what you’re doing.” (Bret Victor) From alec.muffett at gmail.com Mon Aug 5 05:45:24 2019 From: alec.muffett at gmail.com (Alec Muffett) Date: Sun, 4 Aug 2019 20:45:24 +0100 Subject: [TUHS] Set-uid shell scripts In-Reply-To: <20190804174809.GC19836@h-178-80.A328.priv.bahnhof.se> References: <20190804155854.C22CA18C096@mercury.lcs.mit.edu> <20190804163000.GB19836@h-178-80.A328.priv.bahnhof.se> <20190804174809.GC19836@h-178-80.A328.priv.bahnhof.se> Message-ID: On Sun, 4 Aug 2019 at 18:57, Michael Kjörling wrote: > Well, that's even more obvious 32 years of security, and I can't say one has passed without someone saying "in retrospect, [the bug] was obvious" about *something* — so you're in good company. :-) -- http://dropsafe.crypticide.com/aboutalecm -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Mon Aug 5 06:18:37 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 4 Aug 2019 16:18:37 -0400 (EDT) Subject: [TUHS] Set-uid shell scripts Message-ID: <20190804201838.0246918C08C@mercury.lcs.mit.edu> > From: Alec Muffett >>> ln -s /bin/scriptname ./-i >>> "-i" # assuming that "." is already in your path 'scriptname' (above) would have to be a shell script which was SETUID root? That was part of what I was missing, along with the below. > The cited filename is passed as argv[1] I wonder why it passed the link name, instead of the actual filename of the target (script)? Perhaps to allow one script to have multiple functions, depending on the name it was called with? But that could have been done with hard links? (Adding a hard link must require write access, because the link count in the inode has to be updated? So it would be equally secure as not having an SUID program with write access.) Part of the problem is having the kernel involved in starting shell scripts; convenient in some ways, but V6 etc worked fine without that 'feature'. Noel From clemc at ccc.com Mon Aug 5 06:29:58 2019 From: clemc at ccc.com (Clem Cole) Date: Sun, 4 Aug 2019 16:29:58 -0400 Subject: [TUHS] Set-uid shell scripts In-Reply-To: <20190804201838.0246918C08C@mercury.lcs.mit.edu> References: <20190804201838.0246918C08C@mercury.lcs.mit.edu> Message-ID: On Sun, Aug 4, 2019 at 4:18 PM Noel Chiappa wrote: > Part of the problem is having the kernel involved in starting shell > scripts; convenient in some ways, but V6 etc worked fine without that > 'feature'. > That's a tough call. I have mixed opinions about it as a feature. I kind of like the user/kernel interface really, really thin and unadorned. Adding, it certainly made allowing multiple interpreters to be supported much easier; but as you say it opens a new can of worms. Given the later proliferation of what bwk or Jon Bently once referred too as 'little languages' (awk, perl, tcl, and sigh eventually python), it was probably a good feature. But as you said, v6 worked fairly well without it. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Mon Aug 5 06:42:34 2019 From: rich.salz at gmail.com (Richard Salz) Date: Sun, 4 Aug 2019 16:42:34 -0400 Subject: [TUHS] Set-uid shell scripts In-Reply-To: References: <20190804201838.0246918C08C@mercury.lcs.mit.edu> Message-ID: BSD added the #! "magic number" based on a suggestion from Ken I believe. Didn't the exec (2) manpage warn about argv[-1] being clobbered until that was added? On Sun, Aug 4, 2019, 4:31 PM Clem Cole wrote: > > > On Sun, Aug 4, 2019 at 4:18 PM Noel Chiappa > wrote: > >> Part of the problem is having the kernel involved in starting shell >> scripts; convenient in some ways, but V6 etc worked fine without that >> 'feature'. >> > That's a tough call. I have mixed opinions about it as a feature. I > kind of like the user/kernel interface really, really thin and unadorned. > > Adding, it certainly made allowing multiple interpreters to be supported > much easier; but as you say it opens a new can of worms. Given the later > proliferation of what bwk or Jon Bently once referred too as 'little > languages' (awk, perl, tcl, and sigh eventually python), it was probably a > good feature. > > But as you said, v6 worked fairly well without it. > > Clem > -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman at oclsc.org Mon Aug 5 07:18:45 2019 From: norman at oclsc.org (Norman Wilson) Date: Sun, 04 Aug 2019 17:18:45 -0400 Subject: [TUHS] Set-uid shell scripts Message-ID: <1564953528.6352.for-standards-violators@oclsc.org> Noel Chiappa: I wonder why it passed the link name, instead of the actual filename of the target (script)? Perhaps to allow one script to have multiple functions, depending on the name it was called with? ==== In fact the latter is still used here and there in standard system distributions. But from a security viewpoint it doesn't matter. For ln -s /bin/scriptname ./-i substitute execl("/bin/scriptname", "-i", (char *)0); If you can execute a program, you can fake its arguments, including argv[0]. There is no defence. Norman Wilson Toronto ON From norman at oclsc.org Mon Aug 5 07:27:33 2019 From: norman at oclsc.org (Norman Wilson) Date: Sun, 04 Aug 2019 17:27:33 -0400 Subject: [TUHS] Set-uid shell scripts Message-ID: <1564954057.6926.for-standards-violators@oclsc.org> Oops. Didn't think it through: the problem is argv[1], passed as the name of the script being executed, not argv[0]. Disregard my previous execl(...). A related problem is the inherent race condition: If you do ln -s /bin/setuidscript . ./setuidscript ./setuidscript is opened twice: once when the kernel reads it and finds #! as magic number and execs the interpreter, a second time when the interpreter opens ./setuidscript. If you meanwhile run something that swoops in in the background and replaces ./setuidscript with malicious instructions for the interpreter, you win. I remember managing to do this myself at one point in the latter part of the 1980s. That was when I fell out of love with setuid interpreter scripts. It looks like we didn't disable the danger in the Research kernel, though. I don't remember why not. Norman Wilson Toronto ON From dave at horsfall.org Mon Aug 5 09:58:49 2019 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 5 Aug 2019 09:58:49 +1000 (EST) Subject: [TUHS] Set-uid shell scripts In-Reply-To: <20190804201838.0246918C08C@mercury.lcs.mit.edu> References: <20190804201838.0246918C08C@mercury.lcs.mit.edu> Message-ID: On Sun, 4 Aug 2019, Noel Chiappa wrote: > 'scriptname' (above) would have to be a shell script which was SETUID root? > That was part of what I was missing, along with the below. Well, it's in the Subject: line :-) -- Dave From jnc at mercury.lcs.mit.edu Mon Aug 5 10:13:07 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 4 Aug 2019 20:13:07 -0400 (EDT) Subject: [TUHS] Set-uid shell scripts Message-ID: <20190805001307.73F6918C08C@mercury.lcs.mit.edu> > From: Dave Horsfall > Well, it's in the Subject: line :-) That was my _assumption_, but you know the old line about assumptions. Noel From emu at e-bbes.com Tue Aug 6 16:49:34 2019 From: emu at e-bbes.com (emanuel stiebler) Date: Tue, 6 Aug 2019 08:49:34 +0200 Subject: [TUHS] An Excellent Unix YouTube Video In-Reply-To: <20190803003336.GA32125@minnie.tuhs.org> References: <20190803003336.GA32125@minnie.tuhs.org> Message-ID: On 2019-08-03 02:33, Warren Toomey wrote:> https://www.youtube.com/watch?v=g3jOJfrOknA > > National Inventors Hall of Fame - NIHF > Published on Feb 18, 2019 > Bell Labs colleagues Ken Thompson and Dennis Ritchie developed UNIX, > a multi-tasking, multi-user operating system alternative to the batch > processing systems then dominating the computer industry. > > Not sure why I hadn't seen this before :) Specially, as there is even a paper shown in the video, by some "Warren Toomey" ;-) From jason-tuhs at shalott.net Tue Aug 6 18:28:43 2019 From: jason-tuhs at shalott.net (jason-tuhs at shalott.net) Date: Tue, 6 Aug 2019 01:28:43 -0700 (PDT) Subject: [TUHS] Set-uid shell scripts In-Reply-To: <1564954057.6926.for-standards-violators@oclsc.org> References: <1564954057.6926.for-standards-violators@oclsc.org> Message-ID: > A related problem is the inherent race condition: > If you do > ln -s /bin/setuidscript . > ./setuidscript > ./setuidscript is opened twice: once when the kernel > reads it and finds #! as magic number and execs the > interpreter, a second time when the interpreter opens > ./setuidscript. If you meanwhile run something that > swoops in in the background and replaces ./setuidscript > with malicious instructions for the interpreter, you > win. This was always described to me as the canonical reason why setuid interpreted scripts were a security hole, irrespective of any specifics in the shell or other interpreter. However, there's a workaround: use fdescfs. fdescfs allows the kernel to open the script, and then pass the fdescfs path for the (already open) descriptor to the interpreter as the command to run. According to https://www.in-ulm.de/~mascheck/various/shebang/#setuid, this is supported by many systems, including Solaris, several BSDs, and OSX (with a sysctl). -Jason From arnold at skeeve.com Tue Aug 6 19:55:45 2019 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 06 Aug 2019 03:55:45 -0600 Subject: [TUHS] Set-uid shell scripts In-Reply-To: References: <1564954057.6926.for-standards-violators@oclsc.org> Message-ID: <201908060955.x769tjAv005804@freefriends.org> jason-tuhs at shalott.net wrote: > > A related problem is the inherent race condition: > > If you do > > ln -s /bin/setuidscript . > > ./setuidscript > > ./setuidscript is opened twice: once when the kernel > > reads it and finds #! as magic number and execs the > > interpreter, a second time when the interpreter opens > > ./setuidscript. If you meanwhile run something that > > swoops in in the background and replaces ./setuidscript > > with malicious instructions for the interpreter, you > > win. > > This was always described to me as the canonical reason why setuid > interpreted scripts were a security hole, irrespective of any specifics > in the shell or other interpreter. > > However, there's a workaround: use fdescfs. fdescfs allows the kernel to > open the script, and then pass the fdescfs path for the (already open) > descriptor to the interpreter as the command to run. I'm guessing by this you files like /dev/fd/42. > According to https://www.in-ulm.de/~mascheck/various/shebang/#setuid, this > is supported by many systems, including Solaris, several BSDs, and OSX > (with a sysctl). There's a historical disconnect here. Setuid scripts were disabled in the mid- to late 80s. /dev/fd didn't hit the commercial Unix world until SVR4 in 1989, and didn't get into the other systems you mention until even later. So yes, that might have worked, but the solution came along too late. Arnold From dave at horsfall.org Wed Aug 7 08:48:59 2019 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 7 Aug 2019 08:48:59 +1000 (EST) Subject: [TUHS] Set-uid shell scripts In-Reply-To: References: <1564954057.6926.for-standards-violators@oclsc.org> Message-ID: On Tue, 6 Aug 2019, jason-tuhs at shalott.net wrote: [ Replacing a temporary set-uid file ] > This was always described to me as the canonical reason why setuid > interpreted scripts were a security hole, irrespective of any specifics > in the shell or other interpreter. It's a problem for any temporary files in a world-writable directory, hence the extensions to directory permissions e.g. /tmp and /var/tmp... Amusingly enough, the Mac works around this by symlinking /tmp to private/tmp i.e. you get your own /tmp... -- Dave From rminnich at gmail.com Wed Aug 7 08:56:17 2019 From: rminnich at gmail.com (ron minnich) Date: Tue, 6 Aug 2019 15:56:17 -0700 Subject: [TUHS] Set-uid shell scripts In-Reply-To: References: <1564954057.6926.for-standards-violators@oclsc.org> Message-ID: This brought to mind this old discussion: https://www.tuhs.org/Usenet/comp.unix.wizards/1988-November/023460.html On Tue, Aug 6, 2019 at 3:49 PM Dave Horsfall wrote: > > On Tue, 6 Aug 2019, jason-tuhs at shalott.net wrote: > > [ Replacing a temporary set-uid file ] > > > This was always described to me as the canonical reason why setuid > > interpreted scripts were a security hole, irrespective of any specifics > > in the shell or other interpreter. > > It's a problem for any temporary files in a world-writable directory, > hence the extensions to directory permissions e.g. /tmp and /var/tmp... > > Amusingly enough, the Mac works around this by symlinking /tmp to > private/tmp i.e. you get your own /tmp... > > -- Dave From gtaylor at tnetconsulting.net Wed Aug 7 09:46:58 2019 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Tue, 6 Aug 2019 17:46:58 -0600 Subject: [TUHS] Pre-init initialization Message-ID: <7236c9d4-40af-bc49-8aee-5c32d869d2eb@spamtrap.tnetconsulting.net> Do, or did, anything other than Linux use a concept of an initramfs / initrd to create a pre-(main)-init initialization environment to prepare the system to execute the (main)-init process? -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From dave at horsfall.org Wed Aug 7 11:21:17 2019 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 7 Aug 2019 11:21:17 +1000 (EST) Subject: [TUHS] Set-uid shell scripts In-Reply-To: References: <1564954057.6926.for-standards-violators@oclsc.org> Message-ID: Just to extend this thread a bit more, when did the set[ug]id bit start getting turned off if the file was overwritten? I've used so many *x systems over the years that I cannot remember, but I don't think even root was exempt i.e. part of any upgrade process was to put it back again. -- Dave From andreww591 at gmail.com Wed Aug 7 11:22:08 2019 From: andreww591 at gmail.com (Andrew Warkentin) Date: Tue, 6 Aug 2019 19:22:08 -0600 Subject: [TUHS] Pre-init initialization In-Reply-To: <7236c9d4-40af-bc49-8aee-5c32d869d2eb@spamtrap.tnetconsulting.net> References: <7236c9d4-40af-bc49-8aee-5c32d869d2eb@spamtrap.tnetconsulting.net> Message-ID: On 8/6/19, Grant Taylor via TUHS wrote: > Do, or did, anything other than Linux use a concept of an initramfs / > initrd to create a pre-(main)-init initialization environment to prepare > the system to execute the (main)-init process? > Off the top of my head I'm not aware of any other conventional Unix besides Linux that uses a memory filesystem for early userspace. Solaris does use a memory filesystem during boot, but it normally contains only kernel modules and is only read by the kernel module linker, and IIRC AIX uses a weird vaguely zImage-like format for its boot image but I can't remember if the image contains just the kernel and some modules or if there are userspace programs in it. As far as unconventional Unix-like OSes go, QNX Neutrino (but not QNX 2 and 4) and Plan 9 both use in-memory filesystems during early userspace boot, although both only load a single image from disk rather than a separate kernel and ramdisk. In QNX, the image is a page-oriented XIP filesystem that contains the kernel and early userspace as regular files, and in Plan 9 the image is the kernel executable, which contains a minimal embedded filesystem with a few user-mode programs. UX/RT, the OS that I'm writing, will also boot from a memory filesystem containing the kernel and early userspace in a similar manner to QNX (it's loosely based on QNX and Plan 9 but is not a clone of either), although currently it isn't running any real userspace programs. From dave at horsfall.org Wed Aug 7 12:35:49 2019 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 7 Aug 2019 12:35:49 +1000 (EST) Subject: [TUHS] Who's behind the UNIX filesystem permission In-Reply-To: <20190801234351.04A9118C0A1@mercury.lcs.mit.edu> References: <20190801234351.04A9118C0A1@mercury.lcs.mit.edu> Message-ID: On Thu, 1 Aug 2019, Noel Chiappa wrote: > Maybe the application was written by a LISP programmer? :-) > > (Not really, of course; it was probably just someone who didn't know much > about Unix. They had a list of system calls, and 'unlink' probably said ' only > works on directories when the caller is root', so...) I dimly recall that there was a little-documented utility /etc/unlink which did just that; it was probably not on all systems, but was on our CCI Power 6/32. I only discovered their incompetence at the next reboot, when I had to clean up all the orphaned (but temporary) files that were left behind because [idn]check went berserk (we didn't have fsck back then). -- Dave From benito.buchheim at student.hpi.de Wed Aug 7 17:51:34 2019 From: benito.buchheim at student.hpi.de (Benito Buchheim) Date: Wed, 7 Aug 2019 09:51:34 +0200 Subject: [TUHS] Running Research Unix v3 on simh Message-ID: <9e68c3f4-af37-a70f-2a1a-530dfcf0ae51@student.hpi.de> Hello everyone, My name is Benito Buchheim and I am a computer science student at Hasso-Plattner-Institute in Germany. During our Operating Systems Course we came across The Unix Heritage Society, more specifically Research Unix Version 3, and took a look into the source code of this version. The idea arose to try to get this running somehow as a sort of voluntary task. So I started digging my way through the available material and quickly found the "modified_nsys" version by Warren Toomey, which conveniently contained a very detailed readme file on how to compile and run this version on a Unix v5 emulator. Thus, I started cloning the simh Github Repository and built the pdp11 emulator. After downloading the v5root disk image and figuring out how to use simh to run it, I had a working Unix v5, but struggled a bit to copy more than one file onto it using the emulated devices. In the end, I used a very Hacky way and wrote a short python script which just runs the emulator and "copy pastes" the folder structure into the image. I now thought to be ready to start working my way through Toomey's readme. Unfortunately already the first command failed quite miserably. I changed my working directory and ran the first shell script to compile the kernel, but cc spat out loads of error messages which are not very detailed. As this is a very early version of c code I am kinda stuck at this point and running a bit out of ideas on what may have gone wrong. As there is this mailing list we thought to have a chat with the experts. Maybe there is somebody who could help or give a hint on how to get this running on the pdp11 emulator. I attached my shell script output and the v5 image containing the v3 source code in the /sys/nsys directory. It can be downloaded here: https://www.mission-eins.de/runningv3.zip Thanks a lot and best wishes from a small suburb near Berlin, Benito Buchheim From chet.ramey at case.edu Wed Aug 7 22:56:10 2019 From: chet.ramey at case.edu (Chet Ramey) Date: Wed, 7 Aug 2019 08:56:10 -0400 Subject: [TUHS] Set-uid shell scripts In-Reply-To: References: <1564954057.6926.for-standards-violators@oclsc.org> Message-ID: On 8/6/19 6:48 PM, Dave Horsfall wrote: > It's a problem for any temporary files in a world-writable directory, hence > the extensions to directory permissions e.g. /tmp and /var/tmp... > > Amusingly enough, the Mac works around this by symlinking /tmp to > private/tmp i.e. you get your own /tmp... /private/tmp is still word-writable with the sticky bit set. What you do get is a private $TMPDIR, e.g., /var/folders/41/pgctqv8s3_301dzlcghzcbs800008y/T/ -- ``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 clemc at ccc.com Wed Aug 7 23:04:36 2019 From: clemc at ccc.com (Clem Cole) Date: Wed, 7 Aug 2019 09:04:36 -0400 Subject: [TUHS] Pre-init initialization In-Reply-To: <7236c9d4-40af-bc49-8aee-5c32d869d2eb@spamtrap.tnetconsulting.net> References: <7236c9d4-40af-bc49-8aee-5c32d869d2eb@spamtrap.tnetconsulting.net> Message-ID: A couple of the commercial systems did this for sure. Linux definitely picked it up from UNIX practices, although I have no idea/memory of who did it first. We used the idea at Stellar (Stellix) and at Masscomp (RTU). IIRC, a couple of others like Pyramid made have created a RAMFS - but it was kicking around the UNIX community for a fairly long time - certainly in the late 1970s - *i.e.* post V7. FWIW: V7 had /stand which was a funky UNIX-like standalone system that some applications could be compiled. The problem was that it was a little different so you would end up seeing #ifdef STAND in code for things like fsck, fsdb, even cat. At Masscomp we ended up with three target environments for a couple of the system maintenance utilities: the OS, /stand and the boot ROMS. This was expensive/a PITA to maintain and keep straight, and in the case of the boot ROM, space was a huge problem. The RAMFS idea was created to get rid of at least /stand and IIRC we were able to drop a number of utilities out of the boot ROM. I'm not sure how far they took it. I left for Stellar and it was always the way Stellix booted. On Tue, Aug 6, 2019 at 7:47 PM Grant Taylor via TUHS wrote: > Do, or did, anything other than Linux use a concept of an initramfs / > initrd to create a pre-(main)-init initialization environment to prepare > the system to execute the (main)-init process? > > > > -- > Grant. . . . > unix || die > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Thu Aug 8 02:40:06 2019 From: imp at bsdimp.com (Warner Losh) Date: Wed, 7 Aug 2019 10:40:06 -0600 Subject: [TUHS] Pre-init initialization In-Reply-To: References: <7236c9d4-40af-bc49-8aee-5c32d869d2eb@spamtrap.tnetconsulting.net> Message-ID: The move into RAM disks happened as memories grew. This obviated the need to copy a filesystem to a new disk's swap space and then use that to really install the system. Kernels with bundled RAM disks were a thing in BSD for a long time, though I'm unsure when that functionality entered the code stream. I know the early versions of FreeBSD's installer ran out of a RAM disk loaded off floppies, though that's not the same as initrd since there never was a pivot to something else: just a reboot to boot the real thing. FreeBSD, at least, has the functionality to also do a RAM disk to get things configured enough to pivot to the real disk on boot, but that's a niche operation there: most everybody just boots off / directly without the initrd-like thing. It's rarely needed, but it's one of those things that when it is needed, it's really needed, which is why one can do it. FreeBSD has an interesting 'tertiary loader' that plays a similar role to initrd. It orchestrates loading of modules, setting tunable parameters and launching the kernel. It's grown up to be a mini-kernel stand-alone program, but as the real kernel is now 28MB, the boot loader leverages off 'boot services' or other well-known interfaces to weigh in at only a few hundred k. This has proven to be both a blessing and a curse at times, however. Warner On Wed, Aug 7, 2019 at 7:05 AM Clem Cole wrote: > A couple of the commercial systems did this for sure. Linux definitely > picked it up from UNIX practices, although I have no idea/memory of who did > it first. We used the idea at Stellar (Stellix) and at Masscomp (RTU). > IIRC, a couple of others like Pyramid made have created a RAMFS - but it > was kicking around the UNIX community for a fairly long time - certainly in > the late 1970s - *i.e.* post V7. > > FWIW: V7 had /stand which was a funky UNIX-like standalone system that > some applications could be compiled. The problem was that it was a little > different so you would end up seeing #ifdef STAND in code for things like > fsck, fsdb, even cat. At Masscomp we ended up with three target > environments for a couple of the system maintenance utilities: the OS, > /stand and the boot ROMS. This was expensive/a PITA to maintain and keep > straight, and in the case of the boot ROM, space was a huge problem. > > The RAMFS idea was created to get rid of at least /stand and IIRC we were > able to drop a number of utilities out of the boot ROM. I'm not sure how > far they took it. I left for Stellar and it was always the way Stellix > booted. > > > > On Tue, Aug 6, 2019 at 7:47 PM Grant Taylor via TUHS > wrote: > >> Do, or did, anything other than Linux use a concept of an initramfs / >> initrd to create a pre-(main)-init initialization environment to prepare >> the system to execute the (main)-init process? >> >> >> >> -- >> Grant. . . . >> unix || die >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Thu Aug 8 07:33:47 2019 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 8 Aug 2019 07:33:47 +1000 (EST) Subject: [TUHS] Set-uid shell scripts In-Reply-To: <40c92e85142fe7e3@orthanc.ca> References: <1564954057.6926.for-standards-violators@oclsc.org> <40c92e85142fe7e3@orthanc.ca> Message-ID: On Tue, 6 Aug 2019, Lyndon Nerenberg wrote: >> Just to extend this thread a bit more, when did the set[ug]id bit start >> getting turned off if the file was overwritten? > > I'm pretty sure that's been the case since the dawn of time. Hmmm... I have this vague memory of V5 (which I only used for a couple of months before we got V6) not clearing that bit, but after all these years my memory is starting to fail me :-( > It was certainly the case in every System V (release 0 and beyond) I > worked with, along with many BSDs derivatives (SunOS 3+, Ultrix, etc). > (And Xenix, which had it's own insanity that I now think selinux is > trying to inflict on me.) I've always thought that Xenix was insane to start with... Then again, my first experience with it was on a 286... Now, when porting Unify, should I use large memory model here or small memory model? Crazy. > This has been documented in chown(2) for as long as I can remember, so > that's a good place to start if you want to dig back through the various > source trees. I don't have access to the sources right now, but I'll take your word for it; it was just a passing thought. -- Dave From dave at horsfall.org Thu Aug 8 07:40:52 2019 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 8 Aug 2019 07:40:52 +1000 (EST) Subject: [TUHS] Set-uid shell scripts In-Reply-To: References: <1564954057.6926.for-standards-violators@oclsc.org> Message-ID: On Wed, 7 Aug 2019, Chet Ramey wrote: >> Amusingly enough, the Mac works around this by symlinking /tmp to >> private/tmp i.e. you get your own /tmp... > > /private/tmp is still word-writable with the sticky bit set. What you do > get is a private $TMPDIR, e.g., > > /var/folders/41/pgctqv8s3_301dzlcghzcbs800008y/T/ Aha! You have just unwittingly solved a mystery for me :-) I was wondering where those files were coming from... I'm not really a Mac freak; apart from the occasional port, I just use it to SSH into my FreeBSD server, with multiple Terminals all over the screen.. Thanks! -- Dave From athornton at gmail.com Thu Aug 8 15:16:51 2019 From: athornton at gmail.com (Adam Thornton) Date: Wed, 7 Aug 2019 22:16:51 -0700 Subject: [TUHS] Set-uid shell scripts In-Reply-To: References: <1564954057.6926.for-standards-violators@oclsc.org> Message-ID: > On Aug 7, 2019, at 2:40 PM, Dave Horsfall wrote: > > I'm not really a Mac freak; apart from the occasional port, I just use it to SSH into my FreeBSD server, with multiple Terminals all over the screen.. iTerm2 is really rather nice. Folks here may be interested in a new toy of mine: https://mvsevm.fsf.net Currently, the TOPS-10 guest account (42,42) and the Unix v7 account dmr have no passwords. Please treat the dmr account respectfully. I will get to account requests…eventually, probably. TImeliness is not guaranteed. All systems are hosted on Raspberry Pis (the 36-bit ones on a Pi 3B+ and the 16-bit and 32-bit ones on a Pi 2B+) on Debian Buster. Absolutely no guarantee of availability or usability is made. Adam From peter at rulingia.com Thu Aug 8 16:39:03 2019 From: peter at rulingia.com (Peter Jeremy) Date: Thu, 8 Aug 2019 16:39:03 +1000 Subject: [TUHS] Set-uid shell scripts In-Reply-To: References: <1564954057.6926.for-standards-violators@oclsc.org> <40c92e85142fe7e3@orthanc.ca> Message-ID: <20190808063903.GB84848@server.rulingia.com> On 2019-Aug-08 07:33:47 +1000, Dave Horsfall wrote: >I've always thought that Xenix was insane to start with... Then again, my >first experience with it was on a 286... Now, when porting Unify, should >I use large memory model here or small memory model? Crazy. Ah, yes. I remember it well. The large, small and various mixed modes were a consequence of the braindeadedness of the 286 - reloading segment registers (pretty much every memory reference in large mode) was abysmally slow. I recall hacking mg (a cut-down emacs clone) so that buffers were in "far" memory and everything else was "near". Some of the Xenix features I recall were: * occasionally fork() would return -1 in both the parent and child (or something like that - it would both succeed and report failure) * The contents of comments would affect the Pascal compiler's ability to compile the program (this was "using uninitialised variables" behaviour, rather than magic lint-style comments). It made software development "interesting" because checking a program into SCCS might stop it compiling. * fork()ing a large process could panic the system. * The C compiler barfed on parts of starchart (from comp.sources.???) -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From tytso at mit.edu Thu Aug 8 23:31:24 2019 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Thu, 8 Aug 2019 09:31:24 -0400 Subject: [TUHS] Pre-init initialization In-Reply-To: References: <7236c9d4-40af-bc49-8aee-5c32d869d2eb@spamtrap.tnetconsulting.net> Message-ID: <20190808133124.GA3340@mit.edu> On Wed, Aug 07, 2019 at 10:40:06AM -0600, Warner Losh wrote: > The move into RAM disks happened as memories grew. This obviated the need > to copy a filesystem to a new disk's swap space and then use that to really > install the system. > > Kernels with bundled RAM disks were a thing in BSD for a long time, though > I'm unsure when that functionality entered the code stream. I know the > early versions of FreeBSD's installer ran out of a RAM disk loaded off > floppies, though that's not the same as initrd since there never was a > pivot to something else: just a reboot to boot the real thing. I implemented loading the root file system as a ramdisk from a floppy in 1991 for Linux. This predates the publication of 386BSD, and I wasn't aware of how commercial Unix systems did their initial installation and setup. So as far as I know I came up on it on my own, but none of this was especially earthshaking or subtle. Linux's ramdisk was implemented because most PC's of the day (I was using a 40 MHz 386 with only a megabyte of memory) only had a single floppy drive (and if they had a second it was a 5.25" drive). So the very first implementation which I did assumed the kernel would be no larger than 512k, and looked for Minix file system signature at 512k. If it existed, it would load it into the ramdisk and use that as the boot region. Before that, the kernel was loaded from the first floppy, and then kernel would prompt the user to eject the boot disk and insert the root disk, and hit any key to continue, and then it would mount the root disk. But then the only floppy drive would be tied up with the root file system, so that meant there needed to be a second kernel on the root floppy, and everything else needed to set up the root image would have to be copied to the hard disk, and then you'd have to reboot to release the floppy drive so you could install other programs that couldn't fit on that initial 1.44MB root floppy. For people who are interested in the history of initrd used as part of the boot process in Linux, please refer to Werner Almesberger's 2000 paper, "Booting Linux: The History and the Future"[1], presented at the Ottawa Linux Symposium. [1] http://www.almesberger.net/cv/papers/ols2k-9.ps.gz Cheers, - Ted From clemc at ccc.com Thu Aug 8 23:43:15 2019 From: clemc at ccc.com (Clem Cole) Date: Thu, 8 Aug 2019 09:43:15 -0400 Subject: [TUHS] Pre-init initialization In-Reply-To: References: <7236c9d4-40af-bc49-8aee-5c32d869d2eb@spamtrap.tnetconsulting.net> Message-ID: On Wed, Aug 7, 2019 at 12:40 PM Warner Losh wrote: > This obviated the need to copy a filesystem to a new disk's swap space and > then use that to really install the system. > Thanks for the reminder. I don't remember if V7 on the PDP-11 used the swap space (but I don't think so). That said, I fairly sure that by BSD 4.1 the boot loader did, which I think is when that trick was first added to boot phase. Again, it was all about trying to get rid of the special /stand version of things. Funny, history would move on and we come back to that idea with busybox 🤔 -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Fri Aug 9 04:59:23 2019 From: imp at bsdimp.com (Warner Losh) Date: Thu, 8 Aug 2019 12:59:23 -0600 Subject: [TUHS] Pre-init initialization In-Reply-To: References: <7236c9d4-40af-bc49-8aee-5c32d869d2eb@spamtrap.tnetconsulting.net> Message-ID: On Thu, Aug 8, 2019 at 7:43 AM Clem Cole wrote: > > > On Wed, Aug 7, 2019 at 12:40 PM Warner Losh wrote: > >> This obviated the need to copy a filesystem to a new disk's swap space >> and then use that to really install the system. >> > > Thanks for the reminder. I don't remember if V7 on the PDP-11 used the > swap space (but I don't think so). That said, I fairly sure that by BSD 4.1 > the boot loader did, which I think is when that trick was first added to > boot phase. > Just checked the archives. V7 had a stand alone program to restore a filesystem image form the tape to the disk that you ran after running the stand alone program to partition and newfs the disk... I think you are right on your timeline. I installed a dozen Sun3 boxes from tape and hated mistyping the file number and having to start over... > Again, it was all about trying to get rid of the special /stand version of > things. Funny, history would move on and we come back to that idea with > busybox 🤔 > Well, busybox is special in many ways, so there's that in common with /stand, but it runs under a full otherwise standard kernel, not as some special mini-exec that provides just enough of the unix APIs to keep the standalone programs happy. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Fri Aug 9 11:46:22 2019 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Thu, 8 Aug 2019 19:46:22 -0600 Subject: [TUHS] Pre-init initialization In-Reply-To: References: <7236c9d4-40af-bc49-8aee-5c32d869d2eb@spamtrap.tnetconsulting.net> Message-ID: <94138535-c502-109d-752d-5ef7a6d53b23@spamtrap.tnetconsulting.net> On 8/7/19 7:04 AM, Clem Cole wrote: > FWIW: V7 had /stand which was a funky UNIX-like standalone system that > some applications could be compiled. I've seen /stand on a few systems (I think SCO OpenServer and / or UnixWare) but never really knew what it was for. I think I had naively assumed it was associated with the kernel and / or booting. Now I'm somewhat more curious what it was. Was it a simplified version of the OS with minimal utilities with fewer dependencies so that the system could boot and load more features. I thought that Linux's initramfs / initrd had the usual suspect files / utilities copied from /. So the idea that a utility in /stand would be different from the same utility in / seems strange to me. > The problem was that it was a little different so you would end up > seeing #ifdef STAND in code for things like fsck, fsdb, even cat. > At Masscomp we ended up with three target environments for a couple of > the system maintenance utilities: the OS, /stand and the boot ROMS. > This was expensive/a PITA to maintain and keep straight, and in the > case of the boot ROM, space was a huge problem. Ya. I can see how that would be a PITA to maintain. > The RAMFS idea was created to get rid of at least /stand and IIRC we > were able to drop a number of utilities out of the boot ROM.  I'm not > sure how far they took it.   I left for Stellar and it was always the > way Stellix booted. ACK -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From gtaylor at tnetconsulting.net Fri Aug 9 11:52:04 2019 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Thu, 8 Aug 2019 19:52:04 -0600 Subject: [TUHS] Pre-init initialization In-Reply-To: <20190808133124.GA3340@mit.edu> References: <7236c9d4-40af-bc49-8aee-5c32d869d2eb@spamtrap.tnetconsulting.net> <20190808133124.GA3340@mit.edu> Message-ID: On 8/8/19 7:31 AM, Theodore Y. Ts'o wrote: > I implemented loading the root file system as a ramdisk from a > floppy in 1991 for Linux. Impressive. > This predates the publication of 386BSD, and I wasn't aware of how > commercial Unix systems did their initial installation and setup. > So as far as I know I came up on it on my own, but none of this was > especially earthshaking or subtle. That logic makes sense to me. > Linux's ramdisk was implemented because most PC's of the day (I was > using a 40 MHz 386 with only a megabyte of memory) only had a single > floppy drive (and if they had a second it was a 5.25" drive). So the > very first implementation which I did assumed the kernel would be no > larger than 512k, and looked for Minix file system signature at 512k. > If it existed, it would load it into the ramdisk and use that as the > boot region. That's before my time. If I remember correctly, by the time I was creating boot+root disks it was the kernel plus something—I don't remember if it was an initramfs or an initrd—concatenated together. I also remember having to use a utility to update the kernel to tell it where the something started. Which was really based on how big the kernel was as padding before the something started. That was probably 2. on Slackware in '99. > Before that, the kernel was loaded from the first floppy, and then > kernel would prompt the user to eject the boot disk and insert the > root disk, and hit any key to continue, and then it would mount the > root disk. I remember doing that. But perhaps it was for a different reason. > But then the only floppy drive would be tied up with the root file > system, so that meant there needed to be a second kernel on the root > floppy, and everything else needed to set up the root image would > have to be copied to the hard disk, and then you'd have to reboot > to release the floppy drive so you could install other programs that > couldn't fit on that initial 1.44MB root floppy. > > For people who are interested in the history of initrd used as part > of the boot process in Linux, please refer to Werner Almesberger's > 2000 paper, "Booting Linux: The History and the Future"[1], presented > at the Ottawa Linux Symposium. > > [1] http://www.almesberger.net/cv/papers/ols2k-9.ps.gz I will definitely check that out. Thank you for the link. > Cheers, :-) -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From imp at bsdimp.com Fri Aug 9 12:15:34 2019 From: imp at bsdimp.com (Warner Losh) Date: Thu, 8 Aug 2019 20:15:34 -0600 Subject: [TUHS] Pre-init initialization In-Reply-To: <94138535-c502-109d-752d-5ef7a6d53b23@spamtrap.tnetconsulting.net> References: <7236c9d4-40af-bc49-8aee-5c32d869d2eb@spamtrap.tnetconsulting.net> <94138535-c502-109d-752d-5ef7a6d53b23@spamtrap.tnetconsulting.net> Message-ID: On Thu, Aug 8, 2019, 7:47 PM Grant Taylor via TUHS wrote: > On 8/7/19 7:04 AM, Clem Cole wrote: > > FWIW: V7 had /stand which was a funky UNIX-like standalone system that > > some applications could be compiled. > > I've seen /stand on a few systems (I think SCO OpenServer and / or > UnixWare) but never really knew what it was for. I think I had naively > assumed it was associated with the kernel and / or booting. > > Now I'm somewhat more curious what it was. Was it a simplified version > of the OS with minimal utilities with fewer dependencies so that the > system could boot and load more features. > Yes. There was a library that implemented much of the unix API in a simplified way that ran on bare metal. I thought that Linux's initramfs / initrd had the usual suspect files / > utilities copied from /. So the idea that a utility in /stand would be > different from the same utility in / seems strange to me. > They are because there was no kernel for them to run under. They were similar, but if you go look at the sources, they are different. > The problem was that it was a little different so you would end up > > seeing #ifdef STAND in code for things like fsck, fsdb, even cat. > > At Masscomp we ended up with three target environments for a couple of > > the system maintenance utilities: the OS, /stand and the boot ROMS. > > This was expensive/a PITA to maintain and keep straight, and in the > > case of the boot ROM, space was a huge problem. > > Ya. I can see how that would be a PITA to maintain. > FreeBSD, NetBSD and OpenBSD all implement some version of this. FreeBSD has it in src/stand in honor of V7 stand. I did that when I integrate / rewrote the GSoC project to bring Lua scripting to the boot loader. The other BSDs have it split between sys/boot and lib/libs. FreeBSD uses it to implement the rich boot loader which knows how to load off a lot of different file systems and BIOS interfaces. Net/OpenBSD use it more modestly in their boot loaders, but have a few standalone programs for things like bootstrapping VAXen. Warner > The RAMFS idea was created to get rid of at least /stand and IIRC we > > were able to drop a number of utilities out of the boot ROM. I'm not > > sure how far they took it. I left for Stellar and it was always the > > way Stellix booted. > > ACK > > > > -- > Grant. . . . > unix || die > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.bowling at kev009.com Fri Aug 9 16:43:09 2019 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Thu, 8 Aug 2019 23:43:09 -0700 Subject: [TUHS] Pre-init initialization In-Reply-To: References: <7236c9d4-40af-bc49-8aee-5c32d869d2eb@spamtrap.tnetconsulting.net> <94138535-c502-109d-752d-5ef7a6d53b23@spamtrap.tnetconsulting.net> Message-ID: On Thu, Aug 8, 2019 at 7:16 PM Warner Losh wrote: > > > On Thu, Aug 8, 2019, 7:47 PM Grant Taylor via TUHS > wrote: > >> On 8/7/19 7:04 AM, Clem Cole wrote: >> > FWIW: V7 had /stand which was a funky UNIX-like standalone system that >> > some applications could be compiled. >> >> I've seen /stand on a few systems (I think SCO OpenServer and / or >> UnixWare) but never really knew what it was for. I think I had naively >> assumed it was associated with the kernel and / or booting. >> >> Now I'm somewhat more curious what it was. Was it a simplified version >> of the OS with minimal utilities with fewer dependencies so that the >> system could boot and load more features. >> > > Yes. There was a library that implemented much of the unix API in a > simplified way that ran on bare metal. > > I thought that Linux's initramfs / initrd had the usual suspect files / >> utilities copied from /. So the idea that a utility in /stand would be >> different from the same utility in / seems strange to me. >> > > They are because there was no kernel for them to run under. They were > similar, but if you go look at the sources, they are different. > > > The problem was that it was a little different so you would end up >> > seeing #ifdef STAND in code for things like fsck, fsdb, even cat. >> > At Masscomp we ended up with three target environments for a couple of >> > the system maintenance utilities: the OS, /stand and the boot ROMS. >> > This was expensive/a PITA to maintain and keep straight, and in the >> > case of the boot ROM, space was a huge problem. >> >> Ya. I can see how that would be a PITA to maintain. >> > > FreeBSD, NetBSD and OpenBSD all implement some version of this. FreeBSD > has it in src/stand in honor of V7 stand. I did that when I integrate / > rewrote the GSoC project to bring Lua scripting to the boot loader. The > other BSDs have it split between sys/boot and lib/libs. FreeBSD uses it to > implement the rich boot loader which knows how to load off a lot of > different file systems and BIOS interfaces. Net/OpenBSD use it more > modestly in their boot loaders, but have a few standalone programs for > things like bootstrapping VAXen. > Yeah NetBSD has little gadgets in the ports stand directory for booting odd hardware. It would be preferable to have something like FreeBSD’s loader everywhere, but that would be hard to cover to the swath of ports NetBSD has, and would still require chain loading gadgets for many platforms. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sat Aug 10 01:10:01 2019 From: imp at bsdimp.com (Warner Losh) Date: Fri, 9 Aug 2019 09:10:01 -0600 Subject: [TUHS] MERT aka UNIX/RT Message-ID: Greetings, I was wondering if there were any early versions of MERT available? Reading different sources, it appears that MERT was a real time kernel that used EMT traps to implement unix system calls (from around V4 or V5 given the timelines) on top of a real time executive (though some sources seem to imply it was a derivative of V4, most disagree). I see this in our archives https://wiki.tuhs.org/doku.php?id=misc:snippets:mert1 which is quite handy for discover its (and other early) unix lineages for a talk I'm doing in about a month. Now that we have sources, I go back and double check the recollections of things like this to see if version numbers were right, etc. But I can't do that with MERT at all. I can find the Bell Systems Technical Journal for Unix that has a brief article on it, but no sources to double check. So I thought I'd ask here if we have any MERT artifacts I can look at that have escaped my casual browsing of the archive. So far I've just found an email from Kevin Bowling on the topic from last month with no replies. And a similar thread from 2002, plus pleading from time to time (I can't tell if Warren or Noel wants it more :). I guess the same could be said for CB-UNIX and UNIX/TS, though I see a USDL/CB_Unix directory in the archive I could look at :). Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Sat Aug 10 10:23:08 2019 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Fri, 9 Aug 2019 20:23:08 -0400 Subject: [TUHS] Pre-init initialization In-Reply-To: References: <7236c9d4-40af-bc49-8aee-5c32d869d2eb@spamtrap.tnetconsulting.net> <20190808133124.GA3340@mit.edu> Message-ID: <20190810002308.GB8368@mit.edu> On Thu, Aug 08, 2019 at 07:52:04PM -0600, Grant Taylor via TUHS wrote: > That's before my time. If I remember correctly, by the time I was creating > boot+root disks it was the kernel plus something—I don't remember if it was > an initramfs or an initrd—concatenated together. I also remember having to > use a utility to update the kernel to tell it where the something started. > Which was really based on how big the kernel was as padding before the > something started. That was probably 2. on Slackware in '99. In 1993 Fred van Kempen (who did the original Linux TCP stack before I got rewritten by Alan Cox's Net-2 stack) added a patch to the ramdisk code which so the root file system would be loaded from a second floppy into the ramdisk. That was because he wanted to fit more into stuff into the root file system, and by using a second floppy, the full 1.44MB could be used for the root file system in the ramdisk. As I recall the kernel was also getting bigger than 512k, too. In '95, Slackware started releasing on CD-ROM's, and while there may have been boot/root floppies, I suspect more and more they were used as rescue media, since installing from a CD-ROM was *way* more convenient. I'm guesing what you were doing was creating a kernel plus initramfs which was sufficient to mount a root file system elsewhere as an emergency "boot this failsafe kernel off the floppy", perhaps? I don't think a kernel+initramfs on a single 1.44MB floppy would have been sufficient for use as an install medium by '99. Or were you making an emergency USB thumb-drive as a rescue device, maybe? Cheers, - Ted From cmhanson at eschatologist.net Sat Aug 10 11:45:41 2019 From: cmhanson at eschatologist.net (Chris Hanson) Date: Fri, 9 Aug 2019 18:45:41 -0700 Subject: [TUHS] Pre-init initialization In-Reply-To: <7236c9d4-40af-bc49-8aee-5c32d869d2eb@spamtrap.tnetconsulting.net> References: <7236c9d4-40af-bc49-8aee-5c32d869d2eb@spamtrap.tnetconsulting.net> Message-ID: <88A08A53-33F2-4630-B39D-30316AD10D10@eschatologist.net> On Aug 6, 2019, at 4:46 PM, Grant Taylor via TUHS wrote: > > Do, or did, anything other than Linux use a concept of an initramfs / initrd to create a pre-(main)-init initialization environment to prepare the system to execute the (main)-init process? Mach-based UNIX systems (can) have a Mach init that’s separate from UNIX pid 1 init. When using a non-colocated UNIX subsystem (like the BSD Single Server) I think I recall that’s how the UNIX subsystem is started, along with other Mach tasks like the port name server. -- Chris From gtaylor at tnetconsulting.net Sat Aug 10 12:28:55 2019 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Fri, 9 Aug 2019 20:28:55 -0600 Subject: [TUHS] Pre-init initialization In-Reply-To: <20190810002308.GB8368@mit.edu> References: <7236c9d4-40af-bc49-8aee-5c32d869d2eb@spamtrap.tnetconsulting.net> <20190808133124.GA3340@mit.edu> <20190810002308.GB8368@mit.edu> Message-ID: On 8/9/19 6:23 PM, Theodore Y. Ts'o wrote: > In '95, Slackware started releasing on CD-ROM's, and while there may > have been boot/root floppies, I suspect more and more they were used as > rescue media, since installing from a CD-ROM was *way* more convenient. The boot & root floppies were how you booted Slackware for a long time. The CD-ROM was unbootable for quite a while. You booted off of floppy and the installation scripts would ask you which drive had the CD-ROM in it to mount and install from. > I'm guesing what you were doing was creating a kernel plus initramfs > which was sufficient to mount a root file system elsewhere as an > emergency "boot this failsafe kernel off the floppy", perhaps? > I don't think a kernel+initramfs on a single 1.44MB floppy would > have been sufficient for use as an install medium by '99. Or were > you making an emergency USB thumb-drive as a rescue device, maybe? It was a re-roll of the above boot & root disk set. It was not rescue media per-say. Though the standard boot & root disk set did get used for rescue purposes in addition to installation. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From mckusick at mckusick.com Sat Aug 10 14:02:51 2019 From: mckusick at mckusick.com (Kirk McKusick) Date: Fri, 09 Aug 2019 21:02:51 -0700 Subject: [TUHS] Additional groups and additional directory permissions Message-ID: <201908100402.x7A42p7C008714@chez.mckusick.com> > Date: Fri, 2 Aug 2019 09:28:18 -0400 > From: Clem Cole > To: Aharon Robbins , Doug McIlroy > Cc: The Eunuchs Hysterical Society > Subject: Re: [TUHS] Additional groups and additional directory permissions > > The best I can tell/remember is that groups went through 4 phases: > 1.) No groups (earliest UNIX) [ I personally never used this except in the > V0 retrocomputing] > 2.) First group implementation (Thompson) [My first UNIX introduction was > with this implementation] > 3.) PWB 1.0 (Mashey version) [then saw this post PWB] > 4.) BSD 4.2 (wnj version) [and lived this transistion] > > Each was a little different in semantics. > > As Doug mentioned, many sites (like Research) really did not need much and > groups were really not used that widely. Thompson added something like > the Project number of TOPS and some earlier systems. Truth is, it did not > help much IMO. It was useful for grouping things like the binaries and > keeping some more privileged programs from having to be setuid root. > > Mashey added features in PWB, primarily because of the RJE/Front end to the > Mainframes and the need to have better protections/collections of certain > items. But they still were much more like the DEC PPN, were you were > running as a single group (i.e. the tuple UID/GID). This lasted a pretty > long time, as it worked reasonably well for larger academic systems, where > you had a user and were assigned a group, say for a course or class, you > might be talking. If you looked at big 4.1 BSN Vaxen like at Purdue/Penn > State, *etc.*, that how they were admin'd. But as Doug said, if you were > still a small site, the use of groups was still pretty shallow. > > But, as part of the CSRG support for DARPA, there was a push from the > community to have a list of groups that a user could be a part and you > carried that list around in a more general manner. The big sites, in > particular, were pushing for this because they were using groups as a major > feature. wnj implemented same and it would go out widely in 4.2, although > >>by memory<< that was in 4.1B or 4.1C first. It's possible Robert Elz > may have brought that to Bill with his quota changes, but frankly I've > forgotten. There was a lot of work being done to the FS at that point, > much less Kirk's rewrite. > > But as UNIX went back to workstations, the need for a more general group > system dropped away until the advent widely used distributed file systems > like CMU's AFS and Sun's NFS. Then the concept of a user being in more > than one group became much more de rigeur even on a small machine. > > Clem Late to answer... As far as I remember, Clem's description is correct. The filesystem itself stores only one owner and one group ID. When checking access to the file, the file owner is checked to see if the user ID matches. If so, then the owner permissions are applied. If not then the group array associated with the user is used to decide if the group of the file matches one of the groups of which the user is a member and if so the group permissions apply. Otherwise the other permissions are used. In BSD, the group assigned to the file is assigned from the group of the directory in which it is created. The setgid flag can be set only if that group is a member of the user's group array. The user can only change the group ID to one that appears in their group array. Until multiple group sets were added to System V, the group of the file was taken from the gid assigned to the user at login. Kirk McKusick From kevin.bowling at kev009.com Sat Aug 10 14:21:30 2019 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Fri, 9 Aug 2019 21:21:30 -0700 Subject: [TUHS] Pre-init initialization In-Reply-To: References: <7236c9d4-40af-bc49-8aee-5c32d869d2eb@spamtrap.tnetconsulting.net> <20190808133124.GA3340@mit.edu> <20190810002308.GB8368@mit.edu> Message-ID: Yup I remember doing a boot/root floppies with Slackware as late as the early 2000s on an IBM PS/2 Model 95. On Fri, Aug 9, 2019 at 7:29 PM Grant Taylor via TUHS wrote: > On 8/9/19 6:23 PM, Theodore Y. Ts'o wrote: > > In '95, Slackware started releasing on CD-ROM's, and while there may > > have been boot/root floppies, I suspect more and more they were used as > > rescue media, since installing from a CD-ROM was *way* more convenient. > > The boot & root floppies were how you booted Slackware for a long time. > The CD-ROM was unbootable for quite a while. You booted off of floppy > and the installation scripts would ask you which drive had the CD-ROM in > it to mount and install from. > > > I'm guesing what you were doing was creating a kernel plus initramfs > > which was sufficient to mount a root file system elsewhere as an > > emergency "boot this failsafe kernel off the floppy", perhaps? > > I don't think a kernel+initramfs on a single 1.44MB floppy would > > have been sufficient for use as an install medium by '99. Or were > > you making an emergency USB thumb-drive as a rescue device, maybe? > > It was a re-roll of the above boot & root disk set. It was not rescue > media per-say. Though the standard boot & root disk set did get used > for rescue purposes in addition to installation. > > > > -- > Grant. . . . > unix || die > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Sat Aug 10 14:50:32 2019 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Fri, 9 Aug 2019 22:50:32 -0600 Subject: [TUHS] Pre-init initialization In-Reply-To: References: <7236c9d4-40af-bc49-8aee-5c32d869d2eb@spamtrap.tnetconsulting.net> <20190808133124.GA3340@mit.edu> <20190810002308.GB8368@mit.edu> Message-ID: On 8/9/19 10:21 PM, Kevin Bowling wrote: > Yup I remember doing a boot/root floppies with Slackware as late as the > early 2000s on an IBM PS/2 Model 95. That timing seems correct. I didn't think the IBM PS/2 Model 95, or any PS/2 for that matter, supported booting from CD-ROM. At least stock firmware. (I have no idea if a 3rd party / hacked firmware exists.) -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From athornton at gmail.com Sat Aug 10 14:52:47 2019 From: athornton at gmail.com (Adam Thornton) Date: Fri, 9 Aug 2019 21:52:47 -0700 Subject: [TUHS] Pre-init initialization In-Reply-To: References: <7236c9d4-40af-bc49-8aee-5c32d869d2eb@spamtrap.tnetconsulting.net> <20190808133124.GA3340@mit.edu> <20190810002308.GB8368@mit.edu> Message-ID: MCA support came pretty late, so that's not terribly surprising. As did booting-from CD-ROM, for that matter. I think I remember a fairly long period where the CD-ROM hung off the SoundBlaster, not the IDE bus. Adam On Fri, Aug 9, 2019 at 9:22 PM Kevin Bowling wrote: > Yup I remember doing a boot/root floppies with Slackware as late as the > early 2000s on an IBM PS/2 Model 95. > > On Fri, Aug 9, 2019 at 7:29 PM Grant Taylor via TUHS > wrote: > >> On 8/9/19 6:23 PM, Theodore Y. Ts'o wrote: >> > In '95, Slackware started releasing on CD-ROM's, and while there may >> > have been boot/root floppies, I suspect more and more they were used as >> > rescue media, since installing from a CD-ROM was *way* more convenient. >> >> The boot & root floppies were how you booted Slackware for a long time. >> The CD-ROM was unbootable for quite a while. You booted off of floppy >> and the installation scripts would ask you which drive had the CD-ROM in >> it to mount and install from. >> >> > I'm guesing what you were doing was creating a kernel plus initramfs >> > which was sufficient to mount a root file system elsewhere as an >> > emergency "boot this failsafe kernel off the floppy", perhaps? >> > I don't think a kernel+initramfs on a single 1.44MB floppy would >> > have been sufficient for use as an install medium by '99. Or were >> > you making an emergency USB thumb-drive as a rescue device, maybe? >> >> It was a re-roll of the above boot & root disk set. It was not rescue >> media per-say. Though the standard boot & root disk set did get used >> for rescue purposes in addition to installation. >> >> >> >> -- >> Grant. . . . >> unix || die >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.paulsen at firemail.de Sat Aug 10 16:02:03 2019 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Sat, 10 Aug 2019 08:02:03 +0200 Subject: [TUHS] Additional groups and additional directory permissions In-Reply-To: <201908100402.x7A42p7C008714@chez.mckusick.com> References: <201908100402.x7A42p7C008714@chez.mckusick.com> Message-ID: <51fd4ffbdeb80edffe8f837f04edf1aa@firemail.de> thanks a lot! --- Ursprüngliche Nachricht --- Von: Kirk McKusick Datum: 10.08.2019 06:02:51 An: Clem Cole Betreff: Re: [TUHS] Additional groups and additional directory permissions > > Late to answer... > > As far as I remember, Clem's description is correct. The filesystem > itself stores only one owner and one group ID. When checking access > to the file, the file owner is checked to see if the user ID matches. > If so, then the owner permissions are applied. If not then the group > array associated with the user is used to decide if the group of the > file matches one of the groups of which the user is a member and if > so the group permissions apply. Otherwise the other permissions are > used. > > In BSD, the group assigned to the file is assigned from the group of > the directory in which it is created. The setgid flag can be set only > if that group is a member of the user's group array. The user can only > change the group ID to one that appears in their group array. > > Until multiple group sets were added to System V, the group of the > file was taken from the gid assigned to the user at login. > > Kirk McKusick > From efton.collins at gmail.com Wed Aug 14 15:41:50 2019 From: efton.collins at gmail.com (Efton Collins) Date: Wed, 14 Aug 2019 00:41:50 -0500 Subject: [TUHS] Set-uid shell scripts In-Reply-To: References: <1564954057.6926.for-standards-violators@oclsc.org> Message-ID: On 8/8/19, Adam Thornton wrote: > > >> On Aug 7, 2019, at 2:40 PM, Dave Horsfall wrote: >> >> I'm not really a Mac freak; apart from the occasional port, I just use it >> to SSH into my FreeBSD server, with multiple Terminals all over the >> screen.. > > > iTerm2 is really rather nice. > > Folks here may be interested in a new toy of mine: > > https://mvsevm.fsf.net I like this. CTSS would make a good addition to the collection. I've always loved the CTSS - Multics - Unix progression, with Multics having so much ambition, and Unix coming out of that with simplicity and taste and no expectations. > > Currently, the TOPS-10 guest account (42,42) and the Unix v7 account dmr > have no passwords. > > Please treat the dmr account respectfully. > > I will get to account requests…eventually, probably. TImeliness is not > guaranteed. All systems are hosted on Raspberry Pis (the 36-bit ones on a > Pi 3B+ and the 16-bit and 32-bit ones on a Pi 2B+) on Debian Buster. > Absolutely no guarantee of availability or usability is made. > > Adam > > > From imp at bsdimp.com Fri Aug 16 08:08:43 2019 From: imp at bsdimp.com (Warner Losh) Date: Thu, 15 Aug 2019 16:08:43 -0600 Subject: [TUHS] Video of PDP-7 with Graphics-2? In-Reply-To: <20190802230348.GA22981@minnie.tuhs.org> References: <20190802201448.GA5889@minnie.tuhs.org> <20190802230348.GA22981@minnie.tuhs.org> Message-ID: On Fri, Aug 2, 2019 at 5:04 PM Warren Toomey wrote: > On Fri, Aug 02, 2019 at 06:49:19PM -0400, Jim Carpenter wrote: > > On 8/2/19 4:14 PM, Warren Toomey wrote: > > > Hi all, I'm chasing the Youtube video of the PDP-7 at Bell Labs where > > > people are using it to draw circuit schematics. > > > > A Bell Labs video? The only Bell Labs video I remember seeing that had > > someone doing circuit schematics had it being done on a PDP-5. The -7 was > > shown later doing music stuff. (That's the -7 that I thought maybe Unix > > started life on.) > > Thanks Jim, Is it this one? > https://www.youtube.com/watch?v=iwVu2BWLZqA > > They mention a Graphics-1 device, so maybe I'm getting this confused > with the PDP-7 and the Graphics-2. > The early one for the circuit simulator is definitely on a PDP-5 and I presume the Graphics-1 display. You can see the PDP 5 letters on one of the cabinets. How do you know that the music was composed on the PDP-7 that appears from 9:20-10:30? Cool paper tape feeding sequence, though, you gotta admit :) (well, unless you waited for far too many of those to run back in the day). Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Fri Aug 16 08:46:21 2019 From: imp at bsdimp.com (Warner Losh) Date: Thu, 15 Aug 2019 16:46:21 -0600 Subject: [TUHS] Video of PDP-7 with Graphics-2? In-Reply-To: References: <20190802201448.GA5889@minnie.tuhs.org> <20190802230348.GA22981@minnie.tuhs.org> Message-ID: On Thu, Aug 15, 2019 at 4:08 PM Warner Losh wrote: > > > On Fri, Aug 2, 2019 at 5:04 PM Warren Toomey wrote: > >> On Fri, Aug 02, 2019 at 06:49:19PM -0400, Jim Carpenter wrote: >> > On 8/2/19 4:14 PM, Warren Toomey wrote: >> > > Hi all, I'm chasing the Youtube video of the PDP-7 at Bell Labs where >> > > people are using it to draw circuit schematics. >> > >> > A Bell Labs video? The only Bell Labs video I remember seeing that had >> > someone doing circuit schematics had it being done on a PDP-5. The -7 >> was >> > shown later doing music stuff. (That's the -7 that I thought maybe Unix >> > started life on.) >> >> Thanks Jim, Is it this one? >> https://www.youtube.com/watch?v=iwVu2BWLZqA >> >> They mention a Graphics-1 device, so maybe I'm getting this confused >> with the PDP-7 and the Graphics-2. >> > > The early one for the circuit simulator is definitely on a PDP-5 and I > presume the Graphics-1 display. You can see the PDP 5 letters on one of the > cabinets. How do you know that the music was composed on the PDP-7 that > appears from 9:20-10:30? Cool paper tape feeding sequence, though, you > gotta admit :) (well, unless you waited for far too many of those to run > back in the day). > Oh! I've found the right set of photos to make a good case this is a PDP-7... https://docs.google.com/presentation/d/1lNmjaJhuqKSbpDU96sc3Kia3d-Ag0DVylMzW6APdWEY/edit?usp=sharing has an early version of a slide I'll be using in my talk next month. Comments? Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Wed Aug 21 07:10:55 2019 From: athornton at gmail.com (Adam Thornton) Date: Tue, 20 Aug 2019 14:10:55 -0700 Subject: [TUHS] Shell builtin exec Message-ID: This is probably the place to ask: I understand why the shell builtin "exec" is the same as the syscall exec() in the sense of "replace this process with that one." But why is it also the way to redirect filehandles in the current shell? (That is, why isn't the redirection named something else?) Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Wed Aug 21 08:00:33 2019 From: wkt at tuhs.org (Warren Toomey) Date: Wed, 21 Aug 2019 08:00:33 +1000 Subject: [TUHS] Shell builtin exec In-Reply-To: References: Message-ID: <20190820220033.GA18256@minnie.tuhs.org> On Tue, Aug 20, 2019 at 02:10:55PM -0700, Adam Thornton wrote: > This is probably the place to ask: > I understand why the shell builtin "exec" is the same as the syscall > exec() in the sense of "replace this process with that one." But why > is it also the way to redirect filehandles in the current shell? (That > is, why isn't the redirection named something else?) exec() doesn't do anything with file handles; it simply replaces the executable code in the current process. Here's the pseudo-code for a shell where redirection is done. int pid; /* Holds the process-id of the child */ switch (pid = fork()) /* Call fork, and test what it returns */ { case -1: printf("The fork failed\n"); return (-1); case 0: /* The child is given a value of 0 from fork() */ /* Do special things like closing files etc. */ if (redirection required) { close my standard output; open the named output file as my standard output; } /* Replace ourselves with the real child */ /* Call execvp */ execlp(command, arg1, arg2, ..., NULL); exit(1); /* Exec failed, indicate error */ default: /* The parent receives the new process-id from fork() */ wait(); /* Wait for child to exit */ } So the child shell itself does the redirection after the fork(), but before it replaces itself with the new executable code. Cheers, Warren From chet.ramey at case.edu Wed Aug 21 10:38:08 2019 From: chet.ramey at case.edu (Chet Ramey) Date: Tue, 20 Aug 2019 20:38:08 -0400 Subject: [TUHS] Shell builtin exec In-Reply-To: References: Message-ID: <83aa800b-76e8-7d72-8f1b-2148e36eec05@case.edu> On 8/20/19 5:10 PM, Adam Thornton wrote: > This is probably the place to ask: > > I understand why the shell builtin "exec" is the same as the syscall exec() > in the sense of "replace this process with that one."  But why is it also > the way to redirect filehandles in the current shell?  (That is, why isn't > the redirection named something else?) It was probably a side effect that turned out to be useful. The `exec' builtin performs redirections without a way to undo them, because why bother, and executes its arguments as a command with arguments, as if it were in a child process. The original Bourne shell just performed the redirections and returned if there weren't any arguments, leaving the non-undoable redirections in place. -- ``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 krewat at kilonet.net Tue Aug 27 09:13:25 2019 From: krewat at kilonet.net (Arthur Krewat) Date: Mon, 26 Aug 2019 19:13:25 -0400 Subject: [TUHS] If not Linux, then what? Message-ID: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel Leaving licensing and copyright issues out of this mental exercise, what would we have now if it wasn't for Linux? Not what you'd WANT it to be, although that can add to the discussion, but what WOULD it be? I'm not asking as a proponent of Linux. If anything, I was dragged kicking and screaming into the current day and have begrudgingly ceded my server space to Linux. But if not for Linux, would it be BSD? A System V variant? Or (the horror) Windows NT? I do understand that this has been discussed on the list before. I think, however, it would make a good late-summer exercise. Or late winter depending on where you are :) art k. From imp at bsdimp.com Tue Aug 27 09:27:14 2019 From: imp at bsdimp.com (Warner Losh) Date: Mon, 26 Aug 2019 17:27:14 -0600 Subject: [TUHS] If not Linux, then what? In-Reply-To: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> Message-ID: On Mon, Aug 26, 2019, 5:14 PM Arthur Krewat wrote: > > https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel > > Leaving licensing and copyright issues out of this mental exercise, what > would we have now if it wasn't for Linux? Not what you'd WANT it to be, > although that can add to the discussion, but what WOULD it be? > > I'm not asking as a proponent of Linux. If anything, I was dragged > kicking and screaming into the current day and have begrudgingly ceded > my server space to Linux. > > But if not for Linux, would it be BSD? A System V variant? Or (the > horror) Windows NT? > BSD was in decent enough shape at the time to run on PCs. Though it fragmented early through no fault of Linux. And the AT&T lawsuit created a lot of FUD in the area without actually protecting System V. It's unclear if another thing would have popped up to fill the void... Linux flourished in the confusion, but without it, it's hard to know if something else would have been developed before the AT&T lawsuit settled. Warner I do understand that this has been discussed on the list before. I > think, however, it would make a good late-summer exercise. Or late > winter depending on where you are :) > > art k. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Tue Aug 27 09:18:52 2019 From: jon at fourwinds.com (Jon Steinhart) Date: Mon, 26 Aug 2019 16:18:52 -0700 Subject: [TUHS] /dev/null Message-ID: <201908262318.x7QNIqaY012455@darkstar.fourwinds.com> Just curious - am doing a cross-country road trip with my kid and saw a Wisconsin dev null license plate. Didn't get a look at the driver. Does it belong to anyone on this list? Jon From lm at mcvoy.com Tue Aug 27 09:37:04 2019 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 26 Aug 2019 16:37:04 -0700 Subject: [TUHS] If not Linux, then what? In-Reply-To: References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> Message-ID: <20190826233704.GR13570@mcvoy.com> On Mon, Aug 26, 2019 at 05:27:14PM -0600, Warner Losh wrote: > On Mon, Aug 26, 2019, 5:14 PM Arthur Krewat wrote: > > > > > https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel > > > > Leaving licensing and copyright issues out of this mental exercise, what > > would we have now if it wasn't for Linux? Not what you'd WANT it to be, > > although that can add to the discussion, but what WOULD it be? > > > > I'm not asking as a proponent of Linux. If anything, I was dragged > > kicking and screaming into the current day and have begrudgingly ceded > > my server space to Linux. > > > > But if not for Linux, would it be BSD? A System V variant? Or (the > > horror) Windows NT? > > BSD was in decent enough shape at the time to run on PCs. Though it > fragmented early through no fault of Linux. And the AT&T lawsuit created a > lot of FUD in the area without actually protecting System V. It's unclear > if another thing would have popped up to fill the void... Linux flourished > in the confusion, but without it, it's hard to know if something else would > have been developed before the AT&T lawsuit settled. I've always wondered what would have happened if Sun had open sourced SunOS, I think it stood a pretty good chance of winning. Shoulda, woulda, coulda. From pechter at gmail.com Tue Aug 27 09:56:41 2019 From: pechter at gmail.com (William Pechter) Date: Mon, 26 Aug 2019 19:56:41 -0400 Subject: [TUHS] If not Linux, then what? In-Reply-To: References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> Message-ID: <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com> On 8/26/2019 7:27 PM, Warner Losh wrote: > > > On Mon, Aug 26, 2019, 5:14 PM Arthur Krewat > wrote: > > https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel > > Leaving licensing and copyright issues out of this mental > exercise, what > would we have now if it wasn't for Linux? Not what you'd WANT it > to be, > although that can add to the discussion, but what WOULD it be? > > I'm not asking as a proponent of Linux. If anything, I was dragged > kicking and screaming into the current day and have begrudgingly > ceded > my server space to Linux. > > But if not for Linux, would it be BSD? A System V variant? Or (the > horror) Windows NT? > > > BSD was in decent enough shape at the time to run on PCs. Though it > fragmented early through no fault of Linux. And the AT&T lawsuit > created a lot of FUD in the area without actually protecting System V. > It's unclear if another thing would have popped up to fill the void... > Linux flourished in the confusion, but without it, it's hard to know > if something else would have been developed before the AT&T lawsuit > settled. > > Warner > > > I do understand that this has been discussed on the list before. I > think, however, it would make a good late-summer exercise. Or late > winter depending on where you are :) > > art k. > > I ran both FreeBSD (up through at least 4.11 (and have the Tshirt) and NetBSD back in the 0.8 0.9 time frame.  My final -- (I used to move between them based on stability and driver support) -- move to Linux was caused by a lack of drivers for the Lenovo Workstation that used the Marvell 88SE63XX which with 5 SAS/SATA drives on it and 3 available on the Intel SATA controller would've been a great in-house server. I really preferred the FreeBSD stability and docs back in the early 1990's -- but by 2000 my jobs were all going Linux (Red Hat Sysadmin mostly) and I figured the work was moving to supported RHEL.  One of the things that often made me migrate was the support (in the early days) of all the weird interfaced cdrom drives like the Panasonic and other pre-ATAPI stuff. I'm going to revisit the ZFS on Linux stuff when Ubuntu puts it in their installer.  That will finally get me what I want on the D20. Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: From krewat at kilonet.net Tue Aug 27 10:19:45 2019 From: krewat at kilonet.net (Arthur Krewat) Date: Mon, 26 Aug 2019 20:19:45 -0400 Subject: [TUHS] If not Linux, then what? In-Reply-To: <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com> References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com> Message-ID: On 8/26/2019 7:56 PM, William Pechter wrote: > ZFS Here, here! From lm at mcvoy.com Tue Aug 27 10:30:13 2019 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 26 Aug 2019 17:30:13 -0700 Subject: [TUHS] If not Linux, then what? In-Reply-To: References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com> Message-ID: <20190827003013.GS13570@mcvoy.com> On Mon, Aug 26, 2019 at 08:19:45PM -0400, Arthur Krewat wrote: > On 8/26/2019 7:56 PM, William Pechter wrote: > >ZFS > > Here, here! I really don't understand the love for ZFS. I hired Bonwick and I hired Moore, I had high expectations but they were all dashed when I realized ZFS doesn't use the page cache. That's so crazy busted I lost all interest in ZFS. ZFS took us back to HP-UX mmap semantics. From clemc at ccc.com Tue Aug 27 10:48:48 2019 From: clemc at ccc.com (Clem Cole) Date: Mon, 26 Aug 2019 20:48:48 -0400 Subject: [TUHS] If not Linux, then what? In-Reply-To: References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> Message-ID: On Mon, Aug 26, 2019 at 7:28 PM Warner Losh wrote: > > BSD was in decent enough shape at the time to run on PCs. Though it > fragmented early through no fault of Linux. And the AT&T lawsuit created a > lot of FUD in the area without actually protecting System V. It's unclear > if another thing would have popped up to fill the void... Linux flourished > in the confusion, but without it, it's hard to know if something else would > have been developed before the AT&T lawsuit settled. > But what really allowed Linux to take off the AT&T vs. UCB/BSDi lawsuit. At the time Linux, didn't have networking much less a window manager etc... so lot of people, mysef included (incorrectly thinking is was a copyright case) thought we were going to lose a UNIX for our inexpensice (i.e. 'cheap' 386 based systems) so we all started started to hack on Linux 0.99xxx [my first real serious taste was an early Slackware version on a billion floppies fairly soon after Linus made it available and Patrick pulled together his first distribution]. But ... (and as I have point out elsewhere - see http://technique-societe.cnam.fr/la-recherche-sur-les-systemes-des-pivots-dans-l-histoire-de-l-informatique-ii-ii-988170.kjsp?RH=cdhte ], .... *if AT&T had won the case, all the other UNIX flavors* (Linux included would have had to have been pulled from the market). So in many ways, this question is not really a fair one. AT&T lost the case, and Linux got the ball and ran for it. That said, I'll drop into the hypotheical, if AT&T had lost and Linux had not been there ..... then... I do think some flavor of BSD would have been the winner. The two wild cards are from Sun and OSF/CMU. As Larry says is what about SunOS and Solaris, although the legals of Sun doing that I wonder. The other question is Mach/OSF (I know Larry does not like the codebase). But one of the *BSD, Mach or an FOSS Sun code base would have had the most legs. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Tue Aug 27 10:58:54 2019 From: robpike at gmail.com (Rob Pike) Date: Tue, 27 Aug 2019 10:58:54 +1000 Subject: [TUHS] If not Linux, then what? In-Reply-To: <20190827003013.GS13570@mcvoy.com> References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com> <20190827003013.GS13570@mcvoy.com> Message-ID: I always thought Research 10th Edition was fantastic. Even the 8th edition was an improvement on most of its successors. But things flowed another way, with muddy streams mixing in. -rob On Tue, Aug 27, 2019 at 10:30 AM Larry McVoy wrote: > On Mon, Aug 26, 2019 at 08:19:45PM -0400, Arthur Krewat wrote: > > On 8/26/2019 7:56 PM, William Pechter wrote: > > >ZFS > > > > Here, here! > > I really don't understand the love for ZFS. I hired Bonwick and I > hired Moore, I had high expectations but they were all dashed when I > realized ZFS doesn't use the page cache. That's so crazy busted I lost > all interest in ZFS. ZFS took us back to HP-UX mmap semantics. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From krewat at kilonet.net Tue Aug 27 10:59:02 2019 From: krewat at kilonet.net (Arthur Krewat) Date: Mon, 26 Aug 2019 20:59:02 -0400 Subject: [TUHS] If not Linux, then what? In-Reply-To: <20190827003013.GS13570@mcvoy.com> References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com> <20190827003013.GS13570@mcvoy.com> Message-ID: <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net> On 8/26/2019 8:30 PM, Larry McVoy wrote: > > I really don't understand the love for ZFS. I hired Bonwick and I > hired Moore, I had high expectations but they were all dashed when I > realized ZFS doesn't use the page cache. That's so crazy busted I lost > all interest in ZFS. ZFS took us back to HP-UX mmap semantics. > At the risk of going off-topic: From a system-administration standpoint, and data-integrity standpoint, ZFS was a huge step forward. In my humble opinion ;) Besides the obvious (to me) benefits of adding mount points, adjusting volume sizes, and all the other things that ZFS does, I have yet to find any mainstream filesystem (if you can call ZFS "just" a filesystem) that guarantees data integrity. I have an office server, that contains a lot of source code and archived data that I depend on religiously. I do copious backups to LTO tapes as well as an off-site Amazon EC2 instance. Within the recent past few years, I had an issue with a Dell MD Raid array where ZFS was complaining about checksum errors on a certain disk. Data was being corrupted on the fly. It seems that the writes were being corrupted, not reads. Thankfully, it was on a RAIDZ2 volume, where it could correct the corruption. The corruption in question was on files that are dated back to the early 90's. Stopping bit-rot in it's tracks, ZFS has done me well. As for what mmap() doesn't do right, I started using memory mapped files back in the early 80s on VMS on a VAX-11/780 when I and a colleague were converting a database from TOPS-10 to VMS. Perhaps I am misunderstanding your dislike for mmap() but please, enlighten me. It was my understanding at the time that it was akin to swapping/virtual-memory using an MMU. The difference was that instead of using the main paging area, the kernel would use an actual file.  Why would mmap() be a bad thing, when it's hooked into the kernel, and possibly hardware, at such a low point? art k. From clemc at ccc.com Tue Aug 27 11:06:46 2019 From: clemc at ccc.com (Clem Cole) Date: Mon, 26 Aug 2019 21:06:46 -0400 Subject: [TUHS] If not Linux, then what? In-Reply-To: References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com> <20190827003013.GS13570@mcvoy.com> Message-ID: On Mon, Aug 26, 2019 at 8:59 PM Rob Pike wrote: > I always thought Research 10th Edition was fantastic. Even the 8th edition > was an improvement on most of its successors. But things flowed another > way, with muddy streams mixing in. > > -rob > Rob - Fair enough/excellent point/I agree from a pure technology stand point, but the problem was anything from Research after Seventh Edition was the limited availability so few people out side really used it (and I'll have include Plan 9 in that family also - although you guys did get it out more widely than 8th or 10th UNIX -- funny by that point, I had read about it and seen the manuals in a book store in the UK, but I did not get the mess with the actual 10th edition code until a few years after I had a Plan 9 boot floppy that Dave gave me running in a laptop). Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Tue Aug 27 11:17:38 2019 From: crossd at gmail.com (Dan Cross) Date: Mon, 26 Aug 2019 21:17:38 -0400 Subject: [TUHS] If not Linux, then what? In-Reply-To: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> Message-ID: On Mon, Aug 26, 2019, 7:14 PM Arthur Krewat wrote: > > https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel > > Leaving licensing and copyright issues out of this mental exercise, what > would we have now if it wasn't for Linux? Not what you'd WANT it to be, > although that can add to the discussion, but what WOULD it be? > > I'm not asking as a proponent of Linux. If anything, I was dragged > kicking and screaming into the current day and have begrudgingly ceded > my server space to Linux. > > But if not for Linux, would it be BSD? A System V variant? Or (the > horror) Windows NT? > > I do understand that this has been discussed on the list before. I > think, however, it would make a good late-summer exercise. Or late > winter depending on where you are :) > This is an interesting question, though of course impossible to actually answer in a meaningful way, as hypotheticals always are. But assuming one could hold all else constant and just erase Linux from the picture, it seems pretty obvious that some kind of BSD variant would have been "it." I think a more interesting question, however, might be: had Linux not happened, would that have opened the space for serious consideration of alternative system architectures, either along Unix derivative lines, or completely different? For example, perhaps something like plan 9 would have had greater penetration into the market. I saw a talk a couple of months ago that attributed the diversity of systems in the 60s and 70s to the idea that people were trying so many different things because no one knew _how_ to build systems. That may be at least partially true, but I was wondering thinking about that very thing this morning and realized that we're certainly swirling around the toilet bowl converging on some central set of things we think work pretty well (files! processes! threads!). But as time marches on and we see the environment changing around us, we don't often go back and revisit these sorts of fundamental assumptions. More's the shame, I'm afraid. One wonders what's next. People now talk about Linux with the sort of reverent tones they once discussed Windows and before that the mainframe. Too big to fail, the Last System, etc. But there are cracks there: Fuchsia is a different architecture, because that Unix model isn't going to accommodate all contemporary use cases: the security model seems to be a big driver here. Will they succeed? It'll be at least interesting to watch and see. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gregg.drwho8 at gmail.com Tue Aug 27 11:25:51 2019 From: gregg.drwho8 at gmail.com (Gregg Levine) Date: Mon, 26 Aug 2019 21:25:51 -0400 Subject: [TUHS] If not Linux, then what? In-Reply-To: References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> Message-ID: Hello! having run both FreeBSD and NetBSD and several different examples of Linux, I found that FreeBSD was a bit flaky at the time. NetBSD was good, but for my efforts, I ended up with Slackware, I started with his three something examples, and now I have 11 running. I have tried under SIMH most of the examples that live on the FTP site which will boot. But I still have strong support for practically everything SUN wrote. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again." On Mon, Aug 26, 2019 at 8:49 PM Clem Cole wrote: > > > > On Mon, Aug 26, 2019 at 7:28 PM Warner Losh wrote: >> >> >> BSD was in decent enough shape at the time to run on PCs. Though it fragmented early through no fault of Linux. And the AT&T lawsuit created a lot of FUD in the area without actually protecting System V. It's unclear if another thing would have popped up to fill the void... Linux flourished in the confusion, but without it, it's hard to know if something else would have been developed before the AT&T lawsuit settled. > > > > But what really allowed Linux to take off the AT&T vs. UCB/BSDi lawsuit. At the time Linux, didn't have networking much less a window manager etc... so lot of people, mysef included (incorrectly thinking is was a copyright case) thought we were going to lose a UNIX for our inexpensice (i.e. 'cheap' 386 based systems) so we all started started to hack on Linux 0.99xxx [my first real serious taste was an early Slackware version on a billion floppies fairly soon after Linus made it available and Patrick pulled together his first distribution]. > > But ... (and as I have point out elsewhere - see > http://technique-societe.cnam.fr/la-recherche-sur-les-systemes-des-pivots-dans-l-histoire-de-l-informatique-ii-ii-988170.kjsp?RH=cdhte], > .... if AT&T had won the case, all the other UNIX flavors (Linux included would have had to have been pulled from the market). > So in many ways, this question is not really a fair one. > > AT&T lost the case, and Linux got the ball and ran for it. > > That said, I'll drop into the hypotheical, if AT&T had lost and Linux had not been there ..... then... I do think some flavor of BSD would have been the winner. The two wild cards are from Sun and OSF/CMU. As Larry says is what about SunOS and Solaris, although the legals of Sun doing that I wonder. The other question is Mach/OSF (I know Larry does not like the codebase). > > But one of the *BSD, Mach or an FOSS Sun code base would have had the most legs. > > Clem > From crossd at gmail.com Tue Aug 27 11:26:27 2019 From: crossd at gmail.com (Dan Cross) Date: Mon, 26 Aug 2019 21:26:27 -0400 Subject: [TUHS] If not Linux, then what? In-Reply-To: <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net> References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com> <20190827003013.GS13570@mcvoy.com> <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net> Message-ID: On Mon, Aug 26, 2019, 9:00 PM Arthur Krewat wrote: >[snip] > > As for what mmap() doesn't do right, I started using memory mapped files > back in the early 80s on VMS on a VAX-11/780 when I and a colleague were > converting a database from TOPS-10 to VMS. Perhaps I am misunderstanding > your dislike for mmap() but please, enlighten me. It was my > understanding at the time that it was akin to swapping/virtual-memory > using an MMU. The difference was that instead of using the main paging > area, the kernel would use an actual file. Why would mmap() be a bad > thing, when it's hooked into the kernel, and possibly hardware, at such > a low point? I don't mean to put words in Larry's mouth, but I think he meant that ZFS bypasses the OS page cache, so that file IO and mmap use a different buffering scheme that is not mutually consistent. So a process could mmap() a file, write to it via a pointer indirection, and then invoke read() at a relevant offset and (perhaps) not see the earlier write reflected; or vice versa. It's not that mmap is a priori bad, but rather that ZFS has this unfortunate corner case related to mmap. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Tue Aug 27 12:16:58 2019 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Mon, 26 Aug 2019 22:16:58 -0400 Subject: [TUHS] If not Linux, then what? In-Reply-To: References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> Message-ID: <20190827021658.GF28066@mit.edu> On Mon, Aug 26, 2019 at 05:27:14PM -0600, Warner Losh wrote: > > BSD was in decent enough shape at the time to run on PCs. Though it > fragmented early through no fault of Linux. And the AT&T lawsuit created a > lot of FUD in the area without actually protecting System V. It's unclear > if another thing would have popped up to fill the void... Linux flourished > in the confusion, but without it, it's hard to know if something else would > have been developed before the AT&T lawsuit settled. It's really hard to answer these what-if questions. The *BSD's suffered from some really toxic politics which resulted in the fragmentation, but it also no doubt turned away some developers. I had friends at MIT who were urging me to quit the "toy" Linux and switch to the more "Real" Unix efforts. But I got to meet at least one very toxic personality in person which immediately turned me away from that offer --- and I got my start on BSD 4.3 with Project Athena. (For all that people used to like to complain about Linus's e-mail persona, I *much* preferred to work with Linus than with some of the personalities in the *BSD/HURD communities.) People are very fond of blaming the *BSD's failure to become popular on the AT&T lawsuit, and that no doubt didn't help. But it's not at all clear to me that was the only, or even the primary, reason. - Ted From lm at mcvoy.com Tue Aug 27 12:39:13 2019 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 26 Aug 2019 19:39:13 -0700 Subject: [TUHS] If not Linux, then what? In-Reply-To: <20190827021658.GF28066@mit.edu> References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <20190827021658.GF28066@mit.edu> Message-ID: <20190827023913.GT13570@mcvoy.com> On Mon, Aug 26, 2019 at 10:16:58PM -0400, Theodore Y. Ts'o wrote: > On Mon, Aug 26, 2019 at 05:27:14PM -0600, Warner Losh wrote: > > > > BSD was in decent enough shape at the time to run on PCs. Though it > > fragmented early through no fault of Linux. And the AT&T lawsuit created a > > lot of FUD in the area without actually protecting System V. It's unclear > > if another thing would have popped up to fill the void... Linux flourished > > in the confusion, but without it, it's hard to know if something else would > > have been developed before the AT&T lawsuit settled. > > It's really hard to answer these what-if questions. The *BSD's > suffered from some really toxic politics which resulted in the > fragmentation, but it also no doubt turned away some developers. I > had friends at MIT who were urging me to quit the "toy" Linux and > switch to the more "Real" Unix efforts. But I got to meet at least > one very toxic personality in person which immediately turned me away > from that offer --- and I got my start on BSD 4.3 with Project Athena. > (For all that people used to like to complain about Linus's e-mail > persona, I *much* preferred to work with Linus than with some of the > personalities in the *BSD/HURD communities.) > > People are very fond of blaming the *BSD's failure to become popular > on the AT&T lawsuit, and that no doubt didn't help. But it's not at > all clear to me that was the only, or even the primary, reason. I agree with Ted and I'm seeing it to this day, I hang with some BSD folks and they spend way too much time complaining about people. Sorry, but that's my take. Maybe the world is as shitty as they say it is but my world wasn't that great, you just roll up your sleeves and make a difference. I dunno, it does seem different, maybe it was easy for me and it is hard for them but I don't like the complaining. Linus, in my opinion, is a great programmer (all you have to do is read his rants about obscure stuff and it is clear he knows the details of a ton of stuff), a great architect (I could be pushed back a little on this one but he is good), and a great manager. He inspires other people to do well, he pushes for a good code base, he hates shitty code. He is a leader, you can argue about his faults but he leads. And I have *never* seen all those skill sets in one person. I've said that at least 20 years ago and it is true today. The BSD crowd lacked that sort of leader. So {386,Net,Open,Free,DragonFly}BSD all have their own crowd but they are tiny crowds. I say this with dismay, I'm a SunOS 4.x guy, that's the bugfixed BSD. I loved BSD Unix, it was the best and it had the chance to be the future but for whatever reason the "leaders" in BSD didn't have an actual leader. Not one of them. Not 1/100th of the leader that Linus is. So Linux won. I'm not that happy about it, I could imagine a world where BSD won and I think I'd be happier in that world but it didn't happen. From lm at mcvoy.com Tue Aug 27 12:45:11 2019 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 26 Aug 2019 19:45:11 -0700 Subject: [TUHS] If not Linux, then what? In-Reply-To: References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com> <20190827003013.GS13570@mcvoy.com> <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net> Message-ID: <20190827024511.GU13570@mcvoy.com> On Mon, Aug 26, 2019 at 09:26:27PM -0400, Dan Cross wrote: > On Mon, Aug 26, 2019, 9:00 PM Arthur Krewat wrote: > >[snip] > > > > > As for what mmap() doesn't do right, I started using memory mapped files > > back in the early 80s on VMS on a VAX-11/780 when I and a colleague were > > converting a database from TOPS-10 to VMS. Perhaps I am misunderstanding > > your dislike for mmap() but please, enlighten me. It was my > > understanding at the time that it was akin to swapping/virtual-memory > > using an MMU. The difference was that instead of using the main paging > > area, the kernel would use an actual file. Why would mmap() be a bad > > thing, when it's hooked into the kernel, and possibly hardware, at such > > a low point? > > > I don't mean to put words in Larry's mouth, but I think he meant that ZFS > bypasses the OS page cache, so that file IO and mmap use a different > buffering scheme that is not mutually consistent. Dan is right. At Sun, when Joe Moran did the 4.x VM system, he put into place the vision that Bill Joy had. Which was that the page cache is *the* cache. There is nothing else. We spent a bunch of time killing the buffer cache because you couldn't mmap the buffer cache, you could mmap the page cache. It's hard to describe how right that was but it was right. You could have as many processes as you wanted mmap-ing the same data and there was a single version of the data. What ZFS did was manage the data on their own. So if you mmap-ed a ZFS file it had to bcopy the data into the page cache and now it is right back to two copies of the data and you have to manage consistency. I would have been fine if all page sized blocks were in the page cache and ZFS managed the less than page sized blocks. But they punted on the page cache entirely. My mind is blown that that was allowed to ship. The Sun I worked at, if I had proposed that design, I would have been kicked out of the kernel group. From lm at mcvoy.com Tue Aug 27 12:53:10 2019 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 26 Aug 2019 19:53:10 -0700 Subject: [TUHS] If not Linux, then what? In-Reply-To: References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com> <20190827003013.GS13570@mcvoy.com> Message-ID: <20190827025310.GW13570@mcvoy.com> Hey Rob, I followed Bell Labs through the papers, the Lions doc, but I didn't get any insight into Research after v7 or so. Can you tell us what you liked about the later versions? I don't want to be a total suck up but I've been a fan of your insight ever since you said something like "if you think you need threads your processes are too fat". I've had long discussions with Linus about how to make that statement 100% true (partial page table sharing across processes, how do you make that work in general). We didn't come to an answer but we both agreed that processes should be as cheap as threads and mmap is the way to share data. On Tue, Aug 27, 2019 at 10:58:54AM +1000, Rob Pike wrote: > I always thought Research 10th Edition was fantastic. Even the 8th edition > was an improvement on most of its successors. But things flowed another > way, with muddy streams mixing in. > > -rob > > > On Tue, Aug 27, 2019 at 10:30 AM Larry McVoy wrote: > > > On Mon, Aug 26, 2019 at 08:19:45PM -0400, Arthur Krewat wrote: > > > On 8/26/2019 7:56 PM, William Pechter wrote: > > > >ZFS > > > > > > Here, here! > > > > I really don't understand the love for ZFS. I hired Bonwick and I > > hired Moore, I had high expectations but they were all dashed when I > > realized ZFS doesn't use the page cache. That's so crazy busted I lost > > all interest in ZFS. ZFS took us back to HP-UX mmap semantics. > > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From krewat at kilonet.net Tue Aug 27 13:14:45 2019 From: krewat at kilonet.net (Arthur Krewat) Date: Mon, 26 Aug 2019 23:14:45 -0400 Subject: [TUHS] If not Linux, then what? In-Reply-To: <20190827024511.GU13570@mcvoy.com> References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com> <20190827003013.GS13570@mcvoy.com> <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net> <20190827024511.GU13570@mcvoy.com> Message-ID: On 8/26/2019 10:45 PM, Larry McVoy wrote: > Which was that the page cache is > *the* cache. There is nothing else. Yeah, I re-read what you wrote a few times after I replied, and realized what you meant ... eventually ;) From athornton at gmail.com Tue Aug 27 15:54:31 2019 From: athornton at gmail.com (Adam Thornton) Date: Mon, 26 Aug 2019 22:54:31 -0700 Subject: [TUHS] If not Linux, then what? In-Reply-To: <20190827023913.GT13570@mcvoy.com> References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <20190827021658.GF28066@mit.edu> <20190827023913.GT13570@mcvoy.com> Message-ID: <7DB50A42-BBA3-4F70-BCCA-31FBAB2F1E1C@gmail.com> > On Aug 26, 2019, at 7:39 PM, Larry McVoy wrote: > > On Mon, Aug 26, 2019 at 10:16:58PM -0400, Theodore Y. Ts'o wrote: >> But I got to meet at least >> one very toxic personality in person which immediately turned me away >> from that offer --- and I got my start on BSD 4.3 with Project Athena. >> (For all that people used to like to complain about Linus's e-mail >> persona, I *much* preferred to work with Linus than with some of the >> personalities in the *BSD/HURD communities.) >> > > I agree with Ted and I'm seeing it to this day, I hang with some BSD > folks and they spend way too much time complaining about people. Yeah, this. I don’t know about these days, but…. End of the 90s, early 2000s, I was deeply involved in the Linux port to System/390 and then zSeries. Sometime, probably ’99, maybe ’00, I went to a Linux conference in Atlanta; I talked a little about Linux on S/390 and the things we were looking for help with. And I went to the NetBSD booth. I mean, even then, NetBSD’s thing was that it ran on all sorts of architectures. So I introduced myself, to say, “hey, if you guys want a development environment to hammer out a S/390 port, I can probably hook you up.” What I got was a btiter rant about Linux’s “so-called portability” and I was basically told to FOAD. That was…quite a surprise, having been working in a mostly-supportive community, albeit one in which the manufacturer was pretty dubious about the port. Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From gregg.drwho8 at gmail.com Tue Aug 27 16:05:00 2019 From: gregg.drwho8 at gmail.com (Gregg Levine) Date: Tue, 27 Aug 2019 02:05:00 -0400 Subject: [TUHS] If not Linux, then what? In-Reply-To: <7DB50A42-BBA3-4F70-BCCA-31FBAB2F1E1C@gmail.com> References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <20190827021658.GF28066@mit.edu> <20190827023913.GT13570@mcvoy.com> <7DB50A42-BBA3-4F70-BCCA-31FBAB2F1E1C@gmail.com> Message-ID: Hello! Oh dear. At the very first Linux conference in NYC, I caught up with the NetBSD group there, and suggested something-of-a-sort. Let's just say that the person there is probably still active on their lists, and sometimes comes across as someone even Larry wouldn't like very much. I tried again after he stopped behaving like someone from a movie we all know, and I asked again. His response was similar. I put it down to extreme jet lag. Adam if your interested please ask off list. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again." On Tue, Aug 27, 2019 at 1:55 AM Adam Thornton wrote: > > > > On Aug 26, 2019, at 7:39 PM, Larry McVoy wrote: > > On Mon, Aug 26, 2019 at 10:16:58PM -0400, Theodore Y. Ts'o wrote: > > But I got to meet at least > one very toxic personality in person which immediately turned me away > from that offer --- and I got my start on BSD 4.3 with Project Athena. > (For all that people used to like to complain about Linus's e-mail > persona, I *much* preferred to work with Linus than with some of the > personalities in the *BSD/HURD communities.) > > > I agree with Ted and I'm seeing it to this day, I hang with some BSD > folks and they spend way too much time complaining about people. > > > Yeah, this. I don’t know about these days, but…. > > End of the 90s, early 2000s, I was deeply involved in the Linux port to System/390 and then zSeries. Sometime, probably ’99, maybe ’00, I went to a Linux conference in Atlanta; I talked a little about Linux on S/390 and the things we were looking for help with. > > And I went to the NetBSD booth. I mean, even then, NetBSD’s thing was that it ran on all sorts of architectures. So I introduced myself, to say, “hey, if you guys want a development environment to hammer out a S/390 port, I can probably hook you up.” What I got was a btiter rant about Linux’s “so-called portability” and I was basically told to FOAD. > > That was…quite a surprise, having been working in a mostly-supportive community, albeit one in which the manufacturer was pretty dubious about the port. > > Adam From emu at e-bbes.com Tue Aug 27 16:37:26 2019 From: emu at e-bbes.com (emanuel stiebler) Date: Tue, 27 Aug 2019 02:37:26 -0400 Subject: [TUHS] /dev/null In-Reply-To: <201908262318.x7QNIqaY012455@darkstar.fourwinds.com> References: <201908262318.x7QNIqaY012455@darkstar.fourwinds.com> Message-ID: On 2019-08-26 19:18, Jon Steinhart wrote: > Just curious - am doing a cross-country road trip with my kid and saw a > Wisconsin dev null license plate. Didn't get a look at the driver. > Does it belong to anyone on this list? Hopefully he has more fun with it, than this guy: https://www.wired.com/story/null-license-plate-landed-one-hacker-ticket-hell/ From arnold at skeeve.com Tue Aug 27 17:47:07 2019 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 27 Aug 2019 01:47:07 -0600 Subject: [TUHS] If not Linux, then what? In-Reply-To: References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com> <20190827003013.GS13570@mcvoy.com> Message-ID: <201908270747.x7R7l73N024373@freefriends.org> I'd have liked to see Plan 9 take over the world. I think we'd all be in a nicer place if it had. My $.02, Arnold Rob Pike wrote: > I always thought Research 10th Edition was fantastic. Even the 8th edition > was an improvement on most of its successors. But things flowed another > way, with muddy streams mixing in. > > -rob > > > On Tue, Aug 27, 2019 at 10:30 AM Larry McVoy wrote: > > > On Mon, Aug 26, 2019 at 08:19:45PM -0400, Arthur Krewat wrote: > > > On 8/26/2019 7:56 PM, William Pechter wrote: > > > >ZFS > > > > > > Here, here! > > > > I really don't understand the love for ZFS. I hired Bonwick and I > > hired Moore, I had high expectations but they were all dashed when I > > realized ZFS doesn't use the page cache. That's so crazy busted I lost > > all interest in ZFS. ZFS took us back to HP-UX mmap semantics. > > From robpike at gmail.com Tue Aug 27 19:47:58 2019 From: robpike at gmail.com (Rob Pike) Date: Tue, 27 Aug 2019 19:47:58 +1000 Subject: [TUHS] If not Linux, then what? In-Reply-To: <20190827025310.GW13570@mcvoy.com> References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com> <20190827003013.GS13570@mcvoy.com> <20190827025310.GW13570@mcvoy.com> Message-ID: V8 was the first of a series of refinements that unified things nicely, allowing programs to interact more smoothly. Nothing too dramatic, really: things like a shell that could export its environment, including functions; tweaks to how $PATH worked so we could have binaries with names like n/m1 n/m2 etc. to connect to machines m1 and m2; a push for output from programs that worked as input to the same programs (a huge deal for the shell); and so on. Lots of cleanups (db really worked, and worked well; stuff like that). Not to mention clean networking and graphics APIs that showed how easy it was to incorporate them into Unix. What is a socket for, anyway? Why do you need them when you have file descriptors? (Rhetorical question, because the answer is, you don't. But the earliest sockets didn't even implement read and write!) And so on. But we did Plan 9 after v10, so it's clear we didn't think it was perfect, yet. -rob On Tue, Aug 27, 2019 at 12:53 PM Larry McVoy wrote: > Hey Rob, > > I followed Bell Labs through the papers, the Lions doc, but I didn't get > any insight into Research after v7 or so. > > Can you tell us what you liked about the later versions? > > I don't want to be a total suck up but I've been a fan of your insight > ever since you said something like "if you think you need threads your > processes are too fat". I've had long discussions with Linus about how > to make that statement 100% true (partial page table sharing across > processes, how do you make that work in general). We didn't come to > an answer but we both agreed that processes should be as cheap as > threads and mmap is the way to share data. > > On Tue, Aug 27, 2019 at 10:58:54AM +1000, Rob Pike wrote: > > I always thought Research 10th Edition was fantastic. Even the 8th > edition > > was an improvement on most of its successors. But things flowed another > > way, with muddy streams mixing in. > > > > -rob > > > > > > On Tue, Aug 27, 2019 at 10:30 AM Larry McVoy wrote: > > > > > On Mon, Aug 26, 2019 at 08:19:45PM -0400, Arthur Krewat wrote: > > > > On 8/26/2019 7:56 PM, William Pechter wrote: > > > > >ZFS > > > > > > > > Here, here! > > > > > > I really don't understand the love for ZFS. I hired Bonwick and I > > > hired Moore, I had high expectations but they were all dashed when I > > > realized ZFS doesn't use the page cache. That's so crazy busted I lost > > > all interest in ZFS. ZFS took us back to HP-UX mmap semantics. > > > > > -- > --- > Larry McVoy lm at mcvoy.com > http://www.mcvoy.com/lm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman at oclsc.org Tue Aug 27 20:41:43 2019 From: norman at oclsc.org (Norman Wilson) Date: Tue, 27 Aug 2019 06:41:43 -0400 Subject: [TUHS] /dev/null Message-ID: <1566902508.8190.for-standards-violators@oclsc.org> John Steinhart: Just curious - am doing a cross-country road trip with my kid and saw a Wisconsin dev null license plate. Didn't get a look at the driver. ===== It's in ken/mem.c in Fourth Edition, dmr/mem.c in Fifth and Sixth. Norman (no sheds) Wilson Toronto ON From lm at mcvoy.com Wed Aug 28 00:55:56 2019 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 27 Aug 2019 07:55:56 -0700 Subject: [TUHS] If not Linux, then what? In-Reply-To: References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com> <20190827003013.GS13570@mcvoy.com> <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net> <20190827024511.GU13570@mcvoy.com> Message-ID: <20190827145556.GD13570@mcvoy.com> On Mon, Aug 26, 2019 at 11:14:45PM -0400, Arthur Krewat wrote: > On 8/26/2019 10:45 PM, Larry McVoy wrote: > > Which was that the page cache is > >*the* cache. There is nothing else. > Yeah, I re-read what you wrote a few times after I replied, and realized > what you meant ... eventually ;) I might be making too big of a deal about it. mmap semantics mattered a lot when SMPs first showed up and main memory was small. It meant that you could have multiple CPUs seeing and working on the same chunk of data at the same time. It's very similar to way that IOMMUs are exposed to user space these days, enabling virtual machines direct access to the I/O devices. ZFS breaks that model, the data is all in the ARC and if you mmap it they have to bcopy the data out of the ARC, into the page cache and now they have a consistency problem, you could modify stuff via mmap or write and they have to manage that. That consistency problem is the main reason that Sun almost completely killed the buffer cache (it still was used for inodes and directories but that was it). That consistency problem is a pain in the rear, all sorts of race conditions and it tended to bit rot. Jeff and Bill are smart people so I suspect they got it right but I'm still stunned that they took such an architecturally bad approach. And even more stunned that the oversight people approved it. There is zero chance that the Sun I worked at would have allowed that. --lm From aap at papnet.eu Wed Aug 28 02:05:59 2019 From: aap at papnet.eu (Angelo Papenhoff) Date: Tue, 27 Aug 2019 18:05:59 +0200 Subject: [TUHS] Running v10 In-Reply-To: References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com> <20190827003013.GS13570@mcvoy.com> Message-ID: <20190827160559.GA92491@indra.papnet.eu> Did anyone try to get v10 running in simh yet? It's been public for a while now and while we have two blit emulators already I haven't seen v10 alive yet. I have to admit I haven't tried to get it running myself either. aap On 27/08/19, Rob Pike wrote: > I always thought Research 10th Edition was fantastic. Even the 8th edition > was an improvement on most of its successors. But things flowed another > way, with muddy streams mixing in. From henry.r.bent at gmail.com Wed Aug 28 02:27:23 2019 From: henry.r.bent at gmail.com (Henry Bent) Date: Tue, 27 Aug 2019 12:27:23 -0400 Subject: [TUHS] Running v10 In-Reply-To: <20190827160559.GA92491@indra.papnet.eu> References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com> <20190827003013.GS13570@mcvoy.com> <20190827160559.GA92491@indra.papnet.eu> Message-ID: On Tue, 27 Aug 2019 at 12:12, Angelo Papenhoff wrote: > Did anyone try to get v10 running in simh yet? It's been public for a > while now and while we have two blit emulators already I haven't seen > v10 alive yet. I have to admit I haven't tried to get it running myself > either. > After a brief look at the boot and config sources it appears as though there is support for the MicroVAX II which SIMH supports and I have used. Is there an environment which is preferred for building the V10 source tree? 4.3BSD? V8? Something else? -Henry On 27/08/19, Rob Pike wrote: > > I always thought Research 10th Edition was fantastic. Even the 8th > edition > > was an improvement on most of its successors. But things flowed another > > way, with muddy streams mixing in. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggm at algebras.org Wed Aug 28 08:30:01 2019 From: ggm at algebras.org (George Michaelson) Date: Wed, 28 Aug 2019 08:30:01 +1000 Subject: [TUHS] If not Linux, then what? In-Reply-To: <20190827145556.GD13570@mcvoy.com> References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com> <20190827003013.GS13570@mcvoy.com> <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net> <20190827024511.GU13570@mcvoy.com> <20190827145556.GD13570@mcvoy.com> Message-ID: BSD, but with the original STREAMS semantics, not sockets. DARPA did us no favours accepting sockets in place of simple file I/O semantics for networks. Newcastle connection put the namespace into /.../remote-part/path/to/thing which I felt was also good. So for me, 7 -> BSD -> got worse for some values of worse On Wed, Aug 28, 2019 at 12:56 AM Larry McVoy wrote: > > On Mon, Aug 26, 2019 at 11:14:45PM -0400, Arthur Krewat wrote: > > On 8/26/2019 10:45 PM, Larry McVoy wrote: > > > Which was that the page cache is > > >*the* cache. There is nothing else. > > Yeah, I re-read what you wrote a few times after I replied, and realized > > what you meant ... eventually ;) > > I might be making too big of a deal about it. mmap semantics mattered > a lot when SMPs first showed up and main memory was small. It meant > that you could have multiple CPUs seeing and working on the same chunk > of data at the same time. > > It's very similar to way that IOMMUs are exposed to user space these > days, enabling virtual machines direct access to the I/O devices. > > ZFS breaks that model, the data is all in the ARC and if you mmap > it they have to bcopy the data out of the ARC, into the page cache > and now they have a consistency problem, you could modify stuff > via mmap or write and they have to manage that. > > That consistency problem is the main reason that Sun almost completely > killed the buffer cache (it still was used for inodes and directories > but that was it). That consistency problem is a pain in the rear, > all sorts of race conditions and it tended to bit rot. > > Jeff and Bill are smart people so I suspect they got it right but I'm > still stunned that they took such an architecturally bad approach. > And even more stunned that the oversight people approved it. There > is zero chance that the Sun I worked at would have allowed that. > > --lm From lm at mcvoy.com Wed Aug 28 08:40:02 2019 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 27 Aug 2019 15:40:02 -0700 Subject: [TUHS] If not Linux, then what? In-Reply-To: References: <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com> <20190827003013.GS13570@mcvoy.com> <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net> <20190827024511.GU13570@mcvoy.com> <20190827145556.GD13570@mcvoy.com> Message-ID: <20190827224002.GB15511@mcvoy.com> Wait, are you arguing for STREAMS over sockets? Dear god, please no. Have you ever used STREAMS (not Ritchies streams, those were OK)? I have. I ported Lachman's STREAMS based TCP/IP stack twice, once to a long since defunct super computer called the ETA-10 and then to SCO Unix. I've got way more STREAMS experience than most people and I can tell you that sockets are WAY WAY better. I get the "it should have just been file I/O" except that I don't. I tried to write a library that let you open up /net/tcp/$host:$port and do I/O like it was a file descriptor. That works for a lot of stuff but I ran into problems quickly. A networking connection is not a file handle. You can make some stuff work but I couldn't figure out how to do all of it. You end up having to do ioctls to handle the stuff that doesn't fit well into the file system name space. I think plan 9 did this sort of thing, maybe Rob can prove me wrong or remember where it didn't match. I do know that STREAMS came back to Solaris, some VP inked a shitty deal with Lachman and bought the rights to the stack. It was slow as molasses in the winter and customers absolutely hated it. Sun got Mentat to redo it for perf but customers still hated it, they understood sockets, everyone else had sockets, they wanted sockets and they got them. Sun put them back and nobody ever asked about STREAMS again. On Wed, Aug 28, 2019 at 08:30:01AM +1000, George Michaelson wrote: > BSD, but with the original STREAMS semantics, not sockets. > > DARPA did us no favours accepting sockets in place of simple file I/O > semantics for networks. > > Newcastle connection put the namespace into > /.../remote-part/path/to/thing which I felt was also good. > > So for me, 7 -> BSD -> got worse for some values of worse > > On Wed, Aug 28, 2019 at 12:56 AM Larry McVoy wrote: > > > > On Mon, Aug 26, 2019 at 11:14:45PM -0400, Arthur Krewat wrote: > > > On 8/26/2019 10:45 PM, Larry McVoy wrote: > > > > Which was that the page cache is > > > >*the* cache. There is nothing else. > > > Yeah, I re-read what you wrote a few times after I replied, and realized > > > what you meant ... eventually ;) > > > > I might be making too big of a deal about it. mmap semantics mattered > > a lot when SMPs first showed up and main memory was small. It meant > > that you could have multiple CPUs seeing and working on the same chunk > > of data at the same time. > > > > It's very similar to way that IOMMUs are exposed to user space these > > days, enabling virtual machines direct access to the I/O devices. > > > > ZFS breaks that model, the data is all in the ARC and if you mmap > > it they have to bcopy the data out of the ARC, into the page cache > > and now they have a consistency problem, you could modify stuff > > via mmap or write and they have to manage that. > > > > That consistency problem is the main reason that Sun almost completely > > killed the buffer cache (it still was used for inodes and directories > > but that was it). That consistency problem is a pain in the rear, > > all sorts of race conditions and it tended to bit rot. > > > > Jeff and Bill are smart people so I suspect they got it right but I'm > > still stunned that they took such an architecturally bad approach. > > And even more stunned that the oversight people approved it. There > > is zero chance that the Sun I worked at would have allowed that. > > > > --lm -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From ggm at algebras.org Wed Aug 28 08:46:35 2019 From: ggm at algebras.org (George Michaelson) Date: Wed, 28 Aug 2019 08:46:35 +1000 Subject: [TUHS] If not Linux, then what? In-Reply-To: <20190827224002.GB15511@mcvoy.com> References: <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com> <20190827003013.GS13570@mcvoy.com> <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net> <20190827024511.GU13570@mcvoy.com> <20190827145556.GD13570@mcvoy.com> <20190827224002.GB15511@mcvoy.com> Message-ID: oh maybe I meant "streams" not "STREAMS" I always got confused if the original ritchie spec was upper or lower case. Charles Forsyth coded it into the York Uni Vaxen, worked fine. I left shortly after to do stuff at UCL, it only came back into my life when at UQ in Australia we got an ICL "certified" SYSV host and along side dead technology like RFS up it popped (I think ICL had coded an OSI stack we were testing) -G On Wed, Aug 28, 2019 at 8:40 AM Larry McVoy wrote: > > Wait, are you arguing for STREAMS over sockets? Dear god, please no. > Have you ever used STREAMS (not Ritchies streams, those were OK)? > I have. I ported Lachman's STREAMS based TCP/IP stack twice, once > to a long since defunct super computer called the ETA-10 and then > to SCO Unix. I've got way more STREAMS experience than most people > and I can tell you that sockets are WAY WAY better. I get the "it > should have just been file I/O" except that I don't. I tried to > write a library that let you open up /net/tcp/$host:$port and do > I/O like it was a file descriptor. That works for a lot of stuff > but I ran into problems quickly. A networking connection is not > a file handle. You can make some stuff work but I couldn't figure > out how to do all of it. You end up having to do ioctls to handle > the stuff that doesn't fit well into the file system name space. > I think plan 9 did this sort of thing, maybe Rob can prove me wrong > or remember where it didn't match. > > I do know that STREAMS came back to Solaris, some VP inked a shitty > deal with Lachman and bought the rights to the stack. It was slow > as molasses in the winter and customers absolutely hated it. Sun > got Mentat to redo it for perf but customers still hated it, they > understood sockets, everyone else had sockets, they wanted sockets > and they got them. Sun put them back and nobody ever asked about > STREAMS again. > > On Wed, Aug 28, 2019 at 08:30:01AM +1000, George Michaelson wrote: > > BSD, but with the original STREAMS semantics, not sockets. > > > > DARPA did us no favours accepting sockets in place of simple file I/O > > semantics for networks. > > > > Newcastle connection put the namespace into > > /.../remote-part/path/to/thing which I felt was also good. > > > > So for me, 7 -> BSD -> got worse for some values of worse > > > > On Wed, Aug 28, 2019 at 12:56 AM Larry McVoy wrote: > > > > > > On Mon, Aug 26, 2019 at 11:14:45PM -0400, Arthur Krewat wrote: > > > > On 8/26/2019 10:45 PM, Larry McVoy wrote: > > > > > Which was that the page cache is > > > > >*the* cache. There is nothing else. > > > > Yeah, I re-read what you wrote a few times after I replied, and realized > > > > what you meant ... eventually ;) > > > > > > I might be making too big of a deal about it. mmap semantics mattered > > > a lot when SMPs first showed up and main memory was small. It meant > > > that you could have multiple CPUs seeing and working on the same chunk > > > of data at the same time. > > > > > > It's very similar to way that IOMMUs are exposed to user space these > > > days, enabling virtual machines direct access to the I/O devices. > > > > > > ZFS breaks that model, the data is all in the ARC and if you mmap > > > it they have to bcopy the data out of the ARC, into the page cache > > > and now they have a consistency problem, you could modify stuff > > > via mmap or write and they have to manage that. > > > > > > That consistency problem is the main reason that Sun almost completely > > > killed the buffer cache (it still was used for inodes and directories > > > but that was it). That consistency problem is a pain in the rear, > > > all sorts of race conditions and it tended to bit rot. > > > > > > Jeff and Bill are smart people so I suspect they got it right but I'm > > > still stunned that they took such an architecturally bad approach. > > > And even more stunned that the oversight people approved it. There > > > is zero chance that the Sun I worked at would have allowed that. > > > > > > --lm > > -- > --- > Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From lm at mcvoy.com Wed Aug 28 08:59:55 2019 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 27 Aug 2019 15:59:55 -0700 Subject: [TUHS] [SPAM] Re: If not Linux, then what? In-Reply-To: References: <20190827003013.GS13570@mcvoy.com> <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net> <20190827024511.GU13570@mcvoy.com> <20190827145556.GD13570@mcvoy.com> <20190827224002.GB15511@mcvoy.com> Message-ID: <20190827225955.GC15511@mcvoy.com> streams were OK but Dennis himself told me he didn't intend them for networking. They were a simple mechanism for pushing line disciplines onto tty drivers. I can't remember exactly what he said, this was back in ~1988 or so and I was talking to him about the STREAMS stuff. He wasn't very happy with it and I'm pretty sure he said something like streams weren't design to mux multiple sources or network connections. I think he sort of grudgingly gave credit that they made it work but he seemed to think that it was twisting streams more than they should be twisted. On Wed, Aug 28, 2019 at 08:46:35AM +1000, George Michaelson wrote: > oh maybe I meant "streams" not "STREAMS" I always got confused if the > original ritchie spec was upper or lower case. Charles Forsyth coded > it into the York Uni Vaxen, worked fine. I left shortly after to do > stuff at UCL, it only came back into my life when at UQ in Australia > we got an ICL "certified" SYSV host and along side dead technology > like RFS up it popped (I think ICL had coded an OSI stack we were > testing) > > -G > > On Wed, Aug 28, 2019 at 8:40 AM Larry McVoy wrote: > > > > Wait, are you arguing for STREAMS over sockets? Dear god, please no. > > Have you ever used STREAMS (not Ritchies streams, those were OK)? > > I have. I ported Lachman's STREAMS based TCP/IP stack twice, once > > to a long since defunct super computer called the ETA-10 and then > > to SCO Unix. I've got way more STREAMS experience than most people > > and I can tell you that sockets are WAY WAY better. I get the "it > > should have just been file I/O" except that I don't. I tried to > > write a library that let you open up /net/tcp/$host:$port and do > > I/O like it was a file descriptor. That works for a lot of stuff > > but I ran into problems quickly. A networking connection is not > > a file handle. You can make some stuff work but I couldn't figure > > out how to do all of it. You end up having to do ioctls to handle > > the stuff that doesn't fit well into the file system name space. > > I think plan 9 did this sort of thing, maybe Rob can prove me wrong > > or remember where it didn't match. > > > > I do know that STREAMS came back to Solaris, some VP inked a shitty > > deal with Lachman and bought the rights to the stack. It was slow > > as molasses in the winter and customers absolutely hated it. Sun > > got Mentat to redo it for perf but customers still hated it, they > > understood sockets, everyone else had sockets, they wanted sockets > > and they got them. Sun put them back and nobody ever asked about > > STREAMS again. > > > > On Wed, Aug 28, 2019 at 08:30:01AM +1000, George Michaelson wrote: > > > BSD, but with the original STREAMS semantics, not sockets. > > > > > > DARPA did us no favours accepting sockets in place of simple file I/O > > > semantics for networks. > > > > > > Newcastle connection put the namespace into > > > /.../remote-part/path/to/thing which I felt was also good. > > > > > > So for me, 7 -> BSD -> got worse for some values of worse > > > > > > On Wed, Aug 28, 2019 at 12:56 AM Larry McVoy wrote: > > > > > > > > On Mon, Aug 26, 2019 at 11:14:45PM -0400, Arthur Krewat wrote: > > > > > On 8/26/2019 10:45 PM, Larry McVoy wrote: > > > > > > Which was that the page cache is > > > > > >*the* cache. There is nothing else. > > > > > Yeah, I re-read what you wrote a few times after I replied, and realized > > > > > what you meant ... eventually ;) > > > > > > > > I might be making too big of a deal about it. mmap semantics mattered > > > > a lot when SMPs first showed up and main memory was small. It meant > > > > that you could have multiple CPUs seeing and working on the same chunk > > > > of data at the same time. > > > > > > > > It's very similar to way that IOMMUs are exposed to user space these > > > > days, enabling virtual machines direct access to the I/O devices. > > > > > > > > ZFS breaks that model, the data is all in the ARC and if you mmap > > > > it they have to bcopy the data out of the ARC, into the page cache > > > > and now they have a consistency problem, you could modify stuff > > > > via mmap or write and they have to manage that. > > > > > > > > That consistency problem is the main reason that Sun almost completely > > > > killed the buffer cache (it still was used for inodes and directories > > > > but that was it). That consistency problem is a pain in the rear, > > > > all sorts of race conditions and it tended to bit rot. > > > > > > > > Jeff and Bill are smart people so I suspect they got it right but I'm > > > > still stunned that they took such an architecturally bad approach. > > > > And even more stunned that the oversight people approved it. There > > > > is zero chance that the Sun I worked at would have allowed that. > > > > > > > > --lm > > > > -- > > --- > > Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From clemc at ccc.com Wed Aug 28 09:10:03 2019 From: clemc at ccc.com (Clem Cole) Date: Tue, 27 Aug 2019 19:10:03 -0400 Subject: [TUHS] If not Linux, then what? In-Reply-To: <20190827225955.GC15511@mcvoy.com> References: <20190827003013.GS13570@mcvoy.com> <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net> <20190827024511.GU13570@mcvoy.com> <20190827145556.GD13570@mcvoy.com> <20190827224002.GB15511@mcvoy.com> <20190827225955.GC15511@mcvoy.com> Message-ID: I had a similar conversation btw. I liked what Dennis did to clean up the tty handler but I agree as a networking interface it was wretched which is what system v did. At stellar we put in the bbn (walsh2) stack and spliced back in sockets so the bsd code still worked. That said the idea of trying to keep the everything is a file semantic was good and streams were closer. The problem sockets is they really were not quite The same. What I liked about plan 9 was breaking the control interface out so the file stuff stayed sane. But that was a bridge to far for a traditional Unix. On Tue, Aug 27, 2019 at 7:00 PM Larry McVoy wrote: > streams were OK but Dennis himself told me he didn't intend them for > networking. They were a simple mechanism for pushing line disciplines > onto tty drivers. > > I can't remember exactly what he said, this was back in ~1988 or so > and I was talking to him about the STREAMS stuff. He wasn't very > happy with it and I'm pretty sure he said something like streams > weren't design to mux multiple sources or network connections. > I think he sort of grudgingly gave credit that they made it work > but he seemed to think that it was twisting streams more than they > should be twisted. > > On Wed, Aug 28, 2019 at 08:46:35AM +1000, George Michaelson wrote: > > oh maybe I meant "streams" not "STREAMS" I always got confused if the > > original ritchie spec was upper or lower case. Charles Forsyth coded > > it into the York Uni Vaxen, worked fine. I left shortly after to do > > stuff at UCL, it only came back into my life when at UQ in Australia > > we got an ICL "certified" SYSV host and along side dead technology > > like RFS up it popped (I think ICL had coded an OSI stack we were > > testing) > > > > -G > > > > On Wed, Aug 28, 2019 at 8:40 AM Larry McVoy wrote: > > > > > > Wait, are you arguing for STREAMS over sockets? Dear god, please no. > > > Have you ever used STREAMS (not Ritchies streams, those were OK)? > > > I have. I ported Lachman's STREAMS based TCP/IP stack twice, once > > > to a long since defunct super computer called the ETA-10 and then > > > to SCO Unix. I've got way more STREAMS experience than most people > > > and I can tell you that sockets are WAY WAY better. I get the "it > > > should have just been file I/O" except that I don't. I tried to > > > write a library that let you open up /net/tcp/$host:$port and do > > > I/O like it was a file descriptor. That works for a lot of stuff > > > but I ran into problems quickly. A networking connection is not > > > a file handle. You can make some stuff work but I couldn't figure > > > out how to do all of it. You end up having to do ioctls to handle > > > the stuff that doesn't fit well into the file system name space. > > > I think plan 9 did this sort of thing, maybe Rob can prove me wrong > > > or remember where it didn't match. > > > > > > I do know that STREAMS came back to Solaris, some VP inked a shitty > > > deal with Lachman and bought the rights to the stack. It was slow > > > as molasses in the winter and customers absolutely hated it. Sun > > > got Mentat to redo it for perf but customers still hated it, they > > > understood sockets, everyone else had sockets, they wanted sockets > > > and they got them. Sun put them back and nobody ever asked about > > > STREAMS again. > > > > > > On Wed, Aug 28, 2019 at 08:30:01AM +1000, George Michaelson wrote: > > > > BSD, but with the original STREAMS semantics, not sockets. > > > > > > > > DARPA did us no favours accepting sockets in place of simple file I/O > > > > semantics for networks. > > > > > > > > Newcastle connection put the namespace into > > > > /.../remote-part/path/to/thing which I felt was also good. > > > > > > > > So for me, 7 -> BSD -> got worse for some values of worse > > > > > > > > On Wed, Aug 28, 2019 at 12:56 AM Larry McVoy wrote: > > > > > > > > > > On Mon, Aug 26, 2019 at 11:14:45PM -0400, Arthur Krewat wrote: > > > > > > On 8/26/2019 10:45 PM, Larry McVoy wrote: > > > > > > > Which was that the page cache is > > > > > > >*the* cache. There is nothing else. > > > > > > Yeah, I re-read what you wrote a few times after I replied, and > realized > > > > > > what you meant ... eventually ;) > > > > > > > > > > I might be making too big of a deal about it. mmap semantics > mattered > > > > > a lot when SMPs first showed up and main memory was small. It > meant > > > > > that you could have multiple CPUs seeing and working on the same > chunk > > > > > of data at the same time. > > > > > > > > > > It's very similar to way that IOMMUs are exposed to user space > these > > > > > days, enabling virtual machines direct access to the I/O devices. > > > > > > > > > > ZFS breaks that model, the data is all in the ARC and if you mmap > > > > > it they have to bcopy the data out of the ARC, into the page cache > > > > > and now they have a consistency problem, you could modify stuff > > > > > via mmap or write and they have to manage that. > > > > > > > > > > That consistency problem is the main reason that Sun almost > completely > > > > > killed the buffer cache (it still was used for inodes and > directories > > > > > but that was it). That consistency problem is a pain in the rear, > > > > > all sorts of race conditions and it tended to bit rot. > > > > > > > > > > Jeff and Bill are smart people so I suspect they got it right but > I'm > > > > > still stunned that they took such an architecturally bad approach. > > > > > And even more stunned that the oversight people approved it. There > > > > > is zero chance that the Sun I worked at would have allowed that. > > > > > > > > > > --lm > > > > > > -- > > > --- > > > Larry McVoy lm at mcvoy.com > http://www.mcvoy.com/lm > > -- > --- > Larry McVoy lm at mcvoy.com > http://www.mcvoy.com/lm > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at bitblocks.com Wed Aug 28 09:16:18 2019 From: bakul at bitblocks.com (Bakul Shah) Date: Tue, 27 Aug 2019 16:16:18 -0700 Subject: [TUHS] If not Linux, then what? In-Reply-To: Your message of "Tue, 27 Aug 2019 15:40:02 -0700." <20190827224002.GB15511@mcvoy.com> References: <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com> <20190827003013.GS13570@mcvoy.com> <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net> <20190827024511.GU13570@mcvoy.com> <20190827145556.GD13570@mcvoy.com> <20190827224002.GB15511@mcvoy.com> Message-ID: <20190827231625.55E991570CEA@mail.bitblocks.com> On Tue, 27 Aug 2019 15:40:02 -0700 Larry McVoy wrote: Larry McVoy writes: > and I can tell you that sockets are WAY WAY better. I get the "it > should have just been file I/O" except that I don't. I tried to > write a library that let you open up /net/tcp/$host:$port and do > I/O like it was a file descriptor. That works for a lot of stuff > but I ran into problems quickly. A networking connection is not > a file handle. You can make some stuff work but I couldn't figure > out how to do all of it. You end up having to do ioctls to handle > the stuff that doesn't fit well into the file system name space. > I think plan 9 did this sort of thing, maybe Rob can prove me wrong > or remember where it didn't match. Plan9 does a decent enough job. cpu% ls /net/tcp /net/tcp/0 /net/tcp/1 /net/tcp/2 /net/tcp/clone /net/tcp/stats cpu% ls /net/tcp/1 /net/tcp/1/ctl /net/tcp/1/data /net/tcp/1/err /net/tcp/1/listen /net/tcp/1/local /net/tcp/1/remote /net/tcp/1/status cpu% cd /net/tcp/1 cpu% cat local remote 192.168.1.103!17010 192.168.1.11!52027 See http://doc.cat-v.org/plan_9/4th_edition/papers/net/ Replacing ioctls with writing ascii commands to ctl files was a significant improvement. For one thing you can do all this from a shell script. plan9 would've been a big improvement over *BSD or Linux. But I think a conceptual merge was needed between some sane version of Unix and plan9 so as to not throw out all the dusty decks. From lm at mcvoy.com Wed Aug 28 09:33:38 2019 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 27 Aug 2019 16:33:38 -0700 Subject: [TUHS] If not Linux, then what? In-Reply-To: <20190827231625.55E991570CEA@mail.bitblocks.com> References: <20190827003013.GS13570@mcvoy.com> <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net> <20190827024511.GU13570@mcvoy.com> <20190827145556.GD13570@mcvoy.com> <20190827224002.GB15511@mcvoy.com> <20190827231625.55E991570CEA@mail.bitblocks.com> Message-ID: <20190827233338.GM13570@mcvoy.com> On Tue, Aug 27, 2019 at 04:16:18PM -0700, Bakul Shah wrote: > On Tue, 27 Aug 2019 15:40:02 -0700 Larry McVoy wrote: > Larry McVoy writes: > > and I can tell you that sockets are WAY WAY better. I get the "it > > should have just been file I/O" except that I don't. I tried to > > write a library that let you open up /net/tcp/$host:$port and do > > I/O like it was a file descriptor. That works for a lot of stuff > > but I ran into problems quickly. A networking connection is not > > a file handle. You can make some stuff work but I couldn't figure > > out how to do all of it. You end up having to do ioctls to handle > > the stuff that doesn't fit well into the file system name space. > > I think plan 9 did this sort of thing, maybe Rob can prove me wrong > > or remember where it didn't match. > > Plan9 does a decent enough job. > > cpu% ls /net/tcp > /net/tcp/0 > /net/tcp/1 > /net/tcp/2 > /net/tcp/clone > /net/tcp/stats > > cpu% ls /net/tcp/1 > /net/tcp/1/ctl > /net/tcp/1/data > /net/tcp/1/err > /net/tcp/1/listen > /net/tcp/1/local > /net/tcp/1/remote > /net/tcp/1/status I dunno. I can't look at that and know what it means. So it means I have to toss (by the time this came out) a decade or more worth of knowing how to use sockets and learn this new model that may or may not go anywhere. > plan9 would've been a big improvement over *BSD or Linux. But > I think a conceptual merge was needed between some sane > version of Unix and plan9 so as to not throw out all the dusty > decks. That would have made a huge difference. The problem with Unix is it is largely good enough. All sorts of warts appeared over the years but you can get your job done. Plan 9 was such a big departure that it never gained traction. Having it conform to Posix or pick the most popular Unix (SunOS? BSD?) and conform to that. I'm biased but even if I wasn't I'd have picked SunOS, virtually all open source back in the day compiled out of the tarball on SunOS. Everyone else had to tinker or run configure or whatever. From ggm at algebras.org Wed Aug 28 10:07:30 2019 From: ggm at algebras.org (George Michaelson) Date: Wed, 28 Aug 2019 10:07:30 +1000 Subject: [TUHS] If not Linux, then what? In-Reply-To: References: <20190827003013.GS13570@mcvoy.com> <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net> <20190827024511.GU13570@mcvoy.com> <20190827145556.GD13570@mcvoy.com> <20190827224002.GB15511@mcvoy.com> <20190827225955.GC15511@mcvoy.com> Message-ID: At the time we are talking, almost all people were using serial line protocols, of some form, for point-to-point links. Ethernet was "new" and I think at one level, being a good (binary) tty/serial discipline was workable. Stacking things was possible was it not? And, the way I understand it, The code avoided data copying so was very very efficient across protocol stacks. I think it was capable of being improved. Sockets is now defined by standards. Its impossible to make it do things without huge cost. We're comparing now, with then.. always dangerous. -G On Wed, Aug 28, 2019 at 9:10 AM Clem Cole wrote: > > I had a similar conversation btw. I liked what Dennis did to clean up the tty handler but I agree as a networking interface it was wretched which is what system v did. At stellar we put in the bbn (walsh2) stack and spliced back in sockets so the bsd code still worked. > That said the idea of trying to keep the everything is a file semantic was good and streams were closer. The problem sockets is they really were not quite The same. > > What I liked about plan 9 was breaking the control interface out so the file stuff stayed sane. But that was a bridge to far for a traditional Unix. > > > On Tue, Aug 27, 2019 at 7:00 PM Larry McVoy wrote: >> >> streams were OK but Dennis himself told me he didn't intend them for >> networking. They were a simple mechanism for pushing line disciplines >> onto tty drivers. >> >> I can't remember exactly what he said, this was back in ~1988 or so >> and I was talking to him about the STREAMS stuff. He wasn't very >> happy with it and I'm pretty sure he said something like streams >> weren't design to mux multiple sources or network connections. >> I think he sort of grudgingly gave credit that they made it work >> but he seemed to think that it was twisting streams more than they >> should be twisted. >> >> On Wed, Aug 28, 2019 at 08:46:35AM +1000, George Michaelson wrote: >> > oh maybe I meant "streams" not "STREAMS" I always got confused if the >> > original ritchie spec was upper or lower case. Charles Forsyth coded >> > it into the York Uni Vaxen, worked fine. I left shortly after to do >> > stuff at UCL, it only came back into my life when at UQ in Australia >> > we got an ICL "certified" SYSV host and along side dead technology >> > like RFS up it popped (I think ICL had coded an OSI stack we were >> > testing) >> > >> > -G >> > >> > On Wed, Aug 28, 2019 at 8:40 AM Larry McVoy wrote: >> > > >> > > Wait, are you arguing for STREAMS over sockets? Dear god, please no. >> > > Have you ever used STREAMS (not Ritchies streams, those were OK)? >> > > I have. I ported Lachman's STREAMS based TCP/IP stack twice, once >> > > to a long since defunct super computer called the ETA-10 and then >> > > to SCO Unix. I've got way more STREAMS experience than most people >> > > and I can tell you that sockets are WAY WAY better. I get the "it >> > > should have just been file I/O" except that I don't. I tried to >> > > write a library that let you open up /net/tcp/$host:$port and do >> > > I/O like it was a file descriptor. That works for a lot of stuff >> > > but I ran into problems quickly. A networking connection is not >> > > a file handle. You can make some stuff work but I couldn't figure >> > > out how to do all of it. You end up having to do ioctls to handle >> > > the stuff that doesn't fit well into the file system name space. >> > > I think plan 9 did this sort of thing, maybe Rob can prove me wrong >> > > or remember where it didn't match. >> > > >> > > I do know that STREAMS came back to Solaris, some VP inked a shitty >> > > deal with Lachman and bought the rights to the stack. It was slow >> > > as molasses in the winter and customers absolutely hated it. Sun >> > > got Mentat to redo it for perf but customers still hated it, they >> > > understood sockets, everyone else had sockets, they wanted sockets >> > > and they got them. Sun put them back and nobody ever asked about >> > > STREAMS again. >> > > >> > > On Wed, Aug 28, 2019 at 08:30:01AM +1000, George Michaelson wrote: >> > > > BSD, but with the original STREAMS semantics, not sockets. >> > > > >> > > > DARPA did us no favours accepting sockets in place of simple file I/O >> > > > semantics for networks. >> > > > >> > > > Newcastle connection put the namespace into >> > > > /.../remote-part/path/to/thing which I felt was also good. >> > > > >> > > > So for me, 7 -> BSD -> got worse for some values of worse >> > > > >> > > > On Wed, Aug 28, 2019 at 12:56 AM Larry McVoy wrote: >> > > > > >> > > > > On Mon, Aug 26, 2019 at 11:14:45PM -0400, Arthur Krewat wrote: >> > > > > > On 8/26/2019 10:45 PM, Larry McVoy wrote: >> > > > > > > Which was that the page cache is >> > > > > > >*the* cache. There is nothing else. >> > > > > > Yeah, I re-read what you wrote a few times after I replied, and realized >> > > > > > what you meant ... eventually ;) >> > > > > >> > > > > I might be making too big of a deal about it. mmap semantics mattered >> > > > > a lot when SMPs first showed up and main memory was small. It meant >> > > > > that you could have multiple CPUs seeing and working on the same chunk >> > > > > of data at the same time. >> > > > > >> > > > > It's very similar to way that IOMMUs are exposed to user space these >> > > > > days, enabling virtual machines direct access to the I/O devices. >> > > > > >> > > > > ZFS breaks that model, the data is all in the ARC and if you mmap >> > > > > it they have to bcopy the data out of the ARC, into the page cache >> > > > > and now they have a consistency problem, you could modify stuff >> > > > > via mmap or write and they have to manage that. >> > > > > >> > > > > That consistency problem is the main reason that Sun almost completely >> > > > > killed the buffer cache (it still was used for inodes and directories >> > > > > but that was it). That consistency problem is a pain in the rear, >> > > > > all sorts of race conditions and it tended to bit rot. >> > > > > >> > > > > Jeff and Bill are smart people so I suspect they got it right but I'm >> > > > > still stunned that they took such an architecturally bad approach. >> > > > > And even more stunned that the oversight people approved it. There >> > > > > is zero chance that the Sun I worked at would have allowed that. >> > > > > >> > > > > --lm >> > > >> > > -- >> > > --- >> > > Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm >> >> -- >> --- >> Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm > > -- > Sent from a handheld expect more typos than usual From bakul at bitblocks.com Wed Aug 28 10:21:34 2019 From: bakul at bitblocks.com (Bakul Shah) Date: Tue, 27 Aug 2019 17:21:34 -0700 Subject: [TUHS] If not Linux, then what? In-Reply-To: Your message of "Tue, 27 Aug 2019 16:33:38 -0700." <20190827233338.GM13570@mcvoy.com> References: <20190827003013.GS13570@mcvoy.com> <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net> <20190827024511.GU13570@mcvoy.com> <20190827145556.GD13570@mcvoy.com> <20190827224002.GB15511@mcvoy.com> <20190827231625.55E991570CEA@mail.bitblocks.com> <20190827233338.GM13570@mcvoy.com> Message-ID: <20190828002141.40BE41570CE9@mail.bitblocks.com> On Tue, 27 Aug 2019 16:33:38 -0700 Larry McVoy wrote: Larry McVoy writes: > On Tue, Aug 27, 2019 at 04:16:18PM -0700, Bakul Shah wrote: > > On Tue, 27 Aug 2019 15:40:02 -0700 Larry McVoy wrote: > > Larry McVoy writes: > > > and I can tell you that sockets are WAY WAY better. I get the "it > > > should have just been file I/O" except that I don't. I tried to > > > write a library that let you open up /net/tcp/$host:$port and do > > > I/O like it was a file descriptor. That works for a lot of stuff > > > but I ran into problems quickly. A networking connection is not > > > a file handle. You can make some stuff work but I couldn't figure > > > out how to do all of it. You end up having to do ioctls to handle > > > the stuff that doesn't fit well into the file system name space. > > > I think plan 9 did this sort of thing, maybe Rob can prove me wrong > > > or remember where it didn't match. > > > > Plan9 does a decent enough job. > > > > cpu% ls /net/tcp > > /net/tcp/0 > > /net/tcp/1 > > /net/tcp/2 > > /net/tcp/clone > > /net/tcp/stats > > > > cpu% ls /net/tcp/1 > > /net/tcp/1/ctl > > /net/tcp/1/data > > /net/tcp/1/err > > /net/tcp/1/listen > > /net/tcp/1/local > > /net/tcp/1/remote > > /net/tcp/1/status > > I dunno. I can't look at that and know what it means. So it means I have Hence the link to Presotto and Winterbottom's paper. > to toss (by the time this came out) a decade or more worth of knowing how > to use sockets and learn this new model that may or may not go anywhere. It's a simper model. It is no big deal. I was intimately familiar with sockets and the BSD networking stack (worked in a router startup from the beginning where we rejiggered the FreeBSD network stack to support N forwarding tables, additional protocols, interface types etc. etc.). > > plan9 would've been a big improvement over *BSD or Linux. But > > I think a conceptual merge was needed between some sane > > version of Unix and plan9 so as to not throw out all the dusty > > decks. > > That would have made a huge difference. The problem with Unix is it > is largely good enough. All sorts of warts appeared over the years > but you can get your job done. Plan 9 was such a big departure that > it never gained traction. Having it conform to Posix or pick the > most popular Unix (SunOS? BSD?) and conform to that. I'm biased but > even if I wasn't I'd have picked SunOS, virtually all open source back > in the day compiled out of the tarball on SunOS. Everyone else had > to tinker or run configure or whatever. I believe not having to be compatible with Unix meant plan9 could evolve unimpeded. But IMHO it was not so far out that a merge would have been impossible. plan9 had "ape" (ansi/posix environment) for compiling posix compatible programs but that didn't go far enough. The result might've been a worse plan9 but a better Unix. The last version I used SunOS3.5 on a 4MB Sun 3/50. It was very nice in its day. Once I got a 386 (or was it 486) with 16MB of memory & BSD, the Sun machine saw less and less use. From krewat at kilonet.net Wed Aug 28 11:21:43 2019 From: krewat at kilonet.net (Arthur Krewat) Date: Tue, 27 Aug 2019 21:21:43 -0400 Subject: [TUHS] If not Linux, then what? In-Reply-To: <20190828002141.40BE41570CE9@mail.bitblocks.com> References: <20190827003013.GS13570@mcvoy.com> <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net> <20190827024511.GU13570@mcvoy.com> <20190827145556.GD13570@mcvoy.com> <20190827224002.GB15511@mcvoy.com> <20190827231625.55E991570CEA@mail.bitblocks.com> <20190827233338.GM13570@mcvoy.com> <20190828002141.40BE41570CE9@mail.bitblocks.com> Message-ID: In re: the socket() thing... I remember getting into something (forget what) back in the early 90's, writing something (again, I forget what) and realizing what I needed to do to open a socket to a remote endpoint. I remember thinking "wait, I can't just open("hostname:port", O_TCP); ???" And, horror of all horrors, I need to deal with little/big endian things? ntohs(), htons(), et al? jeez... :) art k. From lm at mcvoy.com Wed Aug 28 11:46:40 2019 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 27 Aug 2019 18:46:40 -0700 Subject: [TUHS] If not Linux, then what? In-Reply-To: References: <20190827024511.GU13570@mcvoy.com> <20190827145556.GD13570@mcvoy.com> <20190827224002.GB15511@mcvoy.com> <20190827231625.55E991570CEA@mail.bitblocks.com> <20190827233338.GM13570@mcvoy.com> <20190828002141.40BE41570CE9@mail.bitblocks.com> Message-ID: <20190828014640.GP13570@mcvoy.com> On Tue, Aug 27, 2019 at 09:21:43PM -0400, Arthur Krewat wrote: > In re: the socket() thing... > > I remember getting into something (forget what) back in the early 90's, > writing something (again, I forget what) and realizing what I needed to do > to open a socket to a remote endpoint. > > I remember thinking "wait, I can't just open("hostname:port", O_TCP); ???" So that part is fine. > And, horror of all horrors, I need to deal with little/big endian things? > ntohs(), htons(), et al? That part is reality. You can send ascii and then pay the price for parsing that or you can send binary. These days, we have CPU cycles to burn so the ascii answer seems fine. It is, mostly, it's not when it is tons of small messages that need to be processed at millions or billions/sec. In the past, CPU cycles were not a given so lots of stuff was designed to not be parsed. From robpike at gmail.com Wed Aug 28 13:22:33 2019 From: robpike at gmail.com (Rob Pike) Date: Wed, 28 Aug 2019 13:22:33 +1000 Subject: [TUHS] [SPAM] Re: If not Linux, then what? In-Reply-To: <20190827225955.GC15511@mcvoy.com> References: <20190827003013.GS13570@mcvoy.com> <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net> <20190827024511.GU13570@mcvoy.com> <20190827145556.GD13570@mcvoy.com> <20190827224002.GB15511@mcvoy.com> <20190827225955.GC15511@mcvoy.com> Message-ID: I find it hard to believe what you remember Dennis saying. The point of dmr's streams was to support networking research in the lab and avoid the myriad bugs of the mpx interface by stepping around them completely. Perhaps it's out of context. -rob On Wed, Aug 28, 2019 at 9:00 AM Larry McVoy wrote: > streams were OK but Dennis himself told me he didn't intend them for > networking. They were a simple mechanism for pushing line disciplines > onto tty drivers. > > I can't remember exactly what he said, this was back in ~1988 or so > and I was talking to him about the STREAMS stuff. He wasn't very > happy with it and I'm pretty sure he said something like streams > weren't design to mux multiple sources or network connections. > I think he sort of grudgingly gave credit that they made it work > but he seemed to think that it was twisting streams more than they > should be twisted. > > On Wed, Aug 28, 2019 at 08:46:35AM +1000, George Michaelson wrote: > > oh maybe I meant "streams" not "STREAMS" I always got confused if the > > original ritchie spec was upper or lower case. Charles Forsyth coded > > it into the York Uni Vaxen, worked fine. I left shortly after to do > > stuff at UCL, it only came back into my life when at UQ in Australia > > we got an ICL "certified" SYSV host and along side dead technology > > like RFS up it popped (I think ICL had coded an OSI stack we were > > testing) > > > > -G > > > > On Wed, Aug 28, 2019 at 8:40 AM Larry McVoy wrote: > > > > > > Wait, are you arguing for STREAMS over sockets? Dear god, please no. > > > Have you ever used STREAMS (not Ritchies streams, those were OK)? > > > I have. I ported Lachman's STREAMS based TCP/IP stack twice, once > > > to a long since defunct super computer called the ETA-10 and then > > > to SCO Unix. I've got way more STREAMS experience than most people > > > and I can tell you that sockets are WAY WAY better. I get the "it > > > should have just been file I/O" except that I don't. I tried to > > > write a library that let you open up /net/tcp/$host:$port and do > > > I/O like it was a file descriptor. That works for a lot of stuff > > > but I ran into problems quickly. A networking connection is not > > > a file handle. You can make some stuff work but I couldn't figure > > > out how to do all of it. You end up having to do ioctls to handle > > > the stuff that doesn't fit well into the file system name space. > > > I think plan 9 did this sort of thing, maybe Rob can prove me wrong > > > or remember where it didn't match. > > > > > > I do know that STREAMS came back to Solaris, some VP inked a shitty > > > deal with Lachman and bought the rights to the stack. It was slow > > > as molasses in the winter and customers absolutely hated it. Sun > > > got Mentat to redo it for perf but customers still hated it, they > > > understood sockets, everyone else had sockets, they wanted sockets > > > and they got them. Sun put them back and nobody ever asked about > > > STREAMS again. > > > > > > On Wed, Aug 28, 2019 at 08:30:01AM +1000, George Michaelson wrote: > > > > BSD, but with the original STREAMS semantics, not sockets. > > > > > > > > DARPA did us no favours accepting sockets in place of simple file I/O > > > > semantics for networks. > > > > > > > > Newcastle connection put the namespace into > > > > /.../remote-part/path/to/thing which I felt was also good. > > > > > > > > So for me, 7 -> BSD -> got worse for some values of worse > > > > > > > > On Wed, Aug 28, 2019 at 12:56 AM Larry McVoy wrote: > > > > > > > > > > On Mon, Aug 26, 2019 at 11:14:45PM -0400, Arthur Krewat wrote: > > > > > > On 8/26/2019 10:45 PM, Larry McVoy wrote: > > > > > > > Which was that the page cache is > > > > > > >*the* cache. There is nothing else. > > > > > > Yeah, I re-read what you wrote a few times after I replied, and > realized > > > > > > what you meant ... eventually ;) > > > > > > > > > > I might be making too big of a deal about it. mmap semantics > mattered > > > > > a lot when SMPs first showed up and main memory was small. It > meant > > > > > that you could have multiple CPUs seeing and working on the same > chunk > > > > > of data at the same time. > > > > > > > > > > It's very similar to way that IOMMUs are exposed to user space > these > > > > > days, enabling virtual machines direct access to the I/O devices. > > > > > > > > > > ZFS breaks that model, the data is all in the ARC and if you mmap > > > > > it they have to bcopy the data out of the ARC, into the page cache > > > > > and now they have a consistency problem, you could modify stuff > > > > > via mmap or write and they have to manage that. > > > > > > > > > > That consistency problem is the main reason that Sun almost > completely > > > > > killed the buffer cache (it still was used for inodes and > directories > > > > > but that was it). That consistency problem is a pain in the rear, > > > > > all sorts of race conditions and it tended to bit rot. > > > > > > > > > > Jeff and Bill are smart people so I suspect they got it right but > I'm > > > > > still stunned that they took such an architecturally bad approach. > > > > > And even more stunned that the oversight people approved it. There > > > > > is zero chance that the Sun I worked at would have allowed that. > > > > > > > > > > --lm > > > > > > -- > > > --- > > > Larry McVoy lm at mcvoy.com > http://www.mcvoy.com/lm > > -- > --- > Larry McVoy lm at mcvoy.com > http://www.mcvoy.com/lm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Wed Aug 28 13:25:52 2019 From: robpike at gmail.com (Rob Pike) Date: Wed, 28 Aug 2019 13:25:52 +1000 Subject: [TUHS] [SPAM] Re: If not Linux, then what? In-Reply-To: References: <20190827003013.GS13570@mcvoy.com> <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net> <20190827024511.GU13570@mcvoy.com> <20190827145556.GD13570@mcvoy.com> <20190827224002.GB15511@mcvoy.com> <20190827225955.GC15511@mcvoy.com> Message-ID: There are many things to dislike about sockets, but one of them - irrelevant now, perhaps, but hugely troublesome at the time - was the way they embedded the specific and peculiar behavior of Ethernet, such as accepting a connection before you know if it's authorized - into the networking interface. No other networking hardware worked like Ethernet at either the electrical or the software level, and yet here we are. I grump, I grump. -rob On Wed, Aug 28, 2019 at 1:22 PM Rob Pike wrote: > I find it hard to believe what you remember Dennis saying. The point of > dmr's streams was to support networking research in the lab and avoid the > myriad bugs of the mpx interface by stepping around them completely. > > Perhaps it's out of context. > > -rob > > > On Wed, Aug 28, 2019 at 9:00 AM Larry McVoy wrote: > >> streams were OK but Dennis himself told me he didn't intend them for >> networking. They were a simple mechanism for pushing line disciplines >> onto tty drivers. >> >> I can't remember exactly what he said, this was back in ~1988 or so >> and I was talking to him about the STREAMS stuff. He wasn't very >> happy with it and I'm pretty sure he said something like streams >> weren't design to mux multiple sources or network connections. >> I think he sort of grudgingly gave credit that they made it work >> but he seemed to think that it was twisting streams more than they >> should be twisted. >> >> On Wed, Aug 28, 2019 at 08:46:35AM +1000, George Michaelson wrote: >> > oh maybe I meant "streams" not "STREAMS" I always got confused if the >> > original ritchie spec was upper or lower case. Charles Forsyth coded >> > it into the York Uni Vaxen, worked fine. I left shortly after to do >> > stuff at UCL, it only came back into my life when at UQ in Australia >> > we got an ICL "certified" SYSV host and along side dead technology >> > like RFS up it popped (I think ICL had coded an OSI stack we were >> > testing) >> > >> > -G >> > >> > On Wed, Aug 28, 2019 at 8:40 AM Larry McVoy wrote: >> > > >> > > Wait, are you arguing for STREAMS over sockets? Dear god, please no. >> > > Have you ever used STREAMS (not Ritchies streams, those were OK)? >> > > I have. I ported Lachman's STREAMS based TCP/IP stack twice, once >> > > to a long since defunct super computer called the ETA-10 and then >> > > to SCO Unix. I've got way more STREAMS experience than most people >> > > and I can tell you that sockets are WAY WAY better. I get the "it >> > > should have just been file I/O" except that I don't. I tried to >> > > write a library that let you open up /net/tcp/$host:$port and do >> > > I/O like it was a file descriptor. That works for a lot of stuff >> > > but I ran into problems quickly. A networking connection is not >> > > a file handle. You can make some stuff work but I couldn't figure >> > > out how to do all of it. You end up having to do ioctls to handle >> > > the stuff that doesn't fit well into the file system name space. >> > > I think plan 9 did this sort of thing, maybe Rob can prove me wrong >> > > or remember where it didn't match. >> > > >> > > I do know that STREAMS came back to Solaris, some VP inked a shitty >> > > deal with Lachman and bought the rights to the stack. It was slow >> > > as molasses in the winter and customers absolutely hated it. Sun >> > > got Mentat to redo it for perf but customers still hated it, they >> > > understood sockets, everyone else had sockets, they wanted sockets >> > > and they got them. Sun put them back and nobody ever asked about >> > > STREAMS again. >> > > >> > > On Wed, Aug 28, 2019 at 08:30:01AM +1000, George Michaelson wrote: >> > > > BSD, but with the original STREAMS semantics, not sockets. >> > > > >> > > > DARPA did us no favours accepting sockets in place of simple file >> I/O >> > > > semantics for networks. >> > > > >> > > > Newcastle connection put the namespace into >> > > > /.../remote-part/path/to/thing which I felt was also good. >> > > > >> > > > So for me, 7 -> BSD -> got worse for some values of worse >> > > > >> > > > On Wed, Aug 28, 2019 at 12:56 AM Larry McVoy wrote: >> > > > > >> > > > > On Mon, Aug 26, 2019 at 11:14:45PM -0400, Arthur Krewat wrote: >> > > > > > On 8/26/2019 10:45 PM, Larry McVoy wrote: >> > > > > > > Which was that the page cache is >> > > > > > >*the* cache. There is nothing else. >> > > > > > Yeah, I re-read what you wrote a few times after I replied, and >> realized >> > > > > > what you meant ... eventually ;) >> > > > > >> > > > > I might be making too big of a deal about it. mmap semantics >> mattered >> > > > > a lot when SMPs first showed up and main memory was small. It >> meant >> > > > > that you could have multiple CPUs seeing and working on the same >> chunk >> > > > > of data at the same time. >> > > > > >> > > > > It's very similar to way that IOMMUs are exposed to user space >> these >> > > > > days, enabling virtual machines direct access to the I/O devices. >> > > > > >> > > > > ZFS breaks that model, the data is all in the ARC and if you mmap >> > > > > it they have to bcopy the data out of the ARC, into the page cache >> > > > > and now they have a consistency problem, you could modify stuff >> > > > > via mmap or write and they have to manage that. >> > > > > >> > > > > That consistency problem is the main reason that Sun almost >> completely >> > > > > killed the buffer cache (it still was used for inodes and >> directories >> > > > > but that was it). That consistency problem is a pain in the rear, >> > > > > all sorts of race conditions and it tended to bit rot. >> > > > > >> > > > > Jeff and Bill are smart people so I suspect they got it right but >> I'm >> > > > > still stunned that they took such an architecturally bad approach. >> > > > > And even more stunned that the oversight people approved it. >> There >> > > > > is zero chance that the Sun I worked at would have allowed that. >> > > > > >> > > > > --lm >> > > >> > > -- >> > > --- >> > > Larry McVoy lm at mcvoy.com >> http://www.mcvoy.com/lm >> >> -- >> --- >> Larry McVoy lm at mcvoy.com >> http://www.mcvoy.com/lm >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sauer at technologists.com Wed Aug 28 13:53:26 2019 From: sauer at technologists.com (Charles H. Sauer) Date: Tue, 27 Aug 2019 22:53:26 -0500 Subject: [TUHS] If not Linux, then what? In-Reply-To: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> Message-ID: <9544A973-31DA-49AF-B192-DE170530A8BD@technologists.com> I’m a bit taken aback by the trees (streams/sockets/file systems/paging and difficult people) of this discussion. The forest view seems clear: if not for Linux, Microsoft would have been even more dominant. If not for Microsoft mis-steps (Cairo, ME, Vista, …), Windows dominance would have been even stronger. If not for Steve Jobs return, Apple really would have cratered. Who besides Apple and Linux (including Android) have given Microsoft meaningful competition? The last couple of months or so I’ve been figuring out how to revive and sustain some early 90s PC hardware (not just JAWS but a also a slightly older ISA only i486DX2-50 machine). I’ve been making the machines multi boot a variety of environments: Windows 3.11 (with Mosaic and Netscape), Windows 95, NT 3.51 with the “new shell” (Win 95 Explorer), NEXTSTEP 3.3, Dell SVR4 2.2.1, and Red Had 5.2/6.2/7. For a “Unix person” my perspective may be unusual, but Win95/NT with new shell/Dell SVR4/Linux all seem preferable to my memory of the Unix systems I casually used when I was using those four predominantly. I helped lead AIX from 1982 to ’89 and Dell UNIX from ’89 to ’93. In ’93 I stepped away from Unix to work on Windows 95-based videoconferencing. From ’93 to ’96 I did very little with Unix. Starting in 1992, a friend endeavored to interest me in Linux, but I declined. Then in ’96 I joined a startup that was getting funding based on a prototype app based on PERL/mSQL/Apache/Linux. My task was to make the prototype a real product. My Linux advocate friend said to settle on either Slackware or Red Hat, favoring RPM, so I’ve used Red Hat/Fedora since then. But I also use Windows 10 and am composing this in TextEdit on macOS. I’ve tried the various BSD forks, other Linux distributions, OS/2, Palm OS, etc. but none of those have made me want to keep using them. Charlie > On Aug 26, 2019, at 6:13 PM, Arthur Krewat wrote: > > https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel > > Leaving licensing and copyright issues out of this mental exercise, what would we have now if it wasn't for Linux? Not what you'd WANT it to be, although that can add to the discussion, but what WOULD it be? > > I'm not asking as a proponent of Linux. If anything, I was dragged kicking and screaming into the current day and have begrudgingly ceded my server space to Linux. > > But if not for Linux, would it be BSD? A System V variant? Or (the horror) Windows NT? > > I do understand that this has been discussed on the list before. I think, however, it would make a good late-summer exercise. Or late winter depending on where you are :) > > art k. > -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 web: https://technologists.com/sauer/ Facebook/Google/Skype/Twitter: CharlesHSauer -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Wed Aug 28 14:05:40 2019 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 27 Aug 2019 21:05:40 -0700 Subject: [TUHS] [SPAM] Re: If not Linux, then what? In-Reply-To: References: <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net> <20190827024511.GU13570@mcvoy.com> <20190827145556.GD13570@mcvoy.com> <20190827224002.GB15511@mcvoy.com> <20190827225955.GC15511@mcvoy.com> Message-ID: <20190828040540.GT13570@mcvoy.com> I could be wrong but that's my memory. What he told me was streams was for line disciplines for tty drivers. That's what I know but you were there, I was not. I'm pretty confused because what Dennis said to me was that he did not think streams would work for networking, he thought they made sense for a stream but not for a networking connection because that had multiple connections coming up through a stream. I'm happy to be wrong but can you talk more about what he was thinking? There is no way that I'm saying you are wrong, you are you, I just want to learn. If there is a way that streams made sense for networking I'd like to see that. My experience with STREAMS is that they sucked really hard for networking. My guess is I need to go learn about mpx, I don't know that. On Wed, Aug 28, 2019 at 01:22:33PM +1000, Rob Pike wrote: > I find it hard to believe what you remember Dennis saying. The point of > dmr's streams was to support networking research in the lab and avoid the > myriad bugs of the mpx interface by stepping around them completely. > > Perhaps it's out of context. > > -rob > > > On Wed, Aug 28, 2019 at 9:00 AM Larry McVoy wrote: > > > streams were OK but Dennis himself told me he didn't intend them for > > networking. They were a simple mechanism for pushing line disciplines > > onto tty drivers. > > > > I can't remember exactly what he said, this was back in ~1988 or so > > and I was talking to him about the STREAMS stuff. He wasn't very > > happy with it and I'm pretty sure he said something like streams > > weren't design to mux multiple sources or network connections. > > I think he sort of grudgingly gave credit that they made it work > > but he seemed to think that it was twisting streams more than they > > should be twisted. > > > > On Wed, Aug 28, 2019 at 08:46:35AM +1000, George Michaelson wrote: > > > oh maybe I meant "streams" not "STREAMS" I always got confused if the > > > original ritchie spec was upper or lower case. Charles Forsyth coded > > > it into the York Uni Vaxen, worked fine. I left shortly after to do > > > stuff at UCL, it only came back into my life when at UQ in Australia > > > we got an ICL "certified" SYSV host and along side dead technology > > > like RFS up it popped (I think ICL had coded an OSI stack we were > > > testing) > > > > > > -G > > > > > > On Wed, Aug 28, 2019 at 8:40 AM Larry McVoy wrote: > > > > > > > > Wait, are you arguing for STREAMS over sockets? Dear god, please no. > > > > Have you ever used STREAMS (not Ritchies streams, those were OK)? > > > > I have. I ported Lachman's STREAMS based TCP/IP stack twice, once > > > > to a long since defunct super computer called the ETA-10 and then > > > > to SCO Unix. I've got way more STREAMS experience than most people > > > > and I can tell you that sockets are WAY WAY better. I get the "it > > > > should have just been file I/O" except that I don't. I tried to > > > > write a library that let you open up /net/tcp/$host:$port and do > > > > I/O like it was a file descriptor. That works for a lot of stuff > > > > but I ran into problems quickly. A networking connection is not > > > > a file handle. You can make some stuff work but I couldn't figure > > > > out how to do all of it. You end up having to do ioctls to handle > > > > the stuff that doesn't fit well into the file system name space. > > > > I think plan 9 did this sort of thing, maybe Rob can prove me wrong > > > > or remember where it didn't match. > > > > > > > > I do know that STREAMS came back to Solaris, some VP inked a shitty > > > > deal with Lachman and bought the rights to the stack. It was slow > > > > as molasses in the winter and customers absolutely hated it. Sun > > > > got Mentat to redo it for perf but customers still hated it, they > > > > understood sockets, everyone else had sockets, they wanted sockets > > > > and they got them. Sun put them back and nobody ever asked about > > > > STREAMS again. > > > > > > > > On Wed, Aug 28, 2019 at 08:30:01AM +1000, George Michaelson wrote: > > > > > BSD, but with the original STREAMS semantics, not sockets. > > > > > > > > > > DARPA did us no favours accepting sockets in place of simple file I/O > > > > > semantics for networks. > > > > > > > > > > Newcastle connection put the namespace into > > > > > /.../remote-part/path/to/thing which I felt was also good. > > > > > > > > > > So for me, 7 -> BSD -> got worse for some values of worse > > > > > > > > > > On Wed, Aug 28, 2019 at 12:56 AM Larry McVoy wrote: > > > > > > > > > > > > On Mon, Aug 26, 2019 at 11:14:45PM -0400, Arthur Krewat wrote: > > > > > > > On 8/26/2019 10:45 PM, Larry McVoy wrote: > > > > > > > > Which was that the page cache is > > > > > > > >*the* cache. There is nothing else. > > > > > > > Yeah, I re-read what you wrote a few times after I replied, and > > realized > > > > > > > what you meant ... eventually ;) > > > > > > > > > > > > I might be making too big of a deal about it. mmap semantics > > mattered > > > > > > a lot when SMPs first showed up and main memory was small. It > > meant > > > > > > that you could have multiple CPUs seeing and working on the same > > chunk > > > > > > of data at the same time. > > > > > > > > > > > > It's very similar to way that IOMMUs are exposed to user space > > these > > > > > > days, enabling virtual machines direct access to the I/O devices. > > > > > > > > > > > > ZFS breaks that model, the data is all in the ARC and if you mmap > > > > > > it they have to bcopy the data out of the ARC, into the page cache > > > > > > and now they have a consistency problem, you could modify stuff > > > > > > via mmap or write and they have to manage that. > > > > > > > > > > > > That consistency problem is the main reason that Sun almost > > completely > > > > > > killed the buffer cache (it still was used for inodes and > > directories > > > > > > but that was it). That consistency problem is a pain in the rear, > > > > > > all sorts of race conditions and it tended to bit rot. > > > > > > > > > > > > Jeff and Bill are smart people so I suspect they got it right but > > I'm > > > > > > still stunned that they took such an architecturally bad approach. > > > > > > And even more stunned that the oversight people approved it. There > > > > > > is zero chance that the Sun I worked at would have allowed that. > > > > > > > > > > > > --lm > > > > > > > > -- > > > > --- > > > > Larry McVoy lm at mcvoy.com > > http://www.mcvoy.com/lm > > > > -- > > --- > > Larry McVoy lm at mcvoy.com > > http://www.mcvoy.com/lm > > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From jsteve at superglobalmegacorp.com Wed Aug 28 14:22:51 2019 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Wed, 28 Aug 2019 12:22:51 +0800 Subject: [TUHS] Running v10 In-Reply-To: References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com> <20190827003013.GS13570@mcvoy.com> <20190827160559.GA92491@indra.papnet.eu> Message-ID: I don’t recall their being detailed installation instructions like v8/v9. I never noticed the vax boot stuff as it was buried in the tree. It’s possible that it’s buildable. Or it could be incomplete like the Mach 2.5 VAX missing system headers…. I guess it’s worth trying on whatever should be the parallel BSD system if it’s like v8/v9 which needed a BSD machine to bootstrap. From: Henry Bent Sent: Wednesday, August 28, 2019 12:28 AM To: Angelo Papenhoff Cc: TUHS main list Subject: Re: [TUHS] Running v10 On Tue, 27 Aug 2019 at 12:12, Angelo Papenhoff wrote: Did anyone try to get v10 running in simh yet? It's been public for a while now and while we have two blit emulators already I haven't seen v10 alive yet. I have to admit I haven't tried to get it running myself either. After a brief look at the boot and config sources it appears as though there is support for the MicroVAX II which SIMH supports and I have used.  Is there an environment which is preferred for building the V10 source tree?  4.3BSD?  V8?  Something else? -Henry On 27/08/19, Rob Pike wrote: > I always thought Research 10th Edition was fantastic. Even the 8th edition > was an improvement on most of its successors. But things flowed another > way, with muddy streams mixing in. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsteve at superglobalmegacorp.com Wed Aug 28 14:30:02 2019 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Wed, 28 Aug 2019 12:30:02 +0800 Subject: [TUHS] If not Linux, then what? In-Reply-To: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> Message-ID: <64d347fc-23cf-45db-8153-fc80e312c0c6@PU1APC01FT003.eop-APC01.prod.protection.outlook.com> Maybe that plan B of GNU using the 4.4BSD lite kernel would have gained traction and you would have seen a GNU BSD vs NetBSD thing. I can’t see it though gaining the kind of traction Linux got as it was all so cloistered. Much like how GNU Mach never caught on or moved despite having a NetBSD port (Lites) to it. The killer feature should have been SMP which was available early on in Mach, although it seems that the MPS 1.0 stuff didn’t work well enough or by the time 1.1 caught on it just wasn’t good enough. I think the development model of Linux is what really drove it, just like how EGCS eclipsed GCC. The other crazy thing that hits me is that no Linux means no Caldera which means no Caldera 32v license being set free...  From: Arthur Krewat Sent: Tuesday, August 27, 2019 7:14 AM To: TUHS main list Subject: [TUHS] If not Linux, then what? https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel Leaving licensing and copyright issues out of this mental exercise, what would we have now if it wasn't for Linux? Not what you'd WANT it to be, although that can add to the discussion, but what WOULD it be? I'm not asking as a proponent of Linux. If anything, I was dragged kicking and screaming into the current day and have begrudgingly ceded my server space to Linux. But if not for Linux, would it be BSD? A System V variant? Or (the horror) Windows NT? I do understand that this has been discussed on the list before. I think, however, it would make a good late-summer exercise. Or late winter depending on where you are :) art k. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wobblygong at gmail.com Wed Aug 28 16:19:21 2019 From: wobblygong at gmail.com (Wesley Parish) Date: Wed, 28 Aug 2019 18:19:21 +1200 Subject: [TUHS] If not Linux, then what? In-Reply-To: References: <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com> <20190827003013.GS13570@mcvoy.com> <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net> <20190827024511.GU13570@mcvoy.com> <20190827145556.GD13570@mcvoy.com> <20190827224002.GB15511@mcvoy.com> Message-ID: Speaking of OSI stacks, I know 4.4BSD Lite came with some fragments of one. OSI's dead and hardly mourned these days, but did anyone in the Unix world ever get beyond the 4.4BSD fragmentary implementation? Wesley Parish On 8/28/19, George Michaelson wrote: > oh maybe I meant "streams" not "STREAMS" I always got confused if the > original ritchie spec was upper or lower case. Charles Forsyth coded > it into the York Uni Vaxen, worked fine. I left shortly after to do > stuff at UCL, it only came back into my life when at UQ in Australia > we got an ICL "certified" SYSV host and along side dead technology > like RFS up it popped (I think ICL had coded an OSI stack we were > testing) > > -G > < snip > From peter at rulingia.com Wed Aug 28 16:30:45 2019 From: peter at rulingia.com (Peter Jeremy) Date: Wed, 28 Aug 2019 16:30:45 +1000 Subject: [TUHS] If not Linux, then what? In-Reply-To: References: <20190827003013.GS13570@mcvoy.com> <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net> <20190827024511.GU13570@mcvoy.com> <20190827145556.GD13570@mcvoy.com> <20190827224002.GB15511@mcvoy.com> Message-ID: <20190828063045.GE75146@server.rulingia.com> On 2019-Aug-28 18:19:21 +1200, Wesley Parish wrote: >Speaking of OSI stacks, I know 4.4BSD Lite came with some fragments of >one. OSI's dead and hardly mourned these days, but did anyone in the >Unix world ever get beyond the 4.4BSD fragmentary implementation? There was ISODE (https://en.wikipedia.org/wiki/ISO_Development_Environment). I recall experimenting with it but didn't actually use it in anger. I know that DEC/Compaq/HP Tru64 Unix (nee OSF/1) came with a OSI stack - we had customers who wanted/used FTAM and I was surprised to find it came with the OS. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From aap at papnet.eu Wed Aug 28 17:34:00 2019 From: aap at papnet.eu (Angelo Papenhoff) Date: Wed, 28 Aug 2019 09:34:00 +0200 Subject: [TUHS] Running v10 In-Reply-To: References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com> <20190827003013.GS13570@mcvoy.com> <20190827160559.GA92491@indra.papnet.eu> Message-ID: <20190828073400.GA30049@indra.papnet.eu> On 28/08/19, Jason Stevens wrote: > I don’t recall their being detailed installation instructions like v8/v9. I never noticed the vax boot stuff as it was buried in the tree. It’s possible that it’s buildable. Or it could be incomplete like the Mach 2.5 VAX missing system headers…. > > I guess it’s worth trying on whatever should be the parallel BSD system if it’s like v8/v9 which needed a BSD machine to bootstrap. Check out "Setting Up a Research UNIX System" by Norman Wilson. troff sources are in v10. aap From pnr at planet.nl Wed Aug 28 19:17:08 2019 From: pnr at planet.nl (Paul Ruizendaal) Date: Wed, 28 Aug 2019 11:17:08 +0200 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] Message-ID: <5467B5A6-B084-424E-9493-52D7F03E4074@planet.nl> > I find it hard to believe what you remember Dennis saying. The point of > dmr's streams was to support networking research in the lab and avoid the > myriad bugs of the mpx interface by stepping around them completely. > > Perhaps it's out of context. > > -rob > I could be wrong but that's my memory. What he told me was streams was > for line disciplines for tty drivers. That's what I know but you were > there, I was not. I'm pretty confused because what Dennis said to me > was that he did not think streams would work for networking, he thought > they made sense for a stream but not for a networking connection because > that had multiple connections coming up through a stream. There is some contemporary material that gives a bit of context. The quotes are a bit contradictory and perhaps reflect evolving views. [1] The original dmr paper (1984) on streams (http://cm.bell-labs.co/who/dmr/st.html) seems to support the no networking view, focussing on terminal handling in its discussion. Also, near the end it says: "Streams are linear connections; by themselves, they support no notion of multiplexing, fan-in or fan-out. [...] It seems likely that a general multiplexing mechanism could help in both cases, but again, I do not yet know how to design it.” This seems to exclude usage for networking, which is typically multiplexed. [2] However, now that the V8 sources are available it is clear that the streams mechanism was used (by dmr?) to implement TCP/IP networking. He explains how that tallies with the above quote on multiplexing in a 1985 usenet post: https://groups.google.com/forum/#!topicsearchin/net.unix-wizards/subject$3Astreams/net.unix-wizards/b7W_j_0qASU The config files in the surviving TUHS V8 source tree actually match with the setup that dmr described in the penultimate paragraph. If the post by dmr does not immediately appear, click on the 8-10-85 post by 'd... at dutoit.uucp’ to make it fold out. For ease of reference, I’m including the message text below. Steven J. Langdon claimed that without multiplexing one couldn't do a proper kernel-resident version of TCP/IP in the V8 stream context. Here's how it's done. It is still true in our system that stream multiplexing does not occur, in the sense that every stream connection has (from the point of view of the formal data structures) exactly two ends, one at a user process, and the other at a device or another process. However, this has, in practice, not turned out to be a problem. Say you have a hardware device that hands you packets with a channel (or socket) number buried inside in some complicated format. The general scheme to handle the situation uses both a line discipline (stream filter module) and associated code that, to the system, looks like a stream device driver with several minor devices; these have entries in /dev. A watchdog process opens the underlying real device, and pushes the stream module. Arriving packets from the real device are passed to this module, where they are analyzed, and then given to the appropriate associated pseudo-device. Likewise, messages written on the pseudo-device are shunted over to the line discipline, where they are encoded appropriately and sent to the real device. This is where the multiplexing-demultiplexing occurs; formally, it is outside of the stream structure, because the data-passing doesn't follow the forward and backward links of the stream modules. However, the interfaces of the combined larger module obey stream rules. For example, IP works this way: The IP line discipline looks at the type field of data arriving from the device, and determines whether the packet is TCP or UDP or ARP or whatever, and shunts it off to the stream associated with /dev/ip6 or /dev/ip17 or whatever the numbers are. TCP, of course, is multiplexed as well. So there is a TCP line discipline, and a bunch of TCP devices; a watchdog process opens /dev/ip6, and pushes the TCP line discipline; then the TCP packets it gets are parcelled out to the appropriate /dev/tcpXX device. Each TCP device looks like the end of a stream, and may, of course, have other modules (e.g. tty processor) inserted in this stream. UDP sits on top of IP in the same way. This example is complicated, because (TCP,UDP)/IP is. However, it works well. In particular, the underlying real device can be either an ethernet or our own Datakit network; the software doesn't care. For example, from my machine, I can type "rlogin purdy" and connect to a Sequent machine running 4.2; the TCP connection goes over Datakit to machine "research" where it is gatewayed to a local ethernet that purdy is connected to. A further generalization (that we haven't made) is in principle easy: there can be protocol suites other than IP on an Ethernet cable. So there could be another layer to separate IP from XNS from Chaosnet, etc. Dennis Ritchie Maybe the subtle notion expressed as "formally, it is outside of the stream structure, because the data-passing doesn't follow the forward and backward links of the stream modules. However, the interfaces of the combined larger module obey stream rules” explains how dmr could talk about streams as being just suitable for line disciplines without meaning to say that they did not have good use in networking. Paul From angus at fairhaven.za.net Wed Aug 28 19:36:54 2019 From: angus at fairhaven.za.net (Angus Robinson) Date: Wed, 28 Aug 2019 11:36:54 +0200 Subject: [TUHS] If not Linux, then what? In-Reply-To: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> Message-ID: Interesting question, the alternative OS would have had to have had a good leader and I am sure maybe RMS would have created a kernel after some time. Maybe somebody would have taken 386BSD/FreeBSD/NetBSD and made something completely different. I think another question would be, if Linux was never invented, what technologies would never have happened. For instance, a bunch of animation movies where made with Linux farms, Planes use Linux within their inbuilt entertainment systems, the list goes on (I think NASA uses linux on their ISS). How many people would be interested in technology/IT sector, how many companies would have started (ie: RedHat, Thwat,etc), What features/addons would not have been added to other operating systems (Windows tcp/ip)? Would docker even be a thing, hyper-v ? I know one thing....... All the old technology would be alot more and schools would have alot more vunerabilites on their PC's. On Tue, Aug 27, 2019 at 1:13 AM Arthur Krewat wrote: > > https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel > > Leaving licensing and copyright issues out of this mental exercise, what > would we have now if it wasn't for Linux? Not what you'd WANT it to be, > although that can add to the discussion, but what WOULD it be? > > I'm not asking as a proponent of Linux. If anything, I was dragged > kicking and screaming into the current day and have begrudgingly ceded > my server space to Linux. > > But if not for Linux, would it be BSD? A System V variant? Or (the > horror) Windows NT? > > I do understand that this has been discussed on the list before. I > think, however, it would make a good late-summer exercise. Or late > winter depending on where you are :) > > art k. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at kjorling.se Wed Aug 28 19:50:59 2019 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Wed, 28 Aug 2019 09:50:59 +0000 Subject: [TUHS] If not Linux, then what? In-Reply-To: References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> Message-ID: <20190828095059.GA10799@h-178-80.A328.priv.bahnhof.se> On 28 Aug 2019 11:36 +0200, from angus at fairhaven.za.net (Angus Robinson): > I think another question would be, if Linux was never invented, what > technologies would never have happened. I think that if there is a need to be filled, then something will fill that need. In our timeline, in plenty of cases that need ended up being filled by Linux -- quite possibly not in least part because it's there, it's cheap, it's reasonably well-supported, and it can be modified and extended by end users relatively easily. However, absent Linux, as long as the task still needed to be done, _something else_ would have filled the need at some point. Plenty of people got interested in the technology/information technology sector well before Linux. Maybe Linux offered a venue for some of those people to _express_ their interest, but I have a hard time seeing why Linux would be a prerequisite. On another note, and to get back to the original question, I'm a little surprised that nobody here seems to have mentioned something like an outgrowth of Minix. -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “The most dangerous thought that you can have as a creative person is to think you know what you’re doing.” (Bret Victor) From aap at papnet.eu Wed Aug 28 20:44:59 2019 From: aap at papnet.eu (Angelo Papenhoff) Date: Wed, 28 Aug 2019 12:44:59 +0200 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: <5467B5A6-B084-424E-9493-52D7F03E4074@planet.nl> References: <5467B5A6-B084-424E-9493-52D7F03E4074@planet.nl> Message-ID: <20190828104459.GA7483@indra.papnet.eu> On 28/08/19, Paul Ruizendaal wrote: > > There is some contemporary material that gives a bit of context. The quotes are a bit contradictory and perhaps reflect evolving views. > > [1] > > The original dmr paper (1984) on streams (http://cm.bell-labs.co/who/dmr/st.html) seems to support the no networking view, focussing on terminal handling in its discussion. Also, near the end it says: "Streams are linear connections; by themselves, they support no notion of multiplexing, fan-in or fan-out. [...] It seems likely that a general multiplexing mechanism could help in both cases, but again, I do not yet know how to design it.” This seems to exclude usage for networking, which is typically multiplexed. > > [2] > > However, now that the V8 sources are available it is clear that the streams mechanism was used (by dmr?) to implement TCP/IP networking. He explains how that tallies with the above quote on multiplexing in a 1985 usenet post: https://groups.google.com/forum/#!topicsearchin/net.unix-wizards/subject$3Astreams/net.unix-wizards/b7W_j_0qASU > The config files in the surviving TUHS V8 source tree actually match with the setup that dmr described in the penultimate paragraph. > Something else I found interesting is in v8's blit/Road.map: "Next, operating systems. We run under Berkeley 4.1bsd or Dennis Ritchie's stacked line-discipline system." That sounds to me like an early v8. If not, what was it? I'm really interested in the timeline here. How long was research running on a PDP-11 and when did they move to a VAX? aap From arnold at skeeve.com Wed Aug 28 20:48:33 2019 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 28 Aug 2019 04:48:33 -0600 Subject: [TUHS] If not Linux, then what? In-Reply-To: <20190828095059.GA10799@h-178-80.A328.priv.bahnhof.se> References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <20190828095059.GA10799@h-178-80.A328.priv.bahnhof.se> Message-ID: <201908281048.x7SAmXr7009628@freefriends.org> Michael Kjörling wrote: > On another note, and to get back to the original question, I'm a > little surprised that nobody here seems to have mentioned something > like an outgrowth of Minix. Hoo boy. You can thank Andy Tannenbaum that we have Linux in the first place (almost). Linus used Minix as his development environment and early versions supported the Minix filesystem. I can't cite sources, but as I remember it, at the time (AT&T law suit) a number of people turned to Tannenbaum to get him to open source Minix and let people make it a "real" OS (VM, 386 support, etc.). He wasn't interested. He only cared about teaching and he wanted to maintain control over it. (Eventually it grew anyway, but only long after.) If he'd been more open, things might have indeed gone that way. This brings up that there were other maybe viable candidates in the research world: Sprite at UCB and Tannenbaum's Ameoba. But it seems that those were mainly vehicles to get papers published and didn't spread beyond their home universities. At some point I got a CD with all the Sprite sources. Maybe I can find that and get it to Warren. Arnold From jsteve at superglobalmegacorp.com Wed Aug 28 21:05:11 2019 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Wed, 28 Aug 2019 19:05:11 +0800 Subject: [TUHS] If not Linux, then what? In-Reply-To: <20190828063045.GE75146@server.rulingia.com> References: <20190828063045.GE75146@server.rulingia.com> Message-ID: I have OSF/1 1.0 running on gxemul … Any idea on where/ how to configure OSI? OSF/1 Release 1 (OSFMIPS) console login: root Last login: Thu Aug 29 06:03:07 on console DEC OSF/1 V1.0 (Rev. 166); Sun Jun 07 19:23:34 CDT 1970 DEC OSF/1 V1.0 Worksystem Software (Rev. 161) # find / -name 'osi*' -print # From: Peter Jeremy Sent: Wednesday, August 28, 2019 2:47 PM To: Wesley Parish Cc: TUHS main list Subject: Re: [TUHS] If not Linux, then what? On 2019-Aug-28 18:19:21 +1200, Wesley Parish wrote: >Speaking of OSI stacks, I know 4.4BSD Lite came with some fragments of >one. OSI's dead and hardly mourned these days, but did anyone in the >Unix world ever get beyond the 4.4BSD fragmentary implementation? There was ISODE (https://en.wikipedia.org/wiki/ISO_Development_Environment). I recall experimenting with it but didn't actually use it in anger. I know that DEC/Compaq/HP Tru64 Unix (nee OSF/1) came with a OSI stack - we had customers who wanted/used FTAM and I was surprised to find it came with the OS. -- Peter Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: From arrigo at alchemistowl.org Wed Aug 28 21:11:18 2019 From: arrigo at alchemistowl.org (Arrigo Triulzi) Date: Wed, 28 Aug 2019 13:11:18 +0200 Subject: [TUHS] If not Linux, then what? In-Reply-To: References: <20190828063045.GE75146@server.rulingia.com> Message-ID: On 28 Aug 2019, at 13:05, Jason Stevens wrote: > I have OSF/1 1.0 running on gxemul … > > Any idea on where/ how to configure OSI? I am not entirely sure it was already available on 1.0, it was around on 2.0. You got OSI via the "DECnet Plus OSI” and I seem to recall needing a PAK for it. eolo:~/sys/PAKs/PAKs-DECcampus/paks_unix$ ls *osi* decnet-osi-end decnet-osi-ext :) Arrigo From imp at bsdimp.com Wed Aug 28 22:46:41 2019 From: imp at bsdimp.com (Warner Losh) Date: Wed, 28 Aug 2019 06:46:41 -0600 Subject: [TUHS] If not Linux, then what? In-Reply-To: References: <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com> <20190827003013.GS13570@mcvoy.com> <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net> <20190827024511.GU13570@mcvoy.com> <20190827145556.GD13570@mcvoy.com> <20190827224002.GB15511@mcvoy.com> Message-ID: On Wed, Aug 28, 2019, 12:19 AM Wesley Parish wrote: > Speaking of OSI stacks, I know 4.4BSD Lite came with some fragments of > one. OSI's dead and hardly mourned these days, but did anyone in the > Unix world ever get beyond the 4.4BSD fragmentary implementation? > The Wollongong Group has OSI for various flavors of Sustem V and System III running on the 3B* family, 386 and a few others. I recall setting them up for interop in the summer of 1989. Warner Wesley Parish > > > On 8/28/19, George Michaelson wrote: > > oh maybe I meant "streams" not "STREAMS" I always got confused if the > > original ritchie spec was upper or lower case. Charles Forsyth coded > > it into the York Uni Vaxen, worked fine. I left shortly after to do > > stuff at UCL, it only came back into my life when at UQ in Australia > > we got an ICL "certified" SYSV host and along side dead technology > > like RFS up it popped (I think ICL had coded an OSI stack we were > > testing) > > > > -G > > > < snip > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Aug 28 23:52:42 2019 From: clemc at ccc.com (Clem Cole) Date: Wed, 28 Aug 2019 09:52:42 -0400 Subject: [TUHS] [SPAM] Re: If not Linux, then what? In-Reply-To: <20190828040540.GT13570@mcvoy.com> References: <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net> <20190827024511.GU13570@mcvoy.com> <20190827145556.GD13570@mcvoy.com> <20190827224002.GB15511@mcvoy.com> <20190827225955.GC15511@mcvoy.com> <20190828040540.GT13570@mcvoy.com> Message-ID: On Wed, Aug 28, 2019 at 12:06 AM Larry McVoy wrote: > I could be wrong but that's my memory. What he told me was streams was > for line disciplines for tty drivers. > Rob - this syncs with what Dennis I had talked about too *i.e.* Using streams for the serial interface; as the line disciplines stuff was a mess by that point. I cannt say I remember talking to him about using streams for networking. But I will say, I did agree that when we looked later at Stellar; but stuck with using sockets. This was for no other reason than to ensure that the BSD code 'just worked' and for a product, which where I was at the time (and I think Larry also at Sun), ensuring existing code worked (and worked efficiently), has to be the high order bit. I do hear you about many of the deficancies of 'pure joy.' It seems that it is always difficult as systems implementors to decide when to have an 'ice age' and try to kill off the old code and when to evolve it. IMHO: the code running user space that exploited the networking layer was still new enough, that evolution (*i.e.* hanging on an interface that was seemly 'good enough' - sockets) was more attractive than revolution. FWIW: we can now analyize and argue why BSD UNIX and the socket interface were what made it happen, but the historical fact is that sockets did seed the user space network code base. Also, I will observe that your comments about replacing MPX are a solid memory for me also, IIRC Greg developed MPX for datakit originally. He had sent me a copy at CMU in the late 1970s (but before V7 was out the door) and we had it in our v6++/CMU distr front -end system. I also remember messing with it in on the Teklabs system. Because I had messed with it at CMU aqnd was familar with its semantics, we we got the 3COM UNET code base (which was the first commercial IP/TCP implementation and it ran in user space unlike the later BBN Gurwitiz code base), and I rewrote some of Greg Shaw and Bruce Borden's stuff to use MPX. I'm trying to remember how their code worked before we hacked it -- (maybe Rand Pipes); but that was too many beers ago for my brain to still have it. I'm pretty sure Greg/Bruce took this back to 3Com when we were done. Sadly, the UNET stuff seems to have been lost. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Aug 28 23:57:24 2019 From: clemc at ccc.com (Clem Cole) Date: Wed, 28 Aug 2019 09:57:24 -0400 Subject: [TUHS] If not Linux, then what? In-Reply-To: <20190828063045.GE75146@server.rulingia.com> References: <20190827003013.GS13570@mcvoy.com> <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net> <20190827024511.GU13570@mcvoy.com> <20190827145556.GD13570@mcvoy.com> <20190827224002.GB15511@mcvoy.com> <20190828063045.GE75146@server.rulingia.com> Message-ID: On Wed, Aug 28, 2019 at 2:46 AM Peter Jeremy wrote: > There was ISODE (https://en.wikipedia.org/wiki/ISO_Development_Environment > ). > I recall experimenting with it but didn't actually use it in anger. > Ditto. > > I know that DEC/Compaq/HP Tru64 Unix (nee OSF/1) came with a OSI stack - > we had customers who wanted/used FTAM and I was surprised to find it > came with the OS. > Tru64 talked to DECnet Phase X (I don't remember which one, maybe 4 or 5), which had become an ISO/OSI stack by that point for political reasons inside of Digital (the OSI vs TCP war reminded me of the Pascal vs C and VMS vs UNIX wars - all very silly in retrospect, but I guess it was really about who got which $s for development). Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Aug 29 00:04:13 2019 From: clemc at ccc.com (Clem Cole) Date: Wed, 28 Aug 2019 10:04:13 -0400 Subject: [TUHS] If not Linux, then what? In-Reply-To: References: <20190828063045.GE75146@server.rulingia.com> Message-ID: If that's the MIPs code base, it is likely to not be there. I could be forgetting something, but I remember that DECnet was released for the MIPS products. It was on Tru64 and Ultrix, but is a 'layered product' so you needed a license to install it and it needed to be a late enough version that had switched to exposing a full OSI stack. That said, I do not remember/know how well it functioned talking to any OSI stack other than DECs. On Wed, Aug 28, 2019 at 7:05 AM Jason Stevens < jsteve at superglobalmegacorp.com> wrote: > > > I have OSF/1 1.0 running on gxemul … > > > > Any idea on where/ how to configure OSI? > > > > > > OSF/1 Release 1 (OSFMIPS) console > > > > login: root > > Last login: Thu Aug 29 06:03:07 on console > > DEC OSF/1 V1.0 (Rev. 166); Sun Jun 07 19:23:34 CDT 1970 > > DEC OSF/1 V1.0 Worksystem Software (Rev. 161) > > > > # find / -name 'osi*' -print > > # > > > > *From: *Peter Jeremy > *Sent: *Wednesday, August 28, 2019 2:47 PM > *To: *Wesley Parish > *Cc: *TUHS main list > *Subject: *Re: [TUHS] If not Linux, then what? > > > > On 2019-Aug-28 18:19:21 +1200, Wesley Parish > > wrote: > > >Speaking of OSI stacks, I know 4.4BSD Lite came with some fragments of > > >one. OSI's dead and hardly mourned these days, but did anyone in the > > >Unix world ever get beyond the 4.4BSD fragmentary implementation? > > > > There was ISODE > > (https://en.wikipedia.org/wiki/ISO_Development_Environment). > > I recall experimenting with it but didn't actually use it in anger. > > > > I know that DEC/Compaq/HP Tru64 Unix (nee OSF/1) came with a OSI stack - > > we had customers who wanted/used FTAM and I was surprised to find it > > came with the OS. > > > > -- > > Peter Jeremy > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From earl.baugh at gmail.com Thu Aug 29 00:10:17 2019 From: earl.baugh at gmail.com (Earl Baugh) Date: Wed, 28 Aug 2019 10:10:17 -0400 Subject: [TUHS] If not Linux, then what? In-Reply-To: References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> Message-ID: <08473671-7927-48B7-A4DD-5F766C34E2D7@gmail.com> One point/ direction nobody seems to have mentioned was “what if Linus found out about BSD on PC hw”? From what I’ve read he wasn’t aware of it, so perhaps a very different outcome could have been — what if Linus did find out about it and then ultimately took it over ( removing the caustic personalities ) or at worst forked it. I think that would have become a much preferable outcome. Just my $0.02. Earl Sent from my iPhone > On Aug 28, 2019, at 5:36 AM, Angus Robinson wrote: > > Interesting question, the alternative OS would have had to have had a good leader and I am sure maybe RMS would have created a kernel after some time. > Maybe somebody would have taken 386BSD/FreeBSD/NetBSD and made something completely different. > I think another question would be, if Linux was never invented, what technologies would never have happened. For instance, a bunch of animation movies where made with Linux farms, Planes use Linux within their inbuilt entertainment systems, the list goes on (I think NASA uses linux on their ISS). How many people would be interested in technology/IT sector, how many companies would have started (ie: RedHat, Thwat,etc), What features/addons would not have been added to other operating systems (Windows tcp/ip)? Would docker even be a thing, hyper-v ? > > I know one thing....... All the old technology would be alot more and schools would have alot more vunerabilites on their PC's. > > > > >> On Tue, Aug 27, 2019 at 1:13 AM Arthur Krewat wrote: >> https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel >> >> Leaving licensing and copyright issues out of this mental exercise, what >> would we have now if it wasn't for Linux? Not what you'd WANT it to be, >> although that can add to the discussion, but what WOULD it be? >> >> I'm not asking as a proponent of Linux. If anything, I was dragged >> kicking and screaming into the current day and have begrudgingly ceded >> my server space to Linux. >> >> But if not for Linux, would it be BSD? A System V variant? Or (the >> horror) Windows NT? >> >> I do understand that this has been discussed on the list before. I >> think, however, it would make a good late-summer exercise. Or late >> winter depending on where you are :) >> >> art k. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From sauer at technologists.com Thu Aug 29 00:22:34 2019 From: sauer at technologists.com (Charles H Sauer) Date: Wed, 28 Aug 2019 09:22:34 -0500 Subject: [TUHS] If not Linux, then what? In-Reply-To: References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> Message-ID: possible components of answer regarding animation/CGI: o SGI/MIPS/IRIX would have fared better/longer o Jobs would have pushed Pixar towards Mach o P4+NVIDIA would still have been disruptive (https://secure2.linuxjournal.com/ljarchive/LJ/099/6011s1.html) o Gates would have done more Windows had usable TCP/IP, at least starting with Windows 3, from Trumpet, Chameleon and others. I found/find the Microsoft 32 bit implementation preferable running Mosaic and Netscape, but had to do some work with 16 bit Trumpet a few years ago for a client that needed me to make some things work in DOS outside of Win 3.1. On 8/28/2019 4:36 AM, Angus Robinson wrote: ... > I think another question would be, if Linux was never invented, what > technologies would never have happened. For instance, a bunch of > animation movies where made with Linux farms, Planes use Linux within > their inbuilt entertainment systems, the list goes on (I think NASA uses > linux on their ISS). How many people would be interested in > technology/IT sector, how many companies would have started (ie: RedHat, > Thwat,etc), What features/addons would not have been added to other > operating systems (Windows tcp/ip)? Would docker even be a thing, hyper-v ? > > I know one thing....... All the old technology would be alot more and > schools would have alot more vunerabilites on their PC's. > > > > On Tue, Aug 27, 2019 at 1:13 AM Arthur Krewat > wrote: > > https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel > > Leaving licensing and copyright issues out of this mental exercise, > what > would we have now if it wasn't for Linux? Not what you'd WANT it to be, > although that can add to the discussion, but what WOULD it be? > > I'm not asking as a proponent of Linux. If anything, I was dragged > kicking and screaming into the current day and have begrudgingly ceded > my server space to Linux. > > But if not for Linux, would it be BSD? A System V variant? Or (the > horror) Windows NT? > > I do understand that this has been discussed on the list before. I > think, however, it would make a good late-summer exercise. Or late > winter depending on where you are :) > > art k. > > -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/Skype/Twitter: CharlesHSauer From lm at mcvoy.com Thu Aug 29 00:31:40 2019 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 28 Aug 2019 07:31:40 -0700 Subject: [TUHS] If not Linux, then what? In-Reply-To: References: <20190827024511.GU13570@mcvoy.com> <20190827145556.GD13570@mcvoy.com> <20190827224002.GB15511@mcvoy.com> <20190827225955.GC15511@mcvoy.com> <20190828040540.GT13570@mcvoy.com> Message-ID: <20190828143140.GU13570@mcvoy.com> On Wed, Aug 28, 2019 at 09:52:42AM -0400, Clem Cole wrote: > On Wed, Aug 28, 2019 at 12:06 AM Larry McVoy wrote: > > > I could be wrong but that's my memory. What he told me was streams was > > for line disciplines for tty drivers. > > > > Rob - this syncs with what Dennis I had talked about too *i.e.* Using > streams for the serial interface; as the line disciplines stuff was a mess > by that point. I cannt say I remember talking to him about using streams > for networking. If my memory is right, I would have talked to Dennis about it around 1987 or early 1988. Is it possible that was before they did networking in streams? Maybe I have the dates wrong but my guess is I talked to him about it before the networking stuff was done in research Unix. So his view may have evolved. From clemc at ccc.com Thu Aug 29 00:55:42 2019 From: clemc at ccc.com (Clem Cole) Date: Wed, 28 Aug 2019 10:55:42 -0400 Subject: [TUHS] If not Linux, then what? In-Reply-To: <08473671-7927-48B7-A4DD-5F766C34E2D7@gmail.com> References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <08473671-7927-48B7-A4DD-5F766C34E2D7@gmail.com> Message-ID: On Wed, Aug 28, 2019 at 10:10 AM Earl Baugh wrote: > One point/ direction nobody seems to have mentioned was “what if Linus > found out about BSD on PC hw”? From what I’ve read he wasn’t aware of it, > so perhaps a very different outcome could have been > A couple of items. Linus is on record as saying if he had known about the 'magic FTP site' at UCB for 386BSD code download, he would have obtained it [it is how most of us got it in those days]. The sad part is that his University was licensed for it from UCB, so *they could have gotten the code* is they had asked for it. But as Larry has pointed out, many Universities in those days took a fairly restrictive view of access to the Unix sources; so it's still now clear if Linus himself would have gotten a copy. — what if Linus did find out about it and then ultimately took it over ( > removing the caustic personalities ) or at worst forked it. > Hmmm, I fear, Linus just would have been one more personality, or his version would have been one more fork in the quickly branching, BSD tree. The real problem IMO was the lawsuit which happened shortly after 368BSD went into the wild. Let me tell you about my own experience from the time. As I said, people like myself got scared that UNIX for a PC/386 would not be available. We had Minix, but it did not use the paging HW, whereas Linus' code did and we thought, Linus code was unencumbered (it wasn't/isn't, while* it is a rewrite*, it is still based on the AT&T IP - but again that's a different part of story). I know I had personally had bought Minix myself for whatever it was (??$70 IIRC) in a 'book' of N floppies from Prentiss-Hall. I was semi-happy because it was a rewrite of Unix and was better than DOS. But .... it was originally floppy only for the 16 bit 8088 (XT not the AT) and very, slow and had quite limited in functionality (it did have a C compiler and ed but no vi, and definitely not, sockets). At the time, at work, I had a copy of the WD 1003 controller documentation - which was the disk controller IBM had used for the AT. A lot of people doing hacking on PC Unix in those days did not have that document as it turned out. So one of the first things I did, was to hack together a Minix AT/IDE driver for my system and sent it back, maybe posted it to net.noise (I've forgotten). As I had known him my UCB days, shortly thereafter it went into the wild, Joilitz contacted me. He had tried to write his AT disk driver for his version via "reverse engineering" (the BIOS ROMs I think). Bill's original code worked to a point but had some issues and he was looking for some help. I had a Wyse 32:16, which was one of the first 386 based PCs. Hence, I got my copy of Bill's work via the secret address to download. We updated his driver with missing info I gave him (FWIW: Bill references this in the DDJ articles). Anyway, now I had a 'real UNIX' and it was BSD even, Minix was not only primarily floppy-based, but it was a V7 clone so the difference was remarkable. Then lawyers showed up.... I know I got scared and so did a lot of others. Linus has recently made his post, so we all jumped. The rest is history, although as I point out, it is likely world today would have been much different it AT&T had won the lawsuit. But they did not so that is a moot point. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Aug 29 00:57:11 2019 From: clemc at ccc.com (Clem Cole) Date: Wed, 28 Aug 2019 10:57:11 -0400 Subject: [TUHS] If not Linux, then what? In-Reply-To: <20190828143140.GU13570@mcvoy.com> References: <20190827024511.GU13570@mcvoy.com> <20190827145556.GD13570@mcvoy.com> <20190827224002.GB15511@mcvoy.com> <20190827225955.GC15511@mcvoy.com> <20190828040540.GT13570@mcvoy.com> <20190828143140.GU13570@mcvoy.com> Message-ID: Could be. I'm not sure I can date it, On Wed, Aug 28, 2019 at 10:31 AM Larry McVoy wrote: > On Wed, Aug 28, 2019 at 09:52:42AM -0400, Clem Cole wrote: > > On Wed, Aug 28, 2019 at 12:06 AM Larry McVoy wrote: > > > > > I could be wrong but that's my memory. What he told me was streams was > > > for line disciplines for tty drivers. > > > > > > > Rob - this syncs with what Dennis I had talked about too *i.e.* Using > > streams for the serial interface; as the line disciplines stuff was a > mess > > by that point. I cannt say I remember talking to him about using streams > > for networking. > > If my memory is right, I would have talked to Dennis about it around > 1987 or early 1988. Is it possible that was before they did networking > in streams? > > Maybe I have the dates wrong but my guess is I talked to him about it > before the networking stuff was done in research Unix. So his view > may have evolved. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From usotsuki at buric.co Thu Aug 29 01:00:31 2019 From: usotsuki at buric.co (Steve Nickolas) Date: Wed, 28 Aug 2019 11:00:31 -0400 (EDT) Subject: [TUHS] If not Linux, then what? In-Reply-To: References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> Message-ID: On Wed, 28 Aug 2019, Charles H Sauer wrote: > possible components of answer regarding animation/CGI: > o SGI/MIPS/IRIX would have fared better/longer > o Jobs would have pushed Pixar towards Mach > o P4+NVIDIA would still have been disruptive > (https://secure2.linuxjournal.com/ljarchive/LJ/099/6011s1.html) > o Gates would have done more > > Windows had usable TCP/IP, at least starting with Windows 3, from Trumpet, > Chameleon and others. I found/find the Microsoft 32 bit implementation > preferable running Mosaic and Netscape, but had to do some work with 16 bit > Trumpet a few years ago for a client that needed me to make some things work > in DOS outside of Win 3.1. I actually wrote an IRC client for plain DOS a few years ago - I used WatTCP. -uso. From rich.salz at gmail.com Thu Aug 29 01:37:51 2019 From: rich.salz at gmail.com (Richard Salz) Date: Wed, 28 Aug 2019 11:37:51 -0400 Subject: [TUHS] If not Linux, then what? In-Reply-To: References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> Message-ID: I think the biggest difference would have been no git and therefore no github, etc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Thu Aug 29 02:34:46 2019 From: henry.r.bent at gmail.com (Henry Bent) Date: Wed, 28 Aug 2019 12:34:46 -0400 Subject: [TUHS] If not Linux, then what? In-Reply-To: References: <20190828063045.GE75146@server.rulingia.com> Message-ID: On Wed, 28 Aug 2019 at 10:05, Clem Cole wrote: > If that's the MIPs code base, it is likely to not be there. I could be > forgetting something, but I remember that DECnet was released for the MIPS > products. It was on Tru64 and Ultrix, but is a 'layered product' so you > needed a license to install it and it needed to be a late enough version > that had switched to exposing a full OSI stack. > > That said, I do not remember/know how well it functioned talking to any > OSI stack other than DECs. > OSF/1 for MIPS wasn't actually a beta but it might as well have been. It was slow, it was buggy, and DEC dropped support for it fairly quickly after it was released. It was never ported to any of the R4k machines. Customers were not happy. Anyway, the official release announcement ( https://groups.google.com/forum/?hl=en#!original/bit.listserv.esl-l/BovGe3q9yWE/cqlcCYfxmbAJ ) mentions a few layered products, none of which I have ever seen in the wild. No OSI implementation is mentioned. Looking through a list of layered products for Ultrix from mid-1994, I see a few OSI-related things: MIPS: DEC OSI Application 1.1 GZSAA Developer's Toolkit DECnet/OSI for ULTRIX 5.1A YT9AA OSI Application Toolkit 5.1A OSIAP_RISC VAX: DECnet/OSI for ULTRIX 5.1A 716AA OSI Application Toolkit 5.1A OSIAP_VAX If you want more documentation on any of these, contact me off-list. -Henry > On Wed, Aug 28, 2019 at 7:05 AM Jason Stevens < > jsteve at superglobalmegacorp.com> wrote: > >> >> >> I have OSF/1 1.0 running on gxemul … >> >> >> >> Any idea on where/ how to configure OSI? >> >> >> >> >> >> OSF/1 Release 1 (OSFMIPS) console >> >> >> >> login: root >> >> Last login: Thu Aug 29 06:03:07 on console >> >> DEC OSF/1 V1.0 (Rev. 166); Sun Jun 07 19:23:34 CDT 1970 >> >> DEC OSF/1 V1.0 Worksystem Software (Rev. 161) >> >> >> >> # find / -name 'osi*' -print >> >> # >> >> >> >> *From: *Peter Jeremy >> *Sent: *Wednesday, August 28, 2019 2:47 PM >> *To: *Wesley Parish >> *Cc: *TUHS main list >> *Subject: *Re: [TUHS] If not Linux, then what? >> >> >> >> On 2019-Aug-28 18:19:21 +1200, Wesley Parish >> >> wrote: >> >> >Speaking of OSI stacks, I know 4.4BSD Lite came with some fragments of >> >> >one. OSI's dead and hardly mourned these days, but did anyone in the >> >> >Unix world ever get beyond the 4.4BSD fragmentary implementation? >> >> >> >> There was ISODE >> >> (https://en.wikipedia.org/wiki/ISO_Development_Environment). >> >> I recall experimenting with it but didn't actually use it in anger. >> >> >> >> I know that DEC/Compaq/HP Tru64 Unix (nee OSF/1) came with a OSI stack - >> >> we had customers who wanted/used FTAM and I was surprised to find it >> >> came with the OS. >> >> >> >> -- >> >> Peter Jeremy >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Thu Aug 29 02:46:03 2019 From: henry.r.bent at gmail.com (Henry Bent) Date: Wed, 28 Aug 2019 12:46:03 -0400 Subject: [TUHS] Running v10 In-Reply-To: <20190828073400.GA30049@indra.papnet.eu> References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <75a32043-4830-ba04-ee0f-023c5f5ade3f@gmail.com> <20190827003013.GS13570@mcvoy.com> <20190827160559.GA92491@indra.papnet.eu> <20190828073400.GA30049@indra.papnet.eu> Message-ID: On Wed, 28 Aug 2019 at 03:41, Angelo Papenhoff wrote: > On 28/08/19, Jason Stevens wrote: > > I don’t recall their being detailed installation instructions like > v8/v9. I never noticed the vax boot stuff as it was buried in the tree. > It’s possible that it’s buildable. Or it could be incomplete like the Mach > 2.5 VAX missing system headers…. > > > > I guess it’s worth trying on whatever should be the parallel BSD system > if it’s like v8/v9 which needed a BSD machine to bootstrap. > > Check out "Setting Up a Research UNIX System" by Norman Wilson. troff > sources are in v10. > Thanks, I hadn't found that yet. Unfortunately it assumes that you have a tape with at least a root and /usr dump, which we do not have. I have several ideas about how one might go about building the tree using existing distributions but any further discussion probably isn't appropriate for this list. If anyone would like to collaborate please feel free to contact me off-list. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Thu Aug 29 02:50:36 2019 From: paul.winalski at gmail.com (Paul Winalski) Date: Wed, 28 Aug 2019 12:50:36 -0400 Subject: [TUHS] ISO, OSI, and DECnet (was Re: If not Linux, then what?) Message-ID: On 8/28/19, Clem Cole wrote: > On Wed, Aug 28, 2019 at 2:46 AM Peter Jeremy wrote: > > Tru64 talked to DECnet Phase X (I don't remember which one, maybe 4 or 5), > which had become an ISO/OSI stack by that point for political reasons > inside of Digital (the OSI vs TCP war reminded me of the Pascal vs C and > VMS vs UNIX wars - all very silly in retrospect, but I guess it was really > about who got which $s for development). It was DECnet Phase V that was based on the ISO/OSI stack. IIRC, at the time the European telcos were pushing OSI, it had become an ISO standard, etc. etc. It was also pretty easy to compatibly slide the legacy proprietary DECnet Phase IV adaptive routing and virtual circuit layers into the OSI stack. TCP won the war, of course. The risk with international standards fashioned out of whole cloth by a committee (as opposed to being a regularization of existing practice) is that the marketplace may choose to ignore the "standard". OSI and the Ada programming language are cases in point. -Paul W. From lm at mcvoy.com Thu Aug 29 03:24:51 2019 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 28 Aug 2019 10:24:51 -0700 Subject: [TUHS] ISO, OSI, and DECnet (was Re: If not Linux, then what?) In-Reply-To: References: Message-ID: <20190828172451.GX13570@mcvoy.com> On Wed, Aug 28, 2019 at 12:50:36PM -0400, Paul Winalski wrote: > On 8/28/19, Clem Cole wrote: > > On Wed, Aug 28, 2019 at 2:46 AM Peter Jeremy wrote: > > > > Tru64 talked to DECnet Phase X (I don't remember which one, maybe 4 or 5), > > which had become an ISO/OSI stack by that point for political reasons > > inside of Digital (the OSI vs TCP war reminded me of the Pascal vs C and > > VMS vs UNIX wars - all very silly in retrospect, but I guess it was really > > about who got which $s for development). > > It was DECnet Phase V that was based on the ISO/OSI stack. IIRC, at > the time the European telcos were pushing OSI, it had become an ISO > standard, etc. etc. It was also pretty easy to compatibly slide the > legacy proprietary DECnet Phase IV adaptive routing and virtual > circuit layers into the OSI stack. > > TCP won the war, of course. The risk with international standards > fashioned out of whole cloth by a committee (as opposed to being a > regularization of existing practice) is that the marketplace may > choose to ignore the "standard". OSI and the Ada programming language > are cases in point. The great Mike Padlipski said "do you want protocols that look nice or protocols that work nice?" in his fantastic book Elements of Networking Style [*]. Maybe it's just that I read that book at the right time, I was porting Lachman's STREAMS based TCP/IP stack, I had taken a networking class where we built a stack, so I knew there was a state machine in there, I had read Masscomp's networking primer and written some clients and servers. So I sort of knew a little but did not have the big picture. I read Mike's book and it snapped everything into focus, which is in part why I loved it. The other part was all the less than subtle jabs at OSI. Mike couldn't stand the OSI model, another quote from the book is "If you know what you are doing, 3 layers are enough. If you don't, 7 layers won't help you". I liked the book enough that I tracked down a phone number for Mike, I think he was at UCLA or somewhere in LA but I might be wrong (the number I have is 310-670-4288 which is a LA area code), and called him and thanked him for the book. We ended up becoming friendly with each other and chatted from time to time about networking stuff. I miss that guy, he was great. [*] The book is available here for $20. Worth it. https://www.iuniverse.com/en/bookstore/bookdetails/124830-The-Elements-of-Networking-Style From lm at mcvoy.com Thu Aug 29 03:32:28 2019 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 28 Aug 2019 10:32:28 -0700 Subject: [TUHS] If not Linux, then what? In-Reply-To: References: <20190828063045.GE75146@server.rulingia.com> Message-ID: <20190828173228.GZ13570@mcvoy.com> On Wed, Aug 28, 2019 at 12:34:46PM -0400, Henry Bent wrote: > On Wed, 28 Aug 2019 at 10:05, Clem Cole wrote: > > > If that's the MIPs code base, it is likely to not be there. I could be > > forgetting something, but I remember that DECnet was released for the MIPS > > products. It was on Tru64 and Ultrix, but is a 'layered product' so you > > needed a license to install it and it needed to be a late enough version > > that had switched to exposing a full OSI stack. > > > > That said, I do not remember/know how well it functioned talking to any > > OSI stack other than DECs. > > > > OSF/1 for MIPS wasn't actually a beta but it might as well have been. It > was slow, it was buggy, and DEC dropped support for it fairly quickly after > it was released. It was never ported to any of the R4k machines. Perhaps Clem can shed some light on why DEC did a MIPS machine? I had sort of stopped paying attention to them, so don't know the reasoning. From nobozo at gmail.com Thu Aug 29 03:45:38 2019 From: nobozo at gmail.com (Jon Forrest) Date: Wed, 28 Aug 2019 10:45:38 -0700 Subject: [TUHS] ISO, OSI, and DECnet (was Re: If not Linux, then what?) In-Reply-To: <20190828172451.GX13570@mcvoy.com> References: <20190828172451.GX13570@mcvoy.com> Message-ID: <59c49df3-66c3-ca86-18e7-fa1f8251883a@gmail.com> On 8/28/2019 10:24 AM, Larry McVoy wrote: > The great Mike Padlipski said "do you want protocols that look nice or > protocols that work nice?" in his fantastic book Elements of Networking > Style [*]. > I liked the book enough that I tracked down a phone number for Mike, > I think he was at UCLA or somewhere in LA but I might be wrong (the > number I have is 310-670-4288 which is a LA area code), and called him > and thanked him for the book. We ended up becoming friendly with each > other and chatted from time to time about networking stuff. I miss that > guy, he was great. I'm an average system person who's has had the great fortune to have worked with many world-class people. My first real job was at Ford Aerospace in 1978. They were an early commercial user of Unix (PWB in their case). John Nagle had the desk next to me. Mike Padlipski was also in the group. I never knew exactly what Mike did, given that he seemed to spend most of his time smoking and reading the N. Y. Times. But, other great people in the group said that Mike was a networking protocol expert. I guess he was. Mike didn't really converse. Instead, he expounded at great length. He was quite a character. > [*] The book is available here for $20. Worth it. I have a copy I'd like to sell. It's the 1985 printing. I'll also sell my copy for $20 + shipping (local pickup in the Berkeley area is welcome). Contact me off list if you're interested. Jon From lm at mcvoy.com Thu Aug 29 03:50:11 2019 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 28 Aug 2019 10:50:11 -0700 Subject: [TUHS] ISO, OSI, and DECnet (was Re: If not Linux, then what?) In-Reply-To: <59c49df3-66c3-ca86-18e7-fa1f8251883a@gmail.com> References: <20190828172451.GX13570@mcvoy.com> <59c49df3-66c3-ca86-18e7-fa1f8251883a@gmail.com> Message-ID: <20190828175011.GD13570@mcvoy.com> On Wed, Aug 28, 2019 at 10:45:38AM -0700, Jon Forrest wrote: > >[*] The book is available here for $20. Worth it. > > I have a copy I'd like to sell. It's the 1985 printing. I'll > also sell my copy for $20 + shipping (local pickup in the > Berkeley area is welcome). Contact me off list if you're > interested. If there are any young kids on the list for whom this would be helpful I'll happily pay for the book to go to you. From nobozo at gmail.com Thu Aug 29 03:51:30 2019 From: nobozo at gmail.com (Jon Forrest) Date: Wed, 28 Aug 2019 10:51:30 -0700 Subject: [TUHS] If not Linux, then what? In-Reply-To: <20190828173228.GZ13570@mcvoy.com> References: <20190828063045.GE75146@server.rulingia.com> <20190828173228.GZ13570@mcvoy.com> Message-ID: On 8/28/2019 10:32 AM, Larry McVoy wrote: > Perhaps Clem can shed some light on why DEC did a MIPS machine? I had > sort of stopped paying attention to them, so don't know the reasoning. I always thought it was because the Vaxes were too slow (and too expensive) to compete with Sun, and the Alphas wouldn't be ready soon enough. So, going with MIPS was a relatively quick and easy solution. In UC Berkeley CS in the early 90s we had lots of DEC MIP-stations. In fact, I believe that Ousterhout used them to develop Sprite. IIRC, there weren't nearly as many Suns, which was odd, considering that Dave Patterson was in the department. As a result of the Sequoia 2000 project we got great deals on DEC hardware. Jon From doug at cs.dartmouth.edu Thu Aug 29 03:57:09 2019 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Wed, 28 Aug 2019 13:57:09 -0400 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] Message-ID: <201908281757.x7SHv9gj042779@tahoe.cs.Dartmouth.EDU> > How long was research running on a PDP-11 and when did they move to a VAX? London and Reiser had ported Unix to the VAX, replete with virtual memory, in 1978. By the time v7 was released (1979), Vaxen had become the workhorse machines in Research. Doug From athornton at gmail.com Thu Aug 29 04:05:26 2019 From: athornton at gmail.com (Adam Thornton) Date: Wed, 28 Aug 2019 11:05:26 -0700 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: <201908281757.x7SHv9gj042779@tahoe.cs.Dartmouth.EDU> References: <201908281757.x7SHv9gj042779@tahoe.cs.Dartmouth.EDU> Message-ID: Interesting. In my head, v7 is kind of the pinnacle of what you should run on a PDP-11 (yes, I know 2.11BSD is still maintained), but that once you add a networking stack, the 16-bit address limitations really start to hurt, no matter how clever you are with your overlays. But when I think of v7, in my mind it's running on an 11/70. I also find the multilayer switching described in the streams networking implementation a lot like "inetd, all the way down." That's kinda nifty. Adam On Wed, Aug 28, 2019 at 10:57 AM Doug McIlroy wrote: > > > How long was research running on a PDP-11 and when did they move to a > VAX? > > London and Reiser had ported Unix to the VAX, replete with virtual memory, > in 1978. By the time v7 was released (1979), Vaxen had become the workhorse > machines in Research. > > Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Thu Aug 29 04:08:38 2019 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 28 Aug 2019 12:08:38 -0600 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: <201908281757.x7SHv9gj042779@tahoe.cs.Dartmouth.EDU> References: <201908281757.x7SHv9gj042779@tahoe.cs.Dartmouth.EDU> Message-ID: <201908281808.x7SI8cUg023542@freefriends.org> Doug McIlroy wrote: > > > How long was research running on a PDP-11 and when did they move to a VAX? > > London and Reiser had ported Unix to the VAX, replete with virtual memory, in 1978. By the time v7 was released (1979), Vaxen had become the workhorse machines in Research. > > Doug So, what's the story on why the London/Reiser port didn't get adapted back by Research, and they ended up starting from 4.1 BSD? Thanks, Arnold From khm at sciops.net Thu Aug 29 04:17:27 2019 From: khm at sciops.net (Kurt H Maier) Date: Wed, 28 Aug 2019 11:17:27 -0700 Subject: [TUHS] ISO, OSI, and DECnet (was Re: If not Linux, then what?) In-Reply-To: <20190828172451.GX13570@mcvoy.com> References: <20190828172451.GX13570@mcvoy.com> Message-ID: <20190828181727.GA82704@wopr> On Wed, Aug 28, 2019 at 10:24:51AM -0700, Larry McVoy wrote: > > The great Mike Padlipski said "do you want protocols that look nice or > protocols that work nice?" in his fantastic book Elements of Networking > Style [*]. > This book taught me as much about navigating bureaucracy and the warning signs of impending death-by-committee as it did about networking. I keep a copy on my shelf at the office and annoy my staff with it regularly. It's also a wonderful time capsule that provides a lot of context about how we got where we are. khm From imp at bsdimp.com Thu Aug 29 04:27:26 2019 From: imp at bsdimp.com (Warner Losh) Date: Wed, 28 Aug 2019 12:27:26 -0600 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: <201908281757.x7SHv9gj042779@tahoe.cs.Dartmouth.EDU> References: <201908281757.x7SHv9gj042779@tahoe.cs.Dartmouth.EDU> Message-ID: On Wed, Aug 28, 2019, 11:57 AM Doug McIlroy wrote: > > > How long was research running on a PDP-11 and when did they move to a > VAX? > > London and Reiser had ported Unix to the VAX, replete with virtual memory, > in 1978. By the time v7 was released (1979), Vaxen had become the workhorse > machines in Research. > Is there a paper on this work? Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Thu Aug 29 04:34:10 2019 From: imp at bsdimp.com (Warner Losh) Date: Wed, 28 Aug 2019 12:34:10 -0600 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: References: <201908281757.x7SHv9gj042779@tahoe.cs.Dartmouth.EDU> Message-ID: On Wed, Aug 28, 2019, 12:27 PM Warner Losh wrote: > > > On Wed, Aug 28, 2019, 11:57 AM Doug McIlroy wrote: > >> >> > How long was research running on a PDP-11 and when did they move to a >> VAX? >> >> London and Reiser had ported Unix to the VAX, replete with virtual >> memory, in 1978. By the time v7 was released (1979), Vaxen had become the >> workhorse machines in Research. >> > > > Is there a paper on this work? > Found the 32V paper, but this was still a swapping implementation if I'm reading correctly. I thought that the virtual memory was added by BSD / Bill Joy. That would explain why V8 was BSD 4.1 based, since it was the first usable Vax port with VM. Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Thu Aug 29 04:41:26 2019 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Wed, 28 Aug 2019 14:41:26 -0400 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] Message-ID: <201908281841.x7SIfQS7053036@tahoe.cs.Dartmouth.EDU> > Doug McIlroy wrote: > >> >>> How long was research running on a PDP-11 and when did they move to a VAX? >> >> London and Reiser had ported Unix to the VAX, replete with virtual memory, in 1978. By the time v7 was released (1979), Vaxen had become the workhorse machines in Research. >> >> Doug > > So, what's the story on why the London/Reiser port didn't get adapted > back by Research, and they ended up starting from 4.1 BSD? > > Thanks, > > Arnold Sorry, what I said about London/Reiser is true, but not the whole story. L/R didn't have demand paging; BSD did. Doug From arnold at skeeve.com Thu Aug 29 04:49:30 2019 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 28 Aug 2019 12:49:30 -0600 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: <201908281841.x7SIfQS7053036@tahoe.cs.Dartmouth.EDU> References: <201908281841.x7SIfQS7053036@tahoe.cs.Dartmouth.EDU> Message-ID: <201908281849.x7SInUE1024803@freefriends.org> Doug McIlroy wrote: > > Doug McIlroy wrote: > > > >> > >>> How long was research running on a PDP-11 and when did they move to a VAX? > >> > >> London and Reiser had ported Unix to the VAX, replete with virtual memory, in 1978. By the time v7 was released (1979), Vaxen had become the workhorse machines in Research. > >> > >> Doug > > > > So, what's the story on why the London/Reiser port didn't get adapted > > back by Research, and they ended up starting from 4.1 BSD? > > > > Thanks, > > > > Arnold > > Sorry, what I said about London/Reiser is true, but not the whole > story. L/R didn't have demand paging; BSD did. But my question still stands. Why didn't Research keep going from L/R and add demand paging? Wouldn't that have been "cleaner" than starting from BSD? Thanks, Arnold From clemc at ccc.com Thu Aug 29 04:56:14 2019 From: clemc at ccc.com (Clem Cole) Date: Wed, 28 Aug 2019 14:56:14 -0400 Subject: [TUHS] If not Linux, then what? In-Reply-To: <20190828173228.GZ13570@mcvoy.com> References: <20190828063045.GE75146@server.rulingia.com> <20190828173228.GZ13570@mcvoy.com> Message-ID: On Wed, Aug 28, 2019 at 1:32 PM Larry McVoy wrote: > Perhaps Clem can shed some light on why DEC did a MIPS machine? > I did not work for DEC at the time and obviously, I was not in the room, so this is what I can say I picked up. Supnik would be a better person to ask. That said, some things I do know about the time/and behinds the scene. - Jupiter and Prism had been canceled. - Alpha did not yet exist (and would not for another 2 years) - Cutler had left for Microsoft etc.. - Sun was clearly on its game - The VAX on a Chip just was not cutting it - RISC architectures were the hot item Here is where I get fuzzy on details. - I believe a prototype (i.e. skunk works) MIPS was running at WRL in Palo Alto running Ultrix and DEC windows, I think using some sort of cheap ??PC?? chassis. - But the performance of the prototype was excellent and cost was cheaper than the current vax products. - Somebody sr, maybe Bob, shows this to Sr management and got the money to productize it. The issue as making an official Ultrix for it was I know a big one. Ultimately, DEC farmed that work out to us at LCC (with us eventually taking over all of Ultrix - MIPS and Vax). So, I think the MIPS product was a holding pattern while DEC got it's strategy together. Alpha would really show up until later (I would leave LCC and go to DEC to be apart if that). Also note Alpha was brought up/debugged on Ultrix and of course, Prism sort of had Ultrix on it. But I think using the MIPS chip keep them in the game, when Vax was dying and RISC was the word on the street. FWIW: The issue of OSF/1 was a different one. The whole switching off Ultrix, getting to a new OS had been kicking around DEC for a while. One of the arguments for Cutler had been his new Mica system was that it could run both Unix and VMS on top of it - *i.e.* a single OS kernel. When Prism was canceled (along with Mica) and Cutler left, that was a huge hole for DEC's SW strategy. Oppose Sun Forever (OSF) as it was formed to counter the Sun/AT&T move. That gave DEC a way out. But remember, OSF/1 on MIPS was actually not a full product. What you got was what OSF had released, which is why it really more like a beta. While it started down the path to being a product; and DEC did specifically made it available (primarily to Universities/Research types), DEC management was very reluctant to release it because they did not want to support it. In fact, LCC was asked to give a bid on taking it on after we had taken over Ultrix. DEC management already saw Ultrix/MIPS as a resource drag once Alpha finally had been committed. [ FYI: this was the same behavior as IBM on AIX/360 BTW. Funny, how big companies sometimes do things like this]. I always said, asking customers (and the ISVs) to switch OS and ISA in one step was what caused a huge problem for DEC [along with the ISA being 64-bit only and ISV/customer code 32-bit dirty]. I've often wondered if a 32/64 bit OSF/1 MIPS stepping stone using the R4400 had been available, particularly with the Gem compiler suite (which they had but never released outside of DEC), it would have allowed the ISVs to move to Alpha quicker. Having to do it all in one step, cost them 3 years and more importantly, by the time the code was 64-bit clean; Sun & PPC had a 64-bit system and took the ISVs with away. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From chet.ramey at case.edu Thu Aug 29 05:03:34 2019 From: chet.ramey at case.edu (Chet Ramey) Date: Wed, 28 Aug 2019 15:03:34 -0400 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: <201908281849.x7SInUE1024803@freefriends.org> References: <201908281841.x7SIfQS7053036@tahoe.cs.Dartmouth.EDU> <201908281849.x7SInUE1024803@freefriends.org> Message-ID: <93732314-1521-3118-47c0-5b973b7b926e@case.edu> On 8/28/19 2:49 PM, arnold at skeeve.com wrote: >> Sorry, what I said about London/Reiser is true, but not the whole >> story. L/R didn't have demand paging; BSD did. > > But my question still stands. Why didn't Research keep going from L/R > and add demand paging? Wouldn't that have been "cleaner" than starting > from BSD? It's my impression that BSD had done other work that Research didn't want to duplicate, like autoconfiguration, device support, and so on. Joy got a lot out of the VAX hardware. -- ``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 Thu Aug 29 05:05:34 2019 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 28 Aug 2019 12:05:34 -0700 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: <93732314-1521-3118-47c0-5b973b7b926e@case.edu> References: <201908281841.x7SIfQS7053036@tahoe.cs.Dartmouth.EDU> <201908281849.x7SInUE1024803@freefriends.org> <93732314-1521-3118-47c0-5b973b7b926e@case.edu> Message-ID: <20190828190534.GH13570@mcvoy.com> On Wed, Aug 28, 2019 at 03:03:34PM -0400, Chet Ramey wrote: > On 8/28/19 2:49 PM, arnold at skeeve.com wrote: > > >> Sorry, what I said about London/Reiser is true, but not the whole > >> story. L/R didn't have demand paging; BSD did. > > > > But my question still stands. Why didn't Research keep going from L/R > > and add demand paging? Wouldn't that have been "cleaner" than starting > > from BSD? > > It's my impression that BSD had done other work that Research didn't want > to duplicate, like autoconfiguration, device support, and so on. Joy got > a lot out of the VAX hardware. He was a coding machine back then. Quite the legacy. From paul.winalski at gmail.com Thu Aug 29 05:14:42 2019 From: paul.winalski at gmail.com (Paul Winalski) Date: Wed, 28 Aug 2019 15:14:42 -0400 Subject: [TUHS] DEC's MIPS product (was If not Linux, then what?) Message-ID: On 8/28/19, Clem Cole wrote: > > So, I think the MIPS product was a holding pattern while DEC got it's > strategy together. Alpha would really show up until later (I would leave > LCC and go to DEC to be apart if that). Also note Alpha was brought > up/debugged on Ultrix and of course, Prism sort of had Ultrix on it. But > I think using the MIPS chip keep them in the game, when Vax was dying and > RISC was the word on the street. I was in DEC's compiler development team at the time, working on the new GEM common back end, and this matches my recollection. The original plan was for GEM to be the successor to the VAX Code Generator (VCG, the common back end used by DEC's PL/I, Ada, C/C++ and a few other compilers on VAX/VMS) and its first target was the VMS personality module Prism's OS, Mica. Prism was close to delivering silicon when it was cancelled in favor of Alpha. DEC's MIPS-based products were done as a stopgap until Alpha was ready. The GEM group implemented a MIPS code generator. I don't recall whether we actually shipped any GEM-based products on the MIPS/Ultrix platform. GEM focused on Alpha (on VMS, Unix, and Windows host and target platforms) shortly thereafter. -Paul W. From spedraja at gmail.com Thu Aug 29 05:29:21 2019 From: spedraja at gmail.com (SPC) Date: Wed, 28 Aug 2019 21:29:21 +0200 Subject: [TUHS] ISO, OSI, and DECnet (was Re: If not Linux, then what?) In-Reply-To: <20190828181727.GA82704@wopr> References: <20190828172451.GX13570@mcvoy.com> <20190828181727.GA82704@wopr> Message-ID: It's a bit funny (at least for me) because I was talking about DECNET as OSI standard and TCP/IP and OSI differences some days ago to the group of students of a course on network operation that I am teaching. On the other hand I don't that book about networking. I'd like to get one copy bit I live in Spain. Shipment is not a problem but perhaps to deal with shipping procedures abroad is not what you have in mind :-) Cordiales saludos / Best Regards / Salutations / Freundliche Grüße ----- Sergio Pedraja Senior Technician in Computer Science, Systems Administration, and Information Security. MBA. Qualified occupational trainer. El mié., 28 ago. 2019 20:24, Kurt H Maier escribió: > On Wed, Aug 28, 2019 at 10:24:51AM -0700, Larry McVoy wrote: > > > > The great Mike Padlipski said "do you want protocols that look nice or > > protocols that work nice?" in his fantastic book Elements of Networking > > Style [*]. > > > > This book taught me as much about navigating bureaucracy and the warning > signs of impending death-by-committee as it did about networking. I > keep a copy on my shelf at the office and annoy my staff with it > regularly. It's also a wonderful time capsule that provides a lot of > context about how we got where we are. > > khm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Aug 29 05:39:16 2019 From: clemc at ccc.com (Clem Cole) Date: Wed, 28 Aug 2019 15:39:16 -0400 Subject: [TUHS] Lions Commentary on Unix Message-ID: Gentlefolk, Does anyone have an original copy of the Lions text. All I have is the new printed version and my nth generation photocopy from 1975. There is another 50th event occurring a few weeks that would love to be able to borrow a copy for an artifact display. Reply to me off-list if you can help. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at rulingia.com Thu Aug 29 05:54:47 2019 From: peter at rulingia.com (Peter Jeremy) Date: Thu, 29 Aug 2019 05:54:47 +1000 Subject: [TUHS] If not Linux, then what? In-Reply-To: References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> Message-ID: <20190828195447.GF75146@server.rulingia.com> On 2019-Aug-28 11:37:51 -0400, Richard Salz wrote: >I think the biggest difference would have been no git and therefore no >github, etc. But there are other open SCM tools and it's likely there would be another site serving similar functionality. As an example. Google offered a code-sharing site for many years. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From cbbrowne at gmail.com Thu Aug 29 06:05:56 2019 From: cbbrowne at gmail.com (Christopher Browne) Date: Wed, 28 Aug 2019 16:05:56 -0400 Subject: [TUHS] If not Linux, then what? In-Reply-To: <20190828195447.GF75146@server.rulingia.com> References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <20190828195447.GF75146@server.rulingia.com> Message-ID: On Wed, 28 Aug 2019 at 15:55, Peter Jeremy wrote: > On 2019-Aug-28 11:37:51 -0400, Richard Salz wrote: > >I think the biggest difference would have been no git and therefore no > >github, etc. > > But there are other open SCM tools and it's likely there would be another > site serving similar functionality. As an example. Google offered a > code-sharing site for many years. > I was not a particularly early adopter of Git; I was already a couple years into usage of darcs. A one-time colleage, Graydon Hoare, was one of the designers of Monotone, which definitely influenced Git. (He's more recently known for the Rust language, and presently works at Apple on their Swift language.) Arch, Bazaar (bzr), Mercurial (hg), Codeville were also out there at the time. It's rather interesting that Git happened to "win" that particular war; there were various DSCM systems with similar (and dissimilar) capabilities emerging in around 2003-2005. Various were reasonably "production worthy." Indeed, it's quite fair to say that at the time Git emerged, there was a very active set of competing distributed SCMs out there. -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?" -------------- next part -------------- An HTML attachment was scrubbed... URL: From cbbrowne at gmail.com Thu Aug 29 06:07:39 2019 From: cbbrowne at gmail.com (Christopher Browne) Date: Wed, 28 Aug 2019 16:07:39 -0400 Subject: [TUHS] If not Linux, then what? In-Reply-To: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> Message-ID: On Mon, 26 Aug 2019 at 19:14, Arthur Krewat wrote: > > https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel > > Leaving licensing and copyright issues out of this mental exercise, what > would we have now if it wasn't for Linux? Not what you'd WANT it to be, > although that can add to the discussion, but what WOULD it be? > > I'm not asking as a proponent of Linux. If anything, I was dragged > kicking and screaming into the current day and have begrudgingly ceded > my server space to Linux. > > But if not for Linux, would it be BSD? A System V variant? Or (the > horror) Windows NT? > I can make a firm "dunno" sound :-) Some facts can come together to point away from a number of possibilities... - If you look at the number of hobbyist "Unix homages" that emerged at around that time, it's clear that there was a sizable community of interested folk willing to build their own thing, and that weren't interested in Windows NT. (Nay, one should put that more strongly... That had their minds set on something NOT from Microsoft.) So I think we can cross Windows NT off the list. - OS/2 should briefly come on the list. It was likable in many ways, if only IBM had actually supported it... But it suffers from something of the same problem as Windows NT; there were a lot of folk that were only slightly less despising of IBM at the time than of Microsoft. - Hurd was imagined to be the next thing... To borrow from my cookie file... "Of course 5 years from now that will be different, but 5 years from now everyone will be running free GNU on their 200 MIPS, 64M SPARCstation-5." -- Andrew Tanenbaum, 1992. % "You'll be rid of most of us when BSD-detox or GNU comes out, which should happen in the next few months (yeah, right)." -- Richard Tobin, 1992. [BSD did follow within a year] % "I am aware of the benefits of a micro kernel approach. However, the fact remains that Linux is here, and GNU isn't --- and people have been working on Hurd for a lot longer than Linus has been working on Linux." -- Ted T'so, 1992. Ted has been on this thread, and should be amused (and slightly disturbed!) that his old statements are being held here and there, ready to trot out :-). In the absence of Linux, perhaps hackers would have flocked to Hurd, but there was enough going on that there was plenty of room for them to have done so anyways. I'm not sure what to blame on whatever happened post-1992, though I'd put some on Microsoft Research having taken the wind out of Mach's sails by hiring off a bunch of the relevant folk. In order for Hurd to "make it," Mach has to "make it," too, and it looked like they were depending on CMU to be behind that. (I'm not sure I'm right about that; happy to hear a better story.) Anyway, Hurd *might* have been a "next thing," and I don't think the popularity of Linux was enough to have completely taken wind out of its sails, given that there's the dozens of "Unix homages" out there. - I'd like to imagine Plan 9 being an alternative, but it was "properly commercial" for a goodly long time (hence not amenable to attaching waves of hackers to it to add their favorite device drivers), and was never taken as a serious answer. Many of us had admired it from afar via the Dr Dobbs Journal issue (when was that? mid or late '90s?) but only from afar. - FreeBSD is the single best answer I can throw up as a possibility, as it was the one actively targeting 80386 hardware. And that had the big risk of the AT&T lawsuit lurking over it, so had that gone in a different direction, then that is a branch sadly easily trimmed. If we lop both Linux and FreeBSD off the list of possibilities, I don't imagine Windows NT or OS/2 bubble to the top, instead, a critical mass would have stood behind ... something else, I'd think. I don't know which to suggest. -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?" -------------- next part -------------- An HTML attachment was scrubbed... URL: From arrigo at alchemistowl.org Thu Aug 29 06:23:40 2019 From: arrigo at alchemistowl.org (Arrigo Triulzi) Date: Wed, 28 Aug 2019 22:23:40 +0200 Subject: [TUHS] If not Linux, then what? In-Reply-To: References: Message-ID: On 28 Aug 2019, at 20:57, Clem Cole wrote: >> On Wed, Aug 28, 2019 at 1:32 PM Larry McVoy wrote: >> Perhaps Clem can shed some light on why DEC did a MIPS machine? > I did not work for DEC at the time and obviously, I was not in the room, so this is what I can say I picked up. Supnik would be a better person to ask. That said, some things I do know about the time/and behinds the scene. As a customer, back in 1992 in the UK: DEC sold us Ultrix DECstations running on the R3000, the R4000 upgrade and then told us the Alpha upgrade would be for peanuts. So we ran this research cluster with one Alpha 3000/600 and two Alpha 3000/400 running OSF/1 T1.0 and the DECstations on Ultrix, compiling everything on Ultrix and "mx"ing into OSF/1 until, with OSF/1 2.0 the "upgrades" showed up and we ended up with a beautiful Alpha cluster which was the envy of the college. They then spread like wildfire when engineering depts tried their code on our cluster… For us the MIPS DECstations were literally placeholders for the Alphas we'd be getting with the trade-in! One of the DECstations is still with me because it turned out that DEC did not want back the huge stack of DECstations we had piled up for the trade-in! Arrigo -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Thu Aug 29 06:27:06 2019 From: athornton at gmail.com (Adam Thornton) Date: Wed, 28 Aug 2019 13:27:06 -0700 Subject: [TUHS] If not Linux, then what? In-Reply-To: References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> Message-ID: I was an ardent OS/2 supporter for a long time. Sure, IBM's anemic marketing, and their close-to-outright-hostility to 3rd-party developers didn't help. But what killed it, really, was how damn good its 16-bit support was. It *was* a better DOS than DOS and a better Windows than 3.11fW. So no one wrote to the relatively tiny market of 32-bit OS/2. I fear that had Linux not made the leap, MS might well have won. It's largely the AOL-fuelled explosion of popularity of the Internet and Windows ignoring same until too late that opened the door enough for Linux to jam its foot in. Hurd was, by the time of the '386 Unix Wars and early Linux, clearly not going to be a contender, I guess because it was about cool research features rather than running user-facing code. I kept waiting for a usable kernel to go with what Linux had already shown was a quite decent userspace, but eventually had better things to do with my life (like chase BeOS). It was like waiting for Perl 6--it missed its moment. Plan 9 and Amoeba were both really nifty. I never used Sprite. Neither one of them had much of a chance in the real world. Much like Unix itself, Linux's worse-is-better approach really worked. I have a hypothesis about Linux's ascendance too, which is a personal anecdote I am inflating to the status of hypothesis. As I recall, the *BSDs for 386 all assumed they owned the hard disk. Like, the whole thing. You couldn't, at least in 1992, create a multiboot system--or at least it was my strong impression you could not. I was an undergrad. I had one '386 at my disposal, with one hard disk, and, hey, I needed DOS and Windows to write my papers (I don't know about you, but I wanted to write in my room, where I could have my references at hand and be reasonably undisturbed; sure Framemaker was a much better setup than Word For Windows 1.2 but having to use it in the computer lab made it a nonstarter for me). Papers, and, well, to play games. Sure, that too. Linux let me defragment my drive, non-destructively repartition it, and create a dual-boot system, so that I could both use the computer for school and screw around on Linux. I'm probably not the only person for whom this was a decisive factor. Adam On Wed, Aug 28, 2019 at 1:08 PM Christopher Browne wrote: > On Mon, 26 Aug 2019 at 19:14, Arthur Krewat wrote: > >> >> https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel >> >> Leaving licensing and copyright issues out of this mental exercise, what >> would we have now if it wasn't for Linux? Not what you'd WANT it to be, >> although that can add to the discussion, but what WOULD it be? >> >> I'm not asking as a proponent of Linux. If anything, I was dragged >> kicking and screaming into the current day and have begrudgingly ceded >> my server space to Linux. >> >> But if not for Linux, would it be BSD? A System V variant? Or (the >> horror) Windows NT? >> > > I can make a firm "dunno" sound :-) > > Some facts can come together to point away from a number of > possibilities... > > - If you look at the number of hobbyist "Unix homages" that emerged at > around that time, it's clear that there was a sizable community of > interested folk willing to build their own thing, and that weren't > interested in Windows NT. (Nay, one should put that more strongly... That > had their minds set on something NOT from Microsoft.) So I think we can > cross Windows NT off the list. > > - OS/2 should briefly come on the list. It was likable in many ways, if > only IBM had actually supported it... But it suffers from something of the > same problem as Windows NT; there were a lot of folk that were only > slightly less despising of IBM at the time than of Microsoft. > > - Hurd was imagined to be the next thing... > > To borrow from my cookie file... > > "Of course 5 years from now that will be different, but 5 years from > now everyone will be running free GNU on their 200 MIPS, 64M > SPARCstation-5." -- Andrew Tanenbaum, 1992. > % > "You'll be rid of most of us when BSD-detox or GNU comes out, which > should happen in the next few months (yeah, right)." -- Richard Tobin, > 1992. [BSD did follow within a year] > % > "I am aware of the benefits of a micro kernel approach. However, the > fact remains that Linux is here, and GNU isn't --- and people have > been working on Hurd for a lot longer than Linus has been working on > Linux." -- Ted T'so, 1992. > > Ted has been on this thread, and should be amused (and slightly > disturbed!) that his old statements are being held here and there, ready to > trot out :-). > > In the absence of Linux, perhaps hackers would have flocked to Hurd, but > there was enough going on that there was plenty of room for them to have > done so anyways. > > I'm not sure what to blame on whatever happened post-1992, though I'd put > some on Microsoft Research having taken the wind out of Mach's sails by > hiring off a bunch of the relevant folk. In order for Hurd to "make it," > Mach has to "make it," too, and it looked like they were depending on CMU > to be behind that. (I'm not sure I'm right about that; happy to hear a > better story.) > > Anyway, Hurd *might* have been a "next thing," and I don't think the > popularity of Linux was enough to have completely taken wind out of its > sails, given that there's the dozens of "Unix homages" out there. > > - I'd like to imagine Plan 9 being an alternative, but it was "properly > commercial" for a goodly long time (hence not amenable to attaching waves > of hackers to it to add their favorite device drivers), and was never taken > as a serious answer. Many of us had admired it from afar via the Dr Dobbs > Journal issue (when was that? mid or late '90s?) but only from afar. > > - FreeBSD is the single best answer I can throw up as a possibility, as it > was the one actively targeting 80386 hardware. And that had the big risk > of the AT&T lawsuit lurking over it, so had that gone in a different > direction, then that is a branch sadly easily trimmed. > > If we lop both Linux and FreeBSD off the list of possibilities, I don't > imagine Windows NT or OS/2 bubble to the top, instead, a critical mass > would have stood behind ... something else, I'd think. I don't know which > to suggest. > -- > When confronted by a difficult problem, solve it by reducing it to the > question, "How would the Lone Ranger handle this?" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pechter at gmail.com Thu Aug 29 06:56:05 2019 From: pechter at gmail.com (William Pechter) Date: Wed, 28 Aug 2019 16:56:05 -0400 Subject: [TUHS] If not Linux, then what? In-Reply-To: References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> Message-ID: <03a959f8-e1a3-4765-a135-efa0bea5fbf2.maildroid@localhost> Actually, IIRC, you could use fdisk to split up drives in FreeBSD... I think I did that in the 1.02 days... The problem is the semantics of slices and partitions. Also *BSD, I recall, had to boot from a primary partition. I don't know if lilo cared and grub2 sure doesn't. Sent from pechter at gmail.com -----Original Message----- From: Adam Thornton To: The Eunuchs Hysterical Society Sent: Wed, 28 Aug 2019 16:28 Subject: Re: [TUHS] If not Linux, then what? I was an ardent OS/2 supporter for a long time. Sure, IBM's anemic marketing, and their close-to-outright-hostility to 3rd-party developers didn't help. But what killed it, really, was how damn good its 16-bit support was. It *was* a better DOS than DOS and a better Windows than 3.11fW. So no one wrote to the relatively tiny market of 32-bit OS/2. I fear that had Linux not made the leap, MS might well have won. It's largely the AOL-fuelled explosion of popularity of the Internet and Windows ignoring same until too late that opened the door enough for Linux to jam its foot in. Hurd was, by the time of the '386 Unix Wars and early Linux, clearly not going to be a contender, I guess because it was about cool research features rather than running user-facing code. I kept waiting for a usable kernel to go with what Linux had already shown was a quite decent userspace, but eventually had better things to do with my life (like chase BeOS). It was like waiting for Perl 6--it missed its moment. Plan 9 and Amoeba were both really nifty. I never used Sprite. Neither one of them had much of a chance in the real world. Much like Unix itself, Linux's worse-is-better approach really worked. I have a hypothesis about Linux's ascendance too, which is a personal anecdote I am inflating to the status of hypothesis. As I recall, the *BSDs for 386 all assumed they owned the hard disk. Like, the whole thing. You couldn't, at least in 1992, create a multiboot system--or at least it was my strong impression you could not. I was an undergrad. I had one '386 at my disposal, with one hard disk, and, hey, I needed DOS and Windows to write my papers (I don't know about you, but I wanted to write in my room, where I could have my references at hand and be reasonably undisturbed; sure Framemaker was a much better setup than Word For Windows 1.2 but having to use it in the computer lab made it a nonstarter for me). Papers, and, well, to play games. Sure, that too. Linux let me defragment my drive, non-destructively repartition it, and create a dual-boot system, so that I could both use the computer for school and screw around on Linux. I'm probably not the only person for whom this was a decisive factor. Adam On Wed, Aug 28, 2019 at 1:08 PM Christopher Browne wrote: > On Mon, 26 Aug 2019 at 19:14, Arthur Krewat wrote: > >> >> https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel >> >> Leaving licensing and copyright issues out of this mental exercise, what >> would we have now if it wasn't for Linux? Not what you'd WANT it to be, >> although that can add to the discussion, but what WOULD it be? >> >> I'm not asking as a proponent of Linux. If anything, I was dragged >> kicking and screaming into the current day and have begrudgingly ceded >> my server space to Linux. >> >> But if not for Linux, would it be BSD? A System V variant? Or (the >> horror) Windows NT? >> > > I can make a firm "dunno" sound :-) > > Some facts can come together to point away from a number of > possibilities... > > - If you look at the number of hobbyist "Unix homages" that emerged at > around that time, it's clear that there was a sizable community of > interested folk willing to build their own thing, and that weren't > interested in Windows NT. (Nay, one should put that more strongly... That > had their minds set on something NOT from Microsoft.) So I think we can > cross Windows NT off the list. > > - OS/2 should briefly come on the list. It was likable in many ways, if > only IBM had actually supported it... But it suffers from something of the > same problem as Windows NT; there were a lot of folk that were only > slightly less despising of IBM at the time than of Microsoft. > > - Hurd was imagined to be the next thing... > > To borrow from my cookie file... > > "Of course 5 years from now that will be different, but 5 years from > now everyone will be running free GNU on their 200 MIPS, 64M > SPARCstation-5." -- Andrew Tanenbaum, 1992. > % > "You'll be rid of most of us when BSD-detox or GNU comes out, which > should happen in the next few months (yeah, right)." -- Richard Tobin, > 1992. [BSD did follow within a year] > % > "I am aware of the benefits of a micro kernel approach. However, the > fact remains that Linux is here, and GNU isn't --- and people have > been working on Hurd for a lot longer than Linus has been working on > Linux." -- Ted T'so, 1992. > > Ted has been on this thread, and should be amused (and slightly > disturbed!) that his old statements are being held here and there, ready to > trot out :-). > > In the absence of Linux, perhaps hackers would have flocked to Hurd, but > there was enough going on that there was plenty of room for them to have > done so anyways. > > I'm not sure what to blame on whatever happened post-1992, though I'd put > some on Microsoft Research having taken the wind out of Mach's sails by > hiring off a bunch of the relevant folk. In order for Hurd to "make it," > Mach has to "make it," too, and it looked like they were depending on CMU > to be behind that. (I'm not sure I'm right about that; happy to hear a > better story.) > > Anyway, Hurd *might* have been a "next thing," and I don't think the > popularity of Linux was enough to have completely taken wind out of its > sails, given that there's the dozens of "Unix homages" out there. > > - I'd like to imagine Plan 9 being an alternative, but it was "properly > commercial" for a goodly long time (hence not amenable to attaching waves > of hackers to it to add their favorite device drivers), and was never taken > as a serious answer. Many of us had admired it from afar via the Dr Dobbs > Journal issue (when was that? mid or late '90s?) but only from afar. > > - FreeBSD is the single best answer I can throw up as a possibility, as it > was the one actively targeting 80386 hardware. And that had the big risk > of the AT&T lawsuit lurking over it, so had that gone in a different > direction, then that is a branch sadly easily trimmed. > > If we lop both Linux and FreeBSD off the list of possibilities, I don't > imagine Windows NT or OS/2 bubble to the top, instead, a critical mass > would have stood behind ... something else, I'd think. I don't know which > to suggest. > -- > When confronted by a difficult problem, solve it by reducing it to the > question, "How would the Lone Ranger handle this?" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.paulsen at firemail.de Thu Aug 29 07:02:17 2019 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Wed, 28 Aug 2019 23:02:17 +0200 Subject: [TUHS] If not Linux, then what? In-Reply-To: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> Message-ID: --- Ursprüngliche Nachricht --- Von: Arthur Krewat Datum: 27.08.2019 01:13:25 An: TUHS main list Betreff: [TUHS] If not Linux, then what? > But if not for Linux, would it be BSD? A System V variant? Or (the > horror) Windows NT? mainly variants of Windows, Unices in some niches. From robpike at gmail.com Thu Aug 29 07:54:28 2019 From: robpike at gmail.com (Rob Pike) Date: Thu, 29 Aug 2019 07:54:28 +1000 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: <201908281757.x7SHv9gj042779@tahoe.cs.Dartmouth.EDU> References: <201908281757.x7SHv9gj042779@tahoe.cs.Dartmouth.EDU> Message-ID: I think it was slightly later. I joined mid-1980 and VAXes to replace the 11/70 were being discussed but had not arrived. We needed to convert a lab into a VAX machine room and decide between BSD and Reiser, all of which happened in the second half of 1980. Reiser Unix got demand paging a little later, and it was spectacularly fast. I remember being gobsmacked when I saw a demo in early 1981. Dead ends everywhere. -rob On Thu, Aug 29, 2019 at 3:57 AM Doug McIlroy wrote: > > > How long was research running on a PDP-11 and when did they move to a > VAX? > > London and Reiser had ported Unix to the VAX, replete with virtual memory, > in 1978. By the time v7 was released (1979), Vaxen had become the workhorse > machines in Research. > > Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Thu Aug 29 07:55:00 2019 From: robpike at gmail.com (Rob Pike) Date: Thu, 29 Aug 2019 07:55:00 +1000 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: <201908281841.x7SIfQS7053036@tahoe.cs.Dartmouth.EDU> References: <201908281841.x7SIfQS7053036@tahoe.cs.Dartmouth.EDU> Message-ID: Reiser added paging and it was working well by early 1981. -rob On Thu, Aug 29, 2019 at 4:41 AM Doug McIlroy wrote: > > Doug McIlroy wrote: > > > >> > >>> How long was research running on a PDP-11 and when did they move to a > VAX? > >> > >> London and Reiser had ported Unix to the VAX, replete with virtual > memory, in 1978. By the time v7 was released (1979), Vaxen had become the > workhorse machines in Research. > >> > >> Doug > > > > So, what's the story on why the London/Reiser port didn't get adapted > > back by Research, and they ended up starting from 4.1 BSD? > > > > Thanks, > > > > Arnold > > > Sorry, what I said about London/Reiser is true, but not the whole story. > L/R didn't have demand paging; BSD did. > > Doug > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Aug 29 08:24:38 2019 From: clemc at ccc.com (Clem cole) Date: Wed, 28 Aug 2019 18:24:38 -0400 Subject: [TUHS] If not Linux, then what? In-Reply-To: <03a959f8-e1a3-4765-a135-efa0bea5fbf2.maildroid@localhost> References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <03a959f8-e1a3-4765-a135-efa0bea5fbf2.maildroid@localhost> Message-ID: <6A55D190-D7D6-4C1D-817C-5ED868A7E747@ccc.com> Absolutely. Bill Jolitiz wrote the original version of fdisk with a very small assist from me. I used to keep a 33m dos partition on my system if for no other reason than the diags all ran on dos Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > On Aug 28, 2019, at 4:56 PM, William Pechter wrote: > > Actually, IIRC, you could use fdisk to split up drives in FreeBSD... I think I did that in the 1.02 days... > > The problem is the semantics of slices and partitions. Also *BSD, I recall, had to boot from a primary partition. I don't know if lilo cared and grub2 sure doesn't. > > > Sent from pechter at gmail.com > > -----Original Message----- > From: Adam Thornton > To: The Eunuchs Hysterical Society > Sent: Wed, 28 Aug 2019 16:28 > Subject: Re: [TUHS] If not Linux, then what? > > I was an ardent OS/2 supporter for a long time. Sure, IBM's anemic marketing, and their close-to-outright-hostility to 3rd-party developers didn't help. But what killed it, really, was how damn good its 16-bit support was. It *was* a better DOS than DOS and a better Windows than 3.11fW. So no one wrote to the relatively tiny market of 32-bit OS/2. > > I fear that had Linux not made the leap, MS might well have won. It's largely the AOL-fuelled explosion of popularity of the Internet and Windows ignoring same until too late that opened the door enough for Linux to jam its foot in. > > Hurd was, by the time of the '386 Unix Wars and early Linux, clearly not going to be a contender, I guess because it was about cool research features rather than running user-facing code. I kept waiting for a usable kernel to go with what Linux had already shown was a quite decent userspace, but eventually had better things to do with my life (like chase BeOS). It was like waiting for Perl 6--it missed its moment. > > Plan 9 and Amoeba were both really nifty. I never used Sprite. Neither one of them had much of a chance in the real world. Much like Unix itself, Linux's worse-is-better approach really worked. > > I have a hypothesis about Linux's ascendance too, which is a personal anecdote I am inflating to the status of hypothesis. As I recall, the *BSDs for 386 all assumed they owned the hard disk. Like, the whole thing. You couldn't, at least in 1992, create a multiboot system--or at least it was my strong impression you could not. I was an undergrad. I had one '386 at my disposal, with one hard disk, and, hey, I needed DOS and Windows to write my papers (I don't know about you, but I wanted to write in my room, where I could have my references at hand and be reasonably undisturbed; sure Framemaker was a much better setup than Word For Windows 1.2 but having to use it in the computer lab made it a nonstarter for me). Papers, and, well, to play games. Sure, that too. > > Linux let me defragment my drive, non-destructively repartition it, and create a dual-boot system, so that I could both use the computer for school and screw around on Linux. I'm probably not the only person for whom this was a decisive factor. > > Adam > >> On Wed, Aug 28, 2019 at 1:08 PM Christopher Browne wrote: >>> On Mon, 26 Aug 2019 at 19:14, Arthur Krewat wrote: >> >>> https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel >>> >>> Leaving licensing and copyright issues out of this mental exercise, what >>> would we have now if it wasn't for Linux? Not what you'd WANT it to be, >>> although that can add to the discussion, but what WOULD it be? >>> >>> I'm not asking as a proponent of Linux. If anything, I was dragged >>> kicking and screaming into the current day and have begrudgingly ceded >>> my server space to Linux. >>> >>> But if not for Linux, would it be BSD? A System V variant? Or (the >>> horror) Windows NT? >> >> I can make a firm "dunno" sound :-) >> >> Some facts can come together to point away from a number of possibilities... >> >> - If you look at the number of hobbyist "Unix homages" that emerged at around that time, it's clear that there was a sizable community of interested folk willing to build their own thing, and that weren't interested in Windows NT. (Nay, one should put that more strongly... That had their minds set on something NOT from Microsoft.) So I think we can cross Windows NT off the list. >> >> - OS/2 should briefly come on the list. It was likable in many ways, if only IBM had actually supported it... But it suffers from something of the same problem as Windows NT; there were a lot of folk that were only slightly less despising of IBM at the time than of Microsoft. >> >> - Hurd was imagined to be the next thing... >> >> To borrow from my cookie file... >> >> "Of course 5 years from now that will be different, but 5 years from >> now everyone will be running free GNU on their 200 MIPS, 64M >> SPARCstation-5." -- Andrew Tanenbaum, 1992. >> % >> "You'll be rid of most of us when BSD-detox or GNU comes out, which >> should happen in the next few months (yeah, right)." -- Richard Tobin, >> 1992. [BSD did follow within a year] >> % >> "I am aware of the benefits of a micro kernel approach. However, the >> fact remains that Linux is here, and GNU isn't --- and people have >> been working on Hurd for a lot longer than Linus has been working on >> Linux." -- Ted T'so, 1992. >> >> Ted has been on this thread, and should be amused (and slightly disturbed!) that his old statements are being held here and there, ready to trot out :-). >> >> In the absence of Linux, perhaps hackers would have flocked to Hurd, but there was enough going on that there was plenty of room for them to have done so anyways. >> >> I'm not sure what to blame on whatever happened post-1992, though I'd put some on Microsoft Research having taken the wind out of Mach's sails by hiring off a bunch of the relevant folk. In order for Hurd to "make it," Mach has to "make it," too, and it looked like they were depending on CMU to be behind that. (I'm not sure I'm right about that; happy to hear a better story.) >> >> Anyway, Hurd *might* have been a "next thing," and I don't think the popularity of Linux was enough to have completely taken wind out of its sails, given that there's the dozens of "Unix homages" out there. >> >> - I'd like to imagine Plan 9 being an alternative, but it was "properly commercial" for a goodly long time (hence not amenable to attaching waves of hackers to it to add their favorite device drivers), and was never taken as a serious answer. Many of us had admired it from afar via the Dr Dobbs Journal issue (when was that? mid or late '90s?) but only from afar. >> >> - FreeBSD is the single best answer I can throw up as a possibility, as it was the one actively targeting 80386 hardware. And that had the big risk of the AT&T lawsuit lurking over it, so had that gone in a different direction, then that is a branch sadly easily trimmed. >> >> If we lop both Linux and FreeBSD off the list of possibilities, I don't imagine Windows NT or OS/2 bubble to the top, instead, a critical mass would have stood behind ... something else, I'd think. I don't know which to suggest. >> -- >> When confronted by a difficult problem, solve it by reducing it to the >> question, "How would the Lone Ranger handle this?" -------------- next part -------------- An HTML attachment was scrubbed... URL: From pechter at gmail.com Thu Aug 29 08:27:42 2019 From: pechter at gmail.com (William Pechter) Date: Wed, 28 Aug 2019 18:27:42 -0400 Subject: [TUHS] If not Linux, then what? In-Reply-To: References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> Message-ID: <283e3cc2-42ec-a554-602f-5fb67eca9e40@gmail.com> I tried three times to respond by phone but the lack of a decent environment for mail killed my first attempts. Anyway, without top posting: On 8/28/2019 4:27 PM, Adam Thornton wrote: > I was an ardent OS/2 supporter for a long time.  Sure, IBM's anemic > marketing, and their close-to-outright-hostility to 3rd-party > developers didn't help.  But what killed it, really, was how damn good > its 16-bit support was.  It *was* a better DOS than DOS and a better > Windows than 3.11fW.  So no one wrote to the relatively tiny market of > 32-bit OS/2. > OS/2 was slick and if they could've kept the W\indows 3.x compatibility (the Win32S was a sliding target that Microsoft kept changing.  There was a pretty decent Unix work-alike ported to the top of OS/2 that made most of the public domain and open source (the term didn't exist yet) stuff available. I could telnet into the box and run a pretty slick Unix work-alike shell.  Unfortunately, I left IBM and IBM dumped OS/2 support and future releases. > > I have a hypothesis about Linux's ascendance too, which is a personal > anecdote I am inflating to the status of hypothesis.  As I recall, the > *BSDs for 386 all assumed they owned the hard disk.  Like, the whole > thing.  You couldn't, at least in 1992, create a multiboot system--or > at least it was my strong impression you could not.  I was an > undergrad.  I had one '386 at my disposal, with one hard disk, and, > hey, I needed DOS and Windows to write my papers (I don't know about > you, but I wanted to write in my room, where I could have my > references at hand and be reasonably undisturbed; sure Framemaker was > a much better setup than Word For Windows 1.2 but having to use it in > the computer lab made it a nonstarter for me).  Papers, and, well, to > play games.  Sure, that too. > > I love Framemaker.  I run a 2nd hand version of Windows Framemaker since I no longer have any Unix boxes that would run the Unix version unless I pull an old CD and rebuild a SunOS 4 box.  Wonder if the NVRAM battery's dead in the Sparc2 or Sparc10? I did a training Unix Admin for DC/OSx course for Pyramid that could print a full doc with instructors guide (on back side of the pages) and all the pages and overheads for the class in a single Frame doc.  And everyone told me it couldn't be done in Frame 1.2 or 1.3 on Pyramid OSx. Sure you can if you force it. Come here and hold  my Xterminal keyboard and my beer. 8-) Anyway, I thought I had a 386 running with Win3.1 and OS/2 and FreeBSD on a single drive.  I checked the FreeBSD archives and it COULD install in a primary partition (partition type 165) and share the disk with other OS types. The one thing that was a PITA was the docs --- since they used the partition term as well as "disk slices" with partitions meaning ONE thing to Unix folks and another to DOS/Windows/OS2 types.  So it was explained multiple times on the FreeBSD mailing lists.  I never had any issue with it and until ZFS which wants it's own drives to control (and drives are now cheap and large -- so why not splurge a bit for data protection...) Bill From clemc at ccc.com Thu Aug 29 08:28:10 2019 From: clemc at ccc.com (Clem cole) Date: Wed, 28 Aug 2019 18:28:10 -0400 Subject: [TUHS] If not Linux, then what? In-Reply-To: References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> Message-ID: <016BFF16-C490-425D-8168-3D59DCCA6A21@ccc.com> Not true 386BSD used fdisk. It shared the disk just fine. In fact I liked the way it sliced the disk much better than Slackware in those days. Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > On Aug 28, 2019, at 4:27 PM, Adam Thornton wrote: > > I was an ardent OS/2 supporter for a long time. Sure, IBM's anemic marketing, and their close-to-outright-hostility to 3rd-party developers didn't help. But what killed it, really, was how damn good its 16-bit support was. It *was* a better DOS than DOS and a better Windows than 3.11fW. So no one wrote to the relatively tiny market of 32-bit OS/2. > > I fear that had Linux not made the leap, MS might well have won. It's largely the AOL-fuelled explosion of popularity of the Internet and Windows ignoring same until too late that opened the door enough for Linux to jam its foot in. > > Hurd was, by the time of the '386 Unix Wars and early Linux, clearly not going to be a contender, I guess because it was about cool research features rather than running user-facing code. I kept waiting for a usable kernel to go with what Linux had already shown was a quite decent userspace, but eventually had better things to do with my life (like chase BeOS). It was like waiting for Perl 6--it missed its moment. > > Plan 9 and Amoeba were both really nifty. I never used Sprite. Neither one of them had much of a chance in the real world. Much like Unix itself, Linux's worse-is-better approach really worked. > > I have a hypothesis about Linux's ascendance too, which is a personal anecdote I am inflating to the status of hypothesis. As I recall, the *BSDs for 386 all assumed they owned the hard disk. Like, the whole thing. You couldn't, at least in 1992, create a multiboot system--or at least it was my strong impression you could not. I was an undergrad. I had one '386 at my disposal, with one hard disk, and, hey, I needed DOS and Windows to write my papers (I don't know about you, but I wanted to write in my room, where I could have my references at hand and be reasonably undisturbed; sure Framemaker was a much better setup than Word For Windows 1.2 but having to use it in the computer lab made it a nonstarter for me). Papers, and, well, to play games. Sure, that too. > > Linux let me defragment my drive, non-destructively repartition it, and create a dual-boot system, so that I could both use the computer for school and screw around on Linux. I'm probably not the only person for whom this was a decisive factor. > > Adam > >> On Wed, Aug 28, 2019 at 1:08 PM Christopher Browne wrote: >>> On Mon, 26 Aug 2019 at 19:14, Arthur Krewat wrote: >> >>> https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel >>> >>> Leaving licensing and copyright issues out of this mental exercise, what >>> would we have now if it wasn't for Linux? Not what you'd WANT it to be, >>> although that can add to the discussion, but what WOULD it be? >>> >>> I'm not asking as a proponent of Linux. If anything, I was dragged >>> kicking and screaming into the current day and have begrudgingly ceded >>> my server space to Linux. >>> >>> But if not for Linux, would it be BSD? A System V variant? Or (the >>> horror) Windows NT? >> >> I can make a firm "dunno" sound :-) >> >> Some facts can come together to point away from a number of possibilities... >> >> - If you look at the number of hobbyist "Unix homages" that emerged at around that time, it's clear that there was a sizable community of interested folk willing to build their own thing, and that weren't interested in Windows NT. (Nay, one should put that more strongly... That had their minds set on something NOT from Microsoft.) So I think we can cross Windows NT off the list. >> >> - OS/2 should briefly come on the list. It was likable in many ways, if only IBM had actually supported it... But it suffers from something of the same problem as Windows NT; there were a lot of folk that were only slightly less despising of IBM at the time than of Microsoft. >> >> - Hurd was imagined to be the next thing... >> >> To borrow from my cookie file... >> >> "Of course 5 years from now that will be different, but 5 years from >> now everyone will be running free GNU on their 200 MIPS, 64M >> SPARCstation-5." -- Andrew Tanenbaum, 1992. >> % >> "You'll be rid of most of us when BSD-detox or GNU comes out, which >> should happen in the next few months (yeah, right)." -- Richard Tobin, >> 1992. [BSD did follow within a year] >> % >> "I am aware of the benefits of a micro kernel approach. However, the >> fact remains that Linux is here, and GNU isn't --- and people have >> been working on Hurd for a lot longer than Linus has been working on >> Linux." -- Ted T'so, 1992. >> >> Ted has been on this thread, and should be amused (and slightly disturbed!) that his old statements are being held here and there, ready to trot out :-). >> >> In the absence of Linux, perhaps hackers would have flocked to Hurd, but there was enough going on that there was plenty of room for them to have done so anyways. >> >> I'm not sure what to blame on whatever happened post-1992, though I'd put some on Microsoft Research having taken the wind out of Mach's sails by hiring off a bunch of the relevant folk. In order for Hurd to "make it," Mach has to "make it," too, and it looked like they were depending on CMU to be behind that. (I'm not sure I'm right about that; happy to hear a better story.) >> >> Anyway, Hurd *might* have been a "next thing," and I don't think the popularity of Linux was enough to have completely taken wind out of its sails, given that there's the dozens of "Unix homages" out there. >> >> - I'd like to imagine Plan 9 being an alternative, but it was "properly commercial" for a goodly long time (hence not amenable to attaching waves of hackers to it to add their favorite device drivers), and was never taken as a serious answer. Many of us had admired it from afar via the Dr Dobbs Journal issue (when was that? mid or late '90s?) but only from afar. >> >> - FreeBSD is the single best answer I can throw up as a possibility, as it was the one actively targeting 80386 hardware. And that had the big risk of the AT&T lawsuit lurking over it, so had that gone in a different direction, then that is a branch sadly easily trimmed. >> >> If we lop both Linux and FreeBSD off the list of possibilities, I don't imagine Windows NT or OS/2 bubble to the top, instead, a critical mass would have stood behind ... something else, I'd think. I don't know which to suggest. >> -- >> When confronted by a difficult problem, solve it by reducing it to the >> question, "How would the Lone Ranger handle this?" -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggm at algebras.org Thu Aug 29 08:29:03 2019 From: ggm at algebras.org (George Michaelson) Date: Thu, 29 Aug 2019 08:29:03 +1000 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: References: <201908281841.x7SIfQS7053036@tahoe.cs.Dartmouth.EDU> Message-ID: This is an object lesson in not making assumptions about things. I had always assumed the V in UNIX 32V stood for something which went to demand paging, from 'Virtual Addressing'. Turns out: I was wrong. One other note about sockets: The original 4.2 port had to be used by a lot of people without the ethernet, because we didn't have the DEC ethernet card it was written to. This made unix domain sockets very interesting because you could test in them. Except: the very first test program somebody wrote at Leeds university to create and write to a unix domain socket in /tmp crashed the vax. ... (this was around 1982/3) -We were warned off using sockets until the first patch tape came in the post. The Berkeley lawyers were amazing. I like to think 'shakespear witches' or 'evil gnomes' -We had changed staff in some functional role, and when we came to do licence renewal for the upgrade from 4.1 They insisted we find the mouldering body of the ex appointee and get them to countersign (press the dead flesh in a pot of ink and put on the paper?) before they'd re-issue. I'd never seen documents (a) printed on this bizarre page size called 'legal and (b) actually *embossed* by the university seal.. This was some serious magic going down. In my nightmares, somebody in mid-western nondescript university of somewhereville is screaming "I CANT GET THE ORIGINAL SIGNATURE" and the Berkeley lawyers just shrug and walk away from the deal. This was also the release which brought T/Roff drivers for xerographic process printers. They emitted wet, shiny, even slimy pages in some process I don't want to understand, all of which bore cut marks on the side (roll feed, before A4 printers existed) marking this US legal thing. Cut at the mark? Won't fit a ring-binder we own in the entire University... Mike Lesk told me the code had 'witticisms' such as an extra emitted char on \r to ensure the specific printer it was written for didn't stuff up TBL output. -G On Thu, Aug 29, 2019 at 7:55 AM Rob Pike wrote: > > Reiser added paging and it was working well by early 1981. > > -rob > > > On Thu, Aug 29, 2019 at 4:41 AM Doug McIlroy wrote: >> >> > Doug McIlroy wrote: >> > >> >> >> >>> How long was research running on a PDP-11 and when did they move to a VAX? >> >> >> >> London and Reiser had ported Unix to the VAX, replete with virtual memory, in 1978. By the time v7 was released (1979), Vaxen had become the workhorse machines in Research. >> >> >> >> Doug >> > >> > So, what's the story on why the London/Reiser port didn't get adapted >> > back by Research, and they ended up starting from 4.1 BSD? >> > >> > Thanks, >> > >> > Arnold >> >> >> Sorry, what I said about London/Reiser is true, but not the whole story. L/R didn't have demand paging; BSD did. >> >> Doug >> From pechter at gmail.com Thu Aug 29 08:36:34 2019 From: pechter at gmail.com (William Pechter) Date: Wed, 28 Aug 2019 18:36:34 -0400 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: References: <201908281841.x7SIfQS7053036@tahoe.cs.Dartmouth.EDU> Message-ID: I could've sworn 4.x BSD supported Micom Internan NI1010 or some other early ethernet like 3com as well as the DEC boards. Anyone have the 4.1 or 4.2 BSD docs handy.  Mine are boxed away for safe keeping. On 8/28/2019 6:29 PM, George Michaelson wrote: > This is an object lesson in not making assumptions about things. I had > always assumed the V in UNIX 32V stood for something which went to > demand paging, from 'Virtual Addressing'. Turns out: I was wrong. > > One other note about sockets: The original 4.2 port had to be used by > a lot of people without the ethernet, because we didn't have the DEC > ethernet card it was written to. This made unix domain sockets very > interesting because you could test in them. Except: the very first > test program somebody wrote at Leeds university to create and write to > a unix domain socket in /tmp crashed the vax. ... (this was around > 1982/3) -We were warned off using sockets until the first patch tape > came in the post. > > From athornton at gmail.com Thu Aug 29 08:48:43 2019 From: athornton at gmail.com (Adam Thornton) Date: Wed, 28 Aug 2019 15:48:43 -0700 Subject: [TUHS] If not Linux, then what? In-Reply-To: <016BFF16-C490-425D-8168-3D59DCCA6A21@ccc.com> References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <016BFF16-C490-425D-8168-3D59DCCA6A21@ccc.com> Message-ID: It probably was the partition/slice confusion that, well, confused me, then. My experience, such as it was, was from the DOS world. Although the period I am thinking of was way pre-slackware. You had a boot floppy and a root floppy and that was about it, I think. I think the kernel had MFM/RLL disk drivers for an ISA bus interface? I remember that I could boot the thing on the MCA machines in the lab but not actually install it (even had I been allowed to), and I think installation was pretty much fdisk/mkfs, extract the tarball...I don't remember how you installed the bootloader...which I guess was already LILO at that point? Probably just dding the bootsector to the first physical sector of the disk? Version 0.08 or so, maybe? It was quite a while ago, and I was drunk for most of college, so....memory is imprecise at best. On Wed, Aug 28, 2019 at 3:28 PM Clem cole wrote: > Not true 386BSD used fdisk. It shared the disk just fine. In fact I > liked the way it sliced the disk much better than Slackware in those days. > > Sent from my PDP-7 Running UNIX V0 expect things to be almost but not > quite. > > On Aug 28, 2019, at 4:27 PM, Adam Thornton wrote: > > I was an ardent OS/2 supporter for a long time. Sure, IBM's anemic > marketing, and their close-to-outright-hostility to 3rd-party developers > didn't help. But what killed it, really, was how damn good its 16-bit > support was. It *was* a better DOS than DOS and a better Windows than > 3.11fW. So no one wrote to the relatively tiny market of 32-bit OS/2. > > I fear that had Linux not made the leap, MS might well have won. It's > largely the AOL-fuelled explosion of popularity of the Internet and Windows > ignoring same until too late that opened the door enough for Linux to jam > its foot in. > > Hurd was, by the time of the '386 Unix Wars and early Linux, clearly not > going to be a contender, I guess because it was about cool research > features rather than running user-facing code. I kept waiting for a usable > kernel to go with what Linux had already shown was a quite decent > userspace, but eventually had better things to do with my life (like chase > BeOS). It was like waiting for Perl 6--it missed its moment. > > Plan 9 and Amoeba were both really nifty. I never used Sprite. Neither > one of them had much of a chance in the real world. Much like Unix itself, > Linux's worse-is-better approach really worked. > > I have a hypothesis about Linux's ascendance too, which is a personal > anecdote I am inflating to the status of hypothesis. As I recall, the > *BSDs for 386 all assumed they owned the hard disk. Like, the whole > thing. You couldn't, at least in 1992, create a multiboot system--or at > least it was my strong impression you could not. I was an undergrad. I > had one '386 at my disposal, with one hard disk, and, hey, I needed DOS and > Windows to write my papers (I don't know about you, but I wanted to write > in my room, where I could have my references at hand and be reasonably > undisturbed; sure Framemaker was a much better setup than Word For Windows > 1.2 but having to use it in the computer lab made it a nonstarter for me). > Papers, and, well, to play games. Sure, that too. > > Linux let me defragment my drive, non-destructively repartition it, and > create a dual-boot system, so that I could both use the computer for school > and screw around on Linux. I'm probably not the only person for whom this > was a decisive factor. > > Adam > > On Wed, Aug 28, 2019 at 1:08 PM Christopher Browne > wrote: > >> On Mon, 26 Aug 2019 at 19:14, Arthur Krewat wrote: >> >>> >>> https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel >>> >>> Leaving licensing and copyright issues out of this mental exercise, what >>> would we have now if it wasn't for Linux? Not what you'd WANT it to be, >>> although that can add to the discussion, but what WOULD it be? >>> >>> I'm not asking as a proponent of Linux. If anything, I was dragged >>> kicking and screaming into the current day and have begrudgingly ceded >>> my server space to Linux. >>> >>> But if not for Linux, would it be BSD? A System V variant? Or (the >>> horror) Windows NT? >>> >> >> I can make a firm "dunno" sound :-) >> >> Some facts can come together to point away from a number of >> possibilities... >> >> - If you look at the number of hobbyist "Unix homages" that emerged at >> around that time, it's clear that there was a sizable community of >> interested folk willing to build their own thing, and that weren't >> interested in Windows NT. (Nay, one should put that more strongly... That >> had their minds set on something NOT from Microsoft.) So I think we can >> cross Windows NT off the list. >> >> - OS/2 should briefly come on the list. It was likable in many ways, if >> only IBM had actually supported it... But it suffers from something of the >> same problem as Windows NT; there were a lot of folk that were only >> slightly less despising of IBM at the time than of Microsoft. >> >> - Hurd was imagined to be the next thing... >> >> To borrow from my cookie file... >> >> "Of course 5 years from now that will be different, but 5 years from >> now everyone will be running free GNU on their 200 MIPS, 64M >> SPARCstation-5." -- Andrew Tanenbaum, 1992. >> % >> "You'll be rid of most of us when BSD-detox or GNU comes out, which >> should happen in the next few months (yeah, right)." -- Richard Tobin, >> 1992. [BSD did follow within a year] >> % >> "I am aware of the benefits of a micro kernel approach. However, the >> fact remains that Linux is here, and GNU isn't --- and people have >> been working on Hurd for a lot longer than Linus has been working on >> Linux." -- Ted T'so, 1992. >> >> Ted has been on this thread, and should be amused (and slightly >> disturbed!) that his old statements are being held here and there, ready to >> trot out :-). >> >> In the absence of Linux, perhaps hackers would have flocked to Hurd, but >> there was enough going on that there was plenty of room for them to have >> done so anyways. >> >> I'm not sure what to blame on whatever happened post-1992, though I'd put >> some on Microsoft Research having taken the wind out of Mach's sails by >> hiring off a bunch of the relevant folk. In order for Hurd to "make it," >> Mach has to "make it," too, and it looked like they were depending on CMU >> to be behind that. (I'm not sure I'm right about that; happy to hear a >> better story.) >> >> Anyway, Hurd *might* have been a "next thing," and I don't think the >> popularity of Linux was enough to have completely taken wind out of its >> sails, given that there's the dozens of "Unix homages" out there. >> >> - I'd like to imagine Plan 9 being an alternative, but it was "properly >> commercial" for a goodly long time (hence not amenable to attaching waves >> of hackers to it to add their favorite device drivers), and was never taken >> as a serious answer. Many of us had admired it from afar via the Dr Dobbs >> Journal issue (when was that? mid or late '90s?) but only from afar. >> >> - FreeBSD is the single best answer I can throw up as a possibility, as >> it was the one actively targeting 80386 hardware. And that had the big >> risk of the AT&T lawsuit lurking over it, so had that gone in a different >> direction, then that is a branch sadly easily trimmed. >> >> If we lop both Linux and FreeBSD off the list of possibilities, I don't >> imagine Windows NT or OS/2 bubble to the top, instead, a critical mass >> would have stood behind ... something else, I'd think. I don't know which >> to suggest. >> -- >> When confronted by a difficult problem, solve it by reducing it to the >> question, "How would the Lone Ranger handle this?" >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From krewat at kilonet.net Thu Aug 29 08:53:42 2019 From: krewat at kilonet.net (Arthur Krewat) Date: Wed, 28 Aug 2019 18:53:42 -0400 Subject: [TUHS] If not Linux, then what? In-Reply-To: <283e3cc2-42ec-a554-602f-5fb67eca9e40@gmail.com> References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <283e3cc2-42ec-a554-602f-5fb67eca9e40@gmail.com> Message-ID: On 8/28/2019 6:27 PM, William Pechter wrote: > I checked the FreeBSD archives and it COULD install in a primary > partition (partition type 165) and share the disk with other OS types. At some point, I had written a boot partition hook to select which partition to boot, and set it as Primary on the fly by modifying the partition table. The comments below are from a precursor to that. Sadly I do not have the source code for the later version where I had added the selection menu and actual partition table update to. Note the reason I started it ;) I know I was dual booting FreeBSD or maybe Consensys (SVR4.2) with DOS at some point, and based on the dates on this source code, it would have been around the second half of 1992. PART.ASM: Title PART - Partition table boot-up program. Comment *         (C) 1992 Kilowatt Computing - Arthur Krewat         Started Feb 2, 1992         Initiated by the Michelangelo Virus of 1/1992 - I figured if I         have a program using sector 0 of the hard drive and something writes         to it, it SHOULD crash - unless the virus is particularly         intelligent. And we all know writers of virii are NOT or else they'd         be doing something INTELLIGENT with their time. * Later on in the file: Partb   Db      00H,"Unknown - empty",0 ;System indicators.         Db      01H,"DOS (12 bit FAT)",0         Db      02H,"XENIX",0         Db      04H,"DOS (16 bit FAT)",0         Db      05H,"DOS - extended partition",0         Db      06H,"DOS 4.0",0         Db      51H,"Ontrack extended partition",0         Db      64H,"Novell",0         Db      75H,"PCIX",0         Db      0DBH,"CP/M",0         Db      0FFH,"BBT",0         Db      0 From pechter at gmail.com Thu Aug 29 09:01:28 2019 From: pechter at gmail.com (William Pechter) Date: Wed, 28 Aug 2019 19:01:28 -0400 Subject: [TUHS] If not Linux, then what? In-Reply-To: References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <016BFF16-C490-425D-8168-3D59DCCA6A21@ccc.com> Message-ID: <13e8e297-0b27-ac95-8fd4-e2a9b28d0b64@gmail.com> On 8/28/2019 6:48 PM, Adam Thornton wrote: > It probably was the partition/slice confusion that, well, confused me, > then.  My experience, such as it was, was from the DOS world. As was mine mostly 8-) I remember it from the PITA it was to translate in my head.  Unix folks looked at partitions as /dev/dsk/0s0->0s7 (I think 7 was the SVR2 maximum.  The "Unix" partitions fit inside the FDISK partition or dos slice... The dos guys looked at it kind of like the fdisk space disk0 partition 3 (for example) was the partition and then the BSD folks broke that in to /dev/sd0a /dev/sd0b /dev/sd0c etc. I did a little SunOS and SysV along with Dos and Windows and could make them coexist as long as there was an open primary dos partition. > > Although the period I am thinking of was way pre-slackware.  You had a > boot floppy and a root floppy and that was about it, I think.  I think > the kernel had MFM/RLL disk drivers for an ISA bus interface?  I > remember that I could boot the thing on the MCA machines in the lab > but not actually install it (even had I been allowed to), and I think > installation was pretty much fdisk/mkfs, extract the tarball...I don't > remember how you installed the bootloader...which I guess was already > LILO at that point? Probably just dding the bootsector to the first > physical sector of the disk?  Version 0.08 or so, maybe? > Sounds like SLS -- Soft Landing System -- which later was pretty much replaced with Slackware.  I used the early MCA stuff on PS/2's at IBM for a while.  Most of the PS/2 stuff we had was SCSI.  The boot loader was lilo.  It could go in the partition space or disk mbr.  See:https://www.ibm.com/developerworks/library/l-bootload/index.html > It was quite a while ago, and I was drunk for most of college, > so....memory is imprecise at best. > > On Wed, Aug 28, 2019 at 3:28 PM Clem cole > wrote: > > Not true 386BSD used fdisk.  It shared the disk just fine.  In > fact I liked the way it sliced the disk much better than Slackware > in those days. > > Sent from my PDP-7 Running UNIX V0 expect things to be almost but > not quite. > > On Aug 28, 2019, at 4:27 PM, Adam Thornton > wrote: > >> I was an ardent OS/2 supporter for a long time. Sure, IBM's >> anemic marketing, and their close-to-outright-hostility to >> 3rd-party developers didn't help.  But what killed it, really, >> was how damn good its 16-bit support was.  It *was* a better DOS >> than DOS and a better Windows than 3.11fW.  So no one wrote to >> the relatively tiny market of 32-bit OS/2. >> >> I fear that had Linux not made the leap, MS might well have won.  >> It's largely the AOL-fuelled explosion of popularity of the >> Internet and Windows ignoring same until too late that opened the >> door enough for Linux to jam its foot in. >> >> Hurd was, by the time of the '386 Unix Wars and early Linux, >> clearly not going to be a contender, I guess because it was about >> cool research features rather than running user-facing code.  I >> kept waiting for a usable kernel to go with what Linux had >> already shown was a quite decent userspace, but eventually had >> better things to do with my life (like chase BeOS).  It was like >> waiting for Perl 6--it missed its moment. >> >> Plan 9 and Amoeba were both really nifty.    I never used >> Sprite.  Neither one of them had much of a chance in the real >> world.  Much like Unix itself, Linux's worse-is-better approach >> really worked. >> >> I have a hypothesis about Linux's ascendance too, which is a >> personal anecdote I am inflating to the status of hypothesis.  As >> I recall, the *BSDs for 386 all assumed they owned the hard >> disk.  Like, the whole thing.  You couldn't, at least in 1992, >> create a multiboot system--or at least it was my strong >> impression you could not.  I was an undergrad.  I had one '386 at >> my disposal, with one hard disk, and, hey, I needed DOS and >> Windows to write my papers (I don't know about you, but I wanted >> to write in my room, where I could have my references at hand and >> be reasonably undisturbed; sure Framemaker was a much better >> setup than Word For Windows 1.2 but having to use it in the >> computer lab made it a nonstarter for me).  Papers, and, well, to >> play games.  Sure, that too. >> >> Linux let me defragment my drive, non-destructively repartition >> it, and create a dual-boot system, so that I could both use the >> computer for school and screw around on Linux.  I'm probably not >> the only person for whom this was a decisive factor. >> >> Adam >> >> On Wed, Aug 28, 2019 at 1:08 PM Christopher Browne >> > wrote: >> >> On Mon, 26 Aug 2019 at 19:14, Arthur Krewat >> > wrote: >> >> https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel >> >> Leaving licensing and copyright issues out of this mental >> exercise, what >> would we have now if it wasn't for Linux? Not what you'd >> WANT it to be, >> although that can add to the discussion, but what WOULD >> it be? >> >> I'm not asking as a proponent of Linux. If anything, I >> was dragged >> kicking and screaming into the current day and have >> begrudgingly ceded >> my server space to Linux. >> >> But if not for Linux, would it be BSD? A System V >> variant? Or (the >> horror) Windows NT? >> >> >> I can make a firm "dunno" sound :-) >> >> Some facts can come together to point away from a number of >> possibilities... >> >> - If you look at the number of hobbyist "Unix homages" that >> emerged at around that time, it's clear that there was a >> sizable community of interested folk willing to build their >> own thing, and that weren't interested in Windows NT.  (Nay, >> one should put that more strongly...  That had their minds >> set on something NOT from Microsoft.)  So I think we can >> cross Windows NT off the list. >> >> - OS/2 should briefly come on the list.  It was likable in >> many ways, if only IBM had actually supported it...  But it >> suffers from something of the same problem as Windows NT; >> there were a lot of folk that were only slightly less >> despising of IBM at the time than of Microsoft. >> >> - Hurd was imagined to be the next thing... >> >> To borrow from my cookie file... >> >> "Of course 5  years from now that will be different,  but 5 >> years from >> now  everyone  will  be  running  free  GNU on  their  200 >>  MIPS,  64M >> SPARCstation-5."  -- Andrew Tanenbaum, 1992. >> % >> "You'll be  rid of most of us  when BSD-detox or GNU  comes >> out, which >> should happen in the next few months (yeah, right)." -- >> Richard Tobin, >> 1992. [BSD did follow within a year] >> % >> "I am aware of the benefits  of a micro kernel approach.  >> However, the >> fact remains  that Linux is  here, and GNU  isn't --- and >>  people have >> been working on Hurd for a lot longer than Linus has been >> working on >> Linux." -- Ted T'so, 1992. >> >> Ted has been on this thread, and should be amused (and >> slightly disturbed!) that his old statements are being held >> here and there, ready to trot out :-). >> >> In the absence of Linux, perhaps hackers would have flocked >> to Hurd, but there was enough going on that there was plenty >> of room for them to have done so anyways. >> >> I'm not sure what to blame on whatever happened post-1992, >> though I'd put some on Microsoft Research having taken the >> wind out of Mach's sails by hiring off a bunch of the >> relevant folk.  In order for Hurd to "make it," Mach has to >> "make it," too, and it looked like they were depending on CMU >> to be behind that. (I'm not sure I'm right about that; happy >> to hear a better story.) >> >> Anyway, Hurd *might* have been a "next thing," and I don't >> think the popularity of Linux was enough to have completely >> taken wind out of its sails, given that there's the dozens of >> "Unix homages" out there. >> >> - I'd like to imagine Plan 9 being an alternative, but it was >> "properly commercial" for a goodly long time (hence not >> amenable to attaching waves of hackers to it to add their >> favorite device drivers), and was never taken as a serious >> answer.  Many of us had admired it from afar via the Dr Dobbs >> Journal issue (when was that?  mid or late '90s?) but only >> from afar. >> >> - FreeBSD is the single best answer I can throw up as a >> possibility, as it was the one actively targeting 80386 >> hardware.  And that had the big risk of the AT&T lawsuit >> lurking over it, so had that gone in a different direction, >> then that is a branch sadly easily trimmed. >> >> If we lop both Linux and FreeBSD off the list of >> possibilities, I don't imagine Windows NT or OS/2 bubble to >> the top, instead, a critical mass would have stood behind ... >> something else, I'd think.  I don't know which to suggest. >> -- >> When confronted by a difficult problem, solve it by reducing >> it to the >> question, "How would the Lone Ranger handle this?" >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From krewat at kilonet.net Thu Aug 29 09:02:40 2019 From: krewat at kilonet.net (Arthur Krewat) Date: Wed, 28 Aug 2019 19:02:40 -0400 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: References: <201908281841.x7SIfQS7053036@tahoe.cs.Dartmouth.EDU> Message-ID: <0326ec79-b962-e518-9f4e-dfa80a7aca10@kilonet.net> On 8/28/2019 6:36 PM, William Pechter wrote: > I could've sworn 4.x BSD supported Micom Internan NI1010 or some other > early > ethernet like 3com as well as the DEC boards. I know some VAX-11/750's running BSD 4.2 were running NI1010's - I don't know if that was because someone had made/found a driver and installed it, or it was native. Maybe backported from 4.3. I think I might actually have one of those 1010's and I'm pretty sure I have the driver development guide for it (tech specs). Looking at the 4.3 sources I got from the place that had these VAXs, there's this. ./src/nfsdist/32_43.FCS/sys/vaxif/if_il.c /* @(#)if_il.c  1.4 87/07/22 3.2/4.3NFSSRC */ /*  * Copyright (c) 1982, 1986 Regents of the University of California.  * All rights reserved.  The Berkeley software License Agreement  * specifies the terms and conditions for redistribution.  *  *      @(#)if_il.c     7.1 (Berkeley) 6/5/86  */ #include "il.h" #if NIL > 0 /*  * Interlan Ethernet Communications Controller interface  */ From gregg.drwho8 at gmail.com Thu Aug 29 09:04:27 2019 From: gregg.drwho8 at gmail.com (Gregg Levine) Date: Wed, 28 Aug 2019 19:04:27 -0400 Subject: [TUHS] If not Linux, then what? In-Reply-To: <016BFF16-C490-425D-8168-3D59DCCA6A21@ccc.com> References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <016BFF16-C490-425D-8168-3D59DCCA6A21@ccc.com> Message-ID: Hello! I can certainly attest to that one. The partition methods Slackware was using for releases before 3.0 were stranger then a lot of things. For release 3.0 and later it all started to make sense. I had more problems thought figuring out why several others really wanted me to break up the disk into a batch of individual ones...... However while exploring both NetBSD and FreeBSD I did workout why they wanted the disk broken out into those slices. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again." On Wed, Aug 28, 2019 at 6:29 PM Clem cole wrote: > > Not true 386BSD used fdisk. It shared the disk just fine. In fact I liked the way it sliced the disk much better than Slackware in those days. > > Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > > On Aug 28, 2019, at 4:27 PM, Adam Thornton wrote: > > I was an ardent OS/2 supporter for a long time. Sure, IBM's anemic marketing, and their close-to-outright-hostility to 3rd-party developers didn't help. But what killed it, really, was how damn good its 16-bit support was. It *was* a better DOS than DOS and a better Windows than 3.11fW. So no one wrote to the relatively tiny market of 32-bit OS/2. > > I fear that had Linux not made the leap, MS might well have won. It's largely the AOL-fuelled explosion of popularity of the Internet and Windows ignoring same until too late that opened the door enough for Linux to jam its foot in. > > Hurd was, by the time of the '386 Unix Wars and early Linux, clearly not going to be a contender, I guess because it was about cool research features rather than running user-facing code. I kept waiting for a usable kernel to go with what Linux had already shown was a quite decent userspace, but eventually had better things to do with my life (like chase BeOS). It was like waiting for Perl 6--it missed its moment. > > Plan 9 and Amoeba were both really nifty. I never used Sprite. Neither one of them had much of a chance in the real world. Much like Unix itself, Linux's worse-is-better approach really worked. > > I have a hypothesis about Linux's ascendance too, which is a personal anecdote I am inflating to the status of hypothesis. As I recall, the *BSDs for 386 all assumed they owned the hard disk. Like, the whole thing. You couldn't, at least in 1992, create a multiboot system--or at least it was my strong impression you could not. I was an undergrad. I had one '386 at my disposal, with one hard disk, and, hey, I needed DOS and Windows to write my papers (I don't know about you, but I wanted to write in my room, where I could have my references at hand and be reasonably undisturbed; sure Framemaker was a much better setup than Word For Windows 1.2 but having to use it in the computer lab made it a nonstarter for me). Papers, and, well, to play games. Sure, that too. > > Linux let me defragment my drive, non-destructively repartition it, and create a dual-boot system, so that I could both use the computer for school and screw around on Linux. I'm probably not the only person for whom this was a decisive factor. > > Adam > > On Wed, Aug 28, 2019 at 1:08 PM Christopher Browne wrote: >> >> On Mon, 26 Aug 2019 at 19:14, Arthur Krewat wrote: >>> >>> https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel >>> >>> Leaving licensing and copyright issues out of this mental exercise, what >>> would we have now if it wasn't for Linux? Not what you'd WANT it to be, >>> although that can add to the discussion, but what WOULD it be? >>> >>> I'm not asking as a proponent of Linux. If anything, I was dragged >>> kicking and screaming into the current day and have begrudgingly ceded >>> my server space to Linux. >>> >>> But if not for Linux, would it be BSD? A System V variant? Or (the >>> horror) Windows NT? >> >> >> I can make a firm "dunno" sound :-) >> >> Some facts can come together to point away from a number of possibilities... >> >> - If you look at the number of hobbyist "Unix homages" that emerged at around that time, it's clear that there was a sizable community of interested folk willing to build their own thing, and that weren't interested in Windows NT. (Nay, one should put that more strongly... That had their minds set on something NOT from Microsoft.) So I think we can cross Windows NT off the list. >> >> - OS/2 should briefly come on the list. It was likable in many ways, if only IBM had actually supported it... But it suffers from something of the same problem as Windows NT; there were a lot of folk that were only slightly less despising of IBM at the time than of Microsoft. >> >> - Hurd was imagined to be the next thing... >> >> To borrow from my cookie file... >> >> "Of course 5 years from now that will be different, but 5 years from >> now everyone will be running free GNU on their 200 MIPS, 64M >> SPARCstation-5." -- Andrew Tanenbaum, 1992. >> % >> "You'll be rid of most of us when BSD-detox or GNU comes out, which >> should happen in the next few months (yeah, right)." -- Richard Tobin, >> 1992. [BSD did follow within a year] >> % >> "I am aware of the benefits of a micro kernel approach. However, the >> fact remains that Linux is here, and GNU isn't --- and people have >> been working on Hurd for a lot longer than Linus has been working on >> Linux." -- Ted T'so, 1992. >> >> Ted has been on this thread, and should be amused (and slightly disturbed!) that his old statements are being held here and there, ready to trot out :-). >> >> In the absence of Linux, perhaps hackers would have flocked to Hurd, but there was enough going on that there was plenty of room for them to have done so anyways. >> >> I'm not sure what to blame on whatever happened post-1992, though I'd put some on Microsoft Research having taken the wind out of Mach's sails by hiring off a bunch of the relevant folk. In order for Hurd to "make it," Mach has to "make it," too, and it looked like they were depending on CMU to be behind that. (I'm not sure I'm right about that; happy to hear a better story.) >> >> Anyway, Hurd *might* have been a "next thing," and I don't think the popularity of Linux was enough to have completely taken wind out of its sails, given that there's the dozens of "Unix homages" out there. >> >> - I'd like to imagine Plan 9 being an alternative, but it was "properly commercial" for a goodly long time (hence not amenable to attaching waves of hackers to it to add their favorite device drivers), and was never taken as a serious answer. Many of us had admired it from afar via the Dr Dobbs Journal issue (when was that? mid or late '90s?) but only from afar. >> >> - FreeBSD is the single best answer I can throw up as a possibility, as it was the one actively targeting 80386 hardware. And that had the big risk of the AT&T lawsuit lurking over it, so had that gone in a different direction, then that is a branch sadly easily trimmed. >> >> If we lop both Linux and FreeBSD off the list of possibilities, I don't imagine Windows NT or OS/2 bubble to the top, instead, a critical mass would have stood behind ... something else, I'd think. I don't know which to suggest. >> -- >> When confronted by a difficult problem, solve it by reducing it to the >> question, "How would the Lone Ranger handle this?" From athornton at gmail.com Thu Aug 29 09:09:24 2019 From: athornton at gmail.com (Adam Thornton) Date: Wed, 28 Aug 2019 16:09:24 -0700 Subject: [TUHS] If not Linux, then what? In-Reply-To: <13e8e297-0b27-ac95-8fd4-e2a9b28d0b64@gmail.com> References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <016BFF16-C490-425D-8168-3D59DCCA6A21@ccc.com> <13e8e297-0b27-ac95-8fd4-e2a9b28d0b64@gmail.com> Message-ID: This was pre-SLS as well. I remember vividly how excited I was when it came out in mid-92 and how much like cheating it was. A little googling and I'm sure I used the HJ Lu diskettes. I don't actually remember hand-editing the MBR but, well, I probably did. Adam On Wed, Aug 28, 2019 at 4:01 PM William Pechter wrote: > On 8/28/2019 6:48 PM, Adam Thornton wrote: > > It probably was the partition/slice confusion that, well, confused me, > then. My experience, such as it was, was from the DOS world. > > As was mine mostly 8-) I remember it from the PITA it was to translate in > my head. Unix folks looked at partitions as /dev/dsk/0s0->0s7 (I think 7 > was the SVR2 maximum. The "Unix" partitions fit inside the FDISK partition > or dos slice... The dos guys looked at it kind of like the fdisk space > disk0 partition 3 (for example) was the partition and then the BSD folks > broke that in to /dev/sd0a /dev/sd0b /dev/sd0c etc. > > I did a little SunOS and SysV along with Dos and Windows and could make > them coexist as long as there was an open primary dos partition. > > > > Although the period I am thinking of was way pre-slackware. You had a > boot floppy and a root floppy and that was about it, I think. I think the > kernel had MFM/RLL disk drivers for an ISA bus interface? I remember that > I could boot the thing on the MCA machines in the lab but not actually > install it (even had I been allowed to), and I think installation was > pretty much fdisk/mkfs, extract the tarball...I don't remember how you > installed the bootloader...which I guess was already LILO at that point? > Probably just dding the bootsector to the first physical sector of the > disk? Version 0.08 or so, maybe? > > > Sounds like SLS -- Soft Landing System -- which later was pretty much > replaced with Slackware. I used the early MCA stuff on PS/2's at IBM for a > while. Most of the PS/2 stuff we had was SCSI. The boot loader was lilo. > It could go in the partition space or disk mbr. See: > https://www.ibm.com/developerworks/library/l-bootload/index.html > > > It was quite a while ago, and I was drunk for most of college, > so....memory is imprecise at best. > > On Wed, Aug 28, 2019 at 3:28 PM Clem cole wrote: > >> Not true 386BSD used fdisk. It shared the disk just fine. In fact I >> liked the way it sliced the disk much better than Slackware in those days. >> >> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not >> quite. >> >> On Aug 28, 2019, at 4:27 PM, Adam Thornton wrote: >> >> I was an ardent OS/2 supporter for a long time. Sure, IBM's anemic >> marketing, and their close-to-outright-hostility to 3rd-party developers >> didn't help. But what killed it, really, was how damn good its 16-bit >> support was. It *was* a better DOS than DOS and a better Windows than >> 3.11fW. So no one wrote to the relatively tiny market of 32-bit OS/2. >> >> I fear that had Linux not made the leap, MS might well have won. It's >> largely the AOL-fuelled explosion of popularity of the Internet and Windows >> ignoring same until too late that opened the door enough for Linux to jam >> its foot in. >> >> Hurd was, by the time of the '386 Unix Wars and early Linux, clearly not >> going to be a contender, I guess because it was about cool research >> features rather than running user-facing code. I kept waiting for a usable >> kernel to go with what Linux had already shown was a quite decent >> userspace, but eventually had better things to do with my life (like chase >> BeOS). It was like waiting for Perl 6--it missed its moment. >> >> Plan 9 and Amoeba were both really nifty. I never used Sprite. >> Neither one of them had much of a chance in the real world. Much like Unix >> itself, Linux's worse-is-better approach really worked. >> >> I have a hypothesis about Linux's ascendance too, which is a personal >> anecdote I am inflating to the status of hypothesis. As I recall, the >> *BSDs for 386 all assumed they owned the hard disk. Like, the whole >> thing. You couldn't, at least in 1992, create a multiboot system--or at >> least it was my strong impression you could not. I was an undergrad. I >> had one '386 at my disposal, with one hard disk, and, hey, I needed DOS and >> Windows to write my papers (I don't know about you, but I wanted to write >> in my room, where I could have my references at hand and be reasonably >> undisturbed; sure Framemaker was a much better setup than Word For Windows >> 1.2 but having to use it in the computer lab made it a nonstarter for me). >> Papers, and, well, to play games. Sure, that too. >> >> Linux let me defragment my drive, non-destructively repartition it, and >> create a dual-boot system, so that I could both use the computer for school >> and screw around on Linux. I'm probably not the only person for whom this >> was a decisive factor. >> >> Adam >> >> On Wed, Aug 28, 2019 at 1:08 PM Christopher Browne >> wrote: >> >>> On Mon, 26 Aug 2019 at 19:14, Arthur Krewat wrote: >>> >>>> >>>> https://linux.slashdot.org/story/19/08/26/0051234/celebrating-the-28th-anniversary-of-the-linux-kernel >>>> >>>> Leaving licensing and copyright issues out of this mental exercise, >>>> what >>>> would we have now if it wasn't for Linux? Not what you'd WANT it to be, >>>> although that can add to the discussion, but what WOULD it be? >>>> >>>> I'm not asking as a proponent of Linux. If anything, I was dragged >>>> kicking and screaming into the current day and have begrudgingly ceded >>>> my server space to Linux. >>>> >>>> But if not for Linux, would it be BSD? A System V variant? Or (the >>>> horror) Windows NT? >>>> >>> >>> I can make a firm "dunno" sound :-) >>> >>> Some facts can come together to point away from a number of >>> possibilities... >>> >>> - If you look at the number of hobbyist "Unix homages" that emerged at >>> around that time, it's clear that there was a sizable community of >>> interested folk willing to build their own thing, and that weren't >>> interested in Windows NT. (Nay, one should put that more strongly... That >>> had their minds set on something NOT from Microsoft.) So I think we can >>> cross Windows NT off the list. >>> >>> - OS/2 should briefly come on the list. It was likable in many ways, if >>> only IBM had actually supported it... But it suffers from something of the >>> same problem as Windows NT; there were a lot of folk that were only >>> slightly less despising of IBM at the time than of Microsoft. >>> >>> - Hurd was imagined to be the next thing... >>> >>> To borrow from my cookie file... >>> >>> "Of course 5 years from now that will be different, but 5 years from >>> now everyone will be running free GNU on their 200 MIPS, 64M >>> SPARCstation-5." -- Andrew Tanenbaum, 1992. >>> % >>> "You'll be rid of most of us when BSD-detox or GNU comes out, which >>> should happen in the next few months (yeah, right)." -- Richard Tobin, >>> 1992. [BSD did follow within a year] >>> % >>> "I am aware of the benefits of a micro kernel approach. However, the >>> fact remains that Linux is here, and GNU isn't --- and people have >>> been working on Hurd for a lot longer than Linus has been working on >>> Linux." -- Ted T'so, 1992. >>> >>> Ted has been on this thread, and should be amused (and slightly >>> disturbed!) that his old statements are being held here and there, ready to >>> trot out :-). >>> >>> In the absence of Linux, perhaps hackers would have flocked to Hurd, but >>> there was enough going on that there was plenty of room for them to have >>> done so anyways. >>> >>> I'm not sure what to blame on whatever happened post-1992, though I'd >>> put some on Microsoft Research having taken the wind out of Mach's sails by >>> hiring off a bunch of the relevant folk. In order for Hurd to "make it," >>> Mach has to "make it," too, and it looked like they were depending on CMU >>> to be behind that. (I'm not sure I'm right about that; happy to hear a >>> better story.) >>> >>> Anyway, Hurd *might* have been a "next thing," and I don't think the >>> popularity of Linux was enough to have completely taken wind out of its >>> sails, given that there's the dozens of "Unix homages" out there. >>> >>> - I'd like to imagine Plan 9 being an alternative, but it was "properly >>> commercial" for a goodly long time (hence not amenable to attaching waves >>> of hackers to it to add their favorite device drivers), and was never taken >>> as a serious answer. Many of us had admired it from afar via the Dr Dobbs >>> Journal issue (when was that? mid or late '90s?) but only from afar. >>> >>> - FreeBSD is the single best answer I can throw up as a possibility, as >>> it was the one actively targeting 80386 hardware. And that had the big >>> risk of the AT&T lawsuit lurking over it, so had that gone in a different >>> direction, then that is a branch sadly easily trimmed. >>> >>> If we lop both Linux and FreeBSD off the list of possibilities, I don't >>> imagine Windows NT or OS/2 bubble to the top, instead, a critical mass >>> would have stood behind ... something else, I'd think. I don't know which >>> to suggest. >>> -- >>> When confronted by a difficult problem, solve it by reducing it to the >>> question, "How would the Lone Ranger handle this?" >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Thu Aug 29 09:19:52 2019 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Wed, 28 Aug 2019 19:19:52 -0400 Subject: [TUHS] If not Linux, then what? In-Reply-To: References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> Message-ID: <20190828231952.GA536@mit.edu> On Wed, Aug 28, 2019 at 04:07:39PM -0400, Christopher Browne wrote: > > - Hurd was imagined to be the next thing... > > To borrow from my cookie file... > > "I am aware of the benefits of a micro kernel approach. However, the > fact remains that Linux is here, and GNU isn't --- and people have > been working on Hurd for a lot longer than Linus has been working on > Linux." -- Ted T'so, 1992. That's "Ts'o" :-), and that quote wasn't my arguing that Hurd would be the next thing. It was people had been working on the Hurd for *years* (starting 1984) and it still wasn't real. If it wasn't going to be real after eight years, another eighty probably wouldn't have helped. And a lot of this was because was because RMS was hard to work with, and he was a purist. Pretty much very *definition* of the perfect should always be the enemy of the "good enough". In fact, at one point Thomas Bushnell, one of the senior Hurd developers pushed to have the Hurd switch to using BSD 4.4-Lite, and Stallman refused[1]. “RMS was a very strong believer, wrongly, I think, in a very greedy algorithm approach to code reuse issues,” Thomas Bushnell later remembered. “My first choice was to take the BSD 4.4-Lite release and make a kernel. I knew the code, I knew how to do it. It is now perfectly obvious to me that this would have succeeded splendidly and the world would be a very different place today. RMS wanted to work together with people from Berkeley on such an effort. Some of them were interested, but some seem to have been deliberately dragging their feet: and the reason now seems to be that they had the goal of spinning off BSDI. A GNU based on 4.4-Lite would undercut BSDI.” As Bushnell describes it, Stallman came to the conclusion that “Mach is a working kernel. 4.4-Lite is only partial. We will go with Mach.” [1] https://web.archive.org/web/20121228225905/http://www.linuxuser.co.uk/features/whatever-happened-to-the-hurd-the-story-of-the-gnu-os That's probably one of the other things that may have hampered BSD. The BSD license made it easier (or at least made easier business models) for monetizing BSD, and some of the most talented people went off to make a buck off of BSD. BSDI, Sun, NetApp, Wasabi Systems, etc. Nothing wrong with that of course, and if people like Bill Joy were able to make bank based on BSD, more power to them. But it probably removed from the leadership pool people who might have had better leadership, and technical architect skills who might have led one of the *BSD's to greater success. The GPL makes it harder to monetize Linux --- although, as we've seen, certainly not impossible --- and if you take a look at the most of the senior technical people at Linux, none of us have made off as well as, say, Bill Joy. I'm still a working stiff, and don't have enough to retire. (That's OK; I'm perfectly happy being part of the 99%. :-) > Anyway, Hurd *might* have been a "next thing," and I don't think the > popularity of Linux was enough to have completely taken wind out of its > sails, given that there's the dozens of "Unix homages" out there. Given who called the shots (and it wasn't the key people actually doing most of the technical work, such as Bushnell) I actually think it's not very likely Hurd could have succeeded. RMS actually tried to recruit me to work on the Hurd as well, and I refused, because of project leadership concerns. (Again, feel free to hate on Linus's management style, but there were far worse ones in the open source OS world at the time.) - Ted From clemc at ccc.com Thu Aug 29 10:11:51 2019 From: clemc at ccc.com (Clem cole) Date: Wed, 28 Aug 2019 20:11:51 -0400 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: References: <201908281841.x7SIfQS7053036@tahoe.cs.Dartmouth.EDU> Message-ID: William That’s right. 4.1a supported at least these plus the original Xerox 3m card and I think a card MIT made for chaos and the protean card. iirc. We had one of each of the production 10M Ethernet cards in the cad lab at UCB at some point. The machine dec gave us had a dec card and that was the only dec card on campus so Sam would come over to my lab to test new OSses on that system. UCB originally bought 3com cards (eventually in the cad group I got some early interlan cards from their ceo to test and I remember we liked them better for some reason I don’t remember). Before we had the 3COM based 10M link, we had couple of 3M Xerox cards on the original link back to Evans hall. The Xerox cards were used with the BBN tcp before 4.1a. Eric cooper brought all that up with Sam and Bob Kriddle Iirc. That was all switched to the 3com cards pretty early to get 10M and Early after 4.1a and I do remember sam and I had used all that to debug Routed as we had the CAD Ethernet in Cory Hall, the back link to Evans and another Ethernet in the Evans machine room. Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > On Aug 28, 2019, at 6:36 PM, William Pechter wrote: > > I could've sworn 4.x BSD supported Micom Internan NI1010 or some other early > ethernet like 3com as well as the DEC boards. > > Anyone have the 4.1 or 4.2 BSD docs handy. Mine are boxed away for safe keeping. > >> On 8/28/2019 6:29 PM, George Michaelson wrote: >> This is an object lesson in not making assumptions about things. I had >> always assumed the V in UNIX 32V stood for something which went to >> demand paging, from 'Virtual Addressing'. Turns out: I was wrong. >> >> One other note about sockets: The original 4.2 port had to be used by >> a lot of people without the ethernet, because we didn't have the DEC >> ethernet card it was written to. This made unix domain sockets very >> interesting because you could test in them. Except: the very first >> test program somebody wrote at Leeds university to create and write to >> a unix domain socket in /tmp crashed the vax. ... (this was around >> 1982/3) -We were warned off using sockets until the first patch tape >> came in the post. >> >> > From ggm at algebras.org Thu Aug 29 10:18:36 2019 From: ggm at algebras.org (George Michaelson) Date: Thu, 29 Aug 2019 10:18:36 +1000 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: References: <201908281841.x7SIfQS7053036@tahoe.cs.Dartmouth.EDU> Message-ID: I should add that in the UK the vaxes we run included "systime" equipment: They got done for photocopying DEC boards and reselling without licence fee, and for selling kit to the USSR. They'd started as a Vt100 seller. nice terminals. Shame about the bad business practices. The headquarters was a modernist building used for the BBC tv series "edge of darkness" and did have the CEO's helicopter parked outside: he flew it when they could afford the avgas. -G On Thu, Aug 29, 2019 at 10:12 AM Clem cole wrote: > > William That’s right. 4.1a supported at least these plus the original Xerox 3m card and I think a card MIT made for chaos and the protean card. iirc. We had one of each of the production 10M Ethernet cards in the cad lab at UCB at some point. The machine dec gave us had a dec card and that was the only dec card on campus so Sam would come over to my lab to test new OSses on that system. UCB originally bought 3com cards (eventually in the cad group I got some early interlan cards from their ceo to test and I remember we liked them better for some reason I don’t remember). Before we had the 3COM based 10M link, we had couple of 3M Xerox cards on the original link back to Evans hall. > > The Xerox cards were used with the BBN tcp before 4.1a. Eric cooper brought all that up with Sam and Bob Kriddle Iirc. > > That was all switched to the 3com cards pretty early to get 10M and Early after 4.1a and I do remember sam and I had used all that to debug Routed as we had the CAD Ethernet in Cory Hall, the back link to Evans and another Ethernet in the Evans machine room. > > Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > > > On Aug 28, 2019, at 6:36 PM, William Pechter wrote: > > > > I could've sworn 4.x BSD supported Micom Internan NI1010 or some other early > > ethernet like 3com as well as the DEC boards. > > > > Anyone have the 4.1 or 4.2 BSD docs handy. Mine are boxed away for safe keeping. > > > >> On 8/28/2019 6:29 PM, George Michaelson wrote: > >> This is an object lesson in not making assumptions about things. I had > >> always assumed the V in UNIX 32V stood for something which went to > >> demand paging, from 'Virtual Addressing'. Turns out: I was wrong. > >> > >> One other note about sockets: The original 4.2 port had to be used by > >> a lot of people without the ethernet, because we didn't have the DEC > >> ethernet card it was written to. This made unix domain sockets very > >> interesting because you could test in them. Except: the very first > >> test program somebody wrote at Leeds university to create and write to > >> a unix domain socket in /tmp crashed the vax. ... (this was around > >> 1982/3) -We were warned off using sockets until the first patch tape > >> came in the post. > >> > >> > > From ggm at algebras.org Thu Aug 29 10:29:44 2019 From: ggm at algebras.org (George Michaelson) Date: Thu, 29 Aug 2019 10:29:44 +1000 Subject: [TUHS] ISO, OSI, and DECnet (was Re: If not Linux, then what?) In-Reply-To: References: <20190828172451.GX13570@mcvoy.com> <20190828181727.GA82704@wopr> Message-ID: SPDY and QUIC re-capitulate some ideas of the session layer. It is ironic how many repudiated aspects of the OSI model are re-surfacing inside IP centric networking. -G On Thu, Aug 29, 2019 at 5:29 AM SPC wrote: > > It's a bit funny (at least for me) because I was talking about DECNET as OSI standard and TCP/IP and OSI differences some days ago to the group of students of a course on network operation that I am teaching. > > On the other hand I don't that book about networking. I'd like to get one copy bit I live in Spain. Shipment is not a problem but perhaps to deal with shipping procedures abroad is not what you have in mind :-) > > Cordiales saludos / Best Regards / Salutations / Freundliche Grüße > ----- > Sergio Pedraja > > Senior Technician in Computer Science, Systems Administration, and Information Security. MBA. Qualified occupational trainer. > > El mié., 28 ago. 2019 20:24, Kurt H Maier escribió: >> >> On Wed, Aug 28, 2019 at 10:24:51AM -0700, Larry McVoy wrote: >> > >> > The great Mike Padlipski said "do you want protocols that look nice or >> > protocols that work nice?" in his fantastic book Elements of Networking >> > Style [*]. >> > >> >> This book taught me as much about navigating bureaucracy and the warning >> signs of impending death-by-committee as it did about networking. I >> keep a copy on my shelf at the office and annoy my staff with it >> regularly. It's also a wonderful time capsule that provides a lot of >> context about how we got where we are. >> >> khm From stewart at serissa.com Thu Aug 29 13:24:20 2019 From: stewart at serissa.com (Lawrence Stewart) Date: Wed, 28 Aug 2019 23:24:20 -0400 Subject: [TUHS] If not Linux, then what? In-Reply-To: References: <20190828063045.GE75146@server.rulingia.com> <20190828173228.GZ13570@mcvoy.com> Message-ID: > On 2019, Aug 28, at 2:56 PM, Clem Cole wrote: > > > > On Wed, Aug 28, 2019 at 1:32 PM Larry McVoy > wrote: > Perhaps Clem can shed some light on why DEC did a MIPS machine? > I did not work for DEC at the time and obviously, I was not in the room, so this is what I can say I picked up. Supnik would be a better person to ask. That said, some things I do know about the time/and behinds the scene. > Jupiter and Prism had been canceled. > Alpha did not yet exist (and would not for another 2 years) > Cutler had left for Microsoft etc.. > Sun was clearly on its game > The VAX on a Chip just was not cutting it > RISC architectures were the hot item > Here is where I get fuzzy on details. > I believe a prototype (i.e. skunk works) MIPS was running at WRL in Palo Alto running Ultrix and DEC windows, I think using some sort of cheap ??PC?? chassis. > But the performance of the prototype was excellent and cost was cheaper than the current vax products. > Somebody sr, maybe Bob, shows this to Sr management and got the money to productize it. The issue as making an official Ultrix for it was I know a big one. Ultimately, DEC farmed that work out to us at LCC (with us eventually taking over all of Ultrix - MIPS and Vax). I was at the Digital Systems Research Center in Palo Alto between 1984 and 1989. Also located in Palo Alto were the Western Research Lab (run by Forest Baskett), Workstation Systems Engineering, and the West Coast Systems Lab. Steve Bourne was at one of these. All were within a few blocks of each other and easy walking distance to “Louis’” chinese restaurant, whose official name was “The Little Restaurant”. The rule was that you could not go to Louis' for lunch if you had eaten lunch there the day before. At the time, SRC was building multiprocessor research workstations with VAX chips (the Firefly, I did some of the hardware) and WRL was building an ECL RISC machine (the Titan). WSE was started, I think, to commercialize a multiprocessor VAX workstation something like the Firefly. WSL was a software group working on window systems and things like multimedia software. The WSE machines became the VAXStation 3520 and 3540, code named FireFox (showing the ancestry I guess!). The folks at WSE, I think with egging on from WRL, who were in the same building, then built the R2000 based “PMAX” and then the R3000 based “3MAX”. These were rather nice machines for 1990 and 1991. They also invented a flat attaching I/O card format “TurboChannel”. The impression I has was that the RS6000 and the PA-RISC and the various MIPS machines put a large scare into Digital. I don’t know how the politics worked for this. The west coast was a long long way from Maynard. Larry -------------- next part -------------- An HTML attachment was scrubbed... URL: From stewart at serissa.com Thu Aug 29 13:29:02 2019 From: stewart at serissa.com (Lawrence Stewart) Date: Wed, 28 Aug 2019 23:29:02 -0400 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: <201908281757.x7SHv9gj042779@tahoe.cs.Dartmouth.EDU> References: <201908281757.x7SHv9gj042779@tahoe.cs.Dartmouth.EDU> Message-ID: > On 2019, Aug 28, at 1:57 PM, Doug McIlroy wrote: > > >> How long was research running on a PDP-11 and when did they move to a VAX? > > London and Reiser had ported Unix to the VAX, replete with virtual memory, in 1978. By the time v7 was released (1979), Vaxen had become the workhorse machines in Research. > > Doug I’ve always been a little curious about how Reiser (John Reiser, not Hans!) came to port Unix. I had heard of him from his PhD Dissertation which was something like 35 pages long for Knuth (!) on random number generators. He finished at Stanford in 1977 and in 1978 he was porting Unix? How did that happen? -L From lm at mcvoy.com Thu Aug 29 14:10:11 2019 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 28 Aug 2019 21:10:11 -0700 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: References: <201908281757.x7SHv9gj042779@tahoe.cs.Dartmouth.EDU> Message-ID: <20190829041011.GG10796@mcvoy.com> On Wed, Aug 28, 2019 at 11:29:02PM -0400, Lawrence Stewart wrote: > > On 2019, Aug 28, at 1:57 PM, Doug McIlroy wrote: > >> How long was research running on a PDP-11 and when did they move to a VAX? > > > > London and Reiser had ported Unix to the VAX, replete with virtual memory, in 1978. By the time v7 was released (1979), Vaxen had become the workhorse machines in Research. > > > > Doug > > I???ve always been a little curious about how Reiser (John Reiser, not Hans!) came to port Unix. I had heard of him from his PhD Dissertation which was something like 35 pages long for Knuth (!) on random number generators. He finished at Stanford in 1977 and in 1978 he was porting Unix? How did that happen? I'm with Lawrence, I'd love to hear this. This thread is the first I've heard about John Reiser and London. I don't remember anything about them in the Bell Labs journals. I can say it is not a stretch to go from school to porting, I did that. School is amazing at making you feel like you can do anything. I took the grad compiler class, you could take one of them or two of them at a time, my buddy Rob Netzer and I took two together and we wrote a big subset of the ADA language in a semester. You slow down when you have to make a product that works in the face of people doing silly (aka stupid) things. Error checking is a thing, compiler error messages that point to the exact problem are a much, much bigger thing. Gcc is very good at that, I've got a lot of respect for gcc, I know how hard that is. From wobblygong at gmail.com Thu Aug 29 16:37:05 2019 From: wobblygong at gmail.com (Wesley Parish) Date: Thu, 29 Aug 2019 18:37:05 +1200 Subject: [TUHS] If not Linux, then what? In-Reply-To: <13e8e297-0b27-ac95-8fd4-e2a9b28d0b64@gmail.com> References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <016BFF16-C490-425D-8168-3D59DCCA6A21@ccc.com> <13e8e297-0b27-ac95-8fd4-e2a9b28d0b64@gmail.com> Message-ID: On 8/29/19, William Pechter wrote: > On 8/28/2019 6:48 PM, Adam Thornton wrote: > > >> >> Although the period I am thinking of was way pre-slackware. You had a >> boot floppy and a root floppy and that was about it, I think. I think >> the kernel had MFM/RLL disk drivers for an ISA bus interface? I >> remember that I could boot the thing on the MCA machines in the lab >> but not actually install it (even had I been allowed to), and I think >> installation was pretty much fdisk/mkfs, extract the tarball...I don't >> remember how you installed the bootloader...which I guess was already >> LILO at that point? Probably just dding the bootsector to the first >> physical sector of the disk? Version 0.08 or so, maybe? >> > > Sounds like SLS -- Soft Landing System -- which later was pretty much > replaced with Slackware. I used the early MCA stuff on PS/2's at IBM > for a while. Most of the PS/2 stuff we had was SCSI. The boot loader > was lilo. It could go in the partition space or disk mbr. > See:https://www.ibm.com/developerworks/library/l-bootload/index.html FWLIW, you can get a copy of my installation of SLS at https://sourceforge.net/projects/bochs/files/Disk%20Images/SLS%20Linux/ I included the floppy images so any time you can reinstall it or just work on acquiring the joys of diskswapping as we knew it back then. (It's one way to go crazy when you're tired, and get the fdisk/mkfs stage wrong, or pick up the wrong disk or ... :) > > From arnold at skeeve.com Thu Aug 29 16:43:10 2019 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 29 Aug 2019 00:43:10 -0600 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: References: <201908281757.x7SHv9gj042779@tahoe.cs.Dartmouth.EDU> Message-ID: <201908290643.x7T6hAYc011290@freefriends.org> Rob Pike wrote: > Reiser Unix got demand paging a little later, and it was spectacularly > fast. I remember being gobsmacked when I saw a demo in early 1981. So, once again, *W*H*Y* did Research choose BSD instead of Reiser's version on the vax? > Dead ends everywhere. Explain please? Thanks, Arnold From lars at nocrew.org Thu Aug 29 16:27:34 2019 From: lars at nocrew.org (Lars Brinkhoff) Date: Thu, 29 Aug 2019 06:27:34 +0000 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: (Clem cole's message of "Wed, 28 Aug 2019 20:11:51 -0400") References: <201908281841.x7SIfQS7053036@tahoe.cs.Dartmouth.EDU> Message-ID: <7wa7bs8p0p.fsf@junk.nocrew.org> Clem cole wrote: > William That’s right. 4.1a supported at least these plus the original > Xerox 3m card and I think a card MIT made for chaos I would love to see 4.1a with Chaosnet support. I have 4.1 patched with MIT's Chaosnet software. From robpike at gmail.com Thu Aug 29 17:39:40 2019 From: robpike at gmail.com (Rob Pike) Date: Thu, 29 Aug 2019 17:39:40 +1000 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: <201908290643.x7T6hAYc011290@freefriends.org> References: <201908281757.x7SHv9gj042779@tahoe.cs.Dartmouth.EDU> <201908290643.x7T6hAYc011290@freefriends.org> Message-ID: It had paging already and there was affection by some towards Berkeley. -rob On Thu, Aug 29, 2019 at 4:45 PM wrote: > Rob Pike wrote: > > > Reiser Unix got demand paging a little later, and it was spectacularly > > fast. I remember being gobsmacked when I saw a demo in early 1981. > > So, once again, *W*H*Y* did Research choose BSD instead of Reiser's > version on the vax? > > > Dead ends everywhere. > > Explain please? > > Thanks, > > Arnold > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dot at dotat.at Thu Aug 29 21:12:38 2019 From: dot at dotat.at (Tony Finch) Date: Thu, 29 Aug 2019 12:12:38 +0100 Subject: [TUHS] If not Linux, then what? In-Reply-To: References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> Message-ID: Adam Thornton wrote: > > I fear that had Linux not made the leap, MS might well have won. It's > largely the AOL-fuelled explosion of popularity of the Internet and Windows > ignoring same until too late that opened the door enough for Linux to jam > its foot in. I started work at Demon Internet in 1997. Its origins before 1992 were in SCO / Xenix consultancy, but by the time I joined the ISP systems were mostly flavours of BSD and Sun. My colleagues didn't think Linux was sufficiently good at networking, and I got the impression that was a relatively common opinion in ISP circles around 1995/6. That kind of suggests to me that Unix would have been helped by the rise of the Internet even without Linux... Tony. -- f.anthony.n.finch http://dotat.at/ Shannon: Southwest 5 to 7, occasionally gale 8 for a time. Rough or very rough. Rain. Good, becoming moderate or poor. From dot at dotat.at Thu Aug 29 20:55:11 2019 From: dot at dotat.at (Tony Finch) Date: Thu, 29 Aug 2019 11:55:11 +0100 Subject: [TUHS] If not Linux, then what? In-Reply-To: References: <20190828063045.GE75146@server.rulingia.com> <20190828173228.GZ13570@mcvoy.com> Message-ID: Lawrence Stewart wrote: > > At the time, SRC was building multiprocessor research workstations with > VAX chips (the Firefly, I did some of the hardware) and WRL was building > an ECL RISC machine (the Titan). I've found a Titan System Manual from 1988 https://www.hpl.hp.com/techreports/Compaq-DEC/WRL-86-1.pdf It's a curious machine with a number of unusual instruction set features - an 8 bit CPU process ID hooked into the virtual memory system, register banks selected using the processor status register - otherwise RISC flavoured. Did it have any successors? Tony. -- f.anthony.n.finch http://dotat.at/ The Minch: Southwest 5 to 7, occasionally gale 8 for a time, decreasing 2 or 3 and becoming cyclonic later. Moderate or rough. Rain or showers. Moderate or good, occasionally poor. From a.phillip.garcia at gmail.com Thu Aug 29 23:31:16 2019 From: a.phillip.garcia at gmail.com (A. P. Garcia) Date: Thu, 29 Aug 2019 09:31:16 -0400 Subject: [TUHS] If not Linux, then what? In-Reply-To: <20190828231952.GA536@mit.edu> References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <20190828231952.GA536@mit.edu> Message-ID: On Wed, Aug 28, 2019 at 7:20 PM Theodore Y. Ts'o wrote: > The GPL makes it harder to monetize Linux --- although, as we've seen, > certainly not impossible --- and if you take a look at the most of the > senior technical people at Linux, none of us have made off as well as, > say, Bill Joy. I'm still a working stiff, and don't have enough to > retire. (That's OK; I'm perfectly happy being part of the 99%. :-) Case in point: https://jalopnik.com/the-founders-of-sun-microsystems-their-cars-and-their-5562572 I'm not making any judgments, good or bad. It is what it is. From krewat at kilonet.net Thu Aug 29 23:55:10 2019 From: krewat at kilonet.net (Arthur Krewat) Date: Thu, 29 Aug 2019 09:55:10 -0400 Subject: [TUHS] If not Linux, then what? In-Reply-To: References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <20190828231952.GA536@mit.edu> Message-ID: <3173aba3-b6c3-43db-6374-b600f3217f13@kilonet.net> On 8/29/2019 9:31 AM, A. P. Garcia wrote: > On Wed, Aug 28, 2019 at 7:20 PM Theodore Y. Ts'o wrote: > > > >> The GPL makes it harder to monetize Linux --- although, as we've seen, >> certainly not impossible --- and if you take a look at the most of the >> senior technical people at Linux, none of us have made off as well as, >> say, Bill Joy. I'm still a working stiff, and don't have enough to >> retire. (That's OK; I'm perfectly happy being part of the 99%. :-) > > > Case in point: https://jalopnik.com/the-founders-of-sun-microsystems-their-cars-and-their-5562572 > > I'm not making any judgments, good or bad. It is what it is. > Except for the Ferrari (which would be around $160K in today's US dollars), the other three are pretty much bargain-basement sports cars ;) From jsteve at superglobalmegacorp.com Fri Aug 30 00:54:13 2019 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Thu, 29 Aug 2019 22:54:13 +0800 Subject: [TUHS] ISO, OSI, and DECnet (was Re: If not Linux, then what?) In-Reply-To: References: <20190828172451.GX13570@mcvoy.com> <20190828181727.GA82704@wopr> Message-ID: <1d3d8c9a-7006-4666-b32e-8fa4fc5e9f7c@PU1APC01FT039.eop-APC01.prod.protection.outlook.com> Although I never have seen OSI in the wild, it was the one great thing about ‘Winsock’ is that it worked over TCP/IP , IPX/SPX, AppletTalk and Decnet. It was fun to convert a BBS from being telnet to some ‘telnet over decnet’ monster I built. Although I’m guessing OSI would have allowed for common ‘network’ applications to use different network topologies? I really need to get OSF/1 2.0 installed. From: SPC Sent: Thursday, August 29, 2019 3:30 AM To: tuhs at minnie.tuhs.org Subject: Re: [TUHS] ISO, OSI, and DECnet (was Re: If not Linux, then what?) It's a bit funny (at least for me) because I was talking about DECNET as OSI standard and TCP/IP and OSI differences some days ago to the group of students of a course on network operation that I am teaching. On the other hand I don't that book about networking. I'd like to get one copy bit I live in Spain. Shipment is not a problem but perhaps to deal with shipping procedures abroad is not what you have in mind :-) Cordiales saludos / Best Regards / Salutations / Freundliche Grüße ----- Sergio Pedraja Senior Technician in Computer Science, Systems Administration, and Information Security. MBA. Qualified occupational trainer. El mié., 28 ago. 2019 20:24, Kurt H Maier escribió: On Wed, Aug 28, 2019 at 10:24:51AM -0700, Larry McVoy wrote: > > The great Mike Padlipski said "do you want protocols that look nice or > protocols that work nice?" in his fantastic book Elements of Networking > Style [*]. > This book taught me as much about navigating bureaucracy and the warning signs of impending death-by-committee as it did about networking.  I keep a copy on my shelf at the office and annoy my staff with it regularly.  It's also a wonderful time capsule that provides a lot of context about how we got where we are. khm -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsteve at superglobalmegacorp.com Fri Aug 30 00:58:19 2019 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Thu, 29 Aug 2019 22:58:19 +0800 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: <20190828190534.GH13570@mcvoy.com> References: <201908281841.x7SIfQS7053036@tahoe.cs.Dartmouth.EDU> <201908281849.x7SInUE1024803@freefriends.org> <93732314-1521-3118-47c0-5b973b7b926e@case.edu> <20190828190534.GH13570@mcvoy.com> Message-ID: <02ae25cb-d3c4-477b-849d-3809070a343d@PU1APC01FT114.eop-APC01.prod.protection.outlook.com> Yeah sockets, FFS, VM, autoconfiguration. It almost seems a shame he went to SUN. Although at the same time it’s no wonder why they grabbed him ASAP. I guess it’s like Avie working for NeXT. From: Larry McVoy Sent: Thursday, August 29, 2019 3:06 AM To: Chet Ramey Cc: tuhs at tuhs.org; doug at cs.dartmouth.edu Subject: Re: [TUHS] dmr streams & networking [was: Re: If not Linux,then what?] On Wed, Aug 28, 2019 at 03:03:34PM -0400, Chet Ramey wrote: > On 8/28/19 2:49 PM, arnold at skeeve.com wrote: > > >> Sorry, what I said about London/Reiser is true, but not the whole > >> story. L/R didn't have demand paging; BSD did. > > > > But my question still stands. Why didn't Research keep going from L/R > > and add demand paging? Wouldn't that have been "cleaner" than starting > > from BSD? > > It's my impression that BSD had done other work that Research didn't want > to duplicate, like autoconfiguration, device support, and so on. Joy got > a lot out of the VAX hardware. He was a coding machine back then. Quite the legacy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.paulsen at firemail.de Fri Aug 30 01:54:48 2019 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Thu, 29 Aug 2019 17:54:48 +0200 Subject: [TUHS] If not Linux, then what? In-Reply-To: <3173aba3-b6c3-43db-6374-b600f3217f13@kilonet.net> References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <20190828231952.GA536@mit.edu> <3173aba3-b6c3-43db-6374-b600f3217f13@kilonet.net> Message-ID: <004ec49789583b190ca7c302db9fbb31@firemail.de> >: Arthur Krewat > > > Except for the Ferrari (which would be around $160K in today's US > dollars), the other three are pretty much bargain-basement sports cars ;) Today however not in the 80ths. Inn those days all 4 cars were Richie Rich cars. > > > From arnold at skeeve.com Fri Aug 30 02:25:25 2019 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 29 Aug 2019 10:25:25 -0600 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: <02ae25cb-d3c4-477b-849d-3809070a343d@PU1APC01FT114.eop-APC01.prod.protection.outlook.com> References: <201908281841.x7SIfQS7053036@tahoe.cs.Dartmouth.EDU> <201908281849.x7SInUE1024803@freefriends.org> <93732314-1521-3118-47c0-5b973b7b926e@case.edu> <20190828190534.GH13570@mcvoy.com> <02ae25cb-d3c4-477b-849d-3809070a343d@PU1APC01FT114.eop-APC01.prod.protection.outlook.com> Message-ID: <201908291625.x7TGPPG8030855@freefriends.org> Let's get it straight. I think Kirk McKusick did the FFS. VM was done by Somebody Babaglu (a greek? name - I know I'm not remembering it correctly.) I guess Joy did sockets, but I don't know. I do know that he did the csh and ex/vi. I gather he was also in the kernel, but it wasn't all him. BSD was not a one man show. Arnold Jason Stevens wrote: > Yeah sockets, FFS, VM, autoconfiguration. It almost seems a shame he > went to SUN. Although at the same time it’s no wonder why they grabbed > him ASAP. I guess it’s like Avie working for NeXT. > > From: Larry McVoy > Sent: Thursday, August 29, 2019 3:06 AM > To: Chet Ramey > Cc: tuhs at tuhs.org; doug at cs.dartmouth.edu > Subject: Re: [TUHS] dmr streams & networking [was: Re: If not Linux,then what?] > > On Wed, Aug 28, 2019 at 03:03:34PM -0400, Chet Ramey wrote: > > On 8/28/19 2:49 PM, arnold at skeeve.com wrote: > > > > >> Sorry, what I said about London/Reiser is true, but not the whole > > >> story. L/R didn't have demand paging; BSD did. > > > > > > But my question still stands. Why didn't Research keep going from L/R > > > and add demand paging? Wouldn't that have been "cleaner" than starting > > > from BSD? > > > > It's my impression that BSD had done other work that Research didn't want > > to duplicate, like autoconfiguration, device support, and so on. Joy got > > a lot out of the VAX hardware. > > He was a coding machine back then. Quite the legacy. > From arnold at skeeve.com Fri Aug 30 02:26:51 2019 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 29 Aug 2019 10:26:51 -0600 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: References: <201908281757.x7SHv9gj042779@tahoe.cs.Dartmouth.EDU> <201908290643.x7T6hAYc011290@freefriends.org> Message-ID: <201908291626.x7TGQpV4030895@freefriends.org> Ah, OK. Expedience + other considerations. I don't suppose the Reiser 32V+paging survived anywhere? Much thanks, Arnold Rob Pike wrote: > It had paging already and there was affection by some towards Berkeley. > > -rob > > > On Thu, Aug 29, 2019 at 4:45 PM wrote: > > > Rob Pike wrote: > > > > > Reiser Unix got demand paging a little later, and it was spectacularly > > > fast. I remember being gobsmacked when I saw a demo in early 1981. > > > > So, once again, *W*H*Y* did Research choose BSD instead of Reiser's > > version on the vax? > > > > > Dead ends everywhere. > > > > Explain please? > > > > Thanks, > > > > Arnold > > From ralph at inputplus.co.uk Fri Aug 30 02:38:59 2019 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Thu, 29 Aug 2019 17:38:59 +0100 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: <201908291625.x7TGPPG8030855@freefriends.org> References: <201908281841.x7SIfQS7053036@tahoe.cs.Dartmouth.EDU> <201908281849.x7SInUE1024803@freefriends.org> <93732314-1521-3118-47c0-5b973b7b926e@case.edu> <20190828190534.GH13570@mcvoy.com> <02ae25cb-d3c4-477b-849d-3809070a343d@PU1APC01FT114.eop-APC01.prod.protection.outlook.com> <201908291625.x7TGPPG8030855@freefriends.org> Message-ID: <20190829163859.8ED2221301@orac.inputplus.co.uk> Hi Arnold, > VM was done by Somebody Babaglu (a greek? name - I know I'm not > remembering it correctly.) Özalp Babaoğlu, a Turkish name. https://en.wikipedia.org/wiki/%C3%96zalp_Babao%C4%9Flu -- Cheers, Ralph. From arnold at skeeve.com Fri Aug 30 03:35:48 2019 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 29 Aug 2019 11:35:48 -0600 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: <20190829163859.8ED2221301@orac.inputplus.co.uk> References: <201908281841.x7SIfQS7053036@tahoe.cs.Dartmouth.EDU> <201908281849.x7SInUE1024803@freefriends.org> <93732314-1521-3118-47c0-5b973b7b926e@case.edu> <20190828190534.GH13570@mcvoy.com> <02ae25cb-d3c4-477b-849d-3809070a343d@PU1APC01FT114.eop-APC01.prod.protection.outlook.com> <201908291625.x7TGPPG8030855@freefriends.org> <20190829163859.8ED2221301@orac.inputplus.co.uk> Message-ID: <201908291735.x7THZmmt000452@freefriends.org> Ralph Corderoy wrote: > Hi Arnold, > > > VM was done by Somebody Babaglu (a greek? name - I know I'm not > > remembering it correctly.) > > Özalp Babaoğlu, a Turkish name. > https://en.wikipedia.org/wiki/%C3%96zalp_Babao%C4%9Flu > > -- > Cheers, Ralph. Much thanks. I knew I didn't have it right. :-) Arnold From cym224 at gmail.com Fri Aug 30 04:40:07 2019 From: cym224 at gmail.com (Nemo Nusquam) Date: Thu, 29 Aug 2019 14:40:07 -0400 Subject: [TUHS] If not Linux, then what? In-Reply-To: <283e3cc2-42ec-a554-602f-5fb67eca9e40@gmail.com> References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <283e3cc2-42ec-a554-602f-5fb67eca9e40@gmail.com> Message-ID: <8cb953ef-ef6d-fdfa-76a4-1074cf46f598@gmail.com> On 08/28/19 18:27, William Pechter wrote (in part): > On 8/28/2019 4:27 PM, Adam Thornton wrote: >> I was an ardent OS/2 supporter for a long time. Sure, IBM's anemic >> marketing, and their close-to-outright-hostility to 3rd-party >> developers didn't help. But what killed it, really, was how damn >> good its 16-bit support was. It *was* a better DOS than DOS and a >> better Windows than 3.11fW. So no one wrote to the relatively tiny >> market of 32-bit OS/2. >> > OS/2 was slick and if they could've kept the W\indows 3.x > compatibility (the Win32S was a sliding target that Microsoft kept > changing. There was a pretty decent Unix work-alike ported to the top > of OS/2 that made most of the public domain and open source (the term > didn't exist yet) stuff available. > > I could telnet into the box and run a pretty slick Unix work-alike shell. Indeed -- forgive my nostalgia here... We were developing a DOS-based PC-Card (often incorrectly called a PCMCIA card). With OS/2, you opened up a DOS box. If the driver crashed, you just opened up another and went on. Under Windoze, the whole box crashed (and sometimes took the file-system with it). We used a combination of Eberhard Mattes' emx, the MKS toolkit, and case-sensitive file-systems to give us a reasonable approximation. N. From clemc at ccc.com Fri Aug 30 05:15:24 2019 From: clemc at ccc.com (Clem Cole) Date: Thu, 29 Aug 2019 15:15:24 -0400 Subject: [TUHS] ARS Technica on UNIX @ 50 Message-ID: https://arstechnica.com/gadgets/2019/08/unix-at-50-it-starts-with-a-mainframe-a-gator-and-three-dedicated-researchers/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Fri Aug 30 05:19:43 2019 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 29 Aug 2019 21:19:43 +0200 Subject: [TUHS] If not Linux, then what? In-Reply-To: <004ec49789583b190ca7c302db9fbb31@firemail.de> References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <20190828231952.GA536@mit.edu> <3173aba3-b6c3-43db-6374-b600f3217f13@kilonet.net> <004ec49789583b190ca7c302db9fbb31@firemail.de> Message-ID: <20190829191943.BfJ86%steffen@sdaoden.eu> Thomas Paulsen wrote in <004ec49789583b190ca7c302db9fbb31 at firemail.de>: |>: Arthur Krewat |>> |> Except for the Ferrari (which would be around $160K in today's US |> dollars), the other three are pretty much bargain-basement sports cars ;) |Today however not in the 80ths. Inn those days all 4 cars were Richie \ |Rich cars. And only the Mazda had that wonderful smooth engine which replaces pounding pistons with nice chuckling triangles. --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 steffen at sdaoden.eu Fri Aug 30 05:18:37 2019 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 29 Aug 2019 21:18:37 +0200 Subject: [TUHS] If not Linux, then what? In-Reply-To: <8cb953ef-ef6d-fdfa-76a4-1074cf46f598@gmail.com> References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <283e3cc2-42ec-a554-602f-5fb67eca9e40@gmail.com> <8cb953ef-ef6d-fdfa-76a4-1074cf46f598@gmail.com> Message-ID: <20190829191837.JB08c%steffen@sdaoden.eu> Nemo Nusquam wrote in <8cb953ef-ef6d-fdfa-76a4-1074cf46f598 at gmail.com>: |On 08/28/19 18:27, William Pechter wrote (in part): |> On 8/28/2019 4:27 PM, Adam Thornton wrote: |>> I was an ardent OS/2 supporter for a long time. Sure, IBM's anemic |>> marketing, and their close-to-outright-hostility to 3rd-party |>> developers didn't help. But what killed it, really, was how damn |>> good its 16-bit support was. It *was* a better DOS than DOS and a |>> better Windows than 3.11fW. So no one wrote to the relatively tiny |>> market of 32-bit OS/2. |>> |> OS/2 was slick and if they could've kept the W\indows 3.x |> compatibility (the Win32S was a sliding target that Microsoft kept |> changing. There was a pretty decent Unix work-alike ported to the top |> of OS/2 that made most of the public domain and open source (the term |> didn't exist yet) stuff available. |> |> I could telnet into the box and run a pretty slick Unix work-alike shell. |Indeed -- forgive my nostalgia here... We were developing a DOS-based |PC-Card (often incorrectly called a PCMCIA card). With OS/2, you opened |up a DOS box. If the driver crashed, you just opened up another and went |on. Under Windoze, the whole box crashed (and sometimes took the |file-system with it). We used a combination of Eberhard Mattes' emx, |the MKS toolkit, and case-sensitive file-systems to give us a reasonable |approximation. For a few holiday weeks i once worked in the IBM factory in Mainz Germany in a hard disk production line clean room. One of the gauges were driven by OS/2 which not only catched my attention but also crashed randomly up to several times per shift, causing automatic reboots (reliably). (The factory as such was not worth it, it has been closed after fifty years, in the new Heiligkreuz Viertel (holy-cross quarter) there have been build 242 flats and a supermarket in the meantime.) I liked 4DOS. --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 steve at quintile.net Fri Aug 30 06:56:21 2019 From: steve at quintile.net (Steve Simon) Date: Thu, 29 Aug 2019 22:56:21 +0200 Subject: [TUHS] systime Message-ID: <2C239CD2-B761-45F2-BF19-E66A4FD2B661@quintile.net> wow, systime. i went for a student placement there but didnt get it - i guess my long hair (then) didn't fit as the interview seemed good. i had a mate who was working late on the day the combined uk police and CIA (it was said) arrived to shut them down, and tell them they ARE being taken over by CDC. the crime was selling systime re-badged vaxes to the ussr at the height of the cold war. seem odd now that they thought they could get away with it. exciting times. -Steve From athornton at gmail.com Fri Aug 30 11:08:37 2019 From: athornton at gmail.com (Adam Thornton) Date: Thu, 29 Aug 2019 18:08:37 -0700 Subject: [TUHS] ARS Technica on UNIX @ 50 In-Reply-To: References: Message-ID: <2248B8D1-DEA8-453A-88DA-DAE5BC46DBEA@gmail.com> > On Aug 29, 2019, at 12:15 PM, Clem Cole wrote: > > https://arstechnica.com/gadgets/2019/08/unix-at-50-it-starts-with-a-mainframe-a-gator-and-three-dedicated-researchers/ I’m really glad they cited the interviews Mike Mahoney, RIP, did with a lot of the principal people in his Oral History Of Unix. He was my thesis advisor. I did not finish my thesis, but several times in the last few months (not all about Unix; as LSST construction approaches completion, there’s been some thought about how to make our project documentation useful for future historians of science) I’ve thought “Professor Mahoney would be interested in what I’m doing here.” I’d recommend raising a glass to his memory. Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Fri Aug 30 11:32:24 2019 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 29 Aug 2019 18:32:24 -0700 Subject: [TUHS] ARS Technica on UNIX @ 50 In-Reply-To: <2248B8D1-DEA8-453A-88DA-DAE5BC46DBEA@gmail.com> References: <2248B8D1-DEA8-453A-88DA-DAE5BC46DBEA@gmail.com> Message-ID: <20190830013224.GS10796@mcvoy.com> I'm just watching this now, the MC is a died in the wool nerd, I love him. Great dude, gonna send him some stuff. On Thu, Aug 29, 2019 at 06:08:37PM -0700, Adam Thornton wrote: > > > > On Aug 29, 2019, at 12:15 PM, Clem Cole wrote: > > > > https://arstechnica.com/gadgets/2019/08/unix-at-50-it-starts-with-a-mainframe-a-gator-and-three-dedicated-researchers/ > > I???m really glad they cited the interviews Mike Mahoney, RIP, did with a lot of the principal people in his Oral History Of Unix. He was my thesis advisor. I did not finish my thesis, but several times in the last few months (not all about Unix; as LSST construction approaches completion, there???s been some thought about how to make our project documentation useful for future historians of science) I???ve thought ???Professor Mahoney would be interested in what I???m doing here.??? > > I???d recommend raising a glass to his memory. > > Adam -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From wobblygong at gmail.com Fri Aug 30 19:32:21 2019 From: wobblygong at gmail.com (Wesley Parish) Date: Fri, 30 Aug 2019 21:32:21 +1200 Subject: [TUHS] ISO, OSI, and DECnet (was Re: If not Linux, then what?) In-Reply-To: <1d3d8c9a-7006-4666-b32e-8fa4fc5e9f7c@PU1APC01FT039.eop-APC01.prod.protection.outlook.com> References: <20190828172451.GX13570@mcvoy.com> <20190828181727.GA82704@wopr> <1d3d8c9a-7006-4666-b32e-8fa4fc5e9f7c@PU1APC01FT039.eop-APC01.prod.protection.outlook.com> Message-ID: Well, fwiw, the Aeronautical Telecommunications Network (ATN) that was being discussed in the late nineties and early noughties, was supposed to be built on the OSI stack. I have no idea what happened with that, whether it went ahead or got altered. On 8/30/19, Jason Stevens wrote: > Although I never have seen OSI in the wild, it was the one great thing about > ‘Winsock’ is that it worked over TCP/IP , IPX/SPX, AppletTalk and Decnet. > It was fun to convert a BBS from being telnet to some ‘telnet over decnet’ > monster I built. > > Although I’m guessing OSI would have allowed for common ‘network’ > applications to use different network topologies? > > I really need to get OSF/1 2.0 installed. From jnc at mercury.lcs.mit.edu Fri Aug 30 22:57:39 2019 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 30 Aug 2019 08:57:39 -0400 (EDT) Subject: [TUHS] systime Message-ID: <20190830125739.9891418C0D3@mercury.lcs.mit.edu> > From: Steve Simon > i went for a student placement there but didnt get it - i guess my long > hair (then) didn't fit as the interview seemed good. Maybe you seemed too honest! :-) Noel From clemc at ccc.com Fri Aug 30 23:59:08 2019 From: clemc at ccc.com (Clem Cole) Date: Fri, 30 Aug 2019 09:59:08 -0400 Subject: [TUHS] ISO, OSI, and DECnet (was Re: If not Linux, then what?) In-Reply-To: References: <20190828172451.GX13570@mcvoy.com> <20190828181727.GA82704@wopr> <1d3d8c9a-7006-4666-b32e-8fa4fc5e9f7c@PU1APC01FT039.eop-APC01.prod.protection.outlook.com> Message-ID: Besides DECnet, IIRC, in the USA the only semi-large (required) use of OSI was for TOP [Technical Office Protocol] and MAP [manufacturing automation protocol] that GM and Boeing tried to ram down the industries virtual throat. At Masscomp, we had already built an OSI/X.25 interface for Europe, but since I ran Datacom and these folks were definitely my target customers for a real-time system, I had to listen to them. I spent way too many hours in GM and Boeing conference rooms dealing with it. By memory, the arguments for MAP over ethernet was the later was considered 'unpredictable', they claimed they all had to have fiber on the manufacturing floor, and were convinced that TCP/IP had 'too much overhead' for real-time automation. I never really understood the justification of why TOP was needed, other than there were a bunch of folks in both places running DECnet and there was a huge level of NIH. When I was at Masscomp, I don't think we ever sold many systems into GM. But our stop-gap for Ford was to use Protean fiber-based boards on the manufacturing floor and continued to run TCP on top it, and our traditional Ethernet was just fine by them, "thank you." Since Ford Aerospace was our partner for building the new Mission Control at NASA (we ran redundant ethernet there), they were already pretty familiar with our Ethernet and IP stack products, so they took over working with the folks inside of Ford. Shortly thereafter, Masscomp and Apollo won the bid for the Boeing 7J7 program (which became the 777 when it shipped). The agreed (common) interface between all three firms was Ethernet and IP. [**] I left for Stellar, but I don't think they ever built either the MAP/TOP or any of the rest of the OSI stuff besides X.25, funny how they stopped asking for it. I still have a binder of all the TOP specs in my basement. [**] An interesting factoid that I thought of while writing this reply. One thing I learned from working with Boeing during that time is that until that program, the C5A and the 747-400 were the only two airplanes that could carry their documentation as a payload. The paper required for the FAA weighed that much. One of the justifications of the 7J7 was they had gotten approval from the FAA to make all of the documentation delivered electronically. It was the first plane they designed 100% using CAD and no paper or other models. Masscomp systems on the manufacturing floor, and Apollo's in the engineering offices. -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman at oclsc.org Sat Aug 31 05:50:14 2019 From: norman at oclsc.org (Norman Wilson) Date: Fri, 30 Aug 2019 15:50:14 -0400 Subject: [TUHS] Running v10 Message-ID: <1567194618.21207.for-standards-violators@oclsc.org> Check out "Setting Up a Research UNIX System" by Norman Wilson. troff sources are in v10. ==== But that assumes you're being given a root image to copy to the disk initially, no? We never made a general-purpose distribution tape; we just made one-off snapshots when someone wanted a copy of the system in the 10/e era. Is there a binary root image in Warren's archive? I forget. Norman Wilson Toronto ON (where the weather feels like NJ these days, dammit) From aap at papnet.eu Sat Aug 31 06:10:32 2019 From: aap at papnet.eu (Angelo Papenhoff) Date: Fri, 30 Aug 2019 22:10:32 +0200 Subject: [TUHS] Running v10 In-Reply-To: <1567194618.21207.for-standards-violators@oclsc.org> References: <1567194618.21207.for-standards-violators@oclsc.org> Message-ID: <20190830201032.GA67899@indra.papnet.eu> On 30/08/19, Norman Wilson wrote: > Check out "Setting Up a Research UNIX System" by Norman Wilson. troff > sources are in v10. > > ==== > > But that assumes you're being given a root image to copy > to the disk initially, no? We never made a general-purpose > distribution tape; we just made one-off snapshots when someone > wanted a copy of the system in the 10/e era. > > Is there a binary root image in Warren's archive? I forget. No we don't. Our hope would be to compile things from source and bootstrap it from v8. I don't know the state of v9, I've seen it emulated on a sun but if this helps with bootstrapping v10... We also have sources for Doug's IX in history/ix...maybe that helps too in some ways. Or maybe someone who still has v10 running can help out. I'd really like to see it running, wouldn't it be fitting for the 50th anniversary? aap From norman at oclsc.org Sat Aug 31 06:21:47 2019 From: norman at oclsc.org (Norman Wilson) Date: Fri, 30 Aug 2019 16:21:47 -0400 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] Message-ID: <1567196510.21824.for-standards-violators@oclsc.org> John Reiser did do his own paging system for UNIX 32/V. I heard about it from friends at Bell Labs ca. 1982-83, when I was still running systems for physicists at Caltech. It sounded very interesting, and I would love to have had my hands on it--page cache unified with buffer cache, copy-on-write from the start. The trouble is that Reiser worked in a different group from the original UNIX crowd, and his management didn't think his time well spent on that work, so it never got released. I remember asking, either during my interview at the Labs or after I started work there, why the 4.1 kernel had been chosen instead of Reiser's. It had to do with maintainability: there were already people who could come in and hack on the Berkeley system, as well as more using it and maintaining it, whereas Reiser's system had become a unicorn. Nobody in 1127 wanted to maintain a VM system or anything much close to the VAX hardware. So the decision was to stick with a kernel for which someone else would do those things. Once I'd been there for a year or so and settled in, I found that I was actually looking after all that stuff, because I was really interested in it. (Which seemed to delight a lot of people.) Would we have ended up using Reiser's kernel had I been there a couple of years earlier? I don't know. It is in any case a shame that jfr's code never saw the light of day. I really hope someone can find it on an old tape somewhere and we can get it into the archive, if only because I'd love to look at it. Norman Wilson Toronto ON From lm at mcvoy.com Sat Aug 31 06:28:14 2019 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 30 Aug 2019 13:28:14 -0700 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: <1567196510.21824.for-standards-violators@oclsc.org> References: <1567196510.21824.for-standards-violators@oclsc.org> Message-ID: <20190830202814.GF10796@mcvoy.com> On Fri, Aug 30, 2019 at 04:21:47PM -0400, Norman Wilson wrote: > John Reiser did do his own paging system for UNIX 32/V. > I heard about it from friends at Bell Labs ca. 1982-83, > when I was still running systems for physicists at Caltech. > It sounded very interesting, and I would love to have had > my hands on it--page cache unified with buffer cache, > copy-on-write from the start. Huh, Moran published his SunOS VM system paper in 1988, my guess is he was working on the code for a year or two before that. So Reiser's work predates that. Super interesting. I too would love for someone to find a copy of that code. From clemc at ccc.com Sat Aug 31 06:39:09 2019 From: clemc at ccc.com (Clem Cole) Date: Fri, 30 Aug 2019 16:39:09 -0400 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: <1567196510.21824.for-standards-violators@oclsc.org> References: <1567196510.21824.for-standards-violators@oclsc.org> Message-ID: On Fri, Aug 30, 2019 at 4:22 PM Norman Wilson wrote: > It had to do with maintainability: > there were already people who could come in and hack on the > Berkeley system, as well as more using it and maintaining it, > whereas Reiser's system had become a unicorn. Nobody in > 1127 wanted to maintain a VM system or anything much close > to the VAX hardware. So the decision was to stick with a > kernel for which someone else would do those things. Norman, I suspect the folks in 1127 was really not different the CS-Dept at UCB in fact. The whole reason CSRG wound down (and that was before wnj left BTW) is the project stopped being research and started to have a maintainence flavor which a lot of people found distasteful. Funny, one of the things that I think made BSD the most useful, and *really where wnj made his contribution IMO,* was the all the 'completors' between things like the #ifdef FAST_VAX work and autoconfiguration, all the new device support, *etc*. That was a huge amount of work not very sexy work that made 4.1BSD in particular, 'just work' I had had the out-of-box experience with all of V5 in RK05s, V6 and V7 on 9-track tape, earlier. 4.1BSD was a dream, really not much to do but role the tape and answer questions. I can see why people liked that. I remember a lot of people complaining about the BSD VM system, but it worked 'good enough.' I can tell you when we did the Masscomp system (and the first thing I worked on was the VM system with tjt), even thought we had started with a System III kernel (that was our license), we pulled Joy's code in for the VM pretty early. The first thing Tom and I did is made it 'MP-safe' (big lock scheme to be honest) but we were interested in debugging the locking code, not the VM system. It's true when we did Stellar and had V.3, we used the AT&T VM base by that point and started over, used a fine grain locking model etc...., but by we knew how to make a MP UNIX box by then (remember the MC-500/DP was the first MP Unix >>product<< -- predates our friends in on the West coast by 2 years). -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sat Aug 31 07:52:02 2019 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 30 Aug 2019 14:52:02 -0700 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: References: <1567196510.21824.for-standards-violators@oclsc.org> Message-ID: <20190830215202.GA974@mcvoy.com> On Fri, Aug 30, 2019 at 04:39:09PM -0400, Clem Cole wrote: > MC-500/DP was the first MP Unix >>product<< -- predates our friends in on > the West coast by 2 years). And as I recall you had to do 2 68000's in lockstep to get the VM system to do page fault restarts. That was neat, was that a Masscomp invention or was it a commonly known trick? --lm From clemc at ccc.com Sat Aug 31 10:58:13 2019 From: clemc at ccc.com (Clem Cole) Date: Fri, 30 Aug 2019 20:58:13 -0400 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: <20190830215202.GA974@mcvoy.com> References: <1567196510.21824.for-standards-violators@oclsc.org> <20190830215202.GA974@mcvoy.com> Message-ID: Actually not in lock step. They were independent. One was called the executor and the other the fixer. When a fault was detected the executor was sent wait stated while the fixer handled the fault and refilled the TLB. Once the TLB was set to instruction was allowed to complete. Btw when the 68010 was released the pals on the board were changed to allow the executor to actually take the fault and do something else while the fixer replaced the TLB entry The idea was proposed by Forest Baskett at an early Asilomar conference but never built by him - I want to say 1980 or 81. I have lost that paper and would love to find a copy again BTW. To be fair both Apollo and Masscomp’s hw teams reduced the idea to practice independently but I know of no other folks that tried it. On Fri, Aug 30, 2019 at 5:52 PM Larry McVoy wrote: > On Fri, Aug 30, 2019 at 04:39:09PM -0400, Clem Cole wrote: > > MC-500/DP was the first MP Unix >>product<< -- predates our friends in on > > the West coast by 2 years). > > And as I recall you had to do 2 68000's in lockstep to get the VM system > to do page fault restarts. That was neat, was that a Masscomp invention > or was it a commonly known trick? > > --lm > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at bitblocks.com Sat Aug 31 11:13:52 2019 From: bakul at bitblocks.com (Bakul Shah) Date: Fri, 30 Aug 2019 18:13:52 -0700 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: Your message of "Fri, 30 Aug 2019 20:58:13 -0400." References: <1567196510.21824.for-standards-violators@oclsc.org> <20190830215202.GA974@mcvoy.com> Message-ID: <20190831011359.E9F491570CE9@mail.bitblocks.com> On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole wrote: > > Actually not in lock step. They were independent. One was called the > executor and the other the fixer. When a fault was detected the executor > was sent wait stated while the fixer handled the fault and refilled the > TLB. Once the TLB was set to instruction was allowed to complete. Btw > when the 68010 was released the pals on the board were changed to allow the > executor to actually take the fault and do something else while the fixer > replaced the TLB entry As I remember, the issue with 68000 was that instructions were not restartable so in case of accessing memory that didn't exist, you couldn't take a segfault and do anything useful. This is why you needed a second processor to deal with an external MMU. There would have been no TLB unless you actually added an external TLB -- but an external CAM would've been very expensive. May be a direct map? What we did at Fortune was to utilize a 4 entry external map: text, data, extra and stack. When a new function was invoked it would do a 'probe'. If the probe caused a segfault, stack was extended in the handler. The probe didn't have to be restartable. So we didn't need a second 68k. This logic may have been in the V7 port we started from. From dave at horsfall.org Sat Aug 31 11:35:46 2019 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 31 Aug 2019 11:35:46 +1000 (EST) Subject: [TUHS] If not Linux, then what? In-Reply-To: <20190829191943.BfJ86%steffen@sdaoden.eu> References: <13c5c36e-c84d-e020-d09e-51c8c502dc6d@kilonet.net> <20190828231952.GA536@mit.edu> <3173aba3-b6c3-43db-6374-b600f3217f13@kilonet.net> <004ec49789583b190ca7c302db9fbb31@firemail.de> <20190829191943.BfJ86%steffen@sdaoden.eu> Message-ID: On Thu, 29 Aug 2019, Steffen Nurpmeso wrote: > |Today however not in the 80ths. Inn those days all 4 cars were Richie \ > |Rich cars. > > And only the Mazda had that wonderful smooth engine which replaces > pounding pistons with nice chuckling triangles. [ Getting OT... ] Too bad about the seals, though... They had this habit of wearing out. -- Dave From clemc at ccc.com Sat Aug 31 12:46:57 2019 From: clemc at ccc.com (Clem cole) Date: Fri, 30 Aug 2019 22:46:57 -0400 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: <20190831011359.E9F491570CE9@mail.bitblocks.com> References: <1567196510.21824.for-standards-violators@oclsc.org> <20190830215202.GA974@mcvoy.com> <20190831011359.E9F491570CE9@mail.bitblocks.com> Message-ID: <88242A0D-D08E-47EB-84DC-A7205780A417@ccc.com> There was most definitely a TLB or as Dave called it ‘The TB’ *** Remember Dave Cane (Masscomp hw lead) was part of the 780, led the 750 and designed the BI before he left dec. He was a bus and memory specialist *** west coast VS east coast training - calling it a TB vs a TLB. Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > On Aug 30, 2019, at 9:13 PM, Bakul Shah wrote: > >> On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole wrote: >> >> Actually not in lock step. They were independent. One was called the >> executor and the other the fixer. When a fault was detected the executor >> was sent wait stated while the fixer handled the fault and refilled the >> TLB. Once the TLB was set to instruction was allowed to complete. Btw >> when the 68010 was released the pals on the board were changed to allow the >> executor to actually take the fault and do something else while the fixer >> replaced the TLB entry > > As I remember, the issue with 68000 was that instructions were > not restartable so in case of accessing memory that didn't > exist, you couldn't take a segfault and do anything useful. > This is why you needed a second processor to deal with an > external MMU. There would have been no TLB unless you actually > added an external TLB -- but an external CAM would've been > very expensive. May be a direct map? > > What we did at Fortune was to utilize a 4 entry external map: > text, data, extra and stack. When a new function was invoked > it would do a 'probe'. If the probe caused a segfault, stack > was extended in the handler. The probe didn't have to be > restartable. So we didn't need a second 68k. This logic may > have been in the V7 port we started from. From clemc at ccc.com Sat Aug 31 12:57:22 2019 From: clemc at ccc.com (Clem cole) Date: Fri, 30 Aug 2019 22:57:22 -0400 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: <88242A0D-D08E-47EB-84DC-A7205780A417@ccc.com> References: <1567196510.21824.for-standards-violators@oclsc.org> <20190830215202.GA974@mcvoy.com> <20190831011359.E9F491570CE9@mail.bitblocks.com> <88242A0D-D08E-47EB-84DC-A7205780A417@ccc.com> Message-ID: Btw. The issue with the 68k was Nick Tredenick’s original Microcode did not save enough information during some of the faults. Les Crudele once told me, that it turns out he had tried to fix it but there were a series of errors and some short cuts they used to fit it in the store. They gave up trying to fix it as the part was purely skunkworks and they could not respin it at the time. After it succeeded and were a real project, the difference between the original and the 10 was Nick redid the microcode but they had made a larger microstore - otherwise basically the same Si. Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > On Aug 30, 2019, at 10:46 PM, Clem cole wrote: > > There was most definitely a TLB or as Dave called it ‘The TB’ *** > Remember Dave Cane (Masscomp hw lead) was part of the 780, led the 750 and designed the BI before he left dec. He was a bus and memory specialist > > > *** west coast VS east coast training - calling it a TB vs a TLB. > > Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > >>> On Aug 30, 2019, at 9:13 PM, Bakul Shah wrote: >>> >>> On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole wrote: >>> >>> Actually not in lock step. They were independent. One was called the >>> executor and the other the fixer. When a fault was detected the executor >>> was sent wait stated while the fixer handled the fault and refilled the >>> TLB. Once the TLB was set to instruction was allowed to complete. Btw >>> when the 68010 was released the pals on the board were changed to allow the >>> executor to actually take the fault and do something else while the fixer >>> replaced the TLB entry >> >> As I remember, the issue with 68000 was that instructions were >> not restartable so in case of accessing memory that didn't >> exist, you couldn't take a segfault and do anything useful. >> This is why you needed a second processor to deal with an >> external MMU. There would have been no TLB unless you actually >> added an external TLB -- but an external CAM would've been >> very expensive. May be a direct map? >> >> What we did at Fortune was to utilize a 4 entry external map: >> text, data, extra and stack. When a new function was invoked >> it would do a 'probe'. If the probe caused a segfault, stack >> was extended in the handler. The probe didn't have to be >> restartable. So we didn't need a second 68k. This logic may >> have been in the V7 port we started from. From gregg.drwho8 at gmail.com Sat Aug 31 13:14:29 2019 From: gregg.drwho8 at gmail.com (Gregg Levine) Date: Fri, 30 Aug 2019 23:14:29 -0400 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: References: <1567196510.21824.for-standards-violators@oclsc.org> <20190830215202.GA974@mcvoy.com> <20190831011359.E9F491570CE9@mail.bitblocks.com> <88242A0D-D08E-47EB-84DC-A7205780A417@ccc.com> Message-ID: Hello! That definitely groks with a decidedly thirty year old memory. I remember going to BUSCON, and getting into an interesting discussion with the folks behind the M68K just how difficult it could be to run more modern code (or operating systems). Let's just say it was peculiar. They wanted to stick with a proprietary OS, and one odd man there wanted to expand CPM-68K. And still another was looking into bringing up UNIX on it. It was fun. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again." On Fri, Aug 30, 2019 at 10:58 PM Clem cole wrote: > > Btw. The issue with the 68k was Nick Tredenick’s original Microcode did not save enough information during some of the faults. Les Crudele once told me, that it turns out he had tried to fix it but there were a series of errors and some short cuts they used to fit it in the store. They gave up trying to fix it as the part was purely skunkworks and they could not respin it at the time. After it succeeded and were a real project, the difference between the original and the 10 was Nick redid the microcode but they had made a larger microstore - otherwise basically the same Si. > > Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > > > On Aug 30, 2019, at 10:46 PM, Clem cole wrote: > > > > There was most definitely a TLB or as Dave called it ‘The TB’ *** > > Remember Dave Cane (Masscomp hw lead) was part of the 780, led the 750 and designed the BI before he left dec. He was a bus and memory specialist > > > > > > *** west coast VS east coast training - calling it a TB vs a TLB. > > > > Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > > > >>> On Aug 30, 2019, at 9:13 PM, Bakul Shah wrote: > >>> > >>> On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole wrote: > >>> > >>> Actually not in lock step. They were independent. One was called the > >>> executor and the other the fixer. When a fault was detected the executor > >>> was sent wait stated while the fixer handled the fault and refilled the > >>> TLB. Once the TLB was set to instruction was allowed to complete. Btw > >>> when the 68010 was released the pals on the board were changed to allow the > >>> executor to actually take the fault and do something else while the fixer > >>> replaced the TLB entry > >> > >> As I remember, the issue with 68000 was that instructions were > >> not restartable so in case of accessing memory that didn't > >> exist, you couldn't take a segfault and do anything useful. > >> This is why you needed a second processor to deal with an > >> external MMU. There would have been no TLB unless you actually > >> added an external TLB -- but an external CAM would've been > >> very expensive. May be a direct map? > >> > >> What we did at Fortune was to utilize a 4 entry external map: > >> text, data, extra and stack. When a new function was invoked > >> it would do a 'probe'. If the probe caused a segfault, stack > >> was extended in the handler. The probe didn't have to be > >> restartable. So we didn't need a second 68k. This logic may > >> have been in the V7 port we started from. From bakul at bitblocks.com Sat Aug 31 13:19:04 2019 From: bakul at bitblocks.com (Bakul Shah) Date: Fri, 30 Aug 2019 20:19:04 -0700 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: <88242A0D-D08E-47EB-84DC-A7205780A417@ccc.com> References: <1567196510.21824.for-standards-violators@oclsc.org> <20190830215202.GA974@mcvoy.com> <20190831011359.E9F491570CE9@mail.bitblocks.com> <88242A0D-D08E-47EB-84DC-A7205780A417@ccc.com> Message-ID: <8BFD5926-B916-4AA2-A896-4BA9E5AFDB69@bitblocks.com> It would be interesting to see its MMU details. > On Aug 30, 2019, at 7:46 PM, Clem cole wrote: > > There was most definitely a TLB or as Dave called it ‘The TB’ *** > Remember Dave Cane (Masscomp hw lead) was part of the 780, led the 750 and designed the BI before he left dec. He was a bus and memory specialist > > > *** west coast VS east coast training - calling it a TB vs a TLB. > > Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > >> On Aug 30, 2019, at 9:13 PM, Bakul Shah wrote: >> >>> On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole wrote: >>> >>> Actually not in lock step. They were independent. One was called the >>> executor and the other the fixer. When a fault was detected the executor >>> was sent wait stated while the fixer handled the fault and refilled the >>> TLB. Once the TLB was set to instruction was allowed to complete. Btw >>> when the 68010 was released the pals on the board were changed to allow the >>> executor to actually take the fault and do something else while the fixer >>> replaced the TLB entry >> >> As I remember, the issue with 68000 was that instructions were >> not restartable so in case of accessing memory that didn't >> exist, you couldn't take a segfault and do anything useful. >> This is why you needed a second processor to deal with an >> external MMU. There would have been no TLB unless you actually >> added an external TLB -- but an external CAM would've been >> very expensive. May be a direct map? >> >> What we did at Fortune was to utilize a 4 entry external map: >> text, data, extra and stack. When a new function was invoked >> it would do a 'probe'. If the probe caused a segfault, stack >> was extended in the handler. The probe didn't have to be >> restartable. So we didn't need a second 68k. This logic may >> have been in the V7 port we started from. From bakul at bitblocks.com Sat Aug 31 13:38:14 2019 From: bakul at bitblocks.com (Bakul Shah) Date: Fri, 30 Aug 2019 20:38:14 -0700 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: References: <1567196510.21824.for-standards-violators@oclsc.org> <20190830215202.GA974@mcvoy.com> <20190831011359.E9F491570CE9@mail.bitblocks.com> <88242A0D-D08E-47EB-84DC-A7205780A417@ccc.com> Message-ID: One thing I can think of is something like this: IIRC 68k had 24 address bits. So with a 4K page size, you can have one level pagetable. If the pagetable is in fast SRAM, may be 1 or 2 clock cyles would be added. If you allow 2^N processes, you need 2^(12+N) entry page table. The width of the table would depend on the number of 4K pages in the physical memory. Context switch would be to simply set the 2^N bit process "base" register. Going beyond 2^N you'd have to swap out a process. Each process can then grow up to 16MB. I don't think a real translation lookaside buffer would help much. It would be interesting to see the actual details. > On Aug 30, 2019, at 7:57 PM, Clem cole wrote: > > Btw. The issue with the 68k was Nick Tredenick’s original Microcode did not save enough information during some of the faults. Les Crudele once told me, that it turns out he had tried to fix it but there were a series of errors and some short cuts they used to fit it in the store. They gave up trying to fix it as the part was purely skunkworks and they could not respin it at the time. After it succeeded and were a real project, the difference between the original and the 10 was Nick redid the microcode but they had made a larger microstore - otherwise basically the same Si. > > Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > >> On Aug 30, 2019, at 10:46 PM, Clem cole wrote: >> >> There was most definitely a TLB or as Dave called it ‘The TB’ *** >> Remember Dave Cane (Masscomp hw lead) was part of the 780, led the 750 and designed the BI before he left dec. He was a bus and memory specialist >> >> >> *** west coast VS east coast training - calling it a TB vs a TLB. >> >> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. >> >>>> On Aug 30, 2019, at 9:13 PM, Bakul Shah wrote: >>>> >>>> On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole wrote: >>>> >>>> Actually not in lock step. They were independent. One was called the >>>> executor and the other the fixer. When a fault was detected the executor >>>> was sent wait stated while the fixer handled the fault and refilled the >>>> TLB. Once the TLB was set to instruction was allowed to complete. Btw >>>> when the 68010 was released the pals on the board were changed to allow the >>>> executor to actually take the fault and do something else while the fixer >>>> replaced the TLB entry >>> >>> As I remember, the issue with 68000 was that instructions were >>> not restartable so in case of accessing memory that didn't >>> exist, you couldn't take a segfault and do anything useful. >>> This is why you needed a second processor to deal with an >>> external MMU. There would have been no TLB unless you actually >>> added an external TLB -- but an external CAM would've been >>> very expensive. May be a direct map? >>> >>> What we did at Fortune was to utilize a 4 entry external map: >>> text, data, extra and stack. When a new function was invoked >>> it would do a 'probe'. If the probe caused a segfault, stack >>> was extended in the handler. The probe didn't have to be >>> restartable. So we didn't need a second 68k. This logic may >>> have been in the V7 port we started from. From clemc at ccc.com Sat Aug 31 13:47:00 2019 From: clemc at ccc.com (Clem cole) Date: Fri, 30 Aug 2019 23:47:00 -0400 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: References: <1567196510.21824.for-standards-violators@oclsc.org> <20190830215202.GA974@mcvoy.com> <20190831011359.E9F491570CE9@mail.bitblocks.com> <88242A0D-D08E-47EB-84DC-A7205780A417@ccc.com> Message-ID: <8797F327-14CE-42C2-9B8B-8A58AEA1CC82@ccc.com> Fwiw. the 68k design team used a 11/70 running an ISC based Unix and with Rand Editor running in Perkin Elmer Fox terminals with special microcode in the 6800 in the terminals roms. Basically Les, Nick and Tom were all Unix folks. Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > On Aug 30, 2019, at 11:14 PM, Gregg Levine wrote: > > Hello! > That definitely groks with a decidedly thirty year old memory. I > remember going to BUSCON, and getting into an interesting discussion > with the folks behind the M68K just how difficult it could be to run > more modern code (or operating systems). Let's just say it was > peculiar. They wanted to stick with a proprietary OS, and one odd man > there wanted to expand CPM-68K. And still another was looking into > bringing up UNIX on it. > > It was fun. > ----- > Gregg C Levine gregg.drwho8 at gmail.com > "This signature fought the Time Wars, time and again." > >> On Fri, Aug 30, 2019 at 10:58 PM Clem cole wrote: >> >> Btw. The issue with the 68k was Nick Tredenick’s original Microcode did not save enough information during some of the faults. Les Crudele once told me, that it turns out he had tried to fix it but there were a series of errors and some short cuts they used to fit it in the store. They gave up trying to fix it as the part was purely skunkworks and they could not respin it at the time. After it succeeded and were a real project, the difference between the original and the 10 was Nick redid the microcode but they had made a larger microstore - otherwise basically the same Si. >> >> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. >> >>> On Aug 30, 2019, at 10:46 PM, Clem cole wrote: >>> >>> There was most definitely a TLB or as Dave called it ‘The TB’ *** >>> Remember Dave Cane (Masscomp hw lead) was part of the 780, led the 750 and designed the BI before he left dec. He was a bus and memory specialist >>> >>> >>> *** west coast VS east coast training - calling it a TB vs a TLB. >>> >>> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. >>> >>>>> On Aug 30, 2019, at 9:13 PM, Bakul Shah wrote: >>>>> >>>>> On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole wrote: >>>>> >>>>> Actually not in lock step. They were independent. One was called the >>>>> executor and the other the fixer. When a fault was detected the executor >>>>> was sent wait stated while the fixer handled the fault and refilled the >>>>> TLB. Once the TLB was set to instruction was allowed to complete. Btw >>>>> when the 68010 was released the pals on the board were changed to allow the >>>>> executor to actually take the fault and do something else while the fixer >>>>> replaced the TLB entry >>>> >>>> As I remember, the issue with 68000 was that instructions were >>>> not restartable so in case of accessing memory that didn't >>>> exist, you couldn't take a segfault and do anything useful. >>>> This is why you needed a second processor to deal with an >>>> external MMU. There would have been no TLB unless you actually >>>> added an external TLB -- but an external CAM would've been >>>> very expensive. May be a direct map? >>>> >>>> What we did at Fortune was to utilize a 4 entry external map: >>>> text, data, extra and stack. When a new function was invoked >>>> it would do a 'probe'. If the probe caused a segfault, stack >>>> was extended in the handler. The probe didn't have to be >>>> restartable. So we didn't need a second 68k. This logic may >>>> have been in the V7 port we started from. From dave at horsfall.org Sat Aug 31 15:37:32 2019 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 31 Aug 2019 15:37:32 +1000 (EST) Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] In-Reply-To: References: <1567196510.21824.for-standards-violators@oclsc.org> <20190830215202.GA974@mcvoy.com> <20190831011359.E9F491570CE9@mail.bitblocks.com> <88242A0D-D08E-47EB-84DC-A7205780A417@ccc.com> Message-ID: On Fri, 30 Aug 2019, Clem cole wrote: > Btw. The issue with the 68k was Nick Tredenick’s original Microcode did > not save enough information during some of the faults. Les Crudele once > told me, that it turns out he had tried to fix it but there were a > series of errors and some short cuts they used to fit it in the store. > They gave up trying to fix it as the part was purely skunkworks and they > could not respin it at the time. After it succeeded and were a real > project, the difference between the original and the 10 was Nick redid > the microcode but they had made a larger microstore - otherwise > basically the same Si. Yep, that certainly rings a bell. ISTR that Sun had a board with the two CPUs, one keeping an eye on the other. Ah, those were the days :-) Now, we just have to put up with Intel, although I believe the ARM is much better. -- Dave From rudi.j.blom at gmail.com Sat Aug 31 19:43:47 2019 From: rudi.j.blom at gmail.com (Rudi Blom) Date: Sat, 31 Aug 2019 16:43:47 +0700 Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] Message-ID: Whenever I hear UNIX, networking and streams I have to think about this scheme. Still using this, even on HP-UX 11.31 on Itanium rx-servers Cheers, uncle rubl -------------- next part -------------- A non-text attachment was scrubbed... Name: Transport Interface.gif Type: image/gif Size: 8969 bytes Desc: not available URL: From steve at quintile.net Sat Aug 31 19:44:22 2019 From: steve at quintile.net (Steve Simon) Date: Sat, 31 Aug 2019 11:44:22 +0200 Subject: [TUHS] early vm systems Message-ID: hi the other early vm system not mentioned yet is the one Charles Forsyth wrote at the university of york for sunos. i never used it as i was learning v7 on an interdata 30 miles away at the time but i read his excellent paper on it. -Steve From thomas.paulsen at firemail.de Sat Aug 31 22:04:19 2019 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Sat, 31 Aug 2019 14:04:19 +0200 Subject: [TUHS] early vm systems In-Reply-To: References: Message-ID: --- Ursprüngliche Nachricht --- Von: Steve Simon Datum: 31.08.2019 11:44:22 An: tuhs at minnie.tuhs.org Betreff: [TUHS] early vm systems > hi > > the other early vm system not mentioned yet is the one Charles Forsyth wrote > at the university of york for sunos. i never used it as i was learning v7 > on an interdata 30 miles away at the time but i read his excellent paper > on it. did you mean: https://www.researchgate.net/publication/2411547_The_Mether_System_Distributed_Shared_Memory_for_SunOS_40