przystajnik

Monthly Archives: Wrzesień 2010

Gnome 2.32 – rewolucja przełożona

W dniu wczorajszym zostało ogłoszone stabilne wydanie środowiska GNOME 2.32. Jak można było się spodziewać po wcześniejszych wypowiedziach developerów, to wydanie nie zawiera żadnych odkrywczych wdrożeń, a jedynie poprawia błędy, ujawnia kilka nowych funkcjonalności i generalnie stanowi ostatnią kropkę w wielokropku po którym pojawi się… Gnome 3.0, zapowiedziane na kwiecień 2011 roku. I to na tym wydaniu spoczywa główna uwaga i moc sprawcza ekipy tworzącej GNOME, co można wywnioskować z zapowiedzi rewolucyjnych zmiany sposobu podejścia GNOME 3.0 do naszych pulpitów.

Lecz póki co, mamy przed sobą świeże GNOME 2.32, w którym zauważyć można:

– rozbudowany Empathy (grupowanie kontaktów, itp), jako główny koordynator naszych rozmów online,
– udoskonalona obsługa PDF w Evince (AtkText współpracujący z Orca, dodanie SyncTeX) ,
– bardziej czujny na nasze błędy poprawiony Nautilus (większa kontrola operacji na plikach),
– poprawki w przeglądarce graficznej EOG (większa ilość opcji),
– poprawki w odtwarzaczu Totem (usuwanie przeplotu z materiału podczas odtwarzania, obsługa playlist),
– dla użytkowników z ograniczoną sprawnością ruchową poprawiono MouseTweaks,
– rozbudowana Anjuta (Python i Vala są w pełni wspierane),
– odświeżony Glib 2.26, potrafiący dogadać się z Gsettings (zastępującym powoli Gconf),
– wspomniane wcześniej poprawki błędów

Istotna uwaga dla developerów. Od wydania 3.0 znikną następujące biblioteki:

libart_lgpl, libbonobo, libbonoboui, libglade, libgnome, libgnomecanvas, libgnomeprint, libgnomeprintui, libgnomeui and libgnomevfs.

Jak wynika z listy nowości, rewolucja odbędzie się w późniejszym terminie. Oby tylko została dobrze przygotowana i GNOME 3.0 oprócz zmian w komunikacji z użytkownikiem nie zaskoczył nas połowiczną funkcjonalnością konfiguracji. Przeżyłem już ‚rewolucje’ w postaci GRUB2, GDM2 i kilka wojen o przyśpieszenie i zwiększenie atrakcyjności startu systemu. I niewiele z tego wynikło, poza zamieszaniem i cofnięciem się z możliwościami konfiguracyjnymi do czasów wczesnego trybu tekstowego.

Jak przekonać się do zmiany sprzętu

Banał – gdy komputer nie działa dobrze, to się go wyrzuca i idzie do sklepu po nowy. Takie trendy panują w podgniwającej cywilizacji zachodu. Nas jednak z dziada pradziada uczono szacunku do dóbr wytworzonych i nabytych, a słowiańska dusza szybko ulegała sentymentalnemu przewiązaniu do różnorodnych przedmiotów naszego otoczenia. Jak zatem pozbyć się ukochanego peceta, gdy na przekór naszej woli od X lat jego elektronika bez szwanku wykonuje swoją robotę? Cóż, najrozsądniejszy argument to na pewno oszczędność własnego czasu. Czy jednak na nowszym, szybszym komputerze będziemy w stanie pracować wydajniej? W wielu wypadkach nie, lecz jeżeli rzecz opiera się o obróbkę grafiki, a w tym przypadku wywoływanie i retusz surowych plików RAW z aparatu, to okazuje się, iż…

Czasy bezlitosnego marketingowego postępu znoszą pod nasze strzechy coraz to bardziej wymyślne formaty danych, jak też większą ilość informacji przekazywaną za ich pomocą. W materii cyfrowych aparatów fotograficznych pierwszy rzucający się w oczy parametr to ilość megapikseli matrycy. Zdrowy chłopski rozum podpowiada, że jak czegoś się więcej, to dłuższa przy tym robota (większa furmanka -> więcej siana -> dłuższy czas załadunku). Dlatego w ramach dojrzewania do zmiany pokoleniowej sprzętu, dokonałem prostych wyliczeń. Otóż wziąłem na warsztat plik RAW z matrycy 8, 10 i 12 Mpx. Każdy plik potraktowałem programem Dcraw (wywołanie zdjęcia) i ImageMagick (skalowanie i lekki retusz materiału wyjściowego z Dcraw). Sprawdziłem czas obróbki na dwóch maszynach, z tym samym systemem (Ubuntu 10.04), tą samą wersją Dcraw i ImageMagick. A co z tego wynikło…

