Ponieważ dziś na własnej skórze doświadczyłem, jak dużo czasu może zająć konfiguracja tak banalnej rzeczy, postanowiłem podzielić się swoim doświadczeniem. Nie jestem specjalistą od sieci komputerowych, dlatego chętnie przyjmę krytykę i poprawię błędy, jeżeli dostrzeżecie takowe w poniższej instrukcji.

Zatem do dzieła! Zakładamy, że mamy laptopa z WiFi na interfejsie wlan0, który ma udostępnić połączenie internetowe drugiemu komputerowi, podłączonemu na interfejsie eth0 w podsieci 192.168.42.0/24 (tj. 192.168.42.0 z maską 255.255.255.0). Nasz laptop pracuje pod kontrolą Arch Linuksa.

1. Przygotowanie interfejsów sieciowych.

   Tu napotkałem na pierwszy problem w postaci NetworkManagera. Jest to program, którego z przyjemnością używam na co dzień, ale który doprowadza mnie do białej gorączki, gdy chcę użyć bardziej wymyślnej konfiguracji. Oczywiście, można by go wyłączyć:

   # /etc/rc.d/networkmanager stop

   ale co nam wtedy skonfiguruje automatycznie połączenie? Zostawiamy więc NetworkManagera, licząc się z tym, że przy każdej możliwej okazji będzie nam bruździł, wyłączając eth0. Ja to zaakceptowałem, bo połączenie miało pracować tylko kilka minut. W innym przypadku, wziąłbym się za ręczną konfigurację WiFi.

   Pozostałem jednak przy najprymitywniejszym rozwiązaniu: w konfiguracji NetworkManagera odznaczyłem opcję Łączenie automatyczne we wszystkich połączeniach przewodowych. Bez tego wetknięcie kabla do gniazda wyłączało połączenie radiowe.

   eth0 konfigurujemy ręcznie:

   # ifconfig eth0 up 192.168.42.1 netmask 255.255.255.0

2. Włączenie serwera DHCP i DNS.

   Wbrew pozorom, jest to bardzo prosta czynność. Instalujemy dnsmasq, a w /etc/dnsmasq.conf wpisujemy dwie opcje:

   interface=eth0
   dhcp-range=192.168.42.2,192.168.42.41,12h

   W razie potrzeby możemy też przypisać sztywne IP wskazanemu MAC-owi lub w ogóle wyłączyć DHCP (co jest mniej wygodne) — osoby zainteresowane znajdą stosowne informacje i przykłady w dokumentacji.

   Teraz musimy tylko uruchomić serwer:

   # /etc/rc.d/dnsmasq start

3. Uruchomienie routingu.

   Routing można włączyć jednym poleceniem:

   # echo 1 > /proc/sys/net/ipv4/ip_forward

   Niektórzy zalecają jeszcze dodanie linijki

   net.ipv4.ip_forward = 1

   do /etc/sysctl.conf, jest to chyba jednak potrzebne tylko do automatycznego startu routingu po powtórnym uruchomieniu systemu. Nas to nie interesuje, bo na co dzień nie będziemy nic routować.

4. NAT, czyli maskarada IP.

   Jest to najbardziej skomplikowany krok, wymagający grzebania się w iptables, a niezbędny do tego, by pakiety z Internetu mogły trafiać na odpowiednie IP i porty wewnątrz naszej miniaturowej sieci.

   Tutaj skorzystałem z dokumentacji Gentoo i proponuję poniższe regułki:

   # iptables -F
   # iptables -t nat -F
   # iptables -I FORWARD -i eth0 -d 192.168.42.0/255.255.255.0 -j DROP
   # iptables -A FORWARD -i eth0 -s 192.168.42.0/255.255.255.0 -j ACCEPT
   # iptables -A FORWARD -i eth0 -d 192.168.42.0/255.255.255.0 -j ACCEPT
   # iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE

To wszystko, czego potrzebujemy. Oczywiście, ręczne kopiowanie i wklejanie komend w terminalu jest niewygodne, proponuję zatem skorzystać z poniższego skryptu, okraszonego paroma dodatkowymi instrukcjami, zapożyczonymi ze wspomnianej dokumentacji Gentoo. Przyznaję się bez bicia, że rozumiem tylko część z nich, ale ufam, że zwiększają one uniwersalność i bezpieczeństwo naszego routingu.

#!/bin/bash
 
# Włączenie DHCP, DNS, NAT, routingu.
 
# Iptables i routing na podstawie dokumentacji Gentoo.
# http://www.gentoo.org/doc/pl/home-router-howto.xml
 
# Zmienne konfiguracyjne.
LAN="eth0"
WAN="wlan0"
SIEC="192.168.42.0"
MASKA="255.255.255.0"
NASZEIP="192.168.42.1"
 
# Podniesienie interfejsu.
ifconfig ${LAN} up ${NASZEIP} netmask ${MASKA}
 
# Na początek czyścimy regułki:
iptables -F
iptables -t nat -F
 
# Domyślne zasady dla pakietów nie pasujących do żadnej regułki.
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP
 
# Potem blokujemy usługi tak, aby były dostępne tylko dla sieci LAN:
iptables -I INPUT 1 -i ${LAN} -j ACCEPT
iptables -I INPUT 1 -i lo -j ACCEPT
iptables -A INPUT -p UDP --dport bootps ! -i ${LAN} -j REJECT
iptables -A INPUT -p UDP --dport domain ! -i ${LAN} -j REJECT
 
# (Opcjonalnie) pozwalamy na dostęp do naszego serwera SSH z Internetu:
#iptables -A INPUT -p TCP --dport ssh -i ${WAN} -j ACCEPT
 
# Upuszczamy pakiety TCP/UDP dla uprzywilejowanych portów:
iptables -A INPUT -p TCP ! -i ${LAN} -d 0/0 --dport 0:1023 -j DROP
iptables -A INPUT -p UDP ! -i ${LAN} -d 0/0 --dport 0:1023 -j DROP
 
# Ostatecznie dodajemy regułki dla NAT (to są najważniejsze regułki!):
iptables -I FORWARD -i ${LAN} -d ${SIEC}/${MASKA} -j DROP
iptables -A FORWARD -i ${LAN} -s ${SIEC}/${MASKA} -j ACCEPT
iptables -A FORWARD -i ${WAN} -d ${SIEC}/${MASKA} -j ACCEPT
iptables -t nat -A POSTROUTING -o ${WAN} -j MASQUERADE
 
