Abo
  1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Glibc: Fehlerhaftes Null-Byte führt…

"würden oft Zeit und Energie kosten"

  1. Thema

Neues Thema Ansicht wechseln


  1. "würden oft Zeit und Energie kosten"

    Autor: /mecki78 26.08.14 - 11:48

    Ach ja, das kennen wir Software Entwickler doch nur allzu gut. Wie oft diskutieren die Vorgesetzten mit uns ob man einen Bug fixen oder ob ein Feature implementiert sollte... und das obwohl das tatsächlich Fixen oder Implementieren nicht einmal halb so viel Zeit kosten würde wie bei der Diskussion drauf geht.

    Das ist genauso wie die Erkenntnis, das ein größerer Codeblock fundamental kaputt ist, keineswegs dazu führt, dass man diesen neu schreibt. Nein, man soll hier einen kleinen Fix einbauen, da einen Workaround und dort einen echt fiesen Hack. Und immer bricht dann irgendwann später wieder irgendwo irgendwas anderes und am Ende hat man zusammengerechnet einen ganzen Tag mit Workarounds verschwendet, statt den Codeblock in 2 Stunden einfach neu zu schreiben und nie wieder Probleme damit zu haben.

    Und dann eben dieser Fall: Man kennt den Bug, man weiß dass man ihn fixen will, diskutiert aber darüber wie dringlich der Bug ist und wie bald man ihn fixen muss. Das ist die sinnloseste Diskussion überhaupt. Jeder Bug gehört gefixed und ob man heute Bug A und morgen Bug B fixed, oder umgekehrt, ist auf lange Sicht völlig egal, weil beide gehören gefixed. Manchmal ergibt sich die Dringlichkeit von alleine, z.B. weil ein Bug für sehr viele Crashes verantwortlich ist ober aber eben ein Sicherheitsloch darstellt, für den es bereits einen Exploit gibt. Aber wenn dem nicht so ist, dann ist es sinnlos über Prios zu diskutieren, dann sollte man die Zeit lieber für's Bugfixing nutzen, weil das bringt dem Nutzer was, während Diskussionen den Nutzer meistens gar nichts bringen.

    /Mecki

  2. Re: "würden oft Zeit und Energie kosten"

    Autor: Linuxschaden 26.08.14 - 11:58

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > Ach ja, das kennen wir Software Entwickler doch nur allzu gut. Wie oft
    > diskutieren die Vorgesetzten mit uns ob man einen Bug fixen oder ob ein
    > Feature implementiert sollte... und das obwohl das tatsächlich Fixen oder
    > Implementieren nicht einmal halb so viel Zeit kosten würde wie bei der
    > Diskussion drauf geht.
    >
    > Das ist genauso wie die Erkenntnis, das ein größerer Codeblock fundamental
    > kaputt ist, keineswegs dazu führt, dass man diesen neu schreibt. Nein, man
    > soll hier einen kleinen Fix einbauen, da einen Workaround und dort einen
    > echt fiesen Hack. Und immer bricht dann irgendwann später wieder irgendwo
    > irgendwas anderes und am Ende hat man zusammengerechnet einen ganzen Tag
    > mit Workarounds verschwendet, statt den Codeblock in 2 Stunden einfach neu
    > zu schreiben und nie wieder Probleme damit zu haben.
    >
    > Und dann eben dieser Fall: Man kennt den Bug, man weiß dass man ihn fixen
    > will, diskutiert aber darüber wie dringlich der Bug ist und wie bald man
    > ihn fixen muss. Das ist die sinnloseste Diskussion überhaupt. Jeder Bug
    > gehört gefixed und ob man heute Bug A und morgen Bug B fixed, oder
    > umgekehrt, ist auf lange Sicht völlig egal, weil beide gehören gefixed.
    > Manchmal ergibt sich die Dringlichkeit von alleine, z.B. weil ein Bug für
    > sehr viele Crashes verantwortlich ist ober aber eben ein Sicherheitsloch
    > darstellt, für den es bereits einen Exploit gibt. Aber wenn dem nicht so
    > ist, dann ist es sinnlos über Prios zu diskutieren, dann sollte man die
    > Zeit lieber für's Bugfixing nutzen, weil das bringt dem Nutzer was, während
    > Diskussionen den Nutzer meistens gar nichts bringen.

    +1
    Das wirklich schlimme hier ist aber, dass es sich um OSS handelt. Ich weiß ehrlich nicht, was die da geraucht haben - aber gut, ist Red Hat, von denen erwarte ich eh nichts mehr. :)

  3. Re: "würden oft Zeit und Energie kosten"

    Autor: Jasmin26 26.08.14 - 12:06

    was hat das jetzt mit red hat/oss zu tun ?

  4. Re: "würden oft Zeit und Energie kosten"

    Autor: Ftee 26.08.14 - 12:08

    Drollig. Eigentlich ist das ein allgemeines Problem. Der Author hat nicht mal zu OSS was gesagt. Komischerweise fühlt sich die OSS-Fraktion aber angesprochen das unterschwellig was hätte gesagt sein können. Zumindest gedacht.
    Das erklärt ein wenig das Problem bei diesem Bugfix.

  5. Re: "würden oft Zeit und Energie kosten"

    Autor: Ftee 26.08.14 - 12:09

    Das sind doch keine Entwickler mehr, wenn die über ein +1 im Code diskutieren.....

  6. Re: "würden oft Zeit und Energie kosten"

    Autor: Linuxschaden 26.08.14 - 12:19

    Jasmin26 schrieb:
    --------------------------------------------------------------------------------
    > was hat das jetzt mit red hat/oss zu tun ?

    Freiwilligen, die Code einsenden, kannst du nicht mit Entlassung drohen, wenn die keinen ordentlichen Code schreiben. :) Ich weiß jetzt nicht, WER den Code geschrieben hat, wird sich wahrscheinlich mit ein bisschen Recherche rausfinden lassen, aber dafür bin ich zu faul gerade.

    Und Red Hat ... nun, von denen habe ich bisher eher wenig ordentliches zu sehen bekommen. Ich erinnere mich, mal eine Mail gelesen zu haben, wo ein Entwickler von denen (der wohl auch die glibc maintained hat) einen User angeschnauzt hat, weil sich die glibc nicht kompilieren lassen wollte. Quintessenz: "Ich verbringe keine Zeit damit, Leuten, die von ihrem System keine Ahnung haben, dieses zu erklären."

    EDIT:

    Ftee schrieb:
    --------------------------------------------------------------------------------
    > Drollig. Eigentlich ist das ein allgemeines Problem. Der Author hat nicht
    > mal zu OSS was gesagt. Komischerweise fühlt sich die OSS-Fraktion aber
    > angesprochen das unterschwellig was hätte gesagt sein können. Zumindest
    > gedacht.
    > Das erklärt ein wenig das Problem bei diesem Bugfix.

    Glibc ist OSS.
    Wie das bei Closed-Source aussieht ... nun, ich kann das nicht beurteilen, weil ich bisher immer das Glück hatte, einen kompetenteren Vorgesetzen zu haben, der, wenn ich ihm eine Mail über einen zufällig bemerkten Bug geschrieben habe, zusammen mit einem Fix (nur selten ein Workaround), immer gesagt hat: "Jau, fix mal!".
    Aber wenn man die Sachkenntnis ein bisschen senkt, glaube ich, sieht das schon ganz anders aus. Da geht dann "Features vor Fehlerfreiheit".

    Zweiter EDIT: Typo bei "Quintessenz".



    2 mal bearbeitet, zuletzt am 26.08.14 12:23 durch Linuxschaden.

  7. Re: "würden oft Zeit und Energie kosten"

    Autor: Jasmin26 26.08.14 - 12:20

    Ftee schrieb:
    --------------------------------------------------------------------------------
    > Drollig. Eigentlich ist das ein allgemeines Problem. Der Author hat nicht
    > mal zu OSS was gesagt. Komischerweise fühlt sich die OSS-Fraktion aber
    > angesprochen das unterschwellig was hätte gesagt sein können. Zumindest
    > gedacht.
    > Das erklärt ein wenig das Problem bei diesem Bugfix.


    Schon wieder so eine haltlose behauptung,! Wieso sollte das ein generelles problem sein?

  8. Re: "würden oft Zeit und Energie kosten"

    Autor: bongj 26.08.14 - 13:10

    > Ftee schrieb:
    > ---------------------------------------------------------------------------
    >
    > Glibc ist OSS.
    > Wie das bei Closed-Source aussieht ... nun, ich kann das nicht beurteilen,
    > weil ich bisher immer das Glück hatte, einen kompetenteren Vorgesetzen zu
    > haben, der, wenn ich ihm eine Mail über einen zufällig bemerkten Bug
    > geschrieben habe, zusammen mit einem Fix (nur selten ein Workaround), immer
    > gesagt hat: "Jau, fix mal!".
    > Aber wenn man die Sachkenntnis ein bisschen senkt, glaube ich, sieht das
    > schon ganz anders aus. Da geht dann "Features vor Fehlerfreiheit".
    >

    Ohne dir generell widersprechen zu wollen: Es geht auch um die Wirtschaftlichkeit. Für neue Features zahlt der Kunde, für Fehlerfreiheit in der Regel nicht. Leider kann sich nicht jedes Unternehmen den Luxus leisten, alle Fehler zu korrigieren. Ist halt eine Gradwanderung...

  9. Re: "würden oft Zeit und Energie kosten"

    Autor: EvilSheep 26.08.14 - 14:04

    Ftee schrieb:
    --------------------------------------------------------------------------------
    > Drollig. Eigentlich ist das ein allgemeines Problem. Der Author hat nicht
    > mal zu OSS was gesagt. Komischerweise fühlt sich die OSS-Fraktion aber
    > angesprochen das unterschwellig was hätte gesagt sein können.
    Ähm, OSS wurde doch recht deutlich angesprochen, zwar nciht vom Autor aber direkt im zweiten Post und darauf kam die berechtigte Frage was diese Diskussionsproblematik mit OSS zu tun haben soll.

    > Das erklärt ein wenig das Problem bei diesem Bugfix.
    Das müsstest du doch etwas genauer erklären wenn es mehr als ein bisschen inhaltsloses bashing sein soll.

    @bongj
    Aber bei entsprechend vielen Fehlern wird der Kunde irgendwann gar nicht mehr zahlen und gute PR macht so ein verhalten auch nicht.
    Klar, so lange irgendwelche BWLer am Ende bestimmen wird sich da erst mal nichts ändern, aber man sieht ja oft genug wo dieses "es geht nur um die jetzige Gewinnmaximierung" hinführt.

    Aber das ist ein generelles Problem unserer Gesellschaft.

  10. Re: "würden oft Zeit und Energie kosten"

    Autor: mnementh 26.08.14 - 14:24

    Linuxschaden schrieb:
    --------------------------------------------------------------------------------
    > Jasmin26 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > was hat das jetzt mit red hat/oss zu tun ?
    >
    > Freiwilligen, die Code einsenden, kannst du nicht mit Entlassung drohen,
    > wenn die keinen ordentlichen Code schreiben. :) Ich weiß jetzt nicht, WER
    > den Code geschrieben hat, wird sich wahrscheinlich mit ein bisschen
    > Recherche rausfinden lassen, aber dafür bin ich zu faul gerade.
    >
    > Und Red Hat ... nun, von denen habe ich bisher eher wenig ordentliches zu
    > sehen bekommen. Ich erinnere mich, mal eine Mail gelesen zu haben, wo ein
    > Entwickler von denen (der wohl auch die glibc maintained hat) einen User
    > angeschnauzt hat, weil sich die glibc nicht kompilieren lassen wollte.
    > Quintessenz: "Ich verbringe keine Zeit damit, Leuten, die von ihrem System
    > keine Ahnung haben, dieses zu erklären."
    >
    Das witzige daran ist ja, dass Redhat an Open-Source arbeitet, die Programmierer aber bezahlt. Und bezahlt wird man dann nicht für Bugfixing (was meist eh unsichtbar ist), sondern dafür megafeature XYZ in nullkommanix zusammenzustricken. Ich nehme an Mitarbeiter die in ihrer Freizeit an einem Projekt arbeiten sind meist mehr an Bugfixing interessiert, da es da um ihren Ruf geht.

  11. Spatz in der Hand...

    Autor: Anonymer Nutzer 26.08.14 - 15:54

    > (...) und am Ende hat man zusammengerechnet einen ganzen Tag
    > mit Workarounds verschwendet, statt den Codeblock in 2 Stunden einfach neu
    > zu schreiben und nie wieder Probleme damit zu haben.

    Was leider voraussetzt das der neue Code dann fehlerfrei ist. Was je nach Problemstellung nicht immer der Fall ist. Habe ich bereits erlebt: Code zum Neuschreiben an anderen Entwickler gegeben und mit anderen Fehlern zurückbekommen. Da wäre es besser gewesen den alten (verstandenen!) Code zu reparieren.

  12. Re: Spatz in der Hand...

    Autor: Linuxschaden 26.08.14 - 16:20

    Versuchsperson schrieb:
    --------------------------------------------------------------------------------
    > Was leider voraussetzt das der neue Code dann fehlerfrei ist. Was je nach
    > Problemstellung nicht immer der Fall ist. Habe ich bereits erlebt: Code zum
    > Neuschreiben an anderen Entwickler gegeben und mit anderen Fehlern
    > zurückbekommen. Da wäre es besser gewesen den alten (verstandenen!) Code zu
    > reparieren.

    Das habe ich auch mal erlebt.

    Habe für zwei Jahre eine bestimmte Bibliothek zum Maintainen bekommen, die voller Fehler war (kaputte Datenbankabfragen, dämliche Flaschenhälse und anderes Zeugs). Habe also zwei Jahre damit verbracht, immer wieder Fehler zu fixen und gelegentlich auch Features einzubauen.
    Der Projektleiter hat aber immer nur mitbekommen, dass ich Fehler melde, und hat dann gemeint, dass das mal jemand anderes komplett neuschreiben sollte. Ich habe protestiert, weil ich wusste, dass das schief gehen wird, aber der Leiter wollte nicht auf mich hören.

    Also wurde die Bibliothek komplett neu geschrieben. Und als sie dann verwendet wurde, hat diese aufgrund eines Fehlers den kompletten Arbeitsspeicher sämtlicher Maschinen belegt. Und der Programmierer, der den Code geschrieben hatte? Blickte durch sein eigenes Geschreibsel nicht mehr, und ich musste es fixen.

  13. Re: Spatz in der Hand...

    Autor: /mecki78 26.08.14 - 16:40

    Versuchsperson schrieb:
    --------------------------------------------------------------------------------
    > Was leider voraussetzt das der neue Code dann fehlerfrei ist.

    Er muss nicht fehlerfrei sein, er muss nur besser als der vorhandene sein. Wenn er nur halb so viele Fehler hat oder die Fehler alle deutlich weniger kritisch sind, dann hat man dabei schon massiv gewonnen. Dann muss man zwar immer noch Fehler ausbügeln, aber eben weniger bzw. weniger tragische.

    > Da wäre es besser gewesen den alten (verstandenen!) Code zu reparieren.

    Was voraussetzt, dass den noch irgendwer versteht und nicht der Autor sich schon selber nicht mehr im Code auskennt vor lauter if's oder weil seine Statemachine zu viele States hat, die nirgends dokumentiert sind, genauso wenig wie deren Transitions. Besonders spaßig ist es, wenn der ursprüngliche Autor dann nicht mehr greifbar ist und man schon zig Stunden überhaupt braucht um grob den Code zu verstehen, von fixen will ich noch gar nicht sprechen.

    /Mecki

  14. Re: Spatz in der Hand...

    Autor: /mecki78 26.08.14 - 16:49

    Linuxschaden schrieb:
    --------------------------------------------------------------------------------
    > Also wurde die Bibliothek komplett neu geschrieben. Und als sie dann
    > verwendet wurde, hat diese aufgrund eines Fehlers den kompletten
    > Arbeitsspeicher sämtlicher Maschinen belegt.

    Wenn das der einzige Fehler war, dann hast du unzählig bekannte und noch noch nicht entdeckte Bugs durch einen einzigen Speicherfehler getauscht. Wenn das kein massiver Gewinn ist, dann weiß ich auch nicht.

    Außerdem schreibt man keine ganze Bibliothek neu, bzw. wenn man so was machen muss, dann ist die Bibliothek wirklich misst. Ich meine, nur wegen ein paar Bugs schreibt ja auch keiner ganz glibc neu. Auch eine Bibliothek sollte modular aufgebaut sein und man schreibt dann halt mal ein Modul neu oder teile eines Modules.

    Das ganz kannst du herunterbrechen bis auf eine einzige Funktion, aber auch nur eine Funktion neu schreiben kann deutlich mehr Zeit einsparen als eine viel zu große, viel zu komplexe Funktion, in der keiner mehr durchblickt stundenlang zu debuggen, um irgend einen mysteriösen Bug zu finden. Was ich schon an Zeit damit verbraten haben Bugs zu finden, Stunden, in Funktionen oder Klassen, die ursprünglich mal in weniger als einer halben Stunde geschrieben wurden.

    /Mecki

  15. Re: Spatz in der Hand...

    Autor: Linuxschaden 26.08.14 - 17:11

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > Wenn das der einzige Fehler war, dann hast du unzählig bekannte und noch
    > noch nicht entdeckte Bugs durch einen einzigen Speicherfehler getauscht.
    > Wenn das kein massiver Gewinn ist, dann weiß ich auch nicht.

    Nein, das war er nicht, aber ich wollte die Geschichte nicht endlos werden lassen. :)
    Der Kollege hatte dann einen Monat später aufgehört, und ich war wieder mit dem Debuggen der neuen Lib beschäftigt.

    Die alte Lib funktionierte ja mittlerweile recht stabil, bekannte Probleme gab es da nicht mehr. Und wenn du sagst, dass da noch unentdeckte Fehler sein können, begeben wir uns in das Reich der Spekulation, denn bei der neuen Lib könnten ebenfalls noch nicht gefundene Fehler drin sein. Gefunden hatte ich jedenfalls noch eine ganze Menge.

    > Außerdem schreibt man keine ganze Bibliothek neu, bzw. wenn man so was
    > machen muss, dann ist die Bibliothek wirklich misst. Ich meine, nur wegen
    > ein paar Bugs schreibt ja auch keiner ganz glibc neu.

    Ich habe die Entscheidung nicht getroffen. Ich war dagegen, weil sie endlich mal stabil lief.

    > Auch eine Bibliothek sollte modular aufgebaut sein und man schreibt dann halt mal ein
    > Modul neu oder teile eines Modules.

    Stimmt. Habe ich geschrieben, dass die Lib nicht modular war? :) Gar nichts habe ich darüber geschrieben.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. VALEO GmbH, Erlangen
  2. Dataport, verschiedene Standorte
  3. msg DAVID GmbH, Braunschweig
  4. KoM-SOLUTION GmbH, Berlin

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. (-77%) 11,50€
  2. 4,32€
  3. 23,99€
  4. 2,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


