Już od przynajmniej pół roku korzystam z mirrora http://ftp.sh.cvut.cz/ używając go przede wszystkim jako repozytorium dla paczek dla Arch Linux. Czasem korzystam z niego również do ściągnięcia np iso z Ubuntu itp. Naprawdę szybki i często aktualizowany mirror. Co do transferów, to rzadko kiedy nie osiągam maksimum downloadu swojego łącza, które wynosi ok 25-30Mb/s.

Na szybko, przykładowe adresy:

do wrzucenia do mirrorlist w Arch Linux (dla wersji x86_64)
Server = http://ftp.sh.cvut.cz/MIRRORS/arch/$repo/os/x86_64

ISO Ubuntu
http://ftp.sh.cvut.cz/MIRRORS/ubuntu-releases/

Mirror udostępnia paczki również m.in. dla Ubuntu i Debiana, więc można spróbować dodać go do  sources.list

Przez dość długi czas miałem problem z działaniem picasa pod ArchLinux, który objawiał się tym, iż po próbie zalogowania do konta w google program natychmiast kończył swoje działanie. Tak samo działo się w momencie, gdy naciskany był przycisk upload- po próbie zalogowania również picasa się wyłączała. Niestety w żaden sposób nie znajdowałem powodów takiego zachowania, w logach nie znajdowałem żadnego wytłumaczenia. Uruchamianie programu w konsoli też nie dawało żadnych informacji z tym związanych. Dopiero użycie jakiejś inne wersji, bodajże z paczki deb z Ubuntu pomogło w zdiagnozowaniu przyczyn problemu. Okazało się, że w tej wersji pojawia się komunikat odnośnie braku 32bitowych bibliotek openssl. Już myślałem, że po problemie, ale okazało się, że lib32-openssl jest jak najbardziej już zainstalowany. Raz jeszcze zainstalowałem paczkę, ale bez efektu… Znów zabawy i szukanie „winnego”, ale bez skutku. Stanęło na tym, że może paczka z lib32-openssl jest źle zbudowana. Innej przyczyny nie widziałem, tym bardziej że w AUR tylko jedna osoba oprócz mnie narzekała na picasa Okazało się, że tak właśnie było… Pozostali musieli mieć „starszą instalkę” Archa i akurat tego problemu nie mieli, gdyż brakującą u mnie bibliotekę zainstalowali we wcześniejszej wersji lib32-openssl. Innego wytłumaczenia nie widzę. Co zrobiłem?

Ściągnęłam http://www.archlinux.org/packages/core/i686/openssl/download/ paczkę z openssl dla Archa 32bit, rozpakowałem a pliki: libcrypto.so libssl.a libssl.so.1.0.0 libcrypto.a libcrypto.so.1.0.0 libssl.so  skopiowałem do /usr/lib32/

No i zadziałało Taka pierdoła, a nie ukrywam że sporo czasu mi zajęło szukanie rozwiązania u wujka google.

arch

Po około 2 miesiącach użytkowania Arch Linux w wersji dla procesorów 64 bitowych, mogę zapytać o jedno: „czemu do cholery tak późno”?

Pierwotnie obawy moje wiązały się z kompatybilnością softu pod tę właśnie architekturę, później z biegiem czasu odwlekałem zainstalowanie tej wersji ze względu na czas, a właściwie jego brak. Argumentowałem sobie to tym, że po co mam poświęcać czas na stawianie systemu od nowa, skoro (ponoć) nie odczuję różnicy w wydajności między i686 a x86-64? Tak przynajmniej wynikało z tych opinii, z którymi się zetknąłem.

W pewnym momencie stwierdziłem jednak, że mając 4GB RAm chciałbym, aby miało ono szanse na teoretycznie pełne wykorzystanie. W wersji na i686 jest co prawda możliwość wybrania opcji obsługi większej ilości pamięci RAM przy kompilacji kernela, ale to nie to samo… Poza tym, jakoś minęły czasy gdy miałem ochotę na to, aby każdą nową wersję kernela kompilować samemu . Hmmm, ok skłamałem- może i podłubałbym w configu, ale permanentny brak czasu uniemożliwia to skutecznie.

Dobrze jest mieć odpowiednio podzielony dysk na partycje- reinstalacja lub instalacja systemu „obok” jest bardzo łatwa, szybka i wygodna. Wystarczy w pewnym momencie ustawić punkty montowania i  cały ~HOME jest już w… domu . Instalacja przebiegła bardzo szybko. Później tylko skonfigurować Archa instalując przy tym wszystko co potrzebne.

No i tu okazuje się, że stabilność Linuksa i jego odporność na prewencyjne, albo z konieczności wykonywane „windowsowe reinstalowania” może nieść za sobą negatywne skutki . Tak, jest to możliwe :].
Ileż rzeczy pozapominałem od ostatniego instalowania Archa… Oj dawno tego nie robiłem i musiałem momentami pomyśleć, aby sobie przypomnieć/ skojarzyć, co i jak trzeba zainstalować i jak skonfigurować, aby działało tak jak mi się podoba. Nie ukrywam, że to spory argument przeciwko Archowi, ale na Boga! Ileż ja razy muszę go instalować? Raz „postawiony” na nogi działa miesiące… lata.

Może to jakieś zboczenie, ale bardzo mi się podoba instalacja Archa, gdyż poniekąd stanowi ona wyzwanie, ale nie dlatego że wynika ona z trudności związanej z  niewiedzą, ale z tego, że Arch daje olbrzymie spektrum możliwości wpływu na proces instalacji i konfiguracji i czasem okazuje się być czasochłonnym.

