Заметки

Года с 2008 я ленился обрабатывать накопленные raw-файлы, потому что от виндовой проги Canon для обработки у меня портится настроение и болят руки (а на Fuji я вообще не снимал равки, потому что там прога совершенно садистская), да и вообще у меня ни одного нормального компьютера с Виндовс давно нет, виртуальная машина отдельная мука сама по себе, а для Linux производители камер ничего не сделали (и Adobe тоже, насколько я знаю). И тут внезапно обнаружил, что уже есть вполне адекватный конвертер для Линукса: Darktable, причём он даже входит в репозиторий Убунту (sudo apt install darktable - и готово). А что ещё лучше, у него есть вариант для командной строки darktable-cli, которым можно одним махом перегнать целый каталог с raw-файлами в PNG или TIFF и просто свалить их в архив и выборочно (то что того стоит) редактировать уже привычным Гимпом. Уже проверил - результат после пары движений в Гимпе получается не хуже фирменного конвертера и намного лучше JPEG из камеры, по крайней мере для 40D, из которого у меня и лежит основная непроявленная масса. Для полного счастья не хватает только поддержки 16-битного вывода в darktable-cli в настоящий момент - если фотка сильно не попала по экспозиции то её всё-таки придётся обрабатывать самим Darktable. Сама прога успешно пишет в любой битности, так что, в принципе, можно просто гуёвым Darktable перегнать целый каталог в 16-битный TIFF - не совсем Linux-way, но пойдёт.

https://www.darktable.org/

Есть у меня виниловая вертушка Вега 106, и я почти не слушал её пару лет, потому что она немного гудела в колонки.
Предусилитель не виноват - у меня их два, один новый китаец, один от такой же Веги полностью перебранный, плюс ещё третий есть в самой вертушке, со всеми гудит.
Опытным путём выяснил, что проблема не в столе (не в моторе и не в неонке), не в наводке с других устройств.
Поэтому я решил, что дело либо в наводке с трансформатора, либо в плате коммутации.
Купил отдельный трансформатор, чтобы сделать внешний БП (не хочу вынимать родные, исторические потроха из этого аппарата), купил новые качественные кабели. Но никак руки не доходили сделать этот БП и новую проводку.
В итоге, решил под новый год всё же послушать пластинку, в процессе обнаружил что провода плохо контачат (звук то есть, то нет), начал их подтыкать и ррраз... гул пропал! А через минуту опять появился. И так несколько раз подряд, что-то шевелю - гул уходит, потом снова появляется... Целый час - поиск полуоборванного контакта или холодной пайки в разъёмах, подгибание штырьков, чистка спиртом и т.д. И всё помогает, но только на несколько минут!
Итог - взял напильник и нормально так зачистил контакты 50-летнего штеккера напильником, и всё заработало без гула.

Следующая история, стоит года два-три в углу портативная вертушка Волна 307С, у которой хорошо работает всё, кроме мотора, который должен пластинку крутить. Согласно интернетам, там обычно горит что-нибудь в диодно-фоторезисторных датчиках или транзисторы - я не очень умею такое чинить, поэтому меня всё ломало в неё лезть. После истории с Вегой посмотрел на неё снова... Протянул руку и разодрал штеккер кабеля, которым подключается стол! И что вы думаете, всё это время был оторван проводок в штеккере, потому что кто-то на заводе лет 40 назад не потрудился обжать кабель, заходящий в штеккер, фиксатором. Ремонта оказалось на 3 минуты. Правда, этому пациенту ещё нужно будет заменить конденсаторы и иглу, но это уже ерунда, накатанный процесс.

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

P.S. Продолжение истории с Вегой: гул вернулся, и на этот раз нашлась такая проблема (вторая?): у одного из RCA-штеккеров в переходнике разошлась запрессовка контакта-кольца (земли), в результате чего это колечко начало прокручиваться, а также контакт земли в канале стал "гулять". В стопицотый раз обругав производителей RCA-штеккеров, пропаял ему место соединения кольца и лапки-контакта, к которой паяется провод, и всё снова стало хорошо.

Современный C++ всё-таки странная штука.
Как было в девяностые? Когда-то я выучил основу BASIC, прочитав книжку за вечер. Потом Pascal, прочитав книжку день-два. C и самые необходимые основные функции библиотеки - тоже за пару дней (спасибо отличной книжке от K & R). На C++ перешёл, осилив книжку "От C к C++" за пару подходов. Delphi - зная Pascal и C++, просто сразу начал писать и разбираться по ходу дела.
Вчера я с помощью сначала всех интернетов, а потом нескольких вопросов к ChatGPT 4 (она тоже с первого раза правильно не подсказала), два часа сначала ваял такой фрагмент, а потом разбирался, что тут написано и почему именно так. И эта конструкция функционально ничего не делает, она просто замедляет компиляцию приложения и позволяет избежать копипасты и сэкономить букв (возможно, меньше, чем она сама длиной). В общем, я на освоение малополезной фичи потратил столько времени, сколько раньше было нужно на половину языка. И я даже не напишу второй раз то же самое с первой попытки без шпаргалки.

template<typename Func, typename Obj, typename Arg, typename = void>
struct is_callable_with_arg : std::false_type {};
template<typename Func, typename Obj, typename Arg>
struct is_callable_with_arg<Func, Obj, Arg, std::void_t<decltype((std::declval<Obj>().*std::declval<Func>())(std::declval<Arg>()))>> : std::true_type {};
void call_impl(VAR_TYPE arg, std::true_type) { (clz_->*sig_)(arg); }
void call_impl(VAR_TYPE, std::false_type) { (clz_->*sig_)(); }
...
call_impl(var_, std::integral_constant<bool, is_callable_with_arg<MEMBER, CLASS, VAR>::value>{});

Симптомы - с определённой периодичностью виртуальная машина съедает на несколько минут 100% от каждого выданного ей процессора (т.е. на 4 ядра - загрузка 400% и т.п.), при этом хост притормаживает, а виртуалка вообще неуправляема, т.к. даже движения мышки отрабатываются с огромной задержкой. В это время внутри виртуалки нет процессов, занимающих столько CPU. При этом, на хостах AMD такой проблемы нет. После долгих мучений, рабочий ответ, наконец, найден тут:

This actually is an IOMMU issue and the solution involves enabling it at the kernel command line. Enabling VT-d (the Intel IOMMU kernel driver) in the firmware isn't enough and tinkering with compaction_proactiveness and swappiness only constrain this behavior without addressing the underlying cause.
...
So, for GRUB, edit /etc/default/grub to add the above string to GRUB_CMDLINE_LINUX_DEFAULT, e.g.,

GRUB_CMDLINE_LINUX_DEFAULT="intel_iommu=on"

Save and close the file, then run:

# update-grub

Reboot to take effect.

https://unix.stackexchange.com/a/713470/415520

"Бойцовский клуб" - это "Малыш и Карлсон" для взрослых. Живите теперь с этим.