Однажды люди в Microsoft сделали хорошее дело( да ну? )

Вот спек-файл: microsoft-core-fonts.spec (5K).

Чтобы поставить себе это на Федору, вот примерно что нужно сделать:
wget http://kir.sacred.ru/lj/microsoft-core-fonts.spec
yum install fontpackages-devel xorg-x11-font-utils wget cabextract
rpmbuild -bb microsoft-core-fonts.spec
(если всё сложилось хорошо, то где-то среди последних строчек будет строка, начинающаяся со слова Wrote:, а после неё имя файла. Вот возьмите это имя файла (полное, вместе с путём) и напишите:
rpm -ihv имя_файла

В прошлом году, летом ещё, я написал пост "Сатанинские пляски. Исполняет GTK+", а также зафайлил Red Hat bug #459567. И не просто зафайлил, а потратил какое-то время и дал способ более-менее просто, быстро и надёжно воспроизвести этот баг.

Этим летом деятели из редхата ту багу потихоньку закрыли, пользуясь тем, что Fedora 9 уже не поддерживается. Пишут, мол, если воспроизводится, переоткрой. А я уже перешёл с Гнома на XFCE. Но добрался-таки -- воспроизвёл, переоткрыл.

Теперь жду, что напишут, мол, Федора 10 уже закончилась, поэтому закрываем.

Что я могу сказать по этому поводу окромя ненормативной лексики? Нельзя так работать! Я им баг на тарелочке с голубой каёмочкой, а они мне WONTFIX. Ай-яй-яй!

Последствия
Забавно, что после перехода с ~/.xinitrc на ~/.Xclients у меня сменился моноширинный шрифт. Нет, даже не моноширинный шрифт, а шрифт, используемый в строке статуса и строке ввода Vimperator. Больше, вроде бы, ничего вообще не поменялось. fc-match monospace показывает одно и то же. Даже не представляю, куда копать.

Выводы
В Линуксе всё совсем не так, как было раньше. Но я всё ещё пока могу понять, как это работает.

Ага, ну вот я и дорешал проблему.

Оказалось, что виной всему мой ~/.xinitrc! Дело в том, что xinit подпёрт для ConsoleKit в нескольких местах. Одно из таких мест -- запуск бинаря ck-xinit-session, который делается в /etc/X11/xinit/xinitrc-common, который сорсится из /etc/X11/xinit/xinitrc.

Так вот, если есть пользовательский ~/.xinitrc, то /etc/X11/xinit/xinitrc уже не используется (решает, что использовать, а что нет, скрипт startx), соответственно ck-xinit-session не вызывается, и ConsoleKit ничего про иксы не знает.

Фикс в моём случае такой:

mv ~/.xinitrc ~/.Xclients
chmod u+x ~/.Xclients

Продолжение душещипательной истории про ConsoleKit, HAL, ACL и т.п.

Вводная. Я не использую *DM (то есть графический логин), а логинюсь в консоли, после чего пишу startx. Ну вот привык я так, нравится мне. На первых 8 консолях висят getty, а на девятой запускается сессия X Window.

Так вот, когда я переключаюсь в эту девятую консоль, какие-то демоны (замуровали!) убирают у меня все пермиссии на звуковые устройства из ACL! То же самое происходит, когда я переключаюсь в консоль, где есть getty и никто не залогинен. И, конечно, даже если я руками добавлю себе прав, после переключения консолей она пропадает!

Теперь хотя бы понятно, что надо делать -- как-то научить startx (или xinit, или X), чтобы он рассказывал всем этим демонам, что эту консоль занимает $USER. Очевидно, он этого не рассказывает.

Update: а вот и баг нашёлся, якобы пофикшенный в 2007 году. Надо разбираться, какого рожна не работает.

Раньше, когда ты логинился, специальный PAM модуль выставлял всякие пермиссии для тебя, в частности, для устройств звуковой карты (/dev/audio, /dev/mixer, /dev/dsp, /dev/snd/*). Всё достаточно просто конфигурировалось в /etc/security/console.perms.d/.

Теперь это делают ConsoleKit вместе с HAL, причём выставляют не пермиссии, а дополнительные ACL. Как они это делают, выяснить за 15 минут я не смог.

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

Чудовищно...

Update: за 20 минут я вроде выяснил, правда, очень в общем виде. Там несколько демонов для этого дела, в частности console-kit-daemon и hal-daemon (последний ещё получает сообщения от ещё одного демона -- udev). Полиси по саунд девайсам прописано в /usr/share/hal/fdi/policy/10osvendor/20-acl-management.fdi и далее в /usr/share/PolicyKit/policy/org.freedesktop.hal.device-access.policy. Как видите, там ещё какой-то PolicyKit участвует. Застрелиться и не жить!

История с колёсиком прокрутки на (сильно нестандартной) клавиатуре в Линуксе (см. 1, 2, 3, 4) получила забавное продолжение. Теперь, в Федоре 10, X Window конфигурится аутоматично, то есть через HAL, то есть HAL сообщает иксам, какие есть в системе девайсы. Ну и, как мне кажется, оный HAL не ожидает увидеть мышь (с точки зрения ОС колесо прокрутки -- это такая усечённая мышь) на клавиатуре, ввиду чего эту "мышь" X Window не видит.

Зафайлил багу (Red Hat bug #484654). Suggestions and workarounds are welcome.