DIME - w obronie prywatności

W ostatniej dekadzie amerykanie stracili części swojej prywatność na rzecz bezpieczeństwa, z czym nie wszyscy do końca zdołali się pogodzić. Jedną z takich osób jest Ladar Levison. W 2013 roku został on zmuszony przez władze U.S. do zamknięcia swojego biznesu, który rozwijał przez 10 lat. Jego firma Lavabit oferowała hosting dla usługi szyfrowanej poczty, która zapewniała prywatność jej użytkownikom. Głównym powodem zamknięcia Lavabit było to, że z jej usług korzystał Edward Snowden’s, w wyniku czego nawet FBI było bezradne. Otóż poczta była zaszyfrowana w taki sposób, że nawet administrator serwisu (Ladar Levison) nie mógł jej podejrzeć bez znajomości odpowiedniego hasła ustalanego przez użytkownika skrzynki.

Ladar Levison zaprzestał hostowania szyfrowanej poczty pod naciskami władz i nowego prawa, ale nie porzucił marzeń o wolności i prywatności użytkowników poczty elektronicznej. Niedługo po tych wydarzeniach utworzył nowy projekt o nazwie Dark Mail, który był kontynuacją rozwoju usługi szyfrowanej poczty jako projektu open source, którą wcześniej oferowała jego firma. Na konferencji DEF CON 22 Levison zaprezentował nowości w projekcie Dark Mail i ogłosił jego nową nazwę Dark Internet Mail Environment (DIME), która ma oznaczać nową bezpieczną architekturę poczty.

Levison chce, aby DIME stał się domyślnym standardem poczty. Trwają prace nad opracowaniem standardu w formie dokumentów RFC. Obecnie nie można nazwać projektu standardem, ale raczej prototypem, a jego rozwój dopiero się rozpoczyna. Ponieważ DIME to nie tylko serwer ale i klient poczty, więc przed autorami jeszcze dużo pracy, dlatego Levison zachęca do współpracy. Obecny klient poczty dla DIME to Volcano, który jest forkiem Thunderbirda, natomiast serwerem jest fork serwera magma używanego wcześniej przez firmę Lavebit. Większość kodu jest dostępna na GitHub Lavabit.

Zanim przejdziemy do omówienia architektury i zasady działania DIME warto wspomnieć na czym polega zasadnicza różnica, pomiędzy pocztą elektroniczną a innymi usługami. Otóż obecnie króluje architektura klient-server, jest tak w przypadku HTTP, FTP, czy DNS. Poczta natomiast w uproszczonym ujęciu działa w architekturze server-server. Jest to chyba jedyna usługa, która do prawidłowego działania wymaga zgodnej konfiguracji dwóch niezależnych serwerów. Innymi słowy mówiąc, nie można wysłać e-maila za pomocą DIME, jeżeli jego odbiorca również nie posiada konta na serwerze obsługującym taką architekture. Poza tym, taki e-mail może przejść przez więcej niż dwa serwery zanim trafi do serwera odbiorcy.

Nie bez znaczenia jest sama architektura serwerów poczty, które implementują kilka protokołów. I tak na przykład do wysłania przeciętnego e-maila zostaną użyte następujące protokoły: SMTP -> SMTP -> POP3/IMAP. Ponieważ jest to dość złożony model, to serwery poczty posiadają modułową budowę, pomijając fakt, że zazwyczaj serwer poczty wychodzącej i przychodzącej to dwa oddzielne serwery (demony). Z grubsza możemy wyróżnić trzech najważniejszych agentów. Mail User Agent (MUA) zajmuje się obsługą swojego użytkownika, ma tu miejsce komunikacja klienta poczty z serwerem poczty. Mail Transport Agent (MTA) zajmuje się transportem listów pomiędzy serwerami nadawcy i odbiorcy. Mail Delivery Agent (MDA) zajmuje się przechowywaniem i dostarczaniem poczty przychodzącej z serwera docelowego do klienta poczty, czyli MUA.  W wysyłce przytoczonego wcześniej przeciętnego e-maila wezmą udział następujące moduły: MUA -> MTA -> MTA -> MDA -> MUA. Jak widać jest to dość złożony proces w porównaniu do HTTP, mimo iż jest to najprostszy model. Dlatego implementacja DIME wcale nie jest prosta.

Architektura DIME składa się z wielu niezależnie zaszyfrowanych warstw oraz menadżera kluczy szyfrujących. Poza tym, jest tak przemyślany, aby każdy podmiot biorący udział w dostarczaniu listu
miał dostęp tylko do minimum potrzebnych mu danych aby wykonać swoje zadanie. Z grubsza możemy wydzielić trzy niezależnie szyfrowane warstwy: koperta (zawiera dane dla serwera źródłowego i docelowego), nagłówek i treść listu. Mimo, iż w warstwie koperty znajdują się dane dla obu serwerów, to są one szyfrowane oddzielnymi kluczami, w wyniku czego serwer nadawcy (Origin) nie ma dostępu do danych przeznaczonych dla serwera odbiorcy (Destination).

Warstwa Envelope (koperta) obsługiwana jest głównie przez agenta MTA, nagłówek obsługiwany jest zarówno przez MUA i MDA, w zależności po której stronie przetwarzanie ma miejsce (nadawca SMTP i odbiorca POP3). Warto nadmienić, że w DIME mamy odczynienie z protokołami Dark Mail Transfer Protocol (DMTP), a nie SMTP i będziemy mieli odczynienia z DMAP zamiast IMAP. W wyniku takiej architektury serwer nadawcy (MTA) nie ma dostępu (klucza) do warstwy nagłówka listu i nie zna adresu odbiorcy. Z kolei serwer odbiorcy nie zna adresu e-mail nadawcy, ponieważ znajduje się on w zaszyfrowanej dla niego warstwie nagłówka, do której klucze posiadają tylko nadawca i odbiorca listu. Dzięki takiemu podejściu nie wystarczy dostęp do któregokolwiek z serwerów poczty aby rozszyfrowaną treść wiadomości, a nawet adresata lub odbiorce w zależności od tego, który serwer został skompromitowany. Do treści listu dostęp mają tylko nadawca i odbiorca listu. DIME korzysta również opcjonalnie z DNSSEC w celu weryfikowania autentyczności domen biorących udział w procesie transportu poczty.

