Есть у меня пара файлов — .mailcap и .mime.types, и существует эта пара файлов уже почти 20 лет, и тиражируется на все машины.

И уже лет 20 я запускаю run-mailcap %s. И у меня даже есть возможность конфигурировать некую простую логику выбора нужной программы в случае, если есть несколько альтернатив (самый примитивный случай — это разные обработчики в X Window и в консоли), напр.:

text/plain; nedit %s; test=test -n "${VAR}" -a ${VAR} -eq 0
text/plain; vim %s; test=test -n "${VAR}" -a ${VAR} -eq 1
text/plain; gvim %s; test=test -n "${VAR}" -a ${VAR} -eq 2
text/plain; emacs %s; test=test -n "${VAR}" -a ${VAR} -eq 3
text/plain; emacs -nw %s; test=test -n "${VAR}" -a ${VAR} -eq 4
text/plain; mcedit %s;

(Сама форма записи ; test= описана в RFC 1524.)

И работает эта штука достаточно быстро.

Но вот уже лет пять как продвигается альернатива — xdg-open. Которая прекрасна всем:

1. Пытается определить, какое у меня DE, чтобы запустить «браузер по умолчанию». GNOME? Нет, не GNOME. KDE? Нет, не KDE. XFCE? Опять мимо. Нет, я, конечно, даже глазом не успеваю моргнуть — процесоры нынче быстрые.
2. По MIME-типу файла пытается найти нужное приложение, распарсив 100500 *.desktop-файлов в /usr/share/applications.
3. После этого запускает наименее подходящее приложение (напр., для открытия каталогов я использовал thunar (inode/directory; thunar %s; test=test -n "${DISPLAY}")), но вот xdg-open, с*ка, решил, что разумнее запустить git-cola, а затем — audacious (видимо, потому, что в обычных каталогах git-cola возвращает ненулевой код).
4. Наконец, для программ, у которых отсутствуют *.desktop-файлы, таковые приходится создавать вручную, что однозначно дольше добавления одной строки в .mailcap. Короче, снова приходится настраивать то, что уже годы работало.

Проблема в том, что всё больше инструментов пытаются использовать xdg-open вместо run-mailcap, а сам xdg-open попытается запустить run-mailcap только в случае, если сам не придумает какой-нибудь глупости. Снести xdg-open не получится — от него зависит chromium и ещё куча софта.

Посему вопрос: как сделать, чтобы run-mailcap запускался всегда, и запретить всякие странные эвристики и танцы с бубном?

Для Midnight Commander всё (пока) решается просто:

export MC_XDG_OPEN='run-mailcap'

Для всего остального я, увы, пока вижу лишь

dpkg-divert --divert /usr/bin/xdg-open.orig --local --rename /usr/bin/xdg-open
ln -s run-mailcap /usr/bin/xdg-open

Есть менее радикальные решения?

UPD: Временно решил проблему, создав run-mailcap.desktop след. содержания:

[Desktop Entry]
Encoding=UTF-8
Version=1.0
Type=Application
NoDisplay=true
Exec=run-mailcap %u
Name=run-mailcap
Comment=run-mailcap

и прописав его в качестве обработчика для всех типов в ~/.config/mimeapps.list, но как-то это всё равно через задницу.

Приветствую.

Снёс на работе оффтопик и поставил Linux.

Есть зоопарк виртуальных машин, которые хочется перенести с Hyper-V в VirtualBox. При преобразовании одного из дисковых образов наблюдаю ошибку:

$ VBoxManage clonemedium disk cholera-sda.vhdx cholera.vdi --format VDI
VBoxManage: error: Could not open the medium '/export/vms/cholera/cholera-sda.vhdx'.
VBoxManage: error: VHDX: Image '/export/vms/cholera/cholera-sda.vhdx' has a non empty log which is not supported (VERR_NOT_SUPPORTED).
VBoxManage: error: VD: error VERR_NOT_SUPPORTED opening image file '/export/vms/cholera/cholera-sda.vhdx' (VERR_NOT_SUPPORTED)
VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component MediumWrap, interface IMedium, callee nsISupports
VBoxManage: error: Context: "OpenMedium(Bstr(pszFilenameOrUuid).raw(), enmDevType, enmAccessMode, fForceNewUuidOnOpen, pMedium.asOutParam())" at line 179 of file VBoxManageDisk.cpp

