Pomysł przenośnych aplikacji nie jest niczym nowym, jednak osobiście nie spotkałem się z niczym podobnym dla systemu Linux. Istnieją oczywiście obrazy dystrybucji LiveCD, które można wgrać również na pamięć USB jako samodzielny system, to jednak sama idea przenośnych aplikacji jest bardzo interesująca.

Jedna ikona, jeden plik, jedna aplikacja

Korzyści takiego rozwiązania są znaczne, aby skorzystać z danej aplikacji w systemie nie jest wymagane posiadanie uprawnień administratora. Odpada więc konieczność dodawania nieoficjalnych repozytoriów, kompilacji i dbania o wymagane zależności, dzięki czemu mniej doświadczony użytkownik nie zrobi sobie krzywdy.

Do korzystania z pełnowartościowego programu, wystarczy tylko ściągnąć i uruchomić jeden plik. De instalacja jest jeszcze prostsza - przenosimy plik do kosza i po krzyku. Na chwile obecną minusem jest mała liczba aplikacji oraz ich dostępność wyłącznie dla 32-bitowych odmian systemu.

Audacious Portable

Podoba Wam się w ogóle taki pomysł?

Strona domowa projektu: http://portablelinuxapps.org/

Skomentuj

Właśnie ukończyłem kompilację i konfigurację środowiska KDE 4.7 SC. Z tej okazji przebudowałem sobie również  system, bazując jak zwykle na dystrybucji Slackware z jądrem Linux 3.0. Same przygotowania zacząłem już tydzień temu, pracując tymczasowo na XFCE, który okazał się całkiem sprawnym i przyjemnym biurkiem. Ale do rzeczy.

Nie da się oprzeć wrażeniu, że głównym naciskiem tego wydania jest poprawa funkcjonalności oraz stabilności działania. Nie znajdziemy więc tu wielu nowości - nie oznacza  to jednak, że nie doświadczymy poważnych zmian lub ciekawych udogodnień.

OpenGL ES

Dodano obsługę OpenGL ES, które usprawnia pracę środowiska na urządzeniach mobilnych. Można spotkać się również z opiniami jakoby OpenGL ES sprawuje się równie  dobrze na tradycyjnych konfiguracjach, co zamierzam sprawdzić osobiście w najbliższym czasie. Nowe KDE dostało również nowy system cieniowania, który doskonale sprawuje się na starszym sprzęcie. Pojawiła się także dodatkowa opcja umożliwiająca wykorzystania jednostek cieniujących OpenGL 2.

Lifting Doplhina i nowe ikony Oxygen

Zmiany dotknęły również aplikacje dołączone do samego środowiska. Dolphin dostał bardziej elegancki interfejs w którym pasek menu został ukryty, a cały interfejs został zminimalizowany. Oczywiście możemy przywrócić jego stary wygląd do indywidualnych potrzeb. Dodatkowo zapewnia integrację z systemami kontroli wersji.

Jedną ze zmian, które nie przypadły mi do gustu, jest wymiana ikon folderów.

Porównywanie obrazów w Gwenwiev

Z mniejszych zmian jakie na chwilę obecną "odkryłem" jest możliwość porównywania obrazów w przeglądarce Gwenview. W podglądzie możemy zaznaczyć kilka obrazów, które zostaną ze sobą zestawione.

Brzydkie kaczątko dla KDE

Nowe KDE lepiej integruje się z aplikacjami wykorzystującymi bibliotekę GTK sprawiając, że niektóre perełki wyglądają jak szyte na miarę.

Co jeszcze?

Z udogodnień warto wymienić również usprawniony kalendarz wyświetlający opis wydarzeń oraz menu, w którym możemy swobodnie się poruszać za pomocą wygodnej ścieżki.

Teraz, kiedy mogę już wygodnie pracować na nowym KDE 4.7 SC wypadałoby się przyjrzeć rozwojowemu  KDE 4.8 SC - na które przygotowałem już specjalne miejsce :)

Skomentuj

Oracle wykupił Ksplice Inc., firmę która posiada duży wkład w rozwój oprogramowania Open Source. Mowa tutaj o rozszerzeniu jądra Ksplice, który pozwala na aktualzację jądra bez konieczności restartu całego systemu. Ksplice jest dosyć ważnym elementem systemów, w których zachodzi konieczność nanoszenia łat dotyczących kwestii bezpieczeństwa, które nie wprowadzają zmian semantycznych w strukturach danych. Warto również zaznaczyć, że jest rozwiązaniem bardzo wygodnym, przyjmując odpwiednią łatę oraz kod źródłowy samego jądra.

Ksplice był dostępny bez ograniczeń dla użytkowników Ubuntu oraz Fedora (w przeciwieństwie np. do Red Hat Enterprise Linux, gdzie wymagana jest odpowiednia subskrypcja). Oracle natomiast jest zainteresowany wykorzystaniem rozszerzenia jako integralnej części własnej dystrybucj Oracle Linux oraz programu Oracle Linux Premier Support.

Główna siedziba Oracle

Czy będzie to miało wpływ na użytkownika domowego? Zdecydowanie nie... jednak firmy, które potrzebują profesionalnych rozwiązań serwerowych mogą zacząć się martwić na zapas. Warto również zastanowić się, czy Oracle w przyszłości może jeszcze bardziej zaszkodzić Linuksowi - praktyka dowodzi, że wychodzi mu to doskonale.

Skomentuj

Wraz z pojawieniem się bibliotek Mesa 7.11-rc1 nastąpiła zmiana domyślnego sterownika na Gallium3D dla kart graficznych ATI opartych o układ R6xx. Sugerowałoby to, że nowa architektura jest już gotowa na zajęcie miejsca sterowników starszej generacji.

Tak się składa, że jestem posiadaczem mobilnego układu ATI Mobility Radeon HD3470, dlatego postanowiłem sprawdzić jak sprawują się nowe sterowniki względem starszych. Porównaniu poddałem biblioteki Mesa 7.10.2 oraz 7.11 rc2. Nanjowsze wdyanie Mesy sprawdziłem również pod kątem klasycznego mechanizmu DRI oraz Gallium3D. Do kompilacji Mesy 7.11 wymagane jest również posiadanie kompilatora LLVM (Low Level Virtual Machine), który powinien mieć ogólny wpływ na wydajność nowej Mesy.

Na pierwszy rzut oka zasadniczej różnicy nie ma. Compiz działa bezproblowo na obu wersjach - zarówno starszej jak i nowszej. Dopiero test za pomocą Phoronix Test Suite wykazał pewne różnice.

Testowi poddałem OpenArena oraz Warsow. Niestety ta druga nie wyświetlała poprawnie tekstur zarówno przy wykorzystaniu klasycznych sterowników dostępnych w Mesa 7.10.2 oraz Mesa 7.11-rc2. Dopiero "galliumowe" sterowniki poprawnie obsłużyły ten tytuł. Ma to zasadniczy związek z ilością obsługiwanych rozszerzeń OpenGL 2.1, których o dziwo więcej obsługuje wersja oparta na nowej architekturze Gallium3D.

Lista rozszerzeń, które nie są dostępne w klasycznej wersji sterownika.

Można więc stwierdzić, że klasyczna wersja sterowników ATI pozostała w tyle jeśli chodzi o lepszą obsługę OpenGL. Wyniki wydajności prezentują się następująco:

Przede wszystkim widać znaczne różnice pomiędzy Mesą 7.10 a 7.11, gdzie wydajność jest znacznie lepsza - nie bez znaczenia jest wykorzystanie kompilatora LLVM. Zaskoczeniem dla mnie okazł się jeszcze lepszy wynik sterownika wykorzystującego Gallium3D, co w połączeniu ze znacznie lepszą implementacją OpenGL 2.1 sprawia, że mogę oficjalnie pożegnać starą architekturę.

Skomentuj

