-ENOTTY

Zgodnie z art. 64 par. 2 KPA UOKiK nie ma obowiązku reagowania na pisma anonimowe 9 brak adresu - miejsca zamieszkania)

Taką odpowiedź dostałem po tygodniu od wysłania zapytania o znalezioną w skrzynce ulotkę firmy, o której piszą na http://www.uwagakomputery.pl.

Oczywiście w mailu, który skierowałem do Urzędu Ochrony Konkurencji i Konsumentów znajdowało się zarówno moje imię, jak i nazwisko i adres email. Dodatkowo, jak wszystkie moje maile ostatnio, całość podpisana była podpisem elektronicznym. I miała czytelne nagłówki prowadzące wprost do mnie.

Ale wg. urzędu była to przesyłka anonimowa.

Nawiązując do naszej rozmowy w klubie:

• dostawcy mediów kontrolują zmiany w Windows Vista. Czyli cały ruch mediów po szynie PCI Express ma być szyfrowany. I MS musi się na to zgodzić, inaczej nie będzie filmów ani muzyki na Viście. Legalnych. Z wypożyczalni sieciowych.
• Lista zmian w Viście jest dłuższa i ciekawsza:
  • Microsoft Trusted Computing Updates
  • The Dangers of Device Authentication
  • Protected Media Path, Component Revocation, Windows Driver Lockdown
