[OSy] Zpětná vazba k OSům

[Jethro]

2015-03-21 20:46 GMT+01:00 Martin Decky <decky at d3s.mff.cuni.cz>:

> Vážený pane kolego,
>
> děkujeme mnohokrát za Vaši podrobnou zpětnou vazbu. Velmi si toho ceníme.
> Předmět Operační systémy se sice v současné formě letos vyučuje nejspíš
> naposledy, ale i pro přípravu nové koncepce se nám Vaše komentáře budou
> hodit.
>
> Dovolte mi, abych k Vašim připomínkám přidal několik svých osobních
> komentářů.
>
>
> Ad "zrušit dokumentaci"
> -----------------------
> Na jednu stranu pochopitelně Vašemu sentimentu rozumím, protože je jasné,
> že jen naprosté minimum absolventů OSů se někdy ke své semestrálce někdy
> vrátí. Na druhou stranu, snažíme se, aby se implementace semestrálky co
> nejvíce podobala reálnému softwarovému projektu v reálném světě. Myslím si,
> ze drtivá většina vývojových metodologií stále ještě tvorbu dokumentace v
> té či oné formě vyžaduje, byť některé agilní metodiky staví funkční
> software nad podrobnou dokumentaci a upřednostňují "lean documentation".
>
Já naprosto souhlasím, že reálný softwarový projekt si dokumentaci zasouží.
Ovšem myslím si, že reálný softwarový projekt se odlišuje již v samotném
procesu tvorby od OSů natolik, že není třeba se snažit k němu přiblížit v
dokumentaci. Navíc, jak jsem již psal, od podobání se reálnému softwarovému
projektu tu máme předmět softwarový projekt.

>
> Myslím si, že "lean documentation" je i cílem dokumentace semestrálky z
> OSů. Rozhodně nám nejde o to, aby každá skupina napsala 50-stránkový
> manuál, který bude zároveň sloužit jako malá učebnice principů operačních
> systémů. Dokonce ani nepožadujeme dokonalou referenční dokumentaci na
> úrovni podrobnosti Win32 API nebo Java SE API.
>
> Ideální dokumentace k semestrálce z OSů by měla obsahovat především popis
> architektury celé semestrálky (ideálně v nějaké standardní notaci, např.
> UML), popis datových struktur (opět ideálně s vhodnými diagramy), slovní
> komentář k některým méně triviálním algoritmům a především odkazy na to,
> kde se co v kódu najde. Taková dokumentace skutečně výrazně usnadní i naše
> hodnocení semestrálky, protože nám třeba pomůže odlišit, co v implementaci
> je zámer a co je jen hack.
>
> Problém, na který sám narážíte, je ten, že většina lidí má ve zvyku psát
> dokumentaci až po implementaci a to typicky na poslední chvíli. To je ovšem
> dost špatný postup, který skutečně často vede jen k frustraci nad tím, že
> to je jen jakási formální a zbytečná činnost. Ve skutečnosti by některé
> zásadní části dokumentace (jako třeba popis architektury v UML nebo popis
> datových struktur) měly vznikat už během implementace, ne-li dokonce před
> samotným psaním kódu. Takový přístup k "lean documentation" může pomoci
> architekturu i implementaci softwaru lépe navrhnout, protože si člověk může
> předem ujasnit, jaké stavební bloky bude vlastně potřebovat a jak by měly
> být poskládány dohromady.
>
Pokud bychom na začátku věděli, že to, co se po nás chce, je fotit si
tabule, na kterých si malujeme, jak to má vypadat, a pak k tomu napsat pár
vět a odevzdat to jako část dokumentace, pak bychom asi měli z
dokumentování lepší pocit. Ale když se celé zadání tváří jako enterprise
projekt, tak nás to ani nenapadlo, protože to nemělo korporátní formu.

Možná je to nedostatkem zkušeností (ale ty jsme právě na OSech nabrali),
ale i když jsme měli stavební kameny dopředu jasné, tak stejně většina
struktur a funkcí doznala významných změn, když při testech / zkoušení
vyšly najevo okrajové případy, na které jsme během návrhu nepomysleli.

>
> A poslední, zcela pragmatická poznámka: Kvalitu dokumentace hodnotíme ze
> všech kritérií zdaleke nejmírněji (právě i s přihlédnutím k tomu, že OSy
> skutečně nejsou předmět, kde by se studenti měli primárně učit psát
> dokumentaci). Prakticky si nepamatuji, že by někdy nějaká skupina za
> alespoň nějaký pokus o dokumentaci (byť celkem mizerný) dostala méně než 5
> bodů. Takže lze říci, že to jsou takové celkem jisté body i za poměrně
> malou snahu :)
>
Buďme tedy se 4.5 body praktickým protipříkladem.

