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

• #49 Gregorius őstag Sipi #43

  Új Válasz 2005-03-04 17:36:42 #49

  Ú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 #43 üzenetére

  Te ugye Windows alatt rpogramokat fejlesztesz?
  Mikor mire van szükség. Nem különösebben kedvelem a Linuxot - vagy inkább a C/C++ vonalat - , de a jegyeim többségét ilyen programokra kaptam annó.
  
  Nézd, én most nem Servie Packról beszélek, hanem javításról. Linux alatt ez egy pár kilobájtos szöveges file. Nem lesz új verzió, pár sort ír át.
  Persze mit értesz új verzió alatt. Jobb helyeken a build verziószám változik (jobb esetben ez a harmadik vagy negyedik a sorban; ha jól tudom ez is valamilyen szabvány, éppen ezért nem tartja be senki ), különben egy picit komplikált követni, hogy melyik patch van már fent és melyik nem.
  
  Egy program x.y verziója mindig is kompatibilis lesz önmagával, akárhogy foltozom.
  Ez a kívánatos cél, amit néhány esetben nem sikerül elérni. Főleg, ha konstrukciójában szar a rendszer. Gondolok itt például biztonsági protokollokra.
  
  Kijön egy puffertúlcs. hiba, megkapod a forráshoz való 1500 byte-os foltot, hozzárakod, lefordít, tesztel. Ez miért változtatná meg a kompatibilitást?
  Előszöris, a BOF hiba habár igen gyakori, nem az egyetlen. Másodszoris, a puffertúlírás ugyan megváltoztat a memóriában olyan dolgokat is, amit nem kéne, ez nem mindig fatális a program számára (például már nem használt helyi változókat ír felül). Épp ezért harmadszoris: ha pontos a méretellenőzés a pufferen, ez jelenthet kisebb méretet, mint amekkora méretnél még használható a program (ez alapesetben olyan 4-8 többletkarakter környékén van, de erősen függ a fordítási direktíváktól meg az egyéb változóktól), tehát ha nem is jelentősen, de sérül a ''kompatibilitás''. Ha gondolod, forráskóddal, assemblyvel alátámasztom a gondolatmenetet.
  
  Megintcsak: nem monolitikus Windows-programokról beszélek, azokhoz semmit sem értek.
  Internet Explorer? 90kbyte. Mindennek mondanám, csak monolitikus programnak nem, kábé tizennégy rendszermodult használ.
  
  És mivel ott ez az alapvető dolog, a könyvtáraknak kizárólag a hívási módját, valamint a visszatérési értékeit, illesztését kell tudni
  Meg azt, hogy az a könyvtár mit csinál, amitől neked jó lesz. Ha a frissítés után már nem működik, hanem visszaszól, hogy a paraméterben megadott érték túl nagy, akkor gáz van (ld. még lentebb).
  
  Itt nincsenek simlis ''majd betuszkolom a visszatérést két hamburger közé, oszt kecsuppal elcsúszik''.
  Ez egy kicsit erős állítás. Mondjunk annyit, hogy programozók körében is igen elharapózó tendencia, hogy magasról tojnak a hívási konvenciókra, és olyan ''mellékhatásokat'' használnak ki egy adott függvénynél, amely nem része a specifikációnak. Többek között ezért volt szívás a 9x->NT átállás is. Lehet, hogy az egyes linux disztrók közötti inkompatibilitás is részben ennek a számlájára írható, de ebben nem vagyok kompetens, úgyhogy inkább nem mennék bele.
  
  mutass nekem egy alaprendszert, amiben így, párhuzamosan futhatnak feladatok!
  Bármelyik jött-ment webszerver megteszi? Remélem abban egyetértesz, hogy az nem egymás után, hanem egyszerre szolgálja ki a letöltéseket. A biztonsági alrendszeremben 53 - izé, most már 54 - párhuzamos szál fut. De még a legegyszerűbb java programban is legalább két szál van (az egyiket nem a programozó, hanem a futtatókörnyezet adja hozzá).
  Múltkor én is babráltam ilyen alkalmazással, amiben mindössze három szál volt. Csupán az egyes folyamatok prioritásán változtatva az átlagos memóriahasználatot ''alig'' négyszeresére tudtam növelni (15M->60M).
  
  ha párhuzamos programozással készítették (máshogy nem is futhatna így), akkor ott különböző módszerekkel szinkronizálod a futást.
  És ez az, amit a kedves programozók el szoktak felejteni (persze nem hanyagságból), mert látszólag enélkül is működik(-ött).
  
  Ebbe az x napba ne számítsd már bele egy 3rd party alkalmazás kijavítását
  Nem feltétlenül kell 3rd party-nak lennie. Elvégre az oprendszer sem csak egy darabból van.
  
  Bár nem programozok, de nem hiszem, hogy ez a szinkronizáció timerrel menne
  Nem, lock-okkal megy. Linuxos berkekben mutexnek szokás hívni. És mint mondtam, gyakran el szokták felejteni, vagy rosszul használják. De sok egyéb apró probléma van, ami a kódoptimalizálás során fogja hazavágni a többszálú programot.
  
  hehe, a windoze elerte azt a szintet, hogy minden hibat kijavitottak benne
  
  
  Üdv,
  G.

