Всем здравствуйте.

Недавно по рекомендации какого-то другого пакета установил пакет fonts-ubuntu и вскоре заметил, что Vivaldi для отрисовки UI предпочитает именно эти шрифты, несмотря на то, что я явно просил о другом.

В колхозном CSS-файле для настройки UI Vivaldi:

/*
 * Main menubar.
 */
.topmenu {
        font-family: Arial !important;
        font-size: 12pt !important;
        font-style: normal !important;
        color: inherit !important;
        background-color: inherit !important;
}

/*
 * Tab bar.
 */
.topmenu + #tabs-tabbar-container.top {
        font-family: Arial !important;
        font-size: 12pt !important;
        font-style: normal !important;
        color: inherit !important;
        background-color: inherit !important;
}

Итак, вроде, всё нормально: для отрисовки меню должен использоваться шрифт Arial. «Понеслась.» Запускаем Vivaldi:

strace -f -e open,openat /opt/vivaldi/vivaldi-bin 2>&1 | grep -vF ENOENT | grep -E '\"\/usr\/share\/fonts\/truetype\/[^\"]+[^\/]\.[A-Za-z]{3,4}\"'

И тут в выводе strace я вижу чудное:

[pid 12949] openat(AT_FDCWD, "/usr/share/fonts/truetype/msttcorefonts/Arial.ttf", O_RDONLY) = 200
[pid 12957] openat(AT_FDCWD, "/usr/share/fonts/truetype/ubuntu/Ubuntu-R.ttf", O_RDONLY) = 260 <----------------------
[pid 12957] openat(AT_FDCWD, "/usr/share/fonts/truetype/msttcorefonts/Arial.ttf", O_RDONLY) = 260
[pid 12957] openat(AT_FDCWD, "/usr/share/fonts/truetype/ubuntu/Ubuntu-B.ttf", O_RDONLY) = 260 <----------------------
[pid 12956] openat(AT_FDCWD, "/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf", O_RDONLY) = 260
[pid 12956] openat(AT_FDCWD, "/usr/share/fonts/truetype/msttcorefonts/Arial_Italic.ttf", O_RDONLY) = 235
[pid 12956] openat(AT_FDCWD, "/usr/share/fonts/truetype/msttcorefonts/Arial.ttf", O_RDONLY) = 200
[pid 12946] openat(AT_FDCWD, "/usr/share/fonts/truetype/msttcorefonts/Arial_Bold_Italic.ttf", O_RDONLY) = 181
[pid 12987] openat(AT_FDCWD, "/usr/share/fonts/truetype/msttcorefonts/Courier_New.ttf", O_RDONLY) = 264
[pid 12957] openat(AT_FDCWD, "/usr/share/fonts/truetype/msttcorefonts/Times_New_Roman.ttf", O_RDONLY) = 264
[pid 12957] openat(AT_FDCWD, "/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf", O_RDONLY) = 264
[pid 12957] openat(AT_FDCWD, "/usr/share/fonts/truetype/noto/NotoColorEmoji.ttf", O_RDONLY) = 264
[pid 12947] openat(AT_FDCWD, "/usr/share/fonts/truetype/msttcorefonts/Times_New_Roman_Bold.ttf", O_RDONLY) = 264
[pid 12947] openat(AT_FDCWD, "/usr/share/fonts/truetype/ubuntu/Ubuntu-M.ttf", O_RDONLY) = 264 <----------------------

Ну и по начертанию шрифта видно, что «не тот». Для сравнения, если снести к чертям собачьим пакет fonts-ubuntu, то всё становится на свои места:

[pid 13679] openat(AT_FDCWD, "/usr/share/fonts/truetype/msttcorefonts/Arial.ttf", O_RDONLY) = 219
[pid 13668] openat(AT_FDCWD, "/usr/share/fonts/truetype/msttcorefonts/Arial.ttf", O_RDONLY) = 245
[pid 13668] openat(AT_FDCWD, "/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf", O_RDONLY) = 245
[pid 13679] openat(AT_FDCWD, "/usr/share/fonts/truetype/msttcorefonts/Arial_Italic.ttf", O_RDONLY) = 269
[pid 13679] openat(AT_FDCWD, "/usr/share/fonts/truetype/msttcorefonts/Arial.ttf", O_RDONLY) = 220
[pid 13669] openat(AT_FDCWD, "/usr/share/fonts/truetype/msttcorefonts/Arial_Bold_Italic.ttf", O_RDONLY) = 171
[pid 13679] openat(AT_FDCWD, "/usr/share/fonts/truetype/msttcorefonts/Courier_New.ttf", O_RDONLY) = 245
[pid 13678] openat(AT_FDCWD, "/usr/share/fonts/truetype/msttcorefonts/Times_New_Roman.ttf", O_RDONLY) = 245
[pid 13678] openat(AT_FDCWD, "/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf", O_RDONLY) = 245
[pid 13678] openat(AT_FDCWD, "/usr/share/fonts/truetype/noto/NotoColorEmoji.ttf", O_RDONLY) = 245
[pid 13668] openat(AT_FDCWD, "/usr/share/fonts/truetype/msttcorefonts/Times_New_Roman_Bold.ttf", O_RDONLY) = 245
[pid 13658] openat(AT_FDCWD, "/usr/share/fonts/truetype/msttcorefonts/Arial.ttf", O_RDONLY) = 305

Сам пакет fonts-ubuntu винить не в чем: никаких доп. правил в /etc/fonts он не устанавливает:

$ dpkg -L fonts-ubuntu
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/fonts-ubuntu
/usr/share/doc/fonts-ubuntu/CONTRIBUTING.txt
/usr/share/doc/fonts-ubuntu/FONTLOG.txt.gz
/usr/share/doc/fonts-ubuntu/LICENCE-FAQ.txt.gz
/usr/share/doc/fonts-ubuntu/README.txt
/usr/share/doc/fonts-ubuntu/TRADEMARKS.txt
/usr/share/doc/fonts-ubuntu/changelog.Debian.gz
/usr/share/doc/fonts-ubuntu/copyright
/usr/share/fonts
/usr/share/fonts/truetype
/usr/share/fonts/truetype/ubuntu
/usr/share/fonts/truetype/ubuntu/Ubuntu-B.ttf
/usr/share/fonts/truetype/ubuntu/Ubuntu-BI.ttf
/usr/share/fonts/truetype/ubuntu/Ubuntu-C.ttf
/usr/share/fonts/truetype/ubuntu/Ubuntu-L.ttf
/usr/share/fonts/truetype/ubuntu/Ubuntu-LI.ttf
/usr/share/fonts/truetype/ubuntu/Ubuntu-M.ttf
/usr/share/fonts/truetype/ubuntu/Ubuntu-MI.ttf
/usr/share/fonts/truetype/ubuntu/Ubuntu-R.ttf
/usr/share/fonts/truetype/ubuntu/Ubuntu-RI.ttf
/usr/share/fonts/truetype/ubuntu/UbuntuMono-B.ttf
/usr/share/fonts/truetype/ubuntu/UbuntuMono-BI.ttf
/usr/share/fonts/truetype/ubuntu/UbuntuMono-R.ttf
/usr/share/fonts/truetype/ubuntu/UbuntuMono-RI.ttf

Уважаемые разработчики Vivaldi, как же так? Какой пункт настройки я пропустил?

P. S. Вы делаете замечательный продукт – на голову выше, чем у конкурентов. Спасибо.

Cast Shpankov.

Всем здравствуйте.

Собственно, для начала хочу научиться собирать пакеты для x86 и x32 ABI на amd64-хосте.

Статью CrossCompiling на Debian Wiki видел.

Насколько я понимаю, есть два официально одобренных инструмента – sbuild (восход Солнца вручную) и pbuilder (всё достаточно автоматизировано, но до уровня Docker не дотягивает).

Вопросы:

• почему (для решения тех же задач) так непопулярен Docker? Смотрю на PackagingWithDocker – и это какой-то позор. Такое ощущение, что на wiki.debian.org пишут исключительно старцы в маразме, государственные чиновники и дети-инвалиды.

  • При этом исправить самому нет никакой возможности: регистрация уже несколько лет, как не работает:

    Account creation failed: Automatic account creation disabled to stop spammers signing up. Please contact wiki@debian.org and describe what you want to do in the wiki. Please contact us in English, otherwise we will have to pass your message to online translation services.

    Ау, вы сеьёзно?! 21-й век на дворе, а вы не можете справиться со спамерами?! Я, чёрт побери, хочу править вашу убогую Wiki, чтобы сделать её чуточку лучше. Какое ещё описание вам нужно?

• как наладить сборку с помощью CI-сервера (Jenkins/TeamCity/другого)? Я когда-то сам писал статью на эту тему, но мой опыт – это исключительно самодеятельность, и с жизненным циклом дебиановского пакета оно вяжется плохо.

• как организовать сборку, имея пул не локальных Docker-контейнеров, а доступных по сети физических или виртуальных машин с целевой архитектурой и окружением?

Всем здравствуйте.

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

Upstream-версия останется той же.

Бинарная совместимость (пересобираю библиотеку) сохранится.

Хочется (и это логично), чтобы пересобранный пакет был отличим от пакета из репозитория Debian.

Этого можно добиться двумя способами:

1. Слегка инкрементировав версию (1.2.3-4+deb10u2 -> 1.2.3-4+deb10u2~vasyapupkin). При этом, если параллельно не заморачиваться с apt pinning, после обновления по-прежнему можно затереть «свой» пакет версией из репозитория.

2. Переименовав пакет (libfoo42 -> libfoo42-vasyapupkin provides libfoo42).

Вопросы:

1. Какой из вариантов каноничнее?
2. Как организовать систему веток и git remote’ов, чтобы можно было не только разово собрать, но и периодически делать merge из upstream и из Debian?
3. Быть может, вопрос не нов, и на эту тему уже что-то написано?

Всем здравствуйте.

Как пересборать FreeType 2.7+ так, чтобы по умолчанию выбиралась версия 35 интерпретатора байткода TrueType?

Т. е. я хочу по умолчанию поведения, как в FreeType 2.6, но без необходимости указывать

FREETYPE_PROPERTIES=truetype:interpreter-version=35

И хочется при этом, чтобы более новые версии интерпретатора (38 и 40) тоже были доступны – путём указания FREETYPE_PROPERTIES либо программно, через FT_Property_Set().

Сижу, курю /usr/include/freetype2/freetype/config/ftoption.h – и что-то не понимаю. Вижу лишь, что можно полностью выключить субпиксельный хинтинг, но также это полностью отключает интерпретаторы версий 38 и 40.

P.S. Указание версии по умолчанию в /etc/environment не вариант – интересует именно пересборка.

Всем здравствуйте.

TL;DR: Похоже, что X-сервер отдаёт серверные шрифты в фиксированном разрешении 100 dpi, а не в разрешении, текущем для сервера.

Немного теории. Есть серверные шрифты, которые X-клиенту по сети (через TCP либо UNIX socket) «отдаёт» либо сам X-сервер, либо отдельный X Font Server (один или несколько). В отличие от привычных всем клиентских шрифтов (Xft, GTK 2+, Qt 2+), «серверный» backend (он ещё называется core X font backend) не поддерживает антиалиасинг, но поддерживает сетевую прозрачность (т. е. по сети перегоняются bitmap’ы без альфа-канала). На уровне приложения серверные шрифты задаются не в виде XftFontStruct (что чаще всего вырождается в привычное нам DejaVu Sans Mono 12), а в виде XLFD. Если мы говорим о локальной машине, то один и тот же файл шрифта может быть зарегистрирован сразу в двух подсистемах и доступен и современным приложениям на базе GTK и Qt, и «суровому легаси» (Xt, Athena, Motif, GTK 1.2, Qt 1.x).

Исторически серверные шрифты были растровыми (*.pcf), а для растра существует такое понятие, как его собственное, растра, разрешение. Поэтому в XLFD есть такие поля, как RESOLUTION_X и RESOLUTION_Y. Чтобы растровый шрифт выглядел на экране адекватно, разрешение растра должно быть близким к разрешению экрана, поэтому растровые шрифты обычно поставлялись с собственным разрешением в 75 dpi и 100 dpi (каталоги /usr/share/fonts/X11/75dpi и /usr/share/fonts/X11/100dpi – как раз про это). Так,

-bitstream-charter-bold-r-normal--12-120-75-75-p-75-iso8859-1
-bitstream-charter-bold-r-normal--17-120-100-100-p-107-iso8859-1

– это один и тот же шрифт размером 12 pt, имеющий характерный размер символа

• 12 px при разрешении 75 dpi, и
• 17 px – при 100 dpi, соответственно.

Но, помимо растровых шрифтов, есть ещё векторные (TrueType, OpenType, Adobe Type 1), которые мы все любим и которые можно безбоязненно масштабировать. Некоторые реализации X-сервера (напр., XSun) поддерживали ещё формат Adobe Type 3, в котором шрифт описывался с помощью языка PostScript (Тьюринг-полного, кстати).

К векторным шрифтам понятие разрешения растра, естественно, неприменимо, поэтому в полях RESOLUTION_X и RESOLUTION_Y я могу запрашивать 0, а могу запрашивать «звёздочки» (*), и, в теории, X-сервер должен отдать мне нужный шрифт. Об этом напрямую говорится в статье Arch Wiki по ссылке выше:

Scalable fonts were designed to be resized. A scalable font name, as shown in the example below, has zeroes in the pixel and point size fields, the two resolution fields, and the average width field.

…

To specify a scalable font at a particular size you only need to provide a value for the POINT_SIZE field, the other size related values can remain at zero. The POINT_SIZE value is in tenths of a point, so the entered value must be the desired point size multiplied by ten.

Так, любой из этих запросов должен мне вернуть шрифт Courier New размером 12 pt в разрешении X-сервера:

-monotype-courier new-medium-r-normal--*-120-*-*-m-*-iso10646-1
-monotype-courier new-medium-r-normal--0-120-0-0-m-0-iso10646-1

Или, по кр. мере, я так думал. Штука в том, что, пересев с мониторов с разрешением в 96…115 dpi за 4k-монитор с разрешением в 162 dpi, я заметил, что мои заботливо выбранные векторные шрифты внезапно стали мелковаты.

И выяснилось, что, если явно не указывать RESOLUTION_X и RESOLUTION_Y равными 162 (а никто в здравом уме этого не делает – это пришлось бы каждый раз при изменении монитора переписывать сотни строк Xresources), то X-сервер по умолчанию отдаёт шрифт в разрешении 100 dpi вместо 162. Разница между 17-ю пикселями и 27-ю (пресловутый коэффициент 1.62 = 162 / 100) достаточно заметна. Вот пример для современного Debian 10 (сверху для сравнения дан снимок font-manager, отрисовывающего клиентский шрифт): Debian 10, Courier New 12pt.

Я было подумал, что это следствие постепенного выпиливания устаревших подсистем из X11, но в Debian Woody, выпущенном в 2002 году и имеющем ядро 2.2, увидел ровно то же самое: Debian 3, Courier New 12pt. Разве что сам шрифт старый Debian отрисовывает «чище», видимо, выполняя хинтинг на серверной стороне, до пересылки bitmap’ов по сети.

Проблема существовала всегда и в равной степени затрагивает все векторные шрифты (TrueType, OpenType, Type 1).

Собственно, вопрос. Старожилы, посоветуйте – есть ли способ, не зашивая жёстко в пользовательские настройки для каждого отдельного ресурса разрешение X-сервера, обойтись меньшей кровью, чем рекомендует автор статьи Sharing Xresources between systems? Поддержка препроцессора в xrdb, увы, всё-таки достаточно убога.

Можно ли решить что-то на уровне глобальной конфигурации собственно X-сервера?

Или меня спасёт m4?

Cast Zubok.