Core 2 Duo 2.13 GHz

8Mpx

#$:~/poligon$ time dcraw -c -q 3 -w 8mpx.orf | convert -filter Lanczos -resize "1024x768" -contrast-stretch 0.1% -strip -unsharp 0.3x0.6+1.3+0 - 8mpx.jpg
real 0m4.247s

10Mpx

#$:~/poligon$ time dcraw -c -q 3 -w 10mpx.orf | convert -filter Lanczos -resize "1024x768" -contrast-stretch 0.1% -strip -unsharp 0.3x0.6+1.3+0 - 10mpx.jpg
real 0m5.662s

12Mpx

#$:~/poligon$ time dcraw -c -q 3 -w 12mpx.nef | convert -filter Lanczos -resize "1024x768" -contrast-stretch 0.1% -strip -unsharp 0.3x0.6+1.3+0 - 12mpx.jpg
real 0m6.379s

I7 Q720 1.60 GHz

8Mpx

#$:~/poligon$ time dcraw -c -q 3 -w 8mpx.orf | convert -filter Lanczos -resize "1024x768" -contrast-stretch 0.1% -strip -unsharp 0.3x0.6+1.3+0 - 8mpx.jpg
real 0m2.567s

10Mpx
#$:~/poligon$ time dcraw -c -q 3 -w 10mpx.orf | convert -filter Lanczos -resize "1024x768" -contrast-stretch 0.1% -strip -unsharp 0.3x0.6+1.3+0 - 10mpx.jpg
real 0m3.668s

12Mpx
#$:~/poligon$ time dcraw -c -q 3 -w 12mpx.nef | convert -filter Lanczos -resize "1024x768" -contrast-stretch 0.1% -strip -unsharp 0.3x0.6+1.3+0 - 12mpx.jpg
real 0m3.814s

Jak to wszystko rozumieć? Pierwsze, co rzuca się w oczy, to stosunkowo niewielkie różnice w czasie obróbki pomiędzy plikami z matryc 10 i 12 Mpx i mocno odostająca od nich matryca 8 Mpx (na plus). Teoretycznie, skoro skok jest co 2 Mpx, różnice w czasach powinny być podobne. Wynika to z tego, że obraz z matrycy 8 Mpx jest nieskompresowany, natomiast pozostałe dwa przypadki już tak (postęp). Druga sprawa, to stosunkowo niewielkie różnice – dla słabszego sprzętu (Core 2 Duo) co to za różnica pomiędzy 4.24 s., 5.66 s. i 6.37 s. – można rzecz, pomijalna. Diabeł tkwi jednak w tym, że gdy będziemy mieli kolejkę np. 100 plików do automatycznego obrobienia (choćby tymi minimalnymi zmianami jak powyżej), to otrzymamy 7 minut, 9 minut i 10 minut (mocno zaokrąglając). Dalej jest to akceptowalny czas? Zapewne jest. I tu docieramy do sedna sprawy. Gdy weźmiemy czasy dla mocniejszej maszyny, to dla stukrotnego przebiegu powyżej komendy, dostajemy kolejny – 4 minuty, 6 minut i 6 minut (znowu zaokrąglając). I nadal są to czasy dla bardzo podstawowej obróbki, nic skomplikowanego się tam nie dzieje (wywołanie RAW, skalowanie, wyostrzanie, poprawka kontrastu i zapis do .jpg).

