Fatal trap 18

[Divacky Roman]

On Sun, Aug 22, 2004 at 01:06:57PM +0200, Dan Lukes wrote:
> Divacky Roman napsal/wrote, On 08/22/04 11:58:
> >>>Takze nakonec jsem nastartoval system BSDDeviant. Jsem v konzole.
> >>
> >>	Vzacna schopnost jak delat veci co nejsloziteji. Jsme v konferenci o 
> >>FreeBSD, bavime se o FreeBSD - takze kdyz mluvim o CDs Live Systemem, mam 
> >>na mysli, pochopitelne, FreeBSD.
> 
> >jakoze na druhou stranu je fakt ze zrovna tohle ma oficialni fbsd dost 
> >spatne
> >vyreseno.... dost se mi libi treba jak to ma dfly (ie. instalacni cdcko je
> >rovnou live)
> 
> 	No, to souvisi s kapacitou CD. Ja "live" pouzivam opravdu velice 
> 	zridka (petkrat za tu dlouhou dobu, co FreeBSD dost intenzivne na mnoha 
> pocitach pouzivam ?). Vic ocenim, ze je uz na instalacnim OS urcita 
> zakladni sada packages. To se mi hodi daleko casteji.
 
nooo... videl jsi dane dragonfly? ma to SAME co fbsd ale zaroven je to i livecd
(tj. v pripade nouze kdy mam u sebe jen to instalacni cdcko jehoz fixit mod
stoji za 2 veci je vec neocenitelna)
a co se tyce zakladnich packages... tech fakt potrebujes jen par (cvsup?)


 
> 	Krome toho, klidne to nechme na tom, ze je to udelane blbe. Ale  
> 	kdyz mam problemy s diskem - obzvlast pokud mi opravdu jde o ta data - tak 
> preci neexperimentuji s jinymi distribucemi a nejprve se samozrejme 
> pokusim pouzit tu nativni, ktera by si s danym diskem mela rozumet 
> nejlepe (cimz netvrdim, ze derivaty nemohou byt natolik  shodne, ze na 
> tom budou stejne - ale budu to v takove situaci chtit zkoumat a 
> testovat na disku s dulezitymi daty ?)

naprosty souhlas... ma reakce nebyla vyvolana touhou tohle spochybnovat :)

> >btw: freesbie bude mit podporu pro g_uzip - a pry to BRUTALNE zrychluje
> >natahovani systemu (nekolikrat)
> 
> 	To melo FreeBSD nez se z "aout" preslo na "elf" format take. 
> 	Pouzival jsem to. Ale ze by to melo nejake zasadni dopady na dobu zavadeni 
> programu do pameti si tedy nepamatujia pouzivalo seto prakticky vyhradne 
> kvuli uspore mista na disku (tedy, pokud mel clovek maly disk a  byl 
> clovek v nouzi s mistem).

ted si nerozumime g_uzip != gzip
g_uzip je geom trida ktera komprimuje veci na urovni disku. coz samozrejme
snizuje velikost binarek, knihoven atd. coz je u pomaleho media jako je CD dost
pozehnani (jakoze jestli ti startuje program 40 sekudn nebo 8 je rozdil ne?)
pro userland je to neviditelne

> 	Mozna to ale bylo tim, ze tehdy byla pristupova doba na disk (a 
> pruchodnost diskoveho systemu jako celku) v jinem pomeru k rychlosti 
> procesoru nez dnes.
> 
> 	Krome toho, takove pakovani muze sice zrychlit natahovani systemu, 
> 	ale muze mit negativni dopad na beh "uz natazeneho" systemu - obzvlast  pod 
> vetsim zatizeni.

dneska? (zijeme v dobre kdy ma sektretarka p4 at 3.2 a honi na tom outlooka)
a freesbie rozhodne neni system ktery by byl urcen pro "vetsi zatizeni" (je to
livecd)

> 	Memory management totiz v soucasne chvili, v pripade, ze potrebuje 
> uvolnit stranku pameti a vybrana stranka, kterou se chysta "vyhodit" 
> obsahuje kod programu, takovou stranku newapuje, al eproste "zahodi". 
> Vi, ze az ji bude potrebovat, tak si ji proste natahne z puvodniho 
> souboru (v porovnani se swapovanim je to cteni z disku jako cteni z 
> disku - az na to, ze se nespotrebovalo misto ve swapu).

no... to neni tak jednoduche (tedka to placam z vlasnti hlavy takze to nemusi
byt berna mince)
kdyz se pusti program tak je to asociovano s vnode. ten je nejak backed (swap,
soubor na disku). driv sice ty file-backed (ie. programy) vnody ukazovali primo
na nejaky buffer ale dneska ukazuji na geom. tj. je tam o jeden VM objekt vic a
ten rozhodne co se s tou uvolnenou strankou stane. coz znamena ze to ty g_uzip
veci klidne muze nekde cachovat (v separe pameti) aspon tak to chapu ja

ale i kdyby to jednoduse vypudilo z pameti - tak ten komprimovaci algoritmus je
dost rychly takze tohle bych neresil (vypadky stranek programu versus dat to je
docela jednoznacny pomet)

> 	Pokud je originalni soubor pakovany, bude muset  bud' skutecne 
> 	swapovat (a tim se zvysi obsazenost swapu a tim se snizi,pri dane velikosti 
> swapu, mnozstvi dostupne virualni pameti) nebo ponecha puvodni
> puvodni metody, ale pri kazdem "naswapovani"  stranky zpet do pameti 
> bude  muset dekomprimovat - coz se neobejde bez dopadu na vypocetni vykon.

bavime se o livecd..

> 	Technicky to tedy mozne je, otazka ale je, zajakou cenu bude toho 
> zrychleni dosazeno a zda to za to bude stat (pricemz odpovedna tuto 
> otazku nemusi byt univerzalni).

(schvalne sem si ten thread nasel a pastuju sem cisla)
program	    bez	       s

Boot        1:26    1:04
X             41       9
XFce        1:17      18
xterm         13       2
Firefox     3:02      24

jedna se o minuty:sekundy spousteni programu pod freesbie
to myslim stoji zato ne ;)

> >>>block. Tuto hlasku dostanu pro vsechny partismy. sV pripade ze zadam
> >>>fsck /dev/ad0s1a dostanu hlasku BAD SUPERBLOCK:MAGIC NUMBER WRONG a
> >>>jestli chci hledat alternativni superblocks.. zadam ano a dostanu po
> 
> >v ports/sysutils je urcite neco na opravu fakt_tezke_po*_fs
> 
> 	Netvrdim, ze v hlave udrzuju kompletni seznam portu - ale IMHO  tam 
> 	nic takoveho neni.
> 
> 					Dan
ne? skoda... ale tusim jesm "nekde" neco videl (ie. rada na 2 veci)


ale napada mne - MAGIC NUMBER WRONG
nezkousi ten cloek fsck/ufs1 na ufs2 popr. fsck/ufs2 na ufs1 ?

roman

P.S. ten thread o g_uzip a livecd bych utnul, pac je to uz kapku offtopic ;)