OpenAlt, o distanční výuce s vyzkoušením si HW (Zynq MZ_APO)

5.11.2020 19:45 | Přečteno: 2205× | procesory a roboti | poslední úprava: 5.12.2020 18:55

V sobotním příspěvku Kdo si hraje, nezlobí (se), aneb výuka architektur počítačů v krizi se chceme podělit o zkušenosti s výukou Architektury počítačů v minulém semestru a otevřít prostor k diskuzi i experimentování.

Update: Díky vstřícnosti organizátorů konference jsme dostali k dispozici prostor ještě v sobotu večer od 18:00 (možná i 17:30) na pokračování s experimentováním s naším HW (Hardwarové bastlení na dálku). Kdo se chce připravit, tak si může prohlédnout záznam přednášky Input/Output on MZ_APO Education Kit nebo se i pustit do návrhu vlastní periferie v FPGA. Jak nový návrh nahrát z běžícího systému je pro výukový APO design popsané ve Wiki našeho projektu integrace CTU CAN FD pro Zynq.

Update 2: Záznam přednášky

V třetím týdnu výuky v minulém semestru byl vyhlášený úplný zákaz kontaktní výuky. Nejdříve na přechodnou dobu, kdy vyučující ze dne na den hledali cesty jak vůbec studenty kontaktovat a předat materiály alespoň na ty nejdříve plánované dva týdny (můj zápisek Záznam povídání o paměti a jeho příprava). Poté byli postavení před úkol přejít na distanční výuku do konce semestru. Po strávení většiny času z těch dvou týdnů editováním 140 GB video záznamu z posluchárny jsem dospěl k závěru, že dohromady s vedením cvičení nemám šanci takovou časovou investici a zátěž zvládnout a přešel jsem na nahrávání doma v provizorně vytvořeném virtuálním studiu. O použité technice mám rozepsaný zápisek, ale do přednášky na konferenci OpenAlt 2020 ho určitě vydat nestihnu. V příspěvku se pokusím v rychlosti o některých nápadech a zkušenostech pohovořit naživo. Výsledek přípravy přednášek je k dispozici na YouTube a odkazy na letošní videa jsou přidaná i do zápisku o plánování letošního běhu.

Zásadní pro výuku základní koncepce jednocyklového a zřetězeného procesoru byl simulátor QtMips. Studenti, kteří si ho podle pokynu vyzkoušeli a doma nainstalovali již během začátku semestru mohli plynule přejít na distanční formu výuky podle videí a probírat dotazy a příklady na setkáních se svými cvičícími v časech původně plánovaných cvičení v laboratoři. Pro snadné předávání aktualizovaných příkladů z přednášek a pro procvičení jsme použili GIT (stud-support). Pokud někdo bude mít chuť zkusit úlohy řešené studenty tak si zkuste třeba sladit a optimalizovat na nejnižší počet cyklů algoritmus třidění čísel v paměti s tím, že máte možnost na procesor integrovat maximálně 16 slov paměti cache (popis úlohy v šabloně seminaries/qtmips/apo-sort/apo-sort-template.S). Testovat lze jak v grafické nebo online verzi simulátoru. Automatické vyhodnocení a kontrola na serveru pak využívaly řádkovou verzi simulátoru a plnohodnotný MIPS toolchain (mips-elf-gnu). Po nainstalování pak stačí v adresáři s příkladem zadat make run_test.

Za běžných podmínek pak semestr končí využitím získaných znalostí k naprogramování aplikace pro plnohodnotný systém s procesorem ARM Cortex-A9, na kterém běží distribuce Debian. Přitom vlastní procesorový modul MicroZed je doplněný sadou jednoduchých periferií vstupních a výstupních jak v podobě reálného hardware tak v podobě na míru vytvořeného FPGA návrhu se bloky registrů s bity přímo odpovídajícími LED diodám, čtené poloze voličů atd. Popis periferií připravených pro náš předmět je k dispozici na stránce Přípravek MicroZed APO. Popis prvních kroků, jak s výukovým kitem pracovat pak na stránce Nápověda k práci s přípravkem MicroZed APO. Základní šablona pro přípravu vlastní aplikace s přímým přístupem k registrům periferií z uživatelské aplikace se nachází v GITu mzapo_template. Práce v běžném provozu předpokládá fyzický přístup ke kitům. Stáli jsme tedy před rozhodnutím buď semestrální úlohu zrušit, či zcela nahradit jinou prací nebo zpřístupnit hardware přes Internet. Vzhledem k zátěži studentů dalšími předměty a u některých i ztrácení se v problematice bez kontaktu a porady se spolužáky jsme umožnili těm, kdo měli z práce na dálku obavy, aby odevzdali podobnou práci implementovanou pro simulátor. Ten původně zamýšlený pro grafické aplikace a rychlé spouštění kódu nebyl a jeho použití i po vypnutí většiny vizualizací nebylo komfortní. Odvážnějším studnetům jsme nabídli práci na dálku a po výrobě dalších 20 kitů financovaných z výzvy RPAPS (Rozvojové projekty akademických pracovníků a studentů 2020) jsme kity půjčovali i s lokální instalací systému domů. Pro práci na dálku jsme zajistili přístup k sedmi kitům přes SSH a možnost jejich sledování přes YouTube. Jeden kit byl a stále je k dispozici v zobrazení s vyšším rozlišením přes VLC a ffplay.

ffplay -fflags nobuffer rtmp://147.32.86.117/live/mzapo100

