1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Bug im Linux-Kernel: Keine Panik!

OK, gehen wir das noch mal durch ...

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. OK, gehen wir das noch mal durch ...

    Autor: Linuxschaden 12.04.16 - 12:54

    Maschine wird auf Kernel 4.2 aktualisiert, und plötzlich läuft der Flaunsch nicht mehr. OK.

    Erstmal muss das Problem reproduziert werden können. Nicht nur vom Kunden, sondern von dem Kerl, der das Problem debuggen muss. War der Fall. OK.

    Da das Problem mit dem Kernel-Update aufkam und es sich hier um eine Panic handelt, ist der Fehler im Kernel oder in der Hardware zu suchen. Und da es vorher funktioniert hat, muss der Kernel jetzt irgendwas anders machen als vorher. Sprich, Fehler ist im Kernel zu suchen.

    Dann probiert man die verschiedenen Kernel durch. Kernel zu installieren sollte unter Ubuntu nicht länger als 5 Minuten dauern, dann hat man eine Liste von Kerneln auf /boot - ich glaube, Ubuntu hat noch Update-Skripte, damit die grub.cfg aktualisiert wird, dann braucht man die nicht manuell abändern. So, und dann bootet man der Reihe nach die Kernel und kuckt, wo das Problem auftaucht. Es hängt natürlich von der Bootzeit so einer Maschine ab, aber sagen wir mal, das Ding braucht 15 Minuten pro Versuch (in meiner eher bescheidenen Erfahrung mit Servern ist das immer noch hoch gegriffen, es sei denn, man startet wirklich jeden Dienst manuell). Da komme ich selbst mit Prokrastination und Kaffeepauen auf nicht mal einen Tag, bis man herausgefunden hat, ab wann das Problem auftaucht.

    So, dann fängt man an, den Kernel zu entschlacken. Man sieht ja in den Screenshots unzählige Module eingeladen. Man fängt jetzt an, solange Module auszuladen bzw. gar nicht mehr einladen zu lassen, bis man den Fehler nicht mehr reproduzieren kann. In diesem Fall wären dann bestimmt Fuse hängenbelieben, zusammen mit noch ein paar anderen Modulen.

    Und dann schaut man sich die Änderungen auf die jetzige Kernelversion an und prüft bei den Modulen, die man noch auf der Liste hat, ob es da Änderungen gab. Und bei Fuse gab es die. Dann versucht man, den alten Code des Moduls in den neuen Kernel zu bringen (funktioniert nicht immer, die Interfaces zwischen den verschiedenen Kernel-Teilen sind nicht wirklich stabil, das weiß ich selbst), aber wenn's funktioniert, dann hat man schonmal Fuse als Einstiegspunkt.

    Worauf ich hinauswill: mir ist nicht klar, wie man dafür 4 Montate brauchen kann. Außer natürlich, man setzt das Ganze auf den ToDo-Stapel und kuckt es sich dann mal an, wenn ein Entwickler gerade mal Zeit hat. Was ja klasse ist, einen Kunden mit veralterter Software laufen zu lassen. Immerhin werden Bugfixes noch auf ältere Kernel portiert, sonst hätte ich mir einen Vergleich zu Oracle, die ihre Kunden lieber Monatelang in Messer laufen lassen, nicht verkneifen können ...

  2. Re: OK, gehen wir das noch mal durch ...

    Autor: jkow 12.04.16 - 13:50

    Ja, wenn man den Pfad zum Erfolg vorher kennt, ist das natürlich so einfach.

    Wenn nun aber nicht nur Fuse sondern hundert andere Kernel-Bestandteile geändert wurden? Soll man sich dann in alle potenziell verursachenden Kernelmodule und APIs erstmal reinarbeiten, diese bis aufs letzte verstehen (und da genügt es nicht, nur die Änderungen zu verstehen),... ich glaube, Du hast noch nie Kernel-Bugs untersucht.

    Der Weg über den Stack-Trace zur Identifikation des verursachenden Moduls war genau richtig. Dass die Fuse-Entwickler nicht reagierten, ist ein Problem des Fuse-Projekts. Dass sich andere Entwickler des Problems annehmen konnten und schließlich auch annahmen, ist einer der großen Vorteile von Open Source Software!

    Natürlich dauert es Zeit, wenn sich Entwickler erstmal in einen fremden Treiber einarbeiten müssen. Außerdem haben die Leute üblicherweise auch andere Themen auf dem Tisch. Sie können nicht plötzlich Vollzeit an einem Bug arbeiten, den irgend ein User an sie heranträgt. Da zeigt ihnen der Chef einen Vogel.

    Meiner Meinung nach ist der Bericht ein hervorragendes Beispiel für Zusammenarbeit verschiedener Parteien in der OpenSource-Welt.

  3. Re: OK, gehen wir das noch mal durch ...

    Autor: frostbitten king 12.04.16 - 14:04

    Oder einfach git-bisect. Man wusste ja schon dass es zwischen 4.1 und 4.2 war.
    Man wusste es hatte mit fuse zu tun. Ok, ..
    > git-bisect
    > git checkout 4.2
    > git bisect bad
    > git checkout 4.1
    > git bisect god
    and go.
    ..und dann schaut ma sich die Änderung an und sagt das dem Entwickler.

  4. Re: OK, gehen wir das noch mal durch ...

    Autor: Linuxschaden 12.04.16 - 14:06

    jkow schrieb:
    --------------------------------------------------------------------------------
    > Ja, wenn man den Pfad zum Erfolg vorher kennt, ist das natürlich so
    > einfach.

    Bitte?

    Deswegen bin ich doch direkt naiv an die Sache rangegangen. Informationen beschaffen, und dann Zusammenhänge finden. Das mache ich täglich.

    > Wenn nun aber nicht nur Fuse sondern hundert andere Kernel-Bestandteile
    > geändert wurden? Soll man sich dann in alle potenziell verursachenden
    > Kernelmodule und APIs erstmal reinarbeiten, diese bis aufs letzte verstehen
    > (und da genügt es nicht, nur die Änderungen zu verstehen),... ich glaube,
    > Du hast noch nie Kernel-Bugs untersucht.

    *Gähn*

    Hast du direkt was an meiner Methodik auszusetzen, oder kommen da nur Allgemeinplätze?

    Ich muss Software nicht in ihrer Gänze verstehen, solange diese nur ordentlich modular aufgebaut ist. Bevor ich die Listen erstelle, von denen ich sprach, schaue ich nicht ein einziges Mal in den Source, das mache ich erst dann, wenn ich besagte Liste habe. Wenn du ein Problem damit hast, WIE ich die Liste erstelle, dann würde ich vorschlagen, dass du dagegen mal argumentierst.

    > Der Weg über den Stack-Trace zur Identifikation des verursachenden Moduls
    > war genau richtig. Dass die Fuse-Entwickler nicht reagierten, ist ein
    > Problem des Fuse-Projekts. Dass sich andere Entwickler des Problems
    > annehmen konnten und schließlich auch annahmen, ist einer der großen
    > Vorteile von Open Source Software!

    Und noch mal eine Runde: bitte, was?

    In den Screenshots zieht man deutlich, dass die Panic auch an anderer Stelle auftaucht. Einmal in fuse, einmal in ext4. Sowas deutet häufig auf Speicherkorruption hin, und sowas zu fixen kann relativ unangenehm sein - weil der eigentliche Fehler auch an einer komplett anderen Stelle sein kann. Da übergebe ich einer Funktion einen invaliden Pointer, der Fehler ist beim Funktionsaufruf, aber den Fehler sieht man erst 5 Stapel weiter unten ...

    > Natürlich dauert es Zeit, wenn sich Entwickler erstmal in einen fremden
    > Treiber einarbeiten müssen. Außerdem haben die Leute üblicherweise auch
    > andere Themen auf dem Tisch. Sie können nicht plötzlich Vollzeit an einem
    > Bug arbeiten, den irgend ein User an sie heranträgt. Da zeigt ihnen der
    > Chef einen Vogel.

    Sach an. Leider haben sie, als dann endlich mal ein Entwickler zur Stelle war und sie das Problem reproduzieren konnten, immer noch 4 Monate gebraucht. Sprich: da war bereits ein Entwickler reserviert gewesen.

    Die Zeit davor habe ich bewusst ignoriert, weil es sein kann, dass es da tatsächlich was besseres zu tun gab. Aber danach ... tja, macht halt den Eindruck, als hätten sie es entweder liegenlassen, oder als ob es den verschiedenen Entwicklern wie einen Schwarzen Peter zugeschoben wurde, bis sich dann mal jemand erbarmt und Korrelationen gesucht hat ...

    > Meiner Meinung nach ist der Bericht ein hervorragendes Beispiel für
    > Zusammenarbeit verschiedener Parteien in der OpenSource-Welt.

    Hahaha.

  5. Re: OK, gehen wir das noch mal durch ...

    Autor: chefin 12.04.16 - 14:19

    Also mal ehrlich: du baust das Dateisystem aus und dann funktioniert deine VM nicht mehr. Und das nimmst du dann als Fehlerquelle. Wenn mein Auto nicht mehr anspringt sobald ich die Reifen aufziehe sind die Reifen schuld?

    Tja, wenn Software so einfach wäre, würden alle zu dir kommen um ihren Service zu machen. Aber so einfach ist es nicht. Die Fuseentwickler haben alles richtig gemacht. Der Kernelentwickler aber auch. Und solange nur geringe "Last" auf dem System war, hat es auch funktioniert. Also in deinem Aufbau hätte es den Fehler nie gegegeben. Erst wenn viele Maschinen zusammen kommen und dadurch Laufzeitverzögerungen auftreten kommt es zum Fehler.

    Also du würdest den fehler heute noch suchen, glaubs mir.

  6. Re: OK, gehen wir das noch mal durch ...

    Autor: Linuxschaden 12.04.16 - 14:30

    @chefin:

    Du ergibst keinen Sinn, Sorry.

    schrieb:
    > Also mal ehrlich: du baust das Dateisystem aus und dann funktioniert deine
    > VM nicht mehr. Und das nimmst du dann als Fehlerquelle. Wenn mein Auto
    > nicht mehr anspringt sobald ich die Reifen aufziehe sind die Reifen
    > schuld?

    Bist du C-Programmierer? Ich bin es nämlich. Obwohl man nicht mal C-Programmierer sein muss, um das zu verstehen.

    Dein Vergleich hinkt. Weil ich gerade in Factorio drin bin, nimm mal das Beispiel: ich habe den Ausstoß an Kupferplatten erhöht, und plötzlich habe ich nicht mehr genug Eisen. Wie kommt's? Eisen und Kupfer sind doch zwei völlig unterschiedliche Ressourcen?

    Erst, wenn man dann die Wege zurückverfolgt (Code ließt), ergibt sich das Bild. Durch das Kupfer können sehr viel mehr Kupferdrähte hergestellt werden, die für die Erstellung von Schaltkreisen benötigt werden. Die Eisenproduktion, die vorher für das Erstellen der Schaltkreise locker mitgekommen ist, kann jetzt nicht mehr mithalten.

    > Tja, wenn Software so einfach wäre, würden alle zu dir kommen um ihren
    > Service zu machen. Aber so einfach ist es nicht. Die Fuseentwickler haben
    > alles richtig gemacht. Der Kernelentwickler aber auch. Und solange nur
    > geringe "Last" auf dem System war, hat es auch funktioniert. Also in deinem
    > Aufbau hätte es den Fehler nie gegegeben. Erst wenn viele Maschinen
    > zusammen kommen und dadurch Laufzeitverzögerungen auftreten kommt es zum
    > Fehler.

    Und auch hier bitte ich dich, ins Detail zu gehen, wo mein Ansatz der naiven Fehlersuche fehlerhaft ist.

    Ich sage dir, dass ich schon beschissenere Fehler gefunden habe - Fehler, die sich leider NICHT so einfach reproduzieren lassen. Und das hat mich lange keine 4 Monate gekostet.

    > Also du würdest den fehler heute noch suchen, glaubs mir.

    Blödsinn.

  7. Re: OK, gehen wir das noch mal durch ...

    Autor: jkow 12.04.16 - 14:49

    Linuxschaden schrieb:
    --------------------------------------------------------------------------------
    > Ich muss Software nicht in ihrer Gänze verstehen, solange diese nur
    > ordentlich modular aufgebaut ist.

    Sorry, aber das ist ein Allgemeinplatz.

    Der Linux-Kernel ist modular aufgebaut, deshalb heißen die Treiber auch Module. Innerhalb eines Treibers aber logische Probleme zu debuggen verlangt ein tieferes Verständnis zum Aufbau des Treibers. Und da hat man es schnell mit Low-Level-optimiertem Code zu tun und der ist dann nicht mehr schön, einfach oder modular. Da geht es primär um Performance. Einfach nur ein Changeset angucken hilft da meistens gar nichts.

    Deshalb bleibe ich dabei: Wenn Du noch nie den Kernel debugged hast, kannst Du mit Deinen Allgemeinplätzen zu "wie debugge ich Software" mal schön zuhause bleiben.

    > In den Screenshots zieht man deutlich, dass die Panic auch an anderer
    > Stelle auftaucht. Einmal in fuse, einmal in ext4. Sowas deutet häufig auf
    > Speicherkorruption hin, und sowas zu fixen kann relativ unangenehm sein -

    Ja – so ist das eben. Da kann es sein, dass ein Stack Trace nicht weiter hilft, dennoch würde ich diesen als erste Informationsquelle gegenüber einem Kernel-Diff bevorzugen.

    > Sach an. Leider haben sie, als dann endlich mal ein Entwickler zur Stelle
    > war und sie das Problem reproduzieren konnten, immer noch 4 Monate
    > gebraucht. Sprich: da war bereits ein Entwickler reserviert gewesen.

    Das waren aber nicht die Fuse-Entwickler, wenn ich das richtig verstanden habe, sondern Quobyte und Canonical.

    > > Meiner Meinung nach ist der Bericht ein hervorragendes Beispiel für
    > > Zusammenarbeit verschiedener Parteien in der OpenSource-Welt.
    >
    > Hahaha.

    Lach Du mal. Ich bin froh, dass ich Dank solcher Zusammenarbeiten ein mächtiges System zur Verfügung habe, welches ich auch selbst je nach Anforderungen meiner Projekte anpassen und vorantreiben kann.

  8. Re: OK, gehen wir das noch mal durch ...

    Autor: Linuxschaden 12.04.16 - 15:05

    jkow schrieb:
    --------------------------------------------------------------------------------
    > Sorry, aber das ist ein Allgemeinplatz.

    Nein, das ist Erfahrung.
    Der Code, um testdisc nur gelöschte Dateien anzeigen zu lassen, der Code in Wine, um Transparenz in Texten darzustellen, und die Korrekturen, die ich bei Mednafen durchführen musste (weil diese ihre Kompilerchecks verbockt haben), geben mir recht.

    > Der Linux-Kernel ist modular aufgebaut, deshalb heißen die Treiber auch
    > Module. Innerhalb eines Treibers aber logische Probleme zu debuggen
    > verlangt ein tieferes Verständnis zum Aufbau des Treibers. Und da hat man
    > es schnell mit Low-Level-optimiertem Code zu tun und der ist dann nicht
    > mehr schön, einfach oder modular. Da geht es primär um Performance. Einfach
    > nur ein Changeset angucken hilft da meistens gar nichts.

    Verzeihung ...

    Vorher: Tut
    Nachher: Tut nicht

    Um sicherzustellen, dass das Problem innerhalb des Fuse-Codes ist, soll man ja erst mal den Originalcode des Modules wiederherstellen. Wenn das nicht funktioniert, liegt das Problem woanders (duh!). Wenn es funktioniert, hat man den Fehler gefunden, er liegt in Fuse.

    Das ist einfache Logik!

    > Deshalb bleibe ich dabei: Wenn Du noch nie den Kernel debugged hast, kannst
    > Du mit Deinen Allgemeinplätzen zu "wie debugge ich Software" mal schön
    > zuhause bleiben.

    Hahaha.
    Du wirfst mit Allgemeinplätzen rum und wirfst mir diese gleichzeitig vor.
    Ich sag jetzt einfach mal, dass du vollkommen inkompetent bist, und dass dein Arbeitgeber noch viel inkompetenter ist, dass er das nicht realisiert. Wenn dir das nicht gefällt, dann kannst du mich entweder ignorieren, oder du erklärst mal im Detail, was an meiner Methodik falsch ist.

    Nee, weißt du was, nach der zweiten Aufforderung reicht mir das. Spar's dir.

    > Ja – so ist das eben. Da kann es sein, dass ein Stack Trace nicht
    > weiter hilft, dennoch würde ich diesen als erste Informationsquelle
    > gegenüber einem Kernel-Diff bevorzugen.

    Gaaaaaaaaaaaaaaaaaaah ...

    Genau das habe ich doch gemacht, du Aushilfsprogrammierer! Wenn das Problem immer an einer Stelle auftauchen würde, ist ja alles prima, da kann man dann direkt in der Funktion nachschauen, was die macht. Wenn das aber nicht der Fall ist, dann haste Probleme mit dem Speicher.

    Das lernt jeder, der sich mal eine Stunde intensiv mit dynamischer Speicherverwaltung in C und C++ beschäftigt!

    > Das waren aber nicht die Fuse-Entwickler, wenn ich das richtig verstanden
    > habe, sondern Quobyte und Canonical.

    Ich habe niemals die Fuse-Leute erwähnt. Ich habe lediglich geschrieben, dass 4 Monate Bearbeitungszeit stinken - EGAL von wem.

    Sag mal, wie kannst du eigentlich so toll Code debuggen, wenn du nicht mal Deutsch lesen kannst?

    > > > Meiner Meinung nach ist der Bericht ein hervorragendes Beispiel für
    > > > Zusammenarbeit verschiedener Parteien in der OpenSource-Welt.
    > >
    > > Hahaha.
    >
    > Lach Du mal. Ich bin froh, dass ich Dank solcher Zusammenarbeiten ein
    > mächtiges System zur Verfügung habe, welches ich auch selbst je nach
    > Anforderungen meiner Projekte anpassen und vorantreiben kann.

    Hahaha.

  9. Re: OK, gehen wir das noch mal durch ...

    Autor: jkow 12.04.16 - 15:24

    Linuxschaden schrieb:
    --------------------------------------------------------------------------------
    > Um sicherzustellen, dass das Problem innerhalb des Fuse-Codes ist, soll man
    > ja erst mal den Originalcode des Modules wiederherstellen. Wenn das nicht
    > funktioniert, liegt das Problem woanders (duh!). Wenn es funktioniert, hat
    > man den Fehler gefunden, er liegt in Fuse.

    Es wird nicht besser. Hab ich schonmal erwähnt, dass Deine Userspace-Erfahrungen hier nicht viel nützen?

    Du willst also bei hunderten Modulen mal eben die Änderungen zur Vorversion zurückbauen und dann testen, ob's noch läuft? Na viel Spaß, das in einem Tag durchzuziehen. Witzbold. Da kann es Dir passieren, dass Du nach vier Wochen noch dran sitzt und versuchst eine Treiber-Änderung, die durch Änderung an einer Kernel-API notwendig wurde, rückgängig zu machen und lauffähig zu bekommen. Am besten portierst Du dann gleich auch auf die alte Kernel-API zurück.

    > > Deshalb bleibe ich dabei: Wenn Du noch nie den Kernel debugged hast,
    > kannst
    > > Du mit Deinen Allgemeinplätzen zu "wie debugge ich Software" mal schön
    > > zuhause bleiben.
    >
    > Hahaha.
    > Du wirfst mit Allgemeinplätzen rum und wirfst mir diese gleichzeitig vor.

    Ja stell Dir mal vor. Und jetzt denk mal drüber nach.

    > Ich sag jetzt einfach mal, dass du vollkommen inkompetent bist, und dass
    > dein Arbeitgeber noch viel inkompetenter ist, dass er das nicht realisiert.

    :-)

    Schönes Leben noch.

  10. Re: OK, gehen wir das noch mal durch ...

    Autor: Linuxschaden 12.04.16 - 15:30

    jkow schrieb:
    --------------------------------------------------------------------------------
    > Es wird nicht besser. Hab ich schonmal erwähnt, dass Deine
    > Userspace-Erfahrungen hier nicht viel nützen?

    Wow.

    Da erkläre ich dir genau, warum das, was du erzählst, Blödsinn ist, und dann ignorierst du es immer noch. Na dann noch der hier für's Archiv:

    > Du willst also bei hunderten Modulen mal eben die Änderungen zur Vorversion
    > zurückbauen und dann testen, ob's noch läuft? Na viel Spaß, das in einem
    > Tag durchzuziehen. Witzbold. Da kann es Dir passieren, dass Du nach vier
    > Wochen noch dran sitzt und versuchst eine Treiber-Änderung, die durch
    > Änderung an einer Kernel-API notwendig wurde, rückgängig zu machen und
    > lauffähig zu bekommen. Am besten portierst Du dann gleich auch auf die alte
    > Kernel-API zurück.

    Alleine das zeigt, dass du KOMPLETT inkompetent bist. Warum? Na deswegen:

    >So, dann fängt man an, den Kernel zu entschlacken. Man sieht ja in den Screenshots
    > unzählige Module eingeladen. Man fängt jetzt an, solange Module auszuladen bzw. gar
    > nicht mehr einladen zu lassen, bis man den Fehler nicht mehr reproduzieren kann. In
    > diesem Fall wären dann bestimmt Fuse hängenbelieben, zusammen mit noch ein paar
    > anderen Modulen.

    Unzählige Kernelmodule? Dass ich nicht lache ... oh, doch, tue ich. Du kannst ja nicht mal lesen. Vollkommen inkompetent, ich sag's ja. Aber so was von.

    > Ja stell Dir mal vor. Und jetzt denk mal drüber nach.

    Jemand, der nachweislich inkompetent ist, will, dass ich über seine inkompetenten Ideen nachdenke.

    Nee, die Wette kannst du mit deinem Arbeitgeber machen, meine Zeit ist mir dafür zu schade.

    > :-)
    >
    > Schönes Leben noch.

    Ich will's hoffen!

  11. Re: OK, gehen wir das noch mal durch ...

    Autor: madkiss 12.04.16 - 15:31

    Es zwoa hobts a Gaudi, oda?

  12. Re: OK, gehen wir das noch mal durch ...

    Autor: felix.schwarz 12.04.16 - 15:41

    jkow schrieb:
    > Das waren aber nicht die Fuse-Entwickler, wenn ich das richtig verstanden
    > habe, sondern Quobyte und Canonical.

    und Red Hat, wenn ich den Signed-Off im mainline-Kernel anschaue (nur der Vollständigkeit halber).

  13. Re: OK, gehen wir das noch mal durch ...

    Autor: Eheran 12.04.16 - 16:00

    Naja, es wäre schon schön, wenn man dann auch mal wirklich Argumente bringt und nicht nur sagt "die liegst falsch mit deinen Ausführungen".
    Wenn das dann auch nach Aufforderungen nicht kommt... die Sachlage ist dann recht klar.

  14. Re: OK, gehen wir das noch mal durch ...

    Autor: Moe479 12.04.16 - 16:04

    fuse währe beim laden nicht hängen geblieben, das problem wurde erst durch das tatsächliche arbeiten mit fuse oderer anderen in die aufgabe reinspielenden modulen und seiner anwendung anscheinend recht zufällig angestoßen, die stacktraces waren nicht eindeutig.

    was länger gedauert hat, war das sich überhaupt ernsthaft dafür interessiert wurde, erst über das interesse des quobyte-teams kam das kernel-team von canonical dazu sich das überhaupt erst näher anzusehen und dann erst war die fuse-betreung auch daran zu interessieren ... das war ja die geübte 'kritik', dass entwickler gemeldete fehler ersteinmal überhaupt als solche wahrnehmen müssen, und dazu mitunter eine exemplarische demonstration von nöten ist, auch in ihrer bedeutung.

  15. Re: OK, gehen wir das noch mal durch ...

    Autor: Linuxschaden 12.04.16 - 17:58

    Moe479 schrieb:
    --------------------------------------------------------------------------------
    > fuse währe beim laden nicht hängen geblieben, das problem wurde erst durch
    > das tatsächliche arbeiten mit fuse oderer anderen in die aufgabe
    > reinspielenden modulen und seiner anwendung anscheinend recht zufällig
    > angestoßen, die stacktraces waren nicht eindeutig.

    Ich habe ja auch nicht gesagt, dass es beim Laden hängenbleibt. Es geht darum, dass man herausfindet, mit welchen Modulen es hängenbleibt.

    Soweit ich den Artikel verstanden habe, lies sich das Problem reproduzieren, aber der Stacktrace war halt auch nicht eindeutig.

    > was länger gedauert hat, war das sich überhaupt ernsthaft dafür
    > interessiert wurde, erst über das interesse des quobyte-teams kam das
    > kernel-team von canonical dazu sich das überhaupt erst näher anzusehen und
    > dann erst war die fuse-betreung auch daran zu interessieren ... das war ja
    > die geübte 'kritik', dass entwickler gemeldete fehler ersteinmal überhaupt
    > als solche wahrnehmen müssen, und dazu mitunter eine exemplarische
    > demonstration von nöten ist, auch in ihrer bedeutung.

    Da möchte ich dir nicht direkt so zustimmen.

    Bei mir ist das halt so: ich muss ein Problem reproduzieren können, um es zu beheben. Ich muss es direkt sehen. Das hat nichts damit zu tun, dass ich dem Anwender nicht glaube (gut, tue ich auch nicht), sondern einfach deswegen, dass ich genau nachvollziehen muss, was passiert. Da verlange ich auch immer ein reproduzierbares Beispiel, nicht, weil ich den Anwender so gerne quäle, sondern weil ich es sonst nicht fixen kann.

  16. Re: OK, gehen wir das noch mal durch ...

    Autor: hum4n0id3 12.04.16 - 19:25

    Linuxschaden schrieb:
    --------------------------------------------------------------------------------
    > Bei mir ist das halt so: ich muss ein Problem reproduzieren können, um es
    > zu beheben. Ich muss es direkt sehen. Das hat nichts damit zu tun, dass ich
    > dem Anwender nicht glaube (gut, tue ich auch nicht), sondern einfach
    > deswegen, dass ich genau nachvollziehen muss, was passiert. Da verlange ich
    > auch immer ein reproduzierbares Beispiel, nicht, weil ich den Anwender so
    > gerne quäle, sondern weil ich es sonst nicht fixen kann.

    Und jetzt stell dir mal vor, das geht jedem anderem genau so ;-)

  17. Re: OK, gehen wir das noch mal durch ...

    Autor: Linuxschaden 13.04.16 - 02:44

    hum4n0id3 schrieb:
    --------------------------------------------------------------------------------
    > Und jetzt stell dir mal vor, das geht jedem anderem genau so ;-)

    Sag das doch nicht mir. Ich habe lediglich erklärt, wie ich das sehe. Die Extrapolation überlasse ich dann jedem selbst. ;)

    Ich würde aber immer noch gerne wissen, was an meinem Debuggingmodel so falsch sein soll, vor allem dann, wenn man es bereits mit einer streng modular aufgebauten Infrastruktur zu tun hat, und wie man 4 Monate dafür brauchen kann, so einen Fehler zu finden.

    Gut, auf der anderen Seite: alleine schon einen Kernel zu kompilieren, das kann nicht jeder. Muss auch nicht jeder können, nicht falsch verstehen. Und es kann auch sehr gut sein, dass der Entwickler, der dies dann auch debuggen musste, sich erst einmal damit beschäftigen muss, wie das mit dem Kernel abgeht.

    Trotzdem, wenn ein Kunde da sündhaft teure Hardware am Start hat und seine Software nicht updaten kann, dann ist das verdammt scheiße.

  18. Re: OK, gehen wir das noch mal durch ...

    Autor: felix.schwarz 13.04.16 - 11:40

    > Ich würde aber immer noch gerne wissen, (...) wie man 4 Monate dafür brauchen
    > kann, so einen Fehler zu finden.

    Meine Vermutung: Es funktioniert ja mit dem offiziell unterstützten (älteren) Kernel. Da es einen Workaround gibt, ist der Bug eben nicht so wichtig, so dass sich ein Administrator/Entwickler nur "nebenbei" darum kümmert, das Problem genau zu diagnostizieren bzw. auf den Mailinglisten/IRC-Channels Entwickler zu "nerven".

    Zudem ist es oft nicht einfach, bei einer so komplexen Infrastruktur einen minimalen Testcase zu erstellen.

    > Trotzdem, wenn ein Kunde da sündhaft teure Hardware am Start hat und seine
    > Software nicht updaten kann, dann ist das verdammt scheiße.

    Das ist doch aber gerade der Normalfall? Gerade bei teurer Hardware (und den entsprechenden Support-Verträgen) darf man doch fast nie auf neue Software upgraden. Gerade dort hält einen der Hersteller doch meist auf ewig alten Versionen, die im besten Fall gut "getestet" sind.

  19. Re: OK, gehen wir das noch mal durch ...

    Autor: Linuxschaden 13.04.16 - 11:57

    felix.schwarz schrieb:
    --------------------------------------------------------------------------------
    > Meine Vermutung: Es funktioniert ja mit dem offiziell unterstützten
    > (älteren) Kernel. Da es einen Workaround gibt, ist der Bug eben nicht so
    > wichtig, so dass sich ein Administrator/Entwickler nur "nebenbei" darum
    > kümmert, das Problem genau zu diagnostizieren bzw. auf den
    > Mailinglisten/IRC-Channels Entwickler zu "nerven".
    >
    > Zudem ist es oft nicht einfach, bei einer so komplexen Infrastruktur einen
    > minimalen Testcase zu erstellen.

    Öhm - ich rede nicht von der Zeit, bis ein Entwickler da dran war und das Problem reduzieren konnte. Der Artikel redet davon, dass danach noch mal 4 Monate ins Land gezogen sind. Sprich, die konnten das Problem dann nachvollziehen, und haben dann ... keine Ahnung, Teletubbies geschaut?

    Außerdem: wenn's nicht so wichtig ist, warum dann das Update nicht direkt sein lassen?

    Meiner Erfahrung nach sollte man sich immer einer Sache bewusst sein: man kann sich nur auf sich selbst verlassen, und wenn man's schnell und ordentlich repariert haben will, muss man es selbst machen. Ansonsten wird das einfach eiskalt ignoriert.

    > Das ist doch aber gerade der Normalfall? Gerade bei teurer Hardware (und
    > den entsprechenden Support-Verträgen) darf man doch fast nie auf neue
    > Software upgraden. Gerade dort hält einen der Hersteller doch meist auf
    > ewig alten Versionen, die im besten Fall gut "getestet" sind.

    Eh, stimmt schon. Ich habe Firmen gesehen, da wurde bei der Servereinrichtung einmal Debian draufgepackt und danach nie wieder aktualisiert. Bei den Mitarbeiterbesprechungen, bei denen ich anwesend war, wurde 5 Monate nach Heartbleed darüber gesprochen, mal das OpenSSL zu aktualisieren ...

    Das entkräftet aber nicht die Aussage, dass es scheiße ist. Du stellst lediglich fest, dass der Normalfall scheiße ist. :)

  20. Re: OK, gehen wir das noch mal durch ...

    Autor: felix.schwarz 13.04.16 - 12:16

    Linuxschaden schrieb:
    > Öhm - ich rede nicht von der Zeit, bis ein Entwickler da dran war und das
    > Problem reduzieren konnte. Der Artikel redet davon, dass danach noch mal 4
    > Monate ins Land gezogen sind. Sprich, die konnten das Problem dann
    > nachvollziehen, und haben dann ... keine Ahnung, Teletubbies geschaut?

    Vermutung: Es war einfach nicht wichtig genug. Gerade bei freier Software schaut der Entwickler halt, wann er Zeit hat (bzw. wie sein Arbeitgeber die Prioritäten für den "free support" setzt). Es war ja auch erst mal nicht so dringend, weil der User einen workaround hatte (alte Version).

    > Außerdem: wenn's nicht so wichtig ist, warum dann das Update nicht direkt
    > sein lassen?

    Weil man irgendwann schon upgraden will? Ich habe hier auch ein paar Systeme, bei denen ich nicht die aktuellste Version einsetze, obwohl die ein paar sehr nette Features hätte, die uns die Arbeit erleichtern würden. Allerdings gibt es auch in ein paar Spezialfällen "merkwürdiges" Verhalten, welches ich noch debuggen muss. Weil die Spezialfälle für uns halt wichtig sind, muss das Upgrade halt warten...

    > Meiner Erfahrung nach sollte man sich immer einer Sache bewusst sein: man
    > kann sich nur auf sich selbst verlassen, und wenn man's schnell und
    > ordentlich repariert haben will, muss man es selbst machen.

    Stimmt in der Tendenz auf jeden Fall. Man kann sich die Expertise natürlich auch kaufen, aber das ist oft schweineteuer und funktioniert auch nur, wenn der Umsatz des Support-Vertrags für den Anbieter bedeutsam ist (HP, IBM oder Microsoft lassen sich halt nicht damit beeindrucken, wenn ihnen 100.000 Euro pro Jahr durch die Lappen gehen - ein kleiner mittelständischer Dienstleister für Spezialsoftware springt da dann ganz anders).

    Da ist freie Software oft schon deutlich günstiger: Der direkte Zugang zu den Entwicklern, das ganze Fehlen von "wer hat Schuld" (i.S.v. "verschlechtern wir unsere juristische Position, wenn wir den Fehler eingestehen") und die eigenen Debugging-Möglichkeiten sind wirklich viel Wert. bei proprietärer Software muss man schon sehr viel hinlegen, bis man einen ähnlichen Zugang bekommt.

    > Das entkräftet aber nicht die Aussage, dass es scheiße ist. Du stellst
    > lediglich fest, dass der Normalfall scheiße ist. :)

    Deswegen wird ja an vielen Stellen auch auf die teuren Verträge verzichtet. Gerade die mittelständischen "Buden" im Web-Umfeld haben doch oft nur noch Support für die blanke Hardware im RZ - die Webplattform wird eh in-house entwickelt und dann man die Entwickler/Admins eben auch noch das Linux darunter. Oft genug gibt es 1-2 Leute, die in ihrer Freizeit ohnehin am Kernel hacken, die tauchen dann ggf. auch mal nach ganz unten ab und schaffen zumindest ein vernünftiges bisect.

    Wer natürlich Standard-Software von der Stange einsetzt bzw. die großen proprietären Monolithen (SAP, Oracle), kommt an Support-Verträgen eher nicht vorbei - selbst wenn die oft nicht das halten, was sie versprechen.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


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