Это как-то лечится (в отсутствие инструментов Hyper-V)?

В качестве лирического отступления скажу, что сижу на Debian года с 2006, когда Debian Etch был ещё в стадии тестирования.

Ниже — список вещей, которые меня неприятно поразили в «девятке» (приятных апгрейдов не было уже давно — субъективно, последней нормальной версией была «шестёрка», или Squeeze).

• Во-первых, качество инсталлятора за 10 лет нисколько не изменилось. Например, когда в инсталляторе включаешь LVM2, но к штатным логическим разделам нужно добавить ещё отдельные логические разделы для /usr и /opt — за этим приходится идти в консоль. А потом, когда возвращаешься в установщик, он видит, что в логической группе, чёрт возьми, что-то поприбавилось томов, и этот факт ему сносит крышу — базовую систему установить нельзя, потому что на диске есть «незаписанные изменения», а переразбить диск или перечитать тома в группе мы тоже не можем. Алё, дяденьки из проекта Debian, вы там свой продукт вообще тестируете? Вопрос риторический. «Девятка» на ощупь откровенно «сырая».
• То, что при наличии альтернатив в виде других систем инициализации (sysvinit, openrc, upstart) установщик (в «expert mode», Карл!) ни одну из них не предлагает, меня, как противника systemd, огорчает, но не более того. Это лишь показатель сырости установщика. По умолчанию ставятся базовая система, systemd, sshd и (о, боже!) Wayland с GNOME. Выбрать пакеты индивидуально посредством dselect или aptitude уже давно никто не предлагает. Прогресс требует жертв.
• А вот то, что при последующей миграции новой системы с systemd на sysvinit внезапно отваливается сетка, потому что для sysvinit нам ещё нужен DHCP client, resolvconf, ifconfig и куча других утилит — это реально неприятно. Т. е. при обновлении предыдущих версий Debian, когда всё уже настроено, этого, конечно, не почувствуешь, а для новых инсталляций, увы, критично. В «восьмёрке» (Jessie), кстати, такого г-на не было — там миграция на sysvinit прошла безболезненно. Здесь хочется заметить, что, если бы полтора фанатика из проекта Devuan не пилили ночами свой мега-дистрибутив с шахматами и поэтессами, тратя свои немногие и потому драгоценные ресурсы на ерунду, а доводили бы до ума Debian — например, тупо запилив альтернативные сборки пакетов, изначально зависящих от libsystemd0, но при этом в рамках проекта Debian и с присущими (когда-то) этому проекту стандартами качества — так вот, многим людям стало бы легче.
• Xorg отныне не запускается как setuid root. Если хочется запускать «иксы» по старинке, командой startx — то рядовой пользователь словит кучу охренительно информативных ошибок в логе:

  [   419.152] (EE) modeset(0): drmSetMaster failed: Permission denied
  [   419.152] (EE)
  Fatal server error:
  [   419.152] (EE) AddScreen/ScreenInit failed for driver 0
  [   419.152] (EE)
  [   419.152] (EE)
  Please consult the The X.Org Foundation support 
           at http://wiki.x.org
   for help. 
  [   278.970] (EE) Please also check the log file at "/home/bass/.local/share/xorg/Xorg.1.log" for additional information.
  [   278.970] (EE) 
  [   279.016] (EE) Server terminated with error (1). Closing log file.
  

   — а ещё, с ненулевой вероятностью, зависание системы. Зато безопасно. Для нежелающих в дивный новый мир есть костыли в виде пакета xserver-xorg-legacy, который предоставляет setuid-бинарь Xorg.wrap. Теперь у моих «иксов» два конфига — один для сервера, а другой (/etc/X11/Xwrapper.config) — для «запускалки».
