Re[2]: SVOC :: Remember, remember, the velvet November


node:	Re[2]: SVOC
template:	4
parent:	Re: SVOC
owner:	v92
viewed by:
created:	19.02.2007 - 13:49:25
updated:

cwbe coordinatez:
101
1
102
1546480
1546544
2931877
2933342
2933564

ABSOLUT
KYBERIA

permissions
you:	r,
system:	public
net:	yes

hej diky..povzbudi ;)

000001010000000100000102015464800154654402931877029333420293356402936548

No ten nazov Melua ako taky je onicom... nic to neznamena, zneje to ako z brakovej fantasy knihy, prinajlepsom sa tym da oznacit familiarne pomenovanie vysoko nakazliveho viroveho ochorenia siriaceho sa v afrike :)

keby som siel tvorit nazov pre nieco podobneho, tak pouzijem nejaky nazov, ktory bud nieco znamenal uz predtym (nejaku zjavnu, alebo vymyslenu analogiu) napr.:

Intrinsic grid

co po preklade z anglickeho jazyka do sk_SK znamena cisty grid bez obsahu znecistujucich primesi (vysvetlit sa to moze napriklad podobne, ako Skoda v 70. rokoch pri predaji R-type 110tok v anglicku: Complete sports car -> Plnokrvny grid), alebo ten nazov vytvorim zosrotovanim nejakej skratky, napr.:

HIPESSCA grid s.f. (HIgh PErformance System for SuperComputing Applications) grid

Co uz v principe nieco znamena, sice to zneje latinsky (taliansky), ale take slovo s najvacsou pravdepodobnostou neexistuje.

Nejde o imidz, ale predpokladam, ze to chces aj nejako komercne nasadit ;) a to melua neviem pomaly ani len napisat na prvy krat, nie to este vyslovit, alebo zapamatat si to. A dobry nazov a este viac dobre logo robi marketing.

00000101000000010000010201546480015465440293187702933342029335640293654802936669

HIPESSCA znie mrte vedecky :) celkom sa mi paci.

navrhujem to spravit takto ze uvidi sa v akom stave bude projekt na jesen pretoze vtedy ma expirovat domena a na zaklade toho sa rozhodne ci bude nejaky novy nazov. dovtedy to bude
melua grid.

0000010100000001000001020154648001546544029318770293334202933564029365480293666902959791

Inak rozmyslal si nad tym, ze by mohol byt aj nejaky jednoduchy interface pre vyuzivanie procesoroveho vykonu mobilu?

000001010000000100000102015464800154654402931877029333420293356402936548029366690295979102959859

hm... no... uz vseho vsudy, ked na mobil natiahnes nejaku krute ocesanu verziu inferna, moc vela vykonu ti neostane... teda pokial sa nebavime o plnohodnotnych smartphoneoch...

00000101000000010000010201546480015465440293187702933342029335640293654802936669029597910295985902961382

ne o to neslo. slo o to napisat implementaciu styx protokolu v j2me a urobit pre inferno interface k tomu k comu ma pristup j2me aplikacia v mobile. pocul som ze
napriklad fotoaparat. skratka ze sa spravi nieco ako:
; cd /usr/user1/3/
; ls
camera/
register/
.
.
.
sms

a atd... . napriklad ze niekto chce poslat smsku cez branu (branou by bol hocaky phone na povedzme seriovom rozhrani pripojeny) a napisal len:
; echo 0904123456 "Ahoj, stretneme sa dnes?" > /usr/user1/3/sms

ale to je len predstava.

0000010100000001000001020154648001546544029318770293334202933564029365480293666902959791029598590296138202962092

no ano... to by slo a dokonca by to slo IMHO aj velmi jednoducho... akurat.. skor by som na to postavil server priamo v pocitaci (prepojil ho s transportnym serverom, aby to bolo nezavisle od transportnej vrstvy /kabel, iR, Bt/) a so samotnym telefonom vykecaval cez AT prikazy...

000001010000000100000102015464800154654402931877029333420293356402936548029366690295979102959859029613820296209202962095

alebo takto no, zriesit nejaky gsm fileserver ktory by komunikoval cez seriovy port
s telefonom a cez AT prikazy by spolu komunikovali. nejak takto si to predstavujem:

