IJK
Member
zastupce cloudu 10.66
Registrován: 22.11.2002
Příspěvků: 56
|
| Shrnuti z meho pohledu |
Příspěvek č. 142 |
Procetl jsem (obcas s premahanim) cely thread, pokusim se shrnout muj nazor a vyhnout se flame. Jako mluvci cloudu CZF HoSo (cca 25 lidi) predkladam nasledujici nazory/navrhy za cely cloud.
- S myslenkou trochu uklidit souhlasim, predlozeny navrh ale podobne vice lidi ve foru povazuji za prilis restriktivni, az paranoidni.
- Cleaning by se IMHO urcite mel tykat obsolete nodu, nebo nodu zustavajicich prilis dlouho v nejakem prechodnem stavu.
- Snizovani statusu APcek nebo klientu s chybejicim linkem povazuji za myslenku, ktera CZF USKODI. I neuplnou informaci ze nekde neco bezi a zda je to AP nebo klient povazuji za cennou. Za naprosto dostacujici zmenu oznaceni bych povazoval varovani o tom, ze informace je neuplna - napr ze chybi link.
- Nelibi se mi vynucovani informaci, a to prestoze se v nasem cloudu snazim o jejich vyplnovani - ale na zaklade toho ze jsem ochoten to dobrovolne delat, ne ze mne k tomu nekdo nuti. Mozna je to tim, ze jsem o pul generace starsi a ruznych vynucovani jsem si v predeslem rezimu zazil dost
- Za uzitecne informace bych povazoval zejmena KANAL, POLARIZACI, ESSID a zakladni TYP anteny u AP (Vsesmer/sektor/PtP, u sektoru hrube smer). To je pro mne z hlediska planovani site a mozneho vzajemneho zaruseni zasadni. Uzitecne muze byt jeste IP, uvadeni MAC povazuji za naprosto zbytecne, nevidim jediny duvod, proc by to melo byt povinne. Zaznel tu argument zjisteni ruseni - ale to predsi poznam podle kanalu, polarizace a ESSIDu, pripadne IP. Naopak to, ze nekde je AP, ale vysila jen na opacnou stranu kopce bych povazoval za uzitecne velmi, ale nikdo to ani nenavrhl (opet vsak jako informaci nepovinnou).
- Spoluprace s mappery je spatna, soucasny system je pomerne zbytecne zatezuje a taky vim, ze maji i bez nej dost prace. Definice "lokalnich" maperu to podle mne taky nespasi - zalezi koho se dari zrovna chytit, jak ma cas, naladu apod. - treba pro mne delal nekolik maperskych zasahu v minulosti Sima proste proto, ze se malinko zname a proto mel duveru ze to co po nem chci ma opodstatneni, prestoze je z naprosto opacneho konce Prahy. Na rozdil od autora navrhu bych proto nepovazoval uzivatele za nesvepravne lamy a dal jim minimalne moznost nastavit si stavy "in construction" a "in testing", pripadne zmenit obsolete zpet na "planned" pokud se vyskytne situace, ze se nekde budovani site prilis vlece (zminen zde byl napr. Branik).
- Tim spise za svepravne povazuji spravce AP - minimalne jim nekdo z maperu pred tim status AP musel udelit. Proto bych nechal plne v jejich moci definovat nebo mazat linky na jejich klienty a zmenit jim status na functional. Adminum i klientum by tak ubylo dost prace a tim by byla i vetsi pravdepodobnost ze udaje v mape budou uplne. Pri takove zmene by automaticky prislusnemu klientovi odesla zprava - aby se omezili mozne chyby nebo (v nejhorsim pripadne) byl zjisten zasah spravce bez souhlasu majitele nodu. Za trochu paranoidni povazuji zde tez zmineny mozny boj dvou "provideru" o klienta, stejne jako omezovani vzdalenosti, kam az muze byt klient apod. I kdyby k tomu melo dojit (jakoze to nepredpokladam), zmineny klient by se to diky odeslane zprave dozvedel - pak teprve ma smysl aby nastoupil mapper a pochybnemu spravci AP odebral nebo zmenil jeho status - tam bych to povazoval za plne opravnene, na rozdil od situace, ze nekdo kdo pro CZF ve svem volnem case toho treba dela spoustu, ale proste nestiha trochu byrokracie (jako treba doplnit MACy).
- Vkladani neviditelnych linku jen kvuli mapperum je znacne Orwellovske. Linky maji vyznam zejmena pro planovani site a pro prehled spravcu AP. Neni zasadni duvod, aby si mapperi pri planovani site byli rovnejsi - pokud nekdo link proste uvest nechce, nelibi se mi to, ale jsem ochoten to respektovat, a aktivni bod v mape je stale pro mne jako informace cennejsi nez bod "za trest" vymazany nebo neaktivni (ale to uz se opakuji).
- Odsouhlaseni linku z druhe strany (jako tomu je doposud) bych pozadoval pouze u linku typu Backbone. Tam to ma sve opodstatneni (zpravidla jde o propojeni dvou AP ruznych spravcu a je tedy logicky souhlas jich obou).
- Pokud se zvysi pravomoc spravcu APcek jak jsem uvadel vyse (t.j. moznost samostatne pridavat linky na klienty a menit jejich status), myslim ze by podstatne ubylo prace mapperum a byl dobry duvod vyrazne omezit jejich pocet a ponechat jen "spolehlive".
- Naopak, pokud by moznost menit status node zustala nadale jen na mapperech a navic podstatne vzrostl pocet povinnych udaju, nedokazu si predstavit, ze by bylo realne, abych udrzel v nasem cloudu poradek, aniz bych pritom sam ziskal pravo mappera, po kterem jinak nijak netouzim.
__________________
IJK
Simuv axiom: Libovolny signal se zlepsi, pripojime-li antenu!
|
12.09.2004 v 12:55
) bude jako maper odstrelen.
