Well, this quickly devolved from an interesting exchange on the risk considerations for FOSS vs. Proprietary software to mix of mud-slinging and idealistic perspectives.
In particular, the subtle attacks on the efficacy in which a poster does his or her job started by Greg have no place on this list. Of course as an administrator you should do your research about what software you're using in a foundational manner within your business -- it doesn't take a genius nor even an idiot to figure that out, and making these level of "suggestions" merely stoke a embers because their real purpose is clear. Plus, simply stating one should "choose more carefully" has the benefit of 20/20 hindsight. Anyone can say that about a mistake somebody else made. These variety of comments are wholly pointless on this, and really any, email list. Provided you aren't the boss of one of the other posters, we should all make an effort to avoid these comments. On 09/16/2012 07:16 PM, Joe Landman wrote: >> > In addition. Could we, a company of 15 people pay for the continued >> > development and support of OpenIndina? > Yes, if this is what you wished to use. Or you could do it yourself. I think many of your points Joe are well-made, but I think you see things in a very different, maybe even slightly idealistic light because of the way your business works (as I understand it as an outside observer, so pardon any misunderstanding here). You and (I suspect you do your own hiring) your employees make a business out of tuning every aspect of your product. With the gap between CPU improvements and disk bandwidth growing annually and the inane (in my honest opinion) layout and API of the I/O stack, tuning can go a long way and misconfiguration can hurt a great deal. So for you, having the source available for every level of your product is less a risk-adverse choice than a near-absolute necessity for building fast storage. If you couldn't tune some buffer size or whatever because it was inconfigurable and closed-source you would be in some special kind of creek, probably without a boat-driving device. However...I can imagine many other businesses try not to worry about the OS outside of "will it be there and be supported in X years for a /REASONABLE/ cost." The reasonable part is crucial here, and goes back to my (so far unremarked upon) argument that FOSS vs. Proprietary risk depends heavily on the size of the source you are trying to work with. You suggested in the quoted text above that Andrew's company could continue to develop and support OI. This is, from what I can tell from Andrew's comments, NOT what he (or as I claim, most companies) wants to do because of the cost and effort involved there. It would be a MASSIVE undertaking to not only patch an OS, but eventually keep it up to speed with thousands of perpetually updating packages that you want to support. I don't care if you have 15 or 1500 employees, the up-front and recurring costs of being the sole maintainers of your own OS are huge. And you can't /just/ patch an OS as you suggest -- that might hold your sinking ship afloat for a year or maybe a tad longer, but after that you'll eventually want one of your packages updated and dependency hell will jump in to make sure all of your other packages need updated too. You'll either stagnate into irrelevancy or you'll move on to another OS. Providing full, in-house support for an OS (for MOST businesses) is just not reasonable. So in conclusion, while I think Joe's suggestions are on the money, I think they only remain on the money when we are considering tractably sized projects (small to medium probably). Once you get to talking about large projects like distributions, kernels, shoot even word processors, then the risk you are avoiding is far outweighed by the costs your incurring to avoid that risk. In short: Risk isn't everything. Risk sucks, indeed, and we should avoid it where we can by using FOSS projects, but totally avoiding it has a price too, and it gets much, much more expensive for larger projects. For small projects where there are equal offerings for FOSS and commercial, FOSS will dominate. But for large projects where there are equal offerings for FOSS and commercial...well...that really depends. No matter how open that FOSS project might be, if it is too sprawling it might end up being just as impossible, for fiscal rather than pragmatic reasons, to keep it updated as its closed-source brethren. Best, ellis _______________________________________________ Beowulf mailing list, Beowulf@beowulf.org sponsored by Penguin Computing To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
