Új hozzászólás Aktív témák

• #39 zLegolas őstag Sipi #36

  Új Válasz 2005-03-04 13:56:59 #39

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  zLegolas

  őstag

  válasz Sipi #36 üzenetére

  Forralt bort a baciknak, neked meg jobbulást!

  Én normális vagyok! Megmondták a hangok is a fejemben!

• #42 Gregorius őstag Sipi #36

  Új Válasz 2005-03-04 15:03:48 #42

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Gregorius

  őstag

  válasz Sipi #36 üzenetére

  Egy végfelhasználói bináris (wuftpd) hibája nem ugyanaz, mint egy .so vagy dll-é. Hiba lehet mindkettőben. Ha dll-ben, az sok file-t érint. Ha binárisban, az nem annyira.
  A wuftpd-t arra mondtam példának, hogy ami nem valószínű az attól még nem lehetetlen. Rúgtak már ki azért embert, mert azt mondta ''hát ez úgy sem fog megtörténni''. Egyébként épp elég programot, ftp klienst is érinthet a hiba javítása (mert ugye nagyon szeretjük betartani a szabványokat... ).
  
  De ettől, ha egy kukuc.so.1-nek x,y, és z függvényeket kell biztosítania a kukuc.h-ban leírt hívási feltételekkel, az a patch után is ugyanolyan marad.
  Az időzítést pedig nem értem, Linux alatt max. a kernelben találsz ilyen funkciókat...
  Nem lehetsz biztos abban, hogy egy javítás nem sérti meg a visszafelé kompatibilitást, amíg le nem tesztelted (a ránézek és jó módszer nem valami megbízható), de talán még akkor sem. Deha mégis kompatibilis, akkor irdatlan nehéz fenntartani. Ezért van az, hogy a windóz ott bugzik, ahol, de még a win3.1-re készült programokat is tudja futtatni.
  Az időzítésre példa. Vegyük azt a hipotetikus szituációt, amikor az xy komponensben történt egy javítás, ami annyiban merült ki, hogy beépítettek egy függvénybe némi extra ellenőrzést, amitől lassabb lett. Most nézzük a zw komponenst, ami többek között ezt az xy komponenst is használja, méghozzá elég intenzíven. Emellett csinál még mást is. A hosszabb xy-használó idő miatt elképzelhető, hogy a rendszer máshogy fogja ütemezni a zw komponens feladatainak végrehajtását, tehát azok sorrendje potenciálisan felcserélődik (itt most párhuzamos műveletekről van szó, nem a program átrendezéséről). A felcserélődés miatt pedig a két folyamat összebalhézik (sokféle módja van, több szálon egyébként is kiba* nehéz tisztességesen programozni és tesztelni a programot), és zw szépen elhalálozik, de legalábbis nem azt csinálja, amit kellene.
  Namost a kedves főnökséget nem szokta érdekelni, hogy az xy javítás vagy a zw hiba miatt nem fog működni, őket csak az érdekli, hogy a rendszer nem megy. Két dolgot lehet csinálni: egy - nem javítjuk ki az xy komponenst. Kettő: kijavítjuk, leteszteljük, és miután látjuk a tesztből, hogy nem passzol össze a zw komponenssel, azt is kijavítjuk.
  Persze az is megtehető, hogy a tesztelést az end-júzerek végzik, csak az khmm kínos és imázsromboló tud lenni.
  
  ''Felhasználói'' szemmel semmit sem érek a stack strace-szel. Eddig Linux alatt az egyszerű, futás közbeni hibajelzésből következtetni tudtam a hiba helyére,
  Azt mondtam, akár stack trace-t. Majd elfelejtettem. Az EventLog is a barátod. Példa:
  -----
  The IP address lease [**IP cím**] for the Network Card with network address [**MAC cím**] has been denied by the DHCP server [**DHCP szerver IP címe**] (The DHCP Server sent a DHCPNACK message).
  -----
  Elég részletes?
  
  Jobbulást!
  G.

Új hozzászólás Aktív témák