Top programmers hope to release on Wednesday a major update to Linux, version 2.6.0, a change that’s expected to help carry the open-source operating system into new markets. Linux 2.6 might get released tonight, C|Net says. UPDATE: The kernel 2.6.0 is out. Get it while it’s hot. Changelog here.
TurboLinux 10. They had (2.6.0-test5) as the default kernel so I don’t see a reason why they wouldn’t just upgrade straight away.
http://www.osnews.com/story.php?news_id=4728
Thanks to the suggestions by Montana & Someone, I compiled ReiserFS support into the kernel instead of leaving it as a module, and was able to boot up 2.6.0. I must say that I’m really impressed with the responsiveness, which is even better than WinXP on the same machine. The only downside is now my wireless & ethernet cards no longer work, so all network connectivity is out. Perhaps another recompile with the appropriate patches will fix that!
“I’ll pass
”
Good call, cause I’m sure your box with 32GB of ram will be paging out all the time now that it can only use 24GB…
“This kernel is a peice of junk. The driver for one of the most popular network cards ever is BROKEN. The 3c59x driver does not load on boot. It’s a known issue, but why release the kernel with such a major problem?”
Wow, great attitude. And wouldn’t that be a *driver* issue? The kernel sports many improvements. I think “junk” is generally unwanted trash. Given the number of responses to this thread, and the number of people downloading it…one could hardly classify it as “junk”.
Let’s not forget about the brand new sluggish swapping feature and the 1% overall performance hit. Gawd knows that normal machines *never* use the swap space ;p
Seriously, some of you people are as bad as I am
Step 14. That’s it! Reboot your machine with a ‘shutdown -h now’ (leave no disks in the floppy drive) and when you reboot, you should be selecting and rebooting the new kernel.
Good luck everyone!
reboot: shutdown -r now
halt: shutdown -h now
Hello,
The only way I know of to get kernel boot failure messages is to reconfigure lilo to boot with a console device as a serial port. The boot with another computer loggin the serial port. This also works for catching kernel panics.
Note: The last time I did this you had to patch the kernel to put the console on the serial port. (intel boxes) I haven’t done it in a while so milage my vary.
Donaldson
problems like this almost never arise in FreeBSD
Well, you don’t exactly have a plethora of filesystems to choose from either, do you?
problems like this almost never arise in FreeBSD, but when they do, because the bootloader understands the filesystem and can link modules into the kernel before booting, fixing them is as simple as adding a line to /boot/loader.conf, rather than recompiling your kernel.
man initrd the next time you’re on a Linux system. I believe most distros use this. Either that or GRUB.
What is it with Linux people and constantly recompiling their kernels and hand tuning their kernel configs?
Because it gives them that good fussy feeling inside I suppose, kinda like the BSD folks who insist in compiling everything from source.
With FreeBSD I rarely need to deviate from the GENERIC kernel config
Nor do you with Linux. Ever tried Knoppix?
especially with the advent of the GENERIC SMP config.
Better late than never.
On bsd bootloaders it just means thier more bloated. I guess in my case If I was to move over to BSD the bootloader would need the Raid-5 code , LVM code and the reiserfs handy to meet the requirement of
“understands the filesystem and can link modules into the kernel before booting”
After all my kernel and its toys are down there.
For the record I keep a copy of my kernel on a dos partition at the start of every drive. The kernel has all the need modules compiled in. I’m not recompiling milo ever again….
Donaldson
Well, you don’t exactly have a plethora of filesystems to choose from either, do you?
We have enough. I thought the following was somewhat relevant:
“All of the BSD camps make stability priority #1 and performance priority #2. Performance and fast crash recovery is completely irrelevant if the filesystem corrupts the data or causes a crash! This is especially true as HD capacities increase and filesystems become larger. I have never quite understood why the Linux community gets so revved up by the huge number of filesystems they support. As if the sheer number combine together to provide a more effective system! You don’t get reliability, performance, and long term stability by playing with filesystems, you get it by choosing or focusing on one or two filesystems that deliver those characteristics. Depending on filesystem-specific ‘super’ features makes code non-portable and is not usually a good idea.”
http://www.osnews.com/story.php?news_id=153&page=2
We have enough.
By not too long terrabyte filesystems will be fairly common even on desktop machines (and of course it won’t stop there). Non-journaling/logging filesystems just won’t cut it. Not only does it take a ridiculous amount of time to fsck such a system after an unclean shutdown, but it also requires a lot of RAM to do so. Good luck with those 24+ hour recoveries.
Also, the part you highlighted is pretty amusing. UFS2 in FreeBSD is basically a Kirk McKusick show, whereas none of the major filesystems in Linux are one-man shows. In fact, some of them has had _years_ of testing in other systems prior to going into Linux.
Wow. The ignorance
I stand by what I posted before. Having a multitude of filesystems is not the tremendous advantage that most Linux users think that it is (the sole exception being for purposes of interoperability).
I am not at my own machine, so I’ll try to find the links to back up my next staements (feel free to look yourself), but UFS has been around “forever,” and has been *VERY* well tested. It is definately more mature than anything in Linux now.
Let’s not forget about background fsck (new in FreeBSD 5 and I might say pretty damned nice, I’ve used it already), meaning that disaster recovery isn’t going to be quite the issue that you’re making it out to be.
UFS2 (and UFS1) already support terrabyte sized filesystems. (this is not FreeBSD specific) Filesystems of roughly an exabyte in size are theoretically possible (I need to find a link for this one). (Sun already does have a multiterabyte UFS, and their UFS code is derived from the exact same source code as is FreeBSD’s, meaning that if FreeBSD is not so capable already, it’s not impossible for the FreeBSD folks to do so.)
http://se.sun.com/service/support/infoexpress/2003/nr3/0903-01.html
UFS is *NOT* a one man show, and every one of the BSDs do in fact do their fair share of the innovation and maintainence of the code. They don’t all wait around for Mckusick to fix what few bugs are found or for him to innovate any more than Red Hat waits for Linus to incorporate things into Linux. That’s a silly argument you made, akin to saying that Linux is a one man show.
If that’s not enough, if you really think that the BSD developers aren’t going to keep their respective systems up to date with regard to to the trends in the world of computing, you’ve got to be smoking something. Like the technology itself, they do not stand still.
Having a multitude of filesystems is not the tremendous advantage that most Linux users think that it is (the sole exception being for purposes of interoperability).
For the people who want or need jfs, it’s important that they get it. For the people who want or need xfs, it’s important that they get it. For the people who want or need reiserfs, it’s important that they get it. For the people who want or need ext3, it’s important that they get it. You can go with any or none of the above. You’re allowed to make an informed choice. Choice is not bad. Is this simple principle so hard to grasp?
All of the above filesystems has seen far more developer time and peer review than UFS2 that is going to be the default file system in the next generation FreeBSD. It makes your Dillon quote look pretty dumb.
I am not at my own machine, so I’ll try to find the links to back up my next staements (feel free to look yourself), but UFS has been around “forever,” and has been *VERY* well tested.
Man, talk about punching a straw man. I _specifically_ said UFS2, not UFS. While UFS2 may be based on UFS, they aren’t even on-disk compatible. Also, while UFS has been around ‘forever’, softupdates is a lot more recent, and yes, even that was initially a one-man show by Kirk McKusick. It was paid for by Whistle (later bought by IBM) I believe for use in the FreeBSD-based InterJet, and it was not released under a BSD license until sometime late 1999 or early 2000 if I remember correctly.
It is definately more mature than anything in Linux now.
And ext2 is more mature than any of the other filesystems in Linux. Yet I don’t use it. Mature is a term you use when you don’t really have much to say beyond, ‘it’s old, it’s gotta rock’.
UFS2 (and UFS1) already support terrabyte sized filesystems. (this is not FreeBSD specific) Filesystems of roughly an exabyte in size are theoretically possible
What has this got to do with anything? Did I somehow claim they couldn’t handle big filesystems? Stop punching straw men.
Let’s not forget about background fsck (new in FreeBSD 5 and I might say pretty damned nice, I’ve used it already), meaning that disaster recovery isn’t going to be quite the issue that you’re making it out to be.
That’s certainly better than not having it (when it works), but it’s a stop gap measure. I can’t possible see how you can argue otherwise.
UFS is *NOT* a one man show, and every one of the BSDs do in fact do their fair share of the innovation and maintainence of the code.
Right now UFS2 is FreeBSD 5.x only.
If that’s not enough, if you really think that the BSD developers aren’t going to keep their respective systems up to date with regard to to the trends in the world of computing
FreeBSD atleast is trying, Net- and OpenBSD aren’t even close.
you’ve got to be smoking something. Like the technology itself, they do not stand still.
They are all volunteer projects with only so much man power.
For the people who want or need jfs,..
I repeat, “for purposes of interoperability…”
Right now UFS2 is FreeBSD 5.x only
I beg to differ:
http://www.osnews.com/story.php?news_id=3185
and:
http://netbsd.org/Changes/#ufs2-commit
FreeBSD atleast is trying, Net- and OpenBSD aren’t even close.
NetBSD is tackling almost all the same problems as FreeBSD, with the exception (AFAIK) being TrustedBSD.
And ext2 is more mature than any of the other filesystems in Linux. Yet I don’t use it. Mature is a term you use when you don’t really have much to say beyond, ‘it’s old, it’s gotta rock’
I guess my point was that it’s because UFS has been around and tested for so long that it’s mature. If I remember correctly, it was first implemented nearly a decade before Linux was first written, and has been tested and used on countless machines since then, while being constantly tuned and evolved as a fundamental part of BSD derived systems (much as ext2/ext3 has with Linux). I’d trust ext3 on Linux more than I would say XFS wouldn’t you?
Also, while UFS has been around ‘forever’, softupdates is a lot more recent, and yes, even that was initially a one-man show by Kirk McKusick.
The progression from the original Linux filesystem to ext2 to ext3 was part of this process of evolution and maturation, just like the addition softupdates (regardless of it’s origins) and the newer extentions in FreeBSD and NetBSD are to UFS. Sometimes additions are an important part of maturation.
BTW, it’s still silly to be talking about it having been a one man show to begin with, as they no longer are, regardless of the number of developers involved in the major BSD projects.
About background fsck: That’s certainly better than not having it (when it works), but it’s a stop gap measure. I can’t possible see how you can argue otherwise.
That’s a good argument for darned near anything! (the “when it works” part) Everything can be seen as a stop gap measure until something better comes along.
Just to clarify, I’m not going to get into a shouting match between which among either journalling or softupdates is “better,” as I have not read nearly enough about the two, nor have I or anyone I know done any testing.
http://mail-index.netbsd.org/current-users/2003/04/02/0005.html