SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Really? name a filesystem that I can't mount in 2.4x (and that includes ntfs,mass storage devices, etc) yes the support may not be native but that is a technical footnote not an obsticle.
Anything which reduces the chances that you will render your installation un-usable is a good thing. One good idea when learning kernel compiling is to not recompile the same kernel that is already working. /lib/modules can quickly become a big fat mess. You already have a working 2.4 series kernel. Why mess with that while still learning? Jump to a 2.6 series kernel. Since the 2.4 kernel on your system is already working (and should continue to work if you compile new kernels correctly), I think compiling a 2.6 kernel is a great learning tool. Keep compiling until you get it to work. After that, re-compile until you get it to break
Shilo, some good points!
Might I add you can compile a new kernel without effects on your current modules by just editing the /usr/src/linux/Makefile and add to the EXTRAVERSION= parameter.
This way you will create a new /lib/modules/kernel.ver tree.
Another point of interest is to break something! Some people break without even knowing it. How many people really look at their log files on what they think is a running system? If they would look on a frequent basis or have email errors then that would also provide means to learning the system. Tracking errors and then fixing can be fun yet frustrating at times.
As for the rampant compile method. I would rather like to have a planned compile. Know your hardware and the needs for that system. We don't want bloatware, do we?
For most of my systems I have several boot options. I have some set to allow custom 2.4 or 2.6 kernels for varied setups.
No, I'm pretty sure Reiser4 is not in the vanilla 2.6 kernel yet.
As I see it the two main reasons to use 2.6 over 2.4 are the improved performance and udev. Not only does it allow for dbus and hal, which would be reason enough to use it but it's also useful being able to set rules as to what /dev nodes are assigned to which devices, regardless of the order in which they're plugged in. Udev is just so much better a way of handling device nodes than a static /dev tree or, worse, devfs.
Improved hardware support is all well and good, but if 2.4 already works for your system, that's not a very compelling reason to upgrade.
Quote:
Originally Posted by gwsandvik
Might I add you can compile a new kernel without effects on your current modules by just editing the /usr/src/linux/Makefile and add to the EXTRAVERSION= parameter.
No need even for that. Just set CONFIG_LOCALVERSION in the kernel config (under 'General Setup in the menu) and it'll get added to the version string.
thanx shilo,
I must admit compiling the kernel is quite a complex process especially when things go wrong...I’ve been a windows programmer for a number of years (c/c++/asm/basic etc etc) and I thought that linux would be a breeze. However, hours of debugging installation scripts, hunting down package dependencies etc has cured me of this naďve assumption. I suppose that anything that streamlines the user experience would be eagerly anticipated by the linux community and in this regard progress is inevitable. The original question though was: has enough progress been made to justify upgrading?
For my purposes, the answer is: not really.
No, I'm pretty sure Reiser4 is not in the vanilla 2.6 kernel yet.
As I see it the two main reasons to use 2.6 over 2.4 are the improved performance and udev. Not only does it allow for dbus and hal, which would be reason enough to use it but it's also useful being able to set rules as to what /dev nodes are assigned to which devices, regardless of the order in which they're plugged in. Udev is just so much better a way of handling device nodes than a static /dev tree or, worse, devfs.
Improved hardware support is all well and good, but if 2.4 already works for your system, that's not a very compelling reason to upgrade.
No need even for that. Just set CONFIG_LOCALVERSION in the kernel config (under 'General Setup in the menu) and it'll get added to the version string.
Hi,
Good points! I forgot about CONFIG_LOCALVERSION, thanks for the reminder.
i've never used 2.6 as i've never had any reason to... but i might start thinking about moving to 2.6 in a couple years, after development on it has cooled-down... for now, all my boxes are extremely happy with 2.4...
having said that, i will be getting my first laptop soon, and when i do, i will definitely put the latest and greatest 2.6 on it!!!
yeah, i think a move from 2.4 to 2.6 should be done only when needed, or when you really really want it really bad...
Quote:
Originally Posted by KimVette
break past the 2GB file size barrier
you mean the imaginary 2GB file size barrier??
no but seriously, what do you mean?? the only time i've heard about this limitation was with the ext2 filesystem... on reiserfs i've never had any file size limitation issues...
no but seriously, what do you mean?? the only time i've heard about this limitation was with the ext2 filesystem... on reiserfs i've never had any file size limitation issues...
Other than say servers or workstations, does any here ever encounter 2G+ files? I mean I guess its nice to know, but I don't think I could justify switching kernels because of that. I'd would be more concerned about speed, flexabiliy, and stability.
Other than say servers or workstations, does any here ever encounter 2G+ files? I mean I guess its nice to know, but I don't think I could justify switching kernels because of that. I'd would be more concerned about speed, flexabiliy, and stability.
I have worked with a file in excess of 10Gbyte on reiserfs (v3). Audio PCM wave file.
If you meddle around with DVD ISOs especially DVD9, then you will be working with file larger then 2G.
I would suggest formating your drive with SGI's XFS or IBM's JFS if you routinely meddle with file of those magnitude.
Otherwise, reiserfs works well.
Please note, all meddling was done in 2.6.* kernel environment.
Yeah, I use XFS for my /root and /home paritions, but only because I was told it was fast and stable, aslong as it had a good constant power supply. But I no longer have a fear of large files :P
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