Pozor, počáteční prodleva je velmi vysoká, video se přeposílá přes NGINX z VLC jako RTMP stream (Pokud by někdo uměl poradit, jak počáteční prodlevu zkrátil, radu velmi uvítám). Poté je již latence přenosu i ke mě domů 1.5 sekundy, tedy použitelná na experimentování s HW. Postupně jsme pro studenty přidali i na dva kity možnost nastavovat otočné voliče na dálku přes modelářská serva a doplnily sestavy i přípravky se stejnosměrnými motory.

Během sobotní přednášky plánuji poskytnout privátní klíč ke kontaktování desky a zájemci si mohou vyzkoušet manipulovat s periferiemi, otáčet servy nebo naimplementovat i kompletní servořízení stejnoměrného motoru s inkrementálním čidlem. Vzorem může být článek Linux pro řízení: minimalistické řešení řízení stejnosměrného motoru. V případě naší desky a Zynqu je úloha výrazně zjednodušená, protože výstup inkrementálního čidla je zpracovaný do formy čítače polohy již na úrovni FPGA. Přípravek běží z overlayfs vrstvy v tmpfs nad vyexportovaným svazkem z mého školního počítače. (během semestru běžely kity z diskless infrastruktury katedry). Cílový systém je i na dálku monitorovaný přes sériový port z mého počítače a vysláním dostatečně dlouhého break signálu je možné systém na dálku resetovat a začne poté nabíhat z cela čistého exportovaného svazku. Poškození dat tedy nehrozí. Jinak tento konkrétní kus je trvale používaný v systému kontinuální integrace a testování našeho projektu CTU CAN FD. Může se tedy stát, že kolegové pošlou do repozitáře i během soboty změnu a svět se případným experimentátorům změní pod rukama, výukové periferie se nahradí naším projektem řešeným pro části jednoho velkého automobilového koncernu.

Těším se na vás v sobotu. Něco s kolegou Karlem Kočím o našich zkušenostech popovídáme, budeme rádi, když se do diskuze zapojí i další, ať již naši cvičící, studenti nebo další zájemci a odborníci a přinesou něco nového. Kdo se trochu připraví, tak si i s našimi hračkami (simulátorem a jednou deskou MZ_APO - další nyní slouží v jiném předmětu) mohou vyzkoušet experimentovat. Plánuji pohled na destičku připojit do BigBlueButton jako dalšího účastníka konference. Práci studentů a případnou nápravu/reboot HW jsem během semestru kontroloval z domova. Během soboty budu prezentovat přímo z naší místnosti na Galerii nad Strojovnu, takže budu i fyzicky přítomný. Pokud by někdo moc zlobil, tak kit má i dostupné tlačítko reset a nebo lze vypojit zdroj ze zásuvky.

S přáním Ať vám i vašim blízkým umožní zdraví plnit si své sny a nic a nikdo vám nebrání sdílet radost a výsledky vaší práce a tvorby z mého letošního PF 2020, které je nyní o mnohem aktuálnější než v době jeho rozesílání,
Pavel Píša

       

Komentáře

[Max]

Myslel jsem, že studenti mají mailbox/mailovou adresu od fakulty s doménu fakulty a lze je tedy kontaktovat takto? Nebo tak to nefunguje? Už si to moc nepamatuji, takže nevím, co vše se zadává a co dnes umožňuje KOS a věci na to napojené.
Zdar Max

[Aleš Kapica]

Koukni na stránku ohledně mailů co provozuje VIC (založeno na produktech MS) a např. podobnou stránku co má FEL (řešení na opensource). Někdo prostě svoje maily mít na produktech MS nechce. Jiní se zase zuby nehty brání změnám. Víš co to dalo práce, aby přestali používat lokální katederní mailové servery? A studentské mailboxy nejsou nafurt.

Je to vtipné. Kamarád dodnes používá svůj školní mailbox v USA. Tady u nás ti to po skončení studií ustřelí v lepším případě dva roky po skončení studia a nazdar. Totéž se týká tisíců odkazů na dávno mrtvé weby. Proto jsem si rozjel vlastní server. Je můj a jeho existence je daná jenom tím jak dlouho ho budu schopen udržovat.

[Pavel Píša]

Aleš má v mnohém pravdu. Něco ani není tak jednoduše řešitelné. Jednoznačné je, že každý student, zaměstnanec atd.. má jednotnou identitu, osobní číslo a osmiznakový login přes celý ČVUT a číslo a myslím že i to zkrácené jméno je garantované navěky. V návazné databázi je i e-mail. Ten je po založení nasměrovaný pro FEL na xxxxxxxx@fel.cvut.cz . Mohou si ale nastavit, že se bude z xxxxxxxx@fel.cvut.cz někam automaticky přesměrovávat místo V KOS je možné všem studentům možné nechat poslat e-mail. Jde o to, aby v daném čase schůzky měli volno. To je také celkem jasné, pokud se pokračovalo dále v termínech, kdy byla běžná kontaktní výuka. I když na začátek byli asi studenti v pohyby stěhovali se z kolejí atd. Takže to nebylo až tak jednoduché.

Zásadní problém je ale jinde, zaslání e-malu na 300 adres studentů zapsaných v kurzu. Pokud se pošle bez prodlev, tak všude zaberou antispamy. Stejně tak při využití fóra k předmětu je přeposílání notifikací na e-mail problém. S kolegy z IT jsme během prvních hektických dnů řešili i problém (odstartování antispamu) mezi některými servery naší infrastruktury z fóra do FEL IMAPu. To se snad vyřešit povedlo.