Ponownie stanąłem przed dylematem wyboru pomiędzy systemem 32-bitowym a 64-bitowym. Wszystko za sprawą rozszerzenia pamięci z rozmiaru 3GB do 4GB. Na początku wybór wydawał się oczywisty - przynajmniej do czasu, kiedy potrzebowałem uruchomić kilka programów 32-bitowych. Na szczęście jest klika rozwiązań pozwalających na taką operację.

Multilib - miksujemy i mieszamy

Posiadając 64-bitowy system,  rozwiązaniem jest dosłowne wymieszanie architektury 32 i 64-bitowej. W zależności od dystrybucji czynność ta jest mniej lub bardziej skomplikowana. W przypadku dystrybucji Slackware sprawa nie jest taka "hop siup".  Znalazłem nawet gotowe repozytorium Aliena, ale biorąc pod uwagę dość mocną ingerencję w kluczowe elementy systemu, odrzuciłem to rozwiązanie już na samym wstępie.

Szczerze mówiąc, nie jestem do końca przekonany do zalet takiej hybrydy w której można łatwo popełnić błąd podczas doinstalowania kolejnych pakietów wymaganych dla programów 32-bitowych. Taka pomyłka może być opłakana w skutkach, na którą po prostu nie mogę sobie pozwolić w życiu codziennym. Problematyczne jest również uruchamianie programów za pomocą dodatkowych skryptów.

Chrootowane środowisko 32-bitowe

Drugim rozwiązaniem jest stworzenie sobie chrootowanej kopii 32-bitowego systemu. Ten sposób jest w miarę bezpieczny, skutecznie  separując od siebie obie wersje systemu. O katastrofę jest tutaj trudniej,  jednak wadą jest tutaj duży rozmiar 32-bitowego "dodatku". Można powiedzieć, że w czasach kiedy dyski sięgają pojemności rzędu terabajtów, nie jest to problemem. Narzuca to niestety pewną konieczność dbania o dwa systemy jednocześnie pod kątem zarówno aktualizacji jak i prawidłowego jego działania. Ale o tym może innym razem.

PAE

Przypomniałem sobie o PAE (Physical Address Extension) - rozszerzeniu, które umożliwia procesorem z rodziny x86 na dostęp do pomięci fizycznej o rozmiarze większym niż 4GB. W teorii rozszerzenie jest przydatne, kiedy mamy więcej niż 4GB RAM-u. Tak jednak nie jest - dla systemu operacyjnego bez obsługi PAE pozostaje tylko 3GB z hakiem. Zdarzają się również i takie sytuacje w których PAE nie przyniesie żadnego efektu - na przykład z winy barku obsługi po stronie sprzętowej (płyta główna). Reasumując PAE pozwala na zaadresowanie 2^36 (64GB) pamięci w systemach 32-bitowych. Oczywiście PAE ma swoje wady. Pomimo możliwości zaadresowania 64GB pamięci, pojedyncza aplikacja i tak będzie mogła skorzystać z ciągłego obszaru 4GB. Nie zmienia to jednak faktu, że sumarycznie uruchomione aplikacje mogą tą barierę przekroczyć.

Obsługa PAE jest domyślnie włączona w większości dystrybucji. Zdarzają się jednak i takie sytuacje w których musimy przekompilować jądro z jego obsługą.

64 bity nie takie cudowne...

Zacząłem się więc zastanawiać, czy warto pchać się w 64 bity. Nie dość, że korzyści wydajnościowe są prawie żadne, to 64-bitowa wersja systemu pożerała około 30% więcej pamięci. Dla porównania XFCE 4  z uruchomionym Eclipse w 32 bitach zajęłą 728MB pamięci, a odpowiedni tandem w 64 bitach aż 955MB.

Dochodzę do wniosku, że tak naprawdę 64 bity nie są mi obecnie do niczego potrzebne - przynajmniej do momentu, gdy oprogramowanie 32-bitowe odejdzie w niepamięć i na stacji roboczej będę miał 16GB oraz aplikacje wymagające dostępu do dużych jej obszarów.

Skomentuj