Hi Kyle,

> This is the problem I have with mailing lists;

This is not only a problem with mailing lists, but more generally with written 
communication.

> 2/3 responses didn't go  back and read the critical bit of context to my 
> stance (but at least you 
> still included it in your quote, the other one trimmed it entirely):

I assume that the "other one trimmed it entirely" refers to my mail.  And the 
"2/3 responses" probably also.

Then, allow me to make something clear: I never respond to people before having 
read what they wrote entirely (there can be exceptions with very long texts, 
not correctly articulated ones, deficient syntax, etc., but in this case I 
normally say so; and, of course, the occasional error or omission).

This case is no different.  I trimmed the content of your first mail precisely 
because I had its content clearly in mind and didn't think it necessary to 
expose it again.  And my response mentions "(snip) at least don't without an 
option to avoid that (snip)", just a rephrasing of a small part of your first 
mail (but this was impossible to guess given the actual sentence I wrote down).

>  > [...] surprises like this from the different execution environments.
>  > This /feels/ like the kind of thing we could take an opinionated
>  > stance on, maybe providing an escape hatch of some sort if someone
>  > really wants to complain that they can't document all filenames on
>  > the system.
> 
> I don't disagree that there are probably valid cases, this is a proposal 
> of a possible change, not a change itself.  Admittedly I didn't see it 
> as likely as it apparently is, but it's not like I completely ignored 
> the possibility.

I don't think I ever disputed that you had considered another possibility at 
start.  My concern was rather to perceive a possible "assertion progression" in 
your sentences.  You started with "It might be better (snip)" (which 
incidentally you didn't repeat in the last mail), then continued with "/feels/" 
(emphasized; what for exactly?) and "we could take an opinionated stance" 
(which, yes, contains "could", but also contains "opinionated").  There is a 
mention of an "escape hatch" yes, but it disappears completely in your 
subsequent mail "(snip) my proposal is that it stops doing and we teach 
updatedb (snip)".

There are several possible interpretations for this sequence, and my response 
was only to what I consider the worst one.  Admittedly, it can look much 
stronger than what I intended because, out of brevity, I only addressed the 
interpretation that would be problematic to me, and also in part because I was 
using instant messaging quite frenetically at that moment and inadvertently 
treated the mail medium the same (a lesson for me).

A major problem of written communication is that people, especially in 
scientific/engineering settings, tend to focus on the written words so much 
that they forget that the people behind them are much bigger, with much more 
nuance and a lot more ideas, sometimes even contradictory with what they chose 
to write down, and their own mind dynamics (progression, evaluation, change of 
mind, etc.).  I think I know you enough to evaluate that you are not the type 
of guy pushing for solutions without hearing the point of view of others, which 
was another reason to omit discussing the parts we may agree on.  I'm sorry 
that you received my mail too strong than intended.

Going back to the topic, as I think the (few) responses have shown, the point 
is that '/usr/libexec/locate.updatedb' is used not only by 
'/etc/periodic/weekly/310.locate' but also by operators.  So this would call 
for:
- Not enforcing privilege dropping in '/usr/libexec/locate.updatedb', or at the 
very least provide an "escape hatch".
- Possibly moving it into '/usr/bin', along with 'locate', in which case, it 
should not do any privilege dropping by default.

Thanks and regards.

-- 
Olivier Certner

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to