> On May 26, 2013, at 1:57, [email protected] wrote: > >> It is unreasonable to expect a community to contribute to the >> development of Plan 9 if the goal posts move with the fashion... > > You may agree or not with Erik's position, but this is an > unreasonable characterization of it. It actually feels exactly > backwards to me: he's proposing we *not* move the goalposts (or move > them much less). I don't believe he's saying not to support SSE, but > rather to support it in the more modern kernel. 386 would still be > around, but putting effort into amd64 is likely the more productive > use of time.
I guess we're looking at the issue from different philosophical points of view and we miss the wood for the trees: Erik is in a position to use the most recent available equipment, my most recent "386" motherboard is the only one with SATA on board and an Intel 64-bit CPU. My criticism lies with a propensity to disregard the impact of following the fashion has on primitive equipment like mine: if SSE2 is _enforced_ as the only option (as nearly happened with Go - more about that in a minute), then, like Alef and IL, we'll lose conventional 387 capabilities and most of my equipment, specially some of my more expensive stuff like the co-located server in Cape Town, will become redundant. This has two drawbacks for me: (a) the comfortable niche Plan 9 found in my environment will be lost as I will no longer have the same confidence in Plan 9 I built in the last many years and (b) I will no longer have the equipment to assist with further development of Plan 9. Also, let me make it clear that I meant absolutely no disrespect towards Erik personally or of his contribution to the Plan 9 project; on the contrary, I have every reason to be grateful to Erik for the many ways in which he has assisted the project and, frequently, helped me personally. You seem to have misunderstood my position as criticising Erik for abandoning SSE2 on the 32-bit equipment. I was trying to suggest that we should not abandon 387 on the same and, to make things clear, I have no concern if we discard 387 capabilities in the 64-bit world, as long as we don't reflect that where 387 is the only option. I'm not sure how we got these wires crossed :-) Going back to the 387/SSE2 issue, in the Go development forum discussion has stopped without resolving the issue of how to deal with the need to continue to support the 387 instructions while also wanting to benefit from the more powerful and, I presume, efficient SSE2 alternative. As these are mutually exclusive (go figure!) the immediate problem is that the Go developers had to choose which option to release for Go 1.1. The choice went with SSE2, which means that a smaller number of users needed to build Go from sources. It was easy for me to agree with that decision, I'm prepared to pay a reasonable price to retain the ability to use Go and, in my case, I build Go from sources all the time anyway. I think those who cannot do so can probably pressure others besides the Go developers to release binary Go versions for slightly different architectures. There are two outstanding issues, though. On the one hand, the problem the Go developers faced is also a pain for Go users that want to release software (applications, for example) to the public. On the other, there is no clear strategy on how to hold different versions of the Go toolchain as well as Go applications for the 386 architecture: discrimination in the file system ends at the architecture and taking it a level further seems too burdensome for the nett gain. ++L