Kdo měl účty nasměrované na Google, tak byl téměř bez šance. Přitom systémy pro rozesílání hromadné pošty vkládají mezi adresáty prodlevu. Takže některé e-maily poslané z rektorátu asi na všechny studenty (přibližně s textem d zítra je škola zavřená) docházely třeba několik dnů po tom, co byla informace irelevantní.

Výsledek počátečního průzkumu mezi studenty, který kanál zvolit jako primární: Vítězí e-mail - zatím 82%, druhý Facebook 13%.

Notifikace nového příspěvku z fóra e-mailem: 43% nedorazilo nic, z news přišlo vše 39%, jen cást 18%.

Další průzkum pro zjištění jak dopadli studneti na Google.

• dorazily a primam je pres FEL (imap, POP) 50%
• NEdorazily a primam je pres FEL (imap, POP) 29%
• dorazily Google 0%
• NEdorazily Google 14%
• dorazily jiný 7%
• NEdorazily jiný 0%

Co se týče e-mailů/identity studentů ale i zaměstnanců po ukončení studia/práce pro FEL, tak je blokace myslím o mnoho rychlejší, než uvedl Aleš. Studenti možná půl roku nebo jen dva měsíce. Vylistování ve vyhledávacích seznamech je pak zablokované téměř okamžitě, má na tom podíl i GDPR. Osobně bych si přál, aby minimálně identita studentovi zůstala přístupná včetně změny hesla a nastavení kontaktního e-mailu do té doby, dokud se nerozhodnou ji zrušit.

S e-mailem je to podle autorit problém, pokud nějaký podepsaný vztah mezi školou a osobou, tak by neměla mít e-mail přímo na hlavní doméně, aby nemohla vystupovat jménem školy, jejího studenta při komunikaci. Zahraniční univerzity to často řeší e-mailem ve formátu xxxxxxxx@alumni.cvut.cz . To je řešení, které sluším i od profesorů zapojenýh do vedení školy jako preferované, když se s někým bavím. Jenže doručování nebo i jen přeposílání pošty někomu, kdo není členem akademické obce vede k využití sítě pro nevědecké účely a tím je proti pravidlům CESNETu. Alespoň to slýchám jako hlavní důvod proti. Slyšel jsem, že se dokonce někde (senát, vědecká rada, ...) vážně diskutovalo a navrhovalo, že by měl FEL zvážit platit pro tyto účely komerční službu mimo CESNET.

Takže ano, je to v dnešní době divné, ale e-mail nefugoval, nebyl dopředu plán, takže se zkoušely Google hangsout, Temsy, Jitsi atd... a byl to zmatek. Nyní se používají převážně MS Temsy, ale ty neumožní těm, co nemají převedenou poštu na SVTI Exchange ani naplánovat schůzku jindy, než okamžitě. Druhé řešení, které umožnilo pokračovat nám byla lokální instalace BigBluButtonu, kterou kolegové zvládli během týdne zprovoznit a zaintegrovat. Nyní již i s pěkným plánováním podle rozvrhu které lze promítnout i do Wiki předmětu, jak je vidět na stránce kurzu BE4M35PAP - Advanced Computer Architectures aktuálního kurzu, který aktuálně vedu.

[Max]

Já jen dodám, že to je právě ten problém, to přeposílání. Kdyby měli uživatelé nastaveno vybírání schránek (dnes umí kdekdo, google, seznam a další), tak to u googlu aj. padat do spamu nebude. Tj., stačilo by pak mít vyřešené jen to posílání v rámci mail serverů školy.
Zdar Max

[trekker.dk]

Já jen dodám, že to je právě ten problém, to přeposílání.

Tak tohle lidem zkuste vysvětlit. Přesměrování čehokoliv na Google je přece samozřejmost.

[Max]

Přesměrování něčeho mimo mailserver je v dnešní době nefunkční věc. Aby to nějak fungovalo, musí se naladit SRS a další věci (nikdo to na serverech nemá nastaveno) a i tak to nebude ideální. Proto je v dnešní době nejlepším řešením si nastavit automatické vybírání schránky. Jak už jsem napsal, dnes to podporuje kdejaké mailové řešení.
Pokud mají třeba vlastní řešení, tak zakázat možnost přesměrování na externí adresy, nebo k tomu dát jednoduché poučení, ať to nedělají a nastaví si vybírání.
Zdar Max

[trekker.dk]

Přesměrování něčeho mimo mailserver je v dnešní době nefunkční věc.

Zopakuju, co jsem napsal: tak to zkuste vysvětlit lidem. Přesměrování čehokoliv na Google je samozřejmost.

musí se naladit SRS a další věci (nikdo to na serverech nemá nastaveno) a i tak to nebude ideální.

Mám a není Zejména když se do toho zamotá DMARC, který aplikuje pravidla platná na obálkovou adresu odesílatele na adresu odesílatele ve zprávě.

Pokud mají třeba vlastní řešení, tak zakázat možnost přesměrování na externí adresy, nebo k tomu dát jednoduché poučení, ať to nedělají a nastaví si vybírání.

Zakázat - no jestli nám přijdete pomoct se zvedáním telefonů, tak klidně, ale vemte si s sebou tak deset lidí na výpomoc Dát poučení - nikdo ho nečte.

[Max]

Již jsem několikrát šel proti proudu, takže vím, jak těžké je udělat změny v něčem zaběhnutém. Nicméně nenarovnávat věci a nechávat je ležet jen tak, to také není ideální, protože se to stejně jednou vrátí. A to je i případ toho CVUT, kdy neměli jak kontaktovat studenty.
Pak je tu ta věc, kdy někdo vymýšlí nesmyslně dlouhá poučení, které nikdo nečte. Neznám moc lidí, co umí dobře a věcně něco napsat s nějakým rozumným formátováním. Ono totiž vymyslet x stránkový elaborát není nic světoborného, ale vymyslet stejné sdělení do pár kratších vět, to nevím proč, ale moc lidí to nedává :-/.
Zdar Max

[trekker.dk]

Holt každý žijeme v jiném světě.

[Jendа]

Proto je v dnešní době nejlepším řešením si nastavit automatické vybírání schránky.

Mně přijde nejlepší řešení dát přeposílající server/obálkovou adresu do allowlistu. Jenže to by Google nesměl být capitalism gone amok:

• Normální by samozřejmě bylo umožnit uživateli si to v nastavení povolit. Dobře, tady můžeme říct, že to je příliš málo využívaná feature (což si nemyslím na to kolik lidí si přeposílá) a nemělo cenu ji implementovat.
• Když už to nejde říct explicitně, tak oni se přece pořád ohání tou klasifikací spamu pomocí umělé inteligence. Jak je možné, že se jejich umělá inteligence nenaučila, že když uživatel maily z mé adresy/mého serveru neoznačuje jako spam, nemaže, a dokonce na ně normálně odpovídá a píšeme si, tak stejně občas nějaký náhodný mail s úplně stejnými parametry odmítne?! To je naprosto jednoznačně úmyslně dohackované. Samozřejmě, provoz vlastních mailserverů je potřeba lidem znechutit, aby všichni přešli na GSuite.

[Max]

Hrajou v tom mj. politiky SPF, ADSP, DMARC, DKIM. Přeposíláním emailu se tváříš jako server původního odesílatele, jen ti nesedí SPF, podpis mailu, ADSP a jiné věci. Takže putuješ rovnou do spamu, nebo jsi rovnou zahozen. Toto jsou politiky, které si nastavuje server původního odesílatele. Koncový mailserver by je tedy měl bez keců akceptovat.
Pokud přeposílat maily, tak jedině formou přílohy. Tzn., nový mail a původní hodit do přílohy. To ale není také optimální, páč to udělá bordel v třídění emailů (nevidíš na první dobrou, od koho mail šel. atd.)
Něco z toho lze řešit pomocí SRS, které se nasadí na ten přeposílací server, ale není to všespásné.
Zdar Max

[trekker.dk]

Ten druhý odstavec už není o přeposílání mailů, ten platí i pro maily pocházející přímo z našich mailserverů. Na gmail prostě nedojdou, protože kdovíproč. SPF trochu pomůže (místo explicitního odmítnutí v SMTP relaci se ta zpráva přijme a tiše vyhodí), DKIM trochu pomůže (totéž) - a přitom jsme Googlu nikdy nedali důvod myslet si, že ty zprávy jsou spam. (Většinou se jedná o maily, kdy klienty informujeme o nějaké plánované odstávce.)

Něco z toho lze řešit pomocí SRS, které se nasadí na ten přeposílací server

Už jsem psal - jde to, ale selže DMARC, protože mechanismus standardizovaný pro obálkové adresy aplikuje na adresy ve zprávě. Na to se musí použít ARC, to určitě povede k nějakému dalšímu problému, takže kolečko, kdy monopolní Google každých pár let vymyslí nový standard, aby lidem provozování vlastních poštovních služeb co nejvíc znepříjemnil, může pokračovat.

Samozřejmě ze svých serverů rozesílají spam taky, ale s tím se nic dělat nedá. Prostě "capitalism gone amok" to vystihuje přesně. A nikdo si na ně nedošlápne, když mají obrat větší než HDP států, kde nabízejí své služby.

[ewew]

Pritom by možno stačilo označiť v google mail :"Toto nie je SPAM." Vidim problém, že niektorí to buď neoznačia alebo to umýselne urobia. Potom google nevie čo vlastne s tým má urobiť.

Iný prístup je poučenie, že správa čo prišla do schránky sa považuje za doručenú. Ďalšie doručovanie už nie je na zodpovednosti Vysokej školy.

[Max]

Pokud máš problémy s googlem u regulérních emailů, tak mají možnost verifikace (zdůvěryhodnění) tvého serveru pomocí dns záznamu.
Pokud rozesíláš hodně mailů, tak by jsi pak i v jejich analyzátoru mohl něco vidět (já tam u domén, co spravuji, nic nemám).
Zdar Max

[trekker.dk]

Máte k tomu nějaký odkaz? O tomhle nevím nic a když se to kolegové pokoušeli řešit s nějakým člověkem od Google, tak AFAIK o žádném DNS záznamu nic neříkal.

[Max]

Postmaster Tools (snad přímý link). Přidáš si doménu, oni ti na základě toho vygenerují DNS záznam, ten hodíš do svých dns k doméně a až se to propíše do světa, tak si v rámci googlu dáš verify. Ono si to ověří, že dns záznam existuje a je korektní a to je vše.
Pokud pak tvůj server odesílá maily asi v desítkách tisíc, tak se ti zpřístupní nějaké statistiky od google. Já odesílám v jednotkách tisíc a statistiky nemám, takže předpokládám, že to musí být větší objem.

Jinak ještě bývá problém s ipv6, kdy celý tvůj subnet zahučí do blacklistu kvůli jedné adrese z toho subnetu.
Dále lze ještě whitelistovat tvojí doménu přes dnswl.org (nevím, kdo vše využívá, google ani ms asi ne)
Zdar Max

[Max]

Jop a ještě bývá jeden záhadný fail. To je ten, když máš k IP tvého mailserveru víc, jak jeden PTR. To je taky výjeb a končíš.
Na base diagnostiku (neodhalí vše, jen základní problémy) je dobrý www.mail-tester.com (od nějaké doby komerční / limitováno na počet mailů za den z jedné domény, nad limit je nutné si zaplatit službu nebo počkat do druhého dne).
Zdar Max

[trekker.dk]

Přidáš si doménu, oni ti na základě toho vygenerují DNS záznam

Kouknu. Ale jinak dobrý, co 10000 domén? To je teda separátní problém, ale úplně podobný - maily poslané přes tenhle server (relay pro desktopové poštovní klienty) občas zahučí u googlu v černé díře. A to ten server je nastavený extra paranoidně, aby se přes něj nespamovalo, i když lidem ukradnou přihlašovací údaje.

Fakt neberu to, že Google zahazuje maily na základě nějakých platných důvodů (mailservery fakt mám nastavené dobře včetně PTR a spol.) Prostě házejí klacky pod nohy konkurenci. Ostatně totéž platí i pro jejich ostatní aktivity třeba u webu.

[Vantomas]

Pokud ten relay server nemá DKIM a SPF od všech těch 10000 domén, tak je stejně pro tyhle účely mrtvý.

[j]

Ja ti teda nevim, ale on si chudak student technicky VS nezvladne nastavit preposlani mailu? Pokud vim tak to normalne slo a nikdy sem to jinak nepouzival.

Vzhledem k tomu, ze produkty M$ email neumi (vubec) tak se ani nedivim, ze o to spousta lidi nestoji nebo se tomu dokonce aktivne brani. Staci bohate kdyz se jen podivas, co za sracky ti utlouk vlozi do prakticky prazdnyho mailu.

Jinak kdyz si to nakous, tak by me celkem zajimalo, ja sudruhovia resej (nejen) GDPR a stim souvisejici faktum, ze jednou pridelenej mail uz proste nemuzes nikdy pridelit nikomu dalsimu, jednoduse proto, ze nevis, jestli mu na to nekdo neco i klidne za 10 let neposle - trebas nejakej ten vypis z banky a podobne.

Mnohem vic by mel pak zajimalo, jak se sudruhovia srovaji s tim, ze v rozporu s GDPR (a to nijak nevokecas, protoze to neni nic co by bylo nezbytne nutny) vyrabej studentsky ucty u M$. Coz ostatne plati i pro stavajici hromadny pouzivani M$ sracek pro vyuku i na zakladnich skolach a jinde.

BTW: SSL zabezpečení, port 465 (případně TLS zabezpečení, port 25 nebo SSL zabezpečení, port 587)

To jako fakt?

---

Dete s tim guuglem dopice!

[Aleš Kapica]

Jo. Zvládne. Jenže se pak dost těžko řeší problémy s doručováním mailu. Nebo jsi snad nečetl tu Pavlovu litanii?

Pokud jde o ten zbytek. To jsou věci co jdou mimo mě a jsem rád, že je nemusím řešit.

[xxx]

a přešel jsem na nahrávání doma v provizorně vytvořeném virtuálním studiu.

To je trochu skoda, kdyz 209/309 i K1 jsou v podstate kvalitne vybavena nahravaci/streamovaci studia, s technikou, kterou by jim mozna mohla kdejaka garazova TV zavidet.

[Aleš Kapica]

To jo, ale doma je doma. A po pravdě řečeno, je to fuk. Pokud máš vhodné nástroje.

[Aleš Kapica]

Jinými slovy, i mojí ženě by moha její domácí "studio" kdejaká garážová TV závidět. A to je jenom "blbá" učitelka na ZŠ. Dva notebooky (jeden pro stream, druhý pro práci), kvalitní konektivita. Nic co by jí mohla škola nabídnout.

[trekker.dk]

Nic co by jí mohla škola nabídnout.

Ne každá škola má po ruce kvalifikovaného ajťáka, který bude schopen něco takového vyrobit. A naopak každá učitelka si může doma (nechat) postavit všechno tak, jak chce, aniž by kvůli tomu bylo potřeba pořádat výběrové řízení. (Ve kterém před lepším řešením snadno vyhraje lépe vypapírované řešení.)

[Aleš Kapica]

To jo. Ale zajistit si alespoň trochu slušnou konektivitu by snad problém být neměl, ne? Mnohem větší problém je, že učitelky jsou ve vztahu k vedení školy většinou dost submisivní. Pokud není ředitel debil, tak se to dá. Ovšem bohužel od té doby, co o obsazení těchto postů rozhodují politické kliky, se to na těchto postech pakama jen hemží – čest výjimkám!

[trekker.dk]

zajistit si alespoň trochu slušnou konektivitu by snad problém být neměl

Je to zakázka, musí to projít přes výběrové řízení, což pro začátek znamená, že někdo (ten ajťák, kterého škola nejspíš nemá) musí vědět, co vlastně chce. Napsat do zadání "trochu slušná konektivita" ke kýženému výsledku nepovede.

bohužel od té doby, co o obsazení těchto postů rozhodují politické kliky

Tedy od vzniku škol.

[Pavel Píša]

