Aparat PTP

Od ręki nie działa. Próbowałem rozwiązać problem instalując następujące pakiety:

yum install  gphoto2 gvfs-gphoto2 gtkam digikam gthumb geeqie

Geeqie to zamiennik gqview, które używałem do tej pory. DigiKam nie działa (gryzie się z XFce). Wydaje mi się, że większość tego co zainstalowałem nie jest potrzebna -- istotne jest geeqie, dzięki któremu mogę wygodnie zaimportować zdjęcia z aparatu na komputer (lądują w katalogu ~/Pictures).

Wysyłanie fotek na flickr.com za pomocą Emacsa

Prawie działa. Problem stanowią słowa kluczowe zawierające polskie znaczki. Trzeba nieco zmodyfikować skrypty generujące bazę słów kluczowych tj. flickr_getalltags, i inne.

Cała procedura odświeżania tagów i innych metadanych jest uruchamiana skryptem flickr_update_kb, który w uproszczeniu wygląda następująco:

#!/bin/bash
# Get list of public photos with 'flickr.people.getPublicPhotos
flickr_getphotolist.pl -u hr.icio

# Refreshing information on tags/sets/geolocs"
# Get information on sets defined by the user:
flickr_getsets && \
# Get tags from flickr for current user
flickr_getalltags && \
# Get information on groups to which one can add photos
flickr_getgroups && \
## For flickr_xml2el we need _special treatment_ otherwise UTF is spoiled
PERL_UNICODE=S flickr_xml2el > ~/.flickr/hr.icio.el

cd ~/.knows &&  make 2flicker && \
cd ~/.flickr && make check

Z nieustalonych powodów cześć komunikatu zwracana przez flickra jest teraz kompresowana (a nie była -- nowsza wersja pakietu Perla?). Z tego też powodu konstrukcja (ze skryptu flickr_getalltags.pl -- w innych skryptach podobnie):

my $xm = $xmlp->XMLin($response->{_content}, forcearray=>[raw]);

została zamieniona na:

## zmienione 15.08.2011 (gzip as content-encoding)
## ustalenie w jakim `content_encoding' jest _content
my $content_encoding = $response->{_headers}->{'content-encoding'} ;
my $plain_content;
if ($content_encoding =~ /gzip/ ) {## jeżeli gzip to odpakować:
    $plain_content = Compress::Zlib::memGunzip( $response->{_content});
} else { $plain_content = $response->{_content};  }

Powyższe załatwia problem z (nie) działaniem skryptów flickr_getphotolist.pl, flickr_getsets, flickr_getalltags, flickr_getgroups.

Konwersja plików XML do formatu Emacsa za pomocą skryptu flickr_xml2el daje w rezultacie las komunikatów Wide character in print at... a plik wynikowy jest błędnie kodowany. Problem ciągle wraca a ja ciągle nie wiem czemu. Zaślepkowo pomogło dodanie PERL_UNICODE=S (zaklęcie to należy wstawić w odpowiednie miejsce także do pliku Make w katalogu ~/.knows).

Po tych wszystkich ww. zabiegach (które zajęły mi pół dnia) jestem w stanie odświeżyć bazę metadanych z mojego konta na flickr.com. Sukces:-)

Przejście z FC8 na FC15 rozpoczęło się od wymiany starego dysku (250Gb) na WDC EADS 1Tb (Green Power). Już na początku się zdarzył falstart, bo zarówno BIOS jak i Linux utrzymywał uparcie, iż dysk ma pojemność ok. 33Mb. Nie wchodząc w szczegóły problem powoduje błąd w BIOSie (starych) płyt Gibabyte (cf. WD10 EADS problem ..from 1TB to 31MB). The reason the drive is reporting 33MB is that Gigabyte's BIOS has a bug that incorrectly adjusts the drive's capacity after creating the HPA. 1TB drives are reduced to 33MB, 1.5TB become 500GB, and 2TB become 1TB. (cf. Lost Partition on Hitachi...).

Więcej na temat można się dowiedzieć wpisując w Google HDA+Gigabyte i/lub ze strony Wikipedii.

Aby przywrócić ,,fabryczną'' pojemność postąpiłem wg. zalecenia: The solution is to use a tool such as HDAT2 or the HDD Capacity Restore Tool to remove the HPA (Host Protected Area), tyle że zamiast HDAT2/HDDCRT użyłem poczciwego hdparm.

## Potrzebny jest hdparm > 8.0 cf http://en.wikipedia.org/wiki/Host_protected_area
## w zapisie p1953525168 litera `p' jest OK i oznacza `permanent'
[root@darkstar]#hdparm -N p1953525168 /dev/sdb

/dev/sdb:
 setting max visible sectors to 1953525168 (permanent)
 max sectors   = 1953525168/1953525168, HPA is disabled

[root@darkstar]#hdparm -N /dev/sdb

/dev/sdb:
 max sectors   = 1953525168/1953525168, HPA is disabled

Teraz podzieliłem dysk na partycje używając gparted: / (ok. 50Gb), /swap (ok. 2Gb), /boot (ok. 500Mb), /home (ok. 750Gb). Zainstalowałem FC15 używając do tego obrazu Fedora-15-i686-Live-Desktop ze strony http://torrent.fedoraproject.org/. Instalacja zakończyła się dziwnym błędem, objawiającym się tym, że partycja / miała 50Gb według np. fdiska, a 2,5Gb tak w ogóle i na prawdę. W drugiej próbie podział na partycje został wykonany przez instalator i wtedy było dobrze. Czemu było źle za pierwszym razem nie wiadomo...