Głównym założeniem projektu Dark Mail jest stworzenie ogólnodostępnego (na zasadach open source) standardu przesyłania szyfrowanej poczty w łatwy do użycia sposób, który w przyszłości zastąpiłby obecny standard poczty elektronicznej. Zaszyfrowany list w architekturze DIME podczas przesyłania przez otwarty Internet dostarcza tylko informacji na temat serwera (hosta) docelowego i źródłowego, nic poza tym. Całość mechanizmu przypomina rosyjską matrioszkę, im głębiej tym mniej podmiotów posiada do niej klucz. Takie podejście gwarantuje nienaruszalność treści listu, co zaczyna budzić duże kontrowersje, zarówno po stronie przeciwników jak i zwolenników. Jednak jak zostało napisane wcześniej, obecnie implementacja DIME ma bardziej charakter demonstracyjny niż produkcyjny, ale już istnieją plany jego implementacji w serwerze Postfix. Nie mniej jednak do upowszechnienia się DIME czeka go jeszcze długa droga, być może nie tylko techniczna ale i prawna, a raczej polityczna.

Dark Internet Mail Environment: Architecture and Specifications [pdf]

Podsumowanie roku 2013 według Google

Najpopularniejsze dystrybucje i oprogramowanie w 2012 roku

Już w grudniu użytkownicy największego linuksowego forum mogli oddawać swoje głosy na najpopularniejsze projekty open source w roku 2012. Wyniki zostały ogłoszone na początku lutego 2013 roku.

Poniżej przedstawię wybrane kategorie, które mnie cieszą, bo sam na nie głosowałem.

2012 LinuxQuestions.org Members Choice Award Winners:

Server Distribution of the Year - Debian (28.74%)
Najpopularniejszą dystrybucją serwerową został Debian, podobnie jak w poprzednim roku, ale spadł jego udział z 31.15%. Ja używam tego systemu również na komputerach domowych.

Database of the Year - MySQL (40.00%)
Najpopularniejszym serwerem baz danych został MySQL, podobnie jak rok temu, wtedy 49.54%. Jak widać proces migracji do MariaDB będzie bardziej ewolucyjny, niż reakcyjny na politykę Oracle po przejęciu Sun.

Virtualization Product of the Year - VirtualBox (53.79%)
Ten wybór mnie już nie cieszy, głosowałem na KVM i mam nadzieję, że mój wkład w jego popularyzację w postaci artykułu, który ukaże się już w marcu i kwietniu coś przyśpieszy. W ogóle nie wiem w jakim kontekście VirtualBox miałby występować poza zastosowaniami desktopowymi. Jeżeli chodzi o otwartą i serwerową wirtualizację to tu wygrywa KVM.

Network Security Application of the Year - Wireshark (25.79%)
Nie pamiętam, czy był do wyboru tcpdump, jeżeli był to głosowałem na niego, w przeciwnym wypadku, również głosowałem na Wireshark.

Host Security Application of the Year - SELinux (34.07%)
To kolejna z dużych radości, chociaż rok temu było 50.42%, nie wiem dlaczego. W każdym bądź razie jest to jednocześnie najlepszy i najmniej używany mechanizm bezpieczeństwa w GNU/Linux. Od dawna walczy z tym Red Hat, to on ma chyba największy wkład w jego rozwój.

Text Editor of the Year - vim (34.35%)
Tu bez komentarza, oczywiście sam na niego głosowałem i używam :)

Programming Language of the Year - Python (28.03%)
Python też mnie cieszy, widać nie tylko Perl. Mój ips_outline został napisany w Pythonie.

Web Server of the Year (NEW) - Apache httpd (74.04%)
A tu bez rewelacji, ale jako nowa kategoria otwiera drzwi dla innych projektów.

To chyba wszystkie kategorie, które mnie interesują, jeżeli chcesz zobaczyć pozostałe znajdziesz je tutaj.

Powyższe wyniki ankiet stanowią pewnego rodzaju odpowiedź na pytanie np. "Jaka dystrybucja jest najlepsza na serwer?", "Jaki tekstowy edytor jest najlepszy?" itp.. Pytanie tylko na ile społeczność LinuxQuestions.org stanowi najlepszą próbę do przeprowadzania takich badań. LQ to największe międzynarodowe forum linuksowe, które istnieje od ponad 12 lat. Lepszy przekrój dałoby tylko przeprowadzenie takich ankiet na innych forach i sumowanie wyników. Natomiast jeżeli chodzi o ankiety z tylko jednego forum, to LQ jest chyba najlepszym miejsce.

Tradycyjne podsumowanie roku

Jak zwykle na swoim blogu prezentuję podsumowanie mijającego roku przez Google, na które czekałem z ciekawością. Niestety, w porównaniu do dwóch poprzednich lat ten klip nie zrobił na mnie takiego wrażenia. Może to nowe podejście do Zeitgeist przez Google. Oczywiście pisząc o tym, że moje oczekiwania trochę się zawiodły to konkretnie mam na myśli podkład muzyczny. Natomiast sam cel podsumowania wydarzeń minionego roku jak zwykle ma ukryty cel, chodzi o pokazanie jak te wydarzenia były relacjonowane przez sieć.

Dostępna jest również strona Zeitgeist 2012, na której można sprawdzić co w naszym kraju było najczęściej wyszukiwane w 2012 roku.




W rym roku podsumowania dokonała również fundacja Linuksa.




Jako podsumowanie roku 2012 polecam również obejrzenie Linux Kernel Report z konferencji LinuxCon Europe 2012, która odbyła się na początku listopada. Można tam usłyszeć o większość nowinek, w które jądro Linux zostało wyposażone w mijającym roku.

