После очередного обновления дефолта на дефолт, была замечена ликвидация python27. Еще 10 лет разработки из чьих-то жизней ушли в никуда.

Перемещено alpha из screenshots

В gnome 2 была настройка для установки dpi . В третьемгноме не могу найти .
Где теперь это настраивается? Сейчас вот такой бред:

$ xdpyinfo | grep resolution
resolution: 129x127 dots per inch

$ xrdb -query | grep dpi
Xft.dpi:   96

Есть-ли возможность подсмотреть структуру интерфейса (иерархию виджетов) у gtk приложения? Вопрос возник в процессе тюнигда темы gtk. Например, можно-ли, не залезая в исходники, узнать, что у Nautilus есть виджеты Places и Sidebar? Как узнать какие есть еще виджеты?

widget_class «*Nautilus*Places*Sidebar*» style «nautilus-sidebar»

Есть две бредовые идеи и подозрение, что уже все давно реализовано :

1. Типичный алгоритм для генерации динамической html-страницы при помощи php, с кешированием результата, выглядит следующим образом: php скрипт формирует html-страницу, записывает содержимое в кеш (файл), после чего отдает данные. При следующем обращении к этому же самомоу url, если кеш валиден, php просто отдает данные из файла.

Недостаток очевиден: для отдачи кеша страницы -- фактически статического файла -- используется интерпретатор php, в то время как apache (или любой другой web-сервер), могут это делать гораздо шустрее и потребляя меньше памяти.

Идея: сделать так, чтобы php скрипт возвращал apache'у не сам контент, а лишь путь к файлу. А apache, каким-то магическим образом, уже бы сам отдавал данные из этого файла. Какой модуль апача можно использовать?

Смысл в том, чтобы как можно раньше выгружать сеанс php из памяти. Т.е. php-скрипт в этом случае будет заниматься авторизацией пользователя, выбором, проверкой валидности, и формированием кеш-файла при необходимости. После того, как он быстренько отдаст путь к файлу, php-сеанс можно чистить. Основное время (в реальном масшабе) сервер тратит на отдачу данных (если у пользователя еще и медленное соединение...), когда продолжать держать весь сеанс php в памяти нет ни какого смысла..

2. Ответ http-сервера состоит из http-заголовков, пустой строки и собственно данных. Если данные статические, то заголовки будут всегда одни и те же (размер данных, дата модификации, тип контента, кодировка и т.п.).

Идея: для статического контента все заголовки достаточно вычислить один раз в жизни, после чего сохранить в кеш-файл полный дамп ответа сервера (т.е. заголовки, пустую строку и содержимое исходного контента). В этом случае, для генерации ответа, apache'у достаточно выдать ("HTTP/1.0 200 OK\r\nDate: <дата>"), а дальше тупо прочитать файл. Быстрее и проще не бывает. Какой модуль можно использовать?

>>>

есть репозиторий mercurial для постоянно развивающегося проекта "project". Обновления коммитятся в branch с именем "trunk". Заказчик попросил сделать несколько специфичных изменений в исходниках, которые не нужны в основной ветке, однако заинтересован, чтобы все последующие обновления из trunk были ему доступны. Было принято решение для версии проекта заказчика сделать отдельный бранч "customer". Таким образом теперь в проекте два head:

$ hg heads
changeset: 2197...
branch: trunk -- рабочая версия.
...
changeset: 2188...
branch: customer -- версия заказчика.

теперь для синхронизации версии заказчика с trunk можно периодичести набирать:
$ hg update customer
$ hg merge -r trunk
$ hg commit

однако наоборот -- из customer в trunk -- мержить нельзя ни при каких обстоятельствах. как-то можно обезопасить репозиторий от возможности такого действия со стороны несознательного разработчика? хук какой-нить в .hgrc?

или есть лучшие способы для работы с версиями проектов?

>>>

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

echo 'hi all! всем привет' | grep --colour=auto -E '[[:alpha:]]+'

подкрашивает только hi и all. кириллица не подкрашена. если убрать латиницу, в выводе остается фраза, но не подкрашена.