Z jakiś powodów Fedora gadała do mnie po angielsku (Założyłbym się, że w czasie instalacji nikt mnie się nie pytał czy chcę po angielsku czy nie...) Zmieniłem to wpisując do /etc/sysconfig/i18n:

##LANG="en_US.UTF-8" ## tak było po instalacji
LANG="pl_PL.UTF-8"
SYSFONT="latarcyrheb-sun16"

Jednym słowem zamierzam przejść na Unicode (do tej pory używałem ISO-8859-2). Kompatybilność wstecz gwarantuje mi Emacs, w którym redaguję moje dokumenty/pliku tekstowe. Dla przypomnienia następujące zaklęcia gwarantują, że Emacs przełączy się na właściwe kodowanie:

% -*- coding: iso-8859-2 -*-
tra-ta-tata

% Local Variables:
% coding: iso-8859-2
% ispell-local-dictionary: "polish"
% End:

Zaklęcie % -*- coding: iso-8859-2 -*- musi być w pierwszym wierszu. Wpisy Local Variables: ... End: na końcu pliku. Do przestawienia kodowania wystarczy albo wpis w pierwszym wierszu albo Local Variables:. Można zastosować też oba na raz -- nie będzie błędu.

Gnome3

Po kilkugodzinnej walce z Gnome 3 zmieniłem go na Xfce. Szkoda czasu na deliberowanie, w jaki sposób zdefiniować tak elementarne rzeczy, jak przykładowo skrót do programu (Nb. sposoby podane np. tu albo tu u mnie nie działają.)

Gpsbabel

Fundamentalna dla mnie aplikacja, a mianowicie gpsbabel nie działa. Na szczęście, ktoś już z tym walczył przede mną (cf. libusb-config missing from libusb-devel):

## Gpsbabel w fc15 jest `broken' trzeba go skompilować:
wget http://mirrors.xmission.com/fedora/updates/15/SRPMS/gpsbabel-1.4.2-6.fc15.src.rpm  
## bo nie bo w http://download.fedoraproject.org/pub/fedora/linux/releases/15/

rpm -ivh gpsbabel-1.4.2-6.fc15.src.rpm
## się rozpakował w /root/rpmbuild/

yum install rpm-build  rpm-build-libs
rpmbuild -ba /root/rpmbuild/SPECS/gpsbabel.spec # tam się rozpakował SPEC
rpm -Uvh /root/rpmbuild/RPMS/i386/gpsbabel-*
## zgłaszany jest konflikt zatem
rpm -e gpsbabel
rpm -Uvh /root/rpmbuild/RPMS/i386/gpsbabel-*
##

## Poniższe jest potrzebne do moich skryptów obsługujących ściąganie śladu z Legenda:
wget http://search.cpan.org/CPAN/authors/id/B/BL/BLUEFEET/Geo-Distance-0.17.tar.gz
tar -zxvf Geo-Distance-0.17.tar.gz && cd Geo-Distance-0.17
perl Makefile.PL && make && make install 

Niestety coś się zmieniło i magiczne zaklęcie (wpisane do /etc/udev/rules.d/51-garmin.rules) działające w poprzednich fedorach:

SYSFS{idVendor}=="091e", SYSFS{idProduct}=="0003", MODE="0666"

przestało działać. Na razie odpuszczam i będę ściągał ślady jako root; z czasem się dowiem jak problem pokonać.

Googleearth

Instalowanie Googleearth też nie okazało się oczywiste:

wget http://dl.google.com/earth/client/current/GoogleEarthLinux.bin
sh ./GoogleEarthLinux.bin
## się wysypało z błędem, przy czym
## skrypt pyszczył, że mu brakuje LSB
yum install redhat-lsb redhat-lsb-graphics

## dalej się wysypuje. Ale znalazłem via google co robić:
./GoogleEarthLinux.bin --target /tmp/ge
## kończy się błędem ale idziemy dalej:-)

cd /tmp/ge/setup.data/bin/Linux/x86/
mv setup.gtk setup.gtk2
cd /tmp/ge
## poniższe polecenie jako `root' oczywiście:
./setup.sh

Na razie tyle... Da się tego używać, ale z ostateczną oceną się na razie wstrzymuję -- zobaczymy co jeszcze zostało spartolone...

Dopisane 15 sierpnia 2011: Dopisałem do .emacs polecenia, które mają powodować, że pliki TeXa oraz pliki w formacie Blosxoma są domyślnie redagowane w Emacsie w kodowaniu jednobajtowym:

