Nyílt forrás: a biztonság hamis érzetét nyújtja?

Nyílt forrás: a biztonság hamis érzetét nyújtja?
2002-10-03T21:15:00+02:00
2002-10-15T09:43:51+02:00
2022-11-02T10:10:31+01:00
  • hoi!

    kicsit off. open source dolgokrol veltem felfedezni itt gondolkodokat. nem akarok ujbol redundans topikot inditani, ezert megkerlek benneteket, vessetek mar ide egy pillanatot:

    index >> forum >> linux >> open source development
    http://forum.index.hu/forum.cgi?a=t&t=9079241&uq=2


    thx.
    Mutasd a teljes hozzászólást!
  • Igen, tényleg eltértünk egy picit a témától.
    Mutasd a teljes hozzászólást!
  • Pl. mert egy CR-t LF-re úgy is le lehet cserélni egy text fájlban hogy nem kell újraírni a fájlt vagy memória tartalmat.

    Már bocs, de ez az érvelés kicsit olyannak hat nekem, mint egy rekurzív definíció. Mert miért is kellene cserélgetni a memóriában a sorvégjelet egy normáls programnak? Semmiért. Ez maximum egy másik rendszerre/formátumra konvertáláskor jöhet szóba, de akkor már eljutottunk oda, hogy a probléma nem az, hogy CRLF önmagában rossz, hanem azért rossz, mert nem azonos hosszúságú, mint az LF. Ebben az esetben azonban az LF is lehet a rossz, mert ő sem azonos hosszúságú a CRLF-fel. Igaz?

    Plusz fölöslegesen foglal egy byte-ot soronként

    Na, ez aztán komoly érv. Főleg ma, amikor 20e Ft-ért kapsz egy 40GB-ot vinyót.
    Egyébként meg erre lehet a másik oldalon azzal érvelni, hogy a CRLF 16-bitet foglal, ami 16-bites processzorokon jóval gyorsabban manipulálható, mint egy 8-bájtos érték. Ez az állítás ugyanúgy igaz lenne, mint az, hogy a CRLF 1 bájttal többet (vagy ha dramatizálni akarom: kétszer annyit) foglal, mint az LF, viszont pontosan ugyanannyira irreleváns is.
    Főleg a Unicode korában, amikor minden írásjel legalább 2 bájtot foglal...

    Én a 4.0-ra emléxem.

    Az lehet. Ettől még a 3.0-ban jelent meg a FAT16.

    Akkor sem váltak volna használhatatlanná ha NTFS-t használnak, a DOS-os programok túlnyomó többsége kiválóan műxik NT alatt NTFS fájlrendszerrel is. Amik + nem, azok is többnyire azért nem mert védett módra akarnának kapcsolni.

    Ne beszéljünk mellé! Itt nem a sima, a lemezt maximum fájlszinten manipuláló alkalmazásokról volt szó (ezt te is tudod), mert az triviális, hogy azok bármilyen fájlrendszeren elmennek (főleg amíg van 8+3-as névképzés), hanem a lemezt közvetlenül író/olvasó programokról. Ezeknél pedig nem mindegy, hogy egyetlen deklarációt kell átírni ahhoz, hogy működjenek (FAT32-höz, mert FAT->VFAT esetén még ennyi sem kell), vagy teljesen újra kell írni a fájlrendszer kezelését.

    Azért egyébként még jó, hogy on-topic-ok vagyunk...
    Mutasd a teljes hozzászólást!
  • Miért is nem? Még mindig nem hallottunk egyetlen észérvet sem ez ügyben.

    Pl. mert egy CR-t LF-re úgy is le lehet cserélni egy text fájlban hogy nem kell újraírni a fájlt vagy memória tartalmat. Plusz fölöslegesen foglal egy byte-ot soronként. Egyszerűen nem igazán látom hogy miért volt ez jó, mindenki a világon (kivéve talán a CP/M-et, azt nem ismerem) egy karakteret használt erre, az M$ az inkompatibilitás jegyében kettőt.

    A FAT16 a DOS 3.0-ban jelent meg, és itt is pontosan arról volt szó, hogy bár binárisan nem volt kompatibilis az el?z?vel, de minimális módosításokat kellett csak eszközölni az addigi programokon (kb. mint egy 16-bites program 32-bites konvertálásánál).

    Én a 4.0-ra emléxem. Voltak is szép nagy szívások a 4.0 után (Pl. akkori kedvenc programom a PC-Tools nem igazán működött a 4.0-án, így sokáig a 3.3 volt a kedvencem a 4.0 megjelenése után is, csak az 5.0 után tértem át az újabb DOS-okra).


    Az, hogy mondjuk a Norton Disk Doctor hamisan hibákat jelzett a hosszú fájlneveket is alkalmazó a lemezre teljesen érthet?, de ett?l még nem váltak használhatatlanná a FAT16 programok.

    Akkor sem váltak volna használhatatlanná ha NTFS-t használnak, a DOS-os programok túlnyomó többsége kiválóan műxik NT alatt NTFS fájlrendszerrel is. Amik + nem, azok is többnyire azért nem mert védett módra akarnának kapcsolni.
    Mutasd a teljes hozzászólást!
  • Itt tökmind1 hogy milyen karakter a sorvégjel

    Akkor ez nekem kicsit öngólként hangzik a felvetéssel kapcsolatban.

    de szvsz két karakteresre csinálni nem volt szerencsés ötlet

    Miért is nem? Még mindig nem hallottunk egyetlen észérvet sem ez ügyben.

    Én nem vettem észre hogy a FAT lényegesen gyorsabb lenne mint Pl. a linuxos ext3fs, sőt az NTFS-nél sem.

    Nekem pedig ezt alátámasztó tapasztalataim vannak. WinNT jóval gyorsabban fut FAT32-n, mint NTFS-en.

    Ami + a kompatibilitást illeti: a közvetlenül lemezbuheráló programokat egyszer ki kellett dobni az MS-DOS 4.0 után (amikor a 12 bites FAT-ból 16 bites lett)

    A FAT16 a DOS 3.0-ban jelent meg, és itt is pontosan arról volt szó, hogy bár binárisan nem volt kompatibilis az előzővel, de minimális módosításokat kellett csak eszközölni az addigi programokon (kb. mint egy 16-bites program 32-bites konvertálásánál). Mellesleg a DOS 2.0-ban megjelent FAT12-re azért olyan túl sok program nem épülhetett, amit "ki kellett dobni".
    Ez a formátum (FAT12) egyébként még a DOS 3.0 után is sokáig élt a lemezek fájlrendszereként.

    utána pedig ki kellett dobni a win9x után (Pl a DOS-os Norton-os cuccokat).

    A FAT32 csak a W95 OSR2-ben jelent meg, előtte csak FAT16-ot, pontosabban VFAT-ot tudott W95 (ez egyébként már az NT3.51-ben is benne volt). Utóbbi pedig tökéletesen kompatibilis volt felülről a FAT16-tal, csak éppen hosszú fájlnevek alkalmazását is lehetővé tette.
    Az, hogy mondjuk a Norton Disk Doctor hamisan hibákat jelzett a hosszú fájlneveket is alkalmazó a lemezre teljesen érthető, de ettől még nem váltak használhatatlanná a FAT16 programok, és kiválóan operáltak VFAT köteteken is (pl. a Norton Disk Editor is).

    Azoknak a programoknak + akik szabályosan a DOS-on keresztül nyitogatták a fájlokat szvsz tökmind1 hogy milyen fájlrendszre van alattuk.

    Ahogy írtam már korábban: a bináris szempontjából valóban tök mindegy, hogy mennyit változik a formátum, ha nem képes kezelni, viszont az már nagyon nem mindegy, hogy (nagyon leegyszerűsítve a dolgot) a forráskódban csak egyetlen helyen kell az int16-ot int32-re átírni, vagy alapjaitól újra kell írni az egész fájlrendszerkezelőt (mondjuk FAT<->NTFS esetében ugye gyakorlatilag nincs közös kód).
    Mutasd a teljes hozzászólást!
  • Ezt a dolgot a CRLF-fel nem nagyon értem. Akkor most a Mac CR sorvégjele jobb, vagy rosszabb a Unix-ok LF-énél? Megjegyzem: ha valammelyik a 3 közül logikus, akkor az az MS-DOS féle CRLF. Azért, mert az konvertálás nélkül, követlenül nyomtatható.

    A nyomtató ott csinál soremelést ahová programozzák. Ha úgy van megírva a nyomtató programja hogy cr-re kocsi vissza-t is csináljon akkor már meg is oldótott a kérdés. Itt tökmind1 hogy milyen karakter a sorvégjel, de szvsz két karakteresre csinálni nem volt szerencsés ötlet. A bithiba + mint érv elég erőltetettnek tűnik, ha már ilyen van akkor annak az adatállománynak régen rossz, viszont ha jól emléxem már a zmodem protokoll is védte az adatcsomagokat.


    A VFAT-tal, FAT32-vel megint nem értem mi a bajod. Azok jóval gyorsabbak egy journaling fájlrendszernél. Márpedig azoknál a rendszereknél ahol a W9X-eket alkalmazzák, ez a tulajdonság sokkal fontosabb, mint az, hogy halálos biztonságban legyenek a fájlok.

    Én nem vettem észre hogy a FAT lényegesen gyorsabb lenne mint Pl. a linuxos ext3fs, sőt az NTFS-nél sem. Ami + a kompatibilitást illeti: a közvetlenül lemezbuheráló programokat egyszer ki kellett dobni az MS-DOS 4.0 után (amikor a 12 bites FAT-ból 16 bites lett), utána pedig ki kellett dobni a win9x után (Pl a DOS-os Norton-os cuccokat). Azoknak a programoknak + akik szabályosan a DOS-on keresztül nyitogatták a fájlokat szvsz tökmind1 hogy milyen fájlrendszre van alattuk.
    Mutasd a teljes hozzászólást!
  • "Nem kell mindenhová feltétlenül stored proc, beágyazott sql vagy trakzakció"

    Azert azt ne felejtsuk el, hogy a tarolt eljarasok alapveto fontossaguak a biztonsagos SQL alapu alkalmazasok keszitesenel.

    netchan

    Mutasd a teljes hozzászólást!
  • Nabazz, megeloztek :)

    netchan
    Mutasd a teljes hozzászólást!
  • FAT: Maga idejeben tokeletes megoldas volt
    VFAT, FAT32: Kenyszer az oprendszer upgrade biztositasara. Ugye nem kell tovabb magyarazni?

    CRLF: na, ezzel nagyon mellenyultal.
    1. Meg a CP/M-bol maradt, azaz nem DOS/Windows talalmany.

    2. Direkt kikuldve a printerre, csak ez csinal soremeles+kocsivissza kombinaciot.

    3. 7bites ASCII adatfolyamot feltetelezve mekkora az eselye, hogy mondjuk bithiba miatt egy
    LF es mekkora annak, hogy CRLF generalodik? Ha a tuloldal CRLF-et var, de tudja, hogy kulon kulon CR vagy LF nem johet, akkor mennyivel jobb a felismeres eselye CRLF-nel, mint sima LF-nel?

    4. Vajon miert lehet, hogy az IETF szabvanyokban (tudod, POP3, SMTP.. meg meg par ezer) a CRLF az elfogadott, ha tenyleg akkora marhasag?

    "Csak az ilyen beszólásoktól tudnátok megszabadulni! Egész jó vitapartnerek lehetnétek"

    netchan
    Mutasd a teljes hozzászólást!
  • Ezt a dolgot a CRLF-fel nem nagyon értem. Akkor most a Mac CR sorvégjele jobb, vagy rosszabb a Unix-ok LF-énél?
    Megjegyzem: ha valammelyik a 3 közül logikus, akkor az az MS-DOS féle CRLF. Azért, mert az konvertálás nélkül, követlenül nyomtatható. (A nyomtató ugyanis az LF hatására csak egy sorral léptet, a CR pedig csak visszahúzza a kocsit, és csak a kettő együtt viszi a következő sor elejére azt.)

    A VFAT-tal, FAT32-vel megint nem értem mi a bajod. Azok jóval gyorsabbak egy journaling fájlrendszernél. Márpedig azoknál a rendszereknél ahol a W9X-eket alkalmazzák, ez a tulajdonság sokkal fontosabb, mint az, hogy halálos biztonságban legyenek a fájlok, vagy, hogy mindenfajta kiegészítő attribútumokat lehessen tárolni velük.

    Ráadásul mindkettőt elsősorban a kompatibilitás igénye (is) szülte: a VFAT gyakorlatilag felülről kompatibilis a FAT16-tal, a FAT32 pedig ugyanis binárisan nem kompatibilis, viszont a FAT16-on dolgozó programokat alig kell módosítani ahhoz, hogy FAT32-n működjenek.

    Egyébként bármilyen a W9X-ekre jellemző tulajdonságot felhozni egy ilyen technológiai szuperioritást vizsgáló vitában alapvető hiba. Ezen rendszerek létrehozásánál ugyanis a kompatibilitás, és nem a teljesítmény, megbízhatóság, biztonság, stb. voltak az elsődleges szempontok.
    Mutasd a teljes hozzászólást!
  • >Szvsz valahogy így keletkezhettek az M$ oprendszerei is
    Csak az ilyen beszólásoktól tudnátok megszabadulni! Egész jó vitapartnerek lehetnétek

    Azert ne mondd hogy nincsenek bennuk erdekes megoldasok. Pl. FAT, VFAT, FAT32 amikor mar volt NTFS is, ket karakteres sorvegjel (CR+LF).
    Mutasd a teljes hozzászólást!
  • Igazad van, én emlékeztem rosszul, bár az általad megadott első link alatt 4 oprendszer is található, amelynél a szekvenciaszám 100%-os biztonsággal megjósolható, így a véletlenség csupán egy ígéret, nem bizonyíték...
    Ebből a szempontból viszont úgy néz ki, hogy a nyílt forrású rendszerek állnak jobban, persze ez csak egy tényező...
    Mutasd a teljes hozzászólást!
  • Itt nem erről van szó, mert ezt a sorszámot (sequence number) véletlenszerűen generálják, így nem lehet megjósolni. (Ha lehetne, az komoly sebezhetőséget jelentene, lásd -> http://razor.bindview.com/publish/papers/tcpseq.html)

    Viszont opcionálisan hordozhat egy TCP fejléc timestamp információt is (option 8). Ezt fel lehet használni az uptime mérésére, viszont ez nem feltétlenül a valódi uptime-ot adja meg, hanem ugye annak csak modulo értékét a számláló ábrázolási hosszának megfelelően. (Valószínűleg erről van szó az MS szerverek 4x napos "újraindulása" kapcsán is.) -> http://www.securiteam.com/securitynews/5NP0C153PI.html

    Azok az operációs rendszerek amelyek ez az opcionális timestamp mezőt nem csatolják a csomagokhoz küldéskor, azok uptime-ját a NetCraft sem tudja mérni (Accuracy Information)

    Mutasd a teljes hozzászólást!
  • "Szóval pontosítok: a NetCraft oldalán látható UpTime grafikonok honnan veszik az adatot??? "

    - Minden hálózaton elküldött csomagnak van egy azonosító száma, ami alapján a "vevő" össze tudja állítani az üzenetet. Ez általában szekvenciálisan növekszik, és egy szerver alkalmazás leállítás/újraindítás sem befolyásolja, mert ez TCP-szinten generálódik.
    Azt hiszem ebből szoktak következtetni az uptime-ra. Az lehet, hogy különböző rendszerek különböző algoritmussal számolnak, ekkor még az op. rendzsert is tudni kell meghatározni az uptime-hoz.
    Mutasd a teljes hozzászólást!
  • Ahogy irtam, "amikor legutoljára találkoztam vele". Legalább egy éve volt.

    Köszönöm azért a korrekciót, jó látni, hogy fejlődik az ipar :)

    Van mondjuk táblaszintű gyors replikáció, mint az MSSQL esetén? A táblaszintű számos esetben fontos, ha backend-frontend felállást alkalmazol, tehát amit mondjuk bent rögzítesz, az húzzon ki a web mögötti szerverhez, de a webes szerver az ügyfél kiegészítéseit (pl. preferenciák, egyéb) már nyomja vissza a benti (work) adatbázisba.
    Mutasd a teljes hozzászólást!
  • Na, ez egy racionális hozzászólás volt szerintem, jó látni ilyet.

    A windows-ok az uptime idejet egy DWORD(elojel nelkuli 32bit) meretu valtozoban tartja. Ezt biz. idokozonkent noveli. 36 nap utan tulcsordul, es 0 lesz megint. Ha addig nem inditod urjra a rendszert, akkor itt garantaltan ujraindul


    Ha már Windows operációs rendszerről beszélünk (NT ág), akkor hadd mondjak ennek ellent, tapasztalatból. A cégnél nálunk a fejlesztői workstation-ök nincsenek kikapcsolva, csak logoff. Az eddigi leghosszabb uptime szerintem olyan két és három hónap között lehetett, akkor is csak azért reboot, mint most is lesz (security patch).
    Részemről biztos vagyok benne, hogy a GetTickCount() 0-nál nincs reboot.
    Egyébként a DWORD 49.7 napig elég, nem 36.
    Mutasd a teljes hozzászólást!
  • "..Marpedig emlekeim szerint 'in real' indul ujra. Mindenesetre kb 3-evvel ezelott olvastam a dologrol utoljara..."
    szerintem arra gondolsz, amikor meg beledoglott egy ilyen tulcsordulasba a win98 (a win98se mar nem
    Mutasd a teljes hozzászólást!
  • Szvsz valahogy így keletkezhettek az M$ oprendszerei is

    Csak az ilyen beszólásoktól tudnátok megszabadulni! Egész jó vitapartnerek lehetnétek.

    Amúgy én sem igazán tudom miért bántjátok szegény mysql-t. Neki is megvan a maga feladata. Pénzügy tranzakciókra én sem használnám, de Pl. egy ilyen fórumot kapásból kiszolgál.

    Ez a fórum történetesen nem MySQL-en megy, de ennek ellenére igazad van. Sőt, alá kell írnom, hogy adott esetben egy weboldal alá sokkal jobb választás lehet egy MySQL egy másik adatbáziskezelőnél, mondjuk IB-nél vagy MSSQL-nél. Azért szerencsére van megoldás a kettő között is.
    Mutasd a teljes hozzászólást!
  • nemtom mier bantjatok a mysqlt. szerintem kedves kis szerver.

    Nem bántjuk csak elmondjuk róla a véleményünk, meg, hogy mire alkalmas és főleg mire nem.

    az a szerencsetlen mssql kb. 1.5 evig tokeletesen kiszolgalta a rendszert, aztan elkezdett hibakat produkalni.[...]hogy mi volt a hiba oka, azota sem tudja senki.

    Ha azóta sem tudjátok, hogy mi volt a hiba oka, akkor én ebből mondjuk nem vonnék le messzemenő következtetéseket az adatbáziskezelő rendszerrel kapcsolatban, bár ezzel nem akarok kizárni azt, hogy abban volt valami gáz (7.0 előtt MSSQL is tudott sokszor furcsákat csinálni).

    ja, konvertaltam az adatbazist mysql-be, programot is (fuggvenyek, ugye), es mukodott.

    Ha nem kellett a teljes adatbázist cakk-pakk újraszervezned a MySQL alá történő portoláskor, akkor az egy olyan adatbázis volt, amit felesleges volt MSSQL alá berakni, minden szempontból.

    Nekem pl. a legnagyobb problémám a stored procedure-ök hiánya mellett az a MySQL-lel, hogy egyszerűen adatbázist nem lehet rá portolni (ha csak nem DBF-ről áttért programozó által létrehozott "adatbázisról", vagy inkább mondjuk úgy: táblahalomról beszélünk), mert egyszerűen még csak nem is hasonlítanak a képességei és a teljesítményjellemzői egy komoly SQL szerverhez. Így ha át is lehet erőltetni bele a táblákat, a kliens oldalon akkor plusz fejlesztési munkát és overheadet generál a port, hogy tökéletesen használhatatlanná válik az addig kitűnően működő rendszer.
    Mutasd a teljes hozzászólást!
  • "Hát ezt az általad "csak egy feature"-nek kikiáltott dolgot azért az SQL szerverek kb. 15 éve tudják, és minden komoly helyen alkalmazzák."

    MArpedig szerintem csak feature.
    Hol van az leirva a relacios adatbaziskezeles elvei kozott, hogy az adatbazishoz kapcsolva kell-lehet tarolni az ot kezelo eljarasokat? sehol.

    Viszont az OO adatbaziskezelesnel szinte magatol ertetodik a dolog (bar ebbe nem mentem meg bele annyira). Ezert mondtam amit mondtam.

    Az meg hogy mar "az SQL szerverek kb. 15 eve tudjak" a tarolt eljarasokat nem jelenti azt, hogy a relacios modell szerves resze. Innentol kezdve viszont csak feature.

    Az elmondottak alapjan pedig nagyon hasznos feature. Alkalmazzak is rendesen.
    Mutasd a teljes hozzászólást!
  • "Ez elég fapados módszer és vannak problémáim vele:

    - Nálunk a rendszergazda nem nagyon ismeri az SQL-t, továbbá a táblák szerkezetét sem minden esetben ismeri(ismerheti !). De ettol még kell tudnia backup-ot készíteni.
    - Nem tunik nagyon "felhasználóbarát" megoldásnak, bár ezt bizonyos oprendszereknél már megszoktuk :))))"

    En sehol sem mondtam, hogz ez egy jo megoldas. En csak leirtam, hogy hogyan lehet backupolni.

    "Én itt igazából arra gondoltam, hogy mi van akkor, ha fizikailag másolom a táblát és másolás közben abba a MySQL beleturkál. Az InterBase általában "belehal" abba, hogy lemásolsz egy megnyitott fájlt és használni akarod a másolt példányt. Az eredetivel nem lesz gond, de a másolat általában checksum error-os lesz. De viszont van backup tool :)"

    Nem tudom, mi ilyenkor az eredmeny, nem probaltam. Vszinuleg nem hasznalhato a tabla, viszont itt is van backup tool... csak mashogy hivjak.
    Mutasd a teljes hozzászólást!
  • "gyanitom, hogy bhubert kollega a fenti kommentben nem ugy gondolta, hogy real ujraindul, hanem csak "kulso szemlelo szamara" indul ujra. (dword zerorol indul ujra, de a rendszer fut tovabb)."

    Marpedig emlekeim szerint 'in real' indul ujra. Mindenesetre kb 3-evvel ezelott olvastam a dologrol utoljara...
    Mutasd a teljes hozzászólást!
  • Valamikor olvastam egy találó megjegyzést: "a MySQL-t olyan programozók tervezték, akik nem láttak még SQL szervert és megpróbáltak rájönni, hogy vajon mit is kellene tudnia..."


    Szvsz valahogy így keletkezhettek az M$ oprendszerei is

    Amúgy én sem igazán tudom miért bántjátok szegény mysql-t. Neki is megvan a maga feladata. Pénzügy tranzakciókra én sem használnám, de Pl. egy ilyen fórumot kapásból kiszolgál. Nem kell mindenhová feltétlenül stored proc, beágyazott sql vagy trakzakció. Ha meg egy fokkal korrektebb dolog kell akkor ott a postgresql vagy az open interbase, ha még korrektebb akkor ott a SAPDB, a SyBase, a pénzes interbase, Oracle, DB2, stb... És egy fórumhoz vagy egy más hasonló kisebb site-hoz ami nem kezel létfontosságú adatokat szvsz jóval hatékonyabb mint a sokkal korrektebb de nagyobb hardverigényű RDBMS-ek.

    A dolog másik része hogy bőven vannak még DBF és más hasonló fájl alapú hálózatos ügyviteli szoftverek W$ alatt (igaz, többnyire szerencsére nem webesek, bár láttam én már olyat aki ilyesmivel is próbálkozott). Na most szvsz a legszuperebb fájl alapú megoldásnál is ezerszer korrektebb dolog a MySQL is... Annak ellenére hogy én a magam részéről azért szívesebben használom a postgresqlt és az open IB-t.
    Mutasd a teljes hozzászólást!
  • nemtom mier bantjatok a mysqlt. szerintem kedves kis szerver. sokat nem tud, de amit tud, azt legalabb tudja.
    eccer volt egy esetem mssql-el, ami gondolom megkozeliti a tobbek altal emlegetett 'komoly' kategoriat. ha nem, akkor ne is olvassatok tovabb.
    fejlesztettunk ra egy rendszert, a felhasznalo kifejezett kerese volt az mssql, mer volt mar neki beallitva egy 7-es.
    elkeszult, semmi spec., direkt nem hasznaltam semmit (ja, delphi4pro), ami kizarna, hogy mas szerver is hasznalhato legyen (na jo, par fuggvenyt).
    kerult a rendszerbe egy iteracio, tobb helyen is vegrehajtodott, olyan igazi xbase-es stilusu (do while !eof(), hehe).
    az a szerencsetlen mssql kb. 1.5 evig tokeletesen kiszolgalta a rendszert, aztan elkezdett hibakat produkalni. mit ad isten, pont az iteraciok kornyeken.
    huszonegynehany rekordos eredmenytablat kellett volna feldolgozni a randa iteracionk keretein belul (elolvasom, kiszamolom, visszairom, megyek tovabb), de nem ment. connection is busy tipusu hibauzenet kisertett.
    2 napot ultunk folotte egy mssql szakertovel, de csak addig jutottunk, irjam at azt az iteraciot sql szemleletben.
    hogy mi volt a hiba oka, azota sem tudja senki.
    ja, konvertaltam az adatbazist mysql-be, programot is (fuggvenyek, ugye), es mukodott.
    azt mar nem probaltam ki, hogy egy xbase 'engine' kepes-e megbirkozni a feladattal, de szerintem igen.
    na, hat nem szeretem az mssql-t. meg akkor sem, ha van szep enterprise managere, meg tud triggereket. a tranzakciokrol meg az elejen le kellett mondani, mert odbc-n keresztul vmiert ugy szetszallt, ha nem 2 sort postoltam, ahogy kell.
    Mutasd a teljes hozzászólást!
  • Az a 36 valóban elnézés volt (megint én vagyok a bűnös), viszont ebben a longintes (32-bites előjel nélküli egész) dologban van valami.

    Ha ugyanis megnézed, hogy ha a 32-bites ábrázolható legnagyobb szám a 4,294,967,296 ms-okat jelöl, akkor az hány nap múlva fordul körbe, akkor a 4294967296/24/60/60 = 49.71 eredményt kapod. Ez pedig gyanúsan a Windows .NET szerver 48.98-as eredménye közelében van. Persze, lehet, hogy tök véletlen az egész, de mindenesetre azért ez a túl egyenletes (azonos időközönkénti) újraindítás nekem gyanús.
    Mutasd a teljes hozzászólást!
  • ez a 36 nap attol tok poen, hogy ilyen adat nem is szerepelt sehol.
    annyi tortent mindossze, hogy valaki elnezett egy grafikont (van ilyen, emberek vagyunk) es innen adodik a hibas adat. ezt mar tudjuk, de ennek ellenere meg mindig mindenki 36 napot emleget.

    "..36 nap utan tulcsordul, es 0 lesz megint. Ha addig nem inditod urjra a rendszert, akkor itt garantaltan ujraindul.."
    gyanitom, hogy bhubert kollega a fenti kommentben nem ugy gondolta, hogy real ujraindul, hanem csak "kulso szemlelo szamara" indul ujra. (dword zerorol indul ujra, de a rendszer fut tovabb).

    fentiek alapjan a jovo het kozepere altalanosan is elterjed:
    "a windows 36 naponkent magatol ujraindul"
    Mutasd a teljes hozzászólást!
  • "Az eljarasra gondolsz?
    Irsz egy scriptet, ami legeneralja az adatbazist.
    Lemented az adatokat tartalmazo tablakat.

    Ha osszevizeli magat, akkor script futtat, tablak bemasol."

    Ha jól értem, akkor ezek szerint MySQL-en úgy lehet "éles futás alatt" backup-ot készíteni, hogy egy script segítségével legenerálom a táblák szerkezetét és valahogy importálom/másolom azok tartalmát?

    Ez elég fapados módszer és vannak problémáim vele:

    - Nálunk a rendszergazda nem nagyon ismeri az SQL-t, továbbá a táblák szerkezetét sem minden esetben ismeri(ismerheti !). De ettől még kell tudnia backup-ot készíteni.
    - Nem tűnik nagyon "felhasználóbarát" megoldásnak, bár ezt bizonyos oprendszereknél már megszoktuk :))))


    "És mi van ilyenkor, a köztes tranzakciókkal???
    ...Inkonzisztencia"

    Én itt igazából arra gondoltam, hogy mi van akkor, ha fizikailag másolom a táblát és másolás közben abba a MySQL beleturkál. Az InterBase általában "belehal" abba, hogy lemásolsz egy megnyitott fájlt és használni akarod a másolt példányt. Az eredetivel nem lesz gond, de a másolat általában checksum error-os lesz. De viszont van backup tool :)
    Mutasd a teljes hozzászólást!
  • " Viszont ha belegodondoltok, akkor ez mar erosen az OODBMS fele hajlo dolog. Annak ellenere, hogy csak egy feature."

    Hát ezt az általad "csak egy feature"-nek kikiáltott dolgot azért az SQL szerverek kb. 15 éve tudják, és minden komoly helyen alkalmazzák.
    Mutasd a teljes hozzászólást!
  • Windows alatt valóban a GetTickCount adja meg ezt az időt, ezt természetesen én is tudtam.


    A hangsúly itt a "tetszőleges oldal"-on volt :)
    Szóval pontosítok: a NetCraft oldalán látható UpTime grafikonok honnan veszik az adatot??? Tudtommal a HTTP protokol nem tartalmaz erre vonatkozó információcserét... Tehát, a NetCraft-osok honnan tudják például, hogy mikor bootoltak a MS-nél?

    ui: Utánanéztem a 36 napnak... Nem számoltam utána, de az MSDN 47,6 napot emleget, tehát ez nem igazán lehet magyarázat a 36 napos uptime-ra :)
    Mutasd a teljes hozzászólást!
  • Amit mostan irok, az csak a 3.23-ra vonatkozik (4 doksit meg nem neztem at)

    "- Triggerek !!!"
    Vannak, de nem hasznalhato semmire

    "- Beágyazott select"
    Mint irtam, klasszikus modon nincs, de mas szintaktikaval ugyanaz az eredmeny.

    "- View !!!"
    Tudtommal nincs

    "- Tárolt eljárások (már említették)"
    Talan a 4-ben...

    "- Shadow fájl készítési lehetőség"
    Emelekeim szerint nincs

    "- Elosztott tranzakciók"
    Biztos nincs

    "- Továbbá kiváncsi lennék az adatbázis fájl egyszerű másolására is backup céljából."
    Az eljarasra gondolsz?
    Irsz egy scriptet, ami legeneralja az adatbazist.
    Lemented az adatokat tartalmazo tablakat.

    Ha osszevizeli magat, akkor script futtat, tablak bemasol.


    "És mi van ilyenkor, a köztes tranzakciókkal???"
    Inkonzisztencia

    "Az egy ok, hogy nálad le van kódolva PHP-ben az a feladat amit a stored proc hajt végre,"
    Egyszer sem hasznaltam meg PHP-t
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd