Linus has released kernel 2.6.14 after two months of development. There’s a big amount of changes: new features like HostAP, FUSE, the linux port of the plan9’s 9P protocol, netlink connector, relayfs, securityfs, centrino’s wireless drivers, support for DCCP (currently a RFC draft, PPTP, full 4 page-table support for ppc64, numa-aware slab allocator, lock-free descriptor lookup and many other things. Read the comprehensible changelog or the full changelog.
This is pretty neat. I think FUSE is the best part of the release, it should hopefully allow for some nifty ideas.
Great news on the Centrino drivers.
It’s a shame that the Linux kernel doesn’t have a good driver model. If it did the Centrino wireless drivers might have been available for Linux users 2 years ago.
Centrino drivers have been available to Linux for 2 years as intel put in resources to create the an open driver (with firmware limitation though).
However, the newest stable version of this ipw driver has just been included in this kernel version. IPW support has been working great in Linux, even before the inclusion of it in the main kernel tree.
Those drivers have been implemented by the intel guys. It’s not about having a “good driver model” (may you could explaing why linux doesn’t have a “good one”, it certainly doesn’t have a stable one – on purpose – but you may want to explain why it’s “bad”), is about “having specs and/or people willing to do the dirty job”. Those drivers have been living out-of-the tree for ages, anyway.
….I’m still using the 2.4 kernel but this looks like a great release.
“….I’m still using the 2.4 kernel but this looks like a great release.”
Bloody Debian users 😉
Don’t forget Slackware
My laptop is running Slackware 10.2 with Linux 2.6.14, and it’s rock solid 🙂
My laptop is running Slackware 10.2 with Linux 2.6.14, and it’s rock solid 🙂
Hmm, LOL here. Don’t you think that is a bold statement to make for something that’s been released, what, the day before?
For me, ‘rock solid’ means ‘everything working fine’ (I assume that’s what you mean here), but IMHO also includes ‘continues to do so with time passing by’ and ‘with a variety of circumstances, systems and applications’. Time hasn’t passed by yet, and testing by a larger audience is about to happen (but hasn’t yet).
Not that I have much doubt about how well the latest 2.6.x release will work for me, but unless you’re a developer who just ran the exact same thing for at least a week non-stop on, say, an 8-way SMP machine under heavy load, ‘rock solid’ is simply a premature claim. And yes, I know pre-release (-RC1, -RC2 etc) DO get plenty of testing, but that’s just not the same as the testing it gets when it’s released to the public at large. And from what I gather, average Linux users don’t have a habit of running every other -RC kernel.
My laptop is running smooth as butter. It’s been stuck on this “kernel panic!” thing for two years running, but the darn thing just doesn’t explode! definitely stable, IMO.
as far as i know – despite the support for the drivers being in the kernel now – you still need to manually get the firmware from intel – it cannot be distributed with the gpl kernel.
… when “Numa-aware slab allocator” is the first item in the “comprehensible” version of the changelog.
Anyway, good to see PPTP included, now maybe someone will come up with a good configuration system for it. I’m pretty sick of booting into windows every time I need to access my uni VPN.
explaining what a “numa-aware slab allocator” for people who has no idea of what a slab allocator or numa is isn’t exactly a easy task. It’d require more than a A4 paper.
The “comprehensible changelog” is supposed to have a list of the most important kernel changes. That doesn’t means people is really going to understand what they mean, by “comprehensible” it means “something that people can beat themselves to understand” (which is an almost impossible task in a 2.1 MB changelog even if you’re a kernel hacker from other OS)
There are probably people who are responsible for things on the full changelog who will never read the full changelog.
I think comprehensible means, you can read it in 10 minutes like you can on everyone elses projects.
reiser4 developers were about to fulfill all requirements to commit it to mainline kernel, what happened to these plans?
A big flamewar happened, which ended when the code reviewer said “Well, screw you, I’m not going to review your code anymore. Find someone else.” Since then, I haven’t heard anything from either side.
Funny… obviously the linux guys think they have all the leverage. I rather think they are wrong.
I think Reiser4 is something so amazing (or at least hyped to be so) that enough people want it, to make it worth treating exceptionally.
I’m actually now at a point where I’m getting progressively irritated with the Linux devs for not doing more to include Reiser4. Mind you, I’m running it under linux with patches… but stil.
Yes, Hans Reiser may not be the pal you want to first call when you have your next play-date coming up… but for heaven’s sake grow up. Most people that dislike Hans appear to do so less because he’s arrogant, but because he is smarter than them on some topics, and Hans wasn’t afraid to say it loud and clear.
Urgh. ;-(
I think Reiser4 is something so amazing (or at least hyped to be so) that enough people want it, to make it worth treating exceptionally.
God, just because “it’s reiser4” doesn’t means they shouldn’t address the problems
Most people that dislike Hans appear to do so less because he’s arrogant, but because he is smarter than them on some topics
I won’t comment on this…
Hmm Hans is that you? If it is I just want to say that I do think you’re learning how to play nice with other kernel developers and I hope you keep it up. Name calling doesn’t do anything so let’s all play together and have fun. OK great.
“I think Reiser4 is something so amazing (*****or at least hyped to be so*****)”
Ding ding ding ding!!!
Whether or not it really is worthy, the reason “enough people want it” is because of the hype. Most of the users clamoring for it don’t know enough to be able to make a good judgement, they are motivated by hype.
Let the kernel devs makes their call. They are a lot more qualified to do so than the folks who keep wondering why it isn’t in.
I think there are a lot of pepole who likes Reiser4 because they understand the potential of the new namespace model + plugins system.
I also think that there are an even bigger number people who just can’t understand the possibillities of this new platform.
Let the kernel devs makes their call. They are a lot more qualified to do so than the folks who keep wondering why it isn’t in.
I think just about everybody can see the potential of Reiser 4’s model, especially when it comes to things like namespaces.
The sole reason why some devs are fairly hostile to it is because they can see the end of their filesystems – it’s about a question of ego. They haven’t looked into the future and planned ahead. Hans quite obviously has.
While part of it might be ego, I think the majority just think that the current file systems are good enough. And they wonder why anyone would want to do things in such a different way. Kind of a “If it ain’t broke, don’t fix it” attitude. Meanwhile Hans sees that everyone accepts Reiser3, which he believes to be inferior in every way, and so he gets upset when people question why he’s changing things.
the current file systems are good enough.
and 640k is enough for everyone, and the world will only ever need one or two computers.
please….
Let’s be fair: Architectures and designs always last longer than a finite amount of resources is going to. The devs think traditional file systems will scale up as they always have and wonder why Reiser is fiddling with so many things that file systems are “supposed” to leave alone. They just don’t see the upside.
Not that I think they’re right…
Yet, it’s the reality. For many people, computer data is priceless. For enterprises, it’s a question of survival. Under these circumstances, anyother with some common sense would rather play safe than trying the new bling-blings that could potentially screw his data up.
Now, we need some people to test the new stuff, but the average Joe won’t risk himself unless necessary. That was his point.
I think the majority just think that the current file systems are good enough.
No, they’re not. You always need to try and keep pushing. A filesystem is afterall, a storage place. Current filesystems are as primitive as it gets.
How come this post was modded down? It just states the truth. If you don’t believe me, then look it up on kerneltrap.org.
It seems to me that both sides in this argument were acting a little bit entitled, but I imagine they would both point to previous “discussions” to support that the other guy started it first.
I believe they missed the feature freeze deadline for Linus’ new development cycle. After the first 2 weeks of merging during the development cycle only bug fixes and minor improvements go in.
R4 did not make it into mainline because it really is not quite ready yet. Hans ego is causing no end of delays for those people who want R4 to go mainline. I will admit I am looking forward to the day R4 *IS* ready for mainline inclusion. Until then I will simply keep plodding along with good ole XFS
Peace
…forgive me, if this is common knowledge, but has the “Hi-memory” problem been fixed in the Linux kernel? I heard somewhere that you had to recompile the kernel if you had > 1GB of RAM to support that much memory…but I’m not sure if this is true.
That’s not a problem. It is a compile time option. In make menuconfig, you select the memory limit (1 GB, 4 GB, 64 GB….patched kernels go higher I believe). Ubuntu ships in its repos a 386 kernel (limit of 768 MB of RAM for some odd reason) and a 686 kernel (limit of 4 GB if I’m not mistaken).
“Add /proc/$PID/smaps: This file will shows how much memory is resident in each mapping. Useful for people who want to perform memory consumption analysis”
It’s excellent! No more confusion about cache memory.
Dear Eugenia,
Don’t you mean “comprehensive changelog”
…a 17 year old Dutch kid
http://dictionary.cambridge.org/define.asp?key=15752&dict=CALD
i want it ready for inclusion into the big-three’s april distro release.
waiting……………..
“Add /proc/$PID/smaps: This file will shows how much memory is resident in each mapping. Useful for people who want to perform memory consumption analysis.”
Thank you.
Thanks for 2.6.14 Linux kernel developers!
FYI:
http://en.wikipedia.org/wiki/Comparison_of_file_systems
Filesystems which only take care for the metadata are really not on the top of my list to put in production use. My *personal* favorite based on safety first is ext3, next would be vxfs on Solaris (out of scope) but both XFS and Reiserfs caused dataloss when we used it on our (I must say older) fileservers. YMMV but i’am looking forward to ext4 (extents/multiblock allocator/delayed allocation).
I’d recomend people to read http://www.9con.org/rml/servers.pdf to see wat v9fs/9P can do. Also peek at the various plan 9 papers – these things are quite so neat.
(atleast in comparison with FUSE)
reiser4 still not in?
By Anonymous on 2005-10-28 11:28:10
reiser4 developers were about to fulfill all requirements to commit it
to mainline kernel, what happened to these plans?
>
>
Who cares? Reiser4 is pretty much useless overrated crap anyway.
I think there are a lot of pepole who likes Reiser4 because they
understand the potential of the new namespace model + plugins system.
I also think that there are an even bigger number people who just
can’t understand the possibillities of this new platform.
>
>
And then there’s an even bigger number of people who think Reiser4’s namespace model + plugins system is totally stupid idea and will cause nothing but compatibilty problems. It just not worth the hassles involved.
No, they’re not. You always need to try and keep pushing. A filesystem
is afterall, a storage place. Current filesystems are as primitive as
it gets.
>
>
Um…Talk to the people who to *DEAL* with the mess created by fans “LET’S FORCE PEOPLE TO USE THE NEWSEST,LAMEST FILESYSTEM OF THE WEEK” So what if *YOU* won’t be around in a few years to deal with the problems of *RETREVING* the data on what was suposed to be *THE LASTEST AND GREATEST FILESYSTEM KNOWN TO THE HUMAN RACE*.
Ummmm, calm down people.
Claiming that reiser4 wasn’t included in 2.6.14 because it is utter crap and the majority of kernel developers recognize this is just plain wrong.
Claiming that it wasn’t included in 2.6.14 because the majority of kernel developers are protecting their egos is also plain wrong.
Linux is about choice, and thats why reiser4 will eventually get merged into mainline. Even if the new concepts introduced by reiser4 aren’t thought to be useful by some, there is no harm in including it in the main kernel as long as it doesn’t negatively affect other parts of the kernel.
There are many filesystems that are currently in mainline which *I* deem useless, but who cares? I just don’t use them. Filesystem A doesn’t pose a risk to my data if I don’t use filesystem A; likewise reiser4 won’t affect you if you choose not to use it.
This is a silly flame war. When the issues around the current implementation of reiser4 are resolved then you will see it in mainline, until then, you’ll have to wait or patch yourself.
/mike.
Regarding FUSE, what exactly is its aim – is it meant for all filesystems to eventually be put under it? I heard this can be so for both security reasons and stability reasons. Is ext2, ext3, JFS, XFS, etc. available under it?
What about Reiser4 coming into the kernel, will this be going under FUSE?