(modify-coding-system-alist 'file "\\.blx\\'" 'iso-8859-2)
(modify-coding-system-alist 'file "\\.tex\\'" 'iso-8859-2)

Zastanawiam się też nad dodaniem czegoś takiego (najpierw wypróbuję czy na pewno działa):

(modify-coding-system-alist 'process "svn" 'iso-8859-2)

Dopisane 18 sierpnia 2011: Pobieranie zrzutu ekranu. W gnome jest do tego gnome-screenshot a w Xfce -- xfce4-screenshooter (cf. http://goodies.xfce.org/projects/applications/xfmpc). Program gnome-screenshot (uruchamiany jako gnome-screenshot --interactive) działa ,,nieintuicyjnie'' przy wybraniu zrzutu z okna, xfce4-screenshooter działa lepiej

Dopisane 21 sierpnia 2011: Avatary w ekranie logowania (gdm). W internecie są sprzeczne informacje na ten temat. Niektórzy twierdzą, że się nie da. W rzeczy samej sposób najprostszy, a polegający na umieszczeniu stosownej ikony w postaci pliku o nazwie .face w katalogu domowym użytkownika nie działa, ale działa umieszczenie tegoż pliku (niekoniecznie nazywającego się .face tym razem) do katalogu /var/lib/AccountsService/icons/ oraz dodanie do każdego pliku z katalogu /var/lib/AccountsService/users/ wpisu:

Icon=/var/lib/AccountsService/icons/nazwa_pliku_zaw_avatara

Por. https://bugzilla.redhat.com/show_bug.cgi?id=705240.

Dopisane 26 sierpnia 2011: Konfigurowanie drukarki (system-config-printer). Zalecany sterownik pn. HP LaserJet 6P Cups+ Gutenprint v.5.2.7 simplified [en] czasami nie działa (np. plik .ps generowany przez pstops drukuje ohydnymi fontami bitmapowymi o niskiej rozdzielczości). Pomaga przestawienie na sterownik pn. HP LaserJet 6P Foomatic/ljet4.

Dodałem też syntax off do ~/.vimrc ponieważ kolorowane pliki były skrajnie nieczytelne.

Prywatne pakiety R, takie jak Rcmdr będę instalował w katalogu R_LIBS=$HOME/R. Odpowiedni wpis dodałem zatem do ~/.bash_profile.

W uzupełnieniu do wpisu: TV w Internecie oglądam więcej niż sporadycznie ale dziś chciałem pooglądać mecz Barcelona vs Chelsea i nie potrafiłem uruchomić sopcasta. Ostatecznie zadziałał sposób podany na blogu Mateusza Wójcika, tj. poprzez uruchomienie skryptu (lekko zmieniony przez dodanie if-then-else-fi):

#!/bin/bash
if [ $1 ]
then
 sp-sc $1 3908 8908 > /dev/null &
 echo "Poczekaj 20 sekund na scachowanie danych i otworzenie odtwarzacza..."
 sleep 20
 mplayer http://localhost:8908/tv.asf
 echo "Zamykanie polaczenia..."
 killall sp-sc
else
 echo "Podaj kanał..."
fi

Adres kanału znalazłem na stronie http://www.soccer-live.pl/.

Skrypt Erika Möllera , którego używałem do ładowania zdjęć na WikiCommons przestał działać. Konsultacja na stronie wykazała, że jest outdated and should be considered deprecated and useless. Program proponowany w zamian nie podoba mi się. Może i jest dobry, ale zbytnio się różni od poprzedniego a ja nie mam czasu go rozgryzać. Znalazłem za to poprawioną wersję skryptu Möllera, która działa, tutaj (lub tutaj).

Jest ciągle problem z kodowaniem (używam domyślnie ISO-8859-2), bo po przesłaniu na WC tekst jest niepoprawnie zakodowany. Metodą prób i błędów ustaliłem, że działa dopisanie na początku skryptu czegoś takiego:

binmode( STDOUT, ':utf8' );
use open IN => ':encoding(iso-8859-2)'; ## I am using legacy encoding, ha!
use open OUT => ':utf8'; ## write utf8

Opis zdjęcia w pliku tekstowym jest w ISO, po przesłaniu na WC kodowanie jest OK. Próbowałem wysyłać pliki kodowane jako UTF-8, ale to też nie działało (mój perl jest w wersji v5.8.8).

Rysunek obok znalazłem przypadkiem. Ktoś skopiował moje zdjęcie z flickr.com na WC dodając zabawny opis...

Przy okazji ustaliłem jak przejść do ,,trybu UTF'' otwierając nowy plik w Emacs: C-x C-m f utf-8

Nie do końca legal, chyba. Ściągnąłem rpm polecany na tym blogu. Zainstalowałem:

rpm -Uvh qsopcast-0.3.1-1mgc.i686.rpm

Teraz można uruchomić program podając qsopcast. Trzeba tylko zmienić konfigurację podając adres listy kanałów jako http://www.sopcast.com/gchlxml (Config|Config). Zmieniłem też program do oglądania na mplayer (też w zakładce Config|Config). Kłopot tylko z wyborem kanału. Opisywany na blogach sposób (np. tu) przez konfigurację FF via about:config nie działa.

No i oglądam MU vs Barcelona; na razie jest 1:0 a strzelił Paul Scholes.

Przełączyłem aparat na format RAW a do zamiany plików w tym formacie (rozszerzenie .orf) na tiff użyłem dcraw, np.:

dcraw -T plik.orf # zamiana poj. pliku
for i in *.orf; do dcraw -T $i ; done

Pliki są nieskompresowane, więc następnie:

convert plik.tiff -compress ZIP plik_z.tiff # albo
mogrify -compress ZIP plik.tiff

Program mogrify modyfikuje plik oryginalny

Zamiana tiffa na jpeg z wykorzystaniem convert wygląda zaś następująco:

for i in *.tiff; do convert $i `basename $i .tiff`.jpg ; done

Powyższe ma jeden dyskwalifikujący brak: dcraw usuwa dane EXIF. Szukając rozwiązania znalazłem dwa skrypty basha do konwersji z zachowaniem metadanych: Converting RAW images to JPEG with Exif on Fedora oraz wrapper script for dcraw. Pierwszy ze skryptów używa exiv2 a ja mam awersję do tego programu (być może niesłuszną, ale kiedyś mi podpadł). Drugi niby jest dla Nikona, ale żeby działał z Olympusem to wystarczy zmienić nef na orf w jednym wierszu (oprócz tego uprościłem skrypt, bo był sophisticated zbytnio i niepotrzebnie):

#!/bin/bash
# http://www.howtofixcomputers.com/forums/digital-photo/my-humble-contribution-wrapper-script-dcraw-linux-4360.html
# Zamiana plików ORF (Olympus) na JPEG z zachowaniem danych EXIF
# Wykorzystuje dcraw, cjpeg (do kompresji) oraz exiftool
#
DCRAW="dcraw -w -c "

while [ $# -ge 1 ]
do

JPEG=`basename $1 .orf`.jpg
echo "Converting $1 => ${JPEG}..."
$DCRAW $1 | cjpeg -quality 90 > $JPEG || echo " *** Problem writing "

# transfer EXIF data from the original raw file
exiftool -overwrite_original -TagsFromFile "$1" "$JPEG" >/dev/null

shift
done

Przy okazji znalazłem link do konferencji Libre Graphics Meeting.

Dopisane 27 kwietnia 2008: zmieniłem ustawienia w aparacie na zapis RAW+HQ. Poprzednio było RAW, a przedtem HQ. HQ zapisuje prawie że identyczne ,,objętościowo'' pliki .jpg o wielkości 2Mb (z ogonkiem). Nie ustaliłem jeszcze czemu ale pliki konwertowane z RAW różnią się znacząco wielkością (ten sam parametr quality oczywiście) a te produkowane przez aparat są takie same.

Jak w tytule. Trudno problem zdiagnozować. Wygląda jakby cron coś uruchamiał, a to coś miele dyskiem na tyle intensywnie, że mysz i klawiatura są praktycznie zablokowane. Praktycznie, tj. z początku jeszcze jakoś tam reagują a po chwili jest już totalny klops. Próba połączenia się z komputerem via ssh (żeby np. zobaczyć co tak intensywnie pracuje) też nic nie daje. Żeby było śmieszniej, na laptopie mam prawie-że-identyczną instalację FC8 i się nie wiesza. Hardware? Ale jeżeli to jakiś bardzo subtelny błąd...

Najpierw myślałem, że to updatedb, które jest umieszczone w /etc/cron.daily, ale nie--updatedb wydaje się być OK. Patrząc na zawartość /etc/cron.daily następnym podejrzanym wydał się /etc/cron.daily/prelink. Więcej o prelinku jest przykładowo tutaj. Log prelinka jest zaś w /var/log/prelink/prelink.log. Przydatność tego narzędzia jest dość często kwestionowana, np.: You should disable prelink, since its benefits are barely noticeable with minimum performance improvements.

Skoro prelink modyfikuje pliki, to być może mój problem jest spowodowany resetem wykonanym w trakcie pracy tegoż? Przyznaję się, że kiedyś zniecierpliwiony zwisem zresetowałem komputer. Anyway, wyłączyłem:

1. W pliku /etc/sysconfig/prelink ustawiłem PRELINKING na no.
2. Uruchomiłem /etc/cron.daily/prelink.

W tym momencie prelinking jest wyłączone. Zobaczymy czy to coś zmieni--tj. czy zwisy znikną.

Dopisane 27 Marca 2008: To nie jest problem z prelinkiem bo pomimo jego wyłączenia problem uporczywie powrócił. Teraz usunąłem z crona program (skrypt tak na prawdę) 000-delay.cron. Nie wiem czemu ten skrypt miałby szkodzić ale nie mam innego pomysłu. Mówiąc ściśle wstawiłem w drugim wierszu tegoż skryptu exit 0. Na razie od wczoraj wszystko działa. Patrzyłem do /var/log/cron i są wpisy świadczące, że skrypty z /etc/cron.daily były uruchamiane i pomyślnie wykonane. No może tym razem...

Zaktualizowałem też system poprzez yum update. Kontrowersyjna procedura--co update to coś popsute. O perlu już pisałem. Nie pisałem, ale po którejś aktualizacji przestał rozpoznawać kartę graficzną googleearth. Program działa ale wolno, zresztą w momencie startu pojawia się stosowny komunikat. Niby nic ważnego, bo to aplikacja do zabawy nie do pracy, ale zawsze--tym bardziej że już kiedyś działał. Podejrzewam że winna jest aktualizacja jądra do wersji 2.6.24.3-50. Dziś zrobiłem m.in. update do 2.6.24.3-50 i googleearth działa jak dawniej.

Od trzech lat używam do wypełniania PITów programu Marcina Konopki / firmy IPS pn. Pity 2007. Świetny program, polecam wszystkim. Do tego legalnie można go używać nawet za darmo; należy jedynie wesprzeć dowolnie wybraną Organizację Pożytku Publicznego (autor prosi o wsparcie dla Dzieła Pomocy św. Ojca Pio). Jedyna kłopot z Pitem 2007 był taki, że jest to aplikacja na tzw. system alternatywny.

Piszę był, bo w FC8 świetnie działa z Wine. No prawie świetnie: wydruk trochę nie ten-teges ale to się da poprawić mianipulując wielkością marginesów.

Zainstalowałem Emacsa w wersji 23 z plików rpm przygotowanych przez Brada Walkera (cf. rpm.bradmwalker.com/). Wygląda na to, że rpm miał być przygotowany w taki sposób, żeby dodawał nową wersję emacsa do systemu bez usuwania starej (poprzez polecenie alternatives). Ale coś nie wyszło: u mnie usunął starego, a nowy został zainstalowany w katalogu /usr/bin pod nazwą: emacs-23.0.60. Ręcznie zatem dodałem:

/usr/sbin/alternatives --config emacs

Wpis dotyczący Emacs 23 już był--nie trzeba była uruchamiać alternatives --install. Dodałem też wpis do /etc/X11/Xresources:

Emacs.font: Monospace-10

Można też to samo wpisać do ~/.Xresources, ale wtedy nie będzie system wide.

Zaktualizowałem dziś system przez wykonanie yum update i przestał działać skrypt do ładowania zdjęć na flickr:

junk '500 Can't locate object method "configure" via package "Net::HTTP"
' before XML element

Pakiet Net::HTTP jest imho częścią Perla jako takiego (wchodzi w skład pakietu libwww-perl). Bliższa inspekcja /var/log/yum ujawniła, że faktycznie Perl został zaktualizowany do wersji 5.8.8-33.fc8, co wskazywało niezbicie źródło problemu. Teraz pozostało tylko odkręcić z powrotem aktualizację do wersji poprzedniej.

Chciałem przywrócić poprzednią wersję ,,porządnie'', ale przeglądają relewantne informacje via Google zorientowałem się że może być z tym problem. Yum nie ma opcji przywracania pakietu w określonej wersji (podobno konkurencyjny apt ma). Istnieje wprawdzie plugin do yuma pn. allowdowngrade (instalowany przez yum install yum-allowdowngrade) tyle, że nie działa, np.:

yum --allow-downgrade localupdate perl-5.8.8-32.fc8.rpm

Status tegoż plugina zresztą jest mocno podejrzany. Zero dokumentacji i/lub śladów (pomyślnego) wykorzystania na stronach google. Ostatecznie użyłem opcji, co do której dokumentacja stwierdza, cyt. zezwala uaktualnianiu na zastąpienie nowszego pakietu starszym:

rpm -Uvh --oldpackage perl-5.8.8-32.fc8.i386.rpm \
 perl-libs-5.8.8-32.fc8.i386.rpm  perl-ExtUtils-Embed-1.26-32.fc8.i386.rpm \
 perl-devel-5.8.8-32.fc8.i386.rpm perl-ExtUtils-MakeMaker-6.30-32.fc8.i386.rpm \
 perl-Test-Harness-2.56-32.fc8.i386.rpm  perl-Test-Simple-0.62-32.fc8.i386.rpm

Na liście są wszystkie pakiety zależne od perl-5.8.8-32.fc8.i386 zainstalowane podczas ostatniej aktualizacji. Nie wiem czy taki sposób jest w 100% poprawny. Okaże się później. Na forach proponowano też:

yum erase perl

Ale to polecenia chciało usunąć nie tylko Perla ale jeszcze -- w ramach zależności -- pół systemu. Łącznie kilkaset Mb. Nie poszedłem na to:-)

Żeby yum nie usuwał pakietów po instalacji, należy zmienić w pliku /etc/yum.conf

keepcache=1

Ściągnięte pakiety można odnaleźć w katalogu /var/cache/yum/. Zamiast instalować pakiety bezpośrednio poprzez uruchomienie yuma niektórzy radzą używać programu yumdownloader do ściągania plików .rpm a programu rpm do ich instalowania.

Dziś o 23.05 w radiu Gdańsk będzie o płycie Elki i Anki S pn. Duo Sopot. Na tę okoliczność gorączkowo ustaliłem jak słuchać Radia Gdańsk przez Internet. Klikanie w przeglądarce oczywiście nie działa, bo formaty są dedykowane na system alternatywny (konkretnie są w formacie aacPlus). Należy wpisać w konsoli:

xine -H http://www.radio.gdansk.pl/audio/rg.pls

Więcej nt. radia internetowego -- także w linuksie -- na stronie radioapma.elzet.biz/jaksluchac.html. Można też kliknąć w rysunek obok, aby dowiedzieć się więcej o płycie Duo Sopot.

Dopisane 1 kwietnia 2008: Dziś usiłowałem słuchać transmisji meczu Man Utd vs AS Roma w radiu iGol FM:

xine -H http://fm.igol.pl/igol.m3u 

Działa tak sobie. Są kłopoty ze startem -- pomoga kilkukrotne uruchomienie + nerwowe kliki w okno xmms. Transmisja jest przerywana (buforowanie). Nie wiem czemu.

Dopisane 19 kwietnia 2009: Polskie radio można też słuchać używając vlc:

vlc http://www.polskieradio.pl/st/program1M.asx

xine nie działa, bo coś-tam, albo nie potrafię go uruchomić we właściwy sposób

Portal www.gust.org.pl pozwala na redagowania zawartości poprzez WebDav. Kiedyś ustaliłem jak można wygodnie edytować pliki via WebDav posługując się Emacsem. Jest jeszcze prostszy sposób, wykorzystujący program wdfs i fuse.

Pakiet wdfs instaluję za pomocą yuma; fuse był w fc8 zainstalowany ,,fabrycznie''. Teraz można wykonać operację zamontowania odległego katalogu. Przykładowo dla strony głównej portalu GUST wygląda to następująco:

wdfs http://www.gust.org.pl:1980/ ~/dir/ -o username=user -o password=passwd

Zamiast powyższego można modyfikować /etc/fstab, ale ja tego nie próbowałem. Aby odmontować należy zaś wpisać:

fusermount -u ~/dir/

Żeby powyższe zawsze działało należy zadbać aby odmontowujący był w grupie fuse oraz wykonać sudo chgrp fuse /dev/fuse

Podmontowany katalog wygląda jak lokalny, więc można wygodnie edytować pliki nie tylko Emacsem ale dowolnym innym edytorem.

Jak to często bywa rozwiązanie jednego problemu rodzi następny. Zawartość portalu GUST jest kodowana w UTF-8. Do tej pory starannie unikałem posługiwania się UTF-8, a nawet wpisałem do /etc/profile zaklęcie EMACS_UNIBYTE=t. Muszę teraz skonfigurować Emacsa żeby był bardziej elastyczny. Ale o tym później--jak zacznie działać...

Celem synchronizacji danych na moich komputerach założyłem archiwum SVN na PC. Do tej pory trzymałem moje pliczki potajemnie na svn.gust.org.pl, ale baza padła, svn wypisuje, że takiej to a takiej wersji nie ma svn: No such revision 465, no i generalnie kicha. Ponieważ svn w moim przypadku to duży overkill myślałem o czymś w rodzaju unisone, ale szkoda mi czasu, a po drugie -- pewnie niesłusznie -- wydaje mi się, że unisone bardziej nadaje się do synchronizacji w jedną stronę, np. przesłanie plików konfiguracyjnych z serwera na wiele komputerów. Tak więc ostatecznie stanęło na svn.

Zacząłem od ,,konfiguracji'' mojej ,,sieci'' LAN. Po uruchomieniu /sbin/ifconfig ustaliłem, że mój PC ma adres 192.168.1.102. Dopisałem zatem do /etc/hosts:

192.168.1.102 darkstar.pinkaccordions.org darkstar

W zasadzie całą konfigurację zrobił router! Komputer ma zatem nazwę darkstar, a pinkaccordions.org jest ukłonem w stronę Elki. Laptopa konfiguruję podobnie, nie używam WiFi, tylko kabel. Sieć będę używał tylko do transferu-synchronizacji więc nie ma to (mam nadzieję) większego znaczenia. Teraz najtrudniejsze:

svnadmin create '/stuff/svn/repos/tomek/'
svn mkdir file:///stuff/svn/repos/tomek/weblog -m'pierwszy projekt'
chown -R g+w /stuff/svn/

Następnie dopisuję do /etc/group, grupę svn, a do niej tych, którzy mają korzystać z svn. Zmieniam grupę, do której należy katalog /stuff/svn/:

chown -R root:svn /stuff/svn/

Wylogowuję się jako root I dodaję do repozytorium pierwszy projekt. Ponieważ repo jest na lokalnej maszynie mogę wpisać:

svn import  file:///stuff/svn/repos/tomek/weblog -m "Import mojego bloga"

Jeżeli nie zadziała, ale zamiast tego wyświetli:

svn: Can't create directory '/subversion/main/db/transactions/0-1.txn':\
   Permission denied 

Albo ekwiwalent w języku polskim, to trzeba zrestartować komputer i powinno działać. Jeżeli coś dalej jest nie tak, no to nie wiem -- u mnie działa.

Obezwładniam SELinuksa, edytując /etc/selinux/config:

SELINUX=disabled

SELinux jest usługą, która przeszkadza w wielu miejscach i z moich doświadczeń wynika, że lepiej ją prędzej czy później wyłączyć. Usługa ssh powinna być ,,zaufana'' (trusted services). Teoretycznie można konfigurować zaporę sieciową poprzez wybór z System/Administracja/Zapora, ale u mnie to nie działa. Być może jest to moja wina, bo nie używam domyślnego unicode tylko ISO-8859-2. W każdym bądź razie, radzę sobie uruchamiając program poprzez terminal (oczywiście jako root):

LANG=C system-config-securitylevel

Żeby nie wpisywać hasła, generuję odpowiednie klucze używając ssh-keygen, w sposób opisany tutaj:

ssh-keygen -t rsa

Teraz dwa razy Enter. W rezultacie klucz prywatny jest w .ssh/id_rsa, a publiczny w .ssh/id_rsa.pub Zawartość tego ostatniego trzeba dodać do .ssh/authorized_keys na maszynie, z którą mamy się łączyć bez podawania hasła. Procedurę powtarzam dla drugiej maszyny. Można sprawdzić:

ssl -l tomek darkstar

Powinno działać. Także będzie działać svn, np. mogę ściągnąć repozytorium z PC na laptopa:

svn co  svn+ssh://tomek@darkstar/stuff/svn/repos/tomek/weblog

Dopisane 26 lutego 2008: Sam się dziwiłem jakim cudem router przydziela moim komputerom te same numery IP. Ale do czasu. Wczoraj przydzielił inne... Pomysł oparty na /etc/hosts miał raczej krótkie nogi. Nie mając bladego pojęcia jak to osiągnąć i posługując się google ustaliłem, że 1) static DHCP jest tym czego mi potrzeba; 2) fabryczny firmware do mojego routera WRT54GL nie potafi tego zrobić i należy wgrać alternatywny 3) są różne alternatywy, zachęcony tym wpisem postawiłem w ciemno na Tomato.

