Впечатления от новой мышки.

Была у меня лазерная мышь SVEN ML-1600. Простой, классический вариант. Три кнопки, средняя - ролик, плюс кнопка для переключения DPI c 800 на 1600.

Но стала у неё плохо срабатывать любимая левая кнопка(а именно ей чаше всего я и пользуюсь, ведь выделение различных объектов и открытие завязано именно на неё, на неё завязан огонь в любимых играх action жанра и добрая половыина всего взаимодействия с GUI-based программами. В общем, это самая важная и нужныя кнопка у мыши. И раз она стала нечётко срабатывать, пришло время отправить мою SVEN ML-1600 на заслуженный покой.


Стал вопрос о выборе новой мыши. Выбрал я себе A4Tech Q4-370X-1 Black USB - очень хорошие характеристики у мыши. Повышение частоты шины до 500 Мгц, переключение на разные режимы DPI(их там целых пять), всё это обычно встречается только у дрогих моделей. Но у этой замечательной мыши есть один недостаток - короткий кабель. И ещё при работе с Linux она почему-то иногда то ускорялась без причины, то замирала. Специальные кнопки не работали. А я обычно только в Linux и работаю, если я на Windows - значит помогаю кому-то, или чиню чей-то компьютер. В общем, Windows - это крайний случай. Не моё. Я бы его в идеальную игровую приставку только ставил, игр под него много:)

Сегодня пошёл в свой любимый из чеканских(район такой в городе, где я живу - Кишинёве) компьютерный салон, Matrix. Хорошие, внимательные и отзывчивые к нуждам клиента продавцы-консультанты, и привлекательные цены - это их преимущество перед целым рядом других салонов. Хотя если у них чего-то нет, есть Cosmo. Там я тоже не мало разных вешей покупал, отличные ребята. Но цены по многим позициям чуть-чуть дороже.

В общем доплатил я немного, и взял мышку чуточку подороже. Мышка от моего любимого производителя - фирмы A4Tech. У меня камера и клавиатура тоже от этого производителя. На мой взгляд - их продукция для меня оптимальна, т.к. при приличном качестве у их продуктов довольно демократическая цена. Мышка модели A4Tech X6-55D. Рабочее разрешение у неё 1000 DPI, это удобное рзрешение и для работы, и для игр. Необычный дизайн, замечательное колесико прокрутки.Колёсико прорезиненное и очень чётко, осязаемо прокручиваемое - это то, что очень важно для любого любителя игр жанра Shooter, ведь приближение оптического прицела и смена оружия традиционно завязаны на колёсико прокрутки, так что от него зависит точность игры. Кроме левой кнопки есть ещё и маленькая кнопка 2x, она позволяет осушествить двойной клик одним нажатием(работает и в играх, так что пригодится не только в работе). И наконец,слева, на боку, расположены две кнопки работающие как "вперёд" и "назад" в файловом менеджере и браузере.

Нижняя часть мыши выполнена из какого-то шелковистого на ошупь, и очень приятного платика. Верхняя из глянцевого, тоже приятного на ошупь пластика. Тыльная часть мыши имеет глянцевую черную вставку.

Нажатия на кнопки чёткие, с характерным шелчком. Именно  такие кнопки и должны быть у мыши, с которой не только работают, но иногда и играют. Ведь не уверенность, было ли нажатие, или нет, может подвести, да и просто раздражает. В общем что я могу сказать про эту мышку - мышка красивая, недорогая и очень хорошо сделана для её ценовой категории.

А вот парочка изображений, одно сделано мной, а второе нашёл готовое:

Ну разве она не красавица? Если надумаете покупать простую и дешёвую лазерную мышь, такая вам точно подойдёт. И кроме всего прочего она работает на почти любой ровной поверхности, даже на стеклянной. Для любителей стекла на столе - это просто находка.

Archlinux, xulrunner 2.0 и WebKitGTK+ 1.3.13 - устраняем ошибку No more handles [Unknown Mozilla path (MOZILLA_FIVE_HOME not set)]

Случилась у меня проблемма с моей любимой IDE. Думаю, не сложно догадаться, что это Eclipse.

Почему Eclipse?

