Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
KDE Bug EU GUI Open Source

KDE Bug Fixed After 13 Years (kate-editor.org) 118

Posted by EditorDavid from the resolved dept.
About 50 KDE developers met this week in the Swiss Alps for the annual Randa Meetings, "seven days of intense in-person work, pushing KDE technologies forward and discussing how to address the next-generation demands for software systems." Christoph Cullmann, who maintains the Kate editor, blogs that during this year's sprint, they finally fixed a 13-year-old bug. He'd filed the bug report himself -- back in 2003 -- and writes that over the next 13 years, no one ever found the time to fix it. (Even though the bug received 333 "importance" votes...) After finally being marked Resolved, the bug's tracking page at KDE.org began receiving additional comments marveling at how much time had passed. Just think, when this bug was first reported:
-- The current Linux Kernel was 2.6.31...
-- Windows XP was the most current desktop verison. Vista was still 3 years away.
-- Top 2 Linux verions? Mandrake and Redhat (Fedora wouldn't be released for another 2 months, Ubuntu's first was more than a year away.)
This discussion has been archived. No new comments can be posted.

KDE Bug Fixed After 13 Years More

KDE Bug Fixed After 13 Years

Comments Filter:

  • Oh please. (Score:1)

    by Anonymous Coward

    I fixed this bug a month after it was first announced, but when submitting it I was told that other parties didn't want the bug fixed, and that I should forget about it for my own safety. The more you know.

    • Re: Oh please. (Score:1)

      by Anonymous Coward

      That was you?

      Wish I could talk more about what happened, but....well, sorry.

    • Attention:

      The woods are lovely dark and deep.

      But I have promises to keep,

      And miles to go before I sleep.

  • KDE Bug Fixed After 13 Years (Score:1)

    by Anonymous Coward

    They've finally corrected it to "CDE"

  • ...discussing how to address the next-generation demands for software systems....

    Hopefully, the future KDE will be a bit more (OK, a lot more) efficient, and less bloaty.

  • 2.4.<bignum> (Score:4, Interesting)

    by epine ( 68316 ) on Sunday June 19, 2016 @10:56AM (#52347291)

    17 December 2003 — release of Linux kernel 2.6.0 (5,929,913 lines of code)

    If we're all feeling nostalgic, this should do the trick:

    The Linux Backdoor Attempt of 2003 [freedom-to-tinker.com]

    if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
          retval = -EINVAL;

    But on Nov. 5, 2003, Larry McVoy noticed that there was a code change in the CVS copy that did not have a pointer to a record of approval. Investigation showed that the change had never been approved and, stranger yet, that this change did not appear in the primary BitKeeper repository at all.

    Other issues back in 2003 were burning up the Linux development intertubes.

    The mind behind Linux [ted.com]

    16:00

    To me, the sign of people I really want to work with is that they have good taste, which is how ... I sent you this stupid example that is not relevant because it's too small. Good taste is much bigger than this. Good taste is about really seeing the big patterns and kind of instinctively knowing what's the right way to do things.

    The following is my idea of good taste (since the 1980s), whenever a comparison involves a constant term:

    if ((options == (__WCLONE|__WALL)) && (0 = current->uid))
          retval = -EINVAL;

    This does not achieve root. It won't even compile.

    • Why not:
      if (((__WCLONE|__WALL) == options) && (0 = current->uid))
                  retval = -EINVAL;
      ?

    • The following is my idea of good taste (since the 1980s), whenever a comparison involves a constant term: if ((options == (__WCLONE|__WALL)) && (0 = current->uid))

      And when it doesn't involve a constant term, what then?

      Better to make sure your compiler warns on assignments in conditionals (and maybe even turn warnings into errors), then write in comparisons in whatever order reads most naturally.

      • Many schooled in other languages would be wary of coding without a boolean data type. C99 has #include <stdbool.h> although it still evaluates down to 1 and 0.

        But then 'real programmers' don't need hand-holding where others would delegate responsibility for such low level gotchas to a compiler. :)

  • Typical KDE

  • Wait. What? (Score:1)

    by Anonymous Coward

    About 50 KDE developers met this week in the Swiss Alps....

    Reeeaaaallllly?

    Throw in some hookers and blow, and I'll sign up to test, do your laundry, wipe your ass, and even .... WRITE DOCUMENTATION!

  • Slashdot (Score:5, Insightful)

    by allo ( 1728082 ) on Sunday June 19, 2016 @11:19AM (#52347409)

    And slashdot doesn't even try to describe the bug in the summary.

    • ^^^ This. Exactly.

    • Re:Slashdot (Score:5, Informative)

      by zenlessyank ( 748553 ) on Sunday June 19, 2016 @12:02PM (#52347587)
      Description: When I change between files, the icons start changing position in my Kate toolbar. At first (starting with the save icon), they move from extreme right to extreme left. Then, they start to disappear. I waited 2 weeks to report this, on SadEagle advice. (Wait 2 weeks, if the problem persist, report it.) How to reproduce it: Open Kate. Open a two arbitrary files. Switch between them.

      • Re: (Score:2)

        by Trogre ( 513942 )

        The fix, in line with the UI genius behind gedit, was to simply remove the icon bar completely.

        I kid, I kid.

    • If it was 13 years old and we haven't bitched about it then chances are we don't care either ;)

    • Re: (Score:2)

      by sootman ( 158191 )

      It's been there for 13 years -- they probably figured everyone already knew what it was.

  • One of the problems with software development is that people like adding features but they won't invest the time to crush every last bug. As a result, a bug could come from any number of layers in the API you are using so it's considered to be "impossible" to make perfect software. My fellow software developers, you really need to up your game! :(

    • Nobody likes being told that they screwed up, but QA is really only a mirror for developers. It is entirely up to the devs to fix things if they do not like what QA reports. Leadership / management also sees devs as "Gods" while QA is that pesky group of negative Nancies that only comes in handy when there is someone needed to blame for the major flaw that was not found. Typically, it was found by QA and pointed out in any which way possible just to be dismissed by developers as "irrelevant edge cases". It
      • It is astounding that this cultural flaw is found in every development group.

        Not *every* group. A couple of years ago, I worked with a company where Development and QA actually looked at themselves as a partnership, and anything that came back marked broken from QA was looked at quite carefully and generally considered a failure on Dev's part. Even if we couldn't reproduce QA's bug right away, we still took quite a bit of time working with them trying to get it to show up again, and more than once too

      • Re:software woes (Score:4, Interesting)

        by Dutch Gun ( 899105 ) on Sunday June 19, 2016 @02:13PM (#52348203)

        At my former employer (I'd consider them the best place I'd worked at), we had "embedded QA". They'd sit right next to the developers, would be at our status meetings, would often develop specialties related to what that dev was working on, and would immediately provide either unofficial or official feedback on new features. As annoying as it is to have someone point out mistakes you've made, as a dev, you need to get over it and realize it's better for one QA member to point out your stupid mistakes than for the entire world to see them after you shipped.

        For QA to be effective, I'm convinced they need to be working as part of the dev team, not as some standalone team the devs don't think about except when they get a bug report. This helps to prevent a lot of the problems with QA filing bug reports on things that aren't actually bugs since perhaps they're simply unfinished, or because they're something they don't understand about how things are supposed to work, etc. More importantly, this specialized QA person can vet other bugs from people on the team to make sure they're not dupes, etc. It can actually save the devs a lot of work.

        I'm not sure how you could apply this lesson with open source development. The best is probably to release detail patch notes detailing what you worked on, so people can keep on eye on those features for any breakage, and to have an active and helpful team willing to help test out alpha or beta builds. And of course, the devs need to be willing to actually *listen* to feedback, which can unfortunately be a stumbling block when the feedback clashes with their "vision".

    • One of the problems with software development is that people like adding features but they won't invest the time to crush every last bug.

      YES!!
      When there is a bug in my code, I feel shame, and I fix it as soon as possible! I don't know what's wrong with these people.

  • JWZ said it best (Score:1)

    by Anonymous Coward
    I'll just leave this here: https://www.jwz.org/doc/cadt.html [jwz.org]

  • "no one ever found the time to fix it" (Score:4, Insightful)

    by MoarSauce123 ( 3641185 ) on Sunday June 19, 2016 @12:04PM (#52347595)
    And I bet in the end it took 10 minutes to do the job. This is nothing but a testament of wrong priorities of project leadership. Fix the stuff that people are already using rather than cramming in more broken features that users did fine without so far. I guess users are fine with subpar quality even in FOSS projects.

    • Re:"no one ever found the time to fix it" (Score:5, Interesting)

      by dfaure ( 115987 ) on Sunday June 19, 2016 @01:48PM (#52348097) Homepage

      It took me a full day of very intense and complex debugging to fix this.

    • This is nothing but a testament of wrong priorities of project leadership

      How do you come to that conclusion? A bug that has been around for 13 years to be a big priority would have cause the mother of all bitchfests on various forums. By the look of things it appeared to be more a minor annoyance. Try and fix ALL of those and you'll never put another feature in your program again and will be destined for ever to sit in a maintenance release loop.

      • "Try and fix ALL of those and you'll never put another feature in your program again"

        If that's your approach to software quality, then so be it: the world will be a much better place without your "features".

        Now, think on NOT introducing all these bugs to start with and focus on correct them as soon as you are aware of those that go through, so you don't end up needed days upon days to correct them and, all of a sudden, all your software stack will be more solid and you will be able to start adding new featu

        • the world will be a much better place without your "features".

          How well did you post this from your MSDOS machine? Please don't type "features" as if you actually would prefer to live without them. Advancement requires the acceptance of the imperfect.

          Now, think on NOT introducing all these bugs

          Yeah, damn these people who get up in the morning and put effort into not being perfect.

          • "Please don't type "features" as if you actually would prefer to live without them"

            You can bet there're a lot of "features", exactly the ones I put between quotation marks, I really prefer to live without. I really would live without the "this release is no further supported, so your issue gets automatically closed", the "this is not the last release, so I won't take the time to test if your bug request is of any merit: go with the last version" or the "yes, I know I'm developing a library others may depen

  • Something went wrong with "Linus Law" (Score:3)

    by williamyf ( 227051 ) on Sunday June 19, 2016 @12:08PM (#52347613)

    " 8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.

    Or, less formally, ``Given enough eyeballs, all bugs are shallow.'' I dub this: ``Linus's Law''.

    My original formulation was that every problem ``will be transparent to somebody''. Linus demurred that the person who understands and fixes the problem is not necessarily or even usually the person who first characterizes it. ``Somebody finds the problem,'' he says, ``and somebody else understands it. [...] But the key point is that both parts of the process (finding and fixing) tend to happen rapidly." ESR CatB

    So, 13 years, right? And is not the first time. Holes in hipervisors for 12 years, heartbleed, ...

    I've said it before and I'll say it again:

    One does not only need "Eyes". One needs QUALIFIED AND MOTIVATED EYES, along with adequated Q&A Process to tame the bugs.

    • You might have a point if the bug hadn't been found for 13 years.....in this case, the bug has been known for a long time, it was a matter of finding fingers to fix rather than eyeballs to see. So you'll have to step off your soapbox this time, abuelo.

      • Re: (Score:2)

        by Calydor ( 739835 )

        So it is fine for open source software to have known and understood bugs that no one ever bothers to take the time to fix?

        A known but unfixed bug (in this case not an exploit, but it could be) is far worse than a completely unknown bug.

        • So it is fine for open source software to have known and understood bugs

          Open source programmers should all read this book [amazon.com], and when a project doesn't fix bugs, it's time for a fork.

        • Re: (Score:2)

          by Kjella ( 173770 )

          A known but unfixed bug (in this case not an exploit, but it could be) is far worse than a completely unknown bug.

          In what universe is that? A known bug has a known severity - no, just because something doesn't work right doesn't mean it could be an exploit. Say I make a calculator to solve 2 + 2 * 2. Well shit my program is stupid and doesn't do operator precedence so it says the answer is (2+2)*2 = 8 instead of 2+(2*2) = 6. That's a bug and nothing more, it has a well defined outcome that is wrong. A known bug can be fixed if only someone cares enough to fix it. If the scope is known you could probably pay someone to

        • So it is fine for open source software to have known and understood bugs that no one ever bothers to take the time to fix?

          That depends entirely on the severity of the bug.

      • "But the key point is that both parts of the process (finding and ***fixing***) tend to happen ***rapidly.***" ESR CatB [emphasis mine]
        'Nuff Said Youngling! :-P

        • Re: (Score:2)

          by jrumney ( 197329 )

          "But the key point is that both parts of the process (finding and fixing) ***tend to*** happen rapidly." ESR CatB [emphasis mine]

          FTFY

    • I feel I need to Clarify:

      My post had nothing to do with FOSS vs Closed source development. (After all, Metafile Fiascos (afecting both), and Bugs in Windows Network Code abound).
      So, is not a criticisms of FOSS

      My post had nothing to do with BaazarStyle development vs CathedralStyle development (after all, Microsoft, Sun and Google develop(ed) FOSS Cathedral Style, with bugs to spare).
      So, no critticism to Baazar.

      If there is any criticism on my part in the post (and yes there is) is to this silly notion that

      • If there is any criticism on my part in the post (and yes there is) is to this silly notion that " " 8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.

        Regardless of the development methodology essentially all significant programs will always contain bugs. Having lots of testers tends to find them faster, having a good QA team tends to find them faster yet... but there will always be bugs remaining.

        Or, less formally, ``Given enough eyeballs, all bugs are shallow.'

        Linus was saying that given enough people looking for the cause of a known bug, the cause will be obvious to someone. He didn't say anything about finding bugs.

    • Re: (Score:2)

      by gosand ( 234100 )

      I've been in Software Testing/QA (NOT Q&A, unless you actually meant "question and answer") since 1993. I've been a manager in that field for 11 years.
      Here is the reality - in any reasonably sized project, bug-free software is a myth. And saying this to upper-management is a huge no-no that will likely get you pulled into multiple meetings and probably chastised for subverting the quality process or some such nonsense created by someone who never tested in their life.
      The whole key to it is prioritizin

  • "Windows XP was the most current desktop verison. Vista was still 3 years away." I suggest you to take some more time and write "version" correctly

  • Pretty typical of KDE (Score:1)

    by Anonymous Coward

    I have posted who knows how many bugs to the KDE bug tracking system. All legitimate and very bad bugs (I don't report minor stuff) with detailed intructions on how to reproduce and often how to fix the bug. All I get from the devs is that they can't recreate it(*) or pure silence.

    (*) Which is a joke because I know they're just too lazy to even try. If I'm reporting a bug you can be damn well sure it exists because I test and retest on multiple clean installs on various hardware. It's what I do for a living

    • Re: (Score:1)

      by Dog-Cow ( 21281 )

      Who the fuck pays you to report KDE bugs that won't even be fixed?

      Also, if you know how to fix it, submit a damned PR already and then go jump off a cliff.

Slashdot Top Deals

Children begin by loving their parents. After a time they judge them. Rarely, if ever, do they forgive them. - Oscar Wilde

Close