On Thu, 06 Nov 2003 21:34:57 -0600, Kent West wrote: >Mark Healey wrote: >> On Thu, 6 Nov 2003 13:09:24 -0500, ScruLoose wrote: >> >> First off. I am doing this because none of the kernels on the cds >> support my nic. Consequently, any suggestions that involve using >> apt-get isn't really helpful. Also, my X isn't working either so the same applies any graphical tools.
>One thing that helps in this regard is to keep different topics in >different threads, and to title the subject line accordingly. For >example, X issues might be titled something like "X won't start for this >newbie", and network issues might be titled something like "3c59x module >loads, but can't ping". This also helps other users when they go >searching the archives for answers to their similar dilemmas. > >So, what's wrong again with your X setup? I don't even want to think about the X problem until I get the networking up. My guess, right now, is that ATI changed their chipset. I'll really look into it later. > >> >> Buying another nic card isn't an option either. > >Why? I vaguely remember someone saying they couldn't get to town to get >a nic because they have a broken/missing accelerator cable. Fixed that. Perhaps that >was you? Or is it because you can't afford one? Don't have the slots >available for one? Several reasons. I'm afraid that the model listing on the box won't include any revision numbers indicating that it is actually broken for linux use (has happened to me before). I fear lots of reconfiguration difficulties when I remove it and try to move everything to the original nic (this has happened with OS/2). I also fear that even if I succeed to move back to the original card that there will be lots of vestigal crap missed that will make things difficult later. >> I've decided to roll my own (this is hacker shit that an ordinary user >> should never have to even think about) becasue none of the precompiled >> kernels match what I have very well. > >You're right; ordinary users shouldn't have to think about rolling their >own if they're paying for service. However, if you're getting something >free, sometimes you have to accept the flaws in that product. Debian >coders are volunteers; I'm sure they'd love to have real paying jobs >where they could scratch their itch and yours. Instead, they scratch >their itch because they want to, and if you benefit from it, great!. And >part of that itch scratching for many of them is to solve problems for >you, but that's lower on the priority list for most. > >I certainly understand your frustration. I've been there a time or two. >I've learned to blame the hardware manufacturers for not supporting >Debian instead of blaming Debian for not supporting certain hardware. I >hope that lesson has made me a better citizen of the Debian community. I realize that and I've been told that writing installers is considered scut work. But if it isn't fixed, Debian will remain a hackers distro. > >I would suggest (modestly?) that you read "Kent's 10-Step Procedure to >Compiling a Debian Kernel", which is the bottom section of "README.gz" >in /usr/share/doc/kernel-package (you'll need to "apt-get install >kernel-package" to ge this document). I hope that was a cruel joke. >It also seems to be online here: Appearantly it was. >http://lists.debian.org/debian-user/2002/debian-user-200205/msg02951.html. >It may not answer your questions, but it covers the things that I saw as >issues. I'll give it a shot in the morning. This is more out of curiosity than anything else but is there a way to check what features are incorperated into a running kernel. Mark Healey [EMAIL PROTECTED] Giving debian a chance. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