Eclipse - это фреймворк, позволяющий из разных компонент построить IDE на любой вкус, и для разных языков. Это не IDE, а мета-IDE, местами больше напоминающая ещё одну ОС:)
Среда написана на Java, что является гарантией её корректной работы на различных ОС(не известно, на чём прийдётся работать в будущем).
Она легко расширяема(в этом она мне напоминает Emacs, так как среди расширений есть IDE для различных языков, разные редакторы, файловый менеджер, медиаплеер, фреймворк для создания отчётов и многое другое).
У меня установленно всё что нужно, для изучения технологий XSL, Java и Scheme(я изучаю Sheme по замечательной книге SICP), а также Web Tools и ещё кое-что(для работы с XML/HTML/CSS и JavaScript).

Суть проблемы

Установленно всё на Archlinux 64-bit, и при этом я использую firefox 4/xulrunner-2.0 и Gnome 3(а вместе с ним и WebKitGTK+ 1.3.13). Из-за этого то свежего софта и сломался компонент SWT, отвечающий за внутренний браузер. При запуске Eclipse вместо браузера отображается такое вот сообщение:

No more handles [Unknown Mozilla path (MOZILLA_FIVE_HOME not set)]
org.eclipse.swt.SWTError: No more handles [Unknown Mozilla path (MOZILLA_FIVE_HOME not set)]
 at org.eclipse.swt.SWT.error(SWT.java:4109)
 at org.eclipse.swt.browser.Mozilla.initMozilla(Mozilla.java:1739)
 at org.eclipse.swt.browser.Mozilla.create(Mozilla.java:656)
 at org.eclipse.swt.browser.Browser.(Browser.java:119)
 at org.eclipse.ui.internal.browser.BrowserViewer.(BrowserViewer.java:225)
 at org.eclipse.ui.internal.browser.WebBrowserEditor.createPartControl(WebBrowserEditor.java:78)
 at org.eclipse.ui.internal.EditorReference.createPartHelper(EditorReference.java:670)
 at org.eclipse.ui.internal.EditorReference.createPart(EditorReference.java:465)
 at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:595)
 at org.eclipse.ui.internal.EditorAreaHelper.setVisibleEditor(EditorAreaHelper.java:271)
 at org.eclipse.ui.internal.EditorManager.setVisibleEditor(EditorManager.java:1429)
 at org.eclipse.ui.internal.EditorManager$5.runWithException(EditorManager.java:942)
 at org.eclipse.ui.internal.StartupThreading$StartupRunnable.run(StartupThreading.java:31)
 at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
 at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:134)
 at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3515)
 at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3164)
 at org.eclipse.ui.application.WorkbenchAdvisor.openWindows(WorkbenchAdvisor.java:803)
 at org.eclipse.ui.internal.Workbench$31.runWithException(Workbench.java:1567)
 at org.eclipse.ui.internal.StartupThreading$StartupRunnable.run(StartupThreading.java:31)
 at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
 at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:134)
 at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3515)
 at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3164)
 at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2548)
 at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2438)
 at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:671)
 at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
 at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:664)
 at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
 at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115)
 at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
 at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
 at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
 at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369)
 at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
 at java.lang.reflect.Method.invoke(Unknown Source)
 at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:620)
 at org.eclipse.equinox.launcher.Main.basicRun(Main.java:575)
 at org.eclipse.equinox.launcher.Main.run(Main.java:1408)
 at org.eclipse.equinox.launcher.Main.main(Main.java:1384)

И всё. Стал я искать в интернете сведения, как эту проблемму решить. И нашёл два варианта решения, оба базируются на добавлении в конец eclipse.ini опций для компонента WEB-браузера в SWT. Вначале добавил в конец файла эти строки:

-XX:-UseCompressedOops
-Dorg.eclipse.swt.browser.XULRunnerPath==/usr/lib/xulrunner-2.0/

Но не завелось, ведь xulrunner версии 2 и выше не поддерживает JavaXPCOM, а эта технология была связующей между Java-приложениями и объектами XPCOM. В результате при апгрейде до Firefox 4 и Gnome 3 автоматически ломается работа браузера, встроенного в приложения Java. SWT c версии 3.6 позволяет использовать WebKit вместо xulrunner, а в SWT 3.7 и Eclipse 3.7 этот HTML-движок является компонентом web-браузера по умолчанию. Я решил, что вторая рекомендация мне поможет. Для задействования для отображения HTML движка WebKit, в eclipse.ini надо добавить строку:

-Dorg.eclipse.swt.browser.UseWebKitGTK=true

В результате мой конфиг(eclipse.ini) стал выглядеть так:

plugins/org.eclipse.equinox.launcher_1.1.1.R36x_v20101122_1400.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.1.2.R36x_v20101019_1345
-product
org.eclipse.epp.package.javascript.product
--launcher.defaultAction
openFile
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
256m
--launcher.defaultAction
openFile
-vmargs
-Dosgi.requiredJavaVersion=1.6
-XX:+UnlockExperimentalVMOptions
-XX:+UseG1GC
-Xms256m
-Xmx256m
-XX:+AggressiveOpts 
-Dorg.eclipse.swt.browser.UseWebKitGTK=true

Из конфигурации видно, что оперативы у меня мало(на борту всего 1Гб памяти, и 64 метра из неё съедает встроенная GeForce 6100), и я использую новый сборщик мусора и агрессивную оптимизацию. Всё из-за устаревшего железа, что делать... Но проблемма осталась, всё так-же eclipse ругался на отсутсвие подходящей версии xulrunner. Почему не завёлся WebKit? У меня паралельно имеется Eclipse Helios(версия 3.6), и тестовая версия Eclipse Indigo(версия 3.7). И в обоих версиях всё осталось по прежнему. Так в чём же причина? С Gnome 3 установилась и WebKitGtk версии 1.3.13-1. Смотрим скриншот:

А на сайте проекта WebKitGTK что мы видим? Вот такое предупреждение: What's new in WebKitGTK+ 1.3.13? IMPORTANT: In this release the GObject DOM Bindings contain a major change. Итак, в WebKitGTK+ сломали совместимость, и пока команда, разрабатывающая SWT не успела внести нужные изменения в SWT 3.7, а SWT 3.6 уже никогда не заработает с WebKitGTK+ 1.3.13. Получается, что использовать xulrunner 2.0 и выше мы не можем, WebKitGTK+ 1.3.13-1 тоже не модходит. Удалять новыю версию WebKitGTK+? Так я люблю максимально свежий софт, поэтому и перешёл с Ubuntu на Debian testing, а затем и на Archlinux. Удалять новую версию библиотеки ради установки старой версии - неправильно. И я пошёл на трюк, использовав такой вот скрипт для запуска Eclipse:

#!/bin/bash
export LD_LIBRARY_PATH=libwebkit-1.2.7-1-x86_64.pkg/usr/lib
./eclipse

Да, скрипт лежит прямо в корневой директории Eclipse. Я качаю архив с Eclipse для Linux 64-bit и просто разворачиваю его на специальном разделе диска. Устанавливать eclipse при помощи pacman не вижу смысла, т.к. eclipse умеет обновлять установленные модули сам, используюя собственный механизм репозиториев расширений и механизм их обновления. Cкачал вручную пакет с нужной версией WebKitGTK+, он называется libwebkit-1.2.7-1, и распаковал его в каталог с моей версией Eclipse. А при помощи LD_LIBRARY_PATH я заставил eclips загружать нужную ему версию библиотеки WebKitGTK+. Это, конечно, выглядит как грязный хак, но ведь теперь всё работает(только запускать надо Eclipse через запуск шелл-скрипта, но ведь это не такая уж большая проблема?). В общем, я боролся с коварным багом, и хоть и не по правилам, но сделал его. И Eclipse опять работает как часы:)

Для всех пользователей среды рабочего стола Gnome и Archlinux праздник. Вчера Gnome3 был добавлен в репозиторий [testing]. В обед я ещё ставил Gnome3 из [gnome-unstable], и вот он уже в тестинг. Не зря я перепробовал разные дистрибутивы, но больше всех люблю Arch, ох не зря! Разработчики этого чудесного дистрибутива не спят, работают оперативно.
Итак, что же хорошего в новом Gnome нашёл я для себя? Смотрим, что у Gnome3 под катом:
Начнём с Gnome Shell. Я собирал Gnome Shell из git ещё в пору его самых ранних версий, и он неуклонно улучшался. Итак, его основные достоинства:

• Удобный поиск приложений и документов.
• Поиск введённого запроса в Wikipedia и Google
• Наглядное и интуитивно понятное управление рабочими столами и окнами
• Упор на использование открытых на весь экран окон, и использования нескольких рабочих столов.
• Панель "избранное", с правого края экрана очень похоже на докбар в стиле Cairo Dock, или AWN. Она отображает значки приложений, запущенных вами, и добавленных в избранное вами. Значки запущенных приложений подсвечены, как и положено.
• Миниатюры окон запущенных приложений, с возможностью увеличения/уменьшения нужного окна при помощи скролинга мышью(юзайте ролик, господа:))

Обобщаем увиденное

Теперь по порядку, что же мы имеем. А имеем мы оболочку, которая объединяет меню приложений похожее на Unity, док-панель типа Cairo Dock(или AWN), а также поиск и запуск приоложений как в Gnome-Do(или Launchy). Интерфейс минималистичный и очень удобный для нетбуков или планшетов, и других девайсов с небольшим монитором. Есть два режима работы, при одном из них вы видите рабочий стол и минималистичную панель. На ней индикатор активного приложени, кнопка "Обзор" для перехода в основной режим, по центру часы, справа индикатор раскладки, индикатор звука, и индикатор вашего статуса для IM(Telepathy), совмещённый с меню выхода из сеанса, перезагрузки и отключения ПК.
В основном режиме вы увидите вышеописанные меню запуска, панель "избранное", миниатюры окон и строку поиска, а также менеджер рабочих столов.
Кроме того, системные требования у Gnome3 даже ниже, чем у второй версии. Сразу после загрузки в Gnome3 я посмотрел на расход памяти, система вместе с несколькими программами в автозагрузке и Gnome3 израсходовала всего 237 мегабайт оперативной памяти, и 0 мегабайт из swap. Честно говоря, не ожидал такого. KDE4 был куда более прожорливый в этом плане с самого начала. Работает стабильно, что радует. С Ubuntu и его Unity у меня с самого начала были проблеммы, оно постоянно вылетало и перезапускалось. С Gnome Shell такого не наблюдается.

Заключение.

Я очень боялся, что Gnome3 станет прожорливым, как KDE4. К счастью, это не так. У него более интуитивный и продуманный интерфейс, не похожий не на что, виденное раньше в других ОС. Центр управления стал ещё проще и понятней, очень похож на такой-же из KDE4. Правда настроек там пока немного. Кроме того, стоит обратить внимание на gnome-tweak-tool, с ним вы получите немного больше возможностей для настройки, и на dconf-editor для настройки тех опций, которые иначе не настроить. Простота и удобство новой версии Gnome производят самое лучщее впечатление. Ничего похожего, даже близко подобного по простоте и удобству я просто не видел. Разработчики Gnome совершили невозможное, создав первую среду рабочего стола, которая отойдя от традиционных интерфейсов рабочего стола, сделали среду намного интуитивней, проще и удобней. Проработав в ней немного, я понял что старый Gnome и другие среды рабочего стола просто не способны предложить подобный уровень удобства. Попробуйте новый Gnome3 и вы.

Установка Gnome3 в Archlinux

В Archlinux для этого надо раскоментировать репозиторий [testing]:

 
#testing uncommented
[testing]
Include = /etc/pacman.d/mirrorlist

Затем обновить систему командой:

 
# pacman -Syu 

И установить Gnome Shell, если вы хотите получить Gnome3 со всем функционалом, без этого пакета запускается режим fallback, который мало отличается от традиционного Gnome2, так как вместо новых возможностей вы получаете классический Gnome с двумя панелями.

 
# pacman -S gnome-shell

Пару скриншотов:

The Canterbury Project-апрельская шутка, которая заставляет задуматься о совсем не шуточных вопросах недостаточного взаимодействия дистростроителей

Вчера зашёл на www.archlinux.org, а там висит новость о создании нового проекта The Canterbury Project. В анонсе говорилось о создании нового дистрибутива, который будет простым как Arch, стабильным как Debian, податливым(скорее всего на этом месте должно быть слово "гибким", а не "податливым", т.к. обороты речи не переводятся дословно) как Gentoo, иметь солидный фреймворк для создания Live систем как Grml, и открытым(для новых идей и коммитов, наверно...) как openSUSE.

На сайтах всех упомянутых дистрибутивов висела одна и та же страничка приветсвия.Скриншот и ссылки прилагаются:

Новость на www.archlinux.org

Новость на сайте openSUSE

Новость на сайте Grml

Новость на сайте Gentoo

И, наконец, признание Debian, что это всего лишь первоапрельская шутка.

Что эта новость - шутка, было понятно сразу. Союз таких разных проектов подобен лебедю, раку и щуке из небезизвестной басни Крылова. Разница в организации пакетных менеджеров, где у Debian и openSUSE c Grlm классический подход, с использованием обычных бинарных пакетов(deb и rpm, но они очень похожи по своему устройству). У Arch бинарные пакеты более простого устройства, и более шустрый менеджер пакетов, а также система PKGBUILD'ов похожая на скрипты для сборки пакетов в системах семейства BSD. А Gentoo вообще создан на идее собирать пакеты под используемую архитектуру со всеми мыслимыми и немыслимыми оптимизациями. И только с нужными вам USE-флагами. Это позволяет вам держать в системе только те программы, которые нужны вам, и только с нужным вам функционалом. Такой аскетизм в IT позволяют получить компактную, нетребовательную к ресурсам и заточенную под ваши нужды ОС. Но при этом немало времени у вас будет уходить на доводку системы до ума. Надо будет изучать зависимости, хорошо разбираться в конфигурации системы и вникать во многие тонкости и ньюансы системы. Кроме того, в отличии от похожего в этом отношении Arch'а вам самим прийдётся собирать все пакеты для вашей системы. И если для таких целей у вас нет сервачка с билд-сервером в подсобке, то сборка пакетов при массштабном обновлении может идти сутками:)

Кроме того, openSUSE силён в удобстве настройки всего и вся из GUI, прекрасным дизайном и юзабиити, и великолепной поддержкой и документацией.

Debian славится своей стабильностью и надёжностью. Также известен своей неторопливостью и неповоротливостью в деле принятия новых идей и решений. Новые патчи могут годами ожидать внесения в Debian, и просто потерять свою актуальность к моменту решения их судьбы неторопливыми, и очень осторожными разработчиками.

Grml это базирующийся на Debian дистрибутив, главное достоинство которого - это очень хорошая платформа для создания Live систем, которые грузятся с CD/DVD, а также флеш-брелков и внешних винтов. Используют это чудо бородатые сисадмины и прочий, помешанный на порядке и безопасности, люд.

Главные достоинства Arch-это простота системы иниациализации, скриптов для сборки пакетов и файов конфигурации. А также свежий, и очень свежий(из AUR) и Git(посредством своих PKGBUILD'ов) софт. Обратная сторона медали-софт не всегда стабильный, у меня например страшно глючил Abiword(при любом размере шрифта курсор оставаля маленьким, и не получалось удалить набранный текст. Исчезала только узкая полоска внизу строки.

Gentoo-это не дистрибутив, а конструктор LEGO. Из него можно собрать что угодно, хоть игрушку, хоть необыкновенно хорошую и стабильную систему. При этом вы всё затачиваете под свои нужды, и возитесь с его доводкой до ума не меньше, чем с коньками, или Emacs.

Очень они разные. И объединить их не реально. Но, как мы все знаем: сказка ложь, да вней намёк. Дистрибутивы очень много сил теряют, тестируя и сопровождая одни и те же пакеты, а также изобретая одни и те же велосипеды, но под другим девизом. Почему бы не создать одну рабочую группу, которая бы разработала стандартную систему пакетов, систему разрешения зависимостей и систему сборки и конйигурации, а также иниациализации и тестирования. Ведь имея набор стандартов, и одних и тех же пакетов-работать было бы легче. Пакеты, патчи, различные системы, окружения и фреймворки должны быть стандартными. И разрабатываться одним глобальным сообществом разработчиков. А вот включение в дистрибутив по умолчанию того, или иного пакета или набора пакетов, оформление и т.д. - вот это те облати, которые должны быть в компетенции дистростроителей. Ведь и так уже ясно, что разработка велосипедов, и отличия в устройстве систем управления пакетами, систем сборки пакетов и решение о принятии патчей разработчиками каждого из дистрибутивов в индивидуальном порядке, всё это на годы тормозит прогресс во всей сфере Linux. И это - то, что отпугивает многих разработкчиков профессионального ПО, а также коммерческих игр и приложений. Ведь в ОС, в которой нет стандартов на инсталляционные пакеты, нет гарантии, что нужная библиотека присутсвует в ОС(или что нужная версия библиотеки хотя-бы присутсвует в репозиториях дистрибутива), и даже пути к "стандартным" каталогам на самом деле могут отличаться, а боле старая(или новая) библиотека в зависимостях их ПО может при установке потребовать удалить многие другие программы-такая ОС слишком капризна и сложна в сопровождении для разработчиков подобного ПО.

В настоящее время гарантированно работают в любом дистрибутиве только открытые программы, исходники которых сопровождающие их разработчики могут пропатчить и собрать с более старыми/новыми версиями библиотек, идущими по умолчнию в данном дистре.

Так нужен ли нам Canterbury Project? Я думаю-нет, не нужен. Но тесное взаимодействие между разработчиками всех дистрибутивов, создание общей и открытой площадки для создания новых стандартов, и общих проектов по стандартизации и развитию сообща всей экосистемы Linux-да, такой проект нужен. А то провальный LSB, со своими постоянно устаревающими и не актуальными стандартами, явно не справляется со своей работой.