"The Florida law defines the crime as an attempt to solicit a minor: actions in the real world, not the dream realm of thought crime. In refusing to see and accept the distinction, you have fundamentally misread Orwell."
Sorry, I really have to disagree on this. In 1984, the protagonist was arrested for *attempting* to purchase antique goods, the trade of which was illegal. It was a blatent case ef entrapment, as well. The whole point of a thought crime is that the *action* is prohibited because the *thought* behind it needs to be supressed. The supression is so critical that we must go search out possible violators.
What if you exclude all of the tests which have >60% CPU use as well? Regardless of how long a test took to run, it cannot be considered to be I/O bound unless the cache hit rate is low. The biggest flaw in these tests is that he only did a 'sync' in between each test, instead of a 'umount'; all of the cache-bound results are virtually meaningless.
As another poster pointed out, I'd love to see the a set of benchmarks using CFQ v3 as well as the anticipatory I/O scheduler...
I wonder if this will destroy SunnComm's copy protected CD model? The CD installs software on a Windows machine without user permission to prevent them from accessing it directly. Obviously this can be bypassed with the infamous Shift Key "Hack" anyway, but it works for most people cause they don't know what it is doing in the background. This bill could force SunnComm to get the user's permission to install the software, and even Joe Shmoe could bypass it then.
As someone who is very interested in filesystem design, I've been following your progress and goals for a while, especially when it comes to fundamental changes in v4 and v5, and new API's. After a great deal of discussion, you managed to get a new system call all to yourself (reiser4()), so that you could experiment with new API's for advanced features. This seems like a good solution for now, because you can test stuff and refine your ideas. However, it seems that Reiser5 is going to need a complete new API.
My question is twofold. 1) Are you going to try to write a new API from scratch, even if(when) Linus doesn't like the idea of a complete new filesystem interface? 2) Would you consider porting to another plaform if necessary to have the control over the API that you need? Or even just to expand the number of supported platforms?
It think you are confusing NTFS with FAT. NTFS is a full journalling filesystem complete with large volume support, file permissions and all that. While it is not very portable or particularly fast at anything, it is stable and works very well for desktop systems. FAT, on the other hand, is so ancient it should never be used for any system other than in a museum display.
There is a big difference, and NTFS is a force to be reckoned with, although it pales in comparison with XFS.
ReiserFS is a unique(AFAIK) new design intended to boost performance for small file accesses. It is highly optimized not only to reduce the number of seeks necessary to get to a small file but also to continually re-arrange the data for faster access using very advanced(and kinda slow) algorithms. It's approach is to use spare disk and CPU time to decrease file access time. It is not focused on large files and does little optimization for them.
XFS, on the other hand, was designed with today's multimedia systems in mind. It supports systems in the millions of terabytes range, and has highly scalable, optimized data structures for metadata and journaling. Thus it is able to run on multiple CPU and RAID servers, with the intention to actually be serving multiple raw video or other high bandwidth streams. It has a special subsystem that handles Guaranteed Rate I/O, both soft(error checked) and hard(will deliver bad data if needed) data rate guarantees. I'm not sure if the GRIO stuff is fully supported in linux right now, but it requires special system calls which linux software obviously doen't have support for yet anyway.
ReiserFS and XFS are both VERY cool, but they address completely different areas of file system optimixation, desktops and multimedia servers. Use the right tool for the right task, etc. means that XFS is the only choice for high bandwidth linux data servers at this point. That's why this is a big deal.
Slashdot Mirror
"The Florida law defines the crime as an attempt to solicit a minor: actions in the real world, not the dream realm of thought crime. In refusing to see and accept the distinction, you have fundamentally misread Orwell."
Sorry, I really have to disagree on this. In 1984, the protagonist was arrested for *attempting* to purchase antique goods, the trade of which was illegal. It was a blatent case ef entrapment, as well. The whole point of a thought crime is that the *action* is prohibited because the *thought* behind it needs to be supressed. The supression is so critical that we must go search out possible violators.
What if you exclude all of the tests which have >60% CPU use as well? Regardless of how long a test took to run, it cannot be considered to be I/O bound unless the cache hit rate is low. The biggest flaw in these tests is that he only did a 'sync' in between each test, instead of a 'umount'; all of the cache-bound results are virtually meaningless.
As another poster pointed out, I'd love to see the a set of benchmarks using CFQ v3 as well as the anticipatory I/O scheduler...
I wonder if this will destroy SunnComm's copy protected CD model? The CD installs software on a Windows machine without user permission to prevent them from accessing it directly. Obviously this can be bypassed with the infamous Shift Key "Hack" anyway, but it works for most people cause they don't know what it is doing in the background. This bill could force SunnComm to get the user's permission to install the software, and even Joe Shmoe could bypass it then.
As someone who is very interested in filesystem design, I've been following your progress and goals for a while, especially when it comes to fundamental changes in v4 and v5, and new API's. After a great deal of discussion, you managed to get a new system call all to yourself (reiser4()), so that you could experiment with new API's for advanced features. This seems like a good solution for now, because you can test stuff and refine your ideas. However, it seems that Reiser5 is going to need a complete new API.
My question is twofold.
1) Are you going to try to write a new API from scratch, even if(when) Linus doesn't like the idea of a complete new filesystem interface?
2) Would you consider porting to another plaform if necessary to have the control over the API that you need? Or even just to expand the number of supported platforms?
There is a big difference, and NTFS is a force to be reckoned with, although it pales in comparison with XFS.
XFS, on the other hand, was designed with today's multimedia systems in mind. It supports systems in the millions of terabytes range, and has highly scalable, optimized data structures for metadata and journaling. Thus it is able to run on multiple CPU and RAID servers, with the intention to actually be serving multiple raw video or other high bandwidth streams. It has a special subsystem that handles Guaranteed Rate I/O, both soft(error checked) and hard(will deliver bad data if needed) data rate guarantees. I'm not sure if the GRIO stuff is fully supported in linux right now, but it requires special system calls which linux software obviously doen't have support for yet anyway.
ReiserFS and XFS are both VERY cool, but they address completely different areas of file system optimixation, desktops and multimedia servers. Use the right tool for the right task, etc. means that XFS is the only choice for high bandwidth linux data servers at this point. That's why this is a big deal.