Slashdot Mirror
KDE Bug Fixed After 13 Years (kate-editor.org)
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.)
-- 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.)
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.
That kernel was released in 2009 IIRC.
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.
First post and.. The linux kernel version is clearly wrong
a good example of expecially fast bug resolving?
Seems about right, considering the usability of the thing in particular and xDEs in general.
At this pace, we will see Hurd on desktop by next year
If we're all feeling nostalgic, this should do the trick:
The Linux Backdoor Attempt of 2003
if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
retval = -EINVAL;
Other issues back in 2003 were burning up the Linux development intertubes.
The mind behind Linux
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.
Typical KDE
The only news is that project is more than 13 years old. Any long lived product can say the same, that many low priority bugs have languished in the queue b/c not enough customers care relative to the effort required for a fix.
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!
And how exactly is any of this shit at all relevant? Furthermore, what you call good taste is actually fucking ugly. Configure your compiler to emit the proper warnings instead, then heed them.
Hopefully fixing the bug means making it identical to Gnome 2.
When it was submitted apple still had a 1 button mouse.
Some drink at the fountain of knowledge. Others just gargle.
So who cares ?
And slashdot doesn't even try to describe the bug in the summary.
Bad code is ugly code. There's zero reason not to swap the expression into something safer except "that's the way I think it in my head". Turn your head around.
Play Command HQ online
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! :(
Anons need not reply. Questions end with a question mark.
"There are concerns that KDE may not always remain open source."
Can you provide references for this statement? I have never heard any rumors of KDE going Closed Source! Not sure it is even possible!
2.6.0 was out around 2000 or 2001. 2.2->2.4->2.6 was only a 4 year window or so if I remember correctly. Due to the architectural changes 2.4 kept being updated for years (including hardware/interface backports which broke 2.4 compatibility, I don't remember the exact minor number revisions, but a number of things stopped working if you were using an older 2.4 distro.)
2.6.9 was the last of the 'real' 2.6 series, then game changing breaks happened again in like .19 and .23 mostly centering on plug and play and maybe glibc if I remember correctly.
Most userspace stuff kept working fine, but anything requiring root access was iffy on whether it broke.
I'll just leave this here: https://www.jwz.org/doc/cadt.html
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.
" 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.
*** Suerte a todos y Feliz dia!
Qt was closed source, that's what was the sand in the gear box for some people. Now Qt is open source, so there is nothing to worry about.
I loved kate until I found out about REAL IDEs. !@#$ vim. !@#$ kate. !@#$ emacs. !@#$ sublime. !@#$ notepad++.
Why not:
if (((__WCLONE|__WALL) == options) && (0 = current->uid))
retval = -EINVAL;
?
I don't think many compilers will emit a warning on that code because the assignment is surrounded by parenthesis.
"First they came for the slanderers and i said nothing."
The summary says that Cullman reported the bug initially. Cullman did not. He only triaged it as being part of kxmlgui rather than Kate.
As a long-time KDE user, this unfixed bug is the one that bothers me the most, by far:
"Dolphin doesn't refresh the folder list until I press F5"
https://bugs.kde.org/show_bug.cgi?id=244163
The bug has been present for many years, and has gone through many cycles of being marked "fixed" only to be re-opened yet again a short time later.
This bug means that you can't ever trust the list of files that Dolphin displays. That is an absolutely unacceptable bug in a file manager. If I was responsible for releasing a file manager, I would assign the highest priority to this bug, and I would not consider releasing with this bug unfixed. Imagine, for example, a word processor that randomly hides text in a document -- how can that be anything other than the most severe category bug?
I reported a Firefox usability bug in 2005... it's still not fully fixed in iceweasel and thunderbird! https://bugs.launchpad.net/firefox/+bug/18995
A real product doesn't take this long to Fitz a bug or loses sales.
"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
I'm not going to turn my head around just to appease the likes of you.
Open Source:
Closed Source|Commercial:
Both Open Source and Closed Source suffer from project abandonment.
It does seem though that Closed Source gets away with ignoring usability feature requests, and feature requests in generall
It's pretty much up to the Dev.
1) WinRar -> constantly developed and updated. Very usable.
2) Total Commander -> rarely developed. Curmudgeon single developer that hasn't implemented a single usability UI request in 10 years.
3) EmEditor -> frequent (small updates). Possibly single developer, that hasn't implemented a single usability UI request in 10 years.
Most of KDE is GPLed.
Yeah! That epine moron doesn't even understand the concept of "a constant term". He's a risk to programming projects regardless of code styles.
.dnuora daeh ruoy nruT ."daeh ym ni ti kniht I yaw eht s'taht" tpecxe refas gnihtemos otni noisserpxe eht paws ot ton nosaer orez s'erehT .edoc ylgu si edoc daB
You say it like "what's in your head" is some small insignificant function of source code. There's a reason it's not in binary like a computer would prefer, it's so we humans can work on it. Whenever you're given a problem like "solve for x" everybody in western countries ends up with "x = [value]" not "[value] = x". Sure you could learn to read backwards too, like the text above but it's extremely annoying unless you force yourself to learn it. Personally I'd rather have banned the "=" operator and made it ":=" for assignment, "==" for comparison. You could keep the complex operators like "+=" etc. but not just the equal sign. That we don't use for equality, I mean it should be obvious something's not all that smart here.
Live today, because you never know what tomorrow brings
There's zero reason not to swap the expression into something safer except "that's the way I think it in my head".
Except... your little trick only works in a very limited amount of cases, when comparing against constants. If you compare two variables, then it doesn't help swapping them around. It promotes a code style that creates a false sense of security.
My code style is to never use assignments in a boolean condition (if, while), but to put them on a separate line. And then have the compiler throw an error if I accidentally type one less equals char in a boolean comparison. That results in much safer code than your half trick that doesn't really work.
Linux kernel version 2.6.31 was released in 2009, not 2003...
I back port all the kernel bugs and features to 2.6.31 still.
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.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
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. KDE is infected to the core with this lazy attitude.
Alternatively, learn to pay attention to -Wall.
I completely agree, and do the same thing. Assignments inside a conditional statement are horrendous, because it's not immediately clear whether the developer intended to make an assignment or a comparison. Moreover, the result of an assignment isn't as immediately obvious to anyone reading the code. It's one of the shittier "features" of C.
I've never understood people that try to shove as much shit as possible in a single line of code. It generally doesn't compile to more efficient machine code at all, and just makes it more difficult to parse by a human reader, which many developers underestimate the importance of. Just the other day I realized I'd been bit by a precedence bug when I was "sure" that I knew the correct precedence, only I didn't. It's just not worth being "clever". Boring, obvious code is the best code, for a variety of reasons.
Irony: Agile development has too much intertia to be abandoned now.
Boring, obvious code is the best code, for a variety of reasons.
That's why I choose... COBOL.
I kid, I kid.
But then 'real programmers' don't need hand-holding where others would delegate responsibility for such low level gotchas to a compiler. :)
KDE, like Gnome and Unity, have outlived their usefulness. With the current hardware, the desktop is an issue that has been solved long ago. Developers behind these three projects insist in making mostly inane changes, probably for the sake of staying relevant - or, rather, to appear to stay relevant. But they are not, and they have not been for some five years or so.
So many of the posters here are missing the context. At the time that bug was found, compilers, especially GCC, did not warn about assignments in conditional statements. Now, they do*.
* experience with GCC and clang. Both force double parentheses to indicate assignment is actually desired.
At the time that bug was found, compilers did not warn. Now, both GCC and clang will warn unless you enclose the assignment in two sets of parentheses.
Still waiting on ftape for my old QIC-80.
If someone is too inflexible to solve their algebra problems with [value] = x, then they probably should not take up programming as a career.
Play Command HQ online
I've seen bugs from the 1990s finally fixed in our OS. In other words, yes it's bad that the bugs aren't fixed, but this is pretty darn "new" in my opinion to warrant a "wow, such an old bug was fixed" kind of story.