Why not develop a speedy drive that can slow itself down if it starts to generate too much heat or if it's not being used (as opposed to shutting it completely off)? I assume it's probably much easier to create a single speed motor than a variable speed one, but what would the disadvantages be?
The heads in your hard drive fly above the surface of the media due to the circulating air inside of the harddrive. Typically the heads are also engineered to fly at a specified height at all times given a specified amount of air moving through the drive. If you slowed the drive down the head would most likely fly lower or not fly at all, this would be quite bad for your data and the head.
Hard drive spindle motors are variable speed and are typically servo controlled for speed. Adjusting the speed wouldn't be a big deal except for the above.
Why does everyone always scream when this stuff happens? The EULA give them permission to make your computer their bitch. The solution is to read the EULAs and be aware of what they say, OR don't agree to them. Buyer beware.
If they would only accept patches
on
Gaim For Windows
·
· Score: 1
to Gaim. The patch tracker has patches from 6-8 months ago that haven't been processed/removed yet.
It may appear that IDE drives get new tech first due to their much lower development cycles so you tend to see more change. In reality the tech used in IDE drives is the cheapest that can run reliably and perform reasonably well. SCSI drives on the other hand are the Porches of drives. Much higher performance, tighter tolerances in parts, more strict reliabilty testing etc.
Perhaps the Internet does not in fact contain all the information in the world? Or if so, it's not all in a language we all can understand?
The claim was that there are self-sharpening razor blades and that the technology is being held down by Gillette. I don't think I'm going too far out on a limb by saying that if this was true there should be information out on the net that will shed some light on the issue. The poster can feel free to respond with any source, whether it be printed or not. Until then I'll just put this in the same bucket with the great flood, 100mpg cars in the 60's and the falsified moon landings.
What I don't get from the article is why performance and compatibility is so poor, given that WINE is a virtual machine, according to its circular acronym ("WINE Is Not an Emulator"). Sounds like WINE doesn't link very well to the existing native hardware. Wine is NOT an emulator and thus also NOT a virtual machine. It's a reimplementation of the Windows API. Performance is much more of an algorithm and interface to native libraries/systems(X11) issue, not that of interfacing to hardware.
Playing most games inside of a pc emulator is going to be nearly impossible due to poor performance.
As far as being slow there have been great leaps in performance in WineX as far as games are concerned. As Wine continues to evolve it's performance should be able to get pretty darn close to that of windows and even now you'll hear of people getting equivalent or higher fps in Half-life under wine than under windows.
Transgaming's WineX is indeed based on Wine but I think it's appropriate for them to keep their changes proprietary. They have spend over a year and a half reimplementing DirectX, implementing copy protection support and improving performance, they should rightly get something for their effort. And afaik they are still offering to give back all of their changes, less the copy protection ones due to DMCA and NDA issues, if they get enough subscribers.
Tell that to Dmitry or Bruce Perens' employer HP. The DMCA really is being used to intimidate people doing legitimate research like Prof. Felten's group and providing information necessary for compatibility purposes(decss etc).
I wouldn't worry too much about Apple taking over anytime soon. As far as freedom goes, if Apple had their choice they would be just like Microsoft except you would also have to get your hardware from them.
When I installed the KDE3 experimental packages under debian I didn't read any release notes, had no performance issues and in fact felt like I recieved an "upgrade" from a lesser developed gui. I'm just not impressed with the look and feel of the gnome desktop. The controls are a bit boxish looking even. I'm just glad we have KDE to fall back on.
There's an old saying, those who live in glass houses shouldn't throw stones. There's not much in Linux that didn't come (ported or copied) from Minix, the original BSD, SVR4 or a commercial Unix. And on the applications side, KDE from CDE, GIMP from Photoshop, Octave from Matlab, etc. etc.
The difference is that you don't see many Linux people raving about the innovation of symlinks, databased file systems or other ideas that are dozens of years old. MS on the other hand consistently claims that their innovation drives the whole computer industry.
Apple, once thought dead, is back and better than ever, and yelling a fierce battle cry (http://www.apple.com/switch/). Apple has pulled off the impossible and put UNIX on the desktop. Where they go, the others follow, so expect many repetitions of that miracle shortly.
As much as I think its cool to have Apple competing with MS their biggest wish is that you were stuck with their operating system AND their hardware. Once thought dead? They'll be dead until they start running on x86 and other hardware.
"Straightforward read/write tests in a single user environment." hardly specifies whether the tests are sequential or random. Single user could mean a single process or dozens of processes on the same machine. Single user only really means that the machine has a chance of not being loaded 100% at any given time, something that has to be accounted for in a system used by many multiple users.
I'd like to see what benchmarks they are using to compare the performance of SCSI and IDE drives. For instance whether they are comparing sequential read/write or random read/write.
Take a comparison between Maxtors DiamondMax Plus D740x and a Fujitsu MAM3367MC/MP:
DiamondMax Plus D740x 7200 rpm 8.5ms average seek time 41MB/s(OD) to 25MB/s(ID) sequential transfer rates 145 IOMeter heavy load(should be about the same depth as the database index measurement)
Fujitsu MAM3367MC/MP: 15000 rpm 3.5ms average seek time 57MB/s(OD) to 44MB/s(ID) sequential transfer rates 364.34 IOMeter database index
Even if these specs are off by a few percent we can see that for sequential workloads with low queue depth that IDE and SCSI are about the same. IDE wins on price, SCSI wins on overall data integrity and drive reliability.
For random workloads however SCSI is far faster than IDE in general due to the much lower seek time. Random workloads also often tend to have very deep queue depths, sometimes 32+ commands are queued. IDE drives don't perform command queing. Because of a SCSI drives command queuing the drive can internally reorder seeks. This gives a very large performance gain. Rotational latency is a huge factor in seek time, this is why 15k rpm beats out 7200rpm with random workloads.
The article could have been a bit more descriptive when it described why they claim IDE drives perform better than SCSI although it appears clear that it is due to the typical sequential workload of their application.
"This law would be something the left would devise"
Uh... left == liberal == free thinking and open minded. Senator Hollings is basically a republican in disguise since he is promoting the corporate agenda of content control that the media companies want. I'm all for them controling their content but lets have them come up with a better way of doing so since unlike things that cause serious damage, like guns and cars, I don't think we need to legislate content control technologies. On top of the fact that they are less than likely to work considering the dropped ball on CSS and SDMI.
Is there any work being done to build a database file system for Linux and other os's? I know I have a hell of a time navigating through my mp3s and it would sure be nice to be able to assign attributes to them(rock+favorite+2002) so you could just search on 'favorites and rock' for instance and have a playlist. A database filesystem should also simplify the task of managing files since you could sort them by adding attributes.
I think this is the thought of most of the Wine developers. While people are screaming about how any kind of GPL license takes away the freedoms of use the truth is that most of us Wine developers don't want to give full freedom to use Wine anyway they choose. I certainly would like to see companies use Wine and be forced by the license to contribute their improvements back at some point in time.
Right... why not judge the two based on some kind of technical merit, like their features? And it would really be nice if the debian people and the redhat people got together and standardized on the next generation package format that they would both be happy with.
Certainly TransGaming will see this as a very important game to support. With TransGamings current patch Wine can run some of the very latest games and development appears to be moving foward rapidly.
Support Wine by developing, testing or bug reporting.
Assuming of course that they load the bios data into memory and then execute this code to unencrypt itself. They might have specific hardware built into a chip on the board that is performing this encryption/decryption so if you wanted to put LinuxBIOS on the board you would have to encrypt it using the same mechanism they do, and then put it in the flash part. Also, since they might not be using a standard chipset it is questionable as to whether a straight PC bios will even work on the xbox, something xbox specific would more than likely have to be written and would require a bit more knowledge about the chipset and other components.
Even if you can't read the bios flash part it is important in understanding how the device starts up. Chances are that if you can get your own executable onto the box you should be able to do whatever you choose and install some sort of interface that will allow for continued hacking/exploring. Knowing whats in the bios might also allow for changing the harddrive out, or having the ability to use the other 64MB ram footprint on the pcb.
Slightly less than the entire keyspace might be a reduction by half of the work required. The smaller keyspace made the already weak DES a bit weaker, and hence the scramble for AES;-)
Why not develop a speedy drive that can slow itself down if it starts to generate too much heat or if it's not being used (as opposed to shutting it completely off)? I assume it's probably much easier to create a single speed motor than a variable speed one, but what would the disadvantages be?
The heads in your hard drive fly above the surface of the media due to the circulating air inside of the harddrive. Typically the heads are also engineered to fly at a specified height at all times given a specified amount of air moving through the drive. If you slowed the drive down the head would most likely fly lower or not fly at all, this would be quite bad for your data and the head.
Hard drive spindle motors are variable speed and are typically servo controlled for speed. Adjusting the speed wouldn't be a big deal except for the above.
Why does everyone always scream when this stuff happens? The EULA give them permission to make your computer their bitch. The solution is to read the EULAs and be aware of what they say, OR don't agree to them. Buyer beware.
to Gaim. The patch tracker has patches from 6-8 months ago that haven't been processed/removed yet.
It may appear that IDE drives get new tech first due to their much lower development cycles so you tend to see more change. In reality the tech used in IDE drives is the cheapest that can run reliably and perform reasonably well. SCSI drives on the other hand are the Porches of drives. Much higher performance, tighter tolerances in parts, more strict reliabilty testing etc.
Chris
Perhaps the Internet does not in fact contain all the information in the world? Or if so, it's not all in a language we all can understand?
The claim was that there are self-sharpening razor blades and that the technology is being held down by Gillette. I don't think I'm going too far out on a limb by saying that if this was true there should be information out on the net that will shed some light on the issue. The poster can feel free to respond with any source, whether it be printed or not. Until then I'll just put this in the same bucket with the great flood, 100mpg cars in the 60's and the falsified moon landings.
Religious people in general tend to be people that are good at dismissing logic, they replace it with faith. Who knows what they might do?
Link? Or is this just another unsubstantiated urban legend?
What I don't get from the article is why performance and compatibility is so poor, given that WINE is a virtual machine, according to its circular acronym ("WINE Is Not an Emulator"). Sounds like WINE doesn't link very well to the existing native hardware.
Wine is NOT an emulator and thus also NOT a virtual machine. It's a reimplementation of the Windows API. Performance is much more of an algorithm and interface to native libraries/systems(X11) issue, not that of interfacing to hardware.
Playing most games inside of a pc emulator is going to be nearly impossible due to poor performance.
As far as being slow there have been great leaps in performance in WineX as far as games are concerned. As Wine continues to evolve it's performance should be able to get pretty darn close to that of windows and even now you'll hear of people getting equivalent or higher fps in Half-life under wine than under windows.
Transgaming's WineX is indeed based on Wine but I think it's appropriate for them to keep their changes proprietary. They have spend over a year and a half reimplementing DirectX, implementing copy protection support and improving performance, they should rightly get something for their effort. And afaik they are still offering to give back all of their changes, less the copy protection ones due to DMCA and NDA issues, if they get enough subscribers.
Tell that to Dmitry or Bruce Perens' employer HP. The DMCA really is being used to intimidate people doing legitimate research like Prof. Felten's group and providing information necessary for compatibility purposes(decss etc).
Winex only feeds some patches back into mainline wine, codeweavers on the other hand feeds all of their patches back as far as anyone can tell.
I wouldn't worry too much about Apple taking over anytime soon. As far as freedom goes, if Apple had their choice they would be just like Microsoft except you would also have to get your hardware from them.
When I installed the KDE3 experimental packages under debian I didn't read any release notes, had no performance issues and in fact felt like I recieved an "upgrade" from a lesser developed gui. I'm just not impressed with the look and feel of the gnome desktop. The controls are a bit boxish looking even. I'm just glad we have KDE to fall back on.
There's an old saying, those who live in glass houses shouldn't throw stones. There's not much in Linux that didn't come (ported or copied) from Minix, the original BSD, SVR4 or a commercial Unix. And on the applications side, KDE from CDE, GIMP from Photoshop, Octave from Matlab, etc. etc.
The difference is that you don't see many Linux people raving about the innovation of symlinks, databased file systems or other ideas that are dozens of years old. MS on the other hand consistently claims that their innovation drives the whole computer industry.
Apple, once thought dead, is back and better than ever, and yelling a fierce battle cry (http://www.apple.com/switch/). Apple has pulled off the impossible and put UNIX on the desktop. Where they go, the others follow, so expect many repetitions of that miracle shortly.
As much as I think its cool to have Apple competing with MS their biggest wish is that you were stuck with their operating system AND their hardware. Once thought dead? They'll be dead until they start running on x86 and other hardware.
"Straightforward read/write tests in a single user environment." hardly specifies whether the tests are sequential or random. Single user could mean a single process or dozens of processes on the same machine. Single user only really means that the machine has a chance of not being loaded 100% at any given time, something that has to be accounted for in a system used by many multiple users.
I'd like to see what benchmarks they are using to compare the performance of SCSI and IDE drives. For instance whether they are comparing sequential read/write or random read/write.
Take a comparison between Maxtors DiamondMax Plus D740x and a Fujitsu MAM3367MC/MP:
DiamondMax Plus D740x
7200 rpm
8.5ms average seek time
41MB/s(OD) to 25MB/s(ID) sequential transfer rates
145 IOMeter heavy load(should be about the same depth as the database index measurement)
Fujitsu MAM3367MC/MP:
15000 rpm
3.5ms average seek time
57MB/s(OD) to 44MB/s(ID) sequential transfer rates
364.34 IOMeter database index
Even if these specs are off by a few percent we can see that for sequential workloads with low queue depth that IDE and SCSI are about the same. IDE wins on price, SCSI wins on overall data integrity and drive reliability.
For random workloads however SCSI is far faster than IDE in general due to the much lower seek time. Random workloads also often tend to have very deep queue depths, sometimes 32+ commands are queued. IDE drives don't perform command queing. Because of a SCSI drives command queuing the drive can internally reorder seeks. This gives a very large performance gain. Rotational latency is a huge factor in seek time, this is why 15k rpm beats out 7200rpm with random workloads.
The article could have been a bit more descriptive when it described why they claim IDE drives perform better than SCSI although it appears clear that it is due to the typical sequential workload of their application.
"This law would be something the left would devise"
Uh... left == liberal == free thinking and open minded. Senator Hollings is basically a republican in disguise since he is promoting the corporate agenda of content control that the media companies want. I'm all for them controling their content but lets have them come up with a better way of doing so since unlike things that cause serious damage, like guns and cars, I don't think we need to legislate content control technologies. On top of the fact that they are less than likely to work considering the dropped ball on CSS and SDMI.
Is there any work being done to build a database file system for Linux and other os's? I know I have a hell of a time navigating through my mp3s and it would sure be nice to be able to assign attributes to them(rock+favorite+2002) so you could just search on 'favorites and rock' for instance and have a playlist. A database filesystem should also simplify the task of managing files since you could sort them by adding attributes.
I think this is the thought of most of the Wine developers. While people are screaming about how any kind of GPL license takes away the freedoms of use the truth is that most of us Wine developers don't want to give full freedom to use Wine anyway they choose. I certainly would like to see companies use Wine and be forced by the license to contribute their improvements back at some point in time.
Right... why not judge the two based on some kind of technical merit, like their features? And it would really be nice if the debian people and the redhat people got together and standardized on the next generation package format that they would both be happy with.
Certainly TransGaming will see this as a very important game to support. With TransGamings current patch Wine can run some of the very latest games and development appears to be moving foward rapidly.
Support Wine by developing, testing or bug reporting.
Assuming of course that they load the bios data into memory and then execute this code to unencrypt itself. They might have specific hardware built into a chip on the board that is performing this encryption/decryption so if you wanted to put LinuxBIOS on the board you would have to encrypt it using the same mechanism they do, and then put it in the flash part. Also, since they might not be using a standard chipset it is questionable as to whether a straight PC bios will even work on the xbox, something xbox specific would more than likely have to be written and would require a bit more knowledge about the chipset and other components.
Even if you can't read the bios flash part it is important in understanding how the device starts up. Chances are that if you can get your own executable onto the box you should be able to do whatever you choose and install some sort of interface that will allow for continued hacking/exploring. Knowing whats in the bios might also allow for changing the harddrive out, or having the ability to use the other 64MB ram footprint on the pcb.
Slightly less than the entire keyspace might be a reduction by half of the work required. The smaller keyspace made the already weak DES a bit weaker, and hence the scramble for AES ;-)