In eigener Sache: Golem.de bietet Seminar zu TLS an
In eigener Sache
Golem.de bietet Seminar zu TLS an

Der Verschlüsselungsexperte und Golem.de-Redakteur Hanno Böck gibt einen Workshop zum wichtigsten Verschlüsselungsprotokoll im Netz. Am 24. und 25. September klärt er Admins, Pentester und IT-Sicherheitsexperten in Berlin über Funktionsweisen und Gefahren von TLS auf.

  1. In eigener Sache Zweiter Termin für Kubernetes-Seminar
  2. Leserumfrage Wie können wir dich unterstützen?
  3. In eigener Sache Was du schon immer über Kubernetes wissen wolltest

Transport Fever 2 angespielt: Wachstum ist doch nicht alles
Transport Fever 2 angespielt
Wachstum ist doch nicht alles

Wesentlich mehr Umfang, bessere Übersicht dank neuer Benutzerführung und eine Kampagne mit 18 Missionen: Das Schweizer Entwicklerstudio Urban Games hat Golem.de das Aufbauspiel Transport Fever 2 vorgestellt - bei einer Bahnfahrt.
Von Achim Fehrenbach

  1. Mordhau angespielt Die mit dem Schwertknauf zuschlagen
  2. Bus Simulator angespielt Zwischen Bodenschwelle und Haltestelle
  3. Bright Memory angespielt Brachialer PC-Shooter aus China

