From tfb at tfeb.org Thu Jan 1 00:58:38 2015 From: tfb at tfeb.org (Tim Bradshaw) Date: Wed, 31 Dec 2014 14:58:38 +0000 Subject: [TUHS] I swear! I rtfm'ed In-Reply-To: <54AEAFD8-1B3E-4327-98E3-D897B4045C20@orthanc.ca> References: <0CD3A100-6CDD-449C-8FD0-A3F93F421A0D@tuhs.org> <54AEAFD8-1B3E-4327-98E3-D897B4045C20@orthanc.ca> Message-ID: <59014A39-8A70-45F2-BF6D-36CF0AAA30F8@tfeb.org> On 31 Dec 2014, at 06:36, Lyndon Nerenberg wrote: > Does the infamous (X11 or was it Sunview) 'crumble' still exist in source code form? I know many "sysadmins" still deserving of it. If I remember they worked by talking to the framebuffer so they were happy to work with either. By the same token they probably won't work on anything that's not a 1980s Sun framebuffer, sadly. From arnold at skeeve.com Thu Jan 1 01:31:03 2015 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 31 Dec 2014 08:31:03 -0700 Subject: [TUHS] I swear! I rtfm'ed In-Reply-To: <59014A39-8A70-45F2-BF6D-36CF0AAA30F8@tfeb.org> References: <0CD3A100-6CDD-449C-8FD0-A3F93F421A0D@tuhs.org> <54AEAFD8-1B3E-4327-98E3-D897B4045C20@orthanc.ca> <59014A39-8A70-45F2-BF6D-36CF0AAA30F8@tfeb.org> Message-ID: <201412311531.sBVFV3gA012941@freefriends.org> > Does the infamous (X11 or was it Sunview) 'crumble' still exist in source > code form? I know many "sysadmins" still deserving of it. It appears to have been posted in comp.sources.misc/volume4 if you can find that. :-) Arnold From milov at cs.uwlax.edu Thu Jan 1 01:37:26 2015 From: milov at cs.uwlax.edu (Milo Velimirovic) Date: Wed, 31 Dec 2014 09:37:26 -0600 Subject: [TUHS] I swear! I rtfm'ed In-Reply-To: <201412311531.sBVFV3gA012941@freefriends.org> References: <0CD3A100-6CDD-449C-8FD0-A3F93F421A0D@tuhs.org> <54AEAFD8-1B3E-4327-98E3-D897B4045C20@orthanc.ca> <59014A39-8A70-45F2-BF6D-36CF0AAA30F8@tfeb.org> <201412311531.sBVFV3gA012941@freefriends.org> Message-ID: <4CAC989D-2E2C-40BA-BC35-B705C334B0FB@cs.uwlax.edu> It appears to be available here http://ftp.sunet.se/pub/usenet/ftp.uu.net/comp.sources.misc/volume4/ On Dec 31, 2014, at 9:31 AM, arnold at skeeve.com wrote: >> Does the infamous (X11 or was it Sunview) 'crumble' still exist in source >> code form? I know many "sysadmins" still deserving of it. > > It appears to have been posted in comp.sources.misc/volume4 if you can > find that. :-) > > Arnold > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs From mah at mhorton.net Thu Jan 1 02:11:15 2015 From: mah at mhorton.net (Mary Ann Horton) Date: Wed, 31 Dec 2014 08:11:15 -0800 Subject: [TUHS] I swear! I rtfm'ed In-Reply-To: <54AEAFD8-1B3E-4327-98E3-D897B4045C20@orthanc.ca> References: <0CD3A100-6CDD-449C-8FD0-A3F93F421A0D@tuhs.org> <54AEAFD8-1B3E-4327-98E3-D897B4045C20@orthanc.ca> Message-ID: <54A42023.4000500@mhorton.net> I loved my Ambassador! Still have one. I remember performing the "twisted mode" mod to be able to run it in 60x80 portrait mode, before Ann Arbor released a portrait product. http://stargatemuseum.org/html/cubix_and_dumb_terminal.html Forgive me if I didn't do a lot of EMACS on it, though. :) Mary Ann On 12/30/2014 10:36 PM, Lyndon Nerenberg wrote: > And speaking of kick-ass terminals, who else remembers chiselling > emacs commands into the keyboard of an Ann Arbor Ambassador in 60x132 > mode?!? I loved that keyboard. They could hear me pounding on it a > mile down the road :-) --lyndon From jnc at mercury.lcs.mit.edu Thu Jan 1 02:25:43 2015 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 31 Dec 2014 11:25:43 -0500 (EST) Subject: [TUHS] I swear! I rtfm'ed Message-ID: <20141231162543.9216718C0F8@mercury.lcs.mit.edu> > From: Mary Ann Horton > I loved my Ambassador! Ditto! > Still have one. Argh! Now you've made me want one for my vintage -11's! Alas, I don't see one on eBay.... :-( Noel From dwalker at doomd.net Thu Jan 1 03:37:53 2015 From: dwalker at doomd.net (Derrik Walker v2.0) Date: Wed, 31 Dec 2014 12:37:53 -0500 Subject: [TUHS] I swear! I rtfm'ed In-Reply-To: <4CAC989D-2E2C-40BA-BC35-B705C334B0FB@cs.uwlax.edu> References: <0CD3A100-6CDD-449C-8FD0-A3F93F421A0D@tuhs.org> <54AEAFD8-1B3E-4327-98E3-D897B4045C20@orthanc.ca> <59014A39-8A70-45F2-BF6D-36CF0AAA30F8@tfeb.org> <201412311531.sBVFV3gA012941@freefriends.org> <4CAC989D-2E2C-40BA-BC35-B705C334B0FB@cs.uwlax.edu> Message-ID: <1420047473.23152.3.camel@sagan> On Wed, 2014-12-31 at 09:37 -0600, Milo Velimirovic wrote: > It appears to be available here > http://ftp.sunet.se/pub/usenet/ftp.uu.net/comp.sources.misc/volume4/ > > On Dec 31, 2014, at 9:31 AM, arnold at skeeve.com wrote: > > >> Does the infamous (X11 or was it Sunview) 'crumble' still exist in source > >> code form? I know many "sysadmins" still deserving of it. > > > > It appears to have been posted in comp.sources.misc/volume4 if you can > > find that. :-) > > I just happen to have all these usenet posts archived on my local system. I found the program in question, and it appears to require a Sun box, and judging by the date, a Sun 3 or early Sparc running Sun OS 4. Since my Linux box doesn't have the 'suntools' headers, I wont even try to compile it. Now, if only I still had that IPX I use to have :-/ - Derrik From dds at aueb.gr Thu Jan 1 03:42:23 2015 From: dds at aueb.gr (Diomidis Spinellis) Date: Wed, 31 Dec 2014 19:42:23 +0200 Subject: [TUHS] Illumos ) In-Reply-To: <20141231131335.GA26926@mercury.ccil.org> References: <20141231062219.GA21046@mcvoy.com> <1420018115.54a3c1c32faaa@www.paradise.net.nz> <20141231131335.GA26926@mercury.ccil.org> Message-ID: <54A4357F.9040703@aueb.gr> On 31/12/2014 15:13, John Cowan wrote: > Wesley Parish scripsit: > >> [The] primary importance [of Solaris forks], from my POV, is that they >> keep the POSIX space open for experimentation: a Linux monoculture's >> as deadening as a MS Windows monoculture or a \[choose your own poison\] >> monoculture ... > > Well, BSD does that. But Solaris is the only descendant of System V for > which we have source, which means that in non-Posix cases it can give > us helpful information how the original Unix code fared after leaving > the Labs. By comparison, both Linux and BSD are clones. Thank you for stressing the importance of Solaris as a Unix descendant for which source code is available. It's a pity that we don't have public source code for the Solaris versions 2.1 to 10, so there's a 15 year gap between System V R4 and the first release of Open Solaris. I don't agree that BSD systems are a clone of Unix. There are bits in them that were written at Bell Labs. The earliest example I've found up to now comes from timezone.c, and was written at least 36 years ago (1979-01-10 14:58:45). Compare the 7th Edition implementation of timezone() http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/libc/gen/timezone.c with lines 110-128 of the current FreeBSD _tztab() implementation. https://github.com/freebsd/freebsd/blob/master/lib/libc/gen/timezone.c (How did I find it? For the past six months I've been running git blame on various tags of https://github.com/dspinellis/unix-history-repo.) Happy new year everybody! -- Diomidis Spinellis http://www.spinellis.gr From lm at mcvoy.com Thu Jan 1 06:09:09 2015 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 31 Dec 2014 12:09:09 -0800 Subject: [TUHS] I swear! I rtfm'ed In-Reply-To: <1420047473.23152.3.camel@sagan> References: <0CD3A100-6CDD-449C-8FD0-A3F93F421A0D@tuhs.org> <54AEAFD8-1B3E-4327-98E3-D897B4045C20@orthanc.ca> <59014A39-8A70-45F2-BF6D-36CF0AAA30F8@tfeb.org> <201412311531.sBVFV3gA012941@freefriends.org> <4CAC989D-2E2C-40BA-BC35-B705C334B0FB@cs.uwlax.edu> <1420047473.23152.3.camel@sagan> Message-ID: <20141231200909.GC2280@mcvoy.com> On Wed, Dec 31, 2014 at 12:37:53PM -0500, Derrik Walker v2.0 wrote: > On Wed, 2014-12-31 at 09:37 -0600, Milo Velimirovic wrote: > > It appears to be available here > > http://ftp.sunet.se/pub/usenet/ftp.uu.net/comp.sources.misc/volume4/ > > > > On Dec 31, 2014, at 9:31 AM, arnold at skeeve.com wrote: > > > > >> Does the infamous (X11 or was it Sunview) 'crumble' still exist in source > > >> code form? I know many "sysadmins" still deserving of it. > > > > > > It appears to have been posted in comp.sources.misc/volume4 if you can > > > find that. :-) > > > > > I just happen to have all these usenet posts archived on my local > system. I found the program in question, and it appears to require a > Sun box, and judging by the date, a Sun 3 or early Sparc running Sun OS > 4. > > Since my Linux box doesn't have the 'suntools' headers, I wont even try > to compile it. > > Now, if only I still had that IPX I use to have :-/ http://www.ebay.com/itm/Sun-SPARCstation-LX-/201238223990?pt=LH_DefaultDomain_0&hash=item2edabb9c76 Not an IPX but it will sun sunos 4.x if I recall correctly. From clemc at ccc.com Thu Jan 1 06:14:00 2015 From: clemc at ccc.com (Clem Cole) Date: Wed, 31 Dec 2014 15:14:00 -0500 Subject: [TUHS] I swear! I rtfm'ed In-Reply-To: References: Message-ID: Jake - you have lots of help from others and using curses(3) is definitely the right way to program. But to answer your specific question about printf(string), according to Chapter 3 (Programmer's Info) of my old VT-100 user's guide, I think what is you are doing wrong is that "\033c" is not the ANSI clear to end of screen command. When I saw your message on my iPhone last night, the cache said - wait that can't be correct. But I could not remember why. So I had to wait until I got back home today to look in my basement. As I suspected, it's not an ANSI sequence. So are you running in VT-100 (ANSI) mode or VT52 mode? I ask because it is close to the VT52 cursor right command which is actually: "\033C" but I do not remember is case mattered. In VT52 mode you need to send the terminal: "\033H\033J" to clear the screen. In ANSI mode, it becomes: "\033[1;1\033[0J" A few things to remember: 1.) Clear takes the current cursor position and clears from there to end of X (where X depends on mode, and type of clear). So you need to move the cursor to home position (aka 1,1). 2.) VT-100's did not implement the full ANSI spec like Ann Arbor, Heathkit, Wyse etc. So there are a number of things that those terminals did better. A really good reason to you curses(3) because all the knowledge is keep in the termcap and as a programmer you don't need to worry about it. 3.) I saw sites were VT52 mode was sometimes preferred because it was good enough for most editing, and needed fewer chars to do manipulation. On slow serial lines, this sometimes was helpful. That said, give me an AAA any day. Like others, I still miss that terminal. :-) Clem On Tue, Dec 30, 2014 at 5:56 PM, Jacob Ritorto wrote: > , but I can't see how you're supposed to clear the screen on a vt100 in > 2.9BSD. I guess printf'ing ("\033c") would do the trick, but I assumed > there was a more proper way; something that leverages the vt100 termcap > entry and does the right thing. Anyone? > > thx > jake > > > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Jan 1 06:32:07 2015 From: clemc at ccc.com (Clem Cole) Date: Wed, 31 Dec 2014 15:32:07 -0500 Subject: [TUHS] Illumos ) In-Reply-To: <54A4357F.9040703@aueb.gr> References: <20141231062219.GA21046@mcvoy.com> <1420018115.54a3c1c32faaa@www.paradise.net.nz> <20141231131335.GA26926@mercury.ccil.org> <54A4357F.9040703@aueb.gr> Message-ID: On Wed, Dec 31, 2014 at 12:42 PM, Diomidis Spinellis wrote: > Thank you for stressing the importance of Solaris as a Unix descendant for > which source code is available. > ​Amen​. BTW: I really don't consider Solaris a pure System V ​either. Larry and his siblings hacked on it pretty heavily. SGI's Iris and NCR's RAS were much closer to "pure" Summit code and that was not "Research" UNIX. They all devolved. > It's a pity that we don't have public source code for the Solaris versions > 2.1 to 10, so there's a 15 year gap between System V R4 and the first > release of Open Solaris. > > I don't agree that BSD systems are a clone of Unix. > ​Ditto. To me, anything post First Edition of Research UNIX is UNIX. Where hacking started and was slowly changed. But the core BTL DNA was is left intact. Idris, Linux, Minux, etc. were clones, where the API was followed and the DNS regenerated. ​Either way, it really does not matter too much. Clem​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Thu Jan 1 06:36:17 2015 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 31 Dec 2014 12:36:17 -0800 Subject: [TUHS] Illumos ) In-Reply-To: References: <20141231062219.GA21046@mcvoy.com> <1420018115.54a3c1c32faaa@www.paradise.net.nz> <20141231131335.GA26926@mercury.ccil.org> <54A4357F.9040703@aueb.gr> Message-ID: <20141231203617.GB3922@mcvoy.com> On Wed, Dec 31, 2014 at 03:32:07PM -0500, Clem Cole wrote: > On Wed, Dec 31, 2014 at 12:42 PM, Diomidis Spinellis wrote: > > > Thank you for stressing the importance of Solaris as a Unix descendant for > > which source code is available. > > > ???Amen???. BTW: > I really don't consider Solaris a pure System V either. Nope, not by a long stretch. System V had an awful VM / file system layer, Solaris took the one from SunOS 4 and wedged it in there. > Larry and his siblings hacked on it pretty heavily. Not me, man. I hated Solaris with a passion. I liked SunOS 4.x, I hacked the heck out of that. From fair-tuhs at netbsd.org Thu Jan 1 06:45:16 2015 From: fair-tuhs at netbsd.org (Erik E. Fair) Date: Wed, 31 Dec 2014 12:45:16 -0800 Subject: [TUHS] I swear! I rtfm'ed In-Reply-To: References: Message-ID: <25524.1420058716@cesium.clock.org> The sequence ESC-c is ANSI X3.64 for "reset to initial state" which happens to clear the screen, among other things. I still use it frequently to reset Mac OS X "Terminal" windows to a sane state, manually entered. Erik From clemc at ccc.com Thu Jan 1 07:05:43 2015 From: clemc at ccc.com (Clem Cole) Date: Wed, 31 Dec 2014 16:05:43 -0500 Subject: [TUHS] I swear! I rtfm'ed In-Reply-To: <25524.1420058716@cesium.clock.org> References: <25524.1420058716@cesium.clock.org> Message-ID: Ah - that makes sense, and since VT-100 are not fully ANSI, that's likely why it's not listed in my circa 1976 VT-100 programmers manual and probably why it does not work for Jacob. ;-) Clem On Wed, Dec 31, 2014 at 3:45 PM, Erik E. Fair wrote: > The sequence ESC-c is ANSI X3.64 for "reset to initial state" which > happens to clear the screen, among other things. I still use it > frequently to reset Mac OS X "Terminal" windows to a sane state, > manually entered. > > Erik > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jacob.ritorto at gmail.com Thu Jan 1 08:19:15 2015 From: jacob.ritorto at gmail.com (Jacob Ritorto) Date: Wed, 31 Dec 2014 17:19:15 -0500 Subject: [TUHS] Illumos ) In-Reply-To: <20141231203617.GB3922@mcvoy.com> References: <20141231062219.GA21046@mcvoy.com> <1420018115.54a3c1c32faaa@www.paradise.net.nz> <20141231131335.GA26926@mercury.ccil.org> <54A4357F.9040703@aueb.gr> <20141231203617.GB3922@mcvoy.com> Message-ID: Wow, Larry, were you one of the guys in Sun who actually lobbied to abandon Solaris 2 and resurrect SunOS 4.x when Solaris 2.3 flopped? Sorry for the late answer to your original question about why we should care about Illumos, but here's my take and some personal observations / conclusions to boot: With a huge sustained effort by many of the people who wrote and/or maintained it, Solaris was finally mostly open-sourced just before Sun died. There was so much good technology in the OS that it would've been a real shame to relegate it to the Oracle people who would (did) eventually close it, effectively killing Solaris. Illumos is the OS/net piece, not a distro, and takes the reins from the moment that Oracle re-closed Solaris as the base and repo-of-record for a number of distributions, such as the ones mentioned above, OpenIndiana, OpenSXCE, Tribblix and most importantly to me, SmartOS from Joyent. I don't (yet) work for Joyent, so don't take this as a sales spin or anything -- it's just that the company I worked for last year underwent a rather amazing and inspirational cultural as well as technology / performance growth when we switched the stack from CentOS to SmartOS. It was really cool to see the eyes opening while working with some pretty brilliant programmers who effectively 'grew up on linux' when they saw how engineered, featureful and just generally "sorted out" SmartOS was. They started using dtrace to dig into performance problems, smf to manage services, speed of containers / zones instead of full linux VMs everywhere, real (not hypervisor-emulated) I/O using zfs straight to SSD arrays, etc. They saw that, in fact, a well written and architected operating system actually does matter quite a lot for their day to day work. And it's all seriously free and open source. Like, Real Actual unix, not a clone. The way it was meant to be. They actually really care, not just about being "good enough", but about continuing to develop the operating system in an artful, elegantly simple, efficient and practical way. This, to me, is the perfect contrast to the Linux culture that seems to wantonly embrace the 'copy/paste coding' / 'bazaar' / 'good enough' mentality and seems to do no innovation but just produce knockoff, un-architected partial functional clones of what the unix people invented. But they miss the interacting, distributed, tolerant and very polyclutural computing environment concepts every time. I think they're effectively dragging the unix ecosystem into the shitter. Not that this hasn't been done before, but at least before it was ill-thought-out litigious zeal, not junk code and minimum-viable-product quality problems. This brings to mind the one major, albeit non-technical, problem I recognize Linux (actually, perhaps it was just GNU) as having truly solved - they made it really stinking clear that your license has to be open. OSI approved open source. And that accomplishment, of itself, makes it totally worth tolerating its existence. Please accept my apologies if I've offended you with the opinionated content there. These are my honest observations after four decades of doing this, but may seem like flame bait to many. I don't write about this stuff often and I figure: if anyone's going to be able to understand and respond with constructive input to this train of thought, it's the unix historians here. Anyway, a friend I admire quite a lot took the time to put some of this Sun history and Illumos fork stuff into a talk at LISA a few years back and I think he did a really nice job. Have a look if you like: www.youtube.com/watch?v=-zRN7XLCRhc Some other interesting reading from another brilliant guy I worked with a little, who got so disheartened about the failure of tech -- partially Linux monoculture, partially other sad moves -- just walked away from tech to farming instead: http://dtrace.org/blogs/wesolows/2014/12/29/fin/ Then there's Kamp's recent article: https://queue.acm.org/detail.cfm?id=2349257 Thanks for your time and interest; In earnest, jake On Wed, Dec 31, 2014 at 3:36 PM, Larry McVoy wrote: > On Wed, Dec 31, 2014 at 03:32:07PM -0500, Clem Cole wrote: > > On Wed, Dec 31, 2014 at 12:42 PM, Diomidis Spinellis > wrote: > > > > > Thank you for stressing the importance of Solaris as a Unix descendant > for > > > which source code is available. > > > > > ???Amen???. BTW: > > I really don't consider Solaris a pure System V either. > > Nope, not by a long stretch. System V had an awful VM / file system layer, > Solaris took the one from SunOS 4 and wedged it in there. > > > Larry and his siblings hacked on it pretty heavily. > > Not me, man. I hated Solaris with a passion. I liked SunOS 4.x, I hacked > the heck out of that. > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jacob.ritorto at gmail.com Thu Jan 1 08:25:39 2015 From: jacob.ritorto at gmail.com (Jacob Ritorto) Date: Wed, 31 Dec 2014 17:25:39 -0500 Subject: [TUHS] I swear! I rtfm'ed In-Reply-To: <20141231200909.GC2280@mcvoy.com> References: <0CD3A100-6CDD-449C-8FD0-A3F93F421A0D@tuhs.org> <54AEAFD8-1B3E-4327-98E3-D897B4045C20@orthanc.ca> <59014A39-8A70-45F2-BF6D-36CF0AAA30F8@tfeb.org> <201412311531.sBVFV3gA012941@freefriends.org> <4CAC989D-2E2C-40BA-BC35-B705C334B0FB@cs.uwlax.edu> <1420047473.23152.3.camel@sagan> <20141231200909.GC2280@mcvoy.com> Message-ID: I have at least one of these and some other old SPARCstations, keyboards, mice, etc. here that could use a good home if you (or others on list) want 'em to run SunOS 4.1.3 or somesuch. I think I have install media for that OS as well. On Wed, Dec 31, 2014 at 3:09 PM, Larry McVoy wrote: > On Wed, Dec 31, 2014 at 12:37:53PM -0500, Derrik Walker v2.0 wrote: > > On Wed, 2014-12-31 at 09:37 -0600, Milo Velimirovic wrote: > > > It appears to be available here > > > http://ftp.sunet.se/pub/usenet/ftp.uu.net/comp.sources.misc/volume4/ > > > > > > On Dec 31, 2014, at 9:31 AM, arnold at skeeve.com wrote: > > > > > > >> Does the infamous (X11 or was it Sunview) 'crumble' still exist in > source > > > >> code form? I know many "sysadmins" still deserving of it. > > > > > > > > It appears to have been posted in comp.sources.misc/volume4 if you > can > > > > find that. :-) > > > > > > > > I just happen to have all these usenet posts archived on my local > > system. I found the program in question, and it appears to require a > > Sun box, and judging by the date, a Sun 3 or early Sparc running Sun OS > > 4. > > > > Since my Linux box doesn't have the 'suntools' headers, I wont even try > > to compile it. > > > > Now, if only I still had that IPX I use to have :-/ > > > http://www.ebay.com/itm/Sun-SPARCstation-LX-/201238223990?pt=LH_DefaultDomain_0&hash=item2edabb9c76 > > Not an IPX but it will sun sunos 4.x if I recall correctly. > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jacob.ritorto at gmail.com Thu Jan 1 08:30:16 2015 From: jacob.ritorto at gmail.com (Jacob Ritorto) Date: Wed, 31 Dec 2014 17:30:16 -0500 Subject: [TUHS] I swear! I rtfm'ed In-Reply-To: References: <25524.1420058716@cesium.clock.org> Message-ID: I'm actually running an old CIT-101 from c.itoh. The pdp11 is currently just simh on a raspberry pi, but I have a lot of pdp11 hardware in various states of disrepair. my 11/73 ran 2.11bsd nicely has a burned out power supply and I haven't been able to fix it. I checked out the curses man page in 2.11 and tried to use curses clear, but it really does tack on a lot of overhead & slows things down. So I'm now tempted to just cheat, keep it simple, find a simple escape string that works on real vt100s as well as xterms, etc. and just printf it. On Wed, Dec 31, 2014 at 4:05 PM, Clem Cole wrote: > Ah - that makes sense, and since VT-100 are not fully ANSI, that's likely > why it's not listed in my circa 1976 VT-100 programmers manual and probably > why it does not work for Jacob. ;-) > > Clem > > On Wed, Dec 31, 2014 at 3:45 PM, Erik E. Fair > wrote: > >> The sequence ESC-c is ANSI X3.64 for "reset to initial state" which >> happens to clear the screen, among other things. I still use it >> frequently to reset Mac OS X "Terminal" windows to a sane state, >> manually entered. >> >> Erik >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Thu Jan 1 08:42:49 2015 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 31 Dec 2014 14:42:49 -0800 Subject: [TUHS] Illumos ) In-Reply-To: References: <20141231062219.GA21046@mcvoy.com> <1420018115.54a3c1c32faaa@www.paradise.net.nz> <20141231131335.GA26926@mercury.ccil.org> <54A4357F.9040703@aueb.gr> <20141231203617.GB3922@mcvoy.com> Message-ID: <20141231224249.GA5833@mcvoy.com> On Wed, Dec 31, 2014 at 05:19:15PM -0500, Jacob Ritorto wrote: > Wow, Larry, were you one of the guys in Sun who actually lobbied to abandon > Solaris 2 and resurrect SunOS 4.x when Solaris 2.3 flopped? Over and over and over again. You have no idea. > Anyway, a friend I admire quite a lot took the time to put some of this > Sun history and Illumos fork stuff into a talk at LISA a few years back and > I think he did a really nice job. Have a look if you like: > www.youtube.com/watch?v=-zRN7XLCRhc Yeah, I know Bryan pretty well, we used to be neighbors in Noe Valley and have spent a fair amount of time discussing OS stuff. Here's Bryan, Jeff Bonwick, and Bill Moore at my place in the Santa Cruz mountains: http://www.mcvoy.com/lm/photos/2007/05/257.html and Bill and Linus talking file systems at the same party: http://www.mcvoy.com/lm/photos/2007/05/255.html The best shot was the next morning when the women were gathered around Linus asking him how he lost weight: http://www.mcvoy.com/lm/photos/2007/05/276.html His answer? "Eat less." "Did you stop drinking?" Hell no, I like my beer!" Fun times. I don't agree that Linux is as bad as you have described, Linus has pretty reasonable taste. Solaris may be sorted but /proc in Linux is oh-so-much-more-useful. My view is Linux is pragmatic about stuff, Solaris was dogmatic about it. Yeah, the latter leads to better thought out stuff but the former tends to be useful sooner. --lm From lm at mcvoy.com Thu Jan 1 08:50:35 2015 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 31 Dec 2014 14:50:35 -0800 Subject: [TUHS] Illumos ) In-Reply-To: <20141231224249.GA5833@mcvoy.com> References: <20141231062219.GA21046@mcvoy.com> <1420018115.54a3c1c32faaa@www.paradise.net.nz> <20141231131335.GA26926@mercury.ccil.org> <54A4357F.9040703@aueb.gr> <20141231203617.GB3922@mcvoy.com> <20141231224249.GA5833@mcvoy.com> Message-ID: <20141231225035.GB5833@mcvoy.com> On Wed, Dec 31, 2014 at 02:42:49PM -0800, Larry McVoy wrote: > On Wed, Dec 31, 2014 at 05:19:15PM -0500, Jacob Ritorto wrote: > > Wow, Larry, were you one of the guys in Sun who actually lobbied to abandon > > Solaris 2 and resurrect SunOS 4.x when Solaris 2.3 flopped? > > Over and over and over again. You have no idea. > > > Anyway, a friend I admire quite a lot took the time to put some of this > > Sun history and Illumos fork stuff into a talk at LISA a few years back and > > I think he did a really nice job. Have a look if you like: > > www.youtube.com/watch?v=-zRN7XLCRhc > > Yeah, I know Bryan pretty well, we used to be neighbors in Noe Valley > and have spent a fair amount of time discussing OS stuff. Here's > Bryan, Jeff Bonwick, and Bill Moore at my place in the Santa Cruz > mountains: > > http://www.mcvoy.com/lm/photos/2007/05/257.html Sorry, I should assume people know who is who, that's Bryan on the left, Jeff is making like a chicken, Bill on the right. Jeff and Bill were the main ZFS guys (I hired Jeff at Sun, he was one of my students at Stanford; Bill worked for me on BitKeeper and went on to do ZFS and then a storage startup that EMC bought for a bazillion dollars, Bill now lives on the largest lot in Los Altos :) Smart guys, it was fun listening to that crowd chat. From aek at bitsavers.org Thu Jan 1 09:00:52 2015 From: aek at bitsavers.org (Al Kossow) Date: Wed, 31 Dec 2014 15:00:52 -0800 Subject: [TUHS] HP300/4.4BSD stuff In-Reply-To: References: Message-ID: <54A48024.8020800@bitsavers.org> On 12/20/14 10:01 PM, Cory Smelosky wrote: > Evening all, > > Am I correct in my guess that 4.4BSD was built cross on an HP300? I have never found a binary dist of anything other than HP300 4.4...and my attempts to build 4.4 on ULTRIX/SunOS have so far not > succeeded...it had to have been built SOMEHOW. > Wasn't all the 9000/300 work done at the University of Utah? They had a pile of machines there running it, and it was self-hosting there. Or was that just 4.3? From mah at mhorton.net Thu Jan 1 09:06:14 2015 From: mah at mhorton.net (Mary Ann Horton) Date: Wed, 31 Dec 2014 15:06:14 -0800 Subject: [TUHS] I swear! I rtfm'ed In-Reply-To: References: <25524.1420058716@cesium.clock.org> Message-ID: <54A48166.9060007@mhorton.net> Jacob, Are you just clearing the screen in an otherwise scroll-oriented program, or are you doing graphics by clearing and repainting a similar screen when something changes? The termcap "cl" method is perfect for the former, but curses is better suited for the latter. Mary Ann On 12/31/2014 02:30 PM, Jacob Ritorto wrote: > I'm actually running an old CIT-101 from c.itoh. The pdp11 is > currently just simh on a raspberry pi, but I have a lot of pdp11 > hardware in various states of disrepair. my 11/73 ran 2.11bsd nicely > has a burned out power supply and I haven't been able to fix it. > > I checked out the curses man page in 2.11 and tried to use curses > clear, but it really does tack on a lot of overhead & slows things > down. So I'm now tempted to just cheat, keep it simple, find a simple > escape string that works on real vt100s as well as xterms, etc. and > just printf it. > > > On Wed, Dec 31, 2014 at 4:05 PM, Clem Cole > wrote: > > Ah - that makes sense, and since VT-100 are not fully ANSI, > that's likely why it's not listed in my circa 1976 VT-100 > programmers manual and probably why it does not work for Jacob. ;-) > > Clem > > On Wed, Dec 31, 2014 at 3:45 PM, Erik E. Fair > > wrote: > > The sequence ESC-c is ANSI X3.64 for "reset to initial state" > which > happens to clear the screen, among other things. I still use it > frequently to reset Mac OS X "Terminal" windows to a sane state, > manually entered. > > Erik > > > > > > > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs -------------- next part -------------- An HTML attachment was scrubbed... URL: From b4 at gewt.net Thu Jan 1 09:09:10 2015 From: b4 at gewt.net (Cory Smelosky) Date: Wed, 31 Dec 2014 18:09:10 -0500 (EST) Subject: [TUHS] HP300/4.4BSD stuff In-Reply-To: <54A48024.8020800@bitsavers.org> References: <54A48024.8020800@bitsavers.org> Message-ID: On Wed, 31 Dec 2014, Al Kossow wrote: > > Wasn't all the 9000/300 work done at the University of Utah? > They had a pile of machines there running it, and it was self-hosting there. > I don't know about all...but some certainly was. > Or was that just 4.3? Bostic's nameserver seems to have run 4.4 at one point...at least one of them anyway. Some method for compiling it for non-HP300 had to exist somehow. > > > -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From jacob.ritorto at gmail.com Thu Jan 1 09:11:28 2015 From: jacob.ritorto at gmail.com (Jacob Ritorto) Date: Wed, 31 Dec 2014 18:11:28 -0500 Subject: [TUHS] I swear! I rtfm'ed In-Reply-To: <54A48166.9060007@mhorton.net> References: <25524.1420058716@cesium.clock.org> <54A48166.9060007@mhorton.net> Message-ID: Well, it's just me teaching my kid recursion in c, so it's kind of informal and I'm just clearing the screen to repaint it a second later with changes. It's too bad that curses adds so much overhead. I'll have to compare the resultant a.outs to confirm exactly how much.. Not that it matters for a play program, really, more of a curiosity.. Thanks again Mary Ann! On Wed, Dec 31, 2014 at 6:06 PM, Mary Ann Horton wrote: > Jacob, > > Are you just clearing the screen in an otherwise scroll-oriented program, > or are you doing graphics by clearing and repainting a similar screen when > something changes? > > The termcap "cl" method is perfect for the former, but curses is better > suited for the latter. > > Mary Ann > > > On 12/31/2014 02:30 PM, Jacob Ritorto wrote: > > I'm actually running an old CIT-101 from c.itoh. The pdp11 is currently > just simh on a raspberry pi, but I have a lot of pdp11 hardware in various > states of disrepair. my 11/73 ran 2.11bsd nicely has a burned out power > supply and I haven't been able to fix it. > > I checked out the curses man page in 2.11 and tried to use curses clear, > but it really does tack on a lot of overhead & slows things down. So I'm > now tempted to just cheat, keep it simple, find a simple escape string that > works on real vt100s as well as xterms, etc. and just printf it. > > > On Wed, Dec 31, 2014 at 4:05 PM, Clem Cole wrote: > >> Ah - that makes sense, and since VT-100 are not fully ANSI, that's >> likely why it's not listed in my circa 1976 VT-100 programmers manual and >> probably why it does not work for Jacob. ;-) >> >> Clem >> >> On Wed, Dec 31, 2014 at 3:45 PM, Erik E. Fair >> wrote: >> >>> The sequence ESC-c is ANSI X3.64 for "reset to initial state" which >>> happens to clear the screen, among other things. I still use it >>> frequently to reset Mac OS X "Terminal" windows to a sane state, >>> manually entered. >>> >>> Erik >>> >> >> > > > _______________________________________________ > TUHS mailing listTUHS at minnie.tuhs.orghttps://minnie.tuhs.org/mailman/listinfo/tuhs > > > > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aek at bitsavers.org Thu Jan 1 09:29:55 2015 From: aek at bitsavers.org (Al Kossow) Date: Wed, 31 Dec 2014 15:29:55 -0800 Subject: [TUHS] HP300/4.4BSD stuff In-Reply-To: References: <54A48024.8020800@bitsavers.org> Message-ID: <54A486F3.4090403@bitsavers.org> On 12/31/14 3:09 PM, Cory Smelosky wrote: > Bostic's nameserver seems to have run 4.4 at one point...at least one of them anyway. > Sorry, misunderstood the question. By the time of 4.4, weren't the distributions coming out of Mt Xinu and BSDI? I was just looking at press releases from around that time trying to track down BSD with NFS for VAX for someone and that seemed to be what was going on. The 4.4 release from Utah I was thinking of was http://www.flux.utah.edu/~mike/hpbsd/hpbsd.html From b4 at gewt.net Thu Jan 1 09:52:33 2015 From: b4 at gewt.net (Cory Smelosky) Date: Wed, 31 Dec 2014 18:52:33 -0500 (EST) Subject: [TUHS] HP300/4.4BSD stuff In-Reply-To: <54A486F3.4090403@bitsavers.org> References: <54A48024.8020800@bitsavers.org> <54A486F3.4090403@bitsavers.org> Message-ID: On Wed, 31 Dec 2014, Al Kossow wrote: > > Sorry, misunderstood the question. By the time of 4.4, weren't the > distributions coming out > of Mt Xinu and BSDI? I was just looking at press releases from around that > time trying to > track down BSD with NFS for VAX for someone and that seemed to be what was > going on. > 4.4's documentation from the CSRG hinted at the existence of SPARC and MIPS disributions...and mentions them being different from the Utah stuff. NFS for BSD on VAX would be 4.3BSD-UWisc+NFS or later. > The 4.4 release from Utah I was thinking of was > http://www.flux.utah.edu/~mike/hpbsd/hpbsd.html > HPBSD 1.x was 4.3, 2.x was part 4.4 part 4.3, IIRC...according to CSRG installation guides. > > > > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From bqt at update.uu.se Thu Jan 1 09:52:42 2015 From: bqt at update.uu.se (Johnny Billquist) Date: Thu, 01 Jan 2015 00:52:42 +0100 Subject: [TUHS] I swear! I rtfm'ed In-Reply-To: References: Message-ID: <54A48C4A.90307@update.uu.se> On 2014-12-31 21:14, Clem Cole wrote: > > Jake - you have lots of help from others and using curses(3) is definitely > the right way to program. > > But to answer your specific question about printf(string), according to > Chapter 3 (Programmer's Info) of my old VT-100 user's guide, I think what > is you are doing wrong is that "\033c" is not the ANSI clear to end of > screen command. Right... > When I saw your message on my iPhone last night, the cache said - wait that > can't be correct. But I could not remember why. So I had to wait until > I got back home today to look in my basement. > > As I suspected, it's not an ANSI sequence. So are you running in VT-100 > (ANSI) mode or VT52 mode? I ask because it is close to the VT52 cursor > right command which is actually: "\033C" but I do not remember is case > mattered. Case do matter. > In VT52 mode you need to send the terminal: "\033H\033J" to clear the > screen. > > In ANSI mode, it becomes: "\033[1;1\033[0J" Shorter form: "\033[H\033[J" > A few things to remember: > 1.) Clear takes the current cursor position and clears from there to end of > X (where X depends on mode, and type of clear). So you need to move the > cursor to home position (aka 1,1). Not really. It's way more advanced than that. If we start with the generic clear screen, it is CSI Pn J Where CSI can be expressed as ESC [ (or "\033[" in the same parlance as above.) Pn, then is an argument to the function, while J is the actual function (clear screen in this case). Now, Pn can cause many things: 0 Clear from cursor to end of screen 1 Clear from cursor to end of screen 2 Clear from beginning of screen to cursor 3 Clear whole screen If no argument is given, the default is 0. > 2.) VT-100's did not implement the full ANSI spec like Ann Arbor, Heathkit, > Wyse etc. So there are a number of things that those terminals did > better. A really good reason to you curses(3) because all the knowledge is > keep in the termcap and as a programmer you don't need to worry about it. Probably true. However, I'm not sure Ann Arbor or Heathkit did much better. As far as I can remember, they were always more "weird", but I might just be confused. However, curses(3) is definitely a good way of not having to care about different terminal oddities. > 3.) I saw sites were VT52 mode was sometimes preferred because it was good > enough for most editing, and needed fewer chars to do manipulation. On > slow serial lines, this sometimes was helpful. That said, give me an AAA > any day. Like others, I still miss that terminal.:-) Yeah, the VT52 was simpler, and had shorter control strings. But of course, with the additional limitations that came with that. Personally, I'd give an AAA or a Heathkit away if one was dropped on me. A VT100 I would keep. :-) Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From lm at mcvoy.com Thu Jan 1 11:17:16 2015 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 31 Dec 2014 17:17:16 -0800 Subject: [TUHS] Illumos ) In-Reply-To: <20141231225035.GB5833@mcvoy.com> References: <20141231062219.GA21046@mcvoy.com> <1420018115.54a3c1c32faaa@www.paradise.net.nz> <20141231131335.GA26926@mercury.ccil.org> <54A4357F.9040703@aueb.gr> <20141231203617.GB3922@mcvoy.com> <20141231224249.GA5833@mcvoy.com> <20141231225035.GB5833@mcvoy.com> Message-ID: <20150101011716.GC9254@mcvoy.com> On Wed, Dec 31, 2014 at 02:50:35PM -0800, Larry McVoy wrote: > On Wed, Dec 31, 2014 at 02:42:49PM -0800, Larry McVoy wrote: > > On Wed, Dec 31, 2014 at 05:19:15PM -0500, Jacob Ritorto wrote: > > > Wow, Larry, were you one of the guys in Sun who actually lobbied to abandon > > > Solaris 2 and resurrect SunOS 4.x when Solaris 2.3 flopped? > > > > Over and over and over again. You have no idea. > > > > > Anyway, a friend I admire quite a lot took the time to put some of this > > > Sun history and Illumos fork stuff into a talk at LISA a few years back and > > > I think he did a really nice job. Have a look if you like: > > > www.youtube.com/watch?v=-zRN7XLCRhc > > > > Yeah, I know Bryan pretty well, we used to be neighbors in Noe Valley > > and have spent a fair amount of time discussing OS stuff. Here's > > Bryan, Jeff Bonwick, and Bill Moore at my place in the Santa Cruz > > mountains: > > > > http://www.mcvoy.com/lm/photos/2007/05/257.html > > Sorry, I should assume people know who is who, that's Bryan on the left, s/should/shouldn't/ Sigh. I swear I wasn't drinking, just a brain fart. > Jeff is making like a chicken, Bill on the right. > > Jeff and Bill were the main ZFS guys (I hired Jeff at Sun, he was one of > my students at Stanford; Bill worked for me on BitKeeper and went on to > do ZFS and then a storage startup that EMC bought for a bazillion dollars, > Bill now lives on the largest lot in Los Altos :) > > Smart guys, it was fun listening to that crowd chat. > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From fair-tuhs at netbsd.org Thu Jan 1 11:29:54 2015 From: fair-tuhs at netbsd.org (Erik E. Fair) Date: Wed, 31 Dec 2014 17:29:54 -0800 Subject: [TUHS] I swear! I rtfm'ed In-Reply-To: <54A48C4A.90307@update.uu.se> References: Message-ID: <13336.1420075794@cesium.clock.org> All those terminal quirks made writing termcap entries challenging (I wrote a few), and made the comments in the termcap file interesting reading for the frustration and cursing of terminal firmware authors. All kinds of history of the evolution of terminals is captured therein. The removal of the ability to read the source is - IMHO - what greatly impeded adoption of the AT&T "termlib" replacement for termcap: they stopped distributing the terminal database source (they distributed just the binary "compiled" versions), and made it harder to write new entries. Erik From fair-tuhs at netbsd.org Thu Jan 1 11:34:09 2015 From: fair-tuhs at netbsd.org (Erik E. Fair) Date: Wed, 31 Dec 2014 17:34:09 -0800 Subject: [TUHS] Illumos ) In-Reply-To: <20150101011716.GC9254@mcvoy.com> References: <20141231225035.GB5833@mcvoy.com> Message-ID: <29950.1420076049@cesium.clock.org> > Date: Wed, 31 Dec 2014 17:17:16 -0800 > From: Larry McVoy > Sigh. I swear I wasn't drinking, just a brain fart. Tonight's the night for drinking - wash away 2014 in a bath of your favored libation! Happy New Year from blustery Lake Tahoe, Erik From reed at reedmedia.net Thu Jan 1 10:59:34 2015 From: reed at reedmedia.net (Jeremy C. Reed) Date: Wed, 31 Dec 2014 18:59:34 -0600 (CST) Subject: [TUHS] HP300/4.4BSD stuff In-Reply-To: References: <54A48024.8020800@bitsavers.org> <54A486F3.4090403@bitsavers.org> Message-ID: On Wed, 31 Dec 2014, Cory Smelosky wrote: > NFS for BSD on VAX would be 4.3BSD-UWisc+NFS or later. The UWisc+NFS is Sun's NFS (with Sun's permission via academic use license). The HPBSD also included the Sun NFS implementation via Lebeck's Univ. of Wisconsin 4.3BSD fork. NFS for BSD was a clean implementation done by Rick Macklem which was contributed to CSRG. (I have several pages about this in my book in progress.) From arnold at skeeve.com Thu Jan 1 13:37:45 2015 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 31 Dec 2014 20:37:45 -0700 Subject: [TUHS] HP300/4.4BSD stuff In-Reply-To: <54A486F3.4090403@bitsavers.org> References: <54A48024.8020800@bitsavers.org> <54A486F3.4090403@bitsavers.org> Message-ID: <201501010337.t013bjSM012715@freefriends.org> Al Kossow wrote: > Sorry, misunderstood the question. By the time of 4.4, weren't the > distributions coming out of Mt Xinu and BSDI? I was just looking at > press releases from around that time trying to track down BSD with NFS > for VAX for someone and that seemed to be what was going on. Mt. Xinu did 4.3 + Sun NFS for the vax. It required owning Unix licenses before being able to get it from them. I ran it on vaxen at Emory University in the mid-80s. Initialy it was 4.2 + NFS and then a few months after 4.3 came out it was 4.3 + NFS. We saw a huge performance gain in moving to 4.3; I'm convinced we'd have had to buy another vax if we hadn't switched to 4.3. That was a good company to work with. Nice folks, very responsive, and they knew what they were doing. UCB did the 4.4 distributions - both 4.4 and 4.4-lite. The latter had all the AT&T code removed but wasn't fully bootable. BSDI came along later and did Unix for the '386; their ads started the whole lawsuit stuff. :-( (Let's not rehash that, please!) Arnold From aek at bitsavers.org Thu Jan 1 15:58:56 2015 From: aek at bitsavers.org (Al Kossow) Date: Wed, 31 Dec 2014 21:58:56 -0800 Subject: [TUHS] HP300/4.4BSD stuff In-Reply-To: <201501010337.t013bjSM012715@freefriends.org> References: <54A48024.8020800@bitsavers.org> <54A486F3.4090403@bitsavers.org> <201501010337.t013bjSM012715@freefriends.org> Message-ID: <54A4E220.9040502@bitsavers.org> On 12/31/14 7:37 PM, arnold at skeeve.com wrote: > BSDI came along later and did Unix for the '386; their ads started > the whole lawsuit stuff. :-( (Let's not rehash that, please!) > well, here is a history http://www.softpanorama.org/People/Torvalds/Finland_period/att_lawsuit_as_a_launcher_for_linux.shtml with this in it: Trent[ Hein] was a student at the University of Colorado, where he was a co-author of both the UNIX and the Linux system administration handbooks. He worked on the 4.4BSD port to the MIPS architecture. From b4 at gewt.net Thu Jan 1 16:04:43 2015 From: b4 at gewt.net (Cory Smelosky) Date: Thu, 1 Jan 2015 01:04:43 -0500 (EST) Subject: [TUHS] HP300/4.4BSD stuff In-Reply-To: <54A4E220.9040502@bitsavers.org> References: <54A48024.8020800@bitsavers.org> <54A486F3.4090403@bitsavers.org> <201501010337.t013bjSM012715@freefriends.org> <54A4E220.9040502@bitsavers.org> Message-ID: On Wed, 31 Dec 2014, Al Kossow wrote: > On 12/31/14 7:37 PM, arnold at skeeve.com wrote: > >> BSDI came along later and did Unix for the '386; their ads started >> the whole lawsuit stuff. :-( (Let's not rehash that, please!) >> > > well, here is a history > > http://www.softpanorama.org/People/Torvalds/Finland_period/att_lawsuit_as_a_launcher_for_linux.shtml > > with this in it: > > Trent[ Hein] was a student at the University of Colorado, where he was a > co-author of both the UNIX and the Linux system administration handbooks. He > worked on the 4.4BSD port to the MIPS architecture. > I have the first edition of the UNIX book series! > > > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From ron at ronnatalie.com Thu Jan 1 21:44:18 2015 From: ron at ronnatalie.com (Ronald Natalie) Date: Thu, 1 Jan 2015 06:44:18 -0500 Subject: [TUHS] Happy New Year and an amusing story from the past Message-ID: <6A488816-8384-4AA0-A9EA-0340DCDA9009@ronnatalie.com> A prosperous New Years to all us old UNIX farts. Years ago the USENIX conference was in Atlanta. It was a stark contrast between us and the Southern Baptists who were in town for their conference as well (punctuated at some goofball Baptist standing up in the middle of one of the restaurants to sing God Bless America or some such). Anyhow, right before the conference someone (I think it was Dennis) made some comment about nobody ever having asked him for a cast of his genitals. A couple of friends decided we needed to issue genital casting kits to certain of the UNIX notables. I went out to an art supply store and bought plaster, paper cups, popsicle sticks to mix with, etc… Gould computers let me use one of their booth machines and a printer to print out the instructions. I purloined some bags from the hotel. It was pointed out that you need vaseline in order for the plaster to not stick to the skin. Great, I head into the hotel gift shop and grab ten tiny jars of vaseline. As I plop these on the counter at the cashier, she looks at me for a minute and then announces… I guess y’all aren’t with the baptists. People took it pretty tongue in cheek when they were presented. All except Redman who flew off the handle. From clemc at ccc.com Fri Jan 2 00:30:45 2015 From: clemc at ccc.com (Clem Cole) Date: Thu, 1 Jan 2015 09:30:45 -0500 Subject: [TUHS] Happy New Year and an amusing story from the past In-Reply-To: <6A488816-8384-4AA0-A9EA-0340DCDA9009@ronnatalie.com> References: <6A488816-8384-4AA0-A9EA-0340DCDA9009@ronnatalie.com> Message-ID: Love it. IIRC that was the conference a number of us with BSD daemon t-shirts were accosted for the wearing them. A story I like to tell was in the early 1980s at the Toronto USENIX. This was just as when the US was going through AIDS reaction similar to the current ebola over-worries. I was wearing a "Sex, Drugs & UNIX" button when I got on the hotel elevator with Mike Krueger when your basic midwest family of 4 or 5 got on at the same time. The mother sees my button and asks, what's "UNIX." Krueger looks at her and replies: "It's like AIDS -- only worse." She immediately takes her kids and cowers in the corner while I'm alternating being wanting to kick Krueger and laughing. On Thu, Jan 1, 2015 at 6:44 AM, Ronald Natalie wrote: > A prosperous New Years to all us old UNIX farts. > > Years ago the USENIX conference was in Atlanta. It was a stark contrast > between us and the Southern Baptists who were in town for their conference > as well (punctuated at some goofball Baptist standing up in the middle of > one of the restaurants to sing God Bless America or some such). > > Anyhow, right before the conference someone (I think it was Dennis) made > some comment about nobody ever having asked him for a cast of his > genitals. A couple of friends decided we needed to issue genital casting > kits to certain of the UNIX notables. I went out to an art supply store > and bought plaster, paper cups, popsicle sticks to mix with, etc… Gould > computers let me use one of their booth machines and a printer to print out > the instructions. I purloined some bags from the hotel. It was pointed > out that you need vaseline in order for the plaster to not stick to the > skin. Great, I head into the hotel gift shop and grab ten tiny jars of > vaseline. As I plop these on the counter at the cashier, she looks at me > for a minute and then announces… > > I guess y’all aren’t with the baptists. > > People took it pretty tongue in cheek when they were presented. All > except Redman who flew off the handle. > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bqt at update.uu.se Fri Jan 2 01:03:05 2015 From: bqt at update.uu.se (Johnny Billquist) Date: Thu, 01 Jan 2015 16:03:05 +0100 Subject: [TUHS] I swear! I rtfm'ed In-Reply-To: <13336.1420075794@cesium.clock.org> References: <13336.1420075794@cesium.clock.org> Message-ID: <54A561A9.6030808@update.uu.se> On 2015-01-01 02:29, Erik E. Fair wrote: > All those terminal quirks made writing termcap entries challenging > (I wrote a few), and made the comments in the termcap file interesting > reading for the frustration and cursing of terminal firmware authors. > All kinds of history of the evolution of terminals is captured therein. > > The removal of the ability to read the source is - IMHO - what > greatly impeded adoption of the AT&T "termlib" replacement for > termcap: they stopped distributing the terminal database source > (they distributed just the binary "compiled" versions), and made it > harder to write new entries. I was way to removed from the action to know, but why did people slowly move over to termlib? Was there really any advantages over termcap? Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From clemc at ccc.com Fri Jan 2 01:45:37 2015 From: clemc at ccc.com (Clem Cole) Date: Thu, 1 Jan 2015 10:45:37 -0500 Subject: [TUHS] I swear! I rtfm'ed In-Reply-To: References: <25524.1420058716@cesium.clock.org> Message-ID: On Wed, Dec 31, 2014 at 5:30 PM, Jacob Ritorto wrote: > CIT-101 from c.itoh ​I remember those, but I do not have a manual for it. I reasonable guess is they tried to clone the VT-100 which means its ANSI sequences but not full ANSI and lots of strangeness - Thank you to my old friend Tom Kent who had a lot to do with the original FW and the keyboard. In his defense, the ANSI sequences were not yet a standard when then started that project. So they took what they knew was going to be there, add a ton of DEC specific stuff and the result is history. BTW: If you even wanted to know why the original Masscomp keyboard worked as it did, was because Tom had the "second systems effect" when he did the MC-500 and I always tease him about it all the time - although unlike the MC-500 you could not use the VT-100 as a weapon ;-)​ Anyway - I just looked in the original VT-100 programmer guide again and could not find the sequence "\033c" defined in it. So I'm >>guessing<< Tom and team did not implement it, and thus c.itoh did not either when they cloned it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mah at mhorton.net Fri Jan 2 01:59:51 2015 From: mah at mhorton.net (Mary Ann Horton) Date: Thu, 01 Jan 2015 07:59:51 -0800 Subject: [TUHS] I swear! I rtfm'ed In-Reply-To: <54A561A9.6030808@update.uu.se> References: <13336.1420075794@cesium.clock.org> <54A561A9.6030808@update.uu.se> Message-ID: <54A56EF7.60204@mhorton.net> The move was from termcap to terminfo. Termlib was the library for termcap. There were two problems with termcap. One was that the two-character name space was running out of room, and the codes were becoming less and less mnemonic. But the big motivator was performance. Reading in a termcap entry from /etc/termcap was terribly slow. First you had to scan all the way through the (ever-growing) termcap file to find the correct entry. Once you had it, every tgetstr (etc) had to scan from the beginning of the entry, so starting up a program like vi involved quadratic performance (time grew as the square of the length of the termcap entry.) The VAX 11/780 was a 1 MIPS processor (about the same as a 1 MHz Pentium) and was shared among dozens of timesharing users, and some of the other machines of the day (750 and 730 Vaxen, PDP-11, etc.) were even slower. It took forever to start up vi or more or any of the termcap-based programs people were using a lot. I wrote a paper about it for Usenix in 1982, but it seems to be lost to Google. Here is a nice write-up Pavel Curtis posted about it with more detail about the motivation: http://www.informatica.co.cr/unix-source-code/research/1982/0711.html Mary Ann On 01/01/2015 07:03 AM, Johnny Billquist wrote: > On 2015-01-01 02:29, Erik E. Fair wrote: >> All those terminal quirks made writing termcap entries challenging >> (I wrote a few), and made the comments in the termcap file interesting >> reading for the frustration and cursing of terminal firmware authors. >> All kinds of history of the evolution of terminals is captured therein. >> >> The removal of the ability to read the source is - IMHO - what >> greatly impeded adoption of the AT&T "termlib" replacement for >> termcap: they stopped distributing the terminal database source >> (they distributed just the binary "compiled" versions), and made it >> harder to write new entries. > > I was way to removed from the action to know, but why did people > slowly move over to termlib? Was there really any advantages over > termcap? > > Johnny > From clemc at ccc.com Fri Jan 2 02:01:19 2015 From: clemc at ccc.com (Clem Cole) Date: Thu, 1 Jan 2015 11:01:19 -0500 Subject: [TUHS] I swear! I rtfm'ed In-Reply-To: <54A48C4A.90307@update.uu.se> References: <54A48C4A.90307@update.uu.se> Message-ID: below .. On Wed, Dec 31, 2014 at 6:52 PM, Johnny Billquist wrote: > > Case do matter. ​I thought so, but it's been years since I played with any of this.​ > > Shorter form: "\033[H\033[J" ​right - that looks much more what I remember. > > 2.) VT-100's did not implement the full ANSI spec like Ann Arbor, >> Heathkit, >> Wyse etc. So there are a number of things that those terminals did >> better. A really good reason to you curses(3) because all the knowledge >> is >> keep in the termcap and as a programmer you don't need to worry about it. >> > > Probably true. However, I'm not sure Ann Arbor or Heathkit did much better. ​They did - but they had the advantage of complete spec, which when then VT-100 team did their thing, was working with a proposal.​ > As far as I can remember, they were always more "weird" ​I guess. Maybe the were not too go at running programs like EDT on VMS. which used the DEC private sequences. As I recall you grew up on RSX and VMS so would not have had the same affinity that we in the UNIX side did. VMS folks tended to stay with something that looked a lot like VT-100, whereas UNIX folks often chose more functionality in the terminal. > > > Personally, I'd give an AAA or a Heathkit away if one was dropped on me. A > VT100 I would keep. :-) ​To each each his own. I still have an H19 and a Wyse-60. Would love to find an old AAA, but I personally would not bother with any member of VT-100 family since most SW emulators are "good enough" for my use when I might want VT-100 specifics.​ ​ I heard that some folks in the VMS world gripe about the emulators not being good enough, but my use has never been that much and certainly there are lots of other issues with the newer VT-xxx's that drove me bonkers. ​I've sometimes toyed with the thought of taking one of the Mac Terminal emulators and hacking it in AAA features, but it's never been​ high on my list. I have always had too many other worthy projects in front of it. Truth is the programmable keyboard macros of the Tek 4025 and AAA are what I miss in modern systems more than anything else. Then again, if I had one, I'd probably hate the keyboard layout these days. Once the ANSI/ECMA keyboard layout came out, I forced myself to key used to it and actually now prefer it. But that took years to reprogram the ROMS in my fingers. ;-) Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From bqt at update.uu.se Fri Jan 2 02:11:06 2015 From: bqt at update.uu.se (Johnny Billquist) Date: Thu, 01 Jan 2015 17:11:06 +0100 Subject: [TUHS] I swear! I rtfm'ed In-Reply-To: References: <54A48C4A.90307@update.uu.se> Message-ID: <54A5719A.9000606@update.uu.se> On 2015-01-01 17:01, Clem Cole wrote: > below .. > > On Wed, Dec 31, 2014 at 6:52 PM, Johnny Billquist > wrote: > > > 2.) VT-100's did not implement the full ANSI spec like Ann > Arbor, Heathkit, > Wyse etc. So there are a number of things that those terminals did > better. A really good reason to you curses(3) because all the > knowledge is > keep in the termcap and as a programmer you don't need to worry > about it. > > > Probably true. However, I'm not sure Ann Arbor or Heathkit did much > better. > > ​They did - but they had the advantage of complete spec, which when then > VT-100 team did their thing, was working with a proposal.​ True. Not sure how much changed though. Do you have any list of things that differs, and things that AA or Heathkit did better? > As far as I can remember, they were always more "weird" > > ​I guess. Maybe the were not too go at running programs like EDT on > VMS. which used the DEC private sequences. As I recall you grew up on > RSX and VMS so would not have had the same affinity that we in the UNIX > side did. True that I grew up on DEC OSes, but I never used EDT. Always Emacs. (Proper Emacs, that is, not the GNU stuff... :-) ) > VMS folks tended to stay with something that looked a lot like VT-100, > whereas UNIX folks often chose more functionality in the terminal. Possible. But people in general seems to have preferred the VT100 to most other stuff on Unix as well, judging by history. > Personally, I'd give an AAA or a Heathkit away if one was dropped on > me. A VT100 I would keep. :-) > > > ​To each each his own. I still have an H19 and a Wyse-60. Would love > to find an old AAA, but I personally would not bother with any member of > VT-100 family since most SW emulators are "good enough" for my use when > I might want VT-100 specifics.​ Indeed. To each his own. No problem with that. And yes, most VT-100 emulators suck seriously. I usually identifies the first problem within 10 seconds, and almost all emulators do some of the common simple stuff wrong. xterm is my savior. It actually do things pretty might right all the time. > ​ I heard that some folks in the VMS world gripe about the emulators > not being good enough, but my use has never been that much and certainly > there are lots of other issues with the newer VT-xxx's that drove me > bonkers. Let me guess - the missing escape key? :-) (That one drove almost everyone bonkers...) Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From bqt at update.uu.se Fri Jan 2 02:21:07 2015 From: bqt at update.uu.se (Johnny Billquist) Date: Thu, 01 Jan 2015 17:21:07 +0100 Subject: [TUHS] termcap vs terminfo (was: I swear! I rtfm'ed) In-Reply-To: References: Message-ID: <54A573F3.4050503@update.uu.se> On 2015-01-01 17:11, Mary Ann Horton wrote: > > The move was from termcap to terminfo. Termlib was the library for termcap. Doh! Thanks for the correction. Finger fart. > There were two problems with termcap. One was that the two-character > name space was running out of room, and the codes were becoming less and > less mnemonic. Ah. Yes, that could definitely be a problem. > But the big motivator was performance. Reading in a termcap entry from > /etc/termcap was terribly slow. First you had to scan all the way > through the (ever-growing) termcap file to find the correct entry. Once > you had it, every tgetstr (etc) had to scan from the beginning of the > entry, so starting up a program like vi involved quadratic performance > (time grew as the square of the length of the termcap entry.) The VAX > 11/780 was a 1 MIPS processor (about the same as a 1 MHz Pentium) and > was shared among dozens of timesharing users, and some of the other > machines of the day (750 and 730 Vaxen, PDP-11, etc.) were even slower. > It took forever to start up vi or more or any of the termcap-based > programs people were using a lot. Hum. That seems like it would be more of an implementation issue. Why wouldn't you just cache all the entries for the terminal once and for all? terminfo never came to 16-bit systems anyway, so we're talking about systems with plenty of memory. Caching the terminal information would not be a big memory cost. Thanks for the insight. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From clemc at ccc.com Fri Jan 2 02:59:04 2015 From: clemc at ccc.com (Clem Cole) Date: Thu, 1 Jan 2015 11:59:04 -0500 Subject: [TUHS] I swear! I rtfm'ed In-Reply-To: <54A5719A.9000606@update.uu.se> References: <54A48C4A.90307@update.uu.se> <54A5719A.9000606@update.uu.se> Message-ID: below... On Thu, Jan 1, 2015 at 11:11 AM, Johnny Billquist wrote: > > True. Not sure how much changed though. Do you have any list of things > that differs, and things that AA or Heathkit did better? ​I've forgotten the specifics. MaryAnn may remember - having lived much of the brain-damage with so many manufactures. IIRC: Erase and line operations was one of them. Tom implemented the regions stuff which again, if I remember could be dorked into doing some of the stuff that was missing/different. Unfortunately, they deviated it as hard to come back to what the rest of the world did. Plus Tom left DEC for Masscomp around the time of 102 FW and I suspect that sort of sealed it a little. I've lost track of him, but I heard at a party a week before Christmas that he is still knocking around the area, so if I can dig him up, I'll try to remember to ask him. > > Always Emacs. (Proper Emacs, that is, not the GNU stuff... :-) ) ​Fair enough. FYI: I learned Emacs on the 10s before I ever saw UNIX. Gosling would not come to CMU for another couple of years, so we used ed and later "Fred" which was the first screen editor for UNIX I saw. By the time CMU and MIT Emacs made it to UNIX I was at Berkeley and vi was burned into the roms. ​ > Possible. But people in general seems to have preferred the VT100 to most > other stuff on Unix as well, judging by history. ​I'm not so sure. My experience is otherwise. There were two vectors at the time - cheap/simple (think ADM3A and later Wyse) and smart/expensive (think HP & Tek and later AA). The VT-100 family fell in-between. You are right, it was incredibly successful and the fact is there were lots of clones​ of the VT-100 - so you did see them on UNIX boxes sometimes. But as Horton mentioned on the termcap/terminfo thread - there were a ton of players in the cheap/simple side. I think more UNIX sites tended to play out the cheap and simple over anything else, so most sites would get a deal on a one or another. CMU went with PK's Fox with smattering of ADMs. UCB was ADMs or something very high end. I saw most of the smart HP & Tek terminals at the BTL sites. My experience was that VMS/RSX, and to some extent, Twinex, shops tended to migrate to the VT-100s or clones - probably because the native DEC SW were well intregrated, but Unix folks either wanted cheap or as much functionality as possible. Curses(3) really allowed that occur. I think "cheap and simple" came first, but once termcap existed, it really allowed the UNIX folks to use what ever they wanted. But as Erik mentioned, we all had to hack termcap entries (usually by hacking on an existing one). > xterm is my savior. It actually do things pretty might right all the time. ​Twas for me too for a long time. iterm2 on the Mac is that pretty much my standard these days. ​ > Let me guess - the missing escape key? :-) > (That one drove almost everyone bonkers...) ​Just one of many :-) Control and Caps were in wrong place. BTW: Tek had a layout was worse - it had the 0 next to 1 which caused me to make a painful screw up. I've forgotten which terminal it was, but we had one of them as console on the Teklab 11/60 and I typo-ed and wiped out a bunch of Fred Park's life work.​ ​ Thus creating the infamous "guts in the bucket/​ball on a platter" comment in the bugs section of the RT-PIP man page that got me in trouble a few years later. -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Fri Jan 2 03:04:04 2015 From: imp at bsdimp.com (Warner Losh) Date: Thu, 1 Jan 2015 10:04:04 -0700 Subject: [TUHS] termcap vs terminfo (was: I swear! I rtfm'ed) In-Reply-To: <54A573F3.4050503@update.uu.se> References: <54A573F3.4050503@update.uu.se> Message-ID: > On Jan 1, 2015, at 9:21 AM, Johnny Billquist wrote: > > On 2015-01-01 17:11, Mary Ann Horton wrote: >> >> The move was from termcap to terminfo. Termlib was the library for termcap. > > Doh! Thanks for the correction. Finger fart. > >> There were two problems with termcap. One was that the two-character >> name space was running out of room, and the codes were becoming less and >> less mnemonic. > > Ah. Yes, that could definitely be a problem. > >> But the big motivator was performance. Reading in a termcap entry from >> /etc/termcap was terribly slow. First you had to scan all the way >> through the (ever-growing) termcap file to find the correct entry. Once >> you had it, every tgetstr (etc) had to scan from the beginning of the >> entry, so starting up a program like vi involved quadratic performance >> (time grew as the square of the length of the termcap entry.) The VAX >> 11/780 was a 1 MIPS processor (about the same as a 1 MHz Pentium) and >> was shared among dozens of timesharing users, and some of the other >> machines of the day (750 and 730 Vaxen, PDP-11, etc.) were even slower. >> It took forever to start up vi or more or any of the termcap-based >> programs people were using a lot. > > Hum. That seems like it would be more of an implementation issue. Why wouldn't you just cache all the entries for the terminal once and for all? terminfo never came to 16-bit systems anyway, so we're talking about systems with plenty of memory. Caching the terminal information would not be a big memory cost. BSD solved this problem that way: parse /etc/termcap and put all the entries into termcap.db. :) Warner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dave at horsfall.org Fri Jan 2 06:11:30 2015 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 2 Jan 2015 07:11:30 +1100 (EST) Subject: [TUHS] I swear! I rtfm'ed In-Reply-To: <54A561A9.6030808@update.uu.se> References: <13336.1420075794@cesium.clock.org> <54A561A9.6030808@update.uu.se> Message-ID: On Thu, 1 Jan 2015, Johnny Billquist wrote: > I was way to removed from the action to know, but why did people slowly > move over to termlib? Was there really any advantages over termcap? It was a lot more flexible; attribute names could be of arbitrary length, whereas Termcap confined you to two characters IIRC. You had to get a bit imaginative in the naming of new attributes... -- Dave Horsfall DTM (VK2KFU) "Bliss is a MacBook with a FreeBSD server." http://www.horsfall.org/spam.html (and check the home page whilst you're there) From dave at horsfall.org Fri Jan 2 06:18:06 2015 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 2 Jan 2015 07:18:06 +1100 (EST) Subject: [TUHS] I swear! I rtfm'ed In-Reply-To: <54A56EF7.60204@mhorton.net> References: <13336.1420075794@cesium.clock.org> <54A561A9.6030808@update.uu.se> <54A56EF7.60204@mhorton.net> Message-ID: On Thu, 1 Jan 2015, Mary Ann Horton wrote: > The move was from termcap to terminfo. Termlib was the library for > termcap. Oops - ignore my subsequent contribution (it *was* some years ago...). -- Dave Horsfall DTM (VK2KFU) "Bliss is a MacBook with a FreeBSD server." http://www.horsfall.org/spam.html (and check the home page whilst you're there) From scj at yaccman.com Fri Jan 2 09:48:24 2015 From: scj at yaccman.com (scj at yaccman.com) Date: Thu, 1 Jan 2015 15:48:24 -0800 Subject: [TUHS] Happy New Year and an amusing story from the past In-Reply-To: References: <6A488816-8384-4AA0-A9EA-0340DCDA9009@ronnatalie.com> Message-ID: <5a94ba4be13b879314b92467eb129cfc.squirrel@webmail.yaccman.com> Oh that brings back memories! It seems that every Baptist read Usenix as Unisex (Freud would have something to say about that...). Families with children would pass up an elevator rather than get on it with Usenix folks... > Love it. IIRC that was the conference a number of us with BSD daemon > t-shirts were accosted for the wearing them. > > A story I like to tell was in the early 1980s at the Toronto USENIX. This > was just as when the US was going through AIDS reaction similar to the > current ebola over-worries. I was wearing a "Sex, Drugs & UNIX" button > when I got on the hotel elevator with Mike Krueger when your basic midwest > family of 4 or 5 got on at the same time. The mother sees my button and > asks, what's "UNIX." Krueger looks at her and replies: "It's like AIDS -- > only worse." > > She immediately takes her kids and cowers in the corner while I'm > alternating being wanting to kick Krueger and laughing. > > On Thu, Jan 1, 2015 at 6:44 AM, Ronald Natalie wrote: > >> A prosperous New Years to all us old UNIX farts. >> >> Years ago the USENIX conference was in Atlanta. It was a stark >> contrast >> between us and the Southern Baptists who were in town for their >> conference >> as well (punctuated at some goofball Baptist standing up in the middle >> of >> one of the restaurants to sing God Bless America or some such). >> >> Anyhow, right before the conference someone (I think it was Dennis) made >> some comment about nobody ever having asked him for a cast of his >> genitals. A couple of friends decided we needed to issue genital >> casting >> kits to certain of the UNIX notables. I went out to an art supply >> store >> and bought plaster, paper cups, popsicle sticks to mix with, etc… >> Gould >> computers let me use one of their booth machines and a printer to print >> out >> the instructions. I purloined some bags from the hotel. It was >> pointed >> out that you need vaseline in order for the plaster to not stick to the >> skin. Great, I head into the hotel gift shop and grab ten tiny jars >> of >> vaseline. As I plop these on the counter at the cashier, she looks at >> me >> for a minute and then announces… >> >> I guess y’all aren’t with the baptists. >> >> People took it pretty tongue in cheek when they were presented. All >> except Redman who flew off the handle. >> _______________________________________________ >> TUHS mailing list >> TUHS at minnie.tuhs.org >> https://minnie.tuhs.org/mailman/listinfo/tuhs >> > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > From wes.parish at paradise.net.nz Fri Jan 2 10:46:12 2015 From: wes.parish at paradise.net.nz (Wesley Parish) Date: Fri, 02 Jan 2015 13:46:12 +1300 (NZDT) Subject: [TUHS] Happy New Year and an amusing story from the past In-Reply-To: <5a94ba4be13b879314b92467eb129cfc.squirrel@webmail.yaccman.com> References: <6A488816-8384-4AA0-A9EA-0340DCDA9009@ronnatalie.com> <5a94ba4be13b879314b92467eb129cfc.squirrel@webmail.yaccman.com> Message-ID: <1420159572.54a5ea545ea1f@www.paradise.net.nz> And nobody thought to pronounce the word UNIX (EUNUCHS) to the Very Reverend Baptist-folk? :) That would've made it even funnier! Quoting scj at yaccman.com: > Oh that brings back memories! It seems that every Baptist read Usenix > as > Unisex (Freud would have something to say about that...). Families with > children would pass up an elevator rather than get on it with Usenix > folks... > > > > Love it. IIRC that was the conference a number of us with BSD daemon > > t-shirts were accosted for the wearing them. > > > > A story I like to tell was in the early 1980s at the Toronto USENIX. > This > > was just as when the US was going through AIDS reaction similar to > the > > current ebola over-worries. I was wearing a "Sex, Drugs & UNIX" > button > > when I got on the hotel elevator with Mike Krueger when your basic > midwest > > family of 4 or 5 got on at the same time. The mother sees my button > and > > asks, what's "UNIX." Krueger looks at her and replies: "It's like AIDS > -- > > only worse." > > > > She immediately takes her kids and cowers in the corner while I'm > > alternating being wanting to kick Krueger and laughing. > > > > On Thu, Jan 1, 2015 at 6:44 AM, Ronald Natalie > wrote: > > > >> A prosperous New Years to all us old UNIX farts. > >> > >> Years ago the USENIX conference was in Atlanta. It was a stark > >> contrast > >> between us and the Southern Baptists who were in town for their > >> conference > >> as well (punctuated at some goofball Baptist standing up in the > middle > >> of > >> one of the restaurants to sing God Bless America or some such). > >> > >> Anyhow, right before the conference someone (I think it was Dennis) > made > >> some comment about nobody ever having asked him for a cast of his > >> genitals. A couple of friends decided we needed to issue genital > >> casting > >> kits to certain of the UNIX notables. I went out to an art supply > >> store > >> and bought plaster, paper cups, popsicle sticks to mix with, etc… > >> Gould > >> computers let me use one of their booth machines and a printer to > print > >> out > >> the instructions. I purloined some bags from the hotel. It was > >> pointed > >> out that you need vaseline in order for the plaster to not stick to > the > >> skin. Great, I head into the hotel gift shop and grab ten tiny jars > >> of > >> vaseline. As I plop these on the counter at the cashier, she looks > at > >> me > >> for a minute and then announces… > >> > >> I guess y’all aren’t with the baptists. > >> > >> People took it pretty tongue in cheek when they were presented. All > >> except Redman who flew off the handle. > >> _______________________________________________ > >> TUHS mailing list > >> TUHS at minnie.tuhs.org > >> https://minnie.tuhs.org/mailman/listinfo/tuhs > >> > > _______________________________________________ > > TUHS mailing list > > TUHS at minnie.tuhs.org > > https://minnie.tuhs.org/mailman/listinfo/tuhs > > > > > __________________ _____________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuh s > From lyndon at orthanc.ca Fri Jan 2 11:53:21 2015 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Thu, 1 Jan 2015 17:53:21 -0800 Subject: [TUHS] Happy New Year and an amusing story from the past In-Reply-To: <1420159572.54a5ea545ea1f@www.paradise.net.nz> References: <6A488816-8384-4AA0-A9EA-0340DCDA9009@ronnatalie.com> <5a94ba4be13b879314b92467eb129cfc.squirrel@webmail.yaccman.com> <1420159572.54a5ea545ea1f@www.paradise.net.nz> Message-ID: <1426610E-0D07-42DD-AF66-6F1708FFEF88@orthanc.ca> On Jan 1, 2015, at 4:46 PM, Wesley Parish wrote: > And nobody thought to pronounce the word UNIX (EUNUCHS) to the Very Reverend Baptist-folk? :) "Are you the police?" "No ma'am, we're UNIX." From mah at mhorton.net Fri Jan 2 11:50:25 2015 From: mah at mhorton.net (Mary Ann Horton) Date: Thu, 01 Jan 2015 17:50:25 -0800 Subject: [TUHS] termcap vs terminfo (was: I swear! I rtfm'ed) In-Reply-To: References: <54A573F3.4050503@update.uu.se> Message-ID: <20150101175025.18876dpnq938daap@webmail.mhorton.net> Quoting Warner Losh : >> >>> But the big motivator was performance. Reading in a termcap entry from >>> /etc/termcap was terribly slow. First you had to scan all the way >>> through the (ever-growing) termcap file to find the correct entry. Once >>> you had it, every tgetstr (etc) had to scan from the beginning of the >>> entry, so starting up a program like vi involved quadratic performance >>> (time grew as the square of the length of the termcap entry.) The VAX >>> 11/780 was a 1 MIPS processor (about the same as a 1 MHz Pentium) and >>> was shared among dozens of timesharing users, and some of the other >>> machines of the day (750 and 730 Vaxen, PDP-11, etc.) were even slower. >>> It took forever to start up vi or more or any of the termcap-based >>> programs people were using a lot. >> >> Hum. That seems like it would be more of an implementation issue. >> Why wouldn't you just cache all the entries for the terminal once >> and for all? terminfo never came to 16-bit systems anyway, so we're >> talking about systems with plenty of memory. Caching the terminal >> information would not be a big memory cost. > > BSD solved this problem that way: parse /etc/termcap and put all the > entries into termcap.db. :) That's essentially what terminfo's binary files are: a parsed, cached version of the source. From fair-tuhs at netbsd.org Sat Jan 3 05:13:28 2015 From: fair-tuhs at netbsd.org (Erik E. Fair) Date: Fri, 02 Jan 2015 11:13:28 -0800 Subject: [TUHS] termcap vs terminfo (was: I swear! I rtfm'ed) In-Reply-To: <20150101175025.18876dpnq938daap@webmail.mhorton.net> References: Message-ID: <3578.1420226008@cesium.clock.org> "terminfo" - that was the name I was reaching for and couldn't quite remember (and google-fu failed me)! The other BSD answer to the "searching /etc/termcap takes too long" problem (and I recall it being noticeable on the heavily loaded Cory Hall PDP-11/70 when you used a terminal whose entry was farther from the top of the termcap file) was to put the termcap entry for your terminal into the TERMCAP environment variable at login time, which my .login does to this day - that puts it already in RAM, ready to go, no banging on the disk required - you only pay for the /etc/termcap (or, excuse me, /usr/share/misc/termcap in NetBSD 5 - it seems NetBSD 6 finally moved to a BSD-ified terminfo and I should probably update my .login ...) search once. Erik From dave at horsfall.org Sat Jan 3 05:49:14 2015 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 3 Jan 2015 06:49:14 +1100 (EST) Subject: [TUHS] Happy New Year and an amusing story from the past In-Reply-To: <6A488816-8384-4AA0-A9EA-0340DCDA9009@ronnatalie.com> References: <6A488816-8384-4AA0-A9EA-0340DCDA9009@ronnatalie.com> Message-ID: On Thu, 1 Jan 2015, Ronald Natalie wrote: > I guess y’all aren’t with the baptists. Hilarious! The AUUG conferences seem pretty tame by comparison; one year, we used the menu holders as catapults (I don't know where we got the rubber bands) and dotted the ceiling with toothpicks (they were still there at a subsequent conference). Or am I confusing that with a Caving conference? At another (Warren will remember this one, as he was involved) we refaced a Pyramid poster (KNOW UNIX, THINK PYRAMID) to "NO UNIX IN PYRAMID", with the strategic application of napkins and some gaffer tape that we'd dug up from somewhere... Gary Jackson took it well. At an early one, when Gould first came out, we social-engineered their booth-marketoid into giving us root access; the buggers never did pay the bounty, claiming that we'd cheated. Well, yeah... At yet another, we had a Sun 3/50 window connected to a Convex, and acted all innocent when various dweebs did the old "echo 99k2vp..." etc trick. Sigh; I miss the AUUG conferences. > People took it pretty tongue in cheek when they were presented. All > except Redman who flew off the handle. Some people have no sense of humour. Did anyone actually, err, avail themselves of this unique opportunity? -- Dave Horsfall DTM (VK2KFU) "Bliss is a MacBook with a FreeBSD server." http://www.horsfall.org/spam.html (and check the home page whilst you're there) From sdaoden at yandex.com Sat Jan 3 06:12:58 2015 From: sdaoden at yandex.com (Steffen Nurpmeso) Date: Fri, 02 Jan 2015 21:12:58 +0100 Subject: [TUHS] termcap vs terminfo (was: I swear! I rtfm'ed) In-Reply-To: References: <54A573F3.4050503@update.uu.se> Message-ID: <20150102201258.44QU13Nq%sdaoden@yandex.com> Warner Losh wrote: |> On Jan 1, 2015, at 9:21 AM, Johnny Billquist wrote: |> On 2015-01-01 17:11, Mary Ann Horton wrote: |>> |>> The move was from termcap to terminfo. Termlib was the \ |>> library for termcap. |>> But the big motivator was performance. Reading in a termcap entry from |>> /etc/termcap was terribly slow. First you had to scan all the way |BSD solved this problem that way: parse /etc/termcap and put \ |all the entries into termcap.db. :) I like the current approach of FreeBSD: having a super-minimalized version in /etc and a completely outdated (compared to the termcap that Thomas Dickey maintains) stale version in /usr/share. --steffen From lm at mcvoy.com Sat Jan 3 06:14:27 2015 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 2 Jan 2015 12:14:27 -0800 Subject: [TUHS] Happy New Year and an amusing story from the past In-Reply-To: References: <6A488816-8384-4AA0-A9EA-0340DCDA9009@ronnatalie.com> Message-ID: <20150102201427.GD15302@mcvoy.com> On Sat, Jan 03, 2015 at 06:49:14AM +1100, Dave Horsfall wrote: > On Thu, 1 Jan 2015, Ronald Natalie wrote: > > > I guess y???all aren???t with the baptists. > > At an early one, when Gould first came out, we social-engineered their > booth-marketoid into giving us root access; the buggers never did pay the > bounty, claiming that we'd cheated. Well, yeah... Wasn't that Guy Harris? He noticed root had dot in their path and wrote an ls that dumped core if (!getuid()) and else tried to stash away a setuid shell only to realize that Gould had killed setuid so he had to copy the file (/usr/lib/secure or something like that) and chmod it so he could read it. As I recall it said "Gould makes fire breathing secure systems" or similar. The reason I remember all of this is I blasted gould on comp.unix-wizards for not coming through with the prize, I thought that was lame in the extreme. Funny ending to that story is that I actually interviewed at Gould and when I showed up there everyone's head was sticking out of their office to see the asshole who had the balls to show up and ask for a job. Much to my surprise, after an uncomfortable day of interviews, they offered me one. Didn't take it, went to work for Lachman instead which turned out better for me, had a blast. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From cowan at mercury.ccil.org Sat Jan 3 07:31:08 2015 From: cowan at mercury.ccil.org (John Cowan) Date: Fri, 2 Jan 2015 16:31:08 -0500 Subject: [TUHS] Happy New Year and an amusing story from the past In-Reply-To: References: <6A488816-8384-4AA0-A9EA-0340DCDA9009@ronnatalie.com> Message-ID: <20150102213108.GF28115@mercury.ccil.org> Dave Horsfall scripsit: > At an early one, when Gould first came out, we social-engineered their > booth-marketoid into giving us root access; the buggers never did pay the > bounty, claiming that we'd cheated. Well, yeah... In a former life, my employer was looking to have its Internet connection audited by an outside party, and brought in Bellcore. As the insider most concerned with such things (which was why they didn't trust me), I sat in on the kickoff meeting. After they detailed the list of penetration attacks they were going to use, I raised my hand and said "What about social engineering?" I feel morally certain that nobody from $EMPLOYER except me and my boss knew what that was. The Bellcore rep did, however: "Oh, we never do that." "Why not?" "It always succeeds, so it doesn't form the basis of actionable recommendations." > At yet another, we had a Sun 3/50 window connected to a Convex, and acted > all innocent when various dweebs did the old "echo 99k2vp..." etc trick. High-precision approximation to sqrt(2). What's the trick? -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org If I read "upcoming" in [the newspaper] once more, I will be downcoming and somebody will be outgoing. From norman at oclsc.org Sat Jan 3 08:36:43 2015 From: norman at oclsc.org (Norman Wilson) Date: Fri, 2 Jan 2015 17:36:43 -0500 (EST) Subject: [TUHS] Happy New Year and an amusing story from the past Message-ID: <20150102223643.A89FA1DE415@lignose.oclsc.org> Dave Horsfall: > At yet another, we had a Sun 3/50 window connected to a Convex, and acted > all innocent when various dweebs did the old "echo 99k2vp..." etc trick. John Cowan: High-precision approximation to sqrt(2). What's the trick? ====== Not really a trick, just a hoary old zero-order CPU benchmark: echo 99k2vp | time dc You can see why letting people type that on a Convex thinking it was a Sun 3/50 might have entertainment value. Modern systems are far too fast for that to be worth while, though. I still use a variant of it: a shell script called dc-N, containing dc < References: <20150102223643.A89FA1DE415@lignose.oclsc.org> Message-ID: <20150102230019.GG28115@mercury.ccil.org> Norman Wilson scripsit: > Dave Horsfall: > > > At yet another, we had a Sun 3/50 window connected to a Convex, and acted > > all innocent when various dweebs did the old "echo 99k2vp..." etc trick. > > You can see why letting people type that on a Convex thinking it was > a Sun 3/50 might have entertainment value. Ah. I interpreted what Dave said as the other way around: you walked up to the Convex but were teleported to the Sun, and ended up thinking "Ghu, this Convex is slow". -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org Half the lies they tell about me are true. --Tallulah Bankhead, American actress From gregg.drwho8 at gmail.com Sat Jan 3 09:59:58 2015 From: gregg.drwho8 at gmail.com (Gregg Levine) Date: Fri, 2 Jan 2015 18:59:58 -0500 Subject: [TUHS] Happy New Year and an amusing story from the past In-Reply-To: References: <6A488816-8384-4AA0-A9EA-0340DCDA9009@ronnatalie.com> Message-ID: Hello! Dave can you explain how all of you managed to connect a Sun 3/50 window to a Convex? I can of course imagine how those dweebs did that trick. As for annoying marketing droids, I did that myself back when the original RS/6000 came out. Interesting contraption and I never did appreciate what it grew up into. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again." On Fri, Jan 2, 2015 at 2:49 PM, Dave Horsfall wrote: > On Thu, 1 Jan 2015, Ronald Natalie wrote: > >> I guess y’all aren’t with the baptists. > > Hilarious! > > The AUUG conferences seem pretty tame by comparison; one year, we used the > menu holders as catapults (I don't know where we got the rubber bands) and > dotted the ceiling with toothpicks (they were still there at a subsequent > conference). Or am I confusing that with a Caving conference? > > At another (Warren will remember this one, as he was involved) we refaced > a Pyramid poster (KNOW UNIX, THINK PYRAMID) to "NO UNIX IN PYRAMID", with > the strategic application of napkins and some gaffer tape that we'd dug up > from somewhere... Gary Jackson took it well. > > At an early one, when Gould first came out, we social-engineered their > booth-marketoid into giving us root access; the buggers never did pay the > bounty, claiming that we'd cheated. Well, yeah... > > At yet another, we had a Sun 3/50 window connected to a Convex, and acted > all innocent when various dweebs did the old "echo 99k2vp..." etc trick. > > Sigh; I miss the AUUG conferences. > >> People took it pretty tongue in cheek when they were presented. All >> except Redman who flew off the handle. > > Some people have no sense of humour. Did anyone actually, err, avail > themselves of this unique opportunity? > > -- > Dave Horsfall DTM (VK2KFU) "Bliss is a MacBook with a FreeBSD server." > http://www.horsfall.org/spam.html (and check the home page whilst you're there) > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > From ron at ronnatalie.com Sat Jan 3 10:49:17 2015 From: ron at ronnatalie.com (Ronald Natalie) Date: Fri, 2 Jan 2015 19:49:17 -0500 Subject: [TUHS] Happy New Year and an amusing story from the past In-Reply-To: <20150102201427.GD15302@mcvoy.com> References: <6A488816-8384-4AA0-A9EA-0340DCDA9009@ronnatalie.com> <20150102201427.GD15302@mcvoy.com> Message-ID: Never had to social engineer anything. I think we cracked the Gould booth systems using the WIZ sendmail hack. I remember another time IBM loaned me an RS6000 but didn’t send along the root password. I left a message wanting to know if they knew the root password or should I just break in. It took me about 20 minutes and I called back and told them I’d solved the problem (the RS6000 had a MAINTENANCE mode on the keyswitch that booted up a maintenance program as root which displayed documentation using more, which had a shell escape….). I remember one day showing up at an office I had been working in the pentagon and I my sponsor was on the phone and I asked if I should knock down the screen saver and he said sure go at it. After he realized that I actually could do that he told the guy on the phone that he needed to check on how I’d done that. My old boss (Steve Wolff later of NSFNet and Cisco fame) volunteered me for the Army Tiger Team. Mostly they were physical security guys so I was about the only computer guy with them, but we had a lot of fun, some through breaking UNIX security and others just physical games. I was down at White Sands Missile Range one time and had already pretty much gotten into all the systems there when someone had noticed the physical security guys wandering around and put a warning in MOTD (of course I let them know right away that they were on to them). I heard years later that anytime a machine went down at WSMR they still blamed me. From dds at aueb.gr Sat Jan 3 20:29:59 2015 From: dds at aueb.gr (Diomidis Spinellis) Date: Sat, 03 Jan 2015 12:29:59 +0200 Subject: [TUHS] Happy New Year and an amusing story from the past In-Reply-To: References: <6A488816-8384-4AA0-A9EA-0340DCDA9009@ronnatalie.com> <20150102201427.GD15302@mcvoy.com> Message-ID: <54A7C4A7.9060009@aueb.gr> On 03/01/2015 02:49, Ronald Natalie wrote: > I asked if I should knock down the screen saver and he said sure go at it. At the university we were a few hundred undergraduates using two VAX 780s through about 40 serial terminals. They were running 4.3BSD. It was common for students who would leave their terminal for a few minutes to lock(1) it, so that others wouldn't mess with their account. Sometimes terminals were forgotten with the lock program running, and then a staff member would come, type some magic characters, and exit the lock program. Through shoulder surfing a student had found that magic sequence, and some of us were led into this secret. What we didn't know at the time, was that the magic character sequence was the root password. #ifndef lint static char sccsid[] = "@(#)lock.c 8.1 (Berkeley) 6/6/93"; #endif /* not lint */ /* * Lock a terminal up until the given key is entered, until the root * password is entered, or the given interval times out. * From ron at ronnatalie.com Sat Jan 3 22:56:25 2015 From: ron at ronnatalie.com (Ronald Natalie) Date: Sat, 3 Jan 2015 07:56:25 -0500 Subject: [TUHS] Happy New Year and an amusing story from the past In-Reply-To: <54A7C4A7.9060009@aueb.gr> References: <6A488816-8384-4AA0-A9EA-0340DCDA9009@ronnatalie.com> <20150102201427.GD15302@mcvoy.com> <54A7C4A7.9060009@aueb.gr> Message-ID: It was the old suntools lock program, which was nothing more than a full size window that covered up the screen. You could use the hotkeys to iconify it but you had a fraction of a second before it replaced itself. However, if you were fast you could as you kept iconifying it find a terminal window, do a ps, and kill the screen saver. You’d get like 2 characters typed on each iteration. That was the time I scared all my old BRL buddies because the account they gave me was ron at hq.af.mil . I don’t recall the root password that time, but the password on the cisco routers we were working on was “DickCheney” (this was back when he was secy of defense). -------------- next part -------------- An HTML attachment was scrubbed... URL: From b4 at gewt.net Sun Jan 4 18:30:14 2015 From: b4 at gewt.net (Cory Smelosky) Date: Sun, 4 Jan 2015 03:30:14 -0500 (EST) Subject: [TUHS] VAX faxing? Message-ID: Friend asked an odd question: Were VAXen ever used to send/receive faxes large-scale? What software was used and how was it configured? Was any of this run on any of the UCB VAXen? -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From dave at horsfall.org Mon Jan 5 03:50:40 2015 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 5 Jan 2015 04:50:40 +1100 (EST) Subject: [TUHS] VAX faxing? In-Reply-To: References: Message-ID: On Sun, 4 Jan 2015, Cory Smelosky wrote: > Were VAXen ever used to send/receive faxes large-scale? What software > was used and how was it configured? I don't think fax modems were even invented then, were they? I remember using FlexFax (then renamed to Hylafax) quite a lot, sometimes for nefarious purposes (it was trivial to fake the CSID)... -- Dave Horsfall DTM (VK2KFU) "Bliss is a MacBook with a FreeBSD server." http://www.horsfall.org/spam.html (and check the home page whilst you're there) From clemc at ccc.com Mon Jan 5 08:40:39 2015 From: clemc at ccc.com (Clem Cole) Date: Sun, 4 Jan 2015 17:40:39 -0500 Subject: [TUHS] VAX faxing? In-Reply-To: References: Message-ID: Yeah - some of the modems were. IIRC: Sam Leffler (sam "usual email punctuation" errno.com) did the original FlexFax SW and we had a couple kicking around. My memory is that the modems that could also support Fax in those days, sucked at UUCP, so most of us did want to dedicate a phone line to one of them. Also the scanner interface was not very easy. We tried to replace an HP fax machine with SW, including a scanner and fax modem, but it was not very satisfactory for the non-technical types. I don't have any memory of "large-scale" use however. What was cool was some of the printers knew how to use PS as the format, instead of the 1860's style scanning [yes, FAX was invented for the US civil war and originally ran over telegram lines - the current format is just a super-set of the old mechanical scan system from those days]. On Sun, Jan 4, 2015 at 12:50 PM, Dave Horsfall wrote: > On Sun, 4 Jan 2015, Cory Smelosky wrote: > > > Were VAXen ever used to send/receive faxes large-scale? What software > > was used and how was it configured? > > I don't think fax modems were even invented then, were they? > > I remember using FlexFax (then renamed to Hylafax) quite a lot, sometimes > for nefarious purposes (it was trivial to fake the CSID)... > > -- > Dave Horsfall DTM (VK2KFU) "Bliss is a MacBook with a FreeBSD server." > http://www.horsfall.org/spam.html (and check the home page whilst you're > there) > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fair-tuhs at netbsd.org Mon Jan 5 09:15:51 2015 From: fair-tuhs at netbsd.org (Erik E. Fair) Date: Sun, 04 Jan 2015 15:15:51 -0800 Subject: [TUHS] VAX faxing? In-Reply-To: References: Message-ID: <19446.1420413351@cesium.clock.org> It amazes and annoys me to this day how many PDFs purported to be "electronic documents" are merely pictures of paper. Not only am I missing my 2000's-era personal jetpack, I'm still waiting for my fully paperless office. Though given the incredible state of computer security, perhaps that's a good thing. Erik From jacob.ritorto at gmail.com Mon Jan 5 09:36:51 2015 From: jacob.ritorto at gmail.com (Jacob Ritorto) Date: Sun, 4 Jan 2015 18:36:51 -0500 Subject: [TUHS] VAX faxing? In-Reply-To: <19446.1420413351@cesium.clock.org> References: <19446.1420413351@cesium.clock.org> Message-ID: sorry to troll, but i think we lost at least three decades to microsoft, so, now that that's almost over we should be able to get on with things :D On Sun, Jan 4, 2015 at 6:15 PM, Erik E. Fair wrote: > It amazes and annoys me to this day how many PDFs purported to be > "electronic documents" are merely pictures of paper. Not only am I missing > my 2000's-era personal jetpack, I'm still waiting for my fully paperless > office. > > Though given the incredible state of computer security, perhaps that's a > good thing. > > Erik > > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lyndon at orthanc.ca Mon Jan 5 11:02:24 2015 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Sun, 4 Jan 2015 17:02:24 -0800 Subject: [TUHS] VAX faxing? In-Reply-To: References: Message-ID: <2147E845-AAD6-4575-B57F-E89C814F88AD@orthanc.ca> On Jan 4, 2015, at 2:40 PM, Clem Cole wrote: > Yeah - some of the modems were. IIRC: Sam Leffler (sam "usual email punctuation" errno.com) did the original FlexFax SW and we had a couple kicking around. My memory is that the modems that could also support Fax in those days, sucked at UUCP, so most of us did want to dedicate a phone line to one of them. In what sense? Telebit came along early with their UUCP g-protocol spoofing, but that predated all the Hayes et al FAX support. By the time modems grew (good) FAX support, UUCP was dying out in favour of PPP over V.xxx 56kb/s. I had banks of Hayes (and other) V.x modems that handled dialup 38.4 + FAX quite cheerfully. The Telebit UUCP-aware modems died out quite quickly once V.32 hit the streets. --lyndon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From clemc at ccc.com Mon Jan 5 11:48:26 2015 From: clemc at ccc.com (Clem Cole) Date: Sun, 4 Jan 2015 20:48:26 -0500 Subject: [TUHS] VAX faxing? In-Reply-To: <2147E845-AAD6-4575-B57F-E89C814F88AD@orthanc.ca> References: <2147E845-AAD6-4575-B57F-E89C814F88AD@orthanc.ca> Message-ID: On Sun, Jan 4, 2015 at 8:02 PM, Lyndon Nerenberg wrote: > Telebit came along early with their UUCP g-protocol spoofing, but that > predated all the Hayes et al FAX support. ​I don't think so. I think it was about the same time. We had both in the early 1980s when 120 cps was the fastest. Hayes may have been later with Fax support, certainly with the 56K stuff, but we had fax support with the slower modems from another manufacturer who's name escapes me now [IIRC it started with a C, they were black and the SW interface was terrible/buggy]. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lyndon at orthanc.ca Mon Jan 5 14:10:56 2015 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Sun, 4 Jan 2015 20:10:56 -0800 Subject: [TUHS] VAX faxing? In-Reply-To: References: <2147E845-AAD6-4575-B57F-E89C814F88AD@orthanc.ca> Message-ID: > Telebit came along early with their UUCP g-protocol spoofing, but that predated all the Hayes et al FAX support. > > ​I don't think so. I think it was about the same time. We had both in the early 1980s when 120 cps was the fastest. Hayes may have been later with Fax support, certainly with the 56K stuff, but we had fax support with the slower modems from another manufacturer who's name escapes me now [IIRC it started with a C, they were black and the SW interface was terrible/buggy]. Okay, nailing it down a bit more, according to my fuzzy memory ... 1982 ish: 1200 bps hayes (the black slab) 1084-5 ish: 2400 bps 1986 ish (telebit trailblazer) 1988 ish: trailblazer 2, v.32 I don't recall commodity FAX modem support until the V.34 stuff started rolling out circa 1994(?). I'm curious to know of anyone shipping (interoperable) modem FAX bits before then. I admit to not knowing of anyone or thing using V.17. --lyndon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dave at horsfall.org Mon Jan 5 14:31:15 2015 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 5 Jan 2015 15:31:15 +1100 (EST) Subject: [TUHS] VAX faxing? In-Reply-To: <19446.1420413351@cesium.clock.org> References: <19446.1420413351@cesium.clock.org> Message-ID: On Sun, 4 Jan 2015, Erik E. Fair wrote: > It amazes and annoys me to this day how many PDFs purported to be > "electronic documents" are merely pictures of paper. Not only am I > missing my 2000's-era personal jetpack, I'm still waiting for my fully > paperless office. Right after we get the paperless toilet... -- Dave Horsfall DTM (VK2KFU) "Bliss is a MacBook with a FreeBSD server." http://www.horsfall.org/spam.html (and check the home page whilst you're there) From lyndon at orthanc.ca Mon Jan 5 14:31:56 2015 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Sun, 4 Jan 2015 20:31:56 -0800 Subject: [TUHS] VAX faxing? In-Reply-To: References: <19446.1420413351@cesium.clock.org> Message-ID: <047E47F1-354F-4825-A7B0-FE70483C258B@orthanc.ca> On Jan 4, 2015, at 8:31 PM, Dave Horsfall wrote: > Right after we get the paperless toilet... It's called an air compressor. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From fair-tuhs at netbsd.org Mon Jan 5 14:54:55 2015 From: fair-tuhs at netbsd.org (Erik E. Fair) Date: Sun, 04 Jan 2015 20:54:55 -0800 Subject: [TUHS] VAX faxing? In-Reply-To: References: <19446.1420413351@cesium.clock.org> Message-ID: <26843.1420433695@cesium.clock.org> I hear tell that the Japanese have paperless toilets ... They even appear to be sold in the USA: http://www.totousa.com/products/washlets Erik From peter at rulingia.com Mon Jan 5 17:06:13 2015 From: peter at rulingia.com (Peter Jeremy) Date: Mon, 5 Jan 2015 18:06:13 +1100 Subject: [TUHS] termcap vs terminfo (was: I swear! I rtfm'ed) In-Reply-To: <3578.1420226008@cesium.clock.org> References: <3578.1420226008@cesium.clock.org> Message-ID: <20150105070613.GB10940@server.rulingia.com> On 2015-Jan-02 11:13:28 -0800, "Erik E. Fair" wrote: >your terminal into the TERMCAP environment variable at login time, >which my .login does to this day - that puts it already in RAM, But you pay for the size of $TERMCAP in every process you run. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 949 bytes Desc: not available URL: From dugo at xs4all.nl Mon Jan 5 19:59:26 2015 From: dugo at xs4all.nl (Jacob Goense) Date: Mon, 05 Jan 2015 10:59:26 +0100 Subject: [TUHS] =?utf-8?q?VAX_faxing=3F?= In-Reply-To: References: Message-ID: <534d2eef8d0fb84d3880c067d9e1517d@xs4all.nl> On 2015-01-04 09:30, Cory Smelosky wrote: > Friend asked an odd question: > > Were VAXen ever used to send/receive faxes large-scale? What software > was used and how was it configured? > > Was any of this run on any of the UCB VAXen? Early 80s INTELPOST ran on small 11s running RT-11/RSX-11 with Mills' fuzzball bolted on top. These were hooked up to DACOM or Rapicom fax machines. Dedicating VAXen to do this kind of thing might have been overkill for a long time. /Jacob From sdaoden at yandex.com Mon Jan 5 21:11:42 2015 From: sdaoden at yandex.com (Steffen Nurpmeso) Date: Mon, 05 Jan 2015 12:11:42 +0100 Subject: [TUHS] VAX faxing? In-Reply-To: <26843.1420433695@cesium.clock.org> References: <19446.1420413351@cesium.clock.org> <26843.1420433695@cesium.clock.org> Message-ID: <20150105111142.9_hj3zig%sdaoden@yandex.com> "Erik E. Fair" wrote: |I hear tell that the Japanese have paperless toilets ... To the best of my knowledge civilized tribes never used paper, but their hands and either sand or water. Then a little bit of (creme or) oil for the rosette muscle. On what i hear, the thing about japanese toilets seems to be that they are so clean that you can drink their water. (I hope this sentence isn't inappriate.) --steffen From tfb at tfeb.org Mon Jan 5 22:02:59 2015 From: tfb at tfeb.org (Tim Bradshaw) Date: Mon, 5 Jan 2015 12:02:59 +0000 Subject: [TUHS] Illumos ) In-Reply-To: <20141231224249.GA5833@mcvoy.com> References: <20141231062219.GA21046@mcvoy.com> <1420018115.54a3c1c32faaa@www.paradise.net.nz> <20141231131335.GA26926@mercury.ccil.org> <54A4357F.9040703@aueb.gr> <20141231203617.GB3922@mcvoy.com> <20141231224249.GA5833@mcvoy.com> Message-ID: On 31 Dec 2014, at 22:42, Larry McVoy wrote: > My view is Linux is pragmatic about stuff, Solaris was dogmatic about it. > Yeah, the latter leads to better thought out stuff but the former tends > to be useful sooner. I think that this is exactly right. I used Solaris for pretty much my whole career (BSD then SunOS then Solaris) and eventually I had to give up and just admit that, for reasons I don't understand but are probably to do with culture at Sun, Solaris was making a lot of decisions which smelt like ones that an academic who didn't need to actually care about use in the real world might make, while Linux almost never did that (it had/has other problems, specifically long-term interface stability). The case that made me finally realise that Solaris Had Lost was ZFS, and specifically ZFS consistency check. There is (was in ~2010) *no way to check a zpool outside the kernel*, so if you had a zpool which you thought might be damaged you were supposed to check it by importing it. So all that check code which had to deal with possibly completely random crap in the pool ran in the kernel where any kind of serious mistake involved, if you're lucky, the machine crashing, and if you're not lucky some awful data-corruption problem. But that's OK, because the ZFS code is all perfect, and never has any problems at all, of course. From jacob.ritorto at gmail.com Tue Jan 6 03:04:37 2015 From: jacob.ritorto at gmail.com (Jacob Ritorto) Date: Mon, 5 Jan 2015 12:04:37 -0500 Subject: [TUHS] Illumos ) In-Reply-To: References: <20141231062219.GA21046@mcvoy.com> <1420018115.54a3c1c32faaa@www.paradise.net.nz> <20141231131335.GA26926@mercury.ccil.org> <54A4357F.9040703@aueb.gr> <20141231203617.GB3922@mcvoy.com> <20141231224249.GA5833@mcvoy.com> Message-ID: On Mon, Jan 5, 2015 at 7:02 AM, Tim Bradshaw wrote: > On 31 Dec 2014, at 22:42, Larry McVoy wrote: > > > My view is Linux is pragmatic about stuff, Solaris was dogmatic about it. > > Yeah, the latter leads to better thought out stuff but the former tends > > to be useful sooner. > > I think that this is exactly right. I'm mostly agreeing with the gist of this, although I'd shy away from taking it as an absolute. I think the motivation for the dogmatic behaviour stems from not wanting to utterly immerse in the "just hack it" mindset. They were from the cathedral days and, from experience of the previous iterations of it, participated in the contemporary bazaar mindset with caution and reservation. One example is the penchant for (arguably over-) applying higher level design to a problem instead of just doing something myopic and 'good enough' to get through a minimum viable product scenario. It's a gradient, not a slippery slope and finding the sweet spot within it is, of course, an exercise in pragmatism. > [...] Solaris was making a lot of decisions which smelt like ones that an > academic who didn't need to actually care about use in the real world might > make, while Linux almost never did that (it had/has other problems, > specifically long-term interface stability). Even in SmartOS (Illumos-derived and vociferously "not-Solaris-anymore"), which amplifies both the pragmatism and the 10000' view design tenets, I still run into that. An a low-hanging example, while the rest of the world's happily wheelbarrowing everything into /usr/local and one has to "follow the rules" and use /opt, it's smacks of an unnecessary kick in the eye that, unix dissenters could argue, just breaks shit for spite. I understood it culturally -- for SVR4-steeped folks, it was a parseable style pattern / smell -- when you saw a machine configured around /usr/local, you braced yourself for an unbridled shitshow. We all kind of stepped back and grew some pragmatism around that, though -- Joyent, after much griping from me and my co-workers, came out with sngl containers to stop this hubris so we could use Chef recipes more easily, albiet rather late in the game (2012-ish). Now you can more readily build stuff as a toddler builds with his blocks. The brilliant bit is that with SmartOS, you now academic design, stability, speed and real world usability. There's certainly a platform for debate, perhaps in another thread, around the merits of understanding and engineering everything -vs.- building with blocks. > > The case that made me finally realise that Solaris Had Lost was ZFS, and > specifically ZFS consistency check. There is (was in ~2010) *no way to check a zpool outside the kernel*, so if > you had a zpool which you thought might be damaged you were supposed to > check it by importing it. I'm afraid there's bias confirmation and a zeal for driving nails into coffins happening here. Bear in mind that unix didn't even have fsck for a decade after its release (it appeared after v7 released), while conversely, zfs had the manual scrub command and other manual zfs recovery tools (which, much like fsck and icheck, et al, admittedly required expert knowledge to wield successfully) before it released. Yes, the default is that the system will panic or pass over a zfs it can't mount, but that's by design and when I was in that situation myself, even as a zfs noob, I managed to figure out how to recover without damaging my pool. Would you care to compare this experience to some of the battles we've all personally waged with fsck? In the unix tradition, zfs is a designed and deliberate iteration (innovation) on the filesystem concept, not a "pragmatic," good-enough, minimum viable product hip-shot, and the obvious fact that it isn't what we're used to doesn't make it bad. While there are certainly plenty of Solaris coffin nails, this ain't one. Here's my favourite Solaris coffin nail: Oracle's last five years of lawnmowing, almost zero innovative milestones and clueless customer base and community erosion and desecration. I do now agree that Solaris is finally and irredeemably dead. Their lack of understanding and stewardship has tragically transitioned it from the being the definitive unix system to, in essence, a proprietary firmware for expensive iron. But in the same breath I'd also assert that Illumos and its derivatives have taken all the good from it, continue to drive the fork forward in a wonderful variety of ways, and are the repo- and distros-of-record for this flavour of unix. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at mercury.ccil.org Tue Jan 6 10:40:54 2015 From: cowan at mercury.ccil.org (John Cowan) Date: Mon, 5 Jan 2015 19:40:54 -0500 Subject: [TUHS] termcap vs terminfo (was: I swear! I rtfm'ed) In-Reply-To: <20150105070613.GB10940@server.rulingia.com> References: <3578.1420226008@cesium.clock.org> <20150105070613.GB10940@server.rulingia.com> Message-ID: <20150106004054.GD16715@mercury.ccil.org> Peter Jeremy scripsit: > But you pay for the size of $TERMCAP in every process you run. A single termcap line doesn't cost that much, less than a KB in most cases. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org May the hair on your toes never fall out! --Thorin Oakenshield (to Bilbo) From wkt at tuhs.org Tue Jan 6 11:55:36 2015 From: wkt at tuhs.org (Warren Toomey) Date: Tue, 6 Jan 2015 12:55:36 +1100 Subject: [TUHS] State of networking in the early '90s In-Reply-To: <534d2eef8d0fb84d3880c067d9e1517d@xs4all.nl> References: <534d2eef8d0fb84d3880c067d9e1517d@xs4all.nl> Message-ID: <20150106015536.GA27434@www.oztivo.net> On Mon, Jan 05, 2015 at 10:59:26AM +0100, Jacob Goense wrote: > Early 80s INTELPOST ran on small 11s running RT-11/RSX-11 with Mills' > fuzzball bolted on top. These were hooked up to DACOM or Rapicom fax > machines. Reading this e-mail caused me to read up on the fuzzball, which then lead me to this overview of the state of networking in the early '90s: http://museum.media.org/eti/ In 1990 and 1991, I made three trips around the world to write a technical travelogue. The result was the book "Exploring the Internet", originally published by Prentice-Hall. Perhaps because they felt the Internet trend had passed, or more likely because of the less-than-mainstream appeal, they allowed the book to go out of print. I decided to republish the book on the Internet in the hope that perhaps it retains some minor historical interest. So far I've got through about 6 chapters and it's a good read. I've made it into an epub if anybody wants a copy. Cheers, Warren From crossd at gmail.com Tue Jan 6 12:23:58 2015 From: crossd at gmail.com (Dan Cross) Date: Mon, 5 Jan 2015 21:23:58 -0500 Subject: [TUHS] COHERENT sources released under 3-clause BSD license. Message-ID: Bob Swartz, founder of Mark Williams Co, has allowed the sources for COHERENT to be published under a three-clause BSD license. Steve Ness is hosting them. They are available here: http://nesssoftware.com/home/mwc/source.php For reference, for folks who don't know what COHERENT is, it started as a clone of 7th Edition, but grew more modern features over time. Dennis Ritchie's recollections of his interaction with it: https://groups.google.com/forum/#!msg/alt.folklore.computers/_ZaYeY46eb4/5B41Uym6d4QJ And of course the requisite Wikipedia link: http://en.wikipedia.org/wiki/Coherent_(operating_system) - Dan C. PS: I hold a soft spot for COHERENT in my heart. I became interested in Unix in high school, but this was before Linux was really a thing and access to other systems was still hard to come by. I spotted an ad for COHERENT in the back of one of the PC-oriented publications at the time, "Computer Shopper" or some such, and realized that it was *almost* within my reach financially and that I could install it on the computer I already owned. Over the next month or so, I scraped up enough money to buy a copy, did so, and put it on my PC. It was quirky compared to actual Unix distributions, but it was enough to give one a flavor for things. The manual, in particular, did not follow the traditional Unix format, but rather was an alphabetical "lexicon" of commands, system calls and functions and was (I've always thought) particularly well done. Links to the COHERENT lexicon and various other documents: http://www.nesssoftware.com/home/mwc/. I graduated onto other systems rather quickly, but COHERENT served as my introduction to Unix and Unix-like systems. PPS: Bob Swartz is the father of the late Aaron Swartz. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Tue Jan 6 12:40:59 2015 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 5 Jan 2015 18:40:59 -0800 Subject: [TUHS] COHERENT sources released under 3-clause BSD license. In-Reply-To: References: Message-ID: <20150106024059.GD25082@mcvoy.com> This one line hit me hard: > PPS: Bob Swartz is the father of the late Aaron Swartz. Small world. The fact that he is still doing good things after losing his son, wow. I'm a guy who would probably have gone postal if I lost my son. My heart and admiration goes out to Bob. On a fun note, I remember Coherent, it was fun. From lm at mcvoy.com Tue Jan 6 12:49:46 2015 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 5 Jan 2015 18:49:46 -0800 Subject: [TUHS] COHERENT sources released under 3-clause BSD license. In-Reply-To: <20150106024059.GD25082@mcvoy.com> References: <20150106024059.GD25082@mcvoy.com> Message-ID: <20150106024946.GE25082@mcvoy.com> And as a troff fan, I love their docs. My team hates that I love troff but I do. It's a pretty decent markup language and it lends itself to being version controlled. As the BitKeeper guy I like version control. On Mon, Jan 05, 2015 at 06:40:59PM -0800, Larry McVoy wrote: > This one line hit me hard: > > > PPS: Bob Swartz is the father of the late Aaron Swartz. > > Small world. The fact that he is still doing good things after losing his > son, wow. > > I'm a guy who would probably have gone postal if I lost my son. My heart > and admiration goes out to Bob. > > On a fun note, I remember Coherent, it was fun. > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From imp at bsdimp.com Tue Jan 6 13:01:04 2015 From: imp at bsdimp.com (Warner Losh) Date: Mon, 5 Jan 2015 20:01:04 -0700 Subject: [TUHS] COHERENT sources released under 3-clause BSD license. In-Reply-To: <20150106024946.GE25082@mcvoy.com> References: <20150106024059.GD25082@mcvoy.com> <20150106024946.GE25082@mcvoy.com> Message-ID: <13F6FD2B-7520-4EF7-A210-D03AEC6B11D2@bsdimp.com> I wonder if this will run on my old DEC Rainbow 100B… There was a binary version of COHERENT for the RAINBOW, iirc, that I’ve been hoping to get my hands on for more years than most of my co-workers have been alive… But I’m pretty sure that was version 2…. Hmmm, some googling suggests it was Venix/86R, which sadly hasn’t turned up in years :( Warner > On Jan 5, 2015, at 7:49 PM, Larry McVoy wrote: > > And as a troff fan, I love their docs. My team hates that I love troff > but I do. It's a pretty decent markup language and it lends itself to > being version controlled. As the BitKeeper guy I like version control. > > On Mon, Jan 05, 2015 at 06:40:59PM -0800, Larry McVoy wrote: >> This one line hit me hard: >> >>> PPS: Bob Swartz is the father of the late Aaron Swartz. >> >> Small world. The fact that he is still doing good things after losing his >> son, wow. >> >> I'm a guy who would probably have gone postal if I lost my son. My heart >> and admiration goes out to Bob. >> >> On a fun note, I remember Coherent, it was fun. >> _______________________________________________ >> TUHS mailing list >> TUHS at minnie.tuhs.org >> https://minnie.tuhs.org/mailman/listinfo/tuhs > > -- > --- > Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From akosela at andykosela.com Tue Jan 6 14:54:21 2015 From: akosela at andykosela.com (Andy Kosela) Date: Mon, 5 Jan 2015 22:54:21 -0600 Subject: [TUHS] Illumos ) In-Reply-To: References: <20141231062219.GA21046@mcvoy.com> <1420018115.54a3c1c32faaa@www.paradise.net.nz> <20141231131335.GA26926@mercury.ccil.org> <54A4357F.9040703@aueb.gr> <20141231203617.GB3922@mcvoy.com> <20141231224249.GA5833@mcvoy.com> Message-ID: On Mon, Jan 5, 2015 at 11:04 AM, Jacob Ritorto wrote: > Here's my favourite Solaris coffin nail: Oracle's last five years of > lawnmowing, almost zero innovative milestones and clueless customer base and > community erosion and desecration. I do now agree that Solaris is finally > and irredeemably dead. Their lack of understanding and stewardship has > tragically transitioned it from the being the definitive unix system to, in > essence, a proprietary firmware for expensive iron. But in the same breath > I'd also assert that Illumos and its derivatives have taken all the good > from it, continue to drive the fork forward in a wonderful variety of ways, > and are the repo- and distros-of-record for this flavour of unix. This is your way of putting history together, but I think that objective view on the matter potray this a little bit differently. I personally know a lot of Fortune 500 shops still using Oracle Solaris and happily migrating from Solaris 10 to Solaris 11, instead of embracing Illumos and myriad of its incarnations. You know why? There could be only one answer -- all of those shops depend heavily on other technologies provided by Oracle like databases and middleware, and by sticking to one support vendor they actually save a lot. There is even more -- I see an increasing trend in adopting Oracle Linux in enterprise in place of Red Hat Enterprise Linux also because of the integration with Oracle databases and other Oracle technologies. It is a shame that Oracle closed Solaris source, but to be honest their integration of hardware and software is still unmatched if you ask me. If you take a look at their hardware and software plans they have pretty solid plans going into 2019 for new new CPU's and Solaris versions[1]. Their T4 and T5 chips are pretty sweet and perform really well as compared to x86; they still also put a lot of improvements into ZFS[2], so to say that Oracle Solaris is dead is a gravely exaggeration. In contrast Joyent is still just a small start-up. And start-up's come and go as we have seen recently with the history of Joyent spin-off TextDrive run by Dean Allen. I don't see Oracle going anywhere in the next 25 years or so. just my .02 --Andy [1] http://www.oracle.com/us/products/servers-storage/servers/sparc/oracle-sparc/sparc-roadmap-slide-2076743.pdf [2] https://blogs.oracle.com/darren/en_GB/entry/new_zfs_encryption_features_in From fair-tuhs at netbsd.org Tue Jan 6 17:02:27 2015 From: fair-tuhs at netbsd.org (Erik E. Fair) Date: Mon, 05 Jan 2015 23:02:27 -0800 Subject: [TUHS] State of networking in the early '90s In-Reply-To: <20150106015536.GA27434@www.oztivo.net> References: <534d2eef8d0fb84d3880c067d9e1517d@xs4all.nl> Message-ID: <22750.1420527747@cesium.clock.org> > Date: Tue, 6 Jan 2015 12:55:36 +1100 > From: Warren Toomey > > On Mon, Jan 05, 2015 at 10:59:26AM +0100, Jacob Goense wrote: > > Early 80s INTELPOST ran on small 11s running RT-11/RSX-11 with Mills' > > fuzzball bolted on top. These were hooked up to DACOM or Rapicom fax > > machines. > > Reading this e-mail caused me to read up on the fuzzball, which then lead me > to this overview of the state of networking in the early '90s: 31 years ago almost to the day, I stayed up until 01:30 PST to write a description of all of the networks I knew of in response to a query on the HUMAN-NETS mailing list; it appears under the subject "The Plethora of Networks" in HUMAN-NETS digest V7 #1 which can be found: http://www.cs.rutgers.edu/~cwm/NetStuff/Human-Nets/Volume7.html A number of others also chimed in, and the resulting discussion inspired (and was source material for) John S. Quarterman's book "The Matrix" (1989): http://www.amazon.com/The-Matrix-Computer-Conferencing-Worldwide/dp/1555580335 It's a bit of a budgie-killer, but a fine snapshot of what was at that time. Erik From angus at fairhaven.za.net Tue Jan 6 17:37:56 2015 From: angus at fairhaven.za.net (Angus Robinson) Date: Tue, 6 Jan 2015 09:37:56 +0200 Subject: [TUHS] State of networking in the early '90s In-Reply-To: <20150106015536.GA27434@www.oztivo.net> References: <534d2eef8d0fb84d3880c067d9e1517d@xs4all.nl> <20150106015536.GA27434@www.oztivo.net> Message-ID: Hi Warren It seems like it would be an interesting read. Would you mind sending me a copy of the epub? On Tue, Jan 6, 2015 at 3:55 AM, Warren Toomey wrote: > On Mon, Jan 05, 2015 at 10:59:26AM +0100, Jacob Goense wrote: > > Early 80s INTELPOST ran on small 11s running RT-11/RSX-11 with Mills' > > fuzzball bolted on top. These were hooked up to DACOM or Rapicom fax > > machines. > > Reading this e-mail caused me to read up on the fuzzball, which then lead > me > to this overview of the state of networking in the early '90s: > > http://museum.media.org/eti/ > > In 1990 and 1991, I made three trips around the world to write a > technical travelogue. The result was the book "Exploring the > Internet", originally published by Prentice-Hall. Perhaps because > they felt the Internet trend had passed, or more likely because > of the less-than-mainstream appeal, they allowed the book to go > out of print. I decided to republish the book on the Internet in > the hope that perhaps it retains some minor historical interest. > > So far I've got through about 6 chapters and it's a good read. I've made it > into an epub if anybody wants a copy. > > Cheers, Warren > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Tue Jan 6 18:07:54 2015 From: wkt at tuhs.org (Warren Toomey) Date: Tue, 6 Jan 2015 19:07:54 +1100 Subject: [TUHS] COHERENT sources released under 3-clause BSD license. In-Reply-To: References: Message-ID: <20150106080754.GA16120@www.oztivo.net> On Mon, Jan 05, 2015 at 09:23:58PM -0500, Dan Cross wrote: > Bob Swartz, founder of Mark Williams Co, has allowed the sources for > COHERENT to be published under a three-clause BSD license. Steve Ness > is hosting them. They are available here: > http://nesssoftware.com/home/mwc/source.php The Unix Archive has some Coherent files at: http://www.tuhs.org/Archive/Other/Coherent/ I'll mirror Steve's files along with the copyright notice and place them in a sub-folder of the above URL. Cheers all, Warren From khm at sciops.net Tue Jan 6 21:10:05 2015 From: khm at sciops.net (Kurt H Maier) Date: Tue, 06 Jan 2015 11:10:05 +0000 Subject: [TUHS] Illumos ) In-Reply-To: References: <20141231062219.GA21046@mcvoy.com> <1420018115.54a3c1c32faaa@www.paradise.net.nz> <20141231131335.GA26926@mercury.ccil.org> <54A4357F.9040703@aueb.gr> <20141231203617.GB3922@mcvoy.com> <20141231224249.GA5833@mcvoy.com> Message-ID: <20150106111005.Horde.tR5qOnLIK14Fxim9iVGlRQ3@ssl.eumx.net> Quoting Andy Kosela : > There could be only one answer -- Vendor lock-in is not going to save Oracle Solaris, in exactly the same way DB2 did not save AIX. khm From arnold at skeeve.com Tue Jan 6 22:22:56 2015 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 06 Jan 2015 05:22:56 -0700 Subject: [TUHS] termcap vs terminfo (was: I swear! I rtfm'ed) In-Reply-To: <20150106004054.GD16715@mercury.ccil.org> References: <3578.1420226008@cesium.clock.org> <20150105070613.GB10940@server.rulingia.com> <20150106004054.GD16715@mercury.ccil.org> Message-ID: <201501061222.t06CMvTO027313@freefriends.org> > Peter Jeremy scripsit: > > But you pay for the size of $TERMCAP in every process you run. John Cowan wrote: > A single termcap line doesn't cost that much, less than a KB in most cases. In 1981 terms, this has more weight. On a non-split I/D PDP-11 you only have 32KB to start with. (The discussion a few weeks ago about cutting yacc down to size comes to mind...) On a Vax with 2 Meg of memory, 512 bytes is a whole page, and it might even be paged out, and BSD on the vax didn't have copy-on-write. ISTR that the /etc/termcap file had a comment saying something like "you should move the entries needed at your site to the top of this file." Or am I imagining it? :-) In short - today, sure, no problem - back then, carrying around a large environment made more of a difference. Thanks, Arnold From doug at cs.dartmouth.edu Tue Jan 6 23:41:37 2015 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Tue, 06 Jan 2015 08:41:37 -0500 Subject: [TUHS] COHERENT sources released under 3-clause BSD license. Message-ID: <201501061341.t06Dfbsh025288@coolidge.cs.dartmouth.edu> A very nice addition to the archives. Thank you. I well remember our disbelief that Mark Williams wrote all its own code, unlike other vendors who had professed the same. As Dennis described, we had fun putting together black-box tests that recognized undocumented quirks (or bugs) in our code. We were duly impressed when the results came back negative. Doug From rp at servium.ch Wed Jan 7 00:25:30 2015 From: rp at servium.ch (Rico Pajarola) Date: Tue, 6 Jan 2015 09:25:30 -0500 Subject: [TUHS] COHERENT sources released under 3-clause BSD license. In-Reply-To: <201501061341.t06Dfbsh025288@coolidge.cs.dartmouth.edu> References: <201501061341.t06Dfbsh025288@coolidge.cs.dartmouth.edu> Message-ID: do you still have those black-box tests somewhere? On Tue, Jan 6, 2015 at 8:41 AM, Doug McIlroy wrote: > A very nice addition to the archives. Thank you. > > I well remember our disbelief that Mark Williams wrote all its own > code, unlike other vendors who had professed the same. As Dennis > described, we had fun putting together black-box tests that > recognized undocumented quirks (or bugs) in our code. We were > duly impressed when the results came back negative. > > Doug > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tfb at tfeb.org Wed Jan 7 01:37:36 2015 From: tfb at tfeb.org (Tim Bradshaw) Date: Tue, 6 Jan 2015 15:37:36 +0000 Subject: [TUHS] Illumos ) In-Reply-To: References: <20141231062219.GA21046@mcvoy.com> <1420018115.54a3c1c32faaa@www.paradise.net.nz> <20141231131335.GA26926@mercury.ccil.org> <54A4357F.9040703@aueb.gr> <20141231203617.GB3922@mcvoy.com> <20141231224249.GA5833@mcvoy.com> Message-ID: <389F2E19-7E08-4294-914E-49EE2641B118@tfeb.org> On 5 Jan 2015, at 17:04, Jacob Ritorto wrote: > I'm afraid there's bias confirmation and a zeal for driving nails into coffins happening here. Bear in mind that unix didn't even have fsck for a decade after its release (it appeared after v7 released), while conversely, zfs had the manual scrub command and other manual zfs recovery tools (which, much like fsck and icheck, et al, admittedly required expert knowledge to wield successfully) before it released. I own a vintage car, by which I don't mean the spurious things people now call 'vintage' but a car registered in 1930 or before. It's a lovely thing to drive. But it has no seatbelts, the fuel tank is over your knees and immediately behind the top of the engine (I try not to think about what that means in an accident) and rod brakes which you adjust with wingnuts. I would not be happy with these features in a new car. > Yes, the default is that the system will panic or pass over a zfs it can't mount, but that's by design and when I was in that situation myself, even as a zfs noob, I managed to figure out how to recover without damaging my pool. Would you care to compare this experience to some of the battles we've all personally waged with fsck? Again: the 'fsck on old systems' comparison is simply not relevant, sorry: we have learnt a lot of stuff since then. One thing we should have learnt is that you want code to run with the minimum possible privilege, because running things with too much privilege has led to appalling disasters which I'm sure I don't need to mention. That means, for instance, that you should run nothing in the kernel that does not have to be there. One thing which clearly does not have to be there is consistency checkers and debuggers for filesystems, of whatever kind. There is absolutely nothing in the design of ZFS which prevents that being done. > In the unix tradition, zfs is a designed and deliberate iteration (innovation) on the filesystem concept, not a "pragmatic," good-enough, minimum viable product hip-shot, and the obvious fact that it isn't what we're used to doesn't make it bad. While there are certainly plenty of Solaris coffin nails, this ain't one. I'm extremely happy that ZFS is not a traditional filesystem, because the traditional volume-manager / filesystem model sucks, to put it mildly: I have spent enough of my life dealing with it that I just want it to be over. I just want ZFS to be properly engineered. Instead, what will (has, probably) happen is a ZFS clone will appear for Linux, which will be properly engineered. Such is the fate of Solaris: pride does, indeed, come before a fall. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mah at mhorton.net Wed Jan 7 02:02:54 2015 From: mah at mhorton.net (Mary Ann Horton) Date: Tue, 06 Jan 2015 08:02:54 -0800 Subject: [TUHS] termcap vs terminfo In-Reply-To: <201501061222.t06CMvTO027313@freefriends.org> References: <3578.1420226008@cesium.clock.org> <20150105070613.GB10940@server.rulingia.com> <20150106004054.GD16715@mercury.ccil.org> <201501061222.t06CMvTO027313@freefriends.org> Message-ID: <54AC072E.7030605@mhorton.net> On 01/06/2015 04:22 AM, arnold at skeeve.com wrote: >> Peter Jeremy scripsit: >>> But you pay for the size of $TERMCAP in every process you run. > John Cowan wrote: >> A single termcap line doesn't cost that much, less than a KB in most cases. > In 1981 terms, this has more weight. On a non-split I/D PDP-11 you only > have 32KB to start with. (The discussion a few weeks ago about cutting > yacc down to size comes to mind...) > > On a Vax with 2 Meg of memory, 512 bytes is a whole page, and it might > even be paged out, and BSD on the vax didn't have copy-on-write. > > ISTR that the /etc/termcap file had a comment saying something like > "you should move the entries needed at your site to the top of this file." > Or am I imagining it? :-) > > In short - today, sure, no problem - back then, carrying around a large > environment made more of a difference. > > Thanks, > > Arnold > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs Even with TERMCAP in the environment, there's still that quadratic algorithm every time vi starts up. From imp at bsdimp.com Wed Jan 7 02:32:06 2015 From: imp at bsdimp.com (Warner Losh) Date: Tue, 6 Jan 2015 09:32:06 -0700 Subject: [TUHS] termcap vs terminfo (was: I swear! I rtfm'ed) In-Reply-To: <201501061222.t06CMvTO027313@freefriends.org> References: <3578.1420226008@cesium.clock.org> <20150105070613.GB10940@server.rulingia.com> <20150106004054.GD16715@mercury.ccil.org> <201501061222.t06CMvTO027313@freefriends.org> Message-ID: <7D77811B-8E40-4369-AB4E-513F07DDD0DB@bsdimp.com> > On Jan 6, 2015, at 5:22 AM, arnold at skeeve.com wrote: > >> Peter Jeremy scripsit: >>> But you pay for the size of $TERMCAP in every process you run. > > John Cowan wrote: >> A single termcap line doesn't cost that much, less than a KB in most cases. > > In 1981 terms, this has more weight. On a non-split I/D PDP-11 you only > have 32KB to start with. (The discussion a few weeks ago about cutting > yacc down to size comes to mind...) > > On a Vax with 2 Meg of memory, 512 bytes is a whole page, and it might > even be paged out, and BSD on the vax didn't have copy-on-write. > > ISTR that the /etc/termcap file had a comment saying something like > "you should move the entries needed at your site to the top of this file." > Or am I imagining it? :-) No, you aren’t. And iirc, we moved the HP terminal entries to the top of ours since we got a VAX 11/750, but a bunch of HP terminals instead of DEC ones for reasons that likely involved graft and fraud in the procurement office :) Warner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rp at servium.ch Wed Jan 7 02:48:55 2015 From: rp at servium.ch (Rico Pajarola) Date: Tue, 6 Jan 2015 11:48:55 -0500 Subject: [TUHS] COHERENT sources released under 3-clause BSD license. In-Reply-To: References: <201501061341.t06Dfbsh025288@coolidge.cs.dartmouth.edu> Message-ID: adding the list back On Tue, Jan 6, 2015 at 10:42 AM, Michael Kerpan wrote: > This is a cool development. Does this code build into a working version of > Coherent or is this mainly useful to study? Either way, it should be > interesting to look at the code for a clone specifically aimed at low-end > hardware. > > Mike > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bqt at update.uu.se Wed Jan 7 02:51:06 2015 From: bqt at update.uu.se (Johnny Billquist) Date: Tue, 06 Jan 2015 17:51:06 +0100 Subject: [TUHS] termcap vs terminfo In-Reply-To: References: Message-ID: <54AC127A.5050508@update.uu.se> On 2015-01-06 17:32, Mary Ann Horton wrote: > > On 01/06/2015 04:22 AM,arnold at skeeve.com wrote: >>> >>Peter Jeremy scripsit: >>>> >>>But you pay for the size of $TERMCAP in every process you run. >> >John Cowan wrote: >>> >>A single termcap line doesn't cost that much, less than a KB in most cases. >> >In 1981 terms, this has more weight. On a non-split I/D PDP-11 you only >> >have 32KB to start with. (The discussion a few weeks ago about cutting >> >yacc down to size comes to mind...) >> > >> >On a Vax with 2 Meg of memory, 512 bytes is a whole page, and it might >> >even be paged out, and BSD on the vax didn't have copy-on-write. >> > >> >ISTR that the /etc/termcap file had a comment saying something like >> >"you should move the entries needed at your site to the top of this file." >> >Or am I imagining it?:-) >> > >> >In short - today, sure, no problem - back then, carrying around a large >> >environment made more of a difference. >> > >> >Thanks, >> > >> >Arnold > Even with TERMCAP in the environment, there's still that quadratic > algorithm every time vi starts up. I must be stupid or something. What quadratic algorithm? vi gets the "correct" terminal database entry directly from the environment. Admittedly, getting any variable out of the environment means a linear search of the environment, but that's about it. What am I missing? And once you have that, any operation still means either searching through the terminal definition for the right function, which in itself is also linear, unless you hash that up in your program. But I fail to see where the quadratic behavior comes in. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From crossd at gmail.com Wed Jan 7 02:56:42 2015 From: crossd at gmail.com (Dan Cross) Date: Tue, 6 Jan 2015 11:56:42 -0500 Subject: [TUHS] termcap vs terminfo In-Reply-To: <54AC127A.5050508@update.uu.se> References: <54AC127A.5050508@update.uu.se> Message-ID: On Tue, Jan 6, 2015 at 11:51 AM, Johnny Billquist wrote: > On 2015-01-06 17:32, Mary Ann Horton wrote: > >> Even with TERMCAP in the environment, there's still that quadratic >> algorithm every time vi starts up. >> > > I must be stupid or something. What quadratic algorithm? > vi gets the "correct" terminal database entry directly from the > environment. Admittedly, getting any variable out of the environment means > a linear search of the environment, but that's about it. > > What am I missing? And once you have that, any operation still means > either searching through the terminal definition for the right function, > which in itself is also linear, unless you hash that up in your program. > But I fail to see where the quadratic behavior comes in. I believe that Mary Ann is referring to repeatedly looking up (presumably different) elements in the entry. Assuming that e.g. `vi` looks up O(n) elements, where $n$ is the number of elements, doing a linear scan for each, you'd end up with quadratic behavior. Hashing, or storing in some kind of balanced-tree like structure or something, would of course help but would also necessitate doing a copy and would entail some additional memory inefficiency. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Wed Jan 7 03:04:52 2015 From: crossd at gmail.com (Dan Cross) Date: Tue, 6 Jan 2015 12:04:52 -0500 Subject: [TUHS] COHERENT sources released under 3-clause BSD license. In-Reply-To: References: <201501061341.t06Dfbsh025288@coolidge.cs.dartmouth.edu> Message-ID: On Tue, Jan 6, 2015 at 11:48 AM, Rico Pajarola wrote: > adding the list back > > On Tue, Jan 6, 2015 at 10:42 AM, Michael Kerpan > wrote: > >> This is a cool development. Does this code build into a working version >> of Coherent or is this mainly useful to study? Either way, it should be >> interesting to look at the code for a clone specifically aimed at low-end >> hardware. >> > Unknown (to me, anyway). Steve said he had intended to organize and catalog the code at some point, but that he hasn't gotten around to it (and not to hold one's breath). I gathered that the tar ball he provided is a snapshot of (a subset of?) the MWC development disks at the time he was asked to create the archive. To that end, I suspect that if one were sufficiently motivated one *could* use it to build a distribution of COHERENT, but I suspect you'd have to know quite a bit about their internal development practices and release processes to do so successfully; knowledge that may very well have been lost over time. Perhaps some motivated person will be able to reverse engineer it, though I suspect it's more useful as a case study than as working code. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Wed Jan 7 03:12:55 2015 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 06 Jan 2015 10:12:55 -0700 Subject: [TUHS] termcap vs terminfo In-Reply-To: <54AC072E.7030605@mhorton.net> References: <3578.1420226008@cesium.clock.org> <20150105070613.GB10940@server.rulingia.com> <20150106004054.GD16715@mercury.ccil.org> <201501061222.t06CMvTO027313@freefriends.org> <54AC072E.7030605@mhorton.net> Message-ID: <201501061712.t06HCtei003805@freefriends.org> Mary Ann Horton wrote: > Even with TERMCAP in the environment, there's still that quadratic > algorithm every time vi starts up. Please remind me which one you're talking about? If TERMCAP is in the environment there's no need to hit /etc/termcap at all. Or are you talking about something else? Thanks, Arnold From bqt at update.uu.se Wed Jan 7 03:33:44 2015 From: bqt at update.uu.se (Johnny Billquist) Date: Tue, 06 Jan 2015 18:33:44 +0100 Subject: [TUHS] termcap vs terminfo In-Reply-To: References: <54AC127A.5050508@update.uu.se> Message-ID: <54AC1C78.6090007@update.uu.se> On 2015-01-06 17:56, Dan Cross wrote: > On Tue, Jan 6, 2015 at 11:51 AM, Johnny Billquist > wrote: > > On 2015-01-06 17:32, Mary Ann Horton > wrote: > > Even with TERMCAP in the environment, there's still that quadratic > algorithm every time vi starts up. > > > I must be stupid or something. What quadratic algorithm? > vi gets the "correct" terminal database entry directly from the > environment. Admittedly, getting any variable out of the environment > means a linear search of the environment, but that's about it. > > What am I missing? And once you have that, any operation still means > either searching through the terminal definition for the right > function, which in itself is also linear, unless you hash that up in > your program. But I fail to see where the quadratic behavior comes in. > > > I believe that Mary Ann is referring to repeatedly looking up > (presumably different) elements in the entry. Assuming that e.g. `vi` > looks up O(n) elements, where $n$ is the number of elements, doing a > linear scan for each, you'd end up with quadratic behavior. Assuming that you'd look up all the elements of the termcap entry at startup, and did each one from scratch, yes. > Hashing, or storing in some kind of balanced-tree like structure or > something, would of course help but would also necessitate doing a copy > and would entail some additional memory inefficiency. Hashing would indeed cause some extra memory, but not necessarily any copying. But that would beg the question, why is vi doing a repeated scan of the terminal entry at startup, if not to find all the capabilities and store this somewhere? And if doing a look for all of them, why not scan the string from start to finish and store the information as it is found? At which point we move from quadratic to linear time. But now we're getting into the innards of vi, which I never looked at anyway, and I guess is less relevant in this thread anyway. The short of it (from what I got out of it) is that the move from termcap to terminfo was mostly motivated by attribute name changing away from fixed 2 character names. A secondary motivation would be performance, but I don't really buy that one. Since we only moved to terminfo on systems with plenty of memory, performance of termcap could easily be on par anyway. Thanks for the insights. Johnny From crossd at gmail.com Wed Jan 7 03:53:27 2015 From: crossd at gmail.com (Dan Cross) Date: Tue, 6 Jan 2015 12:53:27 -0500 Subject: [TUHS] termcap vs terminfo In-Reply-To: <54AC1C78.6090007@update.uu.se> References: <54AC127A.5050508@update.uu.se> <54AC1C78.6090007@update.uu.se> Message-ID: On Tue, Jan 6, 2015 at 12:33 PM, Johnny Billquist wrote: > On 2015-01-06 17:56, Dan Cross wrote: >> >> I believe that Mary Ann is referring to repeatedly looking up >> (presumably different) elements in the entry. Assuming that e.g. `vi` >> looks up O(n) elements, where $n$ is the number of elements, doing a >> linear scan for each, you'd end up with quadratic behavior. >> > > Assuming that you'd look up all the elements of the termcap entry at > startup, and did each one from scratch, yes. Yes. Isn't that exactly what Mary Ann said was happening? :-) Hashing, or storing in some kind of balanced-tree like structure or >> something, would of course help but would also necessitate doing a copy >> and would entail some additional memory inefficiency. >> > > Hashing would indeed cause some extra memory, but not necessarily any > copying. > I fail to see how you can avoid copying the data out of the environment vector (unless you intend to either (a) turn the env var into a hash table, or (b) store pointers to the datum in the env var, but you'd need to encode their length somehow. I don't think environment variables can contain embedded NULs, can they?). But that would beg the question, why is vi doing a repeated scan of the > terminal entry at startup, if not to find all the capabilities and store > this somewhere? And if doing a look for all of them, why not scan the > string from start to finish and store the information as it is found? At > which point we move from quadratic to linear time. > I don't think she said it did things intelligently, just that that's how it did things. :-) But now we're getting into the innards of vi, which I never looked at > anyway, and I guess is less relevant in this thread anyway. > > The short of it (from what I got out of it) is that the move from termcap > to terminfo was mostly motivated by attribute name changing away from fixed > 2 character names. > > A secondary motivation would be performance, but I don't really buy that > one. Since we only moved to terminfo on systems with plenty of memory, > performance of termcap could easily be on par anyway. > I tend to agree with you and I'll go one further: it seems that frequently we tend to identify a problem and then go to 11 with the "solution." I can buy that termcap performance was an issue; I don't know that going directly to hashed terminfo files was the optimal solution. A dbm file of termcap data and a hash table in whatever library parsed termcap would go a long way towards fixing the performance issues. Did termcap have to be discarded just to add longer names? I kind of tend to doubt it, but I wasn't there and don't know what the design criteria were, so my very-much-after-the-fact second guessing is just that. Thanks for the insights. > > Johnny > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Wed Jan 7 04:02:51 2015 From: imp at bsdimp.com (Warner Losh) Date: Tue, 6 Jan 2015 11:02:51 -0700 Subject: [TUHS] COHERENT sources released under 3-clause BSD license. In-Reply-To: <20150106080754.GA16120@www.oztivo.net> References: <20150106080754.GA16120@www.oztivo.net> Message-ID: > On Jan 6, 2015, at 1:07 AM, Warren Toomey wrote: > > On Mon, Jan 05, 2015 at 09:23:58PM -0500, Dan Cross wrote: >> Bob Swartz, founder of Mark Williams Co, has allowed the sources for >> COHERENT to be published under a three-clause BSD license. Steve Ness >> is hosting them. They are available here: >> http://nesssoftware.com/home/mwc/source.php > > The Unix Archive has some Coherent files at: > http://www.tuhs.org/Archive/Other/Coherent/ > > I'll mirror Steve's files along with the copyright notice and place them > in a sub-folder of the above URL. Cool! Looking at Steve’s files, though, it looks like they could use some curating since they are rather jumbled up. It’s great all the stuff that’s there is there, but it makes it a bit hard to browse with tarballs inside of tarballs and multiple copies of what looks like the same thing (but with differences). Also, the mirrors mentioned in the Other/Coherent read me appear to be gone. Warner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From imp at bsdimp.com Wed Jan 7 04:09:58 2015 From: imp at bsdimp.com (Warner Losh) Date: Tue, 6 Jan 2015 11:09:58 -0700 Subject: [TUHS] COHERENT sources released under 3-clause BSD license. In-Reply-To: References: <201501061341.t06Dfbsh025288@coolidge.cs.dartmouth.edu> Message-ID: <63B244BE-7BB0-4E7F-A589-8CD4B9FF42AF@bsdimp.com> > On Jan 6, 2015, at 10:04 AM, Dan Cross wrote: > > On Tue, Jan 6, 2015 at 11:48 AM, Rico Pajarola wrote: > adding the list back > > On Tue, Jan 6, 2015 at 10:42 AM, Michael Kerpan wrote: > This is a cool development. Does this code build into a working version of Coherent or is this mainly useful to study? Either way, it should be interesting to look at the code for a clone specifically aimed at low-end hardware. > > Unknown (to me, anyway). Steve said he had intended to organize and catalog the code at some point, but that he hasn't gotten around to it (and not to hold one's breath). I gathered that the tar ball he provided is a snapshot of (a subset of?) the MWC development disks at the time he was asked to create the archive. To that end, I suspect that if one were sufficiently motivated one *could* use it to build a distribution of COHERENT, but I suspect you'd have to know quite a bit about their internal development practices and release processes to do so successfully; knowledge that may very well have been lost over time. Perhaps some motivated person will be able to reverse engineer it, though I suspect it's more useful as a case study than as working code. Looking at the tarballs and the tarballs inside, this is a mess. It looks like it is all there, but there’s multiple copies of things that are almost identical, RCS files that are mostly enough, but not completely enough, etc. Plus they were using gcc 2.5.1 for compiling things, so using a more modern compiler likely will result in “difficulties”. There’s some docs laying around, but I haven’t read through them all. The collection needs curating TLC... Warner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From random832 at fastmail.us Wed Jan 7 04:41:14 2015 From: random832 at fastmail.us (random832 at fastmail.us) Date: Tue, 06 Jan 2015 13:41:14 -0500 Subject: [TUHS] COHERENT sources released under 3-clause BSD license. In-Reply-To: References: <201501061341.t06Dfbsh025288@coolidge.cs.dartmouth.edu> Message-ID: <1420569674.381164.210321493.7C9C5223@webmail.messagingengine.com> On Tue, Jan 6, 2015, at 11:48, Rico Pajarola wrote: > adding the list back > > On Tue, Jan 6, 2015 at 10:42 AM, Michael Kerpan > wrote: > > > This is a cool development. Does this code build into a working version of > > Coherent or is this mainly useful to study? Either way, it should be > > interesting to look at the code for a clone specifically aimed at low-end > > hardware. In the "distrib" directory there are four files exactly 1440 kb in size - maybe someone could try loading those into a VM/Emulator? From milov at cs.uwlax.edu Wed Jan 7 05:38:28 2015 From: milov at cs.uwlax.edu (=?utf-8?Q?Milo_Velimirovi=C4=87?=) Date: Tue, 6 Jan 2015 13:38:28 -0600 Subject: [TUHS] COHERENT sources released under 3-clause BSD license. In-Reply-To: <1420569674.381164.210321493.7C9C5223@webmail.messagingengine.com> References: <201501061341.t06Dfbsh025288@coolidge.cs.dartmouth.edu> <1420569674.381164.210321493.7C9C5223@webmail.messagingengine.com> Message-ID: <2BE827F7-5498-4D7A-90B9-1228BBBEB950@cs.uwlax.edu> On Jan 6, 2015, at 12:41 PM, random832 at fastmail.us wrote: > On Tue, Jan 6, 2015, at 11:48, Rico Pajarola wrote: >> adding the list back >> >> On Tue, Jan 6, 2015 at 10:42 AM, Michael Kerpan >> wrote: >> >>> This is a cool development. Does this code build into a working version of >>> Coherent or is this mainly useful to study? Either way, it should be >>> interesting to look at the code for a clone specifically aimed at low-end >>> hardware. > > In the "distrib" directory there are four files exactly 1440 kb in size > - maybe someone could try loading those into a VM/Emulator? I had exactly that thought after I downloaded the tar ball this morning. Any suggestions for a VM config that would facilitate this would be welcome. Otherwise I’m going to stumble through virtual box and see what happens. - Milo From dugo at xs4all.nl Wed Jan 7 05:50:23 2015 From: dugo at xs4all.nl (Jacob Goense) Date: Tue, 06 Jan 2015 20:50:23 +0100 Subject: [TUHS] COHERENT sources released under 3-clause BSD license. In-Reply-To: <2BE827F7-5498-4D7A-90B9-1228BBBEB950@cs.uwlax.edu> References: <201501061341.t06Dfbsh025288@coolidge.cs.dartmouth.edu> <1420569674.381164.210321493.7C9C5223@webmail.messagingengine.com> <2BE827F7-5498-4D7A-90B9-1228BBBEB950@cs.uwlax.edu> Message-ID: On 2015-01-06 20:38, Milo Velimirović wrote: > On Jan 6, 2015, at 12:41 PM, random832 at fastmail.us wrote: > >> On Tue, Jan 6, 2015, at 11:48, Rico Pajarola wrote: >>> adding the list back >>> >>> On Tue, Jan 6, 2015 at 10:42 AM, Michael Kerpan >>> wrote: >>> >>>> This is a cool development. Does this code build into a working >>>> version of >>>> Coherent or is this mainly useful to study? Either way, it should be >>>> interesting to look at the code for a clone specifically aimed at >>>> low-end >>>> hardware. >> >> In the "distrib" directory there are four files exactly 1440 kb in >> size >> - maybe someone could try loading those into a VM/Emulator? > > I had exactly that thought after I downloaded the tar ball this > morning. Any suggestions for a VM config that would facilitate this > would be welcome. Otherwise I’m going to stumble through virtual box > and see what happens. A quick try with bochs bails out on me, but at least reveals the version: COHERENT Tertiary boot Version 1.2.7 If installing COHERENT, please type "begin". ? begin Loading COHERENT. - Loading COHERENT data. [-screen clears-] *** COHERENT Version 4.2.10 - 386 Mode. 5712KB free memory. *** Color. NDP=387. 2528 buffers. 2521 buckets. 64 clists. 256KB kalloc pool. 0 KB phys pool. Cyrix OEM CPU Detected Copyright 1982, 1994 Mark Williams Company fd0: PANIC : fsminit: no rootdev(4,15) Call backtrace: -> ffc28142 -> ffc19129 -> ffc002b6 If you want to run COHERENT in a VM this is mandatory reading. http://thebeezspeaks.blogspot.com/2012/02/my-life-with-coherent-part-1.html http://thebeezspeaks.blogspot.nl/2012/05/my-life-with-coherent-part-2.html /Jacob From crossd at gmail.com Wed Jan 7 05:52:33 2015 From: crossd at gmail.com (Dan Cross) Date: Tue, 6 Jan 2015 14:52:33 -0500 Subject: [TUHS] COHERENT sources released under 3-clause BSD license. In-Reply-To: <2BE827F7-5498-4D7A-90B9-1228BBBEB950@cs.uwlax.edu> References: <201501061341.t06Dfbsh025288@coolidge.cs.dartmouth.edu> <1420569674.381164.210321493.7C9C5223@webmail.messagingengine.com> <2BE827F7-5498-4D7A-90B9-1228BBBEB950@cs.uwlax.edu> Message-ID: On Tue, Jan 6, 2015 at 2:38 PM, Milo Velimirović wrote: > On Jan 6, 2015, at 12:41 PM, random832 at fastmail.us wrote: > > In the "distrib" directory there are four files exactly 1440 kb in size > > - maybe someone could try loading those into a VM/Emulator? > > I had exactly that thought after I downloaded the tar ball this morning. > Any suggestions for a VM config that would facilitate this would be > welcome. Otherwise I’m going to stumble through virtual box and see what > happens. > Those look an awful lot like the distribution disks for COHERENT 4.2.10. There's a writeup of how to get that installed and running under qemu here: http://thebeezspeaks.blogspot.in/2012/05/my-life-with-coherent-part-2.html However, there have been some reports of stability issues with the emulated disk under qemu; VirtualBox seems to be the most consistently reliable (and fast!) alternative, but you have to run it under a 32-bit host OS. I ended up installing a 32-bit Linux under VMWare to run virtual box to run COHERENT (yes, it's awful). I haven't tried qemu lately to see if the stability problems have been addressed, though. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From milov at cs.uwlax.edu Wed Jan 7 05:57:43 2015 From: milov at cs.uwlax.edu (=?utf-8?Q?Milo_Velimirovi=C4=87?=) Date: Tue, 6 Jan 2015 13:57:43 -0600 Subject: [TUHS] pdp11 UNIX memory allocation. Was: termcap vs terminfo (was: I swear! I rtfm'ed) In-Reply-To: <201501061222.t06CMvTO027313@freefriends.org> References: <3578.1420226008@cesium.clock.org> <20150105070613.GB10940@server.rulingia.com> <20150106004054.GD16715@mercury.ccil.org> <201501061222.t06CMvTO027313@freefriends.org> Message-ID: Bringing a conversation back online. On Jan 6, 2015, at 6:22 AM, arnold at skeeve.com wrote: >> Peter Jeremy scripsit: >>> But you pay for the size of $TERMCAP in every process you run. > > John Cowan wrote: >> A single termcap line doesn't cost that much, less than a KB in most cases. > > In 1981 terms, this has more weight. On a non-split I/D PDP-11 you only > have 32KB to start with. (The discussion a few weeks ago about cutting > yacc down to size comes to mind…) (Or even earlier than ’81.) How did pdp11 UNIXes handle per process memory? It’s suggested above that there was a 50-50 split of the 64KB address space between instructions and data. My own recollection is that you got any combination of instruction and data space that was <64KB. This would also be subject to limits of pdp11 memory management unit. Anyone have a definitive answer or pointer to appropriate man page or source code? Thanks, Milo From clemc at ccc.com Wed Jan 7 06:01:37 2015 From: clemc at ccc.com (Clem Cole) Date: Tue, 6 Jan 2015 15:01:37 -0500 Subject: [TUHS] pdp11 UNIX memory allocation. Was: termcap vs terminfo (was: I swear! I rtfm'ed) In-Reply-To: References: <3578.1420226008@cesium.clock.org> <20150105070613.GB10940@server.rulingia.com> <20150106004054.GD16715@mercury.ccil.org> <201501061222.t06CMvTO027313@freefriends.org> Message-ID: Depends the processor. For the 11/45 class processors, you had a 17th address bit, which was the I/D choice. For the 11/40 class you shared the instructions and data space. So you had to use overlays and thunks at lot sooner. On Tue, Jan 6, 2015 at 2:57 PM, Milo Velimirović wrote: > Bringing a conversation back online. > On Jan 6, 2015, at 6:22 AM, arnold at skeeve.com wrote: > > >> Peter Jeremy scripsit: > >>> But you pay for the size of $TERMCAP in every process you run. > > > > John Cowan wrote: > >> A single termcap line doesn't cost that much, less than a KB in most > cases. > > > > In 1981 terms, this has more weight. On a non-split I/D PDP-11 you only > > have 32KB to start with. (The discussion a few weeks ago about cutting > > yacc down to size comes to mind…) > > (Or even earlier than ’81.) How did pdp11 UNIXes handle per process > memory? It’s suggested above that there was a 50-50 split of the 64KB > address space between instructions and data. My own recollection is that > you got any combination of instruction and data space that was <64KB. This > would also be subject to limits of pdp11 memory management unit. > > Anyone have a definitive answer or pointer to appropriate man page or > source code? > > > Thanks, > Milo > > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bqt at update.uu.se Wed Jan 7 06:20:36 2015 From: bqt at update.uu.se (Johnny Billquist) Date: Tue, 06 Jan 2015 21:20:36 +0100 Subject: [TUHS] pdp11 UNIX memory allocation. In-Reply-To: References: Message-ID: <54AC4394.3050302@update.uu.se> On 2015-01-06 20:57, Milo Velimirovi? wrote: > Bringing a conversation back online. > On Jan 6, 2015, at 6:22 AM,arnold at skeeve.com wrote: > >>> >>Peter Jeremy scripsit: >>>> >>>But you pay for the size of $TERMCAP in every process you run. >> > >> >John Cowan wrote: >>> >>A single termcap line doesn't cost that much, less than a KB in most cases. >> > >> >In 1981 terms, this has more weight. On a non-split I/D PDP-11 you only >> >have 32KB to start with. (The discussion a few weeks ago about cutting >> >yacc down to size comes to mind?) > (Or even earlier than ?81.) How did pdp11 UNIXes handle per process memory? It?s suggested above that there was a 50-50 split of the 64KB address space between instructions and data. My own recollection is that you got any combination of instruction and data space that was <64KB. This would also be subject to limits of pdp11 memory management unit. > > Anyone have a definitive answer or pointer to appropriate man page or source code? You are conflating two things. :-) A standard PDP-11 have 64Kb of virtual memory space. This can be divided any way you want between data and code. Later model PDP-11 processors had a hardware feature called split I/D space. This meant that you could have one 64Kb virtual memory space for instructions, and one 64Kb virtual memory space for data. (This also means that the text you quoted was incorrect, as it stated that you had 32Kb, which is incorrect. It was/is 32 Kword.) Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From random832 at fastmail.us Wed Jan 7 06:33:53 2015 From: random832 at fastmail.us (random832 at fastmail.us) Date: Tue, 06 Jan 2015 15:33:53 -0500 Subject: [TUHS] pdp11 UNIX memory allocation. In-Reply-To: <54AC4394.3050302@update.uu.se> References: <54AC4394.3050302@update.uu.se> Message-ID: <1420576433.410248.210385277.513EF8EC@webmail.messagingengine.com> On Tue, Jan 6, 2015, at 15:20, Johnny Billquist wrote: > Later model PDP-11 processors had a hardware feature called split I/D > space. This meant that you could have one 64Kb virtual memory space for > instructions, and one 64Kb virtual memory space for data. Was it possible to read/write to the instruction space, or execute the data space? From what I've seen, the calling convention for PDP-11 Unix system calls read their arguments from directly after the trap instruction (which would mean that the C wrappers for the system calls would have to write their arguments there, even if assembly programs could have them hardcoded.) From mah at mhorton.net Wed Jan 7 07:32:48 2015 From: mah at mhorton.net (Mary Ann Horton) Date: Tue, 06 Jan 2015 13:32:48 -0800 Subject: [TUHS] termcap vs terminfo Message-ID: <20150106133248.16223dcz4qtnm35s@webmail.mhorton.net> Quoting Dan Cross : > On Tue, Jan 6, 2015 at 12:33 PM, Johnny Billquist wrote: > >> On 2015-01-06 17:56, Dan Cross wrote: >>> >>> I believe that Mary Ann is referring to repeatedly looking up >>> (presumably different) elements in the entry. Assuming that e.g. `vi` >>> looks up O(n) elements, where $n$ is the number of elements, doing a >>> linear scan for each, you'd end up with quadratic behavior. >>> >> >> Assuming that you'd look up all the elements of the termcap entry at >> startup, and did each one from scratch, yes. > > > Yes. Isn't that exactly what Mary Ann said was happening? :-) Yes > But that would beg the question, why is vi doing a repeated scan of the >> terminal entry at startup, if not to find all the capabilities and store >> this somewhere? And if doing a look for all of them, why not scan the >> string from start to finish and store the information as it is found? At >> which point we move from quadratic to linear time. >> > > I don't think she said it did things intelligently, just that that's how it > did things. :-) > > But now we're getting into the innards of vi, which I never looked at > anyway, and I guess is less relevant in this thread anyway. vi does indeed look up all the various capabilities it will need, once, when it starts up. It uses the documented interface, which is tgetent followed by tgetstr/tgetnum/tgetflag for each capability. tgetent did a linear search. >> The short of it (from what I got out of it) is that the move from termcap >> to terminfo was mostly motivated by attribute name changing away from fixed >> 2 character names. >> >> A secondary motivation would be performance, but I don't really buy that >> one. Since we only moved to terminfo on systems with plenty of memory, >> performance of termcap could easily be on par anyway. >> > > I tend to agree with you and I'll go one further: it seems that frequently > we tend to identify a problem and then go to 11 with the "solution." I can > buy that termcap performance was an issue; I don't know that going directly > to hashed terminfo files was the optimal solution. A dbm file of termcap > data and a hash table in whatever library parsed termcap would go a long > way towards fixing the performance issues. Did termcap have to be > discarded just to add longer names? I kind of tend to doubt it, but I > wasn't there and don't know what the design criteria were, so my > very-much-after-the-fact second guessing is just that. It's been 30+ years, so the memory is a little fuzzy. But as I recall, I did measure the performance and that's how I discovered that the quadratic algorithm was causing a big performance hit on the hardware available at the time (I think I was on a VAX 11/750, this would have been about 1982.) I was making several improvements at the same time. The biggest one was rewriting curses to improve the screen update optimization, so it would use insert/delete line/character on terminals supporting it. Cleaning up the mess termcap had become (the format had become horrible to update, and I was spending a lot of time making updates with all the new terminals coming out) and improving startup time (curses also had to read in a lot of attributes) were part of an overall cleanup. IIRC, there may also have been some restrictions on parameters to string capabilities that needed to be generalized. Hashing could have been done differently, using DBM or some other method. In fact, I'd used DBM to hash /etc/aliases in delivermail years earlier (I have an amusing story about the worlds slowest email I'll tell some other time) but at the time, it seemed best to break with termcap and go with a cleaner format. From ron at ronnatalie.com Wed Jan 7 07:57:14 2015 From: ron at ronnatalie.com (Ronald Natalie) Date: Tue, 6 Jan 2015 16:57:14 -0500 Subject: [TUHS] pdp11 UNIX memory allocation. In-Reply-To: <1420576433.410248.210385277.513EF8EC@webmail.messagingengine.com> References: <54AC4394.3050302@update.uu.se> <1420576433.410248.210385277.513EF8EC@webmail.messagingengine.com> Message-ID: <5E62DDAA-0055-46FB-8077-92DB856DEEE0@ronnatalie.com> > On Jan 6, 2015, at 3:33 PM, random832 at fastmail.us wrote: > > Was it possible to read/write to the instruction space, or execute the > data space? In split I/D mode (411) magic number. It is imposible to execute in D space or use regular data access instructions to access i-space. The addresses are in completely different spaces (i.e, 0 in data is mapped to different memory than 0 in instruction space). Some access at the kernel level can be done with MFPI and MPFD instructions. In write protected, non-split more (410 magic), you could read the I space and you could jump in to D space. You were prohibited to write the i space. In non protected mode (407 magic) everything was fair game. From clemc at ccc.com Wed Jan 7 07:58:30 2015 From: clemc at ccc.com (Clem Cole) Date: Tue, 6 Jan 2015 16:58:30 -0500 Subject: [TUHS] Illumos ) In-Reply-To: References: <20141231062219.GA21046@mcvoy.com> <1420018115.54a3c1c32faaa@www.paradise.net.nz> <20141231131335.GA26926@mercury.ccil.org> <54A4357F.9040703@aueb.gr> <20141231203617.GB3922@mcvoy.com> <20141231224249.GA5833@mcvoy.com> Message-ID: On Mon, Jan 5, 2015 at 12:04 PM, Jacob Ritorto wrote: > Bear in mind that unix didn't even have fsck for a decade after its > release (it appeared after v7 released), ​That is actually not wholly true - although in practice you are probably right. The late Ted Kowalski starting writing fsck as an undergrad at Michigan in about 1976 and then finished it up as a grad student at CMU in 1977 with a summer of work in between at BTL [if I have the dates right -- Armando I think you OYOC at the same time as Ted - is that about right]. BTW: fsck was the program Ted introduced me to C, as I was BLISS hacker before that. Anyway, all of that was done on 6th edition not 7th. Fsck was first released as part of Unix TS inside the labs and migrated independently of any base distribution - although it was included as part of BSD. Ted has been Bill Joy's roommate at Michigan and I never knew how UCB got it, but I'm guessing it was that connection because it was already at UCB by the time I arrived. I never knew for sure, but I think from a legal standpoint it was assumed a CMU program, so BTL could not make claims on it - since you right it was not part of V7 either. Also, for those of you that never saw Unix before fsck or before the work that Goble did at Purdue to get the write ordering down, you have no idea what it was like to put a file system back together. The sync;sync;sync stuff was because of the lack write ordering; but even with that, small file system corruptions where common. fsck was a huge improvement. Also in an earlier thread people we asking about small address space. One of the issues Ted had to deal with early in the life of fsck was that the size of a file system on something like the RP06 was too large for the data structures (just think the RP06 had a formatted capacity of less than 200 Mbytes and we partitioned them into smaller file systems). So, some of you will remember. that when fsck started up, it asked for a temp file [which could be tricky if you were trying to fix the root file system]. In fact, one of the things I worked on was the code that allowed us the deal with the temp file so we could swap those large structures in and out memory and still work on and 11/40 without I/D space. If you look at the early fsck code on Warren's site, I suspect you can find it - crude as it may be -- it worked pretty well. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Jan 7 08:00:20 2015 From: clemc at ccc.com (Clem Cole) Date: Tue, 6 Jan 2015 17:00:20 -0500 Subject: [TUHS] pdp11 UNIX memory allocation. In-Reply-To: <5E62DDAA-0055-46FB-8077-92DB856DEEE0@ronnatalie.com> References: <54AC4394.3050302@update.uu.se> <1420576433.410248.210385277.513EF8EC@webmail.messagingengine.com> <5E62DDAA-0055-46FB-8077-92DB856DEEE0@ronnatalie.com> Message-ID: Right - that's how the kernel set up the page tables for the user processes. On Tue, Jan 6, 2015 at 4:57 PM, Ronald Natalie wrote: > > > On Jan 6, 2015, at 3:33 PM, random832 at fastmail.us wrote: > > > > Was it possible to read/write to the instruction space, or execute the > > data space? > > In split I/D mode (411) magic number. It is imposible to execute in D > space or use regular data access instructions to access i-space. The > addresses are in completely different spaces (i.e, 0 in data is mapped to > different memory than 0 in instruction space). Some access at the kernel > level can be done with MFPI and MPFD instructions. > > In write protected, non-split more (410 magic), you could read the I space > and you could jump in to D space. You were prohibited to write the i > space. > > In non protected mode (407 magic) everything was fair game. > > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Wed Jan 7 08:02:49 2015 From: ron at ronnatalie.com (Ronald Natalie) Date: Tue, 6 Jan 2015 17:02:49 -0500 Subject: [TUHS] pre-FSCK days In-Reply-To: References: <20141231062219.GA21046@mcvoy.com> <1420018115.54a3c1c32faaa@www.paradise.net.nz> <20141231131335.GA26926@mercury.ccil.org> <54A4357F.9040703@aueb.gr> <20141231203617.GB3922@mcvoy.com> <20141231224249.GA5833@mcvoy.com> Message-ID: <1CA66E3E-8596-460B-BF47-5D23A3E3211B@ronnatalie.com> Yep I remember those days. In order to get signed on to work in the UNIX computer center I had to demonstrate I knew the structure of the V6 filesystem and what icheck and dcheck reported, what the common errors were, and how to fix them. Two things changed. First FSCK was wriiten, but even to make that useful, some fixes were done to the ordering of operations in the kernel so that the file system wouldn’t be left in a degenerate state after crashes. Before these changes were made inode link counts less than the number of directory links and dups in free were common. After the changes to the FS, you’d get missing blocks and a few 0-0 inodes (or ones where the links count was higher than the links). These while wasteful were not going to cause problems. From ron at ronnatalie.com Wed Jan 7 08:04:30 2015 From: ron at ronnatalie.com (Ronald Natalie) Date: Tue, 6 Jan 2015 17:04:30 -0500 Subject: [TUHS] pdp11 UNIX memory allocation. In-Reply-To: References: <54AC4394.3050302@update.uu.se> <1420576433.410248.210385277.513EF8EC@webmail.messagingengine.com> <5E62DDAA-0055-46FB-8077-92DB856DEEE0@ronnatalie.com> Message-ID: And then of course there was the famous ISVTX bit (also known as the sticky or t bit). From bqt at update.uu.se Wed Jan 7 08:20:04 2015 From: bqt at update.uu.se (Johnny Billquist) Date: Tue, 06 Jan 2015 23:20:04 +0100 Subject: [TUHS] pdp11 UNIX memory allocation In-Reply-To: References: Message-ID: <54AC5F94.3080401@update.uu.se> On 2015-01-06 22:59, random832 at fastmail.us wrote: > On Tue, Jan 6, 2015, at 15:20, Johnny Billquist wrote: >> >Later model PDP-11 processors had a hardware feature called split I/D >> >space. This meant that you could have one 64Kb virtual memory space for >> >instructions, and one 64Kb virtual memory space for data. > Was it possible to read/write to the instruction space, or execute the > data space? From what I've seen, the calling convention for PDP-11 Unix > system calls read their arguments from directly after the trap > instruction (which would mean that the C wrappers for the system calls > would have to write their arguments there, even if assembly programs > could have them hardcoded.) Nope. A process cannot read or write to instruction space, nor can it execute from data space. It's inherent in the MMU. All references related to the PC will be done from I-space, while everything else will be done through D-space. So the MMU have two sets of page registers. One set maps I-space, and another maps D-space. Of course, you can have them overlap, in which case you get the traditional appearance of older models. The versions of Unix I am aware of push arguments on the stack. But of course, the kernel can remap memory, and so can of course read the instruction space. But the user program itself would not be able to write anything after the trap instruction. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From random832 at fastmail.us Wed Jan 7 08:36:31 2015 From: random832 at fastmail.us (random832 at fastmail.us) Date: Tue, 06 Jan 2015 17:36:31 -0500 Subject: [TUHS] pdp11 UNIX memory allocation. In-Reply-To: <1420583703.863814.210431037.61D6C6EC@webmail.messagingengine.com> References: <54AC4394.3050302@update.uu.se> <1420576433.410248.210385277.513EF8EC@webmail.messagingengine.com> <1420583703.863814.210431037.61D6C6EC@webmail.messagingengine.com> Message-ID: <1420583791.864424.210436089.64BFA544@webmail.messagingengine.com> Apparently the message I was replying to was off-list, but it seems like a waste to have typed all this out (including answering my own question) and have it not go to the list. On Tue, Jan 6, 2015, at 17:35, random832 at fastmail.us wrote: > http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/factor.s > wrchar: > mov r0,ch > mov $1,r0 > sys write; ch; 1 > rts r5 > > Though it looks like the C wrappers use the "indirect" system call which > reads a "fake" trap instruction from the data segment. Looking at the > implementation of that, my question is answered: > > http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/sys/sys/trap.c > if (callp == sysent) { /* indirect */ > a = (int *)fuiword((caddr_t)(a)); > pc++; > i = fuword((caddr_t)a); > a++; > if ((i & ~077) != SYS) > i = 077; /* illegal */ > callp = &sysent[i&077]; > fetch = fuword; > } else { > pc += callp->sy_narg - callp->sy_nrarg; > fetch = fuiword; > } > > http://minnie.tuhs.org/TUHS/Archive/PDP-11/Trees/V7/usr/man/man2/indir.2 > The main purpose of indir is to allow a program to > store arguments in system calls and execute them > out of line in the data segment. > This preserves the purity of the text segment. > > Note also the difference between V2 and V5 libc - clearly support for > split I/D machines was added some time in this interval. > http://minnie.tuhs.org/cgi-bin/utree.pl?file=V2/lib/write.s > http://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/source/s4/write.s From ron at ronnatalie.com Wed Jan 7 08:36:46 2015 From: ron at ronnatalie.com (Ronald Natalie) Date: Tue, 6 Jan 2015 17:36:46 -0500 Subject: [TUHS] pdp11 UNIX memory allocation In-Reply-To: <54AC5F94.3080401@update.uu.se> References: <54AC5F94.3080401@update.uu.se> Message-ID: <50E11A72-348F-4391-B444-33DD1B4ED1CC@ronnatalie.com> Another quaint bit of history was when we made the jump to actually running the kernel in split-I/D mode. My good friend Joe Pistritto wrote the JHU boot loader for that. The 512-byte boot loader that was the standard UNIX one was used to load Joe’s split I/D booter. It had a better support of the UNIX file system, but the question was how do you get from a non-split I/D program into the split I/D program. Joe’s solution was rather clever. He put an instruction that stored the processor status word with the new kernel mode at the top of the boot loader’s address space. As he did the store the PC rolled over and now it was running at the new mode at location zero. Years later I found that others had solved the problem by just setting up the kernel registers and executing a trap which switched the modes. I always thought Joe’s solution was more elegant. The kernel started the same way any other UNIX program would start. From jnc at mercury.lcs.mit.edu Wed Jan 7 08:45:44 2015 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 6 Jan 2015 17:45:44 -0500 (EST) Subject: [TUHS] pdp11 UNIX memory allocation. Message-ID: <20150106224544.393BC18C091@mercury.lcs.mit.edu> > From: Clem Cole > Depends the processor. For the 11/45 class processors, you had a 17th > address bit, which was the I/D choice. For the 11/40 class you shared > the instructions and data space. To be exact, the 23, 24, 34, 35/40 and 60 all had a single shared space. (I have no idea why DEC didn't put it in the 60 - probably helped kill that otherwise intersting machine, with its UCS, early...). The 44, 45/50/55, 70, 73, 83/84, and 93/94 had split. > From: random832 at fastmail.us > the calling convention for PDP-11 Unix system calls read their > arguments from directly after the trap instruction (which would mean > that the C wrappers for the system calls would have to write their > arguments there, even if assembly programs could have them hardcoded.) Here's the code for a typical 'wrapper' (this is V6, not sure if V7 changed the trap stuff): _lseek: jsr r5,csv mov 4(r5),r0 mov 6(r5),0f mov 8(r5),0f+2 mov 10.(r5),0f+4 sys indir; 9f bec 1f jmp cerror 1: jmp cret .data 9: sys lseek; 0:..; ..; .. Note the switch to data space for storing the arguments (at the 0: label hidden in the line of data), and the 'indirect' system call. > From: Ronald Natalie > Some access at the kernel level can be done with MFPI and MPFD > instructions. Unless you hacked your hardware, in which case it was possible from user mode too... :-) I remember how freaked out we were when we tried to use MFPI to read instruction space, and it didn't work, whereupon we consulted the 11/45 prints, only to discover that DEC had deliberately made it not work! > From: Ronald Natalie > After the changes to the FS, you'd get missing blocks and a few 0-0 > inodes (or ones where the links count was higher than the links). These > while wasteful were not going to cause problems. It might be worth pointing out that due to the way pipes work, if a system crashed with pipes open, even (especially!) with the disk perfectly sync'd, you'll be left with 0-0 inodes. Although as you point out, those were merely crud, not potential sourdes of file-rot. Noel From clemc at ccc.com Wed Jan 7 08:55:45 2015 From: clemc at ccc.com (Clem Cole) Date: Tue, 6 Jan 2015 17:55:45 -0500 Subject: [TUHS] pdp11 UNIX memory allocation. In-Reply-To: <20150106224544.393BC18C091@mercury.lcs.mit.edu> References: <20150106224544.393BC18C091@mercury.lcs.mit.edu> Message-ID: On Tue, Jan 6, 2015 at 5:45 PM, Noel Chiappa wrote: > I have no idea why DEC didn't put it in the 60 - probably helped kill that > otherwise intersting machine, with its UCS, early... > ​"Halt and confuse ucode" had a lot to do with it IMO. FYI: The 60 set the record of going from production to "traditional products" faster than​ anything else in DEC's history. As I understand it, the 11/60 was expected to a business system and run RSTS. Why the WCS was put in, I never understood, other than I expect the price of static RAM had finally dropped and DEC was buying it in huge quantities for the Vaxen. The argument was that they could update the ucode cheaply in the field (which to my knowledge the never did). But I asked that question many years ago to one of the HW manager, who explained to me that it was felt separate I/D was not needed for the targeted market and would have somehow increased cost. I don't understand why it would have cost any more but I guess it was late. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bqt at update.uu.se Wed Jan 7 09:14:00 2015 From: bqt at update.uu.se (Johnny Billquist) Date: Wed, 07 Jan 2015 00:14:00 +0100 Subject: [TUHS] pdp11 UNIX memory allocation In-Reply-To: <50E11A72-348F-4391-B444-33DD1B4ED1CC@ronnatalie.com> References: <54AC5F94.3080401@update.uu.se> <50E11A72-348F-4391-B444-33DD1B4ED1CC@ronnatalie.com> Message-ID: <54AC6C38.8070904@update.uu.se> On 2015-01-06 23:36, Ronald Natalie wrote: > Another quaint bit of history was when we made the jump to actually running the kernel in split-I/D mode. My good friend Joe Pistritto wrote the JHU boot loader for that. The 512-byte boot loader that was the standard UNIX one was used to load Joe’s split I/D booter. It had a better support of the UNIX file system, but the question was how do you get from a non-split I/D program into the split I/D program. Joe’s solution was rather clever. He put an instruction that stored the processor status word with the new kernel mode at the top of the boot loader’s address space. As he did the store the PC rolled over and now it was running at the new mode at location zero. ??? Are you sure you remember that right? The change from non split I/D to split I/D is not in the processor status word. Also, the last address of memory, before you enable the MMU, is actually the PSW. You can't have code there. > Years later I found that others had solved the problem by just setting up the kernel registers and executing a trap which switched the modes. I always thought Joe’s solution was more elegant. The kernel started the same way any other UNIX program would start. I'm probably missing a whole bunch of detail here, as I'm not fully following what was done. Also, I fail to even spot the problem. Enabling split I/D space is just a bit in the MMU, but even after, you can have the same memory pages in both page tables, in essence making it a noop. Of course, being able to have data outside your code means you can have so much more code, in addition to more data, that you'd just would want to keep them split. But that means just setting up the two page tables appropriately, load the memory as needed, and then enable the MMU and the split I/D, and you're done. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From bqt at update.uu.se Wed Jan 7 09:34:06 2015 From: bqt at update.uu.se (Johnny Billquist) Date: Wed, 07 Jan 2015 00:34:06 +0100 Subject: [TUHS] pdp11 UNIX memory allocation. In-Reply-To: References: Message-ID: <54AC70EE.4060301@update.uu.se> On 2015-01-06 23:56, Clem Cole wrote: > > On Tue, Jan 6, 2015 at 5:45 PM, Noel Chiappa > wrote: > >> >I have no idea why DEC didn't put it in the 60 - probably helped kill that >> >otherwise intersting machine, with its UCS, early... >> > > ?"Halt and confuse ucode" had a lot to do with it IMO. > > FYI: The 60 set the record of going from production to "traditional > products" faster than? anything else in DEC's history. As I understand > it, the 11/60 was expected to a business system and run RSTS. Why the WCS > was put in, I never understood, other than I expect the price of static RAM > had finally dropped and DEC was buying it in huge quantities for the > Vaxen. The argument was that they could update the ucode cheaply in the > field (which to my knowledge the never did). But I asked that question > many years ago to one of the HW manager, who explained to me that it was > felt separate I/D was not needed for the targeted market and would have > somehow increased cost. I don't understand why it would have cost any > more but I guess it was late. No, field upgrade of microcode can not have been it. The WCS for the 11/60 was an option. Very few machines actually had it. It was for writing your own extra microcode as addition to the architecture. The basic microcode for the machine was in ROM, just like on all the other PDP-11s. And DEC sold a compiler and other programs required to develop microcode for the 11/60. Not that I know of anyone who had them. I've "owned" four PDP-11/60 systems in my life. I still have a set of boards for the 11/60 CPU, but nothing else left around. The 11/60 was, by the way, not the only PDP-11 with WCS. The 11/03 (if I remember right) also had such an option. Obviously the microcode was not compatible between the two machines, so you couldn't move it over from one to the other. Also, reportedly, someone at DEC implemented a PDP-8 on the 11/60, making it the fastest PDP-8 ever manufactured. I probably have some notes about it somewhere, but I'd have to do some serious searching if I were to dig that up. But yes, the 11/60 went from product to "traditional" extremely fast. Split I/D space was one omission from the machine, but even more serious was the decision to only do 18-bit addressing on it. That killed it very fast. Someone else mentioned the MFPI/MFPD instructions as a way of getting around the I/D restrictions. As far as I know (can tell), they are possible to use to read/write instruction space on a machine. I would assume that any OS would set both current and previous mode to user when executing in user space. The documentation certainly claims they will work. I didn't think of those previously, but they would allow you to read/write to instruction space even when you have split I/D space enabled. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From scj at yaccman.com Wed Jan 7 09:52:27 2015 From: scj at yaccman.com (scj at yaccman.com) Date: Tue, 6 Jan 2015 15:52:27 -0800 Subject: [TUHS] pdp11 UNIX memory allocation. In-Reply-To: <54AC70EE.4060301@update.uu.se> References: <54AC70EE.4060301@update.uu.se> Message-ID: >> ...Why the WCS was put in, I never understood, other than I expect >> the price of static RAM had finally dropped and DEC was buying it >> in huge quantities for the Vaxen... The Interdata 8/32, Bell Labs' first 32-bit Unix port target, had writable microcode. It added a rather modest amount to the cost of the system as I remember (about $8K). Unfortunately, it was pretty useless. The instruction format, like many machines at the time, had opcodes and then some of the instruction bits were use to get the operands -- register, memory, offsets from registers, etc. The operand handling was implemented in hardware, and any added instructions could not use get to this operand hardware. So any new instructions that were added were pretty crippled. Moreover, the implementation in microcode was flawed. If you tried to load a word through a pointer that had a -1 in it (a common error in earlier Unices where -1 was an error return from the OS), you actually got two faults--a memory bounds error and an alignment check. Unfortunately, these faults came at slightly different times--the alignment check executed 2 or 3 micro instructions and then the bounds check arrived, reset the microcode and lost all the status information. Not only was the fault unrecoverable but the only way to clear it was to power cycle the processor! A bunch of us went to talk to the manufacturer and said, in effect, "We like your machine but we won't buy any more until this fault recovery problem is fixed". It was like talking to a bunch of cinder blocks -- they just didn't get it. Shortly afterwards the VAX arrived and the rest was history... From dave at horsfall.org Wed Jan 7 11:46:52 2015 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 7 Jan 2015 12:46:52 +1100 (EST) Subject: [TUHS] pdp11 UNIX memory allocation. In-Reply-To: <5E62DDAA-0055-46FB-8077-92DB856DEEE0@ronnatalie.com> References: <54AC4394.3050302@update.uu.se> <1420576433.410248.210385277.513EF8EC@webmail.messagingengine.com> <5E62DDAA-0055-46FB-8077-92DB856DEEE0@ronnatalie.com> Message-ID: On Tue, 6 Jan 2015, Ronald Natalie wrote: > In non protected mode (407 magic) everything was fair game. Which reminds me, I wonder how many people know that "407" was the 40's instruction that, if the a.out header was present, would neatly skip over it... -- Dave Horsfall DTM (VK2KFU) "Bliss is a MacBook with a FreeBSD server." http://www.horsfall.org/spam.html (and check the home page whilst you're there) From dave at horsfall.org Wed Jan 7 11:53:46 2015 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 7 Jan 2015 12:53:46 +1100 (EST) Subject: [TUHS] Illumos ) In-Reply-To: References: <20141231062219.GA21046@mcvoy.com> <1420018115.54a3c1c32faaa@www.paradise.net.nz> <20141231131335.GA26926@mercury.ccil.org> <54A4357F.9040703@aueb.gr> <20141231203617.GB3922@mcvoy.com> <20141231224249.GA5833@mcvoy.com> Message-ID: On Tue, 6 Jan 2015, Clem Cole wrote: > Also, for those of you that never saw Unix before fsck or before the > work that Goble did at Purdue to get the write ordering down, you have > no idea what it was like to put a file system back together. Somewhere, deep in Minnie's bowels, is the article I wrote, explaining exactly how to use icheck/ncheck/dcheck/clri etc. I'm told it's saved the bacon of quite a few people (assuming it was savable at all). > The sync;sync;sync stuff was because of the lack write ordering; but > even with that, small file system corruptions where common. It was drilled into us that the correct usage was: # sync # sync # sync This gives the disk buffers time to actually flush (the writes were merely scheduled, and were asynchronous). -- Dave Horsfall DTM (VK2KFU) "Bliss is a MacBook with a FreeBSD server." http://www.horsfall.org/spam.html (and check the home page whilst you're there) From ron at ronnatalie.com Wed Jan 7 12:00:02 2015 From: ron at ronnatalie.com (Ronald Natalie) Date: Tue, 6 Jan 2015 21:00:02 -0500 Subject: [TUHS] pdp11 UNIX memory allocation. In-Reply-To: References: <54AC4394.3050302@update.uu.se> <1420576433.410248.210385277.513EF8EC@webmail.messagingengine.com> <5E62DDAA-0055-46FB-8077-92DB856DEEE0@ronnatalie.com> Message-ID: <2509FDBD-67C4-4552-BB58-01281049DCB6@ronnatalie.com> Yep, the only time this was ever trully useful was so you could put an a.out directly into the boot block I think. During normal operations the a.out header was never actually loaded into the user memory. > On Jan 6, 2015, at 8:46 PM, Dave Horsfall wrote: > > On Tue, 6 Jan 2015, Ronald Natalie wrote: > >> In non protected mode (407 magic) everything was fair game. > > Which reminds me, I wonder how many people know that "407" was the 40's > instruction that, if the a.out header was present, would neatly skip over > it... From jnc at mercury.lcs.mit.edu Wed Jan 7 12:18:42 2015 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 6 Jan 2015 21:18:42 -0500 (EST) Subject: [TUHS] pdp11 UNIX memory allocation. Message-ID: <20150107021842.2642418C09B@mercury.lcs.mit.edu> > From: Ronald Natalie > Yep, the only time this was ever trully useful was so you could put an > a.out directly into the boot block I think. Well, sort of. If you had non position-independent code, it would blow out (it would be off by 020). Also, some bootstraps (e.g. the RL, IIRC) were so close to 512. bytes long that the extra 020 was a problem. And it was so easy to strip off: dd if=a.out of=fooboot bs=1 skip=16 I'm not sure that anything actually used the fact that 407 was 'br .+020', by the V6 era; I think it was just left over from older Unixes (where it was not in fact stripped on loading). Not just on executables running under Unix; the boot-loader also stripped it, so it wasn't even necessary to strip the a.out header off /unix. Noel From cowan at mercury.ccil.org Wed Jan 7 12:39:19 2015 From: cowan at mercury.ccil.org (John Cowan) Date: Tue, 6 Jan 2015 21:39:19 -0500 Subject: [TUHS] pdp11 UNIX memory allocation In-Reply-To: <54AC5F94.3080401@update.uu.se> References: <54AC5F94.3080401@update.uu.se> Message-ID: <20150107023919.GB16334@mercury.ccil.org> Johnny Billquist scripsit: > The versions of Unix I am aware of push arguments on the stack. Yes. It was typical for HLLs not to use JSR Rn instructions (which you need if you are going to pull arguments out of the instruction stream) but rather JSR PC instructions. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org Long-short-short, long-short-short / Dactyls in dimeter, Verse form with choriambs / (Masculine rhyme): One sentence (two stanzas) / Hexasyllabically Challenges poets who / Don't have the time. --robison who's at texas dot net From bqt at update.uu.se Wed Jan 7 12:59:56 2015 From: bqt at update.uu.se (Johnny Billquist) Date: Wed, 07 Jan 2015 03:59:56 +0100 Subject: [TUHS] pdp11 UNIX memory allocation In-Reply-To: <20150107023919.GB16334@mercury.ccil.org> References: <54AC5F94.3080401@update.uu.se> <20150107023919.GB16334@mercury.ccil.org> Message-ID: <54ACA12C.5090806@update.uu.se> On 2015-01-07 03:39, John Cowan wrote: > Johnny Billquist scripsit: > >> The versions of Unix I am aware of push arguments on the stack. > > Yes. It was typical for HLLs not to use JSR Rn instructions (which you > need if you are going to pull arguments out of the instruction stream) > but rather JSR PC instructions. True. However, in this particular case, we were talking about system calls. But the versions of the code I was aware of were equally much pushing stuff on the stack for that case. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From dave at horsfall.org Wed Jan 7 16:29:45 2015 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 7 Jan 2015 17:29:45 +1100 (EST) Subject: [TUHS] pdp11 UNIX memory allocation. In-Reply-To: <2509FDBD-67C4-4552-BB58-01281049DCB6@ronnatalie.com> References: <54AC4394.3050302@update.uu.se> <1420576433.410248.210385277.513EF8EC@webmail.messagingengine.com> <5E62DDAA-0055-46FB-8077-92DB856DEEE0@ronnatalie.com> <2509FDBD-67C4-4552-BB58-01281049DCB6@ronnatalie.com> Message-ID: On Tue, 6 Jan 2015, Ronald Natalie wrote: > Yep, the only time this [the 407 magic number] was ever trully useful > was so you could put an a.out directly into the boot block I think. But why would you include an a.out header in a boot block? When you only had 512 bytes, every one of 'em counted, and I, oops, I mean others, had to resort to vile stuff such as self-modifying code... > During normal operations the a.out header was never actually loaded into > the user memory. I heard a story that on sufficiently-early Unices, the header was indeed loaded, hence the "407". Any grey-beards here like to comment? -- Dave Horsfall DTM (VK2KFU) "Bliss is a MacBook with a FreeBSD server." http://www.horsfall.org/spam.html (and check the home page whilst you're there) From wkt at tuhs.org Wed Jan 7 16:39:35 2015 From: wkt at tuhs.org (Warren Toomey) Date: Wed, 7 Jan 2015 17:39:35 +1100 Subject: [TUHS] pdp11 UNIX memory allocation. In-Reply-To: References: <54AC4394.3050302@update.uu.se> <1420576433.410248.210385277.513EF8EC@webmail.messagingengine.com> <5E62DDAA-0055-46FB-8077-92DB856DEEE0@ronnatalie.com> <2509FDBD-67C4-4552-BB58-01281049DCB6@ronnatalie.com> Message-ID: <20150107063935.GA27943@www.oztivo.net> On Wed, Jan 07, 2015 at 05:29:45PM +1100, Dave Horsfall wrote: > I heard a story that on sufficiently-early Unices, the header was indeed > loaded, hence the "407". > Any grey-beards here like to comment? My beard isn't grey (yet), but here's the link to the 1st Edition code which does exec(2): http://minnie.tuhs.org/cgi-bin/utree.pl?file=V1/u2.s and here is the relevant code: mov $14,u.count mov $u.off,u.fofp clr u.off / set offset in file to be read to zero jsr r0,readi / read in first six words of user's file, starting / at $core mov sp,r5 / put users stack address in r5 sub $core+40.,r5 / subtract $core +40, from r5 (leaves / number of words less 26 available for / program in user core mov r5,u.count / cmp core,$405 / br .+14 is first instruction if file is / standard a.out format bne 1f / branch, if not standard format mov core+2,r5 / put 2nd word of users program in r5; number of / bytes in program text sub $14,r5 / subtract 12 cmp r5,u.count / bgt 1f / branch if r5 greater than u.count mov r5,u.count jsr r0,readi / read in rest of user's program text add core+10,u.nread / add size of user data area to u.nread br 2f 1: jsr r0,readi / read in rest of file My memory of PDP-11 assembly is too rusty to interpret this. Anybody else? Cheers, Warren From brantleycoile at me.com Wed Jan 7 20:06:29 2015 From: brantleycoile at me.com (Brantley Coile) Date: Wed, 07 Jan 2015 05:06:29 -0500 Subject: [TUHS] pdp11 UNIX memory allocation. In-Reply-To: <20150107063935.GA27943@www.oztivo.net> References: <54AC4394.3050302@update.uu.se> <1420576433.410248.210385277.513EF8EC@webmail.messagingengine.com> <5E62DDAA-0055-46FB-8077-92DB856DEEE0@ronnatalie.com> <2509FDBD-67C4-4552-BB58-01281049DCB6@ronnatalie.com> <20150107063935.GA27943@www.oztivo.net> Message-ID: It indeed executes the magic number. The comment at the end of sysexec says it executes the code at $core, which has the twelve word header still in it. Notice that the magic number is two less than the later formats; 0405 instead of 0407. This most likely means that the header was still in the address space in later versions even after another two words were added to the header. Brantley Sent from my iPad > On Jan 7, 2015, at 1:39 AM, Warren Toomey wrote: > >> On Wed, Jan 07, 2015 at 05:29:45PM +1100, Dave Horsfall wrote: >> I heard a story that on sufficiently-early Unices, the header was indeed >> loaded, hence the "407". >> Any grey-beards here like to comment? > > My beard isn't grey (yet), but here's the link to the 1st Edition code > which does exec(2): > > http://minnie.tuhs.org/cgi-bin/utree.pl?file=V1/u2.s > > and here is the relevant code: > > mov $14,u.count > mov $u.off,u.fofp > clr u.off / set offset in file to be read to zero > jsr r0,readi / read in first six words of user's file, starting > / at $core > mov sp,r5 / put users stack address in r5 > sub $core+40.,r5 / subtract $core +40, from r5 (leaves > / number of words less 26 available for > / program in user core > mov r5,u.count / > cmp core,$405 / br .+14 is first instruction if file is > / standard a.out format > bne 1f / branch, if not standard format > mov core+2,r5 / put 2nd word of users program in r5; number of > / bytes in program text > sub $14,r5 / subtract 12 > cmp r5,u.count / > bgt 1f / branch if r5 greater than u.count > mov r5,u.count > jsr r0,readi / read in rest of user's program text > add core+10,u.nread / add size of user data area to u.nread > br 2f > 1: > jsr r0,readi / read in rest of file > > My memory of PDP-11 assembly is too rusty to interpret this. Anybody else? > > Cheers, Warren > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs -------------- next part -------------- An HTML attachment was scrubbed... URL: From jacob.ritorto at gmail.com Wed Jan 7 23:29:11 2015 From: jacob.ritorto at gmail.com (Jacob Ritorto) Date: Wed, 7 Jan 2015 08:29:11 -0500 Subject: [TUHS] pdp11 UNIX memory allocation. In-Reply-To: References: <54AC4394.3050302@update.uu.se> <1420576433.410248.210385277.513EF8EC@webmail.messagingengine.com> <5E62DDAA-0055-46FB-8077-92DB856DEEE0@ronnatalie.com> <2509FDBD-67C4-4552-BB58-01281049DCB6@ronnatalie.com> Message-ID: > > But why would you include an a.out header in a boot block? When you only > had 512 bytes, every one of 'em counted, and I, oops, I mean others, had > to resort to vile stuff such as self-modifying code... > > Ooh, can we see annotated examples? This is the really delicious stuff! > > I heard a story that on sufficiently-early Unices, the header was indeed > loaded, hence the "407". > Any grey-beards here like to comment? > +1 for hearing that and wanting to see annotated examples of it as well! On Wed, Jan 7, 2015 at 1:29 AM, Dave Horsfall wrote: > On Tue, 6 Jan 2015, Ronald Natalie wrote: > > > Yep, the only time this [the 407 magic number] was ever trully useful > > was so you could put an a.out directly into the boot block I think. > > But why would you include an a.out header in a boot block? When you only > had 512 bytes, every one of 'em counted, and I, oops, I mean others, had > to resort to vile stuff such as self-modifying code... > > > During normal operations the a.out header was never actually loaded into > > the user memory. > > I heard a story that on sufficiently-early Unices, the header was indeed > loaded, hence the "407". > > Any grey-beards here like to comment? > > -- > Dave Horsfall DTM (VK2KFU) "Bliss is a MacBook with a FreeBSD server." > http://www.horsfall.org/spam.html (and check the home page whilst you're > there) > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Jan 8 02:14:48 2015 From: clemc at ccc.com (Clem Cole) Date: Wed, 7 Jan 2015 11:14:48 -0500 Subject: [TUHS] pdp11 UNIX memory allocation. In-Reply-To: <54AC70EE.4060301@update.uu.se> References: <54AC70EE.4060301@update.uu.se> Message-ID: On Tue, Jan 6, 2015 at 6:34 PM, Johnny Billquist wrote: > The basic microcode for the machine was in ROM, just like on all the other > PDP-11s. And DEC sold a compiler and other programs required to develop > microcode for the 11/60. Not that I know of anyone who had them. I've > "owned" four PDP-11/60 systems in my life. I still have a set of boards for > the 11/60 CPU, but nothing else left around. I did not realized it was an option. ​IIRC we had it on the Teklabs 11/60, but we could not run the tools easily so we ended up never messing with it. We had talked about adding the CMU csav/cret instructs from the 11/40e but we got the 11/70 and that sucked up my time and I never got back to try it. It was not a redux of the 11/34 BTW. Jeff Mitchell did the 11/34 and was off working on the 750 when the 60 was done. I believe Al Pat was somehow involved with 60, but I've forgotten. As for the "halt and confuse uCode" stuff. The 60 was notorious for getting "stuck" when running UNIX. I've now forgotten many of the details, IIRC it had to with context switch, register save and I think I remember it was something to do with multiple interrupts. Since Glaser and I did the original 11/60 port, I think we knew most of the USENIX UNIX sites that run it on them since we swapped notes if not code. All of us used to complain about random hangs where the uCode take a jump and the system would halt. The only solution when that happened was the pull the circuit breaker power on the back of the machine because the front panel switched were lost. I personally spend many hours with the DEC guys trying to figure what is was, we could never repeat it. Years later, when I got to know some of the uCode engineers that had worked on the 11s and the Vaxen, I found out it was agreed at DEC engineer there was a uCode bug, but so few UNIX customer were out there (and the system had gone to "traditional products") management dropped as not being worth finding and fixing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Jan 8 02:17:58 2015 From: clemc at ccc.com (Clem Cole) Date: Wed, 7 Jan 2015 11:17:58 -0500 Subject: [TUHS] pdp11 UNIX memory allocation. In-Reply-To: <20150107021842.2642418C09B@mercury.lcs.mit.edu> References: <20150107021842.2642418C09B@mercury.lcs.mit.edu> Message-ID: On Tue, Jan 6, 2015 at 9:18 PM, Noel Chiappa wrote: > I'm not sure that anything actually used the fact that 407 was 'br .+020', > by > the V6 era; I think it was just left over from older Unixes (where it was > not > in fact stripped on loading). Not just on executables running under Unix; > the > boot-loader also stripped it, so it wasn't even necessary to strip the > a.out > header off /unix. > ​If you look at the first edition code that Warren has, that seems to support it. Clem​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Jan 8 02:26:24 2015 From: clemc at ccc.com (Clem Cole) Date: Wed, 7 Jan 2015 11:26:24 -0500 Subject: [TUHS] Illumos ) In-Reply-To: References: <20141231062219.GA21046@mcvoy.com> <1420018115.54a3c1c32faaa@www.paradise.net.nz> <20141231131335.GA26926@mercury.ccil.org> <54A4357F.9040703@aueb.gr> <20141231203617.GB3922@mcvoy.com> <20141231224249.GA5833@mcvoy.com> Message-ID: On Tue, Jan 6, 2015 at 8:53 PM, Dave Horsfall wrote: > Somewhere, deep in Minnie's bowels, is the article I wrote, explaining > exactly how to use icheck/ncheck/dcheck/clri etc. > ​Shows I am old - it would fun to read that again. I never saw the article, I learned from doing it (wrong probably) a few times ;-) Then Ted gives us fsck . . . Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Thu Jan 8 03:27:33 2015 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 8 Jan 2015 04:27:33 +1100 (EST) Subject: [TUHS] pdp11 UNIX memory allocation. In-Reply-To: References: <54AC70EE.4060301@update.uu.se> Message-ID: On Wed, 7 Jan 2015, Clem Cole wrote: > I did not realized it [WCS] was an option.  ​IIRC we had it on the > Teklabs 11/60, but we could not run the tools easily so we ended up > never messing with it. Our 11/60 certainly had it; I remember scouring the manual, trying to make sense of it, but after five years studying at UNSW and eight years working there (almost got long service leave!) I got itchy feet. Besides, although the CSU was a great place to work, I didn't like the plans to merge it with the Chancellery (the bureaucratic centre), lest I come to work one morning and find myself working on a COBOL program... The provenance of the beast was that apparently a deal with some big publishing house fell through (Limited News, perhaps?) and DEC was stuck with a warehouse full of them; it seems the WCS was to be used for the typesetting or something, I dunno; they could always have yanked the WCS? [...] > The only solution when that happened was the pull the circuit breaker > power on the back of the machine because the front panel switched were > lost. Don't all 11s have the same key? I used to carry one on my key-ring. -- Dave Horsfall DTM (VK2KFU) "Bliss is a MacBook with a FreeBSD server." http://www.horsfall.org/spam.html (and check the home page whilst you're there) From scj at yaccman.com Thu Jan 8 04:32:57 2015 From: scj at yaccman.com (scj at yaccman.com) Date: Wed, 7 Jan 2015 10:32:57 -0800 Subject: [TUHS] Illumos ) In-Reply-To: References: <20141231062219.GA21046@mcvoy.com> <1420018115.54a3c1c32faaa@www.paradise.net.nz> <20141231131335.GA26926@mercury.ccil.org> <54A4357F.9040703@aueb.gr> <20141231203617.GB3922@mcvoy.com> <20141231224249.GA5833@mcvoy.com> Message-ID: My memories are somewhat fuzzy on this issue, but I vividly remember the file corruptions. The earliest Unix systems had a file format that limited the size of a file to a size that proved to be too small. So Ken put in a "large file" format as well. All files started out as small, but as they grew they had to be rejiggered to become large files. If the system crashed while this rejiggering was going on, the file was toast. The saving grace was that most of us were using model 33 or 37 teletypes, so we had our edit history on paper. When the system crashed, I picked up a highlighter I kept next to the terminal, reeled in the paper that had piled up behind the terminal, and highlighted the lines that would need to be entered again. One memorable day, I was working at home and the system crashed right before lunch. It was several hours before I could get back to the terminal, and I discovered to my horror that our cat had mistaken the pile of paper behind the terminal for her litter box. Yes, I really did pick up a highlighter and followed the usual plan, but I had to get another color since the yellow didn't show up very well... A later revision of the file system eliminated the small/large file distinction, and disc corruptions became a rare event... > On Tue, Jan 6, 2015 at 8:53 PM, Dave Horsfall wrote: > >> Somewhere, deep in Minnie's bowels, is the article I wrote, explaining >> exactly how to use icheck/ncheck/dcheck/clri etc. >> > > ​Shows I am old - it would fun to read that again. I never saw the > article, I learned from doing it (wrong probably) a few times ;-) > Then Ted gives us fsck . . . > > Clem > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > From andrzejpopielewicz at gmail.com Thu Jan 8 05:36:58 2015 From: andrzejpopielewicz at gmail.com (Andrzej Popielewicz) Date: Wed, 7 Jan 2015 20:36:58 +0100 Subject: [TUHS] COHERENT sources released under 3-clause BSD license. In-Reply-To: References: <201501061341.t06Dfbsh025288@coolidge.cs.dartmouth.edu> Message-ID: <20150107193658.GA72@amu.edu.pl> * Rico Pajarola [2015-01-06 11:48:55]: > adding the list back > > On Tue, Jan 6, 2015 at 10:42 AM, Michael Kerpan wrote: > > > This is a cool development. Does this code build into a working version of > > Coherent or is this mainly useful to study? Either way, it should be > > interesting to look at the code for a clone specifically aimed at low-end > > hardware. > > > > Mike > > > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs Hi This archive contains full sources for 4.2.10 and 4.2.12 . And You can build working version of the system. It contains also full installation media (4 floppy images). So usually You will install the system and You can rebuild the system using the sources. It contains also sources of Coherent 3.x. Andrzej From andrzejpopielewicz at gmail.com Thu Jan 8 05:40:25 2015 From: andrzejpopielewicz at gmail.com (Andrzej Popielewicz) Date: Wed, 7 Jan 2015 20:40:25 +0100 Subject: [TUHS] COHERENT sources released under 3-clause BSD license. In-Reply-To: References: <201501061341.t06Dfbsh025288@coolidge.cs.dartmouth.edu> Message-ID: <20150107194025.GB72@amu.edu.pl> * Dan Cross [2015-01-06 12:04:52]: > On Tue, Jan 6, 2015 at 11:48 AM, Rico Pajarola wrote: > > > adding the list back > > > > On Tue, Jan 6, 2015 at 10:42 AM, Michael Kerpan > > wrote: > > > >> This is a cool development. Does this code build into a working version > >> of Coherent or is this mainly useful to study? Either way, it should be > >> interesting to look at the code for a clone specifically aimed at low-end > >> hardware. > >> > > Unknown (to me, anyway). Steve said he had intended to organize and > catalog the code at some point, but that he hasn't gotten around to it (and > not to hold one's breath). I gathered that the tar ball he provided is a > snapshot of (a subset of?) the MWC development disks at the time he was > asked to create the archive. To that end, I suspect that if one were > sufficiently motivated one *could* use it to build a distribution of > COHERENT, but I suspect you'd have to know quite a bit about their internal > development practices and release processes to do so successfully; > knowledge that may very well have been lost over time. Perhaps some > motivated person will be able to reverse engineer it, though I suspect it's > more useful as a case study than as working code. > > - Dan C. > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs Hi Dan, What to You mean by building distribution. The archive contains original distribution of Coherent 4.2.10. Or You mean one could build quite new distribution ? I mean, which would work on modern hardware ? Andrzej From andrzejpopielewicz at gmail.com Thu Jan 8 05:47:57 2015 From: andrzejpopielewicz at gmail.com (Andrzej Popielewicz) Date: Wed, 7 Jan 2015 20:47:57 +0100 Subject: [TUHS] COHERENT sources released under 3-clause BSD license. In-Reply-To: <63B244BE-7BB0-4E7F-A589-8CD4B9FF42AF@bsdimp.com> References: <201501061341.t06Dfbsh025288@coolidge.cs.dartmouth.edu> <63B244BE-7BB0-4E7F-A589-8CD4B9FF42AF@bsdimp.com> Message-ID: <20150107194757.GA95@amu.edu.pl> * Warner Losh [2015-01-06 11:09:58]: > > > On Jan 6, 2015, at 10:04 AM, Dan Cross wrote: > > > > On Tue, Jan 6, 2015 at 11:48 AM, Rico Pajarola wrote: > > adding the list back > > > > On Tue, Jan 6, 2015 at 10:42 AM, Michael Kerpan wrote: > > This is a cool development. Does this code build into a working version of Coherent or is this mainly useful to study? Either way, it should be interesting to look at the code for a clone specifically aimed at low-end hardware. > > > > Unknown (to me, anyway). Steve said he had intended to organize and catalog the code at some point, but that he hasn't gotten around to it (and not to hold one's breath). I gathered that the tar ball he provided is a snapshot of (a subset of?) the MWC development disks at the time he was asked to create the archive. To that end, I suspect that if one were sufficiently motivated one *could* use it to build a distribution of COHERENT, but I suspect you'd have to know quite a bit about their internal development practices and release processes to do so successfully; knowledge that may very well have been lost over time. Perhaps some motivated person will be able to reverse engineer it, though I suspect it's more useful as a case study than as working code. > > Looking at the tarballs and the tarballs inside, this is a mess. It looks like it is all there, but there???s multiple copies of things that are almost identical, RCS files that are mostly enough, but not completely enough, etc. Plus they were using gcc 2.5.1 for compiling things, so using a more modern compiler likely will result in ???difficulties???. There???s some docs laying around, but I haven???t read through them all. The collection needs curating TLC... > > Warner > > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs Hi, They have used also gcc-2.5.6 , which is in TUHS archives , I believe. I have ported gcc-2.8.1,2.95.3,3.2.3 and 4.2.x. Almost 95% of kernel sources compiles well with these newer compilers. Andrzej From jacob.ritorto at gmail.com Thu Jan 8 04:59:18 2015 From: jacob.ritorto at gmail.com (Jacob Ritorto) Date: Wed, 7 Jan 2015 13:59:18 -0500 Subject: [TUHS] Misread on my part, or is there really a notable gcc port? Was: (Re: COHERENT sources released under 3-clause BSD license.) Message-ID: Andrzej wrote: > > I have ported gcc-2.8.1,2.95.3,3.2.3 and 4.2.x. > Ported them to what? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjkerpan at kerpan.com Thu Jan 8 05:02:22 2015 From: mjkerpan at kerpan.com (Michael Kerpan) Date: Wed, 7 Jan 2015 14:02:22 -0500 Subject: [TUHS] COHERENT sources released under 3-clause BSD license. In-Reply-To: <20150107194757.GA95@amu.edu.pl> References: <201501061341.t06Dfbsh025288@coolidge.cs.dartmouth.edu> <63B244BE-7BB0-4E7F-A589-8CD4B9FF42AF@bsdimp.com> <20150107194757.GA95@amu.edu.pl> Message-ID: My main interest is actually in pre-386 code. I'd love to see how a Unix-like system could be made to work on an 8086 or a 286. Did any of that code survive to the 4.2 era or were things 32-bit only by that point? Mike On Jan 7, 2015 1:46 PM, "Andrzej Popielewicz" wrote: > * Warner Losh [2015-01-06 11:09:58]: > > > > > > On Jan 6, 2015, at 10:04 AM, Dan Cross wrote: > > > > > > On Tue, Jan 6, 2015 at 11:48 AM, Rico Pajarola wrote: > > > adding the list back > > > > > > On Tue, Jan 6, 2015 at 10:42 AM, Michael Kerpan > wrote: > > > This is a cool development. Does this code build into a working > version of Coherent or is this mainly useful to study? Either way, it > should be interesting to look at the code for a clone specifically aimed at > low-end hardware. > > > > > > Unknown (to me, anyway). Steve said he had intended to organize and > catalog the code at some point, but that he hasn't gotten around to it (and > not to hold one's breath). I gathered that the tar ball he provided is a > snapshot of (a subset of?) the MWC development disks at the time he was > asked to create the archive. To that end, I suspect that if one were > sufficiently motivated one *could* use it to build a distribution of > COHERENT, but I suspect you'd have to know quite a bit about their internal > development practices and release processes to do so successfully; > knowledge that may very well have been lost over time. Perhaps some > motivated person will be able to reverse engineer it, though I suspect it's > more useful as a case study than as working code. > > > > Looking at the tarballs and the tarballs inside, this is a mess. It > looks like it is all there, but there???s multiple copies of things that > are almost identical, RCS files that are mostly enough, but not completely > enough, etc. Plus they were using gcc 2.5.1 for compiling things, so using > a more modern compiler likely will result in ???difficulties???. There???s > some docs laying around, but I haven???t read through them all. The > collection needs curating TLC... > > > > Warner > > > > > > > _______________________________________________ > > TUHS mailing list > > TUHS at minnie.tuhs.org > > https://minnie.tuhs.org/mailman/listinfo/tuhs > Hi, > They have used also gcc-2.5.6 , which is in TUHS archives , I believe. > I have ported gcc-2.8.1,2.95.3,3.2.3 and 4.2.x. Almost 95% of kernel > sources > compiles well with these newer compilers. > Andrzej > > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From root at amu.edu.pl Thu Jan 8 06:17:50 2015 From: root at amu.edu.pl (Andrzej Popielewicz) Date: Wed, 7 Jan 2015 21:17:50 +0100 Subject: [TUHS] COHERENT sources released under 3-clause BSD license. In-Reply-To: References: <201501061341.t06Dfbsh025288@coolidge.cs.dartmouth.edu> <1420569674.381164.210321493.7C9C5223@webmail.messagingengine.com> <2BE827F7-5498-4D7A-90B9-1228BBBEB950@cs.uwlax.edu> Message-ID: <20150107201750.GA149@amu.edu.pl> * Jacob Goense [2015-01-06 20:50:23]: > On 2015-01-06 20:38, Milo Velimirović wrote: > >On Jan 6, 2015, at 12:41 PM, random832 at fastmail.us wrote: > > > >>On Tue, Jan 6, 2015, at 11:48, Rico Pajarola wrote: > >>>adding the list back > >>> > >>>On Tue, Jan 6, 2015 at 10:42 AM, Michael Kerpan > >>>wrote: > >>> > >>>>This is a cool development. Does this code build into a working > >>>>version of > >>>>Coherent or is this mainly useful to study? Either way, it should be > >>>>interesting to look at the code for a clone specifically aimed at > >>>>low-end > >>>>hardware. > >> > >>In the "distrib" directory there are four files exactly 1440 kb in size > >>- maybe someone could try loading those into a VM/Emulator? > > > >I had exactly that thought after I downloaded the tar ball this > >morning. Any suggestions for a VM config that would facilitate this > >would be welcome. Otherwise I???m going to stumble through virtual box > >and see what happens. > > A quick try with bochs bails out on me, but at least reveals the version: > > COHERENT Tertiary boot Version 1.2.7 > If installing COHERENT, please type "begin". > ? begin > Loading COHERENT. > - > Loading COHERENT data. > [-screen clears-] > *** COHERENT Version 4.2.10 - 386 Mode. 5712KB free memory. *** > Color. NDP=387. 2528 buffers. 2521 buckets. 64 clists. > 256KB kalloc pool. 0 KB phys pool. > Cyrix OEM CPU Detected > Copyright 1982, 1994 Mark Williams Company > fd0: > PANIC : fsminit: no rootdev(4,15) > Call backtrace: -> ffc28142 -> ffc19129 -> ffc002b6 > > If you want to run COHERENT in a VM this is mandatory reading. > > http://thebeezspeaks.blogspot.com/2012/02/my-life-with-coherent-part-1.html > http://thebeezspeaks.blogspot.nl/2012/05/my-life-with-coherent-part-2.html > > /Jacob > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs You have to inform the emulator that You are booting from floppy. The message no rootdev(4,15) means no floppy there (4 major 15 minor number). Installator awaits media on the floppy. But I had tested only virtual box. Andrzej From root at amu.edu.pl Thu Jan 8 06:03:51 2015 From: root at amu.edu.pl (Andrzej Popielewicz) Date: Wed, 7 Jan 2015 21:03:51 +0100 Subject: [TUHS] COHERENT sources released under 3-clause BSD license. In-Reply-To: References: <201501061341.t06Dfbsh025288@coolidge.cs.dartmouth.edu> Message-ID: <20150107200351.GA126@amu.edu.pl> * Rico Pajarola [2015-01-06 11:48:55]: > adding the list back > > On Tue, Jan 6, 2015 at 10:42 AM, Michael Kerpan wrote: > > > This is a cool development. Does this code build into a working version of > > Coherent or is this mainly useful to study? Either way, it should be > > interesting to look at the code for a clone specifically aimed at low-end > > hardware. > > > > Mike > > > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs Hi Yes. You can build 4.2.10 or 4.2.14 kernel from sources. Usually You will install using full distribution media for 4.2.10 and then rebuild using the full sources, distribution media are of course in the archive. Andrzej From imp at bsdimp.com Thu Jan 8 07:19:04 2015 From: imp at bsdimp.com (Warner Losh) Date: Wed, 7 Jan 2015 14:19:04 -0700 Subject: [TUHS] COHERENT sources released under 3-clause BSD license. In-Reply-To: References: <201501061341.t06Dfbsh025288@coolidge.cs.dartmouth.edu> <63B244BE-7BB0-4E7F-A589-8CD4B9FF42AF@bsdimp.com> <20150107194757.GA95@amu.edu.pl> Message-ID: <501A725C-A616-42A8-A017-12B9B5417E14@bsdimp.com> There’s a PS2 kernel directory in one of the files. This is a 3.x based kernel and runs on 286. There are some vestiges of 8086, but I don’t know how well it will work. It looked fairly incomplete to me… Warner > On Jan 7, 2015, at 12:02 PM, Michael Kerpan wrote: > > My main interest is actually in pre-386 code. I'd love to see how a Unix-like system could be made to work on an 8086 or a 286. Did any of that code survive to the 4.2 era or were things 32-bit only by that point? > > Mike > > On Jan 7, 2015 1:46 PM, "Andrzej Popielewicz" wrote: > * Warner Losh [2015-01-06 11:09:58]: > > > > > > On Jan 6, 2015, at 10:04 AM, Dan Cross wrote: > > > > > > On Tue, Jan 6, 2015 at 11:48 AM, Rico Pajarola wrote: > > > adding the list back > > > > > > On Tue, Jan 6, 2015 at 10:42 AM, Michael Kerpan wrote: > > > This is a cool development. Does this code build into a working version of Coherent or is this mainly useful to study? Either way, it should be interesting to look at the code for a clone specifically aimed at low-end hardware. > > > > > > Unknown (to me, anyway). Steve said he had intended to organize and catalog the code at some point, but that he hasn't gotten around to it (and not to hold one's breath). I gathered that the tar ball he provided is a snapshot of (a subset of?) the MWC development disks at the time he was asked to create the archive. To that end, I suspect that if one were sufficiently motivated one *could* use it to build a distribution of COHERENT, but I suspect you'd have to know quite a bit about their internal development practices and release processes to do so successfully; knowledge that may very well have been lost over time. Perhaps some motivated person will be able to reverse engineer it, though I suspect it's more useful as a case study than as working code. > > > > Looking at the tarballs and the tarballs inside, this is a mess. It looks like it is all there, but there???s multiple copies of things that are almost identical, RCS files that are mostly enough, but not completely enough, etc. Plus they were using gcc 2.5.1 for compiling things, so using a more modern compiler likely will result in ???difficulties???. There???s some docs laying around, but I haven???t read through them all. The collection needs curating TLC... > > > > Warner > > > > > > > _______________________________________________ > > TUHS mailing list > > TUHS at minnie.tuhs.org > > https://minnie.tuhs.org/mailman/listinfo/tuhs > Hi, > They have used also gcc-2.5.6 , which is in TUHS archives , I believe. > I have ported gcc-2.8.1,2.95.3,3.2.3 and 4.2.x. Almost 95% of kernel sources > compiles well with these newer compilers. > Andrzej > > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dugo at xs4all.nl Thu Jan 8 08:19:18 2015 From: dugo at xs4all.nl (Jacob Goense) Date: Wed, 07 Jan 2015 23:19:18 +0100 Subject: [TUHS] COHERENT sources released under 3-clause BSD license. In-Reply-To: <20150107201750.GA149@amu.edu.pl> References: <201501061341.t06Dfbsh025288@coolidge.cs.dartmouth.edu> <1420569674.381164.210321493.7C9C5223@webmail.messagingengine.com> <2BE827F7-5498-4D7A-90B9-1228BBBEB950@cs.uwlax.edu> <20150107201750.GA149@amu.edu.pl> Message-ID: <5cccba3c85f63674843f21371a147639@xs4all.nl> On 2015-01-07 21:17, Andrzej Popielewicz wrote: > * Jacob Goense [2015-01-06 20:50:23]: >> A quick try with bochs bails out on me, but at least reveals the >> version: >> >> COHERENT Tertiary boot Version 1.2.7 >> If installing COHERENT, please type "begin". >> ? begin >> Loading COHERENT. >> - >> Loading COHERENT data. >> [-screen clears-] >> *** COHERENT Version 4.2.10 - 386 Mode. 5712KB free memory. *** >> Color. NDP=387. 2528 buffers. 2521 buckets. 64 clists. >> 256KB kalloc pool. 0 KB phys pool. >> Cyrix OEM CPU Detected >> Copyright 1982, 1994 Mark Williams Company >> fd0: >> PANIC : fsminit: no rootdev(4,15) >> Call backtrace: -> ffc28142 -> ffc19129 -> ffc002b6 > > You have to inform the emulator that You are booting from floppy. > The message no rootdev(4,15) means no floppy there (4 major 15 minor > number). > Installator awaits media on the floppy. > But I had tested only virtual box. That's exactly what I thought I did in the bochs config. floppya: 1_44=d1, status=inserted boot: floppy The bochs floppy drive and the Coherent #1 disk never wanted to dance. The last time I tried before was with bochs-2.4.2 and with bochs-2.6.7 I still get the dreaded message. If you know the magic incantation to get it past that in bochs, please let me know. Meanwhile it installs and seems to run like a charm in qemu-2.2.0. /Jacob From crossd at gmail.com Thu Jan 8 13:22:33 2015 From: crossd at gmail.com (Dan Cross) Date: Wed, 7 Jan 2015 22:22:33 -0500 Subject: [TUHS] COHERENT sources released under 3-clause BSD license. In-Reply-To: <20150107194025.GB72@amu.edu.pl> References: <201501061341.t06Dfbsh025288@coolidge.cs.dartmouth.edu> <20150107194025.GB72@amu.edu.pl> Message-ID: On Wed, Jan 7, 2015 at 2:40 PM, Andrzej Popielewicz < andrzejpopielewicz at gmail.com> wrote: > > > On Tue, Jan 6, 2015 at 10:42 AM, Michael Kerpan wrote: > > > This is a cool development. Does this code build into a working version > > > of Coherent or is this mainly useful to study? Either way, it should be > > > interesting to look at the code for a clone specifically aimed at low-end > > > hardware. > > > > Unknown (to me, anyway). Steve said he had intended to organize and > > catalog the code at some point, but that he hasn't gotten around to it (and > > not to hold one's breath). I gathered that the tar ball he provided is a > > snapshot of (a subset of?) the MWC development disks at the time he was > > asked to create the archive. To that end, I suspect that if one were > > sufficiently motivated one *could* use it to build a distribution of > > COHERENT, but I suspect you'd have to know quite a bit about their internal > > development practices and release processes to do so successfully; > > knowledge that may very well have been lost over time. Perhaps some > > motivated person will be able to reverse engineer it, though I suspect it's > > more useful as a case study than as working code. > > Hi Dan, > What to You mean by building distribution. The archive contains original distribution > of Coherent 4.2.10. Or You mean one could build quite new distribution ? > I mean, which would work on modern hardware ? To a first order approximation, I meant regenerating the installation media from source. You would certainly know more than I would about it; if you say it can be done, I believe you. :-) I don't know how to go about it, though (I assume it involves typing more than one command, but I could well be wrong). - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mparson at bl.org Fri Jan 9 09:11:17 2015 From: mparson at bl.org (Michael Parson) Date: Thu, 8 Jan 2015 17:11:17 -0600 (CST) Subject: [TUHS] VAX faxing? In-Reply-To: References: <19446.1420413351@cesium.clock.org> Message-ID: On Mon, 5 Jan 2015, Dave Horsfall wrote: > On Sun, 4 Jan 2015, Erik E. Fair wrote: > >> It amazes and annoys me to this day how many PDFs purported to be >> "electronic documents" are merely pictures of paper. Not only am I >> missing my 2000's-era personal jetpack, I'm still waiting for my fully >> paperless office. > > Right after we get the paperless toilet... You don't know how to use the 3 clam shells? -- Michael Parson Austin, TX KF5LGQ From cubexyz at gmail.com Fri Jan 9 14:59:21 2015 From: cubexyz at gmail.com (Mark Longridge) Date: Thu, 8 Jan 2015 23:59:21 -0500 Subject: [TUHS] single user mode in v5 & v6 Message-ID: Ok, I've finally managed to get Unix v5 and v6 to go into single user mode while running under simh. I boot up unix as normal, that is to say in multi-user mode. Then a ctrl-e and dep system sr 173030 (simh command) then c to continue execution of the operating system and finally "kill -1 1". This gets me from multi user mode to single user mode. I can also go back to multi user mode with: ctrl-e and dep system sr 000000 then once again c to continue execution of the operating system and "kill -1 1". Now I'm in muti user mode, and I can telnet in as another user so it seems to be working but then if I do a "ps -alx" I get: TTY F S UID PID PRI ADDR SZ WCHAN COMMAND ?: 3 S 0 0-100 1227 2 5676 ???? ?: 1 W 0 1 40 1324 6 5740 - 8: 1 W 0 51 40 2456 19 5766 - ?: 1 W 0 55 10 1377 6 42066 - ?: 1 W 0 5 90 1734 5 5440 /etc/update ?: 1 W 0 32 10 2001 6 42126 - ?: 1 W 0 33 10 2054 6 42166 - ?: 1 W 0 34 10 2127 6 42226 - ?: 1 W 0 35 10 2202 6 42266 - ?: 1 W 0 36 10 2255 6 42326 - ?: 1 W 0 37 10 2330 6 42366 - ?: 1 W 0 38 10 2403 6 42426 - 8: 1 R 0 59 104 1472 17 ps alx The ps command doesn't show the /etc/init process explicitly, although I'm pretty sure it is running. I'm not sure if unix of the v6 or v5 era was designed to go from multi user to single user mode and then back again. Would it be safer to just go to single user and then shut it down? Mark From jnc at mercury.lcs.mit.edu Fri Jan 9 16:18:48 2015 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 9 Jan 2015 01:18:48 -0500 (EST) Subject: [TUHS] single user mode in v5 & v6 Message-ID: <20150109061848.94B1918C0CC@mercury.lcs.mit.edu> > From: Mark Longridge > I've finally managed to get Unix v5 and v6 to go into single user mode > while running under simh. > ... > dep system sr 173030 (simh command) Just out of curiousity, why don't you set the SR before you boot the machine? That way it'll come up single user, and you can icheck/dcheck before you go to multi-user mode. I prefer doing it that way, there's as little as possible going on, in case the disk is slightly 'confused', so less chance any bit-rot will spread... > Now I'm in muti user mode .. but then if I do a "ps -alx" I get: > > TTY F S UID PID PRI ADDR SZ WCHAN COMMAND > ?: 3 S 0 0-100 1227 2 5676 ???? > ?: 1 W 0 1 40 1324 6 5740 - > The ps command doesn't show the /etc/init process explicitly, although > I'm pretty sure it is running. No, it's there: the second line (PID 1). For some reason, the code for /etc/init (in V6 at least, I don't know anything about V5) bashes the command line so it just has '-' in it, so it looks just like a shell. I fixed my copy so it says "/etc/init", or something like that. The machine my source is on is powered down at the moment; if you want, I can upload the 'fixed' code tomorrow. > I'm not sure if unix of the v6 or v5 era was designed to go from multi > user to single user mode and then back again. I seem to recall there's some issue, something like in some cases there's an extra shell left running attached to the console, but I don't recall the details (too lazy to look for the note I made about the bug; I can look it up if you really want to know). > Would it be safer to just go to single user and then shut it down? I don't usually bother; I just log out all the shells except the one on the console, so the machine is basically idle; then do a 'sync', and shortly after than completes, I just halt the machine. Noel From jrvalverde at cnb.csic.es Fri Jan 9 19:23:21 2015 From: jrvalverde at cnb.csic.es (Jose R. Valverde) Date: Fri, 9 Jan 2015 10:23:21 +0100 Subject: [TUHS] Illumos ) In-Reply-To: <389F2E19-7E08-4294-914E-49EE2641B118@tfeb.org> References: <20141231062219.GA21046@mcvoy.com> <1420018115.54a3c1c32faaa@www.paradise.net.nz> <20141231131335.GA26926@mercury.ccil.org> <54A4357F.9040703@aueb.gr> <20141231203617.GB3922@mcvoy.com> <20141231224249.GA5833@mcvoy.com> <389F2E19-7E08-4294-914E-49EE2641B118@tfeb.org> Message-ID: <20150109102321.1987ec37@cnb.csic.es> On all of this discussion I mostly miss the word of old age and experience. Probably because the downing of the Bazaar came to crystallize the old wisdom. Let me explain: it is true that a cathedral is very well engineered. But it is no less true that after any long experiece, it is but a glorified version of the humble bazaar shop. When you start building and designing a cathedral you do it considering the materials, tools and knowledge that you have at hand at the time. But times, they are a'changin. And sooner or later the cathedral will not be fit for your needs and you will need to build another. The life cycle may be longer, or not, but it is still the same. You must throw away the design and start a-new from scratch sooner or later. To continue the analogy. I was often puzzled by ancient megalythic monuments. I recently visited a multi-dolmen site. They transpire an evolution from the cave in a mountain to huge stones making up an artificial mountain and cave, to smaller megalyths, to pyrammids, to probably smaller stone temples, possibly to the brick and mortar ziggurats of the early bronze age... with the obvious return to stone in the Classic to Neoclassic period and back to brick and mortar today... At any rate, caves probably became inconvenient in the Neolythic when hunters became farmers in the plains and they had to "reinvent" them. The Bronze Age allowed reducing the size of the megalyths. The Iron Age allowed making regular stones... and so on. In the end, you start with Unix and one day you need to add unforeseen technology such as VM, so you redesign and rebuild it. Then you need plug-and-play, so you redesign and rebuild it. Then you want support for zillions of devices and need to separate/modularize the kernel from device drivers, and redesign and rebuild it to a micro-kernel-like system, and then you want to have zillions of hackers or developers, and you need to redesign/rebuild it, and then you want isolation and redesign it to have jails/VMs/whatever, and so on. So, pray, what is the difference? For anything we build, we will have to re-design and rebuild it sooner or later, because it no longer satisfies our needs or because new, better, more modern tools and needs come into existence. The life cycle may be millenia, centuries, decades, years, months or weeks, but you can never foresee all future needs, you will always have to re-design and re-build. You will always be "building", be it complex cathedrals of chaotic bazaars. In the end they are both the same. It is not the Cathedral versus the Bazaar. It is all about building for your needs. In the Classic times of the Roman monuments, every household also had its own lair, shrine, for the family "good ancestors" which remained as gods (lares). You need both, the Cathedral and the Bazaar at all times. A good mason, a good architect or a good IT professional understands of "building", and should not need to care whether his assignment is a temple or a shrine. IMMHO j -- Scientific Computing Service Solving all your computer needs for Scientific Research. http://bioportal.cnb.csic.es From jrvalverde at cnb.csic.es Fri Jan 9 19:50:05 2015 From: jrvalverde at cnb.csic.es (Jose R. Valverde) Date: Fri, 9 Jan 2015 10:50:05 +0100 Subject: [TUHS] COHERENT sources released under 3-clause BSD license. In-Reply-To: <20150107201750.GA149@amu.edu.pl> References: <201501061341.t06Dfbsh025288@coolidge.cs.dartmouth.edu> <1420569674.381164.210321493.7C9C5223@webmail.messagingengine.com> <2BE827F7-5498-4D7A-90B9-1228BBBEB950@cs.uwlax.edu> <20150107201750.GA149@amu.edu.pl> Message-ID: <20150109105005.36b72d1b@cnb.csic.es> What Andrzej fails to mention is that for quite a long time, Coherent has been maintained alive by a reduced groups of enthusiasts gathered around him and comp.os.coherent and that a binary distribution was also available thanks to a great extent to his devoted work (he was one of the few who had permission to). I have mentioned on occasion that I remember the code being left loose under a permissive license sometime around the end of the '90s, and I got a copy then, but -sadly- didn't keep the original message with the license (I was switching jobs or house or both or traveling or something). Anyway, the available binary distro can be run on Qemu reasonably well. I think I was the first to succeed running it on 2008 on Qemu 0.9.1. In any case, I would like to publicly thank Adrzej for all the work he has been doing all these years to keep Coherent alive. j On Wed, 7 Jan 2015 21:17:50 +0100 Andrzej Popielewicz wrote: > * Jacob Goense [2015-01-06 20:50:23]: > > > On 2015-01-06 20:38, Milo Velimirović wrote: > > >On Jan 6, 2015, at 12:41 PM, random832 at fastmail.us wrote: > > > > > >>On Tue, Jan 6, 2015, at 11:48, Rico Pajarola wrote: > > >>>adding the list back > > >>> > > >>>On Tue, Jan 6, 2015 at 10:42 AM, Michael Kerpan > > >>>wrote: > > >>> > > >>>>This is a cool development. Does this code build into a working > > >>>>version of > > >>>>Coherent or is this mainly useful to study? Either way, it should be > > >>>>interesting to look at the code for a clone specifically aimed at > > >>>>low-end > > >>>>hardware. > > >> > > >>In the "distrib" directory there are four files exactly 1440 kb in size > > >>- maybe someone could try loading those into a VM/Emulator? > > > > > >I had exactly that thought after I downloaded the tar ball this > > >morning. Any suggestions for a VM config that would facilitate this > > >would be welcome. Otherwise I???m going to stumble through virtual box > > >and see what happens. > > > > A quick try with bochs bails out on me, but at least reveals the version: > > > > COHERENT Tertiary boot Version 1.2.7 > > If installing COHERENT, please type "begin". > > ? begin > > Loading COHERENT. > > - > > Loading COHERENT data. > > [-screen clears-] > > *** COHERENT Version 4.2.10 - 386 Mode. 5712KB free memory. *** > > Color. NDP=387. 2528 buffers. 2521 buckets. 64 clists. > > 256KB kalloc pool. 0 KB phys pool. > > Cyrix OEM CPU Detected > > Copyright 1982, 1994 Mark Williams Company > > fd0: > > PANIC : fsminit: no rootdev(4,15) > > Call backtrace: -> ffc28142 -> ffc19129 -> ffc002b6 > > > > If you want to run COHERENT in a VM this is mandatory reading. > > > > http://thebeezspeaks.blogspot.com/2012/02/my-life-with-coherent-part-1.html > > http://thebeezspeaks.blogspot.nl/2012/05/my-life-with-coherent-part-2.html > > > > /Jacob > > _______________________________________________ > > TUHS mailing list > > TUHS at minnie.tuhs.org > > https://minnie.tuhs.org/mailman/listinfo/tuhs > > You have to inform the emulator that You are booting from floppy. > The message no rootdev(4,15) means no floppy there (4 major 15 minor number). > Installator awaits media on the floppy. > But I had tested only virtual box. > Andrzej > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs -- Scientific Computing Service Solving all your computer needs for Scientific Research. http://bioportal.cnb.csic.es From ron at ronnatalie.com Sat Jan 10 00:23:00 2015 From: ron at ronnatalie.com (Ronald Natalie) Date: Fri, 9 Jan 2015 09:23:00 -0500 Subject: [TUHS] single user mode in v5 & v6 In-Reply-To: <20150109061848.94B1918C0CC@mercury.lcs.mit.edu> References: <20150109061848.94B1918C0CC@mercury.lcs.mit.edu> Message-ID: If I recall, our V6 system would go from singe user to multiuser when you logged out of the single user shell (our init checked the switch register to determine whether to bring up single or multiuser). I believe our system shutdown if you kill -1-1 (HUP to init). V7 would revert to single user at that point. I think the init > On Jan 9, 2015, at 1:18 AM, Noel Chiappa wrote: > >> From: Mark Longridge > >> I've finally managed to get Unix v5 and v6 to go into single user mode >> while running under simh. >> ... >> dep system sr 173030 (simh command) > > Just out of curiousity, why don't you set the SR before you boot the machine? > That way it'll come up single user, and you can icheck/dcheck before you go > to multi-user mode. I prefer doing it that way, there's as little as possible > going on, in case the disk is slightly 'confused', so less chance any bit-rot > will spread... > >> Now I'm in muti user mode .. but then if I do a "ps -alx" I get: >> >> TTY F S UID PID PRI ADDR SZ WCHAN COMMAND >> ?: 3 S 0 0-100 1227 2 5676 ???? >> ?: 1 W 0 1 40 1324 6 5740 - > >> The ps command doesn't show the /etc/init process explicitly, although >> I'm pretty sure it is running. > > No, it's there: the second line (PID 1). For some reason, the code for > /etc/init (in V6 at least, I don't know anything about V5) bashes the command > line so it just has '-' in it, so it looks just like a shell. > > I fixed my copy so it says "/etc/init", or something like that. The machine > my source is on is powered down at the moment; if you want, I can upload the > 'fixed' code tomorrow. > >> I'm not sure if unix of the v6 or v5 era was designed to go from multi >> user to single user mode and then back again. > > I seem to recall there's some issue, something like in some cases there's an > extra shell left running attached to the console, but I don't recall the > details (too lazy to look for the note I made about the bug; I can look it up > if you really want to know). > >> Would it be safer to just go to single user and then shut it down? > > I don't usually bother; I just log out all the shells except the one on the > console, so the machine is basically idle; then do a 'sync', and shortly > after than completes, I just halt the machine. > > Noel > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs From clemc at ccc.com Sat Jan 10 00:36:10 2015 From: clemc at ccc.com (Clem Cole) Date: Fri, 9 Jan 2015 09:36:10 -0500 Subject: [TUHS] single user mode in v5 & v6 In-Reply-To: <20150109061848.94B1918C0CC@mercury.lcs.mit.edu> References: <20150109061848.94B1918C0CC@mercury.lcs.mit.edu> Message-ID: On Fri, Jan 9, 2015 at 1:18 AM, Noel Chiappa wrote: > Just out of curiousity, why don't you set the SR before you boot the > machine? > That way it'll come up single user, and you can icheck/dcheck before you go > to multi-user mode. I prefer doing it that way, there's as little as > possible > going on, in case the disk is slightly 'confused', so less chance any > bit-rot > will spread... > ​Right and it's probably worth digging up the v6 version of fsck. I had it on tape but I worry that it might be 800 bpi which I have lost the ability to read. I need to find a working TS08. Also remember for early UNIX, ps "knew" about some kernel data structures and had to compiled with the same sources that your kernel used if you want all the command field in particular to look reasonable. I've forgotten when that got fixed, my memory is that V7 still had vestiges of that issue i.e. it was not until post 4.1BSD that got ps got more independant. That said, until V8 and /proc that user mode utilities like that got really cleaned up. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Jan 10 00:36:51 2015 From: clemc at ccc.com (Clem Cole) Date: Fri, 9 Jan 2015 09:36:51 -0500 Subject: [TUHS] single user mode in v5 & v6 In-Reply-To: References: <20150109061848.94B1918C0CC@mercury.lcs.mit.edu> Message-ID: On Fri, Jan 9, 2015 at 9:23 AM, Ronald Natalie wrote: > If I recall, our V6 system would go from singe user to multiuser when you > logged out of the single user shell (our init checked the switch register > to determine whether to bring up single or multiuser). That is the behavior I remember, also. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Sat Jan 10 00:44:19 2015 From: ron at ronnatalie.com (Ronald Natalie) Date: Fri, 9 Jan 2015 09:44:19 -0500 Subject: [TUHS] single user mode in v5 & v6 In-Reply-To: References: <20150109061848.94B1918C0CC@mercury.lcs.mit.edu> Message-ID: If I recall, PS read /dev/kmem to get the proc structure which was a table of all the active processes. The user structure of the currently running process is the only one that is guaranteed to be in memory (the others could be paged out) and at least on our system was always located at 0140000. Any processes that were swapped you could read the user structure so things that were stored there were often unavailable (particularly the command name). Yeah, so ps had intimate knowledge of the layout of the kernel user and proc structures. We moved a short version of the command name into the proc structure for reason. We added a new TTY special character ^T (borrowed that from the KA-10 guys) to do a brief listing of the processes controlled by the current terminal from within the kernel. (Mike Muuss did this while he was playing with scheduler hacking). > > > Also remember for early UNIX, ps "knew" about some kernel data structures and had to compiled with the same sources that your kernel used if you want all the command field in particular to look reasonable. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Jan 10 02:52:42 2015 From: clemc at ccc.com (Clem cole) Date: Fri, 9 Jan 2015 11:52:42 -0500 Subject: [TUHS] single user mode in v5 & v6 In-Reply-To: References: <20150109061848.94B1918C0CC@mercury.lcs.mit.edu> Message-ID: Right. We did some similar stuff at CMU. One other hack we had was science compiled ps with the kernel IIRC we had a table of sleep addresses so that ps could print the actual thing you were waiting for not just an address. I think that was a Dan Klein hack. Yeah the ^T hack was implemented a number of times. Masscomp is the only product kernel that I knew supported it. I did miss it for a long time Clem Sent from my iPhone > On Jan 9, 2015, at 9:44 AM, Ronald Natalie wrote: > > If I recall, PS read /dev/kmem to get the proc structure which was a table of all the active processes. > The user structure of the currently running process is the only one that is guaranteed to be in memory (the others could be paged out) > and at least on our system was always located at 0140000. Any processes that were swapped you could read the user structure > so things that were stored there were often unavailable (particularly the command name). Yeah, so ps had intimate knowledge of the > layout of the kernel user and proc structures. > > We moved a short version of the command name into the proc structure for reason. We added a new TTY special character ^T > (borrowed that from the KA-10 guys) to do a brief listing of the processes controlled by the current terminal from within the kernel. (Mike Muuss did this while he was playing with scheduler hacking). > >> >> >> Also remember for early UNIX, ps "knew" about some kernel data structures and had to compiled with the same sources that your kernel used if you want all the command field in particular to look reasonable. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Sat Jan 10 04:06:07 2015 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 9 Jan 2015 13:06:07 -0500 (EST) Subject: [TUHS] single user mode in v5 & v6 Message-ID: <20150109180607.E198918C0CE@mercury.lcs.mit.edu> > From: Noel Chiappa > For some reason, the code for /etc/init .. bashes the command line so > it just has '-' in it, so it looks just like a shell. BTW, that may be accidental, not a deliberate choice - e.g. someone copied another line of code which exec'd a shell, and didn't change the second arg. > I fixed my copy so it says "/etc/init", or something like that. ... I > can upload the 'fixed' code tomorrow. The change is pretty minor: in this piece of code: case reboot: termall(); execl(init, minus, 0); reset(); just change the execl() line to say: execl(init, init, 0); >> I'm not sure if unix of the v6 or v5 era was designed to go from multi >> user to single user mode and then back again. > I seem to recall there's some issue, something like in some cases > there's an extra shell left running attached to the console So the bug is that in going from single-user to multi-user, by using "kill -1 1" in single-user with the switch register set for multi-user, it doesn't kill the running single-user shell on the console. The workaround to that bug which I use is to set the CSWR and then ^D the running shell. In general, the code in init.c isn't quite as clean/clear as would be optimal (which is part of why I haven't tried to fix the above bug), but _in general_ it does support going back and forth. > From: Ronald Natalie > our init checked the switch register to determine whether to bring up > single or multiuser I think that's standard from Bell, actually. > I believe our system shutdown if you kill -1-1 (HUP to init). The 'stock' behaviour is that when that happens, it checks the switch register, and there are three options (the code is a little hard to follow, but I'm pretty sure this is right): - if it's set for single-user, it shuts down all the other children, and brings up a console shell; when done, it does the next - if it's set for 'reboot', it just shuts down all children, and restarts the init process (presumably so one can switch to a new version of the init without restarting the whole machine); - if it's not set for either, it re-reads /etc/ttys, and for any lines which have switched state in that file, it starts/kills the process listening to that line (this allows one to add/drop lines dynamically). > From: Clem Cole > it's probably worth digging up the v6 version of fsck. That's on that MIT V6 tape, too. Speaking of which, time to write the code to grok the tape... Noel From jnc at mercury.lcs.mit.edu Sat Jan 10 04:38:45 2015 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 9 Jan 2015 13:38:45 -0500 (EST) Subject: [TUHS] single user mode in v5 & v6 Message-ID: <20150109183845.05AEB18C0CE@mercury.lcs.mit.edu> > From: Clem Cole > ps "knew" about some kernel data structures and had to compiled with > the same sources that your kernel used if you want all the command > field in particular to look reasonable. Not just the command field! The real problem was that all the parameters (e.g. NPROC) were not stored in the kernel anywhere, so if you wanted to have one copy of the 'ps' binary which would work on two different machines (but which were running the same version of the kernel)... rotsa ruck. I have hacked my V6 to include lines like: int ninode NINODE; int nfile NFILE; int nproc NPROC; etc so 'ps' can just read those variables to find the table sizes in the running kernel. (Obviously if you modify a table format, then you're SOL.) > From: Ronald Natalie > The user structure of the currently running process is the only one > that is guaranteed to be in memory ... Any processes that were swapped > you could read the user structure so things that were stored there were > often unavailable (particularly the command name). Well, 'ps' (even the V6 stock version) was actually prepared to poke around on the swap device to look at the images of swapped-out processes. And the command name didn't come from the U area (it wasn't saved there in stock V6), 'ps' actually had to look on the top of the user stack (which is why it wasn't guaranteed to be accurate - the user process could smash that). > From: Clem cole > IIRC we had a table of sleep addresses so that ps could print the > actual thing you were waiting for not just an address. I've hacked my copy of 'ps' to grovel around in the system's symbol table, and print 'wchan' symbolically. E.g. here's some of the output of 'ps' on my system: TTY F S UID PID PPID PRI NIC CPU TIM ADDR SZ TXT WCHAN COMMAND ?: SL S 0 0 0-100 0 -1 127 1676 16 runout ?: L W 0 1 0 40 0 0 127 1774 43 0 proc+26 /etc/init ?: L W 0 11 1 90 0 0 127 2405 37 tout /etc/update 8: L W 0 12 1 10 0 0 127 2772 72 2 kl11 - a: L W 0 13 1 40 0 0 127 3122 72 2 proc+102 - a: L R 0 22 13 100 0 10 0 3422 138 3 ps axl b: L W 0 14 1 10 0 0 127 2120 41 1 dz11+40 - 4 It's pretty easy to interpret this to see what each process is waiting for. Noel From dave at horsfall.org Sat Jan 10 04:59:08 2015 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 10 Jan 2015 05:59:08 +1100 (EST) Subject: [TUHS] single user mode in v5 & v6 In-Reply-To: <20150109180607.E198918C0CE@mercury.lcs.mit.edu> References: <20150109180607.E198918C0CE@mercury.lcs.mit.edu> Message-ID: On Fri, 9 Jan 2015, Noel Chiappa wrote: > > For some reason, the code for /etc/init .. bashes the command line > > so it just has '-' in it, so it looks just like a shell. > > BTW, that may be accidental, not a deliberate choice - e.g. someone > copied another line of code which exec'd a shell, and didn't change the > second arg. I have a vague recollection of patching "ps" so that process 0 showed as "unix" or something, as otherwise it was just random rubbish. > > our init checked the switch register to determine whether to bring > > up single or multiuser > > I think that's standard from Bell, actually. Yes. -- Dave Horsfall DTM (VK2KFU) "Bliss is a MacBook with a FreeBSD server." http://www.horsfall.org/spam.html (and check the home page whilst you're there) From clemc at ccc.com Sat Jan 10 06:54:36 2015 From: clemc at ccc.com (Clem Cole) Date: Fri, 9 Jan 2015 15:54:36 -0500 Subject: [TUHS] single user mode in v5 & v6 In-Reply-To: <20150109183845.05AEB18C0CE@mercury.lcs.mit.edu> References: <20150109183845.05AEB18C0CE@mercury.lcs.mit.edu> Message-ID: On Fri, Jan 9, 2015 at 1:38 PM, Noel Chiappa wrote: > > Not just the command field! > ​right... ​ > > The real problem was that all the parameters (e.g. NPROC) were not stored > in > the kernel anywhere, so if you wanted to have one copy of the 'ps' binary > which would work on two different machines (but which were running the same > version of the kernel)... rotsa ruck. > ​Yup, I remember that ...​ > > > > I've hacked my copy of 'ps' to grovel around in the system's symbol table, > and print 'wchan' symbolically. ​right - that look pretty much what it looked like on our systems. Great minds run on the same channel. Clem​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Sat Jan 10 06:57:33 2015 From: ron at ronnatalie.com (Ronald Natalie) Date: Fri, 9 Jan 2015 15:57:33 -0500 Subject: [TUHS] single user mode in v5 & v6 In-Reply-To: References: <20150109183845.05AEB18C0CE@mercury.lcs.mit.edu> Message-ID: The symbol table was commonly used, but that was not so good if you didn't boot from /unix. From clemc at ccc.com Sat Jan 10 07:18:23 2015 From: clemc at ccc.com (Clem Cole) Date: Fri, 9 Jan 2015 16:18:23 -0500 Subject: [TUHS] single user mode in v5 & v6 In-Reply-To: References: <20150109183845.05AEB18C0CE@mercury.lcs.mit.edu> Message-ID: On Fri, Jan 9, 2015 at 3:57 PM, Ronald Natalie wrote: > The symbol table was commonly used, but that was not so good if you didn't > boot from /unix. > > IIRC that we stuffed the pathname that we booted with somewhere, so that ps could find it. All of this is very hazy now, too many different UNIX systems and different hacks over the years ;-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From cubexyz at gmail.com Sat Jan 10 12:20:22 2015 From: cubexyz at gmail.com (Mark Longridge) Date: Fri, 9 Jan 2015 21:20:22 -0500 Subject: [TUHS] Early Unix file system checks Message-ID: > Noel Chiappa: > Just out of curiousity, why don't you set the SR before you boot the machine? > That way it'll come up single user, and you can icheck/dcheck before you go > to multi-user mode. I prefer doing it that way, there's as little as possible > going on, in case the disk is slightly 'confused', so less chance any bit-rot > will spread... I actually do file system checks on v5 as it's the early unix I use the most: check -l /dev/rk0 check -u /dev/rk0 same for rk1, rk2. The v5 manual entry for check references the 'restor' command, although the man page for that is missing. Your idea of starting up in single user mode is a good one although I'm not sure if it's necessary to check the file system on each boot up. I've been running this disk image of v5 for about two years and no blow-ups as yet. I also keep various snapshots of v5, v6 and v7 disk images for safety reasons. And there are text files of all the source code changes I've made, so if disaster strikes I can redo it all. Mark From cubexyz at gmail.com Sat Jan 10 13:01:30 2015 From: cubexyz at gmail.com (Mark Longridge) Date: Fri, 9 Jan 2015 22:01:30 -0500 Subject: [TUHS] Fixed Unix v5 bug! Message-ID: > Noel Chiappa > The change is pretty minor: in this piece of code: > > case reboot: > termall(); > execl(init, minus, 0); > reset(); > > just change the execl() line to say: > > execl(init, init, 0); I patched init in v5 and now ps shows /etc/init as expected, even after going from multi to single to multi mode. Looks like init.c was the same in v5 and v6. From david at kdbarto.org Sun Jan 11 08:15:39 2015 From: david at kdbarto.org (David Barto) Date: Sat, 10 Jan 2015 14:15:39 -0800 Subject: [TUHS] Termcap vs terminfo In-Reply-To: <1FD28B19-FA50-4581-BB0A-257B5DDE1890@kdbarto.org> References: <1FD28B19-FA50-4581-BB0A-257B5DDE1890@kdbarto.org> Message-ID: <30E98281-D4A7-424D-A757-2EF50A0BFC65@kdbarto.org> All I remember (and still support to this day) is that I’ve got a TERMCAP=‘string’ in my login scripts to set termcap to the specific terminal I’m logging in with. Long ago this made things much faster. Today I think that it is just a holdover that I’m not changing due to inertia, rather than any real need for it. David — David Barto david at kdbarto.org From lyndon at orthanc.ca Sun Jan 11 08:43:53 2015 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Sat, 10 Jan 2015 14:43:53 -0800 Subject: [TUHS] Termcap vs terminfo In-Reply-To: <30E98281-D4A7-424D-A757-2EF50A0BFC65@kdbarto.org> References: <1FD28B19-FA50-4581-BB0A-257B5DDE1890@kdbarto.org> <30E98281-D4A7-424D-A757-2EF50A0BFC65@kdbarto.org> Message-ID: On Jan 10, 2015, at 2:15 PM, David Barto wrote: > All I remember (and still support to this day) is that I’ve got a TERMCAP=‘string’ in my login scripts to set termcap to the specific terminal I’m logging in with. > > Long ago this made things much faster. Today I think that it is just a holdover that I’m not changing due to inertia, rather than any real need for it. There is still a need for this. Most modern curses capability entries for 'xterm' and friends use the memory buffer windowing capability (a term I made up) such that when you - say - run less to display a file, it switches to a dedicated region in the terminal memory buffer while printing its output, then restores the buffer to back where you were to begin with when you exit the pager. This drives me insane! When I 'man foo' and find the relevant bits in the document, when I quit out of the pager I want those bits to stay on the screen so I can refer to them, dammit! There are two shortcuts to this, both involving custom termcap/terminfo entries. In the termcap case, you can define a $TERMCAP capability that describes an 'xterm' without the memory buffer hopping. In the terminfo case, you tic(1) your custom 'xterm' definition into $HOME/.terminfo/... These days - naturally - everyone knows the universe exists inside an ANSI terminal window, so who gives a fsck about term{cap.info}? Well, I do, for this very reason. A pox on everyone who has not 'setenv TERM aaa-48-s' !!! --lyndon P.S. Terminfo entry attached for your enjoyment. (It's a text/plain. I have no idea what the hell Apple's Mail.app will do with it.) -------------- next part -------------- A non-text attachment was scrubbed... Name: xterm.terminfo Type: application/octet-stream Size: 1339 bytes Desc: not available URL: -------------- next part -------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From lyndon at orthanc.ca Sun Jan 11 08:51:00 2015 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Sat, 10 Jan 2015 14:51:00 -0800 Subject: [TUHS] Termcap vs terminfo In-Reply-To: References: <1FD28B19-FA50-4581-BB0A-257B5DDE1890@kdbarto.org> <30E98281-D4A7-424D-A757-2EF50A0BFC65@kdbarto.org> Message-ID: On Jan 10, 2015, at 2:43 PM, Lyndon Nerenberg wrote: > Most modern curses capability entries for 'xterm' and friends use the memory buffer windowing capability (a term I made up) Umm ... I meant 'just made up' as in "I can't think of a better name this second." I'm pretty sure somebody else invented memory buffers and sliding pointers. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From chneukirchen at gmail.com Sun Jan 11 09:02:50 2015 From: chneukirchen at gmail.com (Christian Neukirchen) Date: Sun, 11 Jan 2015 00:02:50 +0100 Subject: [TUHS] Termcap vs terminfo In-Reply-To: (Lyndon Nerenberg's message of "Sat, 10 Jan 2015 14:43:53 -0800") References: <1FD28B19-FA50-4581-BB0A-257B5DDE1890@kdbarto.org> <30E98281-D4A7-424D-A757-2EF50A0BFC65@kdbarto.org> Message-ID: <87iogegrxh.fsf@gmail.com> Lyndon Nerenberg writes: > On Jan 10, 2015, at 2:15 PM, David Barto wrote: > >> All I remember (and still support to this day) is that I’ve got a >> TERMCAP=‘string’ in my login scripts to set termcap to the specific >> terminal I’m logging in with. >> >> Long ago this made things much faster. Today I think that it is just >> a holdover that I’m not changing due to inertia, rather than any >> real need for it. > > There is still a need for this. > > Most modern curses capability entries for 'xterm' and friends use the > memory buffer windowing capability (a term I made up) such that when > you - say - run less to display a file, it switches to a dedicated > region in the terminal memory buffer while printing its output, then > restores the buffer to back where you were to begin with when you exit > the pager. > > This drives me insane! When I 'man foo' and find the relevant bits in > the document, when I quit out of the pager I want those bits to stay > on the screen so I can refer to them, dammit! There are two shortcuts > to this, both involving custom termcap/terminfo entries. Or just use: xterm -xrm '*titeInhibit: true' Just for less: export LESS="-X" Just for vim: set t_ti= t_te= -- Christian Neukirchen http://chneukirchen.org From lyndon at orthanc.ca Sun Jan 11 09:04:28 2015 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Sat, 10 Jan 2015 15:04:28 -0800 Subject: [TUHS] Termcap vs terminfo In-Reply-To: <87iogegrxh.fsf@gmail.com> References: <1FD28B19-FA50-4581-BB0A-257B5DDE1890@kdbarto.org> <30E98281-D4A7-424D-A757-2EF50A0BFC65@kdbarto.org> <87iogegrxh.fsf@gmail.com> Message-ID: On Jan 10, 2015, at 3:02 PM, Christian Neukirchen wrote: > Or just use: xterm -xrm '*titeInhibit: true' > Just for less: export LESS="-X" > Just for vim: set t_ti= t_te= Please provide the list of workarounds for all other curses consumers used worldwide and forever. Wouldn't it be nice if I could just do this in one place? Oh, wait ... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dave at horsfall.org Sun Jan 11 12:06:08 2015 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 11 Jan 2015 13:06:08 +1100 (EST) Subject: [TUHS] Termcap vs terminfo In-Reply-To: References: <1FD28B19-FA50-4581-BB0A-257B5DDE1890@kdbarto.org> <30E98281-D4A7-424D-A757-2EF50A0BFC65@kdbarto.org> Message-ID: On Sat, 10 Jan 2015, Lyndon Nerenberg wrote: > This drives me insane! When I 'man foo' and find the relevant bits in > the document, when I quit out of the pager I want those bits to stay on > the screen so I can refer to them, dammit! There are two shortcuts to > this, both involving custom termcap/terminfo entries. I'm glad I'm not the only one annoyed by this "feature". -- Dave Horsfall DTM (VK2KFU) "Bliss is a MacBook with a FreeBSD server." http://www.horsfall.org/spam.html (and check the home page whilst you're there) From doug at cs.dartmouth.edu Sun Jan 11 15:20:58 2015 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sun, 11 Jan 2015 00:20:58 -0500 Subject: [TUHS] Less -- was Termcap vs terminfo Message-ID: <201501110520.t0B5KwvP018801@coolidge.cs.dartmouth.edu> > when you - say - run less to display a file, it switches to a dedicated > region in the terminal memory buffer while printing its output, then > restores the buffer to back where you were to begin with when you exit > the pager Sorry for veering away from Unix history, but this pushed one of the hottest of my buttons. Less is the epitome of modern Unix decadence. Besides the maddening behavior described above, why, when all screens have a scroll bar, should a pager do its own scrolling? But for a quantitative measure of decadence, try less --help | wc. It takes excess to a level not dreamed of in Pike's classic critique, "cat -v considered harmful". Doug From dds at aueb.gr Sun Jan 11 19:16:21 2015 From: dds at aueb.gr (Diomidis Spinellis) Date: Sun, 11 Jan 2015 11:16:21 +0200 Subject: [TUHS] Termcap vs terminfo In-Reply-To: References: <1FD28B19-FA50-4581-BB0A-257B5DDE1890@kdbarto.org> <30E98281-D4A7-424D-A757-2EF50A0BFC65@kdbarto.org> Message-ID: <54B23F65.2090104@aueb.gr> On 11/01/2015 04:06, Dave Horsfall wrote: > On Sat, 10 Jan 2015, Lyndon Nerenberg wrote: > >> This drives me insane! When I 'man foo' and find the relevant bits in >> the document, when I quit out of the pager I want those bits to stay on >> the screen so I can refer to them, dammit! There are two shortcuts to >> this, both involving custom termcap/terminfo entries. > > I'm glad I'm not the only one annoyed by this "feature". I agree it's maddening! This is what I have on my .bashrc file to avoid this behavior. # Don't restore screen, quit at EOF, more-like prompt, pass color control chars export LESS=-XEmR This problem, and the desire to use the vi key bindings instead of the Emacs ones for command-line editing, are the reason I invested effort to place my login configuration under Git control, and replicate it on the tens of hosts I find myself logged in over a working day. Now a simple "git clone" restores sanity to my working environment. From chneukirchen at gmail.com Mon Jan 12 02:48:44 2015 From: chneukirchen at gmail.com (Christian Neukirchen) Date: Sun, 11 Jan 2015 17:48:44 +0100 Subject: [TUHS] Termcap vs terminfo In-Reply-To: (Lyndon Nerenberg's message of "Sat, 10 Jan 2015 15:04:28 -0800") References: <1FD28B19-FA50-4581-BB0A-257B5DDE1890@kdbarto.org> <30E98281-D4A7-424D-A757-2EF50A0BFC65@kdbarto.org> <87iogegrxh.fsf@gmail.com> Message-ID: <8761cdgt5f.fsf@gmail.com> Lyndon Nerenberg writes: > On Jan 10, 2015, at 3:02 PM, Christian Neukirchen wrote: > >> Or just use: xterm -xrm '*titeInhibit: true' >> Just for less: export LESS="-X" >> Just for vim: set t_ti= t_te= > > Please provide the list of workarounds for all other curses consumers > used worldwide and forever. > > Wouldn't it be nice if I could just do this in one place? Oh, wait ... I did: xterm -xrm '*titeInhibit: true' -- Christian Neukirchen http://chneukirchen.org From jacob.ritorto at gmail.com Mon Jan 12 03:08:44 2015 From: jacob.ritorto at gmail.com (Jacob Ritorto) Date: Sun, 11 Jan 2015 12:08:44 -0500 Subject: [TUHS] Less -- was Termcap vs terminfo In-Reply-To: <201501110520.t0B5KwvP018801@coolidge.cs.dartmouth.edu> References: <201501110520.t0B5KwvP018801@coolidge.cs.dartmouth.edu> Message-ID: > > Less is the epitome of modern Unix decadence. agree > Besides the > maddening behavior described above, why, when all screens have a scroll > bar, > should a pager do its own scrolling? in lieu of X scrollbars, there's also terminal multiplexers like tmux or screen. Also, there's the case of working directly on a character cell terminal or console (rare these days, I admit, but I still do it frequently enough to occasionally get caught without a scrollback buffer and lose important stuff). Hence my use of tmux et al.. So, yeah, agree. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brantleycoile at me.com Mon Jan 12 05:40:19 2015 From: brantleycoile at me.com (Brantley Coile) Date: Sun, 11 Jan 2015 14:40:19 -0500 Subject: [TUHS] Less -- was Termcap vs terminfo In-Reply-To: <201501110520.t0B5KwvP018801@coolidge.cs.dartmouth.edu> References: <201501110520.t0B5KwvP018801@coolidge.cs.dartmouth.edu> Message-ID: On Jan 11, 2015, at 12:20 AM, Doug McIlroy wrote: >> when you - say - run less to display a file, it switches to a dedicated >> region in the terminal memory buffer while printing its output, then >> restores the buffer to back where you were to begin with when you exit >> the pager > > Sorry for veering away from Unix history, but this pushed one of the hottest > of my buttons. Less is the epitome of modern Unix decadence. Besides the > maddening behavior described above, why, when all screens have a scroll bar, > should a pager do its own scrolling? But for a quantitative measure of > decadence, try less --help | wc. It takes excess to a level not dreamed of > in Pike's classic critique, "cat -v considered harmful". > > Doug I couldn’t agree with you more, Doug. That’s why I started my new company, South Suite Software. I want to re-evolve the software on the server side. Besides “man less | wc -l”, there is the following. - A man of gcc produces more lines than was in Dennis’ 7th Edition compiler. - The number bytes in the C compiler clang's object file on my machine is 37,810,480, yet the compiler I use to build our software, Ken Thompson’s C from Plan 9, is 280,764 bytes. - Kernels now measure in the millions of lines. Even with the various device drivers removed from a recent Linux kernel, almost a million lines remain. - The recently hacked NTP protocol weights in at over 200,000 lines. I could go on. When Coraid’s management decided to change the base operating system from Plan 9 to Solaris, I decided it was time to start a new company dedicated to the re-evolution of the system software used in the back end machine rooms of the Internet. I say re-evolution, because the existing code base has accretions that a software archeologist could use to study all the problems faced by system software since the 1960’s. Each solution to a temporal problem has been entombed in all the code going forward. Paging in from disk is a good example. The Atlas invented paging to overcome a dearth of local memory by swapping out to a magnetic drum. Today, when an average instruction executes in 600 picoseconds, it seems untenable to fetch 4096 bytes from a disk in 6,000,000,000 picoseconds. Most of the code in current Unix-like systems still have code that solves problems like this that we no longer have. And the consequences of the current code growth has real ramifications on everyone. The continued improvement in quality of life has always depended on advancements of technology that lowered the cost of production. Thanks to Moore’s law, system software has had a free lunch for twenty-five years. Now that free lunch room is closed. Six years ago Gordon Moore said there was two, maybe three Moore cycles left. Things have gotten so small that quantum affects are beginning to dominate. Intel, reportedly, has had problem getting satisfactory 14nm technology yields. Silicon capital equipment manufacturers have halted development on equipment to produce larger wafers. Moore’s law will no longer lower the cost of a unit of compute. In addition, it’s obvious from history that the larger the code is the more buggy it is. Not only is reliably an issue, but so is security. Security is compromised by exploiting a class of bugs. So, if the code is larger, and the number of bugs is more, it follows that the number of security bugs is also greater. At one of my previous companies I built the PIX Firewall, later sold to Cisco, which was only about 50,000 bytes. It’s simplicity, at least at the time I was involved with it, made it very secure. So now I have started South Suite to produce software that, when added to white box hardware, creates easy to deploy, highly efficient, high performance appliances at a significantly lower cost. We are re-evoloving system software, skipping all the intermediate steps that are encased in all other solutions. We are doing it in the same culture, the same value system, that was at Bell Labs center 1127 and gave us these wonderful versions of Unix we all enjoy learning from. We are even using Bell Labs tools from Plan 9 to re-invent the back end server room as if we were back at the labs, starting over. I share the frustration with modern Unix some have expressed on this list. And I’m trying to do something about it. We on this list are lucky enough to know versions of Unix that were simple, clear, general and very, very effective. The performance they extracted from the modest PDP-11 hardware was amazing. In whatever way the readers of this list can, we should all bring this kind of values to the programming we do. Together it can have a huge affect on the quality of life for everyone. Thanks for being a part of giving birth to that legacy, Doug. Thanks everyone for listening to my rant. Brantley Coile From dave at horsfall.org Mon Jan 12 07:27:08 2015 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 12 Jan 2015 08:27:08 +1100 (EST) Subject: [TUHS] Less -- was Termcap vs terminfo In-Reply-To: References: <201501110520.t0B5KwvP018801@coolidge.cs.dartmouth.edu> Message-ID: On Sun, 11 Jan 2015, Brantley Coile wrote: > We are re-evoloving system software [...] I know it was a typo, but I still like it :-) -- Dave Horsfall DTM (VK2KFU) "Bliss is a MacBook with a FreeBSD server." http://www.horsfall.org/spam.html (and check the home page whilst you're there) From brantleycoile at me.com Mon Jan 12 08:10:12 2015 From: brantleycoile at me.com (Brantley Coile) Date: Sun, 11 Jan 2015 17:10:12 -0500 Subject: [TUHS] Less -- was Termcap vs terminfo In-Reply-To: References: <201501110520.t0B5KwvP018801@coolidge.cs.dartmouth.edu> Message-ID: <5BA2B1DE-252B-448D-AFA4-868E85E9EDCE@me.com> :) And I guess we evo love it again, too. :) Sent from my iPad > On Jan 11, 2015, at 4:27 PM, Dave Horsfall wrote: > >> On Sun, 11 Jan 2015, Brantley Coile wrote: >> >> We are re-evoloving system software [...] > > I know it was a typo, but I still like it :-) > > -- > Dave Horsfall DTM (VK2KFU) "Bliss is a MacBook with a FreeBSD server." > http://www.horsfall.org/spam.html (and check the home page whilst you're there) > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs From clemc at ccc.com Tue Jan 13 01:32:47 2015 From: clemc at ccc.com (Clem Cole) Date: Mon, 12 Jan 2015 10:32:47 -0500 Subject: [TUHS] Less -- was Termcap vs terminfo In-Reply-To: References: <201501110520.t0B5KwvP018801@coolidge.cs.dartmouth.edu> Message-ID: Brantley/Doug - I think you might be amused (or maybe disgusted) when the 3B2 came out. I pointed out to Dennis that the bootloader was multiple times of the size of 6th edition kernel and not nearly as easy to understand. Indeed, I agree that Pike's railing in "*cat -v considered harmful*" was a telltale of bad things. I always thought that many of my siblings at UCB had lost the spirit of "UNIX Philosophy" of a "single small program doing one job well" when the Vax "fixed" the address issues of the PDP-11. It allowed for sloppiness and programs grew without thought or bound. Doug, while you describe "less" as the an example of decadence, I think a better example of same is sendmail. I have always said that if Eric had left the SMTPD as a separate program (which is what is was when the TCP/IP support came to UCB from BBN); sendmail would never have become what it did. The primary issue of header rewriting was not something most sites had issues like UCB did - they just needed an SMTP interface and sendmail was the SMTPD for 4.3BSD. So sites picked it up because of that. Clem On Sun, Jan 11, 2015 at 2:40 PM, Brantley Coile wrote: > > On Jan 11, 2015, at 12:20 AM, Doug McIlroy wrote: > > >> when you - say - run less to display a file, it switches to a dedicated > >> region in the terminal memory buffer while printing its output, then > >> restores the buffer to back where you were to begin with when you exit > >> the pager > > > > Sorry for veering away from Unix history, but this pushed one of the > hottest > > of my buttons. Less is the epitome of modern Unix decadence. Besides the > > maddening behavior described above, why, when all screens have a scroll > bar, > > should a pager do its own scrolling? But for a quantitative measure of > > decadence, try less --help | wc. It takes excess to a level not dreamed > of > > in Pike's classic critique, "cat -v considered harmful". > > > > Doug > > I couldn’t agree with you more, Doug. That’s why I started my new > company, South Suite Software. I want to re-evolve the software on the > server side. > > Besides “man less | wc -l”, there is the following. > > - A man of gcc produces more lines than was in Dennis’ 7th Edition > compiler. > > - The number bytes in the C compiler clang's object file on my machine is > 37,810,480, yet the compiler I use to build our software, Ken Thompson’s C > from Plan 9, is 280,764 bytes. > > - Kernels now measure in the millions of lines. Even with the various > device drivers removed from a recent Linux kernel, almost a million lines > remain. > > - The recently hacked NTP protocol weights in at over 200,000 lines. > > I could go on. > > When Coraid’s management decided to change the base operating system from > Plan 9 to Solaris, I decided it was time to start a new company dedicated > to the re-evolution of the system software used in the back end machine > rooms of the Internet. > > I say re-evolution, because the existing code base has accretions that a > software archeologist could use to study all the problems faced by system > software since the 1960’s. Each solution to a temporal problem has been > entombed in all the code going forward. Paging in from disk is a good > example. The Atlas invented paging to overcome a dearth of local memory by > swapping out to a magnetic drum. Today, when an average instruction > executes in 600 picoseconds, it seems untenable to fetch 4096 bytes from a > disk in 6,000,000,000 picoseconds. Most of the code in current Unix-like > systems still have code that solves problems like this that we no longer > have. > > And the consequences of the current code growth has real ramifications on > everyone. The continued improvement in quality of life has always depended > on advancements of technology that lowered the cost of production. Thanks > to Moore’s law, system software has had a free lunch for twenty-five > years. Now that free lunch room is closed. Six years ago Gordon Moore > said there was two, maybe three Moore cycles left. Things have gotten so > small that quantum affects are beginning to dominate. Intel, reportedly, > has had problem getting satisfactory 14nm technology yields. Silicon > capital equipment manufacturers have halted development on equipment to > produce larger wafers. Moore’s law will no longer lower the cost of a unit > of compute. > > In addition, it’s obvious from history that the larger the code is the > more buggy it is. Not only is reliably an issue, but so is security. > Security is compromised by exploiting a class of bugs. So, if the code is > larger, and the number of bugs is more, it follows that the number of > security bugs is also greater. At one of my previous companies I built the > PIX Firewall, later sold to Cisco, which was only about 50,000 bytes. It’s > simplicity, at least at the time I was involved with it, made it very > secure. > > So now I have started South Suite to produce software that, when added to > white box hardware, creates easy to deploy, highly efficient, high > performance appliances at a significantly lower cost. We are re-evoloving > system software, skipping all the intermediate steps that are encased in > all other solutions. We are doing it in the same culture, the same value > system, that was at Bell Labs center 1127 and gave us these wonderful > versions of Unix we all enjoy learning from. We are even using Bell Labs > tools from Plan 9 to re-invent the back end server room as if we were back > at the labs, starting over. > > I share the frustration with modern Unix some have expressed on this > list. And I’m trying to do something about it. We on this list are lucky > enough to know versions of Unix that were simple, clear, general and very, > very effective. The performance they extracted from the modest PDP-11 > hardware was amazing. In whatever way the readers of this list can, we > should all bring this kind of values to the programming we do. Together it > can have a huge affect on the quality of life for everyone. > > Thanks for being a part of giving birth to that legacy, Doug. > > Thanks everyone for listening to my rant. > > Brantley Coile > > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Jan 13 01:36:29 2015 From: clemc at ccc.com (Clem Cole) Date: Mon, 12 Jan 2015 10:36:29 -0500 Subject: [TUHS] Termcap vs terminfo In-Reply-To: References: <1FD28B19-FA50-4581-BB0A-257B5DDE1890@kdbarto.org> <30E98281-D4A7-424D-A757-2EF50A0BFC65@kdbarto.org> Message-ID: +1 On Sat, Jan 10, 2015 at 9:06 PM, Dave Horsfall wrote: > On Sat, 10 Jan 2015, Lyndon Nerenberg wrote: > > > This drives me insane! When I 'man foo' and find the relevant bits in > > the document, when I quit out of the pager I want those bits to stay on > > the screen so I can refer to them, dammit! There are two shortcuts to > > this, both involving custom termcap/terminfo entries. > > I'm glad I'm not the only one annoyed by this "feature". > > -- > Dave Horsfall DTM (VK2KFU) "Bliss is a MacBook with a FreeBSD server." > http://www.horsfall.org/spam.html (and check the home page whilst you're > there) > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.rezaian at earthlink.net Tue Jan 13 02:51:54 2015 From: r.rezaian at earthlink.net (Russell Rezaian) Date: Mon, 12 Jan 2015 10:51:54 -0600 Subject: [TUHS] Disable "less" screen swapping was: Re: Termcap vs terminfo In-Reply-To: References: <1FD28B19-FA50-4581-BB0A-257B5DDE1890@kdbarto.org> <30E98281-D4A7-424D-A757-2EF50A0BFC65@kdbarto.org> Message-ID: <54B3FBAA.1060505@earthlink.net> On Sat, Jan 10, 2015 at 9:06 PM, Dave Horsfall > wrote: > > On Sat, 10 Jan 2015, Lyndon Nerenberg wrote: > > > This drives me insane! When I 'man foo' and find the relevant > bits in > > the document, when I quit out of the pager I want those bits to > stay on > > the screen so I can refer to them, dammit! There are two > shortcuts to > > this, both involving custom termcap/terminfo entries. > > I'm glad I'm not the only one annoyed by this "feature". > I am also not happy with this behavior. There is at least one "fix" I have found for this particular annoyance. A little background: this behavior uses a pair of termcap entries called "ti" and "te" which, on most recent xterm implementations, switch between alternate screens. Many programs on startup switch to the alternate screen to keep their displays separate from the normal command scroll buffer. There is an xterm resource "titeInhibit" which, if set to true, will disable the remarkably annoying mode switch that is used by less (and also any other application that tries to use the screen swap). Given this started out as a termcap thread, hopefully this will be appropriate! This complete disable of the screen swap may not be what everyone is looking for, but it certainly was what I wanted. -- Russell -------------- next part -------------- An HTML attachment was scrubbed... URL: From random832 at fastmail.us Tue Jan 13 05:38:25 2015 From: random832 at fastmail.us (random832 at fastmail.us) Date: Mon, 12 Jan 2015 14:38:25 -0500 Subject: [TUHS] Less -- was Termcap vs terminfo In-Reply-To: <201501110520.t0B5KwvP018801@coolidge.cs.dartmouth.edu> References: <201501110520.t0B5KwvP018801@coolidge.cs.dartmouth.edu> Message-ID: <1421091505.3373070.212956033.39DC72E0@webmail.messagingengine.com> On Sun, Jan 11, 2015, at 00:20, Doug McIlroy wrote: > Sorry for veering away from Unix history, but this pushed one of the > hottest > of my buttons. Less is the epitome of modern Unix decadence. Besides the > maddening behavior described above, why, when all screens have a scroll > bar, > should a pager do its own scrolling? The console screen doesn't, and the one in an emulator can't be controlled by the pager. The real question is why a pager should be executed at all in an xterm. Except xterm has no ability to search in scrollback, and its buffer may not be large enough for some very large manpages. From jacob.ritorto at gmail.com Tue Jan 13 05:44:30 2015 From: jacob.ritorto at gmail.com (Jacob Ritorto) Date: Mon, 12 Jan 2015 14:44:30 -0500 Subject: [TUHS] Less -- was Termcap vs terminfo In-Reply-To: <1421091505.3373070.212956033.39DC72E0@webmail.messagingengine.com> References: <201501110520.t0B5KwvP018801@coolidge.cs.dartmouth.edu> <1421091505.3373070.212956033.39DC72E0@webmail.messagingengine.com> Message-ID: On Mon, Jan 12, 2015 at 2:38 PM, wrote: > > > On Sun, Jan 11, 2015, at 00:20, Doug McIlroy wrote: > The console screen doesn't, and the one in an emulator can't be > controlled by the pager. The real question is why a pager should be > executed at all in an xterm. Except xterm has no ability to search in > scrollback, and its buffer may not be large enough for some very large > manpages. srsly, this is why we have tmux. or even good old screen, in a pinch. http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/tmux.1?query=tmux&sec=1 each program small and good at its one own thing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Tue Jan 13 05:52:06 2015 From: cowan at ccil.org (cowan at ccil.org) Date: Mon, 12 Jan 2015 14:52:06 -0500 Subject: [TUHS] Less -- was Termcap vs terminfo In-Reply-To: References: <201501110520.t0B5KwvP018801@coolidge.cs.dartmouth.edu> <1421091505.3373070.212956033.39DC72E0@webmail.messagingengine.com> Message-ID: <26f30fee0aa9ee31687ab7e6ec169975.squirrel@www.ccil.org> > each program small and good at its one own thing. I don't think it's sensible to apply this dictum to editors and viewers. We don't, for example, have separate programs for inserting text, deleting text, replacing text, scrolling a view up, scrolling a view down, and so on. Less is really a sort of ed without the ability to modify its buffer. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org Some people open all the Windows; wise wives welcome the spring by moving the Unix. --Advertisement for Unix Book Units (U.K.) (see http://cm.bell-labs.com/cm/cs/who/dmr/unix3image.gif) From khm at sciops.net Tue Jan 13 05:53:00 2015 From: khm at sciops.net (Kurt H Maier) Date: Mon, 12 Jan 2015 19:53:00 +0000 Subject: [TUHS] Less -- was Termcap vs terminfo In-Reply-To: References: <201501110520.t0B5KwvP018801@coolidge.cs.dartmouth.edu> <1421091505.3373070.212956033.39DC72E0@webmail.messagingengine.com> Message-ID: <20150112195300.Horde.m-KX0gVuyTDTW6lnVUnE1Q2@ssl.eumx.net> Quoting Jacob Ritorto : > > srsly, this is why we have tmux. or even good old screen, in a pinch. > > http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/tmux.1?query=tmux&sec=1 > > each program small and good at its one own thing. If the "one thing" is "fix the broken design of another program" it's often a better idea to just fix the original program. khm From random832 at fastmail.us Tue Jan 13 06:34:21 2015 From: random832 at fastmail.us (random832 at fastmail.us) Date: Mon, 12 Jan 2015 15:34:21 -0500 Subject: [TUHS] Less -- was Termcap vs terminfo In-Reply-To: References: <201501110520.t0B5KwvP018801@coolidge.cs.dartmouth.edu> <1421091505.3373070.212956033.39DC72E0@webmail.messagingengine.com> Message-ID: <1421094861.3387032.212981065.1F9F4427@webmail.messagingengine.com> On Mon, Jan 12, 2015, at 14:44, Jacob Ritorto wrote: > srsly, this is why we have tmux. or even good old screen, in a pinch. > > http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/tmux.1?query=tmux&sec=1 > > each program small and good at its one own thing. In principle, the functions "detachable terminal session", "terminal session multiplexer", and "terminal with scrollback", and "translator from a common VT100 superset to whatever the hell the user is using" could be four separate programs. From clemc at ccc.com Tue Jan 13 07:25:07 2015 From: clemc at ccc.com (Clem Cole) Date: Mon, 12 Jan 2015 16:25:07 -0500 Subject: [TUHS] Less -- was Termcap vs terminfo In-Reply-To: <1421094861.3387032.212981065.1F9F4427@webmail.messagingengine.com> References: <201501110520.t0B5KwvP018801@coolidge.cs.dartmouth.edu> <1421091505.3373070.212956033.39DC72E0@webmail.messagingengine.com> <1421094861.3387032.212981065.1F9F4427@webmail.messagingengine.com> Message-ID: On Mon, Jan 12, 2015 at 3:34 PM, wrote: > > > In principle, the functions "detachable terminal session", "terminal > session multiplexer", and "terminal with scrollback", and "translator > from a common VT100 superset to whatever the hell the user is using" > could be four separate programs. ​To quote Rob and Brian from the "cat -v" paper: [ http://harmful.cat-v.org/cat-v/unix_prog_design.pdf] ​ Separate programs are not always better than wider options; which is better depends on the problem. Whenever one needs a way to perform a new function, one faces the choice of whether to add a new option or write a new program (assuming that none of the programmable tools will do the job conveniently). The guiding principle for making the choice should be that each program does one thing. Options are appropriately added to a program that already has the right functionality. If there is no such program, then a new program is called for. In that case, the usual criteria for program design should be used: the program should be as general as possible, its default behavior should match the most common usage, and it should cooperate with other programs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Wed Jan 14 11:12:03 2015 From: wkt at tuhs.org (Warren Toomey) Date: Wed, 14 Jan 2015 12:12:03 +1100 Subject: [TUHS] SVN of CSRG Releases Message-ID: <20150114011203.GA632@www.oztivo.net> Hi all, I came across this last week: http://svnweb.freebsd.org/ It's a Subversion VCS of all the CSRG releases. I'm not sure if it has been mentioned here before. Cheers, Warren From lm at mcvoy.com Wed Jan 14 11:42:56 2015 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 13 Jan 2015 17:42:56 -0800 Subject: [TUHS] SVN of CSRG Releases In-Reply-To: <20150114011203.GA632@www.oztivo.net> References: <20150114011203.GA632@www.oztivo.net> Message-ID: <20150114014256.GB17893@mcvoy.com> Aren't the SCCS sources for the real history online? I know Kirk made them available on his CD, I have them somewhere. On Wed, Jan 14, 2015 at 12:12:03PM +1100, Warren Toomey wrote: > Hi all, I came across this last week: > > http://svnweb.freebsd.org/ > > It's a Subversion VCS of all the CSRG releases. I'm not sure if it > has been mentioned here before. > > Cheers, Warren > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From wkt at tuhs.org Wed Jan 14 11:55:57 2015 From: wkt at tuhs.org (Warren Toomey) Date: Wed, 14 Jan 2015 12:55:57 +1100 Subject: [TUHS] SVN of CSRG Releases In-Reply-To: <20150114014256.GB17893@mcvoy.com> References: <20150114011203.GA632@www.oztivo.net> <20150114014256.GB17893@mcvoy.com> Message-ID: <20150114015556.GA3136@www.oztivo.net> On Tue, Jan 13, 2015 at 05:42:56PM -0800, Larry McVoy wrote: > Aren't the SCCS sources for the real history online? I know Kirk made > them available on his CD, I have them somewhere. In a previous private e-mail I received from Kirk, he said: The folks at UC Berkeley have always required me to track distributions of the SCCS files as they somehow think of them as still sensitive. which implies that the SCCS files cannot be released publicly. However, the SVN version is a "derivative" of the SCCS files and, on that basis, is publicly available. Go figure :) Cheers, Warren From grog at lemis.com Wed Jan 14 12:24:27 2015 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Wed, 14 Jan 2015 13:24:27 +1100 Subject: [TUHS] SVN of CSRG Releases In-Reply-To: <20150114015556.GA3136@www.oztivo.net> References: <20150114011203.GA632@www.oztivo.net> <20150114014256.GB17893@mcvoy.com> <20150114015556.GA3136@www.oztivo.net> Message-ID: <20150114022427.GB24813@eureka.lemis.com> On Wednesday, 14 January 2015 at 12:55:57 +1100, Warren Toomey wrote: > On Tue, Jan 13, 2015 at 05:42:56PM -0800, Larry McVoy wrote: >> Aren't the SCCS sources for the real history online? I know Kirk made >> them available on his CD, I have them somewhere. > > In a previous private e-mail I received from Kirk, he said: > The folks at UC > Berkeley have always required me to track distributions of the SCCS > files as they somehow think of them as still sensitive. > > which implies that the SCCS files cannot be released publicly. However, > the SVN version is a "derivative" of the SCCS files and, on that basis, > is publicly available. Go figure :) Considering that all the SCCS files are on the CDs that Kirk distributed, that's particularly strange. My thought was that, with the exception of Larry, nobody has the SCCS software any more. Greg -- Sent from my desktop computer. Finger grog at FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available URL: From lm at mcvoy.com Wed Jan 14 12:37:52 2015 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 13 Jan 2015 18:37:52 -0800 Subject: [TUHS] SVN of CSRG Releases In-Reply-To: <20150114022427.GB24813@eureka.lemis.com> References: <20150114011203.GA632@www.oztivo.net> <20150114014256.GB17893@mcvoy.com> <20150114015556.GA3136@www.oztivo.net> <20150114022427.GB24813@eureka.lemis.com> Message-ID: <20150114023752.GC17893@mcvoy.com> On Wed, Jan 14, 2015 at 01:24:27PM +1100, Greg 'groggy' Lehey wrote: > On Wednesday, 14 January 2015 at 12:55:57 +1100, Warren Toomey wrote: > > On Tue, Jan 13, 2015 at 05:42:56PM -0800, Larry McVoy wrote: > >> Aren't the SCCS sources for the real history online? I know Kirk made > >> them available on his CD, I have them somewhere. > > > > In a previous private e-mail I received from Kirk, he said: > > The folks at UC > > Berkeley have always required me to track distributions of the SCCS > > files as they somehow think of them as still sensitive. > > > > which implies that the SCCS files cannot be released publicly. However, > > the SVN version is a "derivative" of the SCCS files and, on that basis, > > is publicly available. Go figure :) > > Considering that all the SCCS files are on the CDs that Kirk > distributed, that's particularly strange. My thought was that, with > the exception of Larry, nobody has the SCCS software any more. GNU has an SCCS clone. A so-so one but James and his crew fixes bugs. And I suspect that BitSCCS is out there on the intertubes somewhere. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From cowan at mercury.ccil.org Wed Jan 14 14:41:11 2015 From: cowan at mercury.ccil.org (John Cowan) Date: Tue, 13 Jan 2015 23:41:11 -0500 Subject: [TUHS] SVN of CSRG Releases In-Reply-To: <20150114023752.GC17893@mcvoy.com> References: <20150114011203.GA632@www.oztivo.net> <20150114014256.GB17893@mcvoy.com> <20150114015556.GA3136@www.oztivo.net> <20150114022427.GB24813@eureka.lemis.com> <20150114023752.GC17893@mcvoy.com> Message-ID: <20150114044111.GF26762@mercury.ccil.org> Larry McVoy scripsit: > GNU has an SCCS clone. A so-so one but James and his crew fixes bugs. OpenIndiana has a derivative of the SVR4 version, and so does the Heirloom Toolkit. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org Consider the matter of Analytic Philosophy. Dennett and Bennett are well-known. Dennett rarely or never cites Bennett, so Bennett rarely or never cites Dennett. There is also one Dummett. By their works shall ye know them. However, just as no trinities have fourth persons (Zeppo Marx notwithstanding), Bummett is hardly known by his works. Indeed, Bummett does not exist. It is part of the function of this and other e-mail messages, therefore, to do what they can to create him. From sdaoden at yandex.com Wed Jan 14 21:24:11 2015 From: sdaoden at yandex.com (Steffen Nurpmeso) Date: Wed, 14 Jan 2015 12:24:11 +0100 Subject: [TUHS] SVN of CSRG Releases In-Reply-To: <20150114023752.GC17893@mcvoy.com> References: <20150114011203.GA632@www.oztivo.net> <20150114014256.GB17893@mcvoy.com> <20150114015556.GA3136@www.oztivo.net> <20150114022427.GB24813@eureka.lemis.com> <20150114023752.GC17893@mcvoy.com> Message-ID: <20150114112411.sD3MlJkTf6mgWh37@yandex.com> Larry McVoy wrote: |On Wed, Jan 14, 2015 at 01:24:27PM +1100, Greg 'groggy' Lehey wrote: |> On Wednesday, 14 January 2015 at 12:55:57 +1100, Warren Toomey wrote: |>> On Tue, Jan 13, 2015 at 05:42:56PM -0800, Larry McVoy wrote: |>>> Aren't the SCCS sources for the real history online? I know Kirk made |>>> them available on his CD, I have them somewhere. |>> |>> In a previous private e-mail I received from Kirk, he said: |>> The folks at UC |>> Berkeley have always required me to track distributions of the SCCS |>> files as they somehow think of them as still sensitive. |>> |>> which implies that the SCCS files cannot be released publicly. However, |>> the SVN version is a "derivative" of the SCCS files and, on that basis, |>> is publicly available. Go figure :) |> |> Considering that all the SCCS files are on the CDs that Kirk |> distributed, that's particularly strange. My thought was that, with |> the exception of Larry, nobody has the SCCS software any more. | |GNU has an SCCS clone. A so-so one but James and his crew fixes bugs. |And I suspect that BitSCCS is out there on the intertubes somewhere. Jörg Schilling also has a(n extended) SCCS, now located at [1]. [1] http://sourceforge.net/projects/schilytools/ I have cloned the (FreeBSD based) git(1) repo mentioned elsewhere in this thread, but it is no good -- a better version with much (, much) better meta data is at [2], but it is much larger, of course. [2] https://github.com/jonathangray/csrg --steffen From dds at aueb.gr Wed Jan 14 21:45:26 2015 From: dds at aueb.gr (Diomidis Spinellis) Date: Wed, 14 Jan 2015 13:45:26 +0200 Subject: [TUHS] SVN of CSRG Releases In-Reply-To: <20150114015556.GA3136@www.oztivo.net> References: <20150114011203.GA632@www.oztivo.net> <20150114014256.GB17893@mcvoy.com> <20150114015556.GA3136@www.oztivo.net> Message-ID: <54B656D6.8080907@aueb.gr> On 14/01/2015 03:55, Warren Toomey wrote: > On Tue, Jan 13, 2015 at 05:42:56PM -0800, Larry McVoy wrote: >> Aren't the SCCS sources for the real history online? I know Kirk made >> them available on his CD, I have them somewhere. > > In a previous private e-mail I received from Kirk, he said: > The folks at UC > Berkeley have always required me to track distributions of the SCCS > files as they somehow think of them as still sensitive. > > which implies that the SCCS files cannot be released publicly. However, > the SVN version is a "derivative" of the SCCS files and, on that basis, > is publicly available. Go figure :) Here's another data point: when I asked Kirk regarding the public availability of the SCCS repo he pointed me to http://svnweb.freebsd.org/csrg/. At https://github.com/dspinellis/unix-history-repo you can find a single 1GB repository that integrates many of the snapshots and version control repositories available through TUHS and other sources (including the CSRG data). Its commit history starts on Jun 20th 1972 with the First Research Edition and ends with FreeBSD 10 in 2015. Git blame works across all the history's commits. From jacob.ritorto at gmail.com Thu Jan 15 03:38:05 2015 From: jacob.ritorto at gmail.com (Jacob Ritorto) Date: Wed, 14 Jan 2015 12:38:05 -0500 Subject: [TUHS] SVN of CSRG Releases In-Reply-To: <54B656D6.8080907@aueb.gr> References: <20150114011203.GA632@www.oztivo.net> <20150114014256.GB17893@mcvoy.com> <20150114015556.GA3136@www.oztivo.net> <54B656D6.8080907@aueb.gr> Message-ID: Not to over-state the importance of this particular version control system, but having this code on github is game-changing; thanks, guys. On Wed, Jan 14, 2015 at 6:45 AM, Diomidis Spinellis wrote: > On 14/01/2015 03:55, Warren Toomey wrote: > >> On Tue, Jan 13, 2015 at 05:42:56PM -0800, Larry McVoy wrote: >> >>> Aren't the SCCS sources for the real history online? I know Kirk made >>> them available on his CD, I have them somewhere. >>> >> >> In a previous private e-mail I received from Kirk, he said: >> The folks at UC >> Berkeley have always required me to track distributions of the >> SCCS >> files as they somehow think of them as still sensitive. >> >> which implies that the SCCS files cannot be released publicly. However, >> the SVN version is a "derivative" of the SCCS files and, on that basis, >> is publicly available. Go figure :) >> > > Here's another data point: when I asked Kirk regarding the public > availability of the SCCS repo he pointed me to http://svnweb.freebsd.org/ > csrg/. > > At https://github.com/dspinellis/unix-history-repo you can find a single > 1GB repository that integrates many of the snapshots and version control > repositories available through TUHS and other sources (including the CSRG > data). Its commit history starts on Jun 20th 1972 with the First Research > Edition and ends with FreeBSD 10 in 2015. Git blame works across all the > history's commits. > > > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Thu Jan 15 03:52:30 2015 From: cowan at ccil.org (cowan at ccil.org) Date: Wed, 14 Jan 2015 12:52:30 -0500 Subject: [TUHS] SVN of CSRG Releases In-Reply-To: References: <20150114011203.GA632@www.oztivo.net> <20150114014256.GB17893@mcvoy.com> <20150114015556.GA3136@www.oztivo.net> <54B656D6.8080907@aueb.gr> Message-ID: Jacob Ritorto scripsit: > Not to over-state the importance of this particular version control > system, but having this code on github is game-changing; thanks, guys. When Github collapses because it can't make money, and there's nowhere to move all 20 million repositories, *that* will be game-changing. ~~ grumble ~~ -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org Wer es in kleinen Dingen mit der Wahrheit nicht ernst nimmt, dem kann man auch in grossen Dingen nicht vertrauen. --Albert Einstein on honesty From jacob.ritorto at gmail.com Thu Jan 15 04:34:09 2015 From: jacob.ritorto at gmail.com (Jacob Ritorto) Date: Wed, 14 Jan 2015 13:34:09 -0500 Subject: [TUHS] SVN of CSRG Releases In-Reply-To: References: <20150114011203.GA632@www.oztivo.net> <20150114014256.GB17893@mcvoy.com> <20150114015556.GA3136@www.oztivo.net> <54B656D6.8080907@aueb.gr> Message-ID: haha, totally +1, but it's soooo easy to broadcast code, garner contribution and collaborate this way that it's almost worth the risk. On Wed, Jan 14, 2015 at 12:52 PM, wrote: > Jacob Ritorto scripsit: > > > Not to over-state the importance of this particular version control > > system, but having this code on github is game-changing; thanks, guys. > > When Github collapses because it can't make money, and there's nowhere > to move all 20 million repositories, *that* will be game-changing. > ~~ grumble ~~ > > -- > John Cowan http://www.ccil.org/~cowan cowan at ccil.org > Wer es in kleinen Dingen mit der Wahrheit nicht ernst nimmt, dem kann > man auch in grossen Dingen nicht vertrauen. --Albert Einstein on honesty > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jacob.ritorto at gmail.com Thu Jan 15 14:32:57 2015 From: jacob.ritorto at gmail.com (Jacob Ritorto) Date: Wed, 14 Jan 2015 23:32:57 -0500 Subject: [TUHS] Less -- was Termcap vs terminfo In-Reply-To: References: <201501110520.t0B5KwvP018801@coolidge.cs.dartmouth.edu> <1421091505.3373070.212956033.39DC72E0@webmail.messagingengine.com> <1421094861.3387032.212981065.1F9F4427@webmail.messagingengine.com> Message-ID: Just noticed that Garrett is doing things to less. Maybe talk to him? http://garrett.damore.org/2014/09/modernizing-less.html ​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tih at hamartun.priv.no Fri Jan 16 18:40:11 2015 From: tih at hamartun.priv.no (Tom Ivar Helbekkmo) Date: Fri, 16 Jan 2015 09:40:11 +0100 Subject: [TUHS] sync; sync; sync; halt (was: Re: Illumos )) In-Reply-To: (Dave Horsfall's message of "Wed, 7 Jan 2015 12:53:46 +1100") References: <20141231062219.GA21046@mcvoy.com> <1420018115.54a3c1c32faaa@www.paradise.net.nz> <20141231131335.GA26926@mercury.ccil.org> <54A4357F.9040703@aueb.gr> <20141231203617.GB3922@mcvoy.com> <20141231224249.GA5833@mcvoy.com> Message-ID: Dave Horsfall writes: > It was drilled into us that the correct usage was: > > # sync > # sync > # sync > > This gives the disk buffers time to actually flush (the writes were merely > scheduled, and were asynchronous). There is another reason why multiple syncs before halting the system were needed. There was no fancy I/O order juggling, so everything was written in the same chronological order as it was scheduled. If you look at 6th edition source code, you'll find that a call to sync would invoke the internal routine update(), which does three things in order: 1: schedule writes of superblocks, and wait for them to complete 2: update in-memory inode time stamps wherever needed 3: schedule writes of inodes and data blocks that are now dirty What this means is that the second sync, by waiting for its own superblock writes, will wait until all the inode and file data flushes scheduled by the first one have completed. What I haven't been able to figure out from a few minutes studying the code, is whether the third sync is really needed, or just a "belt and suspenders" thing. I've heard it claimed that the flushing of inodes and/or file data going on while the second sync is waiting for its already scheduled superblock writes to complete will cause the third one to be needed. That would mean either that flushing dirty file blocks could cause inode updates, or that flushing inodes could cause superblock updates. Anyone know the internals well enough to say? -tih -- Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier" From jnc at mercury.lcs.mit.edu Fri Jan 16 22:33:01 2015 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 16 Jan 2015 07:33:01 -0500 (EST) Subject: [TUHS] sync; sync; sync; halt (was: Re: Illumos )) Message-ID: <20150116123301.A4A9218C099@mercury.lcs.mit.edu> > From: Tom Ivar Helbekkmo > There was no fancy I/O order juggling, so everything was written in the > same chronological order as it was scheduled. > ... > What this means is that the second sync, by waiting for its own > superblock writes, will wait until all the inode and file data flushes > scheduled by the first one have completed. Ah, I'm not sure this is correct. Not all disk drivers handled requests in a 'first-come, first-served' order (i.e. where a request for block X, which was scheduled before a request for block Y, actually happened before the operation on block Y). It all depends on the particular driver; some drivers (e.g. the RP driver) re-organized the waiting request queue to optimize head motion, using a so-called 'elevator algorithm'. (PS: For a good time, do "dd if=/dev/[large_partition] of=/dev/null" on a running system with such a disk, and a lot of users on - the system will apparently come to a screeching halt while the 'up' pass on the disk completes... I found this out the hard way, needless to say! :-) Since the root block is block 1 in the partition, one might think that even with an elevator algorithm, this would tend to guarantee that doing it would more or less guarantee that all other pending operations would have completed (since it could only happen at the end of 'down' pass); _but_ the elevator algorithm is in terms of actual physical block numbers, so blocks in another lower partition might still remain to be written. But now that I think about it a bit, if such blocks existed, that partition's super-block would also need to be written, so when that one completed, the disk queue would be empty. But the point remains - because there's no guarantee of _overall_ disk operation ordering in V6, scheduling a disk request and waiting for it to complete does not guarantee that all previously-requested disk operations will have completed before it does. I really think the whole triple-sync thing is mythology. Look through the V6 documentation and although IIRC there are instructions on how to shut the system down, it's not mentioned. We certainly never used it at MIT (and I still don't), and I've never seen a problem with disk corruption _when the system was deliberately shut down_. Noel From random832 at fastmail.us Fri Jan 16 23:39:06 2015 From: random832 at fastmail.us (random832 at fastmail.us) Date: Fri, 16 Jan 2015 08:39:06 -0500 Subject: [TUHS] sync; sync; sync; halt (was: Re: Illumos )) In-Reply-To: References: <20141231062219.GA21046@mcvoy.com> <1420018115.54a3c1c32faaa@www.paradise.net.nz> <20141231131335.GA26926@mercury.ccil.org> <54A4357F.9040703@aueb.gr> <20141231203617.GB3922@mcvoy.com> <20141231224249.GA5833@mcvoy.com> Message-ID: <1421415546.919096.214748125.23E789CE@webmail.messagingengine.com> On Fri, Jan 16, 2015, at 03:40, Tom Ivar Helbekkmo wrote: > What this means is that the second sync, by waiting for its own > superblock writes, will wait until all the inode and file data flushes > scheduled by the first one have completed. Everything I've read indicates that nothing in the sync call actually waits on anything, and that it's actually just the time taken to type the second and third command on a 110 baud terminal gives the first one time to finish executing. From brantleycoile at me.com Sat Jan 17 00:14:53 2015 From: brantleycoile at me.com (Brantley Coile) Date: Fri, 16 Jan 2015 09:14:53 -0500 Subject: [TUHS] sync; sync; sync; halt (was: Re: Illumos )) In-Reply-To: <1421415546.919096.214748125.23E789CE@webmail.messagingengine.com> References: <20141231062219.GA21046@mcvoy.com> <1420018115.54a3c1c32faaa@www.paradise.net.nz> <20141231131335.GA26926@mercury.ccil.org> <54A4357F.9040703@aueb.gr> <20141231203617.GB3922@mcvoy.com> <20141231224249.GA5833@mcvoy.com> <1421415546.919096.214748125.23E789CE@webmail.messagingengine.com> Message-ID: <4C37916E-48D1-4B6C-9337-581CBC0E948A@me.com> Sixth Edition and 7th Edition are different. Looking at the code, 6th Edition waits on the updates, but 7th Edition delays the writes(bdwrite()) and then calls bflush() when all finished. The three sync’s were indeed to give the disk driver time to do all the IO sitting on the queue. The HP driver used disksort() so those blocks wouldn’t necessarily be written in the order they were touched. We used to use one sync and just watch the disk’s activity light. Brantley South Suite Software On Jan 16, 2015, at 8:39 AM, random832 at fastmail.us wrote: > On Fri, Jan 16, 2015, at 03:40, Tom Ivar Helbekkmo wrote: >> What this means is that the second sync, by waiting for its own >> superblock writes, will wait until all the inode and file data flushes >> scheduled by the first one have completed. > > Everything I've read indicates that nothing in the sync call actually > waits on anything, and that it's actually just the time taken to type > the second and third command on a 110 baud terminal gives the first one > time to finish executing. > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs From tih at hamartun.priv.no Sun Jan 18 07:20:15 2015 From: tih at hamartun.priv.no (Tom Ivar Helbekkmo) Date: Sat, 17 Jan 2015 22:20:15 +0100 Subject: [TUHS] sync; sync; sync; halt In-Reply-To: <20150116123301.A4A9218C099@mercury.lcs.mit.edu> (Noel Chiappa's message of "Fri, 16 Jan 2015 07:33:01 -0500 (EST)") References: <20150116123301.A4A9218C099@mercury.lcs.mit.edu> Message-ID: Noel Chiappa writes: > It all depends on the particular driver; some drivers (e.g. the RP > driver) re-organized the waiting request queue to optimize head > motion, using a so-called 'elevator algorithm'. Ah, yes, now that you point it out, I see the sorting in the RP driver. > I really think the whole triple-sync thing is mythology. It looks that way, yes. The fact that it does a synchronous write of the superblocks at the start of the sync seems to imply that two successive calls should ensure a proper flushing of everything, and may even have been written like that with that effect in mind, but once disk drivers started optimizing I/O ordering, the effect was lost - which might just be why the synchronous superblock write was gone in V7. -tih -- Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"