jeśli korzystacie z ssh z pewnością zdarzyła się wam przynajmniej jedna z tych sytuacji:

1. musicie się gdzieś połączyć gdzie i tak już macie nawiązaną sesję, po to by wykonać jedno polecenie. np. : ssh root@maszynka uptime
2. musicie uruchomić wiele połączeń w jedno miejsce (konto, host, port)

do tego typu sytuacji idealnie nadaje się "connection multiplexing", znany też pod nazwą "connection sharing".
jak to działa?
jedno (pierwsze, ale nie koniecznie) połączenie ssh łączy się w trybie "master". następne połączenia w to samo miejsce używają połączenia master. dzięki temu korzystają (wszystkie) z tylko jednego połączenia tcp/ip., nie tracą czasu na negocjacje tcp/ip i ssh, ani na powtórną autoryzację.
efekt? następne połączenia są znacznie szybsze. w rozumieniu – samo połączenie. praca potem już jest ze standardową prędkością – zależną od tego jak daleko jest zdalny serwer i jak obciążone jest łącze.
ale czasem to właśnie nawiązanie połączenia jest najbardziej wkurzające i powolne.
jak więc to zestawić?
w swoim katalogu domowym macie (albo nie macie, ale wtedy trzeba założyć) katalog .ssh.
w nim trzeba stworzyć plik config. i dopisać mu na początku:
Host *
    ControlPath ~/.ssh/socket-%r-%h-%p
    ControlMaster auto

co to spowoduje? pierwsza linijka mówi, że poniższe tyczą się wszystkich połączeń.
druga – mówi, że sockety unixowe do komunikacji z połączeniem master mają być tworzone w katalogu $HOME/.ssh, a nazwa pliku ma się składać z:

• słowa "socket"
• nazwy konta na które jest połączenie
• nazwy hosta na które jest połączenie
• numeru portu na które jest połączenie

oddzielone myślnikami.
czyli gdy połączę się na konto "depesz" na maszynie kotek, to pojawi mi się taki plik:
srw——- 1 depesz depesz 0 2007-01-17 11:15 /home/depesz/.ssh/socket-depesz-kotek-22
ostatnia linijka mówi ssh, że negocjowanie połączeń lub korzystanie z mastera ma być automatyczne – jak nie ma jeszcze mastera, to aktualne połączenie ma być masterem i stworzyć socket. jak już jest master, to korzystamy z niego.

co nam to daje? przeprowadzę krótki test.
najpierw, bez mastera, połączę się na maszyne w swoim lanie i wykonam uname'a:

=> time ssh kotek uname

Linux

real    0m0.532s

user    0m0.032s

sys     0m0.000s

to teraz połączę mastera i ponowię test:

=> time ssh kotek uname

Linux

real    0m0.036s

user    0m0.020s

sys     0m0.004s

nieźle, nie? a trzeba pamiętać, że im dalej tym "szybciej" całość zadziała.
np.: do kotka mam ping w okolicach 1ms. do maszyny web którą zaraz potestuję, mam ping 12ms.
efekty?
bez mastera:

=> time ssh web uname

Linux

real    0m1.579s

user    0m0.048s

sys     0m0.004s

z masterem:

=> time ssh web uname

Linux

real    0m0.154s

user    0m0.016s

sys     0m0.000s

