Date: Tue, 16 Oct 2001 09:26:17 -0500 (EST) From: Doug Hass <dhass@imagestream.com> To: Ted Mittelstaedt <tedm@toybox.placo.com> Cc: Jim Bryant <kc5vdj@yahoo.com>, MurrayTaylor <taylorm@bytecraft.au.com>, freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG, Alfred Shippen <ashippen@metromatics.com.au> Subject: RE: FYI Message-ID: <Pine.LNX.3.96.1011016090318.14954G-100000@ims1.imagestream.com> In-Reply-To: <000301c15614$f30c78a0$1401a8c0@tedm.placo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> The "hardware API" or the actual register interface code, is a binary-only > module that is "snapped in" to SAND. SAND is GPL and is similar to the > FreeBSD Netgraph module - it provides all the higher-level protocol stuff, > like > Frame Relay, PPP, HDLC, and such. SAND goes between the OS TCP/IP stack and > that binary only module. That's rather simplified, since SAND also does alot of other things, but you have the basics. > The reason that Imagestream went this road is that like Doug said, all > those hardware vendors like Rockwell think that there's something > valuable in a pure register interface spec publication for their > products. So, this way Imagestream can sign their souls away to get > access to that interface spec - but they isolate all that contaminated > code in this binary snap-in module. It's a hack of a solution but > unfortunately is getting more and more common under UNIX because the > Linux people have caved in and are busily screwing their own principles > of GPL, by soliciting ever greater amounts of closed-source, Linux code. > Imagestream isn't the only one out there doing this. Well, not exactly. The SAND architecture was written long before we ever licensed one line of code from ANYONE. The idea behind the hardware modules was very similar to what Netgraph provides. You can "snap in" new hardware, software or pre- and post-processing modules without having to make accomodations in the other code. > Now, you can make all the technical arguments you want about how a modularized > development environment like this allows code reuse and this is quite > true - but you must keep in mind that SAND's modularized development has > a primary goal of being able to keep the contaminated code in the driver > snap-in modules, code reuse is secondary. Again, this is incorrect. Code reuse and shorter devlopment cycles were the reason for SAND. The hardware module code is NOT all licensed code. With the exception of the ATM cards, there's more free code than licensed code in the hardware modules. > It's incorrect because it's perfectly possible to write a monolithic > driver under FreeBSD that's only available as an object module and > instead links in to the FreeBSD answer to SAND - which is Netgraph. > This is exactly how the WANic 400 driver is now. (except of course > the WANic 4xx driver is source available) It is possible to have a monolithic driver set, but it doesn't accomplish the objective that we have (and you noted): to have ONE code tree for ALL platforms (save Windows, which is a different animal altogether). We don't want to see a return to the monolithic drivers of old under ANY platform. I'm not saying that monolithic drivers aren't possible, just that they aren't going to happen again. > But you see that in this area SAND is no more standard than Netgraph is. > SAND provides Linux users that run WANic cards a lot of stuff - but it > is GPL which makes it difficult to use in many commercial FreeBSD > projects. I don't think the use of GPL or LGPL prevents anyone from using it in a commercial project with FreeBSD, Linux or any OS. ImageStream, and other companies, are successfully using GPL and LGPL code in commercial projects. > It's been discussed to death in this forum before but the worst possible > thing that Imagestream could have done was to put SAND under GPL. If you > had simply put it under BSD license then BOTH the BSD and Linux people > could have used it, in fact Netgraph may have never been written, and a > lot of other commercial UNIX's might have used it too (like Apple's > MacOS X) I'll disagree, but the discussion is digressing here from where we started. I'm as disinterested in a license war as I was in an OS war. > I believe you, I believe you. But, did the decision makers at SBS even know > that the BSD community currently can't use the 500 series and above? And > that discontinuting it would cut out that section of their market? Did you > guys know that? They knew it. We knew it. It was such a small portion of the total market that they didn't care. We care, which is why I'm taking the time to have this discussion with all of you. > During that time I've seen WANic or RISCom cards come up for bid exactly SIX > times. And, THREE of the times I was the sole bidder and bought them. The > other three times, well one was a 56K card, another the seller wanted $500 > (hah) and the other the seller wanted another rediculous amount. During that > time I've also kept tabs on what the commercial networking resale vendors > that I also buy from have been doing and I've not seen anything at all marked > RISCom, WANic, or Imagestream. So it's a limited option. I'd never buy commodity hardware used when you could buy it new for next to nothing (compared to even most USED Cisco gear). > 1) The cards are almost impossible to identify if they are just loose with > no documentation. Some vendors slap their moniker in unmistakable letters > across all their cards, SDL/SBS and you guys never did. Incorrect. The SDL or SBS moniker and the words "WANic 400" and the part number are on EVERY card. Ultimately, you CAN get your hands on used equipment. It isn't easy, nor is it desirable in most situations, but it IS an option. I wasn't even the one who suggested it. I just included it in the list. > >2) WANic 400 series cards are still available in quantity. If the market > >for FreeBSD is as large as you claim, then you or someone else in the > >community should have no problem snapping up a quantity of these cards and > >reselling them to interested parties. > > As you know, price determines everything. At $777 per WANic405, you elected > NOT to purchase 100 of them from SBS and just warehouse them. (I'll assume > that your probably paying at least $500 per card, which is $50K for that > quantity of 100) If SBS is going to continue to have that offer of they > will sell them to you at lots of 100, why then in your shoes I'd make > the same decision, because with SBS dumping 1000 of the cards on the > used market, you could be putting $50K into a white elephant. I mean, if > you sell 100 WANic cards a year, why then if SBS dumped 1000 of them, > that's a 10 year supply floating around out there. SBS didn't dump 1000 WANic 400s. One of their OEMs who moved to the 520 series cards did. SBS had nothing to do with that auction. They dumped (sold at regular prices, really) about 400 cards to us and their OEMs. I know who won the auction on the cards, and I doubt you'll see more than a handful ever on the market for resale. The current price at 1 off retail is $676-$693, not $777. The price for 100, which is the minimum quantity required to support a special build, is 20% off of that, or $541. > Now, if SBS is willing to do a lot of 100 cards at a wholesale price of, > say $50 dollars a card, then I and a lot of other people could probably > round up 100 sales very quickly at $100 per card. And you know that this is unreasonable, since you couldn't source the components for $50, much less put together a card. > This is a kind offer but you have to put some pricing to it. If your > only selling them in lots of 100 cards, at the price on your website of > $777 per card, that's 15% off a $77K sale. I'd guess that your volume > discounts would drop that $77K quite a bit - but still out of reach > of an individual company, of course. Well, if the market is as big as you keep saying, 100 cards should be easy to swallow. As I've said, the price is roughly $541, not $777. > But this is all academic marketing of course - because at those dollar > levels, it's far cheaper to simply pay a developer to write FreeBSD > drivers for the WANic 5xx series of cards and deal with the licensing > issues. That's an option, too. One that has been available to everyone for over 5 years. I just was providing another incentive that a) solved the supply problems with the 400s and b) got drivers for all of the cards. > >3) Virtually ALL of our customers, save for OEMs making their own > >products, purchase complete routers. Going this route would eliminate the > >need to have FreeBSD support, as any user would have a standalone router. > > > > Remember, your talking to a bunch of FreeBSD people here, they might not > want a router based on Linux. > They use routers based on IOS, desktops based on Windows, and lots of embedded OSes (including Linux, in some cases, I'll bet). Are you suggesting that all FreeBSD users are OS zealots and refuse to use anything but FreeBSD everywhere? I would disagree with that indictment of the community. Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.96.1011016090318.14954G-100000>