Teraz pozostaje ocenić x86-64 . Przyznam szczerze, że jakiejś wielkiej różnicy nie widzę. System działa niemal bez zarzutów, szybko i wydajnie. No może jest nieco lepiej niż na i686, ale to na prawdę minimalne różnice i na pewno nie są one zauważalne poprzez zwykłe korzystanie z komputera. Jedynym zauważalnym problemem jest to, że dość często wtyczka do flash w przeglądarce potrafi wyzionąć ducha, wymagając wtedy od użytkownika ponownego uruchomienia przeglądarki.

Pakietów na x86-64 w Archu jest cała masa i na pewno nie ma jakichś szczególnych braków względem repozytoriów dla i686. Podobnie jest w AUR, choć mam takie dziwne wrażenie, że dla niektórych pozycji jest większy wybór wersji niż w i686.

Na koniec dodam, że od kilku wersji kernela, korzystam  z edycji jądra bfs. W tym momencie mam kernel26-bfs 2.6.35.7-350

Jak na datę wydania kernela, to paczka w AUR z łatkami wydana została bardzo szybko. W sumie system z tym kernelem mam wrażenie, że działa odrobinę szybciej. Zobaczymy jak kolejne edycje bfs.

Ciekaw jestem kiedy tym razem podziękuję za współpracę i wrócę do KdeMod3. Do tej pory robiłem to od razu, tym razem nie widzę ku temu przesłanek.

Muszę przyznać, że zdziwiłem się pewną kwestią, a mianowicie integracją ze środowiskiem pewnych programów. Jako przykład daję Alunn- w momencie, gdy znajduje nowe pakiety w repo informuje o tym fakcie wyświetleniem stosownej informacji na pulpicie i w trayu. Może i zbyteczna rzecz, ale działa przyjemnie, co istotniejsze świadczy o tym, że twórcy softu rezygnują z  kompatybilności z kde3 (w kde3  nie działał u mnie ten program w taki sposób).

Nieuchronne chyba się zbliża- migracja do KDE4 stanie się koniecznością- patrz info od Patricka Volkerdinga (opiekuna Slackware). Środowisko Linuksa zaczyna się klarować w tej kwestii.

Jeśli tylko będzie działać minimum tak jak KDE3 to nie mam nic przeciwko temu- ot rozwój (oby).

Dość szybko zauważyłem nieprzyjemną przypadłość związaną z działaniem dysku. Mianowicie, co jakiś czas tak jakby się wyłączał i niestety np. kopiowanie było przerywane. W sumie to jeszcze przy kopiowaniu danych źle nie było. Gorzej gdy oglądałem jakiś film z dysku zewn. Wtedy to można się było nieźle zirytować… Sporo szukałem na ten temat w necie, ale nic konstruktywnego i pomocnego nie znalazłem, no może poza jednym wątkiem, który dość negatywnie wpłynął na me odczucia. Dobijający był umieszczony na tej stronie link.
Teraz na koniec coś pocieszającego

Do dnia dzisiejszego korzystałem z kernela 2.6.27.10. Rano uruchomiłem dystrybucyjny Arch linux 2.6.28.x. Może jeszcze zbyt mało czasu upłynęło, aby definitywnie oceniać stan rzeczy, ale w ciągu kilkunastu godzin intensywnego wykorzystywania dysku nic się złego nie działo.

Zobaczymy jak będzie dalej.

Wiem ze argumentów mało, a właściwie brak. Ot subiektywne moje odczucie i nic poza tym.

Tym razem skusiłem się nowym kernelem, który w ARCHu póki co znajduje się w repozytoriach w „testing”. Już był w tej gałęzi repozytorium jakiś czas, ale jakoś nie chciało mi się testować
Postanowiłem dziś sprawdzić co nowego w kwestii b43.

Pierwsze wrażenie było dość pozytywne, gdyż moduł załadował się bezboleśnie no i co najistotniejsze dość szybko udało się uruchomić wifi. Interfejs wstał zdecydowanie szybciej, aniżeli w przypadku wcześniejszych mych prób z tym modułem. Nie było to co prawda tak szybko jak w przypadku ndiswrapper, ale da się przeżyć. W takiej sytuacji zmieniłem swój rc.conf i dodałem uruchamianie wifi poprzez moduł b43. Po restarcie uruchomiło się wifi bez problemów- od razu po starcie KDE był internet. Myślałem już, że b43 zagości u mnie na lapku, ale… sprawdziłem hibernacje. Za pierwszym razem próba zakończyła się ponownym uruchomieniem lapka, ale Xy zawisły…
Druga próba po wymuszonym przez „zwis” restarcie i Xy wstały, ale internet nie działa. Być może kwestia conf do hibernacji, ale w związku z tym, że przy ndiswrapper działa, to póki co nie bawię się w to dalej. Jak znów będę mieć trochę czasu, to poszukam i może coś w tej materii znajdę, co rozwiąże problem. Może potrzebny jest tylko jeden konkretny wpis do conf od hibernacji.

Reasumując.
Progress jest, ale chyba jeszcze to nie jest docelowo to czego wymagałbym…
Kernel 2.6.25 (potestuję sobie) rzecz jasna zostaje, ale b43 (jeszcze) nie.

Po jakimś czasie wyszła beta5, również zainstalowałem. Muszę przyznać, że zauważalny jest istotny progres co do szybkości działania przeglądarki oraz jakby mniejsze wykorzystanie pamięci.

Nic tylko czekać na wersję stable .

Kilka zrzutów z programu:

Jakby ktoś chciał przetestować shamana, to zbudowałem dziś (07-4-2008) nową paczkę:
shaman-svn-669-1-i686.pkg.tar.gz

P.S. Zna ktoś jakieś (bezpłatne) dobre i wygodne miejsce gdzie można byłoby np. taki plik sobie wrzucić na serwer?