Page 8 of 9 FirstFirst ... 6789 LastLast
Results 71 to 80 of 83

Thread: KDE SC 4.7 Release Candidate Hits The Web

  1. #71
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,799

    Default

    Quote Originally Posted by energyman View Post
    MALLOC_CHECK 3 IS a good choice.

    You don't believe? Use google for fsck sake!
    ORLY? A development/debugging setting that slows down execution of every application, sometimes up to 25% or more, is a good choice for end-users? If you have used Google yourself instead of only telling others to, you would have found that this is supposed to be enabled only for betas and snapshots of KDE, not for release canditates.


    So with when problems arise a warning is printed and the program aborted.

    Which is a WISE CHOICE for test candidates like alphas, betas and release candidates.
    No, for RCs it is not.

    Question: why do YOU think it is a bad choice? Please with complete sources.
    Because of the runtime overhead that makes the whole system go slower? OK, your opinion is that KDE should enable this for Firefox, mplayer, VMWare, VirtualBox, and every other app I have installed and which isn't part of KDE itself. It's your opinion, and you're entitled to it. Me, I think it's a retarded opinion. And I'm entitled to it too.
    Last edited by RealNC; 07-02-2011 at 12:25 PM.

  2. #72
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,799

    Default

    Quote Originally Posted by BlackStar View Post
    I really can't be bothered to check
    Oh, so typing "env | grep MALLOC_CHECK_" is too much of a bother. OK. And also, you think it's a good idea, but then you don't go ahead and enable it globally? Gee, why is that?

  3. #73
    Join Date
    Jul 2008
    Posts
    1,729

    Default

    Quote Originally Posted by Ex-Cyber View Post
    Regardless of whether it's a good choice, a KDE startup script is not the right place to make that choice for non-KDE apps.

    have you checked that your distri does have the same entry? Or that it isn't set globally?

  4. #74
    Join Date
    Jul 2008
    Posts
    1,729

    Default

    Quote Originally Posted by RealNC View Post
    ORLY? A development/debugging setting that slows down execution of every application, sometimes up to 25% or more, is a good choice for end-users? If you have used Google yourself instead of only telling others to, you would have found that this is supposed to be enabled only for betas and snapshots of KDE, not for release canditates.



    No, for RCs it is not.


    Because of the runtime overhead that makes the whole system go slower? OK, your opinion is that KDE should enable this for Firefox, mplayer, VMWare, VirtualBox, and every other app I have installed and which isn't part of KDE itself. It's your opinion, and you're entitled to it. Me, I think it's a retarded opinion. And I'm entitled to it too.
    ooh.. you are missing the point that for the env-variable to take effect there must be code in the apps to make use of it.

    Hmmm...

    and yes, for rcs it is a wise choice. Release Candidates are nothing but test releases. Debugging is THE reason to release them. So turning on an option to help debugging is a sane and wise choice.

    You install test releases, you should be prepared to see debug overhead, bugs and crashes. And report them. The debug overhead disappears with the release. This is good release managment.

  5. #75
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,799

    Default

    Quote Originally Posted by energyman View Post
    ooh.. you are missing the point that for the env-variable to take effect there must be code in the apps to make use of it.
    You're wrong. It checks all programs unconditionally. The program is not required to provide any kind of special code.

    and yes, for rcs it is a wise choice. Release Candidates are nothing but test releases. Debugging is THE reason to release them. So turning on an option to help debugging is a sane and wise choice.

    You install test releases, you should be prepared to see debug overhead, bugs and crashes. And report them. The debug overhead disappears with the release. This is good release managment.
    You seem to have zero idea about what you're talking about:

    http://web.archiveorange.com/archive...htlRigNFJfp1QX

    "trunk" is a long way from "RC".

    Also, I don't see you comment on the fact that this enabled runtime checks for the whole system instead of only for KDE. Join my mental club of people with silly ideas.
    Last edited by RealNC; 07-02-2011 at 03:19 PM.

  6. #76
    Join Date
    Oct 2007
    Location
    Under the bridge
    Posts
    2,146

    Default

    Quote Originally Posted by RealNC View Post
    Oh, so typing "env | grep MALLOC_CHECK_" is too much of a bother. OK. And also, you think it's a good idea, but then you don't go ahead and enable it globally? Gee, why is that?
    Argumentative as always. I am using a stable release, so this is disabled as expected.

    "trunk" is a long way from "RC".

    Also, I don't see you comment on the fact that this enabled runtime checks for the whole system instead of only for KDE. Join my mental club of people with silly ideas.
    You are just being silly now. He never mentioned "trunk" he said that release candidates are there for testing and it's a good idea to gather crash reports on those.

    If you install a release candidate you are expected to report bugs. Enabling this option ensures that misbehaving applications will crash, exactly so you can report those bugs.

    It is obvious that you installed a release candidate thinking it is a final release. In short, PEBKAC.

  7. #77
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,799

    Default

    Quote Originally Posted by BlackStar View Post
    If you install a release candidate you are expected to report bugs. Enabling this option ensures that misbehaving applications will crash so you can report these bugs.
    So you're saying I'm expected to report VirtualBox crashes to bugs.kde.org? Because that's what happens if KDE enables this var globally.

    It is obvious that you installed a release candidate thinking it is a final release. In short, PEBKAC.
    Well, please show me where it says that this var is supposed to be enabled on non-developer versions of KDE (like non-debug builds of RCs). Because all info I can find says it's intended for trunk and snapshots. Also, please look up the meaning of "candidate" in a dictionary. "Release candidate" means an actual candidate for release. Candidate. To be released as-is in the (unlikely event) there are not bugs reported against it.

  8. #78
    Join Date
    Jan 2008
    Posts
    772

    Default

    Quote Originally Posted by energyman View Post
    have you checked that your distri does have the same entry? Or that it isn't set globally?
    I'm not sure how that's relevant. The distro vendor legitimately does have that prerogative, just like they get to decide whether to e.g. ship a tickless kernel by default. If you think that's a potential confounding issue with the bug report (which is not mine), you should address it to the bug report.

  9. #79
    Join Date
    Oct 2007
    Location
    Under the bridge
    Posts
    2,146

    Default

    Quote Originally Posted by RealNC View Post
    So you're saying I'm expected to report VirtualBox crashes to bugs.kde.org? Because that's what happens if KDE enables this var globally.
    Are you 100% certain the issue is not KDE-related? If yes, report it to VirtualBox. If not, report to KDE.

    In both cases, *report it* so it can get fixed. Duh.

    Well, please show me where it says that this var is supposed to be enabled on non-developer versions of KDE (like non-debug builds of RCs). Because all info I can find says it's intended for trunk and snapshots. Also, please look up the meaning of "candidate" in a dictionary. "Release candidate" means an actual candidate for release. Candidate. To be released as-is in the (unlikely event) there are not bugs reported against it.
    Different projects have different approaches to the release process and "release candidate" is interpreted according to the selected approach. You are over-generalizing, as always.

    Would KDE plan for two release candidates and 4+ weeks of testing a priori, if they thought the release candidate was bug-free and ready for release? No. They are expecting issues, which is why MALLOC_CHECK is enabled in the RC.

    Contrast for instance with Opera: RC is out today and if no blocking bugs are reported then that RC is promoted to final *tomorrow*. One day. If bugs are found then another RC is released and this process is repeated as many times as necessary (5, 6 or more).

  10. #80
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,799

    Default

    Quote Originally Posted by BlackStar View Post
    Would KDE plan for two release candidates and 4+ weeks of testing a priori, if they thought the release candidate was bug-free and ready for release? No. They are expecting issues, which is why MALLOC_CHECK is enabled in the RC.
    I already asked multiple times but you don't answer: Show me where it says that. "Which is why MALLOC_CHECK is enabled in the RC". WHERE does it say that? How do you know that? Where did you read that?

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •