Beírom a válaszaimat a tieid közé. Kékkel, hogy áttekinthetőbb legyen. Remélem azt a színt szabad használni. Ha nem, majd trey szól, és többé nem teszem.
"Na de ami a log fájlokat illeti, na az a perverzitás csúcsa ha épp az nem text alapú! "
Ja, hatékony keresés az perverzitás. Egy ilyen text fan ismerős is csinált naplót egyszer egy Minecraft szerverhez, hogy vissza lehessen nézni, hogy mit csinál egy-egy player. Aztán hamar rájött, hogy ahhoz picit lassú lesz a text.
Akkor az ismerősöd rosszul tervezte meg a naplóformátumot. Attól hogy valami text alapú, lehet hogy nem csak 1 állományból áll. Azaz lehet ám indexállományt is csinálni hozzá. De többnyire az se kell. Nemrég írtam például egy démont, s az is naplóz. Értelemszerűen minden sor a dátum-és időstringgel kezdődik. S mert többnyire azért lehet tudni, melyik nap lép fel a hiba, elég csak a sorok elejét figyelni/ellenőrizni/összehasonlítani, s a többi adattal csak akkor foglalkozni ha a keresett nap dátuma lett épp beolvasva.
Az ismerősödnél pedig megsaccolom, lehetett volna playerenként külön fájlt csinálni. Mondjuk itt lehet hogy tévedek mert gőzöm sincs a játékokról. De első tippre nekem ez ugrik be.
Továbbá, a spec bináris formátumokban csak azzal a módszerrel kereshetsz/kutakodhatsz amit direkt arra gyártottak. Text fájlban bármivel ami létezik a világon. Find, grep, perl, awk, regexp, meg az ég tudja mi minden még. Csak a fantáziád szab határt.
"Na és ha baj van, akkor egyáltalán nem szükségszerű, hogy épp a speciális bináris formátum kezeléséhez szükséges eszközök még működjenek."
Erre rengeteg jó megoldást kitaláltak már az évek során.
De most egyet se említettél meg... mindenesetre, 2 eset van: vagy te fejlesztetted ki a formátumot, vagy más. Ha te, akkor kisebb a veszély, de akkor se nulla. Ha más, akkor opensource vagy nem. Ha opensource, kisebb a veszély mint ha nem, de akkor se nulla, mert nem szükségszerű hogy legyen a cégednél szakember aki épp ahhoz a speckó akármihez ért. Ha van is ilyen, lehet hogy épp szabin van amikor a baj beáll. Vagy beteg. Vagy meghótta magát mert a fejére esett egy balkon. Vagy előző nap mondott fel. Vagy ott van nálad, de a baj épp abból áll hogy pont azok a progranyok törlődtek le (vagy azok valami függősége) ami kell a bináris formátum feloldásához, de ezt nem tudja megállapítani rögvest, mert hogy ez a baj azt épp a naplófájlból tudná kiolvasni, de azt nem lehet mert hiszen épp az van abban a damned bináris formátumban...
Ha meg nem is opensource, akkor végképp gáz, mert akkor benne vagy a vendor-lock-in-ben...
" biztonsági kockázat"
Hahahahahahaha, RLY?
Az. Ha nem tudod a formátumot elolvasni azon a gépen ahol az állomány eredetileg készült, át kell vinned másik gépre hogy elolvasd. Az ilyesmi mindig kockázatos. Mert a másik gép lehet fertőzött, vagy az ottani dolgozó korrupt, ipari kém, vagy szimplán haragosod, vagy útközben elveszik a pendrive, vagy ha hálózaton át küldöd az adatot valaki lehallgathatja, akármi. Aztán, a bináris formátum olvasásához eleve egy külön program kell, amibe a fene se tudja mit kódoltak le, s vélhetőleg nem fogod átnézni minden kódsorát magad. Ilyesminek kicsi az esélye, elismerem, de akkor se nulla.
"Így jártam én is, egy aránylag közönséges progival, a MySQL-lel."
Irreleváns hülyeség, amit itt leírsz. Sajnos egyébként van egy rossz hírem, bizonyos adatmennyiség felett nem fogsz te text-et használni. Mert lassú lesz.
Attól hogy sommásan kijelented hogy irreleváns, nem lesz igazad. Tényt írtam le, amit nem cáfoltál. Ha nagyon akarom, a pontos hibaüzenetet is reprodukálhatom újra(bocs, csak warning, nem hibaüzenet) s leírhatom.
"Bizonyos adatmennyiség..." - lehet. De a DokuWikim bírja, s vannak nála messze nagyobb leterheltségű DokuWikik is, és azokkal sincs baj. Attól hogy valami text alapú, simán lehet kitalálni olyan állomány- és indexrendszert, hogy nagy valószínűséggel többnyire csak a teljes adathalmaz egy emberileg elfogadható idő alatt kezelhető részét kelljen a rendszernek átnyálaznia. Különben is, ami a naplófájlokat illeti, azokat többnyire hamar törlik, de ha archiválják is, nem kell keresgélni bennük. Csak hiba esetén. Akkor meg mint fentebb említettem, az utóbbi napok sőt inkább csak órák eseményeiben, ami igazán nem vészes. És hiba különben is ritkán adódik.
"És nem fenyeget az a veszély, hogy gondolnak egyet a kedves fejlesztők, s hirtelen vége lesz valamelyik rendszerhívásnak ami muszáj a programomba."
Érdekes, hogy a MySQL backup/restore esetén mindig van valami érdekes meglepetés, de PostgreSQL-nek a bináris backup formátumával sosem volt bajom. Érdekes.
Nem a backupról és nem a restoréról beszéltem. Amint indítottam a szótárprogit, rögvest megjelent a warning. Azaz egy igazán frekventált, fontos hívásról volt szó. Szükséges a napi használathoz.
Különben meg, a PostGreSQL ritkábban áll rendelkezésre tárhelyeken mint a MySQL, s ha mégis többnyire plusz pénzért csak. Egyáltalán, ha a progi MySQL-re van fejlesztve, mit tehetnék? Az egyetlen biztos dolog a txt. Az mindenütt használható.
"Azért hogy nyerjenek 0.2 millisecundumot valamiben, ami naponta 1-szer kell "
Akkor most egy pillanatra húzzuk ki a fejünket a homokból és nézzünk meg valami más eszközt. Pl. TV-t. Vagy Settopboxot. Vagy mp3 lejátszót. Vagy hasonlót.
Tojok a TV-re. Vagy 20 éve nem nézek tévét. Tényleg. Úgy értem, persze néztem nemegyszer: amikor kimentem a konyhába ahol a nejem főz, ugyanis oda száműztem azt a ReklámWare superfluous zajládát, na olyankor amikor be volt kapcsolva és mondjuk várni kellett a kajára, hát akkor volt rá példa hogy akár 5 percig is bámulhattam. Többnyire addig se mert kikapcsoltam. Ha a nejem morgott emiatt, visszakapcsoltam, s inkább bevittem a kaját a szobámba.
A settopboxról azt se tudom micsoda. Tippelem hogy valami játékizé. Nos, nem szoktam olyannal élni.
Mp3 lejátszóm van. Nem tudom az hogy jön ide. Nem vettem észre hogy bootolna, de ha azt teszi is olyan hamar teszi, hogy nem észlelem. Minek kéne ezt gyorsítani? Egyáltalán, ezeket a kínnal szült példákat felejtsd el. Magasan nem érdekelnek. Tőlem ezekbe tehetnek a gyártók amit akarnak. Ezeket ugyanis nem akarom se programozni, se "személyre szabni". Én a legkifejezettebben csak és kizárólag a magam desktop gépéről beszélek (ami jelenleg laptop, de ha nem az lenne akkor is desktop volna). Szerintem azért annak elég más ám a feladata és szoftverkörnyezete mint egy mp3 lejátszónak nevezett "zenemorzsa" célkütyünek. Az egy speckó céleszköz, egyszer beleégetik a progranyját oszt' jóóvan. Az én gépem "általános célú" kütyü, s elvárom hogy ha turkálni akarok benne lehetőleg azért ne kelljen 2 évente újratanulnom épp a legfontosabb rendszerkomponensek kezelését/paraméterezését stb. Mert ha valami ritkábban használt progiról van szó, azt mondom oké, teszek rá. De már azért az init, meg hasonlók...
Nekem a Grub2 se tetszik. Olyan érzésem van, hogy egy komplett operációs rendszert írtak csak amiatt, hogy azzal indíthassák a tulajdonképpeni operációs rendszert. Már egy ideje vele élek és tanulom, de még mindig messze vagyok attól, hogy legalább annyira felfogjam és olyan magabiztosan kezeljem mint a Grub1-et, holott nem állítanám hogy azt is ismertem volna minden részletében. De azzal azért elvoltam. Na de ez... Ilyenkor visszasírom az ESZR gépek idejét ahol ifjúkoromban operátor voltam. Ott egy "IPL" nevű progi volt az, ami úgy távolról megfeleltethető a Grubnak funkciójában. Valami olyasminek a rövidítése ez hogy "Initial Program Load", persze tuti rosszul írom. Nem baj. Na olyan egyszerűnek kéne lennie egy rendszerbetöltőnek. Ezzel szemben most...
-------------
Honlapom: http://parancssor.info
Könyvem a VIM-ről: http://mek.oszk.hu/09600/09648/#
=== Sabayon disztró, DWM ablakkezelő ===