Škoda to je, v místnostech je nádherná technika a 4K záznam. Potíž je, že pro prezentaci toho, co jsme chtěl předvádět (simulátor, animace, někdy dokonce i pohledy na HW, kreslení do slidů atd...) existují dvě možnosti

1. buď si to nahrát s pěkným výkladem u tabule a ukazováním na plátno případně kurzorem, které potom bude v obrazu nahrazené kvalitním, digitálně zaklíčovaným výstupem z monitoru
2. nebo si připravit vlastní setup, OBS a přepínat během nahrávání tak jak je potřeba

To první řešení by dalo mnohem lepší výsledky, jenže zaprvé bylo na nahrávání v posluchárnách tolik požadavků, že se musel rezervovat slot a občas ani čas nebyl vůbec, přitom sám jsem se stíháním přípravy cvičení slidů a dohráváním přednášek ze začátku semestru vůbec nedokázal predikovat, kdy budu mít vše připravené. To je moje chyba. Druhý a zásadní problém je, že na technice záviseli odtaní a nemohl bych si OBS přeskládat podle svých potřeb a nebylo vyřešené přepínání scén atd... V Zengerově posluchárně byli technici asi stále a vím, že některé přednášky aktivně režírovali. Ale sám jsem nahrával bez jakékoliv podpory v době nahrávání. Dvě přednášky jsem takto na začátek nahrál, když jsem přišel ke škole a řekli to jedno první pondělí, že do ní studenti nesmí. Zpracování 4K videa na mém počítači určeném pro programování embedded systemů (Intel grafika) bylo na 4 až 7 hodin jednoho renderování. Přitom doplňování zvýraznění znamenalo jednou stříhat abych získal z 4K zvětšený monitor, část tabule atd... znamenalo jednou záznam shlédout a projít, naplánovat a nekde na políčka doladit střihy. Pak rendering, pak poslouchat až třikrát sám sebe, abych správně zvýraznil informace v slidech, ano pokud bych nahrávání plánoval dopředu, něco by šlo získat animacemi v LibreOffice prezentaci. Ale stejně je to extrémní množství práce. S třetí přednáškou takto nahranou, i když bez přípravy, a poté zpracovanou jsem spokojený. Ale je to výsledek tak 30 hodin práce. Čtvrtá byla natočená zcela mimo plán ihned po třetí ve vyčerpaném stavu. Je to na ní vidět. Opět tak 20 hodin zpracování, dvoje 5h renderování přes noc nepočítám. Prostě bez pomoci a výbavy, přístupu na renderovací servery to bylo neúnosné.

Ostatní přednášky jsem nahrával doma proti zelené zácloně s tím, že jsem již během nahrávání paralelně s výkladem klávesovými zkratkami přepínal pohledy, měl vyřešené dokreslování v LibreOffice atd... Vlastní nahrávání pak trvalo jen o něco málo déle, než vlastní doba přednášky. Většina přednášek, kromě osmé byla tak př zpracování a renderování na tři, čtyři kusy, někde se něco nepovedlo, nebo nějaké větší zaškobrtnutí, telefonát atd... Přitom renderování i několika full HD zdrojů bylo výrazně rychlejší než práce se 140 GB 4K videa. Ano, výsledek není profi, na začátek jsem udělal chybu, že jsem přijímač bezdrátového headsetu zapojil přímo do šasi počítače a i při vzdálenosti metr a půl od něho přenos vypadával. Když jsem zapojil přijímač do A-A prodlužovacího USB kabelu, tak je myslím, zvuk celkem dobrý. Ano, i tak mi kolega říkal, že to není ono. Koupil jsem si tedy nyní ze svého SAMSON XPD2 headset, mohlo by to být pr nějaké nahrávání lepší. Celkově jsem se tímto amatérským způsobem dostal s nahráváním a zpracováním většiny přednášek na méně než dvojnásobek čistého výsledného času (když nepočítám noční renderování). I tak každé přednášce předcházel den možná i víc práce na doplňování a čištění slidů.

Takže ano, líbilo by se mi nahrávání trochu profesionálnější. Například tento studenty nalezený úvodní kurz Crash Course Computer Science je zpracováním nádherný. Obsahem si myslím, že náš pipelining a i další jsou lepší, ale to mlže být osobní pohled. Jenže na každém tomto odkazovaném videu s délkou okolo 10 min je podepsaných asi 30 lidí. Já jsme si musel poradit sám, nikdo na pomoc čas neměl. O spolupráci při režii jsem z počátku uvažoval, ale byl jsem odmítnutý a plně to při nasazení kolegů pro zvládnutí celé infrastruktury chápu. Výsledek můžete ohodnotit. Ano, jsem si vědom, že je to amatérské a narychlo zvládnuté v nouzové situaci. Ale proti velkému množství současných nahrávek, které jsou převážně buď mluvící slidy (pro pokročilejší studenty a témata často OK) nebo nahrávky u tabule bez zvětšování monitoru na celý záběr v ukázkách atd. si myslím, že i tak výsledek mého pokusu patří minimálně k těm povedenějším.

A ano, výklad s projektorem na ukázky a tabulí na kreslení s komunikujícími a dotazujícími se studenty a kolegy naživo video v žádném přídě plně nenahradí.

[trekker.dk]

Zvolte variantu 2. Jednoznačně.

Ze dne na den jste byl povýšen(?) na streamera/youtubera, takže můžete převzít jejich zkušenosti. A jedna z těch zkušeností je, že editace videa zabere SPOUSTU času. Ti sledovaní, co produkují hodně obsahu na youtube (a tím pádem i příjmy, ze kterých to mohou financovat), na to mají lidi. Vy ne - nahrát stream je jasná volba.

