If I may,
Please explain it in your own words and present the pitch to all then.
The concept of what you want to discuss may be a good article, copy and
pasting is not the way to pitch your idea of it though. You should try
to frame it as is suggested at
https://fedoramagazine.org/how-to-structure-your-article/ at least from
my POV. I'm sure more experienced contributors would have more sage
advice regarding idea pitches.
Steve
On 13/02/19 10:24 AM, Suraj Patil wrote:
Thank you for the clarification. But no one is posting about this
particular tool. I know this I'm studying this oprofile i will explain in
my own words not copying on any other sites
Awaiting your response
On Wed 13 Feb, 2019, 6:15 PM Paul Frields <stickster@xxxxxxxxx wrote:
Suraj, once again this information is copied directly from an online
source, in this case the RHEL System Administrators Guide. We are not
interested in content you have copied from an online source. We are
interested in original work. I have explained this to you previously,
when you also submitted work copied from another online source in
violation of its licensing.
The Magazine will not host plagiarism. Please do not send us any more
pitches until you can understand and follow the guideline of
submitting your own, original work.
On Sun, Feb 10, 2019 at 6:28 PM Suraj Patil <surajpatil522@xxxxxxxxx>
wrote:
Hello Magazine Team, I'm suraj patil from India. My FAS is suraj522 and i
want to contribute with content in Fedora Magazine. My first pitch is
This
article explains OProfile is a low overhead, system-wide performance
monitoring tool. It uses the performance monitoring hardware on the
processor to retrieve information about the kernel and executables on the
system, such as when memory is referenced, the number of L2 cache
requests,
and the number of hardware interrupts received. On a RHEL and Fedora, the
oprofile RPM package must be installed to use this tool. Many processors
include dedicated performance monitoring hardware. This hardware makes it
possible to detect when certain events happen (such as the requested data
not being in cache). The hardware normally takes the form of one or more
counters that are incremented each time an event takes place. When the
counter value, essentially rolls over, an interrupt is generated, making
it
possible to control the amount of detail (and therefore, overhead)
produced
by performance monitoring.
I want to know if this idea is suitable to Fedora Magazine.
_______________________________________________
Fedora Magazine mailing list -- magazine@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to magazine-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/magazine@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
Fedora Magazine mailing list -- magazine@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to magazine-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/magazine@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
Fedora Magazine mailing list -- magazine@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to magazine-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/magazine@xxxxxxxxxxxxxxxxxxxxxxx