Wnioski? Rozmiar ma znaczenie. I o ile powyższe prymitywne zestawienie rzuca tylko zarys problemu wydajności starszych maszyn, o tyle można sobie wyobrazić, o ile wzrośnie czas obróbki materiału z przyszłościowych matryc naszych aparatów (18Mpx? 26Mpx?). I pisząc obróbka nie mam tutaj na myśli samo wywołanie zdjęcia. Spróbujcie obróbki w programie Darktable, gdyż obecnie chyba ten program najmocniej wydziera moc z naszych maszyn. Mnóstwo mocnych filtrów, zaawansowanej obróbki, duża ilość danych wejściowych i okazuje się, że takie Core 2 Duo to wymuszone minimum dla komfortowego i bezstresowego machania suwaczkami. I zgadza się, nie brałem tu pod uwagę ilości dostępnej pamięci, jednak dla powyższych wyliczeń nie miała ona większego znaczenia. Jednak przy solidnym zaparciu się nad obróbką zdjęć to już 2GB może się być za mało (mówimy o sprzęcie z czasów gdy 2GB było wyrazem nieujarzmionego snobizmu).

Zatem, czy warto zmieniać sprzęt na nowszy? Dla poprawy humoru zawsze. Dla zaspokojenia swoich amatorskich potrzeb obróbki jednego zdjęcia na miesiąc raczej nie. A w przypadku codziennego ślęczenia i przepuszczania zdjęć przez różne wywoływaczki, tudzież przy poszukiwaniach własnego wyrazu artystycznego – zapewne tak. Zaoszczędzone w ten sposób na obróbce sekundy i minuty w rozrachunku rocznym lepiej przeznaczyć na robienie zdjęć.

GTKRawGallery – w cieniu konkurencji

Pod tą mało oryginalną nazwą kryje się program z wieloletnimi tradycjami, choć nadal pozostający w cieniu bardziej znanych odpowiedników. A przecież rozwijany od 2007 roku GTKRawGallery to solidny kawałek programu, który ma za zadanie uprościć życie fotografom korzystającym na co dzień z Linuksa. Upraszcza je oddając nam do rąk kontrolę nad parametrami wywoływanego pliku RAW, umożliwia nałożenie na materiał kilku efektów, jak też grupować zdjęcia w albumy wg. tagów.

Wydanie wersji 0.9.6 przyniosło ze sobą niebagatelną zmianę (wśród wielu innych nie mniej ważnych) – program został przepisany pod Pythona 2.6, co powinno poprawić jego funkcjonowanie na nowszych dystrybucjach. Co się tyczy zainstalowania programu są dwie wieści. Zła to taka, że program nie doczekał się jeszcze paczek .deb. Dobra natomiast głosi, że jak większość programów napisanych w Pythonie, uda się GTKRawGallery uruchomić bez kompilowania i innych magicznych czynności. Pobrane archiwum rozpakowujemy, udajemy się do utworzonego katalogu i – uwaga – musimy uruchomić z prawami root’a plik setup.py.

#$ cd /home/…/gtkrawgallery-wersja
#$ sudo setup.py install

Program ulokuje się w katalogu /usr/local/share/gtkrawgallery i będzie dostępny po wpisaniu komendy w linię poleceń, bądź za pomocą menu – Programy -> Grafika -> GTKRawGallery. Dezinstalację przeprowadzamy poleceniem sudo uninstall-gtkrawgallery (urok standardów).

Gdzie tkwi wyjątkowość tego programu? Przede wszystkim w możliwości jednoczesnego wykorzystania możliwości Dcraw (wywoływanie plików RAW), ImageMagick (retusz, efekty, filtry, obróbka) oraz Exif (edytor metadanych). Po uruchomieniu zaprezentuje się nam widok przeglądarki…

.. za pomocą której możemy tworzyć albumy (nigdy nie potrafiłem katalogować zdjęć), wybrać zdjęcia do obróbki, edytować/uruchomić kolejkę batch (o ile coś do niej dodaliśmy), edytować etykiety oraz parę innych opcji dla lubujących się w benedyktyńskim porządkowaniu swoich zdjęć.

Jednak to co najciekawsze, kryje się pod dwukrotnym kliknięciem na zdjęciu:

Przechodzimy do okna w którym po prawej stronie znajdują się zakładki z opcjami narzędzi którymi możemy potraktować zdjęcie. Mamy zatem podgląd danych EXIF, wybór słów kluczowych Keywords, zakładkę z parametrami programu Dcraw (wywołanie surowego zdjęcia), kolejno Enhance, Transform, Effects dla retuszu, oraz Edit Metadata dla wypełnienia metadanych. Efekt obróbki zdjęcia możemy od razu zapisać na dysku (ikonka Save As po lewej górnej stronie belki), przesłać do zewnętrznego programu (np. Open With Gimp), czy też dodać plik do kolejki batch, którą uruchomimy w stosownym dla nas momencie (Add to batch queue). Jak widać, stworzonych jest tak wiele możliwości (wystarczy przejrzeć zakładki Enhance, Transform, Effects), że niemal eliminuje to konieczność obróbki zewnętrznym programem graficznym.

Z czego wynika mniejsza popularność tego programu? Cóż, zapewne z faktu powolnego rozwoju, jak też nieco archaicznego UI. Jednak zgrabne połączenie wywoływania zdjęć z ich retuszem, stawia ten program wśród nielicznych obecnych na Linuksie aplikacji tego gatunku. Bo najbliższy i prawdopodobnie jedyny odpowiednik takiej obróbki istnieje w postaci programu Darktable.

Umarł król, niech żyje LibreOffice

Co zrobi Oracle ze schedą po Sun Microsystems? Po paru nerwowych ruchach chyba nikt nie jest do końca pewien chęci Oracle do angażowania się w rozwój Wolnego Oprogramowania. Dlatego w trosce o najpopularniejszy wolny pakiet biurowy zawiązała się fundacja, która przedstawiła światu pod nazwą LibreOffice fork starego dobrego OpenOffice’a (do którego prawa nabył, wraz z nabyciem Sun’a, Oracle).

Fundacja The Document Fundation zrzesza w swoich szeregach takie firmy i organizacje jak Novell, Google, Red Hat, Canonical, FSF, OASIS, Fundacje GNOME i kilka innych. Zadaniem tej fundacji jest utrzymanie wolnego i nieograniczonego dostępu do pełnoprawnego pakietu biurowego rozwijanego przez społeczność. Do grona został też zaproszony Oracle, w charakterze dawcy znaku firmowego (OpenOffice), lecz wobec braku jednoznacznego stanowiska ze strony Oracle, fork otrzymał swoją nazwę LibreOffice.

Czy będziemy musieli zapomnieć wtarty w podświadomość skrót OO? Szczerze mówiąc, to dopinguję tej inicjatywie, a pakiet biurowy – jak się zwał lub będzie zwał, to mało ważne. Istotne, by działał sprawnie i nie powodował niedomówień licencyjnych.

Direct3D 10/11 dla Linuksa

Technologia z piekła rodem w Linuksie? Mrzonki i fantazje dla realistów, marzenia ściętej głowy dla graczy, a dla ideologów czas na ceremonialne posypanie głowy popiołem. Okazuje się, że będziemy musieli oswoić się ze stanem rzeczy, iż implementacja API Direct3D 10/11 dla Linuksa stała się faktem. Oficjalne została dołączona do biblioteki Gallium3D wykorzystywanej przez otwarte sterowniki graficzne.

Sami autorzy sugerują, jakie możliwości otwierają się teraz przed twórcami oprogramowania. O wiele bardziej przejrzysta i mniej skomplikowana struktura API od tego co prezentuje nabrzmiały przez wieki OpenGL, umożliwia prostsze i szybsze pisanie programów wykorzystujących możliwości graficzne naszego ulubionego systemu.

Thanks to a very clean and well-though design done from scratch, the Direct3D 10/11 APIs are vastly better than OpenGL and can be supported with orders of magnitude less code and development time, as you can see by comparing the lines of code of this commit and those in the existing Mesa OpenGL implementation.

Implementacja jest natywna, nie opiera się zatem na tłumaczeniu Direct3D do OpenGL, jak ma to teraz miejsce w WINE. Jakie to stwarza możliwości dla portowania gier z wiodącego systemu chyba nie muszę wspominać. Czy szansa zostanie wykorzystana?

Drżyjcie o wasze kernele

Pomimo tego, iż mamy ‚nowe i lepsze’ czasy, nie wolno zapominać tradycji i mądrości naszych przodków, którzy uknuli powiedzenie ‚gdzie kucharek sześć, tam nie ma co jeść’.