Forschung: Mehr Elektronen sollen Photovoltaik effizienter machen
Forschung
Mehr Elektronen sollen Photovoltaik effizienter machen

Zwei dünne Schichten auf einer Silizium-Solarzelle könnten ihre Effizienz erhöhen. Grünes und blaues Licht kann darin gleich zwei Elektronen statt nur eines freisetzen.
Von Frank Wunderlich-Pfeiffer

  1. ISS Tierbeobachtungssystem Icarus startet
  2. Sun To Liquid Solaranlage erzeugt Kerosin aus Sonnenlicht, Wasser und CO2
  3. Shell Ocean Discovery X Prize X-Prize für unbemannte Systeme zur Meereskartierung vergeben

  1. Hacker-Attacke: Datenleck bei Freenet-Tochter Vitrado
    Hacker-Attacke
    Datenleck bei Freenet-Tochter Vitrado

    Angreifer haben auf die Daten von rund 67.000 Vitrado-Nutzern zugreifen können. Diese sollten besser ihr Bankkonto im Auge behalten, rät die Freenet-Tochter.

  2. Android: Apps kommen auch ohne Berechtigung an Trackingdaten
    Android
    Apps kommen auch ohne Berechtigung an Trackingdaten

    Das Android-Berechtigungsmodell lässt sich mit Tricks umgehen. Eine Studie fand 1.325 Apps, die auch ohne eine Berechtigung an die entsprechenden Daten gelangen.

  3. 3D-Grafiksuite: Epic spendet 1,2 Millionen US-Dollar an Blender
    3D-Grafiksuite
    Epic spendet 1,2 Millionen US-Dollar an Blender

    Der Spielehersteller Epic Games spendet über drei Jahre insgesamt 1,2 Millionen US-Dollar an die Blender-Foundation. Der Verein zur Unterstützung der freien Grafiksuite verdoppelt damit fast seine Einnahmen.


  1. 16:37

  2. 15:10

  3. 14:45

  4. 14:25

  5. 14:04

  6. 13:09

  7. 12:02

  8. 12:01