> No, I already pointed out the distinction between "new, experimental > features;" and "essential components of the FreeBSD operating system." > It's Ok for you to disagree with that distinction, or with its > importance. But what you're suggesting is that if users don't help > developers debug "cool new feature X" then we won't have "cool new > feature X." By implication you're saying that if we don't continue to > develop cool new features then at some point down the road we wither and > die. What I have tried ever-so-delicately to avoid saying is that lack > of user help with debugging "cool new feature X" is generally a sign of > lack of user demand for "cool new feature X." Not all cool new ideas are > good ones. :) Considering there are firewall vendors and CDNs making consistent use of it because it dramatically increases the sustainable data rates it is a bit cavalier to say that there is a "lack of demand." It doesn't show up directly as a lack of demand when FreeBSD drastically underperforms linux in a high bandwidth environment. The solution is for the user to simply switch to linux how is a user to know (parodying Star Trek technobabble) "Darn it, if only FreeBSD provided an exponential phase inverter on the warp core in the network stack." All he or she will see is it is slow. Or another very concrete example is iX keeps losing sales because ZFS doesn't perform adequately. ZFS doesn't perform adequately largely because the VM system can't map and can't recycle pages fast enough because of locking limitations. It has nothing to do with the storage stack itself. However, most developers themselves are not familiar with the issues much less users. So if I were to make further locking changes I would initially inevitably break some things. Your response would be that it isn't something users want. You're absolutely right, because current users with higher performance demands DON'T USE FreeBSD. Now you may wish to cut hairs by saying well ... locking we need flowtable we don't. However, the gist of that would be that things that you don't understand, that don't solve anyone's immediate problems "user's don't want." For many prospective server class users the current performance profile is a bigger deterrent than the fact that Cairo took tons of hand-wringing to build and so I spent hours just getting a broken chat client to install and once I did OTR support didn't work. Taken collectively the "cool new feature X"s are every bit as important to FreeBSD as ports. > OTOH, if we don't fix the fundamental problems with ports, and other key > areas of the operating system, we're just not going to have users, > period. Given that most of the developers (like you) have stopped using > FreeBSD on a day-to-day basis, who can blame them? Not necessarily. Most big shops don't really use ports as is. Particularly appliance vendors don't care about how package management is handled. But yes, in principle we could end up with no desktop users. > Doug > > -- > > This .signature sanitized for your protection -- “The real damage is done by those millions who want to 'get by.' The ordinary men who just want to be left in peace. Those who don’t want their little lives disturbed by anything bigger than themselves. Those with no sides and no causes. Those who won’t take measure of their own strength, for fear of antagonizing their own weakness. Those who don’t like to make waves—or enemies. Those for whom freedom, honour, truth, and principles are only literature. Those who live small, love small, die small. It’s the reductionist approach to life: if you keep it small, you’ll keep it under control. If you don’t make any noise, the bogeyman won’t find you. But it’s all an illusion, because they die too, those people who roll up their spirits into tiny little balls so as to be safe. Safe?! >From what? Life is always on the edge of death; narrow streets lead to the same place as wide avenues, and a little candle burns itself out just like a flaming torch does. I choose my own way to burn.” Sophie SchollReceived on Fri Mar 02 2012 - 18:18:47 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:24 UTC