From steve at quintile.net Mon Jan 1 01:03:49 2018 From: steve at quintile.net (Steve Simon) Date: Sun, 31 Dec 2017 15:03:49 +0000 Subject: [TUHS] Why did PDPs become so popular? In-Reply-To: <456D24C3-022E-4D04-92A4-31496B408E7A@ccc.com> References: <456D24C3-022E-4D04-92A4-31496B408E7A@ccc.com> Message-ID: <40A54DC5-2288-4F0D-A222-BD7EA9E7673E@quintile.net> The Plan9 c Alpha compiler also uses 64bit pointers and 32bit ints. For several years Bell labs kept the port alive, checking builds on real Alpha hardware long after it was no-longer competitive on the basis that “It keeps us honest”. -Steve PS: Gimple’s Llint is a truly wonderful tool, it has saved me from myself many times. > On 31 Dec 2017, at 12:56, Clement T. Cole wrote: > > > >> On Dec 31, 2017, at 12:20 AM, Rudi Blom wrote: >> >> .With the >> Compaq C compiler and HP-UX ANSI C I mostly get pages of warning and a >> few errors. By the time I 'corrected' what I think is relevant some >> nasty coredumps tend to disappear :-) > > I had to chuckle when we read these two lines. As Paul I’m sure also remembers and mentioned about the 32/64 bit issues, when we released Alpha there we very few to zero tools available to help find errors in ISV or customer created C code that was caused by assumptions of size. As you point out with the new ‘Gem’ compilers a great deal of work was spent by Paul and his brothers and sisters in the compiler group putting in just those messages. For C++ it was worse than C because the language was so new at the time few tools for it existed. So one of our engineers, Judy Ward, lead the effort to make the C++ front end be extremely useful and offered extremely good errors and warnings (she also had worked on the C FE before that). > > When people complained about the compiler before no so “noisy” my response was “Listen to Judy’s advise. She’s seeing something you are not and she knows more about C and C++ that all of the rest of us.” > > We discovered a curious thing. The ISVs reported way fewer bugs after the Alpha port because Judy’s messages forced them to clean up long standing issues that were silently causing problem on other systems. I’ve always said Alpha C and C++ compilers was the greatest gift to the Sparc ISVs there was. > > Like you to this day, except for possibly Gimple’s Flexilint product, the old DEC compilers are still the best tools I have ever used to clean up code. > > I’ve reminded and thanked Judy for this many times when I seen her. That was a labor of love by some folks that really cared to make a great product as useful as it could be. > > Clem From paul.winalski at gmail.com Mon Jan 1 01:55:54 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Sun, 31 Dec 2017 10:55:54 -0500 Subject: [TUHS] Why did PDPs become so popular? In-Reply-To: References: <20171229163832.GA17231@mcvoy.com> <091301d3810a$9df2d6b0$d9d88410$@ronnatalie.com> Message-ID: On 12/30/17, Henry Bent wrote: > On 29 December 2017 at 21:30, Paul Winalski > wrote: > > I'm curious about this. As far as I know the development of the released > OS for the Alpha went this way: > (OSF/1 reference) -> (OSF/1 for MIPS) -> OSF/1 V[1.2, 2, 3.0] -> Digital > UNIX [3.2, 4] -> Tru64[5]. Was there ever a branch of this for the VAX? No, you are correct; I was misremembering. I wasn't paying much attention to UNIX at the time. -Paul W. From dave at horsfall.org Mon Jan 1 08:51:57 2018 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 1 Jan 2018 09:51:57 +1100 (EST) Subject: [TUHS] OT: Grace Hopper, Unix epoch, ARPAnet converted to TCP/IP Message-ID: Some interesting historical stuff today... We lost Rear Admiral Dr. Grace Hopper USN (Retd) in 1992; there's not much more than can be said about her, but I will mention that she received (posthumously) the Presidential Medal of Honor in 2016. As every Unix geek knows, today is the anniversary of The Epoch[tm] back in 1970, and at least one nosey web site thinks that that is my birthdate too... And according to my notes, the ARPAnet got converted from NCP to TCP/IP in 1983; do any greybeards here have a more precise date? -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From jnc at mercury.lcs.mit.edu Mon Jan 1 09:10:22 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 31 Dec 2017 18:10:22 -0500 (EST) Subject: [TUHS] OT: Grace Hopper, Unix epoch, ARPAnet converted to TCP/IP Message-ID: <20171231231022.CDC7218C09C@mercury.lcs.mit.edu> > From: Dave Horsfall > the ARPAnet got converted from NCP to TCP/IP in 1983; ... have a more > precise date? No, it was Jan 1. It wasn't so much a 'conversion', as that was the date on which, except for a few sites which got special _temporary_ dispensation to finish their preparations, support for NCP was turned off for most ARPANET hosts. Prior to that date, most hosts on the ARPANET had been running both, and after that, only TCP worked. (Non-ARPANET hosts on the then-nascent Internet had always only been using TCP before that date, of course.) Noel From dave at horsfall.org Mon Jan 1 09:22:02 2018 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 1 Jan 2018 10:22:02 +1100 (EST) Subject: [TUHS] OT: Grace Hopper, Unix epoch, ARPAnet converted to TCP/IP In-Reply-To: <20171231231022.CDC7218C09C@mercury.lcs.mit.edu> References: <20171231231022.CDC7218C09C@mercury.lcs.mit.edu> Message-ID: On Sun, 31 Dec 2017, Noel Chiappa wrote: > > the ARPAnet got converted from NCP to TCP/IP in 1983; ... have a more > > precise date? > > No, it was Jan 1. aneurin% date Mon Jan 1 10:14:58 EST 2018 What timezone did you say you were in again? This is the problem when expressing historical events... > It wasn't so much a 'conversion', as that was the date on which, except > for a few sites which got special _temporary_ dispensation to finish > their preparations, support for NCP was turned off for most ARPANET > hosts. Prior to that date, most hosts on the ARPANET had been running > both, and after that, only TCP worked. (Non-ARPANET hosts on the > then-nascent Internet had always only been using TCP before that date, > of course.) Thanks; I'll amend my notes accordingly. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From khm at sciops.net Mon Jan 1 09:47:28 2018 From: khm at sciops.net (Kurt H Maier) Date: Sun, 31 Dec 2017 15:47:28 -0800 Subject: [TUHS] OT: Grace Hopper, Unix epoch, ARPAnet converted to TCP/IP In-Reply-To: References: <20171231231022.CDC7218C09C@mercury.lcs.mit.edu> Message-ID: <20171231234728.GA6542@wopr> On Mon, Jan 01, 2018 at 10:22:02AM +1100, Dave Horsfall wrote: > On Sun, 31 Dec 2017, Noel Chiappa wrote: > > > > the ARPAnet got converted from NCP to TCP/IP in 1983; ... have a more > > > precise date? > > > > No, it was Jan 1. > > aneurin% date > Mon Jan 1 10:14:58 EST 2018 > > What timezone did you say you were in again? This is the problem when > expressing historical events... I am confident ARPANET did not pin time to AEDT. Even if you go by UTC you've still got about fifteen minutes to wait for 1 JAN 2018. khm From dave at horsfall.org Mon Jan 1 10:15:19 2018 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 1 Jan 2018 11:15:19 +1100 (EST) Subject: [TUHS] OT: Grace Hopper, Unix epoch, ARPAnet converted to TCP/IP In-Reply-To: <20171231234728.GA6542@wopr> References: <20171231231022.CDC7218C09C@mercury.lcs.mit.edu> <20171231234728.GA6542@wopr> Message-ID: On Sun, 31 Dec 2017, Kurt H Maier wrote: > I am confident ARPANET did not pin time to AEDT. Even if you go by UTC > you've still got about fifteen minutes to wait for 1 JAN 2018. So am I, but what reference *am* I supposed to use, FFS? The USA is several zones behind UTC[*], and almost a whole day behind Australia (where I live). My "on this day" policy is to use the local time if it can be narrowed to a particular zone where the event happened (and if it makes sense); if it was universal e.g. moon landings then I'll use UTC; otherwise I'll use the commonly-observed date e.g. the start/end of the world wars. I'm open to suggestions (including FOAD, in which case I'll simply find something better to do). [*] A lingering gripe that explains my latent anti-Americanism goes back to when I had to support Uniplus 2.2/2.4 (sorta SysIII-ish) on the WICAT boxes in here in Australia. At installation time, we had to express the time offset as hours *west* of GMT; this left me with a lingering belief that Americans didn't want to be perceived as being backwards (yeah. it saved an entire keystroke out of the dozens that were otherwise required). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From khm at sciops.net Mon Jan 1 10:59:07 2018 From: khm at sciops.net (Kurt H Maier) Date: Sun, 31 Dec 2017 16:59:07 -0800 Subject: [TUHS] OT: Grace Hopper, Unix epoch, ARPAnet converted to TCP/IP In-Reply-To: References: <20171231231022.CDC7218C09C@mercury.lcs.mit.edu> <20171231234728.GA6542@wopr> Message-ID: <20180101005907.GB6542@wopr> On Mon, Jan 01, 2018 at 11:15:19AM +1100, Dave Horsfall wrote: > > My "on this day" policy is to use the local time if it can be narrowed to > a particular zone where the event happened (and if it makes sense); if it > was universal e.g. moon landings then I'll use UTC; otherwise I'll use the > commonly-observed date e.g. the start/end of the world wars. I support your policy, but I'd say the ARPA in ARPANET makes it at least feasible to stick with Zulu time for related milestones. > I'm open to suggestions (including FOAD, in which case I'll simply find > something better to do). Personally, I've enjoyed your posts marking anniversaries of these events. > A lingering gripe that explains my latent anti-Americanism goes back to The older I get, the more convinced I am that the "two hard things in Computer Science" quote came from someone who never had to accurately report the ages of events predating epoch time. And I can say as a patriotic American, I did not truly understand the desperate plight of being a foreigner until I was in Cape Town during the Super Bowl. After that I limited international travel to extremely profitable endeavors; otherwise the ROI just isn't there. khm From ron at ronnatalie.com Mon Jan 1 21:59:50 2018 From: ron at ronnatalie.com (Ron Natalie) Date: Mon, 1 Jan 2018 06:59:50 -0500 Subject: [TUHS] , ARPAnet converted to TCP/IP Message-ID: <09f101d382f8$077d0350$167709f0$@ronnatalie.com> It was sort of a soft change over. All the did on January 1, 1983, is disable link 0 on the IMPs. This essentially blocked NCP from working anymore. You could (and many of us were) run IP on the Arpanet for years before that. In fact the weeks before we were getting ready for the change and we had our TCP/IP version of the system up. It crashed. We rebooted it and set about debugging it. It crashed again. Immediately my phone rang. It was Louis Mamakos, then of the University of Maryland. He had tried to ping our system. I called out the information to Mike Muuss who was across the desk from me. We set to find the bug. It turned out that the ICMP echo handling in the 4.1c (I believe this was the version) that we'd cribbed our PDP-11/70 TCP from had a bug where it used the incoming message to make the outgoing one, AND it freed it, eventually causing a double free and crash. It was at this point we realized that BSD didn't have a ping client program. Mike set out to write one. It oddly became the one piece of software he was most known for over the years. The previous changeover was to long leaders on the Arpanet (Jan 1, 1981?). This changed the IMP addressing space from eight bits (6 bits for imp number, 2 for a host on imp) to 16 bits for imp number and 8 for a host on imp. While long leaders were available on a port basis for years earlier, they didn't force the change until this date. The one casualty we had a PDP-11/40 playing terminal server running software out of the University of Illinois called "ANTS." Amusingly the normal DEC purple and red logo panels at the top of the rack were silkscreened with orange ANTS logos (with little ants crawling on it). The ANTS wasn't maintained anymore and stuck in short-leader mode. We used that option to replace that machine with a UNIX (we grabbed one of our ubiquitous PDP-11/34's that were kicking around). I kept the racks and the ANTS logo for the BRL Gateways. I turned in the non-MM PDP-11/40. A year later I get a call from the military supply people. ME: Yes? GUY: I need you to identify $65,000 of computer equipment you turned in. ME: What $65,000 machine? GUY: One PDP-11/40 and accessories. ME: That computer is 12 years old... and I kept all the racks and peripherals. Do you know how much a 12-year-old computer is worth? The other major cut over was in October of 1984. This was the Arpanet-Milnet split. I had begged the powers that be NOT to do the change over on the Jan 1st as it always meant I had to be working the days leading up to it. (Oct 1 was the beginning of the "fiscal" year). Our site had problems. I made a quick call to Mike Brescia of BBN. This was pre-EGP, and things were primarily static routed in those days. He'd forgotten that we had routers at BRL now on the MILNET (all the others were on the ARPANET) and the ARPANET-MILNET "mail bridge" routers had been configured for gateways on the MILNET side. From jnc at mercury.lcs.mit.edu Mon Jan 1 22:59:43 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 1 Jan 2018 07:59:43 -0500 (EST) Subject: [TUHS] OT: Grace Hopper, Unix epoch, ARPAnet converted to TCP/IP Message-ID: <20180101125943.429CE18C0A0@mercury.lcs.mit.edu> > From: Dave Horsfall > What timezone did you say you were in again? Ah; didn't realize you wanted the exact time, not just a date! :-) Well, according to this: http://www.rfc-editor.org/rfc/museum/ddn-news/ddn-news.n19.1 it was _planned_ to happen at "00:01 (EST) 1 Jan 1983". Whether it did happen at that moment, or if in reality there was some variance, I don't know (IIRC, I was off sailing in the Caribbean when it actually happened :-). Noel From ron at ronnatalie.com Tue Jan 2 10:57:20 2018 From: ron at ronnatalie.com (Ron Natalie) Date: Mon, 1 Jan 2018 19:57:20 -0500 Subject: [TUHS] OT: Grace Hopper, Unix epoch, ARPAnet converted to TCP/IP In-Reply-To: <20180101125943.429CE18C0A0@mercury.lcs.mit.edu> References: <20180101125943.429CE18C0A0@mercury.lcs.mit.edu> Message-ID: <0a4701d38364$a4f7fc40$eee7f4c0$@ronnatalie.com> Heidi Heiden...now there's a name I've not heard in many a year, Noel. I don't know if it got shut off right at midnight on Jan 1, but it certainly was pretty close to that time. Oddly enough as time went on we started to get link 0 messages again. We didn't have anything set up to process them, but we did print a message when it happened. From clemc at ccc.com Wed Jan 3 02:19:03 2018 From: clemc at ccc.com (Clem Cole) Date: Tue, 2 Jan 2018 11:19:03 -0500 Subject: [TUHS] OT: Grace Hopper, Unix epoch, ARPAnet converted to TCP/IP In-Reply-To: <20180101125943.429CE18C0A0@mercury.lcs.mit.edu> References: <20180101125943.429CE18C0A0@mercury.lcs.mit.edu> Message-ID: On Mon, Jan 1, 2018 at 7:59 AM, Noel Chiappa wrote: > it was _planned_ to happen at "00:01 (EST) 1 Jan 1983". Whether it did > happen > at that moment, or if in reality there was some variance, I don't know ​I don't remember it as being a huge event. As Noel said most people had cut over to TCP by then​. People were much more spooked by Y2K a few years later. Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Jan 3 02:43:59 2018 From: clemc at ccc.com (Clem Cole) Date: Tue, 2 Jan 2018 11:43:59 -0500 Subject: [TUHS] OT: American Culture Message-ID: On Sun, Dec 31, 2017 at 7:15 PM, Dave Horsfall wrote: > > A lingering gripe that explains my latent anti-Americanism goes back to > when I had to support Uniplus 2.2/2.4 (sorta SysIII-ish) on the WICAT boxes > in here in Australia. At installation time, we had to express the time > offset as hours *west* of GMT; this left me with a lingering belief that > Americans didn't want to be perceived as being backwards (yeah. it saved an > entire keystroke out of the dozens that were otherwise required). ​Dave I'm not so sure it's about being perceived as forward or backwards - its just shallow, provincial and often lazy because the program did not really knowing any better. The problem is too many American', (particularly younger ones that experience our 'excellent' educational system), have often never travelled that much and experiences other places, cultures or social norms. I admit this is extreme example, but about 8 years ago, my daughter had a friend, who was approx 16 at the time, that we took to the big city (Boston) to play in a orchestra concert at Symphony Hall when they both were named 'All State' for the instruments. I don't remember why said friends family did not/could not come - but it made sense and we said we would take her with us. On the drive in-town, we were talking with her and I discovered that she had never gone to Boston before ... ever -- she was excited to see it (we live less than 1hr North mind you. Note quite the boon-docks). She had not gone to a 'Bo Sox' game or anything. Never went to the Science Museum, etc. She grew up in her town (mind you happy) and using TV as her window to world. Which brings me to >>my complaint<<. We, as American's, project so much about 'us' via TV. The said truth is most Americans are not like what they see on TV [e.g. Rice-A-Roni is made up!!, Benihana's is an American invention, and "the big yellow school bus" is dirty/noisy and usually without seat belts]. Sadly, many Americans do not know any better - queue the famous quote about never under-estimating the taste of the American public. But think about what folks outside the US see and think? Many of my European friends in particular all want to visit NYC. [I tell them all, visit Boston or Philadelphia first if you can. Those cities are much more representative of America then LA, NYC or Dallas; if for no other reason they are more 'European' in feel]. When I run into things like what you just described (and I seem to run into then most often with MicroSoft based tools), I think to myself, it must have been a cold day in Redmond, WA and some programmer did not want to make an effort to do make her/his solution really general ;-) Clem FWIW: Not only did we take my kids all over the world as children, we brought the world to them by sponsoring kids from all sorts of countries. But I fear, my wife and I are less the norm then I would wish. ᐧ ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Wed Jan 3 12:42:53 2018 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Tue, 02 Jan 2018 21:42:53 -0500 Subject: [TUHS] OT: American Culture Message-ID: <201801030242.w032grt0022600@coolidge.cs.Dartmouth.EDU> > A lingering gripe that explains my latent anti-Americanism goes back to > when I had to support Uniplus 2.2/2.4 (sorta SysIII-ish) on the WICAT boxes > in here in Australia. At installation time, we had to express the time > offset as hours *west* of GMT; this left me with a lingering belief that > Americans didn't want to be perceived as being backwards (yeah. it saved an > entire keystroke out of the dozens that were otherwise required). But east postive is an artifact of north up. I remember Australian souvenir shops selling maps on "MacQuarrie's corrective projection", in which south is up. In fact this orientation was not uncommon in Europe between medieval maps that really were oriented, with east up, and later convention that put north up and shoved Australia down under. Surely an Aussie would prefer south up and west positive! Doug From akosela at andykosela.com Wed Jan 3 17:53:56 2018 From: akosela at andykosela.com (Andy Kosela) Date: Wed, 3 Jan 2018 01:53:56 -0600 Subject: [TUHS] OT: critical Intel design flaw Message-ID: http://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/ Including here as it concerns Unix kernel and leaking memory from kernel space to userland. This is big -- it appears this is a fundamental Intel bug that exists in all x86_64 CPUs. It will be interesting to watch the ramifications and impact of this on the industry as a whole. --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Wed Jan 3 21:57:20 2018 From: ron at ronnatalie.com (Ron Natalie) Date: Wed, 3 Jan 2018 06:57:20 -0500 Subject: [TUHS] OT: critical Intel design flaw In-Reply-To: References: Message-ID: <0b2201d3848a$02ba8d90$082fa8b0$@ronnatalie.com> I think it’s much ado about nothing. In fact, nearly the same bug cropped up in the 386 and we had to hack around it in UNIX then (in the 32 bit pentiums you can use one of the segment registers to provide a second layer of security over paging. Alas, this doesn’t work on the 64 bit addressing mode). From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Andy Kosela Sent: Wednesday, January 3, 2018 2:54 AM To: The Eunuchs Hysterical Society Subject: [TUHS] OT: critical Intel design flaw http://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/ Including here as it concerns Unix kernel and leaking memory from kernel space to userland. This is big -- it appears this is a fundamental Intel bug that exists in all x86_64 CPUs. It will be interesting to watch the ramifications and impact of this on the industry as a whole. --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Wed Jan 3 23:25:05 2018 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 03 Jan 2018 06:25:05 -0700 Subject: [TUHS] OT: American Culture In-Reply-To: References: Message-ID: <201801031325.w03DP567014114@freefriends.org> Yes, this really is OT ... > The problem is too many American', > (particularly younger ones that experience our 'excellent' educational > system), have often never travelled that much and experiences other places, > cultures or social norms. This is very true. I discovered this when, at the age of 18, I came to spend a year studying in Israel. At that point I realized that Americans are terribly parochial. ("Whaddaya mean you don't speak English?!? Whaddaya mean I can't get a hmaburger here?" etc.) > Which brings me to >>my complaint<<. We, as American's, project so much > about 'us' via TV. The said truth is most Americans are not like what they > see on TV It's worse than just TV (and movies). It's huge parts of the culture. We moved to Israel 20 years ago, and on the highways are signs for: Ace Hardware, Toys 'R' Us, Office Depot, McDonald's ... UPS and FedEx trucks are common sights. As well as the culture, many of the values (that I personally moved to Israel to get away from) have seeped in as well. "Cultural Pollution" wouldn't be too strong a term. > When I run into things like what you just described (and I seem to run into > then most often with MicroSoft based tools), I think to myself, it must > have been a cold day in Redmond, WA and some programmer did not want to > make an effort to do make her/his solution really general ;-) I suspect that said programmer didn't even know enough to think about making it general. FWIW, Arnold From jnc at mercury.lcs.mit.edu Wed Jan 3 23:43:58 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 3 Jan 2018 08:43:58 -0500 (EST) Subject: [TUHS] OT: critical Intel design flaw Message-ID: <20180103134358.3F16818C098@mercury.lcs.mit.edu> > From: Andy Kosela > it appears this is a fundamental Intel bug that exists in all x86_64 > CPUs. I'm highly amused by the irony. Intel throws bazillions of transistors at these hyper-complex CPUs in an attempt to make them as fast as possible - and (probably because of the complexity) missed a bug, the fix for which involves... slowing things way down! I wonder how many other bugs are lurking in these hyper-complex designs? Didn't anyone at Intel stop to think that complexity is bad, in and of itself? But I guess the market demands for faster and faster machines outweighed that - until it bit them in the posterior. The real question is 'how many more times will it have to happen before they get a clue'? There's an interesting parallel between this, and uSloth's struggle with security and bugs. For a long time, it seemed it was more important to the market to add features (i.e. complexity), and security be damned - until poor security really started to become an issue. So now they're trying to catch up - but seemingly still haven't got there, in terms of the fundamental architecture of the OS, as the never-ending stream of bug patches attests. The sad thing is that how to provide good security (not perfect, but much, much better than what we have) was worked out a long time ago, and Intel hired Roger Schell to add the necessary hardware underpinnings when they did the 386: http://conservancy.umn.edu/bitstream/11299/133439/1/oh405rrs.pdf Mutatis mutandis. Noel From random832 at fastmail.com Thu Jan 4 00:19:01 2018 From: random832 at fastmail.com (Random832) Date: Wed, 03 Jan 2018 09:19:01 -0500 Subject: [TUHS] OT: American Culture In-Reply-To: <201801030242.w032grt0022600@coolidge.cs.Dartmouth.EDU> References: <201801030242.w032grt0022600@coolidge.cs.Dartmouth.EDU> Message-ID: <1514989141.883521.1222880744.6EE78710@webmail.messagingengine.com> On Tue, Jan 2, 2018, at 21:42, Doug McIlroy wrote: > > A lingering gripe that explains my latent anti-Americanism goes back to > > when I had to support Uniplus 2.2/2.4 (sorta SysIII-ish) on the WICAT boxes > > in here in Australia. At installation time, we had to express the time > > offset as hours *west* of GMT; this left me with a lingering belief that > > Americans didn't want to be perceived as being backwards (yeah. it saved an > > entire keystroke out of the dozens that were otherwise required). > > But east postive is an artifact of north up. Who says right is positive? Anyway, there's a natural reason to want east to be positive in this case completely independent of maps - so that your timezone offset is the number that you add to UTC to get the current local time, rather than subtracting. Incidentally, the V6 code for ctime has the number of *seconds* west of UTC as an *int* - a situation rather worse for parts of Australia than simply requiring a negative number. I'm not exactly sure what AUSAM does. The archive shows ctime.s (its own implementation) with "timezone" as zero, with a note saying to set it to 1*60.*60. for daylight saving. This suggests that the time was simply maintained with an epoch of 1970-01-01 00:00 AEST, but the time(II) manpage says GMT. From random832 at fastmail.com Thu Jan 4 00:22:23 2018 From: random832 at fastmail.com (Random832) Date: Wed, 03 Jan 2018 09:22:23 -0500 Subject: [TUHS] OT: critical Intel design flaw In-Reply-To: <0b2201d3848a$02ba8d90$082fa8b0$@ronnatalie.com> References: <0b2201d3848a$02ba8d90$082fa8b0$@ronnatalie.com> Message-ID: <1514989343.884423.1222903600.4579DCEA@webmail.messagingengine.com> On Wed, Jan 3, 2018, at 06:57, Ron Natalie wrote: > I think it’s much ado about nothing. In fact, nearly the same bug > cropped up in the 386 and we had to hack around it in UNIX then (in the > 32 bit pentiums you can use one of the segment registers to provide a > second layer of security over paging. Alas, this doesn’t work on the > 64 bit addressing mode). To my understanding, what's leaking is the addresses (and possibly physical addresses), which are in turn usable in a "rowhammer"-style attack - something that didn't exist (or wasn't known, anyway) in the 386 era. From clemc at ccc.com Thu Jan 4 00:26:40 2018 From: clemc at ccc.com (Clem Cole) Date: Wed, 3 Jan 2018 09:26:40 -0500 Subject: [TUHS] OT: critical Intel design flaw In-Reply-To: <20180103134358.3F16818C098@mercury.lcs.mit.edu> References: <20180103134358.3F16818C098@mercury.lcs.mit.edu> Message-ID: below.. On Wed, Jan 3, 2018 at 8:43 AM, Noel Chiappa wrote: > > I'm highly amused by the irony. Intel throws bazillions of transistors at > these hyper-complex CPUs in an attempt to make them as fast as possible - > and > (probably because of the complexity) missed a bug, the fix for which > involves... slowing things way down! > ​+1 however... I think there is a corollary ​ > > I wonder how many other bugs are lurking in these hyper-complex designs? > Didn't anyone at Intel stop to think that complexity is bad, in and of > itself? > ​Exactly....​ ​ and a loud "Amen Brother Chiappa​ ." ​ IIRC this is part of the argument Dykstra made with the THE paper years ago, Parnas in his information hiding paper -- i.e. why microkernels and proper layering are a good idea. Keep is simple and do one thing well/protect yourself against other subsystems not being 100%. Linux and Winders are are bad a the processor. ​Yup microkernels are a tad slower and have more overhead, and might (probably will) cost a little more. But I really do think simplicity beats complexity and I'll pay a bit in over head to keep it simple. The problem of course for my employers over the years, is that many people (most ​people ​ probably) ​ ​ do not think me ​ and follow their wallet on the fastest for the cheapest​ ;-) Clem​ ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman at oclsc.org Thu Jan 4 03:06:15 2018 From: norman at oclsc.org (Norman Wilson) Date: Wed, 03 Jan 2018 12:06:15 -0500 Subject: [TUHS] OT: critical Intel design flaw Message-ID: <1514999178.27517.for-standards-violators@oclsc.org> Clem Cole: IIRC this is part of the argument Dykstra made with the THE paper years ago, Parnas in his information hiding paper -- i.e. why microkernels and proper layering are a good idea. Keep is simple and do one thing well/protect yourself against other subsystems not being 100%. ===== Indeed. Complexity creates needless RISC, er, risk. Norman Wilson Toronto ON From bakul at bitblocks.com Thu Jan 4 03:07:41 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Wed, 3 Jan 2018 09:07:41 -0800 Subject: [TUHS] OT: critical Intel design flaw In-Reply-To: <20180103134358.3F16818C098@mercury.lcs.mit.edu> References: <20180103134358.3F16818C098@mercury.lcs.mit.edu> Message-ID: <51CA1A1A-F9AE-4A20-A431-4BF904DAA04D@bitblocks.com> On Jan 3, 2018, at 5:43 AM, Noel Chiappa wrote: > > I'm highly amused by the irony. Intel throws bazillions of transistors at > these hyper-complex CPUs in an attempt to make them as fast as possible - and > (probably because of the complexity) missed a bug, the fix for which > involves... slowing things way down! This bug appears to be the result of taking a shortcut rather than complexity. I suspect this shortcut was taken consciously, not realizing it could be misused. And the "Rowhammer" problem is certainly not due to complexity but (again) playing close to the edge -- the cell geometry is too small to not fail! > I wonder how many other bugs are lurking in these hyper-complex designs? > Didn't anyone at Intel stop to think that complexity is bad, in and of itself? They did try a newer architecture (itanium) but the market rejected it. The same reason we still continue to use buffer overflow inducing languages. Inertia & the cost of change. > http://conservancy.umn.edu/bitstream/11299/133439/1/oh405rrs.pdf This was a fascinating read! Thanks for the reference. From bakul at bitblocks.com Thu Jan 4 03:28:40 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Wed, 3 Jan 2018 09:28:40 -0800 Subject: [TUHS] OT: critical Intel design flaw In-Reply-To: References: <20180103134358.3F16818C098@mercury.lcs.mit.edu> Message-ID: On Jan 3, 2018, at 6:26 AM, Clem Cole wrote: > > ​Yup microkernels are a tad slower and have more overhead, and might (probably will) cost a little more. But I really do think simplicity beats complexity and I'll pay a bit in over head to keep it simple. This slowdown (which is not much -- L4 shows it is about 5% or so) is more due to h/w security architecture that has not evolved for decades. None of the microkernel research has had any influence on x86/ARM etc. Look at how Mill solves the problem. A protection domain switch (a portal call) takes two extra fetches. Second, I think the protection ring idea was counterproductive. It allowed people to be lazy and stuff all sorts of things in the kernel. From rminnich at gmail.com Thu Jan 4 03:46:03 2018 From: rminnich at gmail.com (ron minnich) Date: Wed, 03 Jan 2018 17:46:03 +0000 Subject: [TUHS] OT: critical Intel design flaw In-Reply-To: References: <20180103134358.3F16818C098@mercury.lcs.mit.edu> Message-ID: The type of kernel is orthogonal to this particular design flaw from what I know. It's about how page tables are set up for user mode processes. I may be wrong but pretty much every Unix or Unix-like kernel (including Plan 9) follows the page table model Windows and Linux use: the ring 0 PTEs are present in the page table, even in user mode, and we count on the architecture to prevent ring 3 access to ring 0 memory. This is certainly the case on all the ones I've worked on. I don't think a microkernel would save you. This is not a much ado about nothing case: it's early days and people can make it work: https://twitter.com/brainsmoke/status/948561799875502080 -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Jan 4 04:27:19 2018 From: clemc at ccc.com (Clem Cole) Date: Wed, 3 Jan 2018 13:27:19 -0500 Subject: [TUHS] OT: critical Intel design flaw In-Reply-To: References: <20180103134358.3F16818C098@mercury.lcs.mit.edu> Message-ID: On Wed, Jan 3, 2018 at 12:28 PM, Bakul Shah wrote: > This slowdown (which is not much -- L4 shows it is about 5% or so) > ​I agree. We came to the same conclusion in the early/mid 1990's with Mach and Chorus. In fact, the UI 'requirements for modern OS' document (which is part of why AT&T got behind Chorus for the never completed SVR5/R6 stuff - I'll see if I can find a copy) was based on that work. The OS weenies at the time felt that the cost was low enough and hardware cheap enough that of course kernels would be the way to go. AT&T Research has switched to Plan9 and the like, again going 'small and light' as opposed to monolithic and bigger (BSD, Tru64, Solaris, etc). Similarly, Microsoft since Windows (not OS/2) was the UI for NT in the end; Microsoft had to put hacks into the make user code word and NT became a hybrid (like Mach 2.x) and never pushed the pure kernel that Mica (NT's origin had been). To do so would have broken code which at the time was something they were loath to do. Similarly with Apple, when they switched to Next and the Mach family they could have become more 'pure.' Quickly it became a game of 'speed' and the Mach 3.0/4.0 was never fast (or small enough). To their credit, with OSF/RI trying to make a true uK, UI tried to counter with Chorus, but by this time, Solaris was the 'UNIX of Choice' for the AT&T world - which was being driven on high-end/high margin systems. Plus Mach 3.0 was never 'micro.' None of the production Mach folks ever switched to it, because they did not want to pay the performance penalty and we are users never pushed them. Plus, by that time the 386 had become the driver to the community as a whole (certainly the low end/entry systems) and then AT&T suite blew up UNIX in general with the law suite; and Linux came on the scene as the savior. Linus's ​distain for microkernels was understood, but frankly I think has hurt as if a uKernel based FOSS UNIX had been the leader; I wonder if we would still be in the mess we are in. I have personally hoped that something like L4/seL4 with a clean UNIX/Plan9-ish style upper layer might some day be the thing that really wins. Maybe be written in something else - Rust/Go/Kotlin whatever ... But I suspect that will happen long after I'm gone. We keep reinventing the great work Ken, Dennis and Team did years ago and sadly not really doing a good job of learning from our mistakes. Linux (nor Windows) is/are hardly a small, simple system these days. The fact that AMD, Intel *et. al.* optimize the hardware is clearly traditional sustaining engineering right out Christensen's book. The hope is a new disruptive market -- as you say. Maybe Arm/Cell phones will be that. I would not bet against them, but then again. IBM/Intel *et al *have a history of recovering. It is going to be interesting to both watch and play the game for the next few years -- UNIX is hardly dead nor traditional complex systems that run on them, nor the HW that delivers it :-) All that said - the idea is that this HW error we could limit the damage a bit but removing some of the complexity. Their still an open question, if the VM was in a server process, would we completely be free of the error. As I understand it, not completely; but I think the damage/risk/fix would be smaller and easier - which is my primary point. Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at bitblocks.com Thu Jan 4 04:28:25 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Wed, 3 Jan 2018 10:28:25 -0800 Subject: [TUHS] OT: critical Intel design flaw In-Reply-To: References: <20180103134358.3F16818C098@mercury.lcs.mit.edu> Message-ID: <483D45E8-9F95-4A8E-8F19-05D1CF1F7FEF@bitblocks.com> On Jan 3, 2018, at 9:46 AM, ron minnich wrote: > > The type of kernel is orthogonal to this particular design flaw from what I know. It's about how page tables are set up for user mode processes. I may be wrong but pretty much every Unix or Unix-like kernel (including Plan 9) follows the page table model Windows and Linux use: the ring 0 PTEs are present in the page table, even in user mode, and we count on the architecture to prevent ring 3 access to ring 0 memory. This is certainly the case on all the ones I've worked on. > > I don't think a microkernel would save you. My point was simply that in a ukernel this arrangement doesn't buy you much as the real "OS" is just another user level process. The ukernel is basically just a message router. In Mill the message routing itself is done in h/w (well, a portal call is more like a call to a different protection domain in the same thread so no need for marshalling/unmarshalling arguments). From nobozo at gmail.com Thu Jan 4 04:39:06 2018 From: nobozo at gmail.com (Forrest, Jon) Date: Wed, 3 Jan 2018 10:39:06 -0800 Subject: [TUHS] OT: critical Intel design flaw In-Reply-To: References: <20180103134358.3F16818C098@mercury.lcs.mit.edu> Message-ID: It will be interesting to see if RISC-V suffers from this. If not, that might be just the ticket they were looking for to gain (more) mainstream acceptance. Jon From rminnich at gmail.com Thu Jan 4 04:50:42 2018 From: rminnich at gmail.com (ron minnich) Date: Wed, 03 Jan 2018 18:50:42 +0000 Subject: [TUHS] OT: critical Intel design flaw In-Reply-To: References: <20180103134358.3F16818C098@mercury.lcs.mit.edu> Message-ID: it's implementation dependent, not architecture dependent. RISC-V implementations I've seen don't do the kind of speculation that brought intel to grief. On Wed, Jan 3, 2018 at 10:39 AM Forrest, Jon wrote: > > It will be interesting to see if RISC-V suffers from this. If not, > that might be just the ticket they were looking for to gain (more) > mainstream acceptance. > > Jon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Thu Jan 4 05:56:59 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Wed, 3 Jan 2018 14:56:59 -0500 Subject: [TUHS] OT: critical Intel design flaw In-Reply-To: References: <20180103134358.3F16818C098@mercury.lcs.mit.edu> Message-ID: On 1/3/18, Clem Cole wrote: > On Wed, Jan 3, 2018 at 12:28 PM, Bakul Shah wrote: > > Similarly, Microsoft since Windows (not OS/2) was the UI for NT in the end; > Microsoft had to put hacks into the make user code work and NT became a > hybrid (like Mach 2.x) and never pushed the pure kernel that Mica (NT's > origin had been). To do so would have broken code which at the time was > something they were loath to do. Microsoft's developers had a "hook and hack" mentality with regard to the OS. This goes back to the days of DOS, when once your application started, you could do anything you pleased, as long as you put the OS kernel back to its clean state before you exited. Dave Cutler fought tooth and nail against any attempts to insert hooks in the NT microkernel, or to muddle the layered design. But after Dave left day-to-day NT development, things got muddied up. -Paul W. From bakul at bitblocks.com Thu Jan 4 06:24:40 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Wed, 3 Jan 2018 12:24:40 -0800 Subject: [TUHS] OT: critical Intel design flaw In-Reply-To: References: <20180103134358.3F16818C098@mercury.lcs.mit.edu> Message-ID: On Jan 3, 2018, at 10:27 AM, Clem Cole wrote: > > I have personally hoped that something like L4/seL4 with a clean UNIX/Plan9-ish style upper layer might some day be the thing that really wins. Maybe be written in something else - Rust/Go/Kotlin whatever ... But I suspect that will happen long after I'm gone. It may be sooner than you think. Now it is much harder to produce faster processors than to produce processors with larger and larger number of cores. For most tasks not *all* of these cores have to work in tandem -- more likely you will run a set of loosely coupled diverse tasks on such a machine. In this scenario it is not clear to me that centralized OSes like like unix/windows can use these cores efficiently. Not even plan9 will do well. In the "cloud" we have already given up on such centralization (though present solutions seem clunky and inefficient). IMHO what we need a much more composable architecture. In Barrelfish, a research OS based on L4, each core has its own ukernel that can be independently brought up. This may be a direction worth exploring[1]. If done right + an orchestration protocol can provide the basis for clean, secure, scalable and resilient distributed systems. > We keep reinventing the great work Ken, Dennis and Team did years ago and sadly not really doing a good job of learning from our mistakes. a) Actually we don't reinvent their work -- we just keep fiddling at the edges! b) IMHO their work is better thought of as a compositional architecture or service protocol. That is, in a ukernel arch., different user processes can implement different Unix "system call" protocols. There is no reason to stuff all that in a single "kernel". This model actually fits in with what you said (L4/seL4 with a clean UNIX/Plan9-ish style upper layer). [1] My real bias is that even ukernels shouldn't exist! That is, the very core OS function of thread and protection switch should be done in h/w via a few instructions. The *policy* of this is implemented in s/w. Then an OS is just a (set of) shared libraries and a set of initial services. Thinking this way, it is clear that a ukernel is merely implementing this model in s/w and it makes perfect sense for each core to have its own emulation layer! None of above has anything to do with the "intel design flow". From norman at oclsc.org Thu Jan 4 08:49:31 2018 From: norman at oclsc.org (Norman Wilson) Date: Wed, 03 Jan 2018 17:49:31 -0500 Subject: [TUHS] OT: American Culture Message-ID: <1515019775.7311.for-standards-violators@oclsc.org> Random832 (a good year for randomness, that): Who says right is positive? ===== Good question. Norman Wilson Toronto ON Left-handed From tytso at mit.edu Thu Jan 4 09:40:25 2018 From: tytso at mit.edu (Theodore Ts'o) Date: Wed, 3 Jan 2018 18:40:25 -0500 Subject: [TUHS] OT: critical Intel design flaw In-Reply-To: References: <20180103134358.3F16818C098@mercury.lcs.mit.edu> Message-ID: <20180103234025.GA23371@thunk.org> On Wed, Jan 03, 2018 at 01:27:19PM -0500, Clem Cole wrote: > > This slowdown (which is not much -- L4 shows it is about 5% or so) > > > ​I agree. We came to the same conclusion in the early/mid 1990's with > Mach and Chorus. In fact, the UI 'requirements for modern OS' document > (which is part of why AT&T got behind Chorus for the never completed > SVR5/R6 stuff - I'll see if I can find a copy) was based on that work. > > The OS weenies at the time felt that the cost was low enough and hardware > cheap enough that of course kernels would be the way to go. It's possible to keep the slowdown at 5%, but how much extra engineering work does it take to get the performance gap down to that level? And during that time while the micro kernel team is playing catchup, if the OS with the monolithic kernel adds new features to the OS, how much additional time does it take to add those features to the OS? (Regardless of whether the features are implemented in userspace, or in the kernel, or some combination of the two.) > Similarly, Microsoft since Windows (not OS/2) was the UI for NT in the end; > Microsoft had to put hacks into the make user code word and NT became a > hybrid (like Mach 2.x) and never pushed the pure kernel that Mica (NT's > origin had been). To do so would have broken code which at the time was > something they were loath to do. Actually, at least part of the problem was that graphics performance was *terrible*. So in NT 4.0 they moved it into the kernel for performance reasons. One could argue that with enough effort, the graphics performance perhaps could have been improved while keeping within the microkernel design principles. But in the commercial marketplace, timing is everything; and even being six months late to the game can be enough to lose the battle for mindshare. (There are those who have argued that the *BSD's were delayed by around six months due to the AT&T / Berkeley lawsuit, and if it were but for that, Linux would not have gained the prominence that it had/has. I'm not completely sure I buy that; there were *BSD developers in the Boston area, and it was primarily because of a certain toxic personality that they failed to lure me to the *BSD side of the force --- and I got my start working kernels with BSD 4.3+ at MIT Project Athena. Despite how people like to complain about Linus's shortcomings in that department, let's just say that IMHO there are *far* worse personalities in the open source OS world, and leave it at that.) > The hope is a new disruptive market -- as you say. Maybe Arm/Cell phones > will be that. I would not bet against them, but then again. IBM/Intel *et > al *have a history of recovering. It is going to be interesting to both > watch and play the game for the next few years -- UNIX is hardly dead nor > traditional complex systems that run on them, nor the HW that delivers it > :-) Well, Fuchsia is based on a microkernel, and one interesting thing about it is that full POSIX compatibility is *not* a goal. The team is apparently not worried about legacy support (where they consider Linux and Unix "legacy") and performance on HDD's is also a legacy issue. (It's the 21st century, except for big data centers at Google, Facebook, Microsoft, et. al, who uses disk drives in this day and age?) There will be rough POSIX compatibility, but it is refreshing that they don't consider horrendous design decisions (e.g., such as telldir and seekdir) things that they are bound to support. Of course this means no X11, no GNOME, no KDE, etc. (And because there is no telldir/seekdir, no Samba support, either. Oh, well. Who needs to serve CIFS, anyway?) All graphical applications that want to run on Fuchsia have to be rewritten to use graphics SDK called "Flutter". It'll be interesting to see what happens with this approach, and whether it can supplant the Linux/Unix ecosystem. - Ted From lm at mcvoy.com Thu Jan 4 10:51:03 2018 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 3 Jan 2018 16:51:03 -0800 Subject: [TUHS] OT: critical Intel design flaw In-Reply-To: <20180103234025.GA23371@thunk.org> References: <20180103134358.3F16818C098@mercury.lcs.mit.edu> <20180103234025.GA23371@thunk.org> Message-ID: <20180104005103.GF1534@mcvoy.com> On Wed, Jan 03, 2018 at 06:40:25PM -0500, Theodore Ts'o wrote: > On Wed, Jan 03, 2018 at 01:27:19PM -0500, Clem Cole wrote: > > > This slowdown (which is not much -- L4 shows it is about 5% or so) > > > > > ???I agree. We came to the same conclusion in the early/mid 1990's with > > Mach and Chorus. In fact, the UI 'requirements for modern OS' document > > (which is part of why AT&T got behind Chorus for the never completed > > SVR5/R6 stuff - I'll see if I can find a copy) was based on that work. > > > > The OS weenies at the time felt that the cost was low enough and hardware > > cheap enough that of course kernels would be the way to go. > > It's possible to keep the slowdown at 5%, but how much extra > engineering work does it take to get the performance gap down to that > level? And during that time while the micro kernel team is playing > catchup, if the OS with the monolithic kernel adds new features to the > OS, how much additional time does it take to add those features to the > OS? (Regardless of whether the features are implemented in userspace, > or in the kernel, or some combination of the two.) To add to Ted's points. I was good friends with one of the core guys on the QNX team a long time ago (he died early in 1998 of brain cancer. Yuck). The QNX micro kernel really was micro, the kernel fit entirely in a 4K instruction cache on x86 (thanks CISC). It did very, very little. It took a lot of thinking and discipline to figure out what the kernel should do and what should be delegated. There was constant pressure to put more stuff in the kernel. My buddy told me that there were only 4 people who were allowed to touch the actual kernel code. And they all both backed each other up and second guessed each other in code reviews. They counted instructions and cache misses each time they changed stuff. As a result, the QNX kernel of the late 1980's and 1990's was super super fast. I ran as much as 10 users logged in to a 80286 running QNX doing text editing and compiles and it actually worked. I'd argue that it worked better than Unix would have worked on that miserable processor. QNX made it work. I think they slowed down when they put full posix in but they made it work. The problem is that most people / companies are not that disciplined. Oh, we need this for $CUSTOMER and this for $BENCHMARK and this for $STANDARD and the easiest way to get it is to shove it into the kernel. I'd argue that microkernels are indeed the best answer but only if you have the best programmers. Which nobody does even though everyone claims they do. Monolithic kernels are far more amenable to less than awesome people messing with them. Sad but true, I'd love a microkernel world but I fear we are too stupid to get it. Something, something, something, this is why we can't have nice things. --lm From krewat at kilonet.net Thu Jan 4 12:09:15 2018 From: krewat at kilonet.net (Arthur Krewat) Date: Wed, 3 Jan 2018 21:09:15 -0500 Subject: [TUHS] OT: critical Intel design flaw In-Reply-To: <20180103234025.GA23371@thunk.org> References: <20180103134358.3F16818C098@mercury.lcs.mit.edu> <20180103234025.GA23371@thunk.org> Message-ID: On 1/3/2018 6:40 PM, Theodore Ts'o wrote: > It's the 21st century, except for big data centers at Google, > Facebook, Microsoft, et. al, who uses disk drives in this day and > age? Have you actually priced "Enterprise" level SSD's lately that come with a support contract so that when they hit their end of life, the VAR will replace them? Dell 400GB SLC (Hitachi) in a Compellent, $5K, and that's with an educational discount a couple of years ago. Sure, if you're doing an IOPS/$ comparison, they shine. But for the most part, a Compellent with a few SLC SSDs, and a few MLC SSDs, still needs spinning rust to make the bulk of the storage. And this is a tiny 70TB installation mostly for VMware and Oracle DB. ak From bakul at bitblocks.com Thu Jan 4 12:13:59 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Wed, 03 Jan 2018 18:13:59 -0800 Subject: [TUHS] OT: critical Intel design flaw In-Reply-To: Your message of "Wed, 03 Jan 2018 16:51:03 -0800." <20180104005103.GF1534@mcvoy.com> References: <20180103134358.3F16818C098@mercury.lcs.mit.edu> <20180103234025.GA23371@thunk.org> <20180104005103.GF1534@mcvoy.com> Message-ID: <20180104021414.6EF88156E523@mail.bitblocks.com> On Wed, 03 Jan 2018 16:51:03 -0800 Larry McVoy wrote: Larry McVoy writes: > On Wed, Jan 03, 2018 at 06:40:25PM -0500, Theodore Ts'o wrote: > > On Wed, Jan 03, 2018 at 01:27:19PM -0500, Clem Cole wrote: > > > > This slowdown (which is not much -- L4 shows it is about 5% or so) > > > > > > > ???I agree. We came to the same conclusion in the early/mid 1990's wit > h > > > Mach and Chorus. In fact, the UI 'requirements for modern OS' document > > > (which is part of why AT&T got behind Chorus for the never completed > > > SVR5/R6 stuff - I'll see if I can find a copy) was based on that work. > > > > > > The OS weenies at the time felt that the cost was low enough and hardware > > > cheap enough that of course kernels would be the way to go. > > > > It's possible to keep the slowdown at 5%, but how much extra > > engineering work does it take to get the performance gap down to that > > level? And during that time while the micro kernel team is playing > > catchup, if the OS with the monolithic kernel adds new features to the > > OS, how much additional time does it take to add those features to the > > OS? (Regardless of whether the features are implemented in userspace, > > or in the kernel, or some combination of the two.) I can't find the specific paper that mentions 5% but see Liedke's SOSP97 paper: https://os.inf.tu-dresden.de/pubs/sosp97/ He specifically mentions keeping porting effort low: "In particular, we felt that it was beyond our means to tune Linux to our -kernel in the way the Mach team tuned their single-server Unix to the features of Mach." Also see http://os.inf.tu-dresden.de/papers_ps/adam-diplom.pdf Where the author reports overall about 17-22% slow down compared to native versions of Linux 2.4 or 2.6. Not sure if these are multicore version or not. https://l4linux.org/ shows L4Linux has been ported to Linux-4.13. It would be interesting to see its performance. Port of 4.6 was announced in May 2016 and 4.7 in August 2016 so my guess is porting is more than just recompile but not a very significant effort. > To add to Ted's points. I was good friends with one of the core guys > on the QNX team a long time ago (he died early in 1998 of brain cancer. Dan Hildebrand? I used QNX in 86 and had read his papers but never met him. > The problem is that most people / companies are not that disciplined. The whole idea is not to hack on the ukernel endlessly but to build apps on top of it. On something like Mill you won't even need most of the features of ukernels like L4 or QNX. Best to think of them as s/w emulation of needed h/w instructions (just like we used to use s/w emulation of floating point math on early 68K machines). > Oh, we need this for $CUSTOMER and this for $BENCHMARK and this for > $STANDARD and the easiest way to get it is to shove it into the kernel. In my view this is a losing game - particularly it if is played using performance as the main metric. The the single most critical problem today is that of lax security, not a lack of performance. It is no longer just the NSA or CIA or banks that have to worry about bad guys stealing their stuff. We all have to. Even stealing has been democratized/massively empowered by the Internet! My first unix box's CPU was 16 bit unicore cpu running at 5.6Mhz on a 256KB machine. Today I am using 4 physical core, 8 hyperthreaded 64 bit CPU running at 2.5Ghz on a 16GB machine. But I certainly don't feel my productivity has gone up even by a factor of 10. Will I notice if the machine runs 10% slower if I can get more security? As I mentioned services running in the cloud aren't necessary running most effciently. So far just the single slowdown due to the Meltdown bug is bigger than due to implementing unix on top of a ukernel. And we don't even have a solution yet for Spectre. > I'd argue that microkernels are indeed the best answer but only if you > have the best programmers. Which nobody does even though everyone claims > they do. > > Monolithic kernels are far more amenable to less than awesome people > messing with them. Sad but true, I'd love a microkernel world but I > fear we are too stupid to get it. Something, something, something, > this is why we can't have nice things. A monlithic kernel reimplemented as a set of services on top of ukernel would be even more amenable. But there are too many vested interests in the current state of the computer world. This is the same point Roger Schell made near the end of his interview (see the link in Noel Chiappa's message today). From lm at mcvoy.com Thu Jan 4 12:26:04 2018 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 3 Jan 2018 18:26:04 -0800 Subject: [TUHS] OT: critical Intel design flaw In-Reply-To: <20180104021414.6EF88156E523@mail.bitblocks.com> References: <20180103134358.3F16818C098@mercury.lcs.mit.edu> <20180103234025.GA23371@thunk.org> <20180104005103.GF1534@mcvoy.com> <20180104021414.6EF88156E523@mail.bitblocks.com> Message-ID: <20180104022604.GL1534@mcvoy.com> On Wed, Jan 03, 2018 at 06:13:59PM -0800, Bakul Shah wrote: > > To add to Ted's points. I was good friends with one of the core guys > > on the QNX team a long time ago (he died early in 1998 of brain cancer. > > Dan Hildebrand? I used QNX in 86 and had read his papers but never > met him. Yep, great guy. We could argue long and hard but it was always about the tech, never about the person. An engineer's engineer. > > The problem is that most people / companies are not that disciplined. > > The whole idea is not to hack on the ukernel endlessly but to > build apps on top of it. On something like Mill you won't even Um, I've been reading about Mill for at least a decade. It's not real until it ships. It's still vaporware, no? > > I'd argue that microkernels are indeed the best answer but only if you > > have the best programmers. Which nobody does even though everyone claims > > they do. > > > > Monolithic kernels are far more amenable to less than awesome people > > messing with them. Sad but true, I'd love a microkernel world but I > > fear we are too stupid to get it. Something, something, something, > > this is why we can't have nice things. > > A monlithic kernel reimplemented as a set of services on top > of ukernel would be even more amenable. That's been the claim but there is no data to support that claim. In fact the opposite. History has shown that microkernels can work if you are super super careful. Monolithic kernels work in spite of all the idiots checking in stupid stuff. I *love* the idea of a microkernel with a bunch of processes implementing the OS, it's so much a better design. I also have been in the real world long enough to think that I'm not going to see Linux replaced with a microkernel in my lifetime. I wish, but I don't see it happening. --lm From grog at lemis.com Thu Jan 4 12:59:59 2018 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Thu, 4 Jan 2018 13:59:59 +1100 Subject: [TUHS] OT: American Culture In-Reply-To: <1515019775.7311.for-standards-violators@oclsc.org> References: <1515019775.7311.for-standards-violators@oclsc.org> Message-ID: <20180104025959.GA34418@eureka.lemis.com> On Wednesday, 3 January 2018 at 17:49:31 -0500, Norman Wilson wrote: > Random832 (a good year for randomness, that): > >> Who says right is positive? > > Good question. Time here is round 14:00 UTC+11. UTC time is 3:00, so UTC+11 = 14:00 makes sense to me. UTC-11 = 14:00 doesn't. A thing that nobody has mentioned, and for which I can't find a reference easily: didn't System V have time zone offsets the wrong way round? I have some recollection from about 1988. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From crossd at gmail.com Thu Jan 4 13:21:02 2018 From: crossd at gmail.com (Dan Cross) Date: Wed, 3 Jan 2018 22:21:02 -0500 Subject: [TUHS] OT: critical Intel design flaw In-Reply-To: References: <20180103134358.3F16818C098@mercury.lcs.mit.edu> <20180103234025.GA23371@thunk.org> Message-ID: On Wed, Jan 3, 2018 at 9:09 PM, Arthur Krewat wrote: > On 1/3/2018 6:40 PM, Theodore Ts'o wrote: > >> It's the 21st century, except for big data centers at Google, >> Facebook, Microsoft, et. al, who uses disk drives in this day and >> age? >> > Have you actually priced "Enterprise" level SSD's lately that come with a > support contract so that when they hit their end of life, the VAR will > replace them? > > Dell 400GB SLC (Hitachi) in a Compellent, $5K, and that's with an > educational discount a couple of years ago. > > Sure, if you're doing an IOPS/$ comparison, they shine. But for the most > part, a Compellent with a few SLC SSDs, and a few MLC SSDs, still needs > spinning rust to make the bulk of the storage. > > And this is a tiny 70TB installation mostly for VMware and Oracle DB. > Well sure, but I think this sort of reinforced Ted's point: you're not going to run Fuschia on that machine. The machine you are describing is, conceptually, more in the camp of the things you'd find in a big company's datacenter rather than in an end-user's cell phone or laptop. One of the issues with Unix/Linux-style kernels is that they try to be "general-purpose": suitable for any number of tasks. A new direction in systems is the realization that the software we run in datacenters doesn't need to be the same as the software we run on our desktop machines. The big iron in the rack doesn't necessarily need a graphics subsystem or USB drivers for keyboards, mice, or other data-entry things, for instance; it certainly doesn't need X11, GNOME, and on-and-on. Fuschia's approach is the dual of this: the kernel to drive the cell phone doesn't need datacenter-class storage support or 10Gbps networking. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at bitblocks.com Thu Jan 4 13:31:35 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Wed, 03 Jan 2018 19:31:35 -0800 Subject: [TUHS] OT: critical Intel design flaw In-Reply-To: Your message of "Wed, 03 Jan 2018 18:26:04 -0800." <20180104022604.GL1534@mcvoy.com> References: <20180103134358.3F16818C098@mercury.lcs.mit.edu> <20180103234025.GA23371@thunk.org> <20180104005103.GF1534@mcvoy.com> <20180104021414.6EF88156E523@mail.bitblocks.com> <20180104022604.GL1534@mcvoy.com> Message-ID: <20180104033151.04D5A156E523@mail.bitblocks.com> On Wed, 03 Jan 2018 18:26:04 -0800 Larry McVoy wrote: Larry McVoy writes: > > > > The problem is that most people / companies are not that disciplined. > > > > The whole idea is not to hack on the ukernel endlessly but to > > build apps on top of it. On something like Mill you won't even > > Um, I've been reading about Mill for at least a decade. It's not > real until it ships. It's still vaporware, no? It is vaporware mainly because it's a largely self/unfunded effort led by one guy and a very lean volunteer team. I don't know if it will actually get funded -- in my view there are enough interesting things in it that it is worth supporting by one of the big 3 or 4 companies (or a 3 letter govt agency). Its architecture certainly seems realizable (of course, proof is in the pudding etc). But even just with ukernels we can achieve similar isolation & security. Here is a recent paper: http://ssrg.nicta.com.au/publications/csiro_full_text//Elphinstone_ZMH_17.pdf They show that seL4+rumpkernel is actually faster than native NetBSD on the same hardware (atleast on some TCP throughput tests). > I *love* the idea of a microkernel with a bunch of processes implementing > the OS, it's so much a better design. I also have been in the real world > long enough to think that I'm not going to see Linux replaced with a > microkernel in my lifetime. I wish, but I don't see it happening. It won't *replace* linux but linux API can be made available via such processes and a shared lib. You may be right about real world inertia. And Security is simply not taken seriously enough. I still think it would be well worth it for knowledgeable OS folks like you to /actually/ explore this design space and see what is possible. It would certainly be more fun than hacking on Linux or FreeBSD! From harald at skogtun.org Thu Jan 4 21:53:26 2018 From: harald at skogtun.org (Harald Arnesen) Date: Thu, 4 Jan 2018 12:53:26 +0100 Subject: [TUHS] OT: critical Intel design flaw In-Reply-To: <20180103234025.GA23371@thunk.org> References: <20180103134358.3F16818C098@mercury.lcs.mit.edu> <20180103234025.GA23371@thunk.org> Message-ID: Theodore Ts'o [2018-01-04 00:40]: > (There are those who have argued that the *BSD's were delayed by > around six months due to the AT&T / Berkeley lawsuit, and if it were > but for that, Linux would not have gained the prominence that it > had/has. Didn't Linus say that if there had been an affordable BSD available at the time, he wouldn't have started the Linux project? From clemc at ccc.com Fri Jan 5 00:03:09 2018 From: clemc at ccc.com (Clem Cole) Date: Thu, 4 Jan 2018 09:03:09 -0500 Subject: [TUHS] OT: critical Intel design flaw In-Reply-To: References: <20180103134358.3F16818C098@mercury.lcs.mit.edu> <20180103234025.GA23371@thunk.org> Message-ID: On Thu, Jan 4, 2018 at 6:53 AM, Harald Arnesen wrote: > Didn't Linus say that if there had been an affordable BSD available at > the time, he wouldn't have started the Linux project? ​You need to add >>and that he knew about and had access<<. The truth is there was and it had networking and X windows already. Bill Jolitz had completed the original 386 BSD port (and actually started to publish about it in DDJ). The 386BSD sources were available to all BSD licensees - as CSRG had put them on the ucbvax ftp server (truth is they were actually available to anyone there knew how to grab it -- the attempt to keep the ftp address 'secret' was pretty shallow - not quite announced on net.noise but it certainly was passed hacker to hacker if you went to a USENIX conference in those days).​ The funny part was that Linus university was a BSD licensee and could have gotten it (although I've personally never seen or heard of evidence that they did). So this was an example of ignorance of something, not true in fact - That said, Linus solved the problem he had. More power to him. Although his original kernel was a far cry from '386BSD' - but that was the point. When the AT&T case came out, hackers like me were worried 386BSD was going to go away and started to help make Linux more complete. I should (as Larry has pointed out) at the time of Linus original work, some institutions were far more liberal about source access than others. So even if Linus has known about Jolitz's work, its not clear he would/could have had access to it. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Fri Jan 5 01:54:25 2018 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 4 Jan 2018 07:54:25 -0800 Subject: [TUHS] OT: critical Intel design flaw In-Reply-To: References: <20180103134358.3F16818C098@mercury.lcs.mit.edu> <20180103234025.GA23371@thunk.org> Message-ID: <20180104155425.GC8574@mcvoy.com> On Thu, Jan 04, 2018 at 09:03:09AM -0500, Clem Cole wrote: > On Thu, Jan 4, 2018 at 6:53 AM, Harald Arnesen wrote: > > Didn't Linus say that if there had been an affordable BSD available at > > the time, he wouldn't have started the Linux project? > > ???You need to add >>and that he knew about and had access<<. > > The truth is there was and it had networking and X windows already. Bill > Jolitz had completed the original 386 BSD port (and actually started to > publish about it in DDJ). The 386BSD sources were available to all BSD > licensees But that's not what Linus (or anyone) wanted. They wanted it under some sort of clearly open source license. None of us knew what the penalty was for violating the license, we just knew that at one end was us, with no means to fight a court battle, and at the other end were big entities that viewed court battles as a cost of doing business. I didn't know at the time that Bell Labs had to license their stuff as part of the monopoly deal, that was something I learned here. So I, and I suspect lots of other people, most people, the best people :) all thought that our access to the source was at the whim of AT&T, it could be taken away at any time. That wasn't the rosy "everybody who wanted it could get it" world that Clem lived in. Clem was in a special club, heck, he was president of Usenix at one point, that's sort of the epitome of being in the club. Not being in the club was a far less rosy place and it made perfect sense for Linus to start Linux. I'd argue that if he hadn't, someone else would have. Stupid lawsuit means we're mostly running a Unix-clone, not actual Unix. --lm From tytso at mit.edu Fri Jan 5 02:45:57 2018 From: tytso at mit.edu (Theodore Ts'o) Date: Thu, 4 Jan 2018 11:45:57 -0500 Subject: [TUHS] OT: critical Intel design flaw In-Reply-To: References: <20180103134358.3F16818C098@mercury.lcs.mit.edu> <20180103234025.GA23371@thunk.org> Message-ID: <20180104164557.GI23371@thunk.org> On Thu, Jan 04, 2018 at 09:03:09AM -0500, Clem Cole wrote: > ​You need to add >>and that he knew about and had access<<. > > The truth is there was and it had networking and X windows already. Bill > Jolitz had completed the original 386 BSD port (and actually started to > publish about it in DDJ). How real was it in June 1991, when he demo'ed it in Usenix Anaheim? Was it at the level of a "MIT Media Lab demo", or was it actually something that could be used in anger? The official history states that 386 BSD version 0.0 was released in March 1992, and the "much more usable" 0.1 version was released in July 1992. The biggest problem with Jolitz's work seems to have been more social than anything else. The writeups from that era seem to indicate that the Jolitz's wanted to keep a much tighter control over things, and this discouraged collaboration and contributions, which led to the first of *BSD fragmentation/spin-offs, starting with FreeBSD and NetBSD. Contrast that to Linus, where I started playing with Linux in September 1991 (Linux 0.09), and in three months he accepted fairly major patches from me to implement all of the new syscalls and changes needed to implement POSIX Job Control and POSIX termios (Linux 0.12). The Linux developers were not spending time fighting over who would get commit bits; we were having fun writing code. - Ted From dot at dotat.at Fri Jan 5 02:48:48 2018 From: dot at dotat.at (Tony Finch) Date: Thu, 4 Jan 2018 16:48:48 +0000 Subject: [TUHS] OT: American Culture In-Reply-To: <20180104025959.GA34418@eureka.lemis.com> References: <1515019775.7311.for-standards-violators@oclsc.org> <20180104025959.GA34418@eureka.lemis.com> Message-ID: Greg 'groggy' Lehey wrote: > > A thing that nobody has mentioned, and for which I can't find a > reference easily: didn't System V have time zone offsets the wrong way > round? I have some recollection from about 1988. It's enshrined in POSIX but I believe it goes back earlier than that. http://pubs.opengroup.org/onlinepubs/9699919799/functions/tzset.html As I understand it, POSIX TZ offsets are the wrong way round because it was more convenient to omit the sign on the TZ offsets, and because Unix comes from America that meant no sign -> west, negative -> east. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Rockall, Malin: Cyclonic, becoming mainly northeast later , 5 to 7, increasing gale 8 or severe gale 9 later in Rockall. Very rough or high. Rain or showers. Moderate or poor, occasionally good. From akosela at andykosela.com Fri Jan 5 03:10:14 2018 From: akosela at andykosela.com (Andy Kosela) Date: Thu, 4 Jan 2018 11:10:14 -0600 Subject: [TUHS] OT: critical Intel design flaw In-Reply-To: <20180104164557.GI23371@thunk.org> References: <20180103134358.3F16818C098@mercury.lcs.mit.edu> <20180103234025.GA23371@thunk.org> <20180104164557.GI23371@thunk.org> Message-ID: On Thursday, January 4, 2018, Theodore Ts'o wrote: > On Thu, Jan 04, 2018 at 09:03:09AM -0500, Clem Cole wrote: > > ​You need to add >>and that he knew about and had access<<. > > > > The truth is there was and it had networking and X windows already. Bill > > Jolitz had completed the original 386 BSD port (and actually started to > > publish about it in DDJ). > > How real was it in June 1991, when he demo'ed it in Usenix Anaheim? > Was it at the level of a "MIT Media Lab demo", or was it actually > something that could be used in anger? > > The official history states that 386 BSD version 0.0 was released in > March 1992, and the "much more usable" 0.1 version was released in > July 1992. > > The biggest problem with Jolitz's work seems to have been more social > than anything else. The writeups from that era seem to indicate that > the Jolitz's wanted to keep a much tighter control over things, and > this discouraged collaboration and contributions, which led to the > first of *BSD fragmentation/spin-offs, starting with FreeBSD and > NetBSD. > > Contrast that to Linus, where I started playing with Linux in > September 1991 (Linux 0.09), and in three months he accepted fairly > major patches from me to implement all of the new syscalls and changes > needed to implement POSIX Job Control and POSIX termios (Linux 0.12). > The Linux developers were not spending time fighting over who would > get commit bits; we were having fun writing code. > > - Ted My understanding is that initially Linux project was much simpler and minimalistic than BSD, which in the late 80s was already a very bloated O/S as compared to UNIX V6/V7. And it was also one of the reasons some folks preferred it. It was kind of like moving back in time to times of hacking on V6 for new generation of hackers. Pure fun. Minimalism is what initially brought me to Unix. Of course today Linux is as bloated Windows, thats why some people prefer to hack on simpler projects like FUZIX (Alan Cox). --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Fri Jan 5 03:17:40 2018 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 4 Jan 2018 09:17:40 -0800 Subject: [TUHS] OT: critical Intel design flaw In-Reply-To: <20180104164557.GI23371@thunk.org> References: <20180103134358.3F16818C098@mercury.lcs.mit.edu> <20180103234025.GA23371@thunk.org> <20180104164557.GI23371@thunk.org> Message-ID: <20180104171740.GF19585@mcvoy.com> On Thu, Jan 04, 2018 at 11:45:57AM -0500, Theodore Ts'o wrote: > On Thu, Jan 04, 2018 at 09:03:09AM -0500, Clem Cole wrote: > > ???You need to add >>and that he knew about and had access<<. > > > > The truth is there was and it had networking and X windows already. Bill > > Jolitz had completed the original 386 BSD port (and actually started to > > publish about it in DDJ). > > How real was it in June 1991, when he demo'ed it in Usenix Anaheim? > Was it at the level of a "MIT Media Lab demo", or was it actually > something that could be used in anger? I dunno what "used in anger" means but it worked. I used it. I know Joltiz pretty well, he worked for me around this time period. I hired him just to give him some money, he had gotten sort of screwed by the in crowd in the BSD/Usenix world, I didn't see that as reasonable. > The biggest problem with Jolitz's work seems to have been more social > than anything else. The writeups from that era seem to indicate that > the Jolitz's wanted to keep a much tighter control over things, and > this discouraged collaboration and contributions, which led to the > first of *BSD fragmentation/spin-offs, starting with FreeBSD and > NetBSD. Yep. Leading to the famous (to me) quote: The BSD guys can't decide who is going to drive the big red fire truck so they each get to drive their very own toy fire truck. (I think Linus said that but not sure). From tih at hamartun.priv.no Fri Jan 5 03:20:11 2018 From: tih at hamartun.priv.no (Tom Ivar Helbekkmo) Date: Thu, 04 Jan 2018 18:20:11 +0100 Subject: [TUHS] OT: critical Intel design flaw In-Reply-To: <20180104164557.GI23371@thunk.org> (Theodore Ts'o's message of "Thu, 4 Jan 2018 11:45:57 -0500") References: <20180103134358.3F16818C098@mercury.lcs.mit.edu> <20180103234025.GA23371@thunk.org> <20180104164557.GI23371@thunk.org> Message-ID: Theodore Ts'o writes: > The biggest problem with Jolitz's work seems to have been more social > than anything else. The writeups from that era seem to indicate that > the Jolitz's wanted to keep a much tighter control over things, and > this discouraged collaboration and contributions, which led to the > first of *BSD fragmentation/spin-offs, starting with FreeBSD and > NetBSD. Indeed. I've used NetBSD since it was called 386bsd 0.0, and the way I remember it, we grabbed that when Jolitz made it available, and had an Internet community playing with it and improving it. Patches were accumulated, and sent back to Jolitz. Then he released 0.1, with none of the patches from the 'net. Some of the more active people ported our existing patches to that, and we kept on going. Again, patches were sent back. When Jolitz released 0.2, again with no patches from the Internet community included, it was decided to part ways, and start a forked project on the 'net. This became NetBSD. After a short time, it was obvious that there were two camps: one wanted to keep the OS multi-platform, while the other felt it was smarter to ditch that in favor of maximizing performance and utility on the Intel platform. The latter group became the FreeBSD project. And yes, the stupid lawsuit came at just the right time for the world to adopt Linux instead of BSD, but that's the way the cookie crumbles. The BSD community is doing just fine, thank you, and we still have the better product, so there! ;) -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in computer science. --Alan Kay From imp at bsdimp.com Fri Jan 5 03:20:26 2018 From: imp at bsdimp.com (Warner Losh) Date: Thu, 4 Jan 2018 10:20:26 -0700 Subject: [TUHS] OT: American Culture In-Reply-To: References: <1515019775.7311.for-standards-violators@oclsc.org> <20180104025959.GA34418@eureka.lemis.com> Message-ID: On Thu, Jan 4, 2018 at 9:48 AM, Tony Finch wrote: > Greg 'groggy' Lehey wrote: > > > > A thing that nobody has mentioned, and for which I can't find a > > reference easily: didn't System V have time zone offsets the wrong way > > round? I have some recollection from about 1988. > > It's enshrined in POSIX but I believe it goes back earlier than that. > http://pubs.opengroup.org/onlinepubs/9699919799/functions/tzset.html > > As I understand it, POSIX TZ offsets are the wrong way round because it > was more convenient to omit the sign on the TZ offsets, and because Unix > comes from America that meant no sign -> west, negative -> east. > There's also a time interval measurement convention from the high precision time keeping world that has negative offsets 'forwards' and positive offsets 'backwards' which this matches. It sure was confusing to me when I first encountered it when the time scientists were telling me the measurements were backwards... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Fri Jan 5 03:28:45 2018 From: imp at bsdimp.com (Warner Losh) Date: Thu, 4 Jan 2018 10:28:45 -0700 Subject: [TUHS] OT: critical Intel design flaw In-Reply-To: References: <20180103134358.3F16818C098@mercury.lcs.mit.edu> <20180103234025.GA23371@thunk.org> <20180104164557.GI23371@thunk.org> Message-ID: On Thu, Jan 4, 2018 at 10:20 AM, Tom Ivar Helbekkmo via TUHS < tuhs at minnie.tuhs.org> wrote: > Theodore Ts'o writes: > > > The biggest problem with Jolitz's work seems to have been more social > > than anything else. The writeups from that era seem to indicate that > > the Jolitz's wanted to keep a much tighter control over things, and > > this discouraged collaboration and contributions, which led to the > > first of *BSD fragmentation/spin-offs, starting with FreeBSD and > > NetBSD. > > Indeed. I've used NetBSD since it was called 386bsd 0.0, and the way I > remember it, we grabbed that when Jolitz made it available, and had an > Internet community playing with it and improving it. Patches were > accumulated, and sent back to Jolitz. Then he released 0.1, with none > of the patches from the 'net. Some of the more active people ported our > existing patches to that, and we kept on going. Again, patches were > sent back. When Jolitz released 0.2, again with no patches from the > Internet community included, it was decided to part ways, and start a > forked project on the 'net. This became NetBSD. After a short time, it > was obvious that there were two camps: one wanted to keep the OS > multi-platform, while the other felt it was smarter to ditch that in > favor of maximizing performance and utility on the Intel platform. The > latter group became the FreeBSD project. > Both NetBSD and FreeBSD emerged from the 'patchkit' efforts that would take the good accumulated patches from the net to 386BSD and apply them to try to cobble together some kind of distribution. It was after Jolitz refused to play ball with other people at all. It's unfortunate he was the one to bring 386BSD to market from the net2 distribution in many ways, since it spawned a Diaspora that's been a mixed blessing: A diversity of platforms has has lead to more experimentation. It's also lead to a bunch of duplicated effort when that experimentation lead to a system that made it hard to share. Of course, Jolitz wasn't the only strong personality in the early days that had issues working with others, which also contributed to the Net/Free split, the later Open/Net split and the even later Free/Dragonfly split... Then again, Linux is no paragon of people working together either... There's numerous examples where stupid technical things were done because of personality disputes (exhibit A: systemd, even Linus can't stop it). > And yes, the stupid lawsuit came at just the right time for the world to > adopt Linux instead of BSD, but that's the way the cookie crumbles. The > BSD community is doing just fine, thank you, and we still have the > better product, so there! ;) > I'm with you there, even if we have some denominational differences :) Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From krewat at kilonet.net Fri Jan 5 03:42:32 2018 From: krewat at kilonet.net (Arthur Krewat) Date: Thu, 4 Jan 2018 12:42:32 -0500 Subject: [TUHS] OT: critical Intel design flaw In-Reply-To: References: <20180103134358.3F16818C098@mercury.lcs.mit.edu> <20180103234025.GA23371@thunk.org> Message-ID: <6886c3b5-5778-9691-a3b6-3a5523952c05@kilonet.net> On 1/3/2018 10:21 PM, Dan Cross wrote: > Well sure, but I think this sort of reinforced Ted's point: you're not > going to run Fuschia on that machine. The machine you are describing > is, conceptually, more in the camp of the things you'd find in a big > company's datacenter rather than in an end-user's cell phone or laptop. Quite true, didn't realize that the context was small-form-factor. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at bitblocks.com Fri Jan 5 04:29:59 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Thu, 04 Jan 2018 10:29:59 -0800 Subject: [TUHS] OT: critical Intel design flaw In-Reply-To: Your message of "Thu, 04 Jan 2018 09:17:40 -0800." <20180104171740.GF19585@mcvoy.com> References: <20180103134358.3F16818C098@mercury.lcs.mit.edu> <20180103234025.GA23371@thunk.org> <20180104164557.GI23371@thunk.org> <20180104171740.GF19585@mcvoy.com> Message-ID: <20180104183014.99912156E523@mail.bitblocks.com> On Thu, 04 Jan 2018 09:17:40 -0800 Larry McVoy wrote: Larry McVoy writes: > > I dunno what "used in anger" means but it worked. I used it. I know > Joltiz pretty well, he worked for me around this time period. I hired > him just to give him some money, he had gotten sort of screwed by the > in crowd in the BSD/Usenix world, I didn't see that as reasonable. Not part of any in crowd but I am curious. How was Jolitz "screwed by the in crowd in the BSD/Usenix world"? I got 38BSD on a set of floppies from someone in 92 or 93 - can't remember - and I recall meeting Jolitz at some meetup back then. At the time I was using a Sun 3/50 (BSD) & a Fortune Box (V7) but promptly bought a 386 box (with a full 16MB of memory) and installed 386bsd. I also played with linux-0.11 but I recall reading something about Linus using SysV as a reference and that was the end of my interest in linux! Also because 386BSD was already available and did what I wanted. Later BSD splits were distressing but so it goes. From lm at mcvoy.com Fri Jan 5 04:50:01 2018 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 4 Jan 2018 10:50:01 -0800 Subject: [TUHS] OT: critical Intel design flaw In-Reply-To: <20180104183014.99912156E523@mail.bitblocks.com> References: <20180103134358.3F16818C098@mercury.lcs.mit.edu> <20180103234025.GA23371@thunk.org> <20180104164557.GI23371@thunk.org> <20180104171740.GF19585@mcvoy.com> <20180104183014.99912156E523@mail.bitblocks.com> Message-ID: <20180104185001.GI19585@mcvoy.com> On Thu, Jan 04, 2018 at 10:29:59AM -0800, Bakul Shah wrote: > On Thu, 04 Jan 2018 09:17:40 -0800 Larry McVoy wrote: > Larry McVoy writes: > > > > I dunno what "used in anger" means but it worked. I used it. I know > > Joltiz pretty well, he worked for me around this time period. I hired > > him just to give him some money, he had gotten sort of screwed by the > > in crowd in the BSD/Usenix world, I didn't see that as reasonable. > > Not part of any in crowd but I am curious. How was Jolitz > "screwed by the in crowd in the BSD/Usenix world"? I'll answer off list, not interested in ruffling feathers. From imp at bsdimp.com Fri Jan 5 06:52:33 2018 From: imp at bsdimp.com (Warner Losh) Date: Thu, 4 Jan 2018 13:52:33 -0700 Subject: [TUHS] OT: critical Intel design flaw In-Reply-To: <20180104185001.GI19585@mcvoy.com> References: <20180103134358.3F16818C098@mercury.lcs.mit.edu> <20180103234025.GA23371@thunk.org> <20180104164557.GI23371@thunk.org> <20180104171740.GF19585@mcvoy.com> <20180104183014.99912156E523@mail.bitblocks.com> <20180104185001.GI19585@mcvoy.com> Message-ID: On Jan 4, 2018 11:50 AM, "Larry McVoy" wrote: On Thu, Jan 04, 2018 at 10:29:59AM -0800, Bakul Shah wrote: > On Thu, 04 Jan 2018 09:17:40 -0800 Larry McVoy wrote: > Larry McVoy writes: > > > > I dunno what "used in anger" means but it worked. I used it. I know > > Joltiz pretty well, he worked for me around this time period. I hired > > him just to give him some money, he had gotten sort of screwed by the > > in crowd in the BSD/Usenix world, I didn't see that as reasonable. > > Not part of any in crowd but I am curious. How was Jolitz > "screwed by the in crowd in the BSD/Usenix world"? I'll answer off list, not interested in ruffling feathers. Probably best... as someone on the other side during that time, I have a different perspective on who got screwed when... and what beds were made and who had to sleep in them... But I agree rehashing all that now is not beneficial to anybody... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Fri Jan 5 06:56:31 2018 From: tytso at mit.edu (Theodore Ts'o) Date: Thu, 4 Jan 2018 15:56:31 -0500 Subject: [TUHS] OT: critical Intel design flaw In-Reply-To: <20180104183014.99912156E523@mail.bitblocks.com> References: <20180103134358.3F16818C098@mercury.lcs.mit.edu> <20180103234025.GA23371@thunk.org> <20180104164557.GI23371@thunk.org> <20180104171740.GF19585@mcvoy.com> <20180104183014.99912156E523@mail.bitblocks.com> Message-ID: <20180104205631.GL23371@thunk.org> On Thu, Jan 04, 2018 at 10:29:59AM -0800, Bakul Shah wrote: > 16MB of memory) and installed 386bsd. I also played with > linux-0.11 but I recall reading something about Linus using > SysV as a reference and that was the end of my interest in > linux! As far as I know that was never true. We used used POSIX as a reference mainly because it was more easily available as a specification. So that meant that we implemented termios support, and not termio, or the BSD variant. The networking layer was all BSD sockets; we certainly never implemented STREAMS, for goodness sake! :-) - Ted From bakul at bitblocks.com Fri Jan 5 06:56:53 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Thu, 4 Jan 2018 12:56:53 -0800 Subject: [TUHS] OT: critical Intel design flaw In-Reply-To: References: <20180103134358.3F16818C098@mercury.lcs.mit.edu> <20180103234025.GA23371@thunk.org> <20180104164557.GI23371@thunk.org> <20180104171740.GF19585@mcvoy.com> <20180104183014.99912156E523@mail.bitblocks.com> <20180104185001.GI19585@mcvoy.com> Message-ID: <699C77DA-7685-413F-BAFD-D7C40E06090E@bitblocks.com> > On Jan 4, 2018, at 12:52 PM, Warner Losh wrote: > > > > On Jan 4, 2018 11:50 AM, "Larry McVoy" > wrote: > On Thu, Jan 04, 2018 at 10:29:59AM -0800, Bakul Shah wrote: > > On Thu, 04 Jan 2018 09:17:40 -0800 Larry McVoy > wrote: > > Larry McVoy writes: > > > > > > I dunno what "used in anger" means but it worked. I used it. I know > > > Joltiz pretty well, he worked for me around this time period. I hired > > > him just to give him some money, he had gotten sort of screwed by the > > > in crowd in the BSD/Usenix world, I didn't see that as reasonable. > > > > Not part of any in crowd but I am curious. How was Jolitz > > "screwed by the in crowd in the BSD/Usenix world"? > > I'll answer off list, not interested in ruffling feathers. > > Probably best... as someone on the other side during that time, I have a different perspective on who got screwed when... and what beds were made and who had to sleep in them... > > But I agree rehashing all that now is not beneficial to anybody... My fault. I had meant to reply to just Larry but forgot to remove cc: to the list. Apologies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Fri Jan 5 07:16:46 2018 From: imp at bsdimp.com (Warner Losh) Date: Thu, 4 Jan 2018 14:16:46 -0700 Subject: [TUHS] OT: critical Intel design flaw In-Reply-To: <20180104205631.GL23371@thunk.org> References: <20180103134358.3F16818C098@mercury.lcs.mit.edu> <20180103234025.GA23371@thunk.org> <20180104164557.GI23371@thunk.org> <20180104171740.GF19585@mcvoy.com> <20180104183014.99912156E523@mail.bitblocks.com> <20180104205631.GL23371@thunk.org> Message-ID: On Thu, Jan 4, 2018 at 1:56 PM, Theodore Ts'o wrote: > On Thu, Jan 04, 2018 at 10:29:59AM -0800, Bakul Shah wrote: > > 16MB of memory) and installed 386bsd. I also played with > > linux-0.11 but I recall reading something about Linus using > > SysV as a reference and that was the end of my interest in > > linux! > > As far as I know that was never true. We used used POSIX as a > reference mainly because it was more easily available as a > specification. So that meant that we implemented termios support, and > not termio, or the BSD variant. The networking layer was all BSD > sockets; we certainly never implemented STREAMS, for goodness sake! :-) > There was a natural bias towards SysV interfaces, which highlighted the differences with BSD interfaces in some areas and may have left that impression... Linus certainly had access to SysV or SysV derived systems, but there wasn't even a whisper at the time he copied code from there. And the few maybe less than completely legit versions of SysV that are now available bear this out: they look nothing at all like the 0.11-linux tree. Thank goodness for the sockets thing... Even though it's a horrible interface, it was less horrible than STREAMS... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at bitblocks.com Fri Jan 5 07:17:40 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Thu, 4 Jan 2018 13:17:40 -0800 Subject: [TUHS] OT: critical Intel design flaw In-Reply-To: <20180104205631.GL23371@thunk.org> References: <20180103134358.3F16818C098@mercury.lcs.mit.edu> <20180103234025.GA23371@thunk.org> <20180104164557.GI23371@thunk.org> <20180104171740.GF19585@mcvoy.com> <20180104183014.99912156E523@mail.bitblocks.com> <20180104205631.GL23371@thunk.org> Message-ID: <4DA9612F-4459-4026-9E1C-23F32BCCFB6A@bitblocks.com> On Jan 4, 2018, at 12:56 PM, Theodore Ts'o wrote: > > On Thu, Jan 04, 2018 at 10:29:59AM -0800, Bakul Shah wrote: >> 16MB of memory) and installed 386bsd. I also played with >> linux-0.11 but I recall reading something about Linus using >> SysV as a reference and that was the end of my interest in >> linux! > > As far as I know that was never true. We used used POSIX as a > reference mainly because it was more easily available as a > specification. So that meant that we implemented termios support, and > not termio, or the BSD variant. The networking layer was all BSD > sockets; we certainly never implemented STREAMS, for goodness sake! :-) I remember sysV coming up in connection with Linux.... Ok, found it: https://groups.google.com/forum/#!searchin/comp.os.minix/linus$201991%7Csort:date/comp.os.minix/3dSbdErXdUc/uoBUzk9NEEsJ 1. WHAT IS LINUX 0.11 LINUX 0.11 is a freely distributable UNIX clone. It implements a subset of System V and POSIX functionality. ... 2. LINUX features - System call compatible with a subset of System V and POSIX ... 8. FUTURE PLANS ... - STREAMS The only mention of BSD is WRT pmake. From akosela at andykosela.com Fri Jan 5 08:55:11 2018 From: akosela at andykosela.com (Andy Kosela) Date: Thu, 4 Jan 2018 16:55:11 -0600 Subject: [TUHS] OT: critical Intel design flaw In-Reply-To: References: <20180103134358.3F16818C098@mercury.lcs.mit.edu> <20180103234025.GA23371@thunk.org> <20180104164557.GI23371@thunk.org> <20180104171740.GF19585@mcvoy.com> <20180104183014.99912156E523@mail.bitblocks.com> <20180104205631.GL23371@thunk.org> Message-ID: On Thursday, January 4, 2018, Warner Losh wrote: > > > On Thu, Jan 4, 2018 at 1:56 PM, Theodore Ts'o wrote: > >> On Thu, Jan 04, 2018 at 10:29:59AM -0800, Bakul Shah wrote: >> > 16MB of memory) and installed 386bsd. I also played with >> > linux-0.11 but I recall reading something about Linus using >> > SysV as a reference and that was the end of my interest in >> > linux! >> >> As far as I know that was never true. We used used POSIX as a >> reference mainly because it was more easily available as a >> specification. So that meant that we implemented termios support, and >> not termio, or the BSD variant. The networking layer was all BSD >> sockets; we certainly never implemented STREAMS, for goodness sake! :-) >> > > There was a natural bias towards SysV interfaces, which highlighted the > differences with BSD interfaces in some areas and may have left that > impression... > > Linus certainly had access to SysV or SysV derived systems > > First and foremost Linus was a MINIX user which was based on UNIX V7. That could explain his preference for SysV. People tend to forget that it was MINIX that sparked Linus' interest in the operating systems. The first public announcement of Linux was posted on the MINIX newsgroup. Linux was basically a continuation of MINIX -- small, simple project, but heavily optimized for i386 and with a vision to become a production ready system instead of educational one. Its simplicity and freshness definitely attracted many people who wanted to have a small, simple Unix-like system on their PC. Sometimes it is just better to start something from scratch instead of relying on legacy and bloated solutions from the past. BSD was already bloated and big. It was technically superior at that time, but at the cost of complexity. And it took a lot of effort to polish 386BSD to the point it was stable -- it definitely wasnt in the beginning. --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Jan 6 00:27:33 2018 From: clemc at ccc.com (Clem Cole) Date: Fri, 5 Jan 2018 09:27:33 -0500 Subject: [TUHS] OT: critical Intel design flaw In-Reply-To: References: <20180103134358.3F16818C098@mercury.lcs.mit.edu> <20180103234025.GA23371@thunk.org> <20180104164557.GI23371@thunk.org> <20180104171740.GF19585@mcvoy.com> <20180104183014.99912156E523@mail.bitblocks.com> <20180104205631.GL23371@thunk.org> Message-ID: On Thu, Jan 4, 2018 at 5:55 PM, Andy Kosela wrote: > First and foremost Linus was a MINIX user which was based on UNIX V7. > That could explain his preference for SysV. > ​Andy - please explain that connection, as it seem a tad tenuous to me. Sorry for my thickness, but I don't see how being based on V7 reflected on being System V based or not. System V was released many years after Seventh edition (1984 vs 1979). BSD had been out for years by the time Linus started his work and most everything from Seventh Edition (ney UNIX/TS) has been taken into PWB 3.0 @ Summit which was renamed System III in 1981/82ish by the North Carolina weenies at AT&T. I'm trying to think of a program I wrote for Seventh Edition that other than compiler and architectural differences, would not run with a "make clean; make" incantation (I can think of a few but not many). I guess the primary differences was init(8) had changed at that point, /etc/rc had been restructured, and the terminal handlers (termio vs {g,s}tty); but from an kernel interface standard point except for the terminal handler, System III was pretty much based on Seventh Edition and System V was a superset of that. If I remember a number of the emails/notes from the time, Linus was using SunOS on Sun3 at school. So he seen all of the BSD extensions to Seventh Edition, and in particular networking and the sockets API. As Ted noted, POSIX had more of an influence since it was at least formally described, while BSD was only defined by 'trusting the source.' POSIX had not yet been able to broach the Networking API at this point, but things like termios had begun to appear. In fact, Bostic was in the process of redoing BSD's terminal handler to add that API IIRC [I can ask him of the actually date]. Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Mon Jan 8 11:07:38 2018 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 8 Jan 2018 12:07:38 +1100 (EST) Subject: [TUHS] RIP John Mauchly Message-ID: We lost a co-inventor of ENIAC, John Mauchly, on this day (that's 8th January like my headers say) in 1980. ENIAC is claimed to be the "first general purpose electronic digital computer", but I guess it comes down to a matter of definition[*], as every culture likes to be the "first" (just ask the Penguins, for example); for "computer" you could go all the way back to the Mk-I Antikythera (Hellenic variation, from about the 100BC production run)... [*] Analogue/digital/hybrid Mechanical/electrical/electronic/hybrid General/special Wired/programmable/Turing Prototype/production Harvard/Neumann/quantum Etc... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From wkt at tuhs.org Tue Jan 9 10:30:18 2018 From: wkt at tuhs.org (Warren Toomey) Date: Tue, 9 Jan 2018 10:30:18 +1000 Subject: [TUHS] 2018: eighteen months to the Unix 50th anniversary Message-ID: <20180109003018.GB29792@minnie.tuhs.org> Hi all, Happy New Year. As it's now only eighteen months to the Unix 50th Anniversary, I thought I'd poll you all to get an update of what is being done to celebrate the anniversary, and/or what could we organise that has not yet been organised. Cheers, Warren From dave at horsfall.org Tue Jan 9 10:39:46 2018 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 9 Jan 2018 11:39:46 +1100 (EST) Subject: [TUHS] 2018: eighteen months to the Unix 50th anniversary In-Reply-To: <20180109003018.GB29792@minnie.tuhs.org> References: <20180109003018.GB29792@minnie.tuhs.org> Message-ID: On Tue, 9 Jan 2018, Warren Toomey wrote: > Hi all, Happy New Year. As it's now only eighteen months to the Unix > 50th Anniversary, I thought I'd poll you all to get an update of what is > being done to celebrate the anniversary, and/or what could we organise > that has not yet been organised. Gawd; I'd better get started on ACSnet then... As I recall, Piers did the MHSnet stuff, but I don't recall whether it interoperates with ACSnet (too long ago!). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From noel.hunt at gmail.com Tue Jan 9 12:16:01 2018 From: noel.hunt at gmail.com (Noel Hunt) Date: Tue, 9 Jan 2018 13:16:01 +1100 Subject: [TUHS] 2018: eighteen months to the Unix 50th anniversary In-Reply-To: References: <20180109003018.GB29792@minnie.tuhs.org> Message-ID: Didn't Piers write ACSnet too? On Tue, Jan 9, 2018 at 11:39 AM, Dave Horsfall wrote: > On Tue, 9 Jan 2018, Warren Toomey wrote: > > Hi all, Happy New Year. As it's now only eighteen months to the Unix 50th >> Anniversary, I thought I'd poll you all to get an update of what is being >> done to celebrate the anniversary, and/or what could we organise that has >> not yet been organised. >> > > Gawd; I'd better get started on ACSnet then... As I recall, Piers did the > MHSnet stuff, but I don't recall whether it interoperates with ACSnet (too > long ago!). > > -- > Dave Horsfall DTM (VK2KFU) "Those who don't understand security will > suffer." > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Tue Jan 9 12:38:02 2018 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 9 Jan 2018 13:38:02 +1100 (EST) Subject: [TUHS] 2018: eighteen months to the Unix 50th anniversary In-Reply-To: References: <20180109003018.GB29792@minnie.tuhs.org> Message-ID: On Tue, 9 Jan 2018, Noel Hunt wrote: > Didn't Piers write ACSnet too? He was part of it, yes; the reference was to Piers getting an MHSnet node ready for The Event. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From kevin.bowling at kev009.com Tue Jan 9 17:30:47 2018 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Tue, 9 Jan 2018 00:30:47 -0700 Subject: [TUHS] 2018: eighteen months to the Unix 50th anniversary In-Reply-To: <20180109003018.GB29792@minnie.tuhs.org> References: <20180109003018.GB29792@minnie.tuhs.org> Message-ID: I would like to see an in person event somewhere On Mon, Jan 8, 2018 at 5:30 PM, Warren Toomey wrote: > Hi all, Happy New Year. As it's now only eighteen months to the Unix 50th > Anniversary, I thought I'd poll you all to get an update of what is being > done to celebrate the anniversary, and/or what could we organise that has > not yet been organised. > > Cheers, Warren From helbig at mailbox.org Wed Jan 10 04:05:56 2018 From: helbig at mailbox.org (Wolfgang Helbig) Date: Tue, 9 Jan 2018 19:05:56 +0100 Subject: [TUHS] Some resources for V6/PDP/SIMH newbs like me In-Reply-To: References: Message-ID: Hi, Will may I point to chapter 1.0 of my operating system lecture notes at: http://doc.cat-v.org/unix/v6/operating-systems-lecture-notes/script/ among others, it explains the assembler language, together with the description of the instruction set http://doc.cat-v.org/unix/v6/operating-systems-lecture-notes/pdp11/doc/cpu and finally the Unix Assembler Reference Manual(1) at http://doc.cat-v.org/unix/v6/operating-systems-lecture-notes/v6/doc/index.html might help. Greetings, Wolfgang > Am 20.11.2017 um 20:20 schrieb Will Senn : > > All, > > While it's fresh, I thought I'd share some resources I've found helpful in learning about the venerable v6 as a relative newb... > > Learning Unix V6 in the modern era is an interesting and enormously educational experience. In the process of using it I have had to learn how to host it in a simulator (SimH in my case, but there are others), install it, communicate with it, configure it, build special files for it, attach devices to it, communicate with the devices attached to it and to SimH, build a kernel, install the kernel, boot the kernel, work with a variety of media intended to work with it, extend it, and so on. In addition, I have had to learn a bit about the PDP-11 (as arguably the most convenient architecture for learning about V6), about its architecture, its instruction set, its devices, its memory structure, and so on. > > None of this exploration would have been possible without the excellent work of Bob Supnik, Mark Pizzolato, and co. on the SimH pdp-11 simulator, the Simh mailing list, Warren Toomey and TUHS for making the bits available, the TUHS mailing list, PUPS, Bitsavers, and a slew of readily available documentation and texts including these notables: > > Setting Up Unix 6th Edition from the V6 Programmer's Manual > The Unix V6 Programmer's Manual in its entirety > The SimH and SimH PDP-11 Manuals > A large number of blogs with SimH specific V6 installation logs > The V6 Source Code and man pages (don't forget to install man - the 1bsd version works, and is superior)! > The DEC PDP-11/05-10-35-40 1973 Handbook (the 11/40 handbook is not as detailed with respect to memory management) > Lions's Commentary on the Sixth Edition source code > > Now that I'm over the beginner's hump, so to speak, I'm exploring things differently and I thought I'd share some resources that I am currently finding useful and interesting in my explorations... > > To bone up on assembly language, Lions's commentary is exceptionally helpful in explaining assembly as it is implemented in V6. The manual itself is really thin, and the source is a bit cryptic, for the newcomer. Lions explains the idioms used in the main source of V6. However, without a background in assembly language, Lions is pretty meaningless, so I went looking for something that was PDP specific that would bridge the gap and help me understand Lions's words. I found a number of texts that were really good. Most require a working RT11 instance to actually try out the coding examples and do the exercises (SimH and Bitsavers to the rescue): > > Arthur Gill - Machine and Assembly Language Programming of the Pdp-11 > Charles A. Kapps and Robert L. Stafford - Assembly Language for the PDP-11 > Glenn H. MacEwan - Introduction to Computer Systems: Using the PDP-11 and Pascal > James F. Peters - The Digital Way: Macro-11 Assembler Programming (PDP-11) > Michael G. Schneider - The Principles of Computer Organization: With Assembly Language Programming for the PDP-11 > PDP-11 Processor Handbook (pretty much any edition) > Thomas A. Frank - Introduction to the PDP-11 and its Assembly Language > > All of these are useable with a running RT11 instance. But, I think the Peters and Frank books are the standouts. Peters because all of the exercises that I have tried (dozens) have worked as printed and Frank because he is rigorous in his treatment of the subject and builds up from digital logic all the way through program execution. Frank is an excellent complement to Lions work because he explains the details that Lions assumes. > > To learn about digital logic, and a special thanks to Warren for his work on Crazy Small CPU, I have been introduced to logisim. It is a great playground for exploring digital logic. I had no idea that a sketchpad for digital logic simulation was available and accessible to the layperson. Logisim development stopped around 2014 and while there are a number of successors out there, I am using logisim-evolution: > > https://github.com/reds-heig/logisim-evolution > > The rabbit trails never seem to end... in order to learn how to use logisim, I went through the excellent tutorial and then went looking for a book of experiments in digital logic and found: > > digital computer lab workbook from 1969 > http://bitsavers.trailing-edge.com/pdf/dec/handbooks/Digital_Computer_Lab_Workbook_1969.pdf > > digital equipment corporation computer lab teacher's guide from 1968 > http://www.so-much-stuff.com/pdp8/pdf/ComputerLabTeachersGuide.pdf > > These two are useable with very little modification as a source of digital logic exercises that work great with logisim and are related to the architectural lineage of the PDP-11. > > These resources fit together nicely in my pursuit to better understand digital logic, the pdp-11, assembly language, and unix v6. In sum: > > Source code for v6 for what really is supposed to happen in v6 operation > Lions for understanding Unix V6 sources and for unix assembly language information > PDP-11 Hanbook for quick reference on PDP-11 assembly language instruction set > Frank for assembly language details and for details on digital logic and its relationship to the PDP-11 architecture. > Logisim to test logic constructs > The digital lab workbook for practice with digital logic > > Later, > > Will > > > > -- > GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF > Wolfgang Helbig Stauferstr. 22 71334 Waiblingen From imp at bsdimp.com Wed Jan 10 04:09:37 2018 From: imp at bsdimp.com (Warner Losh) Date: Tue, 9 Jan 2018 11:09:37 -0700 Subject: [TUHS] 2018: eighteen months to the Unix 50th anniversary In-Reply-To: <20180109003018.GB29792@minnie.tuhs.org> References: <20180109003018.GB29792@minnie.tuhs.org> Message-ID: I'm working on a long-term project to reverse engineer the sources to Venix on my Rainbow based off the now-publicly available v7 sources and recently re-surfaced disks... I suspect that the compiler is not going to happen... But lots of the rest of it might... Will make an interesting presentation... On Mon, Jan 8, 2018 at 5:30 PM, Warren Toomey wrote: > Hi all, Happy New Year. As it's now only eighteen months to the Unix 50th > Anniversary, I thought I'd poll you all to get an update of what is being > done to celebrate the anniversary, and/or what could we organise that has > not yet been organised. > > Cheers, Warren > -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Wed Jan 10 06:17:28 2018 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Tue, 09 Jan 2018 15:17:28 -0500 Subject: [TUHS] [TUHS} 2018: eighteen months of the Unix 50th anniversary Message-ID: <201801092017.w09KHSoc023473@coolidge.cs.Dartmouth.EDU> I don't think I'm violating anyone's confidentiality by revealing that Marcus Weldon, current president of the Labs, at the suggestion of Martin Carroll, expects the Labs to embark soon on plans to mark the occasion. I, and no doubt Martin, will keep you posted. Meanwhile I will be happy to forward pertinent suggestions. Doug From doug at cs.dartmouth.edu Wed Jan 10 06:39:31 2018 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Tue, 09 Jan 2018 15:39:31 -0500 Subject: [TUHS] [TUHS} 2018: eighteen months of the Unix 50th anniversary Message-ID: <201801092039.w09KdVDd023506@coolidge.cs.Dartmouth.EDU> > I will be happy to forward pertinent suggestions. Here's one. If Bell Labs holds some kind of symposium on the lines of the dmr memorial, how about a plenary session with TV participation from remote venues (think Berkeley/Silicon Valley and Wollongong/Sydney--a nine-hour span of time zones). Any thoughts about this or other possibilities? Doug From dave at horsfall.org Wed Jan 10 07:31:17 2018 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 10 Jan 2018 08:31:17 +1100 (EST) Subject: [TUHS] Happy birthday, Donald Knuth! Message-ID: Computer pioneer Donald Knuth was born on this day in 1938; amongst other things he gave us the TeX typesetting language, and he's still working on "The Art Of Computer Programming" fascicles (I only got as far as the first two volumes). I really must have a look at his new MMIX, too; I love learning new programming languages (I've used about 50 the last time I looked, and I'm happy to post a list for my coterie of disbelievers). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From crossd at gmail.com Wed Jan 10 08:56:45 2018 From: crossd at gmail.com (Dan Cross) Date: Tue, 9 Jan 2018 17:56:45 -0500 Subject: [TUHS] [TUHS} 2018: eighteen months of the Unix 50th anniversary In-Reply-To: <201801092039.w09KdVDd023506@coolidge.cs.Dartmouth.EDU> References: <201801092039.w09KdVDd023506@coolidge.cs.Dartmouth.EDU> Message-ID: I think that would be wonderful. On Tue, Jan 9, 2018 at 3:39 PM, Doug McIlroy wrote: > > I will be happy to forward pertinent suggestions. > > Here's one. If Bell Labs holds some kind of symposium on > the lines of the dmr memorial, how about a plenary > session with TV participation from remote venues (think > Berkeley/Silicon Valley and Wollongong/Sydney--a nine-hour > span of time zones). > > Any thoughts about this or other possibilities? > > Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From grog at lemis.com Wed Jan 10 13:34:59 2018 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Wed, 10 Jan 2018 14:34:59 +1100 Subject: [TUHS] 2018: eighteen months to the Unix 50th anniversary In-Reply-To: <20180109003018.GB29792@minnie.tuhs.org> References: <20180109003018.GB29792@minnie.tuhs.org> Message-ID: <20180110033459.GB27612@eureka.lemis.com> On Tuesday, 9 January 2018 at 10:30:18 +1000, Warren Toomey wrote: > Hi all, Happy New Year. As it's now only eighteen months to the Unix 50th > Anniversary, ... So we have an exact date? What happened on that day? Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From imp at bsdimp.com Wed Jan 10 14:11:39 2018 From: imp at bsdimp.com (Warner Losh) Date: Tue, 9 Jan 2018 21:11:39 -0700 Subject: [TUHS] 2018: eighteen months to the Unix 50th anniversary In-Reply-To: <20180110033459.GB27612@eureka.lemis.com> References: <20180109003018.GB29792@minnie.tuhs.org> <20180110033459.GB27612@eureka.lemis.com> Message-ID: On Tue, Jan 9, 2018 at 8:34 PM, Greg 'groggy' Lehey wrote: > On Tuesday, 9 January 2018 at 10:30:18 +1000, Warren Toomey wrote: > > Hi all, Happy New Year. As it's now only eighteen months to the Unix 50th > > Anniversary, ... > > So we have an exact date? What happened on that day? > PDP-7 Unix has a date of Jan 1, 1970 date in the TUHS tree. Wikipedia cites http://www.faqs.org/docs/artu/ch02s01.html as saying it was developed in 1969, but is not more specific. I've seen references to the summer of 1969 Ken starting to write the paper filesystem. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggm at algebras.org Wed Jan 10 15:23:04 2018 From: ggm at algebras.org (George Michaelson) Date: Wed, 10 Jan 2018 15:23:04 +1000 Subject: [TUHS] 2018: eighteen months to the Unix 50th anniversary In-Reply-To: References: <20180109003018.GB29792@minnie.tuhs.org> <20180110033459.GB27612@eureka.lemis.com> Message-ID: I'm probably a bit of a simpleton about this stuff. I feel like my engagement with UNIX has been a succession of mind-blown moments. 1978: shown a piped command. mind blown. What.The.Holy.Hell. I cannot understand this. I entered the room with punched cards. How does this even work. 1979: shown how to write macros. mind blown. This.Is.Not.A.Program.This.is.a.meta.program. What reads this? a pre processor. whats that. mind officially blown. I cannot understand. WHERE IS MY CODE 1981: made to read about the design of the IBM 360 monotonically rising clock. mind blown. How.Can.Every.Computer.Not.Have.Had.This. What does time even mean? what is negative time? Whats the granularity of time? I DONT UNDERSTAND WHY I DONT UNDERSTAND 1982: I start work on systems where I have su privilege and can change the time. Mind blown I.Can.Tell.Lies.About.Time How come? How come there isn't some magic once-only pass through hardware abacus rat-in-a-cage machine I can't lie about ITS ALL LIES mind blown. 1984: I start doing NTP and see emails from Dave Mills. Mind blown. He.Is.Not.Typing.English.As.I.Understand.It.This.Is.The.Goon.Show mind blown. But.. in a good way. People can make fun of themselves and write real code? Time is fuzzy? Time has properties? People are thinking about 2039? Mind blown. I don't even believe I will be alive in 2039 given "star wars" and "protect and survive" I really like 1/1/1970. its been like a constant in my life. If it turned out to be 1969 I'd be ok but I have to say.. a bit .. somewhere inside.. a small squirrel inside Searles 'chinese box' is saying... mind... blown... From kevin.bowling at kev009.com Wed Jan 10 16:25:32 2018 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Tue, 9 Jan 2018 23:25:32 -0700 Subject: [TUHS] 2018: eighteen months to the Unix 50th anniversary In-Reply-To: References: <20180109003018.GB29792@minnie.tuhs.org> <20180110033459.GB27612@eureka.lemis.com> Message-ID: Things like this don't really occur in one day [1] "Unix was born in 1969 not 1974" - dmr Is it fair to say 1/1/1970 is the spiritual christening and the day to celebrate? [1] http://webarchive.loc.gov/all/20100506231949/http://cm.bell-labs.com/cm/cs/who/dmr/hist.html On Tue, Jan 9, 2018 at 10:23 PM, George Michaelson wrote: > I'm probably a bit of a simpleton about this stuff. I feel like my > engagement with UNIX has been a succession of mind-blown moments. > > 1978: shown a piped command. mind blown. What.The.Holy.Hell. I cannot > understand this. I entered the room with punched cards. How does this > even work. > > 1979: shown how to write macros. mind blown. > This.Is.Not.A.Program.This.is.a.meta.program. What reads this? a pre > processor. whats that. mind officially blown. I cannot understand. > WHERE IS MY CODE > > 1981: made to read about the design of the IBM 360 monotonically > rising clock. mind blown. How.Can.Every.Computer.Not.Have.Had.This. > What does time even mean? what is negative time? Whats the granularity > of time? I DONT UNDERSTAND WHY I DONT UNDERSTAND > > 1982: I start work on systems where I have su privilege and can change > the time. Mind blown I.Can.Tell.Lies.About.Time How come? How come > there isn't some magic once-only pass through hardware abacus > rat-in-a-cage machine I can't lie about ITS ALL LIES mind blown. > > 1984: I start doing NTP and see emails from Dave Mills. Mind blown. > He.Is.Not.Typing.English.As.I.Understand.It.This.Is.The.Goon.Show mind > blown. But.. in a good way. People can make fun of themselves and > write real code? Time is fuzzy? Time has properties? People are > thinking about 2039? Mind blown. I don't even believe I will be alive > in 2039 given "star wars" and "protect and survive" > > I really like 1/1/1970. its been like a constant in my life. If it > turned out to be 1969 I'd be ok but I have to say.. a bit .. somewhere > inside.. a small squirrel inside Searles 'chinese box' is saying... > > mind... blown... From kevin.bowling at kev009.com Wed Jan 10 16:29:23 2018 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Tue, 9 Jan 2018 23:29:23 -0700 Subject: [TUHS] Happy birthday, Donald Knuth! In-Reply-To: References: Message-ID: I think it's phenomenal that he is still working on his books. It's good to have people to look up to :} On Tue, Jan 9, 2018 at 2:31 PM, Dave Horsfall wrote: > Computer pioneer Donald Knuth was born on this day in 1938; amongst other > things he gave us the TeX typesetting language, and he's still working on > "The Art Of Computer Programming" fascicles (I only got as far as the first > two volumes). > > I really must have a look at his new MMIX, too; I love learning new > programming languages (I've used about 50 the last time I looked, and I'm > happy to post a list for my coterie of disbelievers). > > -- > Dave Horsfall DTM (VK2KFU) "Those who don't understand security will > suffer." From grog at lemis.com Wed Jan 10 16:53:51 2018 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Wed, 10 Jan 2018 17:53:51 +1100 Subject: [TUHS] 2018: eighteen months to the Unix 50th anniversary In-Reply-To: References: <20180109003018.GB29792@minnie.tuhs.org> <20180110033459.GB27612@eureka.lemis.com> Message-ID: <20180110065351.GD27612@eureka.lemis.com> On Tuesday, 9 January 2018 at 23:25:32 -0700, Kevin Bowling wrote: > Things like this don't really occur in one day [1] "Unix was born in > 1969 not 1974" - dmr > > Is it fair to say 1/1/1970 is the spiritual christening and the day to > celebrate? Clearly wkt has something else in mind if he wrote "18 months". I don't think 1 January 1970 had any meaning until it became the (currently last) epoch. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From wkt at tuhs.org Wed Jan 10 20:57:58 2018 From: wkt at tuhs.org (Warren Toomey) Date: Wed, 10 Jan 2018 20:57:58 +1000 Subject: [TUHS] 2018: eighteen months to the Unix 50th anniversary In-Reply-To: <20180110065351.GD27612@eureka.lemis.com> References: <20180109003018.GB29792@minnie.tuhs.org> <20180110033459.GB27612@eureka.lemis.com> <20180110065351.GD27612@eureka.lemis.com> Message-ID: <20180110105758.GA2099@minnie.tuhs.org> On Wed, Jan 10, 2018 at 05:53:51PM +1100, Greg 'groggy' Lehey wrote: >> Is it fair to say 1/1/1970 is the spiritual christening and the day to >> celebrate? > >Clearly wkt has something else in mind if he wrote "18 months". I >don't think 1 January 1970 had any meaning until it became the >(currently last) epoch. HI all, and apologies for the delay in responding. Here's a quote from an interview that Mike Mahoney did with Ken Thompson: (http://www.tuhs.org/Archive/Documentation/OralHistory/transcripts/thompson.htm) MSM: At what point did you feel you had something here? Thompson: Um, well, the first one was not at all multiprogrammed, and was almost like subroutines on the file system. The read call, the system read call, was in fact the call "read" of the file system and it was very synchronous, just subroutine call to the file systems for these applications. And um there was a very quick rewrite that admitted it was an operating system, and it had a kernel user interface that you trapped across. I really can’t remember what the realization was, I mean, the whole time span, from initially starting with...walking downstairs, down there with the idea that we were going to build a file system. MSM: When was this, do you remember the time? Thompson: Yeah, it was the summer of ‘69. MSM: Summer of ‘69 ok Thompson: In fact um my wife went on vacation to my family’s place in California to visit my parents -- we’d just had a new son in August ‘68 -- and uh they hadn’t seen the kid so (unclear) took the kid to visit my family and she was gone a month to California and I allocated a week each to the shell, to the operating system, the shell, the editor, and the assembler, to reproduce itself. During the month she was gone, which was in the summer of ‘69, it was totally rewritten in a form that looked like an operating system, with tools that were sort of known, you know, an assembler, an editor and a shell. If not maintaining itself, right on the verge of maintaining itself, to totally sever the GECOS connection. So, while we don't have an exact date, it's reasonable to assume that, sometime around July 1969, Unix was at a point where it was self-hosting. Ken is a subscriber to this list, so maybe he might be able to help narrow down the date. Cheers all, Warren From akosela at andykosela.com Wed Jan 10 23:23:26 2018 From: akosela at andykosela.com (Andy Kosela) Date: Wed, 10 Jan 2018 07:23:26 -0600 Subject: [TUHS] 2018: eighteen months to the Unix 50th anniversary In-Reply-To: References: <20180109003018.GB29792@minnie.tuhs.org> <20180110033459.GB27612@eureka.lemis.com> Message-ID: On Wednesday, January 10, 2018, Kevin Bowling wrote: > Things like this don't really occur in one day [1] "Unix was born in > 1969 not 1974" - dmr > > Is it fair to say 1/1/1970 is the spiritual christening and the day to > celebrate? > Christians also do not know the _exact_ year when Jesus was born, but they arbitrary chose the date as the start of their Epoch. The Roman calendar before was counted ab urbe condita (from the foundation of the city, i.e., Rome) in 753 BC, so that year was the start of their Epoch. I think it is fair to say that our calendar started on 1/1/1970, and not because UNIX was born on that day, but because that day was chosen arbitrary by the Fathers of UNIX. We, as UNIX disciples, should start counting our calendar starting with the UNIX Epoch, so we have 48 and not 2018 now... --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Thu Jan 11 02:53:57 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 10 Jan 2018 09:53:57 -0700 Subject: [TUHS] 2018: eighteen months to the Unix 50th anniversary In-Reply-To: <20180110105758.GA2099@minnie.tuhs.org> References: <20180109003018.GB29792@minnie.tuhs.org> <20180110033459.GB27612@eureka.lemis.com> <20180110065351.GD27612@eureka.lemis.com> <20180110105758.GA2099@minnie.tuhs.org> Message-ID: <4c313c07-9a36-b6f9-2e90-5992c60d263a@spamtrap.tnetconsulting.net> On 01/10/2018 03:57 AM, Warren Toomey wrote: >> If not maintaining itself, right on the verge of maintaining itself, >> to totally sever the GECOS connection. > > So, while we don't have an exact date, it's reasonable to assume that, > sometime around July 1969, Unix was at a point where it was self-hosting. Somehow I was not aware that Unix was ever dependent on another OS. I get the impression that GECOS was more integral with early Unix than I had ever imagined. It sounds like more than just the GECOS field in /etc/passwd for associating Unix accounts with GECOS accounts on other machines. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From dave at horsfall.org Thu Jan 11 07:33:20 2018 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 11 Jan 2018 08:33:20 +1100 (EST) Subject: [TUHS] Happy birthday, C.A.R. Hoare! Message-ID: Sir Charles Antony Richard Hoare FRS FREng was born on this day in 1934; a computer pioneer (one of the greats) he gave us things like the quicksort algorithm and ALGOLW (a neat language). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From dave at horsfall.org Thu Jan 11 09:48:15 2018 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 11 Jan 2018 10:48:15 +1100 (EST) Subject: [TUHS] 2018: eighteen months to the Unix 50th anniversary In-Reply-To: References: <20180109003018.GB29792@minnie.tuhs.org> <20180110033459.GB27612@eureka.lemis.com> Message-ID: On Wed, 10 Jan 2018, Andy Kosela wrote: > Christians also do not know the _exact_ year when Jesus was born, but > they arbitrary chose the date as the start of their Epoch. Not really arbitrary; the dates were chosen to hijack pagan festivals, so we have Christmas at Yuletide, Easter at the Spring fertility rites, etc. No way the big JC could've been born in the middle of winter in that part of the world; try about 4BC (Halley's comet) around Spring in March or so. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From ggm at algebras.org Thu Jan 11 10:06:33 2018 From: ggm at algebras.org (George Michaelson) Date: Thu, 11 Jan 2018 10:06:33 +1000 Subject: [TUHS] 2018: eighteen months to the Unix 50th anniversary In-Reply-To: References: <20180109003018.GB29792@minnie.tuhs.org> <20180110033459.GB27612@eureka.lemis.com> Message-ID: If you're going to bring religion into it... Try this on the birth of the ICL 2900.. (by D.W. barron, 1976) http://algebras.org/ggm/oldtestament.html On Thu, Jan 11, 2018 at 9:48 AM, Dave Horsfall wrote: > On Wed, 10 Jan 2018, Andy Kosela wrote: > >> Christians also do not know the _exact_ year when Jesus was born, but they >> arbitrary chose the date as the start of their Epoch. > > > Not really arbitrary; the dates were chosen to hijack pagan festivals, so we > have Christmas at Yuletide, Easter at the Spring fertility rites, etc. > > No way the big JC could've been born in the middle of winter in that part of > the world; try about 4BC (Halley's comet) around Spring in March or so. > > > -- > Dave Horsfall DTM (VK2KFU) "Those who don't understand security will > suffer." From cym224 at gmail.com Thu Jan 11 10:20:23 2018 From: cym224 at gmail.com (Nemo) Date: Wed, 10 Jan 2018 19:20:23 -0500 Subject: [TUHS] Happy birthday, C.A.R. Hoare! In-Reply-To: References: Message-ID: On 10 January 2018 at 16:33, Dave Horsfall wrote: > Sir Charles Antony Richard Hoare FRS FREng was born on this day in 1934; a > computer pioneer (one of the greats) he gave us things like the quicksort > algorithm and ALGOLW (a neat language). Certainly agree with your opinion of Hoare but did the "W" in ALGOLW not stand for Wirth? N. From bakul at bitblocks.com Thu Jan 11 10:49:55 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Wed, 10 Jan 2018 16:49:55 -0800 Subject: [TUHS] Happy birthday, C.A.R. Hoare! In-Reply-To: Your message of "Thu, 11 Jan 2018 08:33:20 +1100." References: Message-ID: <20180111005010.8309F156E523@mail.bitblocks.com> On Thu, 11 Jan 2018 08:33:20 +1100 Dave Horsfall wrote: Dave Horsfall writes: > Sir Charles Antony Richard Hoare FRS FREng was born on this day in 1934; a > computer pioneer (one of the greats) he gave us things like the quicksort > algorithm and ALGOLW (a neat language). And conditional critical regions. And Monitors (jointly with Per Brinch Hansen). And CSP. And much more. His "an axiomatic basis for computer programming" paper was quite influential. His Turing Award lecture "Emperor's Old Clothes" is well worth (re)reading. http://zoo.cs.yale.edu/classes/cs422/2014/bib/hoare81emperor.pdf From jnc at mercury.lcs.mit.edu Thu Jan 11 11:22:48 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 10 Jan 2018 20:22:48 -0500 (EST) Subject: [TUHS] 2018: eighteen months to the Unix 50th anniversary Message-ID: <20180111012248.9B7DF18C098@mercury.lcs.mit.edu> > From: George Michaelson > Try this on the birth of the ICL 2900. Along the same lines, there's this: https://www.netjeff.com/humor/item.cgi?file=GenesisForProjects with its great closing line.. Noel From dave at horsfall.org Thu Jan 11 11:24:15 2018 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 11 Jan 2018 12:24:15 +1100 (EST) Subject: [TUHS] Happy birthday, C.A.R. Hoare! In-Reply-To: References: Message-ID: On Wed, 10 Jan 2018, Nemo wrote: > Certainly agree with your opinion of Hoare but did the "W" in ALGOLW not > stand for Wirth? Dunno, but according to https://en.wikipedia.org/wiki/ALGOL_W we have: ``ALGOL W is a programming language. It is based on a proposal for ALGOL X by Niklaus Wirth and Tony Hoare as a successor to ALGOL 60 in IFIP Working Group 2.1.'' It was a brilliant language, and it got me hooked on structural programming etc; hitherto my knowledge was confined to BASIC (shudder) and FORTRAN (double shudder). And then SNOBOL blew my mind, and PL/I, and PL/360, and Pascal, and... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From arnold at skeeve.com Thu Jan 11 18:05:03 2018 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 11 Jan 2018 01:05:03 -0700 Subject: [TUHS] Happy birthday, C.A.R. Hoare! In-Reply-To: References: Message-ID: <201801110805.w0B853sG001874@freefriends.org> Nemo wrote: > On 10 January 2018 at 16:33, Dave Horsfall wrote: > > Sir Charles Antony Richard Hoare FRS FREng was born on this day in 1934; a > > computer pioneer (one of the greats) he gave us things like the quicksort > > algorithm and ALGOLW (a neat language). > > Certainly agree with your opinion of Hoare but did the "W" in ALGOLW > not stand for Wirth? > > N. Indeed it did. Wirth did AlgolW before he did Pascal. Arnold From helbig at mailbox.org Thu Jan 11 20:21:42 2018 From: helbig at mailbox.org (helbig at mailbox.org) Date: Thu, 11 Jan 2018 11:21:42 +0100 Subject: [TUHS] Happy birthday, C.A.R. Hoare! In-Reply-To: References: Message-ID: Hi Dave, Am 11.01.2018 um 02:24 schrieb Dave Horsfall : > On Wed, 10 Jan 2018, Nemo wrote: > >> Certainly agree with your opinion of Hoare but did the "W" in ALGOLW not stand for Wirth? > > Dunno, but according to https://en.wikipedia.org/wiki/ALGOL_W we have: > > ``ALGOL W is a programming language. It is based on a proposal for ALGOL X > by Niklaus Wirth and Tony Hoare as a successor to ALGOL 60 in IFIP > Working Group 2.1.'' As Hoare reported in his Turing Award Lecture "The Emperors Old Clothes" http://zoo.cs.yale.edu/classes/cs422/2014/bib/hoare81emperor.pdf, Wirth soley designed Algol W based on proposals of a small group of which Hoare was a member. Greetings Wolfgang -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Fri Jan 12 07:45:30 2018 From: clemc at ccc.com (Clem Cole) Date: Thu, 11 Jan 2018 16:45:30 -0500 Subject: [TUHS] 2018: eighteen months to the Unix 50th anniversary In-Reply-To: <20180111012248.9B7DF18C098@mercury.lcs.mit.edu> References: <20180111012248.9B7DF18C098@mercury.lcs.mit.edu> Message-ID: Definitely a classic. ᐧ On Wed, Jan 10, 2018 at 8:22 PM, Noel Chiappa wrote: > > From: George Michaelson > > > Try this on the birth of the ICL 2900. > > Along the same lines, there's this: > > https://www.netjeff.com/humor/item.cgi?file=GenesisForProjects > > with its great closing line.. > > Noel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Fri Jan 12 07:50:40 2018 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 12 Jan 2018 08:50:40 +1100 (EST) Subject: [TUHS] Happy birthday, C.A.R. Hoare! In-Reply-To: <20180111005010.8309F156E523@mail.bitblocks.com> References: <20180111005010.8309F156E523@mail.bitblocks.com> Message-ID: On Wed, 10 Jan 2018, Bakul Shah wrote: > And conditional critical regions. And Monitors (jointly with Per Brinch > Hansen). And CSP. And much more. His "an axiomatic basis for computer > programming" paper was quite influential. His Turing Award lecture > "Emperor's Old Clothes" is well worth (re)reading. Noted; thanks. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From robert at timetraveller.org Fri Jan 12 08:08:32 2018 From: robert at timetraveller.org (Robert Brockway) Date: Fri, 12 Jan 2018 08:08:32 +1000 (AEST) Subject: [TUHS] 2018: eighteen months to the Unix 50th anniversary In-Reply-To: References: <20180109003018.GB29792@minnie.tuhs.org> <20180110033459.GB27612@eureka.lemis.com> Message-ID: On Thu, 11 Jan 2018, Dave Horsfall wrote: > No way the big JC could've been born in the middle of winter in that part of > the world; try about 4BC (Halley's comet) around Spring in March or so. Quite right. I was there in winter and got snowed in for 3 days at a kibbutz near Jerusalem. I'd also like to endorse the Holocene Calendar at this point since it results in all events since the development of agriculture having a positive date. Much easier for comparison. https://en.wikipedia.org/wiki/Holocene_calendar OnUNIX: Development of UNIX started in 11969HE. See, perfectly sensible. Rob From lars at nocrew.org Fri Jan 12 18:44:26 2018 From: lars at nocrew.org (Lars Brinkhoff) Date: Fri, 12 Jan 2018 08:44:26 +0000 Subject: [TUHS] origin of C header files Message-ID: <7w1sivv53p.fsf@junk.nocrew.org> The book "Expert C Programming" claims Alan Snyder suggested the addition of a preprocessor. From will.senn at gmail.com Mon Jan 15 05:56:34 2018 From: will.senn at gmail.com (Will Senn) Date: Sun, 14 Jan 2018 13:56:34 -0600 Subject: [TUHS] Some resources for V6/PDP/SIMH newbs like me In-Reply-To: References: Message-ID: <11cf6036-0863-7219-1fbe-84ed824fa0bb@gmail.com> On 1/9/18 12:05 PM, Wolfgang Helbig wrote: > Hi, Will > > may I point to chapter 1.0 of my operating system lecture notes at: > http://doc.cat-v.org/unix/v6/operating-systems-lecture-notes/script/ > > among others, it explains the assembler language, together with the description of the instruction set > > http://doc.cat-v.org/unix/v6/operating-systems-lecture-notes/pdp11/doc/cpu > > and finally the Unix Assembler Reference Manual(1) at > http://doc.cat-v.org/unix/v6/operating-systems-lecture-notes/v6/doc/index.html > > might help. > > Greetings, > Wolfgang Wolfgang, Your notes are great references. When I first started learning about v6, yours was the first truly helpful site that I came across. In addition to the enormously useful UPM and notes above, I really appreciate your PDP 11 devices note: http://doc.cat-v.org/unix/v6/operating-systems-lecture-notes/pdp11/doc/devs Later, Will From arrigo at alchemistowl.org Wed Jan 17 20:26:50 2018 From: arrigo at alchemistowl.org (Arrigo Triulzi) Date: Wed, 17 Jan 2018 11:26:50 +0100 Subject: [TUHS] Scot Hacker's 1999-2001 "BeView" columns for Byte.com (BeOS) Message-ID: <9AC6DC0A-6494-4B59-BD94-DD24203E6354@alchemistowl.org> Scot Hacker has re-published his BeOS columns for Byte. BeOS was an interesting operating system with a clear Unix inheritance built for a dual-PowerPC system, similar to the Macs of that era. http://birdhouse.org/beos/byte/ Its inheritance can be found in Haiku (https://www.haiku-os.org). Arrigo From cym224 at gmail.com Thu Jan 18 04:32:23 2018 From: cym224 at gmail.com (Nemo) Date: Wed, 17 Jan 2018 13:32:23 -0500 Subject: [TUHS] Scot Hacker's 1999-2001 "BeView" columns for Byte.com (BeOS) In-Reply-To: <9AC6DC0A-6494-4B59-BD94-DD24203E6354@alchemistowl.org> References: <9AC6DC0A-6494-4B59-BD94-DD24203E6354@alchemistowl.org> Message-ID: On 17 January 2018 at 05:26, Arrigo Triulzi wrote: > Scot Hacker has re-published his BeOS columns for Byte. BeOS was an interesting > operating system with a clear Unix inheritance built for a dual-PowerPC system, > similar to the Macs of that era. Not just dual-PPC. I ran an early copy on my Motorola Apple-clone. N. > http://birdhouse.org/beos/byte/ > > Its inheritance can be found in Haiku (https://www.haiku-os.org). > > Arrigo > From arrigo at alchemistowl.org Thu Jan 18 04:54:19 2018 From: arrigo at alchemistowl.org (Arrigo Triulzi) Date: Wed, 17 Jan 2018 19:54:19 +0100 Subject: [TUHS] Scot Hacker's 1999-2001 "BeView" columns for Byte.com (BeOS) In-Reply-To: References: <9AC6DC0A-6494-4B59-BD94-DD24203E6354@alchemistowl.org> Message-ID: <507B30A4-6923-4DA3-A7CE-3E0AEE991791@alchemistowl.org> On 17 Jan 2018, at 19:32, Nemo wrote: > >> On 17 January 2018 at 05:26, Arrigo Triulzi wrote: >> Scot Hacker has re-published his BeOS columns for Byte. BeOS was an interesting >> operating system with a clear Unix inheritance built for a dual-PowerPC system, >> similar to the Macs of that era. > > Not just dual-PPC. I ran an early copy on my Motorola Apple-clone. Should have clarified: the original BeBox was a dual-PPC system. BeOS also ran on PREP and other Mac clones (as did, briefly, MacOS…). Arrigo From dave at horsfall.org Fri Jan 19 08:44:10 2018 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 19 Jan 2018 09:44:10 +1100 (EST) Subject: [TUHS] Happy birthday, John Lions! Message-ID: Dr. Prof. John Lions was born on this day in 1937; I had the pleasure of having him as one of my Computer Science lecturers in the early 70s, and he drilled into us the Principle of Least Astonishment (or POLA), better known as "why the fsck did it do that?" (but he was far too genteel to express it that way). And yes, that's my name in the credits; I helped with the proof-reading and provided the use of the high-quality printer in the CSU. You are not expected to understand this. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From wkt at tuhs.org Fri Jan 19 08:50:09 2018 From: wkt at tuhs.org (Warren Toomey) Date: Fri, 19 Jan 2018 08:50:09 +1000 Subject: [TUHS] Happy birthday, John Lions! In-Reply-To: References: Message-ID: <9C91DBF6-E535-48A1-8DDF-8AFCF56C23AF@tuhs.org> I do :-) Warren On 19 January 2018 8:44:10 am AEST, Dave Horsfall wrote: >Dr. Prof. John Lions was born on this day in 1937; I had the pleasure >of >having him as one of my Computer Science lecturers in the early 70s, >and >he drilled into us the Principle of Least Astonishment (or POLA), >better >known as "why the fsck did it do that?" (but he was far too genteel to >express it that way). And yes, that's my name in the credits; I helped > >with the proof-reading and provided the use of the high-quality printer >in >the CSU. > >You are not expected to understand this. > >-- >Dave Horsfall DTM (VK2KFU) "Those who don't understand security will >suffer." -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Sat Jan 20 09:06:43 2018 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 20 Jan 2018 10:06:43 +1100 (EST) Subject: [TUHS] RIP Ed Yourdon Message-ID: We lost Ed Yourdon on this day in 2016; a computer pioneer, he helped to design the underpinnings of relational databases, and pretty much wrote the book. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From cym224 at gmail.com Sat Jan 20 12:51:58 2018 From: cym224 at gmail.com (Nemo) Date: Fri, 19 Jan 2018 21:51:58 -0500 Subject: [TUHS] RIP Ed Yourdon In-Reply-To: References: Message-ID: On 19/01/2018, Dave Horsfall wrote: > We lost Ed Yourdon on this day in 2016; a computer pioneer, he helped to > design the underpinnings of relational databases, and pretty much wrote > the book. Oh. somehow I missed this sad event. Last week, I was organising my library and found his book on YSM. N. > -- > Dave Horsfall DTM (VK2KFU) "Those who don't understand security will > suffer." > From imp at bsdimp.com Sun Jan 21 04:11:24 2018 From: imp at bsdimp.com (Warner Losh) Date: Sat, 20 Jan 2018 11:11:24 -0700 Subject: [TUHS] Kernel Sizes Message-ID: For a presentation I'm doing this summer on FreeBSD, I thought it would be cool to get the kernel sizes for various old flavors of Unix. I see numbers for v5, v6 and v7 in the tuhs tree view, and it appears these versions are complete enough for me to extract the kernels themselves. However, I see nothing prior to that. The archives seem to be somewhat incomplete, but I'm wondering if people have sizes for earlier versions. Later versions are more problematic because they move to new hardware, instruction sets, etc. For this graph to be meaningful, it would need to be pdp-11 only, though I'm of the opinion more data is better than less. I'll also be extracting the different V7 commercial kernels: V7M, Ultrix and Venix and the BSD 2.x releases, but those appear to be intact enough in the archives to extract data on my own. I've heard rumors there's a SysV for the pdp-11, but I've not been able to locate images for that. I don't need the actual images, just sizes with some reference for the source of the data. It's just for one slide in the talk, so I don't want to burn a ton of time on it... The larger picture is that I've written what's effectively modprobe for FreeBSD and will be talking about it in detail. How it's like modprobe, how it's different, how all the pieces fit together, history of similar efforts, etc. Part of the driving force here is the bloated FreeBSD GENERIC kernel. Of course, I'll share the final report I'm planning on sizes with the group. Thanks for any data you can provide. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From mutiny.mutiny at india.com Sun Jan 21 04:33:34 2018 From: mutiny.mutiny at india.com (Donald ODona) Date: Sat, 20 Jan 2018 18:33:34 +0000 (UTC) Subject: [TUHS] Kernel Sizes In-Reply-To: References: Message-ID: <778551886.7260.1516473214699.JavaMail.tomcat@india-live-be03> At 20 Jan 2018 18:12:45 +0000 (+00:00) from Warner Losh : > For a presentation I'm doing this summer on FreeBSD, I thought it would be bsd4.3 289792 V7 55876 SysVr3 702832 From random832 at fastmail.com Sun Jan 21 05:22:27 2018 From: random832 at fastmail.com (Random832) Date: Sat, 20 Jan 2018 14:22:27 -0500 Subject: [TUHS] Kernel Sizes In-Reply-To: References: Message-ID: <1516476147.3105555.1242251720.684D327E@webmail.messagingengine.com> On Sat, Jan 20, 2018, at 13:11, Warner Losh wrote: > For a presentation I'm doing this summer on FreeBSD, I thought it would be > cool to get the kernel sizes for various old flavors of Unix. I see numbers > for v5, v6 and v7 in the tuhs tree view, and it appears these versions are > complete enough for me to extract the kernels themselves. However, I see > nothing prior to that. There is a possibly V2 era kernel (two, actually) on the s1-bits tape image, but it's been too long since I looked at this and I don't recall exactly how to extract them. I posted about this at the time, but there wasn't any interest - I'd determined that s1 was in fact an "init tape" as described in V1 boot.7 and V3 bproc.8. Those manpages do mention the size that was allocated on disk/tape for each kernel in those eras: 6K and 7-8K words [so twice that number of bytes], respectively. To determine how much headroom was in this allocation, I just now went through and checked the s1-bits file for empty 512-byte blocks. It consists of 25 blocks of data (12800 bytes), followed by 4 blocks of zeros. I think that region of the tape was the bootloaders followed by the "cold boot" kernel. Then there are 22 blocks (11264 bytes) of data [then 10 blocks zeros], which was IIRC the other kernel (the "warm boot" kernel, which did not contain code for reinitializing the filesystem). The rest of the tape (not kernel images) is 490 blocks (245 KB) of data, followed by 27 blocks of 0xFF. From michael at kjorling.se Sun Jan 21 07:14:16 2018 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Sat, 20 Jan 2018 21:14:16 +0000 Subject: [TUHS] Kernel Sizes In-Reply-To: References: Message-ID: <20180120211416.GA13685@h-174-65.A328.priv.bahnhof.se> On 20 Jan 2018 11:11 -0700, from imp at bsdimp.com (Warner Losh): > For a presentation I'm doing this summer on FreeBSD, I thought it would be > cool to get the kernel sizes for various old flavors of Unix. I see numbers > for v5, v6 and v7 in the tuhs tree view, and it appears these versions are > complete enough for me to extract the kernels themselves. However, I see > nothing prior to that. The archives seem to be somewhat incomplete, but I'm > wondering if people have sizes for earlier versions. https://github.com/dspinellis/unix-history-repo/tree/Research-V1-Snapshot-Development looks like it might be useful. It's possible that Warren might want to add some of that to the TUHS archives as well. -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “The most dangerous thought that you can have as a creative person is to think you know what you’re doing.” (Bret Victor) From wkt at tuhs.org Sun Jan 21 10:19:28 2018 From: wkt at tuhs.org (Warren Toomey) Date: Sun, 21 Jan 2018 10:19:28 +1000 Subject: [TUHS] Kernel Sizes In-Reply-To: References: Message-ID: <20180121001928.GA6495@minnie.tuhs.org> On Sat, Jan 20, 2018 at 11:11:24AM -0700, Warner Losh wrote: > For a presentation I'm doing this summer on FreeBSD, I thought it would > be cool to get the kernel sizes for various old flavors of Unix. I see > numbers for v5, v6 and v7 in the tuhs tree view, and it appears these > versions are complete enough for me to extract the kernels themselves. > However, I see nothing prior to that. Github has this project: https://github.com/DoctorWkt/unix-jun72 with a June 1972 Unix kernel. Doing a "make", the generated build/unix is: -rwxrwxrwx 1 wkt wkt 36432 Jan 21 10:10 build/unix but I don't have a PDP-11 "size" command to give details. http://www.tuhs.org/Archive/Distributions/Research/Dennis_v3/ has a Unix system written in C, timestamped August 31, 1973 (just before Fourth Edition). Inside nsys.tar.gz you will find: -rw-r--r-- 0/0 26820 1973-09-24 03:41 u which is the kernel image. Unfortunately, we don't have a kernel from 1st Edition or 4th Edition. Cheers, Warren From akosela at andykosela.com Sun Jan 21 11:41:45 2018 From: akosela at andykosela.com (Andy Kosela) Date: Sat, 20 Jan 2018 19:41:45 -0600 Subject: [TUHS] Kernel Sizes In-Reply-To: <20180121001928.GA6495@minnie.tuhs.org> References: <20180121001928.GA6495@minnie.tuhs.org> Message-ID: On Saturday, January 20, 2018, Warren Toomey wrote: > On Sat, Jan 20, 2018 at 11:11:24AM -0700, Warner Losh wrote: > >> For a presentation I'm doing this summer on FreeBSD, I thought it would >> be cool to get the kernel sizes for various old flavors of Unix. I see >> numbers for v5, v6 and v7 in the tuhs tree view, and it appears these >> versions are complete enough for me to extract the kernels themselves. >> However, I see nothing prior to that. >> > > Github has this project: https://github.com/DoctorWkt/unix-jun72 > with a June 1972 Unix kernel. Doing a "make", the generated build/unix is: > > -rwxrwxrwx 1 wkt wkt 36432 Jan 21 10:10 build/unix > > but I don't have a PDP-11 "size" command to give details. > > http://www.tuhs.org/Archive/Distributions/Research/Dennis_v3/ has a Unix > system written in C, timestamped August 31, 1973 (just before Fourth > Edition). > Inside nsys.tar.gz you will find: > > -rw-r--r-- 0/0 26820 1973-09-24 03:41 u > > which is the kernel image. > > Unfortunately, we don't have a kernel from 1st Edition or 4th Edition. > > > Comparing size of kernels is cool and fun, but IMHO comparing system calls is a more valuable metric as to measure the kernel bloat. It would be interesting to compare number of implemented system calls in various UNIX operating systems along with those kernel sizes, e.g., V7 had around 50 system calls, current FreeBSD and Linux have more than 500... --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Sun Jan 21 11:51:55 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Sat, 20 Jan 2018 18:51:55 -0700 Subject: [TUHS] OT - Has anyone seen / have a copy of computer lore story about a DC consolidation? Message-ID: Sorry for the off topic post. I'm hoping that someone here might have seen a (what I consider to be) a computer lore type story about a contractor that was brought in part way through a project to consolidate three DCs into one. - In the end he managed to do it early and under budget. The kicker is that they quite literally physically moved and re-connected everything the way that it was. Meaning that there were still WAN circuits (local only of course) between equipment that was previously in different DCs. I would like to find a copy of this story and save it in my archive. But I've not been able to do so. Thus I'm asking a wider audience to see if anyone might be able to give me a pointer. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From drsalists at gmail.com Sun Jan 21 12:08:43 2018 From: drsalists at gmail.com (Dan Stromberg) Date: Sat, 20 Jan 2018 18:08:43 -0800 Subject: [TUHS] Kernel Sizes In-Reply-To: References: Message-ID: On Sat, Jan 20, 2018 at 10:11 AM, Warner Losh wrote: > For a presentation I'm doing this summer on FreeBSD, I thought it would be > cool to get the kernel sizes for various old flavors of Unix. I see numbers You might find http://stromberg.dnsalias.org/~strombrg/working-set/ interesting. It intentionally fills virtual memory, and measures how much must must be malloc'd and filled with gibberish, to cause thrashing. Subtracting that from the amount of physmem in the machine, gives a sort of measure of OS overhead. From imp at bsdimp.com Sun Jan 21 14:24:27 2018 From: imp at bsdimp.com (Warner Losh) Date: Sat, 20 Jan 2018 21:24:27 -0700 Subject: [TUHS] Kernel Sizes In-Reply-To: References: Message-ID: On Sat, Jan 20, 2018 at 7:13 PM, Steve Johnson wrote: > While you're at it, I heard once that the latest GCC *manual* (>500 pp at > last look) was larger than "the whole Unix distribution". Is there any > truth to that? > compressed (gz), the entire v7 tape 3.5MB. The compressed (gz) source is 250k. Uncompressed tape is 11.5MB while the source is 1.1MB. gcc 7.2.0 compressed (gz) is 105MB. gcc/doc directory is 13.5MB: % tar tvf gcc-7.2.0.tar.xz gcc-7.2.0/gcc/doc | awk '{a += $5;} END {print a;}' 13,470,317 So yea, gcc 7.2 manual is larger than the v7 distribution tapes. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From scj at yaccman.com Sun Jan 21 12:13:55 2018 From: scj at yaccman.com (Steve Johnson) Date: Sat, 20 Jan 2018 18:13:55 -0800 Subject: [TUHS] Kernel Sizes In-Reply-To: Message-ID: While you're at it, I heard once that the latest GCC *manual* (>500 pp at last look) was larger than "the whole Unix distribution".  Is there any truth to that? Steve ----- Original Message ----- From: "Dan Stromberg" To:"Warner Losh" Cc:"The Eunuchs Hysterical Society" Sent:Sat, 20 Jan 2018 18:08:43 -0800 Subject:Re: [TUHS] Kernel Sizes On Sat, Jan 20, 2018 at 10:11 AM, Warner Losh wrote: > For a presentation I'm doing this summer on FreeBSD, I thought it would be > cool to get the kernel sizes for various old flavors of Unix. I see numbers You might find http://stromberg.dnsalias.org/~strombrg/working-set/ interesting. It intentionally fills virtual memory, and measures how much must must be malloc'd and filled with gibberish, to cause thrashing. Subtracting that from the amount of physmem in the machine, gives a sort of measure of OS overhead. -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Mon Jan 22 02:51:29 2018 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sun, 21 Jan 2018 11:51:29 -0500 Subject: [TUHS] Subject: Re: KernelSizesA self-imposed limit of 16K held in v1, and was quite fullyutilized.Subject:Re: Kernel Sizes Message-ID: <201801211651.w0LGpTx4011480@coolidge.cs.Dartmouth.EDU> A self-imposed limit of 16K held in v1, and was quite fully utilized. When the iernel was rewritten in C, the limit (perhaps larger by then) influenced the C compiler. More than one optimization was stimulated by the need to keep the kernel in bounds. Doug From imp at bsdimp.com Mon Jan 22 05:44:53 2018 From: imp at bsdimp.com (Warner Losh) Date: Sun, 21 Jan 2018 12:44:53 -0700 Subject: [TUHS] Subject: Re: KernelSizesA self-imposed limit of 16K held in v1, and was quite fullyutilized.Subject:Re: Kernel Sizes In-Reply-To: <201801211651.w0LGpTx4011480@coolidge.cs.Dartmouth.EDU> References: <201801211651.w0LGpTx4011480@coolidge.cs.Dartmouth.EDU> Message-ID: On Sun, Jan 21, 2018 at 9:51 AM, Doug McIlroy wrote: > > A self-imposed limit of 16K held in v1, and was quite fully utilized. > When the iernel was rewritten in C, the limit (perhaps larger by then) > influenced the C compiler. More than one optimization was stimulated > by the need to keep the kernel in bounds. > 16k words or 16k bytes? Given some of the other reported sizes I'm guessing it's bytes. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From scj at yaccman.com Mon Jan 22 06:48:15 2018 From: scj at yaccman.com (Steve Johnson) Date: Sun, 21 Jan 2018 12:48:15 -0800 Subject: [TUHS] Subject: Re: KernelSizesA self-imposed limit of 16K held in v1, and was quite fullyutilized.Subject:Re: Kernel Sizes In-Reply-To: <201801211651.w0LGpTx4011480@coolidge.cs.Dartmouth.EDU> Message-ID: I seem to remember that at some point early on, we spent some of our capital budget on buying another 16K bytes for the PDP-11.  As I recall, the deal was that the OS got 8K and users got 8K.  I also recall that that purchase was 20% of our capital budget for the year... Doug, did I remember this correctly? Steve ----- Original Message ----- From: "Doug McIlroy" To: Cc: Sent:Sun, 21 Jan 2018 11:51:29 -0500 Subject:[TUHS] Subject: Re: KernelSizesA self-imposed limit of 16K held in v1, and was quite fullyutilized.Subject:Re: Kernel Sizes A self-imposed limit of 16K held in v1, and was quite fully utilized. When the iernel was rewritten in C, the limit (perhaps larger by then) influenced the C compiler. More than one optimization was stimulated by the need to keep the kernel in bounds. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Mon Jan 22 08:03:17 2018 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sun, 21 Jan 2018 17:03:17 -0500 Subject: [TUHS] Kernel Sizes Message-ID: <201801212203.w0LM3Haq013769@coolidge.cs.Dartmouth.EDU> >> A self-imposed limit of 16K held in v1 > 16k words or 16k bytes? Bytes. doug From doug at cs.dartmouth.edu Mon Jan 22 08:36:05 2018 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sun, 21 Jan 2018 17:36:05 -0500 Subject: [TUHS] Kernel Sizes Message-ID: <201801212236.w0LMa5qG013807@coolidge.cs.Dartmouth.EDU> > I seem to remember that at some point early on, we spent some of our > capital budget on buying another 16K bytes for the PDP-11.  As I > recall, the deal was that the OS got 8K and users got 8K.  I also > recall that that purchase was 20% of our capital budget for the > year... > Doug, did I remember this correctly? > Steve Things did happen that way. I don't specifically remember the numbers, but those you state have the ring of truth. Memory came in (expensive) 4K increments. When the keepers of Unix in the Charlotte wire center wanted to add 4K, their management consented only on the condition that the wizards in Research would confirm that roposed new functionality really required it. doug From grog at lemis.com Mon Jan 22 08:53:08 2018 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Mon, 22 Jan 2018 09:53:08 +1100 Subject: [TUHS] Kernel Sizes In-Reply-To: References: Message-ID: <20180121225308.GD14536@eureka.lemis.com> On Saturday, 20 January 2018 at 21:24:27 -0700, Warner Losh wrote: > On Sat, Jan 20, 2018 at 7:13 PM, Steve Johnson wrote: > >> While you're at it, I heard once that the latest GCC *manual* (>500 pp at >> last look) was larger than "the whole Unix distribution". Is there any >> truth to that? >> > > compressed (gz), the entire v7 tape 3.5MB. The compressed (gz) source is > 250k. Uncompressed tape is 11.5MB while the source is 1.1MB. > > gcc 7.2.0 compressed (gz) is 105MB. gcc/doc directory is 13.5MB: > >> tar tvf gcc-7.2.0.tar.xz gcc-7.2.0/gcc/doc | awk '{a += $5;} END {print > a;}' > 13,470,317 > > So yea, gcc 7.2 manual is larger than the v7 distribution tapes. It would be interesting to compare llvm. Here are the most recent FreeBSD packages (effectively installation tarballs). gcc pales by comparison: -rw-r--r-- 1 root wheel 90,805,148 23 Sep 15:53 /var/cache/pkg/gcc6-6.4.0_1-13072ceeab.txz -rw-r--r-- 1 root wheel 90,819,108 30 Sep 15:18 /var/cache/pkg/gcc6-6.4.0_2-d83317c1d0.txz -rw-r--r-- 1 root wheel 305,101,072 16 Nov 18:30 /var/cache/pkg/llvm40-4.0.1_4-06c71eb2eb.txz -rw-r--r-- 1 root wheel 341,208,492 19 Dec 17:05 /var/cache/pkg/llvm50-5.0.0_6-b3fff834c7.txz Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From pnr at planet.nl Mon Jan 22 09:42:53 2018 From: pnr at planet.nl (Paul Ruizendaal) Date: Mon, 22 Jan 2018 00:42:53 +0100 Subject: [TUHS] Kernel Sizes In-Reply-To: References: Message-ID: <39C0AA03-1D57-470E-8D40-58DF7EEC0EFE@planet.nl> > A self-imposed limit of 16K held in v1, and was quite fully utilized. > When the iernel was rewritten in C, the limit (perhaps larger by then) > influenced the C compiler. More than one optimization was stimulated > by the need to keep the kernel in bounds. > > Doug The LSX kernel was kept within a self-imposed limit of 16KB as well. I've often thought that LSX was V5 'regressed' to the concepts of V1, which was facing similar hardware constraints. Is that a reasonable view? For example, LSX has a maximum of three processes that are swapped in and out in a stack-like fashion. Only one process is ever in core. Is that how V1 was organized? I realize that LSX was API compatible with V5/V6 and I don't mean 'regressed' in that sense. Paul From usotsuki at buric.co Mon Jan 22 11:19:08 2018 From: usotsuki at buric.co (Steve Nickolas) Date: Sun, 21 Jan 2018 20:19:08 -0500 (EST) Subject: [TUHS] Kernel Sizes In-Reply-To: <20180121225308.GD14536@eureka.lemis.com> References: <20180121225308.GD14536@eureka.lemis.com> Message-ID: On Mon, 22 Jan 2018, Greg 'groggy' Lehey wrote: > On Saturday, 20 January 2018 at 21:24:27 -0700, Warner Losh wrote: >> On Sat, Jan 20, 2018 at 7:13 PM, Steve Johnson wrote: >> >>> While you're at it, I heard once that the latest GCC *manual* (>500 pp at >>> last look) was larger than "the whole Unix distribution". Is there any >>> truth to that? >>> >> >> compressed (gz), the entire v7 tape 3.5MB. The compressed (gz) source is >> 250k. Uncompressed tape is 11.5MB while the source is 1.1MB. >> >> gcc 7.2.0 compressed (gz) is 105MB. gcc/doc directory is 13.5MB: >> >>> tar tvf gcc-7.2.0.tar.xz gcc-7.2.0/gcc/doc | awk '{a += $5;} END {print >> a;}' >> 13,470,317 >> >> So yea, gcc 7.2 manual is larger than the v7 distribution tapes. > > It would be interesting to compare llvm. Here are the most recent > FreeBSD packages (effectively installation tarballs). gcc pales by > comparison: > > -rw-r--r-- 1 root wheel 90,805,148 23 Sep 15:53 /var/cache/pkg/gcc6-6.4.0_1-13072ceeab.txz > -rw-r--r-- 1 root wheel 90,819,108 30 Sep 15:18 /var/cache/pkg/gcc6-6.4.0_2-d83317c1d0.txz > -rw-r--r-- 1 root wheel 305,101,072 16 Nov 18:30 /var/cache/pkg/llvm40-4.0.1_4-06c71eb2eb.txz > -rw-r--r-- 1 root wheel 341,208,492 19 Dec 17:05 /var/cache/pkg/llvm50-5.0.0_6-b3fff834c7.txz Yikes, and I thought *GNU* sofware was a pig. o.O -uso. From imp at bsdimp.com Mon Jan 22 13:51:01 2018 From: imp at bsdimp.com (Warner Losh) Date: Sun, 21 Jan 2018 20:51:01 -0700 Subject: [TUHS] Kernel Sizes In-Reply-To: <20180121001928.GA6495@minnie.tuhs.org> References: <20180121001928.GA6495@minnie.tuhs.org> Message-ID: On Sat, Jan 20, 2018 at 5:19 PM, Warren Toomey wrote: > Unfortunately, we don't have a kernel from 1st Edition or 4th Edition. > Do we have v8, v9 or v10 kernels? I looked at the tarballs in the archives and couldn't find unix, bsd, or kernel in any of them. Is there some name that's used that I've managed to miss out on? Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Mon Jan 22 14:39:52 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Sun, 21 Jan 2018 21:39:52 -0700 Subject: [TUHS] Kernel Sizes In-Reply-To: References: <20180121001928.GA6495@minnie.tuhs.org> Message-ID: Weren’t these (or their source code) recently released by the IP owner? Virtually Fun has an article about installing and running v8, including an image. https://virtuallyfun.com/2017/03/30/research-unix-v8/ I expect you can find more there and the TUHS pages that he references. -- Grant. . . . unix || die -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2338 bytes Desc: not available URL: From imp at bsdimp.com Mon Jan 22 16:53:13 2018 From: imp at bsdimp.com (Warner Losh) Date: Sun, 21 Jan 2018 23:53:13 -0700 Subject: [TUHS] Kernel Sizes In-Reply-To: References: <20180121001928.GA6495@minnie.tuhs.org> Message-ID: On Jan 21, 2018 9:40 PM, "Grant Taylor via TUHS" wrote: Weren’t these (or their source code) recently released by the IP owner? Virtually Fun has an article about installing and running v8, including an image. https://virtuallyfun.com/2017/03/30/research-unix-v8/ I expect you can find more there and the TUHS pages that he references. I've already looked. There is the source but no kernels... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Mon Jan 22 18:10:11 2018 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 22 Jan 2018 01:10:11 -0700 Subject: [TUHS] OT: Need help from a *BSD guru Message-ID: <201801220810.w0M8ABbq002485@freefriends.org> Hi. Can a modern BSD guru please contact me off-list? I have a set of related tests in the gawk test suite that consistently fail on just about every *BSD system. It has me stumped, and I'd like to see these tests working if possible. (They've been not working for quite a while. That I get no complaints from BSD users tells me that gawk isn't popular in that world, but that's another story. :-) Thanks, Arnold From rudi.j.blom at gmail.com Mon Jan 22 20:46:33 2018 From: rudi.j.blom at gmail.com (Rudi Blom) Date: Mon, 22 Jan 2018 17:46:33 +0700 Subject: [TUHS] Kernel Sizes Message-ID: 16K kernels? Well, I came late to the UNIX world. I only remember getting a SCO UNIX 3.2V4.2 kernel onto a single 3-1/2" diskette and still have all I wanted including (with scripts on a second diskette of course :-) ). That was 25 years ago. Mind you, from there I moved to Digital UNIX /vmunix 9,613.712, Tru64 17.930.976 to HP-UX 11iv2 66.161.464 and HP-UX 11iv3 127.929.032 Of course, I also got lots more functionality I'm supposed to want and need :-) Cheers, rudi From doug at cs.dartmouth.edu Mon Jan 22 22:31:54 2018 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Mon, 22 Jan 2018 07:31:54 -0500 Subject: [TUHS] !mail tuhs@minnie.tuhs.org Message-ID: <201801221231.w0MCVsjq019507@coolidge.cs.Dartmouth.EDU> Re: [TUHS] Kernel Sizes > I've often thought that LSX was V5 'regressed' to the concepts of > V1, which was facing similar hardware constraints. Is that a > reasonable view? > LSX has a maximum of three processes that are swapped > in and out in a stack-like fashion. Only one process is ever in core. > Is that how V1 was organized? The rocess limit was higher in V1. And V1 was a time-sharing system; for which LIFO swapping is inappropriate. So LSX seems to have "regressed" to some pre-Unix state. doug From arnold at skeeve.com Tue Jan 23 00:36:05 2018 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 22 Jan 2018 07:36:05 -0700 Subject: [TUHS] OT: Need help from a *BSD guru In-Reply-To: <201801220810.w0M8ABbq002485@freefriends.org> References: <201801220810.w0M8ABbq002485@freefriends.org> Message-ID: <201801221436.w0MEa5Jt005358@freefriends.org> Hi All. Looks like I solved my problem on my own; thanks to everyone who replied privately. I will send a short note detailing the issue a little later. Thanks! Arnold arnold at skeeve.com wrote: > Hi. > > Can a modern BSD guru please contact me off-list? I have a set of related > tests in the gawk test suite that consistently fail on just about every > *BSD system. It has me stumped, and I'd like to see these tests working > if possible. > > (They've been not working for quite a while. That I get no complaints > from BSD users tells me that gawk isn't popular in that world, but that's > another story. :-) > > Thanks, > > Arnold From itz at very.loosely.org Tue Jan 23 04:03:27 2018 From: itz at very.loosely.org (Ian Zimmerman) Date: Mon, 22 Jan 2018 10:03:27 -0800 Subject: [TUHS] OT: Need help from a *BSD guru In-Reply-To: <201801221436.w0MEa5Jt005358@freefriends.org> References: <201801220810.w0M8ABbq002485@freefriends.org> <201801221436.w0MEa5Jt005358@freefriends.org> Message-ID: <20180122180327.njqe3z4f7bwfytln@matica.foolinux.mooo.com> On 2018-01-22 07:36, arnold at skeeve.com wrote: > Looks like I solved my problem on my own; thanks to everyone who > replied privately. I will send a short note detailing the issue > a little later. Probably an unnecessary reminder, but could you post about it (the problem and the solution) to the Usenet newsgroup comp.lang.awk as well? Thanks. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet, fetch the TXT record for the domain. From arnold at skeeve.com Tue Jan 23 05:07:43 2018 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 22 Jan 2018 12:07:43 -0700 Subject: [TUHS] OT: Need help from a *BSD guru In-Reply-To: <20180122180327.njqe3z4f7bwfytln@matica.foolinux.mooo.com> References: <201801220810.w0M8ABbq002485@freefriends.org> <201801221436.w0MEa5Jt005358@freefriends.org> <20180122180327.njqe3z4f7bwfytln@matica.foolinux.mooo.com> Message-ID: <201801221907.w0MJ7hMb013984@freefriends.org> Ian Zimmerman wrote: > On 2018-01-22 07:36, arnold at skeeve.com wrote: > > > Looks like I solved my problem on my own; thanks to everyone who > > replied privately. I will send a short note detailing the issue > > a little later. > > Probably an unnecessary reminder, but could you post about it (the > problem and the solution) to the Usenet newsgroup comp.lang.awk as well? > Thanks. It's totally a C issue; it merely came up in the context of gawk. And I unsubscribed from comp.lang.awk a year or so ago. My blood pressure has been considerably lower since doing so. :-) Thanks, Arnold From arnold at skeeve.com Tue Jan 23 05:36:17 2018 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 22 Jan 2018 12:36:17 -0700 Subject: [TUHS] OT: Need help from a *BSD guru In-Reply-To: <201801221436.w0MEa5Jt005358@freefriends.org> References: <201801220810.w0M8ABbq002485@freefriends.org> <201801221436.w0MEa5Jt005358@freefriends.org> Message-ID: <201801221936.w0MJaHZe017381@freefriends.org> The problem had to do with the "inplace" extension for gawk that enables in-place editing of files, ala perl or GNU sed -i. On BSD systems, I was getting failures from the test suite. E.g., on a regular system, inplace1.ok looks like: ----------------------- before gawk: inplace:47: warning: inplace_begin: disabling in-place editing for invalid FILENAME `-' stdin start is bar replaced? stdin end after ----------------------- On a BSD system, I get: ----------------------- before gawk: inplace:47: warning: inplace_begiafter abling in-place editing for invalid FILENAME `-' stdin start is bar replaced? stdin end ----------------------- There's some kind of buffering problem going on. The problem only occurs when stdout and stderr are redirected to the same file: command line here > _out 2>&1 I tried adding all kinds of calls to fflush in all kinds of places, but no luck. Finally, I had an "aha!" moment (an epiphany, if I'm using the expensive word correctly :-), and made this change: diff --git a/main.c b/main.c index 55983789..f505c71f 100644 --- a/main.c +++ b/main.c @@ -246,6 +246,10 @@ main(int argc, char **argv) if ((cp = getenv("GAWK_LOCALE_DIR")) != NULL) locale_dir = cp; + int flags = fcntl(fileno(stderr), F_GETFL, NULL); + flags |= O_APPEND; + (void) fcntl(fileno(stderr), F_SETFL, flags); + #if defined(LOCALEDEBUG) initial_locale = locale; #endif Forching stderr to be in append mode did the trick. WHY does that make it work? Beats me. It's not needed on any other system. Adventures In C Programming ... Thanks, Arnold arnold at skeeve.com wrote: > Hi All. > > Looks like I solved my problem on my own; thanks to everyone who > replied privately. I will send a short note detailing the issue > a little later. > > Thanks! > > Arnold From scj at yaccman.com Tue Jan 23 14:27:16 2018 From: scj at yaccman.com (Steve Johnson) Date: Mon, 22 Jan 2018 20:27:16 -0800 Subject: [TUHS] origin of C header files In-Reply-To: Message-ID: Well, the problem is not unique to C.   If Python has such a mechanism it doesn't seem to be used by TensorFlow.   If a TF operation finds an error, in execution, there is, so far as I know, no way for the error to refer back to the source Python code, or even the variable names involved.  You have to say "name=..." for any op for which you want to know the name -- otherwise, TensorFlow gives them internal names that, for large designs, can be very hard to decode.  (Of course, in TensorFlow, most of the heavy lifting is done by C++ called by a Python wrapper, that further "enhances" the debugging experience) Steve ----- Original Message ----- From: "Paul Winalski" To:"Steve Johnson" Cc:"Clem Cole" , "TUHS main list" Sent:Fri, 29 Dec 2017 20:52:00 -0500 Subject:Re: [TUHS] origin of C header files On 12/29/17, Steve Johnson wrote: > I begged Dennis for a solution, and he came up with #line, > which allowed you to say to the C compiler "treat the next line as if > it were line nnn in file fff, and following lines as successor lines > in file fff. It instantly solved the problem, and was used multiple > times for various applications (probably most notably cfront). So > far as I know, many languages including FORTRAN, Pascal and Python do > not have such a mechanism, making it awkward to use them as > preprocessor targets. Language processing systems where the preprocessor functionality is implemented as a part of the compiler itself never had the "associate the error message with the line in the original source" problem that you described. The compiler could keep an internal table mapping the lexical output of the preprocessor to the source lines/files that went into the preprocessor phase. Most (all?) of DEC's and IBM's compilers operate this way. In keeping with UNIX's philosophy of "one image/one purpose", C's preprocessor functionality was in a separate image from the compiler itself. There are many advantages to this design, including that cpp can then be used for other languages than C. But is has the disadvantage of introducing the source correlation problem that required the introduction of #line. -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Tue Jan 23 23:04:52 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 23 Jan 2018 08:04:52 -0500 (EST) Subject: [TUHS] Swapping (Was: !mail tuhs@minnie.tuhs.org) Message-ID: <20180123130452.257FE18C096@mercury.lcs.mit.edu> > From: Doug McIlroy >> From: Paul Ruizendaal >> LSX has a maximum of three processes that are swapped in and out in a >> stack-like fashion. Only one process is ever in core. I'm having a hard time working out how this works. If process A is swapped out, and then B, B has to be swapped in before A can be? But only one process is ever in core at a time? To get A in, B has to be moved out? But then B would be the last one out, and would have to come in before A? Anyway, I don't understand why the OS could/would care which order processes we swapped in - unless it's something like the 'onion skin' memory allocation algorithm of CTSS (which also had only a single process resident at a time, IIRC), where, when a small process had to be swapped in, and a large one was already in, it only swapped out enough of the large one to make room for the small one. The process could recurse, hence the name. > V1 was a time-sharing system; for which LIFO swapping is > inappropriate. And I don't follow that either... V1 ran on the 11/20 without memory management hardware, though, right? (Although there's that cryptic reference to the KS11 in "Odd Comments and Strange Doings in Unix", although I've never been able to find out anything else about the KS11.) So presumably one would not have wanted more than one process resident at a time, as that decreases the odds of a buggy program trashing another process? Noel From dave at horsfall.org Wed Jan 24 08:33:00 2018 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 24 Jan 2018 09:33:00 +1100 (EST) Subject: [TUHS] RIP Marvin Minsky Message-ID: We lost AI pioneer Marvin Minsky on this day in 2016 from a cerebral haemorrhage, aged 88. Amongst other things, along with John McCarthy he co-founded the MIT AI Lab, co-invented the Logo "turtle", was mentioned in Arthur C. Clarke's novel "2001: A Space Odyssey", and built the first randomly wired neural network learning machine, SNARC, in 1951. He is now thought to be cryogenically preserved as "Patient 144" at Alcor (he started cooling on 27/1/2016). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From pnr at planet.nl Fri Jan 26 04:20:25 2018 From: pnr at planet.nl (Paul Ruizendaal) Date: Thu, 25 Jan 2018 19:20:25 +0100 Subject: [TUHS] LSX swapping Message-ID: >>> LSX has a maximum of three processes that are swapped in and out in a >>> stack-like fashion. Only one process is ever in core. > > I'm having a hard time working out how this works. If process A is swapped > out, and then B, B has to be swapped in before A can be? But only one process > is ever in core at a time? To get A in, B has to be moved out? But then B > would be the last one out, and would have to come in before A? > > Anyway, I don't understand why the OS could/would care which order processes > we swapped in - unless it's something like the 'onion skin' memory allocation > algorithm of CTSS (which also had only a single process resident at a time, > IIRC), where, when a small process had to be swapped in, and a large one was > already in, it only swapped out enough of the large one to make room for the > small one. The process could recurse, hence the name. The LSI-11 had 40KB of core. The lower 16KB held the LSX kernel, the upper 24K was for the active process. LSX has 3 process slots and 2 swap slots (on floppy!). Optionally, LSX could be built with an additional background process ("BGOPTION"), but this does not work very well. Process numbers and swap slots have a 1:1 relationship. There is a global variable, cpid, with the process number of the current process, initially zero. Upon boot, LSX will load a shell as process 0. (There is no swapper process and no init in LSX). The original LSI-11 kernel code is here: http://minnie.tuhs.org/cgi-bin/utree.pl?file=LSX/sys I can refer to source lines in the repository for my TI990 port of it: https://1587660.websites.xs4all.nl/cgi-bin/9995/artifact/b6ec9496e23efe8c When a process forks, it writes the current core image out to the corresponding swap slot (this swaps out the parent) and the core image is repurposed as the new process (i.e. cpid is incremented and the proc table filled in): https://1587660.websites.xs4all.nl/cgi-bin/9995/artifact/3617ec3245c40a69?ln=156,159 The child now runs and the parent remains suspended until the child completes. Yes, this implies no pipes. The shell is modified to emulate pipes with files. When the child completes, it stores its u area / exit code in its swap slot (as it is running, the swap slot must be empty. Process 3 has a small swap slot just for this). Next LSX decreases cpid and the parent process is reloaded from its swap slot: https://1587660.websites.xs4all.nl/cgi-bin/9995/artifact/b9c07dfc5add9fc5?ln=239,247 The actual swapping happens here: https://1587660.websites.xs4all.nl/cgi-bin/9995/artifact/b6ec9496e23efe8c?ln=335,368 The original PDP11 source has code to compress the empty space between _end and the stack pointer, which I did not get to work properly. LSX works well enough to run the standard V6 binaries unmodified. Some need to be tweaked (e.g. table space in cpp) and the shell needed the pipe change. It can run the V6 c compiler, but not with a wild card argument: that requires 4 stacked processes (sh, glob, cc and cpp/c0/..) and LSX allows only 3. Hope the above makes it a bit more clear. From jnc at mercury.lcs.mit.edu Fri Jan 26 04:42:59 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 25 Jan 2018 13:42:59 -0500 (EST) Subject: [TUHS] V6 UNIX main() oddness Message-ID: <20180125184259.8B62518C0B0@mercury.lcs.mit.edu> So, while bringing up V6 on a hardware PDP-11/23 with an RK11 emulator using an SD card for storage which Dave Bridgham and I are doing, I found this piece of code in main() on V6 Unix: rootdir = iget(rootdev, ROOTINO); rootdir->i_flag =& ~ILOCK; u.u_cdir = iget(rootdev, ROOTINO); u.u_cdir->i_flag =& ~ILOCK; I don't get why two separate calls to iget(), with the same arguments; why not replace the second pair of lines with: u.u_cdir = rootdir; rootdir->i_count++; What am I missing? Noel From ron at ronnatalie.com Fri Jan 26 05:36:15 2018 From: ron at ronnatalie.com (Ron Natalie) Date: Thu, 25 Jan 2018 14:36:15 -0500 Subject: [TUHS] V6 UNIX main() oddness In-Reply-To: <20180125184259.8B62518C0B0@mercury.lcs.mit.edu> References: <20180125184259.8B62518C0B0@mercury.lcs.mit.edu> Message-ID: <033501d39613$c3f86fa0$4be94ee0$@ronnatalie.com> I don't see any reason why you can't make that optimization at that point. Nothing is going to come in and suddenly invalidate the inode between those two lines. I suspect it was an example of cut/paste-it is from some other part of the kernel. -----Original Message----- From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Noel Chiappa Sent: Thursday, January 25, 2018 1:43 PM To: tuhs at minnie.tuhs.org Cc: jnc at mercury.lcs.mit.edu Subject: [TUHS] V6 UNIX main() oddness So, while bringing up V6 on a hardware PDP-11/23 with an RK11 emulator using an SD card for storage which Dave Bridgham and I are doing, I found this piece of code in main() on V6 Unix: rootdir = iget(rootdev, ROOTINO); rootdir->i_flag =& ~ILOCK; u.u_cdir = iget(rootdev, ROOTINO); u.u_cdir->i_flag =& ~ILOCK; I don't get why two separate calls to iget(), with the same arguments; why not replace the second pair of lines with: u.u_cdir = rootdir; rootdir->i_count++; What am I missing? Noel From clemc at ccc.com Fri Jan 26 05:41:16 2018 From: clemc at ccc.com (Clem Cole) Date: Thu, 25 Jan 2018 14:41:16 -0500 Subject: [TUHS] V6 UNIX main() oddness In-Reply-To: <20180125184259.8B62518C0B0@mercury.lcs.mit.edu> References: <20180125184259.8B62518C0B0@mercury.lcs.mit.edu> Message-ID: Seems reasonable to me give the code path and time its being called. Maybe left over from hacking from an earlier kernel requirement and never noticed by Ken. I wonder if the mount table had been set up in some earlier scheme and he wanted to make sure it was checked first. That's the only thing that seems logical, but we all miss optimizations. ᐧ On Thu, Jan 25, 2018 at 1:42 PM, Noel Chiappa wrote: > So, while bringing up V6 on a hardware PDP-11/23 with an RK11 emulator > using > an SD card for storage which Dave Bridgham and I are doing, I found this > piece > of code in main() on V6 Unix: > > rootdir = iget(rootdev, ROOTINO); > rootdir->i_flag =& ~ILOCK; > u.u_cdir = iget(rootdev, ROOTINO); > u.u_cdir->i_flag =& ~ILOCK; > > I don't get why two separate calls to iget(), with the same arguments; > why not replace the second pair of lines with: > > u.u_cdir = rootdir; > rootdir->i_count++; > > What am I missing? > > Noel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Tue Jan 30 06:03:43 2018 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 30 Jan 2018 07:03:43 +1100 (EST) Subject: [TUHS] Happy birthday, Douglas Engelbart! Message-ID: Born on this day in 1925, he was a pioneer in human/computer interaction, and invented the mouse; it wasn't exactly ergonomic, being just a square box with a button. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From peter at rulingia.com Tue Jan 30 07:03:36 2018 From: peter at rulingia.com (Peter Jeremy) Date: Tue, 30 Jan 2018 08:03:36 +1100 Subject: [TUHS] Happy birthday, Douglas Engelbart! In-Reply-To: References: Message-ID: <20180129210336.GJ75633@server.rulingia.com> On 2018-Jan-30 07:03:43 +1100, Dave Horsfall wrote: >Born on this day in 1925, he was a pioneer in human/computer interaction, >and invented the mouse; it wasn't exactly ergonomic, being just a square >box with a button. For anyone who hasn't seen it, https://www.youtube.com/watch?v=yJDv-zdhzMY ("The Mother of All Demos") is well worth watching even after nearly 50 years. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From pnr at planet.nl Tue Jan 30 20:28:09 2018 From: pnr at planet.nl (Paul Ruizendaal) Date: Tue, 30 Jan 2018 11:28:09 +0100 Subject: [TUHS] Calgary buffer modifications Message-ID: For a while I had been wondering about the origins of a modification to the V6 kernel that places the kernel buffers in a separately mapped area, freeing up space for other things. It is used in some of the early networking code, i.e. both the UoI code and the V6 BBN code (as available on the TUHS Unix Tree). I came across the following reference in https://www.osti.gov/scitech/servlets/purl/12130675: “One widely distributed (though undocumented) solution to this hardware limit on the model 40 was a version of Unix by Robert Sidebotham, Faculty of Environmental Design, University of Calgary. His solution was to move the I/O buffers out of kernel space.” This would explain the modifications being bracketed with "#ifdef UCBUFMOD”. Some questions for the old hands: - Was this patch indeed widely known / distributed? - Widely distributed is not the same as widely used: was it? From clemc at ccc.com Wed Jan 31 00:18:37 2018 From: clemc at ccc.com (Clem Cole) Date: Tue, 30 Jan 2018 09:18:37 -0500 Subject: [TUHS] Calgary buffer modifications In-Reply-To: References: Message-ID: On Tue, Jan 30, 2018 at 5:28 AM, Paul Ruizendaal wrote: > > For a while I had been wondering about the origins of a modification to > the V6 kernel that places the kernel buffers in a separately mapped area, > freeing up space for other things. It is used in some of the early > networking code, i.e. both the UoI code and the V6 BBN code (as available > on the TUHS Unix Tree). > > I came across the following reference in https://www.osti.gov/scitech/ > servlets/purl/12130675: > > “One widely distributed (though undocumented) solution to this hardware > limit on the model 40 was a version of Unix by Robert Sidebotham, Faculty > of Environmental Design, University of Calgary. His solution was to move > the I/O buffers out of kernel space.” > > This would explain the modifications being bracketed with "#ifdef > UCBUFMOD”. > > Some questions for the old hands: > > - Was this patch indeed widely known / distributed? > ​Hmm - a little like the halting problem I fear - how can you tell? I can say we knew about them because Gosling brought them to CMU when he was a grad student; but by that time, we had started to switched to Unix/TS and Seventh edition that Ted had brought from BTL. As I recall, it was more hacking/surgery then I personally wanted to do in the EE 11/34 based systems. I don't think they got added to the SUS or IUS @ CS which were the other heavy 11/40 machines at the time. > > - Widely distributed is not the same as widely used: was it? > ​Not that I remember, but others of course may remember otherwise. I think many of us knew that Calgary (and Toronto to an extent) was a hot bed of Unix hacking because of Gosling, but the places outside the US that were probably having the most effect on the community at the time were in OZ and the UK. ​ ​Remember Net.noise had not really started as UUCP was part Seventh Edition so the news systems are in the future. Also the ArpaNet was limited in reach, and not that many UNIX sites were apart (it was mostly PDP-10s). Thus, unless someone came to a USENIX and talked about something, or a student somehow switch schools (like to be a grad student) folks did not know about the changes.​ For instance, I knew a little about what was going on at MIT and UMICH because of friends that left CMU and went to there or vise versa; and I would bring CMU things to UCB etc... Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Wed Jan 31 09:42:42 2018 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 31 Jan 2018 10:42:42 +1100 (EST) Subject: [TUHS] Calgary buffer modifications In-Reply-To: References: Message-ID: On Tue, 30 Jan 2018, Paul Ruizendaal wrote: > “One widely distributed (though undocumented) solution to this hardware > limit on the model 40 was a version of Unix by Robert Sidebotham, > Faculty of Environmental Design, University of Calgary. His solution was > to move the I/O buffers out of kernel space.” I wonder if that inspired the AUSAM buffer management? The current buffer header was "b" (like "u") which got mapped by KISA5. For the first time I was able to avoid our 11/40 deadlocking; I can't remember all the devices that were on it, but there were a *lot* (including the printer driver etc which used the buffer pool, not the character queue). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From kevin.bowling at kev009.com Wed Jan 31 18:39:25 2018 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Wed, 31 Jan 2018 01:39:25 -0700 Subject: [TUHS] Dynamics between BSD and Linux Message-ID: Hi, Interested in some perspective here since the list has influential Linux people like Ted Tso. Linux has been described as influenced by Minix and System V. The Minix connection is well discussed. The SysV connection something something Linus had access to a spec manual. But I’d guess reality would be more gradual — new contributors that liked CSRG BSD would have mostly gravitated to the continuations in 386/BSDi/Net/Free that were concurrent to early and formative Linux development.. so there’d be an implicit vacuum of BSD people for Linux development. What I am curious about is the continuing ignorance of BSD ideas. Linux isn’t exactly insular; a lot of critical people and components came much later on from other SysV flavors (lvm, jfs, xfs, RCU) The kinds of BSD things I am talking about are ufs, kqueue, jails, pf, Capsicum. Linux has grown alternatives, but with sometimes willful ignorance of other technology. It seems clear epoll was not a good design from the start. Despite jails not being taken to the logical conclusion of modern containers like zones, the architecture is fundamentally closer aligned to how people want to securely use containers versus namespaces and cgroups. And Google ported Capscicum to Linux but it’s basically been ignored in lieu of nebulous concepts like seccomp. And then there seems to be outright hostility toward other platforms from the postmodern generation with things like systemd. This seems strange to me as BSD people are generally open to other /ideas/, we have to be careful with Linux code due to license incompatibility, but the converse is does not seem true either in interest in other ideas or license hampering code flow. The history of UNIX is spectacularly successful because different groups got together at the table and agreeed on the ideas. Is there room for that in the modern era where Linux is the monopoly OS? The Austin Group is still a thing but it’s not clear people in any of the Freenix communities really care about evolving the standards. I get that, but not so much completely burrying ones head in the sand to what other OSes are doing. Is there any future for UNIX as an “open system” in this climate or are people going to go there separate ways? Regards, Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: