Ralf Mardorf wrote: > Gustin Johnson wrote: >> Ralf Mardorf wrote: >> >>> <snip> >>> Sometimes the blame is on Linux ;), e.g. if a module for IDE is fine >>> with primary devices, but not with secondary devices, because the coders >>> tested two IDE devices, but both as primary on another IDE port. Than >>> someone like me gets a board with only one IDE port, but he ... I have >>> got 2 IDE devices, so one becomes the primary and the other the >>> secondary device. It's just bad programmed by Linux coders. That is >>> okay, such things can happen, but the problem with the community is, >>> that they will not see, that many, maybe most problems are self-made and >>> not from evil vendors and ignoring that isn't a help. >>> Actually, if the vendors would lift one finger to help, you would see a reduction in such errors. It is hard enough to reverse engineer a device driver, doing it bug free is impossible.
I am not saying that bugs won't happen, but the blame for the vast majority of device problems lies firmly and squarely with the vendors. Of course you could make the argument that our choosing a non-mainstream OS could put the blame on our shoulders. Until I start paying every kernel developers salary, I do not plan on blaming them for anything. >>> >> The developers do the best they can with the limited assistance they >> receive from the vendors. If you want to make sure that Linux works >> flawlessly with your hardware, send the maintainers the relevant >> hardware or fill out bug reports. They can't test against what they >> don't have. > > I've done a bug report, but I didn't noticed that it had to do with the > primary and secondary situation, the coders also didn't noticed that, > but another user does. This was for a stable Suse release and because of > this, I wish to have a forum for RC versions, in this case for Suse, > where users can share information and do better bug reports. I don't use SuSe, but i am pretty sure they have their user support groups/forums just like Fedora and Ubuntu and almost every other distro. You don't really need a kernel specific group. If by RC you mean release candidate, well the linux kernel mailing list is probably where you would want to go. The RC kernels are for testing, which means they want people to use and abuse them *and* fill out bug reports. So, for kernels that are a part of a distribution, use that distribution's support mechanism, for RC kernels that you download and build from kernel.org (where you get RC kernels) you use the lkml lists. If you download a kernel from a 3rd party you go to the 3rd party for support. Yes this is slightly more complicated than getting support for Windows, but that is part of the price paid. There ain't no such thing as a free lunch. Words to live by. > > It was similar here on the list. Because of troubles I upgraded 64 > Studio 2.1 to Lenny and while there were less people using the list, > some people did not want requests about Lenny. Debian has its own groups and mechanisms to deal with Lenny issues which is where those reports should go. 64Studio is still currently based on etch, so it is a little unreasonable to expect to get support for Lenny here.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 64studio-users mailing list [email protected] http://lists.64studio.com/mailman/listinfo/64studio-users
