Maybe I should read the code in my spare time to see what is actually being done but I doubt that the performance impact is that bad as it is written in ext3. I can see it being a problem BUT again for instance if we have solid state hard drives then the approach would be different again... this is why IMHO the storage makers can sit there and twiddle, optimize their hard drive because THEY know the timings of disk rotation (or whatever lies beneath) and how much they can write and when (maybe I am on a much lower level here and not particularly focused about the atime which at the end of the day feels to me like a fringe optimization... or rather a premature optimization to make it more esoterically implemented.)
Now I am all for better performing file systems BUT not at the expense of harder to read and understandable code because from a maintenance point of view it isn't viable in the long run... but I digress.
Having used Irix, Solaris, BSD, HP-UX, Linux in various forms and with their evolving file systems it makes more sense to me going with some form of RAID and get significant performance increase that way... it definitely helps with those 50 GByte compressed log files of mine... on the other hand if I even get the slightest I/O wait states because the OS I am running insists on seek thrashing then I will be violently vocal about it... like the first couple of FFS implementations for the Amiga back in the day. I never saw the implementation code wise for it but I believe the spirit is living on in some weird fashion in the BSD kernel now... and I can understand in that case why switching off atime might be a performance optimization to "recon" with on that platform. Now I can't categorically say that this is the case for all platforms.
Mountain Dew Moment: one can with a simple excessive use of fflush bring down the mightiest systems if the file system tries to be TOO intelligent on behalf of the user.
It doesn't need to know anything of the underlying data structures to determine for itself when it is optimal to write to disk or to supply the reader by already cached data. I mean do we handle CPU cache specifically? No it would be very inefficient to do so. Same goes with HD as far as I am concerned. Also by doing it in HW it is far more superior because it is VERY time critical. Not only that but each HD manufacturer would have different approach to optimize how things are interacted with. On the other hand I do come from the SCSI "camp" and have looked at both ATA and SATA with some "disdain" BUT its getting there... slowly.
Personally I would rather want this kind of optimization in the HW layer of the HD. The HD should know when to write or not to optimize speed. With this approach the HD manufacturers can differentiate themselves and its up to the consumer to buy what they need. To place code in the kernel to mimic esoteric HD implementations would be good BUT I will always go with a HW implementation if there is one. Testing environments don't need it but production environments sure do.
But having said that... the BSD switch to disable atime would be a good approach because ultimately you either care about atime A-LOT or not at all.
So you exchange a write near the read head by having the atime index someplace else and causing a 2 * ~8 ms seek.... what? NO NO NO not on my machine you are not;-)
I dunno... once the game has been completed its no fun anymore... for instance I never play GT1-3 nor GTA1-3 anymore. And its not like it's a retro binge back to Outrun, Gauntlet, Commando, 1943...
Well... do you really still play PS-One games? How often? If its seldom you could have your PS-One in the closet and take it out when you want to go on a retro binge.
I am not playing my PS-2 anymore for instance... and buying games on old technology is not very cost effective.
are very social types and being "social" with hardware is not a trait usually bestowed upon them in the slightest. And reading up on "Women are from venus..." it is quite evident that IT is more of a cave dweller occupation than anything else.
I don't think this is bad because ultimately it is good to have balance in nature.
Has anyone conversed with a woman that has EVER been "one with the machine" ? I am sure they can be counted quite easy.
Its typical in Zonk's topics that something like this gets 0 as mod point.
As you said choosing scheduler can be done in kernel building so all this mud flinging is assanine IMHO and just shows how little so called gamers know what Linux is capable of.
I mean common the very notion of the cell processor was highly propagated in the media since 5 seconds of the PS2 launch and that PS3 would be based on a multi processor system.
These parasites and other that do the same should stop their disruptive business practices and begin working for real.
but it would indicate that there is 50+ Million Linux installs. Personally I have 6 devices with UNIX/GNU-Linux underpinnings. So... 10+ Million people. And if all are as hard core then there is nothing to worry about regarding the big anthill.
Having run beagle (0.2.7-9) on my 300+ GByte $HOME a year ago or so was clearly an indication that it wasn't good enough... it kept on reindexing all the time... causing HD thrashing (even on a RAID0 with 200MB/s throughput.) Granted it was mostly after updates that happened and it isn't a 1.0 release but still.
I am now testing GDLinux and it feels much more sane and does not contain wine nor mono which I am quite happy with.
612243 is less than 1030728 by a good margin but I guess anyone above 100 is "new here"
Microsoft can implement or use any of the GPL code that exist as long as they feed any changes done to the code back to the community. This would be perfectly legal, not doing so is bad. So again the reason is even more clear to me why they are after striking these deals. I can categorically say that Microsoft does have code that implements patents that are not theirs and that are most probably held by IBM/HP and where Microsoft is explicitly using GPL code without feeding back changes to the community. So your dismissal that code isn't the issue is wrong, it is very much the issue. The whole event that SCO has hitherto failed to prove anything regarding any infractions is a clear indication on what level of difficulty the entire matter is. So instead of Microsoft being their usual aggressive and just passive aggressive like this, Microsoft can make sure that they are still relevant in a GPL environment. Anybody that has followed the evolution of GNU/Linux closely will without a doubt say that progress is far far greater in the OSS camp then in any other software camp (from my "desktop" point of view the latest distros are at par with Mac 10.3.9 usability... and yes I have exclusively used Linux desktop since 1996 (RedHat1.2
Slashdot Mirror
Wow that definitely puts the Microsoft Novell deal in a MUCH clearer light... ok who is whos biatch now?
NotSQL pronounced like "NotSoCool"
drumroll ka czhhhhhhhhhhh
Maybe I should read the code in my spare time to see what is actually being done but I doubt that the performance impact is that bad as it is written in ext3. I can see it being a problem BUT again for instance if we have solid state hard drives then the approach would be different again... this is why IMHO the storage makers can sit there and twiddle, optimize their hard drive because THEY know the timings of disk rotation (or whatever lies beneath) and how much they can write and when (maybe I am on a much lower level here and not particularly focused about the atime which at the end of the day feels to me like a fringe optimization... or rather a premature optimization to make it more esoterically implemented.)
Now I am all for better performing file systems BUT not at the expense of harder to read and understandable code because from a maintenance point of view it isn't viable in the long run... but I digress.
Having used Irix, Solaris, BSD, HP-UX, Linux in various forms and with their evolving file systems it makes more sense to me going with some form of RAID and get significant performance increase that way... it definitely helps with those 50 GByte compressed log files of mine... on the other hand if I even get the slightest I/O wait states because the OS I am running insists on seek thrashing then I will be violently vocal about it... like the first couple of FFS implementations for the Amiga back in the day. I never saw the implementation code wise for it but I believe the spirit is living on in some weird fashion in the BSD kernel now... and I can understand in that case why switching off atime might be a performance optimization to "recon" with on that platform. Now I can't categorically say that this is the case for all platforms.
Mountain Dew Moment: one can with a simple excessive use of fflush bring down the mightiest systems if the file system tries to be TOO intelligent on behalf of the user.
Formed while listening to Rubicon - VNV Nation
It doesn't need to know anything of the underlying data structures to determine for itself when it is optimal to write to disk or to supply the reader by already cached data. I mean do we handle CPU cache specifically? No it would be very inefficient to do so. Same goes with HD as far as I am concerned. Also by doing it in HW it is far more superior because it is VERY time critical. Not only that but each HD manufacturer would have different approach to optimize how things are interacted with. On the other hand I do come from the SCSI "camp" and have looked at both ATA and SATA with some "disdain" BUT its getting there... slowly.
Personally I would rather want this kind of optimization in the HW layer of the HD. The HD should know when to write or not to optimize speed. With this approach the HD manufacturers can differentiate themselves and its up to the consumer to buy what they need. To place code in the kernel to mimic esoteric HD implementations would be good BUT I will always go with a HW implementation if there is one. Testing environments don't need it but production environments sure do.
But having said that... the BSD switch to disable atime would be a good approach because ultimately you either care about atime A-LOT or not at all.
It will go directly to goats.ex without passing go?
Well I would say that file inodes may be closer to file and thus possibly in cache BUT granted that would be an assumption that may not be a good one.
So you exchange a write near the read head by having the atime index someplace else and causing a 2 * ~8 ms seek.... what? NO NO NO not on my machine you are not ;-)
I dunno... once the game has been completed its no fun anymore... for instance I never play GT1-3 nor GTA1-3 anymore. And its not like it's a retro binge back to Outrun, Gauntlet, Commando, 1943...
Well... do you really still play PS-One games? How often? If its seldom you could have your PS-One in the closet and take it out when you want to go on a retro binge.
I am not playing my PS-2 anymore for instance... and buying games on old technology is not very cost effective.
I knew there was a reason for a tinfoil hat!
ROFL a good one... thanks!
are very social types and being "social" with hardware is not a trait usually bestowed upon them in the slightest. And reading up on "Women are from venus..." it is quite evident that IT is more of a cave dweller occupation than anything else.
I don't think this is bad because ultimately it is good to have balance in nature.
Has anyone conversed with a woman that has EVER been "one with the machine" ? I am sure they can be counted quite easy.
Still why did they wait so long? Is it maybe because their stuff is over priced and nobody wants it?
Sorry for being a hard ass but such is life.
Its typical in Zonk's topics that something like this gets 0 as mod point.
As you said choosing scheduler can be done in kernel building so all this mud flinging is assanine IMHO and just shows how little so called gamers know what Linux is capable of.
I mean common the very notion of the cell processor was highly propagated in the media since 5 seconds of the PS2 launch and that PS3 would be based on a multi processor system.
These parasites and other that do the same should stop their disruptive business practices and begin working for real.
but it would indicate that there is 50+ Million Linux installs. Personally I have 6 devices with UNIX/GNU-Linux underpinnings. So... 10+ Million people. And if all are as hard core then there is nothing to worry about regarding the big anthill.
Err.. you misspelled n1nc0mp00p
in Airplane II where the warning light is flashing with a man with a shovel behind a bull.
I read the headline as if they had made Silicon based life... synthetic oil being silicon and all.
What about those users that have a transient vmware instance of an OS that only does one banking session at a time and get "shred -v -n 25 -z -u" 'ed?
Having run beagle (0.2.7-9) on my 300+ GByte $HOME a year ago or so was clearly an indication that it wasn't good enough... it kept on reindexing all the time... causing HD thrashing (even on a RAID0 with 200MB/s throughput.) Granted it was mostly after updates that happened and it isn't a 1.0 release but still.
I am now testing GDLinux and it feels much more sane and does not contain wine nor mono which I am quite happy with.
'Join the off-world colonies. A chance to begin again in a new
exciting world of opportunity and adventure!'
an oh mods... that would be Bladerunner.
It doesn't need an SDK because it is the SAME as the OS SDK? (drop down tab... compile for iPhone kinda deal.)
hmm... html tags....
612243 is less than 1030728 by a good margin but I guess anyone above 100 is "new here"
Microsoft can implement or use any of the GPL code that exist as long as they feed any changes done to the code back to the community. This would be perfectly legal, not doing so is bad. So again the reason is even more clear to me why they are after striking these deals. I can categorically say that Microsoft does have code that implements patents that are not theirs and that are most probably held by IBM/HP and where Microsoft is explicitly using GPL code without feeding back changes to the community. So your dismissal that code isn't the issue is wrong, it is very much the issue. The whole event that SCO has hitherto failed to prove anything regarding any infractions is a clear indication on what level of difficulty the entire matter is. So instead of Microsoft being their usual aggressive and just passive aggressive like this, Microsoft can make sure that they are still relevant in a GPL environment. Anybody that has followed the evolution of GNU/Linux closely will without a doubt say that progress is far far greater in the OSS camp then in any other software camp (from my "desktop" point of view the latest distros are at par with Mac 10.3.9 usability... and yes I have exclusively used Linux desktop since 1996 (RedHat1.2