В субботу был запланирован пешкодрапинг в окрестностях Владивостока, в целях самоизоляции и ограничения социальных контактов посредством транспортировки своей тушки в лес, подальше от этого самого социума и неблагополучной эпидемиологической обстановки в городе. Кроме того, в планах стояла задача государственной важности в части борьбы с треклятым вирусом, путём проведения опытов над людьми (Женевская конвенция? Не, не слышал!) в части стимуляции иммунной системы нечеловеческими (даже живодёрскими) методами, а именно:
- насильственным вдыханием свежего воздуха;
- непомерными нагрузками на двигательный аппарат, сердечно-сосудистую и дыхательные системы;
- стимуляции и манипуляции психикой при помощи созерцания жутких картин живописных видов, буйства дикой природы.
Программа экспериментов открыта и допускается к расширению в полевых условиях.
Число. Подпись.
Изучал
https://github.com/Xilinx/linux-xlnx/blob/xlnx_rebase_v4.19/sound/soc/xilinx/xlnx_pl_snd_card.c
Конкретно функцию xlnx_snd_probe() и не мог понять… Как в pdev->dev.platform_data оказываются нужные ноды, в нужной последовательности (сначала PLAYBACK, потом CAPTURE), причём, если PLAYBACK нет, то там будет NULL.
Так как у драйвера нет of_match_table, то он:
- сам не загрузится (это так на практике) и
- что бы
xlnx_snd_probe() что-то нашла, через него нужно пропустить ВСЕ platform_device… но не всех же платформенных устройств в platform_data вообще именно этот тип данных будет!
Второе оказывается не так. Это “виртуальный” драйвер, а другой,
реальный для этого устройства, вызовом функции
platform_device_register_resndata() собственно создаёт platform_device, и в качестве второго аргумента оно принимает имя, по которому будет отфильтровываться, какому драйверу оно может быть передано. В данном случае “xlnx_snd_card”. И этот же вызов регистрирует pdev->dev.platform_data, в нужном для целевого драйвера виде.
А уже матчинг подходящего платформенного драйвера для вновь созданного платформенного устройства будет происходить здесь:
platform_match(). В данном случае - по имени устройства и по имени драйвера.
Тяжело идёт.
PS разные верии ядра роли не играют.
Суть проблемы, если коротко, в том, что подключая внешний монитор к ноутбуку в том случае, если он логически расширяет экран влево (находится левее основного экрана), то все открытые окна с экрана ноутбука перемещается на вновь подключенный экран.
Вообще, проблема актуальна не только для ноутбука, но частое подключение и отключение мониторов более присуще именно ноутбукам.
Решения проблемы не существует на данный момент. Ну… или я его не нашёл. Но буквально сегодня разыскал занимательный хак, как вернуть окна, если они прыгнули на левый (в прямом и переносном смысле) монитор:
Под катом сохраню копию, на всякий случай. Вообще, как грубое решение в лоб работает. Повесил на горячую клавишу Super+P.
Так получилось, что поймали акционные билеты до Петропавловска, на троих человек - около 22 тыр. Глядя на цену сразу мысль - надо брать!
Ниже небольшой фото-видео-отчёт с выходных на Камчатке. Для тех кого волнует трафик: осторожно, много тяжёлых фото! (я пока не нашёл адекватного варианта хостинга фотографий).
Все фото можно посмотреть в
галерее на Google Photo.
В один прекрасный момент, на ровном месте перестал работать mDNS и перестали резолвится хосты в зоне .local.
При этом демон Avahi был запущен, сервис systemd-resolved остановлен и в /etc/nsswitch.conf всё в порядке (присутствуют mdns4_minimal и mdns4, в общем, всё как в
ArchWiki).
Более того, вызов:
avahi-resolve -n 35002201.local
завершается успешно и возвращает адрес хоста.
Исследование привело к команде getent. Вызов:
getent hosts 35002201.local
выдал пустой результат. Хмм… как говорит документация, эта утилита точно работает через NSS.
Что делает пытливый ум линуксоида в таком случае? Правильно! Запускает команду через strace (я убрал лишний вывод, оставил только суть):
$ LANG=C strace -f getent hosts 35002201.local
execve("/usr/bin/getent", ["getent", "hosts", "35002201.local"], 0x7ffef387b638 /* 98 vars */) = 0
brk(NULL) = 0x5618ad268000
...
openat(AT_FDCWD, "/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=372, ...}) = 0
read(3, "# Name Service Switch configurat"..., 4096) = 372
read(3, "", 4096) = 0
close(3) = 0
...
openat(AT_FDCWD, "/usr/lib/libnss_mdns4_minimal.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 \20\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=18104, ...}) = 0
mmap(NULL, 20496, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f2bef77a000
mmap(0x7f2bef77b000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0x7f2bef77b000
mmap(0x7f2bef77d000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7f2bef77d000
mmap(0x7f2bef77e000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7f2bef77e000
close(3) = 0
...
openat(AT_FDCWD, "/etc/mdns.allow", O_RDONLY) = -1 ENOENT (No such file or directory)
...
exit_group(2) = ?
+++ exited with 2 +++
Хмм… А что это за файл /etc/mdns.allow, который во моей системе отсутствует?
Читаем и видим, что рекомендованная конфигурация - это отсутствие этого файла. Всё как у меня. Тогда, выполняется некоторая эвристика:
- Если запрос не заканчивается на
.local. или .local, он отклоняется
- Если в запросе есть точка (появяляется домент третьего уровня, например
foo.bar.local), то он тоже отклоняется
- Если системный unicast DNS (если проще: обычный DNS, работающий через 53 порт), указанный в
/etc/resolv.conf отдаёт SOA запись для local, запрос тоже отклоняется. Иными словами, запрос отклоняется, если запрос host -t SOA local верунл что-то отличное от Host local not found: 3(NXDOMAIN).
Хм, а вот третий пункт уже интересней. Вводим команду и видим:
$ host -t SOA local
local has SOA record ns1.inetvl.ru. support.inetvl.ru. 2017062801 28800 3600 1209600 86400
Оппа… Создаём файл /etc/mdns.allow со следующим содержимым:
И пробуем:
$ getent hosts 35002201.local
192.168.101.2 35002201.local
$ ping 35002201.local
PING 35002201.local (192.168.101.2) 56(84) bytes of data.
64 bytes from 35002201.local (192.168.101.2): icmp_seq=1 ttl=64 time=0.216 ms
64 bytes from 35002201.local (192.168.101.2): icmp_seq=2 ttl=64 time=0.271 ms
64 bytes from 35002201.local (192.168.101.2): icmp_seq=3 ttl=64 time=0.247 ms
^C
--- 35002201.local ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2029ms
rtt min/avg/max/mdev = 0.216/0.244/0.271/0.022 ms
Ура!
Выводы
Только два:
- При обновлении системы убрали дефолтный
/etc/mdns.allow. Но пакеты, где бы он мог находиться в последнее время не обновлялись.
- Изменились настройки сети провайдера
Собственно, скорее всего пункт 2.
Небольшой хинт:
Если в двух словах:
- делаем альбом и генерируем ссылку на него
- открываем её из другого браузера, где вы не залогинены. Можно в режиме инкогнито - тоже пойдёт.
- копируем ссылку и пользуемся
В конце ссылки есть “=w1236-h825” - это размер. Можно скорректировать под свои нужды. Если заменить на “=d” - скачаем оригинальную картинку (оригинальный размер).
Посмотрим, как работать будет :)
UPD: проблема в том, что при вставке большого числа изображений на страницу, не все будут открываться. Гугл будет ругаться на слишком частые обращения.
UPD: ну и небольшие дополнительные утилиты:
Немного фотографий:
Просто немного фотографий:
Небольшой хинт по настройке автодополнения адресов из адресной книги LDAP в Thunderbird:
Если коротко, в расширенных настройках создать строковое свойство:
ldap_2.servers.[ADDRESSBOOK].autoComplete.filterTemplate
Где [ADDRESSBOOK] - индивидуально для каждой книги.
со значением примерно такого вида:
(|(mozillaNickname=%v*)(cn=%v*)(sn=%v*)(mail=%v*)(displayName=%v*))
Проблема:
- Этот фильтр не работает в адресной книге
- Фильтр вообще не работает в диалоге приглашения в Календаре
- Если что-то начинается со
*, то нужно вводить как \*
Более подробно: не получается слинковать только при указании свойства caps у appsink или вставки между
videoconvert и
appsink фильтра
capsfilter с нужным форматом. Но об этом подробнее под катом.
Кросс-компиляция в Meson достаточно проста. Выполняется, как и в CMake при помощи вспомогательного файла:
[host_machine]
system = 'linux'
cpu_family = 'aarch64'
cpu = 'aarch64'
endian = 'little'
[binaries]
c = 'aarch64-linux-gnu-gcc'
cpp = 'aarch64-linux-gnu-g++'
#ld = 'gold'
ar = 'aarch64-linux-gnu-ar'
strip = 'aarch64-linux-gnu-strip'
pkgconfig = 'pkg-config'
#exe_wrapper = 'wine' # A command used to run generated executables.
[properties]
c_args = ['-DCROSS=1', '-DSOMETHING=3']
c_link_args = ['-some_link_arg']
sys_root = '/some/path'
Сохраняем его под именем cross-build.ini и передаём meson:
mkdir build
cd build
meson --cross-file ../cross-build.ini ..
Стоит отметить, что meson ОЧЕНЬ чувствителен к значениям переменных типа CC ,CXX и LD. Он рассчитывает, что если они установлены, то они отсылают к компилятору, который генерирует код для билд-машины, иными словами - нативный код. Это актуально для среды LTIB, которая настраивает окружение таким образом, что эти переменные окружения ссылаются на кросс-компилятор. Для случая autotools и большинства случаев использования CMake - это нормально. А вот Meson может сломаться.
Ещё одной особенностью является задание линкёра - ld = xxx. Он не задаёт конкретный бинарник, а отсылает к типу: gold (бинарник ld.gold или аналогичный), bsf (ld.bsf или аналогичный). Я задал его некорректно изначально, и только запуск Meson под strace позволил выяснить причину его недовольства.
Небольшое введение.
Есть два поведения для большого количества вкладок:
-
Путь Google Chrome и производных: максимально сжимаем вкладки (правда потом они не отображаются и приходится неочевидным способом прокручивать колесиком мыши или горячими клавишами):
-
Путь Firefox: заполнять вкладками всё пространство, как будет занято, начинать их сжимать, если размер достигнут какого-то минимального значения, включать полосу прокрутки плюс добавляется выпадающий список:
Моё мнение, что прокрутка стимулирует создавать ещё больше вкладок, а так как с моей личной организованностью в этом плане дела обстоят не очень хорошо, то мне нужен внешний стимул, что бы заняться чисткой открытых страниц. Отсутствие визуального различия во вкладках (сильно налеплены) - хороший стимул в этом.
Корабль [космический] такое место, где любая потерянная вещь
рано или поздно находится. Но это обычно не радует.
–
Шумил Павел,
“Три, четыре, пять, я иду искать”, цикл
Окно контакта
PS а порекомендуйте годной космофантастики?
Буквально сегодня состоялся разговор по поводу того, что на
GitLab Pages нет возможности автоматически обновлять сертификаты
Let’s Encrypt (которые протухают каждые 90 дней) и что данная возможность есть на
GitHub Pages.
Кроме того, сегодня как раз подошла череда обновления сертификата, заодно что-то меня потянуло поглядеть статью в документации GitLab по настройке интеграции с Let’s Encrypt:
Let’s Encrypt for GitLab Pages
И что же я там вижу:
Let’s Encrypt for GitLab Pages (manual process, deprecated)
Warning: This method is still valid but was deprecated in favor of the
Let’s Encrypt integration introduced in GitLab 12.1.
Воу! С радостным предчувствием иду по указанной ссылке и таки да, они завезли автообновление сертификатов!
Но если интересно, как это было сделано вручную, добро пожаловать под кат.
Очень полезный ресурс от Андрея Пономаренко (
тыц,
тыц) как для разработчиков библиотек, так и для маинтейнеров разного рода софта. Позволяет мониторить изменения в
API/ABI интерфейсах библиотек:
Вообще функционал ресурса достаточно богат и интересен:
Все доступные инструменты можно глянуть на странице
Reports.
Инструменты, используемые для анализа можно изучить на странице
Open Source. При помощи оных вполне можно организовать мониторинг изменений для вашего проекта или библиотеки.
