Slashdot Mirror
Linux 3.0
An anonymous reader writes "In a post to the kernel mailing list, Rob Landley, sitting in for the floating Linus, cracks the whip over what will be in Linux 3.0. His orders are on Linux and main."
← Back to Stories (view on slashdot.org)
Here is a good place to find out about the state of various features...
there are no stupid questions, but there are a lot of inquisitive idiots
Before anyone gets going on it.
/dev/dsp :)
There have been MAJOR features added to this Kernel.
Including
- UML
- New VM
- New Scheduler
- Finer SMP Locking
- At least 2 new Journaled FS (Reiserfs4 and XFS?)
- A new POSIX thread library/API.
Does anyone know if ALSA will be included?
We will finally be able to forget about the 1980's style
--
Matt
This page contains a complete list of every new feature that has gone into 2.5, and other features waiting to be integrated and their status:
http://kernelnewbies.org/status/latest.html
No, this time Linux is correct since the topic is about the kernel.
... distribute GNU/Linux (you would not do much with a Linux distribution).
If you are talking about the Operating System, you should address it as GNU/Linux (same as you have GNU/Mach).
e.g. Debian, SuSE, Redhat,
You must have amnesia RMS, since you learnt us to cite:
GNU is the operating system and Linux is one of its kernels
Genius doesn't work on an assembly line basis. You can't simply say, "Today I will be brilliant."
The feature he's referring to is the ability to treat files also as directories, and it promises to be a majorly cool enhancement to Linux that rewrites one of the most basic assumptions of OS design. The idea is that by improving the power of the filing system layer, and boosting the performance of the FS for small files, the need to have databases layered on top (and even /etc/passwd is a database) is eliminated. This in turn leads to a more powerful OS as that power is made generic, so being available to everything. It's better explained by Reiser himself.
One problem - 2.6/3.0 won't have that ability. What it will have is a special system call reiser4() that Hans can play with. You won't be able to "cat /etc/passwd/mike/group" anytime soon, unfortunately, this kind of major change takes a long time to work its way though the system. The reiser4 call will allow Hans to experiment with the new semantics before we even start to think about merging with the actual kernel.
Why is small file performance so important (this is the area where RFS kicks the ass of, well, pretty much everything else)? Because there are quite a lot of files out there which would actually be better stored as lots of small files. /etc/passwd is one good example, there are others. The reason they aren't currently stored as files is because traditionally filing systems have sucked when you have lots and lots of very small files, and we're talking like perhaps 5 byte files here. Reiser4 has some extremely clever algorithms in it, which mean it's good at small files but also large files too.
Of course, this is just the start of a much bigger picture, that'll see the filing system become something akin to a searchable knowledge store. Unfortunately, it's not going to happen quickly. For starters, if you were to suggest to the maintainer of app foo that they should store their data as lots of small files, they's say "no way, some of my users are on ext3, or xfs, or jfs" etc. Reiser has great vision, but he's not the only player in this field, and I have a nasty suspicion that the goal of exploding out large files into filing system structures could prove to be difficult while other filing systems are prevalent. Let's hope not, eh?