Насколько я знаю, никому (в т. ч. alt-x) завести это чудо не удавалось. У меня есть Solaris, есть дистрибутив MSIE – но он, зараза, не стартует. Не хватает чего-то.

Тем не менее, у кого-то получилось. Вижу эти кадры впервые:

https://www.youtube.com/watch?v=_AoyQeUzbEU

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

Есть виртуальная машина (VirtualBox), далее guest.

Хочу обеспечить guest’у выход в сеть (в т. ч. интернет), поместив его/её в отдельную подсеть и настроив host как маршрутизатор, минуя стандартные средства VirtualBox (Bridged, NAT, NAT Network).

Соот-но, на самой VM поднята только host-only network, этой сети на host’е соответствует интерфейс vboxnet0:

vboxnet0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.138.1  netmask 255.255.255.0  broadcast 192.168.138.255
        inet6 fe80::800:27ff:fe00:0  prefixlen 64  scopeid 0x20<link>
        ether 0a:00:27:00:00:00  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 11796  bytes 1496688 (1.4 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Host и guest прекрасно видят друг друга, guest использует в кач-ве шлюза по умолчанию 192.168.138.1 (интерфейс vboxnet0 host’а).

В /etc/networks дополнительно определена сеть vboxnet0:

vboxnet0       192.168.138.0

Далее, iptables на host’е настроены примерно так:

*nat

-A POSTROUTING -o vboxnet0 -j MASQUERADE

COMMIT


*filter

# Incoming traffic from virtual network interfaces
-A INPUT -i vboxnet0 -j ACCEPT

# Incoming traffic to virtual networks
-A INPUT --destination vboxnet0/24 -j ACCEPT

-A FORWARD -i eth0 -o vboxnet0 -j ACCEPT
-A FORWARD -i vboxnet0 -o eth0 -j ACCEPT
-A FORWARD -j DROP

-A OUTPUT -j ACCEPT

COMMIT

В результате виртуальная машина «видна» извне (из физической домашней сети 192.168.0.0/24, куда подключён host своим инрефейсом eth0), но вот сама она ничего, кроме host’а (192.168.138.1), не видит.

ЧЯДНТ?

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

После обновления ядра (Debian, 4-19 -> 4.19) начинают «течь» «иксы».

  Mem[||||||||||||||||||||||||||||||||||||||||||||||||||||||||16.5G/31.3G]   Uptime: 2 days, 22:45:57
  Swp[|                                                       6.50M/7.89G]   Tasks: 225; 1 running
  Bat[|||||||||||||||||||||||||||||||||||||||||||||||||||||||||96.0%(A/C)]   Load average: 0.79 0.96 0.99 

  PID USER      PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command
23175 root       20   0 15.2G 13.7G  195M S  3.3 43.8  2h05:43 Xorg -listen tcp -deferglyphs 16 +iglx -auth /home/bass/.Xauthority

«Свежие» значения M_SIZE (VIRT) и M_RESIDENT (RES) редко превышают 1.5 ГБ:

  Mem[|||||||||||||||||||||||||                    974M/31.3G]   Uptime: 2 days, 23:00:03
  Swp[|                                           6.50M/7.89G]   Tasks: 188; 1 running
  Bat[|||||||||||||||||||||||||||||||||||||||||||||96.0%(A/C)]   Load average: 0.37 0.50 0.73 

  PID USER      PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command
28315 root       20   0 1594M  165M  118M S  2.0  0.5  0:02.64 Xorg -listen tcp -deferglyphs 16 +iglx -auth /home/bass/.Xauthority

Затем, за сутки-двое «натекает» 16-32 ГБ. После этого только REISUB.

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

Куда копать?

Могут ли (в принципе) причиной утечки быть некие короткоживущие X-клиенты?

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

Ситуация такая.

Хочу залезть на http://deb.devuan.org/merged/dists/ (да, по HTTP). Браузер – Chromium и любые на его основе: Chrome, Opera, Vivaldi).

Движок Chromium, отличающийся излишней ретивостью и заботой о моей безопасности, зараза такая, автоматически добавляет в запрос

Upgrade-Insecure-Requests: 1

В результате web-сервер «поднимает» протокол до HTTPS (HTTP 307), отдавая мне https://deb.devuan.org/merged/dists/, и дальше бабушка надвое сказала:

• либо проблема с SSL-сертификатом (потому что сервер – зеркало, одно из многих, и принадлежит какой-то CDN, и его имя вовсе не deb.devuan.org),
• либо HTTP 404, потому что на 443-м порту отдаётся совсем другое содержимое, и вообще deb-пакеты обычно не передаются по HTTPS.

С одной стороны, это не совсем корректная настройка сервера.

С другой – мой слишком заботливый браузер, мать его, тупо не даёт мне просмотреть содержимое HTTP-ресурса. Mozilla и lynx, кстати, всё позволяют.

Вопрос: как это к х#рам отключить?

Потому что даже вписав к конфиг squid

request_header_access Upgrade-Insecure-Requests deny all

я всё равно не могу добиться желаемого результата (кроме «чистого» дебиановского Chromium’а).

Для остальных браузеров (Chrome, Opera, Vivaldi) даже блокировка доменов checkdomain.de и 1e100.net на уровне колхозного DNS-сервера ни к чему не приводит: похоже, что IP-адреса узлов домена 1e100.net жёстко прописаны в коде, и соединение с ними происходит вообще всегда (DNS over HTTPS отключён).

При этом, если смотреть HTTP-трафик wireshark’ом, то кажется, что с целевым сервером (deb.devuan.org) HTTP-соединения вообще не происходит: Google «знает», что этот сервер может отвечать по HTTPS, и сразу пытается соединить меня с 443-м портом.

Update: именно так. Если на стороне прокси-сервера вообще запретить HTTPS-трафик, то попытка открытия http://deb.devuan.org/merged/dists/ приводит к ошибке ERR_TUNNEL_CONNECTION_FAILED. И не потому, что пресловутый deb.devuan.org не ответил по HTTPS (до этого не дошло), а потому, что поделие Google (Opera, Vivaldi) не смогло позвонить домой в Google (Google, Google).

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

Дано: есть некий HTTPS-ресурс, про который известно, что он может отвечать, используя TLS 1.2. И есть правильно (до определённой степени) настроенные iptables:

# HTTP traffic blocked by the ISP                                                                                            
-A INPUT -p tcp --sport 80 -m string --string "Location: http://195.94.233.66?UrlRedir=http%3A%2F%2F" --algo bm -j DROP
-A INPUT -p tcp --sport 80 -m string --string "Location: http://stop.seven-sky.net" --algo bm -j DROP
-A INPUT -p tcp --sport 80 -m string --string "Location: http://95.167.13.50/?st" --algo bm -j DROP
-A INPUT -p tcp --sport 80 -m string --string "Location: http://blackhole.beeline.ru" --algo bm -j DROP

# HTTPS traffic blocked by the ISP
-A INPUT -p tcp --sport 443 --tcp-flags RST RST -j DROP

И вот теперь я пытаюсь зайти на этот самый ресурс по HTTPS:

$ wget --inet4-only --https-only --secure-protocol=TLSv1_2 -O - https://www.linkedin.com
--2021-10-06 14:33:28--  https://www.linkedin.com/
Resolving www.linkedin.com (www.linkedin.com)... 13.107.42.14
Connecting to www.linkedin.com (www.linkedin.com)|13.107.42.14|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 88377 (86K) [text/html]
Saving to: ‘STDOUT’

-                     0%[                    ]       0  --.-KB/s               <!DOCTYPE html>
<html lang=ru>
<head>
<link rel="stylesheet" type="text/css" href="/waltz/combined.css?20210926-1635">

<link rel="yandex-tableau-widget" href="/manifest.json" />
<meta name="referrer" content="always">

<title>LINUX.ORG.RU — Русская информация об ОС Linux</title>
...

Всё хорошо. А теперь попробуем то же самое с помощью curl:

$ curl -v --tlsv1.2 --tls-max 1.2 https://linkedin.com
* Expire in 0 ms for 6 (transfer 0x55acfeaa3f50)
...
* Expire in 50 ms for 1 (transfer 0x55acfeaa3f50)
*   Trying 13.107.42.14...
* TCP_NODELAY set
* Expire in 149971 ms for 3 (transfer 0x55acfeaa3f50)
* Expire in 200 ms for 4 (transfer 0x55acfeaa3f50)
* Connected to linkedin.com (13.107.42.14) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* Operation timed out after 300179 milliseconds with 0 out of 0 bytes received
* Closing connection 0
curl: (28) Operation timed out after 300179 milliseconds with 0 out of 0 bytes received

И тишина. И, что характерно, причина отнюдь не в User-Agent, потому что curl -A 'Wget/1.20.1 (linux-gnu)' -v --tlsv1.2 --tls-max 1.2 https://www.linkedin.com тоже не получает ответа.

Совершенно аналогичным образом, lynx и elinks как раз работают, а w3m, links и обычные браузеры как раз нет.

В чём разница?

Update: openssl s_client -connect www.linkedin.com:443 лишь устанавливает TCP-соединение, и не более того, так что отладочной информации, увы, нет.

Update 2: призываю всех проголосовать за Issue 908132: FR: Support for Encrypted SNI (ESNI).

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

Взгляните на автора сообщения – не правда ли, мир тесен?

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

На NFS-сервере есть правильно настроенный NIS и вот такие (идентичные в урезанном варианте) определения сетевых групп (в /etc/netgroup):

trusted (proxima,bass,) (proxima-eth0,bass,)
proxima (proxima,bass,) (proxima-eth0,bass,)

И вот так выглядит /etc/exports:

/export/backup0 @trusted(mp,rw,sync,subtree_check,pnfs)
/export/backup1 @proxima(mp,rw,sync,subtree_check,pnfs)

И вот загвоздка в том, что NFS-клиенту proxima один из сетевых ресурсов (/export/backup0) доступен, а второй нет.

Возникло внезапно. До сих пор всё долгие месяцы работало как часы.

WTF?

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

Хочу обновить память в ноутбуке (Core i7-7700HQ). Сейчас установлена одна «планка», работающая на частоте 2400 МГц, и, похоже, это максимально возможная частота для моего контроллера памяти (DDR4-2400). dmidecode не выдаёт ничего интересного, кроме значения лимита в 32 ГБ:

# dmidecode --type 16
# dmidecode 3.2
Getting SMBIOS data from sysfs.
SMBIOS 3.0.0 present.

Handle 0x0024, DMI type 16, 23 bytes
Physical Memory Array
        Location: System Board Or Motherboard
        Use: System Memory
        Error Correction Type: None
        Maximum Capacity: 32 GB
        Error Information Handle: No Error
        Number Of Devices: 2

Вопрос.

Можно ли воткнуть в ноутбук память, номинально рассчитанную на работу на частоте в 2666 или 3200 МГц?

Не будет ли проблем с совместимостью?

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

Собственно, есть такой контроллер: Silicon Image 3114. Он вставляется в PCI-шину, поддерживает до 4-х SATA-дисков, может работать в режиме IDE-совместимости и потому идеален для миграции старого железа с уходящих в небытие IDE HDD-дисков.

Например, на него можно установить голый DOS (и загрузиться), не говоря уже о том, что любой Linux моложе 2004 года становится на эту железку просто на «ура».

Я решил перенести старый восьмой «Солярис» с IDE-диска. Сделал всё, как рекомендуют советчики в сети:

1. Добавил в базу устройств, используемую Solaris Configuration Assistant (/boot/solaris/devicedb/master):

   pci1095,3114 pci-ide msd pci ata.bef "Silicon Image 3114 SATA Controller"
   

   Пробовал также вместо pci-ide pci1095,3114:

   pci1095,3114 pci1095,3114 msd pci ata.bef "Silicon Image 3114 SATA Controller"
   

2. В /etc/driver_aliases явно сказал, что устройство pci1095,3114 – это ATA-контроллер:

   ata "pci1095,3114"
   

3. Перезагрузил систему (touch /reconfigure; reboot -- -r).

В результате Configuration Assistant таки находит устройство, котороя я заботливо вписал ему в базу (снимок), но загружаться предлагает только со старого IDE-диска (снимок).

После загрузки самого Solaris утилиты format и fdisk «видят» только исходный IDE-диск (что подтверждается файлами устройств в /devices), а prtconf -pv выводит следующее:

        Node 0x190798
            66mhz-capable:  
            assigned-addresses:  81005810.00000000.0000d800.00000000.00000008.81005814.00000000.0000dc00.00000000.00000004.81005818.00000000.0000e000.00000000.00000008.8100581c.00000000.0000e400.00000000.00000004.81005820.00000000.0000e80
0.00000000.00000010.82005824.00000000.df000000.00000000.00000400.82005830.00000000.00000000.00000000.00080000
            class-code:  00010600
            compatible:  31696370.2c353930.34313133.69637000.35393031.3131332c.63700034.39303169.31332c35.70003431.6c636963.2c737361.36303130.00003030
            device-id:  00003114
            devsel-speed:  00000001
            fast-back-to-back:  
            interrupts:  00000001
            max-latency:  00000000
            min-grant:  00000000
            model:  'PCI: 1095,3114 - Silicon Image 3114 SATA Controller'
            name:  'pci1095,3114'
            power-consumption:  00000001.00000001
            reg:  00005800.00000000.00000000.00000000.00000000.01005810.00000000.00000000.00000000.00000008.01005814.00000000.00000000.00000000.00000004.01005818.00000000.00000000.00000000.00000008.0100581c.00000000.00000000.00000000.00000004.01005820.00000000.00000000.00000000.00000010.02005824.00000000.00000000.00000000.00000400.02005830.00000000.00000000.00000000.00080000
            revision-id:  00000002
            slot:  00000003
            subsystem-id:  00003114
            subsystem-vendor-id:  00001095
            unit-address:  'b'
            vendor-id:  00001095

Для сравнения, для встроенного IDE-контроллера выводится в т. ч. и список присоединённых к нему устройств:

        Node 0x18f5d8
            #address-cells:  00000001
            #size-cells:  00000000
            assigned-addresses:  81003910.00000000.000001f0.00000000.00000008.81003914.00000000.000003f6.00000000.00000001.81003918.00000000.00000170.00000000.00000008.8100391c.00000000.00000376.00000000.00000001.81003920.00000000.0000d000.00000000.00000010.81003924.00000000.00000000.00000000.00000000
            boot-interface:  00000013.00000000.00000000.00000010
            class-code:  0001018a
            compatible: 'pci-ide' + 'pci1106,571' + 'pciclass,01018a'
            device-id:  00000571
            device_type:  'pci-ide'
            devsel-speed:  00000001
            fast-back-to-back:  
            max-latency:  00000000
            min-grant:  00000000
            model:  'PCI: 1106,571 - Bus Mastering IDE controller'
            name:  'pci-ide'
            power-consumption:  00000001.00000001
            reg:  00003900.00000000.00000000.00000000.00000000.81003910.00000000.000001f0.00000000.00000008.81003914.00000000.000003f6.00000000.00000001.81003918.00000000.00000170.00000000.00000008.8100391c.00000000.00000376.00000000.00000001.01003920.00000000.00000000.00000000.00000010.01003924.00000000.00000000.00000000.00000000
            revision-id:  00000010
            slot:  00000000
            unit-address:  '7,1'
            vendor-id:  00001106

            Node 0x18fb78
                name:  'ide'
                reg:  00000000
                unit-address:  '0'

            Node 0x18fc48
                name:  'ide'
                reg:  00000001
                unit-address:  '1'

Вопрос: был ли у кого-нибудь положительный опыт?

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

Внезапно, файлы, входящие в состав Solaris Configuration Assistant (на платформе x86), оказались исполняемыми файлами MS-DOS.

2 штуки *.exe и одна штука *.com (пруф).

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

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

Посоветуйте, пожалуйста, систему мониторинга, соответствующую след. набору критериев:

1. Наличие пакетов под Debian. Собирать вручную и самостоятельно поддерживать уже надоело.
2. Распределённая архитектура (с возможностью либо устанавливать на наблюдаемую машину агента, либо, лучше, заходить по SSH по ключу и захватывать вывод произвольной команды). Ибо хочу наблюдать 4 машины и консолидировать данные.
3. Хранение истории метрик (желательно, в базе – MySQL или PostgreSQL).
4. Наличие Web-интерфейса для наблюдения метрик.
5. Наличие Web-интерфейса для настройки (это то, чего лишены Nagios и Icinga).
6. Умение мониторить SMART-атрибуты дисков без ужимок, прыжков, необходимости запускать процесс от имени root и вручную описывать наблюдаемую сущность. Вот это ключевое, потому что XXI век на дворе, а я только что убил полчаса на настройку /usr/lib/nagios/plugins/check_ide_smart – и ловлю себя на мысли, что проще с нуля приготовить MRTG, чем иметь дело с костылями под названием Nagios и его форками.

У кого есть опыт работы с OpenNMS, Zabbix, MRTG, PRTG, Cacti – да хоть чёртом в ступе – поделитесь, пожалуйста.

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

Недавно по рекомендации какого-то другого пакета установил пакет 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?