A ano, výklad s projektorem na ukázky a tabulí na kreslení s komunikujícími a dotazujícími se studenty a kolegy naživo video v žádném přídě plně nenahradí.

Přímý přenos s nějakým jabberem, matrixem nebo něčím takovým na kladení dotazů, by nešel? (Tím neříkám jako náhrada přednášky naživo, ale furt lepší než offline video.)

[Pavel Píša]

Již v pondělí 16.3. jsem studentům napsal e-mail s tím, že jsem na svém školním desktopu jsem rozjel pro všechny otevřený Mumble server a Nginx RTMP zrcadlo. Poslal jsem jak na zrcadlo poslat svojí obrazovku a po předání labelu kolegovi nebo cvičícímu se na kanál připojit. Bez jakékoliv spolupráce s velkými hráči jsme byli schopní rozjet plnou výuku, která by co se výhod společného nahlížení do kódu přes záda studentů (pustil bych si VLC na každého studenta na cvičení), chodila lépe než všechna ostatní řešení. I by si mezi sebou mohli kanály posílat. Ano zabezpečení a šifrování nula, uznávám.

Zcela jsem pohořel, na Mumble se přihlásil jediný student, prohlásil, že všichni studenti jsou na Google Hangouts. Za hodinu jsem byl na Nahgouts, kde mi studenti vysvětlili, že všichni jsou na MS Temsech. Tak jsem s cizinci zkusil Temsy a byl z toho zděšený, jak nemám šanci to na GNU/Linuxu to alespoň trochu rozumně s plánováním používat.

Když mi přišlo od kolegů, že rozběhli BigBluButton tak jsem to bral jako spásu, ale některými studnety byl málem defenestrován.

Jinak si myslím, že Mumble by s hlediska pásma a slabšího připojení byl pro mnoho studentů velmi dobrá volba. Zároveň stejně jako všechno učíme na open-source a vyváříme návody, jak to využít ve vlastních projektech a systémech, tak by Mumble pro IT studenty byl pěkný v tom, že by si mohli okamžitě stavět vlastní servery a být nezávislí jak na velkých společnostech tak na škole. Povolil jsem i pro anonymní návštěvníky vytváření podkanálů, Tím by se mohli studenti radit mezi sebou, zase se scházet k společnému výkladu atd...

Ale na nějaké vysvětlení výhod nebyla pro tvrdou kritiku a opozici a požadavek MZ Teams šance. BBB s přístupem přes prohlížeč, který má každý, množností kreslit do slidů během prezentace a záznamem členěným podle přechodu mezi slidy, je řešení, které běžní uživatelé ještě zvládnou.

[trekker.dk]

No, dobrá zpráva je aspoň to, že tihle "koupím si to od cloudu" mě v budoucnu nepřipraví o práci.

[Max]

MS Teams mi leze krkem. Začínám to silně nesnášet. Jako začátečník jsem byl delší dobu hodně zmaten. Všichni vychvalují, jak je to super, ale že uživatelé neustále volají, že problém tady, problém támhle, to už nikoho nezajímá.
Dokonce jsem měl konferenci s firmou, co zastupuje MS a nebyli schopni to rozjet. Prostě někteří nebyli slyšet a nakonec to vyřešili tak, že si sesedli k sobě :D.
Dnes už jsem o něco dál, takže tak nějak tuším, kde se jaká zrada ukrývá, ale pro obyčejného uživatele to musí být peklo. Nejvíc mně ale vytáčí, že nelze pořádně zjistit, kdo je skutečně do Teamsů přihlášen, jelikož login se nedá nikde zobrazit. Jediný způsob, co jsem našel, je podívat se do trace logů Teamsů.

Každopádně nevím, zda existuje nějaká OSS varianta. Co jsem slyšel, tak Jitsi je v kýblu, videochat s víc účastníky (třeba 10 nebo 20) je údajně konečná. Pár ks je ok, jakmile jich je víc, jde to prý do kolen.
Matrix má údajně také problémy s výkonem. Teď koukám na Mattermost, což by mohla být alternativa pro Teams (má to nějaké kooperace pro dev, sdílení souborů atd.). Nicméně server asi není plně OSS a nejnižší verze se pro nasazení moc nehodí, takže 32USD/user/rok.
Zdar Max

[trekker.dk]

Tak pokud se bavíme o přednášce, tak videochat je podle mě zbytečný luxus, stejně ve větším počtu účastníků - i kdyby to nakrásně fungovalo - nemá smysl mít na obrazovce obrázek každého. Když zrovna bude mluvit někdo jiný než přednášející (dotaz), tak než najdete, kdo to je, tak už dávno domluví. Na tohle podle mě bohatě stačí audio, např. ten Mumble. Má i text chat, takže když někdo bude chtít položit dotaz, tak může napsat "dotaz" a mluvit, když dostane slovo. Video stačí od přednášejícího jako stream

