×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Linux Kernel 2.6.32 Released

CmdrTaco posted more than 4 years ago | from the download-compile-reboot-repeat dept.

Open Source 195

diegocg writes "Linus Torvalds has officially released the version 2.6.32 of the Linux kernel. New features include virtualization memory de-duplication, a rewrite of the writeback code faster and more scalable, many important Btrfs improvements and speedups, ATI R600/R700 3D and KMS support and other graphic improvements, a CFQ low latency mode, tracing improvements including a 'perf timechart' tool that tries to be a better bootchart, soft limits in the memory controller, support for the S+Core architecture, support for Intel Moorestown and its new firmware interface, run-time power management support, and many other improvements and new drivers. See the full changelog for more details."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

195 comments

Llacking in terminology. (3, Informative)

c0l0 (826165) | more than 4 years ago | (#30310310)

I'm not perfectly happy with the term "virtualization memory de-duplication". Linux 2.6.32 introduces what is called "KSM", an acronym that is not to be confused with "KMS (Kernel Mode Setting)" and expands to "Kernel Samepage Merging" (though other possibilities with similar meaning have already emerged). It does not target virtualization or hypervisors in general (and QEMU/KVM in particular) alone. KSM can help save memory for all workloads where many processes share a great lot of data in memory, as with KSM, you can just mark a region of memory as (potentially) shared between processes, and have redundant parts of that region collapse into a single one. KSM automagically branches out a distinct, exclusively modified copy if one of the processes sharing those pages decides to modify a certain part of the data on its own. From what I've seen until now, all that's needed to have an app benefit from KSM is a call to madvise(2) with some special magic, and you're good to go.

I really like how Linux is evolving in the 2.6 line. Now if LVM snapshot merging really makes it into 2.6.33, I'll be an even more happy gnu-penguin a few months down the road!

Re:Llacking in terminology. (-1, Troll)

Anonymous Coward | more than 4 years ago | (#30310514)

That's a really nifty idea and shows I amde the right choice in dedicating my life to Linux. I first used linux in college and was blown away by it. Pretty soon, I was delving through old unix books in the library, dreaming about fucking penguins, growing out my beard (as much as I could!) and not showering. The next logical step was a Tux tattoo. But that wasn't enough, so I had my balls cut off. When I see a new Linux release with awesome new features, I know I made the right choice. In fact, I'm considering going all the way and having my cock removed as well.

Thanks Linus and kernel contributors!

Re:Llacking in terminology. (1, Interesting)

Luyseyal (3154) | more than 4 years ago | (#30310690)

But that wasn't enough, so I had my balls cut off.

Laugh all you want, but I know an AIX kernel hacker who did just that.

-l

Re:Llacking in terminology. (0)

Anonymous Coward | more than 4 years ago | (#30313966)

SMIT happens?

Re:Llacking in terminology. (0)

Anonymous Coward | more than 4 years ago | (#30311234)

You sir, have made my day.

Re:Llacking in terminology. (0)

Anonymous Coward | more than 4 years ago | (#30314004)

^^ change "fucking penguins" to "being fucked by Penguins"

There, fixed that for you...

Re:Llacking in terminology. (2, Informative)

1s44c (552956) | more than 4 years ago | (#30310844)

I'm not perfectly happy with the term "virtualization memory de-duplication".

The term is a little nonspecific. However KSM is truly wonderful and I look forward to saving a ton of physical memory over my KVM machines when the kvm/qemu userland tools catch up.

This is already in redhat's virtualization stuff.

HA!! Windows is at version 7 ALREADY !! Version 2? (0, Funny)

Anonymous Coward | more than 4 years ago | (#30311748)

Windows is version 7. That's WAY MORE than linux. Linux suxors !! use old obsolete shit OS, dumasses to the max !!

Re:HA!! Windows is at version 7 ALREADY !! Version (1, Funny)

Anonymous Coward | more than 4 years ago | (#30311900)

But is it?
A 7th version of a crap OS is still crap.

Re:HA!! Windows is at version 7 ALREADY !! Version (1)

mitoyarzun (1428713) | more than 4 years ago | (#30314094)

Windows is version 7. That's WAY MORE than linux. Linux suxors !! use old obsolete shit OS, dumasses to the max !!

I wish I had mod points, I find this funny!

Re:Llacking in terminology. (4, Interesting)

Bert64 (520050) | more than 4 years ago | (#30312186)

I have a system running a 2.6.32-rc6 kernel with KSM and the latest kvm (which includes support for this, but its turned off by default)... Because i run a number of virtual images that boot the same kernel and system libs (different apps ofcourse), it saved me over 1gb of memory on the host.

Re:Llacking in terminology. (1)

ichigo 2.0 (900288) | more than 4 years ago | (#30314088)

How much memory did the images use in total before the change (i.e. how big was the savings in %)?

Of course, every byte is precious as long as it doesn't affect performance, but it would be interesting to know how much more images one can expect to run on one computer. :)

Re:Llacking in terminology. (-1, Flamebait)

Anonymous Coward | more than 4 years ago | (#30310984)

I claim that Linux people are incompetent idiots. Playing games with VM is bad. memory copies are _also_ bad, but quite frankly, memory copies often have _less_ downside than VM games, and bigger caches will only continue to drive that point home.

http://kerneltrap.org/node/6506

kvm and ksm (1)

xming (133344) | more than 4 years ago | (#30311214)

kvm (with a little patch) supports it, running it right now with 5 guests and have 53K pages which are shared. # cat /sys/kernel/mm/ksm/pages_sharing 53714 That's ~200MB for about 1,5GB memory used on the host. Now I can't figured out how many times those pages are shared, so I can't calculated the actual memory saved (it's between 200MB and 4x200MB).

KSM (2, Funny)

svtdragon (917476) | more than 4 years ago | (#30311682)

Linux 2.6.32 introduces what is called "KSM"

WHAT!? I know Linux users are pretty militant (myself among them), but to implement terrorism [wikipedia.org] in the kernel?

Please tell me it's at least built as a *module* by default!

ATI chipsets (1)

zoward (188110) | more than 4 years ago | (#30310366)

2.6.32's KMS and R600/700 improvements are expected to give a huge 3D performance boost to the open source ATI drivers - can't wait to test this!

Re:ATI chipsets (1)

Ritz_Just_Ritz (883997) | more than 4 years ago | (#30310426)

I'm excited about the ATI improvements making it into the kernel too. Wonder if Ubuntu Karmic will pick up the new kernel after some testing?

Re:ATI chipsets (2, Informative)

Anonymous Coward | more than 4 years ago | (#30310612)

No, as Ubuntu Releases are version-stable, and backport security fixes only (Firefox being the exception of that rule). You may install the kernel from the mainline kernel PPA though: http://kernel.ubuntu.com/~kernel-ppa/mainline/ [ubuntu.com]
Just fetch the .deb that fits your architecture, and install it via `sudo dpkg -i /path/to/your/downloaded/archive.deb`.

Re:ATI chipsets (0)

Jojoba86 (1496883) | more than 4 years ago | (#30310484)

Superb! I've had my laptop for 2 years and now may finally be able to get 3D graphics working without a major headache.

Re:ATI chipsets (1, Interesting)

L4t3r4lu5 (1216702) | more than 4 years ago | (#30310970)

You're modded funny, but this is why I use Windows. Since I moved into my own house and can put cabling where I want (negating the horrific experiences I've had with wireless networking), 3D graphics issues are the only thing stopping me migrating to linux.

Re:ATI chipsets (2, Informative)

erko (806441) | more than 4 years ago | (#30311558)

If you're ok with not-so-open drivers, nvidia 3D cards have worked for years. I am waiting for quality open source 3D linux drivers, but until then, at least 3D can and has worked reliably on linux. (the nvidia-settings tool is reasonable enough that you generally don't need to edit config files)

Re:ATI chipsets (1)

Jojoba86 (1496883) | more than 4 years ago | (#30314214)

I don't know why I was modded funny or you were modded troll, I was being serious. I'm not a complete linux n00b but I've never got my ATi card (R600) working with 3D acceleration, I'm lucky to get smooth 2D graphics. The current version of openSUSE completely locks up after installation due to the graphics driver. For hardware 2 years old it shouldn't be this hard, but good job to those working on this and ATi for opening up the specs.

Re:ATI chipsets (1)

Doug Neal (195160) | more than 4 years ago | (#30310656)

2.6.32's KMS and R600/700 improvements are expected to give a huge 3D performance boost to the open source ATI drivers - can't wait to test this!

This is indeed excellent although it needs to be backed up by support from the X driver. Currently I am running Ubuntu Karmic on a Radeon HD 3600 series card (RV635, which counts as an R600 series - quite confusing) and 3D support sucks. Both the "radeon" and "radeonhd" drivers only have basic support for these chips - desktop effects don't really work.

I was using the fglrx driver on Jaunty, which worked OK, but it seems to be getting worse with every release. In Karmic it was so broken I just gave up on it. It seems to play a lot better with Compiz/GNOME than with KDE for some reason.

Re:ATI chipsets (2, Informative)

RubberDuckie (53329) | more than 4 years ago | (#30312078)

The Fedora team has backported the KMS and R600/700 improvements to FC12, which I've been running for a few weeks now. While it's better than nothing, 3d performance still has a way to go. The performance of my old Heretic II game is still unacceptably slow.

The ATI drivers usually took the sacrifice of a goat to get them to work, but their performance was far superior. Too bad ATI won't support recent releases of Fedora.

Re:ATI chipsets (2, Informative)

bcmm (768152) | more than 4 years ago | (#30314050)

I've been using the RCs of this kernel, and the Radeon r600 support is already much faster and more stable than fglrx.

Does it Fix XKCD 619? (5, Funny)

sheepweevil (1036936) | more than 4 years ago | (#30310372)

All of these features are cool and all, but does it solve the well-known XKCD 619 [xkcd.com] bug?

People work on the "easy" problems (5, Interesting)

Fished (574624) | more than 4 years ago | (#30310506)

Like the strip, and it raises a valid point. The bottom line is that kernel development advances more quickly than user interface and applications for the same reason that physics advanced more quickly than say ... psychology. That is, because developing a faster kernel is a much easier problem than developing a fun, usable desktop environment. It's easier to write, easier to test, and easier to debug. People tend to gravitate towards problems that they think they can solve--and ignore the problems they don't understand or don't want to deal with.

Personally, I think that the best way forward for Linux on the desktop would be to take GNUstep to the next level. There's a LOT of code there already written, and with a bit more work you might be able to have source-level compatibility with Mac OS X--which would give you access to a bunch of commercial apps. And, most importantly, the ability of the OpenStep API to produce a world class desktop--best in the world in fact--is proven. After 10 years, I don't think that either KDE or GNOME have really done all that much for Linux on the desktop... it's time to try a different approach.

Of course, I'm just kibbitzing, not bringing code. So what right do I have to say anything?

Re:People work on the "easy" problems (2, Insightful)

tulcod (1056476) | more than 4 years ago | (#30312068)

Looks like you didn't get your psychology right. The problem is that creating a desktop environment is, in fact, much /easier/ to create than it is to enhance the kernel, and that makes it extremely boring. Desktop environments are trivial, but dull, to make. They are a perfect example of a job you should be getting paid for.

Re:People work on the "easy" problems (2, Insightful)

Anonymous Coward | more than 4 years ago | (#30312312)

You are confusing tough (challenging) with tough (laborious).

Re:People work on the "easy" problems (1, Insightful)

suggsjc (726146) | more than 4 years ago | (#30312132)

People tend to gravitate towards problems that they think they can solve--and ignore the problems they don't understand or don't want to deal with.

I think that should have read

Engineers tend to gravitate towards problems that they think they can solve--and ignore the problems they don't understand or don't want to deal with.

Re:People work on the "easy" problems (1, Insightful)

Brian Gordon (987471) | more than 4 years ago | (#30312202)

Yesterday I started xmoto while a video was playing and my system slowed to a crawl. I could move the mouse at a frame every few seconds, but nothing else responded, even trying to change to a virtual console and zapping X.

I don't know who's to blame but I do know that this wouldn't happen to a Haiku or SkyOS user. I'm tired of the Linux kernel; it's really not that great. Everyone seems obsessed with C, going as far as to spawn these kind of monstrosities [wikipedia.org] just to force modern features into a traditional platform. Give me a stable microkernel with user-mode graphics so the above bug can never happen. Don't break it every few months and fix it later like Linux.

Maybe we just need a systems technology reboot. So much of GNU/Linux is just horribly broken and needs a sanity check, particularly desktop environment stuff. We can probably do a much better job if we start over.

Re:People work on the "easy" problems (2, Insightful)

Anonymous Coward | more than 4 years ago | (#30313714)

what do you propose? to rewrite the kernel in python? sorry, but something needs to run on the hw itself eventually, nevermind that the language used has little to do with your complaints. User mode graphics are ok for basic desktop use, but forget it if you want decent performance for 3d.

do you know any skyOS or haiku users? I don't.

Re:People work on the "easy" problems (2, Insightful)

DragonWriter (970822) | more than 4 years ago | (#30312220)

Personally, I think that the best way forward for Linux on the desktop would be to take GNUstep to the next level.
[...]
After 10 years, I don't think that either KDE or GNOME have really done all that much for Linux on the desktop...

Purely technical solutions to marketing and promotional problems rarely work, so its unsurprising that GNOME and KDE have done much for Linux on the desktop, since their marketing and promotional efforts are pretty minor. Of course, switch technical approaches to focus on GNUstep has the same problem.

And, most importantly, the ability of the OpenStep API to produce a world class desktop--best in the world in fact--is proven.

That the Mac OS X desktop is "best in the world" is a subjective statement on a matter of taste, not a "fact".

In terms of facts, on the marketing and promotional end where Linux has been unsuccessful, Mac OS X has been more successful, though far from as successful as Microsoft Windows.

Re:People work on the "easy" problems (3, Insightful)

shutdown -p now (807394) | more than 4 years ago | (#30312350)

That is, because developing a faster kernel is a much easier problem than developing a fun, usable desktop environment.

I disagree, it's not an easier problem. It is, however, a much more interesting problem to solve, especially to skilled hackers.

One other aspect here is that the target audience is bigger for the kernel. Desktop uptake is still very low, but kernel is used by any device that runs Linux, whether it's a router, a smartphone, a server, or a netbook. This has a side effect of kernel hacking being better financed than desktop development, as there are more commercial players interested specifically in the kernel, who couldn't care less about KDE or Gnome.

Re:People work on the "easy" problems (1)

abigor (540274) | more than 4 years ago | (#30312986)

Very true. Desktop Linux is a bit player when compared to the overall use of Linux, and it's truly a hobbyist's domain.

Re:People work on the "easy" problems (1)

theCoder (23772) | more than 4 years ago | (#30312504)

...developing a faster kernel is a much easier problem than developing a fun, usable desktop environment.

While I agree with tulcod's response -- kernel development is usually much harder than desktop development. However, there is one important difference. A faster kernel is a measurable goal. While you might be able to make a "fun, usable desktop environment" for a single person, and maybe even for a good percentage of the population, you will never, ever satisfy everybody. Half the people want more options and more control and half want a simpler, less cluttered interface. Some people want freedom, others want to lock it down. Some people want blue, others want brown. Some people want menus, others want icons. If you're doing your job well, you can compromise enough to make everyone satisfied, if not completely happy, but that's really hard to do. A faster kernel seems easy by comparison.

Personally, I think Gnome is going too far down the simplification road. Every release it seems they take away more features and options. This last they struck at GDM (the login screen). Before that, they nerfed session management. A few releases earlier they took away screen saver control. And I'm still annoyed that I can't have different backgrounds on different desktops, and I that's been broken since Gnome 2.0!

Of course, I'm just kibbitzing, not bringing code.

Heh, agreed, same here :) Maybe one of these days Gnome will push me over the edge and make me write my own WM.

Re:People work on the "easy" problems (2, Interesting)

javilon (99157) | more than 4 years ago | (#30312766)

Well, GNOME and KDE ( I prefer one of them but it is not relevant to this post ) have done lots for Linux on the desktop. I have been running it for a number of years because I find it more pleasant to use than Windows. And I am not alone.

And the millions of people using it are doing so against active attacks from a number of organizations. Mainly closed software companies, and also (mainly in the past) political organizations and governments.

Re:People work on the "easy" problems (0)

Anonymous Coward | more than 4 years ago | (#30313794)

"The bottom line is that kernel development advances more quickly than user interface and applications for the same reason that physics advanced more quickly than say ... psychology."

Wow!! I guess, kernel development has nothing to do with UI in same way as physics have nothing to do with psychology. So I guess that analogy, being a double negative, is correct. Just wow.

The only thing in common between psychology and physics is you can call both science if you stretch the definition of science. In same way, kernel and UI are as similar since they both generally run on a given computer system.

"source-level compatibility with Mac OS X - which would give you access to a bunch of commercial apps"

No it would not. You are looking for ABI compatible, not source-level compatible (or even API compatible). And who the hell would want to duplicate the nightmare in OS X programming where Apple couldn't even decide if they were going to go with Carbon or Cacoa for 6t4-bit? Then of course, they axed one in-spite of what they were saying previously.

    http://labs.trolltech.com/blogs/2008/03/03/qtmac-cocoa-port-alpha-released/

"After 10 years, I don't think that either KDE or GNOME have really done all that much for Linux on the desktop... it's time to try a different approach."

Please, entertain us. Go on, what new UI paradigm have you managed to come up with and why haven't I heard of it? Or is it Microsoft's fault?

"Of course, I'm just kibbitzing, not bringing code. So what right do I have to say anything?"

Exactly. It's just more whine from people that do nothing. Have you ever thought that people run windows is because that's all they know and because 3rd party apps come for Windows? And 3rd party apps don't come for Linux because there isn't enough market share. And there isn't enough market share because there is no 3rd party apps for Linux.

Re:People work on the "easy" problems (3, Informative)

bcmm (768152) | more than 4 years ago | (#30314172)

You're missing the bit where Flash is closed-source and the people that want it to work properly can't make it happen, whereas the people who can make it work don't want it to happen.

Yeah, that is fine and all but the big question is (0)

Anonymous Coward | more than 4 years ago | (#30311552)

Does it run Linux?

Btrfs: kill off ext# please! (2, Interesting)

Anonymous Coward | more than 4 years ago | (#30310374)

I'm glad to see Btrfs improving so rapidly. I hope popular distros start including support for it, but more importantly, start using it as the default filesystem.

It's time for the ext-based filesystems to die. They are a technology that was obsolete a decade ago.

ReiserFS was set to kill them off, but unfortunately found another victim first... JFS and XFS only work well in certain high-end niches. But Btrfs is much better as an all-around filesystem, which is why it has a chance to finally put an end to ext-based filesystems.

Re:Btrfs: kill off ext# please! (1)

gzipped_tar (1151931) | more than 4 years ago | (#30310556)

Fedora 12 already supports btrfs as an experimental feature, but there's still a long way to go in the near future.

And what about Reiser4?

Re:Btrfs: kill off ext# please! (1)

mcgrew (92797) | more than 4 years ago | (#30311576)

And what about Reiser4?

She's dead, Jim.

Re:Btrfs: kill off ext# please! (2, Interesting)

gzipped_tar (1151931) | more than 4 years ago | (#30311626)

Well joking aside, I heard rumors that Reiser4 is being considered by Linux devs and likely to be merged in the stable kernel soon. Any news on that?

Re:Btrfs: kill off ext# please! (0)

Anonymous Coward | more than 4 years ago | (#30312572)

Fedora 12 is not a suitable system for use. I tried it recently, and the installer crashed before even getting to the disk partitioning screen. This was on a 3-year-old system that has been running Slackware and then Ubuntu its entire life, so I'm pretty sure the problem is with Fedora.

Re:Btrfs: kill off ext# please! (1)

ProfMobius (1313701) | more than 4 years ago | (#30313564)

Fedora12 is perfectly stable. Using it right now on 3 computers. Two of them are Intel based, one is AMD based. And they have all three of ATI, NVidia and Intel graphic chips. Didn't have any problem at all and the installer is quite stable.

Re:Btrfs: kill off ext# please! (1)

diegocg (1680514) | more than 4 years ago | (#30313748)

Not that long, in my opinion. I've been using Btrfs as my root filesystem (except for /boot and /home, but anyway) since the day after Fedora 12 was released (two weeks). I haven't had any problem at all with it - no hangs, not even a simple printk low-periority warning. It seems to be quite stable - i'm not surprised that they are considering (according to LWN) declaring it "ready for early adopters" in the next kernel release.

Re:Btrfs: kill off ext# please! (1)

moosesocks (264553) | more than 4 years ago | (#30310578)

How does Btrfs compare to ZFS? I've been using ZFS-on-FUSE, and absolutely love the incredible data integrity and volume management features that it provides. The new support for deduplication will also be wonderful once implemented.

Of course, the performance and the idea of trusting my data to FUSE leave much to be desired.

(On the downside, I'm peeved that Btrfs is GPL licensed, which will prevent it from becoming "the one true filesystem" from here on out. Windows users will be stuck with NTFS, Linux users will get Btrfs, Mac users will get whatever apple is secretly working on, and the BSD/Solaris camp will get to keep ZFS. None of them will be compatible, and FAT32 somehow remains the only viable option for removable media.)

Re:Btrfs: kill off ext# please! (2, Insightful)

Abreu (173023) | more than 4 years ago | (#30310920)

What prevents other, non-GPL operating systems from using Btrfs?

Writing drivers for a filesystem is not a "derivative work" is it?

Re:Btrfs: kill off ext# please! (1)

Fished (574624) | more than 4 years ago | (#30311568)

It wouldn't be a derivative work to write a driver if you did so from scratch. But to do so from scratch is... shall we say a "non-trivial problem." It would be better to have a BSD licensed filesystem that could be relicensed as appropriate--GPL for linux, proprietary for Windows and Mac, BSD for .. ahem ... BSD, etc.

Re:Btrfs: kill off ext# please! (1)

LOLLinux (1682094) | more than 4 years ago | (#30311978)

Why would it need to be under a proprietary license for Windows? BSD code can live perfectly fine along side of the proprietary code in windows.

Re:Btrfs: kill off ext# please! (2, Insightful)

Abreu (173023) | more than 4 years ago | (#30312064)

Nevermind that, I think that the whole objection to a BSD license in this case would be that such a license could not prevent MS (or Oracle, or Apple) from "embracing and extending" the whole filesystem so that the "standard that everybody uses" is no longer free

Re:Btrfs: kill off ext# please! (2, Insightful)

Bert64 (520050) | more than 4 years ago | (#30312388)

But even assuming ms would use an open filesystem, they would want to alter it to make it incompatible with everyone else's implementation... And they can't do that very well if people are able to download the source.

Re:Btrfs: kill off ext# please! (0, Troll)

LOLLinux (1682094) | more than 4 years ago | (#30312578)

But even assuming ms would use an open filesystem, they would want to alter it to make it incompatible with everyone else's implementation...

So what? People take GPLed programs and make incompatible forks with it often. Why is it wrong if Microsoft wants to do the same with BSD code it would want to use?

Re:Btrfs: kill off ext# please! (1)

Urkki (668283) | more than 4 years ago | (#30311872)

What prevents other, non-GPL operating systems from using Btrfs?

Writing drivers for a filesystem is not a "derivative work" is it?

How good, accurate and up-to-date is the specification of btrfs?

If only real, accurate "specification" is the source code, then it's damn hard to create a compatible and reliable new implementation from scratch. File systems are complex, concurrent (meaning many files being accessed simultaneously) and performance-critical as well as reliability-critical. Getting it right is hard, while getting it wrong is bad, so there needs to be really good reasons to even try to do it, instead of using something that already works.

This is especially true while development is still continuing (as is case with btrfs).

One file system to rule them all (2, Interesting)

DrYak (748999) | more than 4 years ago | (#30311200)

On the downside, I'm peeved that Btrfs is GPL licensed, which will prevent it from becoming "the one true filesystem" from here on out.

Well, ZFS itself has a GPL-non-compatible license, but that doesn't prevent it from being usable in Linux as an independent user-space process through FUSE.
The same approach could be imagined under non-GPL-compatible OS: have the GPL implementation as a standalone userspace daemon.
(Which is not a bad idea - give more freedom to upgrade)

Windows users will be stuck with NTFS

No matter what. Even if some kernel guru released a tri licensed LGPL/BSD/Proprietary perfect file system, Microsoft will still be using NTFS and promising WinFS soon for whatever the next version of Windows is.
They have a strong case of NIH-Syndrome.

None of them will be compatible, and FAT32 somehow remains the only viable option for removable media.)

For removable media, UDF could be a good candidate too. It's getting widespread availability, specially since Microsoft added support for writing on Vista and Win7.

Re:One file system to rule them all (-1, Troll)

Anonymous Coward | more than 4 years ago | (#30311364)

They have a strong case of NIH-Syndrome.

A hilarious statement coming from a Loonix turd.

Re:Btrfs: kill off ext# please! (1)

sim82 (836928) | more than 4 years ago | (#30311738)

None of them will be compatible, and FAT32 somehow remains the only viable option for removable media.)

So in one of your possible ideal worlds, I would have to use ZFS on a 2GB SD card? Sounds interesting.

Re:Btrfs: kill off ext# please! (2, Insightful)

Bert64 (520050) | more than 4 years ago | (#30312472)

I would prefer to use EXT2 on small sdcards, so as to support filesystem permissions...
Or how about something like jffs2 - a filesystem actually designed for flash media.

FAT32 is a pretty garbage filesystem, and it's patent encumbered, an open filesystem without the weaknesses of fat32 and which is supported everywhere would be extremely useful. It won't happen tho so long as MS have sufficient market share to bury any open filesystem, they want people locked in to their proprietary patented filesystems and use their weight to prevent any other fs from gaining traction.

Re:Btrfs: kill off ext# please! (0)

Anonymous Coward | more than 4 years ago | (#30313998)

I don't think full UNIX file ownership and permissions make a lot of sense on removable media, because there's no direct equivalence of user ids between different systems. Unless you go to great lengths to ensure there is. It'd be nice if Linux had a filesystem specifically designed for removable media, that encoded stuff like read-only and executable flags, but didn't include ownership.

Re:Btrfs: kill off ext# please! (1)

Bert64 (520050) | more than 4 years ago | (#30312318)

MS will never support a filesystem they don't control unless forced to, and certainly won't make it the default...

BSD, Solaris and OSX all support UFS, as does Linux.... Linux also supports the hfs+ filesystem currently used by OSX, not sure if bsd/solaris do but there are bsd licensed drivers for it so no reason not to.

multiplement implementations (1)

OrangeTide (124937) | more than 4 years ago | (#30312718)

If Btrfs's design proves to be good, there is not a reason why there can't be both GPL and non-GPL implementations written for it. I think one of the things for universal filesystem to be successful is to have something that has more than one implementation.

FAT32 will have to die in the market when people get sick of files over 2gb getting truncated. The end is near for FAT.

Re:Btrfs: kill off ext# please! (2, Insightful)

phantomcircuit (938963) | more than 4 years ago | (#30313554)

I've been using ZFS-on-FUSE

Are you insane? You probably just cut the performance of your drives by 90%.

Of course, the performance and the idea of trusting my data to FUSE leave much to be desired.

Oh sorry you're informed AND insane. :P

Re:Btrfs: kill off ext# please! (1)

reub2000 (705806) | more than 4 years ago | (#30313574)

I highly doubt we'll be seeing Microsoft make any effort in terms of impliment anything that would make it play nice with Linux or any other operating system.

Re:Btrfs: kill off ext# please! (0, Offtopic)

psm321 (450181) | more than 4 years ago | (#30310712)

I'll stick with my tried-and-true ext3. Tried reiserfs several times with lots of problems (unrelated to the creator's other problems). Tried jfs and had massive corruption and freezes that would lock up most of the kernel. Never had a problem with ext2 or ext3. Given the fact that everybody else also seems to think that reiser, jfs, etc. are also great alternatives, it makes me wary of btrfs.

Re:Btrfs: kill off ext# please! (-1, Flamebait)

Anonymous Coward | more than 4 years ago | (#30311166)

Given the fact that everybody else also seems to think that reiser, jfs, etc. are also great alternatives, it makes me wary of btrfs.

Have you ever thought that the problem might be you? Think about it - if you're the only one having problems, when *everybody else* isn't, chances are it's your own incompetance causing it.

Re:Btrfs: kill off ext# please! (1)

von_rick (944421) | more than 4 years ago | (#30311202)

Since EXT2/3 and recently EXT4 have some level of popularity among users, there are applications in Windows to mount them at startup if you are using a dual boot system. There wasn't anything wrong with ReiserFX or JFS or any other filesystems that I tried - but EXT# was the only one which could be easily used under Windows.

Big speedups for media workstations.. (4, Informative)

delire (809063) | more than 4 years ago | (#30310414)

This 'Per-backing-device writeback' is pretty significant. I'm sure the feature film and database industries will love it especially:

The new system has much better performance in several workloads: A benchmark with two processes doing streaming writes to a 32 GB file to 5 SATA drives pushed into a LVM stripe set, XFS was 40% faster, and Btrfs 26% faster. A sample ffsb workload that does random writes to files was found to be about 8% faster on a simple SATA drive during the benchmark phase. File layout is much smoother on the vmstat stats. A SSD based writeback test on XFS performs over 20% better as well, with the throughput being very stable around 1GB/sec, where pdflush only manages 750MB/sec and fluctuates wildly while doing so. Random buffered writes to many files behave a lot better as well, as does random mmap'ed writes. A streaming vs random writer benchmark went from a few MB/s to ~120 MB/s. In short, performance improves in many important workloads.

Is this a hoax, or what? (5, Funny)

Sockatume (732728) | more than 4 years ago | (#30310446)

rewrite of the writeback code

So you didn't de-lace the interace or uncabulate the turboencabulator? I'm now about 85% convinced that the open source movement is just making shit up.

Re:Is this a hoax, or what? (0)

Anonymous Coward | more than 4 years ago | (#30310852)

sure it can do all that stuff... but does it run linux?

does KSM mean the death of Xen? (1)

trybywrench (584843) | more than 4 years ago | (#30310470)

If KSM puts the KVM module on par with Xen in terms of performance then I think the writing is on the wall for Xen's demise.

Re:does KSM mean the death of Xen? (4, Informative)

1s44c (552956) | more than 4 years ago | (#30310976)

If KSM puts the KVM module on par with Xen in terms of performance then I think the writing is on the wall for Xen's demise.

No. Not at all. KSM saves memory but hurts performance. It shares memory across virtual machines to save memory.

Xen can't share memory across virtual machines, it's just not put together like that.

Performance is about identical for KVM and XEN.

Re:does KSM mean the death of Xen? (1)

FlyingGuy (989135) | more than 4 years ago | (#30311884)

Being somewhat ignorant of the inner workings of XEN, VMWare, KVM and the like the very idea that VM's would share memory at all seems rather risky in terms of them being sandboxed from each other. Beside a hypervisor being able to allow many VM's to run basically any OS, it would also seem that there is a security element involved eg: running Windows in a VM and Linux in another and NetWare in yet another the three would not have the ability to know the other were there and therefor be safe from being hacked into from Windows malware or affected by an ABEND ( basically a kernel panic ) from NetWare.

I can see the Hypervisor being able to move each VM's memory footprint around, but why would you desire a VM to mingle memory with another VM, or am I missing some salient fact(s) and or point?

Re:does KSM mean the death of Xen? (3, Informative)

Bert64 (520050) | more than 4 years ago | (#30312544)

Instead of storing multiple copies of the same data in memory, it stores a single read-only copy and points the others to it. If you try to write to it, it traps, creates a new read/write instance which is exclusive to you and then points you at it...

Shared libraries work in much the same way. Shared libraries been implemented pretty securely for many years now.

Re:does KSM mean the death of Xen? (1)

FlyingGuy (989135) | more than 4 years ago | (#30312922)

I grock the lib concept, each program gets it's own data segment and the code is run in a single image ( if you will ) and that conserves memory. Each data area is private to the program unless they explicitly share it through some IPC mechanism.

This is interesting as it seems like a way to write malware. If I wanted to deliberately run the machine into the ground I could just look for those data area's and keep attempting to write to them and force the OS to keep duplicating them over and over again. Now you could do the same thing by just having a program continue to allocate memory for itself, but this seems to a be a way to do so without having anything being able to detect that you are allocating memory on your own, just using the OS as your proxy to eventually suck up all the machine resources.

Re:does KSM mean the death of Xen? (1)

Hatta (162192) | more than 4 years ago | (#30313606)

KSM saves memory but hurts performance.

If I have plenty of memory, can I easily disable KSM?

Re:does KSM mean the death of Xen? (1)

diegocg (1680514) | more than 4 years ago | (#30312532)

Note that KSM also works for Xen.

KVM may not mean the death of XEN, but it has been a long time since it replaced it as the de-facto Linux virtualization system.

You Fail I7... (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#30310530)

escape> them by

KMS (3, Informative)

shentino (1139071) | more than 4 years ago | (#30311084)

Kernel Mode Switching is great except for the fact that all 3 major video card vendors decided to nix VGA console support.

Re:KMS (3, Interesting)

sigjuice (769539) | more than 4 years ago | (#30313186)

So how does one deal with no VGA console support? I know nothing about what is going on in the video card industry. Nevertheless, I find this quite interesting and would really appreciate it if you could provide some more information so a layman like me can understand what this means.

Re:KMS (1)

diegocg (1680514) | more than 4 years ago | (#30314210)

And how is that related to KMS? KMS is about moving mode switching to kernel, which is neccesary even for the most modern 3D cards. And the memory manager that was implemented to make it possible is also neccesary to implement correctly a modern graphic stack.

ATI support (1)

PenquinCoder (1431871) | more than 4 years ago | (#30311340)

Finally?? I mean how long has ATI been open source, and we're just now getting support for the newer R600/R700 devices now?? I hope this kernel release also addresses the issue of the HD audio in the combined A/V R700 chips.

Re:ATI support (5, Informative)

Anonymous Coward | more than 4 years ago | (#30311680)

The 2D specs were released in September 2007. The 3D specs were released in January 2009. Drivers do not write themselves immediately just because the specs are out, it still takes some time. But it's getting there, and they won't go away like the closed drivers will, the moment the manufacturer feels it's no longer profitable to maintain them.

Re:ATI support (1)

PeterKraus (1244558) | more than 4 years ago | (#30312776)

ATI R600/R700 have had 2D FOSS drivers since may, or so. 3D is partially working as well (well enough to let me run Avogadro on my HD4200, but no games). It's just KMS for R600/R700 being pushed into the kernel now.

Re:ATI support (0)

Anonymous Coward | more than 4 years ago | (#30313980)

The developers are also rolling out modernized code for all the radeon chips. So there was more than a little catching up to do. I bet R800 is supported even more quickly. This is on top of releasing a closed source driver.

stable? (0, Flamebait)

burris (122191) | more than 4 years ago | (#30311616)

Lots of new features, I thought the 2.X.Y versions where X is an even number are supposed to be "stable." There isn't even a 2.7 branch.

What i've been most curious about... (1)

pjr.cc (760528) | more than 4 years ago | (#30312236)

Theres not alot of info around about it, but i'm dying to see the new dm-replicator module. Theres not huge amounts of information available about it and bits and pieces have been floating around for a while... it basically looks like something that could replace drbd as a more sensible mechanism of doing replication...

Personally I hope they let it do local replication as well cause the one thing i've always wanted is to replicate my laptops hd onto an occasionally-pluged-in usb disk with the ability to snapshot just the usb disk now and then... That would be fantasic.

time saving makefile (5, Interesting)

inode_buddha (576844) | more than 4 years ago | (#30313706)

I'm very interested in the new make target. Specifically, "make localmodconfig". It seems that this new target will check your current .config, and also check whatever modules are currently loaded. It then creates a new config file which only builds the modules you are currently using. This could be a great time and space saving, as opposed to building everything and the kitchen sink as distros tend to do. It gives you a fairly easy and sane way to truly tweak your kernel to fit your box, or script it to fit a whole bunch of non-similar boxes.

Re:time saving makefile (3, Interesting)

bcmm (768152) | more than 4 years ago | (#30314116)

That's sounds potentially very useful, but beware that if it works the way you're describing it, it could remove, for example, support for USB MSC if your USB stick wasn't plugged in when you did it.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...