From owner-freebsd-hackers Wed Jan 10 17:22:17 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA18398 for hackers-outgoing; Wed, 10 Jan 1996 17:22:17 -0800 (PST) Received: from etinc.com (et-gw.etinc.com [165.254.13.209]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA18393 for ; Wed, 10 Jan 1996 17:22:14 -0800 (PST) Received: from dialup-110.cdmo.com (dialup-110.cdmo.com [204.141.95.167]) by etinc.com (8.6.12/8.6.9) with SMTP id UAA00519; Wed, 10 Jan 1996 20:20:47 -0500 Date: Wed, 10 Jan 1996 20:20:47 -0500 Message-Id: <199601110120.UAA00519@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Nate Williams From: dennis@etinc.com (dennis) Subject: Re: pppd vs ijppp Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >> >> What i meant is that setup is not nearly as important as passing >> >> packets, which is the bottom line here. The fact that most people feel >> >> that they need 133Mhz pentiums to run a few modems over a 56k link >> >> says something about the overhead in the software they're using, and >> >> the importance of performance. >> > >> >Then what in the heck are you arguing about? You claimed that we should >> >add all of the features in ijppp back into the kernel-mode ppp. If you >> >*do* know what you are talking about, then why do you want to stuff all >> >of the user-level stuff into the kernel, such as built-in dial >> >capabilities, routing, dial-on-demand, etc...? >> >> When ever did i say that? I suggested that the benefits offered by pppij be >> added to pppd so that the kernel level ppp could be used. > >And those benefits offered in ijppp vs. kernel ppp that you want would >be? Having used both, the only features that it can do which I feel >should go in the kernel is 'Predictor-1' compression. All of the others >don't belong in the kernel. What features do you want, because there >must be something else you wouldn't be clamoring for them. you're obviously not qualified to have an opinion on the matter. But weve been through this before. The fact that you think predictor-1 belongs anywhere is much evidence....(BTW....not a bad way to save memory... trash predictor-1!) >> Much of that >> functonality can remain in the pppd user process....but running ppp through >> a tunnel device is preposterous. Theres a separation of functionality, no >> question, but the datacomm belongs in the kernel....period. > >I guess we'd better tell MorningStar that as well. As I understand it, >they *only* sell PPP software/hardware, and they can't fill the number >of orders they have. They are growing so fast they can't keep up. And, >they *only* sell tunnel devices drivers. :) It just happens to be the only supported product on the market. Look at FTP software in the 80s. They had a TERRIBLE TCP/IP product (still do)...but it was the only one around.....helps sales a lot! Plus they're selling to an ignorant market (like you). Also Doesn't mean its better nate. Look at Windows...for example! Since this isnt a technical argument , perhaps it should rest. Cant have an argument with myself, and i havent heard one valid technical point in 4 or 5 messages from you. db ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25