Bug der Woche – äh, des Monats – nein, des Jahres – ach was, des Jahrzehnts!
Vor ein paar Jahren habe ich in Inkscape (freies Graphikprogramm unter Linux) einen Fehler festgestellt, nämlich dass man die Farbe der Spitze und des Endes von Pfeilen (allgemein Linienverzierungen) nicht ändern kann. Oder so ähnlich. Ist schon so lange her, dass ich es nicht mehr genau weiß. Beim Melden des Bug Reports fiel auf, dass es schon einen Bug-Report dazu gibt. Also habe ich mich auf den zum Lesen mit draufgesetzt. Seitdem kommen immer wieder mal Mails dazu, wer dran arbeitet, wie man das Problem lösen könnte, dass es doch eigentlich trivial sei usw. Es ist überhaupt der Bug, zu dem ich mit Abstand am meisten zu lesen bekam.
Nur: Gelöst wurde das Problem nie. Sie diskutieren und diskutieren, aber niemand löste das Problem. Bis neulich. Zumindest laut Bug-Report hat sich vor ein paar Tagen dann endlich mal jemand erbarmt und einen Fix eingebaut. Bedenkt man das Aktualisierungstempo mancher Linux-Distrubutionen, könnte man vermutlich schon in ca. einem Jahr unter Linux bunte Pfeile machen.
Eben wies jemand dazu darauf hin, dass der Bug Report eigentlich schon von 2004 stammt. Soll keiner sagen, dass die Open Source Gemeinde nicht sorgfältig arbeitet und jeden Bug eingehend untersucht. Quick and Dirty ist nicht ihr Ding.
13 Kommentare (RSS-Feed)
Den Bug habe ich auch schon vor 2004 gefunden. Aber ich melde sowas nicht mehr. Endlose Diskussionen, kein Nutzen. Überhaupt, dass man sich erst aufwendig registrieren muss wenn man auf einen Fehler hinweisen will. Kennst du den Bug in dem Minenspiel, egal auf welchem Betriebssystem, den gibt es überall und seit es das Spiel gibt (Ecke, 4 Felder, die drei um das Eckfeld haben eine Mine, das Eckfeld kann keine haben, hat aber eine). Wurde auch nie behoben.
Auch ist die Liste der Duplicates nicht gerade klein…
allerdings ist es leider oft so, dass bestimmte Bugs auf Jahre nicht angefasst werden und manchmal erst durch ein Rewrite des betreffenden Codes gefixt werden.
Es gerüchtet aber, dass dies kein spezielles Problem von offener, freiwillige geschriebener Software ist, sondern dass dies in kommerziellen Produkten ähnlich läuft. Nur kann man da nicht die Liste der offenen Bugs einsehen.
Mir ist es aufgefallen und ich habe mich daran gestört. Aber ich habe es hingenommen, in dem Sinne, dass das in der gegenwärtigen Version halt noch nicht möglich ist, warum auch immer. Man will ja nicht drängeln, wenn man schon Open Source nutzt, aber selbst gar nichts fixen kann …
Dafür ist bei OpenSource auch das Gegenteil möglich.
Letztes Jahr verwendete ich QLandkarteGT, um POI für meinen Urlaub zusammenzustellen. Bei einer bestimmten Klickreihenfolge gab es einen segfault. Ich fand den IRC-Kanal mit Support für QLandkarteGT und wurde darauf hingewiesen, dass eine neuere Version existiert.
Bei der Gelegenheit wies ich auf ein Detail hin, das verbessert werden könnte. Nach sieben Minuten antwortete der Entwickler, dass die Änderung im SVN sei. Zwanzig Minuten darauf arbeitete ich bereits mit der aktuellsten aus dem SVN (von mir selbst) kompilierten Version der Software.
Um solchen Support im kommerziellen Bereich zu erhalten, muss man vermutlich das GoldPlatinRhodiumPalladium-Supportlevel ordern.
Klar, ich hatte Glück, dass jemand im IRC war und Zeit hatte und antwortete und mein issue vermutlich trivial war undundund.
Begeistert war ich trotzdem!
Interessant, das ist ein Bug? Hätte nie erwartet, dass das überhaupt geht 😉
Hab bei Inkscape auch schon seit 2 Jahren einen Bug beobachtet, der sogar schon seit 2007 existiert. Bug #168244, falls das jemand wissen will: image-Tags können kein SVG enthalten. Ist ne klare Verletzung des SVG-Standards. Mittlerweile weiß wohl immerhin jemand, warum das so ist.
Glückwunsch.
Erinnert mich an folgenden Bug:
Wenn man (seit booten des Rechners) zum ersten Mal den Ordner /usr/bin in einem grafischen Dateimanager öffnet (mit Nautilus und Thunar probiert), dann dauert es auf einem nicht mehr ganz jungen Laptop mit IDE-Festplatte ca. 30, 40s, bis die Liste der Dateien (ca. 2000) angezeigt wird.
Benutzt man es dann zum 2. Mal geht es ratz-fatz, scheint also qua Caching für die Leute nicht schlimm, die den Rechner eh nie ausmachen.
Im Vergleich dazu: Startet man den Midnight-Commander in /usr/bin ist die Ansicht sofort da – keine spürbare Latenz. Das deutete ein wenig drauf hin, dass die Icons oder Fonts des GUI-Tools soviel Zeit zum Laden benötigen, aber der Font muss ja nur einmal geladen werden, und die Icons sind auch alle gleich, und wenn man zuvor in einem anderen, kleineren Verzeichnis gestöbert hat ist das ja alles schon geladen – die Erklärung überzeugt nicht wirklich.
Ich dachte aber darüber nach, erstmal abzuschätzen, wieviele Dateinamen man lesen muss, wieviele in so ein Fenster passen, je nach Schriftgröße, Fenstergröße, Ansichtsform (lange/kurze Liste, Icons groß/klein), und dass man doch 50 Namen lesen könnte, Anzeigen, und dann im Hintergrund den Rest lesen, sollte der User zu scrollen beginnen. Ich dachte erstmal einen Prototypen in Java zu programmieren, bevor ich die Quellen von GTK durchstöbere, wo diese Routine (File-Open-Dialog?) überhaupt versteckt ist. Ich bin auch in C völlig raus, und habe nie GTK gelernt.
Dabei zeigte sich aber, dass der popelige File-Open-Dialog von Java (JFileChooser) überhaupt nicht so eine träge Reaktionsweise kennt. Im Vergleich zu mc dauert es ein wenig, aber nicht eine halbe Minute.
Ich habe das nur als Usabilitybug gemeldet – kleine Notiz am Rande: Um sie zu beschämen habe ich geschaut wie es bei Windows-XP aussieht, etwa in /windows/system32 wo auch viele Dateien rumliegen – jetzt nicht wirklich viele, aber eben deutlich mehr, als in ein Fenster passen.
Lustiges Ergebnis: Da dauert es ähnlich lange. 🙂 Inzwischen hat sich ja weitgehend rumgesprochen, dass die Langsamkeit Javas eine Jugendsünde war, und Java längst C das Wasser reichen kann, sporadisch auch umgekehrt, aber so viel schneller ist Java dann doch nicht, da muss noch sonstwo der Hase im Pfeffer liegen.
Nach wenigen Monaten gab es dann eine Confirmed-Notification. Alle paar Monate meldet sich entweder jemand mit einem Duplicate, oder ein anderer bestätigt das Fortbestehen des Problems auch mit der neuesten (X)Ubuntuversion.
Die Jahreszeiten vergehen. Emails tauchen auf der CC-Liste auf. Emails werden von der CC-Liste entfernt. Die Kinder werden eingeschult, gehen auf die Uni, gehen in Rente. Der Bug bleibt.
https://bugzilla.gnome.org/show_bug.cgi?id=356836
Mit 2004 kann ich nicht konkurrieren – 2006-09-20 ist doch eher nur ein Bug mittleren Alters. 🙂
leider treffe ich auch imemr wieder auf Bugs, die die Leute schon vor Jahren gahabt haben und die immer noch nicht gelöset sind.
letztens wieer ein thunderbird-problem (zusammen mit glibc) dasß sich anscheinend auch seit version 5.0 hält (Anzahl offener Dateien zu groß).
Offensichtlich sind neue Features wichtiger als alte Bugs.
Bei kommerzieller Software sieht es leider auch nicht besser aus. 🙁
Schau dir das doch mal mit strace an. 500 Symlinks im Verzeichnis? nautilus öffnet, liest und schließt 500 Mal die Datei mit dem Overlay-Icon für Symlinks.
So gesehen keine schlechte Performance. Die paar Sekunden sollten dann nämlich genauso für ein Verzeichnis mit ein paar tausend (verschiedenen) Bildern gelten. Dass dir das langsam vorkommt, weil du für /usr/bin nicht die Komplexität von ein paar Tausend Vorschaubildern erwartest, zeigt doch nur, dass du nautilus falsch benutzt 😉
Ich weiß nicht, wie wichtig es ist, Pfeile mit Stiel und Spitze verschiedenfarbig zu malen (ich würde dann einfach zwei separate setzen, einen ohne Spitze und einen mit Länge Null), aber Bugs aus der Steinzeit kann ich auch bieten: Die Tools aus dem Paket psutils (Manipulation von Postscript-Files) enthalten ein paar Zeilen Code, die die Funktion setpagedevice durch einen Dummy ersetzen. Da Drucksysteme dem eigentlichen Datenstrom Code voranstellen, der diese Funktion enthält (zur Schachtauswahl in Laserdruckern usw.), kann man umskalierte Dokumente nur noch aus dem Handeinzug drucken (oder man pipet das noch durch “sed -e ‘/^\/setpagedevice.*bin/,+1d'”). Der Fehler ist seit mindestens 2003 drin.
Ach, von solchen Bugs kann ich Lieder singen. Wenn man mal in den OpenOffice-Bugtracker schaut findet man hunderte Bugs die viele Jahre alt sind – einer der Gruende fuer den LibreOffice-Fork. Dort werden dann aber auch mal wieder schnell neue Bugs eingefuehrt, z.B. geht schon seit einigen Versionen das automatische Hochstellen des Anhaengels bei englischen Zahlwoertern wie 1st, 2nd etc. nicht. Wann es gefixt wird – niemand weis es.
Besonders toll fand ich letztens einen Bug/Feature-Request im freien K9-Mail – ich hatte vor etlichen Jahren berichtet, dass im dunklen Thema die EMail-Liste zwar weiss auf schwarz aussieht, aber die EMails selber weiterhin schwarz auf weiss dargestellt werden. Gut, nicht trivial, aber kuerzlich hatte ein Entwickler dafuer eine Loesung gefunden und eingebaut. Gleich darauf meldeten sich etliche Nutzer dass sie doch das alte (inkonsistente) Verhalten viel besser faenden und was das denn solle etc. Der Entwickler musste sich dann fast dafuer entschuldigen, dass korrigiert zu haben und sah sich genoetigt, weitere Optionen einzubauen, um auch das alte Verhalten wieder abzubilden.
Bei i3 soll man angeblich ganz ohne den ganzen Anmeldeschwachsinn der meisten anderen Bugtrackertools, unbürokratisch also, bugreports einbringen können… und die werden dann auch schnell bearbeitet…???
http://m.youtube.com/#/watch?v=QnYN2CTb1hM&desktop_uri=%2Fwatch%3Fv%3DQnYN2CTb1hM&gl=DE
Benutze i3 auf meinem einen Linuxrecher und bin vollauf zufrieden mit dem Teil…
…obwohl ich nur ein Subset der Möglichkeiten überhaupt nutze…
Zählen aus selbst gefixte Bugs? Ich habe da einen von initial Commit des TYPO3 CMS Projektes (03.10.2003) gefixt:
http://git.typo3.org/TYPO3v4/Core.git?a=commitdiff;h=3585c3bcca023da578a0a84e78d8bcbf80e6b158
(Beiweis; die Datei wurde nur umbenannt)
http://git.typo3.org/TYPO3v4/Core.git?a=blob;f=t3lib/class.t3lib_timetrack.php;h=0c71e6258226b5a5fa0bede2321a75538a7f5b59;hb=cfd5961c1ce6b3b8bcfdbbc819e62fbfee557abd#l308
Das hat mich eine halbe Stunde Debugging gekostet, bis ich gemerkt habe, dass der Code schlicht falsch ist (aber mit PHP <5.4 funktioniert hat).
Allerdings ist der TYPO3 CMS Bugtracker eher ein Musterbeispiel für lange liegen Bugs, wie du auch einen in deinem Blogpost beschreibst.
Interessant, ist mir nie aufgefallen. Scheint auch sonst nicht Vielen aufgefallen zu sein, bzw. es haben sich dann nicht Viele daran gestört.