00:19:34 alanc: Do you recall where the "gate" noun usage started? 00:19:59 I am idlely curious about the etymology 00:26:49 long before my time at Sun 00:28:37 so pre ... 2000? 00:28:39 https://twitter.com/clairegiordano/status/666410305811935234 traces it back to SunOS 5.0 00:28:49 ah wow 00:29:28 https://twitter.com/bcantrill/status/666762329380401154 says it was pre-1987 00:33:22 so we may never know haha 00:38:26 heh, the 4.0 sources have an ancient RULES file from 1983 by Bill Shannon which describes just editing files in the master source tree - no concept of gate or putback yet 00:40:19 My assumption is it comes from the use of "gate" in project management literature 00:42:19 could be - as we discussed a week or two ago, https://illumos.org/docs/contributing/qds/ is from the transition in 1994 from each team having their own repo and their own gatekeeper who took care of integrateing their teams changes back to the master gate to having everyone work off the same master gate 14:47:55 jclulow & alanc --> ALSO we had -gate (the source of truth to which you sent changes) and -clone (a read-only copy used for people to update). 14:48:32 This happened because when it was NFS-served you got much better behavior for 100s of people updating their locals from read-only -clone instead of -gate. 14:49:12 (Teamware exacerbated the need for -clone vs. -gate too.) 14:50:14 but no keymasters 15:06:02 big gates like ON did that, smaller gates like X & CDE didn't bother 15:07:06 and yes, because TW used read-write locks, so you couldn't putback if someone was doing a multi-hour bringover across a slow trans-oceanic link 15:30:47 alanc: and to be clear, the reason why it was slow was not throughput but the speed-of-light-limited transatlantic latency of synchronous syscalls like stat() over NFS. 15:37:58 heh 15:38:41 * jbk saw a $60m project almost get completely derailed because a group (without asking anyone else) decided a critical part of it should be done by using NFS over a WAN for a critical portion of it :) 15:39:54 their time constraints for that piece were something like 40-48 hours... and 80 hours in during a dry run, wasn't anywhere near complete 15:50:48 ... it probably didn't help that the thing serving NFS was an S/390 running whatever IBM calls MVS now (z/OS I think?) 16:21:00 sounds like they could have replaced NFS over wan with fedexing a magtape.... 16:30:00 well much like the network, the S/390 is never at fault 16:30:19 all software written on it is perfect and without bugs 16:30:37 if something work, and they apply an upgrade, and someting breaks, it is _your_ system that didn't change that is at fault 16:32:04 the workaround for that was a 'fun' perl script that instead connected via ftp and compressed the data on the fly (from a V890 that was in the same DC) and then sent it across the wan to the e25k to uncompress and set it in place 16:32:26 The interface change had been on display for months in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Leopard'. 16:33:08 (though I suppose I should be thankful they had paid for the TCP/IP license on this mainframe) 16:33:35 i had a coworker that had to connect to a different one (for different reason) and had to run Sun's SNA stack :) 16:34:14 (and again, after an upgrade on the firmware, it stopped working, though the solution there ended up being clocking down the t1 line between the two from 1.54Mbps to 768k) 16:35:28 though that was the end result of months of work.. at one point he actually had the direct# of whoever worked on it at sun.. 19:13:21 [illumos-gate] 15728 bhyve vCPUs need to reach quiesce point -- Patrick Mooney