Quoting Volker Kuhlmann <[EMAIL PROTECTED]>:  
  
> > In addition to those you mention there are:-   
> > Two sorts from Conexant. hcf and hsf - drivers from Linuxant.   
> > Smart Link. slmodem   
> > Motorola. sm56   
>   
> Thanks!  
  
There are quite a few more I forgot mentioned at:-  
http://start.at/modem   and  
http://linmodems.org/  
 
In the context of the ltmodem, the canonical web page for it is at:- 
http://www.physcip.uni-stuttgart.de/heby/ltmodem/ 
There is a host of useful stuff. 
 
> > Winmodems on   
> > POTS is even worse. It's a miracle it ever works at all.   
>   
> True, dito for adsl. But, losemodems make no difference to hardmodems  
> as far as whistling over telephone copper is concerned. The outside end  
> is the same.  
>   
> > Indeed, but so far as I am aware _all_ Linux distros are a bit lacking  
> in the   
> > QA dept.  
>   
> s/Linux/OSS/  
There are quite a few OSS products/projects which are very very good indeed.  
TeX is the one which comes to mind immediately. There are many many others. 
  
> But your point was to recompile a kernel from scratch just to make sure  
> that the headers match the kernel on your $DISTRO. That sucks and is  
> complete overkill. I'm certain that at least SuSE hasn't had a mismatch  
> in at least 5 years, if ever, and I don't think other reputable distros  
> are any different.  
I read about one $DISTRO which screwed up on one of the 2.6.x kernels.  
Sorry I forget which version or distributor because I felt safe and smug with  
my self-built kernel.  
  
> > I have had a very satisfactory degree of success rebuilding   
> > the kernel and its modules from scratch so that it all links together  
> without   
> > problems.   
>   
> What's the technical reason for a complete recompile if the driver  
> source is designed to compile as long as the kernel headers are in  
> gcc's path?  
There have been too many screw-ups by the distributors for my liking.  
OK it probably overkill, but I like to tune my kernel to the the hardware  
and be certain that I know positively that it's either Linus or I to  
blame if I hsve a screw up. btw, it's much more likely to be me than Linus.  
  
imho, the symptoms Nick discribed are very easiy explained by a header file /  
source code mismatch. A misplaced long int counter overflowing over another 
variable or some such could well explain the problem. The first thing I'd do 
is to install the kernel sources and headers, configure them, and as a start 
rebuild the modem module. 
  
  
> > On a modern machine  
>   
> If only I had one...  
>   
> > May be, but it's really very valuable to be able to recompile driver  
> sources   
> > so that the linking loader can do its thing without screwing up. The  
> modem   
> > driver writers are well aware of that fact.   
>   
> Yes. And that when supplying binary packages, one has to supply one for  
> each X Y and Z. Too much trouble to go into. But, please tell me what  
> that has to do with rpm? Nicks answer was spot on.  
  
That may well be true for you. My personal experience with RPMs is that they  
are an unmitigated PITA. The whole idea of using binary drivers, modules and 
program packages in a Free operating system is, at best, an ugly hack, and I'm 
so glad to find a pretty competently put together Linux distribution which is 
free of the sodding things. Crook dependencies, stupid overdetailed library or 
shared object definitions, etc., etc. I could go on and on, but there is no 
need, RPM-hell is well documented. I have found that RPMs only work for me 
about 50% of the time, and that's on a good day. I just can't be bothered with 
the damn pooh. I've been compiling, assembling, and linking code for about 35 
years & just don't see the point of changing my habits for a bunch of jumped 
up neo-nerds who have produced a fawlty file format. Stuff 'em. End of RANT.  
  
--   
Sincerely etc.   
Christopher Sawtell   
   

Reply via email to