Aleksey Gurtovoy wrote:
Could our long-time unix users confirm/negate this experience?
I don't think it is common for ANY sort of source distribution for files to be read-only. For example, are your compiler's header files read-only? Are the SDKs you normally use read-only? Is example code normally read-only?
Sure, if you know what you are doing. You are not supposed to be doing that, though, so that fact that you have to apply an extra effort here shouldn't matter. IOW, the point is that there are hardly any use cases for editing the files that came from the tarball that favor "easiness of editing", and there is a number of use cases in support of read-only status.
I have been annoyed time-after-time by the read-only Boost files. I don't understand what possible purpose there is in making the files read-only. Sure, it helps prevent accidental editing or deletion, but seriously, I think this is on par with "Oops I accidentally deleted my term paper/operating system kernel/girlfriend's picture." And why precisely are users not supposed to be editing Boost sources? I edit them all the time, as oftentimes its just the easiest way to find a bug, or figure out how something works, or fix a minor incompatibility, or whatever. Our users aren't those same people who are telling tech support during blackouts; they're computer scientists and engineers who are hopefully fully qualified for this sort of thing. And keep in mind that unlike our Emacs users, not everyone has an editor for which overriding read-only attributes is easy. On more than one occasion have I been trying to edit the read-only source files of some foolish distribution, remotely in an editor that doesn't support writing to read-only files, or shell escapes. Its a real pain, even on Windows, to have to manually browse for the offending file and change its permissions when Notepad spits back some error message about not being able to save my work. Aaron W. LaFramboise