Valamit nagyon nem szeret az X 


$ ls -l .xses*
-rw------- 1 aron aron 8635203584 okt 27 12.16 .xsession-errors
-rw------- 1 aron aron          0 2009 febr  1 .xsession-errors-:1

Nem vicc. Tényleg 8 GB.
Nem tudjátok mivel lehet egy ekkora file-t megnyitni? Kíváncsi lennék, mi van benne. (vi / vim / emacs / kwrite belehal)
Lehetséges, hogy egy wine-al indított telepítő szemeteli tele?

( trey | 2009. 10. 27., k – 12:28 )

Megnyitni? Gondolom csak a vége érdekes. A "tail -n300 .xsession-errors" feltehetően kiírja az utolsó 300 sort.

--
trey @ gépház

( tomsolo | 2009. 10. 27., k – 12:41 )

intel videokártya-e? :)

No rainbow, no sugar

( BaT | 2009. 10. 27., k – 13:12 )

Khexeditorral pl. simán belenézhetsz. De tail egyszerűbb. :)

( raron | 2009. 10. 27., k – 13:25 )

Ilyenek vannak a végén: 


fixme:richedit:RichEditWndProc_common EM_FORMATRANGE: stub
fixme:richelibpng error: Read Error
libpng error: Read Error
QApplication::postEvent: Unexpected null receiver

A fixme: -ket a wine szokta kiírni, de a QApplication -t mi csilálhatja?

Most töröltem a 8 GB -os file-t, de még mindig tele van a partíció...

( ironcat | 2009. 10. 27., k – 16:12 )

Csak a korrektség érdekében: a vi (pontosabban vim) megnyitja a 8 GByte-os fájlt is.

Csak kell neki hely és idő. Sok hely és sok idő. Készítettem egy 8000 MByte-os állományt, és megnyitottam a vi-al. A gond csak az, hogy amikor a vi megnyit egy fájlt, akkor létrehoz egy ideiglenes fájlt is. Ha az eredeti fájl nagy méretű, akkor ennek a fájlnak a létrehozása sok helyet és időt igényel. Ráadásul az ideiglenes fájl nagyobb mint az eredeti volt.
-rw-r--r-- 1 xxxxx xxxxx 8388608000 2009-10-27 13:10 big.file
-rw-r--r-- 1 xxxxx xxxxx 11897614336 2009-10-27 15:59 .big.file.swp

Ha kivártuk a fájl megnyitását, akkor már nagyon gyorsan lehet mozogni a fájlon belül. Viszont ha valamit módosítottunk, és el akarjuk menteni, akkor megint szükségünk lesz a türelemre.

Ezért aztán a vi-ban sem nyitunk meg nagyon nagy méretű fájlokat, csak ha mindenképpen szükséges. Mint már többen írták a tail a megoldás.

Tudom, hogy ovon aluli, de pontosan ezen okbol van a Jujjniksz rendszerek nagy talalmanya:

man sed

(Egyebkent en dolgoztam olyan szovegszerkeszton Jujjniksz (konkretan DMOS) alatt, ami a fejlesztoje szerint memoriaokokbol mindig csak pontosan egy sort tartott a memoriaban. Ennek ellenere teljes kepernyos volt, meg tudta mindazt, amit kellett es a tempojaval se volt soha problemam, pedig 9600 bps vonalon logtunk, es a gep se volt egy atomeromu.

LAJOS!!! Nem akarod portolni a kezdoknek az "e"-t Linuxra?)

A 21. század nagy problémája, miért tudok megnézni egy 8 Gb-os agyontömörített videót agyontömörített audióval és felirattal úgy hogy tetszőlegesen beletekerhetek, de nem egy 8 Gb-os szöveges fájlt.

Vagyis tudom miért, csak azt nem értem, hogy miért nem lehet ezen változtatni.

Ha a logolás adatbázisba történne, akkor ez nem lenne gond. Viszont akkor a vi-al nem tudnád megnézni. Ha a vi/emacs/less/more/tail/... nem lenne alkalmas a logfájlok megnézésére, akkor meg az lenne a baj.

De az igazi probléma az, hogy nem lenne szabad egy logfájlt hagyni 8 GByte-osra hízni.

filmnél meg tudod mondani hogy a kocsi hányadik bytenál robban fel?
azt tudom hogy az n-k byte pontosan az n-k bytenál van

(a sorra ugrás extra szolgáltatás, nagy fájloknál mindenképp erre vonatkozó index nélkül, a pgdn még működhet, de ilyenkor tipikusan hexa vagy e tekintetben ahhoz hasonló olvasóról beszélünk, ugrá mondjuk százalékban, byteban jól működik)

n-k byte-ra ugraskor azert szeretnel ertelmes adatot olvasni, nemde. szovegfile-nal erdemes megkeresni a sor elejet/veget, amire ugrottal. filmnel a frame elejet/veget MIKOZBEN 4MB/s sebesseggel kene jatszani is, ezert van szukseg a framek elejen a frame meretenek letarolasara, akar hogy a kovetkezo jelenet hol kezdodik stb.
altalanos szoveges fajlokban a sorok elejen le van tarolva, hogy hany karakteres az adott sor, vagy hogy hanyadik byte-on kezdodik a kov. bekezdes? (nincs, kimondhatjuk h nem is misson critical)