# Informujemy jądro o chęci przekazywania IP:
echo 1 > /proc/sys/net/ipv4/ip_forward
for f in /proc/sys/net/ipv4/conf/*/rp_filter ; do echo 1 > $f ; done
 
# Uruchomienie DHCP i DNS.
# W /etc/dnsmasq.conf wystarczy:
# interface=eth0 (nasz interfejs lan)
# dhcp-range=192.168.42.2,192.168.42.41,12h (zakres IP dla DHCP)
/etc/rc.d/dnsmasq start

Mam nadzieję, że mój bardzo nieprofesjonalny poradnik mimo wszystko komuś się przyda. Jeżeli nie, to trudno, będzie przynajmniej stanowił rozwiązanie, do którego będę mógł w razie potrzeby wrócić.

Chcąc nie chcąc, uczyłem się w ramach zajęć na ETI wykorzystywać MATLAB-a, a więc przy okazji i Octave’a, do podstawowych obliczeń, szybko jednak zapominałem pokręconą składnię tego środowiska. Brakowało mi też wsparcia dla obliczeń analitycznych i możliwości pisania programów z użyciem wygodnej składni. Potrzebowałem czegoś, co pozwoli mi zarówno policzyć analitycznie całkę, z którą nie poradzi sobie mój kalkulator (Casio Algebra FX 2.0 Plus), wykreślić przebieg dowolnej funkcji, wyznaczyć DFT sygnału, jak i szybko zaimplementować jakiś własny algorytm.

Cóż więc mi pozostawało? SciPy, Maxima, Scilab? A może coś jeszcze innego? W końcu trafiłem na środowisko Sage.

Powiedzieć, że Sage jest programem matematycznym, to nieścisłość. Określić go jako zgrabne środowisko do wszelkiego rodzaju obliczeń to nadużycie, przynajmniej jeżeli chodzi o mój pogląd na piękno. Uważam, że tutaj najbardziej pasuje określenie „duct tape”. Jeżeli jesteś matematykiem lub cenisz eleganckie rozwiązania programistyczne (albo miejsce na twardym dysku…), Sage może nie wzbudzić Twojego zachwytu. Jeżeli jednak masz w sobie ducha MacGyveryzmu, Sage może okazać się świetnym rozwiązaniem wielu problemów.

Sage jest zbiorem programów i bibliotek matematycznych, takich jak Maxima, SciPy czy GSL, powiązanych Pythonem i okraszonych interfejsem CLI i dziwacznym GUI w postaci… strony WWW. Jego niewątpliwą zaletą jest darmowość i otwartość (możemy więc poznać sposób, w jaki przeprowadzane są obliczenia).

Korzystam z Arch Linuksa, gdzie Sage dostępny jest w repozytorium AUR jako sage-mathematics i sage-mathematics-bin. Pierwszy pakiet chyba nie chciał mi się kompilować, a w każdym razie miałem z nim jakiś problem, ściągnąłem więc źródła bezpośrednio ze strony programu i próbowałem sam go zbudować. Niestety, udało mi się rozwiązać tylko część problemów i w końcu zakończyłem na błędzie po dwóch czy trzech godzinach kompilacji. Zrezygnowany sięgnąłem po binarkę. Pomijając fakt, że pobrałem bodaj 400MB, instalacja przebiegła bezboleśnie. Co prawda z dysku zniknęło mi 1,2GB, ale nie byłem zdziwiony — o ile dobrze zauważyłem, Sage zawiera w sobie wszystkie niezbędne biblioteki i programy, więc mam teraz zdublowanego Pythona, Maximę, SciPy i pewnie sporo innych rzeczy…

Przejdźmy jednak do meritum. Po uruchomieniu program może krzyczeć o odpowiednie uprawnienia do katalogu konfiguracyjnego. Poniższa komenda powinna rozwiązać problem:

# chmod +x ~/.sage/ipython

Teraz odpalamy powłokę Sage’a i możemy przystępować do liczenia. Jednak od interfejsu linii poleceń znacznie wygodniejszy jest interfejs webowy, uruchamiany poleceniem notebook(). Jego działanie polega na wystartowaniu serwera WWW i przeglądarki z aplikacją webową. Jest to rozwiązanie w takim samym stopniu dziwne, co wygodne. Zgodnie z nazwą, serwuje nam ono coś w rodzaju notesów, w których możemy zapisywać obliczenia i ich wyniki. Przyznaję, że jest to bardzo intuicyjne rozwiązanie. Niestety, jesteśmy pozbawieni jakiegoś zgrabnego IDE, pozwalającego wykorzystać możliwości Sage’a do pisania dłuższych skryptów czy programów. Może to i lepiej…

Odłóżmy jednak na bok ironiczne uwagi i przyjrzyjmy się bliżej notebookowi. Screencasty pokazują bogate możliwości tego interfejsu. W szczególności należy zwrócić uwagę na tryb interaktywny — możliwość szybkiego napisania skryptu, który na bieżąco wizualizuje parametry ustawiane suwakiem, zrobiła na mnie wrażenie. To aż się prosi o wykorzystanie w szkołach czy na uczelniach!

Wykresy są całkiem estetyczne, do wypisywania wzorów można wykorzystać składnię LaTeX-a, a możliwość zapisania stanu pracy i powrotu w każdej chwili do obliczeń jest bardzo wygodna. Brakuje mi tylko skrótu klawiaturowego, który obliczałby wyrażenie bez przenoszenia do kolejnego wiersza (a tak działa Shift + Enter). Może jednak to tylko mój brak znajomości klawiszologii.

Jako podsumowanie cisną mi się na usta słowa: „To jest naprawdę świetne narzędzie, ale…”. Owych „ale” jest, niestety, sporo: od samej idei zlepienia różnych programów matematycznych, przez duże rozmiary aplikacji po dziwny interfejs. W zamian jednak otrzymujemy ogromne możliwości, pomysłowy tryb interaktywny i w sumie niegłupią ideę notebooków. Warto zatem instalować? Szczerze mówiąc, gdyby projekt Wolfram|Alpha wystartował trochę wcześniej, to pewnie nie sięgnąłbym po Sega’a, w każdym razie nie po to, by policzyć analitycznie kilka całek czy wykreślić przebieg funkcji. Myślę jednak, że warto spróbować przygody z tą aplikacją czy to przez LiveCD, czy przez instalację binarki. W mojej krótkiej recenzji nie zabrakło złośliwości, ale nie mam zamiaru usuwać w najbliższym czasie programu z dysku — czas pokaże, czy to narzędzie rzeczywiście okaże się niezastąpione.

Nut/OS jest modularnym systemem operacyjnym czasu rzeczywistego (RTOS) opracowanym w ramach projektu Ethernut. Ethernut jest projektem typu „open source hardware”, mającym na celu udostępnienie systemów wbudowanych obsługujących Ethernet.

Nas w tej chwili interesuje jednak tylko część software’owa tego projektu, czyli Nut/OS, udostępniający gotowy stos TCP/IP i obsługę protokołów takich jak DHCP, DNS, SMTP, a nawet HTTP czy FTP. Nut/OS bardzo dobrze wspiera kompilator AVR-GCC, a poza tym autorzy projektu przewidzieli możliwość pracy na Linuksie, więc czas przystąpić do dzieła.

Zaczynamy od ściągnięcia źródeł, rozpakowania i uruchomienia konfiguracji:

$ tar jxvf ethernut-4.8.2.tar.bz2
$ cd ethernut-4.8.2
$ ./configure

Powinniśmy zobaczyć m.in.:

configure: nutconfgui is enabled

co oznacza, że będziemy mogli skorzystać z konfiguratora graficznego. W innym wypadku zapewne będziemy musieli doinstalować wxWidgets lub inną bibliotekę, której brak wskaże nam konfigurator.

Ja napotkałem inny problem, związany ze specjalną biblioteką wxPropertyGrid, wymaganą przez narzędzie nutdisc, czyli Discoverera:

configure: WARNING: wxpropgrid not found
[…]
configure: nutdisc requires propgrid

Discoverer nie jest na szczęście niezbędny, jest to dodatkowy program, umożliwiający odnalezienie w sieci Ethernet nie do końca skonfigurowanych hostów, pracujących pod kontrolą Nut/OS-a.

Niestety, u mnie Ethernut najpierw nie widział skompilowanej biblioteki, a po wprowadzeniu zmian w configure i tak kończył kompilację z błędem. Koniec końców zignorowałem więc brak Discoverera i odpaliłem:

$ make
$ make check
$ su -c "make install"

Podczas kompilacji może nas jednak spotkać kolejna przykra niespodzianka: proces przerwie się niespodziewanie, sypiąc błędami, zapoczątkowanymi przez komunikat

error: wx/setup.h: Nie ma takiego pliku ani katalogu

Na szczęście i na to jest prosta rada:

# ln -s /usr/lib/wx/include/gtk2-unicode-release-2.8/wx/setup.h /usr/include/wx-2.8/wx/setup.h

Teraz make clean i jazda od nowa z kompilacją!

Po zainstalowaniu nie zmieniamy katalogu, tylko uruchamiamy nutconf i wybieramy plik konfiguracyjny MMnet104.conf.

Następnie klikamy Edit -> Settings. W zakładce Build Source Directory powinien wskazywać na katalog, do którego rozpakowaliśmy źródła, zaś Platform powinien mieć wartość avr-gcc. Jako Build Directory podałem katalog ~/test/build, zaś jako Install Directory — ~/test/build/lib. W zakładce Samples wskazałem ~/test/samples.

Teraz klikamy Build -> Build Nut/OS i Build -> Create Sample Directory. W efekcie uzyskujemy gotowe środowisko pracy: jądro RTOS, liczne biblioteki i przykładowe aplikacje. Możemy zacząć np. od serwera HTTP — po wydaniu komendy make w katalogu samples/httpd powinniśmy otrzymać HEX-a gotowego do wgrania do naszego mikrokontrolera.

Przy okazji wspomnę, iż warto skorzystać z debugowania za pomocą interfejsu RS232. Interfejs ten coraz rzadziej spotyka się w komputerach, jeżeli jednak korzystamy z płytki wyposażonej w konwerter RS232<->USB na bazie układu scalonego FTDI, Linux powinien nam automatycznie wykryć port i przypisać go do urządzenia /dev/ttyUSB0. Na PC-cie wystarczy uruchomić terminal RS232, np. GTKTerm czy CuteCom (baudrate odczytamy z kodu źródłowego; w moim przypadku parametry transmisji wynosiły 115200, 8N1), a w kodzie programu mikrokontrolera umieścić wywołania printf() czy puts(), raportujące stan urządzenia.

Jedyną niedogodnością jest fakt, iż po odłączeniu kabla lub zasilania płytki oba terminale zawieszają się, zajmując przy okazji całą moc CPU PC-ta. Dlatego w takich sytuacjach warto pamiętać o wcześniejszym rozłączeniu połączenia w terminalu.

Po konsultacjach uzgodniliśmy, że przed dramatyczną próbą wybebeszenia ATmegi i potraktowania ją programatorem równoległym spróbujemy użyć JTAG-a. Szczęśliwie okazało się, że da się w miarę prosto zbudować taki programator w warunkach domowych.

W Internecie nietrudno natrafić na opisy wykonania JTAG-a, także w języku polskim. Jak widać, schemat ideowy jest całkiem prosty, a elementy dosyć popularne i łatwe do zdobycia. Wyjątkiem jest oscylator kwarcowy o częstotliwości 7,3728MHz. Ja znalazłem go dopiero w czwartym sklepie (jeżeli ktoś mieszka w trójmieście, radzę od razu odwiedzić sklep Jacktronic). Warto też pamiętać, by kupić dwie ATmegi16, dzięki czemu będziemy mieli jeden czysty mikrokontroler, który posłuży do sprawdzenia poprawności działania JTAG-a.

Postępując zgodnie z opisem powinniśmy uruchomić całość w miarę szybko i sprawnie. Ja napotkałem tylko na problem z wgraniem bootloadera za pomocą programatora AVR USBasp, który opisywałem kilka miesięcy temu. Programator ciągle przerywał pracę, strasząc jakimś „broken pipe”. Nie udało mi się znaleźć wytłumaczenia tego problemu — być może jest to kwestia zakłóceń, powstających na skutek montażu na płytce stykowej. W każdym razie wystarczy odrobina cierpliwości i wgrywanie wsadu aż do skutku (w trybie spowolnionego programowania, które wlecze się niemiłosiernie, ale w końcu odnosi skutek). Co do samego wsadu, to radzę zastosować gotowy (u mnie samodzielna kompilacja nie zaowocowała działającą binarką).

Jeżeli komuś nie chce się przeliczać fuse bitów dla ATmegi16 w JTAG-u, poniżej podaję gotową komendę dla avrdude (Fuse Low Byte równy 0xFF i Fuse High Byte równy 0xD8).

$ avrdude -p m16 -c usbasp -v -U lfuse:w:0xFF:m -U hfuse:w:0xD8:m

Przypominam, że należy starannie zaciskać złącza IDC10 na taśmie programującej, a w przypadku użycia scrossowanego kabla RS232 należy zamienić odpowiednie końcówki w gnieździe.

Jeżeli ktoś chciałby uruchomić cały programator pod Linuksem, to, niestety, nie jestem w stanie służyć pomocą. Pod Linuksem wgrałem tylko bootloader, a resztę załatwiło AVR Studio pod Windowsem.

Co do naszej nieszczęsnej ATmegi128 — za pomocą JTAG-a odblokowałem lock bity, ustawiłem poprawną konfigurację oscylatora i wyłączyłem flagę WDTON, która niepotrzebnie włączała watchdoga, dzięki czemu moduł w końcu ruszył.

Jython, następca JPythona, jest implementacją Pythona w Javie i, co w tym przypadku najważniejsze, pozwala posługiwać się klasami Javy przez skrypty Pythona (a także z użyciem trybu interaktywnego!).

Po zainstalowaniu Jythona warto nadać odpowiednie uprawnienia dla katalogu cache’a. W moim przypadku było to:

# /opt/jython/jython
# chmod -R a+rw /opt/jython/cachedir/

Dzięki temu unikniemy komunikatów takich jak poniższy:

*sys-package-mgr*: can't write index file

Poza tym cache powinien odrobinę przyspieszyć pracę Jythona, a przynajmniej tak mi się wydaje ;)

Wracając do meritum: skrypt wywołujący funkcję main() interesującej mnie klasy wygląda bardzo prosto. Wystarczy dodać do ścieżki systemowej plik JAR i zaimportować klasę.

W moim przypadku funkcja main() wywołana bez argumentów zgłosiła błąd, więc szybko dopisałem coś, co powinno z grubsza symulować wywołanie z konsoli.

#!/usr/bin/env /opt/jython/jython
 
import sys
sys.path.append("jdmp.jar")
import org.jdmp.gui.JDMP
 
org.jdmp.gui.JDMP.main(["test","-g"])

PS Domyślam się, że pewnie jest prosty sposób na uruchomienie tej funkcji za pomocą Javy, ale znalezienie takiego rozwiązania zajęłoby mi pewnie tyle samo, co napisanie powyższego skryptu.

$ xrandr --auto

i wszystkie podłączone monitory automatycznie się skonfigurują. Z użyciem tego konsolowego programu można też pobawić się w tworzenie bardziej złożonych ustawień, typu jeden monitor nad drugim, jeden obok drugiego itp.

Żeby było nam wygodniej, przyjemniej i cieplej w plecy GNOME udostępnia GUI dla RandR. Wynalazek ten figuruje w moim menu jako Ekran i uruchamia program gnome-display-properties. Jest to narzędzie, które teoretycznie może i ułatwia życie, ale w praktyce przynosi więcej szkody niż pożytku, przynajmniej w moim wypadku.

Po uruchomieniu wspomnianej aplikacji pobawiłem się trochę ustawieniami, pochwaliłem w duchu dobry pomysł, wykrzaczyłem X-y i w końcu stwierdziłem, że mi to do szczęścia potrzebne nie jest. Niestety, w międzyczasie zdążyłem coś zmienić i cały pulpit przesunął się kilka pikseli poza obszar ekranu. Po restarcie X-y podnosiły się poprawnie, ale po zalogowaniu do GNOME-a wszystko znów się przesuwało. Była to przypadłość tylko i wyłącznie GNOME-a, więc doszedłem do wniosku, że środowisko to musi przy włączaniu ładować jakieś dziwne ustawienia. Ponieważ w autostarcie nie znalazłem nic podejrzanego, zacząłem męczyć gnome-display-properties i w końcu znalazłem przyczynę kłopotów: złą częstotliwość odświeżania. Po jej zmianie ekran przesunął się na dawne miejsce, ale… tapetę miałem rozciągniętą strasznie w dół. Podniesienie pokrywy laptopa ukazało istotę problemu: miałem ustawione dwa monitory, połączone w pionie. Niestety, ustawienia tego nie mogłem anulować, bo próba wyłączenia wbudowanego wyświetlacza kończyła się restartem X-ów.

Ponieważ tapeta jest w komputerze najważniejsza (a ponadto piekielnie niewygodny jest kursor myszy, który nie zatrzymuje się na dole ekranu, ale jedzie sobie śmiało poniżej paska zadań; że o dziwnie maksymalizujących się niektórych oknach już nie wspomnę), zabrałem się za poszukiwania tego-czegoś-co-trzeba-wyłączyć.

Na pierwszy ogień poszedł autostart. Wyłączenie Usługi ustawień środowiska GNOME pomogło, ale przecież trudno używać GNOME bez gnome-settings-daemon. Musiałem więc znaleźć miejsce, w którym nieopatrznie zmieniłem jakieś ustawienie. Oszczędzę Wam szczegółów tych poszukiwań, dość powiedzieć, że w końcu sięgnąłem nawet po hexedytor i przeglądając jedną z bibliotek GNOME-a w końcu znalazłem to, czego szukałem.

Otóż GNOME używa wątpliwej proweniencji (czyżby inspiracja rejestrem Windows?) wynalazku jakim jest GConf. Po uruchomieniu edytora gconf-editor można użyć wyszukiwarki, by znaleźć pozycję /apps/gnome_settings_daemon/plugins/xrandr. Teraz wystarczy odznaczyć opcję active i po sprawie.

Proste, prawda? Oczywiście, można by tę opcję umieścić w gnome-display-properties, ale wtedy byłoby aż za łatwo…

Na przyszłość radzę wspomnianej aplikacji nie dotykać, a w systemie przypisać jakiś łatwy skrót klawiaturowy (np. Win + x) do komendy

$ xrandr --auto

Tak na wszelki wypadek, gdyby nam kiedyś X-y oszalały po podłączeniu nowego monitora.

PS O GConf możecie poczytać u Grzglo.

Zaczynamy od przygotowania rankingu mirrorów. W najprostszym wypadku możemy po prostu wpisać:

# cd /etc/pacman.d/
# rankmirrors mirrorlist

Po kilku minutach otrzymamy listę mirrorów posortowanych wedle szybkości połączenia. Listę kopiujemy do pliku mirrorlist-rankmirrors. Możemy też od razu zapisać np. 5 najszybszych mirrorów do pliku:

# rankmirrors -n 5 mirrorlist > mirrorlist-rankmirrors

Później w /etc/pacman.conf linie

Include = /etc/pacman.d/mirrorlist

poprawiamy na

Include = /etc/pacman.d/mirrorlist-rankmirrors

Na koniec wymuszamy aktualizację aktualnej bazy pakietów:

# pacman -Syy

Na anglojęzycznym wiki Archa można też znaleźć opis innych sposobów na przyspieszenie pacmana. Ja pokusiłem się tylko o optymalizację bazy danych:

# pacman-optimize && sync

Jak mówi pomoc do tego programiku:

Ponieważ pacman używa wielu małych plików aby śledzić pakiety pliki te mają tendencję do fragmentacji w miarę upływu czasu. Ten skrypt próbuje przenieść je w jedno ciągłe miejsce na dysku. W rezultacie dysk twardy powinien czytać je szybciej, ponieważ jego głowica nie musi się często przemieszczać.

Oczywiście, powinien nie jest równoważne z „musi”, ale zawsze możemy liczyć na efekt placebo… ;)

Postanowiłem zatem obejść problem, eksportując sprawozdanie do PDF-a i drukując za pomocą Evince. Niestety, z poziomu Kile nie udało się to ze względu na błędy w osadzaniu plików EPS (buntował się albo TeX, albo Evince, zależnie od użytego sposobu). Pozostał tylko wydruk do PDF-a z poziomu KDVI.

Rzuciłem jednak okiem na Options w oknie wydruku KDVI i zmieniłem opcję Print system currently used z CUPS na Generic UNIX LPD Print System. Ku mojemu zdziwieniu, wydruk ruszył, a co jeszcze bardziej zaskakujące, jakość okazała się lepsza niż w pierwszym obejściu problemu (wydruk był bardziej „gładki”).

Ostatnio padło na zbyt szerokie okno przeglądarki internetowej. Przyzwyczajony jestem do maksymalizowana okna Firefoksa, jednak w czasach coraz większych rozdzielczości ekranu nawyk ten niesie ze sobą pewną niedogodność. Otóż niektórzy twórcy stron nie ograniczają szerokości bloków z treścią, co owocuje wyświetlaniem zbyt długich wierszy tekstu, które po prostu nie nadają się do czytania.

W związku z tym zacząłem szukać jakiejś skryptozakładki lub rozszerzenia, które pozwoliłyby szybko zmniejszyć szerokość strony bez potrzeby normalizowania całego okna. Wtedy przypomniałem sobie o All-in-One Sidebar i pomyślałem, że może po prostu zagospodaruję jakoś pasek boczny w przeglądarce. All-in-One Sidebar nie oferował mi jednak nic przydatnego. Wyświetlanie zakładek? Wystarczy mi pasek zakładek u góry okna. Wyświetlanie jakiejś strony WWW? Może, tylko jakiej? Pomyślałem, o Netvibes, ale w wąskim pasku to wyglądało po prostu tragicznie. Dałem więc szansę iGoogle. Tu rzecz miała się znacznie lepiej dzięki rozszerzeniu iGoogle Sidebar.

Teraz miałem węższy obszar dla stron, a z boku zgrabny pasek z kalkulatorem, kalendarzem, programem telewizyjnym i innymi bajerami. Choć w sumie… tą „zgrabnością“ nie byłem do końca zachwycony, bo nie wszystkie widgety dobrze sobie radziły z tak małą szerokością. Niemniej nie było źle.

Kontynuowałem jednak poszukiwania i w końcu trafiłem na Tree Style Tab, który gości u mnie od kilkunastu dni. Ma on pewne wady, np. nie znalazłem żadnego, poza użyciem F11 sposobu, na szybkie schowanie tego rozszerzenia (jest dostępne autoukrywanie, ale ja autoukrywania po prostu nie znoszę), gdy jakaś strona potrzebuje pełnej szerokości ekranu, ale poza tym jest to całkiem sprytne rozszerzenie. Mogę teraz znacznie łatwiej połapać się w kartach, gdy jest ich większa liczba.

$ ssh-keygen -t dsa

to PuTTY przy próbie autoryzacji tym kluczem wesoło zamiga do nas komunikatem Unable to use key file “C:\test_id_dsa” (OpenSSH SSH-2 private key).

Zagadką jest dla mnie, dlaczego tego klucza nie przekonwertuje sobie w locie na swój własny format, ani nawet nie podpowie użytkownikowi, że ten może zrobić to ręcznie. Na szczęście, my wiemy, co robić.

Uruchamiamy PuTTYgen (PuTTY Key Generator), wybieramy Conversions -> Import key, importujemy klucz (jeżeli jest zabezpieczony hasłem, zostaniemy o nie zapytani) i klikamy Save private key. Otrzymujemy klucz test_id_dsa.ppk, który będzie akceptowany przez PuTTY’ego.

Jeżeli z jakichś powodów chcemy dokonać konwersji kluczy pod Linuksem, instalujemy PuTTY’ego, po czym wydajemy polecenie:

$ puttygen test_id_dsa -o test_id_dsa.ppk