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."

Comments

"An anonymous person writes"

[orthogonal]

Why's he "[A]n anonymous person" and not "an An Anonymous Coward"?

Should I infer something about his identity from this? Should I infer that this means the /. editor knows this person's identity?

Should I cue the X-Files theme song?

Re:"An anonymous person writes"

[Anonymous Coward]

Maybe someone has the username anonymous person?

Re:"An anonymous person writes"

[Anonymous Coward]

Maybe someone has the username anonymous person?

Yep. http://slashdot.org/~anonymous%20person

Re:"An anonymous person writes"

[00_NOP]

X-Files theme song

Song? Ah ha, So there are hidden messages then.

Re:"An anonymous person writes"

[Anonymous Coward]

Good pint, but,

Then wouldn't it have read "Anonymous Person writes"... rather than "An anonymous person"...?

Halfway there...

[Smelly Jeffrey]

I think it's grand that we're already halfway, with this new milestone, to the 3.0 mark. It's great to see development moving along at such a good rate. Finally support for filesystems greater than 2TB, eh? Wow, now I can reduce my pr0n cluster to only 256 machines. Hehe. Keep it up guys.. keep up all the good work.

Linux Needs Kittens (Metaphorically speaking)

[Anonymous Coward]

Linux is bleeding edge in the technical arena thanks to
our super-duper kernel hackers, but we're really lacking
in the "kitten" department. We need to the interface to
be soft, cuddly, and easy to interact with. We have two
of the three thanks to KDE and Gnome, but we still need better
"Kitten Interaction" where the higher level apps provide the verbose,
yet easily used and understood "body language." Much like if we were
playing with a kitten (we can identify what the kitten likes by way of its
behavior and body language).

The fact is, Linux won't take over the world until it has all Three of
the kittens in addition to it's technical superiority. So, please, Slashdot,
when you think of Linux, think of the kittens!

~~~BunnyVomit(NoSpace)

To infinity, and beyond!

[Dirtside]

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? In other words, depending on how big your hard drive is, the addressing method would change to address sectors of a certain size, keeping the need for indexes/tables/whatever down to a certain size, etc.?

Re:To infinity, and beyond!

[Smelly Jeffrey]

Isn't that similar to how the BIOS works with your RAM, and how the rudimentary low level OS interoperates with it? It doesn't index itself beyond the amount of memory you have installed, limiting itself to the actual space available. When you add more memory, or bigger memory, it sets up its tables for that much, and none more. Is that right?

Re:To infinity, and beyond!

[Anonymous Coward]

From what I know as a programmer, but one that's never touched the kernel source code, I would guess that such a system is possible, but the overhead in such a system would be unjustifiable for the majority of situations.

Re:To infinity, and beyond!

[Christopher Thomas]

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).

Re:To infinity, and beyond!

[GroovBird]

Yeah, and 32-bit is more than we'll ever need. Who can imagine 4GB of memory in a machine! We'll never need more than 32-bit in our processors!

or...

640KB is enough for everyone!

see a pattern already?

dave

Re:To infinity, and beyond!

[Anonymous Coward]

As a matter of fact, remember that the BIOS has a limit; you cannot aaddress more than 1024M of memory
on some PentiumIII motherboards, for example.

Re:To infinity, and beyond!

[Alsee]

disk-related parameters to 64 bits makes this largely unnecessary

Right.
2^63 blocks ought to be enough for anybody.

Grin, duck & run

-

Re:To infinity, and beyond!

[nusuth]

Obviously, we might need more than 18,446,744,073,709,551,616 kbytes storage on a non-specialized computer some time in the future. Nobody, incuding original poster, deny that. But it would take a very long time. One thing is we don't need nearly that amount today, the other and perhaps more important thing is it is impossible now. Such storage with a reasonable physical device size would require either a very significant breakthru or several incremental, nevertheless revolutionary, refinements in storage technology.

Harddisk storage space have grown roughly by a factor of ten million in the last 20 years. With the same rate, it would take another 25 years before we need that amount. I'm pretty sure kernel 4.0 will be out long before that.

Re:To infinity, and beyond!

[Ami Ganguli]

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.

Re:To infinity, and beyond!

[Anonymous Coward]

eight [us] billion terabytes

The British switched to the U.S. system of counting several decades ago. Now it's 1 US billion = 1 UK billion.

Re:To infinity, and beyond!

[King of the World]

No no no - anyone suggesting a necessary and reasonable number backed with figures is always laughably naive and I hereby confront you as a wise bearded-weirdy with a BG quote that will rattle you to the very bone...

640KB is enough for everyone!

Yes! Burned! Etc!

Re:To infinity, and beyond!

[Toraz Chryx]

That's a chipset limit, not a bios limit persay.

(I think you were referring to the 512MB limit on i815E mainboards?)

Re:To infinity, and beyond!

[Trevelyan]

wasn't the suposed millenium bug because back in 1970 ppl figured we wouldn't be use that h/w any more, and updated

Re:To infinity, and beyond!

[Anonymous Coward]

No, it's because they figured we wouldn't be use (sic) that s/w any more.

Re:To infinity, and beyond!

[bruthasj]

> 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...

Re:To infinity, and beyond!

[Citizen of Earth]

Keep in mind that there are only 10^80 (2^265) subatomic particles in the universe.

Re:To infinity, and beyond!

[Thing 1]

In other words, depending on how big your hard drive is, the addressing method would change to address sectors of a certain size, keeping the need for indexes/tables/whatever down to a certain size, etc.?

I like this idea. Could be used for memory addressing as well, so you never run out of RAM.

I see it working like this: use a 64-bit dword to store the address (or head/cylinder/sector/etc.). Only use 63 bits. When you run out of room, use the 64th bit to indicate that another 64-bit dword will be used along with the first (making it 126 bits of addressing, since the 64th bit of the second word would be used to denote a third 64-bit dword, which would give 192-3=189 bits, ad nauseum).

We'd never run out of addresses, although there may be a performance hit once we start addressing really large amounts of data.

Looks like Kuro5hin.org is down

[Anonymous Coward]

I guess that fund-raising drive was so successful that Rusty ran off with the money.

Re:My question

[evalhalla]

I believe that 2.9 would be the development version for 2.10, not 3.0. (But I admit that I have no clue on what the dev version for 3.0 would be called.)

Anyway, 3.0 would mean complete rewrite of the code, and I don't think that such a thing is planned in a nearby future.

Re:My question

[Gizzmonic]

You know, sometimes I lie awake at night and wonder about that. God, it makes such difference in my life. If only Linus got to know me...we'd be friends, and we could hang out and play video games. Maybe he'd let me work on the kernel or something. That would just be so coooolllll....

Serial ATA support - why?

[yem]

From the TODO:

Would be nice to have before feature freeze, but most likely 2.7:
...
o Serial ATA support

From serialata.org:

Q13: When does Microsoft plan to support Serial ATA in its OS's?
A13: Serial ATA is software compatible with Parallel ATA and requires no changes to Microsoft operating systems, or any other OS as well.

