Vlákno názorů k článku Prieskum názorov systémových administrátorov od Ivo Peterka - 32 respondentů - to je vskutku velké množství...
-
anonymníTento clanek je k nicemu, naprosto ! Nejen ze pocet dotazovanych je prilis nizky, ale navic (a to predevsim) se jich nikdo nezeptal ani na jednu jedinou podstatnou vec pri ktere by mohli opravdu vyjadrit svuj nazor.
Vysledky jsou takove, jako bych tady na rootu vytvoril anketu:
Za jak dlouho zatlucete hrebik?
a) < 5 hodin
b) 5 az 10 hodin
c) den az dva
d) dva dny a vice
Uz vidim ty tisice lidi ktery si nejasnou otazku vylozi po svem (treba ze se k tomu zatluceni hrebiku dokopou az za mesic) a odpovi jinak nez ti, ktere pri cteni takove otazky napadne spalek v lese na kterem lezi kladivo s hrebikem a vedle nekdo se stopkami...
Poste jste vytvorili anketu uplne na hovno, jeji relevance nenalezena. -
anonymníTento clanek je k nicemu, naprosto ! Nejen ze pocet dotazovanych je prilis nizky, ale navic (a to predevsim) se jich nikdo nezeptal ani na jednu jedinou podstatnou vec pri ktere by mohli opravdu vyjadrit svuj nazor.
Vysledky jsou takove, jako bych tady na rootu vytvoril anketu:
Za jak dlouho zatlucete hrebik?
a) < 5 hodin
b) 5 az 10 hodin
c) den az dva
d) dva dny a vice
Uz vidim ty tisice lidi kteri si nejasnou otazku vylozi po svem (treba ze se k tomu zatluceni hrebiku dokopou az za mesic) a odpovi jinak nez ti, ktere pri cteni takove otazky napadne spalek v lese na kterem lezi kladivo s hrebikem a vedle nekdo se stopkami...
Proste jste vytvorili anketu uplne na hovno, jeji relevance nenalezena. -
BLEK. (neregistrovaný)32 případů ... to ještě netušíš, co dělají skuteční počítačoví vědci --- ti vezmou dvě implementace nějakých algoritmů, měří je, obsesivně se dohadují, zda je měření přesné, a dělají závěry, o kolik procent je který algoritmus lepší. A vůbec jim nedocvakne, že kdyby si ty algoritmy nechali napsat jiným člověkem, tak dostanou výsledky o desítky procent jiné. Samozřejmě z toho nikdy žádný zákon ve znění "algoritmus X je takhle rychlý" nevzejde, ale to je jim celkem jedno, hlavně, že je publikace, kterou mohou uložit do seznamu.
-
BLEK. (neregistrovaný)Nacházejí se na katedře softwarového inženýrství a podobných místech. Nedokázali vyvinout. Jejich mentalita je takováhle: "uživatel potřebuje featuru X, takže systém s featurou X bude úspěšný". Tak napíšou systém s featurou X, na papíře důkladně dokážou, že systém má featuru X a publikují to (přičemž recenzent si ten systém ani nestáhne, uvidí pouze papír). Ukáže se, že uživatel chce nejen featuru X, ale i featury Y Z a W ... na což se ovšem v procesu vývoje ani recenze nepřišlo ... takže jejich systém je zcela nepoužitelný, tak se vyhodí a zbyde z něho jen položka na seznamu publikací. Pak se vezme jiná featura a jiný systém a celé kolečko se opakuje.
Mikrokernely, Corba, middleware, XML databáze, sémantický web --- všechno selhalo tímhle způsobem. -
abyssal (neregistrovaný)"Nakolik by "praktičtí informatici" dokázali vyvinout databázi nebo OS, netuším; kde se vlastně nacházejí?"
Napriklad vo vyvojovych centrach firiem alebo univerzitach. Pozrite si napr. MINIX 3 od Tanenbauma a spol. z Vrije University (http://www.minix3.org/). Je to OS zalozeny na myslienke, ze je lepsie mat malicky mikrokernel beziaci v privilegovanom mode (=mozno modelcheckovat ze tam nie su chyby), kde ostatne sluzby ako drivery zariadeni a filesystemov bezia v user mode (na x86 by bolo mozno pouzit asi ring 1 alebo ring 2 pre taketo drivery/sluzby, ale to by nebolo prenositelne).
Cela podstata je, ze tym padom nie je mozne zhodit alebo napadnut samotne jadro, user-mode sluzby sa daju restartnut a su izolovane (btw paradoxne zrovna v instalatore je par bugov, ale odladenie je otazka casu ;-)). Jedine co tomu systemu chyba k uplnej pouzitelnosti su drivery na HW, par ich tam je, ale rozhodne to nepokryva vacsinu HW (co je vlastne najvacsi problem lubovolneho OS, nech je lubovolne dobry). -
BLEK. (neregistrovaný)Ten jsem již viděl a moc kvalitní mi to nepřijde. Pokud jakýkoli proces dělá I/O na disku, tak nejdou volat žádné další syscally. Takže třeba po dobu pár sekund, co se roztáčí CDčko, je ten systém celý vytuhlý, všechny procesy nereagují, i ty, které s CD namjí nic společného. Pokud si na jedné konzoli pustíte ls -laR, tak na druhé nemůžete ani psát do terminálu.
Linus Tanenbaumovi tuto vlastnost starého Minixu vyčítal již v roce 1991 v té známé hádce, a Tanenbaum to udělá znovu stejně.
Jediné, proti čemu je to chráněno, jsou pády ovladačů. Pokud spadne jiný userspacový systémový proces (syscally, síť ...), tak se to zotavit neumí.
Jedna věc je samozřejmě kvalita argumentace v prezentaci, druhá je, když to vezmeš a pustíš. Vědci se soustřeďují na tu první. -
abyssal (neregistrovaný)Njn, je pravda ze som nemal moc cas skumat v zdrojakoch jak maju riesene I/O (podrobnejsie som skumal len kernel). Na druhej strane kolaps syscall kodu v typickom OS vyusti v uplne zatuhnutie. Pointa bola, ze IMHO podobna separacia "subprocesov" do vlastnych sandboxov je dobry napad (preto sa celkom divim za na x86-only OS sa moc nevyuzili CPL 1 a CPL 2 privilege levels). Drivery sa casom odladia a kazdy dalsi novo napisany driver potom nemoze sposobit pad celeho OS.
-
BLEK. (neregistrovaný)Na tom Minixu, když ti spadnou syscally nebo filesystém, tak ti klekne celý taky.
CPL 1 a CPL 2 moc použít nejdou. Jednak z hardwarového důvodu --- procesor neumí chránit stránky podle CPL, pouze segmenty. Možná by to šlo oblbnout tak, že bys tam dal 4 segmenty v rozsahu 0-1G 1-2G 2-3G a 3-4G a pak kdybys stránku namapoval na některé z těchto rozsahů, tak bys tím určil úrovně, ve kterých je stránka přístupná.
Další důvod je ten, že i kdyby to šlo implementovat, tak by to bylo k ničemu. Tak to mělo VMS, mělo kernel ve dvou ringách. A bylo to celkem na nic, protože když ten vnější ring spadl, tak sice nemohl shodit ten vnitřní ring, ale všem procesům přestaly fungovat volání do toho vnějšího ringu. Takže to stejně spadlo celé.
Stejně tak na tom Minixu, když ti spadne proces se syscallama a filesystémem, tak sice mikrokernel zůstane běžet, ale nemůžeš v tom systému nic, ani napsat znak do bashe. Takže ti stejně nezbývá než to resetovat. -
abyssal (neregistrovaný)OK, ale co v pripade, ze je dokazane, ze najlepsi obecny algoritmus na dany problem bezi trebars v Ω(f(n))? V tom pripade je nevyhnutne, ze jediny sposob jak algoritmus urychlit, je pouzit nejake odhady na "bezne pouzitie", ako cachovanie apod.
Konkretny priklad: filesystemy. Tam najvacsi bordel robi sucasna konstrukcia diskov (cas na seek s prehladom "prakticky zabije" aj O(1) algoritmus, kvoli tej konstante). Preto sa vymyslaju rozne sposoby, ktore optimalizuju FS struktury pre dany sposob pouzitia, cachovanie mmapovanych stranok, ale ziadny algoritmus nema "kristalovu gulu" (orakulum?), ktory by mu dopredu povedal jak sa bude FS pouzivat.
Preto jeden FS vyjde lepsie na jeden sposob pouzitia a iny vyjde lepsie na iny (modulo extremne nepodarky ala FATx; ak vam bude niekto tvrdit, ze "jeden FS is the best", tak ho bez rozmyslania zastrelte). Mimochodom, spravit dobry benchmark na rozlicne FS v rozlicnych situaciach je otazka tak na PhD, vybrat spravne situacie na benchmarkovanie vyzaduje podrobne poznat architekturu benchmarkovanych FS. -
abyssal (neregistrovaný)BTW pre prehlad co je vlastne treba brat do uvahy a jak benchmarkovat viz:
Matthias Hauswirth: Automating Vertical Profiling, Vertical Profiling: Understanding the Behavior of Object-Oriented Applications, http://www.inf.unisi.ch/faculty/hauswirth/publications.html (tam je videt, ako rozlicne vrstvy typu kernel, memory allocation, garbage collector apod. ovplyvnuju benchmarky).
