Everytime you compile a kernel you are builiding an entirely 'new' one! The file in /usr/src/linux called '.config' contains the settings that have been made when the kernel configuration program was last run. And directly after the installation of Tussinella 6.0 or above that .config file is empty/not existing. Is that right? I, too, was scared when I thought I had to build a config from scratch. I like to make small changes, and the first time I did a 'make config', seeing the defaults set to something I knew was different than
On Sat, 7 Apr 2001, Oliver Ob wrote: the running kernel, I panicked! I didn't understand what half the options were for, much less knew how they might be set in the default SuSE kernel. However, after some searching on the distribution CDs, I discovered that there is a .config file corresponding to every binary kernel they ship! So all you have to do is go back to the CD, select the corresponding config, and copy it to /usr/src/linux/.config. Then you can run `make menuconfig` and be confident that you're making only the change you intend. (Unfortunately, I don't remember exactly where I found it, at the moment.)
next, which i am missing, is some index-help-base in which you can enter a search word for instance "squid" and get a 2,3 line short description of what it is and a link to the concerned howto, minihowto and doc files.
is there anyrthing like that (before i am again inventing wheels...) or am i just blind and too pragmatically minded? For this, I mount CD1, go back to yast, select 'index of all packages' and press F2 for the short description.
Now for my rant of frustrations: 1) How can we develop a smooth upgrade path when the RPM package name changes from release to release? Why does SuSE issue Xfree3 and Xfree4 under different names, instead of changing just the release level? They can't coexist, yet one has to manually remove one before installing the next, then reconfigure from scratch. Same for KDE 1 & 2, bind, lpr, squid, etc. I just upgraded from 6.4 to 7.1, and well over half the packages came up with 'no replacement package on installation media'. I have over 300 rpm's I have to manually research and figure out how to upgrade. 2) Why are modules so dependent on the specific kernel build? IMO, the advantage of modules is that they can be compiled SEPARATELY from the kernel. Yet the current linux implementation is highly dependent on being compiled along with the kernel, and knowledge of the system.map generated with the kernel during compile. I discovered the hard way that because I chose to install the OSS drivers shipped with 6.4, I could never recompile my kernel without losing sound. OSS was shipped as `binary-only` and was mapped to the SuSE-compiled kernel, so it would not load on any kernel I compiled myself, no matter how slightly modified. Whatever information the module needs to find it's link points within the kernel, should be supplied *by the kernel* via a system call. This would allow total independence between kernel and modules, so that vendors who choose to develop drivers for their hardware, can produce a module that will install itself to a much wider range of kernel versions, without asking the user to recompile it from source. 3) With the development of the LSB, could there be something like a distribution-spec file? I know that rpm can invoke pre-install and post-install scripts. What if there were a set of standard environment variables which described the variation between the LSB and this particular distribution/release? So that rpm would invoke the pre-install script, which would read the spec file, set the environment variables, and then all the files would be placed in the right place for this distribution? Could we get to a point of 'universal rpms'? Probably, we need to incorporate more standard RPM names (see rant #1), and expand dependency checking to a range of release levels, as well. ...That's enough ranting for now. I'm still sold on SuSE. I bought it back around 5.0 because it was the only release which had actually incorporated the keyboard-howto into the code, and my backspace and delete keys worked consistently across all applications. Maybe a silly reason to you, but it lowered my stress level, and made Linux comfortable for me to use. I have stayed with SuSE as I've learned more about security concerns, and feel most comfortable with the work that the SuSE team puts in to keep the code clean and provide updates whenever exploits are discovered. -- Rick Green "I have the heart of a little child, and the brain of a genius. ... and I keep them in a jar under my bed"