Very likely, yes. Ext2 recovery techniqes are well known, documented, and tools exist (if rudimentary) for recovering files from it. I believe that this translates well to ext3.
Also, if you want someone to recover the data and you're willing to drop some money on it...I strongly suspect that there are people on the reiserfs team that would take on a recovery job quite happily. No one knows reiser better!
That being said, there is currently no good, easy-to-use, powerful recovery tool for Linux filesystems, rather depressingly. Now, you *could* argue that this is because the filesystems are so great, but even so...
This kind of priority is best suited for real-time processes that have real-time needs for disk access.
Yeah. Like my mp3 player.:-)
It's not sufficient to do it just in the file system...With Fibre Channel devices supporting a good-sized output queue, it is important to utilize the priority queuing supported by the disk channel vlsi chip.
This isn't Serial ATA or anything. Plain old vanilla ATA. No command queuing.:-)
Still not as technically elegant as I would have liked, but *damn*! Changing the read elevator max latency from 8192 to 32 makes a tremendous difference. No more breakups with the workloads I mentioned!
A honeypot is certainly not a free wireless access point. Well, a free wireless access point could in *theory* be a honeypot.
Normally, a honeypot is an apparently vunerable system or network that you deliberately leave around to catch the eye of hackers, usually to monitor them or to grab lists of IPs to block.
As it happens, you were right -- in the end, I ended up doing open source, which was fun, and felt a lot more productive. And I don't claim that cracking software is great job training. It's simply that it's too often villanized, it isn't all that bad, and lots of the people now writing software used to crack, or at least pirate software.
As for cracking software legally, it certainly isn't possible in the United States.:-)
Cost to produce (in both money and time) have also increased a great deal, making the risk of funding a large video game project very high...
Sure, but that's talking about the symptom, not the problem. Invest less money in each game! Have a smaller budget! Make smaller game projects!
I mean, how much does FMV add to most games? And yet, most have expensive CGI (*cough* Blizzard), voice actors and a whole squadron of artists just for cut scenes. You see them once. You're impressed with the tech. And then you don't watch them after the first four or so times. How much bang for the buck are you getting there?
What happened to Pac-Man? The above-view shooters with a little airplane that could put out about 100 times its mass in weaponry every second or so? Platform games, like Mario? Side scrolling shooters, like R-Type? These were *fun*! People went back and played them over and over and over. And they didn't cost a hundred million dollars to make.
There used to be a lot of innovation to get the games made. People from Sillicon Beach sat outside an Air Force base with microphones to get recordings for their old Mac combat games. In Myst, the Miller brothers didn't just sit on their butts as game designers -- they grabbed a cheap green screen and acted the part of all the characters. As a matter of fact, for a long time random employees of game companies *were* frequently grabbed to do voices or sound effects. There were no huge sound studios. There weren't big engine licensing fees, and the idea of a game selling for $60 or $70 would have been ludicrous.
What happened to all that? Yes, games look more realistic. Yes, there are more polygons. But are they really, honestly, more fun?
Actually, does anyone know of a website that keeps track of the few retro-style games around? I'd like to see if I can pick some up.
Retro's gotten a bad name, because too often it translates to endless Tetris knockoffs or buggy junk. But it's the closest thing to what I'm trying to talk about.
See, "retro" isn't exactly what I'm thinking of either. Modern, low budget games would be someone different than older low budget games. There are more pixels to work with -- screens are higher res. At least low end 3d cards are common. The days of paletted colors are gone. But because you have those things...why does everyone feel the need to blow so much money making their games?
Whoops -- a little free with terminology. The mp3 player should be "getting 100 context switches to itself". "Seeing 100 context switches" sounds like there's only 100 per second on the whole system.:-)
The skipping is caused by scheduling latency, as Paul suggests.
I can stand behind my claim that it isn't. I've had multiple processes running loops with the same priority running, plus flipping around in X (which I keep at nice -10) to test specifically this, and even with my CPU at 100% load, things stay okay.
*Only* heavy, long term disk activity causes this. I even tried jacking the mp3 player up to nice -20...that's not it.
I had a friend run the same test on his SuSE box with Reiser and 2.4.18 -- same problem, at least as vulnerable. It isn't the filesystem, it's the disk scheduling.
This also isn't short term "blips" -- even if you have other processes eating CPU time, the mp3 player should be getting CPU time frequently. I have #define HZ 1000, and if there is one other process running, I should be seeing 500 context switches a second. Take into account a few extremely low daemons, and you still are getting a good 100 context switches a second. That's way more than enough. I'm talking about a total mp3 dropout for *many seconds*.
In short, the soundcard will be starved of ready to play PCM data long before the decoder will be starved of MP3 encoded data (from disk).
I agree. However, in my case, CPU is nowhere near a scarce resource, but the disk is completely saturated.
I'll make you a challenge. Denice your mp3 player. Run five bash scripts doing infinite loops (while [ true ]; do done;), not niced. At least on my system, this produces no dropouts at all (though six just start to do so). Then run *one* cat process, niced to 20. It will cause dropouts (at least with the mp3 player I was testing with, mpg321, which doesn't precache the whole thing in RAM).
Furthermore, the dropouts I get with the bash scripts, CPU latency issues, are significantly different. They are very short, and sound like static -- a buffer or two wasn't filled. The dropouts I see with the nice 20 cat are far longer, lasting a second, then two, then three.
The problem is that Linux doesn't have any sense of disk scheduling priorities attached to processes. I mean, that's not egregious -- AFAIK, neither does Windows, and I haven't heard of any general purpose OS doing this (though I haven't looked around). But it would be nice, and though some workarounds exist (such as the elvtune that someone else pointed out), I have to specify that latency be emphasized for the whole disk -- what I really want to do is say that "this one process needs high disk priority".
People like to look down on cracking (of software and computers) as being evil or juvenile once they're a sysadmin/security analyst. While I'm not going to call them wrong, I suspect that a very large number of the more knowledgeable sysadmins, system coders, and whatnot out there, have at one time or another spent some time freeriding, and learned one or two technical skills in a not-so-legitimate manner. I don't think I've talked to a UNIX guy (and I'm talking about serious sorts, not the type churned out with an IS degree and little idea what they're doing) yet who's talked about this and said "No, I've never pirated software/cracked software/broken into someone's server".
I spent a lot of time cracking software back in the day. Never distributed it, and it did eat up a lot of time. However, I'm now happily using the skills that started there to do systems work. Poking at people's servers, in the same vein, breeds better security types.
You just have to realize that boys will be boys. Sure, there's mischief when you're a kid. Just because some kid defaced a web page instead of spraying graffiti at some point and the company victimized claimed tens of thousands of dollars in damages doesn't make the defacement worse than the graffiti, IMHO. As long as you learn to grow out of it, and channel what you know into useful areas, things are fine.
This is one reason I'm kind of sad to see the slow death of the freewheeling, "protect your own computer", wide open Internet. Legalisms, laws, and whatnot are showing up left and right. The laid back, long-haired sysadmins of ten years ago have become suits. The emails that techie friends and I used to regularly spoof to each other, coming from Santa Claus, the President, or others, would now land us in a federal prison. Policy is taking the place of technology, and it makes the world a less fun place.
Now if we could just get some stable NTFS read/write support...
That will only happen if Microsoft gets a court mandate to open their specifications. MS has far too much economic benefit in deliberately breaking compatibility to not do so. They've changed the ACL portion of the FS in such a way as to break the Linux NTFS driver in every single NT-line kernel release since Linux came out with an NTFS driver.
This comes secondhand, and is not a personal opinion of my own, but I think it's worth mentioning here.
I had an operating systems professor that did some filesystem design work (and DBMS design work, which at a low level and especially back in the day, was pretty similar). He was pretty negative on the mass demand for journalling filesystems.
See, what people really want is filesystems that don't get corrupt. It's also kind of nice if the recovery procedure at mount is pretty fast. So they want a filesystem that is always consistent -- it's never in a state where if the power is lost, the computer will try to mount the thing and say "hmm, this isn't a proper filesystem."
So if you want to add a file, you can't just add an entry to the table of files, then create the file metadata, than complete the filesystem operation, because you could lose power and end up with only the entry, but no filemetadata...so you have a pointer to garbage on the disk.
You need some sort of atomic updating. You want to say "at this point the change I'm making to the FS is not active, at this point it is, and nowhere in between is the FS invalid".
Journalling is one method of making atomic updating -- always write in the forwards direction on the hard drive, building a journal of all actions as you go, and just using the lastest journal entry when you're reading. Journalling tends to have pretty sexy write performance, because it always writes forward and doesn't have to seek it all. It also usually has fairly lousy read performance, since you have to be sure that you're using the most up to date journal entries.
To avoid some of the slower read performance, most "journalling" filesystems on Linux only journal metadata -- the lists of files in directories, permissions, times modified and so on, because the data is what you're really worried about accessing quickly, and if the data in a file gets corrupted when you lose power, you only lose that file -- not the whole filesystem.
It's possible to use other techniques -- I believe that BSD's FFS uses a non-journalling approach to ensuring a consistent filesystem at all points in time. Despite claims both ways, I don't believe that FFS is radically faster or slower than any of Linux's journalling filesystems.
And what's my personal preference? Well, I use ext3, because I already had an ext2 filesystem, and it's awfully easy to upgrade. ext3 used to have pretty bad performance, but now it's generally on par with ReiserFS (which was ahead for a bit), except for Reiser's strongest points (like a single directory with, say, five or six thousand files in it). That being said, I suspect that most people just use ext3 in it's "metadata journalling mode", which means that it doesn't have many advantages over reiserfs.
Ext3 builds heavily on ext2, which is a pretty mature filesystem. I've had one roommate that screwed up his reiserfs filesystem a while back. I believe the bug that caused that was fixed, but it made me a bit leery of reiser at the time.
The other misgiving I have about reiser is that I'm uncomfortable with the direction that the developers are going -- very heavyweight filesystem drivers, with plugins and all sorts of stuff. I'm not sure that I want my filesystem drivers to be so complex.
On the other hand, if you have lots of very small files (not empty, just a hundred bytes or so), Reiser does a great job of keeping them from eating up more disk space than they should (normally, you have to throw 4K or so at a file, unless you've changed the block size of your FS).
XFS, as far as I can tell, wasn't really designed so much to be a general-purpose filesystem as a streaming video filesystem.
And, as I've said earlier, I don't know a thing about JFS.
Other interesting tidbits:
* ext2 is still a pretty well-designed, fast filesystem.
* All of the mentioned Linux filesystems beat the snot out of MS's FAT-16 and FAT-32 in performance and *particularly* fragmentation. The popular act of defragmenting your hard drive on Windows stems solely from the fact that FAT was not well designed for anything but the very smallest of filesystems, like a disk.
* I've heard stories that NTFS (MS's new filesystem) is still worse off from a fragmentation point of view that Linux's FSes. That's second hand, so it could be wrong.
* I know for a fact that real-world performance on NTFS (at least in the NT 4 era) is significantly slower than on ext2. I have a strong suspicion that a fair bit of that stems from the ACL security system MS uses in their filesystems. In terms of performance, ACLs are not a good choice.
The skipping in your mp3 player has nothing to do with disk i/o. It has to do with scheduling latency.
Not true. I've done quite a bit of poking around this issue. I have plenty of spare CPU time, and I'm not using a sound server or similar. The problem comes when reading an mp3 from disk (and no, this is not a "DMA/umasked interrupts" is not on issue) and other *heavy* sequential disk i/o is being done by another piece of software (because of the amount of data, tar xzvf is frequently the culprit). Linux heavily weights disk scheduling towards overall performance, not fairness. Besides, this isn't mp3-specific -- other software does it too. Try cat/dev/zero > foo and then trying to ls a directory. Extremely long delay. Heck, try doing said operation when playing an mp3 and you'll see the skipping I'm talking about. Seriously, try it -- it takes about ten seconds to try.
I remember seeing benchmarks of various Windows audio latencies and Linux latencys, and at least the low-latency people had Linux at least a couple of ms below Windows. I wasn't aware that only some of these patches were going in, though, so that could be the difference between what we're talking about.
Punishing the duplication of some information, with zero proven *losses* (how many people *would* have purchased the software, anyway?) with over two years of jail time seems just plain idiotic.
Most univ. profs at CMU would be in jail for Xeroxing stuff left and right.
Frankly, in terms of impact to me (esp. since I use free software), I'm more concerned about legalized hacking on the part of copyright-holding corporations affecting my computer. I don't use any commercial software (got rid of xv a while ago, so I'm even clear there).
An interesting aside: Much pirated software is games. The only reason copyright exists is to encourage artists to produce, to improve society in the long term. Over the years, profits and video game budgets have shot sky-high...and yet the entertainment facter has increased very, very little. Is copyright producing the desired effect? (Note that this isn't intended to be taken as a claim that people should be able to pirate software...just a question about whether we're getting our money's worth out of copyright.)
2.6 has got me more excited than recent minor releases. Some of the things that look cool:
* ALSA support. ALSA is a pain to keep patching your kernel with every redownload. ALSA is a Good Thing, if a pain in the butt to configure. My guess is that there will be decent front ends on top of the thing when distros start shipping 2.6. * Batch priority/boosted effect of nice levels. I've always felt that "nicing" something didn't have enough effect -- nicing something by one level is almost unnoticeable. 2.6 boosts this change. It also introduces batch priority, where a process gets *no* CPU time if there is *any* non-batch process in the runnable queue. Very sexy. * Low, low latency. Just as 2.4 emphasized good multiproc support, 2.6 is emphasizing low latency. Preemptive kernel, lots of disabled-interrupt time being reduced (especially the godawful framebuffer console), etc, etc. This is top-notch for both I/O performance and multimedia. Linux kernel 2.6 is supposed to beat any current release of Windows in audio latency when released.
The only thing that I really wish Linux had was a prioritized disk scheduler. Linux can prioritize network traffic. It can prioritize processes. It just can't do the same with disk I/O. This is a shame, since I want my MP3 player not to skip when reading MP3s/paging, followed by X getting next highest priority when paging (so that the UI doesn't freeze up for long when paging something back in), and Linux just doesn't yet have the functionality. Currently, you can have a nice 20 process that's busy untarring a large tarball...and all your paged out processes will be blocked, waiting for this stupid tarball to finish.
"Omigod, what if someone sneaks one of these carp to Europe? Are you going to endanger the species globally?" The short answer is no. If someone snuck a thousand of these things to Europe and released them into the Danube, it really wouldn't make a significant impact," he says.
Actually, I think there are minuses and pluses to Marcelo's work.
It's not a lot of fun to be maintainer of a stable branch -- no glory, lots of bitching if anything breaks...and Marcelo is *young*, and could be doing other stuff.
That said, he does release releases more slowly than Linus (which might be reasonable, given that people were complaining about Linus' lack of QA in the stable branch). I do wish that he would enforce fewer things going into -rc releases, though. There should be one or two -rc releases per version, and only bugfixes in an -rc.
How would we feel if tons of Egyptians came over and took over the study of American Indian stuff and kept looting treasure from burial mounds? Even if the occasional farmer had shredded a mound with his tractor, we wouldn't say that America had lost its right to the mounds.
I used Visio commercially, hated it, and switched to Dia, which is IMHO one of the few pieces of open source software that beats the commercial alternatives (actually, haven't tried Rational Rose, which some people there seemed to like).
Slashdot Mirror
Could they have recovered from ext3?
Very likely, yes. Ext2 recovery techniqes are well known, documented, and tools exist (if rudimentary) for recovering files from it. I believe that this translates well to ext3.
Also, if you want someone to recover the data and you're willing to drop some money on it...I strongly suspect that there are people on the reiserfs team that would take on a recovery job quite happily. No one knows reiser better!
That being said, there is currently no good, easy-to-use, powerful recovery tool for Linux filesystems, rather depressingly. Now, you *could* argue that this is because the filesystems are so great, but even so...
This kind of priority is best suited for real-time processes that have real-time needs for disk access.
:-)
:-)
Yeah. Like my mp3 player.
It's not sufficient to do it just in the file system...With Fibre Channel devices supporting a good-sized output queue, it is important to utilize the priority queuing supported by the disk channel vlsi chip.
This isn't Serial ATA or anything. Plain old vanilla ATA. No command queuing.
Still not as technically elegant as I would have liked, but *damn*! Changing the read elevator max latency from 8192 to 32 makes a tremendous difference. No more breakups with the workloads I mentioned!
A honeypot is certainly not a free wireless access point. Well, a free wireless access point could in *theory* be a honeypot.
Normally, a honeypot is an apparently vunerable system or network that you deliberately leave around to catch the eye of hackers, usually to monitor them or to grab lists of IPs to block.
As it happens, you were right -- in the end, I ended up doing open source, which was fun, and felt a lot more productive. And I don't claim that cracking software is great job training. It's simply that it's too often villanized, it isn't all that bad, and lots of the people now writing software used to crack, or at least pirate software.
:-)
As for cracking software legally, it certainly isn't possible in the United States.
Cost to produce (in both money and time) have also increased a great deal, making the risk of funding a large video game project very high...
Sure, but that's talking about the symptom, not the problem. Invest less money in each game! Have a smaller budget! Make smaller game projects!
I mean, how much does FMV add to most games? And yet, most have expensive CGI (*cough* Blizzard), voice actors and a whole squadron of artists just for cut scenes. You see them once. You're impressed with the tech. And then you don't watch them after the first four or so times. How much bang for the buck are you getting there?
What happened to Pac-Man? The above-view shooters with a little airplane that could put out about 100 times its mass in weaponry every second or so? Platform games, like Mario? Side scrolling shooters, like R-Type? These were *fun*! People went back and played them over and over and over. And they didn't cost a hundred million dollars to make.
There used to be a lot of innovation to get the games made. People from Sillicon Beach sat outside an Air Force base with microphones to get recordings for their old Mac combat games. In Myst, the Miller brothers didn't just sit on their butts as game designers -- they grabbed a cheap green screen and acted the part of all the characters. As a matter of fact, for a long time random employees of game companies *were* frequently grabbed to do voices or sound effects. There were no huge sound studios. There weren't big engine licensing fees, and the idea of a game selling for $60 or $70 would have been ludicrous.
What happened to all that? Yes, games look more realistic. Yes, there are more polygons. But are they really, honestly, more fun?
Actually, does anyone know of a website that keeps track of the few retro-style games around? I'd like to see if I can pick some up.
Retro's gotten a bad name, because too often it translates to endless Tetris knockoffs or buggy junk. But it's the closest thing to what I'm trying to talk about.
See, "retro" isn't exactly what I'm thinking of either. Modern, low budget games would be someone different than older low budget games. There are more pixels to work with -- screens are higher res. At least low end 3d cards are common. The days of paletted colors are gone. But because you have those things...why does everyone feel the need to blow so much money making their games?
Whoops -- a little free with terminology. The mp3 player should be "getting 100 context switches to itself". "Seeing 100 context switches" sounds like there's only 100 per second on the whole system. :-)
The skipping is caused by scheduling latency, as Paul suggests.
I can stand behind my claim that it isn't. I've had multiple processes running loops with the same priority running, plus flipping around in X (which I keep at nice -10) to test specifically this, and even with my CPU at 100% load, things stay okay.
*Only* heavy, long term disk activity causes this. I even tried jacking the mp3 player up to nice -20...that's not it.
I had a friend run the same test on his SuSE box with Reiser and 2.4.18 -- same problem, at least as vulnerable. It isn't the filesystem, it's the disk scheduling.
This also isn't short term "blips" -- even if you have other processes eating CPU time, the mp3 player should be getting CPU time frequently. I have #define HZ 1000, and if there is one other process running, I should be seeing 500 context switches a second. Take into account a few extremely low daemons, and you still are getting a good 100 context switches a second. That's way more than enough. I'm talking about a total mp3 dropout for *many seconds*.
In short, the soundcard will be starved of ready to play PCM data long before the decoder will be starved of MP3 encoded data (from disk).
I agree. However, in my case, CPU is nowhere near a scarce resource, but the disk is completely saturated.
I'll make you a challenge. Denice your mp3 player. Run five bash scripts doing infinite loops (while [ true ]; do done;), not niced. At least on my system, this produces no dropouts at all (though six just start to do so). Then run *one* cat process, niced to 20. It will cause dropouts (at least with the mp3 player I was testing with, mpg321, which doesn't precache the whole thing in RAM).
Furthermore, the dropouts I get with the bash scripts, CPU latency issues, are significantly different. They are very short, and sound like static -- a buffer or two wasn't filled. The dropouts I see with the nice 20 cat are far longer, lasting a second, then two, then three.
The problem is that Linux doesn't have any sense of disk scheduling priorities attached to processes. I mean, that's not egregious -- AFAIK, neither does Windows, and I haven't heard of any general purpose OS doing this (though I haven't looked around). But it would be nice, and though some workarounds exist (such as the elvtune that someone else pointed out), I have to specify that latency be emphasized for the whole disk -- what I really want to do is say that "this one process needs high disk priority".
People like to look down on cracking (of software and computers) as being evil or juvenile once they're a sysadmin/security analyst. While I'm not going to call them wrong, I suspect that a very large number of the more knowledgeable sysadmins, system coders, and whatnot out there, have at one time or another spent some time freeriding, and learned one or two technical skills in a not-so-legitimate manner. I don't think I've talked to a UNIX guy (and I'm talking about serious sorts, not the type churned out with an IS degree and little idea what they're doing) yet who's talked about this and said "No, I've never pirated software/cracked software/broken into someone's server".
I spent a lot of time cracking software back in the day. Never distributed it, and it did eat up a lot of time. However, I'm now happily using the skills that started there to do systems work. Poking at people's servers, in the same vein, breeds better security types.
You just have to realize that boys will be boys. Sure, there's mischief when you're a kid. Just because some kid defaced a web page instead of spraying graffiti at some point and the company victimized claimed tens of thousands of dollars in damages doesn't make the defacement worse than the graffiti, IMHO. As long as you learn to grow out of it, and channel what you know into useful areas, things are fine.
This is one reason I'm kind of sad to see the slow death of the freewheeling, "protect your own computer", wide open Internet. Legalisms, laws, and whatnot are showing up left and right. The laid back, long-haired sysadmins of ten years ago have become suits. The emails that techie friends and I used to regularly spoof to each other, coming from Santa Claus, the President, or others, would now land us in a federal prison. Policy is taking the place of technology, and it makes the world a less fun place.
Just my two cents.
Now if we could just get some stable NTFS read/write support...
That will only happen if Microsoft gets a court mandate to open their specifications. MS has far too much economic benefit in deliberately breaking compatibility to not do so. They've changed the ACL portion of the FS in such a way as to break the Linux NTFS driver in every single NT-line kernel release since Linux came out with an NTFS driver.
This comes secondhand, and is not a personal opinion of my own, but I think it's worth mentioning here.
I had an operating systems professor that did some filesystem design work (and DBMS design work, which at a low level and especially back in the day, was pretty similar). He was pretty negative on the mass demand for journalling filesystems.
See, what people really want is filesystems that don't get corrupt. It's also kind of nice if the recovery procedure at mount is pretty fast. So they want a filesystem that is always consistent -- it's never in a state where if the power is lost, the computer will try to mount the thing and say "hmm, this isn't a proper filesystem."
So if you want to add a file, you can't just add an entry to the table of files, then create the file metadata, than complete the filesystem operation, because you could lose power and end up with only the entry, but no filemetadata...so you have a pointer to garbage on the disk.
You need some sort of atomic updating. You want to say "at this point the change I'm making to the FS is not active, at this point it is, and nowhere in between is the FS invalid".
Journalling is one method of making atomic updating -- always write in the forwards direction on the hard drive, building a journal of all actions as you go, and just using the lastest journal entry when you're reading. Journalling tends to have pretty sexy write performance, because it always writes forward and doesn't have to seek it all. It also usually has fairly lousy read performance, since you have to be sure that you're using the most up to date journal entries.
To avoid some of the slower read performance, most "journalling" filesystems on Linux only journal metadata -- the lists of files in directories, permissions, times modified and so on, because the data is what you're really worried about accessing quickly, and if the data in a file gets corrupted when you lose power, you only lose that file -- not the whole filesystem.
It's possible to use other techniques -- I believe that BSD's FFS uses a non-journalling approach to ensuring a consistent filesystem at all points in time. Despite claims both ways, I don't believe that FFS is radically faster or slower than any of Linux's journalling filesystems.
And what's my personal preference? Well, I use ext3, because I already had an ext2 filesystem, and it's awfully easy to upgrade. ext3 used to have pretty bad performance, but now it's generally on par with ReiserFS (which was ahead for a bit), except for Reiser's strongest points (like a single directory with, say, five or six thousand files in it). That being said, I suspect that most people just use ext3 in it's "metadata journalling mode", which means that it doesn't have many advantages over reiserfs.
Ext3 builds heavily on ext2, which is a pretty mature filesystem. I've had one roommate that screwed up his reiserfs filesystem a while back. I believe the bug that caused that was fixed, but it made me a bit leery of reiser at the time.
The other misgiving I have about reiser is that I'm uncomfortable with the direction that the developers are going -- very heavyweight filesystem drivers, with plugins and all sorts of stuff. I'm not sure that I want my filesystem drivers to be so complex.
On the other hand, if you have lots of very small files (not empty, just a hundred bytes or so), Reiser does a great job of keeping them from eating up more disk space than they should (normally, you have to throw 4K or so at a file, unless you've changed the block size of your FS).
XFS, as far as I can tell, wasn't really designed so much to be a general-purpose filesystem as a streaming video filesystem.
And, as I've said earlier, I don't know a thing about JFS.
Other interesting tidbits:
* ext2 is still a pretty well-designed, fast filesystem.
* All of the mentioned Linux filesystems beat the snot out of MS's FAT-16 and FAT-32 in performance and *particularly* fragmentation. The popular act of defragmenting your hard drive on Windows stems solely from the fact that FAT was not well designed for anything but the very smallest of filesystems, like a disk.
* I've heard stories that NTFS (MS's new filesystem) is still worse off from a fragmentation point of view that Linux's FSes. That's second hand, so it could be wrong.
* I know for a fact that real-world performance on NTFS (at least in the NT 4 era) is significantly slower than on ext2. I have a strong suspicion that a fair bit of that stems from the ACL security system MS uses in their filesystems. In terms of performance, ACLs are not a good choice.
The skipping in your mp3 player has nothing to do with disk i/o. It has to do with scheduling latency.
/dev/zero > foo and then trying to ls a directory. Extremely long delay. Heck, try doing said operation when playing an mp3 and you'll see the skipping I'm talking about. Seriously, try it -- it takes about ten seconds to try.
Not true. I've done quite a bit of poking around this issue. I have plenty of spare CPU time, and I'm not using a sound server or similar. The problem comes when reading an mp3 from disk (and no, this is not a "DMA/umasked interrupts" is not on issue) and other *heavy* sequential disk i/o is being done by another piece of software (because of the amount of data, tar xzvf is frequently the culprit). Linux heavily weights disk scheduling towards overall performance, not fairness. Besides, this isn't mp3-specific -- other software does it too. Try cat
I remember seeing benchmarks of various Windows audio latencies and Linux latencys, and at least the low-latency people had Linux at least a couple of ms below Windows. I wasn't aware that only some of these patches were going in, though, so that could be the difference between what we're talking about.
Punishing the duplication of some information, with zero proven *losses* (how many people *would* have purchased the software, anyway?) with over two years of jail time seems just plain idiotic.
Most univ. profs at CMU would be in jail for Xeroxing stuff left and right.
Frankly, in terms of impact to me (esp. since I use free software), I'm more concerned about legalized hacking on the part of copyright-holding corporations affecting my computer. I don't use any commercial software (got rid of xv a while ago, so I'm even clear there).
An interesting aside: Much pirated software is games. The only reason copyright exists is to encourage artists to produce, to improve society in the long term. Over the years, profits and video game budgets have shot sky-high...and yet the entertainment facter has increased very, very little. Is copyright producing the desired effect? (Note that this isn't intended to be taken as a claim that people should be able to pirate software...just a question about whether we're getting our money's worth out of copyright.)
I wonder what kind of loss of power occurs, though. I'd bet it's greater with a rechargeable mower.
Why is an environmentalist spending money and gas to chop up happily growing natural plants instead of leaving them alone?
Come to think of it, why are you growing *grass* anyway? That isn't natural for most locales...
The first time this manages to mow over someone's foot, the company is going to get sued, pay out the ass and then drop it like a hot potato.
Image recognition is cool, but there are a lot of places to perfect it on other than on self-propelled things with high-speed blades.
I mean, make the same thing but with a broom or vacuum cleaner for indoors or something. Indoors would be flatter, anyway.
They handle slopes. They aren't limited in acreage. They don't need to be recharged. They convert grass to fertilizer. Your kids will love them.
And besides, you'll have a *goat*! There are tons of people in "Do Cyborgs Dream of Electric Sheep" that would kill to be in your shoes!
2.6 has got me more excited than recent minor releases. Some of the things that look cool:
* ALSA support. ALSA is a pain to keep patching your kernel with every redownload. ALSA is a Good Thing, if a pain in the butt to configure. My guess is that there will be decent front ends on top of the thing when distros start shipping 2.6.
* Batch priority/boosted effect of nice levels. I've always felt that "nicing" something didn't have enough effect -- nicing something by one level is almost unnoticeable. 2.6 boosts this change. It also introduces batch priority, where a process gets *no* CPU time if there is *any* non-batch process in the runnable queue. Very sexy.
* Low, low latency. Just as 2.4 emphasized good multiproc support, 2.6 is emphasizing low latency. Preemptive kernel, lots of disabled-interrupt time being reduced (especially the godawful framebuffer console), etc, etc. This is top-notch for both I/O performance and multimedia. Linux kernel 2.6 is supposed to beat any current release of Windows in audio latency when released.
The only thing that I really wish Linux had was a prioritized disk scheduler. Linux can prioritize network traffic. It can prioritize processes. It just can't do the same with disk I/O. This is a shame, since I want my MP3 player not to skip when reading MP3s/paging, followed by X getting next highest priority when paging (so that the UI doesn't freeze up for long when paging something back in), and Linux just doesn't yet have the functionality. Currently, you can have a nice 20 process that's busy untarring a large tarball...and all your paged out processes will be blocked, waiting for this stupid tarball to finish.
...is that the breakdown goes something like this:
:-)
ext3:
* can be told to journal everything, including data (not just metadata) -- most theoretical reliability.
* is backwards compatible with ext2
xfs:
* tweaked for streaming large files to/from disk -- probably best at sequential reads/writes.
reiserfs:
* best performance with many, many files in a single directory.
* Can save space on very small files with -tail option
jfs:
* really don't know.
"Omigod, what if someone sneaks one of these carp to Europe? Are you going to endanger the species globally?" The short answer is no. If someone snuck a thousand of these things to Europe and released them into the Danube, it really wouldn't make a significant impact," he says.
Riiiight.
Actually, I think there are minuses and pluses to Marcelo's work.
It's not a lot of fun to be maintainer of a stable branch -- no glory, lots of bitching if anything breaks...and Marcelo is *young*, and could be doing other stuff.
That said, he does release releases more slowly than Linus (which might be reasonable, given that people were complaining about Linus' lack of QA in the stable branch). I do wish that he would enforce fewer things going into -rc releases, though. There should be one or two -rc releases per version, and only bugfixes in an -rc.
Also, he's had that one high-profile fuckup.
...the most appropriate choice was Windows...
There's a certain argument that there's a long term benefit to using free software in terms of dollars and customizability.
How would we feel if tons of Egyptians came over and took over the study of American Indian stuff and kept looting treasure from burial mounds? Even if the occasional farmer had shredded a mound with his tractor, we wouldn't say that America had lost its right to the mounds.
SLIP was done on a napkin.
I used Visio commercially, hated it, and switched to Dia, which is IMHO one of the few pieces of open source software that beats the commercial alternatives (actually, haven't tried Rational Rose, which some people there seemed to like).
It takes *forever* to enter info into Visio.