Różowy blog
Ponieważ serwer SzLUUGa nie wiadomo czy wróci i nie wiadomo kiedy, to przeniosłem planetę. Nie wiadomo na jak długo planeta SzLUUG dostępna będzie tu (dead link). Poprzedni adres może się pojawi wkrótce (zobaczymy, czy przepną NSy). Ze zmian - odświeżanie co 20 minut. Sorry, ale sprzęt na którym to się generuje jest wooolny i na wooolnym łączu. Enjoy!
Właśnie dotrałem do mojego wpisu o rozczarowaniu szluug. Tak patrzę, jest blisko rok później i co? I jest gorzej. PL5 nie wiadomo czy i kiedy się odbędzie. Serwer jest martwy, backupów nie ma (o przepraszam, były robione na sąsiednią partycję na dysk o którym było wiadomo, że się sypie). I nie mówię o danych userów (bo to od razu jeden z adminów stwierdził, że nie było backupowane), tylko o backupach systemowych. Listy także nie działają. Na propozycję, żeby kliknąć statyczną stronkę (10 linijek kodu?) z informacją, kiedy strona i serwer będą dostępna usłyszałem, że może po świętach...
Właśnie stawiam planetę SzLUUGa gdzieś na boku. Tzn. raczej w ramach sprawdzenia, czy działa z backupu, bo produkcyjnie nie może być stamtąd serwowana, niestety.
Jeśli ktoś ma potrzebę używania komunikatora w trybie tekstowym (wygodny sposób, swoją drogą), to nie tylko opisany tutaj finch, czyli konsolowa wersja pidgina istnieje. Osobiście nie próbowałem fincha (głównie dlatego, że nie ma go w Debianie Etch, za to dałem szansę dwóm innym: mcabber i centericq.
Stało się faktem, to, co można było od dawna przewidzieć. Asus ogłosił, że będą produkowane eee PC w wersji z 9" monitorem. Większy ekran to nie jedyne zmiany. Ma też być szybszy i lepiej wyposażony.
Debianowe fortunki. Nie ma co pisać, trzeba zobaczyć.
Od dłuższego czasu miałem marzenie wizję projektu "planeta SzLUUG" wzorowanej na planet Debian. Miejsca, w którym będą zebrane blogi szluugowiczów i okolic. Sam
SzLUUG nie jest aktualnie zbyt aktywny (eufemizm ;)), ale i całkiem nie umarł, a sporo ludzi zajęło się ciekawymi (zawodowymi) sprawami
(niekoniecznie w Szczecinie). Poza tym,
miło mieć z nimi kontakt, wiedzieć, co się dzieje itd. Wczoraj odbyłem krótką naradę z miłościwie nam panującym prezesem, który stwierdził "chcesz
to rób". No to zrobiłem, jak umiałem (with the little help from my friends)...
Ponieważ ostatnio długo szukałem jednego z poleceń (skleroza nie boli, ale jak coś wyleci z głowy...) - oto lista nienajczęściej używanych, ale bardzo przydatnych poleceń systemu GNU/Linux Debian. Kolejność przypadkowa.
Lista będzie rozwijana. Proszę o inne przydatne polecenia (tylko bez mana tara, instrukcji obsługi vi itp.).
Wiele zupełnie innych, podzielonych na kategorie, bardzo przydatnych poleceń i tricków dostępnych jest na stronie z linuksowymi tips'n'tricks.
Domyślnie Java jest rozpowszechniana w wersji z ograniczoną siłą szyfrowania (zapewne niesławne ograniczenia dotyczące eksportu technologii krypograficznych z USA). Przeciętnemu użytkownikowi ciężko zauważyć różnicę, ale niedawno jeden z programów stwierdził, że hasło to może być do 8 znaków, albo muszę zdjąć limity w Javie.
Samo usunięcie ograniczeń polega na pobraniu ze strony Suna pliku zip z o nazwie Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 5.0 (tu: dla wersji 5.0 - jakoś do niej przywykłem, dla wersji 6.0 istnieje analogiczny plik) i rozpakowaniu go do stosownego katalogu, w przypadku Debiana i Javy zrobionej make-jpkg - do /usr/lib/j2re1.5-sun/lib/security/
Oczywiście nic nie stoi na przeszkodzie, by skorzystać z make-jpkg i zrobić paczkę z Javą, a następnie skorzystać z opisnego kiedyś sposobu i wprowadzić modyfikacje (tu: zmiana plików) w tejże paczce. Ponieważ tak jest elegancko i Debian way - polecam.
PS. Zamiast bawić się w samodzielne paczkowanie sunowskiej javy można skorzystać z pakietu sun-java5-jre i okolicznych znajndujących się w sekcji non-free oficjalnego repozytorium. Bez JCE, z tego, co widzę (i czasami bez update'ów od Suna, przynajmniej jakoś długo trzeba było czekać, ale jeśli nam to nie przeszkadza, to sposób dodania JCE jest analogiczny.
Przyszedł ten dzień, że Thunderbird padł. No, może nie do końca padł, ale coś się stało i to raczej po stronie Thunderbirda. W każdym razie stwierdził, że pobierze maile z serwera, jeszcze raz. Wszystkie. Czyli około 20 tys.Tak, tak, nie usuwam wiadomości z tego serwera po pobraniu. Tak, tak, wiem, że istnieje IMAP (co więcej, serwer go obsługuje). Ale jakoś na początku używania dodałem konto jako POP3 i tak zostało...
W każdym razie pojawiło się 'sporo' duplikatów, które do niczego mi nie są potrzebne. I okazuje się, że jest bardzo proste, miłe i przyjmne rozwiązanie tego problemu, a mianowicie nowa wersja rozszerzenia removedupes.
Co potrafi? Potrafi określić, czy maile się powtarzają, biorąc pod uwagę dane takie jak M-ID, czas wysłania, liczbę linii, temat i - najważniejsze - zawartość. Całość konfigurowalna (można wybrać wg. których kryteriów ma porównywać) i nawet szybka (no, poza folderem rekordzistą z około 20 tys. maili - to trwało dobrych kilkanaście minut).
A tak nawiasem, orinetujecie się, czy zmiana POP3 (z zachowaniem maili na serwerze) na IMAP (z trybem offline) jest w Thunderbirdzie bezbolesna (w sensie, czy zachowa filtry wiadomości, wysyłanie kopii itp. ustawienia)? Ew. jakieś inne wady IMAP (w wersjii offline)?
We wpisie o haśle dla screen mamy ładnie wyjaśnione jak założyć hasło dla aktualnego screena. Można jednak pójść o krok dalej i każdego uruchamianego screena zabezpieczać automatycznie hasłem (jednym, domyślnym).
W tym celu należy w .screenrc w katalogu domowym usera umieścić linijkę z zakodowanym hasłem:
# This is how one can set a reattach password: # password ODSJQf.4IJN7E # "1234"
Od tej chwili każdy nowouruchamiany screen będzie zabezpieczony hasłem.
Aby utworzyć zakodowane hasło naprościej użyć htpasswd:
htpasswd -n test
Podajemy hasło dwukrotnie, otrzymujemy ciąg w stylu
test:DgVb/mZOaJTVs
Od dwukropka mamy nasze zakodowane hasło, które umieszczamy w .screenrc.
PS. Oczywiście to tylko domyślne hasło, które zawsze można zmienić korzystając ze sposobu opisanego we wspomnianym linku
Załóżmy, że mamy pobrane z serwera ze źródłami na dysk pakiet.orig.tar.gz i pakiet.diff.tar.gz. Aby uzyskać efekt identyczy z wajig source pakiet czyli pobraniem pakietu i nałożeniem debianowych patchy, należy:
tar -zcf pakiet.orig.tar.gz && mv pakiet.orig pakiet && cp pakiet.diff.tar.gz pakiet/ && \ cd pakiet && zcat pakiet.diff.tar.gz | patch -p1 && \ rm pakiet.diff.tar.gz
Wersję z kopiowaniem i usuwaniem pakiet.diff.tar.gz można oczywiście łatwo obejść/uprościć. Drobna uwaga: _ (underscore) w nazwie tar.gz pakietu zamienia się na - (minus) w nazwie katalogu.
PS. Zwykle prościej dodać - choćby na chwilę - odpowiednie deb-src do sources.list
Często słyszę, że Firefox jest wolną przeglądarką. Tymczasem u mnie śmiga. Ale jak siądę do czyjegoś FF, to często mam wrażenie, że czas stanął. Wystaczy kilka prostych zabiegów, by FF działał/ładował strony znacznie szybciej:
1. Wyłączenie cache'owania stron w pamięci (about:config -> browser.cache.memory.enable zmieniamy na false). Dysk jest wystarczająco szybki w porównaniu z łączem internetowym, a RAM ma ważniejsze rzeczy do roboty, niż przechowywanie cache przeglądarki. Poza tym istnieje coś takiego jak systemowe bufory do obsługi dysku, które zrobią prawie to samo, FF nie zajmie 30% pamięci, a cały system (w tym FF) będzie działał żwawiej.
2. Instalacja i konfiguracja genialnego pluginu rozszerzenia Adblock Plus. W skrócie plugin ten rozszerzenie to blokuje wczytywanie reklam. W praktyce, pozwala blokować odwołania do serwerów z reklamami w ogóle, a wielokrotne małe odwołania potrafią spowolnić wczytywanie strony znacznie bardziej, niż pobranie nawet sporej reklamy reklamy, zwł. gdy serwer reklamodawcy jest przeciążony. Jeśli chodzi o filtry to korzystam z filtrów Dr. Evil plus parę własnych (warto poświącić parę minut na konfigurację i dodanie tego, co nam przeszkadza do blokowanych - słowa 'hit', 'stat', 'ad' powinny wzbudzać naszą czujność ;)). Nie dość, że szybciej, to czyteleniej, bo często reklamy przysłaniają elementy nawigacyjne na stronie.
3. Blokada pop-upów. W sumie standard w każdej przeglądarce. Wystarczy się upewnić, że jest włączona.
Po ww. zabiegach przeglądanie WWW powinno być znacznie przyjemniejsze.
Kod, który zawsze potrzebowałem i zawsze stosowałem workaroundy. Chodzi o rozrzucenie wartości do n tablic. Przydatne przy fork(), gdzie każdy proces dostaje do obróbki swoją tablicę. Poniżej przykład, jak ładnie, szybko i deterministycznie rozrzucić te wartości.
#!/usr/bin/perl -w use strict; my $na_ile=5; my @a=(); my $tmp=1; my %data=(); # generujemy tablicę ze 104 elementami for (my $i=1;$i<=104;$i++){ push @a,$i; } # rozrzucamy elementy tablicy @a na $na_ile tablic # $data{$tmp} to referencja do tablicy... foreach my $value (@a){ push @{$data{$tmp}},$value; print "wrzucam $value na $tmp\n"; $tmp++; if ($tmp >= $na_ile){ $tmp=1; } } # wyświetlanie foreach my $tabela (sort keys %data){ print "wyswietlam tablice nr $tabela\n"; foreach (@{$data{$tabela}}){ print "$_\n"; } }
Nawiasem, use strict i -w dla niewprawionego to wzywanie. ;/ Ale bez tego z fork() się nie poszaleje. ;)
echo $[1/2*100] echo $[100*1/2]