Update. По здравом размышлении я пришёл к выводу, что схема XLFD сама по себе ущербна. Дело в том, что X-ресурсы (речь в первую очередь о шрифтах) для каждой конкретной программы могут существовать как на стороне сервера (всё то, что даётся на вход xrdb), так и на стороне клиента (см. XUSERFILESEARCHPATH). И настройки, скажем, шрифта для пресловутого xterm должны храниться где-то в одном месте – либо на клиенте, либо на сервере. А XLFD включает в себя и серверные параметры (RESOLUTION_X и RESOLUTION_Y), и клиентские (CHARSET_REGISTRY и CHARSET_ENCODING – ведь потенциально удалённый, «сетевой» X-клиент может быть запущен в окружении и с региональными настройками, отличными от окружения и настроек X-сервера) – и вот это как раз-таки и неправильно. При разработке Xft Кит Пакард всё сделал по уму: имя и размер шрифта в пунктах (DejaVu Sans Mono:size=12) задаёт X-клиент, а X-ресурс Xft.dpi является частью состояния X-сервера.

Возможно, мою проблему удастся решить с помощью серверных псевдонимов шрифтов (font aliases, файлы fonts.alias).

JWZ о том, как авторы cinnamon-screensaver в очередной раз сделали всё криво:

https://www.jwz.org/blog/2021/01/i-told-you-so-2021-edition/

И о нарушении своей лицензии.

Всем здравствуйте.

На старой матери вспухли 7 конденсаторов, все идентичные: 1000 мкф, 10 В.

Что лучше в данном случае на замену: TDK 1000 мкф, 10 В или рассчитанные на чуть большее напряжение Panasonic (1000 мкф, 16 В, low ESR)?

Всем здравствуйте.

Монтирую удалённую ФС на клиенте, который входит в net-группу NIS «trusted».

Почему при вот таком варианте экспорта на NFS-сервере ФС монтируется только для чтения?

/export/backup @trusted(mp,rw,sync,subtree_check,pnfs) 192.168.0.0/24(mp,ro,sync,subtree_check,pnfs)

Вот в таких случаях всё нормально:

/export/backup @trusted(mp,rw,sync,subtree_check,pnfs) *(mp,ro,sync,subtree_check,pnfs)
# или
/export/backup @trusted(mp,rw,sync,subtree_check,pnfs)

Получается, что диапазон IP-адресов, в отличие от *, имеет более высокий приоритет, чем запись из /etc/netgroup. Но это противоречит матчасти:

       If a client matches more than one of the specifications above, then the
       first match from the above list order takes precedence - regardless  of
       the  order they appear on the export line. However, if a client matches
       more than one of the same type of specification (e.g.  two  netgroups),
       then  the  first  match  from  the order they appear on the export line
       takes precedence.

Косвенно наблюдения подтверждаются поведением exportfs: и exportfs -rv, и exportfs -s упрямо помещают 192.168.0.0/24 наверх списка независимо от того, в каком порядке эта маска указана в /etc/exports.

Всем здравствуйте.

Пытаюсь записать несколько старых образов, лежащих в формате cue sheet/bin image:

FILE "%s.bin" BINARY
   TRACK 01 MODE1/2352
   INDEX 01 00:00:00
   TRACK 02 AUDIO
   INDEX 00 26:52:11
   INDEX 01 26:54:11
   TRACK 03 AUDIO
   ...

K3b всё «успешно» пишет, но в конце при попытке прослушать звуковые дорожки слышу белый шум (симптомы точь-в-точь, как в этом древнем обсуждении).

При попытке сделать всё то же самое из консоли cdrdao write %s.cue приводит к тому же «успешному» результату, что и k3b, а wodim выдаёт ошибку:

$ wodim -vv -sao --eject --cuefile=%s.cue
TOC Type: 1 = CD-ROM
wodim: Operation not permitted. Warning: Cannot raise RLIMIT_MEMLOCK limits.
Device was not specified. Trying to find an appropriate drive...
Detected CD-R drive: /dev/cdrw
Using /dev/cdrom of unknown capabilities
scsidev: '/dev/cdrom'
devname: '/dev/cdrom'
scsibus: -2 target: -2 lun: -2
Linux sg driver version: 3.5.27
Wodim version: 1.1.11
Using libusal version 'Cdrkit-1.1.11'.
Driveropts: 'burnfree'
SCSI buffer size: 64512
Device type    : Removable CD-ROM
Version        : 0
Response Format: 2
Capabilities   : 
Vendor_info    : 'Slimtype'
Identification : 'eNAU608   5     '
Revision       : 'CL03'
Device seems to be: Generic mmc2 DVD-R/DVD-RW.
Current: 0x000A (CD-RW)
Profile: 0x002B (DVD+R/DL) 
Profile: 0x001B (DVD+R) 
Profile: 0x001A (DVD+RW) 
Profile: 0x0016 (DVD-R/DL layer jump recording) 
Profile: 0x0015 (DVD-R/DL sequential recording) 
Profile: 0x0014 (DVD-RW sequential recording) 
Profile: 0x0013 (DVD-RW restricted overwrite) 
Profile: 0x0012 (DVD-RAM) 
Profile: 0x0011 (DVD-R sequential recording) 
Profile: 0x0010 (DVD-ROM) 
Profile: 0x000A (CD-RW) (current)
Profile: 0x0009 (CD-R) 
Profile: 0x0008 (CD-ROM) 
Profile: 0x0002 (Removable disk) 
Supported CD-RW media types: 0F
Drive current speed: 10
Drive default speed: 10
Drive max speed    : 10
Selected speed     : 10
Using generic SCSI-3/mmc   CD-R/CD-RW driver (mmc_cdr).
Driver flags   : MMC-3 SWABAUDIO BURNFREE FORCESPEED 
Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R
Drive buf size : 996864 = 973 KB
Beginning DMA speed test. Set CDR_NODMATEST environment variable if device
communication breaks or freezes immediately after that.
FIFO size      : 12582912 = 12288 KB
Unsupported sector size 2352 for data on line 2 in '%s.cue'.

Нет, я, конечно, могу записать всё «правильно» из-под оффтопика.

Но есть ли способ решить задачу из Linux?

Всем здравствуйте.

Во многих СУБД есть такая штука – называется асинхронная репликация. Это значит, что есть второй экземпляр БД (обычно на отдельном сервере, нередко в отдельном ЦОДе), называемый (в зависимости от производителя) shadow либо, простите за неполиткорректность, slave.

И вот этот slave в реальном времени получает по сети от «мастера» все журналы транзакций и применяет их к своему собственному хранилищу (в начальный момент оба хранилища синхронизированы). В результате состояние slave всегда полностью повторяет состояние «мастера» либо по окончании COMMIT’а, либо с некоторой задержкой (зависит от типа СУБД и от настройки).

А теперь вопрос.

Я, конечно, слышал про RAID 1, mdadm и вот это вот всё.

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

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

koi10x16b.pcf:

Copyright (C) 1994 Aleksei Rudnev <alex@kiae.su>,
Portions Copyright (C) 1996-1997 by Andrey A. Chernov, Moscow, Russia.

Алексей Руднев из Курчатовского института – это один из создателей ОС ДЕМОС, советского варианта UNIX:

https://secretmag.ru/stories/absolyutnaya-partizanshina-istoriya-sozdaniya-rossiiskogo-interneta.htm

На фото 1988 года он крайний справа.

А Андрей Чернов – это «отец» кодировки KOI8-R.

P. S. Валерия Бардина тоже уже нет в живых.

Кто-нибудь знает, что с Алексеем Рудневым? Последнее интервью с ним датируется примерно 2004 годом.

За все долгие месяцы, пока действовало предупреждение BitBucket, никто так и не удосужился сконвертировать hg в git.

• http://www.xemacs.org/Develop/hgaccess.html
• https://bitbucket.org/xemacs

Всем здравствуйте.

Периодически ноутбук «кочует» между разными внешними мониторами с разным DPI (от 91 до 162).

Для всех прочих программ достаточно выполнить

xrandr --dpi ...

и изменить значение X-ресурса Xft.dpi.

Исключение составляет Emacs (неважно, с Lucid или GTK+-интерфейсом – оба ведут себя одинаково). Для того, чтобы шрифт в Emacs был сопоставим по размеру с тем же самым шрифтом в терминале (xterm, rxvt, konsole – неважно), приходится увеличивать размер с 12pt до 27pt:

(set-default-font
	"Courier New:size=27:antialias=false")

Из этого можно заключить, что либо размер Xft-шрифта Emacs воспринимает в пикселях, а не в пунктах, либо где-то внутри «зашито» разрешение в 72 DPI.

Проблема наблюдается в версиях 24, 25 и 26 (по меньшей мере).

Как лечить?

Всем здравствуйте.

В процессе использования GNU Autotools (предыстория) заметил, что иногда, в зависимости от проекта, файл компилируется командой

# Такой вариант используется в базовом amhello
gcc -c -o file.o file.c

а иногда

# Такой вариант используется, напр., в strace и gstreamer
gcc -c -o file.o `test -f file.c || echo $(srcdir)/`file.c

Причём VPATH-сборки корректно работают в обоих случаях – просто точный путь до файла вычисляется либо в стадии конфигурации (./configure), либо в стадии сборки (make).

В документации эта разница никак не описана.

Если копаться в истории, то видно, что второй вариант появился с коммитом dd16cf3641508379a977c37b25fbbae93358bc40 и стал опциональным (в зависимости от значения флага GENERIC) с коммитом 29ade8c79e328cb9f0ed0f132386b4a55027661c.

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

Кто-нибудь может пояснить?

Cast Harald

Всем здравствуйте.

Собственно, вопрос.

Я пока что могу назвать лишь 3 инструмента, умеющих указанное:

• SourceTrail,
• CLion,
• Visual Studio Code (через c_cpp_properties.json, очень криво).

Кто ещё?

Может быть, есть какие-л. модули расширения для Anjuta, QtCreator, Code::Blocks, KDevelop, Atom, или CodeLite?

Всем здравствуйте.

Нужно протестировать поведение WSL2 в гостевой Windows 10.

WSL2 работает через Hyper-V.

Hyper-V в гостевой ОС требует не только VT-x pass-through (это умеет VirtualBox 6.1+), но и SLAT (она же Intel EPT) pass-through, и в результате его хрен установишь. VirtualBox, насколько я понял, пока не умеет пробрасывать SLAT, по крайней мере, coreinfo сообщает следующее.

Мне тут камрады настойчиво рекомендуют VMware Player.

У кого-нибудь был с ним положительный опыт в контексте SLAT?

Всем здравствуйте.

Есть монитор, который держит до 76 Гц по вертикали, до 96 кГц по горизонтали, и до 205 МГц pixel clock.

И этот монитор, помимо «родного» 1920x1200, может также 1600x1200@75Гц:

  1600x1200 (0xa1) 202.500MHz +HSync +VSync
        h: width  1600 start 1664 end 1856 total 2160 skew    0 clock  93.75KHz
        v: height 1200 start 1201 end 1204 total 1250           clock  75.00Hz

Теперь я пытаюсь добавить режим 800x600 doublescan, эквивалентный указанному выше 1600x1200. Все режимы взяты отсюда.

xrandr --newmode "800x600d" 101.25 800 832 928 1080 600 600 602 625 DoubleScan +HSync +VSync
xrandr --addmode DP1 800x600d

Результирующий видеорежим в выводе xrandr я вижу:

  800x600d (0x1f7) 101.250MHz +HSync +VSync DoubleScan
        h: width   800 start  832 end  928 total 1080 skew    0 clock  93.75KHz
        v: height  600 start  600 end  602 total  625           clock  75.00Hz

После этого при попытке перейти в новый видеорежим я получаю ошибку:

$ xrandr --output DP1 --mode 800x600d
xrandr: cannot find mode 800x600d
$ xrandr --output DP1 --mode 0x1f7
xrandr: Configure crtc 0 failed

WTF?

Всем здравствуйте.

Возможно, мой вопрос больше подходит для форумов https://www.vogons.org/, но рискну сначала спросить здесь.

Допустим, есть современный монитор 1920x1200, и есть какая-л. древняя программа (скорее всего, игра), выполняющаяся в эмуляторе (PCem, dosbox, virtualbox или qemu) и имеющая фиксированное разрешение в 320x200, 640x480 или 800x600.

