[powrót]
Materiały na stronie wykładu.
Zabawy z gnuplot i ffmpeg.
Jak obiecywałem, zadania z tej listy można przysyłać mailem (do następnego piątku) za 100% punktów. Na potrzeby obliczania końcowej punktacji max z tej listy traktujemy jako 10 punktów (chociaż zadania w sumie są warte 13 jeżeli zrobicie wszystko).
(3) Przy pomocy gnuplota wyświetl wykres dowolnej nie-trywialnej funkcji. Np. jakiś wielomian, wyrażenie z sinusem w środku. Wyświetl go na ekranie, oraz zapisz do pliku PNG. Strona WWW gnuplota zawiera mnóstwo informacji, see w szczególności Official gnuplot documentation. Na dole strony wykładu też są linki do masy dokumentacji.
Pobaw się z opcjami wyświetlania gnuplota, przynajmniej pobaw się wyświetlaniem wykresów filledcurves/lines i coś jeszcze do wyboru. Demo gallery gnuplota (sekcja "Basic 2D plot styles" na początek) może posłużyć jako inspiracja :)
(3) (To samo co zadanie 1 z listy wykladowcy:) Zestaw skryptów (gnuplota i/lub shella), pozwalający użytkownikowi generować wykresy dowolnie wybranych parametrów meteo (jednego lub więcej) z wyborem wyświetlanego przedziału czasowego. Plik z danymi jest tutaj. Opis kolumn w pliku tutaj. Wykresy należy tworzyć w postaci plików graficznych (np. PNG).
(W sumie 7 punktów do zdobycia) Przy pomocy ffmpeg pobawimy się przetwarzaniem filmów.
Przyda się dokumentacja ffmpeg
albo man ffmpeg.
(1) Przede wszystkim, do zabawy z ffmpeg przyda nam się plik z filmem
(audio i wideo). Tylko że pliki jakie zapewne znajdziecie na swoim
dysku twardym są dość duże, i przetwarzanie ich portwa olbrzymią
ilość czasu. Na szczęście, samym ffmpeg'iem można też wyciąć
zadany kawałek filmu. Więc najpierw: napisz polecenie które wycina
5 sekund ze środka filmu. Wynikowy film (powinien zawierać i audio
i wideo) ma być zapisany jako osobny plik, jak out.mpg.
(1) Przetestuj konwersję na różne formaty wyjściowe video.
Przetestuj różne jakości kompresji podając różne wartości
bitrate. Przetestuj też opcję -sameq.
(1) Połącz (concat) dwa filmy w jeden, tzn. najpierw ma być odtwarzany pierwszy, potem drugi film.
(1) Przy pomocy ffmpeg rozdziel film na dwa pliki:
jeden ma zawierać tylko wideo,
drugi tylko audio. Po czym przetwórz plik dźwiękowy przez sox,
np. zwiększ basy (man sox).
Po czym z powrotem połącz audio i wideo w jeden plik za pomocą
ffmpeg.
(1) Przy pomocy ffmpeg można odczytywać
i zapisywać video jako zwyczajny ciąg obrazków,
see image2 demuxer (odczyt)
i image2 muxer (zapis).
Skonwertuj swój plik wideo na ciag obrazków przy pomocy ffmpeg,
po czym użyj convert z ImageMagick z opcją -draw
żeby narysować/napisać coś na wszystkich obrazkach,
po czym skonwertuj ciąg obrazków z powrotem na film przy pomocy
ffmpeg.
Notka: testuj na pliku małej wielkości, ~1/2 sekundy, inaczej potrwa to bardzo długo. Przetwarzanie obrazu filtrami ffmpeg (punkt poniżej) jest zazwyczaj lepszym pomysłem.
(2) Zabawy takie jak powyżej z rozkładaniem + przetwarzaniem (sox, convert) + składaniem z powrotem są możliwe... ale sam ffmpeg też ma wbudowane pewne filtry za pomocą których można przetwarzać audio lub wideo. See Filtergraph description w dokumentacji.
Dodaj na początku filmu proste fade-in za pomocą filtra fade.
Napisz tekst na środku filmu filtrem drawtext.
Pobaw się dowolnymi innymi 2 filtrami. (Warto upewnić się
czy nasz zainstalowany ffmpeg ma wszystkie filtry skompilowane
— sprawdź ffmpeg -filters.)
Chciałem zrobić Wam listę gdzie będziecie mogli pobawić się diff
i patch. Ale z radością odkryłem że grupa Piotrka Wieczorka
już ma taką listę, dobrze napisaną :)
Czyli w ramach dzisiejszych zajęć (lista 11 w/g naszej numeracji) robimy listę 10 z grupy PWI. Punktacja dokładnie taka jak opisana na liście, w sumie 10 punktów.
To zadanie można rozwiązywać zdalnie, za 100% punktów, do następnego piątku. Jako rozwiązanie proszę przysłać mi mailem:
Dokładny URL skąd pobraliście źródła wybranego programu. Tzn. najlepiej wprost do paczki tar.gz ze źródłami.
Może to być też URL dla svn checkout albo git clone
albo innego systemu zarządzania kodem,
jeżeli ściągacie stamtąd źródła. Tylko w takim wypadku upewnijcie
się że pracujecie na wersji z taga, albo podajcie mi revision
które mam wziąć — innymi słowy, upewnijcie się że będę umiał
bez problemu pobrać dokładne te źródła z którymi pracowaliście.
Dokładne instrukcje które wykonaliście żeby skompilować i zainstalować program.
Dokładne instrukcje które wykonaliście żeby znaleźć ciekawą linijkę
do zmiany. Chyba nie zdradzę żadnego sekretu jeżeli podpowiem że warto
użyć grep :), być może opakowanego w jakimś wygodnym IDE.
Oczywiście, Wasz plik z poprawką (łatką, patchem) xxx.patch.
Ma się nakładać na źródła perfekcyjnie.
Oraz precyzyjne polecenie patch
(z odpowiednią opcją -pX) którego trzeba użyć żeby
nałożyć Waszą poprawkę.
Innymi słowy, chciałbym umieć sprawdzić Waszą łatkę.
Kilka ogłoszeń na koniec semestru:
Piątek w tym tygodniu wypada 6 stycznia, i jest ustawowo wolny. Odpoczywamy.
Jakoś strasznie szybko kończy się ten semestr — wychodzi na to że pozostały nam już tylko 2 pracownie (13 i 20 stycznia). Od 23 stycznia jest już sesja egzaminacyjna. Będą jeszcze dwie listy, numer 11 i 12. Planuję że obie będą miały max 10 lub 12 punktów, czyli totalny max punktów (w/g którego liczone są progi punktowe) wzrośnie jeszcze o 20-24.
Punkty z listy 9 przeskalowane w górę: lista 9 (16 zadań za 1 punkt) wyszła nieco dziwnie, nikt nie osiągnął max ilości punktów. W ramach zadośćuczynienia, przemnożyłem wszystkim punkty zdobyte za listę 9 razy 4/3. Na przykład jeśli mieliście wpisane 12 punktów, to teraz macie wpisane 16 punktów.
Bonusowe zadania: prezentacje: chciałbym zaproponować kilka dodatkowych wysoko punktowanych zadań, dla osób chcących nadrobić punkty (albo łatwo wskoczyć na ocenę 5.0 bez robienia regularnych list :). Żeby nie było nudno, zadania są wysoko punktowane, ale polegają na zrobieniu prezentacji i/lub przygotowaniu ściągi (w PDF/ODT/HTML) na dany temat. Szczegóły:
Prezentacja ma trwać 15-20 minut.
Prezentacja musi być zrobiona w czasie pracowni, czyli 13 lub 20 stycznia pomiędzy 10:15-12:00.
W czasie prezentacji do dyspozycji macie rzutnik i laptopa z moim Linuxem (Debian testing 32-bitowy). Jeśli trzeba coś na laptopie zainstalować wcześniej, to dajcie mi znać oczywiście. Prezentacja może być np. o godzinie 11:00, więc będziecie mieli najpierw 45 minut na przygotowanie sobie danych na laptopie. Oczywiście można też przynieść własny laptop i jego użyć.
Nie oczekuję że w czasie prezentacji będziecie koniecznie pokazywać slajdy. (Chociaż jeśli ktoś zrobi slajdy, to tym lepiej, oczywiście...)
Przede wszystkim oczekuję że na laptopie rzeczywiście pokażecie "jak to się robi", tzn. pokażecie jakie pakiety zainstalowaliście, pokażecie istotne pliki i co w nich warto zmienić, uruchomicie istotne komendy, pokażecie jak to działa, jak to testujecie etc. Tzn. po wysłuchaniu, chciałbym zrozumieć co i dlaczego robimy, i umieć to powtórzyć.
Tylko w przypadku zadań o pakietach:
Można zamienić "przygotowanie prezentacji" na "przygotowanie dokumentu-ściągi który to opisuje".
"Dokument" wyślemy do wszystkich w naszej grupie pracowni, i wywiesimy publicznie na stronie naszej pracowni, więc ma być dobry :) Ma być elegancko sformatowany (kilka stron PDF, lub ODT, lub HTML) i tak jak w przypadku prezentacji: zależy mi żeby zawierał precyzyjny opis "jak to się robi", oraz opis istotnych technicznych szczegółów (dlaczego trzeba to robić tak a nie inaczej? co nam to daje? jak tego używać, jak sprawdzić że dobrze to zrobiliśmy?). Czyli wymagam od Was trochę tekstu, ale technicznego i precyzyjnego. Nie zależy mi na żadnym wypracowaniu, ale też nie ma to być po prostu kilka linijek komend bez żadnego komentarza.
Można też zrobić zarówno prezentację jak i przygotować elegancki dokument ją podsumowujący, w takim wypadku dostajecie dodatkowo 5-10 punktów.
Kto pierwszy ten lepszy. Kto chce przygotować dany temat, proszę deklarować się najpierw mailem.
Tematy prezentacji (dokładne ilości punktów zależą od jakości prezentacji i/lub dokumentu):
(15-20 punktów; temat już zajęty - AdZa) Opowiedz jak tworzyć pakiety Debiana (pliki .deb). Jest elegancka dokumentacja całego procesu w "Debian New Maintainers' Guide", strona Wikipedii o deb też zawiera całe mnóstwo linków w sekcji "External links".
Oczywiście nie trzeba opowiedzieć o wszystkim, wystarczy nam informacja jak spakietować prosty program który
Przede wszystkim chcemy nauczyć się jak zrobić pakiet żeby dany program dało się elegancko instalować/usuwać z systemu. Lista zagadnień o których można wspomnieć (można potraktować ją nieco swobodnie, niektóre punkty można pominąć, a inne rzeczy dodać; przypuszczalnie nie ma szans zdążyć o wszystkim poniżej opowiedzieć w ciągu 20 minut).
/usr/local, /opt?
Binarki do /bin czy /usr/bin?
Dane niezależne od platformy gdzie? Dane zależne od platformy gdzie?
Gdzie to jest udokumentowane?
{pre,post}{inst,rm}, kiedy którego używać.
(10-20 punktów) Nic tylko ten Linux i Linux. Chociaż to pracownia z Linuxa, myślę że nie od rzeczy jest wspomnienie o innych Unixach, zwłaszcza że wiele zagadnień działa tak samo lub podobnie (często używając tych samych, lub innych ale prawie-kompatybilnych, programów i bibliotek). Np. o FreeBSD. Jeśli ktoś chce zaszaleć, o Mac OS X. Dla bardzo szalonych, o Cygwin - środowisku Unixowym pod Windowsem. Byłoby fantastycznie gdyby ktoś opowiedział coś o GNU Hurd.
O różnych rzeczach, o różnej trudności można tu opowiedzieć — o ich systemach pakietów (binarnych, ze źródeł, instalatorów), o bundle pod Mac OS X, o specjałach w kernelu FreeBSD (jaile) i o rewelacjach w kernelu GNU Hurd etc.
Najlepiej napiszcie mi wcześniej mniej-więcej jakie zagadnienia z danego systemu chcecie poruszyć.
Opowiedz krótko
Inne zagadnienia? Śmiało, proszę proponować.
Prezentacje trzeba zrobić 13 lub 20 stycznia, w czasie pracowni. Natomiast dokumenty-ściągi można przygotować do końca sesji egzaminacyjnej, 3 lutego. Tylko proszę nie czekajcie na ostatni dzień z nadsyłaniem ostatnich dodatkowych zadań, zwłaszcza jeśli od tego zależy Wasze zaliczenie — mogę mieć uwagi do Waszego dokumentu i chcieć żebyście je poprawili. Więc przyślijcie mi PDFy/etc. co najmniej kilka dni wcześniej żebym zdążył je ocenić i żebyście ew. zdążyli je poprawić.
Bawimy się maszynami wirtualnymi wykonując zadania z listy wykładowcy. Wszystkie zadania za 2 punkty, razem 12 punktów do zdobycia.
Tą listę trzeba wykonać "na miejscu", w trakcie zajęć w sali 7 — nie widzę sposobu jak ocenić większość zadań e-mailem... A zadania są fajne, i przydadzą nam się do późniejszych zabaw, więc warto je wykonać. Kto nie może być obecny 16 grudnia na zajęciach, będzie jeszcze mógł te zadania wykonać na następnych zajęciach.
9 grudnia kontynuujemy listę, robimy zadania 11-16. Wbrew obietnicom, nie dopisałem żadnego nowego zadania — czyli robimy zadania 11-16 w/g listy wykładowcy, poza zadaniem 13 którego zmieniona wersja jest poniżej. Dodatkowe uwagi do zadań 11 i 16 poniżej.
Zadania z 2 grudnia (1-10) proszę przysyłać mi mailem, w tradycyjnym terminie do następnego piątku (9 grudnia).
Robimy te same zadania co grupa wykładowcy, z drobnymi modyfikacjami:
Notki do zadania 11: w treści zadania nie napisano dokładnie jak ograniczamy środowisko procesu — ostatecznie, pozostawiam to do Waszego wyboru, po prostu odseparujcie je tak jak umiecie.
Co najmniej, trzeba zmienić zmienne środowiskowe.
Można zerknąć np. na man sudoers po opis env_reset
po listę zmiennych środowiskowych które (po ew. modyfikacji na coś
przewidywalnego) warto przekazać uruchamianemu procesowi.
Całą resztę zmiennych środowiskowych można skasować,
tzn. niech uruchamiany proces ich nie zna — see man env.
Do odseparowania plików zapewne chcemy uruchamiać proces
jako inny użytkownik albo nawet wewnątrz chroota,
ale na zabawę z nimi nie mamy uprawnień w sali 7.
Więc chwilowo odkładamy zabawy z nimi na listę w przyszłości.
Na potrzeby tej listy, po prostu "separujemy pliki" tak jak umiemy
— np. zmieniamy aktualny katalog na coś ustalonego.
Szczerze mówiąc, nie znam mądrego sposobu na odseparowanie procesu
od naszych plików który nie wymagałby praw roota (no może poza
zabawami typu libsandbox, ale to nie na tym wykładzie) —
ale może ktoś mnie zaskoczy :)
Zadanie 13 (skracanie logów systemowych) zamieniamy na coś innego (ale co służy do tego samego celu).
Oto nowe zadanie 13: naucz się konfigurować logrotate:
Zmień domyślną konfigurację logrotate, aby komunikaty syslog (lądujące w plkach /var/log/syslog*) były dłużej przechowywane.
Zainstaluj jako zadanie crona skrypt który co minutę (lub kilka minut) dopisuje nową linijkę do jakiegoś pliku (np. $HOME/my.log. Linijka ma zawierać aktualny czas i jakąś użyteczną informację o systemie, np. aktualną ilość miejsca na głównym dysku (np. z df) lub zajętość CPU lub pamięci (można wyciągnąć łatwo np. grepem z odpowiednich plików w /proc/). Zależy nam żeby plik $HOME/my.log ciągle rósł.
Napisz zadanie crona które wywołuje logrotate z odpowiednio stworzonym plikiem konfiguracyjnym, tak aby plik $HOME/my.log nie rósł za bardzo. Zbyt długa zawartość ma być przenoszona do plików z .1, .2 etc. w nazwie, skompresowanych gzipem, tak jak to robi logrotate.
Notka do zadania 16: to powinno być wykonalne na dowolnym Linuxie, odpowiednie polecenia pod Debianem są w pakiecie acct (GNU Accounting Utilities), mam nadzieję że pod dowolną dystrybucją Linuxa znajdziecie podobny pakiet. Nie sprawdzałem czy są zainstalowane w pracowni w sali 7.
Więc nie potrzebujecie dostępu do "hery" (o ile w ogóle wiecie co to jest :) żeby wykonać to zadanie.
Zadań 17 i 18 nie robimy (być może zrobimy je za tydzień, być może coś podobnego, a być może coś zupełnie innego :).
Czyli mamy 16 zadań, wszystkie za 1 punkt.
Update: podzielmy tą listę na dwie pracownie. Uznajmy że 2 grudnia do zrobienia były zadania 1-10 z listy, czyli te zadania 1-10 można przysyłać do najbliższego piątku (9 grudnia). Na następnej pracowni zajmiemy się zadaniami 11-16.
Szyfrowanie, GPG.
Notka 2011-12-01: Przedłużamy nieznacznie termin nadsyłania zadań mailem z tej listy: do końca niedzieli (4 grudnia).
gpg dowolny plik.
Przyślij mi polecenia gpg których użyłeś do szyfrowania / deszyfrowania.
my_secure_data.
Skrypt wywołany jako my_secure_data --add blahblah
powinien dopisać linijkę blahblah do zaszyfrowanego
pliku. Tzn. implementacja powinna deszyfrować plik, dopisać do niego
odpowiednią linijkę, po czym szyfrować go ponownie.
Jest dopuszczalne żeby skrypt pytał o hasło nawet 3 razy.
Pytanie o hasło pozostawiamy standardowym mechanizmom gpg (i gpg-agent
pod spodem, see man gpg-agent jeśli jesteś ciekaw).
Skrypt wywołany jako my_secure_data --find blahblah
powinien wypisać linijki zawierające blahblah w zaszyfrowanym
pliku. Tzn. implementacja powinna deszyfrować plik i przepuszczać go
przez grep.
Skrypt wywołany jako my_secure_data --delete blahblah
powinien kasować linijki zawierające blahblah w zaszyfrowanym
pliku (dokładnie te same linijki które byłyby wypisane przez
my_secure_data --find blahblah).
Hint: grep --invert-match może być pomocny.
Nazwa zaszyfrowanego pliku powinna być pobierana ze zmiennej środowiskowej
MY_SECURE_DATA. Jeżeli taka zmienna nie jest ustawiona,
defaultowo używany ma być plik $HOME/.my_secure_data.
Żeby łatwo sobie z tym poradzić w skrypcie, być może warto użyć
konstrukcji ZMIENNA=${...:-...}, przejrzyj
referencję
basha o "Shell Parameter Expansion".
Jeżeli Twoja implementacja --add lub --find musi
tworzyć plik tymczasowy z niezaszyfrowaną zawartością
na dysku, to upewnij się że 1. zawsze jest on kasowany
(nawet w przypadku dziwnych błędów innych poleceń),
2. jest kasowany przez shred, nie zwykłe rm,
3. ani przez chwilę nie istnieje na dysku odszyfrowany plik
który mogliby odczytać inny użytkownicy (np. poprzez umask).
(+1) dodatkowy punkt jeżeli napiszesz skrypt tak żeby nie używał tymczasowego pliku z niezaszyfrowaną zawartością na dysku, wszystko przekazywał przez pipes. Jest dozwolone przechowywać tymczasowy plik z zaszyfrowaną zawartością na dysku przez chwilę (chociaż i tego można uniknąć).
(4) Szyfrowanie symetryczne ma sens kiedy sekretny plik jest do własnego użytku — jakieś nasze tajne sekrety etc. Szyfrowanie symetryczne jest kiepskie do komunikacji z innymi osobami — mielibyśmy problem "jak przekazać im nasze hasło w bezpieczny sposób". Dlatego wymyślono...
Kryptografię asymetryczną, czyli szyfrowanie do kogoś i podpisywanie przez nas. Obie procedury nie wymagają przekazywania sobie żadnych sekretów — przekazujemy sobie tylko klucze publiczne. Klucze publiczne, jak sama nazwa wskazuje, nie są tajne i w praktyce rozgłaszamy je wszystkim, np. umieszczając je na swojej stronie WWW lub wysyłając do specjalnych key-serwerów. Za pomocą mojego klucza publicznego możecie zaszyfrować wiadomość do mnie, albo sprawdzić podpis pod moją wiadomością. Tylko ja posiadam pasujący klucz prywatny, który pozwala mi deszyfrować wiadomości przeznaczone do mnie i podpisywać moje wiadomości.
Zadanie: wygeneruj sobie taką parę kluczy (publiczny + prywatny) do komunikacji, i wyślij do mnie 1. wiadomość która jest podpisana przez Ciebie, 2. wiadomość która jest zaszyfrowana tak żebym tylko ja umiał ją odczytać. Przez wiadomość rozumiem zaszyfrowany/podpisany e-mail (tzn. szyfrowanie/podpisywanie będzie musiało być zintegrowane z Waszym klientem pocztowym). Ew. można też zwyczajnie załączyć zaszyfrowany/podpisany plik tekstowy do "normalnego" e-maila. Można to załatwić jedną wiadomością (jednocześnie zaszyfrowaną i podpisaną), można dwie osobne.
Żeby szyfrować do mnie, będziecie potrzebowali znać mój klucz publiczny GPG — patrz notki na samym dole mojej strony domowej. Ja też będę potrzebował znać Wasz klucz publiczny żeby sprawdzić Waszą wiadomość — możecie przekazać mi swój klucz publiczny w dowolny sposób, najlepiej: po prostu wrzućcie go poprzez gpg na jakiś keyserver.
Zadanie jest o tyle dziwne że nie wymagam od Was zrobienia
go bezpośrednio przy pomocy poleceń gpg
(chociaż jak najbardziej można). Chciałbym Was raczej zachęcić
do skonfigurowania Waszego ulubionego klienta pocztowego,
albo chociaż menedżera plików, tak żebyście
umieli wygodnie wysyłać i odbierać maile/pliki podpisywane/szyfrowane.
Jeżeli znajdziecie sobie jakieś wygodne GUI do wszystkich operacji
(generowania kluczy, podpisywania/szyfrowania/deszyfrowania,
wrzucania kluczy na keyserver etc.) — to tym lepiej dla Was.
Dla mnie Thunderbird
z Enigmail
działa cool, ale zapewne znajdziecie inne opcje.
Jest seahorse, wygodny do zarządzania kluczami program GUI pod GNOME,
i pakiet seahorse-plugins pod Debianem/Ubuntu, zapewniający
trywialne menu kontekstowe w przeglądarce plików GNOME (nautilus)
z komendami do szyfrowania/etc.
Jest wiele innych wygodnych programów.
Nie zależy mi (przynajmniej nie w tym zadaniu :)
żeby Was męczyć z rozpoznawaniem jak takie podpisywanie/szyfrowanie
jest robione "pod spodem", tzn. za pomocą argumentów gpg
w linii poleceń. Chociaż wcale nie są takie straszne!, argumenty
gpg zostały zazwyczaj całkiem przemyślane żeby wygodnie dało
się wszystko zrobić z linii poleceń.
Więc zawsze można poradzić sobie bezpośrednio przez czyste gpg,
jeżeli po prostu nie znajdziecie satysfakcjonujących Was programów GUI.
Zanim wyślecie do mnie maile, proszę upewnijcie się że to działa — możecie np. próbować wysyłać maile do samych siebie i testować.
(1) Stwórz klucze ssh do logowania się na zdalny host bez hasła.
(2) (Bonusowe. Wymaga uprawnień root na systemie —
zapewne niewykonalne na komputerach na pracowni.)
Pobaw się zaszyfrowanym systemem plików pod Linuxem.
See np.
cryptsetup i LUKS
pod Debianem. Google "linux encrypted file system", "debian encrypted file system"
dają sporo wyników.
Doprecyzowanie później: Jako rozwiązanie, należy wysłać coś konkretnego pokazującego że się tym pobawiliście. Można napisać mi komendy których użyliście (lub link do strony gdzie są one opisane, jeżeli postępowaliście precyzyjnie w/g niej), oraz opisać w 2 zdaniach:
doświadczenie z szybkością pracy na takim zaszyfrowanym systemie plików (np. jak szybko duże pliki są kopiowane do/z takiego systemu? czy po skopiowaniu dużego pliku na zaszyfrowany system plików udmontowanie zaszyfrowanego systemu trwa długo?),
doświadczenie z zakładaniem takiej partycji (czy wygodnie? czy jest możliwość zaszyfrowania istniejącej partycji, czy trzeba zakładać nową zaszyfrowaną i dopiero na nią kopiować? być może, jeśli wiecie: czy jest ona obsługiwana tylko pod Linuxem, czy może jest szansa na zobaczenie jej także pod innymi OSami?).
Mamy dwa piątki pod rząd (17 i 18 listopada), czyli powinniśmy zrobić coś wartego dwie listy zadań. I akurat tak się złożyło że niniejsza lista 7, z X Windows, wyszła mi trochę dłuższa — w sumie za 24 punkty.
(Dla osób przysyłających rozwiązania mailem: niektóre z tych zabaw trochę trudno ocenić przez maila, są naprawdę przeznaczone do wykonania na pracowni. Jeśli wysyłacie rozwiązania mailem, upewnijcie się że wysyłacie mi raport komend które wykonaliście, i odpowiedzi na wszystkie pytania (?) w treści zadania.)
Trochę podstawowych zabaw z xterm.
Zamiast xterm można też wykonać je z innym emulatorem terminala,
jak gnome-terminal (domyślny pod GNOME) lub konsole
(domyślny pod KDE)
— wszystko powinno być wykonalne (prawie) tak samo.
W każdym przypadku, man xxx powinno zawierać wszystkie
potrzebne Wam informacje.
top?top -d 0.1 (top którego wynik
jest odświeżany częściej)?for F in *.txt; do echo $F; done — for
nie jest przecież normalnym programem, to specjalne polecenie
wbudowane w język basha). Jak uruchomić program terminala
żeby wykonał takie polecenie? (hint: bash ma opcję -c).Uruchom i pobaw się chwilę xev.
Ten program wyświetla trywialne okienko, a na wyjściu pokazuje
zdarzenia które "widzi" powłoka graficzna, tzn. to co serwer X
(obsługa i/o, czyli rysowanie na monitorze, obsługa klawiatury i myszki etc.)
wysyła do klienta X (czyli "normalnego" programu jak xterm czy firefox czy właśnie xev).
Najlepiej uruchomić xev w terminalu, i obserwować
na bieżąco jakie zdarzenia są rejestrowane kiedy robimy cokolwiek z naszym
okienkiem.
(1) Jakie numery przycisków (w/g X Windows) ma Twoja myszka?
Wykonaj eksperyment 1: przesuń kursor myszy do środka okienka programu xev, po czym przesuń go poza okienko xev. Obserwuj jakie zdarzenia są rejestrowane. Teraz eksperyment 2: przesuń kursor myszy do środka okienka programu xev, przyciśnij klawisz mysz (np. lewy), i trzymając przyciśnięty klawisz myszy przesuń kursor myszy poza okienko xev. Co się zmieniło?
To co się stało nazywa się "mouse capture". Dlaczego ma to sens? Otwórz GIMPa, utwórz w nim dwa okienka z obrazkami, ustaw okienka obok siebie. Teraz zacznij malować pędzlem po lewym okienku: wybierz narzędzie GIMPa pod P, i zwyczajnie wciśnij lewy przycisk myszy żeby mazać po obrazku. Trzymając cały czas wciśnięty lewy klawisz myszy, przesuwaj kursor ponad okienkiem z 2-gim obrazkiem, i z powrotem ponad 1-wszym obrazkiem.
Proste zabawy z xmodmap:
Uruchom xkill, zabij dowolne otwarte okienko.
Uruchom xwininfo, zbadaj dowolne otwarte okienko.
(2) Zapoznaj się z programami xwd i xwud.
Zrób zrzut ekranu całego pulpitu, zrób zrzut ekranu konkretnego
okna poprzez id i poprzez name. Sprawdź że obrazy są Ok poprzez xwud.
Skonwertuj zrzut (obrazek w formacie "X Window Dump image data")
do jakiegoś "normalnego" formatu obrazka, jak JPG lub PNG
(hint: convert, xwdtopnm).
Dla osób przysyłających rozwiązania mailem: opisz polecenia / ich wyniki które wykonałeś.
Zabawa w serwer X "zrób-to-sam". To co widzimy po normalnym zalogowaniu się to dużo więcej niż tylko "serwer X". W tym zadaniu postaramy się trochę zobaczyć od podstaw gdzie jest "serwer X", a gdzie jest "window manager".
(1) Pochodź po konsolach Linuxa (Ctrl+Alt+Fx z graficznej do dowolnej innej, także działa Alt+Fx z tekstowej do dowolnej innej). Jak z konsoli (tej normalnej konsoli Linuxa, np. po Alt+F1) uruchomić program graficzny (jak xterm czy gimp czy firefox) który ma pokazać się na powłoce graficznej?
(2) (Wyślij mi raport wykonanych poleceń) Postaw własny "goły" serwer X, i "ręcznie" uruchom w nim window managera:
X :1.
Przełącz się na niego. Trochę pusto, prawda? :)
gnome-session, na Twoim nowym serwerze X.
Przełącz się na swój nowy serwer X —
zwróć uwagę że nie tylko cały pulpit został skonfigurowany,
ale także xterm został "opakowany" w normalną ramkę i tytuł.(2) Przetestuj różne window managery.
Szukanie "window manager"
w opisach pakietów Debiana/Ubuntu zwróci całą masę wyników, przetestuj
niektóre z nich. Jest GNOME (gnome-session), KDE (startkde),
Xfe (xfce4-session) ze znanych i nowoczesnych.
Jest ion,
awesome,
rat poison
i inne z trochę przekornych i minimalistycznych.
W pracowni 7 jest blackbox.
I jest wiele innych, see notatki z wykładu.
Pobaw się co najmniej dwoma window managerami innymi niż standardowe GNOME i KDE. Przyślij screenshoty i 1-2 zdaniowe opinie o nich.
(2) (Wyślij mi plik .xinitrc) Pobaw się xinit.
See man xinit, w skrócie xinit to jakby skrót do tego
co powyżej zrobiliśmy ręcznie: uruchamia serwer X, i programy w środku.
Domyślnie, programy do uruchomienia są czytane z ~/.xinitrc.
Stwórz swój plik ~/.xinitrc który uruchamia na pulpicie
kilka ulubionych programów (na odpowiednich miejscach,
za pomocą --geometry etc.) i uruchamia Twojego ulubionego window managera.
Przy logowaniu, zwróć uwagę na wybór sesji. Zazwyczaj jest tam jakaś wersja "Custom X session" etc. która w skrócie sprowadza się do uruchomienia xinit — to właśnie jest przeznaczone dla osób które umieją sobie same taki plik napisać.
Zobacz np. do /etc/X11/Xsession, /etc/X11/Xsession.d/,
/etc/gdm/Sessions/ po przykładowe "pełne" skrypty do konfigurowania
sesji.
Pobaw się Xnest, lub jego nowocześniejszą
alternatywą Xephyr.
Nie mam chwilowo pomysłu na jakieś zadanie
z tego, ale bardzo chcę żebyście go uruchomili —
bo bywa przydatny i wygodny. Np. powyższe zadanie ("goły" X server)
można było wykonać nieco przyjemniej za pomocą Xnest / Xephyr,
nie trzeba było przeskakiwać między konsolami.
Zabawy z uruchamianiem innych serwerów X, i łączeniem się z innymi serwerami X:
Tylko że to nie jest bezpieczne — protokół X nie jest szyfrowany w żaden sposób.
Tak, to zadziała w pracowni 7, tylko zwróć uwagę na zabezpieczenia — domyślnie przecież system nie pozwoli Ci otworzyć okienka kiedy ktoś inny jest zalogowany. Jak łatwo pozwolić wszystkim otwierać okienka na swoim pulpicie? Jak to zrobić porządniej? (hint: xhost, może xauth).
(1) Zaloguj się ssh na komputerze obok, na którym działają X. Będąc w środku sesji ssh, uruchom program graficzny (jak xterm) który pojawi się na komputerze obok.
(Uwaga: tego ćwiczenia, ani poprzedniego, nie
wykonacie logując się ssh na
serwer michalis.ii.uni.wroc.pl, bo na tym serwerze
w ogóle nie mamy serwera X-ów.)
(1) Uruchamianie zdalne programu w ten sposób jest zazwyczaj
nie tym czego chcemy... Często chcemy żeby program działał na komputerze zdalnym,
ale pokazywał się na lokalnym! Pobaw się ssh -X,
które pozwala programom uruchamianym zdalnie
(czyli na komputerze zdalnym przez ssh) na korzystanie z
naszego (lokalnego) serwera X, czyli z naszego monitora,
myszki, klawiatury etc.
Żeby zrozumieć jak to działa —
DISPLAY
w obu przypadkach?
(To ćwiczenie uda się Wam wykonać zarówno na pracowni 7,
jak i na serwerze michalis.ii.uni.wroc.pl.
Na zdalnym komputerze nie musi być włączony ani nawet zainstalowany
serwer X, w końcu nie chcemy korzystać z klawiatury/monitora
zdalnego komputera. Wystarczy że na zdalnym komputerze są
klienci (jak xterm). Na michalis.ii.uni.wroc.pl
serwer ssh ma konfigurację (w /etc/ssh/sshd_options):
X11Forwarding yes X11DisplayOffset 10
)
Pobaw się udostępnianiem pulpitu przez VNC (tylko do oglądania, do oglądania i kontroli). Prosta konfiguracja serwera VNC jest w System->Preferences->Remote Desktop (jeżeli używacie GNOME). Prosty klient jest w Applications->Internet->Remote Desktop Viewer.
To niestety nie zadziała w 7 o ile patrzyłem — są zamknięte porty do zabaw z vnc, trzebaby kombinować z tunelowaniem. Więc zadanie jest trochę opcjonalne, bez punktów — po prostu polecam poświęcić 5 minut żeby zobaczyć że VNC jest fajne i działa :)
VNC to zazwyczaj bardziej wydajna opcja niż ssh -X.
Pliki desktop, baza MIME, standardy XDG. Projekt freedesktop.org (wcześniej znany jako XDG, X Desktop Group) zajmuje się tworzeniem różnych standardów związanych z open-source'owymi desktopami zbudowanymi na X Windows. Wiele elementów wspólnych dla GNOME, KDE i innych środowisk graficznych powstało poprzez uzgadnianie i implementowanie różnych standardów właśnie w ramach XDG. Pobawimy się kilkoma rzeczami związanymi z XDG w tym zadaniu:
(1) Typ MIME to nazwa określająca format pliku. Typ MIME jest stosunkowo czytelny dla ludzi, a jednocześnie jest krótki i przyjemny do przetwarzania przez programy. Oryginalnie wymyślono go na potrzeby formatu e-mail MIME, ale jego użycie rozrosło się na różne standardy Internetowe i open-source'owe desktopy.
Użyj xdg-mime żeby zorientować się
jaki jest typ MIME wybranego pliku. Użyj xdg-mime żeby
zorientować się jaki program jest domyślnie przypisany do obsługi
danego pliku. Użyj xdg-open żeby zwyczajnie otworzyć plik
przy pomocy domyślnego programu.
(1) Stwórz trywialny skrypt który pobiera jako opcjonalny argument nazwę pliku i... no, robi na tym pliku cokolwiek. Ważne jest żeby skrypt zawsze (bez względu na to czy podano jako parametr nazwę pliku czy nie) otwierał okienko.
Do wyboru:
Załóżmy że mamy plik z obrazkiem (jpg, png etc.).
Użyj display z ImageMagick żeby wyświetlić
podany obrazek z gamma correction 2.2.
Lub żeby wyświetlić dany obrazek za pomocą 2 kolorów: czarny i biały.
Załóżmy że mamy plik dźwiękowy (ogg, wav, mp3 etc.).
Użyj play z pakietu SoX żeby odtworzyć dany plik,
dodając jakiś efekt dźwiękowy (np. znacznie zwiększając
lub zmniejszając bass lub treble naszego
pliku; man play powie wszystko).
Chcemy żeby program był programem GUI. Więc nasz skrypt
ma uruchamiać play w środku terminala (xterm lub
gnome-terminal lub inny),
tak jak się nauczyliśmy w zadaniu 1. Upewnij się że skrypt coś
wyświetla i czeka (nie tylko miga oknem terminala)
nawet kiedy uruchomimy go bez parametru, np. Proszę podać plik (i czeka na enter).
Upewnij się że skrypt może być uruchamiany jak normalny program, bez podawania nazwy shella explicite — czyli pamiętaj o shebang i chmod.
Teraz, w ramach zabaw, wyobrazimy sobie że nasz skrypt to wspaniały i użyteczny program GUI który właśnie stworzyliśmy :) I spróbujemy zainstalować ten program w menu, i skojarzyć go z odpowiednim rozszerzeniem plików, w "ręczny" sposób.
(Nawiasem mówiąć: łatwy (ale nieedukacyjny :) sposób dodania pliku do menu to edytor Menu Główne w preferencjach, a skojarzenie pliku z programem mamy przez menu kontekstowe kiedy klikniemy na plik prawym klawiszem myszy w przeglądarce plików. Ale nie chcemy tak łatwo.)
(2) Stwórz w edytorze tekstowym plik moj_wspanialy_skrypt.desktop
który opisuje jak Twój program się nazywa i gdzie powinien znaleźć się
w menu.
Prosty opis pliku
.desktop, inny opis pliku .desktop (też z dokumentacji GNOME),
specyfikacja XDG opisująca pliki .desktop,
lista kategorii — to determinuje miejsce naszego programu w menu.
Dodaj swój plik do /usr/share/applications lub
~/.local/share/applications — Twój program powinien
automatycznie pojawić sie w odpowiedniej kategorii menu.
Upewnij się że możesz uruchamiać swój program poprzez menu.
Zazwyczaj, najlepiej wrzucić swój program na ścieżkę (PATH)
i nie pisać już ścieżki w pliku .desktop.
(2) Załóżmy że nasz program obsługuje swój własny, specjalny
format plików. Nazwijmy go Mój Wspaniały Format Pliku,
rozszerzenie .mwfp (jaja sobie robię, nazwijcie
go jak chcecie :). Wymyśl też nazwę typu MIME swojego pliku,
np. image/x-mwfp lub audio/x-mwfp.
Będziecie chcieli zmienić nazwę kilku swoich
przykładowych plików (obrazków lub plików dźwiękowych, w zależności
od tego którą opcję wybraliście poprzednio) tak żeby miały właśnie
takie rozszerzenie.
Teraz chcemy powiedzieć naszemu desktopowi dwie rzeczy:
.mwfp powinny być rozpoznane
jako typ MIME image/x-mwfp lub audio/x-mwfp.
image/x-mwfp lub audio/x-mwfp
powinny być domyślnie otwierane przy pomocy naszego wspaniałego skryptu.
Żeby to zrobić:
Stwórz plik XML opisujący dany typ MIME.
Prosty przykład pliku XML opisującego typ
MIME,
pełna specyfikacja
XDG formatu typu MIME.
Masę przykładów znajdziecie w /usr/share/mime/
na Waszym systemie.
Tak stworzony plik należy zarejestrować przez odpowiednie
wywołanie xdg-mime.
(Alternatywnie, można też skopiować go do
~/.local/share/mime/packages/ (lub /usr/share/mime/packages/),
i wywołać update-mime-database ~/.local/share/mime.
Ale to stara metoda.)
Dopisz do swojego pliku .desktop odpowiednia linijkę MimeType
która mówi że dany program obsługuje odpowiedni typ MIME.
Trzeba jeszcze wykonać update-desktop-database
na katalogu gdzie jest Wasz plik .desktop
(jak ~/.local/share/applications) żeby system załapał
skojarzenie programy z typem MIME.
Upewnij się że to działa. Być może będziesz musiał się wylogować/
zalogować ponownie (chociaż zabicie procesów gnome-panel i nautilusa
też może zadziałać). Kiedy klikniesz dwa razy w przeglądarce
plików na pliku z rozrzeniem .mwfp — powinien
automatycznie uruchomić się Twój skrypt.
Lista do przysłania mailem, do następnego piątku (18 listopada). Lista w sumie za 6 punktów — łatwa.
(2) Prosta zabawa z read (help read): napisz skrypt
który czyta po kolei liczby (jedna liczba w jednej linii)
ze standardowego wejścia, i po każdej liczbie
wypisuje dotychczasową sumę liczb.
(4) Zrób
zadanie 1 z tej listy,
z małą modyfikacją (see below).
Upewnij się że Twój skrypt pick działa dla opisanych przykładów.
Hint: może przyda się jakaś opcja dla read żeby nie czytać
całej linii do jednej zmiennej, tylko jej część (bo np. echo *.png
to cała 1 linia ze spacjami w środku).
Tylko że zrób je z małą modyfikacją: pytaj użytkownika
o potwierdzenie (czy włączyć czy nie dany element listy)
używając gdialog lub zenity
(okienka dialogowe GUI które można wygodnie wywołać i obsłużyć ze skryptów).
W ten sposób zachęcam Was do poznania gdialog lub zenity,
co może jest dobrym wstępem do zabaw z X Windows w następnym tygodniu.
I przy okazji obchodzimy problem "jak spytać użytkownika o potwierdzenie
kiedy stdin jest zajęte" (co możnaby też rozwiązać czytając read'em z stderr
albo wręcz z tty, ale to brudne zabawy i nie chcę Was do nich popychać).
Pamiętaj, poza samym skryptem pick, wysłać też proponowaną
kombinację poleceń ps, pick i kill.
4 listopada nie będzie nowej listy zadań (skoro nie było nowego wykładu 1 listopada). W zamian za to, 11 listopada (święto niepodległości) pojawi się nowa lista zadań, do rozwiązania w domu i przysłania mi mailem (w ciągu 7 dni).
Czyli: przychodzić na pracownię nie ma potrzeby, ani 4 listopada, ani 11 listopada. Ale, żeby się zupełnie nie rozleniwić, pojawi sie tutaj nowa lista (może za full 10 punktów, może za mniej) w okolicach 11 listopada.
(4) Napisz skrypt który za pomocą sed przetwarza prosty podzbiór formatu HTML na format MediaWiki.
Przykładowy plik w formacie HTML.
Notka: nie jest to w pełni poprawny HTML, bo nie zawiera nagłówków ani tytułu — różne wersje HTMLa mają różne wymagania, ale co najmniej <title> jest zawsze wymagany; ale nie przejmujemy się tym w tym zadaniu.
MediaWiki jest używane chociażby przez Wikipedię, można zobaczyć krótką instrukcję składni MediaWiki i kompletną instrukcję składni MediaWiki oraz pobawić się w sandboxie (piaskownicy) Wikipedii.
Notka: MediaWiki de facto dopuszcza niektóre tagi HTMLowe (jak <b> lub <i>). Ale my sobie na to nie pozwalamy: konwertujemy wszystkie znaczniki HTMLowe do odpowiednich "tradycyjnych" znaczników wiki, więc np. <b>bold</b> zamieniamy na '''bold'''. (Reason: Inne silniki wiki nie są tak liberalne.)
Nie wymagamy pełnego konwertera (HTML nie jest taki prosty, i nikt nie sugeruje że przetwarzanie go sedem jest rozsądne na dłuższą metę :). Ale Wasz skrypt musi poradzić sobie z prostymi dokumentami podobnymi do przykładowego HTMLa, używającymi takich znaczników. Tam gdzie w przykładowym HTMLu jest znaczek początkowy i końcowy na tej samej linii (np. <a...> i </a>) tam możecie założyć że będą one zawsze na tej samej linii.
Większość zamian zapewne jest trywialna, poza zamianą linków gdzie będziecie musieli nieco rozumieć z wyrażen regularnych seda. W wersji eleganckiej, możemy chwycić cały link <a ...>...</a> jednym wyrażeniem regularnym, i zamienić go na [http://xxx yyy].
Polecam testować swoje rozwiązania wklejąjąc wynik Waszego skryptu (np. na przykładowym HTMLu) do sandboxa Wikipedii.
(Pomysł na zadanie i kawałek tekstu stąd, chociaż pozmieniałem sporo.)
(Update w piątek wieczorem: w przykładzie HTMLa były listy unordered i ordered. Ale wyrażeniami regularnymi nie da się (przynamniej nie w łatwy i ogólny sposób) rozróżnić takie listy i zamienić je odpowiednio na format MediaWiki. Więc uprościłem przykład: mamy tylko listy unordered.)
(6) Mamy dany prosty plik z punktacją studentów za trzy listy zadań. Tzn. każdy z wierszy pliku zawiera imię, nazwisko, i 3 liczby (tyle ile było list zadań) oddzielone spacjami, każda liczba to int. Napisz skrypt w awk który dla takiego pliku tekstowego generuje tabelkę w HTMLu pokazującą punktację studentów w eleganckiej postaci.
Ponadto na końcu wiersza dla każdego studenta ma być
Ponadto na końcu tabelki ma być
Przykładowo dla takiego wejścia (polskie ogonki w UTF-8) Wasz skrypt powinien wygenerować taki wynik (zobaczcie na źródło strony aby widzieć co Wasz skrypt ma wygenerować; to jest nawet poprawny HTML).
Pobawimy się kilkoma książkami które ściągniemy ze strony projektu Gutenberg jako pliki tekstowe.
(6) Pobawimy się programem grep przetwarzając
polskie
tłumaczenie "Romea i Julii" (z projektu Gutenberg,
tłumaczenie by Józef Paszkowski, tekst w UTF-8).
Używając grep policz ile linijek
"Romea i Julii" zawiera słowo miłość
oraz ile linijek zawiera słowo śmierć.
Policz ile kwestii wypowiada Romeo,
a ile Julia. Zakładamy że każda kwestia danej postaci
jest oznaczona linijką która zaczyna się od *Romeo.* lub
*Julia.*. Pamiętaj że grep domyślnie
traktuje podane wyrażenie jako wyrażenie regularne,
a znaki jak gwiazdka i kropka mają wtedy specjalne znaczenie —
użyj backslash (albo opcji --fixed-strings) żeby się przed
tym zabezpieczyć.
Policz ile kwestii jest wypowiedzianych w całym dramacie. Jak powyżej, zakładamy że 1 kwestia = 1 linia zaczynająca się od gwiazdki + nazwa postaci (ciąg liter, być może z polskimi ogonkami) + kropka + gwiazdka. Czyli trzeba będzie napisać coś podobnego jak wyżej, tylko teraz nie można już zahardcodować nazw "Romeo" lub "Julia", zamiast tego trzeba napisać wyrażenie regularne które dopuści dowolną nazwę postaci.
Użyj grep (z odpowiednią opcją output), sort, uniq żeby wypisać wszystkie nazwy postaci które wypowiadają jakieś kwestie w dramacie. Wypisane nazwy mogą mieć gwiazdkę na początku, i kropkę+gwiazdę na końcu. Ważne żeby każdą nazwę postaci wypisać tylko raz, tzn. output ma zawierać 21 wierszy (tyle jest postaci posiadających jakiekolwiek kwestie, o ile dobrze liczę).
Ostateczne combo: skrypt z ostatniego punktu generuje nam nazwy postaci (z gwiazdkami naokoło, to nawet dobrze). Teraz możemy użyć jego wyniku np. przez for BLAH in `nasz skrypt` żeby wykonać jakąś operację na każdej nazwie postaci. Napisz skrypt który wypisze krótkie podsumowanie: dla każdej postaci, jej nazwa (z ew. gwiazdką i gwiazdką+kropką naokoło) oraz ile razy dana postać wypowiada kwestię w dramacie.
Tzn. output powinien zaczynać się jak
*Abraham.* 5 *Aptekarz.* 5 *Baltazar.* 12 ...
Notka: jak słusznie zauważyliście na zajęciach,
to zadanie można wykonać trywialnie używając uniq -c.
Ale zróbmy też wersję używając for BLAH in `nasz skrypt`
— jest ona w jakimś sensie bardziej edukacyjna,
tzn. pokazuje jak w pętli przetwarzać wynik polecenia.
Notka 2: polecenie echo ma opcję -n.
Może się przydać (chociaż można sobie też poradzić bez niej).
(4) Poczytaj krótko o Unicode, UTF-8, UTF-16, UTF-32. (Znacznie więcej informacji na angielskiej Wikipedii: Unicode, UTF-8, UTF-16, UTF-32.) Nie wymagamy żadnej znajomości szczegółów, tylko bardzo ogólne pojęcie na czym te kodowania znaków polegają, czym się różnią. Większość nowoczesnego oprogramowania na Linuxie rozmawia z Wami przez UTF-8.
Napisz skrypt który dla zadanego pliku (zakładamy że jego kodowanie
to UTF-8) wypisze: 1. jego aktualny rozmiar (dokładnie, w bajtach,
można użyć wc lub ls z odpowiednimi opcjami),
2. rozmiar po konwersji na UTF-16,
3. rozmiar po konwersji na UTF-32.
Konwertujemy plik programem iconv.
Używając swojego skryptu, wykonaj mały eksperyment: ściągnij dowolny polski tekst z projektu Gutenberg. Ściągamy naturalnie jako czysty plik tekstowy w UTF-8. Zobacz jak zmienia się jego rozmiar tego pliku kiedy przekonwertujemy go na UTF-16 i UTF-32.
Wykonaj ten sam eksperyment dla dowolnego tekstu po angielsku. Proporcje powinny być podobne jak w przypadku tekstu po polsku (notka: nawet teksty angielskie zawierają nieznaczną ilość znaczków spoza ASCII, dlatego proporcje nie będą równo x2, x4 — ale powinny być blisko).
Teraz wykonaj ten sam eksperyment dla dowolnego tekstu po rosyjsku. Jak zmieniły się proporcje wielkości (UTF-8 w stosunku do UTF-16, UTF-16 w stosunku do UTF-32).
I może jeszcze wykonaj ten sam eksperyment dla dowolnego tekstu po chińsku.
Notka: żeby statystyki dla rosyjskiego i chińskiego były najbardziej wyraźne, najlepiej najpierw otworzyć ściągnięte książki edytorem który obsługuje UTF-8 (pod Linuxem, to właściwie oznacza: dowolnym) i usunąć z nich początkową deklarację i końcową licencję projektu Gutenberg (one są zawsze po angielsku). Albo po prostu ściągać większe książki, żeby ten kawałek licencji po angielsku nie miał statystycznie żadnego znaczenia :)
Skoro wybiegliśmy zakresem materiału przed wykład, w tym tygodniu robimy sobie mały odpoczynek :) Tzn. pracowni w piątek (14 października) jako takiej nie ma, przychodzić nie trzeba. Rozwiązanie poniższego zadania należy wysłać prowadzącemu na maila, do następnego czwartku (20 października).
(3) Zapoznaj się z konstrukcją for (( exp1; exp2; exp3 )) w bashu
(uruchom help for, druga część opisu mówi o tym for).
Składnia rzeczy w środku expX to wyrażenia arytmetyczne, w skrócie konstrukcje jak
ZMIENNA++ i ZMIENNA=1+2+3 działają.
Zapoznaj się z konstrukcją if w bashu (uruchom help if).
Zapoznaj się z programem test który można też wywołać pod śmieszną
nazwą [.
(uruchom help [, help test).
Używając tych poleceń, napisz skrypt który uruchomiony raz — stworzy plik
blabla0.txt (i zakończy się). Uruchomiony drugi raz — stworzy plik
blabla1.txt. I tak dalej. Czyli: znajdujemy pierwszą wolną nazwę blabla<liczba>.txt,
i zakładamy plik o takiej nazwie (zawartość pliku dowolna, może być pusty).
Alternatywnie, zamiast for można użyć while (wtedy inkrementację
zmiennej trzeba zapewne zrobić osobnym wyrażeniem ((...))).
Ogólnie, można to napisać (krótko) na kilka sposobów, wybieramy dowolny :)
Nie przejmujemy się tutaj race condition (w teorii, inny program mógłby
podstępnie założyć plik o nazwie blabla99.txt dokładnie po tym jak
zrobiliśmy nasz test i tuż zanim założyliśmy nasz plik). Ignorujemy ten problem
tutaj, zakładamy że nasz skrypt to jedyny program na świecie który jest zainteresowany
tworzeniem plików blablaX.txt.
(2.5) Pobaw się last żeby zobaczyć kto był ostatnio zalogowany do systemu.
Znajdź w nim linijkę mówiącą o reboot systemu.
Przepuść wynik przez less żeby zobaczyć długi listing.
Przepuść wynik przez grep żeby przefiltrować.
Przepuść wynik przez head i tail żeby wybrać początek / koniec tekstu.
Zadania: odpowiednio łącząc niektóre powyższe polecenia, napisz:
(2.5) Pobaw się programem convert z ImageMagick.
Wykorzystując go, for i basename, napisz skrypt który
konwertuje wszystkie pliki .gif na pliki .png w aktualnym
katalogu.
(5) Pobaw się pakowaniem plików do tar.gz
poleceniem tar. Pobaw się sprawdzaniem sum kontrolnych plików
przez md5sum.
Pobaw się uruchamianiem poleceń na komputerze obok
używając ssh (można uruchamiać np. powyższe lasty, które zapewne
będą różne dla różnych komputerów).
Pobaw się kopiowaniem plików na komputer obok, używając polecenia
scp (kopiujcie np. do katalogów /tmp/, który w sali 7 powinien
być odrędbny dla każdego komputera).
Zadanie: Używając powyższych poleceń, napisz skrypt który przesyła katalog plików na komputer obok, kompresując go (żeby przesyłanie było szybkie) oraz sprawdzając sumy kontrolne plików (czyli zabezpieczając nas zarówno przez błędami transmisji jak i błędami kompresji):
Bonus points (+2) jeśli exit status skryptu będzie zawsze dobry, tzn. 0 jeżeli wszystko się udało (łącznie z testem sum kontrolnych) lub <> 0 jeżeli coś się nie udało.
Dodatkowe informacje:
Chodzi o to żeby komendy do rozpakowywania i sprawdzania
sum kontrolnych (co można wykonać przez md5sum -c) były wykonywane
remote, tzn. na komputerze docelowym na którym lądują pliki. Zakładamy
że zarówno na naszym komputerze jak i na komputerze docelowym są
zainstalowane podstawowe narzędzia Linuxowe, w szczególności na obu
komputerach jest zainstalowane md5sum.
Cały skrypt ma działać w pełni automatycznie. Nie chodzi mi o to żebyście pisali mi jakie komendy można wpisać — zamiast tego, nasz skrypt ma w pełni automatycznie uruchamiać odpowiednie komendy. Jedyna dopuszczalna interakcja z użytkownikiem to pytania o hasło od ssh, poza wpisywaniem własnych haseł użytkownik nic nie musi robić — skrypt sam rozpakowuje, sprawdza sumy etc.
Czyli trzeba, w ramach naszego skryptu, sprawić żeby kilka komend zostało wykonanych na komputerze docelowym, przekierowując treść tych komend na stdin dla komendy ssh. Można to zrobić różnie, polecam użycie składni heredoc w bashu (google "heredoc bash"), która wygląda jak
ssh ... <<EOF Tutaj piszemy komendy które będą wykonane na komputerze docelowym. EOF
Sumy muszą być sprawdzane tak żeby sprawdzać wszystkie pliki w środku katalogu (najlepiej rekurencyjnie, ale to akurat nie jest konieczne). Nie może być tak że dodatkowo sprawdzamy też sumy jakichś innych plików (jak tar.gz albo samego pliku sumy.txt).
O wpisywaniu haseł ssh: Nie przejmujemy się tym w naszym zadaniu. Jest Ok że użytkownik będzie pytany, być może 2-krotnie, o hasło ssh przez nasz skrypt. Kto jest ciekawy: żeby logować się przez ssh bez wpisywania hasła zazwyczaj ustawiamy klucze ssh, i robimy to zupełnie bez związku z naszym skryptem. W skrócie:
ssh-keygen -t dsa # to stworzy pliki ~/.ssh/id_dsa, ~/.ssh/id_dsa.pub
~/.ssh/id_dsa.pub lokalne do ~/.ssh/authorized_keys
zdalnego. Najłatwiej to zrobić wywołując ssh-copy-id login@michalis.ii.uni.wroc.pl.
Można też zrobić to ręcznie (np. kopiując plik przez scp, albo zwyczajnie logując
się i dopisując odpowiedni tekst do pliku Emacsem / vi / nano etc.
Ew. tworzymy najpierw katalog ~/.ssh zdalny.)
Od teraz wszystkie logowania ssh na zdalny komputer będą przebiegały automatycznie, bez pytania o hasło. Po obszerniejsze info google "ssh keys".
Możecie przysyłać rozwiązania z listy 2 mailem co najmniej do następnego piątku (14 października). Osoby które były obecne za 100% punktów, nieobecne za 2/3 punktów.
W ramach listy 1, zrobiliśmy listę 1 z wykładu. Na stronie wykładu (i w google, wikipedii) znajduje się mnóstwo informacji na temat odpowiednich komend, w szczególności see "Zapoznanie się z systemem Unix".
W ramach naszej pracowni, każdy z Was dostaje konto shellowe na
serwerze michalis.ii.uni.wroc.pl. To zwyczajny serwer którym sobie
administruję, jest tam Debian stable 32-bitowy, można go używać do zabaw
z Linuxem.
Dostajecie konto shellowe, czyli możliwość zalogowania się ssh na swoje
konto na michalis.ii.uni.wroc.pl, wrzucania dowolnych plików do swojego
katalogu (/home/nazwa_użytkownika/) i zabawy z Linuxem w środku.
Możecie nawet zrobić stronę www (~/public_html/ działa,
see notki o konfiguracji na dole głównej strony www serwera),
chociaż to raczej bez związku z naszą pracownią.
Ogólnie, dowolne zabawy (luźno) związane z naszą pracownią Linuxa są dozwolone.
Tylko proszę nie obciążać zbytnio serwera.
W szczególności przyda się Wam to do testowania rozwiązań zadania 2.3, ale myślę że także do wielu następnych zadań.
Więc kto chce (zachęcam!) proszę o przysłanie mi pożądanego loginu (musi zaczynać się od "kl") i hasła, a ja założę konto.
Na stronie wykładu są podane linki do porządnej literatury. To ja może dorzucę jedną nieporządną (za to niekiedy bardziej zabawną :) :
Tak, to jest rant, miejscami kiepski, miejscami przeterminowany, ale zawsze zabawny i może miejscami ciągle zasadny. Wartościowy rebuttal jest np. na stronie Erica S. Raymonda.
Generalnie, zadania na pracowni będą łatwe i będą zazwyczaj przygotowane do rozwiązania na bieżąco (tzn. w ciągu tych 2 godzin pracowni).
Kurs jest prowadzony dla osób zapoznających się z Linuxem, i chcących wiedzieć jak działa kilka rzeczy "od środka", jak zautomatyzować różne zadania, jak skonfigurować/jak działają etc. trudniejsze zagadnienia. Próbuję powiedzieć jednocześnie dwie rzeczy: po pierwsze, mam nadzieję że zadania będą ciekawe; po drugie, na pewno zadania będą też łatwe jeżeli macie jakieś doświadczenie z administracją Linuxem :)
Dokładną treść zadań będę ogłaszał na niniejszej stronie naszej pracowni. Będę starał się robić to wcześniej, ale niczego nie obiecuję, zwłaszcza że sam wykład jest niewiele wcześniej (wykład we wtorek, pracownia z niego już w piątek). Myślę że nie będzie to problemem w świetle 1. — zadania będą naprawdę przygotowywane do zrobienia "na miejscu", to nie będą żadne "wyzwania programistyczne" na weekend.
Przykładowe treści zadań można zobaczyć na stronie wykładu z poprzedniego roku. Zapewne na aktualnej stronie wykładu też będą pojawiały się kolejne listy, ale zapewne będą pojawiały się już po naszej pracowni. Nasze zadania będą trochę się na nich wzorowały, a trochę nie... W zależności od tego na ile Michalisowi uda się wymyślić coś ciekawszego :)
Z przykładowych rzeczy których nie widzę na listach wykładowcy, a które chciałbym żebyśmy przećwiczyli: używanie wgeta do mirrorowania (łatwe), gdzieś ispell/aspell (może później, przy okazji Emacsa), iconv (łatwe), elementarne tworzenie pakietów .deb dla Debiana, Ubuntu (trudniejsze, ciekawsze, jak będzie czas — na całą pracownię). Być może rzucimy okiem na wiresharka i ogólnie zobaczymy *absolutne podstawy* zabaw z siecią (tylko absolutne podstawy, w końcu mamy inne wykłady od porządnej nauki tego). Być może coś o 0install albo autopackage (ale zapewne nie będzie na to czasu). Na pewno przyjdzie mi do głowy więcej pomysłów w czasie semestru :)
Jeżeli jest u nas ktoś zaawansowany, to: po pierwsze, ostrzegam że trochę się ponudzi; po drugie, możemy wymyślić jakieś zaawansowane zadanie. Na przykład: przygotuj krótki opis na 2 strony i wystąpienie 20 minut na pracowni o tym jak robić pakiety RPM (Fedora i inne).
Dokładniejsze zasady?
Obecność jest nieznacznie obowiązkowa. Chciałbym zobaczyć jak rozwiązujecie te zadania (bo szczerze mówiąc zazwyczaj będą tak proste że przysłanie mi maila z rozwiązaniami nie udowodni mi czy nie skopiowaliście ich z Internetu nawet bez sprawdzania).
Umówmy się że rozwiązania zadań z list można przysyłać mi mailem, zazwyczaj przez 7 dni od pracowni, tylko za 2/3 punktów. Chyba że ktoś był obecny na pracowni i zaczął coś robić — wtedy może resztę przysłać mi mailem za 100% punktów.
Czyli obecność na pracowni nie jest taka strasznie obowiązkowa... tylko zalecana, jeśli chcecie zdobyć więcej punktów. Zobaczymy jak to się sprawdzi w praktyce.
Progi (aktualny max = 131):
(Stan aktualny na 2012-02-03.)
| Ocena | Suma | L1 | L2 | L3 | L4 | L5 | L6 | L7 | L8 | L9 | L10 | L11 | L12 | ||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| MAX | MAX | 5 | 131 | 10 | 10 | 3 | 10 | 10 | 6 | 24 | 10 | 16 | 12 | 10 | 10 |