>
>
> Ad "debuggovací výpisy"
> -----------------------
> Tímto bodem narážíte na to, že otázka observability a ladění operačního
> systému (nebo obecně libovolného netriviálně složitého softwaru) je sama o
> sobě docela netriviální. Jinak by neexistovaly projekty typu DTrace nebo
> SystemTap a obecně by se problematikou vhodného způsobu logování nezabývaly
> celé frameworky nebo dokonce celé vývojové technologie (např.
> aspektově-orientovaný vývoj).
>
> Protože je zadání semestrálky z OSů už tak docela obsáhlé (a to je na
> druhou stranu ohlodané až na kost), rozhodně ho nechceme komplikovat ještě
> nějakým složitým mechanismem pro ladění. A koneckonců ve spoustě případů je
> skutečně ad hoc použití printk() celkem dobrá pomůcka při ladění
> konkrétních problémů. Při odevzdání jenom chceme, aby ve zdrojácích nezbyly
> zakomentované ladící výpisy, což se dá udělat v podstatě i automaticky.
>
>
> Ad "rucni průběžná kontrola"
> ----------------------------
> V ideálním světě bych s Vašim návrhem plně souhlasil. Dokonce bych zašel
> ještě dál a chtěl bych dělat code review třeba po každém týdnu nebo větším
> mergi.
>
> Bohužel v ideálním světě nežijeme a tak častou zpětnou vazbu si prostě
> nedovedu v praxi z časových důvodů představit. Navíc by to byla dvousečná
> zbraň: Zatímco současný systém umožňuje skupinám v krajním případě projít
> průběžnými testy s dost "ohackovaným", ne příliš elegantním nebo ne přiliš
> efektivním řešením, které mohou poté vylepšovat, Vámi navrhovaný systém by
> pravděpodobně vynucoval mnohem vyšší laťku hned na začátku a to by možná
> některé skupiny zabilo.
>
> Na druhou stranu, není myslím pravda, že by skupiny neměly podle čeho
> implementaci navrhovat -- pořád ještě existuje také přednáška, vždy jsme
> nabízeli možnost individuálních nebo skupinových konzultací atd.
>
>
> Ad "upravit deadline"
> ---------------------
> Tohle je asi vysloveně věc názoru. Osobně mi příjde, že systém "1 bod za 4
> hodiny" psychologicky nedostatečně odrazuje od odkládání věci na poslední
> chvíli.
>
 Myslím si, že to k odkládání věcí na poslední chvíli nemotvuje o moc více
než současný systém. Věci se na poslední chvíli dělají a dělat budou a
možnost odladit nějakou drobnost (protože víc se stejně nestihne), která se
objevila na poslední chvíli, potěší. Do půlnoci bude programovat skoro
každý bez problémů, ale když si mám vybrat mezi (programováním do rána a
ztrátou bodu) a (možností se vyspat a o bod více), radši se vyspím.

>
>
> Ad "upravit bodování"
> ---------------------
> V tomhle bodě mám vysloveně pocit, že navrhujete něco, co dávno existuje.
> Množství komentářů nikdy nebylo kritériem, vždy hodnotíme kvalitu a
> učelnost komentářů (viz můj komentář o dokumentaci výše).
>
Množství komentářů sice není kritériem, ale chybějící komentáře jsou
strhávány body...

>
> Bonusové body za doplňkovou funcionalitu nad rámec zadání udělujeme a od
> prvního cvičení k tomu skupiny motivujeme.
>
Ano, bonusový minus čtvrtbod za pokus o implementaci forku a execu.

>
>
> Ad "testování na reálném HW"
> ----------------------------
> To, že semestrálku z OSů lze celkem bez velkých problémů rozchodit na
> reálném HW, ukázala letos skupina Boková-Pelikán-Vinárek. Takže i v případě
> tohoto bodu trochu nechápu, co konkrétně navrhujete, protože takové
> iniciativě jsme nikdy nebránili (a samozřejmě ji po zásluze ohodnotíme
> bonusovými body).
>
> Chcete, abychom testování semestrálky na reálném HW požadovali přímo v
> zadání? To by mi nepřišlo šťastné, protože prostředí MSIMu má oproti
> skutenému HW řadu výhod -- chová se deterministicky, je jednodušší
> (neimplementuje cache, nevyžaduje složitou inicializaci a interakci s
> firmwarem), mnohem více odpoušti a umožňuje mnohem snadnější ladění (i pro
> extrémní ladění nevyžaduje JTAG, ale stačí změnit zdroják MSIMu).
>
> Nebo navrhujete, aby všechny skupiny od nás dostaly vhodný HW? Takovému
> požadavku bych docela rozuměl, přecejen procesory MIPS nejsou tak
> všudypřítomné jaké třeba ARM. Aktuálně tolik vývojových desek s MIPSem
> nemáme, ale jistě můžeme uvažovat o jejich pořízení.
>

