On Apr 6, 2014, at 2:34 PM, Adrian Chadd <adr...@freebsd.org> wrote:
> So if we want to be taken seriously by those funny companies that make CPUs, > then: Not really religious about that at all, I just wonder the following: 1. How long will it be considered worthwhile to not be able to have various advanced features in base (like blocks, or someday perhaps, more advanced C++ features / GC / yada yada yada) because the lowest common denominator compiler technology, probably not even under control of the project itself (those “weird-ass compiler ports” David mentioned), simply doesn’t support those things? Moreover, there’s not much incentive for the companies in question to modernize their toolchains if FreeBSD is happy to remain somewhere in the 1990s in terms of what compiler features it leverages, and it’s not particularly clear to me how the presence / participation (?) of those companies is being valued in the overall scheme of things. If one lone MIPS R3000 vendor was holding back because it was using the Mongoose-V radiation-hardened part (yeah, that’s a real thing) and FreeBSD for some solution, would that be worth holding the entire project back? No? How about two such vendors? Three? Where do you draw the line? I don’t even pretend to have the answer to that question, I just think it’s a question worth asking. Also, JFYI, I don’t really have any strong personal agenda where this is concerned - I can just keep taking FreeBSD and hacking it up every which way such that “what’s in base” becomes increasingly irrelevant to me, but the more I diverge, the less easy it becomes to upstream stuff back. I already had that experience once at Apple, and it ultimately didn’t hold me back at all so the “omg the cost of forking” argument is no longer one that holds much fear for me, but it’s a shame that all the I18N / UNIX03 / numerics optimization / … work that occurred in the open over the first 3-5 years I was there was never able to benefit FreeBSD because of said divergence, either. 2. What’s the long-term prognosis on a multi-architecture ecosystem? I certainly remember the “good old days” when any company that knew how to solder two transistors together had their own CPU architecture, but those folks have been dying off for decades now. Now we have Intel as the long-dominant 900 pound gorilla, which is why FreeBSD originally chose to focus almost exclusively on that architecture (and I think that was a smart decision), and the smaller but still feisty ARM architecture. That’s about it. Yes, I know about the others, but just because a port *can* be done doesn’t necessarily mean it *should* be, and I’ll cite the Alpha and Itanium ports as existence proofs of that. Heck, I was a huge proponent of the Alpha port - I wanted a 64 bit version of FreeBSD back then so badly I could taste it, and I personally thought the Alpha was pretty damn cool - I even had one of my own. Didn’t make it such a good idea in hindsight, however. Again, if there’s a common theme in my two bullets there, it’s “show me the numbers!” Sure, I know of vendors who use MIPS and, for that matter, PowerPC and a few other far more obscure architectures as well. I’m familiar with Juniper and Cisco’s interest. I even read Warner’s slides from BSDCan 2008, where a fairly long and slightly sordid tale is told of MIPS support trying repeatedly to get into the tree, being repeatedly rebuffed until it finally somehow took root through a semi-cabalistic effort with dark rituals involving dead chickens and Perforce. Now it’s 2014 and apparently we can’t have nice things in the tree because of MIPS? Maybe I’m over-simplifying the argument, but even simplistically I would easily understand it if you substituted “ARM” or “Intel” because I can count those numbers easily and know without even trying that there are at least 7 zeros involved in the total. Every PC ever shipped. Every Samsung phone. Big and impressive numbers that can’t be argued with. I’m just not getting the same impression from the other architectures under discussion here. - Jordan _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
