From gtaylor at tnetconsulting.net Fri Feb 8 04:07:27 2019 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Thu, 7 Feb 2019 11:07:27 -0700 Subject: [COFF] [TUHS] OSI stack (Was: Posters) In-Reply-To: References: <20190206174913.E518318C07B@mercury.lcs.mit.edu> Message-ID: <0572e855-9aac-337f-4f1b-66dda3839e14@spamtrap.tnetconsulting.net> Seeing as how this is diverging from TUHS, I'd encourage replies to the COFF copy that I'm CCing. On 02/06/2019 01:47 PM, Kevin Bowling wrote: > There were protocols that fit better in the era like DeltaT with a > simpler state machine and connection handling.  Then there was a mad > dash of protocol development in the mid to late ‘80s that were measured > by various metrics to outperform TCP in practical and theoretical > space.  Some of these seemed quite nice like XTP and are still in use in > niche defense applications. $ReadingList++ > Positive, rather than negative acknowledgement has aged well as > computers got more powerful (the sender can pretty well predict loss > when it hasn't gotten an ACK back and opportunistically retransmit). > But RF people do weird things that violate end to end principle on cable > modems and radios to try and minimize transmissions. Would you care to elaborate? > One thing I think that is missing in my contemporary modern software > developers is a willingness to dig down and solve problems at the right > level.  People do clownish things like write overlay filesystems in > garbage collected languages.  Google's QUIC is a fine example of > foolishness.  I am mortified that is genuinely being considered for the > HTTP 3 standard.  But I guess we've entered the era where enough people > have retired that the lower layers are approached with mysticism and > deemed unable and unsuitable to change.  So the layering will continue > until eventually things topple over like the garbage pile in the movie > Idiocracy. I thought one of the reasons that QUIC was UDP based instead of it's own transport protocol was because history has shown that the possibility and openness of networking is not sufficient to encourage the adoption of newer technologies. Specifically the long tail of history / legacy has hindered the introduction of a new transport protocol. I thought I remembered hearing that Google wanted to do a new transport protocol, but they thought that too many things would block it thus slowing down it's deployment. Conversely putting QUIC on top of UDP was a minor compromise that allowed the benefits to be adopted sooner. Perhaps I'm misremembering. I did a quick 45 second search and couldn't find any supporting evidence. The only thing that comes to mind is IPsec's ESP(50) and AH(51) which—as I understand it—are filtered too frequently because they aren't ICMP(1), TCP(6), or UDP(17). Too many firewalls interfere to the point that they are unreliable. > Since the discussion meandered to the distinction of path > selection/routing.. for provider level networks, label switching to this > day makes a lot more sense IMO.. figure out a path virtual circuit that > can cut through each hop with a small flow table instead of trying to > coagulate, propagate routes from a massive address space that has to fit > in an expensive CAM and buffer and forward packets at each hop. I think label switching has it's advantages. I think it also has some complications. I feel like ATM, Frame Relay, and MPLS are all forms of label switching. Conceptually they all operate based on a per-programed path. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From akosela at andykosela.com Fri Feb 8 04:22:14 2019 From: akosela at andykosela.com (Andy Kosela) Date: Thu, 7 Feb 2019 12:22:14 -0600 Subject: [COFF] [TUHS] OSI stack (Was: Posters) In-Reply-To: <0572e855-9aac-337f-4f1b-66dda3839e14@spamtrap.tnetconsulting.net> References: <20190206174913.E518318C07B@mercury.lcs.mit.edu> <0572e855-9aac-337f-4f1b-66dda3839e14@spamtrap.tnetconsulting.net> Message-ID: On Thursday, February 7, 2019, Grant Taylor via TUHS wrote: > Seeing as how this is diverging from TUHS, I'd encourage replies to the > COFF copy that I'm CCing. > > On 02/06/2019 01:47 PM, Kevin Bowling wrote: > >> There were protocols that fit better in the era like DeltaT with a >> simpler state machine and connection handling. Then there was a mad dash >> of protocol development in the mid to late ‘80s that were measured by >> various metrics to outperform TCP in practical and theoretical space. Some >> of these seemed quite nice like XTP and are still in use in niche defense >> applications. >> > > $ReadingList++ XTP was/is indeed very interesting. It was adopted by US Navy for SAFENET and created by Greg Chesson who was active in the early UNIX community. Not sure if we have him here on this list though. --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Fri Feb 8 04:33:05 2019 From: crossd at gmail.com (Dan Cross) Date: Thu, 7 Feb 2019 13:33:05 -0500 Subject: [COFF] [TUHS] OSI stack (Was: Posters) In-Reply-To: References: <20190206174913.E518318C07B@mercury.lcs.mit.edu> <0572e855-9aac-337f-4f1b-66dda3839e14@spamtrap.tnetconsulting.net> Message-ID: On Thu, Feb 7, 2019 at 1:22 PM Andy Kosela wrote: > On Thursday, February 7, 2019, Grant Taylor via TUHS > wrote: > >> Seeing as how this is diverging from TUHS, I'd encourage replies to the >> COFF copy that I'm CCing. >> >> On 02/06/2019 01:47 PM, Kevin Bowling wrote: >> >>> There were protocols that fit better in the era like DeltaT with a >>> simpler state machine and connection handling. Then there was a mad dash >>> of protocol development in the mid to late ‘80s that were measured by >>> various metrics to outperform TCP in practical and theoretical space. Some >>> of these seemed quite nice like XTP and are still in use in niche defense >>> applications. >>> >> >> $ReadingList++ > > > XTP was/is indeed very interesting. It was adopted by US Navy for SAFENET > and created by Greg Chesson who was active in the early UNIX community. > Not sure if we have him here on this list though. > Sadly, Greg Chesson passed away a couple of years ago after battling cancer for some time. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Fri Feb 8 04:50:54 2019 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 7 Feb 2019 10:50:54 -0800 Subject: [COFF] [TUHS] OSI stack (Was: Posters) In-Reply-To: <0572e855-9aac-337f-4f1b-66dda3839e14@spamtrap.tnetconsulting.net> References: <20190206174913.E518318C07B@mercury.lcs.mit.edu> <0572e855-9aac-337f-4f1b-66dda3839e14@spamtrap.tnetconsulting.net> Message-ID: <20190207185054.GA20698@mcvoy.com> On Thu, Feb 07, 2019 at 11:07:27AM -0700, Grant Taylor via TUHS wrote: > On 02/06/2019 01:47 PM, Kevin Bowling wrote: > >There were protocols that fit better in the era like DeltaT with a simpler > >state machine and connection handling.?? Then there was a mad dash of > >protocol development in the mid to late ???80s that were measured by > >various metrics to outperform TCP in practical and theoretical space.?? > >Some of these seemed quite nice like XTP and are still in use in niche > >defense applications. > > $ReadingList++ Greg Chesson was the guy behind XTP. I worked for him at SGI, he was a hoot (lost him to cancer a while back). I think I've posted this before but here he is not long before he died (he came up to bitch about kids these days with their shiney frameworks and new fangled languages, what's wrong with C?) http://mcvoy.com/lm/xtp+excavator He was an engineer to the core, he refused to take any info from me on how to run the machine, just sat there and figured it out. --lm From michael at kjorling.se Fri Feb 8 05:28:21 2019 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Thu, 7 Feb 2019 19:28:21 +0000 Subject: [COFF] OSI stack In-Reply-To: <0572e855-9aac-337f-4f1b-66dda3839e14@spamtrap.tnetconsulting.net> References: <20190206174913.E518318C07B@mercury.lcs.mit.edu> <0572e855-9aac-337f-4f1b-66dda3839e14@spamtrap.tnetconsulting.net> Message-ID: <20190207192821.7hjsf6atfyi747sb@h-174-65.A328.priv.bahnhof.se> On 7 Feb 2019 11:07 -0700, from coff at minnie.tuhs.org (Grant Taylor via COFF): > The only thing that comes to mind is IPsec's ESP(50) and AH(51) which—as I > understand it—are filtered too frequently because they aren't ICMP(1), > TCP(6), or UDP(17). Too many firewalls interfere to the point that they are > unreliable. While different, I think that the introduction of the more advanced IPv6 address formats into DNS also qualifies. I don't recall off hand if bit-string labels (which were used for reverse lookups) or the A6 RRtype (for forward lookups) was the more problematic one, but I do recall that both had issues that made real-world adoption non-trivial in the best of cases. -- 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 gtaylor at tnetconsulting.net Fri Feb 8 12:41:54 2019 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Thu, 7 Feb 2019 19:41:54 -0700 Subject: [COFF] OSI stack In-Reply-To: <20190207192821.7hjsf6atfyi747sb@h-174-65.A328.priv.bahnhof.se> References: <20190206174913.E518318C07B@mercury.lcs.mit.edu> <0572e855-9aac-337f-4f1b-66dda3839e14@spamtrap.tnetconsulting.net> <20190207192821.7hjsf6atfyi747sb@h-174-65.A328.priv.bahnhof.se> Message-ID: On 2/7/19 12:28 PM, Michael Kjörling wrote: > While different, I think that the introduction of the more advanced > IPv6 address formats into DNS also qualifies. I don't recall off hand if > bit-string labels (which were used for reverse lookups) or the A6 RRtype > (for forward lookups) was the more problematic one, but I do recall that > both had issues that made real-world adoption non-trivial in the best > of cases. Middle boxes that (mis)interpret DNS traffic are still a problem. Admittedly less of a problem. I suspect even less after the DNS Flag Day we recently had. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From gtaylor at tnetconsulting.net Fri Feb 8 13:43:27 2019 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Thu, 7 Feb 2019 20:43:27 -0700 Subject: [COFF] [TUHS] OSI stack (Was: Posters) In-Reply-To: References: <20190206174913.E518318C07B@mercury.lcs.mit.edu> <0572e855-9aac-337f-4f1b-66dda3839e14@spamtrap.tnetconsulting.net> Message-ID: <741f24ad-9b26-4620-b51c-3c7d0839a57c@spamtrap.tnetconsulting.net> It looks like Kevin's response didn't make the COFF mailing list. So I'm including it and my email that it's in response to below. Kevin, are you subscribed to the COFF mailing list? On 2/7/19 5:16 PM, Kevin Bowling wrote: > On Thu, Feb 7, 2019 at 11:08 AM Grant Taylor via TUHS > wrote: >> Seeing as how this is diverging from TUHS, I'd encourage replies to the >> COFF copy that I'm CCing. > > My thesis was that the specific vector of TCP becoming dominant is "UH" > >> $ReadingList++ > > Pick up ISBN-13: 978-0201563511 if you work on transport protos. > >> Would you care to elaborate? > > Only briefly for this list -- certain common devices will intercept > TCP streams and cause what are called stretch ACKs from a host because > transmission is expensive in some vector -- shared collision domain > like the air or a coaxial bus, battery power to key up the radio etc. > This means the sender has to accommodate that behavior and know how to > react if it is modeling the connection. Intriguing. It seems that the more answers that I get end up resulting in even more questions and things I want to learn about. Thank you Kevin. >> I thought one of the reasons that QUIC was UDP based instead of it's own >> transport protocol was because history has shown that the possibility >> and openness of networking is not sufficient to encourage the adoption >> of newer technologies. Specifically the long tail of history / legacy >> has hindered the introduction of a new transport protocol. I thought I >> remembered hearing that Google wanted to do a new transport protocol, >> but they thought that too many things would block it thus slowing down >> it's deployment. Conversely putting QUIC on top of UDP was a minor >> compromise that allowed the benefits to be adopted sooner. >> >> Perhaps I'm misremembering. I did a quick 45 second search and couldn't >> find any supporting evidence. > > G and Facebook also admit it uses 200% more CPU to do the same > throughput. All for basically avoiding HOL-blocking, which can be > worked around in most common scenarios, especially when you control > the most popular browser :facepalm:. Both companies together could > pull networking in any direction they want. I see QUIC as yet another > unfortunate direction. Okay. >> The only thing that comes to mind is IPsec's ESP(50) and AH(51) which—as >> I understand it—are filtered too frequently because they aren't ICMP(1), >> TCP(6), or UDP(17). Too many firewalls interfere to the point that they >> are unreliable. >> >> >> I think label switching has it's advantages. I think it also has some >> complications. >> >> I feel like ATM, Frame Relay, and MPLS are all forms of label switching. >> Conceptually they all operate based on a per-programed path. > > By provider networks I mean tier 1 and 2 and core infrastructure like > CDNs. MPLS is good. ATM got a couple things right and a lot of > things less right. I think one thing that MPLS, ATM, FR do / did is to transparently carry other protocols without modification to their operation. I think such transparency allows them to do things that would be considerably more difficult if the switching / routing logic of the transport network was trying to interpret network addressing and / or protocol information of the payloads they were carrying. I don't know how flexible MPLS, et al, are without the support of other associated protocols. How well can a MPLS cloud with redundant connections find an alternate path if a link goes down. That's arguably something that IP is exceedingly capable of doing, even if it's not the most efficient at it. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From dave at horsfall.org Fri Feb 8 16:04:46 2019 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 8 Feb 2019 17:04:46 +1100 (EST) Subject: [COFF] In memoriam: John von Neumann Message-ID: We lost computer pioneer John von Neumann on this day in 1957; the "von Neumann" architecture (stored program etc) is the basis of all modern computers, and he almost certainly borrowed it from Charles Babbage. -- Dave From dave at horsfall.org Wed Feb 13 13:20:40 2019 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 13 Feb 2019 14:20:40 +1100 (EST) Subject: [COFF] [TUHS] OSI stack (Was: Posters) In-Reply-To: References: <20190206174913.E518318C07B@mercury.lcs.mit.edu> <0572e855-9aac-337f-4f1b-66dda3839e14@spamtrap.tnetconsulting.net> Message-ID: Sorry for the x-posting, but I'm not sure upon which list this topic belongs... I think it's slowly drifting towards COFF, but Warren as usual will have the final say :-) On Thu, 7 Feb 2019, Dan Cross wrote: > Sadly, Greg Chesson passed away a couple of years ago after battling > cancer for some time. His birth date is not known, and I cannot find when he left us. But yes, he was indeed one of the Greats. -- Dave, the hysterical historian From akosela at andykosela.com Fri Feb 15 09:35:16 2019 From: akosela at andykosela.com (Andy Kosela) Date: Thu, 14 Feb 2019 17:35:16 -0600 Subject: [COFF] [TUHS] Women in computing In-Reply-To: References: <20190214192940.ED58418C0AB@mercury.lcs.mit.edu> <1b71e45e-5711-ee8d-2bc8-4ea6298311dd@solar.stanford.edu> <201902142037.x1EKbpnR017241@darkstar.fourwinds.com> <33ce5850-f0b5-1fa9-d459-58d4e2416e80@telegraphics.com.au> Message-ID: Is this thread really a good place for TUHS discussion? Maybe COFF would be better suited for it. And maybe the explanation why there are more men in IT is simpler than some folks who forcefully try to create elaborate sociological theories think. In nature males are just wired differently from females. And that is why they ARE different, like 1 and 0. Otherwise they would be just one sex. And as we know nothing can come from just one number... --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at timetraveller.org Fri Feb 15 11:27:51 2019 From: robert at timetraveller.org (Robert Brockway) Date: Fri, 15 Feb 2019 11:27:51 +1000 (AEST) Subject: [COFF] [TUHS] Women in computing In-Reply-To: References: <20190214192940.ED58418C0AB@mercury.lcs.mit.edu> <1b71e45e-5711-ee8d-2bc8-4ea6298311dd@solar.stanford.edu> <201902142037.x1EKbpnR017241@darkstar.fourwinds.com> <33ce5850-f0b5-1fa9-d459-58d4e2416e80@telegraphics.com.au> Message-ID: On Thu, 14 Feb 2019, Thomas Kellar wrote: > I am learning from the discussion. I disagree with the binary > argument. Women and men both have personalities and brains that range > over a huge spectrum of differences. It is society that tries to force > them into particular molds. Hi Thomas. FWIW, the mainstream on both sides of this argument agree that men and women overlap in characteristics. The question is what causes the differences. Many human characteristics are bimodal with most people clustering around one of two points, and those points correlating with biological gender. Opponents of inate gender differences argue that the observed differences are socialised. They point out that neuroplasticity means that even differences in brain structure between genders *could* be socialised. This is why I find studies on infants so interesting. There are plenty of examples but I've linked a study below that monitored the behaviour of infants that are around 24 hours old. Statistically significant differences in behaviour were observed between boys and girls. This is far too early for any socialisation to have occured. https://www.math.kth.se/matstat/gru/5b1501/F/sex.pdf When I was a young man I believed that gender differences (beyond obvious morphological differences) were socialised. But the evidence grew, and has continued to grow, that to a large degree this isn't so. A really fascinating area is "greater male variability" (GMV) which really explains a lot about the world. I wrote an article on that for a well known blog a few years ago. While researching the article I discovered that men vary more than women in personality. That is to say that on average women are more similar to each other in personality than men are. I admit that one really surprised me. Some people claim GMV has been discredited. It hasn't. People claiming GMV has been discredited usually cite a handful of counter examples as evidence of this. GMV was never claimed to be univerally true, only true for most characteristics.. I suspect there is at least one case where females, not males, exhibit greater variability but this still doesn't discredit GMV. Getting back to employment, there have been many studies on employment patterns and gender by researchers and governments. They consistently show that men and women make a myriad of different choices in employment. In particular they show that men will tend to prioritise earning potential over many other characteristics of employment while women tend to do the reverse. The largest study on this topic anywhere is probably the CONSAD Report, commissioned by the US Dept of Labor. The CONSAD Report is actually on the gender earnings gap but it's still relevant to a discussion on different choices men and women make in employment. Here's a tiny URL to the CONSAD Report: https://tinyurl.com/y6vvzm4v Cheers, Rob From dave at horsfall.org Fri Feb 15 16:08:14 2019 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 15 Feb 2019 17:08:14 +1100 (EST) Subject: [COFF] Happy birthday, Niklaus Wirth! Message-ID: Almost forgot... Born on this day in 1934, he pretty much invented ALGOL (and algorithmic languages in general; the running joke was that you could call him by name or by value)... From Clem Cole: "The actual joke was Europeans called him by name ("ni-klaus vurt") and Americans by value ("nickel-less worth").​ -- Dave From bakul at bitblocks.com Fri Feb 15 16:46:17 2019 From: bakul at bitblocks.com (Bakul Shah) Date: Thu, 14 Feb 2019 22:46:17 -0800 Subject: [COFF] Happy birthday, Niklaus Wirth! In-Reply-To: References: Message-ID: On Feb 14, 2019, at 10:08 PM, Dave Horsfall wrote: > > Almost forgot... > > Born on this day in 1934, he pretty much invented ALGOL (and algorithmic languages in general; the running joke was that you could call him by name or by value)... From Clem Cole: "The actual joke was Europeans called him by name ("ni-klaus vurt") and Americans by value ("nickel-less worth").​ Niklaus Wirth did come up with Algol-W, based on Algol-60 but he didn't invent Algol-58 or Algol-60 or Algol-68; though he was on the IFIP Working Group 2.1 for Algol (IIRC, he thought Algol-68 was overly complicated). BTW, Niklaus Wirth himself supposedly made this self-referential joke: “Whereas Europeans generally pronounce my name the right way (‘Nick-louse Veert’), Americans invariably mangle it into ‘Nickel’s Worth.’ This is to say that Europeans call me by name, but Americans call me by value.” [I haven't found a primary source for this but lots of secondary sources and variations!] From mutiny.mutiny at india.com Fri Feb 15 19:17:49 2019 From: mutiny.mutiny at india.com (Donald ODona) Date: Fri, 15 Feb 2019 09:17:49 +0000 (UTC) Subject: [COFF] Happy birthday, Niklaus Wirth! In-Reply-To: References: Message-ID: <1018434267.162933.1550222269508.JavaMail.tomcat@india-live-be02> Pascal was his creation. At 15 Feb 2019 06:09:01 +0000 (+00:00) from Dave Horsfall : > Almost forgot... > > Born on this day in 1934, he pretty much invented ALGOL (and algorithmic > languages in general; the running joke was that you could call him by > name or by value)... From Clem Cole: "The actual joke was Europeans > called him by name ("ni-klaus vurt") and Americans by value ("nickel-less > worth").​ > > -- Dave From stewart at serissa.com Sat Feb 16 00:13:31 2019 From: stewart at serissa.com (Lawrence Stewart) Date: Fri, 15 Feb 2019 09:13:31 -0500 Subject: [COFF] Happy birthday, Niklaus Wirth! In-Reply-To: References: Message-ID: <02A89727-5B08-4BB4-A139-AB55AD4EEF27@serissa.com> > On 2019, Feb 15, at 1:46 AM, Bakul Shah wrote: > > On Feb 14, 2019, at 10:08 PM, Dave Horsfall wrote: >> >> Almost forgot... >> >> Born on this day in 1934, he pretty much invented ALGOL (and algorithmic languages in general; the running joke was that you could call him by name or by value)... From Clem Cole: "The actual joke was Europeans called him by name ("ni-klaus vurt") and Americans by value ("nickel-less worth").​ > > Niklaus Wirth did come up with Algol-W, based on Algol-60 but he > didn't invent Algol-58 or Algol-60 or Algol-68; though he was on > the IFIP Working Group 2.1 for Algol (IIRC, he thought Algol-68 > was overly complicated). > > BTW, Niklaus Wirth himself supposedly made this self-referential joke: > > “Whereas Europeans generally pronounce my name the right way > (‘Nick-louse Veert’), Americans invariably mangle it into > ‘Nickel’s Worth.’ This is to say that Europeans call me by > name, but Americans call me by value.” > > [I haven't found a primary source for this but lots of secondary > sources and variations!] > _______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff In addition to Algol-W and Pascal. Niklaus Wirth also developed Modula-2 and Oberon. Oberon is particularly interesting because it included a language, an operating system, and a computer. There aren’t that many folks who could build a complete environmnet from scratch. A good bit of the Oberon work was done by Jurg Gutknecht but it is nevertheless an impressive achievement. In 2013, Wirth put out a rebooted system running on an FPGA. -L From wkt at tuhs.org Sat Feb 16 07:35:53 2019 From: wkt at tuhs.org (Warren Toomey) Date: Sat, 16 Feb 2019 07:35:53 +1000 Subject: [COFF] Women in computing Message-ID: <20190215213552.GA2566@minnie.tuhs.org> All, I'll kick off the conversation restart here on the COFF list with the original link. https://www.nytimes.com/2019/02/13/magazine/women-coding-computer-programming.html Cheers, Warren From cym224 at gmail.com Sat Feb 16 09:13:26 2019 From: cym224 at gmail.com (Nemo) Date: Fri, 15 Feb 2019 18:13:26 -0500 Subject: [COFF] Happy birthday, Niklaus Wirth! In-Reply-To: <02A89727-5B08-4BB4-A139-AB55AD4EEF27@serissa.com> References: <02A89727-5B08-4BB4-A139-AB55AD4EEF27@serissa.com> Message-ID: On 15/02/2019, Lawrence Stewart wrote (in part): > In addition to Algol-W and Pascal. Niklaus Wirth also developed Modula-2 and > Oberon. > Oberon is particularly interesting because it included a language, an > operating system, and a computer. There aren’t that many folks who could > build a complete environmnet from scratch. He also devised an HDL before switching to Verilog. (The original Oberon UI influenced Pike's acme, though Pike thought Wirth was too minimalist.) At any rate, this page has a picture of Auld Nick (as some wags called him) in his lab with board and helicopters: https://www.srf.ch/radio-srf-3/digital/computer-pionier-niklaus-wirth-80-und-aktiv (Javscript neede to display the photos.) N. From lm at mcvoy.com Sat Feb 16 10:49:40 2019 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 15 Feb 2019 16:49:40 -0800 Subject: [COFF] Women in computing In-Reply-To: <20190215213552.GA2566@minnie.tuhs.org> References: <20190215213552.GA2566@minnie.tuhs.org> Message-ID: <20190216004940.GZ26831@mcvoy.com> I support more women in CS but you read stories about the good old boys club at Uber and elsewhere and I think you have your answer. If you are female and are going to get judged by your looks rather than your talent that's not going to be a big draw for women. It's kind of hard to turn that off, getting guys to stop doing that is about as easy as getting women (well most women) to not swoon when they see a baby. I have no idea what went south, when I was at Sun, SGI, Cobalt, there were plenty of women engineers. And that was in the kernel groups which were pretty hard core. 30% sounds about right, would have been nice to have more but it is what it is. There was certainly plenty of hanky panky going on but even us nerdy engineers knew "no" meant know unless you were in the middle of a massive flirt session. We were pretty nerdy so I'm sure there were plenty of signals that we missed, guys seem good at that and nerds are exceptional at that (ask me how I know. Sigh. I'd love to get a second chance and be 25 again with what I know now). On Sat, Feb 16, 2019 at 07:35:53AM +1000, Warren Toomey wrote: > All, I'll kick off the conversation restart here on the COFF list with the > original link. > > https://www.nytimes.com/2019/02/13/magazine/women-coding-computer-programming.html > > Cheers, Warren > _______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From dave at horsfall.org Mon Feb 18 06:39:29 2019 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 18 Feb 2019 07:39:29 +1100 (EST) Subject: [COFF] Happy birthday, Dick Hustvedt! Message-ID: Dick Hustvedt was born on this day in 1946; an architect of RSX-11 and VMS, he also had a weird sense of humour which he demonstrated by enshrining the "microfortnight" into VMS in order to make admins RTFM. Sadly, we lost him in a car accident in 2008. -- Dave