TCP Fast Open - wkład Google w szybsze połączenia

W czerwcu 2012 pisałem o nowym rozszerzeniu TCP zwanym Multipath, teraz napisze o nowym mechanizmie, który pozwoli na szybsze ładowanie się stron internetowych na pewno o 5-7%, a w niektórych przypadkach nawet o 30-40%! Już pewnie zastanawiasz się o które mechanizmy chodzi, ale może trochę źle się wyraziłem. Tu nie chodzi tylko o szybkość ładowania się stron internetowych, ale o szybkość nawiązywania wszystkich połączeń w sieci przez protokół TCP/IP.

TCP/IP to duma inżynierii prawie z przed 30-tu lat, gdy protokoły te były projektowane ich twórcy nie mieli pojęcia jak będzie wyglądała sieć dziś. Mimo wszystko zostały opracowane tak dobrze, że mimo iż cała sieć zmienia się całkowicie w przeciągu każdych kolejnych 10 lat, to wciąż działa na tym samym TCP/IP.

Google ma chyba największe i najlepsze "laboratorium" do przeprowadzania optymalizacji połączeń w sieci (klient-serwer). Mało która firma ma tak dużo obciążonych serwerów i do tego własną przeglądarkę. Ten zestaw tworzy wspaniałe laboratorium, w którym Google dostrzegł problem i postanowił pracować nad jego rozwiązaniem. Tak właśnie powstał między innymi TCP Fast Open.

Tam i z powrotem

Jak zapewne wiesz, protokół TCP (RFC 793) jest protokołem stanowym, dlatego musi nawiązać sesję przed przesłaniem danych. To nawiązanie jest zwane 3-way handshake (3WHS). Zanim serwer prześle treści do przeglądarki, klient musi wysłać pakiet SYN, a serwer na niego odpowiedzieć pakietem SYN-ACK. W tym momencie klient może już przesyłać pierwsze dane wraz z potwierdzeniem ACK. Dopiero po odebraniu tego pakietu serwer połączenie uważa się za nawiązane (ESTABLISHED) i przystępuje do wysyłania kodu strony dla klienta. Podróż pakietu od klienta do serwera i z powrotem określana jest mianem round-trip time (RTT), czyli czasem podróży tam i z powrotem.

Zauważ, że serwer HTTP jest bezstanowy, czyli każde żądanie jest dla niego indywidualne. Dlatego często trzeba nawiązywać nowe połączenia TCP, a każde takie nawiązanie zawiera w sobie koszt RTT.

Ile kosztuje RTT?

Wartość RTT jest celem dla mechanizmu TCP Fast Open, im większa ona jest, tym zysk jest większy. Dlatego warto dobrze zrozumieć istotę sprawy. Wyobraź sobie, że chcesz wybrać się do kina. Wcześniej jednak musisz pojechać do kina i zakupić bilet. Po otrzymaniu biletu, musisz wrócić do domu i z powrotem wrócić na film, o wyznaczonej porze. Tak w skrócie można zobrazować nawiązanie sesji TCP. W tym miejscu pominiemy fakt, że pierwszy raz bez sensu musisz jechać do kina tylko po to, aby kupić bilet. Skupmy się na tym, ile czasu tracisz przez to.

W rzeczywistym świeci wziąłbyś ze sobą zegarek i zmierzył czas, w świecie komputerów służy do tego program ping. Jeżeli ping-niesz różne strony, to w wyniku otrzymasz czas RTT. Jeżeli masz wolne łącze podróż pakietom zajmie więcej czasu. Ponadto należy pamiętać, że przeciętne strony wymagają wielu zapytań, często do różnych serwerów i w każdym z nich jest zawarty czas RTT.

Jak już wspomniałem wcześniej Google posiada największe "laboratorium", w którym dokładnie policzono jaki jest rzeczywisty koszt RTT.

Wykres przedstawia wyniki badań przeprowadzone na serwerach Google. Czerwony słupek reprezentuje procentowy koszt nowego trójstopniowego połączenia TCP, zielony to suma pierwszych i kolejnych zapytań w nawiązanych sesjach. Dla różnych usług Google te wartości są inne, ale jak widać w procesie wyszukiwania aż 15% czasu zabiera nawiązanie sesji TCP z serwerem.

Problem ten wcale nie jest nowy, po części rozwiązano go już wcześniej wprowadzając do protokołu HTTP mechanizm zwany Persistent Connection (RFC2616). Dla przykładu w serwerze Apache służy do tego dyrektywa KeepAlive, która jest domyślnie włączona. Również wszystkie przeglądarki implementują ten mechanizm.
Problem z Persistent Connection polega na tym, że o ile po stronie klient zasoby są raczej nie wykorzystywane maksymalnie, to po stronie serwera mechanizm ten zużywa bardzo dużo zasobów. Poza tym jak wynika z badań przeprowadzonych przez Google w 33% sytuacji mechanizm ten nie zdaje egzaminu. Wynika to z tego, jak obecnie złożone są strony internetowe i ze sposobu w jaki deweloperzy starają się przyśpieszyć ich ładowanie. Wiele serwisów korzysta z kilku równoległych połączeń, aby przyśpieszyć generowanie treści. Poza tym co raz popularniejsze urządzenia przenośne nie przechowują długo nieaktywnych połączeń z uwagi na mniejszą ilość zasobwów.
Persistent Connection to nie jedyny mechanizm przyśpieszenia protokołu HTTP, jest jeszcze HTTP Pipelining, o którym również pisałem wcześniej.

Pominąć 3WHS

Obecny standard TCP zezwala na wysyłanie danych wraz z pierwszym pakietem SYN, chociaż nie zezwala na wymianę danych przed zakończenie trójstopniowego połączenia. Dlatego postanowiono wykorzystać ten fakt i dodano do pakietu SYN tzw. prośbę o ciasteczko (cookie request) - przedstawia to schemat poniżej.