echo 'hi all! всем привет' | pcregrep --colour=auto '[[:alpha:]]+'

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


$ locale
LANG=ru_RU.UTF-8
LC_CTYPE="ru_RU.UTF-8"
LC_NUMERIC="ru_RU.UTF-8"
LC_TIME="ru_RU.UTF-8"
LC_COLLATE="ru_RU.UTF-8"
LC_MONETARY="ru_RU.UTF-8"
LC_MESSAGES="ru_RU.UTF-8"
LC_PAPER="ru_RU.UTF-8"
LC_NAME="ru_RU.UTF-8"
LC_ADDRESS="ru_RU.UTF-8"
LC_TELEPHONE="ru_RU.UTF-8"
LC_MEASUREMENT="ru_RU.UTF-8"
LC_IDENTIFICATION="ru_RU.UTF-8"
LC_ALL=

>>>

Хочется научить наутилус рисовать для *.exe'шников встроенные иконки.

Наткнулся на совет http://www.objectnetworks.net/wiki/index.php?title=Exe_icon_for_Gnome , где предлагают для этих целей использовать механизм thumbnails.

Проблема в том, что nautilus вокруг каждой миниатюры рисует рамку. И если для миниатюр, например картинок, рамка смотрится нормально, то для иконок выглядит лишней.

Можно-ли отключить рамку вокруг миниатюр для определенного типа файлов?

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

>>>

linux gentoo. видео GeForce FX 5600, вполне устраивает.

обновил ядро (раньше было 2.6.22). а последний, поддерживавший эту видюху драйвер от производителя nvidia-drivers-100.14.19 , не собирается. понятно, что причина в том, что в ядре кучу всего поменяли. :( как быть?

зы: покаместь воткнул xf86-video-nv. но грустно как-то...

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

>>>

Всем привет!

Знатоки этого чудесного редакторя, подскажите, plsss..., что нужно прописать в конфиге Vim'а для того, чтобы он делал следующее, при редактировании файла text.tex:

по <F9> он бы вызывал: make text.tex,

по <F5> -- !xdvi text.dvi,

где text -- любое имя. то есть нужно сочинить универсальный биндинг для tex'овых файлов, зависящий от имени текужего редактируемого файла. причем хочется, чтобы эти нлавиши действовали в любом режиме (вставки, коммандном и т.п.)

а может вы знаете нужный man, где про это рассказано?

Привет, All!

скачал из cvs winex. запускаю

./configure --prefix=/usr --sysconfdir=/etc --localstate=/var \
--enable-opengl --enable-osmesa --disable-debug
...
make depend && make

и компиляция прерывается: не определено OSMESA_NONE_TGT в файле
dlls/x11drv/osmesa.c :(

rgrep -lr OSMESA_NONE_TGT ./
находит данный текст только в этом osmesa.c ( в файле встречается один раз )

rgrep -lr OSMESA_NONE_TGT /usr/include
rgrep -lr OSMESA_NONE_TGT /usr/X11R6/include
rgrep -lr OSMESA_NONE_TGT /home/me/xc // исходник xfree86-4.0.1
rgrep -lr OSMESA_NONE_TGT /home/me/xc-dri //исходник xfree86-dri
не находят ничего.

xfree86 -- v 4.2.0, с установленной поверх, только что скаченной
из cvs -- xfree86-dri (mesa-4.0.1).

что же нужно еще этому winex для сборки? подскажите, plsss...

я хочу установить ядро линукс. на компакт диске есть архив с исходниками linux-2.2.20.tar.bz2, но я не вполне уверен, что это оригинальный (всмысле не патченный) архив. качать заново полный исходник ядра не очень хочется -- долго. какой утилитой можно проверить правильность моего архива, по linux-2.2.20.tar.bz2.sign, скаченного с www.kernel.org?

22 октября 2001 Вышел "стабильный" релиз Mesa 4.0. Добавлены поддержка OpenGL 1.3 и куча исправленных ошибок :)

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