Názory k článku Komiks: Miluji Linux!
-
Mr.Gentleman (neregistrovaný)Na první pohled se člověk zasměje, ani neví proč
Na druhý pohled člověk kouká, že je to vlastně hrozná blbost
Na třetí pohled se člověk zase směje, protože tyhle blbůstky za to stojí ;)
Na čtvrtý pohled zjistíte, že dotyčného nevyhodili kvůli tričku, ale proto, že trpěl poruchou osobnosti...
:D -
BLEK. (neregistrovaný)Dal jsem to na http://artax.karlin.mff.cuni.cz/~mikulas/spadfs/THESIS.PDF
Důvody odmítnutí:
Je to popis vývoje filesystému a nevypadá to jako vědecký text. Nejsou tam tvrzení a nejsou experimentálně doložená. Smyslem PhD nemá být nic naprogramovat, ale dělat výzkum.
Málo citací. Zejména málo akademických citací.
Špatná angličtina, chybí tam členy. -
BLEK. (neregistrovaný)Za celou dobu, co se zabývám operačními systémy, jsem žádné obecně platné tvrzení o rychlosti programů neviděl, ani jsem žádné neudělal.
Bohužel vědci taková tvrzení vyžadují, vědecké práce se hemží úvahami typu "algoritmus X zvyšuje rychlost o 15%" --- takové tvrzení je nepravdivé, protože když algoritmus X naprogramujou různí lidi do různých systémů, bude změna rychlosti značně různá. Takže tam nějaká taková měření a závěry dodělám a pak to podám znovu, ani nevím, zda mám takhle "vylepšenou" disertaci publikovat na internetu, když tomu vlastně ani sám nevěřím. -
deda.jabko (neregistrovaný)nejaky drsny "teorem" s dukazem, ktery by jim vytrel zrak, tam opravdu chybi ;-] ale to je problem vsech realnych aplikaci, protoze se musi spolehat na heuristiky a empiricke mereni :-/
osobne bych to asi tlacil na to ukazat v cem je pocitani padu lepsi oproti jinym technikam... -
deda.jabko (neregistrovaný)a neuvazovals o tom, dat to nejake slecne na korektury (odstranit z tama nejake ty lingvisticke mouchy) a publikovat to v anglictine? ja si myslim, ze by to lidi zkousli... teda ja urcite...
btw. ja jsem za korektury diplomky slibil jedne slecne luxusni veceri... prilezitost spojit tak nutne s prijemnym... a navazat kontakt s lidmi i mimo IT ;-] -
ultra force 3000 (neregistrovaný)jezis, to sou pyce!!!!!!!
ale jako ja to vim uz davno, ze akademicka puda je lehce (EXTREME ULTRA!!) prohnila a tupa :) super info !!! moc se mi to libi
to sou fakt kokoti debilove !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! malo akademickych citaci. boha jeho.... ja bych je tak nakopal do riti....
ale ty experimentalne dolozene tvrzeni by nebyly spatne..... (hadam nejake ty statistiky a srovnani) -
BLEK. (neregistrovaný)No, právě, že ty experimenty nejdou udělat.
Představ si, že doktor má dva pacienty s nějakou nemocí, jednomu dá lék, druhému ne, po nějaké době porovná jejich stav, a udělá závěr na účinnost léku. Takový experiment by nikdo nebral vážně, protože stav pacienta závisí i na mnoha dalších okolnostech než jen na tom, zda dostane lék --- těch pacientů musí být aspoň stovka, aby to mělo nějakou statistickou vypovídací hodnotu.
Nojo, jenomže 100 filesystémů a 50 vývojářů, co by do poloviny filesystémů doimplementovali featuru, nemáš. Takže na otázku, jak moc nějaká featura pomáhá, nejde přesně odpovědět. Odpověď jde pouze intuitivně odhadnout, jenomže intuitivní odhad vědci šíleně nenávidí. Cíl je tedy "napsat to tak, aby to recenzentovi vypadalo jako že je to jisté".
-
Další problém je ten, že experimentem získáš nějaké číslo --- a není známo, jak to číslo souvisí s prožitkem uživatele. Když udělám rozhodnutí, co operaci X zpomalí a operaci Y zrychlí, bude uživatel rád nebo ne?
Já jsem třeba SpadFS optimalizoval na případy, kdy se často hrabe na související soubory, které jsou blízko sebe v adresářové struktuře --- naproti tomu při náhodném přístupu na spoustu souborů bude nejspíš pomalejší než Ext3. Optimalizoval jsem to tak proto, že ze zkušenosti vím, že programy jako "cp", "tar", "find" apod. se takhle chovají (a ještě nějaké optimalizace na to hodlám udělat). A když ti teď vědec předloží umělý benchmark, který přistupuje na soubory náhodně a začne ti tvrdit, že to je ta performance, protože to bylo publikováno na konferenci, co mu na to říct? Které z těch čísel je důležitější?
Aby se tohle rozumně experimentálně vyřešilo, musel bys udělat double-blind test, mít velkou skupinu uživatelů, která neví, jak je filesystém nastaven a pak bude vyplňovat dotazník o tom, jak jim to připadá rychlý a co jim připadá rychlé a co ne. Takový experiment budeš dělat třeba dva měsíce, zjistíš optimální nastavení jedné konstanty v tvém kódu --- nojo, jenomže těch konstant tam máš ještě dalších dvacet.
-
Místo toho existuje mnohem jednodušší metoda vývoje --- neexperimentovat, prostě svůj program používat, a pokud tobě samotnému připadá v nějaké akci pomalý, tak to zrychlit. --- pak nemusíš dělat nějakou statistiku na to, která část je zodpovědná za kolik procent uživatelova prožitku apod. --- jenže tuhle metodu vývoje vědci nesnáší.
Závěr je takový, že špatně provedený experiment (pustíš benchmark, vemeš číslo a to vydáváš za performanci) je horší než vývoj podle intuice. A dobře provedený experiment udělat nejde z důvodů lidské/časové náročnosti. -
BLEK. (neregistrovaný)Prý tam nějaká korelace je, ale rozhodně ne implikace. T.j. porucha osobnosti neimplikuje programování a programování neimplikuje poruchu. Ale pokud má člověk schizoidní poruchu, tak je velká šance, že bude trávit čas nějakou samotářskou činností, např. programováním. Jak velká je ta korelace, nevím.
-
ultra force 3000 (neregistrovaný)nevim..
udelal bych treba nekolik typickych scenaru.. a ty bych aplikoval na kazdy popisovany fs, aby bylo zrejme na co je kterej fs dobrej.. rozumis..
kdyz nechcou tvuj SpadFS, tak aspon budou mit ty statistiky... sak na ne ser.. dej jim co chcou, ne.... nahustit a poslat do riti .))))))))))) -
BLEK. (neregistrovaný)No, jasně, že udělám testy, co oni chtějí, jenom nevěřím, že to někomu k něčemu bude. Spíš by mě zajímaly reálné zkušenosti lidí s nějakými programy, co na tom pustí.
Oponent asi řekne "ano, jsou tam čísla, ta čísla jsou získaná vědeckou metodologií", pak tu práci uloží do skříně a nikdy ta čísla k ničemu nepoužije. -
Imotep (neregistrovaný)Voe, nerob si srandu. Ma dnes volala jedna holka ze nech k nej idem vecer (sex buddy), ale vobec nemam na to naladu. Radsej som si otvoril vino a uz nemam hulenie, ale zato dostavam chut na tripa. Asi to bude porucha osobnosti? Skor si myslim ze porucha reality, ale ta je pojebana tak natrikrat.
-
To je nechutné. Žádný správný linuxák by se nikdy neopovážil uskutečnit styk s tučňákem, maskotem svého systému. To je, jako by fanoušek Spidermana chtěl opíchat pavouka. Fuj!
Ano, člověk se tomu na první pohled zasměje, aby si nepřipadal prudérní. Ale když se podíváte podruhé a zamyslíte se, tak si uvědomíte, že na tom není nic k smíchu. Nemocný člověk obtěžující tučňáky a k tomu ještě schovávající svou úchylku za Linux. To není k smíchu, to je k pláči a zlosti.
Vždy jsem byl na straně komiksu, vždy jsem jej chválil, když ostatní nadávali. Ale tohle je moc!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!! JÁ CHCI KARLA A ČEŇKA !!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -
Ad Karel a Čeněk: viz http://www.root.cz/clanky/komiks-horsi-den-nez-nejhorsi/nazory/99087/
-
anonymníTak teď už vím pro jaké lidi byla zpráva v konferenci lkml
From: Secret Squirrel <secret_squirrel@nym.alias.net> Subject: Inflatable penguins for sale! To: linux-kernel@vger.rutgers.edu Date: 20 Nov 1999 17:37:36 -0000 Hey boys! I have some inflatable penguins, with fully operatable orifices so you can fullfill that dream of having sex with a penguin!! Love and kisses -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
A taky proč jsou nafukovací tučňáci už vyprodaní -
Radek Hulán (neregistrovaný)Dokazuje to moje nejnovější analýza.
http://radekhulan.cz/item/srovnani-gnome-2-20-versus-windows-vista -
Pavel Píša (neregistrovaný)Tak tenhle vtípek dokazuje, že na tom nejste s vnímáním
světa lidí tak špatně.
Co se obhajoby práce týče, tak by mě extrémě potěšilo,
kdybych něco jako SPADFS viděl dělat naše studenty.
Takže z odmítnutí si nic nedělejte a nebo ještě lépe
vemte ho jako pobídku k nabuzení a dokažte, že máte
pravdu. Vždyť Nasranost je kromě Nadpřirozena, Přemlouvání,
Nejistoty jednou ze základních sil, které drží vesmír
(alespoň podle druidů) pohromadě.
Kód SPADFS se mi tedy čte dost špatně (nějak je tam moc
velkých písmen), ale myšlenka je pěkná a věřím tomu,
že to může být opravdu zajímavé řešení a benchmarky
vypadají slibně. Jsem zvědavý, jaká je architektura
ostatních subsystémů SPADu.
Bude někde text práce k dispozici?
S pozdravem
Pavel Píša -
BLEK. (neregistrovaný)Text jsem už dal sem:
http://artax.karlin.mff.cuni.cz/~mikulas/spadfs/THESIS.PDF
Kdyby u Vás nějaký student něco takového naprogramoval, dojdete ke standartnímu problému --- fakulta nebo stát Vás bude nutit to publikovat na konferencích, které se vývojem softwaru nezabývají (recenzenti si tam ten software ani nestáhnou), tam bude dotyčný student soupeřit s lidmi, kteří nic neprogramují a tráví celý čas editováním článků --- taková soutěž se nedá vyhrát. A nakonec z toho Vaše oddělení nebude nic mít, bez ohledu na to, kolik lidí ten software bude používat. -
Pavel Píša (neregistrovaný)Díky za odkaz. Myslím, že text předkládá hodně
informací a jsem přesvědčen, že mnoho rozhodnutí
o způsobu řešení určitého praktického podproblému
je mnohem těžší a vyžaduje mnohem víc znalostí
a představivosti než mnoho vědeckých pseudočlánků.
Co se textu týče, tak je tam na můj vkus moc "We".
U logových sytémů se mi zdá, že není jejich myšlenka
v začátku odstavce ideálně popsaná. Pokud jsem to nepřehlédl,
tak myslím, že u root anode chybí vysvětlení, proč
zahrnuje i ty původní embeddované extenty.
Dále se nikde v textu nevyskytuje popis toho, jakým
způsobem umožňuje SPADFS jednoznačné mapování inode čísel.
Pokud file přejde v důsledku hard-linku na samostatný
blok a potom je původní jméno smazané, tak to vidím
jako dost složitý problém. Obecně vyhledání souboru
podle inode je nechutná věc, kerá komplikuje unixovým FS
život. Když je inode indexem na fyzickou polohy disku,
je potřeba nějak zkontrolovat, že jsou to skutečně platná
metadata. Když je to číslo přiřazení jinou metodou a
vyhledatelné třeba přes stromy, tak je nutné zajistit unique
alokaci. Taky docela komplikovaný problém.
No nic, přeji hodně úspěchů v dalším kole. -
BLEK. (neregistrovaný)"We" --- školitel mi říkal, že nemám psát "I", ale "We", oponent zase, že nemám psát "We", ale "I" --- čili rozporuplné požadavky :-)
Anode kopíruje ty embeddované extenty proto, aby když je adresář poškozen, tak se soubor dal z anody obnovit. Ze stejného důvodu je v anode i prvních 16 znaků jména.
Inody --- unix naštěstí neumožňuje otevírat soubory podle čísla inod, takže otázku, co dělat, když mi někdo dá číslo inody, nemusím řešit. Potřebuje to jen NFS (to zatím SpadFS neumí), asi to hodlám udělat jednoduchým indexem číslo inody->cesta (a v případě použití na NFS serveru se tento index bude sám vyrábět).
Nějaké unixové programy (např. tar) nemají rády, když se číslo inody mění (to jsem zjistil až poté, co jsem to naprogramoval), takže asi do extended attributů přidám 64-bitové číslo inody a každý nový soubor dostane nové číslo. Vzhledem k tomu, že je 64-bitové, tak se nebude muset řešit přetečení ani alokace volných čísel. -
Pavel Píša (neregistrovaný)Co se týče "We"/"I", tak moje osobní preference je
psát technické informace pokud možno (ú)trpně
a činný tvar ponechat v abstraktu, úvodu a závěru,
aby to nevypadalo tak, že se dílo vytvořilo úplně samo
bez autorova přispění. Celkově ale na mě moc nedejte,
protože disertační práci nemám jseště ani dopsanou,
natož obhájenou a hned tak to ani nebude.
To otvírání inode jsem uvažoval právě na úrovni VFS
kvůli NFS a požadavku na stabilitu přes rebooty.
Ono když mají chodit na NFS linky, tak asi nic moc
jiného nezbývá. Ale z hlediska psaní FS je to dost
otrava.
Ještě mě napadl jeden problém, ketrý mi není jasné,
jak je na Vašem FS řešen. Myslím, že lze souhlasit s názorem,
že ochranu před chybou media není až tak nutné řešit na úrovni
FS. Stejně je to většinou ochrana jen metadat a i tak,
aby to opravdu chodilo by bylo nutné provést další čtení
každého zapsaného bloku až na fyzickou úroveň
a zkontrolovat alespoň konzistenci checksumů.
Je tedy možné předpokládat, že selhání média musí být
ošetřeno mimo FS. V dnešní době to RAID celkem rozumně
řeší. Jenže zde vzniká problém, že zápis je distribuován
na více disků naráz a 100% atomicitu při nedokončených
operacích nelze jednoduše zaručit. Může se stát, že
data dorazí jen na některý/é disk/y. SPAFS požaduje
atomicitu zápisu bloku, která pak nemusí být úplně
zaručena. Zvažoval jste nějak tyto situace.
Má smysl, aby crash-count a příslušející tabulka
byla na disku ve dvou kopiích? Adresářům to stejně
asi nepomůže, přepisují se in-place. Jak moc lze
předpokládat, že situaci napraví řadič RAIDu při příštím
startu? Co se bude dít při dvojité chybě (pád systému
a chyba na úrovni media pro právě zapisovaná data bez
dokončeného zápisu kopie/parity).
PS: nestálo by za to k diskuzi o SPADFS založit nějaké
fórum/list nebo budete pokračovat v loňské diskuzi na LKML? -
BLEK. (neregistrovaný)S tím NFS --- dá se to udělat tak, že udělám adresář /.nfs a v něm pro každé číslo inody udělám soubor, který bude obsahovat cestu k souboru s danou inodou. Pokud bude na soubor víc hardlinků, tak dám jeden hardlink rovnou do /.nfs (pojmenovaný podle čísla inody). Soubory budou obsahovat flag, zda jeho číslo inody je v .nfs, aby se zbytečně nezpomalovaly operace se soubory, na které se přes NFS nikdy nepřistoupilo.
Ad ten RAID --- pokud RAID 5 není degradován, tak špatné zapsání (nebo nezapsání) paritního bloku nevadí, protože se po novém startu stejně synchronizuje. Čili se to z hlediska pádů chová stejně jako normální disk.
Degradovaný RAID 5 nepřežije pád počítače v žádném případě, bez ohledu na filesystém. Tam totiž dochází k situaci, kdy pád v momentě zápisu bloku může modifikovat jiný blok, na který filesystém vůbec nesahal --- takové poškození nepřežije žádný filesystém. Hardwarové RAIDy mají baterii, která by měla data zachránit v případě výpadku proudu, softwarový RAID 5 je prostě poškodí.
Zajímalo by mě --- existuje nějaká možnost, jak implementovat softwarově RAID 5, aby k tomuto poškození nedocházelo? O ničem takovém nevím, ale je to celkem zajímavý problém. Jak je to s RAID 6? - dají se v případě pádu během zápisu data nějak dostat ze dvou paritních disků? -
anonymníMožná chtěl jenom napsat, že hulan káže vodu a pije víno.. celej jeho web jede na tom podle něj nejhorším os :
http://uptime.netcraft.com/up/graph?site=www.radekhulan.cz
Obrázek si udělejte sami... obzvláště když si člověk vědomí kolik přemáhání ho musí stát aby si nezměnil hosting na MS .... to musí bejt linux reálně o hodně lepší než MS ;) -
anonymníPán Hulán, neviem akú máte zmluvu, alebo iný kontakt s výrobcami, hardwéru, lebo HW nároky Visty neskryjete, skúste nainštalovať, a udržiavať v akom takom chode počítač s procesorom 800 Mhz a 128 MB RAM. Windovs XP má problémy, obstojne ide iba Windows 2000, ale ten je pomerne starý. Najlepšia alternatíva je Xubuntu, drží sa najnvších trendov, je aktualizovaný. Tento komentár, píšem tu, lebo viem, že na svojej "supermegaextragiga čítanej stránke" upravujete komentáre. Takýto človek nemá na root,cz čo robiť.
P.S máte s falšovaním svoje skúsenosti, a preto sa skúste uchádzať o post riaditeľa Miscrosoftu po Gatesovom odchode -
. (neregistrovaný)hovori sekretarke: Katka, prosim ta, prekopiruj mesacne data nasim partnerom, oni sa pre ne za chvilku zastavia. - Dobry den, vam mam prekopirovat tie data? - Dobry den, ano ano, prosim, tu mate disketu. - Dakujem. Sekretarka strka disketu do mechaniky: # mkfs -t vfat -c /dev/fd0h1440 # mount -t vfat -o iocharset=koi8-r,codepage=866 /dev/fd0 /mnt/floppy # find / -noleaf -type f -name Otchet_april.[a-zA-Z] -exec cp {} /mnt/floppy ; /mnt/floppy; # ls -la /mnt/floppy/Otchet_april.[a-zA-Z] - Tak a je to! - vracia disketu... Partneri na nu nechapavo hladia... - Ach! Zase som ju zabudla odmountovat?!
-
Zdenek (neregistrovaný)Nevim, ale u me staci rozkliknout ikonu Disketova jednotka a je to. (V Linuxu, samozrejme.)
Navic nevim, proc se v tom "vtipu" zbytecne formatuje disketa a proc se pouziva RUSKE kodovani?
Jo a spravne pripojena disketa se ani bez odpojeni nepokazi, protoze u disket se zpozdeny zapis nepouziva! -
BLEK. (neregistrovaný)Když nebudeš používat opožděný zápis, budou hrozně pomalé. A u flash je opožděný zápis nutnost, jinak si ten flash zničíš.
Pamatuju, že kdysi nějaká BFU-friendly distribuce jako ochranu před tupými BFU vytahujícími USB zařízení zavedla synchronní zápis u USB klíčenek --- a na klíčence po několika stovkách MB odešla FAT tabulka. -
stn (neregistrovaný)Ta sekretarka je pekne blba, jestli tohle dela kazdy mesic. To by se mnou asi slehlo kdybych musel takovyhle prikazy plodit z hlavy. Samozrejme v praxi by na to mela skript svazany s ikonkou nekde v menu nebo na plose, takze ve finale by to bylo na tri kroky:
1. Strcit disketu do mechaniky
2. Dvakrat kliknout na ikonu ci zvolit polozku v menu
3. Vyndat disketu z mechaniky -
Yokotashi (neregistrovaný)proc s ikonou? ... moje sitove skripty (na cestovani mezi sitemi) maji jednoznakove jmeno ... proste ho flaknu do konzole a je hotovo, ikona je moc pomala a dobra sekretarka bude umet psat na stroji, takze pro ni bude konzole urcite prirozenejsi (pokud samozrejme bude UNIX znat dostatecne na to, aby jeho silu mohla vyuzit, coz lze pri zvladnuti parametru mountu ocekavat :-)).
-
<|++|> (neregistrovaný)widle sux a vetsina n00bWannaBeRoot readeru take, jediny normalni clovek je tady BLACK a to jeste pouze v pripade, kdy jeho komentare neobsahuji nic o osobnostech a o poruchach. Ten clovek nad "hrcprc" muze byt rovnez technicky zpusobily, ale kdo dalsi ze zdejsich ctenaru zna napr. setxkbmap ci rxvt ?
ČLÁNKY DO MAILU