; mount -c {gsmfs /dev/eia0} /mnt/gsm

kde /dev/eia0 (to je seriove rozhranie) mohol byt akykolvek character device

00000101000000010000010201546480015465440293187702933342029335640293654802936669029597910295985902961382029620920296209502962145

v styxe je mozne zriesit nieco take, ze primontujes jeden server a ten trebars mountne nie jedno character device, ale cely adresarovy strom character devicov... akurat... tu sa to dostava do kolizie so samotnou filozofiou distribuovaneho systemu, lebo mas server, ktory remotne riesi zdroje ineho zariadenia. a tam je prave ten problem, ze na telefon sa nedostanes priamo, ale musis vyuzit sluzby transportnej vrstvy, cize samotny gsmfs by nedokazal bezat len tak, ale potreboval by k svojej cinnosti namontovany filesystem s transportnou vrstvou... a neviem, ako rado by sa to malo so vzdialenym montovanim...
ale cez javu ako taku je to na niektorych mobiloch prakticky nerealizovatelna zalezitost

0000010100000001000001020154648001546544029318770293334202933564029365480293666902959791029598590296138202962092029620950296214502962160

to by slo...inferno to zvlada v pohode. prave na tieto veci je urceny

000001010000000100000102015464800154654402931877029333420293356402936548029366690295979102959859029613820296209202962095029621450296216002962174

takze napriklad... gsmfs pouzije bluezfs ako transportnu vrstvu, aby sa dostal k Obex resource telefonu na hoste gsmhost... ja si ten gsmfs namontujem z desktophosta a gsmfs bude v pohode ako transportnu vrstvu aj nadalej pouzivat bluezfs z gsmhostu? alebo to je skor riesene nejako inak a to riesenie mi uslo? :)

00000101000000010000010201546480015465440293187702933342029335640293654802936669029597910295985902961382029620920296209502962145029621600296217402962214

jasne, tak to funguje ako si to popisal ;)

pripadny bluezfs moze bezat na gsmhost ale rovnako moze bezat aj u teba kedze mas pristup na
bluetooth device gsmhosta. gsmfs moze bezat u teba alebo na gsmhost alebo na uplne inom tretom stroji ktory s tym nic nema spolocne. skratka servery resp drivre ktore obsluhuju device sa mozu nachadzat na uplne inych strojoch nez sa nachadza device. radsej uvediem nejaky priklad.

nech na stroji s menom gsmhost je bluetooth device urceny na komunikaciu s mobilom cez bluetooth.
nech tento device sa vola /dev/bz0 (upozornujem ze toto je len fikcia a ziaden bluetooth stack
neexistuje pod infernom). nas stroj "localhost" chce pristupovat k tomuto mobilu.
bluezfs - tento uz neberme do uvahy, mame /dev/bz0 a ten uplne staci.
gsmfs - moze byt fileserver ktory si moze vziat na vstup nejaky character device a na vystupe
ma Styx protokol.

moze to vyzerat nasledovne:
1. gsmfs bezi na gsmhoste, uz je namountovany a mi k nemu pristupujeme skrz melua grid cez adresarovu strukturu v /usr.
napr:

; cd /usr/user1/1/gsm

2. spustime gsmfs u seba a pouzijeme remotny device

; mount -c {gsmfs /usr/user/1/dev/bz0} /mnt/gsm

3. vyhradime si na to nejaky dedikovany treti stroj ktory sa bude starat len o servovanie gsmfs

"treti stroj":

; listen 'tcp!*!gsmport' { gsmfs /usr/user/1/dev/bz0 }

"localhost":

; mount -c "treti stroj" /mnt/gsm

a podobne kombinacie by som tu mohol vymyslat na 100 sposobov

0000010100000001000001020154648001546544029318770293334202933564029365480293666902959791029598590296138202962092029620950296214502962160029621740296221402967170

jaj jasne... usiel mi ten fakt, ze v inferne neexistuje nic, co by nebolo suborom... nakolko bluetooth stack samotny je v linuxe rieseny ako socketove rozhranie

0000010100000001000001020154648001546544029318770293334202933564029365480293666902936786

no skor aj tak nic nespravis... ak sa ti to HIPESSCA paci, kludne to pouzi, az budes mat chut.