Тег «Linux»

Debian: ищем пакет по имени файла

Иногда встает такая задача: зная имя файла или его фрагмент, найти пакет(ы), которому(ым) этот файл принадлежит.

Если область поиска ограничивается установленными пакетами, то подойдет любой из вариантов:

dpkg -S pattern
dpkg --search pattern
dpkg-query -S pattern
dpkg-query --search pattern

Понятно, что dpkg здесь — просто фронтенд к dpkg-query.

Шаблон имени файла pattern может включать shell-style wildcards (можно я не буду переводить?).

Если же хотим искать во всех пакетах вообще, даже неустановленных, то:

apt-file search pattern

Если задать опцию --regexp|-x, то pattern становится перловой регуляркой.

Кстати, apt-file использует собственную БД, поэтому перед первым использованием нужно выполнить

apt-file update

чтобы синхронизироваться с репозиториями из /etc/apt/sources.list.

УжасноПлохоНормальноХорошоОтлично (Еще не оценили)
Loading ... Loading ...

Удивительное рядом

Уличил сам себя в бессовестном разбазаривании вычислительных ресурсов. У меня запущен urxvt, в котором запущен tmux, в котором через ssh запущен screen, в котором запущен minicom, в котором видна консоль суровой отечественной железки. Остается только запустить это все в виртуальной машине.

Если XOrg падает при запуске Qt-приложений

А именно, XOrg 1.9 и несколько мониторов, сконфигурированные с помощью Xinerama, приводят к стабильному падению Qt- и некоторых Tk-приложений. Это подтвержденный баг. К сожалению, часто в репозиториях популярных дистрибутивов нужные фиксы появляются очень неторопливо, а жить с таким багом ну никак невозможно.

Исправляется баг элементарно: нужно накатить соответствующий патч на исходники иксов и пересобрать. Для арчеводов на форуме приведена подробная инструкция (подразумевает использование Arch Build System).

Обратите внимание на феерический комментарий к патчу:

This fixes a typo introduced in commit 80b5d3a3264d2c5167e5ac85a3b04af0f89cece1. The pointer pDst was changed unintentionally to pWin from a copy/paste error. This resulted in all QT-based apps and some tcl/tk ones (like fontforge) to crash X 1.9 on starting up, when Xinerama was enabled.

То есть, некто внес в код XOrg критическую ошибку в результате бездумного применения copy/paste. Для проекта такого уровня — эпический фэйл.

Перешел на Arch Linux

Fedora перестала меня удовлетворять, и главным образом по двум причинам.

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

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

В результате я пришел к непростому выбору из Gentoo, Arch и FreeBSD. Бесполезно меня спрашивать, почему именно эти три, и почему только они. Не знаю. Возможно, Gentoo просто на слуху, Arch мне советовал коллега (который сам при этом поклонник Gentoo), а FreeBSD — это просто старая платоническая любовь к неведомому миру, который «тоже опенсорс, но другой». Уважение к опыту коллеги перевесило все остальные доводы, и я поставил Arch Linux.

Как человек, развращенный автоматическими установщиками, графическими утилитами настройки и прочими bells and whistles, я готовился к худшему. Отчетливо представлялся процесс установки в виде загрузки с live-диска в голую консоль с приглашением «Вот вам консоль. Пожалуйста, установите Linux на свой вкус и цвет. Спасибо». После этого я должен был погрузиться в чтение мануалов, провести за этим занятием пару недель, отрастить бороду до груди и приобрести интенсивный красный цвет глаз. Эти атрибуты позволили бы мне достигнуть просветления, и я, пятнадцать раз пересобрав ядро и шестнадцать раз — все остальное, — получил бы, наконец, вожделенную системищу. Вот такую жуть напредставлял.

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

Что сразу подкупает в установке «почти вручную», так это что после окончания процесса ты знаешь, где у тебя что лежит, как, откуда и в каком порядке запускается, и где хранятся все настройки. Этакое ощущение тотального контроля появляется, как будто вертолет из Лего собираешь. Перечислю вкратце ключевые достоинства:

  1. Философия «чем проще, тем лучше». Что характерно, «проще» здесь означает «оценишь простоту, когда научишься», а не «любой дурак поймет». Arch — однозначно не для новичков и сторонников подхода, чтобы все из коробки автоматически поставилось и подушечку подложило. Это как раз тот случай, когда «вы можете настроить все… и вы будете настраивать все».
  2. Простое и прозрачное конфигурирование загрузки (все практически в двух файлах — /etc/rc.conf и ~/.xinitrc). Скрипты из /etc/rc.d никуда не делись, но все демоны вызываются централизованно, а не исходя из первой буквы соответствующей символической ссылки.
  3. Менеджер пакетов pacman определенно хорош. В первую очередь тем, что про него сложно сказать что-то плохое.
  4. Arch Build System позволяет при желании превратить Arch в этакий Gentoo. Формат файлов PKGBUILD, управляющих сборкой пакетов, нормально пишется и читается.
  5. AUR — гигантская база пользовательских пакетов в исходных кодах на случай, если в арчевских репозитариях чего-то нет.
  6. Концепция rolling release: отсутствуют релизы. Система эволюционирует, нет нужды переустанавливать ее или делать «апгрейд». Кроме того, всегда доступны самые свежие версии пакетов.
  7. Обширная Wiki, в которой можно найти инструкции почти на все случаи жизни. В некоторой степени переведена на русский.

Короче говоря, друзья, категорически рекомендую Arch тем, для кого Ubuntu — это «для чайников», а Gentoo — «для красноглазых». Очень разумный компромисс.

