David Miller wrote: > Users say this to strong-hand developers, it's not something you > should ever take very seriously. And even if Linux may simply not be > for them, well that's fine too, and implementing something as obscure > as HDLC PPP one way or the other is not going to change that. Certainly not a big deal for Linux, but more significant for vendors of HDLC hardware :-) David Miller wrote: > I would have been more than happy if syncppp was retained and fixed > properly, instead of being abandoned and duplicated in one fell swoop. I'd be happy with that also. I was responding to the suggestion of merging generic HDLC PPP with the pppd implementation. It's been suggested before, but doing so looks messy. James Chapman wrote: > Paul Fulghum wrote: >> Many customers who choose to use generic HDLC PPP are *dead* >> set against the added complexity and (user space) >> components of using pppd even though it has more features. > > Are there technical reasons or is the complexity just a lack of > familiarity? From what I can tell it was an existing investment in scripts, training, tools, naming conventions, etc. Even when provided with new tools and scripts that do the same thing (as far as I could tell) the response was suprisingly vehement against change. -- Paul --
| Alan Cox | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Jan Engelhardt | intel iommu (Re: -mm merge plans for 2.6.23) |
| Adrian Bunk | Re: LSM conversion to static interface |
| Greg Kroah-Hartman | [PATCH 004/196] Chinese: add translation of SubmittingPatches |
git: | |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Andrew Morton | Re: [BUG] New Kernel Bugs |
| Winkler, Tomas | RE: iwlwifi: fix build bug in "iwlwifi: fix LED stall" |