Mówiąc szczerze najwyżej w Google było nt. dd-wrt, ale strona tegoż jakaś taka podejrzanie dziwna, nie mówiąc już o www.dd-wrt.org/. I was a bit afraid.

Zatem ściągnąłem plik ze strony www.polarcloud.com/tomato. Zainstalowałem archiwizer 7-Zip, który do niczego nie był mi wcześniej potrzebny:

yum install p7zip p7zip-plugins

Wypakowałem zawartość archiwum, połączyłem się z routerem (http://192.168.1.1/) i wgrałem firmware (Administration/Firmware Upgrade, wybrałem plik wrt54g_wrt54gl.bin). Teraz ważne (nie zrobiłem tego i straciłem trochę czasu): należy zresetować router (Administration/Restore default configuration, wybrać Erase all data in NVRAM memory). Po resecie loguję się na router jako root/admin. Następnie trzeba przejść do zakładki Basic/Static DHCP i wpisać odpowiednie informacje (numery MAC są w zakładce Status/Device List).

Zgodnie z tym co jest napisane w dokumentacji należy wybrać adresy spoza puli przydzielanej automatycznie przez router. Ponieważ mój router przydziela z przedziału 192.168.1.100--149, wybrałem numery typu: 192.168.1.2 itp.

Jak już wszystko zainstalowałem to znalazłem detaliczny opis co i jak tu: Turbocharge your router with Tomato. Jest też poradnik co robić jak instalując nowy firmware popsujemy router: Recover from a Bad Flash.

No więc problemy sygnalizowane wcześniej zostały rozwiązane i mam komputer z nową płytą, pamięcią i procesorem. Reszta została ze starego. Windows 2000, co był na nim na zasadzie eksponatu muzealnego omówił pracy, a Fedora #5 -- nie. He, he. Nawet bym jej nie zamieniał na coś nowszego, bo aktualizacja systemu to zawsze dla mnie Royal PITA ale nie obsługiwała (ta Fedora) w pełni poprawnie nowej karty graficznej. Można było wprawdzie pracować ale wszystko było przeraźliwie rozciągnięte; litery zwłaszcza w mniejszym stopniu mało czytelne. Nie było wyjścia i na partycji zajętej przez zupełnie już bezużyteczne Windows 2000 zainstalowałem na próbę FC8. Ekran wyglądał świetnie więc po uprzednim zarchiwizowaniu katalogów /home/, /etc/, /usr/local/ na wolne partycje poszedłem na całość i zainstalowałem FC8 zamiast FC5.

Wszytko było super do momentu kiedy nie odpaliłem xmms. Dźwięk nie działa i nie bardzo wiedziałem jak sobie z tym poradzić. W FC o tyle wszystko jest zamotane, że jest wiele miejsc, które służą do manipulowania dźwiękiem: System/Administracja/Wykrywanie karty, Preferencje/Sprzęt, Aplikacje/Dźwięk i obraz. Po pewnej szamotaninie, znalazłem na forum poradę sprowadzającą się do wykonania:

rpm -e alsa-plugins-pulseaudio

Spróbowałem. Poszło--nie było żadnych zależności. Głośniki zaczęły działać. Niestety--to było tylko pół sukcesu. Mikrofon -- potrzebny do komunikowania się przez skype -- jak był głuchy tak został. Odkręciłem odinstalowanie alsa-plugins-pulseaudio:

yum install alsa-plugins-pulseaudio

Następnie zmieniłem stan selinux modyfikując w pliku /etc/selinux/config:

SELINUX=permissive # było enforcing

Oraz manipulując alsamixer -- uruchomionym z wiersza poleceń -- zgodnie z sugestiami podanymi tutaj. Pozwolę sobie zacytować oryginał: 1. Odpalamy terminal i wpisujemy alsamixer. 2. Wciskamy na klawiaturze TAB, aż przejdziemy do zakładki All. 3. Jedziemy w prawo aż dojdziemy do pola Mic. 4. Naciskamy SPACJĘ (pod Mic pojawia się napis capture). 5. Jedziemy dalej aż do pola Mic Selection i wybieramy Mic1 (strzałka do góry). 6. Jedziemy dalej do paska Capture i uruchamiamy go spacją. 7. Upewniamy się, że wszystkie wyżej wymienione paski są na samej górze. 8. Wychodzimy z alsamixera klawiszem ESC. U mnie wprawdzie, co do szczegółów, to ekran alsamixer wygląda trochę inaczej, ale rezultat jest pozytywny: mikrofon i głośniki działają

FC8 zainstalowałem w wariancie Office (jeżeli dobrze pamiętam nazwę). W tym wariancie nie jest instalowany gcc--dziwna decyzja. Na dzień dobry doinstalowałem:

yum -y install gcc emacs emacs-el thunderbird gpsbabel gv xpdf tidy \
  k3b k3b-extras-nonfree \
  grip gprolog clips R amule subversion gqview xine exiv2 unrar 
  mod_dav_svn xinetd dejavu-fonts bitstream-vera-fonts lame mc \
  apel gnutls-utils wdfs kile lyx

yum -y install xchm kchmviewer dia inscape scribus xmms \
  audacious audacious-plugins-nonfree* \
  amarok amarok-extras-nonfree mplayer audacity

Pakiety amarok oraz audacious, to odtwarzacze audio; kiedyś używałem też beep (pakiet bmxp). Beep dalej jest dostępny w FC8 ale nie działa z plikami MP3. Program gpsbabel to program do manipulowania danymi pobranymi z odbiorników GPS, gv, xpdf to programy do wyświetlania plików PS/PDF (domyślnie w FC8 służy do tego evince, też go używam). Pakiety gprolog i clips zawierają odpowiednio kompilator Prologa i środowisko Clips (systemy ekspertowe się kłaniają). Program gqview to moja ulubiona przeglądarka do zdjęć. Pakiet exiv2 to narzędzie do manipulowania metadanymi Exif (w zdjęciach robionych aparatem cyfrowym).

Opera wymaga libstdc++.so.5, co wymaga zainstalowania następujących dwóch pakietów:

yum -y install compat-libstdc++-33 compat-libstdc++-296

Programy xchm i kchmviewer to przeglądarki dokumentów w formacie CHM. Dia, inkscape i scribus to aplikacje graficzne. Kile/lyx to dwa alternatywne IDE do redagowania dokumentów w LaTeXu.

Problem pojawił się przy instalowaniu skryptów do obsługi flickr.com. Perl w FC8 ma wbudowany inny @INC--nie ma w nim żadnych katalogów w /usr/local, wszystkie są /usr/. Kolejna dziwna decyzja, bo niby gdzie wsadzać ,,swoje'' skrypty i/lub niestandardowe biblioteki. Dopisałem w /etc/profile:

PERLLIB="/usr/local/lib/perl5/site_perl/"
export PERLLIB

I w tym katalogu trzymam swoje skrypty. Żeby je uruchomić trzeba się było trochę pomęczyć:

yum install perl-ExtUtils-MakeMaker perl-SOAP-Lite perl-Crypt-SSLeay \
  perl-Test-Simple perl-XML-Simple perl-Text-Iconv  \
  perl-GDGraph perl-Image-ExifTool

Moduł Crypt::SSLeay jest potrzebny do obsługi https przez LWP. Do tego dociągnąć ręcznie, z braku odpowiednich paczek .rpm: XML-Parser-Lite-Tree-0.03, Flickr-API-0.08, Geo-Coordinates-DecimalDegrees-0.08.tar.gz.

Dodanie repozytorium livna:

rpm -ivh http://rpm.livna.org/livna-release-8.rpm \
rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-livna

Dużo wskazówek dotyczących instalowanie/konfigurowania FC8 można znaleźć na stronie: www.mjmwired.net

Dopisane 18 lutego 2008: Instalowanie FC8 na laptopie (HP nx 9020) zaczęło się niefortunnie, bowiem instalator całkowicie odmówił współpracy. Przeszukanie Google na tę okoliczność wskazywało, że problem jest podnoszony często a niektóre doniesienia brzmią dramatycznie. Już zacząłem wierzyć, że tak często raportowane na różnych forumach problemy sprzętowe i mnie w końcu dopadły, ale trafiłem na prosty opis co trzeba zrobić (por. Instalator Fedora 8 zatrzymuje się na laptopie):

floppy.allowed_drive_mask=0 clocksource=acpi_pm

I poszło bez problemu. Powyższy wiersz należy dopisać na pierwszym ekranie po uruchomieniu komputera z DVD Fedora 8 (przedtem wcisnąć Tab).

BTW: FC8 to już moja któraś tam wersja Linuksa. Zaczęło się w 1999 r. od RH5, potem było RH8/9, Fedora Core 4/5 no i teraz FC8. Innych wersji L-systemu nie używałem--przyzwyczajenie drugą naturą człowieka. Przed 1999 r. była epoka człowieka pierwotnego uzbrojonego w krzemień pn. system D:-).

