alanc: Do you recall where the "gate" noun usage started?

I am idlely curious about the etymology

long before my time at Sun

so pre ... 2000?

twitter.com/clairegiordano/status/666410305811935234 traces it back to SunOS 5.0

ah wow

twitter.com/bcantrill/status/666762329380401154 says it was pre-1987

so we may never know haha

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

My assumption is it comes from the use of "gate" in project management literature

could be - as we discussed a week or two ago, 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

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).

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.

(Teamware exacerbated the need for -clone vs. -gate too.)

but no keymasters

big gates like ON did that, smaller gates like X & CDE didn't bother

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

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.

heh

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

... it probably didn't help that the thing serving NFS was an S/390 running whatever IBM calls MVS now (z/OS I think?)

sounds like they could have replaced NFS over wan with fedexing a magtape....

well much like the network, the S/390 is never at fault

all software written on it is perfect and without bugs

if something work, and they apply an upgrade, and someting breaks, it is _your_ system that didn't change that is at fault

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

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'.

(though I suppose I should be thankful they had paid for the TCP/IP license on this mainframe)

i had a coworker that had to connect to a different one (for different reason) and had to run Sun's SNA stack :)

(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)

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..

[illumos-gate] 15728 bhyve vCPUs need to reach quiesce point -- Patrick Mooney <pmooney⊙pc>