I am a software engineer who works mainly on a Mac. I am fully aware of the existence of .DS_Store files, but it has never bothered me nearly as much as it bothers this guy.
IMHO, this falls into the category of "it's much easier to criticize someone else's design decisions than to make your own." How about you build an OS over the course of 15 years and then I can pick it apart and write hyperbolic rants about all the design details that annoy me?
I am also a software engineer who works mainly on a Mac.
Whether or not I agree with his choice to disable .DS_Store (isn't that _his_ decision, and we can just leave it be?) -- I am totally amazed at his persistence, and eventual success, to implement what he wants. The level of sophistication to live-patch a framework using mach_star is far beyond your ordinary level of interaction with the O.S. Forget about the non-portability or possible breakage on an update, this is _hacking_!
So I disagree with your rejoinder: how about you find a reasonably permanent solution to turning off .DS_Store?
I more admire his balls than his sophistication. Patching out a function called 'FlushChanges' without precisely knowing what kind of changes it flushes? I wouldn't take the chance that it does, as a side effect, increase the risk of disk corruption.
But no one is asking you to take that chance. The author notes that there seem to be no ill effects; but how else can one find out, barring some sudden forthcomingness on Apple's part, than by trying, which is exactly what the author is doing—with reports (as the article says) forthcoming in case of trouble?
IMHO, this falls into the category of "it's much easier to criticize someone else's design decisions than to make your own." How about you build an OS over the course of 15 years and then I can pick it apart and write hyperbolic rants about all the design details that annoy me?