>> It's not an either-or proposition. I believe we can keep our existing >> user base while also growing it to include those who have tradionally >> (or at least during the past 5-10 years) have used Linux. > > I didn't say we couldn't, just that the approach of "go GNU" is the > wrong way to do it, and actually alienates a lot of people who truly > love solaris in order to attract people who would prefer linux import > the 2 flashy features rather than having to learn a new OS
Okay, but nowhere did I say we should "go GNU". It's possible that none of the GNU tools are suitable replacements. But it's also possible for some of them to be mature enough (with mature upstream communities) to end up being the default. >> John, I thought you were at the OpenSolaris Developer's Summit? >> Perhaps you missed my "talk" but the incremental approach was exactly >> one of the options that I discussed. In many cases, it's exactly the >> right way to approach a particular command but there might be other >> cases where a replacement with another open-source alternative may >> be a >> better approach. > > incrementally flushing something down the toilet is still flushing it > down the toilet. What will you do when the GNU guys make an > incompatible change? They don't have anything like ARC so it happens > all the time... will you continue to use the old version? you'll catch > flack for using "outdated" software. will you use the new one, and > break things ( I should hope the engineering teams and ARC revoke > commit privileges to anyone who did that ) ? That's an excellent question and I think part of the evaluation of any tool replacement is an examination of the upstream community and their track record. And on that basis alone, many potential replacements may fall by the wayside. But the analysis deserves to be done along with the initial analysis of the relative merits between what's currently in OpenSolaris and what else is out there. > A much better approach is to use what we've got, and improve it as > need/want necessitates, such as adding -z to tar(1) rather than using > gnu tar. We can fix tar(1), it's in a sun-controlled tree. We can't > fix gnu tar without upstream accepting the patches ( and maybe they > don't want to accept them ) I used to be in favor of this approach but from my perspective, we've done a fairly poor job of prioritizing such changes in the tools. But one of the modernization options is certainly to add support for features from GNU or other sources to the existing commands. dsc _______________________________________________ indiana-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