Navrhuji, aby skupiny, pokud budou chtít, dostaly k dispozici nějaký HW
typu routerboard, aby to bylo inzerováno a aby to bylo podporováno. Viděl
jsem, že to jde udělat, ale pro praktické použití by bylo fajn, aby již v
kalistu bylo implementováno putc a getc přes sériovou konzoli a aby byl v
Makefilu cíl pro reálný hardware. Je mi jasné, že debugování na reálném
hardwaru je náročnější na čas a že nejste schopni nám poskytovat detailní
podporu, ale je rozdíl mezi "Má to stejnou architekturu, tak si to
naportujte sami" a "Pro kompilaci na reálný hardware napište "make hw",
binárku si nahrajte podle tohoto návodu a putc a getc vám chodí na sériovou
konzoli, zbytek si ale budete muset napsat sami". Upravovat něco, co už
trochu funguje je mnohem snazší, než psát věci, které jsem nikdy nepsal, na
hardware, který jsem nikdy předtím neměl.

>
> Škoda, že jste toto přání neprojevil dřív. Minimálně jeden RouterBoard k
> případnému zapůjčení máme.
>
>
> Ad "drobnosti pro debuggování"
> ------------------------------
> Díky za návrhy, většinu z nich jistě můžeme implementovat, pokud nám to
> čas dovolí.
>
> Přesměrování: Možná by i v současné verzi MSIMu mohlo pomoci přesměrovat
> výstup zařízení dprinter třeba do pojmenované roury (metoda "redir") a
> potom zpracovávat trace na stdout.
>
To by asi fungovalo, ale pak by v trace chyběla informace o tom, kdy byl
vypsán znak.

>
> Disk a load; Úplně nerozumím, v čem by měl být problém. Na zařízení ddisk
> metoda "load" funguje, pokud je disk nejprve inicializován metodou
> "generic" na vhodnou velikost (podobně jako v případě paměti). Ovšem
> přiznávám, že by dodatečná chybová hláška u "load" neuškodila.
>
A kde je to napsané v dokumentaci msimu? Když dám load, tak bych intuitivně
předpokládal, že chci disk právě tak velký, jako je soubor a hlavně bych
čekal, že chování load a fmap bude identické, až na to, že změny v disku
nataženém přes load se do souboru nepromítnou a přes fmap ano.

>
> Verbose MSIM, lepší dokumentace MSIM: Ano. Vývojová verze MSIMu [1]
> obsahuje celou řadu podobných vylepšení. To neupozorňování na překryv
> paměti bylo zřejmě motivováno tím, že reálný hardware Vás při konfliktu
> dekódovaných fyzických adres také neupozorní. Ale chápu, že takové
> vysvětlení nemusí být úplně uspokojující :)
>
> Převod trace: Je otázka, jestli je skutečně nutné, aby takový skript byl
> součástí distribuce MSIMu. Věřím, že to je něco, co by člověk v případě
> potřeby dokázal spíchnout za pár minut třeba v Pythonu. Další otázka je,
> jestli v případě takové potřeby není lepší sáhnout k plnohodnotnému
> debuggeru jako je gdb nebo dokonce k nějaké jeho grafické nádstavbě.
>
>
> Každopádně ještě jednou díky za Vaše komentáře. I když v některých
> případech s Vámi možná nemohu 100% souhlasit, i tak je pro nás Vaše zpětná
> vazba cenná -- minimálně nám říká, které věci máme lépe komunikovat.
>
>
> [1] http://d3s.mff.cuni.cz/~holub/sw/msim/
>
>
> S pozdravem
>
> Martin Děcký
>
> _______________________________________________
> OSy mailing list
> OSy at d3s.mff.cuni.cz
> https://d3s.mff.cuni.cz/mailman/listinfo/osy
>

A ještě si rýpnu, když už se po nás chce dodržovat deadliny, byli bychom
rádi, kdyby konec dubna nebyl v druhé polovině května.

S pozdravem
Tomáš Pokorný
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://d3s.mff.cuni.cz/pipermail/nswi004/attachments/20150521/3a90d896/attachment.html>