Рассказывать о том, что это не буду, так как проще зайти на google.com и самому все увидеть. Также для этого нужны версии браузеров не ниже Chrome v5/6, Firefox v3, Safari v5 для Mac и Internet Explorer v8. Как только вы начнете набирать запрос, то уже с первых букв поисковик начнет выдавать вам результаты поиска. Также реализовано дополнение запросов по клавише tab. Например, если набрать в поисковике буквы “ку”, то Google подсветит серым цветом наиболее популярный запрос начинающийся на слог “ку” - курсы валют:

Если теперь нажать кнопку tab, то будет автоматически подставлена фраза курс валют с выводом результата поиска.

Если кому-то данный механизм не понравится, то его можно выключить в свойствах поиска, или нажав на ссылку Живой поиск включен.

Дополнительную информацию о механизме Google Instant читайте на сайте Google.

Сегодня я зарегистрировал себе еще один аккаунт webmoney, для того чтобы управлять им с помощью Webmoney Keeper Web Edition или Webmoney Light. Другими словами получать доступ к кошелькам из браузера. Способ аутентификации был выбран Сертификат X.509. Во время настроек Keeper Light пришлось воспользоваться браузером Firefox для того чтобы импортировать корневой сертификат системы Webmoney и свой персональный сертификат. После окончания процедуры регистрации и импорта сертификатов захотел добавить сертификаты в Google Chrome, так как это мой браузер по умолчанию. Ниже описал процедуру. На всякий случай: операционная система Ubuntu 9.10, Chrome версии 7.0.503.1 dev.

1. Сначала нужно сделать экспорт сертификатов из хранилища браузера firefox. Открываем в браузере пункт меню Правка - Настройки. В открывшемся окне - раздел Дополнительные, вкладка Шифрование. Нажимаем кнопку Просмотр сертификатов. Переключаемся на вкладку Центры сертификации и ищем сертификат с именем WebMoney Transfer Root CA:

Рисунок 1

Выбираем сертификат и нажимаем на кнопку Экспортировать. Тип сертификата оставляем по умолчанию - Сертификат X.509 в формате PEM. Имя сертификата я выбрал - WebMoneyTransferRootCA.

Далее переходим на вкладку Ваши сертификаты и выбираем сертификат с именем WM id:ваш идентификатор:

Рисунок 2

Нажимаем на кнопку Сохранить копию. Тип сертификата - PKCS12, имя сертификата пусть будет wm. После нажатия на кнопку Сохранить появится окно Выбор пароля резервной копии сертификата:

Рисунок 3

К этому паролю как и к любому другому паролю нужно отнестись внимательно. Сохраненный файл, является переносимой копией вашего личного сертификата. Любой кто сможет заполучить этот файл сможет аутентифицироваться в системе Webmoney и получить доступ к вашим кошелькам. Поэтому этот файл защищается паролем. Копия такого личного сертификата необходима в любом случае. Ее нужно хранить в надежном месте. В случае переустановки системы или выходя из строя жесткого диска, если у вас не будет копии, вы не сможете получить доступ к своему аккаунту Webmoney. Также если у вас будет копия, но вы забудете пароль к файлу с сертификатом, то и установить его вы не сможете. Именно поэтому будьте внимательны, запомните пароль, и сохраните файл в надежном месте.

Теперь все готово для импорта сертификатов в браузер Chrome.

Сначала установим необходимое ПО:

Проверим, что хранилище работает и доступ к нему есть:

Установка корневого сертификата Webmony:

-n “WebmoneyCA” - здесь задается имя сертификата, как он будет отображен в базе. Вместо WebmoneyCA можете задать любое свое имя.
-i WebMoneyTransferRootCA - здесь указывается путь к файлу.

Проверяем, что сертификат установлен:

Теперь установка личного сертификата. Во время импорта необходимо будет набрать пароль на доступ к файлу с сертификатом:

Еще раз проверяем наличие сертификатов:

Сертификаты импортированы. Теперь из браузера Chrome можно работать с Webmoney Light используя для аутентификации сертификат X.509.

Сначала посмотрел, что выдает команда lsusb:

Итак, вебкамера есть, и определяется она как устройство с названием Syntek Web Cam - Asus F3SA, F9J, F9S. Поиск по слову Syntek привел на сайты http://syntekdriver.sourceforge.net/ и http://forum.ubuntu.ru/index.php?topic=82197.0 и http://doc.ubuntu-fr.org/syntek Были и другие ссылки, но этих трех (особенно последней) оказалось достаточно для решения проблемы.