If this is a drop in replacement for parallel ATA, why is support needed in the linux kernel?

Re:Serial ATA support - why?

[tanksimpson]

Maybe they mean support for add-on PCI card SATA controllers, as opposed to controllers built onto the motherboard. Remember linux also needed special drivers for IDE controllers like the Promise Ultra66.

Re:Serial ATA support - why?

[MrResistor]

Obviously, one can't write a driver for a cipset if one doesn't have the chipset. Either the manufacturers will provide Linux drivers, or we will have to wait until someone skilled gets a card and writes drivers for it themselves.

That's the inherent problem with add-on cards.

My Question: Why Does [s]locate Exist?

[Nailer]

Slocate indexes the contents of the disk. So does the MFT, FAT and whatever the Linux equivalent is called (I'm surprised I don't know this, but I don't).

Would it be possible to organize that information in a manner so that it could be used to find / locat files in a very quick and efficent manner? I guess what I'm looking for is indexes which are updated on writes / unlinks. Would this be possible? Would there be drawbacks, and could they be counteracted? If someone with more skill than I implements this we'd all save a bit of time.

Re:My Question: Why Does [s]locate Exist?

[Anonymous Coward]

It would help if you wrote your comment in a way that we had a clue what you were saying.

Re:My Question: Why Does [s]locate Exist?

[jrfonseca]

Both alocate and the FS table index the content of a disk but with different purposes _and_ structures.

FS has a tree alike structure (which maps directly to the directories and files) to easily get from a file name to its position on the disk.

[s]locate has progressive encoding (from their website http://www.geekreview.org/slocate/) which maps from name fragments to their complete name.

Another difference is that slocate database structure is difficult to update, and you wouldn't want to do that everytime you rename/add/delete a file...

Note that I'm not an expert, and this is just my (incomplete and perhaps even wrong) understanding .

Re:My Question: Why Does [s]locate Exist?

[Nailer]

Thats for your post, but I still don't think that there any reason not to give a file a place in more than one location - a heirarchical tree and an alphabetic sort. I can't see it as being too expensive either - and you always exclude /var/tmp if you were worried about that kind of thing...

Re:My Question: Why Does [s]locate Exist?

[uchian]

Thats for your post, but I still don't think that there any reason not to give a file a place in more than one location - a heirarchical tree and an alphabetic sort. I can't see it as being too expensive either - and you always exclude /var/tmp if you were worried about that kind of thing...

Heres a quick way to compare the functionality of the file system structures versus locates database.

let's say we want to search for documents on the computer.

File system :

find / | grep ".doc"

Locate database :

locate ".doc"

Compare the speed. Locate is incredibly quick, especially on large harddisks.

Now compare creating a new file in the file system :

echo "hello" > test

to updating the locate database so that it can find the file quickly :

updatedb

(I think you need to be root to perform this).

Here the filesystem wins easily.

Unfortunately, like most computer algorithms, there is no "perfect" solution to searching for and adding files : if you optimise for searching speed, then update speed suffers. If you optimise for access and updating, then searching suffers. You can optimise for both (by having both the file system and locate), but you have gained better performance at the penalty of storing the information twice and hence taking up more space and greater code complexity - you need the file system code and locate, rather than just one or the other.

Another way to look at it : why does your favourate computer textbook, or a world atlas contain an index? I mean, that's just duplication of information already on the map!

Of course, it's because it's easier to find the place you are looking for in the index, but the map is actually useful for figuring out how to get there...

Re:My Question: Why Does [s]locate Exist?

[Nailer]

Sign, nobody's still answered the question. I assume it *is* possible, but nobody's been bothered. Obviously your comparison isn't very fair: you recreated the updatedb index from scratch, that would be unnecessary in the suggested system.

Re:My Question: Why Does [s]locate Exist?

[Anonymous Coward]

I'd been in linux a while though does not think I'm really qualified for this thing.. however I'll give it a shot anyways:

sgi has developed a software called fam ( and imon) http://oss.sgi.com/projects/fam/

this piece of software contains of a daemon and a patch to the kernel (which hasn't gotten in yet since linus thinks it's messy written if my mind serves me correcltly)

fam talks as a middleman about the creation / removal of files for processes which want such information...

eg. the new nautilus uses this function

I guess, creating a slocate database after installation and then running some slocate-daemon would not require much effort of writing nor using much of system resources.

I find it a splended idea!

Cheers /Thomas

Re:My Question: Why Does [s]locate Exist?

[Anonymous Coward]

Yes it would be possible. The only drawbacks I can think of are that an extra write is needed for every add/delete/rename of a filename and the possibility that the two may become out of sync.

The first problem really isn't much of a problem since it's not such a common thing that it needs to be lightning fast optimized.

The second problem can easily be fixed by rebuilding the index periodically (like you do now anyways for slocate).

We'd have to use a different indexing system then slocate (or change it, but I'm not sure how feasible that would be) because it is not optimized for adding/removing single entries. It assumes you will be building the index everytime.

Re:My Question: Why Does [s]locate Exist?

[brsmith4]

I thought that journalized file systems, ext3, JFS, Reiser, XFS, already did this. They are all, pretty much, linux standards, so to speak.

Re:My Question: Why Does [s]locate Exist?

[oliveloaf]

Even better, if there was a service that monitored new files, and kept track of files that were deleted, you could easily locate files without manually updating any database, and it would be simple to uninstall programs that didn't come with a "make uninstall" option, as well as, if you forget to run checkinstall before installing a program.

Re:My Question: Why Does [s]locate Exist?

[psamuels]

Sign, nobody's still answered the question. I assume it *is* possible, but nobody's been bothered.

OK, you asked for it. I'll answer the question. Why is there not an implementation of locate (or slocate, which is much the same thing) which indexes filesystem changes in real time?

Because of the kernel/user split. locate and slocate operate in user mode, getting information from the kernel in bulk, when updatedb is run. File creation / linking / unlinking / renaming happens in the kernel. There is no general interface for the kernel to alert userspace of changes to the filesystem - which means locate has no way of picking up updates short of rescanning the whole filesystem for them, manually. As you'll notice when you run updatedb, this is a laborious process, not suitable for running in real time. (Indeed, if you want real time, use find. locate was invented specifically for its cache - that's the only real advantage it has over find.)

...Which spawns two more questions. One, why can't someone add such a callback, and two, why not do a locate in kernel space?

As to the callback, the concept exists in the form of directory notifications, where an application can request a list of directories its wants to be notified about. The kernel then makes it known when one of these changes in some way - link, unlink, rename. I know this has been implemented for Linux, but I don't believe it has made it into the mainstream kernels. It could be put to good use by a file manager application, or a "desktop icon manager" like the Windows Explorer shell.

Having a similar callback for an entire filesystem - well, apparently nobody has found it necessary yet, and it would probably slow down a lot of filesystem workloads / benchmarks. Richard Gooch's devfs filesystem for device nodes does have this - it's called the devfsd protocol - but of course it's specific to the devfs partition.

