by h2-1 on Fri Mar 11, 2011 3:43 pm
blowtorch, first, to be clear in case I wasn't above: if people like, prefer the technical debian way, then that is just fine, in fact, it's ideal, since it's cleanly integrated. The problem arises when that way is treated as if it's actually the only way, when it sadly often totally fails on sid/testing. For example, the only way aptosid manages to get the nvidia-glx package working consistently is by building it themselves when it fails and hosting it on a third party repo they run outside of aptosid.
Just as a quick current example, xorg 1.10 is coming. That xorg is supported ONLY by the new beta nvidia drivers. And those only support the current cards, none of the legacy ones. The second xorg 1.10 hits sid, then testing, all nvidia-glx drivers will immediately fail. And until nvidia releases new drivers for the 5000/400 series cards, those cards will fail without recourse. I assume also that fglrx will fail on xorg 1.10 but I am not certain, it usually fails on major new releases, for up to 3 months. So all the fglrx-driver running systems would also fail.
the debian way for non free drivers is really designed and suited for debian stable, or the frozen pool releases like ubuntu or mint ubuntu. In other words, if you run a frozen pool release and your driver works, it will keep working, because they don't update core components. So it's important to be clear about the difference re driver support on frozen pool or rolling release pools like sid/testing. I tend to agree, unless you want the latest and greatest, for sure use the distro packaged drivers if you run a frozen pool stable release distro, either squeeze or ubuntu based that is. sgfxi is primarily developed for rolling release stuff, or for frozen pool users who want the latest stuff, which often fixes bugs the stable packages might not have fixed. Remember, there is very little desirable about old drivers in general, especially when you use newer hardware.
One of the original reasons I agreed to take on the burden/headache of sgfxi was precisely because of the convoluted mess presented by those very same debian wiki non free driver install pages, which presented not one simple clean method, but 3, none of which were intuitively easy or reliable for regular users, and which left a great deal unsaid and undocumented. So sgfxi automated all that stuff, which is what scripts are supposed to do. The actual debian way has gotten easier since that time, to its credit, but it is still doomed to fail on some kernel/xorg updates.
Re the connection issue, if it's the same one I see in distros using gui connection managers that drop the connection out of X, that is in my opinion a bug with the configuration of those tools, and that bug should be fixed, ie, you should be able to easily and intuitively run a desktop system without X running, precisely so you can do whatever you need if you need to do it, without then hitting a steep learning curve just to get a connection running. Avoiding steep learning curves is how desktop Linux will succeed.
By the way, if I could make sgfxi install non free drivers from the run packages in X, I would have done that years ago, I can't.
Also remember, sgfxi lets you install distro packaged drivers easily: sgfxi -d
that is supposed to implement the Debian method explicitly, failure to do so is a bug and should be reported to my forums as such, usually that is caused by some package name changing without my being aware of it, or something else.
Re your connection drop, what I think is needed is for this problem to be solved so all users can benefit, it's a real problem, I see it in mepis users too, but it's not my issue so I can't fix it, don't have the time/desire to enter into such work at this point in my life, but it would be nice for the entire user base if that issue could be fixed for everyone.