Enlightenment E17 i rozważania o Linuksie na ARM
Gdy rozpoczynano prace nad Enlightenment E17 i pojawił się pierwszy kod w repozytoriach wielu fanów Linuksa i "alternatywnych" środowisk graficznych rzuciło się z zapałem na efekt prac programistów. Jakieś cztery lata temu napisałem recenzję e17. A dzisiaj jak to wygląda?
Jak 4 lata temu tak i teraz menedżer okien sprawia wrażenie bardzo lekkiego, szybko reagującego na zdarzenia. Dobrze też wygląda, jest dostępnych kilka fajnych skórek. Można też uruchamiać aplikacje powiązane z KDE, czy GNOME bez problemów z ich wyglądem. Zminimalizowane aplikacje przedstawiane są jako duże ikony samych aplikacji, co oszczędza miejsce i ułatwia pracę z wieloma aplikacjami.
Niestety na tym plusy się kończą. Żeby e17 było gotowym produktem trzeba popracować sporo nad sposobem konfiguracji tego środowiska. Obecnie muszę się sporo naklikać by coś ustawić, a wiele opcji jest głęboko ukrytych. Menedżer plików domyślnie działa w stylu explorer z Win95 - każdy katalog w nowym oknie. Można to zmienić i nawet włączyć belkę nawigacyjną dla okna menedżera pliku - ale trzeba się naszukać, a po drugie takie ustawienia powinny być domyślne.
Załóżmy że mamy poprawioną domyślną konfigurację i sposób jej zmiany. Dostajemy mały i lekki menedżer okien. Od strony prezentacji mogłoby pewnie dać więcej niż LXDE czy XFCE, ale brak na chwilę obecną natywnych "bazowych" aplikacji. Zarówno LXDE jak i XFCE od dawna nadają się do codziennego użytku. e17 od kilku ładnych lat nie może wydać gotowego produktu...
Projekt Enlightenment wydał stabilne wersje bibliotek swojej platformy - eina, edje, eet, efreet, evas, e_dbus, ecore, eeze, emryo. Samo środowisko graficzne i kilka aplikacji użytkowych nadal nie doczekało się stabilnego wydania (choć można używać kodu z repozytorium). Tak jak kilka lat temu tak i dzisiaj Enlightenment celuje w dostarczanie bibliotek do tworzeniu interfejsów zarówno na architekturach systemów mobilnych, wbudowanych jak i na klasyczne pecety. Problem w tym że Qt potrafi znacznie więcej i zrobiło bardzo duży postęp w kategorii systemów mobilnych i wbudowanych.
Gdy projekt startował o smartfonach mówiło się niewiele. Procesory ARM jeżeli pracowały z takowaniem 200-400 MHz to już było coś. Wyświetlacze też na wiele nie pozwalały. Tak więc dostarczenie bardzo wydajnego zestawu bibliotek o sporych możliwościach miało sens. Qt pracowało nad Qtopią, a OpenMoko próbowało sił właśnie z platformą EFL. Urządzenie z procesorem ARM wyglądało wtedy tak:
Jest to Smartbook Toshiba ac100 wyposażony w układ nVidia Tegra T250 z dwurdzeniowym procesorem ARM o takowaniu 1GHz każdego z rdzeni. Są także potężniejsze układy, np. dostępna dla programistów pandaboard. Takie układy mogą działać pod kontrolą Androida, a także klasycznych dystrybucji Linuksa. Ograniczenia mocy obliczeniowych czy wyświetlacza już dawno zniknęły. Microsoft planuje obsługę ARM dla Windows 8 lub podobny system operacyjny dla tej platformy. Rozwiązania Intela, czy AMD na platformie x86 i x86_64 nie sprawdzają się tak dobrze jak ARM w kategorii poboru mocy.
Wraz z pochodem tabletów, smartfonów i netbooków ARM wejdzie do "zwykłych" komputerów - latopów, czy PeCetów nie przeznaczonych do wykonywania skomplikowanych operacji. Linux ma teraz dużą przewagę zarówno nad Microsoftem jak i nad OSX bo jest w stanie dostarczyć w pełni funkcjonalny desktop dla architektury ARM. By tej szansy nie zmarnować nie może tracić tyle czasu co e17, czy próbować zbyt wielu szalonych dla niektórych eksperymentów z interfejsem. Odpowiednik MacBooka Air działający pod kontrolą Linuksa z układem ARM - cichy, chłodny i w pełni funkcjonalny, działający wiele godzin na baterii. Z ekranami dotykowymi, bądź standardowym - czemu nie?
Comment article