From owner-freebsd-hackers Sat Feb 13 11:22:18 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA05658 for freebsd-hackers-outgoing; Sat, 13 Feb 1999 11:22:18 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA05649 for ; Sat, 13 Feb 1999 11:22:16 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id LAA23366; Sat, 13 Feb 1999 11:21:32 -0800 Date: Sat, 13 Feb 1999 11:21:32 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Jamie Lawrence cc: freebsd-hackers@FreeBSD.ORG Subject: Re: softupdates In-Reply-To: <4.1.19990213000333.0765d230@204.74.82.151> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > >They're even less open than Microsoft. A newer Novell. And I know whereof > >of what I speak- I worked with a large chunk of these folks either at > >Auspex or Sun. > > In some respects, I know you're right. In others, Netapp is > the shit. I'm not going to argue credentials; only performance. Heh. I shouldn't have worded my last sentence that way. > > I don't yet know that they're more reliable; I'm having trouble with > the multiport interface (4 100bT on a card, connected to some Solaris > boxes, to be clear on how off-topic this is). > > When it does work, it is all {T|t}hey promise. I have yet to > see it balk at 5 saturated 100Bt FD connections, at least when I can > make them all work. I suspect I'm doing something wrong with mine. > I will post if that's not the case. In any case, the vast majority > of the time, the Netapp is amazingly fast and robust (if not awe > inspiring when one considers cost...). I'm not saying that they don't do really good work- they do. Much like the model at Auspex, they really optimize data paths and keep data paths separate from control paths. There's classic story for Auspex where the Host Processor (running SunOS) crashed and stayed crashed for some weeks before anyone noticed, despite being the main NFS server for that company. The problem with NetApp is like the problem with a monarchy- you can have a good monarch, and a lot of good may be accomplished. You can have a bad monarch and you all suffer and nothing can be done about it. That NetApp is wonderful and cost effective for today doesn't say what it will be next year. There are some who say that economic factors will ensure that if NetApp (or other like it, e.g. Microsoft) doesn't continue to provide the best product, they'll disappear from the market as customers desert them for better solutions. That's arrant nonsense for the short term (due to capital budget cycles, imperfect information, partially closed markets (can you spell 'oligopoly'?), and the lack of objective comparators (I mean, how do you compare NT's server management tools, Tivoli on Solaris, etc., except qualitatively?)) and irrelevant in the medium and long term. Because they're an intensely proprietary company where they *really* only care about the effectiveness of what they do (as measured in revenues and share value), almost to Randite intensity, I'm sometimes tempted to argue that the use of NetApp's products verges on social irresponsiblity. But that just exposes my weakness for hyperbole. > > >There are two factors being pursued- one is service goals, and the other > >is research/development/tech-transfer. If the former goal was the only > >one, *BSD/Linux would not be considered as it isn't a warrantable item. > > Sure. That's why we spent a (frankly) ridiculous amount of money on > a Netapp. Support would have saved us a bundle, maybe. Real world, > right-here-right-now-we're-doing-it-today applications tend to have > nontechnical restraints imposed on them, which hurt; having technical > (non)-assurances layered on top create a barrier that no zealot can > honestly penetrate, FreeBSD or no. > > I hate (will become hated) to say this, but if taking on Netapp is > a goal, there's a huge hardware requirement for the port, and then > there's probably a steep performance curve. No, their hardware is fairly standard. It started as being commodity PC motherboards, and is now, I believe, fairly standard Alpha motherboards (they do those, I believe). It's not a question of 'competing' with NetApp. It's also a difference of approach and philosophy. They claim to have no interest in an 'OS'- they just want to provide a toaster. If that were really the case then they wouldn't need as much administrative tools as they do have. It's not good to get wrapped up in the System for the sake of the System (as BSD or Solaris or NT zealots can do), but it's even less good to say that you aren't and thus attempt to oversimplify and make static things that by there very nature are protean and complex. NetApp wants your servers to be toasters or coffee grinders. In reality, your servers are organisms (virtual in that the users and maintainers are also part of the organism) that grow and make mistakes and learn. And also, eventually, die. Sigh. Sorry- very off topic. Won't happen again, and, no, I'm not joining one of the advocacy aliases. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message