• Поддержка xfs (сервера legacy-шрифтов, а не файловой системы) в libxfont выпилена, потому что несколько лет назад были найдены уязвимости, уже давно закрытые в апстриме. Поэтому из-за прихоти мэйнтейнера пакета я больше не могу поднять у себя сервер и раздавать шрифты дюжине X-серверов в моём личном зоопарке машин.
• Даже если я не намерен поднимать Wayland, пакеты libwayland и libwayland-bin требуются для gtk+ 3.0 и libegl1-mesa (и, стало быть, косвенно — для X-сервера).
• При обновлении с Jessie, новый mercurial 3.8.1+ ломает hgsubversion и mercurial-git, если они были ранее установлены.
• Пропал пакет openjdk-8-jre-jamvm (отдельная реализация JVM). Были проблемы на PowerPC или S/390, и потому пакет выпилили отовсюду. Радикально, чо.
• tmux 1.9 (Jessie), будучи обновлён до 2.3-4 (Stretch), более не поддерживает кодировки, отличные от UTF-8 (это очень удобно и реально радует, если пытаешься его использовать на тестовой машине, где специально системной локалью выставлена ru_RU.KOI8-R). Он при каждом запуске выставляет stty iutf8, независимо от того, какие у меня самого настройки терминала (bug #885164). Так что теперь я снова счастливый пользователь GNU screen.
• MySQL заменён MariaDB (без каких-л. альтернатив), что меня несказанно радует, т. к. мне по работе, помимо Postgres, Oracle и MS SQL, нужен именно MySQL, а не клоны. Пакеты MySQL теперь можно взять отсюда: http://repo.mysql.com/apt/debian/dists/stretch. Что характерно, куча софта по-прежнему зависит от default-libmysqlclient-dev, но на самом деле это клиентская библиотека MariaDB (libmariadbclient-dev-compat -> libmariadbclient-dev), которая конфликтует с настоящим libmysqlclient-dev. Так что, если при обновлении с Jessie хочешь оставить себе «полный» MySQL — будь добр снести часть софта, которым пользовался раньше.
• Пакет dhelp почему-то доступен в Buster, но вот в Stretch не завезли. Забыли, наверное. Ну и ещё штук 20 подобных мелочей. Вроде бы и не критично, но таки неприятно.

Предвижу вопросы вида «что ты сделал для хип-хопа»^W «где багрепорты на все описанные дефекты» и «хрена ли ты тогда ноешь».

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

В общем, как однажды сказал классик, сраный «Дебиан» катится в сраное г-но.

Увы.

По работе возникла необходимость установить Slack (мы же все хипстеры, нам пользоваться почтой и телефоном западло) — и в потрохах deb-пакета узрел примерно следующее (сценарий запихивается в cron.daily).

Т. е. эта дрянь периодически, сама, в обход меня пытается импортировать PGP-ключи и править sources.list.

Нормально ли это? Вопрос риторический.

Т. е. понятно, конечно, что ООО «Slack» со своим говноприложением — полные уроды, и я, конечно же, или перепакую всю эту порнографию, или сделаю chmod 000 на отдельно взятый сценарий (или даже diversion куда-нибудь подальше). Но меня интересует, скорее, другое — как при установке софта из внешних репозиториев отсекать подобные попытки в полуавтоматическом режиме? Не хочется каждый раз выполнять полный аудит при установке не пойми чего.

В частности, могу ли я какие-л. из ключей (по key id) или множества ключей (напр., по какой-л. маске) явно вогнать в чёрный список («web of distrust»)?

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

Lack of parallelism. OCaml does not offer any primitives for parallelism through multithreading. In many cases, this does not affect us because we tend to distribute work between independent processes. But when large in-process caches are needed, it results in high memory pressure. This can only be alleviated by sharing the caches between processes, which is cumbersome and greatly affects code architecture. Having multithreading primitives could let us explore a more diverse range of architectures when developing services.

Отсюда: http://engineering.issuu.com/2015/09/17/ocaml-production.html

С другой стороны, модуль Thread реализован через POSIX threads, и непонятно, откуда указанное выше ограничение:

• http://caml.inria.fr/pub/docs/oreilly-book/html/book-ora175.html
• https://ocaml.github.io/ocamlunix/threads.html

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

Наконец, интересно, как это всё соотносится с экосистемой F#, у которого на Mono есть вся мощь CLR, а реализация пи этом наверняка опирается на те же pthreads.

Кто проконсультирует?

Сотрудники компании Oracle (вернее, те, кто ими пока остаётся) сообщают, что в прошлую пятницу (1 сентября) компания устроила сотни сокращений в командах, занимающихся ОС Solaris, процессорами SPARC и системами хранения.

Официальные лица компании, естественно, воздерживаются от комментариев. Алан Куперсмит (Alan Coopersmith) в рассылке OpenIndiana-discuss тоже всё отрицает, не вдаваясь, впрочем, в комментарии. Solaris 12 убрана из плана развития ОС и заменена непонятным термином «Solaris 11.next».

Саймон Фиппс (Simon Phipps) утверждает, что «~все» сотрудники Solaris были сокращены: «Для тех, кто не в курсе дела — Oracle вчера сократил ~всех сотрудников Solaris в классическом стиле тихого и незаметного EOL продукта».

Похоже, это таки конец более чем двадцатилетней истории одной из лучших операционных систем. Но есть надежда, что в результате проект Illumos наберёт критическую массу инженеров.

В заключение — статья Брайана Кантрилла (Bryan Cantrill), одного из создателей технологии DTrace: «The sudden death and eternal life of Solaris»

>>> Один из англоязычных источников: Oracle Finally Killed Sun

Был восьмой Debian (Jessie) с подключённым репозиторием jessie-backports.

В какой-то момент установил JamVM (посредством пакета openjdk-8-jre-jamvm) и начал им пользоваться (в тестовом режиме).

В момент обновления на Debian 9 обнаружил, что openjdk-8-jre-jamvm пропал — как из jessie-backports, так и из stretch (хотя остался на bugs.debian.org и packages.ubuntu.com).

Посмотрел в списках рассылки — тишина.

WTF?

Обновляю Debian Jessie из jessie-backports.

Получается обновить всё, кроме libxfont и libxfont-dev, потому что у меня исторически стоит xfs из Wheezy, и я им, чёрт возьми, пользуюсь.

Смотрю ChangeLog и вижу прекрасное:

libxfont (1:1.4.7-2) unstable; urgency=high

  * Pull from upstream git to fix FTBFS with new fontsproto (closes: #746052)
  * CVE-2014-0209: integer overflow of allocations in font metadata
  * CVE-2014-0210: unvalidated length fields when parsing xfs protocol replies
  * CVE-2014-0211: integer overflows calculating memory needs for xfs replies
  * Add breaks on xfs because we broke it by disabling font protocol support
    in 1.4.7.

 -- Julien Cristau <jcristau@debian.org>  Tue, 13 May 2014 17:25:49 +0200

Я правильно понимаю, что они таки сломали поддержку шрифтов X11, доступных по сети?

Нахрена?

WTF?

Пытаюсь прогнать тесты GNU binutils (из git) с переопределённой переменной RUNTESTFLAGS (хочу получить XML-отчёты):

$ make -k RUNTESTFLAGS='--all --xml' check

Всё было прекрасно с runtest 1.5.1, но вот с runtest 1.6 дерьмо летит в вентилятор:

Making a new site.exp file...
srcdir=`cd . && pwd`; export srcdir; \
r=`pwd`; export r; \
LC_ALL=C; export LC_ALL; \
EXPECT=expect; export EXPECT; \
runtest=runtest; \
if /bin/bash -c "$runtest --version" > /dev/null 2>&1; then \
  CC="gcc" CC_FOR_BUILD="gcc" \
  CC_FOR_TARGET="gcc" CFLAGS_FOR_TARGET="-g -O2" \
    $runtest --tool binutils --srcdir ${srcdir}/testsuite \
        --all --xml; \
else echo "WARNING: could not find \`runtest'" 1>&2; :;\
fi
WARNING: Couldn't find tool init file
couldn't open ".../binutils/testsuite": illegal operation on a directory
Makefile:1322: recipe for target 'check-DEJAGNU' failed
    while executing
"open [file join $outdir $xml_file_name] w"
    (procedure "open_logs" line 19)
    invoked from within
"open_logs"
    (file "/usr/share/dejagnu/runtest.exp" line 1223)
make[5]: *** [check-DEJAGNU] Error 1
make[4]: *** [check-am] Error 2
make[3]: *** [check-recursive] Error 1
make[2]: *** [check] Error 2
make[1]: *** [check-binutils] Error 2
make: *** [do-check] Error 2

Цель check-DEJAGNU выглядит идентично на системах с runtest 1.5 и runtest 1.6:

1321 check-DEJAGNU: site.exp
1322         srcdir=`cd $(srcdir) && pwd`; export srcdir; \
1323         r=`pwd`; export r; \
1324         LC_ALL=C; export LC_ALL; \
1325         EXPECT=$(EXPECT); export EXPECT; \
1326         runtest=$(RUNTEST); \
1327         if $(SHELL) -c "$$runtest --version" > /dev/null 2>&1; then \
1328           CC="$(CC)" CC_FOR_BUILD="$(CC_FOR_BUILD)" \
1329           CC_FOR_TARGET="$(CC_FOR_TARGET)" CFLAGS_FOR_TARGET="$(CFLAGS)" \
1330                 $$runtest --tool $(DEJATOOL) --srcdir $${srcdir}/testsuite \
1331                         $(RUNTESTFLAGS); \
1332         else echo "WARNING: could not find \`runtest'" 1>&2; :;\
1333         fi

Насколько я понял, «illegal operation on a directory» — это EISDIR, возникающий тупо из-за того, что $xml_file_name в исходнике на Expect на одной из систем тупо пуст, что и приводит к неудачной попытке писать отчёт в каталог вместо регулярного файла.

Я нашёл обходной путь — пришлось ключу --xml в случае runtest 1.6 сообщить явный аргумент (игнорируется версией runtest 1.5):

$ make -k RUNTESTFLAGS='--all --xml=testsuite.xml' check

Краткий вопрос: WTF? Более точно — чей именно это WTF? В какой из двух проектов (dejagnu или binutils) отправлять багрепорт?

Сегодня утром команда SeaMonkey закончила тестирование и, наконец, анонсировала выпуск SeaMonkey 2.48 (бинарные сборки уже с неделю были доступны на ftp.mozilla.org.

SeaMonkey — это набор интегрированных сетевых приложений, включающий в себя браузер, почтовый клиент, RSS/Atom-агрегатор и WYSIWYG-редактор HTML-страниц. Выпуск 2.48 синхронизирован с кодовой базой Firefox 51.0.3.

Особенности:

• Автоматическое обновление предыдущих версий не работает. Это связано с изменениями в инфраструктуре сборки.
• DOM Inspector 2.0.16.1, доступный с Mozilla Add-Ons, несовместим с SeaMonkey 2.48. Используйте версию 2.0.17.0, собранную Адрианом Каллой (Adrian Kalla) — как только прекратятся перебои с инфраструктурой — см. bug 1383642.
• Компонент «Консоль сообщений об ошибках» (Error Console) теперь является частью SeaMonkey. В Firefox он был заменён компонентами Developer Tools Web и Browser Console, которые теперь тоже доступны в SeaMonkey. «Консоль» теперь доступна по адресу chrome://communicator/content/console/console.xul.
• Модуль просмотра справки (Help Viewer) теперь является частью SeaMonkey (был удалён из Mozilla Gecko).
• Теперь SeaMonkey использует HTTP cache v2 (bug 1241622).
• SSL 3.0 не поддерживается из соображений безопасности (bug 1106470).
• SeaMonkey Sync не работает (bug 998807). Это связано с тем, что Sync-сервера версии 1.1 были некоторое время назад выключены Mozilla. Впрочем, возможно использовать свой собственный либо сторонний сервер, см., напр., Pale Moon Sync.
• Эта версия всё ещё поддерживает NPAPI (планируется сохранять поддержку до версии 2.49.1 включительно).

>>> Английская версия

Задача: хочу выяснить, для сборки каких пакетов (в качестве build-зависимости) нужен пакет X (напр., список всех пакетов, для сборки которых нужен gcj или gfortran).

Т. е. нужно нечто среднее между apt-cache showsrc (показывает зависимости source-пакета, но «не в ту сторону») и apt-cache rdepends (показывает обратные зависимости, но только для бинарных пакетов).

Как решается?

Ищу примеры проектов (желательно на C или C++) с хорошими unit-тестами, использующих в качестве тестовой обвязки DejaGnu, TAP (Test Anything Protocol) либо же интегрирующихся с automake напрямую.

Хочу, чтобы по make test (или make check) выполнялся запуск тестов.

Проекты нужны, дабы тренироваться на кошках — планирую написать интеграцию для Jenkins.

Большие проекты (типа gcc или glibc) не подходят, ибо будут слишком долго собираться. Нужно что-то поменьше, вроде curl, glib или libpng.

Что посоветуете?

Захожу на https://archive.debian.net — и вижу упомянутое сообщение.

Куда он делся? Есть ли альтернативы?

Хочется функциональности https://packages.debian.org (в т. ч. применительно к source-пакетам), но для архивных версий Debian (напр., Woody).

Товарищи, приветствую.

Ставлю jabber.el 0.8.92 из melpa-stable (Emacs 24.x) — и при компиляции наблюдаю кучу ошибок вида:

Compiling file .../.emacs.d/elpa/jabber-0.8.92/jabber-awesome.el at Fri May  5 14:57:12 2017
jabber-awesome.el:21:30:Error: Required feature `jabber-autoloads' was not provided

Compiling file .../.emacs.d/elpa/jabber-0.8.92/jabber-bookmarks.el at Fri May  5 14:57:12 2017
jabber-bookmarks.el:22:1:Error: Required feature `jabber-autoloads' was not provided

Сам пакет (~/.emacs.d/elpa/jabber-0.8.92) наблюдаю, часть исходников скомпилирована.

Причём поведение идентично и на Linux, и на Cygwin.

С другой стороны, jabber.el 0.8.0 из репозитория Debian (пакет emacs-jabber) устанавливается и работает на «ура».

WTF?

Оригинальная статья вышла в журнале «mozillaZine»; ниже публикуется её перевод. Распространение статьи приветствуется.

О положении союза SeaMonkey

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

Самое важное: проект SeaMonkey жив, и мы не планируем прекращать его развитие и поддержку. Но, если мы хотим и впредь выпускать лучший и единственный «комбайн» на платформе Mozilla Gecko, нам понадобится ваша помощь.

( Для начала — о текущем состоянии дел )

>>> Английская версия

Спустя 9 месяцев разработки (предыдущая версия, 2.3.6, была выпущена в июне 2016 года) вышла новая версия библиотеки OpenMotif.

Напомню, что OpenMotif — это одна из старейших библиотек для построения GUI, использующая механизм X Toolkit Intrinsics, лежащая в основе сред CDE, IRIX Interactive Desktop и MaXX Desktop и распространяемая по лицензии LGPL 2.1. Наилучшее представление о разнообразии графических компонентов Motif даёт, пожалуй, вот этот снимок.

Что нового в этой версии:

Официальный файл RELNOTES сообщает:

• Fixed segmentation faults associated with option menus or other popup windows

На деле это исправление сводится к одному коммиту (18de86), который откатывает неудачное исправление бага #1565, который изначально был заведён в RHEL и над исправлением которого коллектив OpenMotif работал более пяти лет. Сам баг #1565 помечен как WONTFIX.

>>> Подробности

Сегодня сподобился таки выяснить, что нового в новой версии одной среды разработки, и увидел какие-то нездоровые соединения по HTTPS с сетью 1e100.net:

$ netstat -4 -p | grep seamonkey
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0 anthrax:44441 a104-126-161-235.:https ESTABLISHED 17902/seamonkey
tcp        0      0 anthrax:60367 74.125.131.95:https     ESTABLISHED 17902/seamonkey
tcp        0      0 anthrax:55755 bam-7.nr-data.net:https ESTABLISHED 17902/seamonkey
tcp        0      0 anthrax:34895 ec2-52-17-140-88.:https ESTABLISHED 17902/seamonkey
tcp        0      0 anthrax:40711 ec2-52-18-226-11.:https ESTABLISHED 17902/seamonkey
tcp        0      0 anthrax:58230 lk-in-f155.1e100.:https ESTABLISHED 17902/seamonkey
tcp        0      0 anthrax:38400 server-205-251-21:https ESTABLISHED 17902/seamonkey
tcp        0      0 anthrax:47717 173.194.122.222:https   ESTABLISHED 17902/seamonkey
tcp        0      0 anthrax:40707 ec2-52-18-226-11.:https ESTABLISHED 17902/seamonkey
tcp        0      0 anthrax:44442 a104-126-161-235.:https ESTABLISHED 17902/seamonkey
tcp        0      0 anthrax:40708 ec2-52-18-226-11.:https ESTABLISHED 17902/seamonkey
tcp        0      0 anthrax:40706 ec2-52-18-226-11.:https ESTABLISHED 17902/seamonkey
tcp        0      0 anthrax:40710 ec2-52-18-226-11.:https ESTABLISHED 17902/seamonkey
tcp        0      0 anthrax:60455 173.194.122.192:https   ESTABLISHED 17902/seamonkey
tcp        0      0 anthrax:40709 ec2-52-18-226-11.:https ESTABLISHED 17902/seamonkey
tcp        0      0 anthrax:42138 ec2-54-217-236-18:https ESTABLISHED 17902/seamonkey

В результате гугления было выяснено, что *.1e100.net, как и следует из названия, — это принадлежащий Google сервис проверки подлинности сайтов.

Буквально первая же ссылка ведёт на SuperUser.com, и комментарии там жгут:

Because Google loves you and just wants you to be happy. Like a benevolent big brother watching your every move and giving you the creepily specific targeted advertising you subconsciously know you need.

Окей, но мой браузер — ни разу не Chrome. WTF?!

• Отключаю к чертям весь safe browsing (browser.safebrowsing.* в about:config).
• Отключаю OCSP (security.OCSP.enabled=0).
• Сношу HTTPS Everywhere.

На выходе same shit — мозилла лезет, куда не следует.

Окей, я не ленивый. Поднимаю BIND 9 и добавляю новую зону:

$TTL    604800
@       IN      SOA     ns.1e100.net. root.1e100.net. (
                              2         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      ns.1e100.net.
@       IN      A       127.0.0.1
@       IN      AAAA    ::1
*       IN      A       127.0.0.1
*       IN      AAAA    ::1

Перезапускаю BIND, переписываю /etc/resolv.conf. Теперь всё должно работать:

$ host li-in-f155.1e100.net
li-in-f155.1e100.net has address 127.0.0.1
li-in-f155.1e100.net has IPv6 address ::1

Запускаю мозиллу — она снова лезет не туда (я наблюдаю ровно тот же вывод, что и в первом листинге, т. к. обратный DNS по-прежнему работает):

$ dig -x 173.194.220.155 | grep -A1 'ANSWER\ SECTION'
;; ANSWER SECTION:
155.220.194.173.in-addr.arpa. 84939 IN  PTR     lk-in-f155.1e100.net.

Причём сброс DNS-кэша операционной системы, её перезапуск и, наконец, запуск браузера с «чистым» профилем и без расширений тоже ни к чему не приводит. Напрашивается один из двух выводов:

• либо Safe Browsing — это неотключаемая «фича», и через какой-то сервис браузер продолжает получать список IP-адресов для соединения по HTTPS,
• либо источник проблемы не на клиенте, а на сервере, и какой-то чёртов JavaScript выполняет роль DNS (разумеется, уже без UDP-запросов на 53-й порт) в обход локального DNS (вы уж простите за конспирологические теории),
• либо, наконец, я недонастроил локальный DNS.

Соответственно, вопрос: WTF и как с этим бороться? В кодовой базе SeaMonkey 2.40 (Firefox 43) «захардкоженных» IP-адресов и строк вида «1e100.net» я не нашёл.

И, чтобы два раза не вставать, вопрос №2.

Попутно, на волне паранойи, решил запретить на уровне DNS всякие facebook.com, fbcdn.net, fb.com, vk.com и прочую дрянь. Отлично, теперь при вводе в строке адреса браузера «fb.com» открывается локальный Apache. Я доволен. Но есть одно «но».

При попытке зайти на http://facebook.com (который, напомню, разрешается в 127.0.0.1) браузер пытается перейти на https://facebook.com, при том, что на моём локальном Apache не сконфигурирована HTTP Strict-Transport-Security и никаких HTTP 302 он тоже, разумеется, не шлёт. Причём версии браузеров трёхлетней давности такой ерундой не страдают.

WTF?! Опять начинаю искать в кодовой базе — и нахожу просто прелестное.

Без малого 3000 доменов, к которым надо ходить строго так, как приказал Большой Брат, описаны в файле security/manager/ssl/nsSTSPreloadList.inc.

И это ещё полбеды. Есть ещё security/manager/ssl/StaticHPKPins.h, содержащий фингерпринты X.509-сертификатов всё тех же сайтов.

Вопрос: как выключить этот чёртов HPKP (на этапе компиляции либо через about:config)? Хочу свой facebook.com с блэкджеком и шлюхами шахматами и поэтессами.

Читал тут давеча стандарт (XLFD Conventions, 1989 года, автор — Джим Флауэрс (Jim Flowers) из DEC) и обнаружил для себя новое.

Оказывается, в поле ptSz можно указать не просто размер шрифта в десятках пунктов (120 == 12pt), а настоящие коэффиценты матрицы (в виде [x1 x2 y1 y2]) для аффинного преобразования символов. При этом пресловутое скалярное значение 120 соответствует матричным коэффициентам [12.0 0 0 12.0] (единичная матрица, умноженная на размер в пунктах; коэффициенты с плавающей точкой; отрицательные значения задаются через тильду (~) вместо минуса (-), поскольку минус является разделителем полей в XLFD).

Применение? Элементарно. Например, так можно получить курсив из обычного шрифта. Или обратный курсив (reverse oblique).

Но можно и совсем упороться и тупо перевернуть символы (и получившийся текст, при определённой сноровке, даже можно прочитать).

А Xft или FreeType так умеет? =)

Исторически использовал Monotype Courier New в кач-ве шрифта XTerm (хорошо отображает и кирилицу, и псевдографику. Ну и, кроме того, он у меня использовался везде — в PuTTY на оффтопике, в IDE, во всяких вимах/емаксах и т. д.). После миграции с KOI8-R на UTF-8 (нет, я не с Луны свалился, это было уже много лет назад), заметил увеличение межстрочного интервала (тж известного как интерлиньяж), после чего любимый Courier New оставалось разве что выкинуть на помойку.

Вот так XTerm выглядел (и выглядит по сей день) в ru_RU.KOI8-R (12pt Courier New).

А вот так он выглядит сейчас (ru_RU.UTF-8, те же 12pt, та же ширина символов, размер терминала по-прежнему 80x24, но вот интерлиньяж увеличен, в результате чего линии псевдографики имеют характерные «разрывы» между строк).

Ну и, собственно, XTerm не один такой красивый. Все программы, использующие Core X11 Fonts, обнаруживают схожее поведение. Вот, например, xfontsel, например.

• KOI8-R (скриншот).
• ISO 10646-1 (ну т. е. Unicode, скриншот).

Что интересно, Courier New — это единственный чёртов TrueType-шрифт, за которым замечен такой грех. У других шрифтов, как -misc-freemono-*, межстрочный интервал от кодировки X11 не зависит.

Вопрос.

Как принудительно изменить межстрочный интервал для конкретного шрифта? В какую сторону смотреть? FreeType? Или Xft?

Это которые серверные и доступны через XLFD-описания (в основном Xaw, Motif, GTK+ 1.x, Qt 1.x).

Вот, помнится, раньше (в Debian до версии 6 («Squeeze») включительно) был такой пакет defoma (и ещё x-ttcidfont-conf к нему впридачу).

В процессе установки новых TrueType-шрифтов включались какие-то триггеры, в результате чего шрифты регистрировались не только в клиентском fontconfig'e, но и в xfs с автоматической доступностью всем X11-серверам в сети (в каталоге со шрифтами обновлялись/создавались fonts.dir/fonts.scale/fonts.alias, сам каталог дописывался в /etc/fs/config, процессу xfs посылался SIGHUP).

На стороне X11-сервера я только делал что-то наподобие «xset fp rehash» — и вуаля!

И вот теперь я типа портирвал этот самый defoma на Debian 7+, воткнул его в машину с Jessie, снёс и переустановил шрифты — и хрен по деревне. Никаких тебе триггеров, и dpkg-reconfigure не помогает. Что как бы наводит на мысль, что была ещё какая-то (ныне выпиленная) обвязка на стороне пакетов шрифтов как раз для интеграции с defoma.

Соответственно, у меня три вопроса:

1. Кто ещё помнит, как работает defoma?
2. Какие есть альтернативы? Запускать ручками mkfontscale каждый раз, когда я обновлю шрифты, не хочется. «crontab -e» не предлагать.
3. Наконец, как с тем же самым обстоят дела в других ОС/дистрибутивах. Особенно интересны отклики пользователей Gentoo и семейства *BSD UNIX — вдруг мне с тёплого лампового дебиана уже сползать пора?