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
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(a)gmail.com 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(a)gmail.com>
> 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(a)lists.fedoraproject.org
>> To unsubscribe send an email to magazine-leave(a)lists.fedoraproject.org
>> 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@lists.fedoraprojec...
>
_______________________________________________
Fedora Magazine mailing list -- magazine(a)lists.fedoraproject.org
To unsubscribe send an email to magazine-leave(a)lists.fedoraproject.org
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@lists.fedoraprojec...