Gdy serwer otrzyma wraz z pakietem SYN prośbę o ciasteczko, wygeneruje je na podstawie adresu IP klienta i odeśle wraz z pakietem SYN, ACK. Klucz używany przez serwer do generowania ciasteczek jest zmieniany co jakiś czas ze względów bezpieczeństwa. Klient otrzymane ciasteczko przechowuje podobnie jak odpowiedzi serwera DNS, na przyszły użytek. Po rejestracji nowego klienta wymiana danych przebiega standardowo.

Korzyści zaczynają się wtedy, gdy ten sam klient ponownie wyśle zapytanie do serwera. Najpierw klient sprawdza, czy dysponuje ciasteczkiem dla danego serwera. Jeżeli takie posiada, to dołączy je i dane do pierwszego pakietu SYN. Serwer spostrzegając ciasteczko w pakiecie SYN przystępuje do jego weryfikacji. Są to podobno bardzo szybkie operacje szyfrowania, które mają minimalny wpływ na opóźnienia.

Prawidłowe ciasteczko sprawia, że serwer przekazuje dane z pakietu SYN do aplikacji, której wynik jest przesyłany z powrotem do klienta wraz z pakietem SYN, ACK. W ten sposób, w przypadku kolejnych zapytań, klient otrzymuje kod strony (w innym przypadku dane) w czasie jednego RTT, czyli pinga.

Ponad to serwer może zacząć wysyłać kolejne dane jeszcze przed otrzymania potwierdzenia, czyli ostatniego kroku 3WHS.

Gdyby nie mechanizm ciasteczek, można byłoby od razu przesyłać dane w pierwszym pakiecie SYN. Niestety, wtedy protokół TCP straciłby jedną ze swoich głównych zalet - stałby się niepodatny na fałszowanie adresu IP. Mimo konieczności generowania ciasteczek mechanizm ten nadal przyśpiesz połączenia (np. o 15% dla każdego kolejnego zapytania do google.com).

Implementacja

W każdym moim wpisie przychodzi czas na stwierdzenie, że GNU/Linux jest najlepszy :). W tym tekście ten czas przyszedł właśnie teraz. Przebrneliśmy przez tyle rzeczy tylko po to, abym znów mógł napisać, że Linux jest najlepszy. Właściwie czytanie tego tekstu można by rozpocząć od tego momentu, ale zapomniałem wspomnieć o tym na samym początku.

Tak więc, Linux jest obecnie pierwszym systemem, który będzie wspierał mechanizm TCP Fast Open. Do wersji jądra 3.6 dodano obsługę client-side, natomiast server-side została dodany do zbliżającej się wersji 3.7.

Obecnie TFO jest na poziomie wdrażania i testowania, istnieje propozycja standardu w IETF, co do której są oczekiwania, że w 2013 roku stanie się oficjalnym standardem. Na chwilę obecną trwają jeszcze rozważania nad propozycjami wdrożenia tego mechanizmu w przyszłości do innych systemów operacyjnych, zwłaszcza systemu Windows. Natomiast korzyści TFO będzie przynosił już niedługo, np. dla Google w samej serwerowni.

Zasoby:
"TCP Fast Open", CoNEXT 2011
"TCP Fast Open: expediting web services", lwn.net
"Let's make TCP faster", The Official Google Code blog

"Main development phase of Linux 3.7 completed", h-online.com
"How Google Wants to Make TCP Faster", readwrite.com

Internet Draft "TCP Fast Open", tools.ietf.org

Nowości w Red Hat Enterprise Linux (RHEL6 i RHEL7)

Wideo przedstawia rozszerzenia wprowadzone do obecnie najnowszej gałęzi RHEL6 oraz do nowej gałęzi RHEL7, której pierwsza beta jest zapowiadana na pierwszą połowę 2013 roku.

Omawiany jest również sam cykl rozwoju systemu Red Hat Enterprise Linux. Z sesji dowiemy się na jakie technologie stawia Red Hat lub jakie proponuje w postacji TP (Technology Preview).

Treść prezentacji jest dostępna również w formacie PDF:
RED HAT ENTERPRISE LINUX ROADMAP HIGHLIGHTS

ARM może okazać się rewolucją w serwerowni i nie tylko

Wszyscy zainteresowani sprzętem komputerowym znają dwóch głównych producentów procesorów, jakimi są Intel i AMD. Choć ich implementacje są różne zachowują przeważnie zgodny standard dla komputerów biurkowych, czyli tzw. PC-tów. Wyścig między firmami Intel i AMD trwa od wielu lat w wyniku czego użytkownicy otrzymują coraz więcej. Choć architekci nowych układów za każdym razem posuwają się o krok dalej, to nadal nie mogą przestać troszczyć się o wsteczną kompatybilność i zrobić coś inaczej - bo na tym przecież polega rewolucja. Tak więc szansa dla innej architektury nadal gdzieś drzemie, pytanie tylko kiedy się obudzi.

Jak wiemy poza wspomnianymi architekturami firm Intel oraz AMD istnieją również inne, chociażby PowerPC jeszcze do 2006 roku używane w komputerach Macintosh. Wtedy zostały zastąpione przez wielordzeniowe i bardziej wydajne procesory Intel. PowerPC reprezentuje RISC (Reduced Instruction Set Computing), która od koncepcji CISC (Complex Instruction Set Computer) w Intelu różni się tym, że procesor posiada tylko minimalną ilość podstawowych instrukcji, w wyniku czego jego budowa jest prostsza, a cena mniejsza. Związane jest z tym więcej korzyści, jednak jak wszystko ma swoje plusy i minusy. Ostatnio, zaleta ARM jaką jest mały pobór energii i cena zaczynają zyskiwać na wartości.

Procesory ARM cechują się bardzo małym zużyciem energii, dlatego odniosły wielki sukces w urządzeniach mobilnych, takich jak smartfony i tablety. Nowe tablety mogą pracować do 10 godzin na baterii, a system Android opracowany na bazie Linux jest najpowszechniejszym systemem operacyjnym dla tych urządzeń. Branża urządzeń mobilnych rozwija się w zawrotnym tępię, a deweloperzy innowacyjnych dystrybucji Linux zaczynają zastanawiać się nad tym, czy architektura ARM może przynieść korzyści poza platformą urządzeń mobilnych.