УжасноПлохоНормальноХорошоОтлично (Еще не оценили)
Loading ... Loading ...

Emacs: переключаем раскладку одинаково с ОС

Наверное, первое, что неприятно поражает новичка в Emacs — невозможность использовать системные средства для переключения языка ввода. Не в том смысле, что оно не работает. А в том, что переключение на любой отличный от английского язык средствами ОС превращает Emacs в Notepad. Перестают работать все клавиатурные комбинации! Паника!

К счастью, Emacs, как и всякая уважающая себя ОС, имеет собственный механизм переключения языков, кодировок и прочего. И все это даже работает. Одна беда — нельзя повесить переключение и в системе, и в Emacs на одну и ту же клавишу, потому что система в таком случае тоже будет переключаться. А пользоваться разными сочетаниями в Emacs и вне него… Что ж, я долгое время так и поступал. Неудобно.

Итак, задача:

  1. Хотим переключаться везде по одной и той же клавише. Причем, чтобы если мы нажимаем эту клавишу в Emacs, использовался его внутренний механизм, в остальных случаях пусть этим занимается ОС.
  2. Хотим, чтобы п. 1 работал и в Windows, и в Linux. И желательно чтобы сценарий загрузки был общим.

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

  • убедить ОС не переключаться, пока активен Emacs;
  • после одновременного переключения и в ОС, и в Emacs, переключить ОС обратно.

Оказывается, первый вариант реализуем в Linux, а второй в Windows. Дальнейшее изложение предполагает, что в качестве универсальной клавиши переключения выбран Caps Lock.

Для Linux палочкой-выручалочкой оказывается сочетание SCIM/iBus и xmodmap. С помощью xmodmap можно переназначить Caps Lock на какое-нибудь неиспользуемое действие, например, F13. Для этого в файл ~/.Xmodmap вписываем строку:

keycode 66 = F13

Число 66 — это код соответствующей клавиши. Скорее всего, у вас будет такой же, но лучше в этом убедиться с помощью утилиты xev.

Дальше убиваем системную переключалку раскладок (без особых зверств), и настраиваем SCIM/iBus на переключение по F13, а затем отключаем переключение для Emacs, вписывая в ~/.Xdefaults строку:

Emacs*useXIM:false

Теперь остается только подправить стартовый сценарий Emacs (.emacs или init.el), вставив туда:

(global-set-key [f13] 'toggle-input-method)

Выходим из сеанса, входим обратно, тратим еще пару часов на доработку напильником, и все заработает. Для Linux это все. Я намеренно опустил некоторые подробности про настройку SCIM/iBus, поскольку времена меняются, и старые инструкции становятся устаревшими. А тут я как бы не причем: «настройте iBus на переключение по F13» еще долго не устареет. В конце концов, гугл никто не отменял. Идея использовать SCIM и его аналоги не новая, об этом много где можно прочитать.

В Windows такой фокус не пройдет, но зато один вдумчивый камрад предложил очень изящное решение (ссылка не работает?..), которое упомянуто выше: после переключения вернуть системную раскладку обратно. (Для установки Caps Lock в качестве клавиши переключения системной раскладкой нужно воспользоваться чем-то вроде lswitch или лезть в реестр.)

Теперь остается только вооружиться переменной system-type, и получим сценарий, который кроссплатформенно решает нашу задачу:

(if (eq system-type 'windows-nt)
    ((defvar safe-language-change-flag nil)
     (defun safe-language-change ()
       (interactive)
       (setq safe-language-change-flag (not safe-language-change-flag))
       (when safe-language-change-flag
         (toggle-input-method)
         (w32-toggle-lock-key 'capslock)))
     (global-set-key (kbd "<language-change>") 'safe-language-change))
  (global-set-key [f13] 'toggle-input-method))

Правда, в случае запуска в натуральной консоли проблема все еще остается.

УжасноПлохоНормальноХорошоОтлично (1 голосов, средний: 5,00 из 5)
Loading ... Loading ...

OpenOffice Impress во всей красе

Вчера весь день работал над своей SITOPовской презентацией в OO Impress 3.1.1 под Fedora 11. Работал — и получал от этого реальное удовольствие, настолько удобная программа. И что особенно приятно, думал я, не тормозит, радость моя, даже на моем стареньком рабочем P4. Ну просто счастье.

Сегодня прихожу на работу, открываю ту же презентацию, и… Иду пить чай. Отклика от интерфейса нет вообще. Смотрю в top — за звание самого прожорливого процесса борются simpress.bin и convert. Последний, очевидно, что-то делал со встроенными в презентацию картинками в формате EPS. Наверное, преобразовывал в какой-то свой внутренний формат. Ладно, минуты 4 попреобразовывал и перестал.

Но вот процесс simpress.bin после этого решил, что он теперь тут главный и ему все можно. Минут через пять интерфейс, наконец, начал неторопливо отвечать на мои действия. Все это время загрузка процессора одним этим процессом держалась на уровне 95%. Еще минут через пять тормоза почти окончательно пропали. Но стоит только просто поелозить колесиком мышки, как Impress тут же начинает жрать 20–40%. И основательно тормозит при любом редактировании. Xorg тоже хорош — глядя на Impress, выдает до 40% при прокрутке слайдов. Они что думают, я их за ушком чешу?.. Откуда такая гипервозбудимость?

Нет, правда, может кто-то знает? Уж очень не хочется для подготовки презентаций загружать винду.