From: Aaron W. LaFramboise (aaronrabiddog51_at_[hidden])
Date: 2004-11-01 15:38:24
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
> 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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk