The DI not supported incident

Questions, comments, and suggestions about this site should go here.
embryo

The DI not supported incident

Post by embryo »

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.
Reason: Thread renamed from “Why Combuster's shame is always hidden?” as that was antagonizing -sortie
seuti
Member
Member
Posts: 74
Joined: Tue Aug 19, 2014 1:20 pm

Re: Why Combuster's shame is always hidden?

Post by seuti »

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.
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:

Re: Why Combuster's shame is always hidden?

Post by Brendan »

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:
log.png
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.
User avatar
Owen
Member
Member
Posts: 1700
Joined: Fri Jun 13, 2008 3:21 pm
Location: Cambridge, United Kingdom
Contact:

Re: Why Combuster's shame is always hidden?

Post by Owen »

In the interests of transparency I have placed the trimmed posts in a locked thread in this forum
User avatar
Wajideu
Member
Member
Posts: 153
Joined: Wed Jul 30, 2014 1:05 am

Re: Why Combuster's shame is always hidden?

Post by Wajideu »

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.
User avatar
sortie
Member
Member
Posts: 931
Joined: Wed Mar 21, 2012 3:01 pm
Libera.chat IRC: sortie

Re: Why Combuster's shame is always hidden?

Post by sortie »

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.
User avatar
thepowersgang
Member
Member
Posts: 734
Joined: Tue Dec 25, 2007 6:03 am
Libera.chat IRC: thePowersGang
Location: Perth, Western Australia
Contact:

Re: The DI not supported incident

Post by thepowersgang »

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
embryo

Re: Why Combuster's shame is always hidden?

Post by embryo »

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.
User avatar
iansjack
Member
Member
Posts: 4703
Joined: Sat Mar 31, 2012 3:07 am
Location: Chichester, UK

Re: The DI not supported incident

Post by iansjack »

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?
embryo

Re: Why Combuster's shame is always hidden?

Post by embryo »

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:
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.
User avatar
iansjack
Member
Member
Posts: 4703
Joined: Sat Mar 31, 2012 3:07 am
Location: Chichester, UK

Re: The DI not supported incident

Post by iansjack »

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.
User avatar
b.zaar
Member
Member
Posts: 294
Joined: Wed May 21, 2008 4:33 am
Location: Mars MTC +6:00
Contact:

Re: The DI not supported incident

Post by b.zaar »

embryo wrote:
iansjack wrote:
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

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

Re: The DI not supported incident

Post by embryo »

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:
• 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.
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:

Re: The DI not supported incident

Post by Brendan »

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:
• 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.
User avatar
b.zaar
Member
Member
Posts: 294
Joined: Wed May 21, 2008 4:33 am
Location: Mars MTC +6:00
Contact:

Re: The DI not supported incident

Post by b.zaar »

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:
• 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.
Last edited by b.zaar on Wed Oct 08, 2014 3:16 pm, edited 2 times in total.
"God! Not Unix" - Richard Stallman

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