Sprawa dotyczy poprawki dwóch dziur odkrytych w systemach 64-bitowych, które umożliwiały lokalnemu grabieżcy uzyskanie praw roota. Błędy z grubsza polegały na niedociągnięciach w konwersji danych z 32-bitów na 64-bity i vice versa. Co więcej, błędy te zostały odkryte w 2007 roku i naprawione w kernelu 2.6.22.7. Lecz następnie ‚ktoś’ przez swoją niefrasobliwość ciągnął kolejne wydania kernela na źródłach bez rzeczonej łatki. Exploit który w 2007 roku umożliwiał przejęcie praw roota, po drobnych poprawkach działał na nowo.

I tak do wydań dystrybucji opierających się o kernel 2.6.22 </ 2.6.3X nadciągnęły masowe poprawki, by pozbyć się tych kilkuletnich dziur (CVE-2010-3081, CVE-2010-3301). Jeżeli ktoś ma awersję do update’ów, polecam zaktualizować przynajmniej kernel.

Dziura jak dziura, mylić się jest rzeczą ludzką, jednak w tym wszystkich przeraża mnie podejście ‚branżowych’ stron Ubuntu, dla których od poinformowania o niebezpieczeństwie ważniejsze jest jak to ‚Make Ubuntu Look Like Mac OSX In Seconds Using Macbuntu’ (http://www.webupd8.org), lub ‚Linux on TV: ‘The Glades’ – detectives run GNOME on a Windows-branded PC’ (http://omgubuntu.co.uk). Z taką prasą to nic dziwnego, że poziom wiedzy użytkownika systemu będzie ograniczał się do wyboru koloru tapety na pulpit.

Sposób na fonty

Niekiedy na potrzeby swoich projektów graficznych (obróbka grafiki/zdjęć/wektorów, itp) mamy potrzebę użycia niebanalnych znaków graficznych. Potrzeba taka rodzi pytanie – skąd zatem brać fonty? Poza tymi obecnymi w repozytoriach, fonty można znaleźć porozrzucane w sieci niemal wszędzie. Jedną z takich stron jest FontPark, która wyróżnia się jasnym i klarownym stanowiskiem twórców:

FontPark is the largest portal noncommercial fonts . The current database has more than 70,000 fonts available for noncommercial and commercial use for PC Mac and Linux.

Witryna wygląda na świeżą i po prawdzie widzę jeszcze lekkie niedomówienia w postaci braku podawania autorów fontów, czy jasnego określenia licencji, niemniej biblioteka 70,000 fontów kusi i zapewne niejeden znajdzie tam coś dla siebie.

Jak instalować fonty? W Ubuntu zwyczajowo, po ściągnięciu klikamy nań dwa razy (fonty instalują się lokalnie w ~/.fonts, aby były widoczne globalnie należy je przenieść do /usr/share/fonts/).

Potrzeba buntu

Prasłowiański atawizm bycia ‚przeciw’ przepchnął mnie systematycznymi kuksańcami na stronę głosicieli prawdy ‚Dystrybucje ciągłe są lepsze od terminowych’. Jak jednak do tego doszło i czy stało się tak naprawdę?

Mianowicie, po osiągnięciu granicy świeżości Ubuntu starszej daty i na wspomnienia wizji instalowania systemu od zera, wezbrała we mnie niechęć (pogardy do automatycznej aktualizacji na wyższą wersję nabrałem już dużo wcześniej). Niechęć potęgowana świadomością, iż taki Debian Sid odżywiany niemal codziennymi aktualizacjami od paru lat (Dwóch? Trzech?) pozwala mi być na świeżo z wersjami programów i usług. Dlaczego zatem dałem się wpędzić do błędnego kółka corocznej zmiany systemu (zwykle instaluję wersje Ubuntu XX.04) i jego konfiguracji. Wszystko sobie dobrze wyliczyłem – wyszło na to, że nawet na naprawy ‚wpadek’ w paczkach w Sidzie poświęcam mniej czasu, niż na zmaganie się z nowymi trendami w Ubuntu, z wersji na wersję. Mało tego, równolegle do kiełkowania tych przemyśleń, na osobnym komputerze próbowałem (i nadal próbuję) dać szansę kolejnemu Linuksowi który ma określone terminy wydań – OpenSuSe użytkuję w sposób ciągły od wersji 11.2. Pomimo tego, iż podoba mi się jego zachowawczość w stosunku do nagłych skoków ‚koncepcyjno-jakościowo-wizualnych’ spotykanych w Ubuntu, to też zostaję momentami przyparty do ściany retorycznym zapytaniem ‚A gdzie nowsza wersja programu (…) i dlaczego muszę czekać do kolejnego wydania systemu?’.

Zatem porzucenie rozwiązań terminowych na rzecz ciągłych powinno być logicznym i niewymuszonym krokiem ku wygodzie osobistej i samozadowoleniu. W podjęciu takiej decyzji pomagają kolejne pomysły developerów kierunkujących wydania Ubuntu w stronę jasno określonych grup społecznych, w których mimo chęci nie odnajduję miejsca dla siebie. Pomaga problem z aktualizacją programów do nowszej wersji, a radość z zapowiedzi ich pojawienia się w nowszym wydaniu systemu przyćmiewa deja vu mrocznego pokoju z przygarbioną nad klawiaturą postacią, oświetloną trupio-bladą poświatą z monitora. I demoniczny śmiech zza zamkniętych drzwi ‚Nigdy nie odgadniesz, jak teraz konfiguruje się XXXX !! Jesteś stary, za stary… ‚.

No to co, Debian Sid, prawda? Wiarę w takie postanowienie podsyca wieloletnia znajomość z systemem, sposobem konfiguracji, możliwością łagodnego przechodzenia z wersji programu na kolejną, w miarę aktualne repozytoria i wiele innych zalet. Sielanka na obrazie ‚Babie lato’ wydaje się być przy tym siermiężną formą rekreacji. Jednak, posępny nastrój i w tym wszystkim potrafi znaleźć dziurę wypełnioną bezprocentową goryczą. A co, gdy będę chciał postawić system od nowa na nowym komputerze? Konfiguracja Debiana od podstaw do formy używalnego biurka to, lekko mówiąc, droga do piekła i z powrotem. Konfiguracja za pomocą konsoli to doskonała forma pobudzania szarych komórek, o ile nie są one atakowane sygnałami z zewnątrz ‚miałeś dziś dywan wytrzepać/wynieść śmieci/choinka gnije/do sklepu po ziemniaki/panie, to bym chciał na jutro-za godzinę-na wieczór’. Dlatego proza błogiego luksusu posiadania zajęć wszelakich siłą rzeczy przymusza człowieka do skracania sobie drogi przez choćby stosowanie graficznych narzędzi do niektórych czynności (zarówno przy początkowej konfiguracji systemu jak i późniejszym użytkowaniu).

Ach tak, pozostają gotowe dystrybucje ‚debianowe’ przeznaczone na biurko. Ostatnio triumfy święci bardzo miły z nazwy i wyglądu Linux Mint Debian Edition. Szybki teścik, łatwo poszło, po starcie zainstalowanego systemu typowe problemy z zestawu ‚standard’ – do NVIDII należy sterowniki ‚dograć’ z repozytorium (och, gdzież jesteś Jockey-gtk z Ubuntu), Compiza sobie trzeba włączyć ‚z palca’ (och, gdzie się podziała zakładka ‚Opcje wizualne’ z ‚Preferencji wyglądu’?) i wiele innych michałków, na które zasadniczo nie zwracam uwagi. Jednak, jak wspomniałem, chcę poczuć XXI wiek i wślizgiwać się w nowe pielesze systemu bezboleśnie – tak, by od razu przystąpić do konstruktywnego wykorzystywania resztek stetryczałego intelektu.

I tak oto zostało położone przede mną na szali z jednej strony Ubuntu/OpenSuSe z uproszczeniami w konfiguracji większości rzeczy oczywistych, ale ograniczone okowami wydań, z drugiej strony pozostał Debian/Mint i enigmatyczne spojrzenie na użytkownika ‚jak wiesz jak, to se zrób’. Jednoczeście pozwalając na zachowanie kontaktu z większością nowych wydań programów, bez demolki partycji ‚/’ co pół roku.

Jak utarło się w demokracji, większość powyższego wywodu można skontrować. Dostępne argumenty są solidne i znajdujące poparcie w rzeczywistości – ‚jak to nie ma nowszych wersji dla Ubuntu/OpenSuSe, jest PPA/One Click Install’, ‚a co ile instalujesz system, że tak się zżymasz o ten czasu konfiguracji świeżego biurka’, ‚jak jesteś głupi, to używaj Windowsa’, itp, itd. Tu jednak nie chodzi o wykazanie, która dystrybucja jest lepsza, lecz bardziej, które bolączki Linuksów przyprawiają o ból zębów zwykłych użytkowników, podczas gdy developerzy może i dobrze się bawią testując swoje umiejętności.

W zasadzie na tym powinienem zakończyć i oczekiwać lepszego, lecz dla ambitnych poniżej znajduje się próba zebrania kilku przywar, które mnie osobiście mocno leżą kamieniem nerkowym na sercu.

Jest siedem grzechów głównych ujętych prostymi słowami:

– niekompatybilność paczek między dystrybucjami,
– niekompatybilność wizji kierunku rozwoju usług/programów/dystrybucji między developerami,
– niekompatybilność sposobu obsługi pulpitu/systemu w obrębie tych samych środowisk graficznych w różnych dystrybucjach,
– brak zachowywania zgodności z starszym oprogramowaniem,
– brak wizji stworzenia w kernelu stabilnych rozwiązań dla twórców sterowników,
– skłonności do blichtru zamiast rozwiązań o rozsądnych podstawach,
– model ‚one man army’ przy tworzeniu programów użytkowych

Tajne akcje Nautilusa

Co powinien potrafić menadżer plików? Niezbędne minimum operacji na plikach, czy całe multum przyciskających go do podłogi opcji, a może… Umożliwić użytkownikowi samemu określić, co dla niego ważne. Tak postępuje np. Thunar, który udostępnia konfigurowanie akcji dostępnych potem pod PPM. Po zaznaczeniu kilku plików, bądź folderów, bądź jednego pliku, w zależności od jego typu i rodzaju, można dokleić do menu oczekiwane przez nas traktowanie takiegoż pliku. W ten sposób na moim komputerze Sprytny Skrypt w tle przerabiał wybrane przez mnie zdjęcia RAW na pliki .jpg. Sprytna Komenda wysyłała pod skonfigurowany adres FTP i do konkretnego katalogu pliki/katalogi które wskazałem. I wiele wiele innych udogodnień wspierających ekologiczne wykorzystanie zasobów komputera.

Z różnych powodów niezależnych ode mnie (a raczej zależnych od mojego lenistwa), Thunar oczekuje na powrót do żywych na leżącej odłogiem partycji z leżącym kompletnie Debianem. Siłą rzeczy traktuję od paru miesięcy Nautilusa jako zło konieczne i niezbędne do poruszania się w gąszczu plików na dysku. Lecz cóż to za poruszanie się, skoro nie mogę uprościć sobie życia jak w Thunarze.

Jak to się zwykle w dobrych bajkach z morałem kleci, okazało się, że zbłądziłem. Bowiem do Nautilusa istnieje od jakiegoś czasu podobne narzędzie jakie znałem wcześniej z Thunara. A wręcz nawet bardziej rozbudowane. Odkryłem bowiem paczkę nautilus-actions. Nie wiem dlaczego nie jest ona domyślnie instalowana ze systemem, bo to wręcz niezbędne narzędzie do automatyzowania i upraszczania wielu nudnych i powtarzalnych czynności.

Po zainstalowaniu paczki mamy do dyspozycji polecenie nautilus-actions-config-tool (znajdziemy je też w Menu->Preferencje-Nautlus-Akcje-konfiguracja). Niestety dodatek nie doczekał się jeszcze pełnego spolszczenia, ale dla nacji która posiada największych odsetek osób z wykształceniem wyższym język nie powinien stanowić bariery.

Jak w skrócie się tym posługiwać? Poniżej prosty przykład wykonywania kopii Ważnych Plików do katalog /home/moj_backup (gdzie ‚moj_backup’ musi zostać wcześniej utworzony i posiadać prawa dostępu/zapisu/odczytu dla użytkownika).

Na początku otworzymy konfigurator akcji i nie przestraszymy się mnogości opcji. Zwrócimy uwagę od razu na zakładki i wybierzemy pierwszą z nich, o nazwie ‚Akcja’. Wpiszemy sobie tam nazwę czynności (Context Label), która się pojawi w rozwijanym PPM menu.

Teraz kolej na zakładkę ‚Command’, gdzie określimy jakie polecenie ma się wykonać na zaznaczonych przez nas plikach. Nie ukrywam, najprościej jest tutaj używać poleceń tekstowych, bez gui (bo zwykle bez problemów przyjmują parametry), choć jeśli ktoś będzie chciał wywołać coś graficznego – nie ma problemu (o ile program przyjmuje parametr w postaci nazwy pliku/katalogu itp). Istotny jest tutaj przycisk ‚Legenda’, który podpowie nam jaki parametr dla naszego polecenia co będzie oznaczał (np. użyte w przykładzie %m to lista wszystkich zaznaczonych plików oddzielona spacją).

Kolejna zakłada to ‚Folders’, która określi podczas pracy w jakich katalog ta akcja ma być udostępniona. Domyślnie jest tam wpisany ‚/’, czyli akcje będą się pojawiały dla każdego katalogu po którym będziemy się poruszali. Możemy to ograniczyć i wpisać np. ‚/home/toja/pliki_na_ktorych_pracuje’ i wtedy akcje pojawią się w menu, gdy będziemy w podanym katalogu.

Następna zakładka to ‚Conditions’ pozwala ustawić, czy akcja ma być pokazywana gdy są zaznaczone pliki, foldery, a może obydwa typy. Ustawimy również dla jakiego rozszerzenia ma się uaktywniać dana akcja (np. *.jpg), czy też dla jakiego typu plików (mime).

Tak wykonaną akcję zapisujemy trwale za pomocą opcji w menu lub skrótu ‚ctrl+s’. ‚Ctrl+n’ doda nam kolejną akcję, i tak dalej. W menu ‚Edit->Preferencje’ (uwielbiam tę spójność językową elementów GUI) znajdziemy wiele innych ciekawy opcji określających styl pojawiania się menu z akcjami, itp. Aby aktywować w podręcznym menu to co skonfigurowaliśmy, potrzebujemy uruchomić ponownie Nautilusa (po pierwszej instalacji dodatku). Wykonujemy zatem lub wylogowanie i zalogowanie, lub zabicie procesu, lub restart komputera, wedle upodobań. I w końcu można się poczuć jak Pan na włościach…

Program znajduje się w repozytoriach Lucid’a, oraz w repozytoriach Squeeze (testing) i Sid (unstable) Debiana (oraz ostatnio też Mint’a).

Masowe przetwórstwo

Niekiedy zachodzi potrzeba, że człowiek „musi”. Życie i społeczeństwo stawiają przed nami wymagania i oczekiwania, którym tylko maszyna byłaby w stanie sprostać. I cóż innego pozostaje, jak nie zdać się na automatyzm masowej przeróbki materiału wsadowego.

Uściślając – poznajcie narzędzie o wdzięcznej nazwie Converseen. To nic, że jest napisane z wykorzystaniem bibliotek QT. Program ma za zadanie przerabiać wskazany typ pliku graficznego na inny, określony przez użytkownika. Jako, że korzysta w tym procesie z bibliotek Magic++, liczba rozpoznawalnych formatów to, nie bez kozery mówiąc, niemal 100 typów. Ponieważ sama konwersja to ubogie spektrum zastosowań, mamy również możliwość zmiany rozmiaru zdjęcia/obrazka, ustawienia parametrów jakościowych efektu końcowego, czy też zmiany nazw.

W porównaniu do kombajna konwersyjnego Phatch, Converseen ma znacznie prostszy i czytelniejszy interfejs, oraz póki co, też mniejszą liczbę funkcji. Brakuje głównie mechanizmu wyostrzania materiału po zmniejszeniu, co jest niejako obowiązkiem. Jednak program może być użyteczny, ze względu na czytelny i prosty interfejs, szczególnie dla osób mających mniejsze wymagania co do przerabianych zdjęć.

Converseen znajduje się w PPA (wersja dla Lucid’a):


sudo add-apt-repository ppa:ferramroberto/extra
sudo apt-get update
sudo apt-get install converseen

Translate »