From clemc at ccc.com Sat Sep 1 00:41:21 2018 From: clemc at ccc.com (Clem Cole) Date: Fri, 31 Aug 2018 10:41:21 -0400 Subject: [TUHS] UNIX System names - since UNIX was a Trademark In-Reply-To: References: <20180829233605.GJ8423@mcvoy.com> <69AFD606-5E1D-4060-95A5-22F33B2322B2@ccc.com> Message-ID: Dave Horsfall's comment about AIX made me think. The joker in me has always been impressed by how marketing people 'missed' the obvious pronunciations that would lead to serious jokes. Some of the more memorable ones from the UNIX world that I knew: AIX -> "aches", CRDS -> "cruds", HP-UX -> HP "yucks" and "hockey pucks" and my favorite: RHEL -> "our hell" I bet there are more and others I did know/consider ;-) That said, I did hear a pro-VMS person in ZKO (*i.e.* a DECie) once tried refered to "DEC Ultrix" as Dirty Tricks, but I never heard that one take off/be repeated outside of ZKO. For history we probably should try to collect them, although I fear the context of the joke in the future may be lost. Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ewayte at gmail.com Sat Sep 1 01:13:53 2018 From: ewayte at gmail.com (Eric Wayte) Date: Fri, 31 Aug 2018 11:13:53 -0400 Subject: [TUHS] UNIX System names - since UNIX was a Trademark In-Reply-To: References: <20180829233605.GJ8423@mcvoy.com> <69AFD606-5E1D-4060-95A5-22F33B2322B2@ccc.com> Message-ID: I've heard Red Hat referred to as "root hat". On Fri, Aug 31, 2018 at 10:42 AM Clem Cole wrote: > > Dave Horsfall's comment about AIX made me think. The joker in me has > always been impressed by how marketing people 'missed' the obvious > pronunciations that would lead to serious > > jokes. > Some of the more memorable ones from the UNIX world that I knew: AIX -> > "aches", CRDS -> "cruds", HP-UX -> HP "yucks" and "hockey pucks" and my > favorite: RHEL -> "our hell" > > I bet there are more and others I did know/consider ;-) > > That said, I did hear a pro-VMS person in ZKO (*i.e.* a DECie) once tried > refered to "DEC Ultrix" as Dirty Tricks, but I never heard that one take > off/be repeated outside of ZKO. > > For history we probably should try to collect them, although I fear the > context of the joke in the future may be lost. > > > Clem > ᐧ > -- Eric Wayte -------------- next part -------------- An HTML attachment was scrubbed... URL: From pechter at gmail.com Sat Sep 1 01:17:54 2018 From: pechter at gmail.com (William Pechter) Date: Fri, 31 Aug 2018 11:17:54 -0400 Subject: [TUHS] UNIX System names - since UNIX was a Trademark In-Reply-To: References: <20180829233605.GJ8423@mcvoy.com> <69AFD606-5E1D-4060-95A5-22F33B2322B2@ccc.com> Message-ID: <3b0a2895-4a6b-48c4-87da-cc1018d7b665.maildroid@localhost> UNIX is a trademark of AT&T AT&T is a modem test command. -----Original Message----- From: Clem Cole To: Dave Horsfall Cc: The Eunuchs Hysterical Society Sent: Fri, 31 Aug 2018 10:42 Subject: Re: [TUHS] UNIX System names - since UNIX was a Trademark Dave Horsfall's comment about AIX made me think. The joker in me has always been impressed by how marketing people 'missed' the obvious pronunciations that would lead to serious jokes. Some of the more memorable ones from the UNIX world that I knew: AIX -> "aches", CRDS -> "cruds", HP-UX -> HP "yucks" and "hockey pucks" and my favorite: RHEL -> "our hell" I bet there are more and others I did know/consider ;-) That said, I did hear a pro-VMS person in ZKO (*i.e.* a DECie) once tried refered to "DEC Ultrix" as Dirty Tricks, but I never heard that one take off/be repeated outside of ZKO. For history we probably should try to collect them, although I fear the context of the joke in the future may be lost. Clem ᐧ From clemc at ccc.com Sat Sep 1 01:25:38 2018 From: clemc at ccc.com (Clem Cole) Date: Fri, 31 Aug 2018 11:25:38 -0400 Subject: [TUHS] UNIX System names - since UNIX was a Trademark In-Reply-To: <3b0a2895-4a6b-48c4-87da-cc1018d7b665.maildroid@localhost> References: <20180829233605.GJ8423@mcvoy.com> <69AFD606-5E1D-4060-95A5-22F33B2322B2@ccc.com> <3b0a2895-4a6b-48c4-87da-cc1018d7b665.maildroid@localhost> Message-ID: Fair enough, but was a cute joke that made those "in the know" smile (like me), but less of a dig at a marketing naming IMO - like RHEL - not seeing the obvious way to pronounce the name - duh. I was more thinking terms of things like that that marketing folks just were clueless. Clem ᐧ On Fri, Aug 31, 2018 at 11:17 AM William Pechter wrote: > UNIX is a trademark of AT&T > AT&T is a modem test command. > > -----Original Message----- > From: Clem Cole > To: Dave Horsfall > Cc: The Eunuchs Hysterical Society > Sent: Fri, 31 Aug 2018 10:42 > Subject: Re: [TUHS] UNIX System names - since UNIX was a Trademark > > Dave Horsfall's comment about AIX made me think. The joker in me has > always been impressed by how marketing people 'missed' the obvious > pronunciations that would lead to serious > > jokes. > Some of the more memorable ones from the UNIX world that I knew: AIX -> > "aches", CRDS -> "cruds", HP-UX -> HP "yucks" and "hockey pucks" and my > favorite: RHEL -> "our hell" > > I bet there are more and others I did know/consider ;-) > > That said, I did hear a pro-VMS person in ZKO (*i.e.* a DECie) once tried > refered to "DEC Ultrix" as Dirty Tricks, but I never heard that one take > off/be repeated outside of ZKO. > > For history we probably should try to collect them, although I fear the > context of the joke in the future may be lost. > > > Clem > ᐧ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcmer-tuhs at tor.at Sat Sep 1 02:07:14 2018 From: mcmer-tuhs at tor.at (Marcus Merighi) Date: Fri, 31 Aug 2018 18:07:14 +0200 Subject: [TUHS] gopher://ftp.icm.edu.pl/1/vol/rzm2/ Message-ID: <20180831160714.GY98238@tor.at> Hello, against my plan to stay under my rock and learn from your messages I now have to speak up, because I stumbled over this: https://bsd.network/@sehnsucht/100635118831337239 which speaks of gopher://ftp.icm.edu.pl/1/vol/rzm2/ (after some puzzled searching for a client I found out that lynx still supports gopher) This site has the following list in its root directory: 4.4BSD-Lite FreeBSD LSI NetBSD OpenBSD UnixArchive ancient-unix desktopbsd dragonflybsd ghostbsd kde kde-applicationdata kś linux-alsa linux-archlinux linux-atm linux-bipv6 linux-blackarch linux-bluehawk linux-cbq.init linux-cryptoapi linux-documentation linux-dret linux-e2compr linux-fido linux-gentoo linux-gentoo-portage linux-inner linux-iproute linux-linos linux-net-tools linux-norlug linux-nvidia linux-nvidia.old linux-nvidia.old2 linux-openvz linux-packware linux-pcmcia linux-radvd linux-raspbian linux-reiserfs linux-rtlinux linux-sgi linux-silo linux-slackware linux-sparc linux-superrescue linux-tsx-11 linux-uk linux-usagi linux-uw-linux linux-vectorlinux linuxberg nexenta openindiana opensolaris pcbsd solaris-10 solaris-cd-fsn solaris-cd-pm solaris_i86pc solaris_sparc sun-fixes sun-patches www.tazenda.demon.co.uk I descended into the OpenBSD directory, where things look quite authentic, at a first glance. Please keep the stories coming, Marcus From ckeck at texoma.net Sat Sep 1 02:24:44 2018 From: ckeck at texoma.net (Cornelius Keck) Date: Fri, 31 Aug 2018 11:24:44 -0500 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: References: <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com> <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net> <1d8c0539-8b43-9954-d8a7-db4dcc22b27d@texoma.net> Message-ID: Cool, thx for the pointer with the mailing list! Grant Taylor via TUHS wrote: > On 08/30/2018 07:15 PM, Cornelius Keck wrote: >> Do I want to reserve retronet.us? Could host that here, as I have >> static IPs. > > I'm not going to tell you not to do so if you want to. > > I will say that I have registered "retrocomp.net", as in "Retro > Computing Network". > > The person that has registered "retronet.com" (TLD is from memory) has > both expressed interest in participating and offered use of the domain. > > So … I think for the moment we are going to continue with retrocomp.net > because that's what we have started with. > > That being said, it is early enough in the process that we can still > change domain names if we want to. I would encourage you to subscribe > to the RetroNet mailing list and start a conversation about which domain > name to use. > > Link - RetroNet mailing list > - http://mailman.chivanet.org/listinfo/retronet > >> Having static IPs hanging of a FIOS line is cheaper and easier than >> dealing with a hoster.. > > *nod* > > I run my personal services on a Linode VPS. They have served me very > well. :-) > > > From ckeck at texoma.net Sat Sep 1 02:24:24 2018 From: ckeck at texoma.net (Cornelius Keck) Date: Fri, 31 Aug 2018 11:24:24 -0500 Subject: [TUHS] =?utf-8?q?RetroNet=E2=80=A6_Virtual_is_cheap=2E?= In-Reply-To: References: <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com> <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net> <1d8c0539-8b43-9954-d8a7-db4dcc22b27d@texoma.net> Message-ID: Indeed, that's cheap. When I started out back in ... thinking .... '99 with my first own domain, there were not that many offerings for hosting at the cost for (then) DSL plus static IPs. Had there been offerings this low back then I might have opted for that. But, I liked the way to have physical control over my setup, still do, so there was, is no reason to switch at this time. Given different circumstances, I might. William Pechter wrote: > Actually, my virtual machine @Digital Ocean has been $5.25/month. Can't get static IP on my Fios for that. Domain registration and DNS via Google Domains is another buck per month... > > I run mail, web and DNS for $6.25/month on FreeBSD or Linux with full root control. > > > > -----Original Message----- > From: Cornelius Keck > To: Grant Taylor , tuhs at minnie.tuhs.org > Sent: Thu, 30 Aug 2018 21:17 > Subject: Re: [TUHS] RetroNet… > > Do I want to reserve retronet.us? Could host that here, as I have static > IPs. > > Having static IPs hanging of a FIOS line is cheaper and easier than > dealing with a hoster.. > > > Grant Taylor via TUHS wrote: >> On 08/29/2018 12:04 PM, Seth Morabito wrote: >>> Hmm. I hate to bring this up, but I've been using the name RetroNET as >>> well. I've had the domain retronet.net registered for ages, and was >>> about to launch a small pilot project with a handful of 3B2 emulators >>> running SVR3, with the hope for many more interconnected systems. >> >> *gulp* >> >> So /you're/ the person that had the domain name we originally wanted. ;-) >> >> We actually decided that we liked "Retro Comp(uting) . Net(work)" and >> have registered that name. There is a wiki(…) and forum(…), but the >> main website isn't up yet. >> >> We are about a week into the discussions. Please join us in the >> #retronet group on the Synchronet network. (irc.chivanet.org) >> >>> That said, maybe we could pool our efforts? I'd be happy to share the >>> domain name with this effort, since it's precisely in line with what >>> I'd like to see. >> >> ~sigh~of~relief~ >> >> I think we would love to welcome more members into the RetroNet. >> >> As much as anything else, the idea is to build a community of friendly >> folks that want to play / learn / help each other, likely in direct >> relation to retro computing. >> >> >> From gtaylor at tnetconsulting.net Sat Sep 1 03:31:35 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Fri, 31 Aug 2018 11:31:35 -0600 Subject: [TUHS] =?utf-8?q?RetroNet=E2=80=A6_Virtual_is_cheap=2E?= In-Reply-To: References: <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com> <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net> <1d8c0539-8b43-9954-d8a7-db4dcc22b27d@texoma.net> Message-ID: On 08/31/2018 10:24 AM, Cornelius Keck wrote: > But, I liked the way to have physical control over my setup, still do, > so there was, is no reason to switch at this time. Given different > circumstances, I might. I've actually seen / discussed some options to combine the static IP that you get with inexpensive VPSs with the only dynamic nature of some residential connections. I'd be happy to talk about details on COFF if people are interested. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From pechter at gmail.com Sat Sep 1 03:36:09 2018 From: pechter at gmail.com (William Pechter) Date: Fri, 31 Aug 2018 13:36:09 -0400 Subject: [TUHS] =?utf-8?q?RetroNet=E2=80=A6_Virtual_is_cheap=2E?= In-Reply-To: References: <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com> <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net> <1d8c0539-8b43-9954-d8a7-db4dcc22b27d@texoma.net> Message-ID: <7b3d9f5f-af86-40ef-aafb-224f6162eb43.maildroid@localhost> One thought about Digital Ocean is they even have a web browser based graphic console so you get to fix things @ single user yourself as well as run X remotely if needed... -----Original Message----- From: Cornelius Keck To: William Pechter Cc: ckeck at texoma.net, tuhs at tuhs.org Sent: Fri, 31 Aug 2018 12:24 Subject: Re: [TUHS] RetroNet… Virtual is cheap. Indeed, that's cheap. When I started out back in ... thinking .... '99 with my first own domain, there were not that many offerings for hosting at the cost for (then) DSL plus static IPs. Had there been offerings this low back then I might have opted for that. But, I liked the way to have physical control over my setup, still do, so there was, is no reason to switch at this time. Given different circumstances, I might. William Pechter wrote: > Actually, my virtual machine @Digital Ocean has been $5.25/month. Can't get static IP on my Fios for that. Domain registration and DNS via Google Domains is another buck per month... > > I run mail, web and DNS for $6.25/month on FreeBSD or Linux with full root control. > > > > -----Original Message----- > From: Cornelius Keck > To: Grant Taylor , tuhs at minnie.tuhs.org > Sent: Thu, 30 Aug 2018 21:17 > Subject: Re: [TUHS] RetroNet… > > Do I want to reserve retronet.us? Could host that here, as I have static > IPs. > > Having static IPs hanging of a FIOS line is cheaper and easier than > dealing with a hoster.. > > > Grant Taylor via TUHS wrote: >> On 08/29/2018 12:04 PM, Seth Morabito wrote: >>> Hmm. I hate to bring this up, but I've been using the name RetroNET as >>> well. I've had the domain retronet.net registered for ages, and was >>> about to launch a small pilot project with a handful of 3B2 emulators >>> running SVR3, with the hope for many more interconnected systems. >> >> *gulp* >> >> So /you're/ the person that had the domain name we originally wanted. ;-) >> >> We actually decided that we liked "Retro Comp(uting) . Net(work)" and >> have registered that name. There is a wiki(…) and forum(…), but the >> main website isn't up yet. >> >> We are about a week into the discussions. Please join us in the >> #retronet group on the Synchronet network. (irc.chivanet.org) >> >>> That said, maybe we could pool our efforts? I'd be happy to share the >>> domain name with this effort, since it's precisely in line with what >>> I'd like to see. >> >> ~sigh~of~relief~ >> >> I think we would love to welcome more members into the RetroNet. >> >> As much as anything else, the idea is to build a community of friendly >> folks that want to play / learn / help each other, likely in direct >> relation to retro computing. >> >> >> From ca6c at bitmessage.ch Sat Sep 1 07:34:51 2018 From: ca6c at bitmessage.ch (=?utf-8?B?Q8OhZw==?=) Date: Fri, 31 Aug 2018 16:34:51 -0500 Subject: [TUHS] SunOS code? In-Reply-To: References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu> Message-ID: <20180831213451.r7LAj%ca6c@bitmessage.ch> Kevin Bowling wrote: > Sun releasing OpenSolaris when they finally did and under the CDDL was > pretty tone deaf to what was going on in the market with Linux, but > you have to admire the amount of contract review and legal work that > must have taken. How is OpenSolaris different from SunOS (Sun/Oracle Solaris) anyway? Isn't the relationship kinda RHEL-CentOS'ish? I.e. one is community- -supported, and another is commercially. -- caóc From clemc at ccc.com Sat Sep 1 07:39:31 2018 From: clemc at ccc.com (Clem Cole) Date: Fri, 31 Aug 2018 17:39:31 -0400 Subject: [TUHS] SunOS code? In-Reply-To: <20180831213451.r7LAj%ca6c@bitmessage.ch> References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu> <20180831213451.r7LAj%ca6c@bitmessage.ch> Message-ID: On Fri, Aug 31, 2018 at 5:36 PM Cág wrote: > How is OpenSolaris different from SunOS (Sun/Oracle Solaris) anyway? > Isn't the relationship kinda RHEL-CentOS'ish? I.e. one is > community--supported, and another is commercially. > Yikes -- this is like Rolls Royce cutting a deal with GM and produce a new car based on the Chevy Sububuran, painting it, adding a few details and calling it a Silver Ghost. SunOS != is not Solaris ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From krewat at kilonet.net Sat Sep 1 07:47:38 2018 From: krewat at kilonet.net (Arthur Krewat) Date: Fri, 31 Aug 2018 17:47:38 -0400 Subject: [TUHS] SunOS code? In-Reply-To: References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu> <20180831213451.r7LAj%ca6c@bitmessage.ch> Message-ID: On 8/31/2018 5:39 PM, Clem Cole wrote: > SunOS != is not Solaris > > ᐧ Confusion may arise because the last released SunOS 4.1.4 was called "Solaris 1.1.2". Solaris nor SunOS were ever "community supported" although one could make the case that SunOS was more generally liked ;) -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Sep 1 07:47:50 2018 From: clemc at ccc.com (Clem Cole) Date: Fri, 31 Aug 2018 17:47:50 -0400 Subject: [TUHS] Usenix: no official Unix 50th celebration, (yet) In-Reply-To: <20180826003127.GA18905@minnie.tuhs.org> References: <20180826003127.GA18905@minnie.tuhs.org> Message-ID: I do not want to say too much yet --- but I am making progress. As people have determined on this list, there are some real financial realities. Warren asked me a question -- I answered it. There is nothing (yet) official. But some things have occurred in the last few days that are encouraging. I will keep you all posted as it progresses. What you can do it to say to bod at usenix.org you would like to see it happen, particularly if you are a member of the organization (feel free to CC me). They need to hear that it is worthwhile and something they should spend some effort and money doing. Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ca6c at bitmessage.ch Sat Sep 1 07:56:36 2018 From: ca6c at bitmessage.ch (=?utf-8?B?Q8OhZw==?=) Date: Fri, 31 Aug 2018 16:56:36 -0500 Subject: [TUHS] cat -v and other complaints In-Reply-To: References: Message-ID: <20180831215636.-eCEx%ca6c@bitmessage.ch> Not completely on-topic, in my opinion one of the reasons Plan9 failed was the fact that it presented itself overly idealistic, occasionally sacrificing usability -- maybe it's because of coming from a Unix system like Berkeley or IRIX, in which case, I think Brian Kernighan said, "if you'll think of it as Unix, you'll often be frustrated because something doesn't exist or works differently." On the one hand the `cat -v` and some other concerns (like columnated ls(1) output) are valid, and very well understood. On the other -- lack of find(1), shell history, and vi are not. Well, to me at least. Both acme and sam seem to have found its fanbase. Note, when I'm saying failed I mean commercially. As a research operating system, or, dare I say, esoteric, because in some way it was and still is esoteric, it succeeded as none of the others, with its impact going through this day. -- caóc From imp at bsdimp.com Sat Sep 1 07:57:27 2018 From: imp at bsdimp.com (Warner Losh) Date: Fri, 31 Aug 2018 15:57:27 -0600 Subject: [TUHS] SunOS code? In-Reply-To: <20180831213451.r7LAj%ca6c@bitmessage.ch> References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu> <20180831213451.r7LAj%ca6c@bitmessage.ch> Message-ID: On Fri, Aug 31, 2018 at 3:36 PM Cág wrote: > Kevin Bowling wrote: > > > Sun releasing OpenSolaris when they finally did and under the CDDL was > > pretty tone deaf to what was going on in the market with Linux, but > > you have to admire the amount of contract review and legal work that > > must have taken. > > How is OpenSolaris different from SunOS (Sun/Oracle Solaris) anyway? > Isn't the relationship kinda RHEL-CentOS'ish? I.e. one is community- > -supported, and another is commercially. > No. Not even close. SunOS is BSD based (first 4.2 then 4.3 then with some small amount of System V code) with a written from scratch vm. Solaris is sun's do-over based on System V Release 4. It's great leap backwards. It was a huge slap in the face of the old SunOS crew by inept management. The final indignity was SunOS 4.1 being rebranded Solaris 1.0, which was pure marketing... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sat Sep 1 07:58:54 2018 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 31 Aug 2018 14:58:54 -0700 Subject: [TUHS] SunOS code? In-Reply-To: <20180831213451.r7LAj%ca6c@bitmessage.ch> References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu> <20180831213451.r7LAj%ca6c@bitmessage.ch> Message-ID: <20180831215854.GB28971@mcvoy.com> On Fri, Aug 31, 2018 at 04:34:51PM -0500, C??g wrote: > Kevin Bowling wrote: > > > Sun releasing OpenSolaris when they finally did and under the CDDL was > > pretty tone deaf to what was going on in the market with Linux, but > > you have to admire the amount of contract review and legal work that > > must have taken. > > How is OpenSolaris different from SunOS (Sun/Oracle Solaris) anyway? > Isn't the relationship kinda RHEL-CentOS'ish? I.e. one is community- > -supported, and another is commercially. SunOS was based on the BSD code, the entire system was frequently described as "a bug fixed BSD". It was, of course, a lot more than that, Sun dis shared libs, a new (much, much better) VM system, invented the vnode interface that virtualized file systems, BSD had none of that. Lots of Usenix papers describing that work here: SunOS felt very much like BSD, all the stuff you thought would work, usually did, the user space was very BSD like. http://mcvoy.com/lm/papers/ Solaris was Sys Vr4 (which, if I recall correctly, differed from r3 largely due to some stuff being ported over from SunOS). Both the kernel and user space went to a Sys V compat system, it no longer felt anything like BSD. So why would Sun take something that everyone loved and replace it with that steaming pile of Sys V garbage? Only the top execs actually knew the real reason, I'm 99% sure my boss, Ken Okin (VP of all server hardware), did not know the real reason. Which was, Sun was in some financial trouble, I don't know the details, but AT&T bought $200M of Sun stock at 35% over market to bail them out. In return, Sun had to drop SunOS and go with Sys V. AT&T was betting that Sun would make Sys V as popular as SunOS. Didn't happen. Not even close. A lot of people just bailed, trying to work with Sys V was miserable. It put us backwards at least 10 years and I'd argue more than that. The engineers loved SunOS and tons of work got done on the system that management never asked for, the engineers really drove the agenda. When all that work was yanked away, it took the heart out of engineering. A bunch of people stuck around and tried, they really did and I applaud them for it but the damage was done. I was gone by the time ZFS came out so I have no idea how that passed through the formal vetting process that Sun had in place. When I was there, if I had proposed a file system that wouldn't use the page cache, you'd have to copy from the buffer cache into the page cache to get mmap to work, I would have been kicked out of the room and probably kicked out of the kernel group. We had spent SO FRIGGING MUCH TIME getting rid of the buffer cache, precisely because trying to maintain coherency between the page cache (mmap) and the buffer cache (read/write), it was clear that you wanted a unified model. Yet the wise heads in charge approved ZFS. It boggles my mind. Yeah, I get it, it's got lots of nice features. But at the expense of breaking one of the cornerstones of the kernel design. The only thing I can think of is that the people who could see the whole kernel architecture had left, I can't imagine Kleiman, Gingell, Rosenthal, Powell, any of the old school distinguished engineers, tolerating that for 1 second. So my guess is they were gone and nobody in the vetting process saw the whole picture any more. If anyone is lurking on the list and was there for the ZFS work, I'd love to hear your take on it. I'm speculating. It just blows my mind that something that was one of the main design points for the previous 10-15 years, was ignored. We're not talking about some obscure device driver, we're talking about mmap(), which was one of the reasons Sun ran circles around the other guys, they all had crappy mmap() implementations that copied. ZFS went back to that. Weird. From imp at bsdimp.com Sat Sep 1 08:02:26 2018 From: imp at bsdimp.com (Warner Losh) Date: Fri, 31 Aug 2018 16:02:26 -0600 Subject: [TUHS] SunOS code? In-Reply-To: <20180831215854.GB28971@mcvoy.com> References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu> <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com> Message-ID: On Fri, Aug 31, 2018 at 3:59 PM Larry McVoy wrote: > A bunch of people stuck around and tried, they really did and I applaud > them for it but the damage was done. I was gone by the time ZFS came out > so I have no idea how that passed through the formal vetting process that > Sun had in place. When I was there, if I had proposed a file system that > wouldn't use the page cache, you'd have to copy from the buffer cache > into the page cache to get mmap to work, I would have been kicked out > of the room and probably kicked out of the kernel group. We had spent > SO FRIGGING MUCH TIME getting rid of the buffer cache, precisely because > trying to maintain coherency between the page cache (mmap) and the buffer > cache (read/write), it was clear that you wanted a unified model. > It's reason #1 why Netflix can't use ZFS: the double copy problem... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From ca6c at bitmessage.ch Sat Sep 1 08:19:27 2018 From: ca6c at bitmessage.ch (=?utf-8?B?Q8OhZw==?=) Date: Fri, 31 Aug 2018 17:19:27 -0500 Subject: [TUHS] SunOS code? In-Reply-To: <20180831215854.GB28971@mcvoy.com> References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu> <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com> Message-ID: <20180831221927.zeKvq%ca6c@bitmessage.ch> Larry McVoy wrote: > SunOS was based on the BSD code, the entire system was frequently > described as "a bug fixed BSD". > Solaris was Sys Vr4 [...]. Both the kernel and user space went to a > Sys V compat system, it no longer felt anything like BSD. I find it kinda weird, considering what Bill Joy did for BSD and, obviously, for Sun. I wonder what he himself thinks about it. Shout out to Bill if he reads the list. Also, I'm using the original vi (ex-vi that is from Heirloom), not nvi, as my development platform. Another weird thing: his original vi never made it to any BSD distribution. -- caóc From ca6c at bitmessage.ch Sat Sep 1 08:20:17 2018 From: ca6c at bitmessage.ch (=?utf-8?B?Q8OhZw==?=) Date: Fri, 31 Aug 2018 17:20:17 -0500 Subject: [TUHS] SunOS code? In-Reply-To: <20180831215854.GB28971@mcvoy.com> References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu> <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com> Message-ID: <20180831222017.KYQ86%ca6c@bitmessage.ch> Forgot to add: thanks for the good read, Larry! -- caóc From nobozo at gmail.com Sat Sep 1 08:23:22 2018 From: nobozo at gmail.com (Jon Forrest) Date: Fri, 31 Aug 2018 15:23:22 -0700 Subject: [TUHS] SunOS code? In-Reply-To: <20180831221927.zeKvq%ca6c@bitmessage.ch> References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu> <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com> <20180831221927.zeKvq%ca6c@bitmessage.ch> Message-ID: On 8/31/2018 3:19 PM, Cág wrote: > Also, I'm using the original vi (ex-vi that is from Heirloom), not nvi, > as my development platform. Another weird thing: his original vi never > made it to any BSD distribution. Are you quite sure? I remember using BSD on a VAX in about 1978 when vi just came out. I'm pretty sure Bill Joy wrote the man page and other documentation. Maybe it depends on what you mean by "his original vi". Jon From ca6c at bitmessage.ch Sat Sep 1 08:30:34 2018 From: ca6c at bitmessage.ch (=?utf-8?B?Q8OhZw==?=) Date: Fri, 31 Aug 2018 17:30:34 -0500 Subject: [TUHS] SunOS code? In-Reply-To: References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu> <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com> <20180831221927.zeKvq%ca6c@bitmessage.ch> Message-ID: <20180831223034.Um9p2%ca6c@bitmessage.ch> Jon Forrest wrote: > Are you quite sure? I remember using BSD on a VAX in about 1978 > when vi just came out. I'm pretty sure Bill Joy wrote the man > page and other documentation. *Open-source BSD distribution. I think it had some license restrictions when the Jolitzes made the 386 port, so they had to put an alternative. Then it was Elvis, nvi was written later on. -- caóc From nobozo at gmail.com Sat Sep 1 08:34:22 2018 From: nobozo at gmail.com (Jon Forrest) Date: Fri, 31 Aug 2018 15:34:22 -0700 Subject: [TUHS] SunOS code? In-Reply-To: <20180831223034.Um9p2%ca6c@bitmessage.ch> References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu> <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com> <20180831221927.zeKvq%ca6c@bitmessage.ch> <20180831223034.Um9p2%ca6c@bitmessage.ch> Message-ID: <83fec4da-b10e-8459-8e93-eebe196f98c4@gmail.com> On 8/31/2018 3:30 PM, Cág wrote: > Jon Forrest wrote: > >> Are you quite sure? I remember using BSD on a VAX in about 1978 >> when vi just came out. I'm pretty sure Bill Joy wrote the man >> page and other documentation. > > *Open-source BSD distribution. I think it had some license restrictions > when the Jolitzes made the 386 port, so they had to put an alternative. > Then it was Elvis, nvi was written later on. Those of us who used pre-open-source BSD probably have a different recollection of what BSD was like than those who came later. Jon From krewat at kilonet.net Sat Sep 1 09:02:36 2018 From: krewat at kilonet.net (Arthur Krewat) Date: Fri, 31 Aug 2018 19:02:36 -0400 Subject: [TUHS] SunOS code? In-Reply-To: <20180831215854.GB28971@mcvoy.com> References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu> <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com> Message-ID: <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net> On 8/31/2018 5:58 PM, Larry McVoy wrote: > > Solaris was Sys Vr4 (which, if I recall correctly, differed from r3 > largely due to some stuff being ported over from SunOS). Both the kernel > and user space went to a Sys V compat system, it no longer felt anything > like BSD. > I would be very interested in anyone's recollections of how Solaris eventually turned out performance-wise, say version 9+, compared to other operating systems. SunOS, Linux, AIX, etc. I find it's about equal, and even exceeds Linux in terms of it's NUMA support and multi-processor support. I need to move some systems away from Solaris and off to Linux, and I find it's NUMA support lacking in certain ways. ak From dave at horsfall.org Sat Sep 1 09:25:09 2018 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 1 Sep 2018 09:25:09 +1000 (EST) Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: <2e58402b-6366-4f74-757b-b7c8dd1b729c@texoma.net> References: <1F62F4D0-7AD1-43C2-A9B7-CF9DF239C3D9@berlan.de> <2e58402b-6366-4f74-757b-b7c8dd1b729c@texoma.net> Message-ID: On Thu, 30 Aug 2018, Cornelius Keck wrote: > Flat rate local toll and long distance is fairly prevalent in the US. > International long distance is a different story. How does that look > like elsewhere, who has a metered land-line? For any Aussie members, I get free local calls on my plan i.e. anywhere in the "02" call area. I even have a server with genuine serial ports, but the latter will change if/when I get a Raspberry Pi. No modem, though, and I need to see if I can get a second "line" on my NBN fibre (to the premises) connection to accept dial-in, and whether modems will actually work (it's implemented as VoIP in the router). (I have tried subscribing to the "retro" list, but nothing heard yet.) -- Dave From dave at horsfall.org Sat Sep 1 10:00:01 2018 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 1 Sep 2018 10:00:01 +1000 (EST) Subject: [TUHS] UNIX System names - since UNIX was a Trademark In-Reply-To: References: <20180829233605.GJ8423@mcvoy.com> <69AFD606-5E1D-4060-95A5-22F33B2322B2@ccc.com> Message-ID: On Fri, 31 Aug 2018, Clem Cole wrote: > Some of the more memorable ones from the UNIX world that I knew: AIX -> > "aches", CRDS -> "cruds", HP-UX -> HP "yucks" and "hockey pucks" and my > favorite: RHEL -> "our hell" Just be glad that Hewlett-Packard was not called Packard-Hewlett... -- Dave From jpl.jpl at gmail.com Sat Sep 1 10:10:59 2018 From: jpl.jpl at gmail.com (John P. Linderman) Date: Fri, 31 Aug 2018 20:10:59 -0400 Subject: [TUHS] UNIX System names - since UNIX was a Trademark In-Reply-To: <3b0a2895-4a6b-48c4-87da-cc1018d7b665.maildroid@localhost> References: <20180829233605.GJ8423@mcvoy.com> <69AFD606-5E1D-4060-95A5-22F33B2322B2@ccc.com> <3b0a2895-4a6b-48c4-87da-cc1018d7b665.maildroid@localhost> Message-ID: We always referred to HP-UX as "H-Pukes". On Fri, Aug 31, 2018 at 11:17 AM, William Pechter wrote: > UNIX is a trademark of AT&T > AT&T is a modem test command. > > -----Original Message----- > From: Clem Cole > To: Dave Horsfall > Cc: The Eunuchs Hysterical Society > Sent: Fri, 31 Aug 2018 10:42 > Subject: Re: [TUHS] UNIX System names - since UNIX was a Trademark > > Dave Horsfall's comment about AIX made me think. The joker in me has > always been impressed by how marketing people 'missed' the obvious > pronunciations that would lead to serious > > jokes. > Some of the more memorable ones from the UNIX world that I knew: AIX -> > "aches", CRDS -> "cruds", HP-UX -> HP "yucks" and "hockey pucks" and my > favorite: RHEL -> "our hell" > > I bet there are more and others I did know/consider ;-) > > That said, I did hear a pro-VMS person in ZKO (*i.e.* a DECie) once tried > refered to "DEC Ultrix" as Dirty Tricks, but I never heard that one take > off/be repeated outside of ZKO. > > For history we probably should try to collect them, although I fear the > context of the joke in the future may be lost. > > > Clem > ᐧ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Sat Sep 1 10:18:58 2018 From: ron at ronnatalie.com (ron at ronnatalie.com) Date: Fri, 31 Aug 2018 20:18:58 -0400 Subject: [TUHS] UNIX System names - since UNIX was a Trademark In-Reply-To: References: <20180829233605.GJ8423@mcvoy.com> <69AFD606-5E1D-4060-95A5-22F33B2322B2@ccc.com> <3b0a2895-4a6b-48c4-87da-cc1018d7b665.maildroid@localhost> Message-ID: <261201d44189$60c7aa50$2256fef0$@ronnatalie.com> Always H-PUCKS to us. Of course, the other HP operating system (MPE) we called Mighty Poor Excuse. From: TUHS On Behalf Of John P. Linderman Sent: Friday, August 31, 2018 8:11 PM To: William Pechter Cc: The Eunuchs Hysterical Society Subject: Re: [TUHS] UNIX System names - since UNIX was a Trademark We always referred to HP-UX as "H-Pukes". On Fri, Aug 31, 2018 at 11:17 AM, William Pechter > wrote: UNIX is a trademark of AT&T AT&T is a modem test command. -----Original Message----- From: Clem Cole > To: Dave Horsfall > Cc: The Eunuchs Hysterical Society > Sent: Fri, 31 Aug 2018 10:42 Subject: Re: [TUHS] UNIX System names - since UNIX was a Trademark Dave Horsfall's comment about AIX made me think. The joker in me has always been impressed by how marketing people 'missed' the obvious pronunciations that would lead to serious jokes. Some of the more memorable ones from the UNIX world that I knew: AIX -> "aches", CRDS -> "cruds", HP-UX -> HP "yucks" and "hockey pucks" and my favorite: RHEL -> "our hell" I bet there are more and others I did know/consider ;-) That said, I did hear a pro-VMS person in ZKO (*i.e.* a DECie) once tried refered to "DEC Ultrix" as Dirty Tricks, but I never heard that one take off/be repeated outside of ZKO. For history we probably should try to collect them, although I fear the context of the joke in the future may be lost. Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Sat Sep 1 10:40:40 2018 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 1 Sep 2018 10:40:40 +1000 (EST) Subject: [TUHS] =?utf-8?q?RetroNet=E2=80=A6_Virtual_is_cheap=2E?= In-Reply-To: <7b3d9f5f-af86-40ef-aafb-224f6162eb43.maildroid@localhost> References: <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com> <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net> <1d8c0539-8b43-9954-d8a7-db4dcc22b27d@texoma.net> <7b3d9f5f-af86-40ef-aafb-224f6162eb43.maildroid@localhost> Message-ID: On Fri, 31 Aug 2018, William Pechter wrote: > One thought about Digital Ocean is they even have a web browser based > graphic console so you get to fix things @ single user yourself as well > as run X remotely if needed... I have a Digital Ocean host myself, so that I can probe my firewall from the outside (and there is a metric shitload of tools that I can use to attack it; after all, everybody else is); another reason was that I could smart-host via it, so that I don't have to use the division of Sirius Cybernetics known as Telstra. -- Dave From cym224 at gmail.com Sat Sep 1 10:55:04 2018 From: cym224 at gmail.com (Nemo) Date: Fri, 31 Aug 2018 20:55:04 -0400 Subject: [TUHS] UNIX System names - since UNIX was a Trademark In-Reply-To: <261201d44189$60c7aa50$2256fef0$@ronnatalie.com> References: <20180829233605.GJ8423@mcvoy.com> <69AFD606-5E1D-4060-95A5-22F33B2322B2@ccc.com> <3b0a2895-4a6b-48c4-87da-cc1018d7b665.maildroid@localhost> <261201d44189$60c7aa50$2256fef0$@ronnatalie.com> Message-ID: On 31/08/2018, ron at ronnatalie.com wrote: > Always H-PUCKS to us. Of course, the other HP operating system (MPE) we > called Mighty Poor Excuse. H-Pox in my neck of the woods. (I think everyone said Slowlaris. Even the guys from Sun who first demo'd dtrace and how it was used to speed up their system calls.) N. From lm at mcvoy.com Sat Sep 1 11:57:41 2018 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 31 Aug 2018 18:57:41 -0700 Subject: [TUHS] SunOS code? In-Reply-To: <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net> References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu> <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com> <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net> Message-ID: <20180901015741.GN28971@mcvoy.com> On Fri, Aug 31, 2018 at 07:02:36PM -0400, Arthur Krewat wrote: > On 8/31/2018 5:58 PM, Larry McVoy wrote: > > > >Solaris was Sys Vr4 (which, if I recall correctly, differed from r3 > >largely due to some stuff being ported over from SunOS). Both the kernel > >and user space went to a Sys V compat system, it no longer felt anything > >like BSD. > > > > I would be very interested in anyone's recollections of how Solaris > eventually turned out performance-wise, say version 9+, compared to other > operating systems. SunOS, Linux, AIX, etc. I did some updating of lmbench [*] when I was dancing with Netflix. I need to check that in and publish that because the bits have rotted since 1995. I have no idea if that will measure what you want, it's a bunch of microbenchmarks that measure bandwidth and latency of everything I could think of: network, disks, file systems, caches, memory, etc. It's interesting but might not be so to you. If you want to know if Solaris is at the same place as Linux, I can pretty much promise it is not in the "getting out of the way of the application". Solaris was known as Slowaris for a reason. Yeah, I know it sucked harder in the beginning, but those were order of magnitude suckages. Linus always cared about performance, he had a big hand in lmbench, we both cared. Linus was about performance like I am about code size. I ran the BitKeeper dev team for almost 20 years. I loved a changeset that removed more lines than it added. We got up to about 120K lines of code in the core and then we stayed there for the next decade, added so much more stuff but always found a way to delete stuff so we didn't get bloated. But all that said, you need to be specific about what perf you care about. These days the kernel is far more complicated, NUMA etc, and you might care about parallel make (I doubt it) or you might care about Oracle or something like that. --lm [*] http://mcvoy.com/lm/papers/lmbench-usenix.pdf From andreww591 at gmail.com Sat Sep 1 13:37:38 2018 From: andreww591 at gmail.com (Andrew Warkentin) Date: Fri, 31 Aug 2018 21:37:38 -0600 Subject: [TUHS] cat -v and other complaints In-Reply-To: <20180831215636.-eCEx%ca6c@bitmessage.ch> References: <20180831215636.-eCEx%ca6c@bitmessage.ch> Message-ID: On 8/31/18, Cág wrote: > Not completely on-topic, in my opinion one of the reasons Plan9 failed > was the fact that it presented itself overly idealistic, occasionally > sacrificing usability -- maybe it's because of coming from a Unix system > like Berkeley or IRIX, in which case, I think Brian Kernighan said, "if > you'll think of it as Unix, you'll often be frustrated because something > doesn't exist or works differently." I'd definitely agree with the lack of usability-oriented features being a part of why Plan 9 hasn't been commercially successful. In general, it seems like Plan 9 focuses on being minimal above everything else, whereas I'd say an ideal OS should focus on being sufficiently general and extensible in addition to being minimal (in other words, do things in the most minimal way that is sufficiently general and extensible). > On the one hand the `cat -v` and > some other concerns (like columnated ls(1) output) are valid, and very > well understood. On the other -- lack of find(1), shell history, and > vi are not. Well, to me at least. Both acme and sam seem to have found > its fanbase. > I'd say features like history, completion, and line editing really don't belong in a shell. They should be handled by a separate listener process with a simple API that shells and other client processes can use for controlling them. That's one good example of Plan 9 prioritizing minimalism above everything else. From tytso at mit.edu Sat Sep 1 13:23:18 2018 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Fri, 31 Aug 2018 23:23:18 -0400 Subject: [TUHS] SunOS code? In-Reply-To: <20180901015741.GN28971@mcvoy.com> References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu> <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com> <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net> <20180901015741.GN28971@mcvoy.com> Message-ID: <20180901032318.GD27277@thunk.org> On Fri, Aug 31, 2018 at 06:57:41PM -0700, Larry McVoy wrote: > > But all that said, you need to be specific about what perf you care > about. These days the kernel is far more complicated, NUMA etc, > and you might care about parallel make (I doubt it) or you might care > about Oracle or something like that. It wouldn't surprise me if Solaris was more scalable for gazillion dollar SMP machines with a huge number of cores. That was one of the reason as I recall why Solaris had a reputation of being slow; being scalable to big (and much more profitable) servers was considered more important than the smaller systems that were probably more numerous (but not nearly as profitable). - Ted From dave at horsfall.org Sat Sep 1 16:52:07 2018 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 1 Sep 2018 16:52:07 +1000 (EST) Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: References: <1F62F4D0-7AD1-43C2-A9B7-CF9DF239C3D9@berlan.de> <2e58402b-6366-4f74-757b-b7c8dd1b729c@texoma.net> Message-ID: On Sat, 1 Sep 2018, Dave Horsfall wrote: > (I have tried subscribing to the "retro" list, but nothing heard yet.) Hmmm... Looking at my reject log, I see this: Date: Aug 31 17:09:49 (w7V79WBG017201) from= relay=[208.45.186.204] reject=550 5.7.1 ... Fix reverse DNS for 208.45.186.204 Would that be it? I have some vicious spam defences here, and requiring rDNS (anything will do) is one of them; I could always whitelist the IP if it won't change, or perhaps chivanet.org if that will be the origin. -- Dave From dave at horsfall.org Sat Sep 1 17:37:46 2018 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 1 Sep 2018 17:37:46 +1000 (EST) Subject: [TUHS] UNIX System names - since UNIX was a Trademark In-Reply-To: References: <20180829233605.GJ8423@mcvoy.com> <69AFD606-5E1D-4060-95A5-22F33B2322B2@ccc.com> <3b0a2895-4a6b-48c4-87da-cc1018d7b665.maildroid@localhost> <261201d44189$60c7aa50$2256fef0$@ronnatalie.com> Message-ID: On Fri, 31 Aug 2018, Nemo wrote: > (I think everyone said Slowlaris. Even the guys from Sun who first > demo'd dtrace and how it was used to speed up their system calls.) I've always called it Slowaris, mostly because my stutter stops me from pronouncing words starting with "r" or "l" (it comes out as "w"). And yes, I've seen "Life of Brian", and I can relate to it :-) "Welease Woger" etc... Oddly enough, I can pronounce "r" and "l" if preceded by a hard consonant, so I dunno... For the morbidly curious, I was born left-handed, and, err, "encouraged" to use my right hand back in kindergarten, which apparently completely fscked up my neural connections. As a result, I write right-handed, bat/bowl/throw left-handed, and am pretty much ambidextrous otherwise. Oh, and I also trained myself to use a mouse in my left hand (in right-hand mode, and in my SunOS days too!) which is apparently quite common amongst the righties; after all, why waste a perfectly good hand? It's hilarious watching someone letting go of the mouse to write something down, then back to the mouse again... -- Dave From mutiny.mutiny at india.com Sat Sep 1 20:46:31 2018 From: mutiny.mutiny at india.com (Donald ODona) Date: Sat, 1 Sep 2018 10:46:31 +0000 (UTC) Subject: [TUHS] SunOS code? In-Reply-To: <20180831223034.Um9p2%ca6c@bitmessage.ch> References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu> <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com> <20180831221927.zeKvq%ca6c@bitmessage.ch> , <20180831223034.Um9p2%ca6c@bitmessage.ch> Message-ID: <1029648209.250928.1535798791745.JavaMail.tomcat@india-live-be04> At 31 Aug 2018 22:32:06 +0000 (+00:00) from "Cág" : > Then it was Elvis, nvi was written later on. "It was originally derived from the first incarnation of elvis, written by Steve Kirkendall, as noted in the README file included in nvi's sources. " https://en.wikipedia.org/wiki/Nvi#Credits_and_distribution From steve.mynott at gmail.com Sat Sep 1 21:43:52 2018 From: steve.mynott at gmail.com (Steve Mynott) Date: Sat, 1 Sep 2018 12:43:52 +0100 Subject: [TUHS] SunOS code? In-Reply-To: <20180829145300.GP317@mcvoy.com> References: <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829004627.GG317@mcvoy.com> <201808290529.w7T5TFKa006049@freefriends.org> <20180829145300.GP317@mcvoy.com> Message-ID: On Wed, 29 Aug 2018 at 15:53, Larry McVoy wrote: The BSDs have a less than optimal VM system. Having SunOS opened up > would at least let people see what they are missing. Maybe I have > rose colored glasses on but it was the only kernel that came into > focus for me and you could see the architecture from the code. > Everything else seems like a mess to me. > That may have been true in the late 80s and even early 90s but I'd have thought FreeBSD, NetBSD and OpenBSD would have useable VMs by now. I've vague recollections that these all originally used the VM from Mach which did have problems at first. I recall a more knowledgeable friend complaining about FreeBSD VM in 1994 or so. I think the latter two use UVM and FreeBSD improved their Mach one (which has a SunOS kvmish API anyway). I've not seen complaints about modern BSD. S -- Steve Mynott cv25519/ECF8B611205B447E091246AF959E3D6197190DD5 -------------- next part -------------- An HTML attachment was scrubbed... URL: From akosela at andykosela.com Sat Sep 1 23:50:05 2018 From: akosela at andykosela.com (Andy Kosela) Date: Sat, 1 Sep 2018 15:50:05 +0200 Subject: [TUHS] SunOS code? In-Reply-To: References: <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829004627.GG317@mcvoy.com> <201808290529.w7T5TFKa006049@freefriends.org> <20180829145300.GP317@mcvoy.com> Message-ID: On Saturday, September 1, 2018, Steve Mynott wrote: > > > On Wed, 29 Aug 2018 at 15:53, Larry McVoy wrote: > > The BSDs have a less than optimal VM system. Having SunOS opened up >> would at least let people see what they are missing. Maybe I have >> rose colored glasses on but it was the only kernel that came into >> focus for me and you could see the architecture from the code. >> Everything else seems like a mess to me. >> > > That may have been true in the late 80s and even early 90s but I'd have > thought FreeBSD, NetBSD and OpenBSD would have useable VMs by now. > > I've vague recollections that these all originally used the VM from Mach > which did have problems at first. > > I recall a more knowledgeable friend complaining about FreeBSD VM in 1994 > or so. > > I think the latter two use UVM and FreeBSD improved their Mach one (which > has a SunOS kvmish API anyway). I've not seen complaints about modern BSD. > > Wasn't the whole FreeBSD VM rewritten by John Dyson and David Greenman in the mid-late 90's? And then further improved by Matthew Dillon. Unfortunately they are not affiliated with the project anymore. All three had exceptional coding skills. --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From cym224 at gmail.com Sat Sep 1 23:54:30 2018 From: cym224 at gmail.com (Nemo) Date: Sat, 1 Sep 2018 09:54:30 -0400 Subject: [TUHS] UNIX System names - since UNIX was a Trademark In-Reply-To: References: <20180829233605.GJ8423@mcvoy.com> <69AFD606-5E1D-4060-95A5-22F33B2322B2@ccc.com> <3b0a2895-4a6b-48c4-87da-cc1018d7b665.maildroid@localhost> <261201d44189$60c7aa50$2256fef0$@ronnatalie.com> Message-ID: On 01/09/2018, Dave Horsfall wrote (in part): > Oh, and I also trained myself to use a mouse in my left hand (in > right-hand mode, and in my SunOS days too!) which is apparently quite > common amongst the righties; As did I -- I am right-handed -- but mainly because reaching over the keypad was such a bother. N. > It's hilarious watching someone letting go of the mouse to write something > down, then back to the mouse again... > > -- Dave > From imp at bsdimp.com Sun Sep 2 00:32:23 2018 From: imp at bsdimp.com (Warner Losh) Date: Sat, 1 Sep 2018 08:32:23 -0600 Subject: [TUHS] SunOS code? In-Reply-To: References: <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829004627.GG317@mcvoy.com> <201808290529.w7T5TFKa006049@freefriends.org> <20180829145300.GP317@mcvoy.com> Message-ID: On Sat, Sep 1, 2018 at 7:50 AM Andy Kosela wrote: > > > On Saturday, September 1, 2018, Steve Mynott > wrote: > >> >> >> On Wed, 29 Aug 2018 at 15:53, Larry McVoy wrote: >> >> The BSDs have a less than optimal VM system. Having SunOS opened up >>> would at least let people see what they are missing. Maybe I have >>> rose colored glasses on but it was the only kernel that came into >>> focus for me and you could see the architecture from the code. >>> Everything else seems like a mess to me. >>> >> >> That may have been true in the late 80s and even early 90s but I'd have >> thought FreeBSD, NetBSD and OpenBSD would have useable VMs by now. >> >> I've vague recollections that these all originally used the VM from Mach >> which did have problems at first. >> > Yes. CSRG used Mach VM because it was available, not because it was awesome. The folks at CSRG approached Sun to have them donate their VM to BSD, and there were serious talks about doing this until the lawyers got involved and explained that would require a serious write down on their quarterly report so that nixed the whole thing. > I recall a more knowledgeable friend complaining about FreeBSD VM in 1994 >> or so. >> > It used to be downright aweful. > I think the latter two use UVM and FreeBSD improved their Mach one (which >> has a SunOS kvmish API anyway). I've not seen complaints about modern BSD. >> > OpenBSD and NetBSD both moved to uvm. > Wasn't the whole FreeBSD VM rewritten by John Dyson and David Greenman in > the mid-late 90's? And then further improved by Matthew Dillon. > > Unfortunately they are not affiliated with the project anymore. All three > had exceptional coding skills. > With the exception of David, it's not unfortunate at all. Although they were good for the project's code, they weren't good for the project. They didn't work well with others and caused much more grief than the code they contributed. There comes a time when there's just too much drama and the rest of the code gets much much better when you aren't always fighting drama :(. It was a tough decision to make when I was on the core team to show Dillon the door. One not made lightly, nor without a lot of effort to work through the issues. In the end, though, we had to part ways. Dillon has done well with DragonFly, however. In the last 10 years or so there's been a number of people that have stepped up and replaced them, most notably Allan Cox and Mark Johnston who have mad coding skills and can play well with others. Though I'm sure I'm slighting several people by not mentioning them. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sun Sep 2 01:01:09 2018 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 1 Sep 2018 08:01:09 -0700 Subject: [TUHS] SunOS code? In-Reply-To: References: <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829004627.GG317@mcvoy.com> <201808290529.w7T5TFKa006049@freefriends.org> <20180829145300.GP317@mcvoy.com> Message-ID: <20180901150109.GT28971@mcvoy.com> On Sat, Sep 01, 2018 at 12:43:52PM +0100, Steve Mynott wrote: > On Wed, 29 Aug 2018 at 15:53, Larry McVoy wrote: > The BSDs have a less than optimal VM system. Having SunOS opened up > > would at least let people see what they are missing. Maybe I have > > rose colored glasses on but it was the only kernel that came into > > focus for me and you could see the architecture from the code. > > Everything else seems like a mess to me. > > > > That may have been true in the late 80s and even early 90s but I'd have > thought FreeBSD, NetBSD and OpenBSD would have useable VMs by now. I wandered through the FreeBSD VM recently. Perhaps I'm just old and tired but it looked pretty messy to me. Still Mach based and the Mach VM system, which came about at about the same time as the SunOS VM system, doesn't remotely compare. Sun had some exceptional talent at the time, there was a reason I fought hard to join that group, I wanted to work with people who were better than me. From imp at bsdimp.com Sun Sep 2 01:20:49 2018 From: imp at bsdimp.com (Warner Losh) Date: Sat, 1 Sep 2018 09:20:49 -0600 Subject: [TUHS] SunOS code? In-Reply-To: <20180901150109.GT28971@mcvoy.com> References: <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829004627.GG317@mcvoy.com> <201808290529.w7T5TFKa006049@freefriends.org> <20180829145300.GP317@mcvoy.com> <20180901150109.GT28971@mcvoy.com> Message-ID: On Sat, Sep 1, 2018 at 9:01 AM Larry McVoy wrote: > On Sat, Sep 01, 2018 at 12:43:52PM +0100, Steve Mynott wrote: > > On Wed, 29 Aug 2018 at 15:53, Larry McVoy wrote: > > The BSDs have a less than optimal VM system. Having SunOS opened up > > > would at least let people see what they are missing. Maybe I have > > > rose colored glasses on but it was the only kernel that came into > > > focus for me and you could see the architecture from the code. > > > Everything else seems like a mess to me. > > > > > > > That may have been true in the late 80s and even early 90s but I'd have > > thought FreeBSD, NetBSD and OpenBSD would have useable VMs by now. > > I wandered through the FreeBSD VM recently. Perhaps I'm just old and > tired but it looked pretty messy to me. Still Mach based and the > Mach VM system, which came about at about the same time as the SunOS > VM system, doesn't remotely compare. Sun had some exceptional > talent at the time, there was a reason I fought hard to join that > group, I wanted to work with people who were better than me. > It is still technically mach based, but it's fixed most of the scalability issues Mach had (and that MacOS still has). There's much clutter in the VM, and there's areas that could stand to be rewritten, or to get at least a good cleaning. The SunOS vm was far superior in its day, and likely is still cleaner than what's in FreeBSD. But it can't scale like FreeBSD's vm (or NetBSD's or even MacOS's) because it hasn't had the same care and feeding for the last 25 years. It's still single threaded and hasn't had the care and feeding to make it perform well in MP situations. Solbourne spent years hacking it to make it scale better, but even with 16 processors that was the high end for them, and they were barely 10x faster than a uniprocessor for many work loads due, in part, to vm contention limiting scalability. We had 2 8 CPU machines that could build our software ~20% faster (with netmake) than the 1 16 CPU machine the OS group had, for example... I recall many discussions with Dave Barak who did the fine-grained work on the 4.0 SunOS kernel complaining about how many of the clever tricks in different subsystems that worked great on UP were terrible for MP... I don't doubt we'd be in an even better place today if we'd started with the SunOS vm system in 4.4BSD rather than mach. Don't get me wrong. And I'll not be the first in line to defend its elegance or clarity of design (in fact, it has many design issues that took a decade to recode to properly scale, and we're still not done). And lord knows even though I'm not close to the foremost expert in the vm, I could easily put together an hour or two talk on how all the areas of the VM that are holding us back. Yet even with all that, I think that the ugly, warty, co-evolved code we have in FreeBSD performs better than the SunOS vm code on any objective benchmark you could have. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Sun Sep 2 02:16:01 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Sat, 1 Sep 2018 10:16:01 -0600 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: References: <1F62F4D0-7AD1-43C2-A9B7-CF9DF239C3D9@berlan.de> <2e58402b-6366-4f74-757b-b7c8dd1b729c@texoma.net> Message-ID: On 09/01/2018 12:52 AM, Dave Horsfall wrote: > Hmmm...  Looking at my reject log, I see this: > >     Date: Aug 31 17:09:49 (w7V79WBG017201) >     from= >     relay=[208.45.186.204] >     reject=550 5.7.1 ... Fix reverse DNS for > 208.45.186.204 > > Would that be it? Yep, that's it. > I have some vicious spam defences here, and requiring rDNS (anything will > do) is one of them; I could always whitelist the IP if it won't change, > or perhaps chivanet.org if that will be the origin. I think that JPW was going to email you directly (reply to the message I sent you). TL;DR: His T1 upstream won't play ball. I added an entry to my hosts file and things have been fine for me. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From kevin.bowling at kev009.com Sun Sep 2 02:27:46 2018 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Sat, 1 Sep 2018 09:27:46 -0700 Subject: [TUHS] SunOS code? In-Reply-To: <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net> References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu> <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com> <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net> Message-ID: On Fri, Aug 31, 2018 at 4:02 PM, Arthur Krewat wrote: > On 8/31/2018 5:58 PM, Larry McVoy wrote: >> >> >> Solaris was Sys Vr4 (which, if I recall correctly, differed from r3 >> largely due to some stuff being ported over from SunOS). Both the kernel >> and user space went to a Sys V compat system, it no longer felt anything >> like BSD. >> > > I would be very interested in anyone's recollections of how Solaris > eventually turned out performance-wise, say version 9+, compared to other > operating systems. SunOS, Linux, AIX, etc. Linux started pulling away fast even on high end systems by the early 2000s. IBM and SGI dumped a ton of money, knowledge, and talent into this. By Linux kernel 2.6 the race was entirely won. After this HP-UX, AIX, and Solaris persist mainly in mainframe-like vertical stacks used mainly to host mission critical applications that are sold in bundles or "solutions" > I find it's about equal, and even exceeds Linux in terms of it's NUMA > support and multi-processor support. I need to move some systems away from > Solaris and off to Linux, and I find it's NUMA support lacking in certain > ways. This is pure fantasy. To understand Linux performance on high core count and multi-socket machines is to have at least passing knowledge of Paul McKenney's genius work on RCU [1] and NUMA [2] at Sequent [3] and on Linux. IBM bought Sequent, made a favorable patent grant of RCU for Linux, and the rest history. There is a single feature I have seen in Solaris NUMA that should be implemented elsewhere. It does a micro-benchmark on boot to figure out the inter-core latency map. On stupid technology like Intel's ACPI and Xeon Cluster-on-Die and Sub-NUMA-Clustering, you get bogus data back in the SRAT table describing where the cores are on the on chip network it just chops things in half and doesn't reflect where the cores actually were fused off for yield or binning reasons which is statistically almost always asymmetric. On better engineered technology like IBM's POWER8/9 and OPAL firmware, you get the real locality information of where cores and cache groups actually are. Solaris' neat little micro-benchmark would work optimally even on the brain damaged data from Intel. [1] http://www2.rdrop.com/~paulmck/RCU/ [2] http://www2.rdrop.com/~paulmck/scalability/ [3] http://www2.rdrop.com/~paulmck/techreports/stingcacm3.1999.08.04a.pdf Regards, Kevin From kevin.bowling at kev009.com Sun Sep 2 02:29:31 2018 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Sat, 1 Sep 2018 09:29:31 -0700 Subject: [TUHS] SunOS code? In-Reply-To: <20180901032318.GD27277@thunk.org> References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu> <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com> <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net> <20180901015741.GN28971@mcvoy.com> <20180901032318.GD27277@thunk.org> Message-ID: I am surprised how good Sun's technical marketing was for you to think this. Linux has scaled better since the early 2000s. The Solaris x86-64 port has some real gaffes in it to this day at least as visible in the OpenSolaris derivative codebases, serialization in the locking primitives kind of things. On Fri, Aug 31, 2018 at 8:23 PM, Theodore Y. Ts'o wrote: > On Fri, Aug 31, 2018 at 06:57:41PM -0700, Larry McVoy wrote: >> >> But all that said, you need to be specific about what perf you care >> about. These days the kernel is far more complicated, NUMA etc, >> and you might care about parallel make (I doubt it) or you might care >> about Oracle or something like that. > > It wouldn't surprise me if Solaris was more scalable for gazillion > dollar SMP machines with a huge number of cores. That was one of the > reason as I recall why Solaris had a reputation of being slow; being > scalable to big (and much more profitable) servers was considered more > important than the smaller systems that were probably more numerous > (but not nearly as profitable). > > - Ted From lm at mcvoy.com Sun Sep 2 02:35:24 2018 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 1 Sep 2018 09:35:24 -0700 Subject: [TUHS] SunOS code? In-Reply-To: References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu> <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com> <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net> <20180901015741.GN28971@mcvoy.com> <20180901032318.GD27277@thunk.org> Message-ID: <20180901163524.GX28971@mcvoy.com> On Sat, Sep 01, 2018 at 09:29:31AM -0700, Kevin Bowling wrote: > I am surprised how good Sun's technical marketing was for you to think > this. Linux has scaled better since the early 2000s. The Solaris > x86-64 port has some real gaffes in it to this day at least as visible > in the OpenSolaris derivative codebases, serialization in the locking > primitives kind of things. I think the SPARC bias was very apparent. Sun loved their own chips, to their detriment IMO. I have no personal knowledge of the x86_64 efforts, but I do know about the Sun i386 efforts. That was very looked down upon by the powers that were, the main kernel group, etc. Those poor guys had an uphill battle to get anything integrated, nobody wanted it. So it would not surprise me in the slightest if the x86_64 was a half assed effort without a lot of attention to stuff like performance. I don't think they wanted Solaris/x86 to be a success, they wanted SPARC to be a success. It was that kind of attitude that has pissed me off at every company I have ever worked for. I'm fine with marketing to customers but I hate it when people believe their own marketing. Internally, I think you should be very skeptical, judgemental, critical, whatever you want to call it, if your code sucks or your hardware sucks, don't pretend it doesn't, own it and fix it. That's how you win. > On Fri, Aug 31, 2018 at 8:23 PM, Theodore Y. Ts'o wrote: > > On Fri, Aug 31, 2018 at 06:57:41PM -0700, Larry McVoy wrote: > >> > >> But all that said, you need to be specific about what perf you care > >> about. These days the kernel is far more complicated, NUMA etc, > >> and you might care about parallel make (I doubt it) or you might care > >> about Oracle or something like that. > > > > It wouldn't surprise me if Solaris was more scalable for gazillion > > dollar SMP machines with a huge number of cores. That was one of the > > reason as I recall why Solaris had a reputation of being slow; being > > scalable to big (and much more profitable) servers was considered more > > important than the smaller systems that were probably more numerous > > (but not nearly as profitable). > > > > - Ted -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From paul.winalski at gmail.com Sun Sep 2 03:03:16 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Sat, 1 Sep 2018 13:03:16 -0400 Subject: [TUHS] UNIX System names - since UNIX was a Trademark In-Reply-To: References: <20180829233605.GJ8423@mcvoy.com> <69AFD606-5E1D-4060-95A5-22F33B2322B2@ccc.com> <3b0a2895-4a6b-48c4-87da-cc1018d7b665.maildroid@localhost> <261201d44189$60c7aa50$2256fef0$@ronnatalie.com> Message-ID: On 9/1/18, Dave Horsfall wrote: > > Oh, and I also trained myself to use a mouse in my left hand (in > right-hand mode, and in my SunOS days too!) which is apparently quite > common amongst the righties; after all, why waste a perfectly good hand? > It's hilarious watching someone letting go of the mouse to write something > down, then back to the mouse again... I'm left-handed but I trained myself to use a mouse in my right hand, for the reason you point out--I still have my dominant hand free to write things down. It also means that when I'm using someone else's machine, most of the time their mouse is configured the way I'm used to. -Paul W. From krewat at kilonet.net Sun Sep 2 03:17:59 2018 From: krewat at kilonet.net (Arthur Krewat) Date: Sat, 1 Sep 2018 13:17:59 -0400 Subject: [TUHS] SunOS code? In-Reply-To: References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu> <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com> <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net> Message-ID: On 9/1/2018 12:27 PM, Kevin Bowling wrote: >> I find it's about equal, and even exceeds Linux in terms of it's NUMA >> support and multi-processor support. I need to move some systems away from >> Solaris and off to Linux, and I find it's NUMA support lacking in certain >> ways. > This is pure fantasy. To understand Linux performance on high core > count and multi-socket machines is to have at least passing knowledge > of Paul McKenney's genius work on RCU [1] and NUMA [2] at Sequent [3] > and on Linux. IBM bought Sequent, made a favorable patent grant of > RCU for Linux, and the rest history. Thanks :) - I'm basing this on Oracle database performance, for the most part, and it's weird way of supporting NUMA on Linux in a bass-ackwards sort of way. Nothing I see in the latest RedHat/CentOS tells me it even cares about NUMA, but maybe that's more of their "we know better than you" mentality and it's all hidden under the covers somewhere. ak -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve.mynott at gmail.com Sun Sep 2 04:24:43 2018 From: steve.mynott at gmail.com (Steve Mynott) Date: Sat, 1 Sep 2018 19:24:43 +0100 Subject: [TUHS] SunOS code? In-Reply-To: References: <201808280601.w7S61oLM030628@freefriends.org> <20180829004627.GG317@mcvoy.com> <201808290529.w7T5TFKa006049@freefriends.org> <20180829145300.GP317@mcvoy.com> <20180901150109.GT28971@mcvoy.com> Message-ID: <20180901182442.GA29206@sunny.my.domain> There is a paper on the SunOS 4 VM available at (for some reason I always forget the ghostview binary is actually called gv the rare time I use it!) Some basic grepping suggests at least some of the tags in the paper were still in use in Open Solaris at: There is a paper on UVM as well. This says the original 4.4BSD Mach VM suffered from "swap memory leak deadlock" and claims of its sibling (at least in 1999) that although the FreeBSD VM is improved that "it still suffers from the object chaining model it inherited". The FreeBSD VM was documented before 2013 in "Much of the apparent complexity of the FreeBSD design, especially in the VM/Swap subsystem, is a direct result of having to solve serious performance issues that occur under various conditions." -- Steve Mynott cv25519/ECF8B611205B447E091246AF959E3D6197190DD5 From lm at mcvoy.com Sun Sep 2 04:38:48 2018 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 1 Sep 2018 11:38:48 -0700 Subject: [TUHS] SunOS code? In-Reply-To: <20180901182442.GA29206@sunny.my.domain> References: <20180829004627.GG317@mcvoy.com> <201808290529.w7T5TFKa006049@freefriends.org> <20180829145300.GP317@mcvoy.com> <20180901150109.GT28971@mcvoy.com> <20180901182442.GA29206@sunny.my.domain> Message-ID: <20180901183848.GD28971@mcvoy.com> All of those papers are here: http://mcvoy.com/lm/papers/ SunOS.nvram.pdf SunOS.shlib.pdf SunOS.smoosh.pdf SunOS.tfs.pdf SunOS.ufs_clustering.pdf SunOS.vfs_arch.pdf SunOS.vm_arch.pdf SunOS.vm_impl.pdf If you have pointers to a paper that is Sun related that I don't have I'd like to see that. > > > There is a paper on UVM as well. > > That's interesting, reading. From lm at mcvoy.com Sun Sep 2 04:50:53 2018 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 1 Sep 2018 11:50:53 -0700 Subject: [TUHS] UVM VM system Message-ID: <20180901185053.GA20993@mcvoy.com> So I just read this https://www.usenix.org/legacy/event/usenix99/full_papers/cranor/cranor.pdf and it looks encouraging. Apparently NetBSD is using it. Does anyone know if they are happy with it? Has FreeBSD considered this? Has anyone benchmarked FreeBSD against NetBSD to see which is faster for VM stuff? From imp at bsdimp.com Sun Sep 2 05:07:45 2018 From: imp at bsdimp.com (Warner Losh) Date: Sat, 1 Sep 2018 13:07:45 -0600 Subject: [TUHS] UVM VM system In-Reply-To: <20180901185053.GA20993@mcvoy.com> References: <20180901185053.GA20993@mcvoy.com> Message-ID: On Sat, Sep 1, 2018 at 12:51 PM Larry McVoy wrote: > So I just read this > > https://www.usenix.org/legacy/event/usenix99/full_papers/cranor/cranor.pdf > > and it looks encouraging. Apparently NetBSD is using it. Does anyone > know if they are happy with it? > They are relatively happy with it... > Has FreeBSD considered this? > Yes, but it would be a huge porting effort. > Has anyone benchmarked FreeBSD against NetBSD to see which is faster > for VM stuff? > Generally, the benchmarks favor FreeBSD. Again, it's a cleaner design, but the time spent optimizing FreeBSD's and eliminating the bottle necks has paid off... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sun Sep 2 05:16:42 2018 From: clemc at ccc.com (Clem Cole) Date: Sat, 1 Sep 2018 15:16:42 -0400 Subject: [TUHS] UVM VM system In-Reply-To: <20180901185053.GA20993@mcvoy.com> References: <20180901185053.GA20993@mcvoy.com> Message-ID: On Sat, Sep 1, 2018 at 2:51 PM Larry McVoy wrote: > So I just read this > > https://www.usenix.org/legacy/event/usenix99/full_papers/cranor/cranor.pdf I remember that presentsation, it was exciting and very cool ;-) > > > and it looks encouraging. Apparently NetBSD is using it. Hmm - integrated/used it at one time ... but ... I'm not sure of that is still true of it it even really made it out. That was all happening when I was still hacking on Alphas (which was a long time ago). We'd need the active NetBSD folks to chime in on curent state. > Does anyone > > know if they are happy with it? > At the time (and I'm doing this by memory) the buffer cache stuff needed a rewrite which I thought FreeBSD did/was doing at the time. In those days, FreeBSD was within epislon on of Tru64 on Alpha performance and NetBSD had a ways to go. At the time, I gave a couple of Alphas to somebody in the UK (I've forgotten whom); who was going to redo it. > > Has FreeBSD considered this? > Last I knew, no. I was under the impression, the work FreeBSD did rewriting the Mach stuff paid off for them at the time. I have FreeBSD, OpenBSD and Linux (and Mac OSx) all running on my systems here. But the problem is that the HW is all over the map in termns of release date, so I'm not sure which is faster at this point. The *BSD systems are the easiest to admin and clean/simplest (which is why they only systems I have exposed is an OpenBSD box). But they have uses ;-) > > Has anyone benchmarked FreeBSD against NetBSD to see which is faster > for VM stuff? > My data was from those days, and FreeBSD was winning, but thats a >>long<< time ago. Lots of bits have been types into to the kernel of both systems, so you tell me, Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sun Sep 2 05:32:18 2018 From: clemc at ccc.com (Clem Cole) Date: Sat, 1 Sep 2018 15:32:18 -0400 Subject: [TUHS] SunOS code? In-Reply-To: <20180901163524.GX28971@mcvoy.com> References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu> <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com> <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net> <20180901015741.GN28971@mcvoy.com> <20180901032318.GD27277@thunk.org> <20180901163524.GX28971@mcvoy.com> Message-ID: below... On Sat, Sep 1, 2018 at 12:35 PM Larry McVoy wrote: > > It was that kind of attitude that has pissed me off at every company > I have ever worked for. I'm fine with marketing to customers but I > hate it when people believe their own marketing. Internally, I think > you should be very skeptical, judgemental, critical, whatever you want > to call it, if your code sucks or your hardware sucks, don't pretend > it doesn't, own it and fix it. That's how you win. > Amen.... ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Sun Sep 2 05:41:54 2018 From: rminnich at gmail.com (ron minnich) Date: Sat, 1 Sep 2018 12:41:54 -0700 Subject: [TUHS] UVM VM system In-Reply-To: References: <20180901185053.GA20993@mcvoy.com> Message-ID: I was his advisor on that thesis so I got to watch it roll out as it happened. uvm replaced the machvm in netbsd. For a time, Chuck set it up to run in parallel with the existing VM. You could start a process and pick which vm it used. For a while, it defaulted to the existing one. Then, at some point, it defaulted to uvm. Then, at some point, the old one was removed. more here: http://www.netbsd.org/docs/kernel/uvm.html via search terms uvm replaces machvm netbsd chuck was a long time contributor to netbsd IIRC, but last time we talked, he was using Linux. ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Sun Sep 2 05:45:28 2018 From: rminnich at gmail.com (ron minnich) Date: Sat, 1 Sep 2018 12:45:28 -0700 Subject: [TUHS] UVM VM system In-Reply-To: References: <20180901185053.GA20993@mcvoy.com> Message-ID: I said that wrong, I was not his advisor, Guru was;I was the external committee member or external advisor or some such thing. Chuck and I talked an awful lot because I was doing a lot in the sunos and AIX VMs at the time, and Chuck and I had known each other from udel days. On Sat, Sep 1, 2018 at 12:41 PM ron minnich wrote: > I was his advisor on that thesis so I got to watch it roll out as it > happened. > > uvm replaced the machvm in netbsd. > > For a time, Chuck set it up to run in parallel with the existing VM. You > could start a process and pick which vm it used. For a while, it defaulted > to the existing one. Then, at some point, it defaulted to uvm. Then, at > some point, the old one was removed. > > more here: > > http://www.netbsd.org/docs/kernel/uvm.html > > via search terms > uvm replaces machvm netbsd > > chuck was a long time contributor to netbsd IIRC, but last time we talked, > he was using Linux. > > ron > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad at anduin.eldar.org Sun Sep 2 05:53:25 2018 From: brad at anduin.eldar.org (Brad Spencer) Date: Sat, 01 Sep 2018 15:53:25 -0400 Subject: [TUHS] UVM VM system In-Reply-To: (message from Clem Cole on Sat, 1 Sep 2018 15:16:42 -0400) Message-ID: Clem Cole writes: [snip] >> and it looks encouraging. Apparently NetBSD is using it. > > Hmm - integrated/used it at one time ... but ... I'm not sure of that is > still true of it it even really made it out. That was all happening when I > was still hacking on Alphas (which was a long time ago). We'd need the > active NetBSD folks to chime in on curent state. > [snip] Yes, UVM has been used with NetBSD for a very long time. The browseable CVS repo at www.netbsd.org suggests that work started in 1997 - 1998 or so. Looks like in 1999 the Mach VM was completely removed from NetBSD except for some include files, but clean up appears to have continued into 2000. -- Brad Spencer - brad at anduin.eldar.org - KC8VKS - http://anduin.eldar.org From imp at bsdimp.com Sun Sep 2 06:25:55 2018 From: imp at bsdimp.com (Warner Losh) Date: Sat, 1 Sep 2018 14:25:55 -0600 Subject: [TUHS] UVM VM system In-Reply-To: References: <20180901185053.GA20993@mcvoy.com> Message-ID: On Sat, Sep 1, 2018, 1:42 PM ron minnich wrote: > I was his advisor on that thesis so I got to watch it roll out as it > happened. > > uvm replaced the machvm in netbsd. > > For a time, Chuck set it up to run in parallel with the existing VM. You > could start a process and pick which vm it used. For a while, it defaulted > to the existing one. Then, at some point, it defaulted to uvm. Then, at > some point, the old one was removed. > > more here: > > http://www.netbsd.org/docs/kernel/uvm.html > > via search terms > uvm replaces machvm netbsd > > chuck was a long time contributor to netbsd IIRC, but last time we talked, > he was using Linux. > These days I know he's hacking on FreeBSD's storage stack with me at work :). I think he's still a netbsd contributor. I see his name in the commit log often.. Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Sun Sep 2 06:31:21 2018 From: will.senn at gmail.com (Will Senn) Date: Sat, 1 Sep 2018 15:31:21 -0500 Subject: [TUHS] Public access multics Message-ID: <899D86D7-1601-4FDA-869A-10EC46500D0D@gmail.com> So, it looks like someone has gone and started running a multics instance: http://lists.nycbug.org/pipermail/semibug/2018-August/000288.html That’s interesting, and y’all may even have been aware of it. But, I was thinking that Multics was a failed predecessor of unix and it’s craziness an inspiration for how unix isn’t multics... straighten me out :) Will Sent from my iPhone -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sun Sep 2 06:50:40 2018 From: clemc at ccc.com (Clem Cole) Date: Sat, 1 Sep 2018 16:50:40 -0400 Subject: [TUHS] Fwd: Public access multics In-Reply-To: References: <899D86D7-1601-4FDA-869A-10EC46500D0D@gmail.com> Message-ID: below... On Sat, Sep 1, 2018 at 4:37 PM Will Senn wrote: > So, it looks like someone has gone and started running a multics instance: > > http://lists.nycbug.org/pipermail/semibug/2018-August/000288.html > > That’s interesting, and y’all may even have been aware of it. But, I was > thinking that Multics was a failed predecessor of unix and it’s craziness > an inspiration for how unix isn’t multics... straighten me out :) > > https://www.quora.com/Why-did-Unix-succeed-and-not-Multics/answer/Clem-Cole ᐧ ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Sun Sep 2 07:15:58 2018 From: rminnich at gmail.com (ron minnich) Date: Sat, 1 Sep 2018 14:15:58 -0700 Subject: [TUHS] UVM VM system In-Reply-To: References: <20180901185053.GA20993@mcvoy.com> Message-ID: good to know! On Sat, Sep 1, 2018 at 1:26 PM Warner Losh wrote: > > > On Sat, Sep 1, 2018, 1:42 PM ron minnich wrote: > >> I was his advisor on that thesis so I got to watch it roll out as it >> happened. >> >> uvm replaced the machvm in netbsd. >> >> For a time, Chuck set it up to run in parallel with the existing VM. You >> could start a process and pick which vm it used. For a while, it defaulted >> to the existing one. Then, at some point, it defaulted to uvm. Then, at >> some point, the old one was removed. >> >> more here: >> >> http://www.netbsd.org/docs/kernel/uvm.html >> >> via search terms >> uvm replaces machvm netbsd >> >> chuck was a long time contributor to netbsd IIRC, but last time we >> talked, he was using Linux. >> > > These days I know he's hacking on FreeBSD's storage stack with me at work > :). I think he's still a netbsd contributor. I see his name in the commit > log often.. > > Warner > >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From don at DonHopkins.com Sun Sep 2 07:21:49 2018 From: don at DonHopkins.com (Don Hopkins) Date: Sat, 1 Sep 2018 23:21:49 +0200 Subject: [TUHS] TUHS Digest, Vol 34, Issue 4 In-Reply-To: References: Message-ID: <586F623A-C819-4E77-9986-88C322E36AFD@gmail.com> > On 1 Sep 2018, at 19:18,Warner Losh > wrote: > > I recall a more knowledgeable friend complaining about FreeBSD VM in 1994 or so. > > It used to be downright aweful. > That sounds like a GOOD thing: full of awe! At least it wasn’t offal: decomposing animal flesh. -Don -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at irreal.org Sun Sep 2 07:27:19 2018 From: lists at irreal.org (jcs) Date: Sat, 01 Sep 2018 17:27:19 -0400 Subject: [TUHS] Public access multics In-Reply-To: <899D86D7-1601-4FDA-869A-10EC46500D0D@gmail.com> References: <899D86D7-1601-4FDA-869A-10EC46500D0D@gmail.com> Message-ID: Will Senn writes: > So, it looks like someone has gone and started running a multics > instance: > > http://lists.nycbug.org/pipermail/semibug/2018-August/000288.html > > That’s interesting, and y’all may even have been aware of it. > But, I was thinking that Multics was a failed predecessor of > unix and it’s craziness an inspiration for how unix isn’t > multics... straighten me out :) Failed only in the sense that the Labs withdrew from the project. Honeywell, which bought out GE's computer division, sold Multics systems, although I don't remember them being very successful. The real mystery is what it's running on. Multics originally ran on the GE/H 600(0) systems. I doubt any are still around. It's probably a simulator but I've never heard of one for the H6000. From tytso at mit.edu Sun Sep 2 08:19:33 2018 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Sat, 1 Sep 2018 18:19:33 -0400 Subject: [TUHS] SunOS code? In-Reply-To: References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu> <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com> <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net> Message-ID: <20180901221933.GA2214@thunk.org> On Sat, Sep 01, 2018 at 01:17:59PM -0400, Arthur Krewat wrote: > On 9/1/2018 12:27 PM, Kevin Bowling wrote: > > > I find it's about equal, and even exceeds Linux in terms of it's NUMA > > > support and multi-processor support. I need to move some systems away from > > > Solaris and off to Linux, and I find it's NUMA support lacking in certain > > > ways. > > This is pure fantasy. To understand Linux performance on high core > > count and multi-socket machines is to have at least passing knowledge > > of Paul McKenney's genius work on RCU [1] and NUMA [2] at Sequent [3] > > and on Linux. IBM bought Sequent, made a favorable patent grant of > > RCU for Linux, and the rest history. > > Thanks :) - I'm basing this on Oracle database performance, for the most > part, and it's weird way of supporting NUMA on Linux in a bass-ackwards sort > of way. Nothing I see in the latest RedHat/CentOS tells me it even cares > about NUMA, but maybe that's more of their "we know better than you" > mentality and it's all hidden under the covers somewhere. It wouldn't surprise me if Linux's NUMA performance is pretty weak compared to Solaris. There was an attempt to try to make NUMA work well on Linux, with a lot of the effort coming from IBM and SGI, but that effort was overtaken by events. Back in Sequent's day, the remote to local memory latency was ten to one, so making the system NUMA aware was critical. But by early 2000's, the remote to local ratio was under 3:1 (or 2:1) for 4 socket systems, and with AMD's "Sufficiently Uniform Memory Organization" (SUMO), the ratio was under 1.5:1 or less. The main reason for this was that Windows was (and as far as I know, still is) NUMA oblivious. So x86 chip and motherboard designers solved the problem, by brute foruce, in hardware. So by 2003 or 2004, the Linux Scalability Effort had more or less petered out. (You can see the leftover remnants at http://lse.sourceforge.net) Fundamentally, the economics of 4 socket and higher machines was such that for many workloads, scale out was much cheaper than scale up. So why buy super-expensive IBM X440, x450, and x460 servers, which were huge cabinets connected by one or more "scalability cables" (sometimes referred to as the "scalability bottleneck"), when most of the time, you could just buy a rack of 2U x86 servers which would be much, much cheaper? There were certainly workloads this wasn't applicable, of course. But when Sun was selling Sun 10k's to web startups during the dot com boom, and they were using it to serve web traffic, they probably had too much VC money to burn, because that was *not* the most cost effective way to do things. Don't get me wrong; the Read Copy Update (RCU) technique was certainly very important, and is responsible for much of Linux's SMP scalability today. But these days, when you can get up to 28 cores (56 threads) on a single socket, the need for more than 2 socket systems is already somewhat niche, and by the time you get to more than 4 sockets, it's positively microscopic. As a result, NUMA support on Linux is certainly not as strong as it could be, and it wouldn't surprise me that Solaris has developed much better ways of handling the behemoths such as Sun Enterprise 10k. - Ted P.S. IBM made the RCU patent available for any GPL code, well before Sun decided on the CDDL for Solaris. So if Sun management had chosen GPL, they could have used RCU.... From jpl.jpl at gmail.com Sun Sep 2 09:24:56 2018 From: jpl.jpl at gmail.com (John P. Linderman) Date: Sat, 1 Sep 2018 19:24:56 -0400 Subject: [TUHS] Public access multics In-Reply-To: References: <899D86D7-1601-4FDA-869A-10EC46500D0D@gmail.com> Message-ID: I was at MIT in the late 60's, using Multics when Bell Labs decided to pull out. A problem, in retrospect, was the use of PL/I as the primary language. PL/I was a language designed by a committee, and it showed. It would never have made a plausible systems programming language. But Multics was a lot more fun to use than CTSS, which it replaced. On Sat, Sep 1, 2018 at 5:27 PM, jcs wrote: > > Will Senn writes: > > So, it looks like someone has gone and started running a multics instance: >> >> http://lists.nycbug.org/pipermail/semibug/2018-August/000288.html >> >> That’s interesting, and y’all may even have been aware of it. But, I was >> thinking that Multics was a failed predecessor of unix and it’s craziness >> an inspiration for how unix isn’t multics... straighten me out :) >> > > Failed only in the sense that the Labs withdrew from the project. > Honeywell, which bought out GE's computer division, sold Multics systems, > although I don't remember them being very successful. > > The real mystery is what it's running on. Multics originally ran on the > GE/H 600(0) systems. I doubt any are still around. It's probably a > simulator but I've never heard of one for the H6000. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Sun Sep 2 09:25:37 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 1 Sep 2018 19:25:37 -0400 (EDT) Subject: [TUHS] Fwd: Public access multics Message-ID: <20180901232537.615A418C09E@mercury.lcs.mit.edu> > From: Will Senn > I was thinking that Multics was a failed predecessor of unix > ... straighten me out :) I'd start with: https://multicians.org/myths.html > From: Clem Cole > https://www.quora.com/Why-did-Unix-succeed-and-not-Multics/answer/Clem-Cole Clem, I think that's too limited in scope. Like a lot of 'big' 'failures' (defined in Multics' case as 'failure to grow to significant market share, and continue in the long term'), I don't think Multics 'failed' for a single reason. In general, in large failures, there are a number of causes, all doing their bit. Now, if there are M causes, ranked in priority, maybe the first N1 are _each_ big enough that _any one_ of them could have led to that outcome. Or maybe not; maybe it needed the first N2, all acting in concert. My crystal ball isn't that accurate. But here's my take on _some_ of Multics' main issues. - Management: if you look at: https://multicians.org/hill-mgt.html it's clear that Honeywell top management didn't understand Multics, and didn't understand that it had a long-term potential. They terminated investment in new hardware, and that was what finally killed Multics. - Non-portability: the system was too tied to a specific platform; it couldn't really be moved elsewhere. (E.g. the code is riddled with 'fixed bin 18'; yes, that could be changed with a program to edit the source, but there are lots of dependencies on the specifics of the machine's architecture.) It would be possible to re-write it to run on, say, a 386, but you'd pretty much have to start from scratch. - Built for the wrong future: a key assumption was that people would continue to get their computes from large centralized machines. Clearly, that was wrong (and it played into the issues with Honeywell management)>. Multics _could_ have made the transition to today's 'small' (physically) machines, in which case it would have been really good to have - e.g. if we could run browsers in AIM boxes a lot of malware simply would not be an issue. But the point above prevented that. Those are some of the big ones; I may come up with more. I've CC'd a couple of Multicians - perhaps they can add additional insight. Noel From jnc at mercury.lcs.mit.edu Sun Sep 2 09:33:41 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 1 Sep 2018 19:33:41 -0400 (EDT) Subject: [TUHS] Public access multics Message-ID: <20180901233341.0CAB118C09E@mercury.lcs.mit.edu> > From: jcs > The real mystery is what it's running on. ... It's=20 probably a > simulator but I've never heard of one for the H6000. Per: https://multicians.org/multics.htmlhttps://multicians.org/multics.html "Harry Reed and Charles Anthony reached a major milestone on the Multics simulator on Saturday 08 November, 2014. Their SIMH-based simulator booted Multics MR 12.5, came to operator command level, entered admin mode, created a small PL/I program, compiled and executed it, and shut down. Release 1.0 of the simulator is now available." Noel From lists at irreal.org Sun Sep 2 09:44:12 2018 From: lists at irreal.org (jcs) Date: Sat, 01 Sep 2018 19:44:12 -0400 Subject: [TUHS] Public access multics In-Reply-To: <20180901233341.0CAB118C09E@mercury.lcs.mit.edu> References: <20180901233341.0CAB118C09E@mercury.lcs.mit.edu> Message-ID: Noel Chiappa writes: > Per: > > https://multicians.org/multics.htmlhttps://multicians.org/multics.html > > "Harry Reed and Charles Anthony reached a major milestone on the > Multics > simulator on Saturday 08 November, 2014. Their SIMH-based > simulator booted > Multics MR 12.5, came to operator command level, entered admin > mode, created a > small PL/I program, compiled and executed it, and shut down. > Release 1.0 of > the simulator is now available." Hmmm. That's interesting. Back in the 70's I earned my living working on H6000s (although not on Multics). I'm pretty sure that no one would have bothered with a simulator if not for Multics so that's another reason not to dismiss Multics as a failure: someone, today, still cares enough to write a simulator just to run it. From crossd at gmail.com Sun Sep 2 10:57:17 2018 From: crossd at gmail.com (Dan Cross) Date: Sat, 1 Sep 2018 20:57:17 -0400 Subject: [TUHS] Public access multics In-Reply-To: References: <899D86D7-1601-4FDA-869A-10EC46500D0D@gmail.com> Message-ID: On Sat, Sep 1, 2018 at 6:15 PM jcs wrote: > Will Senn writes: > > So, it looks like someone has gone and started running a multics > > instance: > > > > http://lists.nycbug.org/pipermail/semibug/2018-August/000288.html > > > > That’s interesting, and y’all may even have been aware of it. > Yup. A few Multics sites are publicly accessible; the one at the Living Computer Museum has a guest account, a few others one can get an account if one asks the site administrator nicely. Some amount of Multics maintenance has been restarted. > But, I was thinking that Multics was a failed predecessor of > > unix and it’s craziness an inspiration for how unix isn’t > > multics... straighten me out :) > Multics was the immediate predecessor of Unix, and one can certainly see some of the influence, though of course many of the details are different. Failed only in the sense that the Labs withdrew from the project. > Honeywell, which bought out GE's computer division, sold Multics > systems, although I don't remember them being very successful. > The multicians.org site has a lot of good information on Multics and what ultimately become of it. (jcs probably knows this already; I'm writing this more for general information of those who may not have been following these developments.) The TL;DR was that a smallish number of sites eventually installed Multics and it was a moderate success for Honeywell, but for the reasons that have been mentioned (failure to market, lack of management understanding, tied to a decomposing architecture well past its prime) it never carved out more than a niche. The real mystery is what it's running on. Multics originally ran > on the GE/H 600(0) systems. I doubt any are still around. It's > probably a simulator but I've never heard of one for the H6000. > The last working hardware installation was shut down in, I think, 2000. An DPS8/M emulator has been built on top of the SIMH framework, and is what folks are running Multics on. Some more details are here: https://multicians.org/simulator.html. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Sun Sep 2 12:06:10 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Sat, 1 Sep 2018 20:06:10 -0600 Subject: [TUHS] Public access multics In-Reply-To: References: <899D86D7-1601-4FDA-869A-10EC46500D0D@gmail.com> Message-ID: <268aed6e-0398-d368-5325-8ca536d310dc@spamtrap.tnetconsulting.net> On 09/01/2018 06:57 PM, Dan Cross wrote: > Yup. A few Multics sites are publicly accessible; the one at the Living > Computer Museum has a guest account, a few others one can get an account > if one asks the site administrator nicely. Some amount of Multics > maintenance has been restarted. I was chatting with modern day Multicians within the last week. They were actively working on getting a 3270 interface working for Multics running in an emulator. They are hanging out in the #multics channel on freenode. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From charles.unix.pro at gmail.com Sun Sep 2 12:32:53 2018 From: charles.unix.pro at gmail.com (Charles Anthony) Date: Sat, 1 Sep 2018 19:32:53 -0700 Subject: [TUHS] Public access multics In-Reply-To: References: <899D86D7-1601-4FDA-869A-10EC46500D0D@gmail.com> Message-ID: > > > > The real mystery is what it's running on. Multics originally ran > on the GE/H 600(0) systems. I doubt any are still around. It's > probably a simulator but I've never heard of one for the H6000. > A simulator. Originally running Multics release 12.5, but a dedicated team of new and original Multicians have completed the Y2K transition, fixed some bugs and added some features, so now running release 12.6f. All of the original systems are believed to be destroyed with the exception of DOCKMASTER (an NSA machine), now in possession of the National Cryptographic Museum, but warehoused. A video of the Living Computer Museum's Multics emulator (with maintenance panel) booting: https://www.youtube.com/watch?v=jni7wk7bjxA At least one of the new Multicians (me) is subscribed to TUHS. -- Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sun Sep 2 12:52:23 2018 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 1 Sep 2018 19:52:23 -0700 Subject: [TUHS] Public access multics In-Reply-To: References: <899D86D7-1601-4FDA-869A-10EC46500D0D@gmail.com> Message-ID: <20180902025223.GQ28971@mcvoy.com> On Sat, Sep 01, 2018 at 07:32:53PM -0700, Charles Anthony wrote: > At least one of the new Multicians (me) is subscribed to TUHS. Welcome. You'll find this list to be pleasant, it's mostly Unix but we've got Ted from Linux (which is a big deal, he has a lot of history in his head and is a good guy), Ken is on here though he rarely posts (and we all try and be nice to keep him around), Doug is here, Steve is here, and all of us wannabes are here. I love being on this list, as a young dude I was pretty unhappy that I was born at the wrong time, I really really wanted be part of Bell Labs. But I got to be part of Sun, which I think was the Bell Labs of their time. And then there is this list which has some of the Bell Labs folks. It reminds me of the Band, there is a video and Neil Young says "it's one of the pleasures of my life to be on stage with these people". Yeah, it's one of the great pleasures of my life to be able to talk the Bell Labs people on this list. And other fans of the Unix history, love this list. https://www.youtube.com/watch?v=J2z7LXpAX3Q From trnsz at pobox.com Sun Sep 2 13:17:02 2018 From: trnsz at pobox.com (Jeffrey H. Johnson) Date: Sat, 1 Sep 2018 23:17:02 -0400 Subject: [TUHS] Public access multics References: <5B48F6A3-374A-4579-AE8F-35BD328D07F9@reagan.com> Message-ID: Greetings, Multics, while not a 'massive' sales success in retrospect, was certainly not the failure commonly believed and wasn't treated as one in the press of the time - at least not until after the decision was made by Honeywell-Bull to phase out the the Multics (and CP-6) products to focus on GCOS - GCOS7/GCOS8 is still a major player today. "Honeywell is having considerable — and surprising — success with the ultra-secure Multics operating system … Besides 3-5 systems within Honeywell, Multics has been installed or committed within Nippon Electric, Rome Air Development Center, USAF Data Services Center, and Ford." from mid-1970's industry press. See also https://multicians.org/myths.html We have about 120 members on BAN - including many original and new Multicians who make the project possible. We're always working on new things and projects - see "pmotd -a" when logged in for some of the most recent activity. I'd be happy to answer any questions on BAN.AI if anyone has particular questions - or just ssh to dps8 at m.trnsz.com - feel free to use the guest account. I don't want to take the list too off-topic. We have many exclusive features that I hope makes BAN.AI a 'special' (and loved) system, a lot more coming. -- https://ban.ai/multics -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Sun Sep 2 14:05:39 2018 From: will.senn at gmail.com (Will Senn) Date: Sat, 1 Sep 2018 23:05:39 -0500 Subject: [TUHS] Fwd: Public access multics In-Reply-To: <20180901232537.615A418C09E@mercury.lcs.mit.edu> References: <20180901232537.615A418C09E@mercury.lcs.mit.edu> Message-ID: <10B61FE8-1418-4201-A782-76E07BD2D34A@gmail.com> On Sep 1, 2018, at 6:25 PM, Noel Chiappa wrote: >> From: Will Senn > >> I was thinking that Multics was a failed predecessor of unix >> ... straighten me out :) > > I'd start with: > > https://multicians.org/myths.html >> Noel, Fascinating read. I must’ve read at least a good handful of the references leading to the myths described in the writeup. As usual, I can trust the folks who lived history to remember it more clearly than many revisionists writing about it later. Thanks for sharing. Now, I’m wondering what awesome features Multics had that we’re still lacking in modern *nices... anything as amazing as say, my favorite filesystem, ZFS? Will From trnsz at pobox.com Sun Sep 2 14:25:44 2018 From: trnsz at pobox.com (Jeffrey H. Johnson) Date: Sun, 2 Sep 2018 00:25:44 -0400 Subject: [TUHS] Public access multics In-Reply-To: <10B61FE8-1418-4201-A782-76E07BD2D34A@gmail.com> References: <20180901232537.615A418C09E@mercury.lcs.mit.edu> <10B61FE8-1418-4201-A782-76E07BD2D34A@gmail.com> Message-ID: <0D39179A-9133-4388-ABEC-DCD769E9CD24@pobox.com> While the best loved feature is probably the pervasive dynamic linking, which is still unrivaled, and the security features (ring brackets, AIM (multilevel labeling), and ACLs) which are the most famous, a feature that isn't built in to Unix and is constantly being reinvented that was available in Multics is the ability to easily set aside a CPU and some memory and disk, while leaving the system in operation, and start another separate instance to do development work, and then when the work is done, be reconfigured to merge the system back into one instance, without disrupting production work. That dynamic reconfiguration was one original design specifications of the system, as opposed to being added later. Much of what makes Multics wonderful to me is just how amazingly sturdily it's engineered and how complete the implementations of these ideas are. Another thing to comes to mind immediately is how hierarchical the system is. For example, users are registered on to projects, and a project administrator can be delegated the task of registering and deregistering user accounts and managing the system resources such as disk quota and access to printers and other physical resources for their project. The system administrator can manage the resources assigned to projects, and the project administration handles how that's further carved up amongst the users. You can have similar granularity in assigning the distribution of resources such as CPU and memory use, by using the workload management features to ensure that high priority tasks/users/projects will always have needed resources available, preempting lower priority tasks if necessary. The I/O system, (while not exceedingly elegant - see iox_), far exceeds what is available in Unix today, but by design. The reputation of Multics as a 'complex' system is, in my experience, well deserved, but that complexity does not mean it's a terrible system to use or administer. I find it quite refreshing and it almost never feels dated. -- Jeff https://ban.ai/multics > On Sep 2, 2018, at 12:05 AM, Will Senn wrote: > > On Sep 1, 2018, at 6:25 PM, Noel Chiappa wrote: > >>> From: Will Senn >> >>> I was thinking that Multics was a failed predecessor of unix >>> ... straighten me out :) >> >> I'd start with: >> >> https://multicians.org/myths.html > > Noel, Fascinating read. I must’ve read at least a good handful of the references leading to the myths described in the writeup. As usual, I can trust the folks who lived history to remember it more clearly than many revisionists writing about it later. > > Thanks for sharing. > > Now, I’m wondering what awesome features Multics had that we’re still lacking in modern *nices... anything as amazing as say, my favorite filesystem, ZFS? > > Will From kevin.bowling at kev009.com Sun Sep 2 15:05:06 2018 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Sat, 1 Sep 2018 22:05:06 -0700 Subject: [TUHS] SunOS code? In-Reply-To: <20180901221933.GA2214@thunk.org> References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu> <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com> <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net> <20180901221933.GA2214@thunk.org> Message-ID: On Sat, Sep 1, 2018 at 3:19 PM, Theodore Y. Ts'o wrote: > On Sat, Sep 01, 2018 at 01:17:59PM -0400, Arthur Krewat wrote: >> On 9/1/2018 12:27 PM, Kevin Bowling wrote: >> > > I find it's about equal, and even exceeds Linux in terms of it's NUMA >> > > support and multi-processor support. I need to move some systems away from >> > > Solaris and off to Linux, and I find it's NUMA support lacking in certain >> > > ways. >> > This is pure fantasy. To understand Linux performance on high core >> > count and multi-socket machines is to have at least passing knowledge >> > of Paul McKenney's genius work on RCU [1] and NUMA [2] at Sequent [3] >> > and on Linux. IBM bought Sequent, made a favorable patent grant of >> > RCU for Linux, and the rest history. >> >> Thanks :) - I'm basing this on Oracle database performance, for the most >> part, and it's weird way of supporting NUMA on Linux in a bass-ackwards sort >> of way. Nothing I see in the latest RedHat/CentOS tells me it even cares >> about NUMA, but maybe that's more of their "we know better than you" >> mentality and it's all hidden under the covers somewhere. > > It wouldn't surprise me if Linux's NUMA performance is pretty weak > compared to Solaris. There was an attempt to try to make NUMA work > well on Linux, with a lot of the effort coming from IBM and SGI, but > that effort was overtaken by events. Back in Sequent's day, the > remote to local memory latency was ten to one, so making the system > NUMA aware was critical. But by early 2000's, the remote to local > ratio was under 3:1 (or 2:1) for 4 socket systems, and with AMD's > "Sufficiently Uniform Memory Organization" (SUMO), the ratio was under > 1.5:1 or less. Sorry this is just bogus about being weak compared to Solaris. Are you looking back with rosy glasses or have you scanned the code in the past couple years? I have and there is nothing particularly special about Solaris internals here or elsewhere. In fact, there are a lot of pessimization all over the place. As Larry said, a lot of folks in the Linux community clearly cared about performance. Although the Solaris code is fairly clean It's not clear Sun valued performance at all. A stroll through arch/*/include/asm/ was enough to convince me of Larry's claims. I'm not a Linux fanboy but credit goes where it's due. Solaris has lgroups, which are a clean design but that is the extent of its NUMA support, one shot at placement and scheduling. Linux has a NUMA allocator, aware scheduler, NUMA-optimized spinlocks and mutexes, various subsystems correctly use the primitives, and can use cgroups to contain or gang things. There is a userland policy tool called numad that tries to add some additional runtime affinity and movement policy decisions. I agree that architecturally Linux NUMA is nowhere near where Sequent and especially SGI was. And the reasons you cite are valid, Linux implementation is good for maybe 8-16 sockets of modern core count with a much tighter off chip network than the big dogs were building. Keep in mind IBM wants to sell RockHoppers and E980s (4 drawers, 16 sockets, 768 threads) for dedicated Linux use which have similar north/south and east/west off chip networks. They have a lot of very talented people on the firmware, kernel, compilers to make these things work fast, including Paul. > The main reason for this was that Windows was (and as far as I know, > still is) NUMA oblivious. So x86 chip and motherboard designers > solved the problem, by brute foruce, in hardware. So by 2003 or 2004, > the Linux Scalability Effort had more or less petered out. (You can > see the leftover remnants at http://lse.sourceforge.net) Windows' NUMA support is on par with Solaris insofar as there is domain aware memory allocator and scheduler hierarchy that takes the domain (and SMT etc) into account. What Windows lacks is the finely tuned concurrency primitives and everything else Linux has done.. which Solaris lacks as well. I'm not even talking about RCU (or epoch based reclamation or proxy collection or hazard pointers, at least one of which is not patent encumbered), I'm just talking about the quality of primitives like spinlocks and mutex and rwlock. There are big tradeoffs to the implementations of these in terms of fairness, progress guarantees, and thread scalability. Linux leads the pack by a long shot in this department. Where you start going beyond Linux-like NUMA IMO is when you get Irix-like features of page copying, migration, and multiple advanced placement policies. > Fundamentally, the economics of 4 socket and higher machines was such > that for many workloads, scale out was much cheaper than scale up. So > why buy super-expensive IBM X440, x450, and x460 servers, which were > huge cabinets connected by one or more "scalability cables" (sometimes > referred to as the "scalability bottleneck"), when most of the time, > you could just buy a rack of 2U x86 servers which would be much, much > cheaper? Agreed, this is why x86 has dominated the server market for a long time. > There were certainly workloads this wasn't applicable, of course. But > when Sun was selling Sun 10k's to web startups during the dot com > boom, and they were using it to serve web traffic, they probably had > too much VC money to burn, because that was *not* the most cost > effective way to do things. Agreed. Those big margins must have caused them to take their eye off what mattered right at the time Linux was getting some momentum from the big HW vendors. > Don't get me wrong; the Read Copy Update (RCU) technique was certainly > very important, and is responsible for much of Linux's SMP scalability > today. But these days, when you can get up to 28 cores (56 threads) > on a single socket, the need for more than 2 socket systems is already > somewhat niche, and by the time you get to more than 4 sockets, it's > positively microscopic. As a result, NUMA support on Linux is > certainly not as strong as it could be, and it wouldn't surprise me > that Solaris has developed much better ways of handling the behemoths > such as Sun Enterprise 10k. The E10k was only a 64-core machine on a tight backplane compared to other large systems. It didn't have any of the pressing needs that Sequent and SGI did with multi-drawer interconnects to drive excellence in NUMA. These are strange times. Intel's been putting out some real doozy chips. The mesh in Skylake is a partial improvement over the dual rings of Haswell (though they did some goofy things to increase latency in undesirable ways), and they aren't going to continue to brute force it like IBM did with their 17 metal layer process node.. many SKUs in Cascade Lake will be a dual die design and cost a hilarious amount of money. AMD's EPYC is really bad in this department too, one EPYC behaves identically to a 4 socket system with extremely poor inter-die latency [1]. I think POWER9 is universally better and the high bin chips (22 core, 88 thread, mega cache) are only around $2500 compared to Skylake's absurd $12,000. POWER9 is a single on chip NUMA domain for 24 cores. Google publicly stated they are using it for GPU servers, and that all their monorepo is built for multiple ISAs. Through the grapevine I've heard gmail is running on POWER9 as well now. That is pretty competent, the reason Intel is sucking so bad is because people allowed themselves such lock in. A hyperscaler should be able to change between a couple ISAs as needed between purchasing cycles. > - Ted > > P.S. IBM made the RCU patent available for any GPL code, well before > Sun decided on the CDDL for Solaris. So if Sun management had chosen > GPL, they could have used RCU... True. There is also at least one unencumbered strategy such as epoch based reclamation which was known about around that time [2] [1] https://www.servethehome.com/amd-epyc-infinity-fabric-latency-ddr4-2400-v-2666-a-snapshot/ [2] https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-579.pdf Regards, Kevin From kevin.bowling at kev009.com Sun Sep 2 15:19:41 2018 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Sat, 1 Sep 2018 22:19:41 -0700 Subject: [TUHS] UVM VM system In-Reply-To: References: <20180901185053.GA20993@mcvoy.com> Message-ID: Seems like Chuck Cranor is at CMU http://chuck.cranor.org/. Chuck Silvers is with you? On Sat, Sep 1, 2018 at 1:25 PM, Warner Losh wrote: > > > On Sat, Sep 1, 2018, 1:42 PM ron minnich wrote: >> >> I was his advisor on that thesis so I got to watch it roll out as it >> happened. >> >> uvm replaced the machvm in netbsd. >> >> For a time, Chuck set it up to run in parallel with the existing VM. You >> could start a process and pick which vm it used. For a while, it defaulted >> to the existing one. Then, at some point, it defaulted to uvm. Then, at some >> point, the old one was removed. >> >> more here: >> >> http://www.netbsd.org/docs/kernel/uvm.html >> >> via search terms >> uvm replaces machvm netbsd >> >> chuck was a long time contributor to netbsd IIRC, but last time we talked, >> he was using Linux. > > > These days I know he's hacking on FreeBSD's storage stack with me at work > :). I think he's still a netbsd contributor. I see his name in the commit > log often.. > > Warner From akosela at andykosela.com Sun Sep 2 16:29:42 2018 From: akosela at andykosela.com (Andy Kosela) Date: Sun, 2 Sep 2018 08:29:42 +0200 Subject: [TUHS] UVM VM system In-Reply-To: References: <20180901185053.GA20993@mcvoy.com> Message-ID: On Saturday, September 1, 2018, Clem Cole wrote: > > > >> >> Has FreeBSD considered this? >> > Last I knew, no. I was under the impression, the work FreeBSD did > rewriting the Mach stuff paid off for them at the time. I have FreeBSD, > OpenBSD and Linux (and Mac OSx) all running on my systems here. But the > problem is that the HW is all over the map in termns of release date, so > I'm not sure which is faster at this point. The *BSD systems are the > easiest to admin and clean/simplest (which is why they only systems I have > exposed is an OpenBSD box). > OpenBSD is also using uvm[1]. But these days it certainly differs from NetBSD implementation as it was hacked on by different people during the last several years. [1] https://man.openbsd.org/uvm.9 --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve.mynott at gmail.com Sun Sep 2 18:07:02 2018 From: steve.mynott at gmail.com (Steve Mynott) Date: Sun, 2 Sep 2018 09:07:02 +0100 Subject: [TUHS] UVM VM system In-Reply-To: References: <20180901185053.GA20993@mcvoy.com> Message-ID: <20180902080701.i5juplmwihwtppnp@zippy.shellcode.eu> On Sun, Sep 02, 2018 at 08:29:42AM +0200, Andy Kosela typed: > OpenBSD is also using uvm[1]. But these days it certainly differs from > NetBSD implementation as it was hacked on by different people during the > last several years. > > [1] https://man.openbsd.org/uvm.9 Both forks now include a unified buffer cache. There is an interesting series of blog posts at The OpenBSD UVM has particularly diverged from the original with the addition of a "dead entry queue" and the blog author complains about its lack of documentation. He also mentions an experimental RadixVM as being current "state of the art" although its not available on any mainstream systems. -- Steve Mynott cv25519/ECF8B611205B447E091246AF959E3D6197190DD5 From dave at horsfall.org Sun Sep 2 23:06:19 2018 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 2 Sep 2018 23:06:19 +1000 (EST) Subject: [TUHS] Public access multics In-Reply-To: References: <899D86D7-1601-4FDA-869A-10EC46500D0D@gmail.com> Message-ID: On Sat, 1 Sep 2018, John P. Linderman wrote: > PL/I was a language designed by a committee, and it showed. [...] I have never seen a full-blown PL/I compiler (only subsets), and I recall being told that there never will be one because it is simply impossible, given the spec. Naturally I am happy to be proven wrong on this. -- Dave From imp at bsdimp.com Mon Sep 3 00:55:29 2018 From: imp at bsdimp.com (Warner Losh) Date: Sun, 2 Sep 2018 08:55:29 -0600 Subject: [TUHS] UVM VM system In-Reply-To: References: <20180901185053.GA20993@mcvoy.com> Message-ID: On Sat, Sep 1, 2018, 11:19 PM Kevin Bowling wrote: > Seems like Chuck Cranor is at CMU http://chuck.cranor.org/. Chuck > Silvers is with you? > Why I'm embarrassed to admit you are right. Chuck Silvers also did some VM work, but not uvm. Warner On Sat, Sep 1, 2018 at 1:25 PM, Warner Losh wrote: > > > > > > On Sat, Sep 1, 2018, 1:42 PM ron minnich wrote: > >> > >> I was his advisor on that thesis so I got to watch it roll out as it > >> happened. > >> > >> uvm replaced the machvm in netbsd. > >> > >> For a time, Chuck set it up to run in parallel with the existing VM. You > >> could start a process and pick which vm it used. For a while, it > defaulted > >> to the existing one. Then, at some point, it defaulted to uvm. Then, at > some > >> point, the old one was removed. > >> > >> more here: > >> > >> http://www.netbsd.org/docs/kernel/uvm.html > >> > >> via search terms > >> uvm replaces machvm netbsd > >> > >> chuck was a long time contributor to netbsd IIRC, but last time we > talked, > >> he was using Linux. > > > > > > These days I know he's hacking on FreeBSD's storage stack with me at work > > :). I think he's still a netbsd contributor. I see his name in the commit > > log often.. > > > > Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Mon Sep 3 01:28:36 2018 From: will.senn at gmail.com (Will Senn) Date: Sun, 2 Sep 2018 10:28:36 -0500 Subject: [TUHS] UVM VM system In-Reply-To: References: <20180901185053.GA20993@mcvoy.com> Message-ID: <82A3E3CE-2A86-4DDA-9C70-A2B6EE4872F7@gmail.com> According to the Netbsd page: Chuck Cranor designed and implemented UVM, Matthew Green handled integration issues and wrote the swap subsystem, Chuck Silvers wrote the anonymous memory object pager (which added support for shared memory), and various other developers have converted the appropriate ports across. Andrew Brown modified UVM to be able to do top down memory management. It appears both Chuck’s contributed! Will Sent from my iPhone > On Sep 2, 2018, at 9:55 AM, Warner Losh wrote: > > > >> On Sat, Sep 1, 2018, 11:19 PM Kevin Bowling wrote: >> Seems like Chuck Cranor is at CMU http://chuck.cranor.org/. Chuck >> Silvers is with you? > > > Why I'm embarrassed to admit you are right. Chuck Silvers also did some VM work, but not uvm. > > Warner > >> On Sat, Sep 1, 2018 at 1:25 PM, Warner Losh wrote: >> > >> > >> > On Sat, Sep 1, 2018, 1:42 PM ron minnich wrote: >> >> >> >> I was his advisor on that thesis so I got to watch it roll out as it >> >> happened. >> >> >> >> uvm replaced the machvm in netbsd. >> >> >> >> For a time, Chuck set it up to run in parallel with the existing VM. You >> >> could start a process and pick which vm it used. For a while, it defaulted >> >> to the existing one. Then, at some point, it defaulted to uvm. Then, at some >> >> point, the old one was removed. >> >> >> >> more here: >> >> >> >> http://www.netbsd.org/docs/kernel/uvm.html >> >> >> >> via search terms >> >> uvm replaces machvm netbsd >> >> >> >> chuck was a long time contributor to netbsd IIRC, but last time we talked, >> >> he was using Linux. >> > >> > >> > These days I know he's hacking on FreeBSD's storage stack with me at work >> > :). I think he's still a netbsd contributor. I see his name in the commit >> > log often.. >> > >> > Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From charles.unix.pro at gmail.com Mon Sep 3 02:23:15 2018 From: charles.unix.pro at gmail.com (Charles Anthony) Date: Sun, 2 Sep 2018 09:23:15 -0700 Subject: [TUHS] Public access multics In-Reply-To: References: <899D86D7-1601-4FDA-869A-10EC46500D0D@gmail.com> Message-ID: On Sun, Sep 2, 2018 at 6:07 AM Dave Horsfall wrote: > On Sat, 1 Sep 2018, John P. Linderman wrote: > > > PL/I was a language designed by a committee, and it showed. [...] > > I have never seen a full-blown PL/I compiler (only subsets), and I recall > being told that there never will be one because it is simply impossible, > given the spec. > > Naturally I am happy to be proven wrong on this. > > AM83 Multics PL1 Reference Manual, pg 1-1: "Multics PL/I is closely related to American National Standards Programming Language PL/I. ... ANSI X3.53-1976... For a complete description of the differences between Multics PL/I and Standard PL/I, see Appendix A of the PL/I Language Specification." Appendix A, pp A-1 to A-4: https://drive.google.com/open?id=12wRW7vgCVTP4bL7942YiEEUQc2J9bWes https://drive.google.com/open?id=1McndftW6HPioowfIAmL1P8WhabpvYeWg https://drive.google.com/open?id=1XJdaj8YGHTERjTu9xq3KEM0nAGiAFm2M https://drive.google.com/open?id=18VdXROFQmkm_9zL1XLHZCeOxiPLmWDMD -- Charles -- Dave > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Mon Sep 3 04:18:06 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Sun, 2 Sep 2018 14:18:06 -0400 Subject: [TUHS] Public access multics In-Reply-To: References: <899D86D7-1601-4FDA-869A-10EC46500D0D@gmail.com> Message-ID: On 9/2/18, Dave Horsfall wrote: > > I have never seen a full-blown PL/I compiler (only subsets), and I recall > being told that there never will be one because it is simply impossible, > given the spec. > > Naturally I am happy to be proven wrong on this. IBM had PL/I compilers for TOS, DOS, and OS on System/360, and for DOS/VS and OS/VS on System/370. If those weren't full implementations of the original spec, they were pretty close. IBM PL/I had a good number of what I call toxic language features, such as the DEFAULT statement (which was Fortran's IMPLICIT on steroids). Most PL/I shops had as part of their coding standards a set of language features banned from the code. The ANSI standard eliminated a lot of these, although it also threw out some useful features such as iSUB defining and by-name structure assignment. One of my favourite features was sterling pictures, with pounds, shillings, and pence fields (represented internally as a packed decimal value in pence). Sterling pictures weren't finally deprecated in the IBM PL/I compilers until 1979, IIRC. -Paul W,. From paul.winalski at gmail.com Mon Sep 3 05:09:37 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Sun, 2 Sep 2018 15:09:37 -0400 Subject: [TUHS] Public access multics In-Reply-To: References: <899D86D7-1601-4FDA-869A-10EC46500D0D@gmail.com> Message-ID: On 9/2/18, Paul Winalski wrote: > > IBM had PL/I compilers for TOS, DOS, and OS on System/360, and for > DOS/VS and OS/VS on System/370. If those weren't full implementations > of the original spec, they were pretty close. TOS, DOS, and DOS/VS PL/I didn't implement PL/I's multitasking features (such as TASKs and EVENTs) because those OSes had no multitasking support. -Paul W. From tytso at mit.edu Mon Sep 3 05:43:01 2018 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Sun, 2 Sep 2018 15:43:01 -0400 Subject: [TUHS] SunOS code? In-Reply-To: References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu> <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com> <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net> <20180901221933.GA2214@thunk.org> Message-ID: <20180902194301.GA22518@thunk.org> On Sat, Sep 01, 2018 at 10:05:06PM -0700, Kevin Bowling wrote: > > Sorry this is just bogus about being weak compared to Solaris. Are > you looking back with rosy glasses or have you scanned the code in the > past couple years? I have and there is nothing particularly special > about Solaris internals here or elsewhere. I haven't looked at Solaris code; I had just *assumed* that if they were selling million dollar E10k's, they would have had NUMA support at *least* as good as SGI's Irix. And it would have been an excuse for their pathetic performance on UP and 2-4 SMP systems. > Keep in mind IBM wants to sell RockHoppers and E980s (4 drawers, 16 > sockets, 768 threads) for dedicated Linux use which have similar > north/south and east/west off chip networks. They have a lot of very > talented people on the firmware, kernel, compilers to make these > things work fast, including Paul. > ... > Where you start going beyond Linux-like NUMA IMO is when you get > Irix-like features of page copying, migration, and multiple advanced > placement policies. One thing to consider is that IBM really only cared about optimizing hardware for DB2, Oracle, and Webshpere. That's one of the reason why you didn't see much in the way of innovative file system work, ala ZFS. There was no business justification for pouring 100+ engineer years to develop a next-generation file systesm --- and they had already done that once already for GPFS, a cluster file system. As far as local disk file system was concerned, the only real business value it had was to serve as a program loader for DB2 and Websphere. :-) (I'm exagerating a little for effect, but *only* a little.) So as far as NUMA was concerned, there was almost certainly not have been much perceived business value in having sophisticated auto-migration for arbitrary workloads in the kernel. Something basic which was good enough for Oracle, DB2, etc., was all that would be needed. (And if you needed to hire consultants from IBM Global Services to mind-meld with the configuration documentation in order to get the best out of your Rockhopper.... well, shucks, darn. :-) At IBM the business people really did make the funding decisions of what to work on. ZFS could have never happened at IBM because no one would have thought that a even a tiny number of IBM's current or potential customer base would abandon AIX or Linux and switch to Solaris, or buy Sun hardware instead of IBM hardware --- just for the sake of ZFS. And that's how decision-makers at IBM really thought. (And to be fair to those decision-makers, IBM is still in business as a free-standing business --- and Sun is not.) - Ted From doug at cs.dartmouth.edu Mon Sep 3 07:47:01 2018 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sun, 02 Sep 2018 17:47:01 -0400 Subject: [TUHS] Public access multics Message-ID: <201809022147.w82Ll1nu034542@tahoe.cs.Dartmouth.EDU> Caveat: As a member of the PL/I committee, and the person who brought the new and unimplemented language to the attention of Multics, let a disastrous contract for a compiler, and finally helped cobble together a rudimentary compiler that got the project off the ground, I am not exactly an unbiased observer. A ground tenet of Multics was that it would be programmed in a higher level language. A subsidiary requirement, which was generally agreed upon, was language-level access to the logical operators and address manipulation inherent in the hardware. No widely used language of the time met this requirement. And they didn't want to get sidetracked into language design. Discussions finally boiled down to AED, developed at MIT by Doug Ross, and PL/I. Ross was a brilliant software innovator with a mystical outlook that made it difficult to distinguish his vision of what could be done from what actually existed. AED was definitely a moving target. By contrast PL/I had a written spec, so you knew exactly what could be done in it, though not how well the compiler would do it. PL/I was very big; we deliberately (and explicitly) omitted about half the spec. The remainder was definitely seen as a "plausible systems programming language". >From the perspective of the time, why do you think the contrary? Doug From will.senn at gmail.com Mon Sep 3 08:30:25 2018 From: will.senn at gmail.com (Will Senn) Date: Sun, 2 Sep 2018 17:30:25 -0500 Subject: [TUHS] Public access multics In-Reply-To: <0D39179A-9133-4388-ABEC-DCD769E9CD24@pobox.com> References: <20180901232537.615A418C09E@mercury.lcs.mit.edu> <10B61FE8-1418-4201-A782-76E07BD2D34A@gmail.com> <0D39179A-9133-4388-ABEC-DCD769E9CD24@pobox.com> Message-ID: Nice. I’ve always marveled at how, dare I say it while not doing anything about it, badly, dynamic linking has fared in nearly every os I can think of? It is a very convenient feature to have, but the way are implemented can be a little frustrating to a user who isn’t steeped in the internals of the implementation. Thanks for the lesson! Sent from my iPhone > On Sep 1, 2018, at 11:25 PM, Jeffrey H. Johnson wrote: > > While the best loved feature is probably the pervasive dynamic linking, which is still unrivaled, and the security features (ring brackets, AIM (multilevel labeling), and ACLs) which are the most famous, a feature that isn't built in to Unix and is constantly being reinvented that was available in Multics is the ability to easily set aside a CPU and some memory and disk, while leaving the system in operation, and start another separate instance to do development work, and then when the work is done, be reconfigured to merge the system back into one instance, without disrupting production work. > > That dynamic reconfiguration was one original design specifications of the system, as opposed to being added later. Much of what makes Multics wonderful to me is just how amazingly sturdily it's engineered and how complete the implementations of these ideas are. > > Another thing to comes to mind immediately is how hierarchical the system is. For example, users are registered on to projects, and a project administrator can be delegated the task of registering and deregistering user accounts and managing the system resources such as disk quota and access to printers and other physical resources for their project. > > The system administrator can manage the resources assigned to projects, and the project administration handles how that's further carved up amongst the users. > > You can have similar granularity in assigning the distribution of resources such as CPU and memory use, by using the workload management features to ensure that high priority tasks/users/projects will always have needed resources available, preempting lower priority tasks if necessary. > > The I/O system, (while not exceedingly elegant - see iox_), far exceeds what is available in Unix today, but by design. > > The reputation of Multics as a 'complex' system is, in my experience, well deserved, but that complexity does not mean it's a terrible system to use or administer. I find it quite refreshing and it almost never feels dated. > > -- Jeff > https://ban.ai/multics > >> On Sep 2, 2018, at 12:05 AM, Will Senn wrote: >> >> On Sep 1, 2018, at 6:25 PM, Noel Chiappa wrote: >> >>>> From: Will Senn >>> >>>> I was thinking that Multics was a failed predecessor of unix >>>> ... straighten me out :) >>> >>> I'd start with: >>> >>> https://multicians.org/myths.html >> >> Noel, Fascinating read. I must’ve read at least a good handful of the references leading to the myths described in the writeup. As usual, I can trust the folks who lived history to remember it more clearly than many revisionists writing about it later. >> >> Thanks for sharing. >> >> Now, I’m wondering what awesome features Multics had that we’re still lacking in modern *nices... anything as amazing as say, my favorite filesystem, ZFS? >> >> Will > From dfawcus+lists-tuhs at employees.org Mon Sep 3 08:45:15 2018 From: dfawcus+lists-tuhs at employees.org (Derek Fawcus) Date: Sun, 2 Sep 2018 23:45:15 +0100 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: <49620ace-ca66-c288-2ab3-3a0fe4af640e@spamtrap.tnetconsulting.net> References: <20180830175420.3zs4gpyacsgrh7wc@h-174-65.A328.priv.bahnhof.se> <49620ace-ca66-c288-2ab3-3a0fe4af640e@spamtrap.tnetconsulting.net> Message-ID: <20180902224515.GA57766@bugle.employees.org> On Thu, Aug 30, 2018 at 12:11:17PM -0600, Grant Taylor via TUHS wrote: > But if you want to use > RetroNet to play Doom across IPX with buddies across town, then you > should be able to do so. Err - maybe not. I recall doing that once or twice on our office LAN at the time, it was very chatty - as I recall it sucked most of the available b/w. (Or maybe that was just 'cause it was using broadcast packets) DF From gtaylor at tnetconsulting.net Mon Sep 3 09:29:04 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Sun, 2 Sep 2018 17:29:04 -0600 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: <20180902224515.GA57766@bugle.employees.org> References: <20180830175420.3zs4gpyacsgrh7wc@h-174-65.A328.priv.bahnhof.se> <49620ace-ca66-c288-2ab3-3a0fe4af640e@spamtrap.tnetconsulting.net> <20180902224515.GA57766@bugle.employees.org> Message-ID: On 09/02/2018 04:45 PM, Derek Fawcus wrote: > Err - maybe not. O.o? > I recall doing that once or twice on our office LAN at the time, it was > very chatty - as I recall it sucked most of the available b/w. That surprises me. Though to be fair, I never did it that often and it was always during times that bandwidth wasn't an issue. > (Or maybe that was just 'cause it was using broadcast packets) I don't know. I will say, functionality is different than feasibility. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From robert at timetraveller.org Mon Sep 3 11:14:07 2018 From: robert at timetraveller.org (Robert Brockway) Date: Mon, 3 Sep 2018 11:14:07 +1000 (AEST) Subject: [TUHS] UNIX System names - since UNIX was a Trademark In-Reply-To: References: <20180829233605.GJ8423@mcvoy.com> <69AFD606-5E1D-4060-95A5-22F33B2322B2@ccc.com> <3b0a2895-4a6b-48c4-87da-cc1018d7b665.maildroid@localhost> <261201d44189$60c7aa50$2256fef0$@ronnatalie.com> Message-ID: On Sat, 1 Sep 2018, Paul Winalski wrote: > On 9/1/18, Dave Horsfall wrote: >> >> Oh, and I also trained myself to use a mouse in my left hand (in >> right-hand mode, and in my SunOS days too!) which is apparently quite >> common amongst the righties; after all, why waste a perfectly good hand? >> It's hilarious watching someone letting go of the mouse to write something >> down, then back to the mouse again... > > I'm left-handed but I trained myself to use a mouse in my right hand, > for the reason you point out--I still have my dominant hand free to > write things down. It also means that when I'm using someone else's > machine, most of the time their mouse is configured the way I'm used > to. At the risk of making a 'me too' post (especially these days) I am also left handed and trained myself to use a mouse right handed for both of the reasons you mention. Left handedness is very well studied so I wondered if there were any studies on this. While looking I found one that argues that numeric keypads and using the mouse on the right don't mix. Maybe time to run with a keyboard with no numeric keypad again.[1] https://www.ncbi.nlm.nih.gov/pubmed/14985137 [1] As a leftie it's on the wrong side anyway. Rob From jsteve at superglobalmegacorp.com Mon Sep 3 11:11:08 2018 From: jsteve at superglobalmegacorp.com (jsteve at superglobalmegacorp.com) Date: Mon, 3 Sep 2018 09:11:08 +0800 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: <20180902224515.GA57766@bugle.employees.org> References: <20180830175420.3zs4gpyacsgrh7wc@h-174-65.A328.priv.bahnhof.se> <49620ace-ca66-c288-2ab3-3a0fe4af640e@spamtrap.tnetconsulting.net> <20180902224515.GA57766@bugle.employees.org> Message-ID: That is the first version. It sent out full 1500 byte frames. Later versions had corrected that. They were padded to all zeros, so they compress quite nicely. Sent from my Windows 10 phone From: Derek Fawcus Sent: Monday, 3 September 2018 06:45 To: tuhs at minnie.tuhs.org Subject: Re: [TUHS] RetroNet… On Thu, Aug 30, 2018 at 12:11:17PM -0600, Grant Taylor via TUHS wrote: > But if you want to use > RetroNet to play Doom across IPX with buddies across town, then you > should be able to do so. Err - maybe not. I recall doing that once or twice on our office LAN at the time, it was very chatty - as I recall it sucked most of the available b/w. (Or maybe that was just 'cause it was using broadcast packets) DF -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Mon Sep 3 16:18:54 2018 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 03 Sep 2018 00:18:54 -0600 Subject: [TUHS] Public access multics In-Reply-To: <201809022147.w82Ll1nu034542@tahoe.cs.Dartmouth.EDU> References: <201809022147.w82Ll1nu034542@tahoe.cs.Dartmouth.EDU> Message-ID: <201809030618.w836IsgW017828@freefriends.org> Was Algol 60 any kind of viable alternative at the time? IIRC manufacturers in Europe were using it for systems programming. (This is all before my time, so I could be wrong, which is why I'm curious.) In the US Burroughs used Algol, but that may have been later than the mid-60s timeframe of Multics. Thanks, Arnold Doug McIlroy wrote: > Caveat: As a member of the PL/I committee, and the person who brought > the new and unimplemented language to the attention of Multics, let a > disastrous contract for a compiler, and finally helped cobble together > a rudimentary compiler that got the project off the ground, I am not > exactly an unbiased observer. > > A ground tenet of Multics was that it would be programmed in a higher > level language. A subsidiary requirement, which was generally agreed > upon, was language-level access to the logical operators and address > manipulation inherent in the hardware. No widely used language of the > time met this requirement. And they didn't want to get sidetracked into > language design. > > Discussions finally boiled down to AED, developed at MIT by Doug Ross, and > PL/I. Ross was a brilliant software innovator with a mystical outlook that > made it difficult to distinguish his vision of what could be done from > what actually existed. AED was definitely a moving target. By contrast > PL/I had a written spec, so you knew exactly what could be done in it, > though not how well the compiler would do it. > > PL/I was very big; we deliberately (and explicitly) omitted about > half the spec. The remainder was definitely seen as a "plausible > systems programming language". > > From the perspective of the time, why do you think the contrary? > > Doug From trnsz at pobox.com Mon Sep 3 17:02:28 2018 From: trnsz at pobox.com (Jeffrey H. Johnson) Date: Mon, 3 Sep 2018 03:02:28 -0400 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: <20180902224515.GA57766@bugle.employees.org> References: <20180830175420.3zs4gpyacsgrh7wc@h-174-65.A328.priv.bahnhof.se> <49620ace-ca66-c288-2ab3-3a0fe4af640e@spamtrap.tnetconsulting.net> <20180902224515.GA57766@bugle.employees.org> Message-ID: Interestingly - https://virtuallyfun.com/wordpress/2013/10/25/doom-ipx-revisited/ has a good writeup on the Doom IPX issue - it was a poor implementation sending mainly empty frames. https://virtuallyfun.com/wordpress/2014/06/10/announcing-hecnetnt/ shows how adding compression to a bridge is able to eliminate 80% of the traffic. Bring this back on topic, perhaps adding optional LZO compression, but enabled by default, would be a good idea for RetroNet. --Jeff > On Sep 2, 2018, at 6:45 PM, Derek Fawcus wrote: > >> On Thu, Aug 30, 2018 at 12:11:17PM -0600, Grant Taylor via TUHS wrote: >> But if you want to use RetroNet to play Doom across IPX with buddies across town, then you should be able to do so. > > Err - maybe not. > > I recall doing that once or twice on our office LAN at the time, it was very chatty - as I recall it sucked most of the available b/w. > > (Or maybe that was just 'cause it was using broadcast packets) > > DF -------------- next part -------------- An HTML attachment was scrubbed... URL: From erc at pobox.com Mon Sep 3 17:21:00 2018 From: erc at pobox.com (Ed Carp) Date: Mon, 3 Sep 2018 00:21:00 -0700 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: <20180829202111.GA17007@minnie.tuhs.org> References: <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com> <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net> <6e3a87ce-f573-4258-9db5-a5f99b5b89b1.maildroid@localhost> <20180829202111.GA17007@minnie.tuhs.org> Message-ID: Wow, that takes me back quite a ways. I think I've still got my UUCP setup somewhere on a backup. UUCP works great over anything from ssh over tcpip to 1200 baud half-duplex packet connections. Fond memories. On 8/29/18, Warren Toomey wrote: > On Wed, Aug 29, 2018 at 02:38:20PM -0400, William Pechter wrote: >> Count me in. Do we need to work up a UUCP mapping project. > > Argh, argh! I did a lot of this last year. It's all on Github at > https://github.com/DoctorWkt/4bsd-uucp/ > > We got as far as recreating this microcosm of Usenet > https://github.com/DoctorWkt/4bsd-uucp/blob/4.3BSD/uucp.png > > before it all petered out! > > Cheers, Warren > From jsteve at superglobalmegacorp.com Mon Sep 3 18:24:47 2018 From: jsteve at superglobalmegacorp.com (jsteve at superglobalmegacorp.com) Date: Mon, 3 Sep 2018 16:24:47 +0800 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: References: <20180830175420.3zs4gpyacsgrh7wc@h-174-65.A328.priv.bahnhof.se> <49620ace-ca66-c288-2ab3-3a0fe4af640e@spamtrap.tnetconsulting.net> <20180902224515.GA57766@bugle.employees.org> Message-ID: Yes, I’m familiar with that write up…. I wrote it! And yes, it's why I later grabbed a bunch of compression algorithms and went with lzss as it compressed well, fast an ld was tiny compared to others... https://virtuallyfun.com/wordpress/2014/06/06/i-forget-what-i-was-looking-for/ I would highly recommend compressing the frames for sure. On high latency links it sure helps too. It's also why cisco had licensed LZS compression for their serial links. And totally worth looking at. From: Jeffrey H. Johnson Sent: Monday, 3 September 2018 15:12 To: Derek Fawcus Cc: tuhs at minnie.tuhs.org Subject: Re: [TUHS] RetroNet… Interestingly -  https://virtuallyfun.com/wordpress/2013/10/25/doom-ipx-revisited/ has a good writeup on the Doom IPX issue - it was a poor implementation sending mainly empty frames.  https://virtuallyfun.com/wordpress/2014/06/10/announcing-hecnetnt/ shows how adding compression to a bridge is able to eliminate 80% of the traffic. Bring this back on topic, perhaps adding optional LZO compression, but enabled by default, would be a good idea for RetroNet. --Jeff  On Sep 2, 2018, at 6:45 PM, Derek Fawcus wrote: On Thu, Aug 30, 2018 at 12:11:17PM -0600, Grant Taylor via TUHS wrote: But if you want to use RetroNet to play Doom across IPX with buddies across town, then you should be able to do so. Err - maybe not. I recall doing that once or twice on our office LAN at the time, it was very chatty - as I recall it sucked most of the available b/w. (Or maybe that was just 'cause it was using broadcast packets) DF -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Mon Sep 3 23:29:05 2018 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Mon, 03 Sep 2018 09:29:05 -0400 Subject: [TUHS] Public access multics Message-ID: <201809031329.w83DT5q0105108@tahoe.cs.Dartmouth.EDU> > Was Algol 60 any kind of viable alternative at the time? The operating system for the Burroughs B5000 had been written in Burroughs Algol. That punctured the widespread belief that OS's were so particular to the hardware that they had to be written in machine language. I don't recall how far Burroughs Algol went beyond Algol 60, nor why Multics did not want to follow that lead. ("Viable" is a slippery concept when choosing among Turing-complete alternatives.) Doug From gtaylor at tnetconsulting.net Tue Sep 4 02:42:38 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Mon, 3 Sep 2018 10:42:38 -0600 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: References: <20180830175420.3zs4gpyacsgrh7wc@h-174-65.A328.priv.bahnhof.se> <49620ace-ca66-c288-2ab3-3a0fe4af640e@spamtrap.tnetconsulting.net> <20180902224515.GA57766@bugle.employees.org> Message-ID: On 09/03/2018 01:02 AM, Jeffrey H. Johnson wrote: > Bring this back on topic, perhaps adding optional LZO compression, but > enabled by default, would be a good idea for RetroNet. Interesting idea Jeff. I don't know that any of the Lego bricks that we're currently using support any form of compression. We'll have to investigate. Consider compression to be on the "It would be really nice to have" list. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From ca6c at bitmessage.ch Tue Sep 4 04:04:01 2018 From: ca6c at bitmessage.ch (=?utf-8?B?Q8OhZw==?=) Date: Mon, 03 Sep 2018 13:04:01 -0500 Subject: [TUHS] cat -v and other complaints In-Reply-To: References: <20180831215636.-eCEx%ca6c@bitmessage.ch> Message-ID: <20180903180401.u4MVs%ca6c@bitmessage.ch> Andrew Warkentin wrote: > I'd say features like history, completion, and line editing really > don't belong in a shell. They should be handled by a separate listener > process with a simple API that shells and other client processes can > use for controlling them. That's one good example of Plan 9 > prioritizing minimalism above everything else. http://wiki.c2.com/?WhatIsNotInPlanNine > fn history {grep '^term%' /mnt/wsys/text|sed -e 's/^term%//'} term% This is sure better. On top of that I don't get how Acme adheres to the philosophy. It's basically a reverse engineered, unavailable on the console, GNU Emacs with a mouse-driven interface. -- caóc From khm at sciops.net Tue Sep 4 04:11:33 2018 From: khm at sciops.net (Kurt H Maier) Date: Mon, 3 Sep 2018 11:11:33 -0700 Subject: [TUHS] cat -v and other complaints In-Reply-To: <20180903180401.u4MVs%ca6c@bitmessage.ch> References: <20180831215636.-eCEx%ca6c@bitmessage.ch> <20180903180401.u4MVs%ca6c@bitmessage.ch> Message-ID: <20180903181133.GB81368@wopr> On Mon, Sep 03, 2018 at 01:04:01PM -0500, Cág wrote: > > On top of that I don't get how Acme adheres to the philosophy. It's > basically a reverse engineered, unavailable on the console, GNU Emacs > with a mouse-driven interface. > My pet theory is that Acme was going to replace Rio, at which time it would be 'the interface' again instead of a text editor with a slightly-incompatible filesystem interface. There are some hints toward this if you squint hard enough, but I can't prove it. "Unavailable on the console" is kind of a cheap shot when talking about an operating system that deliberately doesn't support consoles. Part of the point was outgrowing TTYs. The emacs comparison is a favorite of mine because it's so close to being an anagram, but obviously Acme never suffered from lisp fetishism. I still dislike Acme for basically all the same reasons I dislike emacs. khm From ca6c at bitmessage.ch Tue Sep 4 04:56:16 2018 From: ca6c at bitmessage.ch (=?utf-8?B?Q8OhZw==?=) Date: Mon, 03 Sep 2018 13:56:16 -0500 Subject: [TUHS] cat -v and other complaints In-Reply-To: <20180903181133.GB81368@wopr> References: <20180831215636.-eCEx%ca6c@bitmessage.ch> <20180903180401.u4MVs%ca6c@bitmessage.ch> <20180903181133.GB81368@wopr> Message-ID: <20180903185616.ZnkRk%ca6c@bitmessage.ch> Kurt H Maier wrote: > My pet theory is that Acme was going to replace Rio, at which time it > would be 'the interface' again instead of a text editor with a > slightly-incompatible filesystem interface. There are some hints toward > this if you squint hard enough, but I can't prove it. Oberon 2.0 > "Unavailable on the console" is kind of a cheap shot when talking about > an operating system that deliberately doesn't support consoles. Part of > the point was outgrowing TTYs. Yeah, I guess I should've started with that :) I love Unix for the console. -- caóc From bakul at bitblocks.com Tue Sep 4 06:08:41 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Mon, 3 Sep 2018 13:08:41 -0700 Subject: [TUHS] cat -v and other complaints In-Reply-To: <20180903181133.GB81368@wopr> References: <20180831215636.-eCEx%ca6c@bitmessage.ch> <20180903180401.u4MVs%ca6c@bitmessage.ch> <20180903181133.GB81368@wopr> Message-ID: On Sep 3, 2018, at 11:11 AM, Kurt H Maier wrote: > > I still dislike Acme for basically all the same reasons I dislike emacs. What text editor do you like? One measure of success of a program is additional tools people build to work with it. By that measure emacs has succeeded very well. Acme is used by far fewer people but it too has had additional tools built. And even standard tools such as grep work well with it. You can also view it as an experiment and not an end product. That is, nothing to prevent anyone from extending it or changing it. The same is true of plan9 too. An experiment in seeing how far “representing resources as filesystems” model can be pushed. But for some reason this never happened. From khm at sciops.net Tue Sep 4 06:41:15 2018 From: khm at sciops.net (Kurt H Maier) Date: Mon, 3 Sep 2018 13:41:15 -0700 Subject: [TUHS] cat -v and other complaints In-Reply-To: References: <20180831215636.-eCEx%ca6c@bitmessage.ch> <20180903180401.u4MVs%ca6c@bitmessage.ch> <20180903181133.GB81368@wopr> Message-ID: <20180903204115.GC99551@wopr> On Mon, Sep 03, 2018 at 01:08:41PM -0700, Bakul Shah wrote: > > One measure of success of a program is additional tools people build > to work with it. This is true, but unix and plan 9 are special because they have facilities that let many tools work together. Unix has pipes, plan 9 has the plumber on top of that, and so forth. I prefer tools that work with these systems to create an environment that lets me use the whole world to do my job. Emacs pointlessly restricts itself to its own reinventions of the world it inhabits. It makes sense if you are using a LispM but it constitutes a rejection of the 'system' component of 'operating system' when you transplant it to an ecosystem built on a different paradigm. The current modality of this antisocial behavior is the web; we've come full circle, and now we have bespoke web browsers shoved into the text-editing role, reinventing everything from character addressing to memory management on the way, treating the underlying system as an unfortunate accident of history instead of integrating with (or even learning from) it. Acme is a bad citizen in similar ways, but as I said, I suspect that's because it was intended to supplant Rio rather than infect it. When people talk about "the unix way," they usually hyperfocus on "do one thing well" and leave composability by the wayside, and that's a shame, because that's where the real power comes from. "Do one thing well" is a method to achieve quality when you're building a piece of a well-integrated system. If you're not building a well-integrated system, you *can't* "do one thing well," because you've signed on to do everything, come hell or high water. khm From bakul at bitblocks.com Tue Sep 4 07:46:14 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Mon, 3 Sep 2018 14:46:14 -0700 Subject: [TUHS] cat -v and other complaints In-Reply-To: <20180903204115.GC99551@wopr> References: <20180831215636.-eCEx%ca6c@bitmessage.ch> <20180903180401.u4MVs%ca6c@bitmessage.ch> <20180903181133.GB81368@wopr> <20180903204115.GC99551@wopr> Message-ID: On Sep 3, 2018, at 1:41 PM, Kurt H Maier wrote: > > Acme is a bad citizen in similar ways, but as I said, I suspect that's > because it was intended to supplant Rio rather than infect it. I’m still not clear on why you think acme is a bad citizen. If anything it makes its windows more accessible to other tools. Unlike emacs or vim or any IDE. What could acme have differently or what other editor is not a “bad citizen”. > When people talk about "the unix way," they usually hyperfocus on "do > one thing well" and leave composability by the wayside, and that's a > shame, because that's where the real power comes from. "Do one thing > well" is a method to achieve quality when you're building a piece of a > well-integrated system. If you're not building a well-integrated > system, you *can't* "do one thing well," because you've signed on to do > everything, come hell or high water. Composability is implicitly the key point in “the Unix way” but typically editors are not very composable. Or composable in a different domain. Similarly GUI. Once you add a human in your composition, further composability falls apart! A human being the ultimate “do everything” kitchen sink:-) The question is what can be done to improve composability beyond the “Unix way” or plan9 way. From dave at horsfall.org Tue Sep 4 09:01:47 2018 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 4 Sep 2018 09:01:47 +1000 (EST) Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: References: <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com> <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net> <6e3a87ce-f573-4258-9db5-a5f99b5b89b1.maildroid@localhost> <20180829202111.GA17007@minnie.tuhs.org> Message-ID: On Mon, 3 Sep 2018, Ed Carp wrote: > Wow, that takes me back quite a ways. I think I've still got my UUCP > setup somewhere on a backup. UUCP works great over anything from ssh > over tcpip to 1200 baud half-duplex packet connections. If you're referring to "Amateur" i.e. "ham radio" packet radio than yes, I'm told that it works great i.e. half-duplex -> large data -> short ACK. > Fond memories. Heh heh - I once ran *raw* Xmodem over packet i.e. not encapsulated in that protocol-from-hell AX.25 i.e. technically illegal[*]; it worked great until a packet was lost (the "hidden transmitter" problem) and the various timeouts concerned (Xmodem vs. the TNCs themselves) went completely pear-shaped... [*] Stuff the legality; isn't Amateur radio all about experimentation? But we did announce on that frequency that we were about to conduct an experiment. And whoever designed AX.25 (yes, I have studied it in great detail) must've been on something at the time... Protocol layers? What's that? -- Dave (VK2KFU) From dave at horsfall.org Tue Sep 4 09:41:27 2018 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 4 Sep 2018 09:41:27 +1000 (EST) Subject: [TUHS] Public access multics In-Reply-To: <201809031329.w83DT5q0105108@tahoe.cs.Dartmouth.EDU> References: <201809031329.w83DT5q0105108@tahoe.cs.Dartmouth.EDU> Message-ID: On Mon, 3 Sep 2018, Doug McIlroy wrote: >> Was Algol 60 any kind of viable alternative at the time? > > The operating system for the Burroughs B5000 had been written in > Burroughs Algol. That punctured the widespread belief that OS's were so > particular to the hardware that they had to be written in machine > language. I don't recall how far Burroughs Algol went beyond Algol 60, > nor why Multics did not want to follow that lead. ("Viable" is a > slippery concept when choosing among Turing-complete alternatives.) Call me memory-challenged (which I am these days), but wasn't Burroughs' OS known as Master Control Program (MCP - Male Chauvinist Pig)? -- Dave, who has fond memories of the B1500... From khm at sciops.net Tue Sep 4 10:52:13 2018 From: khm at sciops.net (Kurt H Maier) Date: Mon, 3 Sep 2018 17:52:13 -0700 Subject: [TUHS] cat -v and other complaints In-Reply-To: References: <20180831215636.-eCEx%ca6c@bitmessage.ch> <20180903180401.u4MVs%ca6c@bitmessage.ch> <20180903181133.GB81368@wopr> <20180903204115.GC99551@wopr> Message-ID: <20180904005213.GD99551@wopr> On Mon, Sep 03, 2018 at 02:46:14PM -0700, Bakul Shah wrote: > > I’m still not clear on why you think acme is a bad citizen. If anything it > makes its windows more accessible to other tools. Unlike emacs or vim > or any IDE. What could acme have differently or what other editor is > not a “bad citizen”. > Ok. I apologize for expressing myself poorly. I give up. > Composability is implicitly the key point in “the Unix way” but typically > editors are not very composable. Or composable in a different domain. > Similarly GUI. Once you add a human in your composition, further > composability falls apart! A human being the ultimate “do everything” > kitchen sink:-) I don't consider myself on an equal footing as the tools I use. I don't "add a human in my composition." I compose. This is a pretty fundamental difference between me and software. > The question is what can be done to improve composability beyond the > “Unix way” or plan9 way. I have about a million questions to answer first, and I suspect the industry as a whole will collapse and re-form a few times before anyone gets around to answering that one. We haven't even fully developed composability in "the unix way" since market forces seem to have frozen things in a sort of late-1980s amber. I envy the future generation that rediscovers the core concept and runs with it, but I doubt I'll be around then. Information technology is entering an ice age in which general-purpose computing is not guaranteed to select for survival; the barrier to entry for understanding systems has never been higher, there is a distinct and global trend against it, and the cost of thirty years' abuse of Moore's law is coming due. Hunter Thompson's high-water mark comes to mind. I am grateful, for these reasons, for the efforts of people like TUHS and Bitsavers, so that I can still find and use the tools that were made back before people confused the simplistic for the simple, even if it gets harder to make a living with them each passing year. khm From trnsz at pobox.com Tue Sep 4 12:47:46 2018 From: trnsz at pobox.com (Jeffrey H. Johnson) Date: Mon, 3 Sep 2018 22:47:46 -0400 Subject: [TUHS] Public access multics In-Reply-To: References: <201809031329.w83DT5q0105108@tahoe.cs.Dartmouth.EDU> Message-ID: Yes, correct - I don't want to bring the list too off-topic, but Unisys (UNIVAC + Burroughs) still maintains those two platforms (OS 2000 from the UNIVAC line and MCP from Burroughs), and they have a hobbyist program for both systems. https://www.unisys.com/offerings/clearpath-forward/clearpath-forward-products/clearpath-os-2200-software/clearpath-os-2200-express and https://www.unisys.com/offerings/clearpath-forward/clearpath-forward-products/clearpath-mcp-software/clearpath-mcp-express Unisys has also released older versions of MCP (1970s) as well with less restrictive licensing, and the community has built an emulator capable of running them on an emulated B5500 system - http://www.phkimpel.us/B5500/ The Burroughs MCP name supposedly inspired the MCP villain in TRON as well. I've never used Burroughs Algol nor Honeywell Algol, but I am aware you can use Honeywell Algol on Multics via gcos_tss (the GCOS Time Sharing Simulator). -- Jeff > On Sep 3, 2018, at 7:41 PM, Dave Horsfall wrote: > > On Mon, 3 Sep 2018, Doug McIlroy wrote: > >>> Was Algol 60 any kind of viable alternative at the time? >> >> The operating system for the Burroughs B5000 had been written in Burroughs Algol. That punctured the widespread belief that OS's were so particular to the hardware that they had to be written in machine language. I don't recall how far Burroughs Algol went beyond Algol 60, nor why Multics did not want to follow that lead. ("Viable" is a slippery concept when choosing among Turing-complete alternatives.) > > Call me memory-challenged (which I am these days), but wasn't Burroughs' OS known as Master Control Program (MCP - Male Chauvinist Pig)? > > -- Dave, who has fond memories of the B1500... -------------- next part -------------- An HTML attachment was scrubbed... URL: From akosela at andykosela.com Tue Sep 4 16:10:26 2018 From: akosela at andykosela.com (Andy Kosela) Date: Tue, 4 Sep 2018 08:10:26 +0200 Subject: [TUHS] cat -v and other complaints In-Reply-To: <20180903185616.ZnkRk%ca6c@bitmessage.ch> References: <20180831215636.-eCEx%ca6c@bitmessage.ch> <20180903180401.u4MVs%ca6c@bitmessage.ch> <20180903181133.GB81368@wopr> <20180903185616.ZnkRk%ca6c@bitmessage.ch> Message-ID: On Monday, September 3, 2018, Cág wrote: > Kurt H Maier wrote: > > > My pet theory is that Acme was going to replace Rio, at which time it > > would be 'the interface' again instead of a text editor with a > > slightly-incompatible filesystem interface. There are some hints toward > > this if you squint hard enough, but I can't prove it. > > Oberon 2.0 > > > "Unavailable on the console" is kind of a cheap shot when talking about > > an operating system that deliberately doesn't support consoles. Part of > > the point was outgrowing TTYs. > > Yeah, I guess I should've started with that :) I love Unix for the > console. > Pure text interface will always be the most elegant way to converse with a machine. And Unix is the most elegant command line based system. The world lost something when it moved to GUI. I still prefer to use the old phosphor based CRT monitors even with modern computers and because the text mode is still inherent in modern graphics cards (as a legacy mode), it is possible to not use GUI at all even today. That was one of the main reasons I disliked Plan9. It embraced the "windows interface" trend of the mid 80s. --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Tue Sep 4 16:41:49 2018 From: rminnich at gmail.com (ron minnich) Date: Mon, 3 Sep 2018 23:41:49 -0700 Subject: [TUHS] cat -v and other complaints In-Reply-To: References: <20180831215636.-eCEx%ca6c@bitmessage.ch> <20180903180401.u4MVs%ca6c@bitmessage.ch> <20180903181133.GB81368@wopr> <20180903185616.ZnkRk%ca6c@bitmessage.ch> Message-ID: On Mon, Sep 3, 2018 at 11:11 PM Andy Kosela wrote: > > That was one of the main reasons I disliked Plan9. It embraced the > "windows interface" trend of the mid 80s. > > > well, you can believe that, and I can't stop you, but it's wrong. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfawcus+lists-tuhs at employees.org Tue Sep 4 18:52:27 2018 From: dfawcus+lists-tuhs at employees.org (Derek Fawcus) Date: Tue, 4 Sep 2018 09:52:27 +0100 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: References: <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com> <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net> <6e3a87ce-f573-4258-9db5-a5f99b5b89b1.maildroid@localhost> <20180829202111.GA17007@minnie.tuhs.org> Message-ID: <20180904085226.GA81023@bugle.employees.org> On Tue, Sep 04, 2018 at 09:01:47AM +1000, Dave Horsfall wrote: > > Heh heh - I once ran *raw* Xmodem over packet i.e. not encapsulated in > that protocol-from-hell AX.25 i.e. technically illegal[*]; Why would that be illegal? Last time I checked (in the UK) we can use any form of modulation or encoding we want [*], as long as we record/log it, and don't use encryption. DF [*] Except spark gap transmitters From akosela at andykosela.com Tue Sep 4 19:34:45 2018 From: akosela at andykosela.com (Andy Kosela) Date: Tue, 4 Sep 2018 11:34:45 +0200 Subject: [TUHS] cat -v and other complaints In-Reply-To: References: <20180831215636.-eCEx%ca6c@bitmessage.ch> <20180903180401.u4MVs%ca6c@bitmessage.ch> <20180903181133.GB81368@wopr> <20180903185616.ZnkRk%ca6c@bitmessage.ch> Message-ID: On Tuesday, September 4, 2018, ron minnich wrote: > > > On Mon, Sep 3, 2018 at 11:11 PM Andy Kosela > wrote: > >> >> That was one of the main reasons I disliked Plan9. It embraced the >> "windows interface" trend of the mid 80s. >> >> >> > well, you can believe that, and I can't stop you, but it's wrong. > Can you elaborate more on your point of view? There has been a slow shift in the way we use computer interfaces and the start of the "windows computing" revolution certainly happened around mid 80s with companies like Apple, Microsoft or Commodore developing their own version of GUI (which goes back to Xerox PARC of course). Unix received X Window System from MIT in 1984. At the time people thought that GUI is the best and most useful interface for the new era and text terminal computing is about to die pretty soon. Well it took at least 10 more years to happen and the introduction of World Wide Web and Windows 95 certainly help solidify it. When Plan 9 was created in the mid-late 80s exactly those ideas circulated. Nothing comes from nothing, everything has its historical context. In the late 80s in order to "innovate" it was natural to think that abandoning text terminals is a "progress". Unix was born in the different era. Same with the original IBM PC. That is why they revolve around pure text interface. I'm just glad that text mode survived and it is still available even on modern PC's. But most kids these days don't even know what it is... They have GUIs everywhere, from their smartphones to their laptops. It is a very sad state of things when people more and more abandon text computing for the image based computing. I agree with Kurt that we are already in the Information Technology ice age. General purpose pure text based computing is slowly becoming just a retro hobby. --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From akosela at andykosela.com Tue Sep 4 19:39:42 2018 From: akosela at andykosela.com (Andy Kosela) Date: Tue, 4 Sep 2018 11:39:42 +0200 Subject: [TUHS] SunOS code? In-Reply-To: References: <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829004627.GG317@mcvoy.com> <201808290529.w7T5TFKa006049@freefriends.org> <20180829145300.GP317@mcvoy.com> Message-ID: On Saturday, September 1, 2018, Warner Losh wrote: > > > On Sat, Sep 1, 2018 at 7:50 AM Andy Kosela wrote: > >> >> >> On Saturday, September 1, 2018, Steve Mynott >> wrote: >> >>> >>> >>> On Wed, 29 Aug 2018 at 15:53, Larry McVoy wrote: >>> >>> The BSDs have a less than optimal VM system. Having SunOS opened up >>>> would at least let people see what they are missing. Maybe I have >>>> rose colored glasses on but it was the only kernel that came into >>>> focus for me and you could see the architecture from the code. >>>> Everything else seems like a mess to me. >>>> >>> >>> That may have been true in the late 80s and even early 90s but I'd have >>> thought FreeBSD, NetBSD and OpenBSD would have useable VMs by now. >>> >>> I've vague recollections that these all originally used the VM from Mach >>> which did have problems at first. >>> >> > Yes. CSRG used Mach VM because it was available, not because it was > awesome. The folks at CSRG approached Sun to have them donate their VM to > BSD, and there were serious talks about doing this until the lawyers got > involved and explained that would require a serious write down on their > quarterly report so that nixed the whole thing. > > >> I recall a more knowledgeable friend complaining about FreeBSD VM in 1994 >>> or so. >>> >> > It used to be downright aweful. > > >> I think the latter two use UVM and FreeBSD improved their Mach one (which >>> has a SunOS kvmish API anyway). I've not seen complaints about modern BSD. >>> >> > OpenBSD and NetBSD both moved to uvm. > > >> Wasn't the whole FreeBSD VM rewritten by John Dyson and David Greenman in >> the mid-late 90's? And then further improved by Matthew Dillon. >> >> Unfortunately they are not affiliated with the project anymore. All >> three had exceptional coding skills. >> > > With the exception of David, it's not unfortunate at all. Although they > were good for the project's code, they weren't good for the project. They > didn't work well with others and caused much more grief than the code they > contributed. There comes a time when there's just too much drama and the > rest of the code gets much much better when you aren't always fighting > drama :(. It was a tough decision to make when I was on the core team to > show Dillon the door. One not made lightly, nor without a lot of effort to > work through the issues. In the end, though, we had to part ways. Dillon > has done well with DragonFly, however. > Well, there are certainly as many sides to this story as there are people involved. Same with NetBSD/OpenBSD split. Let's leave it as that as I don't believe we have mentioned people on this list so they can't defend themselves. --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Tue Sep 4 20:23:26 2018 From: crossd at gmail.com (Dan Cross) Date: Tue, 4 Sep 2018 06:23:26 -0400 Subject: [TUHS] cat -v and other complaints In-Reply-To: References: <20180831215636.-eCEx%ca6c@bitmessage.ch> <20180903180401.u4MVs%ca6c@bitmessage.ch> <20180903181133.GB81368@wopr> <20180903185616.ZnkRk%ca6c@bitmessage.ch> Message-ID: On Tue, Sep 4, 2018 at 5:35 AM Andy Kosela wrote: > On Tuesday, September 4, 2018, ron minnich wrote: >> >> On Mon, Sep 3, 2018 at 11:11 PM Andy Kosela >> wrote: >> >>> That was one of the main reasons I disliked Plan9. It embraced the >>> "windows interface" trend of the mid 80s. >>> >> >> well, you can believe that, and I can't stop you, but it's wrong. >> > > Can you elaborate more on your point of view? > I don't mean to speak for Ron, but I think I know where he's coming from. There has been a slow shift in the way we use computer interfaces and the > start of the "windows computing" revolution certainly happened around mid > 80s with companies like Apple, Microsoft or Commodore developing their own > version of GUI (which goes back to Xerox PARC of course). Unix received X > Window System from MIT in 1984. > Don't mistake "windows" (as in "stacking window manager") for "bitmapped graphical displays." At the time people thought that GUI is the best and most useful interface > for the new era and text terminal computing is about to die pretty soon. > Well it took at least 10 more years to happen and the introduction of World > Wide Web and Windows 95 certainly help solidify it. > > When Plan 9 was created in the mid-late 80s exactly those ideas > circulated. Nothing comes from nothing, everything has its historical > context. In the late 80s in order to "innovate" it was natural to think > that abandoning text terminals is a "progress". > This is conflating two things: textual interfaces and the graphical presentation of those interfaces. Plan 9 is about both. Unix was born in an era where the TTY (that is, tele-typewriter, as in "prints to paper") was still very much a force in mediating the interaction between user and computer. That evolved rather quickly to the "green screen" terminals of the 70s and early 80s, but the paradigm was basically the same: the serial terminal was a window showing the tail of an infinite scroll of data. The "terminal", as in the TTY, was and is a central abstraction in Unix. By the late 80s, when plan9 got started, the paradigm had shifted: machines now had relatively high resolution bitmapped graphical interfaces, and by and large you weren't sitting in front of a serial terminal anymore. Being tied to a single "terminal" was a hindrance and led to a lot of complexity (job control, terminal interactions with process groups, POSIX sessions, signals and ioctls for window-size changes for programs that wanted to continue believing that they're using a serial terminal, even though they haven't been for years...). Plan9 wanted to take advantage of the new graphics functionality but didn't want to be chained to the complexity associated with obsolete hardware (e.g., the TTY abstraction, which _still persists_ and has its fingers in weird parts of the kernel). They still wanted a text-oriented interface though, and that's what plan9 provides. You sweep out a rio window and it's running a shell. Text in acme is usually editable and there aren't a lot of strange glyphs to click on; commands are strings. And you're no longer chained to a "terminal": I can have many shells running in many windows and they're all more or less the same. And it allowed them to move beyond the limitations of cursor-addressed user interfaces. They could, for example, write (or more precisely adapt) text editors like `sam`, which is fundamentally a textual program but uses the GUI to very nice effect. It may seem dated by today's standards, but it still works very nicely (indeed, I had to run a coworker through a sam session last Thursday; he was a continent away from me connecting to a plan9 system but we were able to do what needed to be done relatively quickly because it's all text and so simple...). I remember when I was in high school driving over to New Jersey and going to Bell Labs and meeting Dennis Ritchie for the first time (a college student I knew was doing an internship there and let me come visit). Dennis showed me plan9 on his gnot (this was back in the 8.5 days), and specifically talked about this: the focus was text, which was editable, could be manipulated, combined, split apart, was self-explanatory etc, instead of little icons like MS Windows and the Mac which were simultaneously static and cryptic. It *is* a textual interface, though it's *presented* and *multiplexed* via a bitmapped graphics display. I distinctly remember feeling blown away by the powerful marriage of text with bitmapped displays; it was a GUI for a Unix-like experience done right. They didn't sacrifice anything, but they gained so much more. Unix was born in the different era. Same with the original IBM PC. That > is why they revolve around pure text interface. > Unix and the PC date from radically different eras. The original IBM PC had a graphics adapter, and that was the expected mode of interaction, not the serial port. Granted that adapter was pretty weak, but it was there. Using a PC, you were using a graphical representation of your text interface. Unlike a serial terminal, where you simply emit the text to the terminal and the terminal deals with displaying it, writing an interface for CGA or MGA -- even in text mode -- involves scrolling the buffer, handling line feeds, tab and backspace expansion, and all the rest of it in software (granted, lots of serial drivers for Unix handle tab and BS expansion, too). But you, the programmer, have to manually keep track of your position in that little 4k buffer. You have to deal with moving the cursor around, etc. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.bowling at kev009.com Tue Sep 4 21:47:39 2018 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Tue, 4 Sep 2018 04:47:39 -0700 Subject: [TUHS] SunOS code? In-Reply-To: <20180902194301.GA22518@thunk.org> References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu> <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com> <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net> <20180901221933.GA2214@thunk.org> <20180902194301.GA22518@thunk.org> Message-ID: On Sun, Sep 2, 2018 at 12:43 PM, Theodore Y. Ts'o wrote: > On Sat, Sep 01, 2018 at 10:05:06PM -0700, Kevin Bowling wrote: >> >> Sorry this is just bogus about being weak compared to Solaris. Are >> you looking back with rosy glasses or have you scanned the code in the >> past couple years? I have and there is nothing particularly special >> about Solaris internals here or elsewhere. > > I haven't looked at Solaris code; I had just *assumed* that if they > were selling million dollar E10k's, they would have had NUMA support > at *least* as good as SGI's Irix. And it would have been an excuse > for their pathetic performance on UP and 2-4 SMP systems. One would hope so, but that was the strategy that got them eaten by a grue. Another funny anecdote about this aloofness.. Linux on sparc64 uses the Relaxed Memory Order mode that the hardware offers . Solaris.. Total Store Order. There are tons of things like this in the code that blow my mind. I would have been pissed if I were on the hardware side of SPARC. > >> Keep in mind IBM wants to sell RockHoppers and E980s (4 drawers, 16 >> sockets, 768 threads) for dedicated Linux use which have similar >> north/south and east/west off chip networks. They have a lot of very >> talented people on the firmware, kernel, compilers to make these >> things work fast, including Paul. >> ... >> Where you start going beyond Linux-like NUMA IMO is when you get >> Irix-like features of page copying, migration, and multiple advanced >> placement policies. > > One thing to consider is that IBM really only cared about optimizing > hardware for DB2, Oracle, and Webshpere. That's one of the reason why > you didn't see much in the way of innovative file system work, ala > ZFS. There was no business justification for pouring 100+ engineer > years to develop a next-generation file systesm --- and they had > already done that once already for GPFS, a cluster file system. As > far as local disk file system was concerned, the only real business > value it had was to serve as a program loader for DB2 and Websphere. :-) > > (I'm exagerating a little for effect, but *only* a little.) Hmm, I think they've been pretty earnest at wanting to be 2+ years ahead of the general market with POWER for as long as I can see, lots of HPC money has been subsidizing that. Depends on the workload but bus and memory bandwidth right now with PCIe Gen4 and NvLink can really cut down on server sprawl. I've met with the GM/chief architect and they see OpenPOWER positioned as a full frontal competitor to Intel Xeon. I'm fairly disappointed in my contemporaries for not recognizing the value of a completely open source firmware and on chip controller stack; especially after the recent snafu where Intel changed the microcode license to disallow benchmarks and claimed it was an accident. Your statements make sense to me with respect to AIX, as Linux has been the main effort since the 2000s. GPFS looks neat, I wish it were open or at least internals documented well enough to study the implementation academically. > > So as far as NUMA was concerned, there was almost certainly not have > been much perceived business value in having sophisticated > auto-migration for arbitrary workloads in the kernel. Something basic > which was good enough for Oracle, DB2, etc., was all that would be > needed. (And if you needed to hire consultants from IBM Global > Services to mind-meld with the configuration documentation in order to > get the best out of your Rockhopper.... well, shucks, darn. :-) That's probably the dirty little secret. It's long been profitable to carefully plan software interrupt handlers, user threads, and memory allocation even on pedestrian servers if they are running a fixed function. I guess Google's Borg and the new workalikes could do semi-automagic things with cgroups these days. There is evidence of people getting pretty crazy with it when we see things like Intel cache allocation features. > At IBM the business people really did make the funding decisions of > what to work on. ZFS could have never happened at IBM because no one > would have thought that a even a tiny number of IBM's current or > potential customer base would abandon AIX or Linux and switch to > Solaris, or buy Sun hardware instead of IBM hardware --- just for the > sake of ZFS. And that's how decision-makers at IBM really thought. > (And to be fair to those decision-makers, IBM is still in business as > a free-standing business --- and Sun is not.) Agreed, one of these companies is doing pretty well with a fat dividend yield, that other has basically been dismantled for all but a couple remaining desirable platform control points like Java and MySQL. Many things in tech are happy accidents and a small number of motivated people at the right place and time. A Sun engineer admitted on some video I've seen that the green light was really given for ZFS because they got stumped by some UFS bugs.. once enough of ZFS was written to test the end to end checksumming features they found out some of these heisenbugs were LSI HBA and disk firmware issues :o) Surveying some of these filesystems.. JFS2 is a decent, nowhere near the capabilities of ZFS but even today it's not in dire need of replacement.. I suspect another issue complementary to your point is the standalone storage business is many $B of revenue. ESS/DS8000 and the like are preferred revenue. IBM and HP were more in the SAN game than Sun and SGI who let the customers configure systems themselves be used as storage (Sun was using VxFS for a long time, SGI had some CXFS things IIRC). Tru64 had a pretty interesting filesystem on paper, curious if you ever looked at its design since they open sourced it. Regards, Kevin From rminnich at gmail.com Wed Sep 5 00:22:02 2018 From: rminnich at gmail.com (ron minnich) Date: Tue, 4 Sep 2018 07:22:02 -0700 Subject: [TUHS] cat -v and other complaints In-Reply-To: References: <20180831215636.-eCEx%ca6c@bitmessage.ch> <20180903180401.u4MVs%ca6c@bitmessage.ch> <20180903181133.GB81368@wopr> <20180903185616.ZnkRk%ca6c@bitmessage.ch> Message-ID: On Tue, Sep 4, 2018 at 2:34 AM Andy Kosela wrote: > When Plan 9 was created in the mid-late 80s exactly those ideas > circulated. Nothing comes from nothing, everything has its historical > context. In the late 80s in order to "innovate" it was natural to think > that abandoning text terminals is a "progress". > > I don't get the sense, from reading this, that you have ever used Plan 9 for serious work, or indeed done more than see or run a demo. I'm keeping this short because this is TUHS, not T9HS. But your characterization of Plan 9 is just wrong. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gilles at gravier.org Wed Sep 5 03:39:00 2018 From: gilles at gravier.org (Gilles Gravier) Date: Tue, 4 Sep 2018 19:39:00 +0200 Subject: [TUHS] SunOS code? In-Reply-To: References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu> <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com> <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net> <20180901221933.GA2214@thunk.org> <20180902194301.GA22518@thunk.org> Message-ID: This link : https://vetusware.com/download/SunOS%20Source%20Code%204.1.3/?id=13475 seems to have the right file (registration required, but it's free, use a disposable email). Beats my having to find a SCSI adaptor, a QIC-150 drive, and trying to read my old QIC-150 tape with the source code on it... Gilles Le mar. 4 sept. 2018 à 13:48, Kevin Bowling a écrit : > On Sun, Sep 2, 2018 at 12:43 PM, Theodore Y. Ts'o wrote: > > On Sat, Sep 01, 2018 at 10:05:06PM -0700, Kevin Bowling wrote: > >> > >> Sorry this is just bogus about being weak compared to Solaris. Are > >> you looking back with rosy glasses or have you scanned the code in the > >> past couple years? I have and there is nothing particularly special > >> about Solaris internals here or elsewhere. > > > > I haven't looked at Solaris code; I had just *assumed* that if they > > were selling million dollar E10k's, they would have had NUMA support > > at *least* as good as SGI's Irix. And it would have been an excuse > > for their pathetic performance on UP and 2-4 SMP systems. > > One would hope so, but that was the strategy that got them eaten by a > grue. Another funny anecdote about this aloofness.. Linux on sparc64 > uses the Relaxed Memory Order mode that the hardware offers . > Solaris.. Total Store Order. There are tons of things like this in > the code that blow my mind. I would have been pissed if I were on the > hardware side of SPARC. > > > > >> Keep in mind IBM wants to sell RockHoppers and E980s (4 drawers, 16 > >> sockets, 768 threads) for dedicated Linux use which have similar > >> north/south and east/west off chip networks. They have a lot of very > >> talented people on the firmware, kernel, compilers to make these > >> things work fast, including Paul. > >> ... > >> Where you start going beyond Linux-like NUMA IMO is when you get > >> Irix-like features of page copying, migration, and multiple advanced > >> placement policies. > > > > One thing to consider is that IBM really only cared about optimizing > > hardware for DB2, Oracle, and Webshpere. That's one of the reason why > > you didn't see much in the way of innovative file system work, ala > > ZFS. There was no business justification for pouring 100+ engineer > > years to develop a next-generation file systesm --- and they had > > already done that once already for GPFS, a cluster file system. As > > far as local disk file system was concerned, the only real business > > value it had was to serve as a program loader for DB2 and Websphere. :-) > > > > (I'm exagerating a little for effect, but *only* a little.) > > Hmm, I think they've been pretty earnest at wanting to be 2+ years > ahead of the general market with POWER for as long as I can see, lots > of HPC money has been subsidizing that. Depends on the workload but > bus and memory bandwidth right now with PCIe Gen4 and NvLink can > really cut down on server sprawl. I've met with the GM/chief > architect and they see OpenPOWER positioned as a full frontal > competitor to Intel Xeon. I'm fairly disappointed in my > contemporaries for not recognizing the value of a completely open > source firmware and on chip controller stack; especially after the > recent snafu where Intel changed the microcode license to disallow > benchmarks and claimed it was an accident. > > Your statements make sense to me with respect to AIX, as Linux has > been the main effort since the 2000s. GPFS looks neat, I wish it were > open or at least internals documented well enough to study the > implementation academically. > > > > > So as far as NUMA was concerned, there was almost certainly not have > > been much perceived business value in having sophisticated > > auto-migration for arbitrary workloads in the kernel. Something basic > > which was good enough for Oracle, DB2, etc., was all that would be > > needed. (And if you needed to hire consultants from IBM Global > > Services to mind-meld with the configuration documentation in order to > > get the best out of your Rockhopper.... well, shucks, darn. :-) > > That's probably the dirty little secret. It's long been profitable to > carefully plan software interrupt handlers, user threads, and memory > allocation even on pedestrian servers if they are running a fixed > function. I guess Google's Borg and the new workalikes could do > semi-automagic things with cgroups these days. There is evidence of > people getting pretty crazy with it when we see things like Intel > cache allocation features. > > > At IBM the business people really did make the funding decisions of > > what to work on. ZFS could have never happened at IBM because no one > > would have thought that a even a tiny number of IBM's current or > > potential customer base would abandon AIX or Linux and switch to > > Solaris, or buy Sun hardware instead of IBM hardware --- just for the > > sake of ZFS. And that's how decision-makers at IBM really thought. > > (And to be fair to those decision-makers, IBM is still in business as > > a free-standing business --- and Sun is not.) > > Agreed, one of these companies is doing pretty well with a fat > dividend yield, that other has basically been dismantled for all but a > couple remaining desirable platform control points like Java and > MySQL. > > Many things in tech are happy accidents and a small number of > motivated people at the right place and time. A Sun engineer admitted > on some video I've seen that the green light was really given for ZFS > because they got stumped by some UFS bugs.. once enough of ZFS was > written to test the end to end checksumming features they found out > some of these heisenbugs were LSI HBA and disk firmware issues :o) > > Surveying some of these filesystems.. JFS2 is a decent, nowhere near > the capabilities of ZFS but even today it's not in dire need of > replacement.. I suspect another issue complementary to your point is > the standalone storage business is many $B of revenue. ESS/DS8000 and > the like are preferred revenue. IBM and HP were more in the SAN game > than Sun and SGI who let the customers configure systems themselves be > used as storage (Sun was using VxFS for a long time, SGI had some CXFS > things IIRC). Tru64 had a pretty interesting filesystem on paper, > curious if you ever looked at its design since they open sourced it. > > Regards, > Kevin > -- *Gilles Gravier* - Gilles at Gravier.org GSM : +33618347147 and +41794728437 Skype : ggravier | PGP Key : 0x8DE6D026 -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Wed Sep 5 03:45:37 2018 From: henry.r.bent at gmail.com (Henry Bent) Date: Tue, 4 Sep 2018 13:45:37 -0400 Subject: [TUHS] SunOS code? In-Reply-To: References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu> <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com> <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net> <20180901221933.GA2214@thunk.org> <20180902194301.GA22518@thunk.org> Message-ID: On Tue, Sep 4, 2018, 13:40 Gilles Gravier wrote: > This link : > https://vetusware.com/download/SunOS%20Source%20Code%204.1.3/?id=13475 > seems to have the right file (registration required, but it's free, use a > disposable email). > > Beats my having to find a SCSI adaptor, a QIC-150 drive, and trying to > read my old QIC-150 tape with the source code on it... > > Gilles > I feel like we've been through this before on this list, but perhaps it bears repeating: just because you can find source (or binaries, or CD images, etc.) on the internet, that doesn't make it the least bit legal. That is clearly the case here. Sadly, there are even higher profile sites like the Internet Archive that have this problem too. The concept of "abandonware" has no legal footing whatsoever. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Wed Sep 5 03:58:04 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 4 Sep 2018 13:58:04 -0400 (EDT) Subject: [TUHS] SunOS code? Message-ID: <20180904175804.06F7418C0CE@mercury.lcs.mit.edu> > From: Henry Bent > just because you can find source (or binaries, or CD images, etc.) on > the internet, that doesn't make it the least bit legal. ... The concept > of "abandonware" has no legal footing whatsoever. True; but if all the copies of a particular item are discarded, one can make all the lawyers on the planet as happy as clams, and it won't do a bit of good. Save the bits, _then_ work out the legal issues, is my thinking on priorities. Noel (PS: 'Internet' is spelled with a capital; there are many internets, but only one Internet, just as there are many white houses, but only one White House. If the technical community, which _does_ understand the difference, can't get it's act together, how can we expect the media, etc, to do the right thing?) From wkt at tuhs.org Wed Sep 5 06:33:11 2018 From: wkt at tuhs.org (Warren Toomey) Date: Wed, 5 Sep 2018 06:33:11 +1000 Subject: [TUHS] Saving the Unix Bits In-Reply-To: <20180904175804.06F7418C0CE@mercury.lcs.mit.edu> References: <20180904175804.06F7418C0CE@mercury.lcs.mit.edu> Message-ID: <20180904203311.GA21089@minnie.tuhs.org> On Tue, Sep 04, 2018 at 01:58:04PM -0400, Noel Chiappa wrote: > True; but if all the copies of a particular item are discarded, one can make > all the lawyers on the planet as happy as clams, and it won't do a bit of > good. Save the bits, _then_ work out the legal issues, is my thinking on > priorities. I'll also follow up on Henry and Noel's e-mail w.r.t the Unix Archive that TUHS provides. The only files in the public archive are ones where the legal issues have been resolved. I also keep a hidden archive of files where the legal issues have not been resolved. As always, if you would like me to keep an off-site backup of your Unix bits, the hidden Unix archive is write-only. Save the bits, and also be mindful of the legal issues. Cheers, Warren From clemc at ccc.com Wed Sep 5 06:39:36 2018 From: clemc at ccc.com (Clem Cole) Date: Tue, 4 Sep 2018 16:39:36 -0400 Subject: [TUHS] Saving the Unix Bits In-Reply-To: <20180904203311.GA21089@minnie.tuhs.org> References: <20180904175804.06F7418C0CE@mercury.lcs.mit.edu> <20180904203311.GA21089@minnie.tuhs.org> Message-ID: On Tue, Sep 4, 2018 at 4:34 PM Warren Toomey wrote: > On Tue, Sep 04, 2018 at 01:58:04PM -0400, Noel Chiappa wrote: > > True; but if all the copies of a particular item are discarded, one can > make > > all the lawyers on the planet as happy as clams, and it won't do a bit of > > good. Save the bits, _then_ work out the legal issues, is my thinking on > > priorities. > Amen!!! > > Save the bits, and also > be mindful of the legal issues. > Exactly -- we do need to be respectful of the legal issues. That is reality; but as Noel suggest and Warren has demonstrated -- a museum has to have the object in its posession, before you can argue who owns it ;-) Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pechter at gmail.com Wed Sep 5 06:53:43 2018 From: pechter at gmail.com (William Pechter) Date: Tue, 4 Sep 2018 16:53:43 -0400 Subject: [TUHS] Saving the Unix Bits In-Reply-To: <20180904203311.GA21089@minnie.tuhs.org> References: <20180904175804.06F7418C0CE@mercury.lcs.mit.edu> <20180904203311.GA21089@minnie.tuhs.org> Message-ID: One thing I'd like to see saved for the historical value is Pyramid OS/x. It was one of those things I'd have liked to see the internals of -- but I wasn't supposed to have that level accesss in Ed Services. It is an interesting mix of both the SysV and BSD environments and it's a shame it's probably completely gone now. I think the last work on it may have been at Siemens, since I think the last bit of Pyramid that was left was rumored to go to SVR4 (I was there for the DC/OSx transition -- I worked on the courseware fixes and beta testing). I heard from a friend that they may have gone to Solaris before the end hit. I think they were swallowed by Fujitsu. Amazingly, I heard some of my SVR4 courseware stuff ended up in illustrations used in Solaris courseware. My name was in the illustration of the password file. A trainer hired at least 5 years after me went to Sun and I hear some of my stuff went along for the ride. I long wished they had done the full Linux dual universe thing on a *BSD varient. I'd be running FreeBSD on my desktop if I could just watch Netflix with it. Linux, Windows and MacOS have enough pull for Google to port their Widevine Bill -- d|i|g|i|t|a|l had it THEN. Don't you wish you could still buy it now! pechter-at-gmail.com On Tue, Sep 4, 2018 at 4:34 PM Warren Toomey wrote: > On Tue, Sep 04, 2018 at 01:58:04PM -0400, Noel Chiappa wrote: > > True; but if all the copies of a particular item are discarded, one can > make > > all the lawyers on the planet as happy as clams, and it won't do a bit of > > good. Save the bits, _then_ work out the legal issues, is my thinking on > > priorities. > > I'll also follow up on Henry and Noel's e-mail w.r.t the Unix Archive that > TUHS provides. The only files in the public archive are ones where the > legal > issues have been resolved. I also keep a hidden archive of files where the > legal issues have not been resolved. > > As always, if you would like me to keep an off-site backup of your Unix > bits, the hidden Unix archive is write-only. Save the bits, and also > be mindful of the legal issues. > > Cheers, Warren > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Wed Sep 5 08:18:16 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Tue, 4 Sep 2018 16:18:16 -0600 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: <20180904085226.GA81023@bugle.employees.org> References: <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com> <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net> <6e3a87ce-f573-4258-9db5-a5f99b5b89b1.maildroid@localhost> <20180829202111.GA17007@minnie.tuhs.org> <20180904085226.GA81023@bugle.employees.org> Message-ID: On 09/04/2018 02:52 AM, Derek Fawcus wrote: > Last time I checked (in the UK) we can use any form of modulation or > encoding we want [*], as long as we record/log it, and don't use encryption. I think similar is the case here in the US too. The key being "encoding" and decidedly NOT "encryption". Further, you must make said encodings available to anyone and everyone that asks, including the F.C.C. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From dot at dotat.at Wed Sep 5 10:10:41 2018 From: dot at dotat.at (Tony Finch) Date: Wed, 5 Sep 2018 01:10:41 +0100 Subject: [TUHS] SunOS code? In-Reply-To: References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu> <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com> <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net> <20180901221933.GA2214@thunk.org> Message-ID: <2E7183C5-45CD-4F81-84FC-66EEDF4286A9@dotat.at> > On 2 Sep 2018, at 06:05, Kevin Bowling wrote: > > The E10k was only a 64-core machine on a tight backplane compared to > other large systems. It didn't have any of the pressing needs that > Sequent and SGI did with multi-drawer interconnects to drive > excellence in NUMA. When I started work at Cambridge in 2002 our central supercomputer was being replaced with a cluster of Sun Fire E15K machines with a fancy interconnect - it topped out at position 199 on the top500 list https://www.top500.org/list/2003/06/?page=2 with a 300 core configuration. It looks like they never managed to get the whole thing working as a single cluster since the other two thirds of the installation had positions 200 and 201! (The Nov. 2002 top500 list has it in 6 x 144 core shards.) Here’s a news item about it: https://www.cnet.com/news/sun-expands-supercomputer-effort/ > True. There is also at least one unencumbered strategy such as epoch > based reclamation which was known about around that time [2] > > [2] https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-579.pdf The big benchmarks in this lovely thesis were run on one of the E15K supercomputer boxes :-) Tony. -- f.anthony.n.finch http://dotat.at -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Wed Sep 5 13:39:40 2018 From: imp at bsdimp.com (Warner Losh) Date: Tue, 4 Sep 2018 21:39:40 -0600 Subject: [TUHS] Speaking of legality... Message-ID: I have a question... I'm trying to recreate "a" source representation of the Venix for Rainbow that I have. It's a v7 port, and I have all the .o's for it. Most of the .o's compile, with the proper compiler, to the same code that are in the .o's, at least judging from the .c file of the same name in the TUHS archive. The question is, what are the legal ramifications of publishing my reconstruction? Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Wed Sep 5 13:48:05 2018 From: wkt at tuhs.org (Warren Toomey) Date: Wed, 5 Sep 2018 13:48:05 +1000 Subject: [TUHS] Speaking of legality... In-Reply-To: References: Message-ID: <20180905034805.GA23662@minnie.tuhs.org> On Tue, Sep 04, 2018 at 09:39:40PM -0600, Warner Losh wrote: > I'm trying to recreate "a" source representation of the Venix for > Rainbow that I have. It's a v7 port, and I have all the .o's for it. > Most of the .o's compile, with the proper compiler, to the same code > that are in the .o's, at least judging from the .c file of the same > name in the TUHS archive. > The question is, what are the legal ramifications of publishing my > reconstruction? Good question. IANAL of course. Obviously, it's a port of V7 and the vanilla V7 is now under a free license. So I would guess that you only have to worry about the files in Venix which are different: drivers etc. Cheers, Warren From erc at pobox.com Wed Sep 5 15:17:47 2018 From: erc at pobox.com (Ed Carp) Date: Tue, 4 Sep 2018 22:17:47 -0700 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: References: <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com> <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net> <6e3a87ce-f573-4258-9db5-a5f99b5b89b1.maildroid@localhost> <20180829202111.GA17007@minnie.tuhs.org> Message-ID: I just put the TNC into transparent mode and let the Linux boxes talk to each other via UUCP. I guess I could've used KISS, but it was a quick-and-dirty hack so I could read email from my laptop in bed :) On 9/3/18, Dave Horsfall wrote: > On Mon, 3 Sep 2018, Ed Carp wrote: > >> Wow, that takes me back quite a ways. I think I've still got my UUCP >> setup somewhere on a backup. UUCP works great over anything from ssh >> over tcpip to 1200 baud half-duplex packet connections. > > If you're referring to "Amateur" i.e. "ham radio" packet radio than yes, > I'm told that it works great i.e. half-duplex -> large data -> short ACK. > >> Fond memories. > > Heh heh - I once ran *raw* Xmodem over packet i.e. not encapsulated in > that protocol-from-hell AX.25 i.e. technically illegal[*]; it worked great > until a packet was lost (the "hidden transmitter" problem) and the various > timeouts concerned (Xmodem vs. the TNCs themselves) went completely > pear-shaped... > > [*] > > Stuff the legality; isn't Amateur radio all about experimentation? But we > did announce on that frequency that we were about to conduct an > experiment. And whoever designed AX.25 (yes, I have studied it in great > detail) must've been on something at the time... Protocol layers? > What's that? > > -- Dave (VK2KFU) > From gilles at gravier.org Wed Sep 5 16:31:52 2018 From: gilles at gravier.org (Gilles Gravier) Date: Wed, 5 Sep 2018 08:31:52 +0200 Subject: [TUHS] SunOS code? In-Reply-To: References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu> <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com> <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net> <20180901221933.GA2214@thunk.org> <20180902194301.GA22518@thunk.org> Message-ID: (Henri, you're in copy of this again, because first time I did a Reply instead of Reply to list/all. Sorry.) Le mar. 4 sept. 2018 à 19:45, Henry Bent a écrit : > > > On Tue, Sep 4, 2018, 13:40 Gilles Gravier wrote: > >> This link : >> https://vetusware.com/download/SunOS%20Source%20Code%204.1.3/?id=13475 >> seems to have the right file (registration required, but it's free, use a >> disposable email). >> >> Beats my having to find a SCSI adaptor, a QIC-150 drive, and trying to >> read my old QIC-150 tape with the source code on it... >> >> Gilles >> > > I feel like we've been through this before on this list, but perhaps it > bears repeating: just because you can find source (or binaries, or CD > images, etc.) on the internet, that doesn't make it the least bit legal. > That is clearly the case here. Sadly, there are even higher profile sites > like the Internet Archive that have this problem too. The concept of > "abandonware" has no legal footing whatsoever. > > -Henry > Oh I definitely know the sources aren't officially accessible. By the way, I had copies of them (my QIC tape) when I was a student. I still have the QIC. It's the common example that I use to tell people that opensourcing software makes it more secure because the good guys have access to the source code at the same time as the bad guys, which gives them a fair chance to fix bugs before the bad guys use them. With closed source (SunOS, VMS...) the good guys don't have access to the source code... but the bad guys will always (either by paying somebody enough to make a copy for them, or by finding them on some non legitimate place). As a student I had the source of SunOS (4.1.3) but also VMS (on a few TK-50 tapes). For me, that vetusware site is certainly not legitimate... but since I have the QIC tape at home, I just used it as an easy alternative to having to get the hardware to read my tape back in working order... I certainly do not consider it a legally approved way of distributing code which is, as we all agree, NOT open source. Gilles -- *Gilles Gravier* - Gilles at Gravier.org GSM : +33618347147 and +41794728437 Skype : ggravier | PGP Key : 0x8DE6D026 -------------- next part -------------- An HTML attachment was scrubbed... URL: From krewat at kilonet.net Wed Sep 5 22:55:02 2018 From: krewat at kilonet.net (Arthur Krewat) Date: Wed, 5 Sep 2018 08:55:02 -0400 Subject: [TUHS] SunOS code? In-Reply-To: References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu> <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com> <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net> <20180901221933.GA2214@thunk.org> <20180902194301.GA22518@thunk.org> Message-ID: On 9/5/2018 2:31 AM, Gilles Gravier wrote: > It's the common example that I use to tell people that opensourcing > software makes it more secure because the good guys have access to the > source code at the same time as the bad guys, which gives them a fair > chance to fix bugs before the bad guys use them. Bash/Shellshock kinda proves that premise incorrect, although it's pretty much the worst-case example, but still...  ;) Announced in 2014, it goes back to September 1989 (according to a wikipedia article, so I'm not sure about that date's accuracy). https://en.wikipedia.org/wiki/Shellshock_(software_bug) https://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33 https://www.cvedetails.com/product/17/IBM-AIX.html?vendor_id=14 https://www.cvedetails.com/product/20/HP-Hp-ux.html?vendor_id=10 https://www.cvedetails.com/product/19755/Oracle-Solaris.html?vendor_id=93 It could be argued that the above CVE results are either under-reported (closed-source), or over-reported (open-source). Or vice-versa ;) ak From norman at oclsc.org Thu Sep 6 01:04:41 2018 From: norman at oclsc.org (Norman Wilson) Date: Wed, 05 Sep 2018 11:04:41 -0400 Subject: [TUHS] Cryptic Unix Commands Message-ID: <1536159885.28857.for-standards-violators@oclsc.org> Ron Natalie: I use the numbers but I think it stems from the days when kill didn't take the names. It's easier for me to remember -1 and -9 than to remember what the mnemonics are. ==== Me too. And not just the kill command; the (real) shell's trap command too. It's all just muscle memory, not a desire to save keystrokes. On the rare occasions when I need to send a post-modern signal like SIGSTOP or SIGCONT, I use the name. As an aside, why do modern kill and sh accept only the abbreviated form of the signal name, not the full name; e.g. kill -STOP is OK, kill -SIGSTOP an error? When we taught kill about that sometime in (I think) the 9th Edition era at Research, we allowed either form. I think it was Doug who insisted on it, and he was right. All this applies to shell commands, not to programs. It is just plain wrong to code kill(9, pid) in C. Norman Wilson Toronto ON From imp at bsdimp.com Thu Sep 6 01:26:52 2018 From: imp at bsdimp.com (Warner Losh) Date: Wed, 5 Sep 2018 09:26:52 -0600 Subject: [TUHS] SunOS code? In-Reply-To: References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu> <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com> <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net> <20180901221933.GA2214@thunk.org> <20180902194301.GA22518@thunk.org> Message-ID: On Wed, Sep 5, 2018 at 6:55 AM Arthur Krewat wrote: > > > On 9/5/2018 2:31 AM, Gilles Gravier wrote: > > It's the common example that I use to tell people that opensourcing > > software makes it more secure because the good guys have access to the > > source code at the same time as the bad guys, which gives them a fair > > chance to fix bugs before the bad guys use them. > > > Bash/Shellshock kinda proves that premise incorrect, although it's > pretty much the worst-case example, but still... ;) > I'm not sure it does. It proves that bugs aren't instantly found, true. It doesn't provide perfection, but does make it easier to find / fix bugs before the bad guys. How long would such a bug have languished it if were buried inside of DCL.B32 instead of being out in the open? Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From chet.ramey at case.edu Thu Sep 6 01:42:09 2018 From: chet.ramey at case.edu (Chet Ramey) Date: Wed, 5 Sep 2018 11:42:09 -0400 Subject: [TUHS] Cryptic Unix Commands In-Reply-To: <1536159885.28857.for-standards-violators@oclsc.org> References: <1536159885.28857.for-standards-violators@oclsc.org> Message-ID: <8a4c50b5-bd1f-3778-5166-a0a886a59e31@case.edu> On 9/5/18 11:04 AM, Norman Wilson wrote: > As an aside, why do modern kill and sh accept only the > abbreviated form of the signal name, not the full name; > e.g. kill -STOP is OK, kill -SIGSTOP an error? It's the standard: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/kill.html#tag_20_64 "Historical versions of kill have not written the SIG prefix for the -l option and have not recognized the SIG prefix on signal_names." http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_28 "Implementations may also accept the names with the SIG prefix; no known historical shell does so." -- ``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 chet.ramey at case.edu Thu Sep 6 01:36:48 2018 From: chet.ramey at case.edu (Chet Ramey) Date: Wed, 5 Sep 2018 11:36:48 -0400 Subject: [TUHS] SunOS code? In-Reply-To: References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu> <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com> <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net> <20180901221933.GA2214@thunk.org> <20180902194301.GA22518@thunk.org> Message-ID: <3960b738-0939-d43d-e8b3-4454954f31a9@case.edu> On 9/5/18 11:26 AM, Warner Losh wrote: > On 9/5/2018 2:31 AM, Gilles Gravier wrote: > > It's the common example that I use to tell people that opensourcing > > software makes it more secure because the good guys have access to the > > source code at the same time as the bad guys, which gives them a fair > > chance to fix bugs before the bad guys use them. > > > Bash/Shellshock kinda proves that premise incorrect, although it's > pretty much the worst-case example, but still...  ;) > > > I'm not sure it does. It proves that bugs aren't instantly found, true. It > doesn't provide perfection, but does make it easier to find / fix bugs > before the bad guys. How long would such a bug have languished it if were > buried inside of DCL.B32 instead of being out in the open? It proves that if there is someone who has an idea, or who thinks about a thing in new ways, he can verify his suspicions without too much trouble. The barrier to investigation is lowered. Chet -- ``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 Thu Sep 6 01:43:53 2018 From: krewat at kilonet.net (Arthur Krewat) Date: Wed, 5 Sep 2018 11:43:53 -0400 Subject: [TUHS] SunOS code? In-Reply-To: References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu> <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com> <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net> <20180901221933.GA2214@thunk.org> <20180902194301.GA22518@thunk.org> Message-ID: On 9/5/2018 11:26 AM, Warner Losh wrote: > > I'm not sure it does. It proves that bugs aren't instantly found, > true. It doesn't provide perfection, but does make it easier to find / > fix bugs before the bad guys. How long would such a bug have > languished it if were buried inside of DCL.B32 instead of being out in > the open? It depends on how it was found in the first place. A quick Google doesn't tell me much about exactly how it was discovered initially. Nor is there any background information that says it wasn't (or was) exploited before the announcement. Was it discovered because someone (Stéphane Chazelas) was just reading open source code? Or was he trying to do something innocent and it broke in such a way that it was obvious bash was doing something bad? Or was he investigating a break-in and found the vector? Serious questions, I'd love to hear from anyone who knows more. My original point remains: Open Source doesn't necessarily mean more secure if a really bad exploit was allowed to exist for 25 years. No offense intended to anyone on this list. ak From jnc at mercury.lcs.mit.edu Thu Sep 6 01:44:35 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 5 Sep 2018 11:44:35 -0400 (EDT) Subject: [TUHS] Cryptic Unix Commands Message-ID: <20180905154435.103E118C0A0@mercury.lcs.mit.edu> > From: Norman Wilson > It is just plain wrong to code > kill(9, pid) _All_ uses of magic numbers in numeric form are wrong! Noel From jpl.jpl at gmail.com Thu Sep 6 02:12:15 2018 From: jpl.jpl at gmail.com (John P. Linderman) Date: Wed, 5 Sep 2018 12:12:15 -0400 Subject: [TUHS] Cryptic Unix Commands In-Reply-To: <20180905154435.103E118C0A0@mercury.lcs.mit.edu> References: <20180905154435.103E118C0A0@mercury.lcs.mit.edu> Message-ID: On Wed, Sep 5, 2018 at 11:44 AM, Noel Chiappa wrote: > > From: Norman Wilson > > > It is just plain wrong to code > > kill(9, pid) > > _All_ uses of magic numbers in numeric form are wrong! > > Noel > I completely agree, although you can do worse. A junior programmer I worked with at MIT wrote (in IBM assembler) twelv dc 10 (I probably have the syntax wrong, but he was declaring the value of symbolic name 'twelv' to be 10). I have no idea why he did this. He didn't last long. -------------- next part -------------- An HTML attachment was scrubbed... URL: From khm at sciops.net Thu Sep 6 02:45:37 2018 From: khm at sciops.net (Kurt H Maier) Date: Wed, 5 Sep 2018 09:45:37 -0700 Subject: [TUHS] Cryptic Unix Commands In-Reply-To: <20180905154435.103E118C0A0@mercury.lcs.mit.edu> References: <20180905154435.103E118C0A0@mercury.lcs.mit.edu> Message-ID: <20180905164537.GA81179@wopr> On Wed, Sep 05, 2018 at 11:44:35AM -0400, Noel Chiappa wrote: > > From: Norman Wilson > > > It is just plain wrong to code > > kill(9, pid) > > _All_ uses of magic numbers in numeric form are wrong! > > Noel https://www.boost.org/doc/libs/1_68_0/boost/utility/binary.hpp khm From clemc at ccc.com Thu Sep 6 05:17:22 2018 From: clemc at ccc.com (Clem Cole) Date: Wed, 5 Sep 2018 15:17:22 -0400 Subject: [TUHS] Speaking of legality... In-Reply-To: <20180905034805.GA23662@minnie.tuhs.org> References: <20180905034805.GA23662@minnie.tuhs.org> Message-ID: On Tue, Sep 4, 2018 at 11:48 PM Warren Toomey wrote: > On Tue, Sep 04, 2018 at 09:39:40PM -0600, Warner Losh wrote: > > I'm trying to recreate "a" source representation of the Venix for > > Rainbow that I have. It's a v7 port, and I have all the .o's for it. > > Most of the .o's compile, with the proper compiler, to the same code > > that are in the .o's, at least judging from the .c file of the same > > name in the TUHS archive. > > The question is, what are the legal ramifications of publishing my > > reconstruction? > > Good question. IANAL of course. Obviously, it's a port of V7 and the > vanilla V7 is now under a free license. So I would guess that you only > have to worry about the files in Venix which are different: drivers etc. > > Right, but the AT&T parts you need to be sure to attribute them, ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Thu Sep 6 05:37:07 2018 From: imp at bsdimp.com (Warner Losh) Date: Wed, 5 Sep 2018 13:37:07 -0600 Subject: [TUHS] Speaking of legality... In-Reply-To: References: <20180905034805.GA23662@minnie.tuhs.org> Message-ID: On Wed, Sep 5, 2018 at 1:17 PM Clem Cole wrote: > > > On Tue, Sep 4, 2018 at 11:48 PM Warren Toomey wrote: > >> On Tue, Sep 04, 2018 at 09:39:40PM -0600, Warner Losh wrote: >> > I'm trying to recreate "a" source representation of the Venix for >> > Rainbow that I have. It's a v7 port, and I have all the .o's for it. >> > Most of the .o's compile, with the proper compiler, to the same code >> > that are in the .o's, at least judging from the .c file of the same >> > name in the TUHS archive. >> > The question is, what are the legal ramifications of publishing my >> > reconstruction? >> >> Good question. IANAL of course. Obviously, it's a port of V7 and the >> vanilla V7 is now under a free license. So I would guess that you only >> have to worry about the files in Venix which are different: drivers etc. >> >> Right, but the AT&T parts you need to be sure to attribute them, > > Of course... Warner > ᐧ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dds at aueb.gr Thu Sep 6 07:31:15 2018 From: dds at aueb.gr (Diomidis Spinellis) Date: Thu, 6 Sep 2018 00:31:15 +0300 Subject: [TUHS] Usenix: no official Unix 50th celebration, apparently In-Reply-To: <20180826041046.GA3176@thunk.org> References: <20180826003127.GA18905@minnie.tuhs.org> <20180826041046.GA3176@thunk.org> Message-ID: <53afe3bc-b775-154b-b764-7bc6ac4769ec@aueb.gr> On 26/08/2018 07:10, Theodore Y. Ts'o wrote: [...] > The question I would raise is whether some kind of 50th celebration > has to be colocated with Usenix ATC, especially if the Usenix BoD is > not innterested in lending much in the way of financial or staff > support. For example, maybe something combined with some kind of > fund-raising event held at the Compute History Museum in the Bay Area? > > Or perhaps the Linux Foundation might be willing to do a Unix 50th > celebration at their 2019 Open Source Summit event? > > It does seem to me that Usenix ought to have the right of first > refusal to host such a celebration, but if the Board isn't willing to > step it up, there are other possibilities that could be explored. One possibility might be to propose a "50th Unix Anniversary" Developer Room at FOSDEM 2019 [1]. FOSDEM is a free event for software developers to meet, share ideas and collaborate. It takes place every year with thousands of developers of free and open source software from all over the world gathering in Brussels. Our room can be used to host presentations related to topics such as the Unix history, the 50th anniversary, and the reconstruction efforts of historic editions. The many *BSD and Linux folks that attend FOSDEM together with thousands of other open source aficionados provide an excellent audience for our event. We can also combine the presentations with a TUHS stand where we can display running historic software. The deadline for room proposals is September 20th and for stands November 2nd [2]. FOSDEM is entirely organized by volunteers and attendance is free without registration. We don't have to pay anything for the room and the stand, but we also can't expect any funding from the organizers for flying people in. [1] https://fosdem.org/2019/ [2] https://fosdem.org/2019/news/2018-08-10-call-for-participation/ Diomidis From dave at horsfall.org Thu Sep 6 09:40:30 2018 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 6 Sep 2018 09:40:30 +1000 (EST) Subject: [TUHS] SunOS code? In-Reply-To: References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu> <20180831213451.r7LAj%ca6c@bitmessage.ch> <20180831215854.GB28971@mcvoy.com> <7ed51612-82d7-90ca-ceaf-37b0c869ff93@kilonet.net> <20180901221933.GA2214@thunk.org> <20180902194301.GA22518@thunk.org> Message-ID: On Wed, 5 Sep 2018, Gilles Gravier wrote: > (Henri, you're in copy of this again, because first time I did a Reply > instead of Reply to list/all. Sorry.) One of my pet hates is people who use "Reply All" because either they are too lazy to edit the Reply (and they top-post, too), or the list is set up that way. I really don't need my own personal copy, as well as a list copy. Oh, and people who are too lazy to trim their replies too, because they are encouraged to top-post. -- Dave From clemc at ccc.com Thu Sep 6 10:23:27 2018 From: clemc at ccc.com (Clem cole) Date: Wed, 5 Sep 2018 20:23:27 -0400 Subject: [TUHS] Usenix: no official Unix 50th celebration, apparently In-Reply-To: <53afe3bc-b775-154b-b764-7bc6ac4769ec@aueb.gr> References: <20180826003127.GA18905@minnie.tuhs.org> <20180826041046.GA3176@thunk.org> <53afe3bc-b775-154b-b764-7bc6ac4769ec@aueb.gr> Message-ID: <778C65CA-0447-41F0-8F6F-3E3277CFA847@ccc.com> I’ll ok into it. Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > On Sep 5, 2018, at 5:31 PM, Diomidis Spinellis wrote: > >> On 26/08/2018 07:10, Theodore Y. Ts'o wrote: >> [...] >> The question I would raise is whether some kind of 50th celebration >> has to be colocated with Usenix ATC, especially if the Usenix BoD is >> not innterested in lending much in the way of financial or staff >> support. For example, maybe something combined with some kind of >> fund-raising event held at the Compute History Museum in the Bay Area? >> Or perhaps the Linux Foundation might be willing to do a Unix 50th >> celebration at their 2019 Open Source Summit event? >> It does seem to me that Usenix ought to have the right of first >> refusal to host such a celebration, but if the Board isn't willing to >> step it up, there are other possibilities that could be explored. > > One possibility might be to propose a "50th Unix Anniversary" Developer Room at FOSDEM 2019 [1]. FOSDEM is a free event for software developers to meet, share ideas and collaborate. It takes place every year with thousands of developers of free and open source software from all over the world gathering in Brussels. > > Our room can be used to host presentations related to topics such as the Unix history, the 50th anniversary, and the reconstruction efforts of historic editions. The many *BSD and Linux folks that attend FOSDEM together with thousands of other open source aficionados provide an excellent audience for our event. We can also combine the presentations with a TUHS stand where we can display running historic software. > > The deadline for room proposals is September 20th and for stands November 2nd [2]. FOSDEM is entirely organized by volunteers and attendance is free without registration. We don't have to pay anything for the room and the stand, but we also can't expect any funding from the organizers for flying people in. > > [1] https://fosdem.org/2019/ > [2] https://fosdem.org/2019/news/2018-08-10-call-for-participation/ > > Diomidis From dave at horsfall.org Thu Sep 6 10:39:18 2018 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 6 Sep 2018 10:39:18 +1000 (EST) Subject: [TUHS] SunOS code? In-Reply-To: <20180904175804.06F7418C0CE@mercury.lcs.mit.edu> References: <20180904175804.06F7418C0CE@mercury.lcs.mit.edu> Message-ID: On Tue, 4 Sep 2018, Noel Chiappa wrote: > (PS: 'Internet' is spelled with a capital; there are many internets, but > only one Internet, just as there are many white houses, but only one > White House. If the technical community, which _does_ understand the > difference, can't get it's act together, how can we expect the media, > etc, to do the right thing?) Thank you. Thank you. Thank you. At every technical lecture I do, I insist upon Internet, but the younger generation these days think that they invented it because of Google browsing etc. -- Dave, in a grouchy mood having having three teeth pulled out From dave at horsfall.org Thu Sep 6 10:48:19 2018 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 6 Sep 2018 10:48:19 +1000 (EST) Subject: [TUHS] Saving the Unix Bits In-Reply-To: <20180904203311.GA21089@minnie.tuhs.org> References: <20180904175804.06F7418C0CE@mercury.lcs.mit.edu> <20180904203311.GA21089@minnie.tuhs.org> Message-ID: On Wed, 5 Sep 2018, Warren Toomey wrote: > As always, if you would like me to keep an off-site backup of your Unix > bits, the hidden Unix archive is write-only. Save the bits, and also be > mindful of the legal issues. It is really important that Unix history is preserved, lest the revisionists (they start with an "L") take over. Disclaimer: I have a hidden archive of some of the "naughty" bits. -- Dave From erc at pobox.com Thu Sep 6 12:11:22 2018 From: erc at pobox.com (Ed Carp) Date: Wed, 5 Sep 2018 19:11:22 -0700 Subject: [TUHS] RetroNet??? In-Reply-To: <83698bdc-c636-5688-5619-27c8c4b41500@spamtrap.tnetconsulting.net> References: <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com> <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net> <20180829183632.GD8423@mcvoy.com> <83698bdc-c636-5688-5619-27c8c4b41500@spamtrap.tnetconsulting.net> Message-ID: I've read that Taylor UUCP fixed a bunch of issues with HDB UUCP - have you considered using it? On 8/29/18, Grant Taylor via TUHS wrote: > On 08/29/2018 01:28 PM, Arrigo Triulzi wrote: >> Have you considered asking Peter Honeyman if he wishes to collaborate >> in the UUCP project (the “Honey” in HoneyDanBer UUCP)? > > I hadn't thought about it. > > Please reply to me directly / off list with contact information if you > have it and I'll happily send him an email. > > > > -- > Grant. . . . > unix || die > > From grog at lemis.com Thu Sep 6 13:21:09 2018 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Thu, 6 Sep 2018 13:21:09 +1000 Subject: [TUHS] Mail etiquette (was: SunOS code?) In-Reply-To: References: <20180901221933.GA2214@thunk.org> <20180902194301.GA22518@thunk.org> Message-ID: <20180906032109.GC76566@eureka.lemis.com> On Thursday, 6 September 2018 at 9:40:30 +1000, Dave Horsfall wrote: > On Wed, 5 Sep 2018, Gilles Gravier wrote: > >> (Henri, you're in copy of this again, because first time I did a Reply >> instead of Reply to list/all. Sorry.) > > One of my pet hates is people who use "Reply All" because either they are > too lazy to edit the Reply (and they top-post, too), or the list is set up > that way. That's a matter of opinion. Many people consider it good manners to specifically mention people participating in a discussion. For example, https://www.freebsd.org/doc/en_US.ISO8859-1/articles/freebsd-questions/article.html#idp53204040 specifically states: Unless there is a good reason to do otherwise, reply to the sender and to FreeBSD-questions [the list]. > I really don't need my own personal copy, as well as a list copy. That's what procmail is for. > Oh, and people who are too lazy to trim their replies too, because > they are encouraged to top-post. Yes, that's in that URL too: Put your response in the correct place (after the text to which it replies). It is very difficult to read a thread of responses where each reply comes before the text to which it replies. Also another thing that I still think very important: If the submitter did not abide by format conventions (lines too long, inappropriate subject line), please fix it. In the case of an incorrect subject line (such as “HELP!!??”), change the subject line to (say) “Re: Difficulties with sync PPP (was: HELP!!??)”. That way other people trying to follow the thread will have less difficulty following it. That doesn't explicitly address the issue of change of topic within a thread, but it should. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From gtaylor at tnetconsulting.net Thu Sep 6 15:07:00 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 5 Sep 2018 23:07:00 -0600 Subject: [TUHS] RetroNet??? In-Reply-To: References: <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com> <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net> <20180829183632.GD8423@mcvoy.com> <83698bdc-c636-5688-5619-27c8c4b41500@spamtrap.tnetconsulting.net> Message-ID: <55496B84-3FA8-4921-A524-A3513D611327@tnetconsulting.net> On Sep 5, 2018, at 8:11 PM, Ed Carp wrote: > I've read that Taylor UUCP fixed a bunch of issues with HDB UUCP - > have you considered using it? Taylor UUCP (no known relationship) is the default on every Linux distribution (including Cygwin) that I’ve used. Thus it’s the bulk of what I’ve used. I feel like TUHS is a good place to learn about the differences. I’d be interested in anything (history, gotchas, pro tips, lore, etc., that people have to offer. #learningisfun -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2338 bytes Desc: not available URL: From clemc at ccc.com Fri Sep 7 04:22:05 2018 From: clemc at ccc.com (Clem Cole) Date: Thu, 6 Sep 2018 14:22:05 -0400 Subject: [TUHS] RetroNet??? In-Reply-To: References: <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com> <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net> <20180829183632.GD8423@mcvoy.com> <83698bdc-c636-5688-5619-27c8c4b41500@spamtrap.tnetconsulting.net> Message-ID: On Wed, Sep 5, 2018 at 10:12 PM Ed Carp wrote: > I've read that Taylor UUCP fixed a bunch of issues with HDB UUCP - > have you considered using it? > Hmmm.. the only thing it really fixed was the licensing. HBD was part of distributed in the 'toolkit' and as part of Svs V. I think it was part of PWB 3.0, as we shipped it with RTU; but we have have gotten it via the toolkit license [I'm too lazy to look at Warren's System files to check]. HDB was the huge fix of the original version that went 'wide' with V7 and BSD. The primary changes were in house directories and the queues were handled, which had huge performance impact; particularly for large sites with an heavy UUCPnet load (a.k.a. the 'Usenet'). The other things that was in HDB was some collected alternate protocols besides Greg Chesson's original 'g' protocol; although those had all been distributed on the Usenet as net.noise, so all it really did is become a packaging thing. There were a number of UUCP clones written in those days, and PC-uucp was popular for CP/M and later DOS systems that wanted to join the Usenet [Rick Adams, I think had a packaged version of some of them for his non-UNIX customers IIRC). As to why Dave Taylor decided to write another one in thoses, you'ld have to ask him; but in the end it replaced the V7 one in BSD. But a lot of effort was made to make sure Taylor UUCP was more than a functional work-alike. It had admin like HBD and use the same queues etc. What I do not remember, Mary Ann might, is if Berkeley had been running HDB from the Toolkit on ucbvax internally, but could not have easily redistribute it ( seem to remember there were). They funny part is that most Academics had a toolkit license by then becsuse they wanted HDB and ksh as a minimum, so most were running HDB; but the rules in the toolkit for academics were different than the original base license (I've forgotten them -- I had left academia so it did not effect me). But it was around this time the Keith was start to try to remove code that was knows to have AT&T copyright issues, when their was an alternative implementation that had BSD style licenses (which Taylor UUCP, as did Clark's troff as I recall). BTW Grant, Linux picked up Taylor UUCP after BSD (it was not in the original distros and I suspect would have crashed the kernel in those days if the site was as all loaded). ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From akosela at andykosela.com Fri Sep 7 06:02:06 2018 From: akosela at andykosela.com (Andy Kosela) Date: Thu, 06 Sep 2018 22:02:06 +0200 Subject: [TUHS] cat -v and other complaints In-Reply-To: References: <20180831215636.-eCEx%ca6c@bitmessage.ch> <20180903180401.u4MVs%ca6c@bitmessage.ch> <20180903181133.GB81368@wopr> <20180903185616.ZnkRk%ca6c@bitmessage.ch> Message-ID: <5b9187be.JqdXbAJqb0gb8I/y%akosela@andykosela.com> ron minnich wrote: > On Tue, Sep 4, 2018 at 2:34 AM Andy Kosela wrote: > > > When Plan 9 was created in the mid-late 80s exactly those ideas > > circulated. Nothing comes from nothing, everything has its historical > > context. In the late 80s in order to "innovate" it was natural to think > > that abandoning text terminals is a "progress". > > > > > I don't get the sense, from reading this, that you have ever used Plan 9 > for serious work, or indeed done more than see or run a demo. I'm keeping > this short because this is TUHS, not T9HS. But your characterization of > Plan 9 is just wrong. I understand that we are drifting a bit off-topic here, but for the sake of all reading it, it probably would be relevant to at least offer some more explanation of your point. Saying 'you are wrong' is not very informative. I still think that you just misinterpret my words though. One still cannot ignore the fact that Unix and Plan 9 offer two completely different approaches to displaying text. I think it also would not be very productive nor it was intended to use Plan 9 without mouse and rio(1). --Andy From norman at oclsc.org Fri Sep 7 06:29:36 2018 From: norman at oclsc.org (Norman Wilson) Date: Thu, 06 Sep 2018 16:29:36 -0400 Subject: [TUHS] cat -v and other complaints Message-ID: <1536265780.5213.for-standards-violators@oclsc.org> Andy Kosela: One still cannot ignore the fact that Unix and Plan 9 offer two completely different approaches to displaying text. I admit I've never actually used Plan 9. Can you elaborate on the different approaches? One difference from most of what passes for UNIX these days is probably that the basic terminal model allows one to edit anything on the screen, using the mouse and keyboard and a simple button-2 menu similar to that of sam. You can edit what some program has already printed, then pick it up and send it back as input. You can even edit text in the current line that hasn't been sent yet (because you haven't hit a return yet); in effect the canonical-line part of the tty driver is in the terminal. But you probably don't mean that, both because it's not really such a radical difference, and because it doesn't conflict at all with UNIX. In fact it originated on UNIX, five or six years before Plan 9 was thought of: it's the model from the terminal program in mux, the more-advanced version of the Blit/Jerq window manager that nearly everybody used in 1127 by the time I arrived in 1984. And I still use it every day, even on Linux (and in years past on Solaris and IRIX and Digital UNIX and Ultrix). The modern version of the program to do that is called 9term. It doesn't work quite as well as I'd like on Linux due to changes in the tty driver that make it hard for a program to learn right away when tty modes are changed (in particular when echo is turned off or on), and it does conflict with the GNU readline junk because that turns off canonical processing, but to those of us who have a taste for it it's still just fine. As I say, I don't think that's the difference you mean, so please step in and supersede me. (And feel free to use my referring to something that is part of the latter-day Research editions as an excuse to continue discussing it. I think of Plan 9 as a successor to those systems anyway, and therefore related to UNIX heritage, at least as long as we're comparing and contrasting the systems.) Norman Wilson Toronto ON From rminnich at gmail.com Fri Sep 7 06:49:57 2018 From: rminnich at gmail.com (ron minnich) Date: Thu, 6 Sep 2018 13:49:57 -0700 Subject: [TUHS] cat -v and other complaints In-Reply-To: <5b9187be.JqdXbAJqb0gb8I/y%akosela@andykosela.com> References: <20180831215636.-eCEx%ca6c@bitmessage.ch> <20180903180401.u4MVs%ca6c@bitmessage.ch> <20180903181133.GB81368@wopr> <20180903185616.ZnkRk%ca6c@bitmessage.ch> <5b9187be.JqdXbAJqb0gb8I/y%akosela@andykosela.com> Message-ID: On Thu, Sep 6, 2018 at 1:02 PM Andy Kosela wrote: > One still cannot ignore the fact that Unix and Plan 9 offer two > completely different approaches to displaying text. I think it also > would not be very productive nor it was intended to use Plan 9 without > mouse and rio(1). > I spent four years using Plan 9 on the Blue Gene supercomputer (I led the team that did the port). I also spent years using it on embedded systems with no windowing system at all. What you're saying does not accord with anything I experienced with Plan 9 over a dozen year span. I also don't believe your claims are driven by experience using Plan 9; am I missing something? What is the basis of your statement? -------------- next part -------------- An HTML attachment was scrubbed... URL: From akosela at andykosela.com Fri Sep 7 07:55:52 2018 From: akosela at andykosela.com (Andy Kosela) Date: Thu, 06 Sep 2018 23:55:52 +0200 Subject: [TUHS] cat -v and other complaints In-Reply-To: References: <20180831215636.-eCEx%ca6c@bitmessage.ch> <20180903180401.u4MVs%ca6c@bitmessage.ch> <20180903181133.GB81368@wopr> <20180903185616.ZnkRk%ca6c@bitmessage.ch> <5b9187be.JqdXbAJqb0gb8I/y%akosela@andykosela.com> Message-ID: <5b91a268.lXqMJkXVvoGUv0XA%akosela@andykosela.com> ron minnich wrote: > On Thu, Sep 6, 2018 at 1:02 PM Andy Kosela wrote: > > > One still cannot ignore the fact that Unix and Plan 9 offer two > > completely different approaches to displaying text. I think it also > > would not be very productive nor it was intended to use Plan 9 without > > mouse and rio(1). > > > > I spent four years using Plan 9 on the Blue Gene supercomputer (I led the > team that did the port). I also spent years using it on embedded systems > with no windowing system at all. > > What you're saying does not accord with anything I experienced with Plan 9 > over a dozen year span. I also don't believe your claims are driven by > experience using Plan 9; am I missing something? What is the basis of your > statement? Just from personal experience running Plan 9. Well, you can't tell me this system was designed with the idea of running it using text terminal and no mouse. There is also no cursor addressing, no curses. Like I written before it was born in the different era -- they tried to not build it on the idea of character based TTY, but rather incorporate graphical element into it. If it is possible to be fully productive in Plan 9 using just VGA text mode (720x400) and not any of the bitmap modes, with Unix like cursor addressing and with no rio(1) and no mouse then it's something I never really explored. --Andy From akosela at andykosela.com Fri Sep 7 08:16:21 2018 From: akosela at andykosela.com (Andy Kosela) Date: Fri, 07 Sep 2018 00:16:21 +0200 Subject: [TUHS] cat -v and other complaints In-Reply-To: <1536265780.5213.for-standards-violators@oclsc.org> References: <1536265780.5213.for-standards-violators@oclsc.org> Message-ID: <5b91a735.NY0ZEcIRVoU4KsK1%akosela@andykosela.com> Norman Wilson wrote: > Andy Kosela: > > One still cannot ignore the fact that Unix and Plan 9 offer two > completely different approaches to displaying text. > > I admit I've never actually used Plan 9. Can you elaborate on > the different approaches? > > One difference from most of what passes for UNIX these days is > probably that the basic terminal model allows one to edit anything > on the screen, using the mouse and keyboard and a simple button-2 > menu similar to that of sam. You can edit what some program has > already printed, then pick it up and send it back as input. You > can even edit text in the current line that hasn't been sent yet > (because you haven't hit a return yet); in effect the canonical-line > part of the tty driver is in the terminal. > > But you probably don't mean that, both because it's not really > such a radical difference, and because it doesn't conflict at all > with UNIX. In fact it originated on UNIX, five or six years before > Plan 9 was thought of: it's the model from the terminal program > in mux, the more-advanced version of the Blit/Jerq window manager > that nearly everybody used in 1127 by the time I arrived in 1984. > > And I still use it every day, even on Linux (and in years past > on Solaris and IRIX and Digital UNIX and Ultrix). The modern > version of the program to do that is called 9term. It doesn't > work quite as well as I'd like on Linux due to changes in the > tty driver that make it hard for a program to learn right away > when tty modes are changed (in particular when echo is turned off > or on), and it does conflict with the GNU readline junk because > that turns off canonical processing, but to those of us who have > a taste for it it's still just fine. > > As I say, I don't think that's the difference you mean, so please > step in and supersede me. In short, character based approach vs. bitmap based. Yes, in Unix you also has a windowing system which is bitmap based, but IMHO this was always an add-on and not an essential part of the system. Plan 9 on the other hand seems to be designed with more of a graphical based approach than the old school character based approach. --Andy From pnr at planet.nl Fri Sep 7 09:56:35 2018 From: pnr at planet.nl (Paul Ruizendaal) Date: Fri, 7 Sep 2018 01:56:35 +0200 Subject: [TUHS] plan9 first edition Message-ID: <2BEA2847-0FFE-4835-A59C-098E62DB5C0F@planet.nl> Somewhat off topic, for which apologies beforehand. I’m looking for source code of Plan9’s first edition. A quick search on Google came up dry. Would that source be publicly available? Or were the licensing restrictions such that it only exists in non-public archives? From crossd at gmail.com Fri Sep 7 11:59:05 2018 From: crossd at gmail.com (Dan Cross) Date: Thu, 6 Sep 2018 21:59:05 -0400 Subject: [TUHS] cat -v and other complaints In-Reply-To: <5b91a268.lXqMJkXVvoGUv0XA%akosela@andykosela.com> References: <20180831215636.-eCEx%ca6c@bitmessage.ch> <20180903180401.u4MVs%ca6c@bitmessage.ch> <20180903181133.GB81368@wopr> <20180903185616.ZnkRk%ca6c@bitmessage.ch> <5b9187be.JqdXbAJqb0gb8I/y%akosela@andykosela.com> <5b91a268.lXqMJkXVvoGUv0XA%akosela@andykosela.com> Message-ID: On Thu, Sep 6, 2018 at 5:56 PM Andy Kosela wrote: > [snip] Well, you can't tell me > this system was designed with the idea of running it using text terminal > and no mouse. I won't, because it wouldn't be true. You are correct that it was always intended to be used with a graphical console. But you keep talking about "text terminals" and therein lies the confusion: our text terminals haven't been purely "text" since the teletype days. Even green-screen serial terminals have graphics adapters to draw characters on the screen. There is also no cursor addressing, no curses. Actually, there *is* a graphical program to emulate a vt-series terminal, but pretty much no one uses it. So while strictly speaking this is incorrect, it is essentially correct for all intents and purposes. But it begs the question: why would you *want* to use that sort of interface? That was appropriate for an HP or DEC terminal connected via a low-bandwidth link (e.g., serial) or a shared host computer. Once we moved onto personal workstation-class machines with graphics adapters, why continue with that paradigm? Your framebuffer doesn't care that, '\033[H\033[J' means "move the cursor to the upper-left corner and clear the current line to the end of the screen", so why should your terminal emulator? For that matter, if logged into the text-only console on a Linux or FreeBSD machine, why does running `stty` say your graphics adapter has a BAUD rate? The plan9 authors decided to leave such historical debris behind. > Like I > written before it was born in the different era -- they tried to not > build it on the idea of character based TTY, but rather incorporate > graphical element into it. > Correct. I wasn't there, but the observation surely must have been in part that the user was *already* using a graphical environment, just not to very good effect. If it is possible to be fully productive in Plan 9 using just VGA text > mode (720x400) and not any of the bitmap modes, with Unix like cursor > addressing and with no rio(1) and no mouse then it's something I never > really explored. > You could skip `rio` and just run `vt` on the console. I doubt the emulation is very good and it wouldn't be an acceptable substitute for serious use. `vt` was really intended as a stop-gap for accessing older systems; the plan9 model was different, and instead of accessing remote resources, the idea was that those resources would be shared with the (plan9) network and imported locally for manipulation. That is, I wouldn't `ssh` into some machine to make use of something on it; instead I'd use `import` to bring those resources into my namespace locally and I'd manipulate them there. I did a writeup of this a while back: http://pub.gajendra.net/2016/05/plan9part1 I should probably do parts 2 and 3.... - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From akosela at andykosela.com Fri Sep 7 14:40:37 2018 From: akosela at andykosela.com (Andy Kosela) Date: Fri, 07 Sep 2018 06:40:37 +0200 Subject: [TUHS] cat -v and other complaints In-Reply-To: References: <20180831215636.-eCEx%ca6c@bitmessage.ch> <20180903180401.u4MVs%ca6c@bitmessage.ch> <20180903181133.GB81368@wopr> <20180903185616.ZnkRk%ca6c@bitmessage.ch> <5b9187be.JqdXbAJqb0gb8I/y%akosela@andykosela.com> <5b91a268.lXqMJkXVvoGUv0XA%akosela@andykosela.com> Message-ID: <5b920145.7aDYuhN/FRnTadNW%akosela@andykosela.com> Dan Cross wrote: > On Thu, Sep 6, 2018 at 5:56 PM Andy Kosela wrote: > > > [snip] Well, you can't tell me > > this system was designed with the idea of running it using text terminal > > and no mouse. > > > I won't, because it wouldn't be true. You are correct that it was always > intended to be used with a graphical console. But you keep talking about > "text terminals" and therein lies the confusion: our text terminals haven't > been purely "text" since the teletype days. Even green-screen serial > terminals have graphics adapters to draw characters on the screen. I think I was clear enough and meant 'text terminal' as a physical glass TTY e.g. vt220 from DEC, but understand now why someone might have interpreted it differently. There is also a big difference between a text mode (character mode) where what we see on the screen is addressed in terms of characters rather than individual pixels and a bitmap mode (graphics mode) also known as APA (all points addressable) mode where every pixel is addressable[1]. Inherent in the text mode is also the concept of monospace fonts which some people prefer to this day. > > There is also no cursor addressing, no curses. > > > Actually, there *is* a graphical program to emulate a vt-series terminal, > but pretty much no one uses it. So while strictly speaking this is > incorrect, it is essentially correct for all intents and purposes. > > But it begs the question: why would you *want* to use that sort of > interface? That was appropriate for an HP or DEC terminal connected via a > low-bandwidth link (e.g., serial) or a shared host computer. Once we moved > onto personal workstation-class machines with graphics adapters, why > continue with that paradigm? Why there are still people running C64, Atari XL/XE or Amiga? Even more, some of them think those computers are still better than the machines of today... In the Unix community there are some that still prefer to use old CRT terminals or MS-DOS era PC monitors using only text mode. Why I can't speak for all of them, I can speak for myself and explain my motivation behind it. I instantly fell in love with a text mode when I first started computing on Commodore and Atari machines in the 80s and then naturally advanced to a text mode on MS-DOS era PC's. I never really ran Linux or *BSDs with X Window System -- always preferred pure text mode. It is aesthetically pleasing and most elegant to converse with a machine using only text, and a text mode as displayed on cathode ray tube (CRT) is the most beautiful representation of such an idea. Although these days I'm using sometimes MacBook (who doesn't?) which is using of course the bitmap mode, I still prefer to experience the full text mode on a real CRT and actually collect them as they are becoming more and more rare. [1] https://en.wikipedia.org/wiki/Text_mode --Andy From web at loomcom.com Sat Sep 8 05:50:46 2018 From: web at loomcom.com (Seth Morabito) Date: Fri, 07 Sep 2018 12:50:46 -0700 Subject: [TUHS] Public System V UNIX Release 3 (3B2/400) Access Message-ID: <1536349846.1862327.1500626664.39CC3CE7@webmail.messagingengine.com> Hello all, I'm beta-testing a service I've set up to allow public access to a network of computers running System V UNIX Release 3.2. This is only tangentially related to RetroNet, and we hope to peer with them once RetroNet has UUCP peering going! The network consists of three emulated 3B2/400s linked by UUCP, and connected to the Internet through a gateway system. E-mail (UUCP, UUCP-to-SMTP, and SMTP-to-UUCP) works in and out of the network. There is a small private Net News setup running BNews for that true historic flair. All machines have access to the "retronet.*" news hierarchy. (There is no public Usenet access, sorry!) If you're interested in reliving some UNIX history, consider signing up for an account. You'll be randomly assigned a home host in the network. Account signup form is here: https://loomcom.net/ Access is via SSH-to-Telnet gateway, by connecting to: $ ssh access at loomcom.net (No password is needed for the SSH gateway, it is a captive portal) -Seth -- Seth Morabito Poulsbo, WA web at loomcom.com From doug at cs.dartmouth.edu Sat Sep 8 22:02:24 2018 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sat, 08 Sep 2018 08:02:24 -0400 Subject: [TUHS] [TUHS} cat -v and other complaints Message-ID: <201809081202.w88C2OCj038136@tahoe.cs.Dartmouth.EDU> > you can't tell me > this system was designed with the idea of running it using text terminal > and no mouse. There is also no cursor addressing, no curses. The well named Curses and the associated vi were an ugly outgrowth of glass screens--an outgrowth many of us in the Unix lab never adopted. That branch of evolution was unrelated to the Blit branch that essentially preserved the old TTY interface, except that one could have multiple terminals on screen and a mouse was available to give mechanical help for manual cut/paste/edit activities. Plan 9 terminal-handling smoothly continued that evolutionary branch. Mouse support could have been used to take off in a radical direction, but it wasn't. To my mind, the primary innovation in Plan 9 was not terminal support, nor everything-is-a-file. Rather it was an advance in what Vyssotsky called "distributable computing", where components can collaborate in a uniform way, no matter where they are. The key was the 9P protocol that unpacked the notion of file type--a unifying principle that brought simplicity and generality to a diversity of particulars. From will.senn at gmail.com Sat Sep 8 23:36:56 2018 From: will.senn at gmail.com (Will Senn) Date: Sat, 8 Sep 2018 08:36:56 -0500 Subject: [TUHS] [TUHS} cat -v and other complaints In-Reply-To: <201809081202.w88C2OCj038136@tahoe.cs.Dartmouth.EDU> References: <201809081202.w88C2OCj038136@tahoe.cs.Dartmouth.EDU> Message-ID: <3054F86A-0FDA-4266-B8B8-EE53869F3700@gmail.com> Doug et al., I’m interested in learning about this curses vs blit business. Is there a writeup or book chapter out there that covers this in any detail? Thanks, Will Sent from my iPhone On Sep 8, 2018, at 7:02 AM, Doug McIlroy wrote: >> you can't tell me >> this system was designed with the idea of running it using text terminal >> and no mouse. There is also no cursor addressing, no curses. > > The well named Curses and the associated vi were an ugly outgrowth > of glass screens--an outgrowth many of us in the Unix lab never > adopted. That branch of evolution was unrelated to the Blit branch that > essentially preserved the old TTY interface, except that one could have > multiple terminals on screen and a mouse was available to give mechanical > help for manual cut/paste/edit activities. Plan 9 terminal-handling > smoothly continued that evolutionary branch. > > Mouse support could have been used to take off in a radical direction, > but it wasn't. To my mind, the primary innovation in Plan 9 was not > terminal support, nor everything-is-a-file. Rather it was an advance in > what Vyssotsky called "distributable computing", where components can > collaborate in a uniform way, no matter where they are. The key was the 9P > protocol that unpacked the notion of file type--a unifying principle > that brought simplicity and generality to a diversity of particulars. From ralph at inputplus.co.uk Sun Sep 9 00:22:12 2018 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Sat, 08 Sep 2018 15:22:12 +0100 Subject: [TUHS] cat -v and other complaints In-Reply-To: <3054F86A-0FDA-4266-B8B8-EE53869F3700@gmail.com> References: <201809081202.w88C2OCj038136@tahoe.cs.Dartmouth.EDU> <3054F86A-0FDA-4266-B8B8-EE53869F3700@gmail.com> Message-ID: <20180908142212.167B1218D6@orac.inputplus.co.uk> Hi Will, > I'm interested in learning about this curses vs blit business. Is > there a writeup or book chapter out there that covers this in any > detail? https://en.wikipedia.org/wiki/Blit_(computer_terminal) is a jumping-off point. And I suppose the same goes for curses(3): https://en.wikipedia.org/wiki/Curses_(programming_library) -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy From krewat at kilonet.net Sun Sep 9 02:10:00 2018 From: krewat at kilonet.net (Arthur Krewat) Date: Sat, 8 Sep 2018 12:10:00 -0400 Subject: [TUHS] cat -v and other complaints In-Reply-To: <20180908142212.167B1218D6@orac.inputplus.co.uk> References: <201809081202.w88C2OCj038136@tahoe.cs.Dartmouth.EDU> <3054F86A-0FDA-4266-B8B8-EE53869F3700@gmail.com> <20180908142212.167B1218D6@orac.inputplus.co.uk> Message-ID: On 9/8/2018 10:22 AM, Ralph Corderoy wrote: > >> I'm interested in learning about this curses vs blit business. Is >> there a writeup or book chapter out there that covers this in any >> detail? > https://en.wikipedia.org/wiki/Blit_(computer_terminal) is a jumping-off > point. And I suppose the same goes for curses(3): > https://en.wikipedia.org/wiki/Curses_(programming_library) > In my opinion (as retarded as I can be sometimes), this is an apples-and-oranges comparison. Blit is a completely new terminal type, with specific operating system/software support. Curses is a way to control various already-existing terminal types. DEC terminals, Hazeltine, etc. A recent termcap on my Solaris server has 472 entries. The wide-ranging support was quite important. Many people/institutions had a variety of terminals already, usually recycled from previous systems. I remember one instance when I was 17 years old working at BOCES/LIRICS on Long Island, and an office worker in a local high-school looked at me like a deer in the headlights when they could no longer use their current-loop terminal and acoustic coupler. Sorry, the leased-line mux in the other room can't do that. It has to be RS232. We gladly gave them a new LA36. Which invoked another set of "how do I..." questions. Ah, progress. (This was to support TOPS-10 on DEC KS10's, but the same thing happened many times over my early career. People just didn't want to give up what they already had) ak From dave at horsfall.org Sun Sep 9 09:02:00 2018 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 9 Sep 2018 09:02:00 +1000 (EST) Subject: [TUHS] Happy birthday, Dennis Ritchie Message-ID: Co-inventor of Unix, and sadly lost to us in 2011, he was born on this day in 1941. Thank you Dennis (and of course Ken), for that wonderful OS that we still use to this day, and imitated by others. -- Dave From Caipenghui_c at 163.com Sun Sep 9 19:02:24 2018 From: Caipenghui_c at 163.com (Caipenghui) Date: Sun, 09 Sep 2018 09:02:24 +0000 Subject: [TUHS] Happy birthday Dennis Ritchie Message-ID: <6003545F-2925-49B0-8829-67E330FD466C@163.com> Today, a great scientist Dennis Ritchie was born, he did too much for humanity! I can't describe him in words, Dennis wishes you a happy birthday! Caipenghui From dave at horsfall.org Mon Sep 10 16:35:56 2018 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 10 Sep 2018 16:35:56 +1000 (EST) Subject: [TUHS] =?utf-8?q?=5BCOFF=5D__RetroNet=E2=80=A6_Virtual_is_cheap?= =?utf-8?q?=2E?= In-Reply-To: <20180901222055.GA71355@server.rulingia.com> References: <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com> <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net> <1d8c0539-8b43-9954-d8a7-db4dcc22b27d@texoma.net> <0b739af0-da9e-6bdb-fe17-6f2dda837de5@spamtrap.tnetconsulting.net> <20180901222055.GA71355@server.rulingia.com> Message-ID: On Sun, 2 Sep 2018, Peter Jeremy wrote: > [2] This is good enough because Australian ISPs don't believe in IPv6 If I go to a site that reports my IP address, I get IPv6 (I have a static IPv4 address), which appears to be the default used by my router (a Fastnet 5355 or something, which T$ appear to be unloading on us). I tried asking T$ for a static IPv6 range, but was unable to find anyone who even knew what I was talking about. -- Dave From jacob.ritorto at gmail.com Tue Sep 18 11:27:12 2018 From: jacob.ritorto at gmail.com (Jacob Ritorto) Date: Mon, 17 Sep 2018 21:27:12 -0400 Subject: [TUHS] unix svr1 install docs Message-ID: Hi, I'm hoping to run System V Release 1 on my pdp11/45, provided I can find a controller that'll emulate one of the few disks it supports. I've been looking around trying to find the installation manual to no avail. The programmers manual, user's manual and error manual are all readily available, but nothing about install aside from some anecdotal lines from a simh install. Would anyone have a hint on where to find it or perhaps a real copy to lend? Happy to scan and mail back if so. thx jake -------------- next part -------------- An HTML attachment was scrubbed... URL: From wlc at jctaylor.com Tue Sep 18 12:39:20 2018 From: wlc at jctaylor.com (William Corcoran) Date: Tue, 18 Sep 2018 02:39:20 +0000 Subject: [TUHS] unix svr1 install docs In-Reply-To: References: Message-ID: Hello Jacob, Below, please find the installation details. This is from the TUHS archive (Papenhoff Distribution). SVR1 is an incredibly stable port. I have an AWS cloud instance running SVR1 and the last reboot was in May. Random832 fixed a defect with flsbuf.c for me. This corrected an issue with Standard Error. If you want it, let me know. Truly, Bill Corcoran -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00001.txt URL: From wlc at jctaylor.com Tue Sep 18 13:39:47 2018 From: wlc at jctaylor.com (William Corcoran) Date: Tue, 18 Sep 2018 03:39:47 +0000 Subject: [TUHS] unix svr1 install docs In-Reply-To: References: , Message-ID: <2AA7374C-5E79-430F-BDAC-C70A87BDDFFD@jctaylor.com> Hello Jacob, Strike my earlier remarks about the source location. It is on github. Bill Corcoran. > On Sep 17, 2018, at 10:56 PM, William Corcoran wrote: > > Hello Jacob, > > Below, please find the installation details. This is from the TUHS archive (Papenhoff Distribution). > > SVR1 is an incredibly stable port. I have an AWS cloud instance running SVR1 and the last reboot was in May. > Random832 fixed a defect with flsbuf.c for me. This corrected an issue with Standard Error. If you want it, let me know. > > Truly, > > Bill Corcoran > > > > > > > > > > > > On Sep 17, 2018, at 9:27 PM, Jacob Ritorto wrote: > > Hi, > I'm hoping to run System V Release 1 on my pdp11/45, provided I can find a controller that'll emulate one of the few disks it supports. I've been looking around trying to find the installation manual to no avail. The programmers manual, user's manual and error manual are all readily available, but nothing about install aside from some anecdotal lines from a simh install. Would anyone have a hint on where to find it or perhaps a real copy to lend? Happy to scan and mail back if so. > > thx > jake > From aap at papnet.eu Tue Sep 18 15:24:12 2018 From: aap at papnet.eu (Angelo Papenhoff) Date: Tue, 18 Sep 2018 07:24:12 +0200 Subject: [TUHS] unix svr1 install docs In-Reply-To: References: Message-ID: <20180918052412.GA82105@indra.papnet.eu> On 17/09/18, Jacob Ritorto wrote: > Hi, > I'm hoping to run System V Release 1 on my pdp11/45, provided I can find > a controller that'll emulate one of the few disks it supports. I've been > looking around trying to find the installation manual to no avail. The > programmers manual, user's manual and error manual are all readily > available, but nothing about install aside from some anecdotal lines from a > simh install. Would anyone have a hint on where to find it or perhaps a > real copy to lend? Happy to scan and mail back if so. My guide was already linked, but here again from me personally: http://a.papnet.eu/UNIX/sysV_pdp11/Installation Hope it helps. There's also some other guides there. aap From jacob.ritorto at gmail.com Thu Sep 20 05:15:11 2018 From: jacob.ritorto at gmail.com (Jacob Ritorto) Date: Wed, 19 Sep 2018 15:15:11 -0400 Subject: [TUHS] unix svr1 install docs In-Reply-To: <20180918052412.GA82105@indra.papnet.eu> References: <20180918052412.GA82105@indra.papnet.eu> Message-ID: Cool, Angelo, thank you - your writeup was the only hint I'd found and I did manage to follow along and get it to run in the emulator. Was there a source you referred to in figuring out how to do what you did? I imagine there's an original AT&T doc out there somewhere that'd describe the whole install process for real iron. thx jake On Tue, Sep 18, 2018 at 1:32 AM Angelo Papenhoff wrote: > On 17/09/18, Jacob Ritorto wrote: > > Hi, > > I'm hoping to run System V Release 1 on my pdp11/45, provided I can > find > > a controller that'll emulate one of the few disks it supports. I've been > > looking around trying to find the installation manual to no avail. The > > programmers manual, user's manual and error manual are all readily > > available, but nothing about install aside from some anecdotal lines > from a > > simh install. Would anyone have a hint on where to find it or perhaps a > > real copy to lend? Happy to scan and mail back if so. > > My guide was already linked, but here again from me personally: > http://a.papnet.eu/UNIX/sysV_pdp11/Installation > Hope it helps. > There's also some other guides there. > > aap > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aap at papnet.eu Thu Sep 20 06:03:36 2018 From: aap at papnet.eu (Angelo Papenhoff) Date: Wed, 19 Sep 2018 22:03:36 +0200 Subject: [TUHS] unix svr1 install docs In-Reply-To: References: <20180918052412.GA82105@indra.papnet.eu> Message-ID: <20180919200335.GA21575@indra.papnet.eu> On 19/09/18, Jacob Ritorto wrote: > Cool, Angelo, thank you - your writeup was the only hint I'd found and I > did manage to follow along and get it to run in the emulator. Was there a > source you referred to in figuring out how to do what you did? I imagine > there's an original AT&T doc out there somewhere that'd describe the whole > install process for real iron. I think I just did mostly the same as I did for installing System III, which comes with documentation. It's really simple, just follow the prompts to install the base system and then extract the extra cpio archives. BTW, if anyone has SysVR1 for VAX, I'd like to add this to my site as well. aap From don at DonHopkins.com Mon Sep 24 04:37:01 2018 From: don at DonHopkins.com (Don Hopkins) Date: Sun, 23 Sep 2018 20:37:01 +0200 Subject: [TUHS] SPARC is CRAPS spelled backwards. In-Reply-To: References: Message-ID: <1686170E-4323-4BDF-B95C-8A6B3FFD5288@gmail.com> Its register windows have spilled out into the SCRAP heap of history. But to its credit, the SPARCSTATION represents PANTISOCRACY with NO RACIST PAST. It ROASTS CATNIP for SATANIC SPORT with no PARTISAN COST. It can create a CAT SOPRANIST with a CASTRATO SNIP. -Don -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.phillip.garcia at gmail.com Mon Sep 24 05:49:28 2018 From: a.phillip.garcia at gmail.com (A. P. Garcia) Date: Sun, 23 Sep 2018 15:49:28 -0400 Subject: [TUHS] SPARC is CRAPS spelled backwards. In-Reply-To: <1686170E-4323-4BDF-B95C-8A6B3FFD5288@gmail.com> References: <1686170E-4323-4BDF-B95C-8A6B3FFD5288@gmail.com> Message-ID: On Sun, Sep 23, 2018, 2:37 PM Don Hopkins wrote: > Its register windows have spilled out into the SCRAP heap of history. > But to its credit, the SPARCSTATION represents PANTISOCRACY with NO RACIST > PAST. > It ROASTS CATNIP for SATANIC SPORT with no PARTISAN COST. > It can create a CAT SOPRANIST with a CASTRATO SNIP. > In trying to steer this word salad towards some semblance of meaningful discussion, is SPARC dead? Practically, yes, I would say so. Or at least it seems to be heading in that direction. Is RISC dead? Not at all. ARM is doing quite well, and the old "CISC vs RISC" thing seems to be a non-issue now, as even the current x86 processors have adopted many design features that originated in RISC research. The saddest thing about the death of SPARC, in my opinion, is that it likely also means the death of the most advanced OS with "true" UNIX roots. CDDL was ostensibly chosen to prevent Linux from cannibalizing the best parts of Solaris. But it only seems to have slowed that down. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Mon Sep 24 07:17:35 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Sun, 23 Sep 2018 17:17:35 -0400 Subject: [TUHS] SPARC is CRAPS spelled backwards. In-Reply-To: References: <1686170E-4323-4BDF-B95C-8A6B3FFD5288@gmail.com> Message-ID: On 9/23/18, A. P. Garcia wrote: > > In trying to steer this word salad towards some semblance of meaningful > discussion, is SPARC dead? Practically, yes, I would say so. Or at least it > seems to be heading in that direction. Is RISC dead? Not at all. ARM is > doing quite well, and the old "CISC vs RISC" thing seems to be a non-issue > now, as even the current x86 processors have adopted many design features > that originated in RISC research. In general, a CISC instruction set encoding can express the same algorithm more compactly than a RISC instruction set. Once CISC technology solved the instruction pipelining and decoding problem, it gained an advantage over RISC architectures such as Alpha because the instruction set stream was less verbose. Modern x86 designs have a bit of logic stuck in one corner that translates the x86 instruction stream into a string of RISC-style micro-operations. The cores execute the micro-ops. Micro-op sequences can be cached, so the translation is done only once for loops. The result is, as it were, the best of both worlds--the compactness of a CISC instruction stream and the simpler and faster circuitry of RISC. -Paul W. From dot at dotat.at Mon Sep 24 21:25:46 2018 From: dot at dotat.at (Tony Finch) Date: Mon, 24 Sep 2018 12:25:46 +0100 Subject: [TUHS] SPARC is CRAPS spelled backwards. In-Reply-To: References: <1686170E-4323-4BDF-B95C-8A6B3FFD5288@gmail.com> Message-ID: Paul Winalski wrote: > > In general, a CISC instruction set encoding can express the same > algorithm more compactly than a RISC instruction set. Once CISC > technology solved the instruction pipelining and decoding problem, it > gained an advantage over RISC architectures such as Alpha because the > instruction set stream was less verbose. It's more subtle than that, I think. One of the best contributions to this discussion was John Mashey's classic comp.arch article (which I originally read in 1994, I think) - https://yarchive.net/comp/risc_definition.html What is striking about it is that the two dominant architectures now are (very roughly) the least CISCy CISC and the least RISCy RISC. In particular x86 did not go in for elaborate addressing modes and highly orthogonal instruction sets that allow you to use the elaborate addressing modes multiple times in one instruction. (Compare it with later 68Ks, for contrast.) So the translation to RISC-style micro-ops does not end up with ridiculously long dependency chains within most instructions. Tony. -- f.anthony.n.finch http://dotat.at/ Shannon: South 3 or 4, increasing 5 to 7, perhaps gale 8 later. Moderate, becoming rough, then very rough later in far northwest. Fair then occasional rain. Good, becoming moderate, occasionally poor. From jnc at mercury.lcs.mit.edu Mon Sep 24 21:48:04 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 24 Sep 2018 07:48:04 -0400 (EDT) Subject: [TUHS] SPARC is CRAPS spelled backwards. Message-ID: <20180924114804.CFF9B18C082@mercury.lcs.mit.edu> > From: Paul Winalski > In general, a CISC instruction set encoding can express the same > algorithm more compactly than a RISC instruction set. I have often pointed to memory bandwidth as one of the key factors in the evolution of CISC and RISC. When it was low, compared to CPU speeds (most of the core era), CISC made sense. When it increased (with DRAM), RISC made more sense, because it allowed CPUs to run faster (via simpler instructions). Caching made the picture a little more complex; and today, with the incredible mismatch between memory speeds and CPU speeds, caching dominates, whether you have RISC or CISC. Noel From peter at rulingia.com Tue Sep 25 05:46:47 2018 From: peter at rulingia.com (Peter Jeremy) Date: Tue, 25 Sep 2018 05:46:47 +1000 Subject: [TUHS] SPARC is CRAPS spelled backwards. In-Reply-To: References: <1686170E-4323-4BDF-B95C-8A6B3FFD5288@gmail.com> Message-ID: <20180924194647.GA29897@server.rulingia.com> On 2018-Sep-23 17:17:35 -0400, Paul Winalski wrote: >In general, a CISC instruction set encoding can express the same >algorithm more compactly than a RISC instruction set. Once CISC >technology solved the instruction pipelining and decoding problem, it >gained an advantage over RISC architectures such as Alpha because the >instruction set stream was less verbose. RISC architectures have another advantage that instructions are always aligned on known boundaries (typically 2 or 4 bytes). This simplifies the logic around (pre-)fetching instructions. >Modern x86 designs have a >bit of logic stuck in one corner that translates the x86 instruction >stream into a string of RISC-style micro-operations. Where "modern" is "this century". ... >the best of both worlds--the compactness of a CISC instruction stream >and the simpler and faster circuitry of RISC. In the specific case of x86, I would dispute that. The various warts in the x86 instruction set and "architecture" mean that x86 code density is relatively low and on a par with SPARC code. I agree that the overall performance is impressive but that is more a measure of the abilities of Intel's engineers than the overall approach. -- 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 paul.winalski at gmail.com Tue Sep 25 06:20:17 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 24 Sep 2018 16:20:17 -0400 Subject: [TUHS] SPARC is CRAPS spelled backwards. In-Reply-To: <20180924194647.GA29897@server.rulingia.com> References: <1686170E-4323-4BDF-B95C-8A6B3FFD5288@gmail.com> <20180924194647.GA29897@server.rulingia.com> Message-ID: On 9/24/18, Peter Jeremy wrote: > > In the specific case of x86, I would dispute that. The various warts in > the > x86 instruction set and "architecture" mean that x86 code density is > relatively low and on a par with SPARC code. I agree that the overall > performance is impressive but that is more a measure of the abilities of > Intel's engineers than the overall approach. No doubt about it--x86 instruction encoding is butt-ugly and wasteful, due to the need for backward compatibility with what was originally an 8-bit architecture. Does SPARC have the vector instructions that have been added to x86 over the years? -Paul W. From krewat at kilonet.net Tue Sep 25 06:45:13 2018 From: krewat at kilonet.net (Arthur Krewat) Date: Mon, 24 Sep 2018 16:45:13 -0400 Subject: [TUHS] SPARC is CRAPS spelled backwards. In-Reply-To: References: <1686170E-4323-4BDF-B95C-8A6B3FFD5288@gmail.com> <20180924194647.GA29897@server.rulingia.com> Message-ID: On 9/24/2018 4:20 PM, Paul Winalski wrote: > No doubt about it--x86 instruction encoding is butt-ugly and wasteful, > due to the need for backward compatibility with what was originally an > 8-bit architecture. Does SPARC have the vector instructions that have > been added to x86 over the years? The 8086 was the first of the "x86" line, which was 16-bit, although it's I/O was more 8080-ish if I recall correctly. The 8088 was an 8-bit data bus, granted, but having done both 8080 and 8086+ assembler, you couldn't really tell the difference, programming-wise between the 8086 and the 8088, 16-bit registers, and all. Cutting costs, as always, IBM opted for the 8088, which allowed them to use an 8085-style I/O architecture. Also, granted, to this day you can still use only 8-bits of a register: MOV AL,0x80 art k. From dot at dotat.at Tue Sep 25 20:00:37 2018 From: dot at dotat.at (Tony Finch) Date: Tue, 25 Sep 2018 11:00:37 +0100 Subject: [TUHS] SPARC is CRAPS spelled backwards. In-Reply-To: <20180924194647.GA29897@server.rulingia.com> References: <1686170E-4323-4BDF-B95C-8A6B3FFD5288@gmail.com> <20180924194647.GA29897@server.rulingia.com> Message-ID: Peter Jeremy wrote: > In the specific case of x86, I would dispute that. The various warts in > the x86 instruction set and "architecture" mean that x86 code density is > relatively low and on a par with SPARC code. This paper has a nice survey of instruction set densities, which very much disagrees with your statement: http://web.eece.maine.edu/~vweaver/papers/iccd09/iccd09_density.pdf Tony. -- f.anthony.n.finch http://dotat.at/ Dogger, Fisher, German Bight, Humber: West or northwest 4 backing southwest 5 to 7, occasionally gale 8 later except in Humber. Slight or moderate becoming moderate or rough, then very rough later in Fisher. Showers. Good. From jnc at mercury.lcs.mit.edu Tue Sep 25 22:12:12 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 25 Sep 2018 08:12:12 -0400 (EDT) Subject: [TUHS] SPARC is CRAPS spelled backwards. Message-ID: <20180925121212.C179D18C08D@mercury.lcs.mit.edu> > From: Arthur Krewat > Also, granted, to this day you can still use only 8-bits of a register: Yeah, but that's not totally useless; lots of byte-organized data out there in the world, e.g. ASCII strings. 16-bit data, less so, although there is some in networking protocols (checksums, ports, etc - although the checksums you _compute_ using bigger chunks). (Not a defense of the x86 instruction set, mind!) Noel From tytso at mit.edu Wed Sep 26 00:49:08 2018 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Tue, 25 Sep 2018 10:49:08 -0400 Subject: [TUHS] SPARC is CRAPS spelled backwards. In-Reply-To: <20180925121212.C179D18C08D@mercury.lcs.mit.edu> References: <20180925121212.C179D18C08D@mercury.lcs.mit.edu> Message-ID: <20180925144908.GA2933@thunk.org> On Tue, Sep 25, 2018 at 08:12:12AM -0400, Noel Chiappa wrote: > > From: Arthur Krewat > > > Also, granted, to this day you can still use only 8-bits of a register: > > Yeah, but that's not totally useless; lots of byte-organized data out there in > the world, e.g. ASCII strings. 16-bit data, less so, although there is some in > networking protocols (checksums, ports, etc - although the checksums you > _compute_ using bigger chunks). Windows and Microsoft Office still uses UTF-16.... - Ted From lm at mcvoy.com Wed Sep 26 01:01:52 2018 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 25 Sep 2018 08:01:52 -0700 Subject: [TUHS] SPARC is CRAPS spelled backwards. In-Reply-To: References: <1686170E-4323-4BDF-B95C-8A6B3FFD5288@gmail.com> <20180924194647.GA29897@server.rulingia.com> Message-ID: <20180925150152.GJ10989@mcvoy.com> On Tue, Sep 25, 2018 at 11:00:37AM +0100, Tony Finch wrote: > Peter Jeremy wrote: > > > In the specific case of x86, I would dispute that. The various warts in > > the x86 instruction set and "architecture" mean that x86 code density is > > relatively low and on a par with SPARC code. > > This paper has a nice survey of instruction set densities, which very much > disagrees with your statement: > > http://web.eece.maine.edu/~vweaver/papers/iccd09/iccd09_density.pdf That's a neat paper, I like it, thanks for the pointer. I'm curious why Peter thought what he thought, my guess would have been more like what the paper showed, but that was a "hand optimized assembly", maybe the compilers aren't that good? I dunno, Peter, care to comment? From krewat at kilonet.net Wed Sep 26 01:29:01 2018 From: krewat at kilonet.net (Arthur Krewat) Date: Tue, 25 Sep 2018 11:29:01 -0400 Subject: [TUHS] SPARC is CRAPS spelled backwards. In-Reply-To: <20180925121212.C179D18C08D@mercury.lcs.mit.edu> References: <20180925121212.C179D18C08D@mercury.lcs.mit.edu> Message-ID: <78271134-1774-9c43-2df0-9bcd5174a349@kilonet.net> On 9/25/2018 8:12 AM, Noel Chiappa wrote: > > From: Arthur Krewat > > > Also, granted, to this day you can still use only 8-bits of a register: > > Yeah, but that's not totally useless; lots of byte-organized data out there in > the world, e.g. ASCII strings. 16-bit data, less so, although there is some in > networking protocols (checksums, ports, etc - although the checksums you > _compute_ using bigger chunks). > > (Not a defense of the x86 instruction set, mind!) > > Noel > > Oh, I like 8-bit operations... I use them a lot. Coming from MACRO-10 on a 36-bit PDP-10 I used in high school, the move to microcomputers was challenging in some ways, but much easier in others. Especially 7 or 8 bit operations. From paul.winalski at gmail.com Wed Sep 26 04:34:46 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Tue, 25 Sep 2018 14:34:46 -0400 Subject: [TUHS] SPARC is CRAPS spelled backwards. In-Reply-To: References: <1686170E-4323-4BDF-B95C-8A6B3FFD5288@gmail.com> <20180924194647.GA29897@server.rulingia.com> Message-ID: On 9/25/18, Tony Finch wrote: > Peter Jeremy wrote: > > This paper has a nice survey of instruction set densities, which very much > disagrees with your statement: > > http://web.eece.maine.edu/~vweaver/papers/iccd09/iccd09_density.pdf Thanks for the pointer to that paper. Interesting reading. There is an error in Table I (Summary of Investigated Architectures). VAX is a pure little-endian architecture and can't operate on big-endian data without byte swizzling. Alpha, on the other hand, can operate either big- or little-endian (selectable at system boot time). The version of the Intel C compiler that they used--version 9--is a little old in the tooth. There have been several versions released since then. Interesting, and disappointing, that linking statically drags in the entire C runtime. Lo-level RTLs such as libc ought to be designed to minimize dependencies between individual library routines (e.g., if I call only strcmp(), strcmp.o and nothing else should participate in the static link). As the paper points out, compilers are usually designed to optimize for execution speed rather than code size these days. -Paul W. From jnc at mercury.lcs.mit.edu Wed Sep 26 04:41:55 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 25 Sep 2018 14:41:55 -0400 (EDT) Subject: [TUHS] SPARC is CRAPS spelled backwards. Message-ID: <20180925184155.50F5518C08D@mercury.lcs.mit.edu> > From: Tony Finch > This paper has a nice survey of instruction set densities And the winner is.... the PDP-11! I'm not too surprised by this; back in the days of core memory (and limited, at that - the first PDP-11's came standard with ... 8KB of memory :-), having the denset possible code had real savings. Noel From peter at rulingia.com Wed Sep 26 05:48:17 2018 From: peter at rulingia.com (Peter Jeremy) Date: Wed, 26 Sep 2018 05:48:17 +1000 Subject: [TUHS] SPARC is CRAPS spelled backwards. In-Reply-To: <20180925150152.GJ10989@mcvoy.com> References: <1686170E-4323-4BDF-B95C-8A6B3FFD5288@gmail.com> <20180924194647.GA29897@server.rulingia.com> <20180925150152.GJ10989@mcvoy.com> Message-ID: <20180925194817.GB29897@server.rulingia.com> On 2018-Sep-25 08:01:52 -0700, Larry McVoy wrote: >On Tue, Sep 25, 2018 at 11:00:37AM +0100, Tony Finch wrote: >> Peter Jeremy wrote: >> >> > In the specific case of x86, I would dispute that. The various warts in >> > the x86 instruction set and "architecture" mean that x86 code density is >> > relatively low and on a par with SPARC code. >> >> This paper has a nice survey of instruction set densities, which very much >> disagrees with your statement: >> >> http://web.eece.maine.edu/~vweaver/papers/iccd09/iccd09_density.pdf > >That's a neat paper, I like it, thanks for the pointer. I'm curious >why Peter thought what he thought, my guess would have been more like >what the paper showed, but that was a "hand optimized assembly", maybe >the compilers aren't that good? I dunno, Peter, care to comment? I agree that looks like an interesting paper - I've skimmed it and will have to read it in details. I was thinking back to when I was using a mixture of SPARC and x86 at a previous job. I didn't do any careful analysis, more eyeballing various executables and gut feeling. I no longer have access to that environment. In view of that paper, I'll withdraw my claim since it's not backed up by evidence. -- 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 peter at rulingia.com Wed Sep 26 16:20:00 2018 From: peter at rulingia.com (Peter Jeremy) Date: Wed, 26 Sep 2018 16:20:00 +1000 Subject: [TUHS] SPARC is CRAPS spelled backwards. In-Reply-To: References: <1686170E-4323-4BDF-B95C-8A6B3FFD5288@gmail.com> <20180924194647.GA29897@server.rulingia.com> Message-ID: <20180926062000.GC29897@server.rulingia.com> On 2018-Sep-24 16:45:13 -0400, Arthur Krewat wrote: >The 8086 was the first of the "x86" line, which was 16-bit, although >it's I/O was more 8080-ish if I recall correctly. The 8086/8088 bus was designed to be similar to the 8085 to allow 8080/8085 peripherals to support 8086 systems. This saved Intel the effort of developing a new range of support peripherals and made it quicker for vendors to build 8086 systems because they didn't need to wait for the peripheral chips. There are still 8080 support chips - 8253, 8257, 8259 - embedded in PC Southbridge chips. >The 8088 was an 8-bit >data bus, granted, but having done both 8080 and 8086+ assembler, you >couldn't really tell the difference, programming-wise between the 8086 >and the 8088, 16-bit registers, and all. This was deliberate - the 8080 was an upgraded 8008 and Intel made the 8086 similar enough to allow automated ASM translation. It seems highly likely that the undocumented 8085 opcodes were undocumented because they weren't readily translatable to 8086. >Cutting costs, as always, IBM opted for the 8088, which allowed them to >use an 8085-style I/O architecture. An 8-bit memory bus means half as many RAM chips and buffers. Keep in mind that the IBM 5150 was intentionally crippled to ensure it didn't compete with IBM's low-end minis. -- 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 lars at nocrew.org Wed Sep 26 16:46:20 2018 From: lars at nocrew.org (Lars Brinkhoff) Date: Wed, 26 Sep 2018 06:46:20 +0000 Subject: [TUHS] SPARC is CRAPS spelled backwards. In-Reply-To: <20180926062000.GC29897@server.rulingia.com> (Peter Jeremy's message of "Wed, 26 Sep 2018 16:20:00 +1000") References: <1686170E-4323-4BDF-B95C-8A6B3FFD5288@gmail.com> <20180924194647.GA29897@server.rulingia.com> <20180926062000.GC29897@server.rulingia.com> Message-ID: <7wsh1wdadf.fsf@junk.nocrew.org> Peter Jeremy wrote: > the 8080 was an upgraded 8008 Also note the 8008 instruction set originated at Compuer Terminal Corporation (later Datapoint), for use as a text terminal controller. I'd say it's an OK design for that purpose... From tytso at mit.edu Thu Sep 27 01:03:52 2018 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Wed, 26 Sep 2018 11:03:52 -0400 Subject: [TUHS] SPARC is CRAPS spelled backwards. In-Reply-To: <7wsh1wdadf.fsf@junk.nocrew.org> References: <1686170E-4323-4BDF-B95C-8A6B3FFD5288@gmail.com> <20180924194647.GA29897@server.rulingia.com> <20180926062000.GC29897@server.rulingia.com> <7wsh1wdadf.fsf@junk.nocrew.org> Message-ID: <20180926150352.GE3321@thunk.org> On Wed, Sep 26, 2018 at 06:46:20AM +0000, Lars Brinkhoff wrote: > Peter Jeremy wrote: > > the 8080 was an upgraded 8008 > > Also note the 8008 instruction set originated at Compuer Terminal > Corporation (later Datapoint), for use as a text terminal controller. > I'd say it's an OK design for that purpose... That's not that only CPU for which this was true. The IBM PC/RT (e.g., the 6150) CPU was originally designed to be used as a typewriter controller. It was a RISC design which was approximately 3 times faster than a Microvax, which meant that it was quite popular for students using MIT's Project Athenna who needed to run Scribe or TeX/LaTeX. :-) - Ted From paul.winalski at gmail.com Thu Sep 27 01:32:47 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Wed, 26 Sep 2018 11:32:47 -0400 Subject: [TUHS] SPARC is CRAPS spelled backwards. In-Reply-To: <20180926150352.GE3321@thunk.org> References: <1686170E-4323-4BDF-B95C-8A6B3FFD5288@gmail.com> <20180924194647.GA29897@server.rulingia.com> <20180926062000.GC29897@server.rulingia.com> <7wsh1wdadf.fsf@junk.nocrew.org> <20180926150352.GE3321@thunk.org> Message-ID: On 9/26/18, Theodore Y. Ts'o wrote: > > That's not that only CPU for which this was true. The IBM PC/RT > (e.g., the 6150) CPU was originally designed to be used as a > typewriter controller. The CPU in the IBM 5100 was a 16-bit processor originally designed for use in System/370 I/O peripheral controllers. -Paul W. From henry.r.bent at gmail.com Thu Sep 27 01:44:11 2018 From: henry.r.bent at gmail.com (Henry Bent) Date: Wed, 26 Sep 2018 11:44:11 -0400 Subject: [TUHS] SPARC is CRAPS spelled backwards. In-Reply-To: <20180926062000.GC29897@server.rulingia.com> References: <1686170E-4323-4BDF-B95C-8A6B3FFD5288@gmail.com> <20180924194647.GA29897@server.rulingia.com> <20180926062000.GC29897@server.rulingia.com> Message-ID: On Wed, 26 Sep 2018 at 02:21, Peter Jeremy wrote: > > An 8-bit memory bus means half as many RAM chips and buffers. Keep in mind > that the IBM 5150 was intentionally crippled to ensure it didn't compete > with > IBM's low-end minis. > Did the 5150 have a UNIX available anywhere near its launch date? I know that it had DOS, CP/M-86, and the UCSD p-System relatively early on. It's not clear to me whether Xenix ever supported the original PC; were there other early porting efforts? -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From pechter at gmail.com Thu Sep 27 02:02:43 2018 From: pechter at gmail.com (William Pechter) Date: Wed, 26 Sep 2018 12:02:43 -0400 Subject: [TUHS] Fwd: Re: SPARC is CRAPS spelled backwards. In-Reply-To: References: <1686170E-4323-4BDF-B95C-8A6B3FFD5288@gmail.com> <20180924194647.GA29897@server.rulingia.com> <20180926062000.GC29897@server.rulingia.com> Message-ID: <8aef3a1c-f21d-4909-9df2-b9ed6c5fc562.maildroid@localhost> Should have copied the list... -----Original Message----- From: William Pechter To: Henry Bent Sent: Wed, 26 Sep 2018 11:59 Subject: Re: [TUHS] SPARC is CRAPS spelled backwards. There was Xenix-86 which ran on the AT&T 6300, and IBM PC/XT. I ran it on an 8MHz NEC V30 cpu on the 6300. I would love to install it on my Panasonic Sr. Partner but lost the install key. -----Original Message----- From: Henry Bent To: TUHS main list Sent: Wed, 26 Sep 2018 11:45 Subject: Re: [TUHS] SPARC is CRAPS spelled backwards. On Wed, 26 Sep 2018 at 02:21, Peter Jeremy wrote: > > An 8-bit memory bus means half as many RAM chips and buffers. Keep in mind > that the IBM 5150 was intentionally crippled to ensure it didn't compete > with > IBM's low-end minis. > Did the 5150 have a UNIX available anywhere near its launch date? I know that it had DOS, CP/M-86, and the UCSD p-System relatively early on. It's not clear to me whether Xenix ever supported the original PC; were there other early porting efforts? -Henry From mutiny.mutiny at india.com Thu Sep 27 04:24:01 2018 From: mutiny.mutiny at india.com (Donald ODona) Date: Wed, 26 Sep 2018 18:24:01 +0000 (UTC) Subject: [TUHS] SPARC is CRAPS spelled backwards. In-Reply-To: References: <1686170E-4323-4BDF-B95C-8A6B3FFD5288@gmail.com> <20180924194647.GA29897@server.rulingia.com> <20180926062000.GC29897@server.rulingia.com>, Message-ID: <190720804.17371.1537986240922.JavaMail.tomcat@india-live-be02> At 26 Sep 2018 15:45:25 +0000 (+00:00) from Henry Bent : > Did the 5150 have a UNIX available anywhere near its launch date? I know > that it had DOS, CP/M-86, and the UCSD p-System relatively early on. It's > not clear to me whether Xenix ever supported the original PC; were there > other early porting efforts? read more here: http://www.softpanorama.org/People/Torvalds/Finland_period/xenix_microsoft_shortlived_love_affair_with_unix.shtml From dfawcus+lists-tuhs at employees.org Thu Sep 27 05:31:55 2018 From: dfawcus+lists-tuhs at employees.org (Derek Fawcus) Date: Wed, 26 Sep 2018 20:31:55 +0100 Subject: [TUHS] SPARC is CRAPS spelled backwards. In-Reply-To: <20180925144908.GA2933@thunk.org> References: <20180925121212.C179D18C08D@mercury.lcs.mit.edu> <20180925144908.GA2933@thunk.org> Message-ID: <20180926193155.GA88914@bugle.employees.org> On Tue, Sep 25, 2018 at 10:49:08AM -0400, Theodore Y. Ts'o wrote: > > Windows and Microsoft Office still uses UTF-16.... As do Mac's, and probably iOS; the Foundation framework uses it for NSString. DF From pnr at planet.nl Thu Sep 27 17:35:44 2018 From: pnr at planet.nl (Paul Ruizendaal) Date: Thu, 27 Sep 2018 09:35:44 +0200 Subject: [TUHS] SPARC is CRAPS spelled backwards. Message-ID: > Did the 5150 have a UNIX available anywhere near its launch date? I know > that it had DOS, CP/M-86, and the UCSD p-System relatively early on. It's > not clear to me whether Xenix ever supported the original PC; were there > other early porting efforts? The first version of Venix-86 ran on the PC/XT, almost a 5150, in May 83. It was V7 based. I think it was the first Unix on a PC. Heinz Lycklama (who did Unix LSX and MX at Bell labs in the 70’s) did PC/IX about a year later, based on Sys III. This was marketed by IBM. Based on the early Xenix porting chart here http://seefigure1.com/2014/04/15/xenixtime.html , a PC/XT version of Xenix appeared around the same time as PC/IX. However, if the chart is correct there may have been Xenix versions for other 8086-based machines a year before that. Note that in this chart the “Xenix 2.0” and “Xenix 3.0” labels refer to MS internal versions, i.e. these numbers are not to be confused with the marketing labels IBM PC Xenix 2.0 and 3.0. These versions are a hole in the TUHS archive (unless they are in the confidential archive). It would be wonderful if MS would open up pre-1984 Xenix on the occasion of Unix 50th. These builds would well illustrate the broad Unix portability, which was unique at the time. Paul From arrigo at alchemistowl.org Thu Sep 27 17:52:51 2018 From: arrigo at alchemistowl.org (Arrigo Triulzi) Date: Thu, 27 Sep 2018 09:52:51 +0200 Subject: [TUHS] SPARC is CRAPS spelled backwards. In-Reply-To: References: Message-ID: <93A6E956-D376-409D-995A-785534D7E5D0@alchemistowl.org> On 27 Sep 2018, at 09:35, Paul Ruizendaal wrote: >> Did the 5150 have a UNIX available anywhere near its launch date? I know >> that it had DOS, CP/M-86, and the UCSD p-System relatively early on. It's >> not clear to me whether Xenix ever supported the original PC; were there >> other early porting efforts? > > The first version of Venix-86 ran on the PC/XT, almost a 5150, in May 83. It was V7 based. I think it was the first Unix on a PC. > > Heinz Lycklama (who did Unix LSX and MX at Bell labs in the 70’s) did PC/IX about a year later, based on Sys III. This was marketed by IBM. > > Based on the early Xenix porting chart here http://seefigure1.com/2014/04/15/xenixtime.html , a PC/XT version of Xenix appeared around the same time as PC/IX. However, if the chart is correct there may have been Xenix versions for other 8086-based machines a year before that. Note that in this chart the “Xenix 2.0” and “Xenix 3.0” labels refer to MS internal versions, i.e. these numbers are not to be confused with the marketing labels IBM PC Xenix 2.0 and 3.0. I am almost certain of the existence of a Unix variant for the Olivetti M24 which was an 8086-equipped PC (The M24 was rebranded as an AT&T 6300 if memory serves me correctly). It might have been Xenix or Venix but I honestly cannot remember it as I certainly recall Xenix floppies & manuals making the rounds later on 286s in Italy but I only faintly recall the M24 Unix. Arrigo From ca6c at bitmessage.ch Thu Sep 27 22:08:54 2018 From: ca6c at bitmessage.ch (=?utf-8?B?Q8OhZw==?=) Date: Thu, 27 Sep 2018 07:08:54 -0500 Subject: [TUHS] The origin of /home Message-ID: <20180927120854.u8rei%ca6c@bitmessage.ch> Hi, The earliest I've found to be in the FHS from '94. Are there any earlier examples of a home directory being at /home instead of /usr/$(user)? Are there any current Unix systems that don't use /home by default (except OSX)? Does anybody here do it intentionally? Also, what was the rationale of moving the directory to /home? Thanks! -- caóc From alec.muffett at gmail.com Thu Sep 27 22:30:15 2018 From: alec.muffett at gmail.com (Alec Muffett) Date: Thu, 27 Sep 2018 13:30:15 +0100 Subject: [TUHS] The origin of /home In-Reply-To: <20180927120854.u8rei%ca6c@bitmessage.ch> References: <20180927120854.u8rei%ca6c@bitmessage.ch> Message-ID: Opinion, predating that era: I believe that the driver for /home was automounter, because of the complexity of referencing local and remote /export/foo/whatever/username paths consistently across a large NFS-enabled university deployment with many different platforms and individual systems. On Thu, 27 Sep 2018, 13:11 Cág, wrote: > Hi, > > The earliest I've found to be in the FHS from '94. Are there any earlier > examples of a home directory being at /home instead of /usr/$(user)? Are > there any current Unix systems that don't use /home by default (except > OSX)? Does anybody here do it intentionally? Also, what was the > rationale of moving the directory to /home? > > Thanks! > > -- > caóc > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mutiny.mutiny at india.com Thu Sep 27 22:58:49 2018 From: mutiny.mutiny at india.com (Donald ODona) Date: Thu, 27 Sep 2018 12:58:49 +0000 (UTC) Subject: [TUHS] The origin of /home In-Reply-To: <20180927120854.u8rei%ca6c@bitmessage.ch> References: <20180927120854.u8rei%ca6c@bitmessage.ch> Message-ID: <633187202.18875.1538053129435.JavaMail.tomcat@india-live-be04> At 27 Sep 2018 12:11:15 +0000 (+00:00) from "Cág" : > Hi, > Also, what was the > rationale of moving the directory to /home? originally /usr, placed on a separate disk, was what became /home much later. Then disk space of / was running out and more an more applications and libs were moved to the /usr device. Much later in the 80ths much more disk space was available and a separate /home was created. Exacly when I don't know, but there was no /home in Ed. 7 but System V release 3 had it already. From jpl.jpl at gmail.com Thu Sep 27 23:54:29 2018 From: jpl.jpl at gmail.com (John P. Linderman) Date: Thu, 27 Sep 2018 09:54:29 -0400 Subject: [TUHS] The origin of /home In-Reply-To: <633187202.18875.1538053129435.JavaMail.tomcat@india-live-be04> References: <20180927120854.u8rei%ca6c@bitmessage.ch> <633187202.18875.1538053129435.JavaMail.tomcat@india-live-be04> Message-ID: More opinion, unencumbered by facts. /usr contained many sudirectories, like /usr/bin and /usr/lib, that were essential to an operational OS. Home directories, on the other hand, persisted unchanged when new releases of an OS were installed. Some of us had symlinks from /usr into a separate file system to make the distinction easier to maintain across releases. On Thu, Sep 27, 2018 at 8:58 AM, Donald ODona wrote: > At 27 Sep 2018 12:11:15 +0000 (+00:00) from "Cág" : > > Hi, > > > Also, what was the > > rationale of moving the directory to /home? > originally /usr, placed on a separate disk, was what became /home much > later. Then disk space of / was running out and more an more applications > and libs were moved to the /usr device. > Much later in the 80ths much more disk space was available and a separate > /home was created. Exacly when I don't know, but there was no /home in Ed. > 7 but System V release 3 had it already. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Fri Sep 28 00:09:13 2018 From: ron at ronnatalie.com (Ronald Natalie) Date: Thu, 27 Sep 2018 10:09:13 -0400 Subject: [TUHS] The origin of /home In-Reply-To: References: <20180927120854.u8rei%ca6c@bitmessage.ch> <633187202.18875.1538053129435.JavaMail.tomcat@india-live-be04> Message-ID: <2F919C1F-3C91-4083-9B46-B5A6D28A1D54@ronnatalie.com> Symlinks? Surely you jest. Not in Version 7 or System V. The idea was to keep root small for convenience in various stages of setup. /usr was indeed intended to be a separate disk. If you look at the early distributions like V7, you’ll find the /usr image was a separate tape file. > On Sep 27, 2018, at 9:54 AM, John P. Linderman wrote: > > More opinion, unencumbered by facts. /usr contained many sudirectories, like /usr/bin and /usr/lib, that were essential to an operational OS. Home directories, on the other hand, persisted unchanged when new releases of an OS were installed. Some of us had symlinks from /usr into a separate file system to make the distinction easier to maintain across releases. > > On Thu, Sep 27, 2018 at 8:58 AM, Donald ODona > wrote: > At 27 Sep 2018 12:11:15 +0000 (+00:00) from "Cág" >: > > Hi, > > > Also, what was the > > rationale of moving the directory to /home? > originally /usr, placed on a separate disk, was what became /home much later. Then disk space of / was running out and more an more applications and libs were moved to the /usr device. > Much later in the 80ths much more disk space was available and a separate /home was created. Exacly when I don't know, but there was no /home in Ed. 7 but System V release 3 had it already. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nobozo at gmail.com Fri Sep 28 00:18:48 2018 From: nobozo at gmail.com (Jon Forrest) Date: Thu, 27 Sep 2018 07:18:48 -0700 Subject: [TUHS] The origin of /home In-Reply-To: References: <20180927120854.u8rei%ca6c@bitmessage.ch> <633187202.18875.1538053129435.JavaMail.tomcat@india-live-be04> Message-ID: Another reason why the home directory part of /usr was made into /home is because after doing so, it was possible to mount /usr read-only, and supply it from a server. This was the so-called "dataless" method. I wrote a short email message summarizing what we were doing with this in UC Berkeley Comp. Sci., and mentioning a paper I had written describing how to create a "dataless" environment for DEC's OSF1 operating system (see http://beowulf.org/pipermail/beowulf/2008-July/022210.html). Jon Forrest From arrigo at alchemistowl.org Fri Sep 28 00:28:59 2018 From: arrigo at alchemistowl.org (Arrigo Triulzi) Date: Thu, 27 Sep 2018 16:28:59 +0200 Subject: [TUHS] The origin of /home In-Reply-To: References: <20180927120854.u8rei%ca6c@bitmessage.ch> <633187202.18875.1538053129435.JavaMail.tomcat@india-live-be04> Message-ID: <36C6F216-490E-4DE4-B5EF-CED26899542F@alchemistowl.org> > On 27 Sep 2018, at 16:18, Jon Forrest wrote: > Another reason why the home directory part of /usr was made into > /home is because after doing so, it was possible to mount /usr > read-only, and supply it from a server. This was the so-called > "dataless" method. I wrote a short email message summarizing > what we were doing with this in UC Berkeley Comp. Sci., and mentioning > a paper I had written describing how to create a "dataless" > environment for DEC's OSF1 operating system (see > http://beowulf.org/pipermail/beowulf/2008-July/022210.html). Not to be pedantic but the OSF/1 “dataless” trick is from 1993 in Jon Forrest’s writeup: https://groups.google.com/d/msg/comp.unix.osf.osf1/-s1xW80zXPE/OGENDhH2Sc0J As one of the three people figuring out what DEC had told us was impossible I’m pretty sure we were the first - our DEC 3000/400s with OSF/1 T1.0 did not have enough disk space so we struggled to get our network operational serving /usr and /home from the “big” DEC 3000/600 which had two disks (one of which was /home). Cheers, Arrigo From jnc at mercury.lcs.mit.edu Fri Sep 28 00:31:08 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 27 Sep 2018 10:31:08 -0400 (EDT) Subject: [TUHS] The origin of /home Message-ID: <20180927143108.C05D418C08E@mercury.lcs.mit.edu> > From: Jon Forrest > Another reason why the home directory part of /usr was made into /home > is because after doing so, it was possible to mount /usr read-only, and > supply it from a server. The real issue is that /usr contained stuff which wasn't true 'user data' - e.g. /usr/bin. The reasons for that must have seemed good at the time it started, but it was IMO a mistake. (Disgression about partitions, physical packs, etc elided for now.) Noel From crossd at gmail.com Fri Sep 28 00:47:21 2018 From: crossd at gmail.com (Dan Cross) Date: Thu, 27 Sep 2018 10:47:21 -0400 Subject: [TUHS] The origin of /home In-Reply-To: <20180927120854.u8rei%ca6c@bitmessage.ch> References: <20180927120854.u8rei%ca6c@bitmessage.ch> Message-ID: On Thu, Sep 27, 2018 at 8:11 AM Cág wrote: > The earliest I've found to be in the FHS from '94. Are there any earlier > examples of a home directory being at /home instead of /usr/$(user)? Are > there any current Unix systems that don't use /home by default (except > OSX)? Does anybody here do it intentionally? Also, what was the > rationale of moving the directory to /home? > Naming on Unix (and derived systems) is one of those things that has always had different schools of thought applied to it. As has been pointed out, the original place for what we now refer to as "home" directories was /usr, though this may not be entirely accurate: it's my belief that PDP-7 Unix had separate directories for each user, but I don't think these were nested under a common 'usr' directory. Someone please correct me if I'm wrong. The original impetus for moving things around was surely space considerations on early disk devices: Not only was space limited, but filesystems couldn't span devices (in the /dev sense) and often *partition* sizes on a single volume were fixed by the driver for the underlying storage device. In such a rigidly defined world, varying conventions would necessary evolve to work around the inevitable limitations, particular in sites with lots of users like universities and production-focused corporate groups, including the degeneration of `/usr` as purely holding user directories. One can easily imagine the conversation: "we're out of room on the root filesystem and I can't install this new program in /bin..." "Hmm. Well, we've got space in /usr: create /usr/bin and we'll fix up the difference in the shell by incorporating some notion of a search path for binaries." Similarly with lib, man, and all the rest of it. It's interesting that now /usr is most often devoid of user data; the intent behind the name seems to be justified after the fact by asserting that it contains programs, libraries and other data of interest to users (as opposed to administrators). That explains why other things starting encroaching and eventually took over on /usr, but I think the provenance of "/home" specifically relates to an etymological question. At some point, the "user's directory" as denoted in /etc/passwd became known as the "home directory." If that was common vernacular by the time that `/home` came around as a convention, then it seems a logical name stemming from that usage. The more intriguing possibility from the antiquarian point of view is whether someone coined "/home" and then THAT led to the rise of the "home directory" nomenclature. man(5) on 7th Edition calls that field the user's "initial working directory." The first time I see it called "home directory" in my cursory search is in 4.3 Reno. I intentionally eschew /home on a few systems. 4.4BSD had a convention of placing user home directories in /a, /b, etc. 4.4BSD-Lite also had /var/users. Both of which I occasionally use. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Fri Sep 28 01:33:53 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 27 Sep 2018 11:33:53 -0400 (EDT) Subject: [TUHS] The origin of /home Message-ID: <20180927153353.F354118C08E@mercury.lcs.mit.edu> > From: Dan Cross > particular in sites with lots of users like universities and > production-focused corporate groups The existence of /usr, /usr/bin, /etc, /lib, etc dates back to the Research group at Bell, so I don't think we can look to these other environments for an explanation. > "Hmm. Well, we've got space in /usr: create /usr/bin I seem to recall reading (don't recall where, OTTOMY) an explanation for the creation of /usr/bin, and I think it was performance related; IIRC the issue was that they wanted to keep the directory size down (both for disk block caching, and search time, reasons). Or maybe that was later on, and it was originally created for 'user-maintained' ancillary programs (another vague memory)? > The more intriguing possibility from the antiquarian point of view is > whether someone coined "/home" and then THAT led to the rise of the "home > directory" nomenclature. My memory is that the term "home directory" predates /home - perhaps on other OS's such as TOPS-20, but I don't have time to research that. (I did look quickly in the Multics docs, and it has 'working directory', i.e. current dir - but it refers to the home dir as 'original WD', i.e. the WD at the time of login.) Noel From nobozo at gmail.com Fri Sep 28 01:36:35 2018 From: nobozo at gmail.com (Jon Forrest) Date: Thu, 27 Sep 2018 08:36:35 -0700 Subject: [TUHS] The origin of /home In-Reply-To: <36C6F216-490E-4DE4-B5EF-CED26899542F@alchemistowl.org> References: <20180927120854.u8rei%ca6c@bitmessage.ch> <633187202.18875.1538053129435.JavaMail.tomcat@india-live-be04> <36C6F216-490E-4DE4-B5EF-CED26899542F@alchemistowl.org> Message-ID: <4caca587-4945-c8be-5a35-c9f0ecfdd08b@gmail.com> On 9/27/2018 7:28 AM, Arrigo Triulzi wrote: > Not to be pedantic but the OSF/1 “dataless” trick is from 1993 in Jon > Forrest’s writeup: Right, and I am that Jon Forrest > https://groups.google.com/d/msg/comp.unix.osf.osf1/-s1xW80zXPE/OGENDhH2Sc0J > > As one of the three people figuring out what DEC had told us was > impossible I’m pretty sure we were the first - our DEC 3000/400s with > OSF/1 T1.0 did not have enough disk space so we struggled to get our > network operational serving /usr and /home from the “big” DEC > 3000/600 which had two disks (one of which was /home). It's been a while, but what I remember is that DEC actually published their own method for doing this but it was surprisingly cumbersome. What I described was incredibly simple but effective. I ran many Alphas this way with no problems at all. Jon From arrigo at alchemistowl.org Fri Sep 28 01:54:51 2018 From: arrigo at alchemistowl.org (Arrigo Triulzi) Date: Thu, 27 Sep 2018 17:54:51 +0200 Subject: [TUHS] The origin of /home In-Reply-To: <4caca587-4945-c8be-5a35-c9f0ecfdd08b@gmail.com> References: <20180927120854.u8rei%ca6c@bitmessage.ch> <633187202.18875.1538053129435.JavaMail.tomcat@india-live-be04> <36C6F216-490E-4DE4-B5EF-CED26899542F@alchemistowl.org> <4caca587-4945-c8be-5a35-c9f0ecfdd08b@gmail.com> Message-ID: <309587CA-4C65-4AFA-ADFF-0E99B430D191@alchemistowl.org> On 27 Sep 2018, at 17:36, Jon Forrest wrote: > Right, and I am that Jon Forrest Well, made a fool of myself there! > It's been a while, but what I remember is that DEC actually published > their own method for doing this but it was surprisingly cumbersome. > What I described was incredibly simple but effective. I ran many > Alphas this way with no problems at all. On OSF/1 T1.0, which is what we got shipped with our first Alphas, we were categorically told by REO that we were on our own. At the time there were four Alphas in the UK: three were ours and one was at REO running OpenVMS in the morning and OSF/1 in the afternoon (or vice-versa) and we spent a long weekend napping on the machine room floor and on caffeine trying to figure out how to get /usr mounted despite the SIA startup script as we had no choice and the cluster needed to be up as it had cost a small fortune. The later DEC solution I recall requiring more disk space on the clients, which we didn’t have, but I’m sure that later ships with sufficient disk space had less issues. Another weekend was spent getting TeX and LaTeX running with ghostscript MX’d from the Ultrix MIPS binary as we just couldn’t get it to compile. That it even worked using MX remains one of the most beautiful surprises of that install. Arrigo From arnold at skeeve.com Fri Sep 28 03:20:11 2018 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 27 Sep 2018 11:20:11 -0600 Subject: [TUHS] The origin of /home In-Reply-To: References: <20180927120854.u8rei%ca6c@bitmessage.ch> Message-ID: <201809271720.w8RHKBNh031105@freefriends.org> Dan Cross wrote: > At some point, the "user's directory" as denoted in /etc/passwd became > known as the "home directory." If that was common vernacular by the time > that `/home` came around as a convention, then it seems a logical name > stemming from that usage. It most definitely was common usage before /home came along. As I recall it, in the System V Release 4 time frame, AT&T, Sun, DEC and UCB agreed on the division of things into /home, /usr, and /var, with the impetus being that /usr could be mounted read-only from a single file server (saving many copies of the same files), /home mounted read-write (or automounted) and /var holding things that were peculiar to each system but read-write, such as log files and temporary files. Diskless workstations, or workstations with very small disks for holding the root filesystem only, were very popular at the time. Arnold From mutiny.mutiny at india.com Fri Sep 28 03:33:03 2018 From: mutiny.mutiny at india.com (Donald ODona) Date: Thu, 27 Sep 2018 17:33:03 +0000 (UTC) Subject: [TUHS] The origin of /home In-Reply-To: <633187202.18875.1538053129435.JavaMail.tomcat@india-live-be04> References: <20180927120854.u8rei%ca6c@bitmessage.ch>, <633187202.18875.1538053129435.JavaMail.tomcat@india-live-be04> Message-ID: <2042420101.18686.1538069583443.JavaMail.tomcat@india-live-be03> At 27 Sep 2018 12:59:50 +0000 (+00:00) from Donald ODona : to the /usr device. > Much later in the 80ths much more disk space was available and a separate /home was created. Exacly when I don't know, but there was no /home in Ed. 7 but System V release 3 had it already. 4.3 BSD had it, as I found out, after login in a few sconds ago. 4.3BSD was released in June 1986. Thus the /home appeared in between 1979 (Ed 7) and 1986. From nobozo at gmail.com Fri Sep 28 04:49:02 2018 From: nobozo at gmail.com (Jon Forrest) Date: Thu, 27 Sep 2018 11:49:02 -0700 Subject: [TUHS] The origin of /home In-Reply-To: <309587CA-4C65-4AFA-ADFF-0E99B430D191@alchemistowl.org> References: <20180927120854.u8rei%ca6c@bitmessage.ch> <633187202.18875.1538053129435.JavaMail.tomcat@india-live-be04> <36C6F216-490E-4DE4-B5EF-CED26899542F@alchemistowl.org> <4caca587-4945-c8be-5a35-c9f0ecfdd08b@gmail.com> <309587CA-4C65-4AFA-ADFF-0E99B430D191@alchemistowl.org> Message-ID: <52fac873-cd89-420c-c15f-b67df83aa0d3@gmail.com> On 9/27/2018 8:54 AM, Arrigo Triulzi wrote: > On 27 Sep 2018, at 17:36, Jon Forrest wrote: >> Right, and I am that Jon Forrest > > Well, made a fool of myself there! That's OK. I do things like that at least once a day. > On OSF/1 T1.0, which is what we got shipped with our first Alphas, we were > categorically told by REO that we were on our own. Those were the days when DEC would tell you all kinds of things. I remember in the late 80s they told me that TCP/IP wasn't going to catch on, and that I should stick with DecNet. > The later DEC solution I recall requiring more disk space on the clients, > which we didn’t have, but I’m sure that later ships with sufficient disk space had less issues. I actually started my dataless design back when we were running Ultrix. It worked fine there too, although back then 10Mbs networking was common so it wasn't super speedy. Of course, neither were the workstations. The document I quoted also described how the CS department used an Auspex file server to serve what we called the "Software Warehouse", which was a collection of open source software that we built for all the popular architectures then. Jon From beebe at math.utah.edu Fri Sep 28 04:03:26 2018 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Thu, 27 Sep 2018 12:03:26 -0600 Subject: [TUHS] SPARC is CRAPS spelled backwards. Message-ID: As a followup to discussions on this thread about hardware architectures, some of you may be interested in this new letter published today: Letters to the editor: Hennessy and Patterson on the roots of RISC Comm. ACM 61(10) 6 (2018) https://doi.org/10.1145/3273019 http://delivery.acm.org/10.1145/3280000/3273019/p6-friedman.pdf The short two-paragraph letter is from Fred Brooks, noted computer architect, author, and computer scientist. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From cym224 at gmail.com Fri Sep 28 05:34:38 2018 From: cym224 at gmail.com (Nemo) Date: Thu, 27 Sep 2018 15:34:38 -0400 Subject: [TUHS] SPARC is CRAPS spelled backwards. In-Reply-To: References: Message-ID: On 27/09/2018, Nelson H. F. Beebe wrote: > As a followup to discussions on this thread about hardware > architectures, some of you may be interested in this new letter > published today: > > Letters to the editor: Hennessy and Patterson on the roots of RISC > Comm. ACM 61(10) 6 (2018) > https://doi.org/10.1145/3273019 > http://delivery.acm.org/10.1145/3280000/3273019/p6-friedman.pdf Also of interest may be the video "SPARC at 25" (https://www.youtube.com/watch?v=w3ukXhEaYGI ), wherein Patterson, Joy, and others discuss SPARC. (Joy's comment on register windows is interesting and matches Brooks' remark.) N. > > The short two-paragraph letter is from Fred Brooks, noted computer > architect, author, and computer scientist. > > ------------------------------------------------------------------------------- > - Nelson H. F. Beebe Tel: +1 801 581 5254 > - > - University of Utah FAX: +1 801 581 4148 > - > - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu > - > - 155 S 1400 E RM 233 beebe at acm.org > beebe at computer.org - > - Salt Lake City, UT 84112-0090, USA URL: > http://www.math.utah.edu/~beebe/ - > ------------------------------------------------------------------------------- > From crossd at gmail.com Fri Sep 28 06:15:05 2018 From: crossd at gmail.com (Dan Cross) Date: Thu, 27 Sep 2018 16:15:05 -0400 Subject: [TUHS] The origin of /home In-Reply-To: <20180927153353.F354118C08E@mercury.lcs.mit.edu> References: <20180927153353.F354118C08E@mercury.lcs.mit.edu> Message-ID: On Thu, Sep 27, 2018 at 11:34 AM Noel Chiappa wrote: > > From: Dan Cross > > > particular in sites with lots of users like universities and > > production-focused corporate groups > > The existence of /usr, /usr/bin, /etc, /lib, etc dates back to the Research > group at Bell, so I don't think we can look to these other environments > for an > explanation. > Sorry, I was (very) unclear in this point. I was referring to two separate things: 1) Why things were spread out across multiple filesystems (space and/or performance considerations dating from the Bell Labs days), and 2) The notion that rigid structures built in at a very low level would naturally give rise to local naming conventions as "large" sites grew beyond the limitations built into the system. E.g., /udd/u1 etc vs /home vs /usr/users vs /net/somehostname vs /var/users vs whatever. As a concrete example is the use of name-dependent hierarchical home directory paths like "/home/c/r/cross" because one tried to put too many directories into /home (I have actually seen the UFS directory entry limit hit in /home on a machine that had >32k users). Anyway, eventually through whatever accident of history "/home" seems to have won as a de facto standard. > "Hmm. Well, we've got space in /usr: create /usr/bin > > I seem to recall reading (don't recall where, OTTOMY) an explanation for > the > creation of /usr/bin, and I think it was performance related; IIRC the > issue > was that they wanted to keep the directory size down (both for disk block > caching, and search time, reasons). Or maybe that was later on, and it was > originally created for 'user-maintained' ancillary programs (another vague > memory)? > I think the latter might be a justification-after-the-fact: /usr as the filesystem containing stuff of interest to the users. > The more intriguing possibility from the antiquarian point of view is > > whether someone coined "/home" and then THAT led to the rise of the > "home > > directory" nomenclature. > > My memory is that the term "home directory" predates /home - perhaps on > other > OS's such as TOPS-20, but I don't have time to research that. (I did look > quickly in the Multics docs, and it has 'working directory', i.e. current > dir > - but it refers to the home dir as 'original WD', i.e. the WD at the time > of > login.) > If I recall correctly, the mappings from "users" on TOPS-20 to directories is an injection, but I don't think they used the "home directory" nomenclature. Certainly the analogy with one's directory as home is clear enough. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Fri Sep 28 06:30:25 2018 From: crossd at gmail.com (Dan Cross) Date: Thu, 27 Sep 2018 16:30:25 -0400 Subject: [TUHS] SPARC is CRAPS spelled backwards. In-Reply-To: References: Message-ID: On Thu, Sep 27, 2018 at 3:16 PM Nelson H. F. Beebe wrote: > As a followup to discussions on this thread about hardware > architectures, some of you may be interested in this new letter > published today: > > Letters to the editor: Hennessy and Patterson on the roots of RISC > Comm. ACM 61(10) 6 (2018) > https://doi.org/10.1145/3273019 > http://delivery.acm.org/10.1145/3280000/3273019/p6-friedman.pdf Aside: This is taking an inordinately long time to download from the ACM. It must be "the TUHS effect." - Dan C. > The short two-paragraph letter is from Fred Brooks, noted computer > architect, author, and computer scientist. > > > ------------------------------------------------------------------------------- > - Nelson H. F. Beebe Tel: +1 801 581 5254 > - > - University of Utah FAX: +1 801 581 4148 > - > - Department of Mathematics, 110 LCB Internet e-mail: > beebe at math.utah.edu - > - 155 S 1400 E RM 233 beebe at acm.org > beebe at computer.org - > - Salt Lake City, UT 84112-0090, USA URL: > http://www.math.utah.edu/~beebe/ - > > ------------------------------------------------------------------------------- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ca6c at bitmessage.ch Fri Sep 28 06:42:37 2018 From: ca6c at bitmessage.ch (=?utf-8?B?Q8OhZw==?=) Date: Thu, 27 Sep 2018 15:42:37 -0500 Subject: [TUHS] The origin of /home In-Reply-To: References: <20180927120854.u8rei%ca6c@bitmessage.ch> Message-ID: <20180927204237.h3kQJ%ca6c@bitmessage.ch> Thanks for such an interesting and informative answer, Mr. Cross. Dan Cross wrote: > 4.4BSD had a convention of placing user home directories in /a, /b, > etc. Do I understand it correctly: they were in just "slash a/b/etc" in root? Not /home/a or /usr/a but just /a? > 4.4BSD-Lite also had /var/users. Was it /var/users/$(user) or /var/$(user)? To everyone: thanks for all the answers, it's always interesting to read such things. I try not to miss a single mail after signing up for the list. This question actually came up long ago when I first tried Plan 9, which, as you know, has the directory in /usr, and it was released in 90s, after 4.4BSD. Of course, Plan 9 is(not) (Research) Unix, and doesn't have a root user, and apparently has a different rationale behind it -- if I'm not mistaken, it has bin, lib and something else there, none of which are usually present in /home these days, even bin is usually in /usr/local. -- caóc From steve at quintile.net Fri Sep 28 06:50:58 2018 From: steve at quintile.net (Steve Simon) Date: Thu, 27 Sep 2018 21:50:58 +0100 Subject: [TUHS] /home Message-ID: At college we had /h but that may be an interdata/edition7 thing. mine was /h/beng4/ssimon. each course/year was in a separate disk partition - if group filled their partition other groups could still work. -Steve From ca6c at bitmessage.ch Fri Sep 28 06:51:31 2018 From: ca6c at bitmessage.ch (=?utf-8?B?Q8OhZw==?=) Date: Thu, 27 Sep 2018 15:51:31 -0500 Subject: [TUHS] SPARC is CRAPS spelled backwards. In-Reply-To: References: Message-ID: <20180927205131.TuTBR%ca6c@bitmessage.ch> Dan Cross wrote: >> Letters to the editor: Hennessy and Patterson on the roots of RISC >> Comm. ACM 61(10) 6 (2018) >> https://doi.org/10.1145/3273019 >> http://delivery.acm.org/10.1145/3280000/3273019/p6-friedman.pdf > > Aside: This is taking an inordinately long time to download from the ACM. > It must be "the TUHS effect." For me it doesn't even work: "An error occurred while processing your request." -- caóc From henry.r.bent at gmail.com Fri Sep 28 07:01:15 2018 From: henry.r.bent at gmail.com (Henry Bent) Date: Thu, 27 Sep 2018 17:01:15 -0400 Subject: [TUHS] SPARC is CRAPS spelled backwards. In-Reply-To: <20180927205131.TuTBR%ca6c@bitmessage.ch> References: <20180927205131.TuTBR%ca6c@bitmessage.ch> Message-ID: On Thu, 27 Sep 2018 at 16:52, Cág wrote: > Dan Cross wrote: > > >> Letters to the editor: Hennessy and Patterson on the roots of > RISC > >> Comm. ACM 61(10) 6 (2018) > >> https://doi.org/10.1145/3273019 > >> http://delivery.acm.org/10.1145/3280000/3273019/p6-friedman.pdf > > > > Aside: This is taking an inordinately long time to download from the ACM. > > It must be "the TUHS effect." > > For me it doesn't even work: > "An error occurred while processing your request." > The direct PDF link that Nelson posted doesn't work, but if you go to the first link and select "PDF" it should work. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From ca6c at bitmessage.ch Fri Sep 28 07:04:19 2018 From: ca6c at bitmessage.ch (=?utf-8?B?Q8OhZw==?=) Date: Thu, 27 Sep 2018 16:04:19 -0500 Subject: [TUHS] SPARC is CRAPS spelled backwards. In-Reply-To: References: <20180927205131.TuTBR%ca6c@bitmessage.ch> Message-ID: <20180927210419.KyQbu%ca6c@bitmessage.ch> Henry Bent wrote: > The direct PDF link that Nelson posted doesn't work, but if you go to the > first link and select "PDF" it should work. Thanks! Is it intended? -- caóc From crossd at gmail.com Fri Sep 28 07:07:30 2018 From: crossd at gmail.com (Dan Cross) Date: Thu, 27 Sep 2018 17:07:30 -0400 Subject: [TUHS] The origin of /home In-Reply-To: <20180927204237.h3kQJ%ca6c@bitmessage.ch> References: <20180927120854.u8rei%ca6c@bitmessage.ch> <20180927204237.h3kQJ%ca6c@bitmessage.ch> Message-ID: On Thu, Sep 27, 2018 at 4:43 PM Cág wrote: > > Thanks for such an interesting and informative answer, Mr. Cross. > I'm happy to write it! Dan Cross wrote: > > > 4.4BSD had a convention of placing user home directories in /a, /b, > > etc. > > Do I understand it correctly: they were in just "slash a/b/etc" in > root? Not /home/a or /usr/a but just /a? > Correct. I believe the idea was to program the automounter to make these appear in some directory like /home, but the directories themselves lived in /a, /b, etc. Presumably these were mount points for separate disk-resident filesystems. > 4.4BSD-Lite also had /var/users. > > Was it /var/users/$(user) or /var/$(user)? > /var/users/$user. For example, 4.4BSD-Lite1 contains entries for Ken and Dennis in /etc/master.passwd: dmr:*:10:31::0:0:Dennis Ritchie:/var/users/guest/dmr: ken:*:11:31::0:0:& Thompson:/var/users/guest/ken: To everyone: thanks for all the answers, it's always interesting to read > such things. I try not to miss a single mail after signing up for the > list. > > This question actually came up long ago when I first tried Plan 9, > which, as you know, has the directory in /usr, and it was released in > 90s, after 4.4BSD. Of course, Plan 9 is(not) (Research) Unix, and > doesn't have a root user, and apparently has a different rationale > behind it -- if I'm not mistaken, it has bin, lib and something else > there, none of which are usually present in /home these days, even bin > is usually in /usr/local. > Plan 9 represented an opportunity to do things over. Many of us rather liked it and thought it was a worthy successor to Unix, but it never caught on in the larger world and now, in the bathed in the cold light of history, some of its faults are evident. The issue with bin/ is that it's in several places. In plan9, these are all bound onto /bin, which is nice. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman at oclsc.org Fri Sep 28 07:07:40 2018 From: norman at oclsc.org (Norman Wilson) Date: Thu, 27 Sep 2018 17:07:40 -0400 Subject: [TUHS] SPARC is CRAPS spelled backwards. Message-ID: <1538082464.23158.for-standards-violators@oclsc.org> NUXIi s artdamera kfoB le laLobarotirse (A few of you are expected to understand this.) Norman Wilson Toronto ON From clemc at ccc.com Fri Sep 28 08:04:49 2018 From: clemc at ccc.com (Clem Cole) Date: Thu, 27 Sep 2018 18:04:49 -0400 Subject: [TUHS] The origin of /home In-Reply-To: References: <20180927120854.u8rei%ca6c@bitmessage.ch> <20180927204237.h3kQJ%ca6c@bitmessage.ch> Message-ID: I wish I could remember exactly everything happened, but I cannot say I do. Dan Cross, Don and Noel have all said things that line up with what I remember. I’m actually thinking the /home came out of a set of discussions that occurred before what would eventually be called UNIX International. As, Noel says, I do remember using the term ‘home directory’ as a student, so it is likely that was a term being used either by the old PDP-10 or IBM shops; but like Noel, I cannot pin the term down either. Don noted that the /home does not come to the BSD strain until 1986, which also makes sense; because one of the goals of 4.3BSD was to try to make BSD a little less divergent from the other UNIX paths, and one of the things Keith did was to start to made an effort to try use some of the same conventions the industry (Sun and AT&T in particular) were using. Dan Cross made the most important note and that is that in the early days the size a disk was quite small. UNIX Sixth and Seventh edition often ran on systems that 2 or 3 RK05 drives of 2.5M each [ https://en.wikipedia.org/wiki/RK05] and as Dan point out, there were limits to the what got put in the what file system. Simply the guiding principle at that time was that you stored in the root filesystem; just enough to the boot the system, pushed everything else to /usr and then used UNIX mount/name space splicing/path mechanisms to make a uniform set of paths. BTW: A thing to remember is that symbolic links are not a wide spread when all of this was going on in the early 1980s, so they really did not have a lot to do with the /home idea. In the case of symbolic links, Dennis had created them as part of V8, but 4.1BSD and System III (PWB 3.0) did not have the idea yet. BSD 4.2 would later get them as part of FFS, but I don’t remember if 4.1c did (the kernel source was not in Warren’s browsable archive so I could not check). Dennis had showed them to me on a visit, I thought they were cool and useful, and put them in Masscomp’s RTU (which was a System III/4.1 mash up) and then created CDL’s shortly thereafter which we used for what later Pyramid called Universes (we called it modes originally but started calling it universes also because it sounded cooler). Sun picked up symlinks when they went to the 4.2 kernel and BSD FFS. The other missing item was quotas. The universities in particular needed quotas, which is one of the reasons why Joy added it to 4.2, as it was a requested feature by the DARPA community. Before 4.2, people used the partition size within the disk as a way to have some sort of quotas. So what happened? The factiod no one has brought up so far is what would become the /usr/group standards committee (later Unix International (UI) and before that was the work Heinz Lycklama and Peter Weiner were doing at Interactive Systems Corp (ISC). Heinz wanted an industry wide ABI and was pretty vocal about it. He felt the ISVs would never take UNIX seriously if there were not ‘one true >>binary<< system’ that they compiled too. The /usr/group API work got started from that and was the compromise, a programming interface, not an binary one. But during the discussions that led up to the standards committee was a series of meetings originally at USENIX ATC, where we began to talk about the naming conventions. They were trying to agree what needs to be in /bin, /usr/bin, /lib, /usr/lib etc… and to make them more 'readonly-ish' primarily so that programs that went amok, did the least amount of damage. This was also where the idea of /usr/opt and /var were born. /usr/local was a UCB-ism, but people used it for stuff the built themselves. Most installed systems /usr1 /usr2 … where the actual user files were stored. The commercial folks wanted it more like other systems were there were some sorts of fences around things. But …it was basically agreed by the commercial side, that if there ever were going to be any hope for the ISVs to be able to ship a binary, each ISV needed her/his own spot. The idea for them was /usr/opt/hp, /usr/opt/intel, /usr/opt/msft and then under that the usual bin, etc, include, lib, … Equally /var was deal with things like logs which were being to show up (the printer and shell accounting were first), but that way ISVs and random programs did not step on each other. I think HP might have actuallybeen the first of the vendors to start to ship using that convention, but USL did pick it up by the time of System V. Similarly, at some point the /usr1, /usr2 etc … switched to /home /home1 /home2 etc… I do remember that there HP guys where pretty vocal in the arguments when it all went down. There was (should be) an email/netnews article kicking around with the name something like ‘standardized UNIX file tree’ or some such. I would think this was about 1984 or 1985 time frame. This email/article was part of the model that Keith used for 4.3BSD later on; but it is also where my memory gets hazy and I lost those notebooks in the flood. I cannot swear by it, but I do seem to think I remember that /home was one of the directories that came out of that discussion. The timing is certainly right, as is the reasoning. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Fri Sep 28 08:09:09 2018 From: clemc at ccc.com (Clem Cole) Date: Thu, 27 Sep 2018 18:09:09 -0400 Subject: [TUHS] /home In-Reply-To: References: Message-ID: Right... was how quotas were done before FFS and 4.2 and very typical of a university set up ᐧ On Thu, Sep 27, 2018 at 4:51 PM Steve Simon wrote: > > At college we had /h but that may be an interdata/edition7 thing. mine was > /h/beng4/ssimon. > > each course/year was in a separate disk partition - if group filled their > partition other groups could still work. > > -Steve > -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Fri Sep 28 08:18:51 2018 From: henry.r.bent at gmail.com (Henry Bent) Date: Thu, 27 Sep 2018 18:18:51 -0400 Subject: [TUHS] The origin of /home In-Reply-To: References: <20180927120854.u8rei%ca6c@bitmessage.ch> <20180927204237.h3kQJ%ca6c@bitmessage.ch> Message-ID: On Thu, 27 Sep 2018 at 18:06, Clem Cole wrote: > > BTW: A thing to remember is that symbolic links are not a wide spread when > all of this was going on in the early 1980s, so they really did not have a > lot to do with the /home idea. In the case of symbolic links, Dennis had > created them as part of V8, but 4.1BSD and System III (PWB 3.0) did not > have the idea yet. BSD 4.2 would later get them as part of FFS, but I > don’t remember if 4.1c did (the kernel source was not in Warren’s browsable > archive so I could not check). > 4.1c did indeed have symlinks; the "4.1c.1" source on the CSRG CD set has the code for them. lib/libc/sys/symlink.c revision 4.1 is dated 82/12/04, so that's about the time they went in. -Henry > ᐧ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Fri Sep 28 09:14:19 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 27 Sep 2018 19:14:19 -0400 (EDT) Subject: [TUHS] The origin of /home Message-ID: <20180927231419.6C71718C08E@mercury.lcs.mit.edu> > My memory is that the term "home directory" predates /home - perhaps on > other OS's such as TOPS-20, but I don't have time to research that. Well, I looked at the "Introduction to MIT-XX" (a TOPS-20 machine), and it also used the terms "logged-in directory" (home dir) and "connected directory" (current dir). I couldn't find any use of 'home' in the V6 documentation. I _did_ find "home directory" in the ITS documentation; the oldest doc file I found it in was dated 5/25/79. If ITS was the source, not sure how it spread - maybe via EMACS? Noel From grog at lemis.com Fri Sep 28 10:14:09 2018 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Fri, 28 Sep 2018 10:14:09 +1000 Subject: [TUHS] /home In-Reply-To: References: Message-ID: <20180928001409.GH75165@eureka.lemis.com> On Thursday, 27 September 2018 at 21:50:58 +0100, Steve Simon wrote: > > At college we had /h but that may be an interdata/edition7 > thing. mine was /h/beng4/ssimon. This sounds like a workaround for short pathname limits, particularly with System V. I had a file system mounted on /S for the same reason decades ago. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From imp at bsdimp.com Fri Sep 28 10:19:51 2018 From: imp at bsdimp.com (Warner Losh) Date: Thu, 27 Sep 2018 18:19:51 -0600 Subject: [TUHS] /home In-Reply-To: <20180928001409.GH75165@eureka.lemis.com> References: <20180928001409.GH75165@eureka.lemis.com> Message-ID: On Thu, Sep 27, 2018 at 6:14 PM Greg 'groggy' Lehey wrote: > On Thursday, 27 September 2018 at 21:50:58 +0100, Steve Simon wrote: > > > > At college we had /h but that may be an interdata/edition7 > > thing. mine was /h/beng4/ssimon. > > This sounds like a workaround for short pathname limits, particularly > with System V. I had a file system mounted on /S for the same reason > decades ago. At Solboure, we had /h/admin /o/os /o/home /x/build /x/home /x/prod etc. The reason for this was the SunOS automounter and bugs it had that required each machine to have a different top level directory. Luckily we only had like 4 servers... This was to prevent hanging /h mounts when the /x machine would go away and someone would do an ls in that directory. That bug got fixed in the 4.0 -> 4.1 transition, but we none-the-less kept the structure because it was too painful to transition... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Fri Sep 28 10:50:01 2018 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Thu, 27 Sep 2018 20:50:01 -0400 Subject: [TUHS] The origin of /home In-Reply-To: <52fac873-cd89-420c-c15f-b67df83aa0d3@gmail.com> References: <20180927120854.u8rei%ca6c@bitmessage.ch> <633187202.18875.1538053129435.JavaMail.tomcat@india-live-be04> <36C6F216-490E-4DE4-B5EF-CED26899542F@alchemistowl.org> <4caca587-4945-c8be-5a35-c9f0ecfdd08b@gmail.com> <309587CA-4C65-4AFA-ADFF-0E99B430D191@alchemistowl.org> <52fac873-cd89-420c-c15f-b67df83aa0d3@gmail.com> Message-ID: <20180928005001.GA2320@thunk.org> On Thu, Sep 27, 2018 at 11:49:02AM -0700, Jon Forrest wrote: > > I actually started my dataless design back when we were running Ultrix. > It worked fine there too, although back then 10Mbs networking was common > so it wasn't super speedy. Of course, neither were the workstations. MIT Project Athena had a dataless design in the late 1980's. For read-only remote file systems, Athena developed a Remote Virtual Disk (RVD) which was intergrated into BSD 4.3. RVD was a networked block device, since for read-only file systems it had better scaling properties than NFS. The Athena technical plan talks about it in a fair amount of detail. http://web.mit.edu/Saltzer/www/publications/atp.html By 1988 or so we had hundreds of workstations all over MIT that had its system softare deliviered via RVD, and for which no data would be stored on the public workstations, which were managed using the "cattle" metaphor. If a system wasn't working correctly, a workstation could be TFTP booted and the base software could be reinstalled automatically, and the reinstall was fast because the only files that had to be installed on the local disk was essentially enough for the system to come up on the network and to mount the RVD. - Ted From doug at cs.dartmouth.edu Fri Sep 28 12:39:43 2018 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Thu, 27 Sep 2018 22:39:43 -0400 Subject: [TUHS] The origin of /home Message-ID: <201809280239.w8S2dhpX048249@tahoe.cs.Dartmouth.EDU> > I couldn't find any use of 'home' in the V6 documentation. $HOME was set by default in v7. It probably dates from the advent of enviroment variables. Doug From lars at nocrew.org Fri Sep 28 15:27:42 2018 From: lars at nocrew.org (Lars Brinkhoff) Date: Fri, 28 Sep 2018 05:27:42 +0000 Subject: [TUHS] The origin of /home In-Reply-To: <20180927231419.6C71718C08E@mercury.lcs.mit.edu> (Noel Chiappa's message of "Thu, 27 Sep 2018 19:14:19 -0400 (EDT)") References: <20180927231419.6C71718C08E@mercury.lcs.mit.edu> Message-ID: <7wftxu9ooh.fsf@junk.nocrew.org> Noel Chiappa writes: > I _did_ find "home directory" in the ITS documentation; the oldest doc > file I found it in was dated 5/25/79. If ITS was the source, not sure > how it spread - maybe via EMACS? I see "home directory" in an ITS file from 1976 (.TECO.; TECORD 508). There could be a hint the AI memos, but they are hard to search. From dot at dotat.at Fri Sep 28 18:33:45 2018 From: dot at dotat.at (Tony Finch) Date: Fri, 28 Sep 2018 09:33:45 +0100 Subject: [TUHS] The origin of /home In-Reply-To: References: <20180927120854.u8rei%ca6c@bitmessage.ch> Message-ID: Dan Cross wrote: > > I intentionally eschew /home on a few systems. 4.4BSD had a convention of > placing user home directories in /a, /b, etc. 4.4BSD-Lite also had > /var/users. Both of which I occasionally use. The /a convention seems to go back quite a long way. I was looking through old password files to see where the home directories were, e.g. https://www.tuhs.org/cgi-bin/utree.pl?file=4.1cBSD/etc/passwd has a lot of /a/guest whereas 4.3BSD has /usr/guest Tony. -- f.anthony.n.finch http://dotat.at/ safeguard the balance of nature and the environment From beebe at math.utah.edu Fri Sep 28 22:08:21 2018 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Fri, 28 Sep 2018 06:08:21 -0600 Subject: [TUHS] SPARC is CRAPS spelled backwards. Message-ID: Noel Chiappa comments on the use of "home directory" on Thu, 27 Sep 2018 19:14:19 -0400 (EDT): >> I _did_ find "home directory" in the ITS documentation; the oldest doc file I >> found it in was dated 5/25/79. If ITS was the source, not sure how it spread - >> maybe via EMACS? I looked in my own TECO code (> 12K lines), and found "home directory" in two files with internal date headers from 1983. I scanned my archive of TOPS-20 emacs source code and found these uses: % grep -i 'home dire' * babyl.info:operating system; this file resides in the user's "home directory" and conv.info:stands for the user's home directory. If neither file exists, the emacs.info:Home Directory Your home directory is the one on which your mail and emacs.info: may be the same as your home directory's name. emacs.mss:@Index{Home Directory}@Index{User Name} emacs.mss:it should be called @ITS{; EVARS instead of EMACS.} emacs.mss:@Index{Home Directory} emacs.mss:EMACS into the file @ITS[;TS ESAVE]@Twenex[ESAVE.EXE]. Binary file mkdump.info matches teco.archiv:*) FS U HSNAMEnd FS U MAILllow you to get a user's home directory teco.archiv:* FS HSNAME$ is the user's home directory, as a numeric sixbit word. teco.archiv:On old versions of ITS that don't have home directories, it is the teco.archiv:same as FS MSNAME$. The home directory is (presumably) where such things teco.archiv: B) People whose home directory is a shared directory tecord.info: If you @EJ a file TS FOO on your home directory, then FOO^K tecord.info:FS HSNAME s the user's home directory. The home directory tecord.ref:FS HSNAME user's home directory tecord.ref:FS U HSNAME used to determine a user's home directory Here are the file dates: % grep -l -i 'home dire' * | xargs ls -log -rw-r--r-- 1 51376 Jun 5 1981 babyl.info -rw-r--r-- 1 81689 Oct 16 1981 conv.info -rw-r--r-- 1 466772 Dec 28 1981 emacs.info -rw-r--r-- 1 412673 Oct 16 1981 emacs.mss -rw-r--r-- 1 12570 May 24 1982 mkdump.info -rw-r--r-- 1 121865 Oct 16 1981 teco.archiv -rw-r--r-- 1 225207 Oct 16 1981 tecord.info -rw-r--r-- 1 16407 Dec 28 1981 tecord.ref In another directory named emacs-162, there were 18 files containing "home directory"; the oldest is dated 6-Mar-1980. However, when I dug into teco.archiv, I found that the match occurred in a change log block that begins TECO 699: RMS 10/14/77 Many changes ... ITS only: Thus, 14-Oct-1977 is the earliest date that I can find for "home directory", credited to Richard Stallman. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From cym224 at gmail.com Sat Sep 29 02:02:55 2018 From: cym224 at gmail.com (Nemo) Date: Fri, 28 Sep 2018 12:02:55 -0400 Subject: [TUHS] The origin of /home In-Reply-To: <20180927120854.u8rei%ca6c@bitmessage.ch> References: <20180927120854.u8rei%ca6c@bitmessage.ch> Message-ID: On 27/09/2018, Cág wrote (in part): > Hi, > > The earliest I've found to be in the FHS from '94. Are there any earlier > examples of a home directory being at /home instead of /usr/$(user)? Are > there any current Unix systems that don't use /home by default (except > OSX)? This is a bit late but Solaris uses /export/home by default. N. > Does anybody here do it intentionally? Also, what was the > rationale of moving the directory to /home? > > Thanks! > > -- > caóc From gtaylor at tnetconsulting.net Sat Sep 29 02:15:07 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Fri, 28 Sep 2018 10:15:07 -0600 Subject: [TUHS] The origin of /home In-Reply-To: References: <20180927120854.u8rei%ca6c@bitmessage.ch> Message-ID: On 09/28/2018 10:02 AM, Nemo wrote: > This is a bit late but Solaris uses /export/home by default. I disagree. Or at least not as such. Many Solaris systems I've used have put homes in /export/home. But they are /NOT/ supposed to be used /directly/ as the home directory. The intention that they would be NFS exports and that said export would be auto mounted to /home. The /export/home is really the /export/ point, /not/ the location that is supposed to be used. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From krewat at kilonet.net Sat Sep 29 03:28:01 2018 From: krewat at kilonet.net (Arthur Krewat) Date: Fri, 28 Sep 2018 13:28:01 -0400 Subject: [TUHS] The origin of /home In-Reply-To: References: <20180927120854.u8rei%ca6c@bitmessage.ch> Message-ID: On 9/28/2018 12:15 PM, Grant Taylor via TUHS wrote: > On 09/28/2018 10:02 AM, Nemo wrote: >> This is a bit late but Solaris uses /export/home by default. > > I disagree. > > Or at least not as such. > > Many Solaris systems I've used have put homes in /export/home. But > they are /NOT/ supposed to be used /directly/ as the home directory.  > The intention that they would be NFS exports and that said export > would be auto mounted to /home. > > The /export/home is really the /export/ point, /not/ the location that > is supposed to be used. > > Solaris 10 u10: beef / # useradd asdf beef / # grep asdf /etc/passwd asdf:x:504:1::/home/asdf:/bin/sh Solaris 11.3: medusa# useradd asdf medusa# grep asdf /etc/passwd asdf:x:65540:10::/export/home/asdf:/usr/bin/bash When creating a user on Solaris 11, because it requires you to install a regular user because you can't login directly as root, it creates the home directory in /export/home Interesting. To be honest, I did not expect Solaris 10 to use /home as the default. From reed at reedmedia.net Sat Sep 29 04:23:20 2018 From: reed at reedmedia.net (Jeremy C. Reed) Date: Fri, 28 Sep 2018 13:23:20 -0500 (CDT) Subject: [TUHS] The origin of /home In-Reply-To: References: <20180927120854.u8rei%ca6c@bitmessage.ch> Message-ID: On Fri, 28 Sep 2018, Tony Finch wrote: > > I intentionally eschew /home on a few systems. 4.4BSD had a convention of > > placing user home directories in /a, /b, etc. 4.4BSD-Lite also had > > /var/users. Both of which I occasionally use. > > The /a convention seems to go back quite a long way. I was looking through > old password files to see where the home directories were, e.g. > > https://www.tuhs.org/cgi-bin/utree.pl?file=4.1cBSD/etc/passwd > > has a lot of /a/guest whereas 4.3BSD has /usr/guest And the 4.3BSD docs show the /a, /b, /c https://www.tuhs.org/cgi-bin/utree.pl?file=4.3BSD/usr/man/man8/adduser.8 Traditionally, user files live on a file system different from /usr. Typically the user file systems are mounted on a directories in the root named sequentially starting from from the beginning of the alphabet, eg /a, /b, /c, etc. On each such file system there are subdirectories there for each group of users, i.e.: ``/a/staff'' and ``/b/prof''. This is not strictly necessary but keeps the number of files in the top level directories reasonably small. By the way, Berkeley early on (at time of the first Berkeley tape) had a separate /etc/htmp database to list user's home (or alternate home) directories (so didn't have to search "large password files" which were "unreasonably slow") and terminal type (part of the precursor to termcap). The home's then were like /mnt/staff/mosher, /mnt/quals/katseff, /mnt/chuck/, /mnt/jeff. Joy's early 2BSD csh docs show /mnt/bill and /usr/ken as "home directory" examples. And 3BSD's adduser docs show: Traditionally, user files live on the file system /mnt and there are subdirectories there for each group of users, i.e.: ``/mnt/staff'' and ``/mnt/prof''. This got changed for 4BSD (4.0BSD): Traditionally, user files live on a file system which has the machines single letter net(1) address as the first of two characters. Thus on the Berkeley CS Department VAX, whose Berknet address is ``csvax'' abbreviated ``v'' the user file systems are mounted on ``/va'', ``/vb'', etc. On each such filesystem there are subdirectories there for each group of users, i.e.: ``/va/staff'' and ``/vb/prof''. This is not strictly necessary but keeps the number of files in the top level directories reasonably small. (where net(1) is Schmidt's Berkeley Network) As for 4.3BSD the only reference I find of /home is from the aardvark game from Mike Urban of UCLA (/home/urban). (That is the earliest reference of a directory called /home/ I found.) From gtaylor at tnetconsulting.net Sat Sep 29 05:38:26 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Fri, 28 Sep 2018 13:38:26 -0600 Subject: [TUHS] The origin of /home In-Reply-To: References: <20180927120854.u8rei%ca6c@bitmessage.ch> Message-ID: On 09/28/2018 11:28 AM, Arthur Krewat wrote: > Solaris 10 u10: > > beef / # useradd asdf > beef / # grep asdf /etc/passwd > asdf:x:504:1::/home/asdf:/bin/sh > > Solaris 11.3: > medusa# useradd asdf > medusa# grep asdf /etc/passwd > asdf:x:65540:10::/export/home/asdf:/usr/bin/bash > > When creating a user on Solaris 11, because it requires you to install a > regular user because you can't login directly as root, it creates the > home directory in /export/home > > Interesting. To be honest, I did not expect Solaris 10 to use /home as > the default. Strange. I'd have to play with things to refine my opinion. I've long thought that Solaris was a moving target and did things inconsistently. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From gtaylor at tnetconsulting.net Sat Sep 29 05:47:24 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Fri, 28 Sep 2018 13:47:24 -0600 Subject: [TUHS] The origin of /home In-Reply-To: References: <20180927120854.u8rei%ca6c@bitmessage.ch> Message-ID: <7b2ef685-ebae-86ea-5332-8e50d2c2a533@spamtrap.tnetconsulting.net> On 09/28/2018 11:28 AM, Arthur Krewat wrote: > Solaris 10 u10: > Solaris 11.3: Were those fresh installs to test things for this discussion? Or were they existing installs that you checked? If they were fresh installs, were they larger kitchen sink type installs? Or minimal installs? -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From cym224 at gmail.com Sat Sep 29 06:00:29 2018 From: cym224 at gmail.com (Nemo) Date: Fri, 28 Sep 2018 16:00:29 -0400 Subject: [TUHS] The origin of /home In-Reply-To: References: <20180927120854.u8rei%ca6c@bitmessage.ch> Message-ID: On 28/09/2018, Grant Taylor via TUHS wrote: > On 09/28/2018 10:02 AM, Nemo wrote: >> This is a bit late but Solaris uses /export/home by default. > > I disagree. > > Or at least not as such. > > Many Solaris systems I've used have put homes in /export/home. But they > are /NOT/ supposed to be used /directly/ as the home directory. The > intention that they would be NFS exports and that said export would be > auto mounted to /home. > > The /export/home is really the /export/ point, /not/ the location that > is supposed to be used. >From https://docs.oracle.com/cd/E26505_01/html/E29492/userconcept-36940.html#userconcept-6 : A home directory can be located either on the user's local system or on a remote file server. In either case, by convention the home directory should be created as /export/home/username. For a large site, you should store home directories on a server. Use a separate file system for each /export/homen directory to facilitate backing up and restoring home directories. For example, /export/home1, /export/home2. Regardless of where their home directory is located, users usually access their home directories through a mount point named /home/username. When AutoFS is used to mount home directories, you are not permitted to create any directories under the /home mount point on any system. The system recognizes the special status of /home when AutoFS is active. > -- > Grant. . . . > unix || die From krewat at kilonet.net Sat Sep 29 06:30:43 2018 From: krewat at kilonet.net (Arthur Krewat) Date: Fri, 28 Sep 2018 16:30:43 -0400 Subject: [TUHS] The origin of /home In-Reply-To: <7b2ef685-ebae-86ea-5332-8e50d2c2a533@spamtrap.tnetconsulting.net> References: <20180927120854.u8rei%ca6c@bitmessage.ch> <7b2ef685-ebae-86ea-5332-8e50d2c2a533@spamtrap.tnetconsulting.net> Message-ID: On 9/28/2018 3:47 PM, Grant Taylor via TUHS wrote: > On 09/28/2018 11:28 AM, Arthur Krewat wrote: >> Solaris 10 u10: >> Solaris 11.3: > > Were those fresh installs to test things for this discussion? > > Or were they existing installs that you checked? > > If they were fresh installs, were they larger kitchen sink type > installs?  Or minimal installs? One is my home Solaris server 11.3, the other is a customer's Solaris 10 install from way back when. Nothing changes behavior like that from version-to-version of Solaris. Solaris 11 as a whole was a big jump in terms of GNU user-land stuff, etc, so that behavior was changed, again, probably because as of 11, you had to create a regular user during the install. I just checked Solaris 7 and 8 (x86), which are both "vanilla" installs I did to a VMware guest. On both, useradd used /home - an 11.2 guest used /export/home From gtaylor at tnetconsulting.net Sat Sep 29 07:07:34 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Fri, 28 Sep 2018 15:07:34 -0600 Subject: [TUHS] The origin of /home In-Reply-To: References: <20180927120854.u8rei%ca6c@bitmessage.ch> Message-ID: <68a3b1e2-41d0-e807-2eb6-eaafdcd47e95@spamtrap.tnetconsulting.net> On 09/28/2018 02:00 PM, Nemo wrote: > From > https://docs.oracle.com/cd/E26505_01/html/E29492/userconcept-36940.html#userconcept-6 > : > > A home directory can be located either on the user's local system or on > a remote file server. In either case, by convention the home directory > should be created as /export/home/username. For a large site, you should > store home directories on a server. Use a separate file system for each > /export/homen directory to facilitate backing up and restoring home > directories. For example, /export/home1, /export/home2. > > Regardless of where their home directory is located, users usually access > their home directories through a mount point named /home/username. When > AutoFS is used to mount home directories, you are not permitted to create > any directories under the /home mount point on any system. The system > recognizes the special status of /home when AutoFS is active. Yep, that jives with what I thought. "… by convention the home directory should be created as /export/home/username … users usually access their home directories through a mount point named /home/username …" Yep, that jives with my experience and my understanding. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From wkt at tuhs.org Sat Sep 29 09:04:44 2018 From: wkt at tuhs.org (Warren Toomey) Date: Sat, 29 Sep 2018 09:04:44 +1000 Subject: [TUHS] Original Unix SOSP paper? Message-ID: <20180928230444.GB17171@minnie.tuhs.org> All, I just got an e-mail from a TUHS member who would like to lay their hands on a copy of the original Unix SOSP paper: Anyway, I am trying to get my hands on the original 1972/73 paper on The UNIX TIME-SHARING SYSTEM that was published at the SOSP ‘73 Proceedings of the fourth ACM symposium on operating system principles. I do have the 1974 and 1978 reprint papers. But, I really want the 1972/73 original. I see it in the ACM digital library, but the full text PDF prints only the abstract. Does anybody have a scan of the original SOSP paper? I'd also like a copy of the 1974 reprint in CACM. Thanks, Warren From khm at sciops.net Sat Sep 29 09:24:08 2018 From: khm at sciops.net (Kurt H Maier) Date: Fri, 28 Sep 2018 16:24:08 -0700 Subject: [TUHS] Original Unix SOSP paper? In-Reply-To: <20180928230444.GB17171@minnie.tuhs.org> References: <20180928230444.GB17171@minnie.tuhs.org> Message-ID: <20180928232408.GB14945@wopr> On Sat, Sep 29, 2018 at 09:04:44AM +1000, Warren Toomey wrote: > > Does anybody have a scan of the original SOSP paper? Page 27 was the abstract, and page 28 was ARGOS. I'm not sure the paper actually appeared in that publication; it seems it was presented at SOSP but not published until CACM a year later. Can someone clarify? khm From wkt at tuhs.org Sat Sep 29 09:24:58 2018 From: wkt at tuhs.org (Warren Toomey) Date: Sat, 29 Sep 2018 09:24:58 +1000 Subject: [TUHS] Original Unix SOSP paper? In-Reply-To: <20180928230444.GB17171@minnie.tuhs.org> References: <20180928230444.GB17171@minnie.tuhs.org> Message-ID: <20180928232458.GA19886@minnie.tuhs.org> On Sat, Sep 29, 2018 at 09:04:44AM +1000, Warren Toomey wrote: > Does anybody have a scan of the original SOSP paper? > I'd also like a copy of the 1974 reprint in CACM. Hah, I found a copy of the CACM reprint here: https://www2.cs.duke.edu/courses/cps210/spring16/resources/papers/p365-ritchie.pdf Cheers, Warren From beebe at math.utah.edu Sat Sep 29 09:20:53 2018 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Fri, 28 Sep 2018 17:20:53 -0600 Subject: [TUHS] Original Unix SOSP paper? In-Reply-To: <20180928230444.GB17171@minnie.tuhs.org> Message-ID: Warren Toomey asks on Sat, 29 Sep 2018 09:04:44 +1000 for a copy of the original 1972/73 paper on The UNIX TIME-SHARING SYSTEM that was published at the SOSP bProceedings of the fourth ACM symposium on operating system principles. The URL in this entry from unix.bib works for me: @InProceedings{Ritchie:1973:UTSa, author = "Dennis M. Ritchie and Ken Thompson", editor = "{ACM}", booktitle = "Fourth ACM Symposium on Operating Systems Principles, IBM Thomas J. Watson Research Center, Yorktown Heights, New York, October 15-17, 1973", title = "The {UNIX} time-sharing system", publisher = pub-ACM, address = pub-ACM:adr, pages = "??--??", year = "1973", bibdate = "Thu Feb 23 07:01:17 2017", bibsource = "http://www.math.utah.edu/pub/tex/bib/unix.bib", URL = "https://www.bell-labs.com/usr/dmr/www/cacm.html", acknowledgement = ack-nhfb, remark = "This electronic edition of this paper is a reprint of the version appearing in The Bell System Technical Journal 57 no. 6, part 2 (July--August 1978). In turn, that was a revised version of an article that appeared in Communications of the ACM, 17, No. 7 (July 1974), pp. 365--375. That article was a revised version of a paper presented at the Fourth ACM Symposium on Operating Systems Principles, IBM Thomas J. Watson Research Center, Yorktown Heights, New York, October 15--17, 1973. Most of the differences between versions occur between the C. ACM version and the BSTJ printing; we incorporated updated numbers and material on portability.", } ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From wkt at tuhs.org Sat Sep 29 09:55:12 2018 From: wkt at tuhs.org (Warren Toomey) Date: Sat, 29 Sep 2018 09:55:12 +1000 Subject: [TUHS] Original Unix SOSP paper? In-Reply-To: References: <20180928230444.GB17171@minnie.tuhs.org> Message-ID: <20180928235512.GB24118@minnie.tuhs.org> On Fri, Sep 28, 2018 at 05:20:53PM -0600, Nelson H. F. Beebe wrote: > Warren Toomey asks on Sat, 29 Sep 2018 09:04:44 +1000 for > a copy of the original 1972/73 paper on The UNIX TIME-SHARING SYSTEM > that was published at the SOSP Proceedings of the fourth ACM > symposium on operating system principles. > > The URL in this entry from unix.bib works for me: Ah, but: > remark = "This electronic edition of this paper is a reprint of > the version appearing in The Bell System Technical > Journal 57 no. 6, part 2 (July--August 1978). In turn, > that was a revised version of an article that appeared > in Communications of the ACM, 17, No. 7 (July 1974), > pp. 365--375. That article was a revised version of a > paper presented at the Fourth ACM Symposium on > Operating Systems Principles, IBM Thomas J. Watson > Research Center, Yorktown Heights, New York, October > 15--17, 1973. Most of the differences between versions > occur between the C. ACM version and the BSTJ printing; > we incorporated updated numbers and material on > portability.", so not the original SOSP paper or the original 1974 CACM paper :-) However, it's yet another version of the paper. I've spent some time tracking down the various "versions" of this paper. So far, I know of: + the mid-1971 draft, available at https://www.tuhs.org/Archive/Distributions/Research/McIlroy_v0/UnixEditionZero-Threshold_OCR.pdf + a later version which is in the Nokia Bell Labs archives, which I haven't been able to get my hands on + the SOSP presentation, still unclear if there was an actual paper + the 1974 CACM paper + the version in 6th Edition Unix, available at https://minnie.tuhs.org//cgi-bin/utree.pl?file=V6/usr/doc/unix + the 1978 BSTL version cited above Are there any others that people know about that I've missed? I would like to do some work on how the content changed over time. The result would be, for me, an interesting paper to read but somehow I think the readership base would be limited :-) Cheers, Warren From sauer at technologists.com Sat Sep 29 10:15:38 2018 From: sauer at technologists.com (Charles H. Sauer) Date: Fri, 28 Sep 2018 19:15:38 -0500 Subject: [TUHS] Original Unix SOSP paper? In-Reply-To: <20180928235512.GB24118@minnie.tuhs.org> References: <20180928230444.GB17171@minnie.tuhs.org> <20180928235512.GB24118@minnie.tuhs.org> Message-ID: <471D7A71-A0FC-4471-BFC4-0263B0D77AD6@technologists.com> As Kurt has already remarked, the page counts at https://dl.acm.org/citation.cfm?id=800009&picked=prox seem all but conclusive that only the abstract was published as part of the '73 SOSP. I have old paper copies of OSR & SOSP stuff in the attic, but I don’t think they start until ’75. Next time I’m looking there, which is probably months or more away, I’ll verify. Charlie > On Sep 28, 2018, at 6:55 PM, Warren Toomey wrote: > > On Fri, Sep 28, 2018 at 05:20:53PM -0600, Nelson H. F. Beebe wrote: >> Warren Toomey asks on Sat, 29 Sep 2018 09:04:44 +1000 for >> a copy of the original 1972/73 paper on The UNIX TIME-SHARING SYSTEM >> that was published at the SOSP Proceedings of the fourth ACM >> symposium on operating system principles. >> >> The URL in this entry from unix.bib works for me: > > Ah, but: > >> remark = "This electronic edition of this paper is a reprint of >> the version appearing in The Bell System Technical >> Journal 57 no. 6, part 2 (July--August 1978). In turn, >> that was a revised version of an article that appeared >> in Communications of the ACM, 17, No. 7 (July 1974), >> pp. 365--375. That article was a revised version of a >> paper presented at the Fourth ACM Symposium on >> Operating Systems Principles, IBM Thomas J. Watson >> Research Center, Yorktown Heights, New York, October >> 15--17, 1973. Most of the differences between versions >> occur between the C. ACM version and the BSTJ printing; >> we incorporated updated numbers and material on >> portability.", > > so not the original SOSP paper or the original 1974 CACM paper :-) > > However, it's yet another version of the paper. > > I've spent some time tracking down the various "versions" of this paper. > So far, I know of: > > + the mid-1971 draft, available at https://www.tuhs.org/Archive/Distributions/Research/McIlroy_v0/UnixEditionZero-Threshold_OCR.pdf > + a later version which is in the Nokia Bell Labs archives, which I > haven't been able to get my hands on > + the SOSP presentation, still unclear if there was an actual paper > + the 1974 CACM paper > + the version in 6th Edition Unix, available at https://minnie.tuhs.org//cgi-bin/utree.pl?file=V6/usr/doc/unix > + the 1978 BSTL version cited above > > Are there any others that people know about that I've missed? > > I would like to do some work on how the content changed over time. > The result would be, for me, an interesting paper to read but somehow > I think the readership base would be limited :-) > > Cheers, Warren -- 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 khm at sciops.net Sat Sep 29 10:48:28 2018 From: khm at sciops.net (Kurt H Maier) Date: Fri, 28 Sep 2018 17:48:28 -0700 Subject: [TUHS] Original Unix SOSP paper? In-Reply-To: <20180928235512.GB24118@minnie.tuhs.org> References: <20180928230444.GB17171@minnie.tuhs.org> <20180928235512.GB24118@minnie.tuhs.org> Message-ID: <20180929004828.GA41042@wopr> On Sat, Sep 29, 2018 at 09:55:12AM +1000, Warren Toomey wrote: > + a later version which is in the Nokia Bell Labs archives, which I > haven't been able to get my hands on Archive.org has it at https://archive.org/details/bstj-archives but I collected this specific issue for my own purposes here: http://sciops.net/information/bstj/ (archive.org's new web interface is ... touch-friendly.) The paper in question is bstj57-6-1905_text.pdf. khm From imp at bsdimp.com Sat Sep 29 11:44:46 2018 From: imp at bsdimp.com (Warner Losh) Date: Fri, 28 Sep 2018 19:44:46 -0600 Subject: [TUHS] Original Unix SOSP paper? In-Reply-To: <20180929004828.GA41042@wopr> References: <20180928230444.GB17171@minnie.tuhs.org> <20180928235512.GB24118@minnie.tuhs.org> <20180929004828.GA41042@wopr> Message-ID: On Fri, Sep 28, 2018, 6:50 PM Kurt H Maier wrote: > On Sat, Sep 29, 2018 at 09:55:12AM +1000, Warren Toomey wrote: > > + a later version which is in the Nokia Bell Labs archives, which I > > haven't been able to get my hands on > > Archive.org has it at https://archive.org/details/bstj-archives but I > collected this specific issue for my own purposes here: > http://sciops.net/information/bstj/ > > (archive.org's new web interface is ... touch-friendly.) > > The paper in question is bstj57-6-1905_text.pdf. > I have a paper copy of the BSTJ in question... Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Sat Sep 29 20:11:18 2018 From: wkt at tuhs.org (Warren Toomey) Date: Sat, 29 Sep 2018 20:11:18 +1000 Subject: [TUHS] Original Unix SOSP paper? In-Reply-To: <20180929004828.GA41042@wopr> References: <20180928230444.GB17171@minnie.tuhs.org> <20180928235512.GB24118@minnie.tuhs.org> <20180929004828.GA41042@wopr> Message-ID: <20180929101118.GA30784@minnie.tuhs.org> On Fri, Sep 28, 2018 at 05:48:28PM -0700, Kurt H Maier wrote: > Archive.org has it at https://archive.org/details/bstj-archives but I > collected this specific issue for my own purposes here: > http://sciops.net/information/bstj/ > The paper in question is bstj57-6-1905_text.pdf. I've also got a mirror of the relevant BSTJ at: https://www.tuhs.org/Archive/Documentation/Papers/BSTJ/ Cheers, Warren From wlc at jctaylor.com Sat Sep 29 20:32:26 2018 From: wlc at jctaylor.com (William Corcoran) Date: Sat, 29 Sep 2018 10:32:26 +0000 Subject: [TUHS] Original Unix SOSP paper? In-Reply-To: <20180929101118.GA30784@minnie.tuhs.org> References: <20180928230444.GB17171@minnie.tuhs.org> <20180928235512.GB24118@minnie.tuhs.org> <20180929004828.GA41042@wopr>,<20180929101118.GA30784@minnie.tuhs.org> Message-ID: Hi Warren, Thank you for all of your help here! Truly, Bill Corcoran > On Sep 29, 2018, at 6:12 AM, Warren Toomey wrote: > >> On Fri, Sep 28, 2018 at 05:48:28PM -0700, Kurt H Maier wrote: >> Archive.org has it at https://archive.org/details/bstj-archives but I >> collected this specific issue for my own purposes here: >> http://sciops.net/information/bstj/ >> The paper in question is bstj57-6-1905_text.pdf. > > I've also got a mirror of the relevant BSTJ at: > https://www.tuhs.org/Archive/Documentation/Papers/BSTJ/ > > Cheers, Warren From doug at cs.dartmouth.edu Sat Sep 29 22:03:56 2018 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sat, 29 Sep 2018 08:03:56 -0400 Subject: [TUHS] Original Unix SOSP paper? Message-ID: <201809291203.w8TC3u0O057718@tahoe.cs.Dartmouth.EDU> Warren wrote: > I would like to do some work on how the content changed over time. > The result would be, for me, an interesting paper to read but somehow > I think the readership base would be limited :-) "Critical editions", as they are known in literary circles, garner wide respect if not wide readership. Go for it. Incidentally the earliest diff programs I know about date from about 1969. One was by Steve Johnson, specifically for comparing comdecks--compressed assembler source. The other arose in service of critical editions. Doug