Re: kernel panic at boot on any 6.x OS
- Original Message - From: "Joe Auty" <[EMAIL PROTECTED]> To: "Daan Vreeken [PA4DAN]" <[EMAIL PROTECTED]> Cc: "Kip Macy" <[EMAIL PROTECTED]>; ; Sent: Sunday, February 25, 2007 8:14 AM Subject: Re: kernel panic at boot on any 6.x OS > > Any idea how this could have happened after disabling everything in > my /etc/loader.conf, and simply running a: > > make buildworld > make buildkernel KERNCONF=myconfig > make installkernel KERNCONF=myconfig > well your supposed to do this single-user, run mergemaster and a few other things. I also don't see a make installworld. Joe, please try booting from a 6.2-release install ISO. If it works without panicing, then you did something wrong during the upgrade. Since by your own admission your not an expert, you would be well advised to simply back up your files the old fashioned way, reformat your hard disk, install from a 6.2 boot ISO, then restore your files. Leave the fancy in-place updating to someone else. It's a big PIA and doesen't work half the time anyway. Ted ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kernel panic at boot on any 6.x OS
- Original Message - From: "Joe Auty" <[EMAIL PROTECTED]> To: "Ted Mittelstaedt" <[EMAIL PROTECTED]> Cc: "Daan Vreeken [PA4DAN]" <[EMAIL PROTECTED]>; "Kip Macy" <[EMAIL PROTECTED]>; ; Sent: Sunday, February 25, 2007 10:39 PM Subject: Re: kernel panic at boot on any 6.x OS > -BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On Feb 25, 2007, at 7:56 PM, Ted Mittelstaedt wrote: > > > > > - Original Message - > > From: "Joe Auty" <[EMAIL PROTECTED]> > > To: "Daan Vreeken [PA4DAN]" <[EMAIL PROTECTED]> > > Cc: "Kip Macy" <[EMAIL PROTECTED]>; ; > > > > Sent: Sunday, February 25, 2007 8:14 AM > > Subject: Re: kernel panic at boot on any 6.x OS > > > > > >> > >> Any idea how this could have happened after disabling everything in > >> my /etc/loader.conf, and simply running a: > >> > >> make buildworld > >> make buildkernel KERNCONF=myconfig > >> make installkernel KERNCONF=myconfig > >> > > > > well your supposed to do this single-user, run mergemaster and a > > few other > > things. > > I also don't see a make installworld. > > > > I usually perform those steps after I've rebooted to ensure that my > system will boot off the new kernel, as per the instructions in the > FreeBSD handbook. > > > Joe, please try booting from a 6.2-release install ISO. If it > > works without > > panicing, > > then you did something wrong during the upgrade. > > > > Downloading the image now, I'll let you know if I'm able to boot from > it... > > > Since by your own admission your not an expert, you would be well > > advised > > to simply back up your files the old fashioned way, reformat your > > hard disk, > > install from a 6.2 boot ISO, then restore your files. Leave the fancy > > in-place > > updating to someone else. It's a big PIA and doesen't work half > > the time > > anyway. > > > > > How well does simply upgrading with the CD work (as opposed to wiping > clean)? I've upgraded several times to new releases simply by > rebuilding world, it has never failed me in the past. I don't doubt > what you are saying here, but since I will have to change how I work, > assuming that I can boot off of the 6.2 CD, I'd appreciate any > general upgrade tips that don't involve wiping the disk clean (which > is not really an option). > If wiping the disk really isn't an option then you have one or more of the following problems: 1) Production system with a lack of hardware spares 2) inadequate backup plan and execution. People who state that wiping the disk isn't an option are screaming at the top of their lungs for the hardware gremlins to explain what MTBF is all about. The gremlins will visit you, I guarentee. And they always pick the very best times for it too. I just hope (if this is your workplace) that your job survives. > For instance, is rebuilding world between point releases (e.g. 5.4 to > 5.5) an okay idea, compared to across major releases (e.g. 5.5 to 6.2)? > > > I'll do my own homework regarding this too, but I appreciate any > nuggets of wisdom you might have! As far as me being an expert, I > guess I'd categorize me somewhere in between complete newb and > FreeBSD developer =) > The problem is that all of the ports and packages that you put on a server change from release to release. The developers of openssl, for example, don't give a tinkers damn about how FreeBSD's upgrade process works, when they are making changes in their code. I run a number of FreeBSD servers and what I do is simply keep them patched with security updates. Every once in a while a security hole will be discovered in a non-core program and if it's serious enough I'll go into the port and do a "make deinstall" followed by downloading and compiling the program the "old fashioned way" I shoot for a min of 3 years on the OS before even thinking about updating, and when it's time to update the hardware has generally reached the old rag stage anyway. Ted ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kernel panic at boot on any 6.x OS
- Original Message - From: "Mike Meyer" <[EMAIL PROTECTED]> To: "Ted Mittelstaedt" <[EMAIL PROTECTED]> Cc: "Joe Auty" <[EMAIL PROTECTED]>; "Daan Vreeken [PA4DAN]" <[EMAIL PROTECTED]>; "Kip Macy" <[EMAIL PROTECTED]>; ; Sent: Monday, February 26, 2007 8:36 AM Subject: Re: kernel panic at boot on any 6.x OS > > and do a "make deinstall" followed by downloading and compiling the program > > the "old fashioned way" I shoot for a min of 3 years on the OS before even > > thinking about updating, and when it's time to update the hardware has > > generally reached the old rag stage anyway. > > This works great for servers, that don't have any real users on them, > and is pretty much how I do things. I'll try updating the ports tree > and installing from that rather than building the old fashioned way, > because that works a surprising percentage of the time. > > On desktop and development systems, the users tend to get pissed if I > let things get that old. So I do upgrade them more often. That depends on who's paying for it. If your in-house support your screwed of course, since all of them think your labor hours are inexhaustable. But if the users are in a small business or whatever that has to actually pay real money to have their systems updated, then they are usually a lot less enthusiastic about new updates (at least, their owners are) > There are a > couple of things you can do to make reinstalling to a clean disk a bit > less painfull. > > 1) Intelligent file system layout. I put all the things that aren't > installed from the FreeBSD disks on their own partitions (/home and > /local). I can then wipe and reinstall /, /var and /usr without > clobbering the non-system data. > > 2) Mirrored disks. Disks for consumer systems are cheap. Throwing a > second one in a system and mirroring the system disk is a cheap way to > improve the reliability of the system. When it's time to upgrade, take > a drive out of the mirror, and install to that drive. You can reboot > to the old system if you need to interrupt the process and run the old > system for some reason. With a file system layout as per #1, you can > even mount the users files under both versions of the OS. When you're > happy with the new system, mirror the new system drive to the old one. > I do the mirroring thing too but the one thing you have to watch is inadequate cooling in some of these minitowers. Stacking the disks on top of each other with no cooling fan blowing air on them is not a good idea. Ted ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kernel panic at boot on any 6.x OS
- Original Message - From: "Joe Auty" <[EMAIL PROTECTED]> To: "Ted Mittelstaedt" <[EMAIL PROTECTED]> Cc: "Daan Vreeken [PA4DAN]" <[EMAIL PROTECTED]>; "Kip Macy" <[EMAIL PROTECTED]>; ; Sent: Monday, February 26, 2007 10:01 AM Subject: Re: kernel panic at boot on any 6.x OS > > On Feb 26, 2007, at 8:01 AM, Ted Mittelstaedt wrote: > > > > > - Original Message - > > From: "Joe Auty" <[EMAIL PROTECTED]> > > To: "Ted Mittelstaedt" <[EMAIL PROTECTED]> > > Cc: "Daan Vreeken [PA4DAN]" <[EMAIL PROTECTED]>; "Kip Macy" > > <[EMAIL PROTECTED]>; ; > > > > Sent: Sunday, February 25, 2007 10:39 PM > > Subject: Re: kernel panic at boot on any 6.x OS > > > > > >> -BEGIN PGP SIGNED MESSAGE- > >> Hash: SHA1 > >> > >> > >> On Feb 25, 2007, at 7:56 PM, Ted Mittelstaedt wrote: > >> > >>> > >>> - Original Message - > >>> From: "Joe Auty" <[EMAIL PROTECTED]> > >>> To: "Daan Vreeken [PA4DAN]" <[EMAIL PROTECTED]> > >>> Cc: "Kip Macy" <[EMAIL PROTECTED]>; >>> [EMAIL PROTECTED]>; > >>> > >>> Sent: Sunday, February 25, 2007 8:14 AM > >>> Subject: Re: kernel panic at boot on any 6.x OS > >>> > >>> > >>>> > >>>> Any idea how this could have happened after disabling everything in > >>>> my /etc/loader.conf, and simply running a: > >>>> > >>>> make buildworld > >>>> make buildkernel KERNCONF=myconfig > >>>> make installkernel KERNCONF=myconfig > >>>> > >>> > >>> well your supposed to do this single-user, run mergemaster and a > >>> few other > >>> things. > >>> I also don't see a make installworld. > >>> > >> > >> I usually perform those steps after I've rebooted to ensure that my > >> system will boot off the new kernel, as per the instructions in the > >> FreeBSD handbook. > >> > >>> Joe, please try booting from a 6.2-release install ISO. If it > >>> works without > >>> panicing, > >>> then you did something wrong during the upgrade. > >>> > >> > >> Downloading the image now, I'll let you know if I'm able to boot from > >> it... > >> > >>> Since by your own admission your not an expert, you would be well > >>> advised > >>> to simply back up your files the old fashioned way, reformat your > >>> hard disk, > >>> install from a 6.2 boot ISO, then restore your files. Leave the > >>> fancy > >>> in-place > >>> updating to someone else. It's a big PIA and doesen't work half > >>> the time > >>> anyway. > >>> > >> > >> > >> How well does simply upgrading with the CD work (as opposed to wiping > >> clean)? I've upgraded several times to new releases simply by > >> rebuilding world, it has never failed me in the past. I don't doubt > >> what you are saying here, but since I will have to change how I work, > >> assuming that I can boot off of the 6.2 CD, I'd appreciate any > >> general upgrade tips that don't involve wiping the disk clean (which > >> is not really an option). > >> > > > > If wiping the disk really isn't an option then you have one or more > > of the > > following > > problems: > > > > 1) Production system with a lack of hardware spares > > > > 2) inadequate backup plan and execution. > > > > People who state that wiping the disk isn't an option are screaming > > at the top of their lungs for the hardware gremlins to explain what > > MTBF is > > all about. > > > > The gremlins will visit you, I guarentee. And they always pick the > > very > > best > > times for it too. I just hope (if this is your workplace) that > > your job > > survives. > > > > My production system is backed up daily to two different sites, > that's not an issue. The system I'm thinking of upgrading to 6.2 is > my test server I run out of my house that stores movie files and > other non-essential files. Technically, wiping it clean *would* be an > option if it came down to it, just an inconvenience. Perhaps I should > in
What tty changes - question on porting ltmdm and hcfmdm to FreeBSD 8
Hi All, I have a pager monitoring system built on FreeBSD 6.4 that uses the ltmdm driver. (ltmdm is a "controllerless winmodem") I was looking into updating to FreeBSD 8 and I see that ltmdm and hcfmdm are now both broken. hcfmdm broke on FreeBSD 7 but it is easily patched to build on that. ltmdm worked on early FreeBSD 8 but after the tty changes went in it broke. I was looking into fixing both of these to build on 8 but it seems to be non-trivial. They both spew all kinds of errors of missing various tty structures, and when I search for those in the include files for 8 I get nothing. It seems there's been a fundamental change in FreeBSD 8 in this layer. In googling around I see that a number of other programs out there that talk to serial ports were also busted by the FreeBSD 8 tty changes. Some have been patched and some not. The ones that have been patched do not seem to have trivial patches made. Setting aside the question of why do we break software that a lot of people use (these chips are in use on a lot of laptops) is there a document somewhere that explains what changes need to be made in code for this new tty setup? Or, is there a set of magic include files or a "conversion shim" library that will allow these kinds of programs to build without much work? Or is porting these drivers just so non-trivial that the only way is to just delve into the system manuals and delve into the driver code and try to figure out what is going on in each? If that's the case that's probably beyond my ability but I'd be happy to serve as a testbed. Yes I know I can use FreeBSD 7 for now. Yes I know I can use an external modem, and that winmodems are evil, that I can send a page by e-mailing the paging company , yadda yadda yadda. If your only going to suggest a workaround, please don't. Thanks! Ted ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: What tty changes - question on porting ltmdm and hcfmdm to FreeBSD 8
On 4/24/2010 8:29 AM, M. Warner Losh wrote: In message:<20100424102255.12d78...@ernst.jennejohn.org> Gary Jennejohn writes: : On Fri, 23 Apr 2010 16:27:12 -0700 : Ted Mittelstaedt wrote: : :>Setting aside the question of why do we break software that a lot of :> people use :> (these chips are in use on a lot of laptops) is there a document :> somewhere that explains :> what changes need to be made in code for this new tty setup? Or, is :> there a set :> of magic include files or a "conversion shim" library that will allow :> these kinds :> of programs to build without much work? :> :>Or is porting these drivers just so non-trivial that the only way is :> to just delve into :> the system manuals and delve into the driver code and try to figure out :> what is :> going on in each? If that's the case that's probably beyond my ability :> but I'd :> be happy to serve as a testbed. :> : : The guy to ask about this would be Ed Schouten (ed@). AFAICR he did the new : TTY stuff. I don't know whether he reads these lists. : : AFAIK there is no easy way to fix this and there are no backwards compati- : bilty shims or magic header files. : : The fundamental problem with ltmdm is that it's a KLD and has to grovel : around in the guts of the kernel. That makes fixing it decidely non- : trivial. The fundamental reason that things changed was due to the locking of the TTY layer. These things change over time, and the old APIs made it very difficult to lock without driver visible changes. Warner I mailed Ed and his response is to look at the changelog of sys/dev/uart/uart_tty.c for an idea of how to rewrite the driver, so I will take a look there. The ltmdm driver was updated in 2008 for an early version of FreeBSD 8, before the TTY layer changes went in, so that's where I'll start. Ted ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
RE: FreeBSD Mall now BSDCentral
sition of WC that started all this fuss. WindRiver's doings is just the end of a game that was started by BSDi. >it's not even clear to us that they want to stay in the >CDROM business anyway, Trust me THEY DON'T!!! If they did they would have moved heaven and earth to service all their customers and fulfilled orders instead of this schlocky excuse even if it took the President of WindRiver himself driving to the homes of the CD customers to hand-deliver the CD's. As it is the WindRiver president didn't even _sign_ the apology for not shipping the CD's! WindRiver wants to go out there and take the proprietary BSD code and make a shitpile of money in the embedded systems market. Fine, Great, More Power Too Them. I'm damn happy about it. I don't expect them to keep the CD distribution business going if they don't want it. LET THEM GO! But The FreeBSD Project is sticking it's head where the sun don't shine to even hint that WindRiver wants the distribution business. What's incumbent on the Project now is to make some hard choices and select 2 or at most 3 CDROM vendors who clearly DON'T step on each other's markets, and who clearly want to have the business, and designate them "Blessed" and let the CD distributors alone to repair all the damage done by this last fiasco. Then in a year or so when the users trust has been regained and the CD and toys shipping volumes are back to normal, why then if other CD vendors want in on the pie then the core can bless them too. If you try to do it your way your going to end up pissing off ALL the CD vendors and then we are going to be really, totally fucked. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: problem due to hostname change
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Pietro Cerutti > Sent: Thursday, March 17, 2005 7:42 AM > To: FreeBSD; freebsd-hackers@freebsd.org > Subject: Re: problem due to hostname change > > > > Well I double check once more on my system! > Unless your system is the dns server you need to do as I suggested and fix the DNS!! Ted ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: FYI
>-Original Message- >From: Doug Hass [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, October 17, 2001 9:19 AM >To: Ted Mittelstaedt >Cc: Leo Bicknell; Jim Bryant; MurrayTaylor; [EMAIL PROTECTED]; >[EMAIL PROTECTED] >Subject: RE: FYI > > >> Doug, in the entire history of the FreeBSD project, when given a choice >> between a better driver or code that is closed source, and a worse >> driver that has open source, the FreeBSD community has never chosen the >> driver or code with closed source. In fact I can only remember ONCE >> that the Project has recommended against freely available BSD code - and >> they did so in favor of GPL code, not closed source code - and this was >> for the coprocessor emulator (used for 386 and 486SX chips only) > >> The only time that FreeBSD gets involved in closed-source code is when >> there is simply NO other alternative - like in this case where the >> register interface specs are being withheld. > >We certainly support the right for companies to protect their intellectual >property in whatever way they see fit, even if the FreeBSD community does >not. > Whoah whoah here! Where did I say that FreeBSD didn't support intellectual property? Choosing not to include a lot of binary licensed code in the FreeBSD distribution is a free choice that the maintainers have made. How can you fault them for that?!?! I think that your ignoring a lot of issues here when you say that FreeBSD doesen't support IP. For starters I'm only stating what is current in the Project. Unlike Linux, there is not a large quantity of binary-only code distributed with FreeBSD distributions. Companies are free to distribute such as they see fit. Not many of them would allow binary-only code into the FreeBSD CD distribution anyway. In fact one of the reasons that the Ports directory is set up the way it is, is so that the project doesen't have to deal with a bunch of licensing issues. >The lack of flexibility in accepting various requirements illustrates the >difference between an OS WITH legs in the market and one WITHOUT legs. > >Much to my chagrin, FreeBSD continues to fall more and more into the >latter category. > This is a gross simplification of a great many issues. I fail to see why you feel that FreeBSD is threatening anyone's IP and I don't understand why you are reacting this way. Any company is free to take the FreeBSD distribution and customize it the way they want and include any proprietary and binary code they want and hand out distributions as they see fit. Imagestream could do this if it wanted to. I'm just saying that in the past the main FreeBSD distributions have preferred not to do this, and I see no indication that things are changing in the latest release. The fact is that just about everything included in the release has full source code. If Imagestream wants to release binary-only drivers for the WANic card and have them included in the FreeBSD distribution, since there's no alternative I'm sure that nobody would complain - unless Imagestream demanded that anyone getting a FreeBSD distribution with the drivers report back to them, or some such. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: FYI
>-Original Message- >From: Doug Hass [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, October 17, 2001 11:10 AM >To: void >Cc: Mike Smith; Ted Mittelstaedt; Leo Bicknell; Jim Bryant; >MurrayTaylor; [EMAIL PROTECTED]; [EMAIL PROTECTED] >Subject: Re: FYI > > >If you didn't say it, then you weren't the one I was talking about, was I? > >:-) > >I got several other private mails saying that BSD licensed code was the >one and only way, well Doug, there's a reason you got those as private mails instead of public posts - because this isn't the viewpoint of the FreeBSD community. >and 2 or 3 mails (from Ben, among others) saying that >BSD-licensed was preferred. > Preferred doesen't mean we are going to throw the baby out with the bathwater and turn up our nose at anyone's effort with FreeBSD. >Either approach is as flawed as someone who claims GPL only or GPL >preferred. The license terms of add-on drivers and products should be set >according to the needs of the authoring person or company, in my opinion. > This is a perfectly valid viewpoint that a lot of companies share which is why they don't include their drivers. For example Sangoma, and Emerging don't include FreeBSD drivers either - but they make them available from their own websites. In My Humble Opinion this is inferior than just giving the binaries over to the project and letting the drivers be handed out where they may, but those companies and you are welcome to do it that way if you prefer. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com >Doug > >On Wed, 17 Oct 2001, void wrote: > >> On Wed, Oct 17, 2001 at 12:19:34PM -0500, Doug Hass wrote: >> > >> > I'm glad someone else is speaking up--all I've heard is Ted's point of >> > view (from him, and from others who have said the same thing: >FreeBSD only >> > accepts BSD licensed code, period.) >> >> I said to you in private mail that where there's a BSD-licensed solution >> and a non-BSD-licensed solution, all else being roughly equal, FreeBSD >> tends towards the BSD-licensed solution. Not the same thing at all. >> >> -- >> Ben >> >> "An art scene of delight >> I created this to be ..." -- Sun Ra >> > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: FYI
>-Original Message- >From: Mike Smith [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, October 17, 2001 9:46 AM >To: Doug Hass >Cc: Ted Mittelstaedt; Leo Bicknell; Jim Bryant; MurrayTaylor; >[EMAIL PROTECTED]; [EMAIL PROTECTED] >Subject: Re: FYI > > >> > Doug, in the entire history of the FreeBSD project, when given a choice >> > between a better driver or code that is closed source, and a worse >> > driver that has open source, the FreeBSD community has never chosen the >> > driver or code with closed source. In fact I can only remember ONCE >> > that the Project has recommended against freely available BSD code - and >> > they did so in favor of GPL code, not closed source code - and this was >> > for the coprocessor emulator (used for 386 and 486SX chips only) >> >> > The only time that FreeBSD gets involved in closed-source code is when >> > there is simply NO other alternative - like in this case where the >> > register interface specs are being withheld. >> >> We certainly support the right for companies to protect their intellectual >> property in whatever way they see fit, even if the FreeBSD community does >> not. > >Doug; I would recommend against falling for Ted's flamebait here, since >that's really all it is. That's silly, what did you find in it that's flamebait? I think you didn't read it. >His characterisation of the FreeBSD Project's >attitude towards proprietary drivers fails to mention many of the other >factors that get weighed into these decisions, and I think he's missing a >lot of history. > No, I am well aware of FreeBSD's history and if you don't believe that the project avoids closed-source code then I don't know what to say, frankly. I clearly remember the ruckus over the Adaptec 2740 drivers and the long statement against Adaptec that used to be in the older versions of FreeBSD, that only had AHA 1740 code in them. If things have changed and the majority of the users in the FreeBSD project welcome closed-source code, then please point out where all of this is? I don't see it. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: FYI
>-Original Message- >From: Doug Hass [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, October 17, 2001 10:20 AM >To: Mike Smith >Cc: Ted Mittelstaedt; Leo Bicknell; Jim Bryant; MurrayTaylor; >[EMAIL PROTECTED]; [EMAIL PROTECTED] >Subject: Re: FYI > >I'm glad someone else is speaking up--all I've heard is Ted's point of >view (from him, and from others who have said the same thing: FreeBSD only >accepts BSD licensed code, period.) > That is not my point of view and if you read my mail you will see that and I will thank you very much not to go around saying that. To repeat: I said that "The only time that FreeBSD gets involved in closed-source code is when there is simply NO other alternative - like in this case where the register interface specs are being withheld." and "when given a choice between a better driver or code that is closed source, and a worse driver that has open source, the FreeBSD community has never chosen the driver or code with closed source" This is very far from saying that FreeBSD only accepts BSD licensed code, period. When we have a choice, we take the BSD code and improve it as necessary. Otherwise, we take what we can get. Sometimes, even, companies that release the stuff closed source end up opening it up when they see that by doing so that lots more people will contribute bugfixes and such. > >It's not a generalization at all. Honestly, compared to the market >traction that Linux, VxWorks, Solaris and others have, FreeBSD is >definitely without legs. FreeBSD is not a commercial product and there is no pressure for it to steal all the market share away from all the other UNIX and UNIX-like vendors. It's been proven by Microsoft rather well I think that the majority of computer users in the market will fight their way to junk and push the good stuff aside in their stampede. Even you must admit that if Imagestream had 80% of the router market that it would in no way, shape or form resemble what it is today. You would turn into Cisco. It's unavoidable, and just how life works. (this is not to infer that Cisco is junk, BTW, just that they are a big and often unresponsive company) >The WAN card and RAS card markets are good >examples of where the attitude toward "BSD-licensed code or bust" has >resulted in FreeBSD being largely left out of the party. Three of the >largest manufacturers in these segments (SBS, Cyclades, and Ariel) all >support Linux and NT, but do not have BSD support. > The Cyclades Cyclom-Y boards are supported by the "cy" driver in FreeBSD. This was not written by Cyclades. OK - so it's not a RAS card, but where was Cyclades? >It's too bad we can't find a way to include more companies and >solutions instead of continuing to find ways to EXCLUDE them... > It's a shame that so much misinformation is spread over the BSD license. Just ask yourself - why is it that the BSD license is such an object of controversy? People talk about the GPL being controversial? Sheesh! All the license says is to give away code for free. What a revolutionary idea! Most ironic is that it seems like 1/4 of the GPL advocates out there who are making noise about it want us all lined up against the wall and shot for saying that!!! Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Imagestream WanIC-520 interface cards
>-Original Message- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On >Behalf Of Louis A. Mamakos >Sent: Wednesday, October 17, 2001 4:31 PM >To: Ted Mittelstaedt >Cc: void; Matt Dillon; [EMAIL PROTECTED]; [EMAIL PROTECTED] >Subject: Re: Imagestream WanIC-520 interface cards > > > >> I am perfectly aware of this. >> >> The RBOCs deserved to have those "fines" levied against them for a number >> of years, to punish them for attempting to block the CLECs. However, it's >> been long enough for this, and in fact the money from the RBOCs is >no longer >> being used to increase the CLEC's reach or service area (ie: >infrastructure) >> and being used by the CLECS to bash each other, instead of bashing the >> RBOCS. > >The recip-comp charges have nothing to do with extending the reach of >a CLEC's network. It's (supposed) to cover the cost of carrying or >terminating an inbound POTS voice call. Back up a sec - the reason that Bellcore was busted up is because the trust people claimed that CLECs could provide voice dialup better and cheaper than ILECS by the sheer fact that they were competitive. The FCC has always pushed as hard as it could to give CLECs an advantage over RBOCS to promote competition. The RBOCS forced the call term charges as a fairness issue. Once it was discovered that the cash transfer was going towards the CLECS from the ILECS, the FCC couldn't have been happier. They never wanted things to be fair in the first place between the CLECS and the RBOCS. By the pro-breakup people's definition, the CLECS incur less cost than the RBOCS for terminating a call. If this was a fairness issue then the RBOCS would only have to pay the CLECS the actual cost incurred by the more efficient CLECS for the call term. But instead they pay what it costs the RBOCS to terminate a call (which is higher according to the pro-breakup people's definition) Now, obviously it's hard to know what the truth is because the entire point of Telco accounting is to so confuse the numbers that the PUC's and the FCC and all the other governmental regulators are so baffled by them that they pretty much throw their hands up in the air and accept whatever bullshit the phone companies care to dish out. Telco accounting is the science of making an absolute into a negotiated item. > >Huh? You might also explain the situation as subsidizing the cost >of providing Internet service. It's revenue coming into the business >which would otherwise need to come from some other source, such as the >customers. > And of course the entire point of running a Telco is to not make a profit by the customers that are supposedly paying you for the service your supposedly giving, but to screw everyone else in the business that's otherwise totally unaffiliated into paying for your customers. Yes, I know all about that. :-( >There are lots of other examples of charges and tariffs which telecom >carriers charge each other because of the bizzare reality set up by >FCC regulations. You simply siezed upon one with contemporary sex-appeal. > >If you want to rant about something, go take a look at how half-circuit >pricing is done for international private lines. Don't even get me started. There's a huge litany. Like, why are T1 charges so gouging yet DSL (which delivers more bandwidth in some cases) so rediculously low. Like, why is each trunk on a T1 charged at nearly the same rate as if it were provided by POTS yet it costs the phone company 10% of the expense to deliver trunks over T1 than POTS. Like why is mileage charges allowed in a calling area when it costs the phone company exactly the same amount to run a T1 5 miles as it does to run it 1 mile (and in some cases the CO is 4 miles from both endpoints so the total line length is 8 miles but they still only charge for 5) >You think the US >carriers are evil, go see what state-supported telecom monopolies get >to do. Or the hoops which much be jumped through to get licenses to >operate telecom, datacom, or Internet lines of business in some >countries around the world. > Ah - you mean like China. Don't forget all the state-sponsored porno filtering of the Internet feeds into Iran either. Yes there are some very nasty and greedy people in the world. Frankly, as long as the CLECs and ILECS are using the FCC to beat each other over the heads, I could care less. What I get mad about is that the CLECS seem to have given up fighting with the RBOCS and are turning against the ISPs. It's like they turn around and start bullying the ISP's simply because the ISP's are weaker than they are. Yet it was those ISP's that got the recipri-comp payments wacked out in the CLECs favor to start with. That's gratitude for you. Ted
RE: FYI
>-Original Message- >From: Bill Fumerola [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, October 17, 2001 11:13 PM >To: Ted Mittelstaedt >Cc: Doug Hass; Mike Smith; Leo Bicknell; Jim Bryant; MurrayTaylor; >[EMAIL PROTECTED]; [EMAIL PROTECTED] >Subject: Re: FYI > > >On Wed, Oct 17, 2001 at 10:51:25PM -0700, Ted Mittelstaedt wrote: > >> When we have a choice, we take the BSD code and improve it as necessary. >> Otherwise, we take what we can get. Sometimes, even, companies >that release >> the stuff >> closed source end up opening it up when they see that by doing so that lots >> more people will contribute bugfixes and such. > >you say 'we' an awful lot for someone who isn't part of, doesn't represent, >and is in no way affiliated with the freebsd project. > >thankfully, the project's official word can be found here: >http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ >policies-encumbered.html And, what exactly on this page is any different from what I've just said? Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: FYI
>-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED]]On Behalf Of Mike Smith >Sent: Wednesday, October 17, 2001 10:32 PM >To: Ted Mittelstaedt >Cc: Doug Hass; Leo Bicknell; Jim Bryant; MurrayTaylor; >[EMAIL PROTECTED]; [EMAIL PROTECTED] >Subject: Re: FYI > > >> That's silly, what did you find in it that's flamebait? I think you didn't >> read it. > >You're a) misrepresenting the project, b) dismissing the opinions and >statements of others that are arguably more in touch with the project, >and c) you won't let this stupid thread die. > I do not feel that this thread is stupid. To the contrary I'm very concerned when a manufacturer pulls a specialty card supported by FreeBSD off the market and replaces it with nothing that is supported. Every time this happens (and it seems to be happening a lot with network adapters lately) it causes problems for a lot of users, confusion because This rev of the card is supported and That rev isn't, extra work for the maintainers, and in short sets the project back. This does not help FreeBSD to support lots of peripherals, as Doug pointed out we are being ignored by the RAS card manufacturers, and nobody is going to use FreeBSD no matter how good the kernel is if the OS doesen't support the hardware they own. Telling Imagestream we built a module architecture that makes writing, maintaining and deploying binary-only drivers easy is fine, but it does nothing to respond to the problem of how to convert their binary drivers to our framework. They don't even understand we have a framework, let alone how it operates. They are asking us to write the drivers and they don't even understand that some of the developers that could do it have reservations against binary-only drivers only available under NDA, or how much more it could help them if they were to just publish source. And attempting to even talk about this openly leads into irrelevant pointless accusations about stealing intellectual property. Device driver support in PC operating systems seems always to have been a political football no matter what OS vendor - even Microsoft with all their power still was forced into writing drivers for some hardware, despite all the pressure they applied to the hardware vendors to do the work. You seem to be taking the attitude that "we made a framework, and that's as far as we go - you write the driver" and then labeling any further discussion on the matter as stupid. Well, if this is the attitude in the FreeBSD project (which I doubt) then if it was such an effective one then why does Linux seem to have many more drivers written for it? >> >> No, I am well aware of FreeBSD's history and if you don't believe that the >> project avoids closed-source code then I don't know what to say, frankly. > >You could say "I'm wrong". It'd be a good start. > OK, your right, I'm wrong. Contrary to my statement, FreeBSD attempts to get as much closed-source code as possible. That's why the name of the distribution starts with the word "Free" Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: (no subject)
>-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED]]On Behalf Of >[EMAIL PROTECTED] >Sent: Wednesday, November 28, 2001 8:27 PM >To: [EMAIL PROTECTED] >Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] >Subject: (no subject) > > >The concept that "netgraph hooks" are a "leg up" on say, ETs drivers that >have integrated bandwidth management and prioritization, WAN bridging >support, load balancing and a probably 25% performance advantage is a bit >entertaining. Unless you need to do some convoluted encapsulation netgraph >is, aside from being appallingly non-standard to anything else in >the market, > not much of an "advantage", and its a poster child for the trade off of >"flexibility" versus performance. > >Lets face it. If you were going to sit down and design an interface >for frame >relay, multi-protocol support, etc, you'd have to be smoking >something pretty >strong to come up with netgraph. But its free and there is source, so it >must be great! > Well, let me give you something else to put in your pipe and smoke. :-) I've spent about $800 on a few WANic 4xx cards (used, I'll grant) precisely because source for the driver is available. I happen to not use them with Frame circuits so I used the HDLC in the driver. I have spent $0.00 on ET cards precisely because the driver code is unavailable. Now, as I've never used ET cards, I'll take your statement at face value that their drivers are superior to the WANic one. But, I'm not going to pick a superior binary-only driver over an inferior source-freely-available driver, if I have a choice. You may think this is screwy but it's how I feel. I'm glad that ET is out there selling cards to the FreeBSD community but I wouldn't spend money on them as long as a source-freely-available alternative was around. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Imagestream WanIC-520 interface cards
The WANic 5xx's use an incompatible chipset and the driver will not work with them. I thnk your supplier is feeding you a line of bullshit. SBS Communications has posted no plans whatsover to discontinue or change the WANic line. They are fully aware that the 405's have open source drivers and are furthermore used in embedded systems too. The WANic 5xx series of cards sell for more money and so naturally your supplier is most interested in maximizing his margin and would prefer to push you into a more expensive card. With the increase in CPU power all of the go-fast hardware on the higher-level cards is less important. Consider that the Hitachi controller chip used on the WANic 405 is the SAME chip that Cisco uses in it's 25xx series of routers, and the Cisco 2501 is the most used router in the world and has the most installed units. SBS Communications is STILL selling the RISCom series of cards which is the predecessor to the WANic, uses the same controller, these are ISA cards that have a design that's over 10 years old. You tell your supplier that since the 405 is being "phased out" that he should sell you a bunch of them at closeout prices. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com >-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED]]On Behalf Of MurrayTaylor >Sent: Thursday, October 11, 2001 4:49 PM >To: [EMAIL PROTECTED]; [EMAIL PROTECTED] >Subject: Imagestream WanIC-520 interface cards > > >As the WanIC-405 is being phased out (according to my supplier >down under here in OZ), has any development / testing been done on the >apparent replacement, the WanIC-521 (522, 524 ... ) range > >I am especially interested in its compatibility with its predecessor >which I am using very successfully for frame relay under Netgraph. > >I'm trying to get compatability info from the supplier here, >but we are a long way down the food chain ;-( > >Tia > >Murray Taylor >Bytecraft Systems Pty Ltd >[EMAIL PROTECTED] > > > > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-questions" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Imagestream WanIC-520 interface cards
outers out of PC's. They have Linux drivers for the more expensive WANic cards so of course they have a vested interest in seeing the WANic 405 go away, because SBS allows any reseller to register with them to sell the WANic cards and when someone like Joe Blow Computers fills out the paperwork and start selling WANic405 cards on FreeBSD boxes as routers, Imagestream sees it cutting into their Linux/expensive WANic router business. The rumor that the WANic405 is going away is totally unsubstantiated by the facts and if it ever did then Linux would see immediate benefit because the FreeBSD OS would end up losing one more of the few cards that it has that supports a T1. So consider who it is that has a vested interest in spreading this kind of FUD. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Imagestream WanIC-520 interface cards
of corporate WAN's that are frame-relay based. The T1 and the E1 are not going to go away any time soon, and until they do there will be plenty of demand for devices that interface to them. The T1 and the E1 aren't going to go any faster and so there's no need to change the capacity of the serial interface controllers that interface to them. In short, synchronous serial connectors of this type are in a market that is pretty static. All hardware devices eventually will stop being manufactured including every CPU that FreeBSD runs on currently. Are we to stop using FreeBSD because someday the Pentium is going to be obsolete? Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: RE: Imagestream WanIC-520 interface cards
>-Original Message- >From: Matt Dillon [mailto:[EMAIL PROTECTED]] >Sent: Friday, October 12, 2001 10:40 PM >To: Ted Mittelstaedt >Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] >Subject: Re: RE: Imagestream WanIC-520 interface cards > > >The Cisco 2600 series is great for T1's. A 2620 with a T1 card (it >can take up to two) and you are done. The 2501's are ancient, don't >even bother any more. You can find 2620's on EBay in the $700-$1500 >range, many of which appear (in my quick look) to include a T1 card. > >As much as I like to support running things on BSD, I stopped trying to >run T1's from general purpose unix boxes 4 years ago. When BEST Internet >first started we ran the (old) Riscom cards from a BSDI box w/ >an external >csu/dsu, and they were great for that, but these days the overall >cost of ownership is much, much lower with a used cisco and a WAN >card with an integrated csu/dsu in it. It's file and forget... once >you set the thing up you don't have to touch it ever again. > >One advantage of the dot-com crash is that EBay and other sites are >saturated with high quality, barely used hardware. > This is very true for leaf-node routers as used at customer sites and I've said the same thing myself on freebsd-questions before. However, there's still a market for those "Internet access toasters" that are basically PC's plus T1 interfaces, for the "set and forget" crowd. The cost issue, however, not true for BGP routers. Despite the dot-bombs the 7204/6 and the 3640 (both minimum cost of entry for BGP4 on Cisco) are both still very expensive even on Ebay. It's still cheaper to hook a fast Celery or something like that to an ISP feed. Furthermore, I feel compelled to point out that the Internet is still getting bigger and bigger and bigger. At some point in time even with Cisco's packing algorithims, the BGP route table plus Cisco IOS will exceed 128MB of ram. (both the 7206 and 3640 are limited to this as a maximum) Long before that the CPU's used in those Cisco devices will be swamped. And, I hear your answer to that, but screw that, why should I have to settle for a half-assed BGP feed with 3/4's of the routes chopped out of it from my providers? I've run BGP4 into both 7206's with NPE200's and Pentium 500Mhz systems with WANic cards, and the PC will converge BGP views faster than the Cisco, and tolerate route flaps far better, while under routing load. Cisco has a lot of exposure here, and their answer to the need for increased routing power on the Internet has been routers costing in the $100,000 range. Now, maybe BEST Internet is now wealthy enough that you can blow that kind of money on Cisco gear without thinking about it, but a lot of smaller ISP's are not. If you look at what happened last weekend on Sunday, and the number of people that screamed about it, it's quite obvious that there are a huge number of gated and zebra boxes out there handling global routing. Take off those Cisco blinders, boy! ;-) Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: RE: RE: Imagestream WanIC-520 interface cards
>-Original Message- >From: Matt Dillon [mailto:[EMAIL PROTECTED]] >Sent: Saturday, October 13, 2001 6:33 PM >To: Ted Mittelstaedt >Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] >Subject: Re: RE: RE: Imagestream WanIC-520 interface cards > > >:on the Internet has been routers costing in the $100,000 range. Now, maybe >:BEST Internet is now wealthy enough that you can blow that kind of money on >:Cisco gear without thinking about it, but a lot of smaller ISP's are not. >: >:If you look at what happened last weekend on Sunday, and the number >of people >:that screamed about it, it's quite obvious that there are a huge number of >:gated and zebra boxes out there handling global routing. Take off those >:Cisco blinders, boy! ;-) >: >:Ted Mittelstaedt [EMAIL PROTECTED] >:Author of: The FreeBSD Corporate Networker's Guide > >Hmm. Well, as a person who ran gated at BEST, has hacked on gated on >same, had to deal with BSDI and FreeBSD route table bugs, tracked down >OSPF bugs for a friend running gated, and otherwise spent hundreds of >hours (at least!) keeping boxes running gated operational... well, I'll >take the Cisco any day thank you very much! :-) As I've said I run both - and each has it's strengths and weaknesses. I've not had the problems you apparently did with gated. However, I'll admit that you probably ran it a lot earlier than I did, on a lot slower hardware than I, thus I'm benefiting from all the bug-squishing that you have done on gated and FreeBSD. I have found that CPU speed makes a huge difference. I have had lots of problems trying to run BGP and gated on anything slower than a 400Mhz system. > >If you are a small ISP and you have enough money to pay for two T1's, >you have enough money to buy a used router that can do BGP for you. >IMHO. > Probably for you or I because we both know Cisco and are familiar with the ins and outs of their stuff and know where to get used gear. But, if you do it the Cisco Way, where you go buy a new 7206VXR with a service contract - no way. In our market, and I swear this is true, we have CLEC's that are selling fractional T1's (split voice/data with add-drop DSU's) and they are charging less than $50 a month for 768k or greater feeds. It's competitive with DSL. The customer pays for the voice lines which are maybe $1-$5 cheaper per trunk than what the ILEC would charge, then gets in essense a free Internet feed. Now, obviously the CLEC is planning on the company growing and adding trunks onto that T1, because they are making their money off the voice circuits and the call termination payments that the RBOC's are paying them. So they give away the Internet service as an enticement. And, obviously it's crap - I've used a few of them and your lucky to get 128kbits/sec on a "768k point to point to the Internet" And these same CLECS are also still not profitable (according to the local business journal) and haven't been for years. But, the upshot is that it's tremendously depressed prices for point-to-point or Frame service in our market. It's a very hard sell to sell one of these circuits now and we usually have to walk the prospect over to another of our customers to demonstrate what a true 768Kbps is supposed to be like. Now I don't know if we are just in a over-wired market, although PDX has more Internet usage per capita than any other city in the country. But, I've heard about markets (like Phoenix) where there's only national providers and a single regional provider, all the other regional providers have gone out of business. In those markets, yes, the regional provider that has enough money to pay for 2 T1's probably can charge enough to afford a used router that will do BGP. But, in markets like ours, the margins are far, far thinner. You cut where it makes sense, and gated on FreeBSD makes sense for one of our border routers, (probably also for a second, I just haven't gotten around to replacing it) Given a choice between spending on a lot of networking hardware so we can say we are 100% Cisco, and spending the money on more bandwidth, the choice is obvious. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: FYI
There are other vendors that sell the WanIC than Imagestream. I realize that you see yourself as the only supplier but this isn't true. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com >-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED]]On Behalf Of Doug Hass >Sent: Friday, October 12, 2001 3:11 PM >To: [EMAIL PROTECTED]; Ted Mittelstaedt; MurrayTaylor; >[EMAIL PROTECTED]; [EMAIL PROTECTED] >Cc: Alfred Shippen >Subject: Re: FYI > > >I'm providing this to the people whose addresses appear in the original >messages. My apologies if this gets cross-posted or sent multiple times >to the same place. As I mention below, the WANic 400 series cards and all >of the RISCom/N2 series cards are now End Of Life, and only available in >special quantity builds. > >If anyone reading this message needs further information, please contact >me directly and I can go into further depth about the EOL cards mentioned >below and their replacements in the SBS line. > >Regards, > >Doug > >- > >Doug Hass >ImageStream Internet Solutions >[EMAIL PROTECTED] >http://www.imagestream.com >Office: 1-219-935-8484 >Fax: 1-219-935-8488 > > >On Fri, 12 Oct 2001, Doug Hass wrote: > >> The WANic 400 series is definitely EOL. The cards are available in >> quantities of 100+ only by special order. The RISCom/N2 series cards are >> also EOL. >> >> This is a recent decision--it went into effect as of September 21st. >> Closeout quantities have already been sold to other companies, so the >> cards are only available by special order. >> >> The WANic 521/522 have replaced these cards, and should be used instead. >> There are no drivers for FreeBSD, however. >> >> Doug >> >> >> >> On Sat, 13 Oct 2001, Alfred Shippen wrote: >> >> > This guy is local to you and is under the misapprehension that >the Risc/400 >> > series is not a discontinued item. I dont know if you want to >follow them up >> > or not. My customer (Bytecraft) is fine by this and has passed on the >> > comments to me. >> > >> > Cheers >> > >> > >> > >> > > >> > > - Original Message - >> > > From: "Ted Mittelstaedt" <[EMAIL PROTECTED]> >> > > To: "MurrayTaylor" <[EMAIL PROTECTED]>; >> > > <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> >> > > Sent: Friday, October 12, 2001 3:07 PM >> > > Subject: RE: Imagestream WanIC-520 interface cards >> > > >> > > >> > > > The WANic 5xx's use an incompatible chipset and the driver will not >> > > > work with them. >> > > > >> > > > I thnk your supplier is feeding you a line of bullshit. SBS >> > > Communications >> > > > has posted no plans whatsover to discontinue or change the >WANic line. >> > > > They are fully aware that the 405's have open source drivers and are >> > > > furthermore used in embedded systems too. >> > > > >> > > > The WANic 5xx series of cards sell for more money and so >naturally your >> > > > supplier is most interested in maximizing his margin and >would prefer to >> > > > push you into a more expensive card. >> > > > >> > > > With the increase in CPU power all of the go-fast hardware on the >> > > higher-level >> > > > cards is less important. >> > > > >> > > > Consider that the Hitachi controller chip used on the WANic >405 is the >> > > > SAME chip that Cisco uses in it's 25xx series of routers, >and the Cisco >> > > > 2501 is the most used router in the world and has the most installed >> > > > units. >> > > > >> > > > SBS Communications is STILL selling the RISCom series of >cards which is >> > > > the predecessor to the WANic, uses the same controller, these are ISA >> > > cards >> > > > that have a design that's over 10 years old. >> > > > >> > > > You tell your supplier that since the 405 is being "phased >out" that he >> > > > should sell you a bunch of them at closeout prices. >> > > > >> > > > Ted Mittelstaedt >> > > [EMAIL PROTECTED]
RE: WanIC 405 _IS_ End of Life -- what are the (netgraph) based alternatives??
>-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED]]On Behalf Of MurrayTaylor >Sent: Sunday, October 14, 2001 5:05 PM >To: Ted Mittelstaedt >Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] >Subject: WanIC 405 _IS_ End of Life -- what are the (netgraph) based >alternatives?? > > >Hi Ted et al, > >A- thanks for the hint re Ebay. I actually will lookup the >card and manufacturer for more detail for when we are in the >buying mode again. > >B- You should have received the End Of Life mail forwarded from >Alfred Shippen ( our supplier down under ) by now so >you can see where the WanIC 405 stands > SBS, not Imagestream, is the manufacturer of the WANic405. What happened is a long time ago SBS signed some kind of deal with Imagestream to where Imagestream took over driver authorship. Previous to that, SBS (actually SDL Communication) supplied drivers for the cards directly. SDL/SBS transferred all of their code over to Imagestream as a part of that deal, and since that time Imagestream has been unwilling to work with the FreeBSD community to write drivers. (I know because R Grimes attempted a number of times to get source to the drivers and Imagestream sent him in a runaround) Before SDL signed the deal with Imagestream, they were free with the programming details for the WANic cards. In fact I have a bunch of documentation I got with an older RIScom card that I have (in service, actually) that explains how to program it, along with a BSD driver skeleton. Since the WANic 400 series used the same programming interface it was a simple matter to mod the driver for the RISCom card to work with the WANic. Undoubtedly the sr driver that John Hay is responsible for originated from this documentation. Since that deal, SDL (now SBS) will not supply driver programming details undoubtedly because Imagestream has them gagged. And Imagestream will not supply programming details nor driver source for their Linux drivers for the higher-order WANic cards, nor will they port it over to FreeBSD. Imagestream was probably the largest reseller of the WANic 400 series cards. So when they stopped selling them, I would guess that most distributors were buying them from Imagestream, and thus were affected. But I know that Rod actually has filled out the paperwork with SBS to be a reseller for them and has (in the past) sold the cards through his company. (without going through the Imagestream loop) I don't know what he's doing nowadays. I also recall that when SDL was still supplying drivers pre-Imagestream, that there were a number of other resellers listed as selling these. A year ago, at my request, the sister VAR of the ISP that I worked for contacted SBS and got the paperwork from them to resell the WANic cards. They ended up never completing it because we found that when people queried SBS for driver support they were referring them to Imagestream, and since everyone asks this question, it was effectively funneling all sales prospects to Imagestream. Also, Imagestream wasn't marking up the WANic 400 cards that much so we decided that it wasn't worth the trouble to bother with it. Perhaps we should revisit this now that Imagestream has made their announcement. >As I am quite happy with Netgraph as it is supporting >multiple frame relay links as well as our MPD based VPN for our >road worriers ( sorry warriors ), I now expand my original question > > >What are the potential netgraph supported replacement cards now and >under consideration, for the WanIC 405 series...?? > I know that Rod Grimes got pissed off enough with this whole WANic400 series/Imagestream driver problem a year ago that he stopped using those cards and switched to something else. He probably builds 5-10 FreeBSD-based T1 routers a year under contract. I don't remember what he told me that he switched to, though. He was using Netgraph with the 405 before he switched. I still use the SBS cards, and I have a small stash of the 405's that I will continue to use as spares. Also, if there's demand for these I think that my associates would probably start selling them. There's also probably still a number of resellers out there that can still sell these directly from SBS you would just need to get their names and give them the right part numbers for their computers. >The new (read more expensive) card is the WanIC 520/521/ series, >but I am willing to look at alternates that provide the interface >to the telco NTU for frame relay. > >(Just as an aside, given the unique nature of the card and the >us - au exchange rate, we are already paying AU$2000 ish prices for card and >interface cable package, so a cheaper alternate is always welcome ;-) > As has been pointed out in this forum, a much cheaper alternative is to use a Cisco or other router, and connect t
RE: FYI
>-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED]]On Behalf Of Doug Hass >Sent: Sunday, October 14, 2001 7:23 PM >To: Jim Bryant >Cc: Ted Mittelstaedt; [EMAIL PROTECTED]; MurrayTaylor; >[EMAIL PROTECTED]; [EMAIL PROTECTED]; Alfred >Shippen >Subject: Re: FYI > > >Also--understand that the replacement for the 400 and 405 is a >multi-interface card (supports all of the wiring specs instead of just 1), >and costs virtually the same (or less as a reseller or in volume) than the >400/405 did. > And if you want to sell these to FreeBSD users then make your Linux driver source (not the SAND stuff) available so that we can mod it into our own driver. Many other companies do this and as a matter of fact, we (meaning FreeBSD) have even found bugs in crummy Linux drivers that have been reported back to Linux and helped those manufacturers better their products. No offense, but once Imagestream stopped selling WANic400's you ceased being an entity of interest to FreeBSD, as you no longer sell any products that run under it. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com >Doug > >On Sun, 14 Oct 2001, Jim Bryant wrote: > >> No offense to you or your sales partners, but the way I see it, >this means that tons of these will be available for a song on eBay >> soon, and will be in the hands of a lot of FreeBSD and Linux >people [not all of which can afford top-of-the-line all of the time]. >> >> Doug Hass wrote: >> >> > Ted, >> > >> > We're SBS' worldwide distributor. Others who resell them buy >them from us >> > or from one of our distributors. In any case, I can ASSURE you without a >> > doubt that the WANic 400 series and the entire RISCom/N2 series >are end of >> > life as of the end of September. >> > >> > If you have questions, feel free to contact me at your convenience. >> > >> > Regards, >> > >> > Doug >> > >> > - >> > >> > Doug Hass >> > ImageStream Internet Solutions >> > [EMAIL PROTECTED] >> > http://www.imagestream.com >> > Office: 1-219-935-8484 >> > Fax: 1-219-935-8488 >> >> >> jim >> -- >> ET has one helluva sense of humor! >> He's always anal-probing right-wing schizos! >> - >> POWER TO THE PEOPLE! >> - >> "Religious fundamentalism is the biggest threat to >> international security that exists today." >> United Nations Secretary General B.B.Ghali >> >> >> _ >> Do You Yahoo!? >> Get your free @yahoo.com address at http://mail.yahoo.com >> > > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-questions" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: WanIC 405 _IS_ End of Life -- what are the (netgraph) based alternatives??
>-Original Message- >From: Soren Kristensen [mailto:[EMAIL PROTECTED]] >Sent: Monday, October 15, 2001 1:17 AM >To: Ted Mittelstaedt >Cc: MurrayTaylor; [EMAIL PROTECTED]; >[EMAIL PROTECTED] >Subject: Re: WanIC 405 _IS_ End of Life -- what are the (netgraph) based >alternatives?? > > >Hi Everybody, > >I've been following the sync serial board discussion a little, and it >seems like that there's no source for inexpensive sync serial boards >with FreeBSD, or boards with documentation to make a driver, or from >companies with a good policy towards open source and/or FreeBSD > >The only one close seems to be the cronyx, they seems to have full >source code, but their boards is not easily available in the US, or >available with T1 interfaces. > >So maybe I should just make one, and sell for cheap, I need them anyway >for my small boxes (see http://www.soekris.com) The most common chip >for the PCI bus, the 4 channel Infinion DSCC4 PEB20534 (used by cronyx >and others...) cost around $60 in small volume, so the basic 2 ch board >would probably go for around $250 qty 1. Boards with more channels or >integrated T1/E1 phys will be a little higher. > >FreeBSd drivers should be relatively easy, t.ex based on the cronyx >drivers, they're even netgraph enabled > >I would then be happy to supply hardware and documentation to somebody >that could do and maintain the drivers. > An interesting proposition. However, you might find it even easier to do a Hitachi HD64570-based board. It should be much easier to modify the sr driver to work with it than to write a new one from scratch. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: WanIC 405 _IS_ End of Life -- what are the (netgraph) based alternatives??
>-Original Message- >From: Poul-Henning Kamp [mailto:[EMAIL PROTECTED]] >Sent: Monday, October 15, 2001 2:05 AM >To: Soren Kristensen >Cc: Ted Mittelstaedt; MurrayTaylor; [EMAIL PROTECTED]; >[EMAIL PROTECTED] >Subject: Re: WanIC 405 _IS_ End of Life -- what are the (netgraph) based >alternatives?? > > >In message <[EMAIL PROTECTED]>, Soren Kristensen writes: > >>So maybe I should just make one, and sell for cheap, I need them anyway >>for my small boxes (see http://www.soekris.com) The most common chip >>for the PCI bus, the 4 channel Infinion DSCC4 PEB20534 (used by cronyx >>and others...) cost around $60 in small volume, so the basic 2 ch board >>would probably go for around $250 qty 1. Boards with more channels or >>integrated T1/E1 phys will be a little higher. > >We already have drivers in the tree for the infinion "MUNICHX" chip, >when used with a FALC frontend. We also have drivers for the MUSYCC >from Conexant. > Ha hmm - Poul, do you how what the reference boards were that these drivers were tested/developed with? Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: WanIC 405 _IS_ End of Life -- what are the (netgraph) based alternatives??
>-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED]]On Behalf Of Poul-Henning >Kamp >Sent: Monday, October 15, 2001 2:53 AM >To: Ted Mittelstaedt >Cc: Soren Kristensen; MurrayTaylor; [EMAIL PROTECTED]; >[EMAIL PROTECTED] >Subject: Re: WanIC 405 _IS_ End of Life -- what are the (netgraph) based >alternatives?? > > >We want something with an integral T1/E1 DSU/CSU, otherwise cost is >still prohibitive. as long as there's a carrier detect and a DTE light I hope. A little button for a hard loop would be good too. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: FYI
>-Original Message- >From: Andrew C. Hornback [mailto:[EMAIL PROTECTED]] >Sent: Monday, October 15, 2001 2:59 PM >To: Doug Hass; Ted Mittelstaedt >Cc: Jim Bryant; MurrayTaylor; [EMAIL PROTECTED]; >[EMAIL PROTECTED]; Alfred Shippen >Subject: RE: FYI > > >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED]]On Behalf Of Doug Hass >> Sent: Monday, October 15, 2001 9:53 AM >> To: Ted Mittelstaedt >> Cc: Jim Bryant; MurrayTaylor; [EMAIL PROTECTED]; >> [EMAIL PROTECTED]; Alfred Shippen >> Subject: RE: FYI >> >> > And if you want to sell these to FreeBSD users then make your >> Linux driver >> > source (not the SAND stuff) available so that we can mod it into our own >> > driver. Many other companies do this and as a matter of fact, >> we (meaning >> > FreeBSD) have even found bugs in crummy Linux drivers that have >> been reported >> > back to Linux and helped those manufacturers better their products. >> >> I'm not going to get dragged into an OS war. Both Linux and FreeBSD >> have their share of "crummy" drivers and features. That discussion is >> honestly beyond the scope of a discussion of ImageStream's SAND >> architecture and the WANic 400 series. > > I don't believe Ted was trying to start an OS war, he's not >that petty of a >person. been there, done that. :-) No, it's not an OS war, just trying to illustrate why making source available is a Good Thing. His point, and I hope that I'm not reading this incorrectly, is >that FreeBSD not only has fixed problems with drivers released by hardware >vendors, but also with drivers given over to "us" by the Linux group, as >that was all that we had to work with when the hardware vendors have refused >to provide any help whatsoever. > correct. >[snip] > >> > No offense, but once Imagestream stopped selling WANic400's you >> > ceased being an entity of interest to FreeBSD, as you no longer sell >> > any products that run under it. >> >> I'll reiterate what I've said to you privately: ImageStream DID NOT make >> the decision to discontinue the 400 series or the RISCom/N2 series. This >> decision rested solely with SBS. >> >> However, FreeBSD users are NOT without options: >> >> 1) FreeBSD users can still get the WANic 400 and RISCom cards from the >> second hand market, as another person mentioned. > > What is wrong with THIS picture? You're telling people to >purchase used >hardware, instead of purchasing components from your company? *shakes his >head* > I'll point out that the "1000 cards closed out" is not "used" hardware, it's brand new stuff that's never been opened. This is quite common in the hardware industry. The difficulty is finding out who that highest bidder was and if they are going to use those 1000 cards for themselves or are going to sell them off in dribs and drabs over the next 10 years. >> 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. I'll go one step further: If anyone >> contacts me about the WANic 400 series, mentions that they are for >> FreeBSD, I promise to give an extra 15% discount over and above our normal >> volume discounts just to illustrate my desire to support the FreeBSD >> community. > > Perhaps a better idea, if I may be so bold, would be to offer >samples of >the newer cards (520 series, I believe they are) to FreeBSD developers >interested in producing drivers, software and utilities for these cards. >After all, you are saying that the 400 is EOL. Wouldn't the idea of >engineering samples be more beneficial to all involved? > Just about every hardware vendor is happy to provide samples to developers, anyone working on this would get plenty of support. >> 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. > > This sounds quite argumentative to me. Simply because >everyone else is >buying a router, there's a refusal to support FreeBSD, since people with >"true routers" would have no need for using FreeBSD as a router engine. > No company is going to support a product that has no market, and it's reasonable
RE: FYI
>-Original Message- >From: Doug Hass [mailto:[EMAIL PROTECTED]] >Sent: Monday, October 15, 2001 6:53 AM >To: Ted Mittelstaedt >Cc: Jim Bryant; MurrayTaylor; [EMAIL PROTECTED]; >[EMAIL PROTECTED]; Alfred Shippen >Subject: RE: FYI > Hi Doug, I'm going to address myself to these points openly as there's some points here which we all need to be familiar with. > >We are bound by third party agreements and are not allowed to release any >more free code (legally) than we already have. If we were not restricted >by SBS, Trillium, and Rockwell (among others), we would release all of the >code under GPL or lGPL. These agreements do NOT prevent us from working >with developers to support other platforms, though. It only prevents the >free release of portions of the code. > You said in a mail to Leo, the following: "Unfortunately, the API to the cards (the driver development kit, hardware programming specifications or whatever you want to call them) are licensed from several third parties and we are bound by agreement not to make them public." I'm going to assume that the programming specs you refer to here are what is being licensed from SBS, Trillium, and Rockwell, because either Rockwell or Trillium is the actual manufacturer of the sync chip. I'll assume that SBS is just making the support chips on the board and the interface chips to the PCI bus. Now, let me discuss for a moment how the current Imagestream WAN drivers operate. (based on my reading of the public code, which of course may be incorrect) Please feel free to interject where you feel I'm full of crap. :-) 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. Imagestream has no problem releasing SAND for public consumption basically because all that PPP/HDLC/Frame and other datalink code is already available, PPP code has been available for time out of mind from many places, (including BSD) long before Imagestream ever wrote SAND, and Cisco HDLC was reverse-engineered some time ago (Besides that, Cisco gave up trying to hide their HDLC interface once Wellfleet/Bay Networks died) Obviously, Imagestream had to do some work, but I'd say a lot of it was in the area of supporting these binary snap in modules. 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. 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. There's other modularized driver development models in which EVERYTHING is publically available including the modules. >That being said, we're always interested in supporting a wide variety of >platforms. Without the SAND architecture, though, there really is little >hope of having FreeBSD support for the WANic 520 series cards (or other >cards, for that matter). This is correct and incorrect. It's correct because what Imagestream wants to have to be able to easily graft in FreeBSD to their supported UNIX os's is SAND - if done right then the actual driver module itself would have trivial changes whether used on FreeBSD or Linux, so you don't have to do much other than keep SAND maintained in FreeBSD. 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) Of course, this object module will have to be recompiled for every new version of FreeBSD, because it has to either be mod-loaded into the kernel or statically compiled into it. It's a rather icky proposition for a company like Imagestream to contemplate from a support
RE: FYI
>-Original Message- >From: Doug Hass [mailto:[EMAIL PROTECTED]] >Sent: Monday, October 15, 2001 8:04 AM >To: Leo Bicknell >Cc: Ted Mittelstaedt; Jim Bryant; MurrayTaylor; >[EMAIL PROTECTED]; [EMAIL PROTECTED]; Alfred >Shippen >Subject: Re: FYI > > >> Would your agreements allow you to provide resources to a small >> number of developers (under NDA and all that of course) to produce >> drivers that you would then release in binary form (eg a kernel >> module) under a free license? > >It sure would. > >> If you cannot release the source code to your drivers, can you >> release hardware programming specifications (again, perhaps under >> NDA) that allowed someone to develop an independant free licensed >> driver? > >Unfortunately, the API to the cards (the driver development kit, hardware >programming specifications or whatever you want to call them) are licensed >from several third parties and we are bound by agreement not to make them >public. The 400 series cards (and, for that matter, the RISCom/N2 series >cards) did not require an API, which is how BSDI and FreeBSD drivers came >about in the first place. > >As I mentioned above, we CAN license the driver code and the DDK for >development. This means that you could produce FreeBSD drivers which we >could then distribute in a binary form under a free end-user license. > Frankly this is the only way I can see that FreeBSD drivers for the 5xx series would ever come about. Porting SAND over, while having advantages of long term support, is just overkill for this, besides which it's unlikely you will get a FreeBSD developer to work on GPL code. This would end up putting a WANic 5xx driver into the same status as the drivers for the Emerging Technologies, or Sangoma sync cards, which both come with binary-only FreeBSD drivers. It would actually have a leg up over those drivers because it would have Netgraph hooks and I believe that the Sangoma drivers don't (but I've never worked with the Sangoma cards so I don't know for certain) If the register interface to the 5xx cards wasn't tremendously different than the 4xx cards then the sr driver would be a good skeleton to start with. While the offer of the DDK is nice, my guess is most of the code in it is for making SAND modules. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: FYI
>-Original Message- >From: Doug Hass [mailto:[EMAIL PROTECTED]] >Sent: Monday, October 15, 2001 8:56 AM >To: Leo Bicknell >Cc: Ted Mittelstaedt; Jim Bryant; MurrayTaylor; >[EMAIL PROTECTED]; [EMAIL PROTECTED] >Subject: Re: FYI > > >In a private e-mail, Leo writes: > >> You offered a discount on these boards on the list. If you think there >> is a real opportunity to sell these to the *BSD crowd, I recomend you >> take that 15% (or some part of it) and offer to partially fund a driver >> developer. There are many freelance programmers working on the project >> who for $1000-$5000 (depending on complexity) could make your driver a >> reality. A good developer could probably also make them work under >> OpenBSD and NetBSD in one fell swoop. > >I'd be happy to pledge the 15% to a driver developer. That's a >great idea! It will accomplish two objectives: > >1) There will be at least 100 WANic 400 series cards available for >purchase to support existing installations (assuming someone out there >places the order). > >2) ImageStream will pledge 15% of the purchase price of any lots of these >400 series cards toward porting of our SAND architecture to FreeBSD. >That's a MINIMUM of $8,100 that ImageStream is willing to pay a developer >or group of developers to port the drivers for the rest of the cards. > >Ted--you've indicated that there is a significant market for the 400 >series cards in the community. There is depending on the price. I'll freely admit however that I have not priced the competitive serial sync cards that are currently supported under FreeBSD, so I don't know how the WANic 400 or 500 stacks up against them. For all I know right now there's someone just bringing a T1 interface card to the market with integrated CSU that sells for $30 per card which would make this entire discussion moot. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: FYI
>-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED]]On Behalf Of Doug Hass >Sent: Tuesday, October 16, 2001 7:28 AM >To: Ted Mittelstaedt >Cc: Leo Bicknell; Jim Bryant; MurrayTaylor; [EMAIL PROTECTED]; >[EMAIL PROTECTED] >Subject: RE: FYI > > >> There is depending on the price. I'll freely admit however that I have not >> priced the competitive serial sync cards that are currently supported >> under FreeBSD, so I don't know how the WANic 400 or 500 stacks up against >> them. For all I know right now there's someone just bringing a T1 >interface >> card to the market with integrated CSU that sells for $30 per card which >> would make this entire discussion moot. > >$30 per card? Do tell, do tell. I'll buy 10,000 of them right now, and >pay you $60 a card to buy them for me. > >What company would be foolish enough to offer a $30 T1 card? I have my >credit card ready! > :-) That was an example only, exaggerated to illustrate a point. But, it's a point with some validity too - if T1 circuits were as common as DSL circuits, and DSL circuits were like T1's in volume, you would see ADSL chipsets at the sync port chipset pricing levels, and sync port chipsets at the $30 range. As you pointed out this is a volume thing. Before anyone would dump $50K into a special order of WANic 400 cards, you would need to do a comparison of what's currently available in the market. As someone else pointed out in this forum, the Hitachi chipset is an older design. I'm sure that it's probably possible today to design a sync controller chip that sells for a lot less than the Hitachi part, perhaps even under the $30 level. Certainly, async chips sell at that level in volume. It's too bad that IBM didn't decide to put a sync serial port on the original XT. :-) Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: FYI
>-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED]]On Behalf Of Julian Elischer >Sent: Tuesday, October 16, 2001 5:29 PM >To: Doug Hass >Cc: Ted Mittelstaedt; Jim Bryant; MurrayTaylor; >[EMAIL PROTECTED]; [EMAIL PROTECTED]; Alfred >Shippen >Subject: RE: FYI > > > > >On Tue, 16 Oct 2001, Doug Hass wrote: > >> > 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. >> > >If there's a published interface, we could make a netgraph/SAND interface >module > Well, you might want to take a shortcut and leave the SAND code out of this and just make that interface one that the driver modules that would normally snap into SAND use. The modules would think that Netgraph is SAND? The goal would be to be able to make use of all the SAND modules that Imagestream has. Then all Imagestream's programmers would need to do is add in defines to the module code for FreeBSD and build the modules. While it's not a _port_ of SAND per-se, it's an emulation of it. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: FYI
>-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED]]On Behalf Of Doug Hass >Sent: Tuesday, October 16, 2001 9:54 AM >To: Ted Mittelstaedt >Cc: Leo Bicknell; Jim Bryant; MurrayTaylor; [EMAIL PROTECTED]; >[EMAIL PROTECTED] >Subject: RE: FYI > > >Let's dispense with all the talk about $75 T1 cards that don't exist (and >won't for some time), whose licensing scheme is better, what driver >architecture was developed for what reason and let's get back to the >original issues: > >1) Availability of the 400 series cards. > >If the FreeBSD market has the 400 series cards in such demand, then >someone should be calling me with an order. I'll cut 20% off list for you >if you tell me its for FreeBSD, and I'll still pledge 15% of your purchase >price on top of that toward driver development. I'll give up my volume >margin as a clear indication of my willingness to work with the community. > Well, Murray started all this by asking for ONE WANic 400. ;-) FreeBSD has an eclectic mix of device drivers - some are personal efforts, some are contributed by corporations, some are ports from other OS's and some are a mix of all of the above. The point is that incentives can take forms other than just money. Getting contributed code is a very powerful incentive, and there's a lot of code in the driver modules for the WANic 5xx, 6xx 8xx and the Aries and Maxim cards that Imagestream has driver code for. Is there any way to get some of this - NOT under GPL and NOT under NDA? There's at least one person during this thread who was looking for a DS-3 card like a WANic 8xx You _did_ mention that some of the card modules in SAND are not under NDA? We might be easier getting 10 buyers for DS3 cards than 100 buyers for WANic 4xx cards, if you get my drift. >The drivers BSDI developed and gave to the community for the 400 series >are seriously out of date, by the way. >Last I knew, they still referred >to the cards as the "n2pci" and used some outdated code that has since >been much improved. I'd be interested in working with a developer or >developers to get some updated drivers out there for FreeBSD. Doug, as a FYI, I believe that I can fill in a bit on the state of the sr driver. They don't actually refer to the cards as the n2pci (now, at least) They have had work done to them already by John Hay and Julian. This brings >me to... > >2) Driver development for FreeBSD > >We'll pledge 15% of the purchase of the aforementioned 400 series cards >toward supporting a developer or developers to bring drivers to the >FreeBSD market. The 400 series drivers need to be updated. Yes and no - there is one bug in there that needs killing still but otherwise the driver for the 400 is OK. Let me explain the history as I am aware of it. As you stated, BSDI wrote a driver for the RISCom/N2 card and contributed this back to SDL. I believe that this version made it's way to John Hay and formed the base of the FreeBSD sr driver. At some point, this driver was enhanced by either BSDI or SDL to add support for the later RISCom cards that had an integrated T1 CSU. This support does NOT appear in the FreeBSD driver. It's not possible to use port1 (the one with the CSU port) in a FreeBSD system at this time. It may be that John Hay chopped out this support but more likely he was working with an older version of the driver. I have the source for the later N2 driver that has the integrated CSU. It would be nice if someone would put the CSU support into the FreeBSD driver. I looked at doing it myself but there's now big differences between this BSDI/SDL driver and the one in FreeBSD, too much for me to be able to do it. I would gladly loan a disk with this source plus a later model RISComN2 card with the integrated CSU port to anyone who would do it. I'm sure that someone like Julian or John could do it. At any rate, the FreeBSD fork of this driver was later modified to support the PCI version of the RISCom, the WANic 400/405 cards. Since the WANic 405 series has no integrated CSU, the sr driver works with both ports on it. The sr driver has gone through some debugging by John Hay, and Rodney Grimes. I've worked with Rod on this some, and he has discovered 2 bugs that appear on the WANic405 driver. I've verified that both of these bugs exist. The first bug deals with the interrupt handling of the transmit register. It appears on all RISCom and WANic card variants. Rod has written a patch for this and the patch works. Without the patch, the cards lose packets. John has not gotten a copy of this patch nor integrated it into the current version of the sr driver, unfortunately. The patch is for 1.34.2.2 of the driver that comes in FreeBSD 4.3 and unfortunately Rod got it completed after Joh
RE: RE: RE: Imagestream WanIC-520 interface cards
>-Original Message- >From: void [mailto:[EMAIL PROTECTED]] >Sent: Monday, October 15, 2001 9:22 AM >To: Ted Mittelstaedt >Cc: Matt Dillon; [EMAIL PROTECTED]; [EMAIL PROTECTED] >Subject: Re: RE: RE: Imagestream WanIC-520 interface cards > > >On Sat, Oct 13, 2001 at 10:09:44PM -0700, Ted Mittelstaedt wrote: >> >> In our market, and I swear this is true, we have CLEC's that are selling >> fractional T1's (split voice/data with add-drop DSU's) and they >are charging >> less than $50 a month for 768k or greater feeds. It's competitive >with DSL. >> The customer pays for the voice lines which are maybe $1-$5 >cheaper per trunk >> than what the ILEC would charge, then gets in essense a free Internet feed. >> Now, obviously the CLEC is planning on the company growing and >adding trunks >> onto that T1, because they are making their money off the voice >circuits and >> the call termination payments that the RBOC's are paying them. > >I thought the RBOCs got the call termination payment scheme repealed >when it didn't work out in their favor like they thought it would. >But I can't find a reference, at least I haven't yet. > We have been told by our rep at Time Warner Communications that those payments are still continuing. TW (at least in PDX) does not have enough voice sales to be able to get on that pig trough and is equally unhappy as we are that the RBOC's are propping up what are in effect bankrupt CLECs. I used to have sympathy for the CLECs and their beef that the ILEC's are screwing everyone by not allowing competition. But not any more - in our market the CLEC's charge about 95% of what the ILEC charges for voice services, so the customers gain nothing on the voice side of the house. Instead, the way that the CLEC's get customers is by giving away Internet service for free. In short, the call termination payments fund the Internet service, instead of decreasing the cost of the voice service. Basically, the CLEC's have figured out how to use a poor government regulation that needs changing to put their competition out of business. It's no different than what Microsoft does when they use operating system revenue to fund a variety of unprofitable and destructive ventures into software applications like web browsers, web servers, ecommerce apps, etc. The only saving grace is that most of the CLECS are so ignorant when it comes to networking that their Internet service is so awful that at least the good customers are staying away from them for now. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com >-- > Ben > >"An art scene of delight > I created this to be ..." -- Sun Ra > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Imagestream WanIC-520 interface cards
>-Original Message- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On >Behalf Of Louis A. Mamakos >Sent: Wednesday, October 17, 2001 6:43 AM >To: Ted Mittelstaedt >Cc: void; Matt Dillon; [EMAIL PROTECTED]; [EMAIL PROTECTED] >Subject: Re: Imagestream WanIC-520 interface cards > > > >> >> We have been told by our rep at Time Warner Communications that >those payments >> are still continuing. TW (at least in PDX) does not have enough >voice sales >> to be able to get on that pig trough and is equally unhappy as we >are that the >> RBOC's are propping up what are in effect bankrupt CLECs. >> >> I used to have sympathy for the CLECs and their beef that the ILEC's are >> screwing everyone by not allowing competition. But not any more - in our >> market the CLEC's charge about 95% of what the ILEC charges for voice >> services, so the customers gain nothing on the voice side of the house. >> Instead, the way that the CLEC's get customers is by giving away Internet >> service for free. In short, the call termination payments fund the >> Internet service, instead of decreasing the cost of the voice service. >> >> Basically, the CLEC's have figured out how to use a poor government >> regulation that needs changing to put their competition out of business. >> It's no different than what Microsoft does when they use operating system >> revenue to fund a variety of unprofitable and destructive ventures into >> software applications like web browsers, web servers, ecommerce apps, etc. >> >> The only saving grace is that most of the CLECS are so ignorant when it >> comes to networking that their Internet service is so awful that at least >> the good customers are staying away from them for now. > >You have much of this backwards. > >This whole notion of "reciprocal compensation" for call termination was >originally put into the telecom tariffs by the RBOCs to prevent competation >in the local space. They figured that the call volume would be asymetrical, >with the CLEC customer calling "the rest of the world" connected to the >RBOCs. Thus, they created an unlevel playing field and changed the rules >of the game. This "poor goverment regulation" is there solely because >the RBOCs worked really hard to ensure it would be put there. > >Surprise, surprise, a bunch of folks came along and decided that the >new game was one they could play, and used it to their advantage. D'oh! >(And this was sweet, because these same telecom tariffs would be used >by the RBOCs on a regular basis to whack their customers/competitors, >with the excuse, "Our hands are tied!" > I am perfectly aware of this. The RBOCs deserved to have those "fines" levied against them for a number of years, to punish them for attempting to block the CLECs. However, it's been long enough for this, and in fact the money from the RBOCs is no longer being used to increase the CLEC's reach or service area (ie: infrastructure) and being used by the CLECS to bash each other, instead of bashing the RBOCS. The situation is equivalent to Foreign Aid that the US pays to a country such as Japan. (which we still do to the tune of millions and millions of dollars a year) Japan has long since ceased being a poor relation that needs to be bailed out. The reasons for them being paid off by the US have been fulfilled. Yet, the payments continue, and the money is being used to free up other funding that's being spent on political - not necessary - things. >Live by the tariff, die by the tariff. > then there's also the saw about the kid won't never amount to anything if mommy's apron strings aren't ever cut. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: (no subject)
eard down to my knees. I routinely purchase DSU's today on the seconds market for use with brand new T1 installs that have manufacture dates of the late 80's. I have a concern about the ET cards because if I bought an ET card today for use in a router I would expect to be able to use that card for another 20 years, or at least until the PCI slot is no longer available on PC hardware. Buying a card that has binary only drivers ties you to a specific version of the OS - what if something happens to ET? As far as I know about Evergreen Technologies, the source code for the drivers is not being held in Escrow by anyone. Thus if the main developer at ET gets hit by a bus tomorrow, the code dies with him, and the cards will never be able to be used in a future FreeBSD version. I'd feel a lot better about ET cards if there was a public statement on the website that in the event ET ceases to exist as an entity, or decides to stop supporting FreeBSD, that the FreeBSD driver source would be immediately donated to FreeBSD as open source. You might be surprised but at the ISP I work at we currently use a billing system called Billmax that was originally developed on FreeBSD. This system has part of it's code in binary-only. When I selected them as the accounting system to use several years ago, code escrow was a mandatory requirement by us and they happily complied. I'm not opposed to binary-only software on FreeBSD but there's a difference between companies that write software for FreeBSD and use binary-only releases to help preserve competitive advantage, and companies that just simply don't release source, period. It's quite possible to do controlled releases where you implement some new idea in a binary module and keep it binary for a few years, then when you have made your profit on it you open it up, because by then you have the next new idea implemented and are making your money off of that one. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Netgraph
>-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED]]On Behalf Of >[EMAIL PROTECTED] >Sent: Thursday, November 29, 2001 4:44 PM >To: [EMAIL PROTECTED] >Cc: [EMAIL PROTECTED] >Subject: RE: Netgraph > > >"Lego" is a good analogy. The "usefulness" is not the point. Its great for >hackers, and terrible for the general technical population. It depends on >your goal, whether its to build an OS for hackers, or to gain widespread >acceptance for FreeBSD from the general technical public. Complicated, >unintuitive interfaces with a long learning curve are not generally accepted. > >DB > This is a myth, your greately underestimating the "general technical public" The general technical public has displayed a willingness to read instructions and follow directions (much different than the general computing public which is a different animal) If there is anything wrong with netgraph is that there's a lack of examples of setting up common configurations in the handbook, man pages, and other documents. Also, speaking as a writer, section 4 of the manual page on netgraph is extremely hard to digest, within the first paragraph alone they redefine the meaning of the words "graph", "node", "hook", and "edge" I understand it's because of the modularness of the software but this is a man page that needs to be a lot less abbreviated. But none of this matters to the general technical public because what most of those people do is find a FAQ that contains a recipe for what they want to be doing and follow that. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Netgraph
>-Original Message- >From: Julian Elischer [mailto:[EMAIL PROTECTED]] >Sent: Friday, November 30, 2001 1:01 AM >To: Ted Mittelstaedt >Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] >Subject: RE: Netgraph > > > > >On Fri, 30 Nov 2001, Ted Mittelstaedt wrote: > >> >-Original Message- >> >> If there is anything wrong with netgraph is that there's a lack of >examples of >> setting up common configurations in the handbook, man pages, and other >> documents. > >/usr/share/examples/netgraph gives examples of some common >configurations. > Oh dang, I should have checked there. But really, this info needs to be in the ngctl man page. >> Also, speaking as a writer, section 4 of the manual page on netgraph is >> extremely >> hard to digest, within the first paragraph alone they redefine the >meaning of >> the words "graph", "node", "hook", and "edge" I understand it's because of >> the modularness of the software but this is a man page that needs >to be a lot >> less >> abbreviated. > >Suggestions welcome.. :-) > The biggest problem with those man pages is that they tell you exactly what the stuff does but not exactly why you would want to do it. I actually sent in a proposal to BSDcon to give a presentation on building network routers with FreeBSD, with a big D&P show of different systems tied together. Discussion of Netgraph would have been part of this of course and while I was writing that part I could have modified the man pages. But it wasn't picked up and I set it aside. Maybe sometime in the future I'll pick it up again. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
