OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 30, 2017 10:47 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 28 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: The DI not supported incident
PostPosted: Mon Oct 06, 2014 1:06 am 
It is not the first time when Combuster uses his moderator account to hide the shame of being too selfconfident. Are moderators agree with such behaviour? Is it a good practice for a public forum?

I see here one common pattern:
Combuster fails to prove his words, but starts to talk about general things, that he sees as an excuse for his words. Next I (and I suppose other users) try to convince Combuster that he is not always right. And after this point my posts are deleted, while Combuter's are not. But there's even more shame - Combuster is allowed to edit his posts after my has been deleted and it was the post where I have shown Combuster's crude words. As a result we have Combuster's post edited, but my (with Combuster's shame evidence) deleted.

Is it an official position of the site moderators to hide information from users? Is it the official position of the site moderators, that allows Combuster to be always on the hill while pushes other always deep down underground?

Here are the threads that are affected by the Combuster's misbehavior:
http://forum.osdev.org/viewtopic.php?f=1&t=28569
http://forum.osdev.org/viewtopic.php?f=2&t=28476

And here is the private message from Combuster, where he convinces me that he always will be right:
Combuster wrote:
This is a warning regarding the following post made by you: viewtopic.php?f=14&p=241056#p241056 .

I'm going to turn this particular case into an official forum warning, because pointing you to your own behaviour in more friendly ways in all previous cases has shown to cause no improvement in your behaviour.

You claimed DI was not supported on some processors. This is a flat out fabrication, and should be corrected for the sake of the original poster. You then posted several times in terms of a petty argument about how you have been wronged, which is not helpful for any readers, and spoils the OP's original thread. You subsequently insult people which makes you violate two distinct forum rules within one day.

Next you pretend to be right by posting a summary of 64-bit instructions. The thread dealt with bootloaders, which made the involvement of 16-bit code very likely, and although 32-bit registers were used, there was no mention of 64-bits anywhere. This is a form of argumentation that is unacceptable, and is only employed in a last-resort attempt to divert attention.

You then resort to calling a fact a "hack you can't trust", again without proper evidence.

The bottom line is that you need to learn two things in public discussions:
- Accept it when you have made an error
- Prioritize helping other people over staging a show around yourself.


Stay safe, and hopefully I don't need to resort to further administrative measures.

As we can see Combuster has no evidence of my error, but still recommends me to stay safe (from Combuster?).

Is it a good moderation practice? Are other moderators agree with such behavior?


Last edited by sortie on Mon Oct 06, 2014 9:38 am, edited 1 time in total.
Thread renamed from “Why Combuster's shame is always hidden?” as that was antagonizing -sortie


Top
  
 
 Post subject: Re: Why Combuster's shame is always hidden?
PostPosted: Mon Oct 06, 2014 1:55 am 
Offline
Member
Member

Joined: Tue Aug 19, 2014 1:20 pm
Posts: 74
I think it would be nice if we could see something like a moderation log, where we can see when posts were deleted/edited etc.


Top
 Profile  
 
 Post subject: Re: Why Combuster's shame is always hidden?
PostPosted: Mon Oct 06, 2014 3:06 am 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 7750
Location: At his keyboard!
Hi,

seuti wrote:
I think it would be nice if we could see something like a moderation log, where we can see when posts were deleted/edited etc.


Ok, here's a screenshot of the moderator's log:
Attachment:
log.png
log.png [ 217.48 KiB | Viewed 5282 times ]


You'll see from this that Combuster didn't edit embryo's post, and didn't delete embryo's post. Instead the topic was split, and part of it was moved to the moderator's forum for all moderators to see. I have reviewed the moved posts. My conclusion is that embryo was wrong, and that he knows that he was wrong (partly because 3 completely different people explained it to him; where 2 of these people are normal members and not moderators at all). Embryo's wrongness wouldn't have helped anyone (including the topic's original poster), so moving it was the right decision for the topic. Ironically, moving it (so other people don't see embryo being wrong) was also the right decision for embryo's reputation.

What you can't see (as the screenshot is too small to cover the entire moderator logs) is that Combuster has not touched the "My BoxOn PC" topic at all. However, on the 17th of September (maybe 18th in your time zone, I don't know) a completely different moderator did delete one of embryo's posts from this topic and gave embryo a warning. That warning begins with "This comment was exceptionally rude, and should not have been made.". Combuster had nothing to do with that incident.


Cheers,

Brendan

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re: Why Combuster's shame is always hidden?
PostPosted: Mon Oct 06, 2014 3:23 am 
Offline
Member
Member
User avatar

Joined: Fri Jun 13, 2008 3:21 pm
Posts: 1700
Location: Cambridge, United Kingdom
In the interests of transparency I have placed the trimmed posts in a locked thread in this forum


Top
 Profile  
 
 Post subject: Re: Why Combuster's shame is always hidden?
PostPosted: Mon Oct 06, 2014 3:30 am 
Offline
Member
Member
User avatar

Joined: Wed Jul 30, 2014 1:05 am
Posts: 153
Ugh. I hate these kinds of topics. Even if Combuster was being a douche, just blow him off. Anything less than a 24-hour ban just isn't worth getting riled up about.

Your post wasn't moved because it was incorrect, it was moved because it was irrelevant and would lead to confusion. It would be nice if this website had spoiler tags so you could hide extra details like that.


Top
 Profile  
 
 Post subject: Re: Why Combuster's shame is always hidden?
PostPosted: Mon Oct 06, 2014 9:37 am 
Offline
Member
Member
User avatar

Joined: Wed Mar 21, 2012 3:01 pm
Posts: 894
I don't believe proper procedure and mature behaviour has been applied in this situation.

If you blur the lines here, what you see is embryo making a remark, Combuster points out it is wrong, and somehow this escalates into a public spectacle and outright antagonizing.

This is obviously not how forum members should conduct themselves.

At any point, either of you could have let this go as it was irrelevant to the original thread or admitted you were wrong. After all, this matter can easily be determined by reading the CPU documentation and testing whether it works on the relevant hardware. That could have been split into its own thread where the matter is thoroughly investigated. Instead you increasingly antagonize each other instead of seeking the truth using professional conduct.

Your argument was derailing the poor thread it occurred in and Combuster made the correct decision to make this stop. This could have been done by splitting the thread and locking it, or since in this case most of the argument was non-contributory, he made the acceptable decision to just move the posts to the moderator forum. It's fine that a warning was given since they aren't really too important, their only use is to guide other moderators next time an issue comes up. This would have been a perfectly acceptable place to let this go.

Instead, embryo, you make this antagonizing thread. You're not trying to get a full account from the moderators what happened, no, you are playing the position of the victim and destabilizing the trust in the moderators. Perhaps Combuster was wrong, if so, this isn't the way to handle it. Instead, if you believe a moderator is abusing, please send a private message to the other moderators that you do trust and ask them to investigate the matter.

To keep this forum operating smoothly, moderators follow these principles:

  • Moderator operations can be audited by other moderators. This is done using the moderator log shown above.
  • Moderator operations can be undone if other moderators disagree. This is done by moving posts to a moderator forum rather than deleting them.

This means we can easily make up our mind on whether our co-moderators are behaving responsibility.

Unfortunately, thePowersGang did delete one of embryo's posts that contained an insult. This makes investigating this matter today a bit harder. It must have been a really bad insult as that also granted him a warning.

This is another perfectly acceptable point to let this go and spend some quality time with friends and family, or perhaps some satisfying coding.

embryo wrote:
Is it an official position of the site moderators to hide information from users?

Yes. We make excessive amounts of non-contributory posts go away in a manner that can be audited and undone. The job of the moderators is to keep this place running smoothly and we do sometimes make rule violations go away and rewrite it out of public history.


Top
 Profile  
 
 Post subject: Re: The DI not supported incident
PostPosted: Mon Oct 06, 2014 10:40 pm 
Offline
Member
Member
User avatar

Joined: Tue Dec 25, 2007 6:03 am
Posts: 692
Location: Perth, Western Australia
My apologies for the deletion of the post. I indented to move it, but could not find the move option during my lunch break (and, if I recall correctly, believed that it should be removed as soon as possible).

I think it was a very inflammatory post which added nothing to the discussion (and reminded me of some of the less desirables that join Freenode#osdev)

_________________
Kernel Development, It's the brain surgery of programming.
Acess2 OS (c) | Tifflin OS (rust) | mrustc - Rust compiler
Currently Working on: mrustc


Top
 Profile  
 
 Post subject: Re: Why Combuster's shame is always hidden?
PostPosted: Tue Oct 07, 2014 3:44 am 
Brendan wrote:
You'll see from this that Combuster didn't edit embryo's post, and didn't delete embryo's post.

Combuster has edited his own post. In my post I just rephrased his words and next the post was deleted. After the deletion I had a look at Combuster's original post and it was EDITED.

Also about "didn't delete embryo's post" - for ordinary users the post just disappears and no one of them can find it. Can I name such situation using word "deleted"?
Brendan wrote:
My conclusion is that embryo was wrong, and that he knows that he was wrong (partly because 3 completely different people explained it to him; where 2 of these people are normal members and not moderators at all).

Am I wrong just because 3 people explained it or because there is an evidence that Intel's processors in 64-bit mode can use 16-bit indirect addressing? There was no evidence in any post above. There is only one post about AMD's docs where it is claimed that 67h prefix can make no harm, but does it work as expected in 64-bit mode? And how can we trust some appendixes from AMD docs when main part of Intel's docs explicitly says "32 or 64 bit registers". Should we always trust some old AMD's appendixes instead of a new Intel's docs for every new Intel's processor? Do you think such loosy philosophy is making us safe from having a lot of troubles in the future (or even with existing processors)?
Brendan wrote:
Embryo's wrongness wouldn't have helped anyone (including the topic's original poster), so moving it was the right decision for the topic.

Ok, I agree that it was off topic, but everybody can see that many threads go wrong way after discussion has found something interesting outside of the subject of the thread. And do moderators "move" in invisible thread all such messages? It is obvious - no, such destiny is for some selected messages only. And the question is about the selection principles. Why not to move off topic messages in a visible thread? Why not to leave a message in the original thread about some messages were moved and here is the link to help find them?
Brendan wrote:
Ironically, moving it (so other people don't see embryo being wrong) was also the right decision for embryo's reputation.

I don't care if somebody sees me being wrong, but I care a lot if I have no way to defend myself and to explain my words.
Brendan wrote:
a completely different moderator did delete one of embryo's posts from this topic and gave embryo a warning. That warning begins with "This comment was exceptionally rude, and should not have been made.". Combuster had nothing to do with that incident.

Combuster was the reason for the incident and his original post was kept safe, but edited by Combuster to hide his "exceptionally rude" words.

And as a final note I can say about human habits. It requires less time when moderator hides some messages and keeps calmness among users as long as possible, but there is a problem under the calmness disturbance. Keeping everything quiet just hides the original problem and makes a solid base for the problem to return with greater power. So I think it is better not to wait until the problem gathers enough power, but to start looking for solutions as early as possible.

DaemonR wrote:
It would be nice if this website had spoiler tags so you could hide extra details like that.

Agree.


Top
  
 
 Post subject: Re: The DI not supported incident
PostPosted: Tue Oct 07, 2014 3:58 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 2669
Location: Chichester, UK
Quote:
There is only one post about AMD's docs where it is claimed that 67h prefix can make no harm, but does it work as expected in 64-bit mode? And how can we trust some appendixes from AMD docs when main part of Intel's docs explicitly says "32 or 64 bit registers". Should we always trust some old AMD's appendixes instead of a new Intel's docs for every new Intel's processor?

This seems to be an exceptionally easy thing to test practically. Why not do so, and post your results proving that it doesn't work, rather than throwing your toys out of the pram?


Top
 Profile  
 
 Post subject: Re: Why Combuster's shame is always hidden?
PostPosted: Tue Oct 07, 2014 4:09 am 
sortie wrote:
At any point, either of you could have let this go as it was irrelevant to the original thread or admitted you were wrong.

I suppose there could be some procedure to split original thread into two new, the original and a fork thread. But to keep the fork thread informative it is required to copy/move some messages there. May be moderator can ask a user about creating new thread and, after it has been created, move/copy relevant messages there.
sortie wrote:
Instead, embryo, you make this antagonizing thread. You're not trying to get a full account from the moderators what happened, no, you are playing the position of the victim and destabilizing the trust in the moderators. Perhaps Combuster was wrong, if so, this isn't the way to handle it. Instead, if you believe a moderator is abusing, please send a private message to the other moderators that you do trust and ask them to investigate the matter.

Keeping everything hidden from users leads to some ugly effects like misbehavior of those in power.

But I will try to ask a moderator next time, even despite that it (most probably) will lead to relatively long discussion. Also it seems viable to send mails to more than one moderator. Just to get some clue about moderator community's attitude.
sortie wrote:
embryo wrote:
Is it an official position of the site moderators to hide information from users?

Yes. We make excessive amounts of non-contributory posts go away in a manner that can be audited and undone. The job of the moderators is to keep this place running smoothly and we do sometimes make rule violations go away and rewrite it out of public history.

I think it is much better to create some mechanism to fork threads instead of quietly (or secretly?) deleting user posts without any notice to all participants. The best notice I think can be a message with a link to the moved part of a thread. And of course, the moved part should not be invisible or at least it's disappearing should be commented publicly.

iansjack wrote:
Quote:
There is only one post about AMD's docs where it is claimed that 67h prefix can make no harm, but does it work as expected in 64-bit mode? And how can we trust some appendixes from AMD docs when main part of Intel's docs explicitly says "32 or 64 bit registers". Should we always trust some old AMD's appendixes instead of a new Intel's docs for every new Intel's processor?

This seems to be an exceptionally easy thing to test practically. Why not do so, and post your results proving that it doesn't work, rather than throwing your toys out of the pram?

Just because I can throw only toys while Combuster throws off all my messages. And he does it without any testing.


Top
  
 
 Post subject: Re: The DI not supported incident
PostPosted: Tue Oct 07, 2014 4:22 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 2669
Location: Chichester, UK
Quote:
Combuster throws off all my messages

But he didn't. He moved it for review by all the moderators. You seem unable to accept that review process and the result of it.

None of us have any rights here. Those who run the forum are free to do so in the manner they think fit. Whilst I might not agree with an individual moderator I am more than happy to accept their consensus. If you are not then perhaps this is not the forum for you.


Top
 Profile  
 
 Post subject: Re: The DI not supported incident
PostPosted: Tue Oct 07, 2014 4:38 am 
Offline
Member
Member
User avatar

Joined: Wed May 21, 2008 4:33 am
Posts: 294
Location: Mars MTC +6:00
embryo wrote:
iansjack wrote:
Quote:
There is only one post about AMD's docs where it is claimed that 67h prefix can make no harm, but does it work as expected in 64-bit mode? And how can we trust some appendixes from AMD docs when main part of Intel's docs explicitly says "32 or 64 bit registers". Should we always trust some old AMD's appendixes instead of a new Intel's docs for every new Intel's processor?

This seems to be an exceptionally easy thing to test practically. Why not do so, and post your results proving that it doesn't work, rather than throwing your toys out of the pram?

Just because I can throw only toys while Combuster throws off all my messages. And he does it without any testing.


You seem to be missing the main point. The 67h is an intentionally designed instruction prefix to do the things it claims. It is not a backwards hack as it also makes 32 bit instructions available in a 16 bit protected mode code segment or in real mode. AMD also designed the 64 bit extensions to the x86 CPUs so their appendix would actually be more valid in this case as it's their design Intel are working from, not the other way around.

_________________
"God! Not Unix" - Richard Stallman (probably)

Website: venom Dev
OS project: venom OS
Hexadecimal Editor: hexed


Top
 Profile  
 
 Post subject: Re: The DI not supported incident
PostPosted: Wed Oct 08, 2014 6:51 am 
b.zaar wrote:
You seem to be missing the main point. The 67h is an intentionally designed instruction prefix to do the things it claims.

May be I miss something, but what is the reason Intel has docs like this:
Quote:
• Base — The value in a 32-bit (or 64-bit if REX.W is set) general-purpose register.
• Index — The value in a 32-bit (or 64-bit if REX.W is set) general-purpose register.


Top
  
 
 Post subject: Re: The DI not supported incident
PostPosted: Wed Oct 08, 2014 11:42 am 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 7750
Location: At his keyboard!
Hi,

embryo wrote:
b.zaar wrote:
You seem to be missing the main point. The 67h is an intentionally designed instruction prefix to do the things it claims.

May be I miss something, but what is the reason Intel has docs like this:
Quote:
• Base — The value in a 32-bit (or 64-bit if REX.W is set) general-purpose register.
• Index — The value in a 32-bit (or 64-bit if REX.W is set) general-purpose register.


The reason is that the specific section you've quoted is wrong in older versions of Intel's docs - 0x67 prefix effects address size (e.g. the size of the base and index registers in 64-bit code), and the REX.W effects operand size and not address size (and not base and index).

In newer versions of Intel's docs it's been changed; but it's still not 100% right (because it fails to mention the 0x67 prefix). Fortunately there's another section (e.g. "3.6.1 Operand Size and Address Size in 64-Bit Mode") which is correct for both the newer versions of the manual and the older versions of the manual, and is much clearer anyway.


Cheers,

Brendan

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re: The DI not supported incident
PostPosted: Wed Oct 08, 2014 1:31 pm 
Offline
Member
Member
User avatar

Joined: Wed May 21, 2008 4:33 am
Posts: 294
Location: Mars MTC +6:00
embryo wrote:
b.zaar wrote:
You seem to be missing the main point. The 67h is an intentionally designed instruction prefix to do the things it claims.

May be I miss something, but what is the reason Intel has docs like this:
Quote:
• Base — The value in a 32-bit (or 64-bit if REX.W is set) general-purpose register.
• Index — The value in a 32-bit (or 64-bit if REX.W is set) general-purpose register.


I'm talking crap again... mixing my 66h's with 67h's without checking the docs...

I don't think the original thread mentions 64 bit mode though so the 67h prefix works there.

_________________
"God! Not Unix" - Richard Stallman (probably)

Website: venom Dev
OS project: venom OS
Hexadecimal Editor: hexed


Last edited by b.zaar on Wed Oct 08, 2014 3:16 pm, edited 2 times in total.

Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 28 posts ]  Go to page 1, 2  Next

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group