Burning software
in [Mandrake]
|
Prev: madwifi & ath_pci
Next: What is MRL?
From: Aragorn on 27 Aug 2005 23:01 On Sunday 28 August 2005 01:20, Ron Gibson stood up and spoke the following words to the masses...: > On Sat, 27 Aug 2005 14:42:16 -0500, Teilhard Knight wrote: > >> Now you are telling me most probably the problem is a packaged piece >> of code, my next move is to look for the sources and build the damn >> kernel source myself. Any advise to remove what I already have and >> get the tarball? > > Yes. As I said distro kernel hacking can cause problems when you try > to add third party modules which are almost always built by the > hardware dudes for a "pristine" kernel source from kernel.org Actually Ron, third party modules are mostly built for the patched distribution kernels and packed in distribution-specific packages, rather than for vanilla flavor kernel trees. The default choices for /.rpm/ packages are Red Hat (or Fedora Core) and/or SuSE, and then often - but certainly not always - a /.deb/ package is also supplied. Mandriva-specific /.rpm's/ are also found, but to a lesser degree. Finally, every once in a while you will find a binary Slackware package as well. Typically, a hardware vendor will support binary packages for one or two Gnu/Linux distributions, and then they expect you to just shut up and be grateful that you get Linux kernel modules with your hardware, rather than to complain that the packages they supply just don't happen to be for the distribution you're running. While it is true that an /.rpm/ for RedHat or Fedora Core may typically work for Mandriva as well - you may want to stay away from SuSE /.rpm's/ - this only applies to userspace programs. Kernel modules are a different story, as a RH kernel is certainly not an MDK/MDV kernel. > Often distro providers take and modify that code and include it to > work with their modified kernel. Since you don't have a clue what they > did that is a problem. We typically don't have a clue, but it is verifiable, as they have to supply you with the source code, and most likely there will be a /Changelog/ file as well. So it's traceable. What's far more obscure is what the hardware vendors' binary modules contain, as their source code is hidden and you just have to accept their modules as they come. > What I'd do for starters is go where you found those drivers and take > note of any requirements on what version kernel is required if any. if > it specifies a version level then download that kernel source. > > Stop at that point and then ask for suggestions on the best way to > test the vanilla kernel with your current setup. My personal experience is that vanilla kernels are more stable than distro-patched kernels. At least, that is the case for Mandriva, and I've heard similar tales regarding RedHat, Debian, etc. In theory and in the kernel development schedule as was used last year, the kernel core team supplies you with a "production-ready" kernel, but expects the distribution makers to stabilize the kernel further. However, in practice, this came down to the kernel developers actually submitting patches themselves to get rid of the bugs, resulting in intermediate small number version bumps - the current stable kernel is 2.6.12.5 - while the distribution makers are more concerned with throwing in extra junk (like Supermount) to add features to their kernels and are spending less time actually debugging the kernels because of their tighter release schedules. -- With kind regards, *Aragorn* (Registered Gnu/Linux user #223157)
From: Aragorn on 27 Aug 2005 23:04 On Sunday 28 August 2005 00:21, Teilhard Knight stood up and spoke the following words to the masses...: > Thanks so much for your explanation. I hate to confuse people, but I > did it this time. We were talking about Debian, and I know I shouldn't > do it here, it's just that my conversation with Ron, lead me there, > not because of his fault but rather than mine for referring to Debian > when we were talking about distros in general. Still, what you say is > useful to me to understand Mandriva better and that is much > appreciated. I didn't even pay attention to that you were talking about Debian. ;-) I noticed it yes, but the problem you addressed was not Debian-specific. It applies to all distribution-patched kernels. Glad I could help... ;-) -- With kind regards, *Aragorn* (Registered Gnu/Linux user #223157)
From: WCB on 28 Aug 2005 01:15 Ron Gibson wrote: > On Sat, 27 Aug 2005 13:09:53 -0500, Teilhard Knight wrote: > >> And in the case >>> of Linux knowledge is most definitely power. > >> True, and knowledge is what I lack. I installed Debian in another machine >> just for fun and to appreciate what I am dealing with and why Debian is >> so a popular distro among the geeks. It has been a source of headaches >> for me. > > Well much geekier would be gentoo, slackware, LFS, FreeBSD (not really a > Linux). > >> I do that and I cannot compile. Then someone said I needed the kernel >> headers (whatever they are) and to install a package and run "m-a > prepare". >> When I run this command I get the warning that I do not have a configured >> kernel source. I ignored the warning and compiled my driver and >> apparently compiled all right. But the module didn't load in the kernel >> and refuse to > > Well this is IMO an artifact of "package managed" distros. > > I really like a distro that allows me to install what I want and where I > want to. I'd prefer to get the source package, read the docs on the > website, meet the requirements of the package (libs, make, etc) and > build it myself. This almost always works fine and the docs are complete > enough. > > OTOH "packaged managed" distros often split packages, especially libs > and headers, and/or modified a binary in a way that you don't know about > which may cause problems. > > But actually as far as hardware goes it's much better to buy custom > built or build it yourself and select known compatible components. > > Hell I couldn't figure out the instructions to install a wireless > network on windoze which many champion as the OS even the brain dead > would flourish with. > > You tried a compile and at this point in your learning that probably is > a big leap. I'd reacess my needs and perhaps drop a few bucks on solving > the hardware issue before I ran myself crazy trying to do things beyond > my expertise. > > OTOH you can't learn to swim without getting wet. > > The question at this time is the water too cold to jump in now. Gobo Linux is supposed to be trying to move around many of these problems. Gobo tries to keep a tarball package and dependencies in a discrete directory with libraries et al. Once you have it set up and running, it keeps all libraries and other stuff together. This has a number of advantages, including upgades. Since an Application is in its own little package, you can set up a new Gobo install and simply move working packages in and use them without having to reinstall from scratch. You can have packages that run on oddball libraries seperated or different packages that clash over which version of GCC you compile with seperate and running with less problems. In theory. Its a bit of a Beta now, but I am keeping an eye on this one. It has the possibility of making upgrades simpler, like setting up a new install of Mandrake but keeping /home/ seperate, one can keep Gobo's Application partition seperate in the same manner, untouched. Just run the linking utility to link those packages to desktop and off you go. It means potentially if somebody has gotten all the stuff together to set up a new version of something or a new software app, all Gobo users could use it with no changes. Sort of like being able to get setup RPMs via urpmi. -- Xenu is around and about, mention Hubbard, Xenu pops out! No way for the clams to stamp Xenu out, Xenu is around and about! Cheerful Charlie
From: Ron Gibson on 28 Aug 2005 13:16 On Sun, 28 Aug 2005 03:01:17 +0000, Aragorn wrote: > Actually Ron, third party modules are mostly built for the patched > distribution kernels and packed in distribution-specific packages, > rather than for vanilla flavor kernel trees. I said it the simple way. Often that process involves patching the kernel. I had to use Hedricks patch for ATA controllers for over a year (1999-2000) and found that a patched kernel can be troublesome. How and in what form the kernel module will be supplied is not a singular approach. Some require a specific kernel version. The patches on kernel.org always required a patch specific to a certain version. Of course if you can get a prebuilt one, have not the expertise to DIY then one best do urpmi. > The default choices for /.rpm/ packages are Red Hat (or Fedora Core) > and/or SuSE, and then often - but certainly not always - a /.deb/ > package is also supplied. I just tried the Nero rpm with mandrake and first thing it told me was unsupported distro so go figure. It did however work but I saw no feature that isn't already available with several burning front ends. That pisses me off too. Here's a company offering nothing other than their name and they want to charge for the pretty GUI they coded ??? Hogwash. > Mandriva-specific /.rpm's/ are also found, but to a lesser degree. > Finally, every once in a while you will find a binary Slackware package > as well. Hmmmm...any binay tarball will work with Slackware as long as the required libs are present. Well lets rephrase that - I never ran across one that didn't. In fact there is a site that even offers prebuilt Slackware packages not provided by Pat. http://linuxpackages.net/ > Typically, a hardware vendor will support binary packages for one or two > Gnu/Linux distributions, and then they expect you to just shut up and > be grateful that you get Linux kernel modules with your hardware, > rather than to complain that the packages they supply just don't happen > to be for the distribution you're running. > While it is true that an /.rpm/ for RedHat or Fedora Core may typically > work for Mandriva as well - you may want to stay away from SuSE > /.rpm's/ - this only applies to userspace programs. Kernel modules are > a different story, as a RH kernel is certainly not an MDK/MDV kernel. >> Often distro providers take and modify that code and include it to >> work with their modified kernel. Since you don't have a clue what they >> did that is a problem. > > We typically don't have a clue, but it is verifiable, as they have to > supply you with the source code, and most likely there will be a > /Changelog/ file as well. So it's traceable. If you program C. I've done it before muddling through the mess. Today my patience is less and when I have to resort to learning a language I'll opt to find an easier solution. I just want to drive the car, not know the thermodynamics of combustion, albeit I know that too but I drove just fine as a kid before I became an engineer. > What's far more obscure is what the hardware vendors' binary modules > contain, as their source code is hidden and you just have to accept > their modules as they come. And quite often you'll find that it's simply something off of kernel.org they added a fancy splash screen to and managed to muck that up. >> What I'd do for starters is go where you found those drivers and take >> note of any requirements on what version kernel is required if any. if >> it specifies a version level then download that kernel source. >> Stop at that point and then ask for suggestions on the best way to >> test the vanilla kernel with your current setup. > My personal experience is that vanilla kernels are more stable than > distro-patched kernels. At least, that is the case for Mandriva, and > I've heard similar tales regarding RedHat, Debian, etc. Most definitely. As soon as possible I dump -mdk -deb -gentoo kernels and get back to mainstream. Hell there is absolutely nothing I need in those cooked kernels unless your a passionate Supermount type which I sure am not. BTW just reinstalled MDK 10.2 again. Didn't apply the updates and it runs a lot smoother tha last time. Recompiled and removed the junk from the kernel I don't need but still get core dumps all over the place so I'm using my run-parts scripts to locate them for deletion. I;ve got all the apps in place and as a goof have the desktop looking identical again. I think I'll just disable the update media and Matt forget it. Save your breath. I'm not worried about security and don't run a server. I suspect that will not go away because I'm here to tell ya, gcc 3.4.3 sucks bug time. None of the other three distros use it and I don't have these problems. > In theory and in the kernel development schedule as was used last year, > the kernel core team supplies you with a "production-ready" kernel, but > expects the distribution makers to stabilize the kernel further. My experience is just the opposite. The distro kernels are more likely to not be ready for prime time, so I'd say that is yes, a theory. > However, in practice, this came down to the kernel developers actually > submitting patches themselves to get rid of the bugs, resulting in > intermediate small number version bumps - the current stable kernel is > 2.6.12.5 - while the distribution makers are more concerned with > throwing in extra junk (like Supermount) to add features to their > kernels and are spending less time actually debugging the kernels > because of their tighter release schedules. LOL! Well I guess we couldn't agree more on that :-) Note for the less experience readers - If none of this made sense stick to urpmi. PS: After working on the latest 10.2 install for 2 days and almost done now it sure seems a lot better than my last taste. I wonder if they even modify the ISO's post roll out.
From: Aragorn on 28 Aug 2005 16:22
On Sunday 28 August 2005 19:16, Ron Gibson stood up and spoke the following words to the masses...: > On Sun, 28 Aug 2005 03:01:17 +0000, Aragorn wrote: > > I just tried the Nero rpm with mandrake and first thing it told me was > unsupported distro so go figure. It did however work but I saw no > feature that isn't already available with several burning front ends. > > That pisses me off too. Here's a company offering nothing other than > their name and they want to charge for the pretty GUI they coded ??? > > Hogwash. I don't understand why people would want to install things like Nero or even Adobe Acrobat Reader when there already are much better alternatives present in every distro. ;-) >> Mandriva-specific /.rpm's/ are also found, but to a lesser degree. >> Finally, every once in a while you will find a binary Slackware >> package as well. > > Hmmmm...any binay tarball will work with Slackware as long as the > required libs are present. Well lets rephrase that - I never ran > across one that didn't. In fact there is a site that even offers > prebuilt Slackware packages not provided by Pat. > > http://linuxpackages.net/ Well, I was not talking of tarballs. I was actually under the impression that Slackware used its own package manager, similar to RPM. Guess I was wrong. :-) >> We typically don't have a clue, but it is verifiable, as they have to >> supply you with the source code, and most likely there will be a >> /Changelog/ file as well. So it's traceable. > > If you program C. I've done it before muddling through the mess. Today > my patience is less and when I have to resort to learning a language > I'll opt to find an easier solution. I just want to drive the car, not > know the thermodynamics of combustion, albeit I know that too but I > drove just fine as a kid before I became an engineer. Yes, but what I meant was that at least that is something that's available, while the source code for the proprietary kernel modules from hardware vendors are usually not available, making it all the more arcane as to whether said module will work in your particular distro if that doesn't happen to be a RedHat or a SuSE. > And quite often you'll find that it's simply something off of > kernel.org they added a fancy splash screen to and managed to muck > that up. Hmm... This is something I don't know, but in regards to video drivers and the likes, I doubt they would get it from kernel.org. If that were the case, then native Gnu/Linux would already support their card without the vendor-specific drivers, which is clearly not the case. I happen to know, as I have such an unsupported card. Well, there are drivers available from ST MicroElectronics, but only for the 2.4 kernel, and they even state that in the event of Mandrake, you have to use a vanilla kernel as their driver causes the Mandrake kernel to crash because of a security patch in the MDK kernel... >> My personal experience is that vanilla kernels are more stable than >> distro-patched kernels. At least, that is the case for Mandriva, and >> I've heard similar tales regarding RedHat, Debian, etc. > > Most definitely. As soon as possible I dump -mdk -deb -gentoo kernels > and get back to mainstream. Hell there is absolutely nothing I need in > those cooked kernels unless your a passionate Supermount type which I > sure am not. Is the Gentoo kernel that flawed as well? I was rather expecting Gentoo to have done a better job at stabilizing their kernels. > I suspect that will not go away because I'm here to tell ya, gcc 3.4.3 > sucks bug time. None of the other three distros use it and I don't > have these problems. Indeed, Mandrake/Mandriva made a bad call on that one. > Note for the less experience readers - If none of this made sense > stick to urpmi. .... or read up a bit on the kernel and learn something interesting... :-ý > PS: After working on the latest 10.2 install for 2 days and almost > done now it sure seems a lot better than my last taste. I wonder if > they even modify the ISO's post roll out. To my knowledge, they don't. As soon as the /.iso's/ are out, the only corrections are patches, as well as a few sections on their Errata pages, but only concerning the very obvious bugs that a lot of users have encountered. -- With kind regards, *Aragorn* (Registered Gnu/Linux user #223157) |