Pojawiają się już takie inicjatywy jak 'ARM jako podstawowa architektura dla dystrybucji Fedora'. Dla projektu zaowocowałoby to przypływem ogromnej ilości nowych użytkowników i wzrostem popularności. Dzięki taniemu kosztowi architektury ARM komputery z systemem Fedora byłaby bardziej dostępna w edukacji i wszędzie tam, gdzie wcześniej koszty stanowiły barierę. Niewielka cena za sprzęt świetne współgrałaby z nieodpłatną dostępności systemu Linux. Jak czytamy we wskazanym tekście "sukces procesorów ARM powinien być poważnym ostrzeżeniem dla architektury x86". Ponadto ARM posiada już 64-bitową wersję procesora i mógłby zastąpić architekturę x86_64. Jeżeli ktoś chciałby sobie już wyobrazić serwery z procesorami ARM to wcale nie musi tego robić, otóż one już są, wystarczy zobaczyć.

Najistotniejsze w tym wszystkim jest chyba to, aby zrozumieć, że nowe podejście nie ma na celu zastąpienie obecnego, ale jego rozszerzenie o nowe możliwości. Co do szczegółów to nie ma co opisywać, to trzeba zobaczyć. Jako pierwszy polecam projekt HP Project Moonshot.





Dla zainteresowanych specyfikacją techniczną prezentowanej platformy serwerowej podaje link: http://www.calxeda.com/products/energycards/quadnode

HP nie jest jedynym z pośród największych producentem serwerów, który zainteresował się architekturą ARM i zaproponował już swoje rozwiązania w nowym trędzie. Kolejnym pionierem jest firma Dell, która również zaprojektowała już swoje rozwiązania dla energooszczędnych procesorów ARM.

Jak napisał autor artykułu "Dell ARMs up for hyperscale servers" w portalu The Register, Dell nie projektowałby serwerów bazujących na architekturze ARM, gdyby nikt ich nie chciał.



Co ciekawe rozwiązanie to będzie oferowane z systemem operacyjnym Ubuntu 12.04 LTS w jakiejś komercyjnej odmianie. Więcej szczegółów na temat projektu Copper firmy Dell można znaleźć pod adresem: http://content.dell.com/us/en/enterprise/d/campaigns/project-copper

Rozwój technologii Cloud i w związku z tym wzrost zapotrzebowania na serwery sprawił, że firma Canonical również jest bardzo zainteresowana prezentowaną platformą serwerową. Mark Shuttleworth, człowiek który 'rozkręcił' obecnie najpopularniejszą dystrybucje systemu GNU/Linux uważa że architektura ARM "zatrzęsie" platformą serwerową.





Jeżeli chodzi o wykorzystanie możliwości procesorów ARM w komputerach domowych to jak widać na poniższym wideo (połączenie projektu Raspberry Pi i Fedora) dopiero pracuje się nad takimi wariacjami. Przyznać jednak trzeba, że projekt jest bardzo ciekawy biorąc pod uwagę fakt, że użyta konstrukcja (płytka) kosztuje trochę ponad 100 PLN.



Czy platforma ARM w połączeniu z Open Source przyniesie zmiany o jakich nam się nawet nie śniło? Czas pokaże, w każdym bądź razie na pewno ARM ugruntuje swoją pozycje jako lider rozwiązań energooszczędnych.

Wydaje się że właśnie rozpoczął się wyścigu o miano lidera w rozwiązaniach implementacyjnych architektury ARM. Jeżeli chodzi o rozwiązania softwarowe, to na dzień dzisiejszy Canonical jest na przodzie, ale Projekt Fedora depcze mu po piętach.

Więcej informacji:
http://nullr0ute.com/2012/03/arm-hardware-now-and-the-not-so-distant-future/
http://www.arm.com/community/software-enablement/linux.php
http://www.theregister.co.uk/2011/10/28/arm_holdings_arm_v8/
https://www.linux.com/learn/tutorials/582501-tiny-pluggable-linux-arm-computers-are-red-hot
http://www.debian.org/ports/arm/
http://wiki.freebsd.org/FreeBSD/arm

GPW podało datę przejścia na nowy system notowań UTP

Giełda Papierów Wartościowych w Warszawie już rok temu informowała o planach wprowadzenia nowego systemu transakcyjnego jakim jest UTP (Universal Trading Platform), który ma zastąpić obecny system zwany Warset.

GPW w dzisiejszym komunikacie[1] informuje:

"W listopadzie br. polski rynek kapitałowy czeka przełomowa zmiana technologiczna i jakościowa, jaką będzie wdrożenie nowego systemu transakcyjnego na warszawskiej giełdzie. UTP (Universal Trading Platform), zakupiony przez GPW od NYSE Euronext, jest systemem transakcyjnym, który spełnia najwyższe światowe standardy w dziedzinie technologii i obecnie jest wykorzystywany na giełdach w Nowym Jorku, Paryżu, Lizbonie, Amsterdamie i Brukseli. W listopadzie do tej grupy dołączy giełda warszawska, zyskując dostęp do globalnej infrastruktury technologicznej, z której od lat korzystają inwestorzy z całego świata.

...

W porównaniu z Warsetem nowy system transakcyjny giełdy będzie szybszy, bardziej wydajny i skalowalny. Zwiększy się także jego przepustowość, co umożliwi obsługę nowych, niedostępnych dotychczas typów zleceń oraz pozwoli na uruchomienie nowych usług związanych z zawieraniem transakcji"

Wydarzenie to jest dosyć hucznie reklamowane przez GPW, o czym może świadczyć ten film.

Pozostaje jeszcze pytanie, co to ma wspólnego z tematyką tego bloga?