Собственно проблема заключалась в том, что текущий модуль который отвечает за вебкамеру, не поддерживает ее. У меня этот модуль назывался stkwebcam. Поэтому нужно было скомпилировать модуль который будет поддерживать вебкамеру ноутбука.

Действия которые рекомендовали сделать и которые были сделаны для того чтобы заработала вебкамера.

Установка файлов заголовков ядра, которые необходимы для компиляции модуля. У меня эти файлы уже были установлены.

Установка subversion:

Создаем каталог syntek в своем домашнем каталоге:

переходим в каталог:

и выполняем команду для загрузки исходных файлов модуля:

Далее переходим в подкаталог ./driver:

и выполняем команду wget для закачки файла Makefile-syntekdriver:

После этого компиляция:

и установка модуля (по сути копирование файла stk11xx.ko):

После этой операции модуль stk11xx.ko был скопирован в каталог /lib/modules/2.6.32-24-generic/kernel/drivers/usb/media.

Теперь выгружаем текущий модуль:

И загружаем скомпилированный модуль stk11xx:

Во время загрузки модуля камера подмигнула зеленым диодом и после запуска cheese я увидел свою физиономию :) После перезагрузки системы модуль stk11xx.ko подгрузился автоматически, поэтому больше никаких действий предпринимать не пришлось.

Первым делом решил проверить наличие файлов у которых размер превышает 1 Gb:

Таких файлов оказалось немного и все за исключением файла VirtualBox уже были не нужны. Поэтому смело удалил эти файлы:

Таким же образом нашел файлы размером более 600 мегабайт, но менее 1 гигабайта. Здесь хочу обратить внимание на небольшую особенность выполнения данной команды. Если написать такую команду в таком виде:

то команда не выдаст результат, так как, вероятно, пытается интерпретировать -1G как самостоятельную опцию, а не как значение опции -size. А вот в таком виде команда сработает и выдаст правильный результат:

Здесь тоже удалил все ненужное.

Уже после этих действий свободное место в каталоге home увеличилось примерно на 6 Гб, что не так уж и плохо.

Далее решил посмотреть файлы подкаталога ./downloads в который я закачиваю информацию из сети Интернет. Для этого удобно использовать команду ls с сортировкой по размеру файла:

В таком виде самые большие по размеру файлы будут выводиться внизу. Просматриваем, и что не нужно - удаляем.

Содержимое подкаталога ./downloads можно просматривать и сортировать разными способами в зависимости от того, что закачивалось. Например, так как на работе у всех установлена операционная система Windows XP, то я периодически закачиваю файлы с расширением exe. Просмотрев эти файлы:

и переместив нужные в подкаталог c файлами для Windows, удалил все оставшиеся файлы exe:

Точно также проверяю и удаляю файлы с расширениями zip, deb и другие.

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

Сначала смотрю есть ли подкаталоги с размером более 1 гигабайта:

Такие подкаталоги есть, оба мне не нужны, поэтому удаляю:

Теперь подкаталоги поменьше:

Эти подкаталоги также оказались ненужными, поэтому последовали за остальными удаленными файлами.

В результате, даже после таких простых действий, удалось увеличить свободное место примерно с 13 до 27 гигабайт:

А как вы избавляетесь от ненужных файлов?

Чтобы понять о каком типе вентилятора и каких креплениях идет речь выкладываю пару фотографий. Качество не очень, но разглядеть причину можно.

Рисунок 1

На рисунке 1 обратите внимание на нижние два крепления, а на рисунке 2 на эти же крепления (слева) только расположенные немного в другом ракурсе.

Рисунок 2

На всякий случай еще один рисунок, где уже точно должно быть видно, что произошло:

Рисунок 3

На первой части рисунка 3 показано рабочее крепление в положении перед установкой, на второй части положение крепления установленного вентилятора, а в на третьей части видно, что пластмассовые держатели сорваны.

Хотя в моей практике это первый случай когда срывается крепление такого рода, но тем не менее, лучше от креплений такой конструкции отказаться. Есть гораздо более надежные за ту же цену.

Вот на картинке фотография изображения на мониторе после выхода из полноэкранного режима:

Рисунок 1

Как видите ничего хорошего. Сначала решил, посмотреть настройки флеш плеера. На самой первой вкладке есть возможность включить или отключить аппаратное ускорение:

Рисунок 2

После отключения аппаратного ускорения flash плеер начал работать как нужно и при выходе из полноэкранного режима глюков больше не было.

Проблема появилась не так давно, из возможных причин вижу установку поддержки аппаратного ускорения для плеера vlc. Пару месяцев назад удалось таки заставить vlc использовать ресурсы видеокарты для проигрывания HD видео.

На рабочем компьютере с Ubuntu 9.10 аппаратное ускорение для флеш плеера включено и таких проблем нет. Так, что проблема пока решена частично. Надеюсь, в скором времени разберусь, что там точно происходит. Если у кого-то есть еще идеи - делитесь, буду проверять.

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

Чтобы с чего-то начать решил посмотреть с помощью команды lsmod, что у нас есть за модули связанные с видео:

Затем решил выгрузить модуль uvcvideo командой rmmod, предварительно закрыв все приложения которые могли бы использовать этот модуль:

И тем не менее я все равно увидел сообщение о том что Module uvcvideo is in use. Значит какой-то процесс использует этот модуль. Такая мысль была и до попытки выгрузки модуля, но теперь она подтвердилась окончательно. Осталось только найти процесс.

Список процессов, смотрел в выводе команды htop, так как-то нагляднее. Процесс с именем camserv меня заинтересовал сразу. Google подсказал, что camserv - это сервер видео вещания и я тут же вспомнил, что действительно несколько месяцев назад, что-то о нем читал, что-то ставил, и что-то настраивал…

После удаления camserv и скайп и cheese заработали как нужно, но вот изображение… Изображение было просто ужасным. Настройки в Cheese не приводили его даже близко к тому, что было раньше. Вероятно camserv изменил настройки в самой web-камере. И теперь нужно было вернуть их в исходное состояние.

К счастью, оказалось, что есть такая утилита как v4l2ucp. Она присутствует в репозитории Ubuntu, поэтому установка стандартная:

После установки запустил программу из консоли:

и в открывшемся окне (программа имеет графический интерфейс) напротив всех параметров нажал Reset, чтобы сбросить параметры. Могу сказать, что некоторые параметры (особенно контрастность) существенно отличались от тех которые были прочитаны из вебкамеры изначально. После нажатия на кнопку Update, закрыл v4l2ucp, открыл cheese и увидел, что изображение стало таким как и раньше.

Кстати, программу v4l2ucp можно запускать параллельно с тем же скайпом, для того чтобы подрегулировать настройки изображения.

Вот такая история. Еще одно подтверждение, что причина нестандартного поведения системы всегда есть, даже когда кажется, что ее нет.

Router: Failed to connect to SMTP host domain.com because : The server is not responding. The server may be down or you may be experiencing network problems. Contact your system administrator if this problem persists.

Имя почтового домена я изменил в остальном все соответствует. Я объяснил сотруднику, что проблема с почтой не у нас, так как “не отвечает” почтовый сервер-получатель (The server is not responding). Но сотрудник ответил, что связывался с получателем и он клятвенно заверил, что у них проблем с почтой нет и что у них все работает и проблемы у нас.

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

Здесь я запрашиваю запись MX для домена domain.com. Запись MX как раз и показывает тот сервер (или сервера), которые должны обрабатывать почтовый трафик. Но как видите для домена domain.com такой записи не существует.

Этот ответ я получил от нашего DNS-сервера (SERVER: 192.168.1.10#53(192.168.1.10)). На всякий случай решил спросить у NS-сервера для домена domain.com. Сначала определяем NS-сервера:

Теперь делаем MX-запрос к NS-серверу, который отвечает за домен domain.com:

Результат тот же - запись MX для домена не прописана, значит почту из внешнего мира они получать не могут. Но на самом деле могут. Если не прописана запись MX, то почта должна уйти на ip-адрес указанный в A-записи. А-запись для домена domain.com прописана, но вот порты ни POP3 ни IMAP не открыты. Это можно определить, например, командой nmap (ip-адрес, естественно, выдуман):

Если вы работаете в операционной системе Windows, то эти же действия можно выполнить с помощью команды nslookup:

Уточняем, если нужно, NS-сервера для domain.com:

И спрашиваем у сервера ns1.dsredirection.com:

Результат аналогичен.

А вот, что должно быть для работающего почтового сервера, например ukr.net:

Как видите здесь запись MX присутствует:

Конечно, это частный пример и проблемы с почтой могут быть разные. Например, запись MX может быть прописана, но сам почтовый сервер, может быть силу каких-то причин недоступным. Или как я уже писал, MX-записи нет, почта пытается уйти на адрес указанный в A-записи, но там не поднят почтовый сервер. И т.д. Основной смысл был показать как это можно увидеть с помощью команды dig или nslookup и двух-трех запросов.

Если вдруг, где ошибся или, что-то не так написал, или быть может неправильно я определил, что почтовый сервер не работает - просьба сообщить об этом.

А теперь примеры. Об одном я уже писал в статье Где скачать обновления для ETKA 7.2. Но здесь повторюсь с дополнениями. По адресу http://update1.lex-com.net/update/audi/0/ лежат exe-файлы, которые нужно закачать. В книге Скотта Граннемана - Linux карманный справочник, есть пример, на основании которого можно написать вот такую команду:

По идее, эта команда должна загрузить все файлы с расширением exe, которые находятся в http://update1.lex-com.net/update/skoda/0/. Ключ -l0 говорит о том, чтобы не идти глубже по иерархии, а закачивать только из текущего каталога, -w 5 - это задержка в 5 секунд перед закачкой следующего файла. Этот ключ нужен, чтобы не перегружать сервера запросами. -A.exe - закачивать только файлы с расширением .exe. Но эта команда не сработала и выдала ошибку. Скорее всего из-за того, что wget не смогла получить список файлов в каталоге. Так как http-сервер не отдает такой список. Зато это должен делать ftp-сервер и для ftp-протокола команда wget в таком виде сработает. Вот пример для ftp-сервера компании dlink:

Но как же закачать наши exe файлы? Только указав в команде wget точную ссылку с именем файла:

В этой команде я точно указывал wget какой файл качать, а с помощью цикла while организовал закачку нужных файлов. Как только номер версии увеличится до несуществующего, команда wget вернет ошибку (false) и цикл прервется, закачка прекратится.

Вот еще один пример с закачкой фотографий. На одном из сайтов были выложены фотографии изделий из арбуза. Ссылки вели на сайт ru.fushki.net. Посмотрев несколько ссылок и увидев структуру имен файлов закачал их с помощью двух команд.

Со второй по девятую вот так:

Правда фотография arbuz006.jpg отсутствовала, поэтому пришлось, задать i=7 и запустить команду еще раз, а затем уже закачать фотографии начиная с 10-й и до последней:

Точно также я закачивал статистические данные сети Интернет от ресурса bigmir.net. Думаю идея понятна. Если имена файлов структурированы, то их можно закачивать командой wget, организовав простой цикл.

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

Закачать официальные обновления для ETKA можно по прямым ссылкам с сайта компании Lexcom:
Для марки Audi:

Для марки VW:

Для марки Seat:

И для марки Skoda:

Меняете только числа в имени файла, которое соответствует номеру обновления: eupdsk3500.exe, eupdsk3510.exe, eupdsk3520.exe и т.д. Закачанные файлы обновлений нужно положить в каталог в который установлена ETKA. Для марки audi - это каталог .\etka\DATA\AU\Update, для VW - это .\etka\DATA\VW\Update и т.д. После чего запускаем вечером обновление программы и утром получаем готовую к работе Этку. Это если не было никаких ошибок. Иногда случаются. В таком случае нужно повторить обновление.

Из Ubuntu я закачивал обновления с помощью wget. Так как изначально неизвестно какой номер у последнего обновления, то можно написать так:

Эта команда будет закачивать обновления начиная с 330 до последнего, после чего прекратит свою работу. Точно также можно закачать обновления для остальных марок. Вчера тестировал этот скрипт на марке audi, закачал все обновления с 761-го по 817-й (последний) номер. Если кому нужны забирайте:

Обновления для ETKA 7.2, марка AUDI, с 761-го по 790-й
Обновления для ETKA 7.2, марка AUDI, с 791-го по 817-й
Если вы как системный администратор только начали работать с программой ETKA и по ней есть вопросы, то задавайте. Если знаю ответ, обязательно отвечу.