czy to wszystko jest "za darmo"? nie ma wad?
ma jedną, drobną.
pierwsze połączenie automatycznie staje sie masterem. i nawet jak się wylogujemy ze zdalnego hosta, to nie odzyskamy terminala, bo połączenie musi być cały czas aktywne – do czasu aż wylogujemy się ze wszystkich sesji ssh otwartych w tym połączeniu.
czyli jeśli:
na jednej konsoli zrobię ssh kotek, to to połączenie staje się masterem
na drugiej konsoli robię ssh kotek, to korzysta z połączenia mastera. odpalam tam sobie coś trwającego długo – np. backupy. to nie mogę zamknąć połączenia 1 dopóki się 2 nie skończy.
nie jest to wada wielka. trochę gorsze jest to, że jeśli zerwę (np. kill'em) pierwsze połączenie – to padają wszystkie.
to dwie wady. zyski w/g mnie mocno przeważają.
polecam każdemu zobaczenie jak to działa. warto.

drm – digital rights management.
ogólna nazwa tycząca się jakichkolwiek metod służących ochronie praw autorskich lub intelektualnych do utworów, tekstów oraz innych "obiektów" zapisanych w postaci cyfrowej.
najsłynniejsze przypadki do css (dvd-css) – system zabezpieczeń dvd, różnego rodzaju drm'y w sklepach z mp3 (np. w itunes) czy software do drm od sony który instalował w systemie rootkita i który kosztował sony ponad 15 milionów dolarów w odszkodowaniach.
czemu o tym piszę? bo alan cox – osoba dosyć znana wszystkim zainteresowanym rozwojem linuksa – jako jądra systemu, zgłosił drm jako technikę którą chce opatentować. oficjalny wniosek został złożony, czekamy na to czy patent zostanie przyznany.
po co patent? dzięki temu alan będzie mógł trzymać "w szachu" wszelkiego rodzaju firmy (riaa/mpaa/…) które chciałyby kiedykolwiek wykorzystać jakieś patenty przeciwko linuksowi.

jak przy większości zagadnień technicznych tak i przy kwestii anonimowości jest wiele punktów widzenia i wiele opinii.

• na samym początku ludzie czują się bezpieczni, bo skąd ktoś ma wiedzieć, że "jozia17@onet.pl" (adres zmyśliłem, mam nadzieję, że nie trafiłem w niczyj 🙂 to józia krakowiak, mająca 17 lat i mieszkająca w opolu?
• potem, ludzie już wiedzą, że z adresu maila czy nagłówków można wiele wydobyć informacji, połączyć kilka informacji z różnych stron google'em i już mieć wszystkie potrzebne dane
• potem mamy ludzi którzy myślą, że jak zmieniają adresy email i mają dynamiczne ip to są anonimowi
• następna grupa wie, że dynamiczne ip nie zabezpiecza anonimowości, a w szczególności, że 90% ludzi z grupy poprzedniej nie potrafi korzystać z tego "zabezpieczenia"
• następna (ostatnia, z mojego punktu widzenia, ale może ktoś mi udowodni, że są następne grupy) grupa – ludzie wiedzą, że anonimowość da się uzyskać, ale nie jest to trywialne i wymaga trochę pracy.

jednym z celów uzyskania anonimowości w sieci jest wysyłanie maili i/lub postów na grupy newsowe w sposób uniemożliwiający wykrycie nadawcy.
przyczyny tego typu zachowania mogą być różne. część z nich jest nie-fajna, ale część całkowicie legalna i sensowna.
jedną z metod (i chyba najprostszą w warunkach "domowych") do wysyłania anonimowych maili i postów na newsy jest korzystanie z usług tzw. remailerów. służy do tego protokół mixmaster i jego bazowa implementacja – pod tą samą nazwą.
nie wdając się w szczegóły techniczne – mixmaster zapewnia wystarczający poziom bezpieczeństwa do olbrzymiej większości zastosowań.
o tym ja go skonfigurować – można przeczytać w dzisiaj opublikowanym poście na debian administration – tekst jest po angielsku, ale wydaje mi się, że nie będziecie mieli problemu ze zrozumieniem.

nie wiem. czy ja jestem jakiś lewy?
mam od jakiegoś już czasu (rok albo dwa) kompa z karta telewizyjną, wyjściem s-video z grafiki.
i ni cholery nie potrafię tego skonfigurować.
dziś usiadłem. uzyskany efekt – działa mi radio (karta tv ma też radio). ale:

1. tylko pod programem kradio. tzn. jak odpalę kradio, to potem mi pod np. tekstowym "radio" też działa. ale bez odpalenia kradio – nie bangla.
2. strasznie cicho
3. szumi

poczytałem, pokombinowałem z kilkoma ustawieniami parametru tuner= do saa7134. i co? i gówno. karta działa tak samo na wszystkich "tunerach". bez sensu.
chciałem zrobić wyjście z nvidii na telewizor. zero efektu. poczytałem jakieś strony, pokombinowałem – zero efektu.
oczywiście mogę założyć, że jestem jakiś ułomny. i dlatego mi nie działa.
ale mam jakieś takie wrażenie, że pod windowsami sprawa zamknęłaby się w kilku kliknięciach. i byłoby po sprawie – wszystko by działało tak jak chcę i kiedy chcę.
czy znacie kogokolwiek kto byłby w stanie pomóc to skonfigurować?
na pytanie podobne na newsach dostałem kiedyś tonę informacji: poszukaj w google'ach. fajnie. google zwraca tysiące trafień. wszystkie są albo przeterminowane i nie działają, albo zawierają prostą treść: poszukaj w google'ach.
robię się poniekąd zdesperowany – jestem gotów zapłacić by wreszcie móc korzystać z kupionego sprzętu. zastanawiam się wręcz czy migracja na windows nie byłaby najprostszym i najtańszym rozwiązaniem.

jak większość programistów wie, systemowy (glibcowy) malloc jest delikatnie sprawę ujmując zbyt ogólny. mniej delikatnie – do niczego.
sprawdza się przy programach gdzie wydajność nie jest kluczowa.
problem jest znany. część projektów pisze własne wersje malloca – przykładem chociażby postgres i jest palloc.
jak mi donieśli zaprzyjaźnieni admini google wypuścł, a kolesie od wikipedii przetestowali, nową wersję malloca. ta – napisana przez google'a, nazywa się tcmalloc i jest dużo szybsza. można obejrzeć np. spadek zajętości procesora przez squidy zrekompilowane z tcmalloc'iem – różnica powala.
tcmalloc jest całkowicie bezstresowym zastępnikiem do standardowego malloca. można go alko zlinkować przy budowaniu, albo zaladować przy pomocy LD_PRELOAD.
polecam przyjrzenie się temu – wygląda mocno obiecująco.

podobno (to jeszcze nie jest chyba potwierdzone) w następnej wersji linuksa – 2.6.20 ma być włączona (do źródeł) wirtualizacja!
samo w sobie jest to dosyć szokujące. jeszcze bardziej szokujące jest to, że nie będzie to żaden ze znanych i uznanych systemów wirtualizacyjnych – nie xen, bochs, vmware.
będzie to kvm. no właśnie. co to jest kvm?
kvm jest dziełem małej, działającej poniekąd w ukryciu firmy izraelskiej, finansowanej przez dwa znane fundusze vc – sequoię i norwest'a.
ich produkt jest mały. działa jedynie w oparciu o wirtualizację sprzętową (to dosyć dziwne, bo jak kolesie od xena pokazali jakiś czas temu wirtualizacja sprzętowa jest wolniejsza od software'owej). nie potrafi wszystkiego tego co potrafi np. xen.
za to potrafi uruchamiać na maszynach wirtualnych standardowe, niemodyfikowane linuksy czy windowsy!.
podobno.
co z tego wyjdzie – zobaczymy. martwi mnie trochę fakt iż nie ma 2.7 gdzie tego typu pomysły byłyby całkiem na miejscu i miejscem do zabawy jest 2.6. używany przez wielu produkcyjnie.

na wypadek jakby was ominęło.
andrew morton – poprosił o patcha na kernel który zablokuje możliwość ładowania zamkniętych (nie-gpl) modułów. patch dostał.
idea jest taka, że patch zostanie włączony teraz, ale przez rok będzie tylko wyświetlał informację, że ta funkcjonalność (ładowanie binarnych modułów, nie będących na licencji gpl) będzie niedługo wyłączona.
rozpętała się dyskusja. w dyskusji wziął też udział linus stwierdzając, że pomysł jest głupi, on go nie popiera i nie w-merguje do źródeł linuksa. i jeśli oponenci chcą – niech przekonują swoich szefów i działy prawne w swoich firmach (chodzi głównie o rozmaite dystrybucje linuksa) – aby to te firmy same włączały tego patcha w swoje dystrybucyjne jądra.
wizja mortona trąci mi stallmanizmem – stallmana ogólnie nie znoszę i uważam za najgorsze co mogło sie przydarzyć idei open source (wiem, że on to stworzył, ale po prostu nie trawię kolesia i jego wygiętych poglądów).
i cieszę się, że linus po raz kolejny ukazał swoje zdroworozsądkowe podejście. mam nadzieję, że póki on to wszystko firmuje swoim imieniem (i nazwiskiem) to tego pomysły będą ukręcane zanim ktoś błyskotliwy inaczej wstawi patcha w jądro wykrywając, że korzystamy z softu na "złej" licencji.

artykuł na ten temat napisał w serwisie osnews niejaki dmitri czarkoff – jeden z użytkowników (i chyba developerów) openbsd i freebsd.

czemu nie odniesie sukcesu? no cóż – nie chcę zdradzać treści – po prostu przeczytajcie.

teza na pewno jest kontrowersyjna, ale muszę przyznać, że “coś w tym jest" – co prawda nie wiem czy rozwiązanie kwestii przyniesie rok 200x, ale może się to okazać bliższe niż myślimy.