Stellenmarkt
  1. Würth Industrie Service GmbH & Co. KG, Bad Mergentheim
  2. allsafe GmbH & Co.KG, Engen
  3. Universitätsmedizin der Johannes Gutenberg-Universität Mainz, Mainz
  4. Bundeskriminalamt, Wiesbaden

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 555,55€ (zzgl. Versandkosten)
  2. (reduzierte Überstände, Restposten & Co.)
  3. täglich neue Deals bei Alternate.de


Haben wir etwas übersehen?

E-Mail an news@golem.de


Mitsubishi: Satelliten setzen das Auto in die Spur
Mitsubishi
Satelliten setzen das Auto in die Spur

Mitsubishi Electric arbeitet am autonomen Fahren. Dafür betreibt der japanische Mischkonzern einigen Aufwand: Er baut einen eigenen Kartendienst sowie eine eigene Satellitenkonstellation auf.
Ein Bericht von Dirk Kunde


    Weltraumsimulation: Die Star-Citizen-Euphorie ist ansteckend
    Weltraumsimulation
    Die Star-Citizen-Euphorie ist ansteckend

    Jubelnde Massen, ehrliche Entwickler und ein 30 Kilogramm schweres Modell des Javelin-Zerstörers: Die Citizencon 2949 hat gezeigt, wie sehr die Community ihr Star Citizen liebt. Auf der anderen Seite reden Entwickler Klartext, statt Marketing-Floskeln zum Besten zu geben. Das steckt an.
    Ein IMHO von Oliver Nickel

    1. Theatres of War angespielt Star Citizen wird zu Battlefield mit Raumschiffen
    2. Star Citizen Mit der Carrack ins neue Sonnensystem
    3. Star Citizen Squadron 42 wird noch einmal verschoben

    Minikonsolen im Video-Vergleichstest: Die sieben sinnlosen Zwerge
    Minikonsolen im Video-Vergleichstest
    Die sieben sinnlosen Zwerge

    Golem retro_ Eigentlich sollten wir die kleinen Retrokonsolen mögen. Aber bei mittelmäßiger Emulation, schlechter Steuerung und Verarbeitung wollten wir beim Testen mitunter über die sieben Berge flüchten.
    Ein Test von Martin Wolf


      1. Bundesrechnungshof: Behörden gaben für eigene Apps Millionen Euro aus
        Bundesrechnungshof
        Behörden gaben für eigene Apps Millionen Euro aus

        Bundesbehörden haben mehrere Millionen Euro für eigene Apps ausgegeben. Der Bundesrechnungshof will diese abschalten lassen, wenn der Betrieb weitere Kosten verursacht.

      2. Riot Games: Schatteninseln und Zeitreisen mit League of Legends
        Riot Games
        Schatteninseln und Zeitreisen mit League of Legends

        Zwei sehr unterschiedliche Abenteuer für Einzelspieler hat Riot Games vorgestellt - beide sind in der Welt von League of Legends angesiedelt. In Ruined King erkunden die Champions die mysteriösen Schatteninseln, Conv/Rgence beschäftigt sich mit Zeitmanipulation.

      3. Energiewende: Dänemark plant künstliche Insel für Wasserstofferzeugung
        Energiewende
        Dänemark plant künstliche Insel für Wasserstofferzeugung

        Dänemark will seine klimaschädlichen Emissionen bis 2030 um 70 Prozent reduzieren. Eine Maßnahme ist der weitere Ausbau der Windenergie. Die Regierung plant einen riesigen Windpark mit angeschlossener Power-To-X-Anlage auf einer künstlichen Insel.


      1. 18:10

      2. 16:56

      3. 15:32

      4. 14:52

      5. 14:00

      6. 13:26

      7. 13:01

      8. 12:15