(Actually, I just remembered - as of 2.5.27 Linus is in the process of merging LSM. This is a security module framework which presumably would make it fairly easy to provide such filesystem-wide notifications to userspace. I don't yet know any more about it than that, at present.)

So ... next question ... why not just do locate in kernel space? In short, too little benefit for too much complexity - i.e. it would be seen as bloat.

Oh boy...

[Anonymous Coward]

Wow! A feature freeze! For two months!

It's a good thing this important news got to me so quickly. And to think I was just saying how slashdot posts useless articles.

my pet feature

[Anonymous Coward]

Ok I might be clueless here so please help me if this makes no sense..

I want good cdrom/other drive auto mounting/unmounting. From what I have seen this is provided by a seperate patch. Mandrake has it in some of their releases (in 8.2, but not in 8.1). But the mandrake one never seems to work well.

This feature not working has got to be my biggest problem with linux today. I want to set something in my fstab (someone please tell me you can already do this and I am out to lunch) so that when I put a cd in my drive it mounts itself. And when I push eject it interupts anything using it, unmounts and ejects. Note: not even windows has the "when I push eject I want the cd now, not when some app is done with it" part of this down right.

Re:my pet feature

[autechre]

Is that really what you want? If you're burning a CD, and you somehow hit the CD button by accident (let's say you have the DVD drive right above the CD-RW like I do, and you're trying to take out the DVD you left in there), do you really want the drive to immediately stop burning the CD and spit it out?

There's a _reason_ the system won't give you back the CD "right now" sometimes. It's because it still needs it. You can handle waiting a few seconds for the program to finish reading data so that it doesn't block, explode, or fail at whatever it was trying to finish (which will probably lead to you being more upset than it not giving you back the CD the instant you want it).

What sort of CDs do people use on a Linux system these days anyway, other than audio CDs (which don't need to be mounted)? And thankfully, some people are starting to get the idea that floppies are annoying and bad. True, they're now transferring files by emailing them to themselves via Hotmail...

Re:my pet feature

[Anonymous Coward]

Why are people defending poor usability ideas like this when easily implemented and better solutions have been available for years?

This is a usability issue. It's not about YOU don't use floppies. It's about the countless others people who still use them for work or personal reasons.
Programs automagically closing when the cdrom is ejected isn't a new idea any more than programs asking back for the floppy if someone ejected it.

As for your example:

I blame that mistake on you for being dumb enough not to know the difference between a drive burning a cd (the write light is on genius) and one that doesn't.

Re:my pet feature

[Zenki]

Like why couldn't the cd burning software lock the cdrom drive, and pop up a modal to tell you.
"I'm burning the disk right now. If you eject, this current burn will fail. Do you really want to eject the CD drive? *NO* Yes"

mounting floppies, CD's and DVD's

[oever]

I'd like to install linux on my Mom's new computer, but the mounting of disks should be a lot easier. All we regular linux users are very accustomed to it, but really, it's rediculous.

It possible to jerk out my netword PC-Card. The network is closed down nicely. Reinsert the card and the network restarts.

But if I put a floppy in the drive, I cannot read it by default. Aargh. Sure, I can use automount, but then it's not safe to just remove the floppy.

And for the CD it's even more weird. A CD/DVD player has a button. This is disabled when I mount a CD. So a mounted CD cannot be ejected. Yet, mounting the CD when it is inserted. That's apparently asking too much.

It's great that so many new features go into the kernel. But why can't a simple feature like this make it into the kernel. There's no lack of patches.

Re:mounting floppies, CD's and DVD's

[yobbo]

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...

Re:mounting floppies, CD's and DVD's

[yem]

You probably want supermount. Just ask google.

Here's a patch for 2.4.18:
http://espectro.hypermart.net/supermount. patch

The latest version of Mandrake Linux includes supermount and I've grown to like it. It would be nice to have it in the kernel, even if it was marked EXPERIMENTAL.

Re:mounting floppies, CD's and DVD's

[rossz]

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!

Re:mounting floppies, CD's and DVD's

[io333]

I keep trying to take the damn floppy drive out of the various systems I deal with, and I keep having some rediculous reason where I *need* to put the horror back in. It's bizzare. Try it: take a machine that hasn't had a floppy inserted into it in years. Remove the drive. It is a physical LAW that the machine will require the use of a floppy drive within three days.

And my goodness: is there any brand of floppies left that doesn't have at least three dead in a box of 10?

Re:mounting floppies, CD's and DVD's

[byran lei]

>And for the CD it's even more weird. A CD/DVD player has a button.
>This is disabled when I mount a CD. So a mounted CD cannot be ejected.
>Yet, mounting the CD when it is inserted. That's apparently asking too
>much.
>It's great that so many new features go into the kernel. But why can't
>a simple feature like this make it into the kernel. There's no lack of
>patches.
>
Because what you suggest is a basically stupid idea. Look at the grief Mac users got when they inserted one of damnable copy-protected cdroms.

Re:mounting floppies, CD's and DVD's

[WasterDave]

is there any brand of floppies left that doesn't have at least three dead in a box of 10?

No, there bloody isn't. I now maintain a small collection of antique floppy disks for the rare occasions where I want them to work.

Dave

Re:mounting floppies, CD's and DVD's

[Anonymous Coward]

As stated above, there are userland utilities that poll the cd drive to see if there's a disk to mount.

If these utilities aren't a solution, it isn't the fault of the kernel.

It's up to the big distro's to fine tune such user experience.

Re:mounting floppies, CD's and DVD's

[Anonymous Coward]

And you don't know how much fun is this mounting thing when you are using a shared computer!!!

When I finished university we used to have a room full of Linux PCs. Most people went, mounted the floppy disk to copy files (through a KDE icon, so they didn't even know what "mounting" was) and then ejected the floppy manually before loggin out.

As a result: the floppy unit was mounted, so noone could unmount it (only root and whoever mounted it), and thus was rendered useless until the system was rebooted. Nice.

Re:mounting floppies, CD's and DVD's

[naasking]

I've been running my machine without a floppy for months now. Then again, it never had a floppy to begin with, so maybe the "law" should be extended to include only machines that had a floppy in the first place.

Re:mounting floppies, CD's and DVD's

[handsomepete]

"Because what you suggest is a basically stupid idea. Look at the grief Mac users got when they inserted one of damnable copy-protected cdroms."

Bah. Don't condemn a perfectly good feature (which has worked just fine for nearly a decade on Windows) because of a some shitty think tank's music copy protection sc(am)heme. At least place blame where it belongs, not on Apple's (somewhat ill-conceived but still very usable) automount system.

Re:mounting floppies, CD's and DVD's

[binner1]

I also made this leap when I purchased my machine this spring. No floppy for me. The only reason that I would ever miss it, is a nice 3-floppy networked debian install. I decided to suck it up and forego that niceness.

My main reason for the decision though is that while in school I worked at the University Help Desk. You have _no_ idea how depressing it is to watch people lose their thesis because the only place they saved it was on a floppy! Sure, they should have backed it up on the network (that's what it's there for)...anyway, floppies just aren't reliable for anything anymore.

It's time to start the push for elmination of this antique and very fragile technology.

Down with floppy drives and disks!

-Ben

Re:mounting floppies, CD's and DVD's

[rgbrenner]

Its marked experimental because it has race conditions. Heres a quote from this LWN article:

The most common answer to this problem seems to be supermount... There is also evidently a need for an audit by a serious filesystem hacker to deal with some questionable practices and race conditions.

You can find more referencing to the race conditions in Supermount here.

Re:mounting floppies, CD's and DVD's

[Anonymous Coward]

But there are still cases for this to be used.

Drivers necessary to the boot of the PC, for example.

If the Boot system was upgraded (and drop the bloody real mode x86! PLEASE!!!), then the need for this would be reduced.

Have PCMCIA as a bootable item, much as IDE is, then you can have an etherboot machine with PC/Ethernet cards, "Floppy" boots with a CFlash card, etc..

Hmmm, nice.

Re:mounting floppies, CD's and DVD's

[dd301]

For the floppies just use mtools. It is much simpler and provides all the commands that you would expect. Also has the advantage (?) that it is similar to windows commands. No need to mount/umount.

As for CDs, put the CD in eject -t and then mount /mnt/cdrom followed by eject which will autmatically umount it. I think you don't even need the initial eject -t command.

Just my $0.02

Re:mounting floppies, CD's and DVD's

[mrseth]

I agree, I'd like to see them go, but you've got to tell the motherboard makers to give us another route to flash our BIOSes. Especially for those of us who do not run any sort of MS Windows. I still have to keep a win98 boot floppy around just for this purpose.

Re:mounting floppies, CD's and DVD's

[io333]

It would actually be quite simple for them to do:

There's some free DOS clone out there, I can't remember the name, but it works as well as, or better than DOS6.

So the mfr could just put those files need to boot a disk from that DOSclone, as well as the files needed to flash the bios, in a compressed archive. Then all you have to do is uncompress the archive and burn in on a cdr -- and then boot the CD.

--
Posted from Gentoo+KDE3, day1. GENTOO ROCKS!!! You won't understand 'till you try it. Don't be intimidated, it's not hard to install! It's so freaking fast!

Re:mounting floppies, CD's and DVD's

[Anonymous Coward]

The reason this is done is because some files on the media may be in use by programs (perhaps even by other logged in users on Linux/winXP). If you remove the media, you have a problem. In windows (win95-98, I've never tried it on NT/2k/XP) you get a blue screen telling you to re-insert the floppy/CD, in Linux they don't let you remove the CD (although there's a bug, with my laptop after resuming from a suspend the CDROM drive is unlocked and I can remove a mounted CD :-). What they should do (I think), is only let you remove the CD if no files on it are being read. Most floppy drives can't be locked so there's not much you can do there.

Re:mounting floppies, CD's and DVD's

[Anonymous Coward]

Being able to remove a mounted CD is a security issue!
Please, RTFM!

Re:mounting floppies, CD's and DVD's

[DGolden]

I find a deeper problem with removable disks on Linux and Windows: ranted about this at length on LKML a while back. I'm now trying to do something (possibly misguided) about it. The basic problem is that a disk is not the drive it is in.

both Unix and Windows, in general, assume it is. You don't copy a file to "disk xyzzy", you copy it to "A:" or "the filesystem mounted on /dev/fd0" - /dev/fd0 identifies a drive, not a disk!

The amiga got this right:
a disk became part of the filesystem based on its label/id, if possible -
so I could say "copy mfile.doc to xyzzy:mydocs", and if the disk xyzzy was unvailable, the system would prompt for it, while the copy process blocked waiting for it. If I put it back in a different drive, the system didn't care.

I'm currently casting an eye over the linux block device and filesystem code with a view to mangling into something vaguely amiga-like - but I'm not really even a C programmer (more of a Lisp guy), so I make take a while.

Basically, a disk contains a set of blocks. Some or all of those blocks may be accesible via a block device file. But you should be able to mount the filesystem "on the set of blocks of the disk", not the set of blocks currently accessible by a particular drive - disk partitioning schemes still have one or two fields to facilitate this, the disk label/name and/or a uniqueid.

If I have a disk labelled "peaches", I want it part of the filesystem at e.g. /mnt/peaches, and if I have two drives, I don't want to have to care about what drive it is in!

Re:mounting floppies, CD's and DVD's

[KjetilK]

I just instructed my parents to mount and umount usnig the icons on KDEs desktop. Told them it is more secure and lessens the risk of data corruption. They are perfectly happy about it, it took them less than 5 minutes to master. Just go ahead and teach her.

Re:mounting floppies, CD's and DVD's

[Hawke]

This isn't a full solution, but some "mount by label" stuff is already there.

e2label /dev/foo "Foo"
mount LABEL=Foo /mnt/foo

Add in automounter magic, and TaDa: "Its a userspace problem," albeit one that assumes you are using ext2 as your only file system.

If you actually want to hack this, look into the executable maps and wildcards features of autofs (man 5 autofs). It might be possible now with some clever automounter config files...

Re:mounting floppies, CD's and DVD's

[Hawke]

oever says:

Sure, I can use automount, but then its not safe to just remove the floppy.

$ more /etc/auto.master
# Format of this file:
# mountpoint map options
# For details of the format look at autofs(8).
/misc /etc/auto.misc --timeout=1

A 1 second delay good enough? There are still some details about remembering to change out of any automounted subdirectories, but this setup "Works For Me(TM)"

I also use the CD like this, and have setup some view profiles for Konqi that start in the directory. Now I can buttons on the desktop I click to look at the cd... and no need to care about mounting/unmounting it.

Re:mounting floppies, CD's and DVD's

[Anonymous Coward]

sounds like a useful feature for the next gen of distros...

Re:mounting floppies, CD's and DVD's

[psamuels]

Add in automounter magic, and TaDa: "Its a userspace problem," albeit one that assumes you are using ext2 as your only file system.

The Linux mount program knows about SGI XFS labels. I'm pretty sure it doesn't parse labels for FAT, HPFS or NTFS (yes they all have them) or whatever other filesystems have labels - probably because nobody really needs to specify label-based FAT mounts in fstab (it's a legacy format anyway). Plus, FAT/HPFS/NTFS labels are much harder to extract than ext2/ext3 and XFS labels, which are in fixed fields in a fixed superblock. (In FAT, the label is a pseudo-file in the root directory.)

Re:mounting floppies, CD's and DVD's

[Anonymous Coward]

It's not been all that long that Windows has been able to cleanly unmount CD. Try unmounting a CD in use by Windows 95/98 (like when you insert a CD and suddenly realize you don't want it to autorun) and you'll get a Blue Screen. The newer versions of Windows have been corrected, but it took Microsoft quite a while to get around this.

Re:mounting floppies, CD's and DVD's

[Anonymous Coward]

The label field is used to scan for the disk, the filesystem is actually mounted on the drive the disk is in - you can't subsequently, and _while the disk is still mounted_ take the disk out temporarily and put it back in a different drive and have the system carry on as if nothing happened - i.e. the blocks for the filesystem are found by indirecting over the drive, not the disk label.

The automounter is _not_ enough. I know, I've tried - it gets you 50% there - the stuff I (DG) intend would still require the automounter - but the automounter would be mounting /mnt/xyzzy on block device /dev/vol/xyzzy -
think of it as a "Physical Volume Manager" analogous to the LVM...

Re:mounting floppies, CD's and DVD's

[Sloppy]

It's not really a floppy issue; it's a removable writable media problem. There's Zip disks, etc. too to think about. (Yes, I still use Zip disks.)

The problem has kind of been sidestepped by the popularity of CDR (and RW, and DVD, etc) drives which typically end up completely copping out by requiring a special application to write, instead of just being a filesystem. That really sucks, BTW, and it's even worse.

I see..

[MOMOCROME]

Doesn't this bode ill for the kernel dev efforts, if the concept of "feature freeze" must be reported on and placed in quotes as if it were some novel new design technique?

This should be standard practice. Sure reporting on the features to be included before the freeze is worthwhile, I can see why that's interesting, but "feature freeze" in quotes? C'mon already. every two-bit dev team from Seattle to Sri Lanka must reach a point of "feature freeze" during a dev cycle.

Re:I see..

[Rhinobird]

No, you got it wrong. It's not a new concept, they put it in quotes, because basically those are gonna be the features which they work the bugs out of first. Everything else is probably gonna have a big "EXPERIMENTAL" tag on it when go to configure your kernal. Then once they get 2.6 stable, they move onto 2.7 and work more seriously on the stuff that didn't get that much attention in 2.5. Gosh I hope I haven't mangled this process too badly.

Re:I see..

[MOMOCROME]

I think you might have it wrong...

If what you were saying was the case, the writeup might appear more along the lines of ' ..feature freeze for the "2.5 kernel"...' instead of ' ..."feature freeze" for the 2.5 kernel...'.

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.

Re:I see..

[FreeUser]

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.

Which, historically, has been the case. Linus admits he isn't very good about things like that ... anyone else remember the "Give Linus a Backbone" website shortly before the release of 2.4?

In any event, it is really unconscionable that XFS isn't being integrated into 2.5. It is hands down the best, most reliable filesystem under Linux bar none, and the only filesystem I will use on mission critical servers running Linux.

This politicking about kernel patch sizes and "I don't like the way you tweaked [whatever]" has really gotten out of hand, and the result is that we have subpar filesystems integrated into the default kernel while the best of the breed remains an external patch.

Maybe we'll get lucky and Linus will cave once again and let XFS through, but my money is on something a lot less innocuous, like another VM revamp in the middle of a "stable" series a la 2.4.

Re:I see..

[psamuels]

In any event, it is really unconscionable that XFS isn't being integrated into 2.5.

It is nothing of the sort. For one thing, you should look up the word unconscionable - "I do not think it means what you think it means." For another, if you think it such a great crime, why don't you undertake to integrate it?

Hint: "integrate" does not mean "take the SGI patch and throw it at Linus". It means "comb through SGI's patch, figure out what all was added to the kernel to support XFS, and take it apart feature by feature." Then, for each separate feature:

• Produce an independent patch - independent meaning does not require the rest of the XFS patch, does not break the kernel, and actually accomplishes something on its own.
• Figure out how to justify its existence in a sufficiently convincing way that Linus knows you're actually trying to improve the kernel, not just throw crap in it so you can have XFS.
• If Linus thinks your feature is stupid, poorly designed or poorly implemented, he's probably right. He's pretty amazing that way. You must take his criticism into account to figure out another way to get the needed facility. (If necessary, hash something out on linux-kernel or linux-fsdevel.) Iterate until you get a patch Linus likes, then adapt XFS to use that instead.

Finally, when Linus has merged enough of your patches that XFS has all it needs, send Linus the XFS filesystem code itself. At this point Linus will most likely take it. If Linus has objections to the XFS code itself, work with him to clean it up as necessary. Remember, just because code was good enough for IRIX doesn't mean it's good enough for Linux. (:

Here endeth the XFS Integration Mini-HOWTO.

What? You don't want to be the one who gets to do all that after all? Then quitcher bellyachin'.

Left Out and Left Behind

[tarsi210]

Now, someone correct me, but it sounds like a lot of really really necessary crap is (probably) going to be left out of the 2.5 kernel (which will become 2.6 stable eventually). I'd like to mention a few here and why I'm stunned that they probably won't make it.

• Add XFS (A journaling filesystem from SGI) - Excuse-the-hell me? Isn't the idea to get journaling filesystems in to the kernel because that's what everyone wants? XFS is proven, get it the heck in there.
• Asynchronous IO (aio) support - This is really surprising in some ways. IIRC from the kernel summit summary, this was a hot topic and argued vehemently. Even Linus agreed it was a Good Thing(tm) and should be done. If I also remember correctly, it's a hell of a lot of work, so I can justify that.
• Full compliance with IPv6 - Ok, for crying in my lukewarm beer, this needs to get in there, folks. IPv6 needs to get going and you're not helping.
• ext2/ext3 large directory support: HTree index - Sounds like something that enterprise Linux people would enjoy, yes?
• Remove the 2TB block device limit - Ditto.
• Overhaul PCMCIA support - Ogg heat metal. Ogg form new stick from copper, copper much better than wood stick. Ogg progresses. Anyone else think that PCMCIA sucks under Linux? It could use an overhaul in a large, hairy, neanderthal way.
• Reiserfs v4 - See the comment above about XFS.
• Serial ATA support - I don't know how close this standard is to manufacturing, but it certainly sounds like this is the way that hardware is going (and bless them, too.) Probably a good thing to NOT leave in the dust.

That about does it for the ones that make me cringe uncomfortably. Past that, I can rationalize the other ones out. These just flick that, "Whoa, aren't you making a mistake?" light inside my head.

And would anyone care to comment on the SCSI interface? According to the kernel summit, there was going to be much code yoinkage and redoing for the entire subsystem. Where does that play in the 2.5 freeze?

Re:Left Out and Left Behind

[yem]

* Add XFS (A journaling filesystem from SGI) - Excuse-the-hell me? Isn't the idea to get journaling filesystems in to the kernel because that's what everyone wants? XFS is proven, get it the heck in there.

Easy there - XFS has been available available for months for those that really want it. It'd be nice to have it in the base kernel, but its not like you're going without.

I'd like to know exactly what hasn't been implemented in IPv6...

Re:Left Out and Left Behind

[Anonymous Coward]

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.

Re:Left Out and Left Behind

[RussGarrett]

Full compliance with IPv6

Exactly what isn't compliant with IPv6 in the current (2.4) kernel? I'm currently using stock unpatched 2.4 to run a web server over IPv6 quite happily. It's the applications that are lacking support. Hell, with radvd it's functioning as a full 6-to-4 router for my home network.

Re:Left Out and Left Behind

[mrscorpio]

Personally, I'd love to see NTFS write support "finished" (i.e. made stable), but judging from the state of things, that's a high priority for few...

Chris

Re:Left Out and Left Behind

[Ami Ganguli]

Depends on how you look at it. If the feature freeze holds (a big 'if') then 2.7/2.8 will follow in reasonable time. There's always a next version.

The danger is that the feature freeze holds just well enough to keep a few important features out, but not well enough to bring a stable 2.6 quickly. That's pretty much the worst of both worlds.

I'm hopeful anyway. I think everybody is serious about getting the release cycle shorter.

Re:Left Out and Left Behind

[fferreres]

# Reiserfs v4

Will not be ready/tested. You can always patch your kernel to add support for it. It just won't come default as they can't bundle everything, specially the non stable developements (reiser4 has not even been released yet).

# Full compliance with IPv6

I am not an expect, but surelly the "full compliance" means a lot of unused parts that are non-critical and non-important and can be implemented later. For example, no C++ compiler implements all the C++ specs. Does this mean C++ is unsopported?

# Serial ATA support

What's this for?

# Overhaul PCMCIA support

I agree, it sucks a bit. I'd like it to be more userfriendly. I sometimes don't know what is used for what (what do you have to check to get ATA CompactFlash cards to mount?). Probably just my fault here! (the PCMCIA network card works great though, and Slackware 8 default kernel autodetected it).

Re:Left Out and Left Behind

[RussGarrett]

OK, so I jumped the gun a bit there - there are bits still missing from the Linux IPv6 stack which make it non-compliant, such as IPSec and such. See the USAGI project. But the major points of IPv6 certainly work on Linux.

Re:Left Out and Left Behind

[Screaming Lunatic]

Full compliance with IPv6

Exactly what isn't compliant with IPv6 in the current (2.4) kernel? I'm currently using stock unpatched 2.4 to run a web server over IPv6 quite happily. It's the applications that are lacking support. Hell, with radvd it's functioning as a full 6-to-4 router for my home network.

Here's a little info . Doesn't go into specifics. Follow the links and you end up here .

They key is the "my home network" part. The router for an autonomous system would probably require full support. I'm running RH7.3 (kernel v2.4.18) and i don't see kame dancing.

Re:Left Out and Left Behind

[daserver]

>* Add XFS (A journaling filesystem from SGI) - >Excuse-the-hell me? Isn't the idea to get journaling >filesystems in to the kernel because that's what everyone >wants? XFS is proven, get it the heck in there. I agree that XFS had been proven stable. Right now it is been merged in a seperate cvs repos (SGI). I tried to run 2.5.15, I think it was, with XFS cvs. It didn't go very well, when I did large transfers, the system would completely lock for about 5 sec. and then continue. This happened every 5 minutes or so. That combined with the fact that the ide had been rewritten and isn't really stable has given me some series doubts about trying 2.5 again. About ReiserFS v.4 is it _not_ going it! There isn't even a downloadable version out yet. Is way to alpha/beta to go into 2.5.

Re:Left Out and Left Behind

[RussGarrett]

Hrm I can see the dancing kame on the debian box which is doing the actual routing (or rather, I can't because I'm using lynx, but I'm seeing the IPv6 page :)). I can't on this box because neither IE6 nor Mozilla 1.1 appear to have IPv6 functionality on Windows. However the debian box, having been allocated a /64 by FreeNet6, assigns addresses on to the ipv6-enabled (windows) computers on the LAN, and I can ping6 www.6bone.net from my Windows box.

Still, Microsoft still hasn't got a production driver out for Windows either, so Linux isn't behind yet :) (although they're apparently going to release a production driver for .NET server).

Re:Left Out and Left Behind

[IamTheRealMike]

# Reiserfs v4 - See the comment above about XFS.

ReiserFS v4 makes some BIG changes to the kernel - for instance, it requires that files can be also directories at the same time. It's currently slated for December 31st, so I doubt it'll be in the next kernel. It's a big bit of work. Anyway, I think most distros have had ReiserFS v3 (which is also journalled) in their for ages, I know SuSE has, or you can recompile your own. Having it in the base kernel is nice, but hardly necessary.

Re:Left Out and Left Behind

[Anonymous Coward]

Foget the kernel, how about the fact we still DON'T HAVE A DECENT ALTERNATIVE TO NDS AND AD!!!!

NIS can suck it, and picking some open source ldap server and customizing it doesn't do much for standards now does it?

When oh when will linux have a STANDARDIZED scalable directory service that can compete with the commercial ones? Instead of trying to figure out how to "fit linux in" with some huge AD deployment, Windows et al should be clamoring to try to fit in our superior open source directory.

Until that happens linux can't ever be considered the "glue" that holds organizations together.

Re:Left Out and Left Behind

[MrResistor]

Serial ATA is software compatable with paralell ATA, so I hardly see a need to "add" support for it.

If you mean Serial ATA add-on cards, well, people would have to have them and write drivers for them, or the manufacturers would have to write drivers. It's hardly reasonable to expect drivers that don't exist to be included in the kernel.

Re:Left Out and Left Behind

[tarsi210]

Oh, I agree with the shortening of the release cycle. My only point that I was trying to drive (and heck, it was late, maybe I wasn't clear enough) was that in software development, you have to balance the need to get the product out with the need to get the important features in. Although Linux isn't being "sold" to anyone, in a sense it is...to maintain corporate support and usage of Linux, the kernel has to maintain a software product's appeal, despite its free nature.

To this end, I put on my corporate CTO's hat and looked at the listing of things being left out and said, "Uh...maybe a tad longer development cycle rather than shorter and getting a few more of the features in would be a good thing for the market."

Mind you, I'm not a kernel hacker and therefore some of these issues I may have said, "Ok, why aren't these in?" and the reason is because they're involved beyond what I know.

Re:Left Out and Left Behind

[Anonymous Coward]

>>Asynchronous IO (aio) support

Part of this have started going in already.

Modversions...

[ndogg]

I'm sorry to ask this question, but my experience with the kernel source is limited.

What's so ugly about modversions that some of the core kernel developers would like to see them dropped?

Re:Modversions...

[fferreres]

Apparently they don't like you to inset modules compiled for another differet kernel. The reson is not they like to make things harder, but that they think modversions is a mess and not the right solution (and it may cause more problems than it solves).

I'd love to have some way to use generic modules but not sacrifice the stability of the system (as in insmod -f -error all arround-..."it works". And when the system freezes you don't know what it was (and when you bugreport, you translate the problem to the developers)).

parent overrated

[Anonymous Coward]

Damn, trolls are getting more clever.

Support for mounting NTFS

[dytin]

OK, I know, I'm stupid when it comes to knowing anything about the Linux kernel, so please be patient.

I just got a new computer, and I installed a dual boot of Windows 2000 and Redhat 7.3. When I went into Linux, and tried to mount windows (mount /dev/hda1 /mnt/windows) an error was returned saying that the kernel did not support NTFS. Windows 2000 uses the NT file structure as oppoesed to FAT32 that previous versions of windows have used. My question is whether or not newer versions of the kernel will have the ability to mount windows 2000 partitions.

Re:Support for mounting NTFS

[UncleFluffy]

They have been able to for ages. Looks like the default RH kernel isn't built with this enabled.

Re:Support for mounting NTFS

[philip_bailey]

There has been some support for for the NTFS filesystem available for years. The original driver system is no longer developed, and a new system is being actively developed (link). Unfortunately, because of the complexity of this filesystem, which is not fully documented by Microsoft, only read support is satisfactory - i.e. it may be dangerous to write to an NTFS filesystem from Linux.

You may wish to explore loading NTFS as a module or compiling it into your kernel.

Re:Support for mounting NTFS

[Anonymous Coward]

NTFS is not compiled into the default red-hat kernel. You'll have to intall the kernel-source, compile the kernel with NTFS as a module (M) and then add a line to your /etc/fstab so that you can more easily mount the NTFS partition. In the fstab you'll want to make it as read-only (r). Hope that helps even just a little bit ...

Re:Support for mounting NTFS

[Zapdos]

3.2 How do I get Linux to understand NTFS?
There are two ways to get NTFS support. The simplest is to add the NTFS module to the kernel (as root):

modprobe ntfs

If this fails, modprobe: Can't locate module ntfs, then your distribution didn't install the NTFS module.

The second way is to recompile the kernel, yourself. This sounds like a lot of work, but it isn't that hard. Have a look at the section: How do I add NTFS support to Linux?

3.3 Can I write to an NTFS Volume, too?
NO.

There are two drivers, currently. The original driver, in 2.4 has some write code in it, but it is extremely dangerous to use it. The possibility of destroying your filesystem is very high.

The new driver, introduced in 2.5.11, has no write code at all. This may sound like a backwards step, but it was necessary to rewrite the driver in order to make the future coding simpler and more solid.

Adding write support will take a long time. NTFS is built like a database. Any changes you make, necessitate making changes in many places, for consistancy. Make a mistake and the filesystem will be damaged, make too many mistakes and the filesystem will be destroyed. Also, the current developers are only working on NTFS as a hobby, during their free time. If you'd like to help, please email: webmaster@flatcap.org.

Re:Support for mounting NTFS

[dd301]

Looks like the default RH kernel isn't built with this enabled.

They don't have anything on their kernel which is marked experimental/dangerous in the config. Of course, write support is really dangerous. FWIW, they don't have UDF support either.

Re:Support for mounting NTFS

[gerardrj]

Since Kernel 2.2 I think NTFS paritions have been supported as read-only.
The stock kernel from your distro probably doesn't have the support comiled in. Assuming the kernel was compiled for loadable modules, you could compile the code as a module, and it would probably auto-insert itself when you tried to mount the partition.

The HOW of getting that done isn't very difficult, but beyond the scope of this thread.

Re:Support for mounting NTFS

[UncleFluffy]

I was aware that write support is extremely dubious, but I thought that read support was pretty safe - am I wrong ?

Re:Support for mounting NTFS

[dd301]

I was aware that write support is extremely dubious, but I thought that read support was pretty safe - am I wrong ?

Well, if the code is not reliable, all bets are off when it is mounted, although in the config it says that read support is just experimental and not dangerous. I don't think RedHat would want to take that chance.

My project

[Alsee]

support for filesystems greater than 2TB

Ah, good! This has been a major stumbling block for me. I've been writing a guide and I hit the 2TB ceiling. My target market is hitchhikers.

-

are you new here?

[Xtifr]

The kernel developers know what a feature freeze is. There's no quotation marks around it in the referenced article. The quotation marks in the slashdot headline came from an "anonymous person" somewhere, and the slashdot "editors" decided to leave it there because they are "editors", not editors.

#include <usual lecture about reading the article before commenting.h>

Not a troll

[Anonymous Coward]

I was just asking a question! The post by Evalhalla in reply to my question was the troll

Re:Not a troll

[fferreres]

Evalhalla made an honest and insightfull reply. Your post has probably been maked "Stupid +1" if there was an option. Because of the lack of the option, they marked it a troll so that it doesn't expand automatically.

Next version number will be 2.7/2.8 with 99,9% probability. Who cares?!

Re:Not a troll

[Anonymous Coward]

I believe that 2.9 would be the development version for 2.10, not 3.0.

I don't call that very insightfull.

Bill Gates on Linux Filesystems

[Anonymous Coward]

Hey! What do we need 2TB for! It's bloat! Bloat, I say! 640K ought to be enough for anybody!

--William H. Gates, Chairman of the Board of Microsoft Corporation (MSFT), overheard at a Silicon Valley insider dinner.

kbuild?

[spongman]

how about kbuild that has been ready for a fucking eon? yeah, yeah, it's a big patch, so were the first few that went into 2.5, and kbuild2.5 was ready then, too. and still we wait for kai to pretent he's helping...

politics: from the greek: poly:(adj.) many, ticks:(n., pl.) blood sucking animals.

Re:kbuild?

[Anonymous Coward]

I like your sig.

Re:Serial ATA support

[Anonymous Coward]

Why is Serial ATA support important?

Because it is fast looking like serial ata disks are going to be hitting the market in a big way, before the end of this year. By the time 2.6 comes out, it is going to be more than important.

Controllers from all the major manufacturors are out as of now, and disks from seagate and maxtor are likely to be out next month.

And to boot, all of the prototype Opteron motherboards seen to date have had Serial ATA onboard. It seems improbable that they'll have a standard ide controller as well, considering that the serial ata controllers can be used with standard ata drives, via a converter.

If support doesn't appear, linux users will be left in the dust.

Just one important bit they left out:

[Bollie]

v4l2

This would allow the latest bttv driver to be packaged with the kernel once more...

After the preemptive patch, that's the first patch I run on a plain vanilla kernel.

Re:Linux 3.0 == Trusted Linux

[axxackall]

From the point of view of OS corporate consumer, I am comfortable to welcome Linux 3.0 if it will be "Trusted", at last. Trusted not in terms of outdated BSD - "good old stable fixed stuff", but in terms of system architecture from the begining designed to behave stable even in environment of some unstable "userland" packages.

Being more specific, I expect LSM, SE-Linux and LIDS to bring me RBAC. I am sick of primitive Unix user-group-other file permissions and unsecure workarounds.

In kernel checkpoint support?

[maynard]

I'd really like to see one of the checkpoint patches includeded in the mainline kernel series. There are several to choose from: EPCKPT, CRAK, CP.... Which one doesn't matter (feature wise), they all basically allow for the kernel to stop a process, save it's state and pages to a file, and then load and restart that process by request.

Yes, I could distribute a patched kernel across all of my systems. But then I'm tied to that kernel until whichever project I'm following updates their patch (or I update it myself, and I don't consider myself competent as a kernel hacker). This would be a really useful mainline feature for those of us in the scientific computing community. Wasn't there some talk of one of these going in 2.6 proper? --M

What the big shots say

[daserver]

This gives a very nice overview why and which things should be able to make it in 2.5.

So much for Enterprise Linux

[baptiste]

While I understand that you have to draw the line somewhere and that it can be difficult to deal with such far flung development groups with their own priorities. BUT...

Why is XFS still not considered ready? Its in almost every major distro except for RedHat. Heck - the XFS team even provides custom XFS RedHat installer iso's to fill in the gap. XFS v1.1 is already released and is being used on huge fileservers in production all the time. Why can't we get past the 'we don't like the way you tweaked module X' and finally move forward.

I wish EVMS was going to be ready - this is going to be huge for enterprises - finally a unified, feature rich storage manager.

LVM 2.0 - well, I'd rather ensure 1.x is super stable (it is so far for me) so this isn't as big a deal.

Serial ATA - Bummer. I realize this is new. But I get the feeling Serial ATA is going to be huge, especially for lower end servers. Finally getting real hot plug support and a setup that'll make things easier on the HW RAID vendors (I can't wait to see a Serial ATA card from 3-Ware!) I would hope this would be flagged as something to be merged into 2.6 as soon as its possible, even if marked experimental.

Don't get me wrong - I'm really psyched for 2.6, but there are some features (whose development is out of the control of the core kernel team) we really need, to push Linux farther and farther into the enterprise. I know you can patch in what you want - but many IT folks, even Linux zealots, are wary of doing so in production - they want stock RedHat kernels so they can tell their boss its gone through RedHat Q&A and all that. Its CYA sure, but necessary in many environments. Granted RedHat often adds stuff not in the stock kernel, but not usually hueg features.

Re:So much for Enterprise Linux

[Anonymous Coward]

"Serial ATA - Bummer. I realize this is new. But I get the feeling Serial ATA is going to be huge, especially for lower end servers. Finally getting real hot plug support and a setup that'll make things easier on the HW RAID vendors (I can't wait to see a Serial ATA card from 3-Ware!) I would hope this would be flagged as something to be merged into 2.6 as soon as its possible, even if marked experimental."

As an AC pointed out on the kerneltrap link:
--- from www.serialata.org --- Q2: Previous efforts to transition to a serial bus were not successful. Why do you believe that Serial ATA will be successful? A2: Serial ATA is a drop-in solution in that it is compatible with today's software

So, I'll bet that it'll be handled at the hardware level (at least preliminarily) in Linux using the base chipset drivers that are already in place. Sounds like it should be trivial to tack on a quickie patch just to recognize the hdd (albeit w/o optimizations) in the 2.6 branch, but the number of lines of code I've written in the kernel can be counted on an armless man's fingers, so what do I know.

Seems like everyone and their mother has been waiting for Serial ATA, so I doubt they'll leave us completely out in the cold...

Re:So much for Enterprise Linux

[Anonymous Coward]

Sigh. There should be a FAQ for this stuff:

XFS - It fairly heavily modifies the VFS and VM layers, so it will take time. Everybody wants it in but it will take some work first.

SERIAL ATA - There are two versions of support for this. The first is where the kernel goes "Hmm, this is a very fast IDE drive"; this is already in. The second is where the kernel actually realizes that there is a SERIAL ATA drive. That is being worked on.

LSM to be included - yay!

[sasha328]

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

Re:LSM to be included - yay!

[AaronMB]

well, if you are refering to ACLs in the filesystem, Extended Attributes has been in the VFS since 2.5.3 so now it's just up to the filesystems to include ACL information and the NFS server/clients to support the ACCESS command(there's a patch floating around to do it, but I haven't heard anyone talk about). Samba already supports ACLs if you are running XFS or Ext3+acl. If I can get filesystem/nfs-supported ACLs, i'll be happy.
-Aaron

Re:LSM to be included - yay!

[psamuels]

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.

Well, Linus has started integrating it, so you'll get your wish.

As to whether NT is superior, it depends on if you measure by flexibility or by ease-of-use. NT ACLs are hella flexible - you can grant or deny a whole range of permissions to anyone you wish. The Unix "read write execute / owner group other" seems horribly primitive by comparison. But it comes at a cost. NT does not come with any sane way to manage permissions. The GUI tool? Puh-leeze. It can't even add / remove users from a tree of files without resetting every file in the tree to the same ACL. It doesn't give access to the "deny" half of an ACL either - everything is "start from zero, and allow". It doesn't seem to have any "summary mode" or search capabilities - you have to click on objects individually to find out their status, which gets pretty old on even a small filesystem.

The command line CACLS.EXE is not much better. It is some better, but still does not have a "search" mode, or an easily greppable output format - there seems to be no equivalent to "find -user" or "find -perm".

Finally, although the order of ACL entries is significant in NT, the tools (both GUI and CACLS.EXE) do not seem to provide access to the ordering. (CACLS lets you view the order, but not change it; the GUI goes so far as to sort the entries alphabetically! - misleading at best.) This is a fatal flaw, and shows that either the tools are inadequate, or the system is overdesigned. (IMHO, both.)

Windows 2000 is a bit better - the GUI at least gives you access to the "deny" half of things, and exposes the "inherit permissions" functionality which can simplify life considerably.

Unix / Linux, on the other hand, may not have ACLs, but frankly, with a few well-chosen groups you usually don't need ACLs anyway. (My evidence: AIX and IRIX do have ACLs, yet in several years of AIX/IRIX administraction, I've never actually used them, or wanted to.) And, thanks to both the simplicity of the scheme and the maturity of the tools, Unix permissions are much easier to manage than NT ACLs, in my experience. (Speaking of which, I may as well admit some serious bias, since I've had a lot more experience managing Unix than NT.)

kbuild 2.5

[DemENtoR]

As i remember reading on kerneltrap.org a little while ago kbuild 2.5 one is done, the only thing thats stoping it form being in the release is Linus, i rember reading that he dosn't like big kernel patches so he is makeing Keith Owens submit it pice by pice, i don't know but makeing picers of the new kbuild be compatible with kbuild 2.5 is takeing a lot of time from bug testing/stabilzing 2.5. Quoute from kerneltrap.org: "fear Keith might go SPC if this had to wait for 2.7"

i know this might be in the wrong place

[Anonymous Coward]

i know this might be in the wrong place but crap, forget about the kernel for a moment and focus on the FONTS issue with X.

Re:i know this might be in the wrong place

[chez69]

My fonts look fine in X.

It's a bug not a feature

[Joe Enduser]

Swapping floppies in Windows has desasterous effects on the data on both media, if there are any documents open.

I've seen years of work being destroyed, working at the university's help desk, because our users were able to do this. It shows the cynical side of Windows' user-friendliness.

But I admit, I had to learn to appreciated mount myself. Joke opportunities helped a lot though :)

Why was UltraDMA requiring of new code?

[Inoshiro]

Because the hardware supports new features. You can use it in "dumb" mode, like you can run a 180gb Maxtor in PIO4 mode, but you're not getting your best use out of it (in this case, better speeds, cable detection, hotplug, etc).

Linux

[Freddy_K]

What are the most exciting things currently being worked on for Linux?

What about a bootable cd?

[Anonymous Coward]

Wouldn't that work?