Co se cvičení týče, tam už se obraz hodí k tomu, aby bylo vidět, co má student na monitoru, když bude řešit nějaký problém. Na druhou stranu ani na to není potřeba videokonferenci, podle mě stačí stream od přednášejícího ke všem a stream všech k přednášejícímu (první odstavec v #35) - když bude potřeba, aby ostatní viděli, co má na monitoru konkrétní student, tak stačí zachytit, když cvičící do svého streamu dá stream od toho konkrétního studenta.

(A když píšu stream, tak mám na mysli obecné video podle toho prvního odstavce #35, nikoliv nutně Youtube nebo podobnou službu. Zrovna fakulta asi má dost silnou linku na to, aby to zvládli.)

Jen tak na okraj - mají studenti štěstí, že se jim přednášející přizpůsobuje s každou kravinou, co si vymyslí ("všichni jsou na Hangouts" - "ne, všichni jsou na Teams.") Bejt to já, tak by to skončilo tím, že tady je Mumble, kdo tam není, jeho smůla.

[Rezza]

Na ty přednášky je právě super ten BigBlueButton a musím poděkovat autorovi zápisku, že nám ho ukázal (a domluvil) pro Fedora Release party, zrovna tady na Ábíčku. Já si pak na něj vzpomněl na OpenAlt a zase posloužil skvěle.

[Rezza]

V Nextcloudu jde rozjet něco podobného stylu ala Teams. Ony Teamsy mají jako spousta věcí u MS dobrý základ, skvělý nápad, ale implementaci na... V Nextcloudu je jejich Talk. Ten sije jako Jitsi nedává moc lidí, ale slíbili (možná už to udělali), že bude open source i backend, který by měl umožnit větší konference. Zatím za něj chtěli pár tisíc euro. No a když se udělají správně uživatelé a skupiny v Nextcloudu, tak se tím dají nasimulovat prakticky celé Teamsy.

[xxx]

Ja si neuvedomil, ze ty prednaskovy mistnosti jsou behem semesetru obsazeny, a ze virus vyhnal jen studenty, ale ne prednasejici.

Delat 1. variantu bez supportu a vybaveni je casova sebevrazda.

[trekker.dk]

Pozor, počáteční prodleva je velmi vysoká, video se přeposílá přes NGINX z VLC jako RTMP stream (Pokud by někdo uměl poradit, jak počáteční prodlevu zkrátil, radu velmi uvítám). Poté je již latence přenosu i ke mě domů 1.5 sekundy

Vzhledem k tomu, že se tam prakticky nic nehýbe, tipnul bych si, že zdroj toho videa neposílá moc B-snímků, protože všechno jde řešit rozdílem oproti předchozímu. Tj. že počáteční latence není nic jiného, než čekání na to, až ten enkodér nějaký B-snímek vyrobí, i když to potřeba není. Pokud by to tak bylo, mohlo by stačit vynutit generování B-snímků v kratších intervalech

[Pavel Píša]

Děkuji za názor, asi tomu tak je. Snažil jsem se to vyladit nastaveném kodeku na ultrafast,tune=zerolatency,keyint=30,bframes=0 . Díval jsem se do dokumentace, ale nejsem odborník, takže to bylo především experimentování.

/usr/bin/vlc -I dummy v4l2:///dev/video0:chroma=yu12:width=1920:height=1080:fps:30 --sout=#transcode{vcodec=h264,acodec=none,vb=1200,fps=30,venc=x264{preset=ultrafast,tune=zerolatency,keyint=30,bframes=0,ref=1,level=30,profile=baseline,hrd=cbr,crf=20,ratetol=1.0,vbv-maxrate=1200,vbv-bufsize=1200,aud,lookahead=0,repeat-headers=1}}:std{access=rtmp,mux=ffmpeg{mux=flv},dst=xxx}

Na druhou stranu se mi i podle nějaké dokumentace a dalšího zdá, že ffplay na začátek nabírá nejdříve buffer nějaké, celkem značné velikosti a teprve potom začne řešit co v něm vlastně má.

Dobře chodící připojení z VLC jako klienta se mi nastavit nepodařilo. Vždy to bylo s velkou prodlevou.

Předem díky za případné další nápady.

[trekker.dk]

Na druhou stranu se mi i podle nějaké dokumentace a dalšího zdá, že ffplay na začátek nabírá nejdříve buffer nějaké, celkem značné velikosti a teprve potom začne řešit co v něm vlastně má.

Těžko říct. Zkusil jsem a zdálo se mi to taky - mplayer s -nocache i mpv s --cache=auto a no přehrávání spustí v podstatě vždycky stejně, nějakých půl minuty po spuštění programu. Na druhou stranu tohle

mkfifo stream
rtmpdump -r rtmp://147.32.86.117/live/mzapo100 --live --quiet >stream
mpv --cache=no stream

přestane přehrávat nějakých 5 sekund po ukončení toho rtmpdump. Což ovšem může znamenat, že zahodí zbytek cache, když narazí na konec dat v tom souboru.

Jinak jsem to spletl, není to B-snímek, ale (velké i) I-snímek. Zkuste se podívat na parametry sout-x264-keyint/keyint, možná to pomůže. Jestli jsem dobře pochopil, tak při výchozí hodnotě můžou být při 30fps v intervalu 8 sekund.

[Pavel Píša]

Díky,

ten keyframe/iframe interval jsem se právě snažil zkrátit tou volbou keyint=30, to by mělo dát (podle mě) jednu sekundu. Popis k volbě

sout-x264-keyint <integer> : Maximum GOP size default value: 250

To je default těch 8 sekund. Ale prodleva je řádově delsí. Pokud pak cce člověk dělat něco delší dobu, tak to v zásadě tak velký problém není.

[trekker.dk]

ten keyframe/iframe interval jsem se právě snažil zkrátit tou volbou keyint=30

... a to jsem to v tom příspěvku to "keyint" hledal, než jsem odpověděl. No jo, tak příště