I have an experience to share as a new contributor to unix.stackexchange.com where I sensed some slight undercurrents of prejudice. It would be great to receive a response from the moderatorsusers mentioned here but any input, technical or otherwise, from others is welcome. I was not able to respond in situ with my thoughts so pardon me for creating a new question.
Observation 1: New contributors cannot comment on their own posts [Resolved]
I attempted to contact a contributor via a minor edit to muru's lowest rated answer to question 278443 regarding the "mangled code", where he responded "you can always address editors to your post by commenting with @username". I couldn't comment, only edit, my posts. The resultant URL after clicking "comment" was: What's the POSIX way to read an exact number of bytes from a file? where the query is noredirect=1#
.
I attempted to contact a contributor via a minor edit to @muru's lowest rated answer to question 278443 regarding the "mangled code". @muru responded "you can always address editors to your post by commenting with @username". I was not able to comment, but only edit, my posts.
I was unsuccessful in commenting on my answer to question 278443. The resultant URL was What's the POSIX way to read an exact number of bytes from a file? where the query is
noredirect=1#
.
Observation 2: A possibly valid edit by a new user is ignored
Incidentally, I found a possible error in @muru'smuru's answer to question 278443 where he said that the command dd bs=1 count=1000000
"will be horrendously slow". This involved processing only 1 million bytes which would not be slow. A test on my dual-core took 1.8 seconds.
Observation 3: Logical reasoning is not always required by moderatorshigh-rep users, only statements
In my first draft of the edit to @muru'smuru's answer I realised that I had altered it too much and decided to post my own answer to question 278443. I said "a partial read by dd
with ibs=1
would be unlikely". A moderatorhigh-rep user @StephenStephen Kitt commented that "it is impossible". That comment has since been deleted but how is it impossible? For raw data without a multiple of 8 bits i.e. 0< n mod 8 <8 and ibs=1
where the block size is 1 byte or 8 bits how does dd
deal with a read of, say, 3 bits? I do not know, particularly with older media such as tape and older versions of dd
. My knowledge on dd
is limited here. If @StephenStephen Kitt had the time to explain or point to a relevant post on this topic then this would fill in the path to education could continuegaps. I have not yet found any further information to support his statement.
Observation 4: Plausible solutions by new users are disparaged
Question 278443 is "What's the POSIX way to read an exact number of bytes from a file?". I then added an option using the read
command, stating that there are limitations after testing a few successful examples. I received a comment recently from @StephenStephen Kitt saying "POSIX read is very limited, so in the context of this question, your read approach doesn’t work". "Limited" and "doesn't work" are mutually exclusive mathematical probabilities. In the context of the question, read
is a built-in command of POSIX that can be successfully used to read an exact number of bytes as long as certain conditions are met. There are limitations, as stated in my answer, but the OP did not require a failsafe or limitless option. Even so, if Stephen Kitt can briefly explain these limitations then the wider community would benefitI can understand why my answer doesn't work.
Observation 5: Self-deletion of a post by a new user is not possible [Resolved]
Seeing that my answer, described in Observation 4, was not beneficial I then attempted to delete it by the obvious method of clicking on the "delete" button at the bottom of the post where it shows in this order: "share", "edit", "delete", "flag". However, I was not able to do so. The result is a client-side redirection to What's the POSIX way to read an exact number of bytes from a file? where the query is noredirect=1#
, which only goes to the top of the page.
Observation 6: Prejudice favouring moderators and long-standing users
I noted that @muru'smuru's post on the same question (278443) possessed similar, if not, less merit than my answer, yet apparently received no critique from moderatorsreviewers. His post had a score of "-1" prior to my posted answer and "0" afterwards which indicates to me that it was probably upvoted by @StephenStephen Kitt.
Observation 7: ModeratorsHigh-rep users can edit and approve at will, even if incorrect
A few days ago I posted an answer to a Vim question at unix.stackexchange.com and a moderatorhigh-rep user @murumuru edited it in kind, but inadvertently introduced errors into the code. It was a by-product of format conversion and I rectified it, but it appeared muru's edit wasn't reviewed by a third party because of moderator statuscertain privileges/status because the error was not noticed.
Discussion
As I have only spent a few days on the unix.stackexchange.com site it is too early to make conclusions. I don't believe the aforementioned moderatorscontributors are making any begrudging or personal attacks but I am of the impression that there is a hierarchical culture here where there is bias between new members are scrutinised without restraint and without provision of grounds by long standing-standing members (moderators). I understand that moderators will need to politicise their responses, but is this true? Is there a pecking order here or is this community on a level field of information sharing?