Otóż UTP to rozwiązanie zaimplementowane na bazie systemu Red Hat Enterprise Linux. Wniosek z tego taki, że nie tylko największe giełdy na świecie używają systemu Linux, ale będą musiały to również robić wszystkie domy maklerskie w Polsce.[2] To doskonały przykład rangi, w jakich zastosowaniach sprawdza się system Linux.

Dla osób zastanawiających się dlaczego akurat Linux przypominam, iż RHEL jest systemem czasu rzeczywistego co z punktu widzenia giełdy jest jednym z najważniejszych wymagań. Oczywiście to nie jedyny powód, dla którego wybrano RHEL.

Nowy system notowań na GPW oficjalnie ma ruszyć 2 listopada 2012 roku.


[1] http://www.gpw.pl/wydarzenia/?ph_tresc_glowna_start=show&ph_tresc_glowna_cmn_id=48227
[2] http://www.parkiet.com/artykul/961329.html

Nowości w btrfs

Interesującym się możliwościami nowego systemu plików polecam kolejne wideo Btrfs Filesystem: Status and New Features.

Na moim blogu publikowałem wcześniej nagranie na temat systemu plików btrfs: Nagrania z linux.conf.au (LCA) 2012

Rosnąca popularność Linuksa

Dziś przedstawię parę ostatnich wydarzeń, które coraz bardziej dają do zrozumienia, że GNU/Linux już jest najbardziej znaczącym systemem UNIX-owym. Warto zobaczyć klip wideo niedawno przygotowany przez
The Linux Foundation, który przedstawia jak obecnie sprawy się mają w rozwoju kernela Linux.

Dokładny raport ze statystykami dostępny jest pod adresem http://go.linuxfoundation.org/who-writes-linux-2012 Raport dotyczy okresu od grudnia 2010 roku.
Z najistotniejszych faktów można wymienić iż np. nad wydaniem kernela 3.0 pracowało 331 firm, ogólnie natomiast największy wkład miały Red Hat, Novell, Intel, IBM. Oracle pomału również zmierza do tej czołówki. Google natomiast stanowi tylko 1%, wynika to pewnie z faktu, że oni rozwijają własną modyfikowaną wersję jądra. Bardziej interesuje ich soft o czy może świadczyć ich zaangażowanie znane pod nazwą Google Summer of Code. Nadal jednak największa grupę wśród developerów stanowią wolontariusze. 75% deweloperów otrzymało zapłatę za swoją pracę.

Warto zacytować następującą wypowiedź:

“Linux is the platform for the future of computing. More developers and companies are contributing to the advancement of the operating system than ever before, especially in the areas of mobile, embedded and cloud computing,”

Amanda McPherson

Jedną z najciekawszych rzeczy jaka rzuciła mi się w oczy to częstotliwość prac nad kodem, dla przykładu ilość zmian w wersji 3.2 wyniosłą średnio 6.88 na godzinę.

Co do ostatnio głośnego udziału Microsoft w rozwój kodu to nie ma co się ekscytować. Jest to efekt istotności Linuksa w zastosowaniach serwerowych. Microsoft musi zacząć liczyć się z GNU/Linux, bo inaczej ich produkt stanie się systemem niewspółpracującym z najpowszechniejszą platformą serwerową.



A no właśnie skoro o platformie mowa. Teraz chciałbym się odnieść do ostatniej publikacji firmy IBM ftp://public.dhe.ibm.com/software/linux/IBM_Linux_vs_Solaris_paper_2011_Final.pdf. Jak widzicie tytuł bardzo ciekawy i burzliwy - Linux vs Solaris. Treść tego dokumentu jasno pokrywa się z tytułem tego wpisu. Najpierw może jednak napiszę skąd ten temat. A no chodzi o ostatnią metamorfozę firmy Oracle w stosunku do open source i samego Linuksa. Skoro firma ta odziedziczyła po przejętym Sun'ie taki system jak Solaris to dlaczego angażuje się w rozwijanie własnej dystrybucji Oracle Linux opartej na RHEL? Na to pytanie stara się odpowiedzieć wspomniana publikacja. Z podsumowania możemy wyczytać w czym Linux jest lepszy:

"Linux is a better choice for a wider mix of workloads, hardware architectures, and administrator skill sets. Flexibility is crucial in an enterprise IT department, and Linux provides more choice of hardware, distribution models, and support providers without effecting how it is administered or the applications it may run. This allows IT executives to select hardware to match a workload, knowing that it will almost certainly be supported by Linux."

oraz jak istotną rolę odgrywają użytkownicy Linuksa

"Human factors are also important. There are many competent Solaris administrators available today, but commercial Solaris is rarely the first choice for college graduates adding certifications to their resumes. The popularity of Linux has created a larger supply of administrators, driving down their average cost without affecting a company's ability to find highly qualified individuals. It has also helped create an active and helpful community of users, developers, and commercial backers that have given the platform a great deal of momentum."


Odnośnie wkładu Oracle w świat systemu GNU/Linux to nie sposób nie wspomnieć o systemie plików btrfs. Ostatnio na swoim blogu publikowałem wideo prezentujące możliwości tego systemu plików.
Wkład będzie jeszcze większy, ponieważ można już zauważyć, że Oracle zaczyna przenosić pewne rozwiązania do Linuksa, chociażby DTrace.

Warto też wspomnieć o wprowadzonej na koniec 2010 roku wersji jądra zwanego "longterm", które wychodzi na przeciw potrzebom poważnych zastosowań i zmienia podejście dynamicznego rozwoju jądra. Teraz większość dystrybucji wybiera wersję longterm wspieraną przez 2 lata i tym samym produkt staje się bardziej dopracowany.

Linux rozwija się tak szybko, że z trudem śledzę najnowsze doniesienia na ten temat. Warto jednak od czasu do czasu je z grubsza podsumować.

Nagrania z linux.conf.au (LCA) 2012

Oto najciekawsze nagrania (moim zdaniem), które udostępniono na kanale YouTube.

