Slashdot Mirror
New Features For 2.5 Linux Kernel
An anonymous person writes "The current development version of the Linux kernel is 2.5. At the recent Linux kernel summit, it was agreed to have a "feature freeze" on this kernel by October 31, 2002. Here's a story looking at what's left to be merged before the freeze. Projects most likely to make it into 2.5 (and thus be a part of the next stable kernel, 2.6), include: the reverse mapping VM, the Linux Security Module framework, User Mode Linux and support for filesystems greater than 2TB."
Maybe someone has the username anonymous person?
Yep. http://slashdot.org/~anonymous%20person
So what I'm wondering is, wouldn't it be possible to invent a disk addressing scheme which basically self-extends, so that you would never really need to manually change things to support disk sizes beyond a certain size?
Finishing moving disk-related parameters to 64 bits makes this largely unnecessary. It is extremely unlikely that we'll have to worry about devices with more than 2^63 blocks for a very long time (with 1k blocks, this would be eight [us] billion terabytes).
Having the OS scale block size instead of just using a sane parameter width leads to much nastiness (remember how much fun FAT16 was).
supermount is entirely adequate, IMO. Sure there may be dangers removing floppies, but then again, do we *really* need floppies still? I thought we were over the days where we'd save our documents to 8 different disks and hope one of them worked when we got to work...
The need to mount and unmount CD/DVDs has been one of my pet peeves. Hell, Windoze can detect when a new disk is inserted and even launch stuff (which is annoying but can be disabled). So use the same technique and automount the damn thing. And when the eject button is pressed, catch that and umount. If the Microsoft programmers can do it, it can't be all that hard!
-- Will program for bandwidth
Yes. Serial ATA is going to be BIG once it gets to the marketplace later this year. I have a feeling we'll see it added to 2.5 pretty quickly after release.
I think you might have it wrong...
..feature freeze for the "2.5 kernel"...' instead of ' ..."feature freeze" for the 2.5 kernel...'.
If what you were saying was the case, the writeup might appear more along the lines of '
If you see what I am saying. The emphasis established by putting the phrase "feature freeze" in quotes is suggestive of that particular practice being unusual.
We may need it some day, but figure 64 gig (2^36) is a reasonable hard disk size today. Then assume that hard disk size doubles every year. We won't be running into the 64 bit limit for another (64-36=) 28 years!
By that time all of our computers will be using 256 bit words, or maybe word-sizes won't really exist anymore. Who knows. Certainly Linux will have morphed into something entirely different. It's pointless trying to plan that far ahead.
Also, there is in fact some limit to hard disk size, we just don't know what it will be yet. I have a 10gig drive in my laptop, and really I just fill it up with crap. I don't need half that much room. Until I start saving movies on my laptop I'll never need 80 gig. We'll run into physical limits too at some point.
It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail. - Abraham Maslow
I think it is about time that the LSM (or anything similar) was included in the kernel. When it comes to access control, I think Windows NT/2000 wins hands down against Linux.
I know I am running the risk of being modded down for saying that Win2K is way ahead of linux (or other *nix for all I know) but in the real world of file sharing, we use permissions and auditing quite a lot; these are not always black and white (what linux is currently capable of) permissions, they are often varying shades of grey.
Hopefully, with LSM, this will change even if it is in the future (1 year? 2 years?)
For a good explanation of the LSM, read this from NSA/SELinux
> for a very long time
Let's compute this long time, just for fun. Let's see, we've got to assume a bunch of crap before we can compute a specific time for this. Using data from this and this, let's assume that the current largest hard drive size on the market is 180GB with a doubling rate now at 9 months. (The 80s saw 30% growth annually, 60% in the 90s and 130% now.) Unlike processors, which have been steadily doubling every 18 months thanks to Mr. Moore, it appears that the growth rate itself for storage capacity is doubling every 10 years. Go figure.
Let's use this, blow some hot air and molest these numbers a little bit.
180 * 2 ^ p = 8 billion TB
p = periods of doubling = 36
Using a flat constant growth of 130% this would equal to
36 * 9 = 324 months / 12 = 27 years
Now, we see crossed 2 periods of doubling in growth, but can storage technology really experience growths of 260% or 520% annually. I'd have to say not, so I'll just give up computing the time given the growth of the growth right now. That's an assignment left to the reader -- I'd say it has to do with "e".
Anyhow, the reality is:
1) No one will ever read this comment since the article is so far down on the front page.
2) We'll have quantum computers in 10 years that will use unlimited-bit numbers to access unlimited capacity storage devices.
Ok, I'm all babbled out...