• #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.

• #29 Gregorius őstag Sipi #26

  Új Válasz 2005-03-04 12:58:06 #29

  Ú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 #26 üzenetére

  Sőt, mivel egy adott program foltozása azon library-k működését, melyeket a program ellát, nem változtatja meg (vagyis nem változnak meg a ''dll''-ben található függvényhívások, nevek)
  Attól még, hogy egy függvényhívás neve nem változik meg, a működés megváltozhat. Ha a működés nem változik meg, az időzítés még megváltozhat. És akár az időzítés okozta változás is előhozhat olyan egyéb hibákat, ami potenciálisan használhatatlanná teszi a rendszert.
  
  nem valószínű, hogy bármi, ami erre épül, összedőlne
  Az sem valószínű, hogy valaki ftp szervert 300 karakteres jelszóval fog használni, aztán mégis milyen jó kis remote exploitot lehetett rá írni annó (wuftpd volt talán?). Ilyen ügyekben nincs olyan, hogy valószínű, vagy nem. Csak olyan van, hogy lehetséges.
  
  A Linux nem monolitikus. Ráadásul hibajelzést is ad, se ez nem az, hogy súlyos hiba történt a rendszerben.
  Ezek szerint még sosem nyomtál ''súlyos hiba történt a rendszerben'' után a details gombra... Ha tudod, hogy mit és hol kell keresni, akkor még az egyes stack-trace-eket meg a rendszerfolyamatok memóriaképét is elő lehet ásni. Ha kicsit utánaolvasol, még arról is találsz publikus információkat a Microsoftnál, hogy hogyan lehet kernel szinten debuggolni.

• #23 Gregorius őstag WN31RD #21

  Új Válasz 2005-03-04 11:01:26 #23

  Ú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 WN31RD #21 üzenetére

  lényegesen nagyobb hírnevet jelentene bizonyos körökben
  Hírnévvel egy valamit lehet nyerni: FBI-t az ember nyakába. A vírusok zömét spammerek(nek) írják, azoknak meg a tömeg a lényeg. Aki hírnevet akar, az publikációt, meg proof-of-concept-et szokott írni.
  Ha jól megfigyeled, most hogy elkezdett terjedni a Mozilla, már a vírusíróknak is egyre kedveltebb célpontja.

• #20 Gregorius őstag Sipi #18

  Új Válasz 2005-03-04 10:51:12 #20

  Ú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 #18 üzenetére

  attól még pár nap alatt ki szokták javítani a hibákat
  A pár nap már sokkal közelebb áll a hihetőhöz.
  
  Le kell tesztelni, hogy valóban sikerült rendesen kijavítania a hibát.
  Le kell tesztelni, hogy az érintett szoftverek működését befolyásolja-e a javítás.
  El szoktak gondolkodni, hogy melyik a nagyobb ciki: ha valaki bejön és körülnéz, vagy ha a (saját ember által!) telepített folt működésképtelenné tesz kritikus rendszereket.
  
  mennyi idő alatt javítja ki a már megtalált _és_ bejelentett
  Bejelentett hiba az van. Utána meg kell találni, hogy ezt a hibát mi okozza, ami rosszabb esetben a tünet keletkezési helyétől fényévekre van. Ez sem öt perc. Ha megvan a hiba, akkor előszöris lehet workaround-ot keresni, javítani a hibát, elemezni a javítás lehetséges negatív hatásait, stb, stb...
  
  nem arról volt szó, hogy a kész foltot a cégek mennyi idő alatt teszik fel
  A fentebb említett tesztelést természetesen a gyártó is elvégzi (jobb helyeken), persze csak az általánosabb rendszerekre tudja, de a saját rendszerben is lehetnek együttműködő komponensek, amiket érint. És akkor a regressziós tesztekről még nem is mondtam semmit. Mindkét (gyártó/vevő) oldalon igen komoly iparág épül peccselésre (sajnos).
  
  [Szerkesztve]

• #17 Gregorius őstag nap #15

  Új Válasz 2005-03-04 09:58:43 #17

  Ú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 nap #15 üzenetére

  Nade alapbealitasokkal?
  Te sem láttál még frissen települt windows server 2003-at.
  
  71 NAP?!?
  Na, ezt a büdös életbe nem fogom elhinni... A 71 perc már hihetőbb lenne.
  Nos, nagyobb cégeknél csak a peccs befogadása eltart egy napig, és nem azért, mert a rendszergazdák olyan balfaszok, hogy egyenként mennek oda több száz géphez. Szóval hadd kételkedjek a 71 perces peccsek minőségében (már ha vannak ilyenek). Hogy nem ellenőrizték őket alaposan, az biztos.

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