Dopisane 20 lutego 2008: Na podstawie tego wpisu i poprzednich doświadczeń ze strojeniem FC5, przygotowałem dokument pn. Uwagi dot. instalowania Fedora Core 8.

Wczoraj na komputerze kupionym na Św. Mikołaja w zeszłym roku zainstalowałem Fedora Core 8. Wykorzystałem, że Elka wyjechała z Jasiem i Krzysiem na ferie do Habovki. Nie będę raczej z tego komputera korzystał, bo został kupiony dla dzieci -- chciałem sprawdzić jak mi pójdzie z instalacją.

Na dysku był już zainstalowany produkt MSC pn. Windows XP (dzieciom do gier potrzebny). Doinstalowanie FC8 poszło świetnie i zajęło circa 40 minut. Można sprawdzić na zdjęciach porównując wartości tagów Exif ze zdjęć obok. Jest Firefox, Pidgin, Thunderbird, OpenOffice. Czegóż więcej potrzeba 99% użytkowników PCtów? Pewnie będzie problem z aplikacjami do audio/wideo, no ale to już jest problem nie do przeskoczenia, bo natury prawnej.

Emacs pisze out-of-the-box w Unicode. Czas już sprawdzić, jak ten UTF działa w Linuksie.

Mój PCet się zepsuł. Co pewien czas się resetuje. Kol. Pacek przelutował kondensatory, ale to tym razem nie pomogło. Pomogło za to wyłączenie cache w BIOSie. Coś jest nie tak albo z procem albo z płytą. Teraz wprawdzie nie ma resetów, ale komfort pracy taki sobie. Już jestem umówiony z kol. Markiem na upgrade. Jak będzie nowy komputer, to wtedy pomyślę o upgrade do FC8.