• Mamy złącza cyfrowe DVI, teoretycznie bezstratne. Ale też niebiezpieczne. Na szczęście za rogiem czai się High-Bandwidth Digital Content Path. To DVI opakowane w mniejszą, wygodniejszą wtyczkę, dodatkowo od razu z dźwiękiem. I zabezpieczeniami DRM - już sobie nie nagrasz.
• Masz podłączony magnetowid do DVI, bez DRM? Karta graficzna z radością ci wyłączy to gniazdo w trakcie odtwarzania zabezpieczonego filmu. Albo wyświetli napis ,,Podłącz do HDCP, bo nie obejrzysz!''. Zmienisz BIOS karty graficznej, żeby tak nie robił? Proszę bardzo, sygnatura nie będzie się zgadzała z tym co podpisał cyfrowo MS -> do karty nie zostanie wysłana nawet jedna klatka filmu.
• when Windows Vista ships (and Apple's next OS), most people won't be able to watch protected HD content on their computers
• A co jeśliby zamiast BIOSu była maszyna wirtualna wyłączająca dostęp do karty graficznej i innych komponentów?

To ostatnie to oczywiście spekulacje. W dzisiejszych czasach takie zabezpieczenia można obejść nawet edytując kod maszynowy zawartego w pamięci procesu przyznającego uprawnienia. Ale gdy chipy DRM się upowszechnią, może zabraknąć fizycznej możliwości modyfikacji.

Xbox Microsoftu był zabezpieczony -- co prawda kiepsko, ale przełamanie tych zabezpieczeń wymagało wpięcia się między mostek północny i południowy (teraz wiem, po co się VHDLa uczyłem, hehehe). A teraz mostek północny integrowany jest w procesorze, coraz więcej rzeczy będzie gdzieś zaszytych. I nie będzie gdzie się wpiąć. Zresztą zobaczymy, jaką architekturę zademonstruje Intel w tym tygodniu. Może to będzie coś na kształt intelowskich procesorów sieciowych, z jednym rdzeniem przeznaczonym do szyfrowania całego ruchu wychodzącego z CPU.

W listopadzie zaś hackerzy dostaną do zabawy Xboxy 360. I wtedy może dowiemy się więcej o tych wszystkich zabezpieczeniach. Długość życia konsoli to około 5 lat. W tym czasie ma szansę nawet pojawić się kolejna wersja MS Windows. Xbox 360 oczywiście musi być kompatybilny zarówno z Vistą, jak i kolejną wersją. A że ma być domowym centrum rozrywki, musi być kompatybilny ze wszystkimi DRMami. I to co najmniej na pięć lat.

A jak to wszystko zaimplementować w wolnym oprogramowaniu?

W wolnej chwili zrobiłem dzisiaj reboot i narysowałem przebieg uruchamiania systemu:

I co widać? Od załadowania jądra do chwili kiedy mogę się zalogować mija aż 45 sekund. Pierwsze piętnaście nie dzieje się nic sensownego - uruchamia się jądro i programy zawarte w initrd. Czyli lvm vgscan i vgchange. Przed uruchomieniem inita następuje zamountowanie /. I na to mija najwięcej czasu - na oko coś koło 10 sekund (!!) trwa zamountowanie 177 GB ReiserFS'a. Wg. mnie coś jest nie tak, sprawdzanie journala nie powinno tyle trwać. Ale nie wiem co z tym zrobić.

W szesnastej sekundzie zaczynają działać skrypty startowe. Hotplug ładuje moduły co powoduje podniesienie sieciówki. W oczy rzucają się sleepy około 2 sekundowe, jeden nawet dłuższy - trzeba je wziąść pod lupę.

Po trzydziestej sekundzie wszystko wisi na I/O - dysk pracuje intensywnie, chociaż z bardzo małą przepustowością - najwyraźniej ma miejsce bardzo wiele wyszukiwań i małych odczytów. Tutaj może pomóc zaimplementowanie jakiegoś readahead, chociaż czytałem, że wbrew pozorom nie daje to zysku większego niż dwie-trzy sekundy.

W końcu po 45 sekundach okno logowania GDM czeka na mój login i hasło, a bootchart kończy działanie. Po zalogowaniu muszę czekać jeszcze jakieś 5-8 sekund na załadowanie GNOME - ale optymalizacją tego już się zajmować nie będę. Ekipa od dużego G cały czas się zajmuje różnymi małymi ulepszeniami.

Widoczne na wykresie skrypty delay.sh odpowiadają za uruchomienie usług niekrytycznych na workstacji (acpid, samba, cron, apache, cups, smartd, qmail) w czasie 2 do 4 minut po ich wywołaniu.
Podsumowując - nie widać zbyt wielu oczywistych kandydatów do optymalizacji i skrócenia czasu bootowania. A szkoda, bo 45 sekund to kupa czasu, kiedyś było zdecydowanie mniej. Dobrze, że tak rzadko komputer uruchamia się od zera.

Ciekawych rzeczy można się ostatnio dowiedzieć z Planet KDE. Pewnie zaraz zostanę posądzony o trolowanie, ale trend wydaje mi się ciekawy - czyżby KDE zaczęło wstępować na drogę, którą GNOME kroczy od wersji 2.0?

Najpierw Matthias Ettrich podzielił się swoimi planami co do KDE4.

Zauważył między innymi, że Konqueror jest przeładowany opcjami i wygląda jak szwajcarski scyzoryk. Nawołuje do jego uproszczenia i nie przesadzania z ficzerami. I brzmi to jak jedna z zasad GNOME, wg. której programy powinny trzymać się filozofii Uniksowej - nie robić mnóstwa rzeczy, a tylko jedną. Za to robić ją doskonale.

Czytając opinie Matthiasa miałem wrażenie, że ponownie czytam esej Havoca Penningtona z przed trzech lat, który wyznacza kierunek rozwoju GNOME.

Między linijkami planów uproszczenia KDE można wyczytać błaganie o wyrzucenie zbędnych informacji, nie potrzebnych użytkownikowi przez większość czasu obsługi komputera. Przywołany jest monstrualny, KDEowy dymek (tooltip) pojawiający się przy wskazaniu pliku - myComputer.desktop is a Desktop Config File that is 170B large, owned by ettrich - users with -rw-r-r- and points to media://...

Dodatkowo Matthias podsunął dobrą myśl - okienka dialogowe blokujące aplikację powinny powodować wyszarzenie jej głównego okna. Także przesuwanie okna programu, nad którym wyświetlony jest jego dialog, powinno przesuwać tak samo okienko dialogowe.

Z kolei Ben Meyer zwraca uwagę na dobre pomysły do skopiowania z Mac OS X. Na początek proponuje jednorazowe wypytanie użytkownika o jego dane. Potem wpisane imię i nazwisko ma być użyte do automatycznego wypełniania pól w kliencie pocztowym, komunikatorze czy liście najlepszych wyników w grach. Ostatni punkt trochę mnie zdziwił, ale okazuje się, że KDEowe gry po każdej rozgrywce pytają użytkownika o imię i nazwisko. GNOMEowe tego nie robią - te dane pobierane są z pola GECOS w /etc/passwd automatycznie.

Oprócz tego w do dyspozycji jest okienko O mnie, analogiczne do tego z Mac OS X i postulowanego dla KDE.

Ben również zwraca uwagę na zbyt duże skomplikowanie opcji okien programów - mnóstwo pozycji menu, ikonek, przyborników itp. Dla kontrastu w jego artykuł ilustrowany jest zrzutami porównującymi analogiczne programy w dwóch środowiskach. Efekt jest piorunujący. Tą samą funkcjonalność DA SIĘ zawrzeć w czystszym interfejsie.

Meyer postuluje ciekawy eksperyment - posadzić deweloperów przy komputerach z jednoprzyciskową myszką. W systemie Apple da się wszystko zrobić takim urządzeniem (a nawet nową myszką Apple bez przycisków). W innych środowiskach - już nie za bardzo. Jeden przycisk to bardzo skuteczny (i sprytny) sposób wymuszenia na deweloperach tworzenia łatwych w obsłudze programów.

Dodatkowo, KDE stosunkowo niedawno dorobiło się ekipy zajmującej się używalnością. To taka grupa, która cały czas marudzi ,,za dużo przycisków, ikonek, za dużo opcji, za dużo zbędnych wodotrysków'', i wg. djurbana - podcina skrzydła developerom, dążącym do maksymalnej ilości nowych ficzerów w każdym wydaniu.

Jednak za cenę odrobinę większej pracy deweloperów uzyskuje się środowisko o wiele łatwiejsze i przyjemniejsze dla użytkowników. Warto ponieść ten koszt.

Dzisiaj jest poniedziałek, i jeszcze dzisiaj wyjechawszy z Bydgoszczy dotrę do Tczewa. To taki trochę na około sposób, żeby jutrzejszy dzień spędzić w Warszawie. Potem środa w Tczewie i reszta tygodnia w Gdańsku. Powrót do Bydgoszczy pewnie w poniedziałek. I znowu robota, tym razem pod szyldem serwerów pocztowych (say hello to Postfix!).

Od dwóch lat tak nie jeździłem.

Na konferencji GUADEC 2005, która odbyła się już jakiś czas temu, jedna sesja poświęcona była tzw. Lighting Talks. Ich idea polegała na przedstawieniu danego programu czy też zagadnienia w ciągu pięciu minut. Ciekawi całości mogą ściągnąć całe nagranie, pozostałym proponuję dwa wycięte fragmenty:

Pierwszy pokazuje, jak można zastosować OpenGL w composition managerze. Widoczne są ogólnie znane przezroczyste okienka z cieniami. Na co warto zwrócić uwagę, to szybkość i płynność ich przemieszczania. Radzę też wyczekać do momentu, w którym prelegent zaczyna przełączać wirtualne desktopy!

W drugiej odsłonie mamy prezentację możliwości Mozilli z obsługą Canvas i SVG. Poza drobnymi problemami technicznymi i flicker bug zobaczyć możemy wpływanie JavaScriptem na SVG osadzony w XHTML. Ponownie pod koniec mamy rodzynek, tym razem w postaci użycia biblioteki Cairo do rysowania zarówno interfejsu Mozilli, jak i samej strony. I zastosowanie transformacji... jakiej? Prostej, ale nie powiem jakiej. Warto zobaczyć.

Obydwa filmiki zakodowane są jakimś MPEG-4 z dźwiękiem w mp3. Mają po ok. 19 MiB.

Siedzę i po raz kolejny zaczynam pisać newsy jądrowe do Linux+. A może ktoś kto ma subskrypjce na LWN podeśle mi ten artykuł? Albo pomoże mi wykupić prenumeratę, bo ani LWN, ani PayPal nie przyjmują mojej karty płatniczej?

Asa Dotzler na swoim blogu stara się pokazać, dlaczego Linux nie jest gotowy na desktop. Czytając jego wpis można się przerazić, że człowiek o tak dużym wpływie (słyszeliście o Mozilla Firefox?) pisze z przekonaniem kompletne bzdury.

Zaczyna się niewinnie, od informacji o dystrybucji:

my latest is FC4

Fedora Core? Czwarta? Na desktop dla ZU? Błąd. Zacząć należy od tego, że Asa chyba nie rozróżnia pojęcia użytkownik od administrator. Obydwaj mają różne zadania i potrzebują różnej wiedzy. Nawet w środowisku typowo rodzinnym mamy często do czynienia z grupą użytkowników (Ojciec, Matka, Siostra, Brat, Pies) oraz administratora (zazwyczaj któryś z synów). Ten rodzinny administrator ma na głowie rzeczy takie jak zarządzanie użytkownikami, instalacja systemu, dbanie o kwestie bezpieczeństwa i aktualizacji. I służy również jako helpdesk, gdy trzeba pokazać jak się zmienia tapetę albo jak obsługiwać edytor tekstu.

Fedora Core nie jest przeznaczona dla użytkowników bez administratora. Może mieć zastosowanie w desktopach korporacyjnych, ale nie w domu. Sytuacja nie poprawia fakt bycia przez Fedorę wielkim placem betatestów.
Dla większości ZU odpowiednim wyborem jest Ubuntu, bo to jest dystrybucja tworzona do używania, a nie testowania.

The first issue, migration, is pretty serious.

Wg. Asa, ważne jest przeniesienie wszystkich danych, zakładek i dokumentów użytkowników z Windows na sytem Linuksowy. Moim zdaniem nie jest to zupełnie potrzebne, gdyż nie należy skupiać się na użytkownikach przyrosłych do MS Win. Błędem jest uszczęśliwianie ich na siłę. Ważni są nowi użytkownicy, stający się właśnie posiadaczami swoich komputerów. Nie mają żadnych danych i najważniejszym celem jest umożliwienie im stworzenia takowych. Czyli bezproblemowa konfiguracja czytnika poczty, komunikatora, tapety na pulpicie.

Zresztą, czy ktoś kiedyś jako wadę MS Windows przytoczył brak narzędzi do migracji z Linuksa? Albo Mac OS X? Bądźmy sprawiedliwi!

Najgroźniejszy błąd w rozumowaniu Dotzlera pojawia się zaraz potem:

doesn't require the user jump through hoops when they want to download a new application from download.com. A user should be able to install Fedora Core 4 and go grab the latest Firefox release from Download.com and have it work

Stop! W ogólnie pojętym GNU/Linuksie nie instaluje się oprogramowania w ten sposób. A już na pewno nie robi tego ZU. To najkrótsza droga do zrobienia sobie problemów. I chociaż najkrótsza, to również stanowiąca znaczne utrudnienie jeśli chodzi o procedurę instalacji.

Nowe oprogramowanie użytkownik instaluje uruchamiając jakiegoś graficznego zarządzce pakietów, wpisując nazwę poszukiwanego programu lub wyszukując po opisie i klikając przycisk Instaluj. Nie szuka po stronach, nie martwi się zależnościami, czeka tylko chwilę patrząc na pasek postępu. I po chwili ma zainstalowany poszukiwany program.

Mamy 2005 rok i instalowanie oprogramowania znalezionego na stronach plus walka z dependency hell już dawno odeszło w przeszłość. Dlatego też ważny jest wybór przez ZU dystrybucji z dużą ilością przygotowanego oprogramowania. Tutaj Debian pokazuje swoją siłę (oczywiście po uprzednim uczłowieczeniu w postaci Ubuntu).

Przechodząc dalej do Asa żyjącego w swoim dziwnym świecie:

The third issue is a lack simplicity. Just because you can include a feature doesn't mean that you should. Just because you can provide a user preference doesn't mean you should.

Zdanie jakby żwycem wyjęte z Human Interface Guidelines, wedle którego od paru lat tworzone są wygodne programy. Programy działające między innymi pod Linuksem. Dziwne jest, że Dotzler szuka wady tam, gdzie wszystko jest robione dokładnie tak, jak on uznaje za słusznie. W ogóle ten akapit jego wywodu jest niemal kopią zasad według których tworzone są i GNOME, i Ubuntu.

I na koniec najlepsze:

The final major issue is comfort. Linux must feel comfortable to Windows users. [...] Linux UI fundamentals need a reworking to match the habits that Windows users have been building over the last decade.

Znowu błąd. GUI działające na Linuksie nie powinno kopiować Windows, który w wielu miejscach jest bardzo kiepskim systemem, jeśli chodzi o Używalność. Na te stwierdzenia Dotzlera można odpowiedzieć prosto: screw Windows users! Nie należy im się kopia, a system interfejs zrobiony dobrze. Po dłuższej pracy widać, że poprawne, spójne środowisko okazuje się wygodniejsze.

Z tego akapitu pochodzi też przepiękny cytat:

Regular People don't want their OK and Cancel buttons reversed

Jeśli tak jest w istocie, to dlaczego najwięcej ludzi na świecie używa systemu MS Windows, w którym kolejność tych przycisków jest odwrócona?

Wiele osób żyje w kulturach, w których pisze się od lewej do prawej. Zwyczaj ten przenosi się również na inne aspekty kierunkowo-postępowości. Rysując osie, czy to na wykresie, czy na skali czasu z prawej umieszczamy większe wartości. To co jest bardziej na prawo stanowi rzeczy które są później - które są wynikiem postępu. Naturalnym jest więc umieszczenie z prawej strony przycisków, które będą posuwały do przodu interakcję użytkownika z komputerem. Natomiast po lewej stronie tych, które będą cofały lub zatrzymywały bieżące polecenia. OK po prawej, Anuluj po lewej. Intuicyjnie.

Zresztą wystarczy uruchomić jakiś program GTKowy z LC_ALL=il i zobaczyć, że tam, gdzie pisze się od prawej do lewej zarówno wyrównanie tekstu jest inne (do prawego marginesu), kolejność menu jest odwrotna, a przycisk OK jest po prawej stronie.

Do tej pory uważałem, że Asa jest osobą orientującą się w komputerach wśród mozzilowych programistów, ale teraz zaczynam w to wątpić. I nie dziwię się już, że niektóre bugi mimo wielokrotnego zgłaszania są wciąż nienaprawione od 5,5 roku.

gst-launch mmssrc location=mms://stream.onet.pl/info/200507/1c9b85d3be.wmv ! filesink location=a.asf

W wielu sieciach stosowane jest wymuszone cachowanie treści przesyłanych przez WWW. Oprócz zmniejszenia zajętości pasma pozwala to też na ingerencję w treść - np. wycięcie niechcianych reklam. Pozwala też ominąć wielokrotną konfigurację wszelakich programów korzystających z HTTP na porcie 80.

Skonfigurowanie transparentnego proxy na maszynie będącej routerem jest trywialne i nie ma sensu go omawiać. Co jednak zrobić, gdy za router służy niezbyt silny komputer, czy wręcz Access Point z Linuksem? Stworzenie przezroczystego proxy gdzie indziej, niż na routerze, jest odrobinę bardziej skomplikowane. Ale dzięki iptables, wciąż proste. Należy jednak pamiętać, że do tego celu został opracowany protokół WCCP i to on jest prawidłowym rozwiązaniem.

Załóżmy, że na proxy przenaczono komputer o adresie IP 192.168.1.128, z uruchomionych Squidem, nasłuchującym na porcie 8080. Konfiguracja składa się z trzech etapów:

1. włączenie przezroczystego cacheowania w Squidzie; tu w zależności od wersji postępujemy w dwójnasób:
   • Squid w wersji 2.5 - w pliku konfiguracyjnym umieszczamy 4 dyrektywy:

     	httpd_accel_port 80
     	httpd_accel_host virtual
     	httpd_accel_with_proxy on
     	httpd_accel_uses_host_header on
     	

     Do czego one służą należy oczywiście przeczytać w dokumentacji lub komentarzach w squid.conf
   • Squid w wersji 3 - w tym przypadku konfiguracji jest mniej; wystarczy jedynie przypiąć Squida do dodatkowego portu, zaznaczając przy tym, że na tym porcie odbywać się będzie przezroczyste buforowanie:

     	http_port 192.168.1.128:8081 transparent
     	

     Co ciekawe, można dopisać opcje protocol=, co powinno umożliwić przechwytywanie i obslugiwanie przez proxy również protokołu FTP. Nie sprawdzałem jednak takiego trybu działania.
   
   
2. Przekierowanie przychodzących pakietów do Squida. Prosta regułka - wszystkie pakiety TCP idące na port 80. Robi się to w łańcuchu FORWARD, w którym pojawiają się pakiety z pakietem docelowym różnym od adresu maszyny:

   	iptables -t nat -I PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8081
   	

   Należy zwrócić uwagę na numer portu docelowego - zależy od konfiguracji Squida.


3. Pozostaje jeszcze dodanie na routerze regułki przekazującej pakiety do maszyny z proxy. I tu pojawia się jedyna trudność - należy posłużyć się łatką z patch-o-matic dodającą cel ROUTE. Chyba, że dystrybutor zrobił to za nas.

   	iptables -t mangle -A FORWARD  -p tcp --dport 80 \
   	         -s ! 192.168.1.128 -j ROUTE --gw 192.168.1.128
   	

I to wszystko! Trzy linijki konfiguracji.