Był jasny, choć prawdopodobnie dosyć chłodny dzień. Stałem na dosyć dziwnym peronie. Choć dalsze wydarzenia sugerują, iż musiał to być peron kolejowy, to wyraźnie pamiętam, że z samego początku podchodziłem do stojącej na nim wiaty, zupełnie jak na przystanku tramwajowym. Być może była tam również barierka, taka oddzielająca przystanek od jezdni.
W zasadzie to miałem już zatopić się we własnych myślach i stracić kontakt z rzeczywistością, kiedy nagle wydarzyło się coś niezwykłego. Nie wiem, czy to ona podeszła do mnie, czy to ja do miejsca, w którym ona stała. Odezwała się do mnie, lecz nie dosłyszałem wszystkiego — być może dlatego, że owy kontakt z rzeczywistością miałem już tracić. Z całą pewnością pojawiło się tam jednak nazwisko.
W przeważającej liczbie uczelnie oraz inne instytucje, udostępniające większym grupom klientów dostęp do Sieci, mają skłonność do wprowadzania dosyć prymitywnych ograniczeń w korzystaniu z niego — jak np. bezmyślne blokowanie połączeń wychodzących na większość portów. Jakkolwiek należałoby je pochwalić za to, że wśród dozwolonych portów znalazł się używany standardowo przez SSH, to jednak we współpracy z typowo zabezpieczonym serwerem na niewiele nam się zda.
Jednym bowiem ze skuteczniejszych, choć niezwykle prymitywnych, sposobów zabezpieczenia serwera przed floodowaniem za pomocą prób logowania jest wykorzystanie niestandardowego portu. Jak więc ukrywać serwer SSH przed światem, nie blokując jednocześnie dostępu samemu sobie?
Standard UPnP IGD stanowi całkiem sympatyczne rozwiązanie dla użytkowników korzystających z NAT-owanego dostępu do Internetu. Można wręcz posunąć się do stwierdzenia, że w tego rodzaju sieciach uzupełnia DHCP, umożliwiając wygodne i dynamiczne zarządzanie wpisami DNAT (czyli popularne „przekierowywanie portów”).
Wbrew pozorom, rozwiązanie takie sprawdza się nie tylko w amatorskich sieciach, gdzie administrator chce oszczędzić sobie wysiłku dodawania wpisów. Przekierowania dynamiczne sprawdzają się również w sytuacjach, gdy przyjmowanie połączeń jest potrzebne jedynie przez krótką chwilę (np. aktywne FTP) czy serwer danej usługi „przemieszcza się” (wraz z użytkownikiem) między wieloma komputerami.
Jednym z bardziej zawiłych i niejasnych zagadnień związanych z HTML-em jest osadzanie zawartości multimedialnej na stronach internetowych. Stopień niewiedzy webmasterów w tej kategorii wręcz zaskakuje; brak rzetelnych i konkretnych informacji — jeszcze bardziej.
Nie ukrywajmy, że typowy przypadek webmastera, mając zamiar zamieścić na stronie internetowej film, najprawdopodbniej skorzysta z jednego z ogólnodostępnych serwisów hostujących takowe lub też wrzuci go wraz z jednym z odtwarzaczy we Flashu. Przy tym nie przejmie się szczególnie sposobem osadzenia go — skorzysta z gotowego, wygenerowanego kodu.
Dlatego też postaram się dziś przyjrzeć bliżej poszczególnym aspektom i metodom osadzania zawartości, ich relacji ze standardami i rzeczywistością, a także błędnymi przekonaniami cieszącymi się niemałą popularnością.
Podczas swojej długotrwałej współpracy z Gentoo miałem przyjemność (i nieprzyjemność) pracy z wieloma różnymi systemami budowania. Pomimo znacznych różnic, zarówno w aspektach stricte technicznych, jak i ogólnoideologicznych, wszystkie z nich łączyła pewne wspólna cecha — powolny wariant configure.
Jakkolwiek i w tej kwestii można napotkać wyraźne różnice w wydajności. Pomimo podejmowania różnych rozwiązań, mających na celu (i uzyskujących) przyspieszenie wykonywania tego procesu, nadal nie wykorzystano wszystkich możliwości. Dlatego też postanowiłem zająć się własnym rozwiązaniem w tej kwestii.
System budowania oparty o narzędzia GNU autotools cieszy się znaczną popularnością wśród wszelakiego oprogramowania na systemy uniksopodobne. Dostarcza sporą garść metod, umożliwiających budowanie oraz instalowanie aplikacji w sposób adekwatny do środowiska, a także znacznie ułatwiających tworzenie przenośnego kodu (chociażby poprzez skrypty configure).
Można wręcz powiedzieć, że cała idea autotools kręci się wokół szeroko rozumianej przenośności. Stąd też wynika inny problem — konieczność utrzymania wewenętrznej przenośności kodu, a więc i korzystania z ograniczonego zestawu narzędzi. Dlatego też skrypty configure to najprostsze skrypty powłoki, a cały proces budowania wykorzystuje tylko make.
Słownik języka polskiego PWN definiuje czasownik uwierzytelnić
następująco: uczynić coś wiarygodnym; stwierdzić autentyczność dokumentu lub podpisu […]. W Internecie,
sieci otwartej praktycznie dla każdego, potrzeba uwierzytelniania jest wszechobecna.
W praktyce najczęściej uwierzytelnianie
upraszcza się do stwierdzenia tożsamości, jako powiązanej z konkretnym
profilem czy kontem, i upoważnionej do zarządzania nim. Może to być prosta skrzynka pocztowa, dedykowane konto
użytkownika na komputerze czy prosty profil w obrębie serwisu WWW. Ja chciałbym skoncentrować się dziś na ostatnim
z tych aspektów.
Od jakiegoś czasu na naszym pięknym IRC-u (#qwpx) przebywa
zaciekły fanboj systemów z rodziny Windows, zwany x3nU. Jednym z jego podstawowych zarzutów wobec Linuksa jest to,
iż nie posiada on jednego (wymuszonego) systemu zarządzania kodekami
jak Windows. Pomińmy jednak już
zasadność jego argumentów
czy ich wewnętrzną sprzeczność (bo w końcu DirectShow i VfW to dwie różne implementacje).
Postanowiłem postawić mu wyzwanie, mające udowodnić, że kodeki dla Windows są w stanie zdziałać tyle samo, ile jeden,
najzwyklejszy mplayer. Zasady całkiem proste — on dostaje ode mnie trzy krótkie filmiki, zakodowane w różnych formatach,
które mplayer jest w stanie odtworzyć od ręki
. Jego zadanie polega na odtworzeniu ich tylko i wyłącznie za pomocą
kodeków DirectShow lub VfW (innymi słowy, mplayer czy VLC odpada).
Od dłuższego czasu jestem posiadaczem telefonu Motorola ROKR E6, standardowo wyposażonego w oprogramowanie oparte o zmodyfikowaną wersję Linuksa 2.4. Wbrew pozorom, zastosowanie takiegoż jądra na telefonie nie gwarantuje w pełni bezproblemowej współpracy z systemami opartymi o standardową wersję Linuksa 2.6. Dlatego też dzisiaj chciałbym poruszyć większość związanych ze współpracą tegoż telefonu z komputerem, a w szczególności na kwestii udostępnienia telefonowi dostępu do Internetu (również za pośrednictwem Bluetooth).
Przestrzeń wymiany powszechnie rozumiana jest jako swoiste poszerzenie pamięci; zapasowy obszar na dysku, w którym umieszczane są dane, które nie mieszczą się w pamięci operacyjnej. W myśl tego, swap byłby właściwie używany jedynie w przypadku całkowitego zapchania RAM-u, co na komputerze wyposażonym w 2 GiB pamięci operacyjnej nie wydaje się zjawiskiem osiągalnym w trakcie normalnego użytkowania. Stąd wielu użytkowników dochodzi do wniosku, że swap jest zupełnie zbędny. Czy słusznie?