Raport z prac nad jądrem w poprzednim roku 2011.



Prezentacja możliwości systemu plików btrfs.

Anonymous wzywają polskich członków do zaprzestania ataków DDoS

Od kilku dni w internecie, TV i radiu mówi się głównie tylko o akcie zwanym ACTA. Dużo się zadziało podczas aktywności polskich internautów przeciwko podpisania tego aktu. Po tym jak na stronie premiera został umieszczony apel Pani Barbary o wprowadzeniu stanu wojennego na terenie całego Internetu anonimowi wzywają polskich hakerów do zaprzestania ataków na strony polskiego rządu.



To nie codzienne wydarzenie, gdy sami anonimowi wzywają do zaprzestania ataków na serwery. Oto ich apel:

"Ataki na strony polskich władz MUSZĄ zostać zaprzestane
--------------------------------------------------------

Mówiliśmy to już wcześniej i powiemy jeszcze raz. Ataki na strony zarówno Polskiego rządu jak i Unii Europejskiej nie pomagają w walce z ACTA. Jesteśmy w stałym kontakcie z polskimi organizacjami pozarządowymi które poinformowały nas o tym, że ataki niszczą ponad trzy lata ich trudnej współpracy z rządem w tworzeniu prawodawstwa odpowiednio odnoszącego się do internetu i chroniącego podstawowe wolności internautów oraz możliwości negocjacji wstrzymania podpisu Polski pod ACTA. Jeśli potrzebujecie kolejnych dowodów przeczytajcie słowa wygłoszone przez Polskiego premiera Donalda Tuska:

  - Nie ustąpimy w żadnym wypadku wobec szantażu - oświadczył premier, odnosząc się do ataków na niektóre strony internetowe administracji państwowej. Szef rządu zapewnił, że jak na razie nie możemy mówić o zagrożeniach dla funkcjonowania państwa. - Nie wyobrażam sobie, aby polski rząd, polski parlament, polski premier ustępował przed kimś, kto mówi: "nie podpisuj, bo inaczej opublikujemy kompromitujące dane o twoich urzędnikach". Tego typu metody uważam za niedopuszczalne - powiedział Tusk.

Poinformował, że sprawdzane są zabezpieczenia stron, które zostały lub mogą zostać zaatakowane. Dodał, że jak na razie nie możemy powiedzieć o zagrożeniu dla funkcjonowania państwa ze względu na ataki na strony internetowe. Według niego są one raczej dokuczliwe i skuteczne propagandowo. - Nie ma żadnego powodu, żeby wzniecać alarm - uspokajał premier.

http://wiadomosci.gazeta.pl/wiadomosci/1,114884,11024567,Tusk__Dalem_upowaznienia_ambasador__by_podpisala_ACTA.html

Ataki DDOS zwróciły uwagę świata na toczącą się sprawę podpisania ACTA przez Polskę. Teraz tydiące Polaków wyszły na ulicę po to by manifestować swój przeciw. Nadszedł czas by pozwolić działać procesom politycznym i społecznym skierowanym przeciwko ACTA. Wszelkie ataki na strony polskiego rządu jak i Unii Europejskiej powinny zostać wstrzymane. Strony te służą przecież komunikacji krajowych i unijnych władz ze społeczeństwem. Jeśli lubisz DDOSować dla samego DDOSowania prosimy wybierz zamiast tego stronę swojej szkoły/uczelni.

Anonymous"

http://pastebin.com/1mDAceCF

Podsumowanie roku przez Google

Już coroczny przegląd statystyk wyszukiwania i tego co się wydarzyło w mijającym roku 2011.

Więcej na www.googlezeitgeist.com

Jest też podsumowanie tego co oglądano najczęściej na YouTube.

Lista najczęściej oglądanych dostępna na:

http://googleblog.blogspot.com/2011/12/what-were-we-watching-this-year-lets.html

Dzień z życia (Life in a Day)

W 2010 roku na portalu YouTube ruszył projekt, którego celem było nakręcenie filmu dokumentalnego o jednym dniu życia na ziemi. Dniem tym był 24 lipiec 2010 r. - tysiące użytkowników youtube.com z całego świata mogło nagrać swój dzień (dokładnie 24 lipca) i przesłać go do projektu Life in a Day.

Z 4500 godzin przesłanych nagrań powstał 90-minutowy film dokumentalny. To pierwszy film tego typu, od 31 października 2011 r. dostępny jest już na YouTube.

O filmie: http://www.filmweb.pl/film/Dzie%C5%84+z+%C5%BCycia-2011-593899

Pełen film dostępny pod adresem http://youtu.be/JaFVr_cJJIY

Obsługa HTTP Pipelining w Chrome 17

Pipelining to technologia przyśpieszająca działanie protokołu HTTP, została wprowadzona wraz z wersją HTTP/1.1. Pozwala na niesekwencyjne wysyłanie zapytań do serwera w ramach jednej sesji TCP. Dla odróżnienia Keep-Alive daje już duże przyśpieszenie, a pozwala na sekwencyjne wysyłanie zapytań w ramach jednej sesji. Apache wspiera obie metody. Z kolei Firefox wspiera, ale domyślnie jest to wyłączone. Opera jest obecnie jedyną przeglądarką, która to wspiera domyślnie.

Teraz Chrome będzie wspierać tą funkcję. Aby lepiej zrozumieć jej znaczenie polecam zapoznać się z stroną: http://www.igvita.com/2011/10/04/optimizing-http-keep-alive-and-pipelining/

Najzabawniejsze jest to, że technika Pipelining istnieje od 1999 w RFC 2616.

http://code.google.com/p/chromium/issues/detail?id=8991

Capsicum - nowy sposób na izolację procesów

