From: ibuprofin@painkiller.example.tld.invalid   
      
   On Fri, 26 Oct 2012, in the Usenet newsgroup alt.os.linux.mandriva, in article   
   , Adam wrote:   
      
   >Moe Trin wrote:   
      
   >> Adam wrote:   
      
   >> Not many people think to look at the updates issue. Yes, the   
   >> packages included and the versions thereof, but how does the   
   >> distribution respond to bugs and security problems?   
      
   >I can see where if this were my job, a great many factors would go   
   >into choosing a distro. I expect every user would have a complaint   
   >that some feature was better in a distro I'd rejected.   
      
   Thing is, it _is_ your job. You're not getting paid for it, but it's   
   as much your job as choosing the car you drive, the insurer you use   
   to protect it, and the gas that you put in the tank and so on.   
      
   >>> I've stayed with the latest Mandriva-customized kernel which ATM   
   >>> is 2.6.39.4-5.1.   
      
   >> I don't believe 2.6.39 is being maintained by kernel.org.   
      
   >"Notice: This is an official package supported by Mandriva"   
      
   And are they actually keeping it up to date? A _very_ crude scan   
   through the ChangeLog-3* files says there have been a couple of   
   updates related to CVEs. Several are for the PPC and ARM processor   
   kernels, but at least two relate to ext4 error handling and network   
   attacks - they're relatively recent (after July 2012).   
      
   [slow dialup connections]   
      
   >I think I found it. Looks like a small bug in the linmodem software.   
   >When powered up, the modem is set ("AT+MS?") to v.92, but acts as if   
   >it's v.34 or whatever the 33.6k standard is.   
      
   V.34 goes to 28.8, and it's v.34+ to get to 33.6   
      
   >If I set it to v.90 ("AT+MS=V90"), it can connect with v.90 speed   
   >and compression. After one connection using v.90, I can set it to   
   >v.92 and it'll use v.92 speed and compression. (Or I could just   
   >leave it at v.90, which doesn't seem much worse than v.92.)   
      
   Depends on the data you're passing. The real difference between v.90   
   and v.92 is the data compression protocol (v.42bis verses v.44). The   
   latter is a better algorithm, and can result in a 6:1 compression   
   compared to 4:1 for the former. That only is important when you are   
   passing NON-COMPRESSED data (text, and similar) as opposed to   
   compressed data such as jpeg/mpeg/.gz/.bz2/etc. With compressed data   
   the difference is the _possible_ uplink speeds - but you don't seem   
   to be able to negotiate anything faster than 33.6 up, so it doesn't   
   matter.   
      
   >Unfortunately that setting isn't part of its "NVRAM". It looks to me   
   >like the default protocol setting is in the part of the   
   >package/tarball that's distributed as object code (some is .O, some   
   >is .c and .h), and I think tracking that down would be more work than   
   >it's worth.   
      
   Agree   
      
   >I'll look into whether "echo AT+MS=V90 > /dev/modem" will work, or   
   >maybe invoking minicom with a very short script.   
      
   Echoing to the device _should_ do it, but that may require root. What   
   are the "normal" permissions/ownership of the actual device?   
      
   >> What kind of error messages? Do you have all of the assorted -devel   
   >> packages installed?   
      
   >So far, I've only been able to try it under Fedora and Mageia (and   
   >CentOS where it succeeded the first time). At first, both complained   
   >that one system header file (different one for each) wasn't found. I   
   >created empty files with that name in the appropriate kernel source   
   >directory, hoping that would do it. Now both distros give the same   
   >errors:   
      
   On CentOS: rpm -qf `locate $NAME.OF.MISSING.HEADER.FILE.H`   
   On others: rpm -q $NAME.OF.PACKAGE   
    locate $NAME.OF.MISSING.HEADER.FILE.H   
      
   >I don't know much C, but maybe some headers are missing.   
      
   Bingo. You've run into a problem where the various package authors   
   may have installed different file-names in "a" package, or the installs   
   have different degrees of "all" of the -devel packages. I suspect the   
   latter. It could also be missing links (there should be several links   
   in /usr/include/ that are pointing to header _directories_ in the   
   kernel source tree - that tree will vary by kernel version and distro)   
   which is why I suggest the 'locate' (assuming the system has been up   
   long enough to run the updatedb cron job).   
      
   >I could either spend time looking into it, or I could consider how   
   >seldom I'd be using dialup (especially on eris) and that I already   
   >have it working under CentOS and just leave it at that. I think I'll   
   >be replacing Fedora there anyway.   
      
   I'd suggest spending a few minutes, just for the experience.   
      
   >> I had a [USR] 5686-03 for a while, and sold it for some reason. It   
   >> was a fine modem.   
      
   >This one was given away ~2008 at the local Windows UG back when my   
   >parents were curious about Linux, so I had louise-desktop use it for   
   >both WinXP and Ubuntu (through USB-RS232 adapter) instead of the   
   >winmodem.   
      
   Hmmm, was it that long ago? It might have been that the modem was   
   X2, or an early implementation of v.90   
      
   >> Were those speeds here, or at the previous place?   
      
   >All "here", which I believe is about a mile from the H.P. CO, and all   
   >to the same H.P. POP phone number.   
      
   As I said, the 5686 was definitely a fine modem.   
      
   >>> There's another PCI winmodem in there that I might try on eris.   
      
   >> I'd probably keep only one plugged in at a time - both noise/loading   
   >> issues and avoiding exposing them to the same lightning surge at the   
   >> same time.   
      
   >I have to, as eris only has 2 PCI slots (plus two PCIe) and one's   
   >needed for the Wi-Fi card.   
      
   What I was referring to was plugging in the phone cable. With all of   
   my systems that have internal modems, you can't easily see the   
   connector on the back plate (never mind reading which connector goes   
   to the line and which to the phone), so all have a suitable cable   
   plugged in to the right connector, and the cable coiled and secured   
   in a zip-lock freezer bag. I _can_ reach the telephone outlet - it's   
   the backs of the computers that are inaccessible. ;-)   
      
   [netzero-juno.txt]   
      
   >Well, I tried not to bother you with yet another request for comments   
   >on it, but you have some good points. There IS a need for version   
   >1.3.1.   
      
   As long as it's able to continue working with the more modern Linux   
   distributions.   
      
   >> Re: internal PCI modems - my understanding is the the USR 5610C is   
   >> still available, though I haven't seen it locally. It works fine.   
      
   >I haven't seen any in years, which was why I wrote that. I suppose I   
   >should check NewEgg, TigerDirect, Amazon, et al. to see whether they   
   >still have anything.   
      
   Don't forget there are people like me who still have old enough   
   computers that will marginally run a modern Linux distro (I'm using   
   them as servers, so they don't need all the bells/whistles/shinys)   
   that still have an _ISA_ internal modem. Linux doesn't need the   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   
|