И хочется получить картинку типа «pixel-perfect», чтобы каждая точка исходного изображения отображалась в 4, 9, 16 или 25 точек растра монитора без какой-л. интерполяции (средствами монитора и/или видеокарты). Для 4k-монитора размер такого «олдскульного» пикселя может достигать 10x10.

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

Вопросы:

1. Лет 20 назад я слышал про т. наз. doublescan-режимы (напр., ModeLine "400x300" 28.1 400 412 444 508 300 304 306 327 +hsync +vsync doublescan). Вопрос: поддерживают ли их X11 и по сей день, или это уже анахронизм?

2. Почему никто не озаботился такими понятиями, как triplescan, quadruplescan и т. д.? Существует ли такое в природе?

3. Допустим, виртуальные 800x600 из фактических 1600x1200 (на мониторе 1920x1200) получить можно с помощью пресловутого doublescan, но вот можно ли получить виртуальные 640x480 из фактических 1280x960 таким образом, чтобы сверху и снизу было точно «отрезано» по горизонтальной полосе шириной в 120 точек (960+120+120=1200)? Формализуем ли такой видеорежим средствами X11 ModeLine?

4. Имеет ли какой-л. смысл при использовании современных мониторов полярность сигналов вертикальной и горизонтальной синхронизации (+HSync, -HSync, +VSync, -VSync)?

5. Какие инструменты посоветуете для тестирования/отладки нестандартных видеорежимов, кроме старого доброго xvidtune? Увы, xrandr, lxrandr и arandr, кажется, не годятся, потому как оперируют лишь тем, что зашито у монитора в EDID.

6. Что из технических статей на тему можно почитать?

Спасибо.

Всем здравствуйте.

Собственно, вопрос.

Есть ли у кого-нибудь успешный опыт проектирования дома, используя не какой-нибудь дорогущий ArchiCAD под оффтопик, а таки Linux и таки СПО?

Как минимум, хочется иметь «трёхмерный чертёж»,

• который можно «повертеть» со всех сторон,
• который можно «распилить» на проекции и экспортировать в DWG, дабы отдать прорабу, и
• на котором можно указать размеры (и измерить виртуальной линейкой расстояние между двумя произвольными точками).

Как максимум, хочется иметь возможность также и натянуть на всё это безобразие текстуры, чтобы внешний вид был ближе к реальному.

Возможно, программы «минимум» и «максимум» решаются разными инструментами (как выяснилось, есть люди, проектирующие дома в Blender’е – там с текстурами и освещением всё норм).

Я пока что успел посмотреть на LibreCAD (но он, кажется, умеет оперировать сугубо двумерными моделями) и на FreeCAD и Sweet Home 3D.

Последние два кажутся неплохими инструментами, и я пытаюсь понять, стоит ли инвестировать в их освоение своё время.

Всем здравствуйте.

Собственно, ${subj}.

Есть старая (5.0.1) виртуалка 2017 года. Пытаюсь обновить список пакетов:

$ sudo pkg update
Updating Avalon repository catalogue...
pkg: Repository Avalon load error: access repo file(/var/db/pkg/repo-Avalon.sqlite) failed: No such file or directory
pkg: http://mirror-master.dragonflybsd.org/dports/dragonfly:5.0:x86:64/LATEST/meta.txz: Not Found
repository Avalon has no meta file, using default settings
pkg: http://mirror-master.dragonflybsd.org/dports/dragonfly:5.0:x86:64/LATEST/packagesite.txz: Not Found
Unable to update repository Avalon
Error updating repositories!

И это верно, потому как по адресу http://mirror-master.dragonflybsd.org/dports/ лежат пакеты для версий с 5.2 по 5.10.

В /usr/local/etc/pkg/repos/df-latest.conf у меня запись вида:

Avalon: {
        url             : http://mirror-master.dragonflybsd.org/dports/${ABI}/LATEST,
        mirror_type     : NONE,
        signature_type  : NONE,
        pubkey          : NONE,
        fingerprints    : /usr/share/fingerprints,
        enabled         : yes 
}

– т. е. предполагается, что строчка dragonfly:5.2:x86:64 автоматически должна подставиться вместо ${ABI}.