Capsicum, tak nazywa się nowe rozwiązanie opracowane w laboratorium Uniwersytetu Cambridge przy finansowym wsparciu firmy Google. Celem projektu jest kompleksowe rozwiązanie problem z bezpieczeństwem przeglądarki Chrome i systemu operacyjnego Chrome OS.
Capsicum to tzw. sandbox framework, który rozszerza POSIX API. Jego użycie wymaga zmiany kodu w aplikacjach. Poza tym jest to rozwiązanie na poziomie aplikacji, póki co, bo biblioteka dopiero się rozwija.

Na początek wprowadzono ją do nowego wydania FreeBSD 9.0, ale Google ma w planach przeportowanie go na system Linux.

W publikacjach na temat Capsicum (http://www.cl.cam.ac.uk/research/security/capsicum/papers/2010usenix-security-capsicum-website.pdf) wspomina się o tym, że użyta technika rozwiązuje wszystkie problemy w przeciwieństwie do swoich konkurentów, w tym do SELinux. Pojawia się pytanie, czy Capsicum wyprze SELinux?

Okazuje się, że nie koniecznie, pisze o tym Robert Watson, jedne z developerów Capsicum:

> How is Capsicum positioned, from user & admin perspective, when compared to 
> the MAC work on FreeBSD and SELinux on Linux? Is one the superset of 
> another, will one obsolete another?

This is a point addressed in some detail in the paper, which considers the 
relationship between Capsicum and other security models.  Capsicum is really 
addressed at the application author, whereas MAC models are typically 
addressed at a blend of system integrators and system administrators.  As a 
result, users mostly benefit from Capcisum transparently.

źródło: http://lists.freebsd.org/pipermail/freebsd-arch/2011-January/011084.html

Ponadto jeden z deweloperów SELinux w swojej notatce poświęconej konkurencji ze strony Capsicum stwierdza, że z technicznego punku widzenia nie ma powodu, który nie pozwalałby na działanie obu tych technologi na tym samym systemie. To ważny fakt, ponieważ można się w sieci natknąć na takie informacje.

http://etbe.coker.com.au/2011/10/28/capabilities-vs-se-linux/

Rozwiązanie użyte w projekcie Capsicum jest o tyle prostsze, że nie wymaga administrowania w przeciwieństwie do SELinux, gdzie np. zmiana konfiguracji Apache może pociągnąć za sobą konieczność zmiany polityki SELinux, a ta wymaga już ponownego uruchomienia serwera.

Jednak z ogólnego punktu widzenia Capsicum wcale nie jest antidotum na wszystkie problemy związane z bezpieczeństwem. Capsicum nie można użyć do kontroli np. współpracy różnych części systemu.
Trzeba pamiętać, że jest to rozwiązanie problemu z bezpieczeństwem przeglądarki internetowej, które może mieć szersze zastosowanie, a nie odwrotnie. Zresztą jak Russell Coker zauważył, deweloperzy Capsicum ogłaszają, że stworzyli coś nowego ale nie zależy im na tym, aby to propagować.

Strona projektu: http://www.cl.cam.ac.uk/research/security/capsicum/

Microsoft - "don't panic!"

Microsoft z okazji zbliżającego się 20-lecia systemu GNU/Linux po prostu chce powiedzieć wszystkiego najlepszego i zaproponować rozejm i współpracę?





http://h-online.com/-1282639

Biznes w Internecie, czyli Polska Internetowa

"Google zleciło wiodącej firmie konsultingowej Boston Consulting Group przygotowanie niezależnego raportu na temat znaczenia internetu dla polskiej gospodarki. Naszym zdaniem, internet istotnie wpływa na wzrost gospodarczy, a raport dostarcza informacji wyjściowych do zaplanowania jego rozwoju."

W ramach dalszych działań Google stworzyło akcję Internetowa Rewolucja, skierowaną do Polskich firm. Partnerami akcji są home.pl oraz (uwaga!) Polską Konfederacją Pracodawców Prywatnych Lewiatan. Honorowym patronatem akcji jest Ministerstwo Gospodarki.
Nie ma co ukrywać, że większe obroty w polskim internecie przełożą się na większe dochody Google.



Więcej na www.polskainternetowa.pl

Yahoo! dołączył do The Linux Foundation

The Linux Foundation zrzesza największe firmy, którym zależy na rozwoju systemu Linux. Zazwyczaj wykorzystują go w swoim biznesie, członkowie płacą roczne składki, które są stopniowane. I tak:

Platinum Membership (500,000USD)
Gold Membership (100,000USD)
Silver Membership (5,000 - 20,000USD)

The Linux Foundation właśnie poinformował, że Yahoo! dołączyło do grona Silver Membership. Pod adresem http://www.linuxfoundation.org/about/members możemy zobaczyć spis członków Linux Foundation.

Dlaczego fakt dołączenia Yahoo! jest wart odnotowania? Już mówię. Jeżeli interesowałeś się systemem FreeBSD, lub masz zamiar, to zapewne usłyszysz o tym, że wiele firm, w tym własnie Yahoo! używa tego systemu. Pamiętam, że w książce poświęconej FreeBSD we wstępnie przeczytałem, że o stabilności tego systemu może świadczyć fakt, że twórcy serwisu Yahoo! wybrali FreeBSD, a nie Linuksa mimo, iż był on jeszcze we wstępnej fazie rozwoju. Natomiast dziś możemy usłyszeć o tym, że Yahoo! przechodzi na Linuksa.

W dniach 6-7 kwietnia 2001 r. w San Francisco miał miejsce panel Linux Foundation Collaboration Summit z udziałem dyrektorów największych firm (IBM, AMD, Yahoo!), gdzie dyskutowano na temat przyszłości systemu Linux w roli systemu Enterprise oraz w rozwiązaniach Cloud.




http://www.linuxfoundation.org/news-media/announcements/2011/04/yahoo-joins-linux-foundation

Linux ma już 20 lat

W 2009 roku 40-lecie obchodził UNIX, natomiast w tym roku swoje 20-lecie obchodzi Linux. Linux Foundation przygotował video z tej okazji.

W przedstawionym filmie wspomniano o poniższej reklamie IBM

W sierpniu planowana jest konferencja celebrująca to wydarzenie.