2. Fórumok
  3. Infotech
  4. Melyik a biztonságosabb: a Windows vagy a Linux?
Keresés

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

  • #43 Sipi addikt Gregorius #42
    Új Válasz #43
    Ú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

    Sipi

    addikt

    válasz Gregorius #42 üzenetére

    Azt hiszem, jól elbeszélünk egymás mellett. :)
    Te ugye Windows alatt rpogramokat fejlesztesz? Mert Linux alatt szerintem totál máshogy van...

    A visszafele kompatibilitást nem értem... Alapvető, hogy egy javítás nem sérti. 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.
    Nem értem ezt a viszzafele komp. fenntartást... Egy program x.y verziója mindig is kompatibilis lesz önmagával, akárhogy foltozom. Ha nem az, akkor már nem x.y verzió, kiadják frissebbnek.
    Egyébként én még nem találkoztam olyan javítással, ami visszafele nem lett volna komp. Ezt hogyan érted?!? 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?
    Megintcsak: nem monolitikus Windows-programokról beszélek, azokhoz semmit sem értek. Linux alatt egy normál program (lényegében az összes) ezer más libre, programra épü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. Ezt definiálják is a headerekben.
    Mivel egy Linuxos program lényegében mást sem csinál, csak tonnaszámra hívja meg egyéb programok függvényeit, ha egy függvényben nem változik meg a visszatérési érték, sem a mód, ahogy hívom, mi dőlne össze? Itt nincsenek simlis ''majd betuszkolom a visszatérést két hamburger közé, oszt kecsuppal elcsúszik''. A programod összvissz egy definiált elérési/visszatérési módszrtant lát a másikból. Ha ez egyezik, oké. Max. az adott lib dőlhet össze. :)

    Ez az időzítéses pedig... Izé, ezt már NT kernel alatt sem igen játszhatod el... A párhuzamos műveleteket pedig inkább ne hozd be, mert mutass nekem egy alaprendszert, amiben így, párhuzamosan futhatnak feladatok!
    Egyébként ha csak a futási idő nőtt a folttól, akkor nem változik semmi, ugyanis 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. Bár nem programozok, de nem hiszem, hogy ez a szinkronizáció timerrel menne. :)
    Legfeljebb anyázik egy programrész, hogy a másik hol van már. :D

    De ez, úgy látom, a munkádhoz kapcsolódóan, megincsak valamilyen speciális, ''külső'' cég által készített nagy alkalmazás.

    Itt a két rendszerről volt szó, és azok javításáról. Ebbe az x napba ne számítsd már bele egy 3rd party alkalmazás kijavítását...:)

    Köszi a jókívánságokat, igyekszem! :D

    Sipi

  • #36 Sipi addikt Gregorius #29
    Új Válasz #36
    Ú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

    Sipi

    addikt

    válasz Gregorius #29 üzenetére

    Mindegy, úgy látom, nem érted, mit akarok mondani, és úgy látom, nem ismered a Linux működését. :)

    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.
    Az általam látott, tesztelt Linux foltok természetesen megváltoztatnak valamit a forrásban. Sőt, mivel ezután újrafordítod a programot totál megváltozik maga a file is.
    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...
    Ja, várj, Linuxban nem a kész binárist foltozod, hanem a forrást!

    Itt úgy épülnek a dolgok egymásra, hogy az alapszintre szétbontott funkciók mindegyikét más és más csomag valósítja meg.
    Mindegyik külső elérése rögzített. Ez nem változik meg. A patch nem ezt változtatja. Persze, ha jól patchelnek. :)

    Debug: MS-ben nem debugoltam, de máshol sem, ahhoz nem értek. Sőt, a core dumpokat sem szoktam kinyomtatnui és olvasgatni. :)
    ''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, sokszor még arra is, mi lehet az oka. Megoldani persze nem tudom, mert nem értek a programozáshoz.
    Ezt azonban ne hasonlítsd már össze azzal, hogy ha akarom, totál memory dumpot kérhetek a deails gombbal... Hibajelzést írtam, nem core dumpot! Az utóbbi a supportnak van, az előző a felhasználónak.

    Mindegy, szerintem sosem győzzük meg egymást. Ráadásul a jól fejlett hőemelkedésemnek köszönhetően már azt sem tudom, miről is ''vitázunk''. :D

    Sipi

  • #34 anulu félisten Gregorius #29
    Új Válasz #34
    Ú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

    anulu

    félisten

    válasz Gregorius #29 üzenetére

    nálam volt olyan, h Debian alatt futott X, rajta X11AMP, semmi mást nem használtam. (haverom állította be az egészet, elég régóta foglalkozik Linuxszal) egyszercsak x bezár, szöveges módban annyi van, hogy ''kernel panic''. a vége az lett, hogy az egészet újra kellett telepíteni, mert teljesen meghülyült.

  • #26 Sipi addikt Gregorius #20
    Új Válasz #26
    Ú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

    Sipi

    addikt

    válasz Gregorius #20 üzenetére

    Bocs, a 71 percnél lemaradt a mosoly.
    Ezzel csak arra céloztam, hogy a valós időhöz inkább 71 perc áll közelebb, mint 71 nap.

    Nem tudom, szoktál-e Linuxos bugreport-helyeken nézelődni. Neadjisten hibát jelenteni.
    A Linux nem monolitikus. Ráadásul hibajelzést is ad, se ez nem az, hogy súlyos hiba történt a rendszerben. :)

    Akkor fogalmazok így: saját tapasztalatom szerint egy bugreportban feltűnt hiba helyét, valószínű okait már a bejelentés napján megállapítják, többnyire másnapra (de sokszor aznap) elkészül a javítás.
    (Az más dolog, hogy ebből adott rendszerre csomagot mikor csinálnak, és csak forráskódból telepítek, úgyhogy tudom, hogy maga a kész, javított forrás nagyon hamar készen áll.)

    Mivel a Linux iszonyú erősen (kizárólag...) építőkocka-jellegű, sokkal kevésbé valószínű, hogy egy adott komponens (ami a valós rendszerben alig látszik) megváltoztatása az egészet romba döntené.
    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), nem valószínű, hogy bármi, ami erre épül, összedőlne.

    Pontosítok: nekem még sosem dőlt össze. Az más tészta, ha más _verzió_ jelenik meg, változik a függvény szerkezete.

    Sipi

  • #25 WN31RD addikt Gregorius #23
    Új Válasz #25
    Ú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

    WN31RD

    addikt

    válasz Gregorius #23 üzenetére

    A ''hírnevet'' ne szószerint értsd... ;)
    A spammerek pedig jellemzően inkább idióta (szakmailag érdektelen), bár a céljuknak megfelelő, férgeket írnak.

    Mozilla: Jaja, aggódok miatta én is. :((( Nem véletlen, hogy csak grsec-es kernel mellett kizárólag erre a célra fenntartott account alatt vagyok hajlandó futtatni.

    [Szerkesztve]

  • #18 Sipi addikt Gregorius #17
    Új Válasz #18
    Ú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

    Sipi

    addikt

    válasz Gregorius #17 üzenetére

    Kételkedj nyugodtan, de attól még pár nap alatt ki szokták javítani a hibákat. Még a Linux kernelben sem vesz igénybe 71 napot, pedig azt alaposan tesztelni kell.

    És itt nem arról volt szó, hogy a kész foltot a cégek mennyi idő alatt teszik fel (még szép, hogy nem megy egy nagy rendszerben egy nap alatt), hanem a program készítője mennyi idő alatt javítja ki a már megtalált _és_ bejelentett hibát.

    Sipi

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

Hirdetés