From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <5097e190aef16d0162d5306987028552@proxima.alt.za> To: 9fans@9fans.net Date: Wed, 4 Dec 2013 06:25:33 +0200 From: lucio@proxima.alt.za In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Go and 21-bit runes (and a bit of Go status) Topicbox-Message-UUID: 920aea2e-ead8-11e9-9d60-3106f5b1d025 > but it's not a question of forking the library. there's a ton of stuff > under go/src, > so what makes libbio special? I'm not sure where the wires get crossed, let's see if I can get my point across or, alternatively, if I can figure out what I'm missing. In building the Go tool chain, in Plan 9, only libmach, of the libararies required, differs substantially from the Go release version to require special functionality. The differences aren't irreconcilable, but they are pretty vast. For a more Posix-y environment, lib9 and libbio are also required to provide features that Plan 9 has natively. Lib9 mirrors libc and libbio is analogous to "the real thing". My contention is that we ought to keep these differences to an absolute minimum and, specifically, we ought to avoid libbio diverging from the Plan 9 native version - at the cost of altering the latter, if necessary - so that the two systems are kept closer together. The point here is that once we grant licence for libbio to diverge, there is no limit to how far it will go and any efforts to bring either in line with the other will be as difficult as it would be now for libmach. Libmach and lib9 both show how far apart this divergence will go if encouraged. It is moot, I grant that, but as a responsible citizen, I feel it is my duty not to create conditions than future generations can't recover from, at least as long as there is an option. Yeah, it's a philosophical line in the sand, but you did ask where I was drawing it and I'm hoping I have made it a little clearer (even to myself). ++L