Блог:Виталий Филиппов
Технические вопросы и вменяемые заметки от меня, Виталика.
У меня, конечно, уже есть блог 
simply_a_man.
2024-04-25 Как покрасить лаком стол!
Внезапное! Для тех, кто давно хотел, но стеснялся спросить, как!
Уроки, вынесенные из покраски лаком стола! Что делать, если хочется получить идеальное гладкое зеркально-глянцевое покрытие. В интернете такой инструкции ни фига не нашёл…
- Кисточка должна быть ЧИСТАЯ. На финишный слой — НОВАЯ. Благо цена ей 100 рублей. Ибо каждая пылинка на кисточке — это будущий дефект на лаке.
- Лак на водной основе (акриловый) НЕ использовать вообще — зеркального покрытия вы с ним НИКОГДА не получите. Почему? Потому что лак на водной основе — это не раствор, а дисперсия. То есть, это взвесь мелких НЕрастворимых в воде частичек лака (а не отдельных молекул, как в растворе). Когда вода высыхает, частички оседают на окрашиваемую поверхность, как-то склеиваются и создают какое-то покрытие, но очевидно, что оно не может получиться идеально гладким. Для глянцевой зеркальной поверхности нужно использовать либо — самое простое — алкидный лак, либо двухкомпонентный полиуретановый — по принципу действия он подобен эпоксидке, поэтому тоже даёт «настоящий» глянец. Да, алкидный лак воняет, ну и что! Зато идеальный результат получить гораздо легче! Ну и даже вкусно воняет, вообще-то ]:->
- Для алкидного лака нужна кисточка с натуральной щетиной, для водной основы или полиуретановых — с искусственной.
- Кисточку перед покраской промять и продрать рукой, чтобы все волосины, которые могут легко выпасть, выпали ДО покраски, а не в процессе.
- Яхтный лак FARBITEX PROFI WOOD разбавить на 30% уайт спиритом. Он тогда становится более текучим и легче прощает ошибки. Да, красьте именно яхтным лаком — идеал получить гораздо легче. Само собой, для получения глянцевой поверхности лак тоже должен быть глянцевым!
- Красить надо не таким уж и тонким слоем, лака на поверхности должно быть ощутимое количество! Чтобы было, чему натягиваться под действием поверхностного натяжения. Но, конечно, и слишком толстым слой быть не должен.
- Кисточку до почти сухого состояния в процессе покраски не вымазывать! Кисточка всегда должна быть мокрая. Как только с кисточки перестает «течь» лак на поверхность при движении, её надо мочить снова.
- На кисточку не надо давить, практически вообще! Если давить, из неё выдавливаются пузырьки. Если не давить, тоже лезут пузырьки, но только чуть-чуть и почти все сами лопаются.
- Красить равными мазками в одном направлении, вдоль волокон древесины, потом в идеале по каждой покрашенной полоске проходиться одним проходом по всей, чтобы выровнять покрытие.
- Сразу после покраски проверить на дефекты. В первую очередь — обязательно проверить на предмет отвалившихся от кисточки волосин! Аккуратно убрать их, поддев кисточкой же. Далее, где остались непрокрасы (почти сухие визуально места) — можно аккуратно докапать лака кисточкой, где пузырьки — можно их аккуратно полопать уголком кисточки. Хотя 99% пузырьков в норме лопаются сами, под действием поверхностного натяжения. Также обязательно проверить края, подтёки снять.
- Сушить надо ДОЛГО. Лак сохнет быстро, но окончательно застывает и превращается в «стекло» — очень долго (вплоть до месяца), особенно, если его слой толстый. Если в это время на него что-то поставить, это что-то в нём отпечатается. Возможно, есть какие-то способы ускорить процесс (обдувать горячим воздухом?), но это скорее актуально для условий покрасочной камеры, чем для домашних… Также, возможно, быстрее сохнут другие виды лака, например 2-х компонентный полиуретановый, но опять же х-з, надо тестировать.
- Как мыть кисточку: берем баночку, наливаем туда чуть-чуть растворителя, моем в нём кисточку, отжимаем об стенку банки и дальше вытираем кисточку насухо об картон, как бы крася его. Растворитель выливаем, наливаем чуть-чуть нового, повторяем. И так раза 4-5. Останавливаемся, когда растворитель уже почти не «пачкается» кисточкой. Итог — абсолютно чистая кисточка.
- Красить надо в 3 слоя, перед каждым слоем — обязательно шкурить! Особенно после первого слоя, так как после первой покраски «поднимается ворс» и дерево становится шершавее, чем было! Просто берём брусок и 320-ю наждачную бумагу, и шлифуем весь стол до гладкого матового состояния. Не волнуйтесь, после следующего слоя лак зальёт все микронеровности и стол опять станет зеркально-глянцевым!
- Каждый лак уникален! Любой новый лак в идеале сначала нужно запрототипировать — попробовать на ненужной детали. Особенно какой-нибудь «акриловый на водной основе», так как г#на среди них встречается гораздо больше.
- В идеале лак брать не прямо из основной банки, а наливать в промежуточную банку и красить из неё. Либо хотя бы использовать небольшие банки лака (по литру). Чтобы в лаке не накапливались пылинки с кисточки. Лайфхак: если вы разбавляете лак, это получится само собой!
- Перед покраской лак размешать палочкой, не взбалтывая, чтобы не порождать дополнительные пузырьки воздуха.
И да пребудет с тобой сила, Люк…
2024-01-22 Как чучуть переназначить клавиши на Xiaomi Mi Notebook
На Xiaomi Mi Notebook клавиатура отличная, почти идеальная.
Есть вертикальный ряд кнопок home/end/pageup/pagedown, ход клавиш приятный, стрелочки полноразмерные.
Единственное извращение - в углу клавиатуры стоит уникальная кнопка, которая ни за что не отвечает - по задумке ты на неё должен назначить что-то своё, Delete сдвинут влево, а Insert находится на Fn+F12. Ну и ряд вертикальный хочется home/pageup/pagedown/end, а не home/end/pageup/pagedown.
Но всё это очень легко поправимо. Прям в /etc/rc.local:
# remap del -> ins setkeycodes e053 110 # remap xiaomi key -> del setkeycodes e072 111 # remap home end pgup pgdown -> home pgup pgdown end setkeycodes e04f 104 setkeycodes e049 109 setkeycodes e051 107
И всё, каеф.
P.S: На ноутбуке Xiaomi Redmibook Pro 15 2023 в ядрах Linux как минимум 6.2-6.8 также присутствует баг драйвера Radeon, приводящий к белому экрану или бело-чёрным артефактам после выхода из полноэкранного режима (игры, фильма). Лечится легко: путём прописывания amdgpu.sg_display=0 в опции загрузки ядра.
2021-06-09 Blender, OpenCL и Radeon ProRender
Есть у меня такая традиция — раз примерно в год с блендером и каким-нибудь радеоном трахаться.
В этот раз меня, в принципе, ждал успех. Получилось, во-первых, завести Cycles на OpenCL с Radeon RX 5500M (Navi 14) под Linux-ом, а во-вторых, даже получить расчётные показатели производительности! Расчётные — это немного быстрее нивидии GTX 1660 Ti и примерно на уровне GTX 1080 (да, она быстрее 1660), именно так, как и заявляется про данный GPU.
Бонусом завёлся и Radeon ProRender, но на конкретном демо-файле толку от него оказалось мало.
Итак, что я сделал…
2020-08-22 Полноэкранная цветокоррекция, KWin и драйвер Intel Iris
Недавно на ноуте словил багов с Intel-овскими дровами, которые под Linux раньше были самые беспроблемные. Все полечил, хочу запротоколировать.
В общем, суть такая: я использую нетривиальный ноутбук Samsung, у дисплея которого очень упоротая цветопередача. В остальном ноутбук отличный, поэтому я попереживал, что цвета не очень и написал себе свой собственный цветокорректор для KDE — в виде эффекта для оконного менеджера KWin.
KWin вообще уже очень давно работает гораздо лучше Compiz-а и подобных, при этом умеет все те же самые эффекты. Как вспомню, как я прикручивал Compiz к Gnome 2 — о боже, какой это был глюкодром… А сейчас в KWin просто включаешь эффекты и всё — всё работает. Никаких тебе артефактов, никаких тебе падений.
Ну, собственно, KDE вообще на порядок лучше гнома. До выхода гномощели (Gnome 3 / Gnome Shell) они шли примерно ноздря в ноздрю и я переходил то на гном, то обратно на KDE, но гномощель отбросила гном назад лет на 20, поэтому теперь — только KDE.
В общем вот. Я использую собственный эффект для KDE, который делает полноэкранную ICC-цветокоррекцию через шейдер: https://github.com/vitalif/kwin
И вдруг на тебе! Обновляю систему, пересобираю свой плагин для KWin 5.17 (до этого был 5.14) и вместо эффектов весь экран в каких-то диких артефактах.
Чешу репу, лезу пробовать настраивать драйвер intel в Xorg. В общем все похождения описывать не буду — задолбаюсь — но прихожу к тому, что опция AccelMethod=UXA помогает, с ней эффект работает нормально. Успокаиваюсь.
Через некоторое время начинает проявляется ещё один баг — ИНОГДА подвисает отрисовка (картинка на экране). При этом можно переключиться в консоль (Ctrl-Alt-F1) и обычно даже переключиться обратно, и всё отлипает. Нахожу какой-то баг с GPU Lockup-ами, который кто-то обходил через опцию ядра i915.enable_psr=0, прописываю, подвисания уходят. Успокаиваюсь снова.
В итоге обнаруживается ещё более прикольная вещь — тормозит GTK. Если открыть любое GTK-приложение, например, Gimp, процесс Xorg начинает жрать 100 % CPU, а отрисовка дико тормозить. Особенно заметно это, если в Gimp сделать квадратное выделение, нагрузку на иксы создаёт ползущий пунктирчик выделения.
В общем, да — оказывается, GTK тормозит при AccelMethod=UXA. Выключаю AccelMethod=UXA, эффекты отваливаются обратно. Тогда решаю проверить под новым, тестовым, пользователем на том же ноутбуке — опа, обнаруживаю, что эффекты работают. Обнуляю свой конфиг KWin (kwinrc) и настраиваю эффект заново — опа, и под моим пользователем работает. Виновата была какая-то опция, оставшаяся от прошлых времён. Окончательно радуюсь — эффекты работают, GTK не тормозит.
Но не даёт покоя вопрос: а из-за чего вообще-то произошёл такой геморрой?
А оказалось всё просто. С обновлениями системы приехала Mesa 20, а в ней для интела включили по умолчанию новый драйвер iris_dri. Когда я это понял, конечно, сразу его отключил переменной окружения MESA_LOADER_DRIVER_OVERRIDE=i965. А отключил бы сразу — и всего вышеупомянутого бы не было :-).
В общем, вот такая ситуация. Iris всё ещё сыроват.
2020-08-14 mdadm shrink
Пипец, чуть с ума щас не сошёл. Вроде такая простая задача, а протрахался… :)
Дано: mdadm RAID1 (зеркало) из /dev/sda2 и /dev/sdb2, и это rootfs. Надо немного уменьшить разделы на диске. Ну, я думаю — что тут сложного:
- Перезагружаемся в initramfs (в Debian опция ядра break=mount), прихватив с собой busybox, resize2fs и sfdisk (и нужные им библиотеки), ну или делаем извращение типа такого, но перезагрузиться проще
- Уменьшаем ФС — resize2fs /dev/md0 <SIZE>K
- Уменьшаем RAID — mdadm --grow --size=<SIZE> /dev/md0
- Останавливаем RAID — mdadm --stop /dev/md0
- Меняем размеры разделов sfdisk-ом — sfdisk --dump /dev/sda > sda.txt; vi sda.txt; sfdisk /dev/sda < sda.txt; sfdisk /dev/sdb < sdb.txt — конечно, правильно их рассчитав по mdadm --examine /dev/sda сложением Data Offset + 2*Array Size (он в килобайтах).
- Запускаем RAID обратно — mdadm --assemble --scan
И вот на последнем этапе схема даёт сбой:
/ # mdadm --assemble --scan mdadm: failed to add /dev/sdb2 to /dev/md/0: Invalid argument mdadm: failed to add /dev/sda2 to /dev/md/0: Invalid argument mdadm: failed to RUN_ARRAY /dev/md/0: Invalid argument
Причём я априори в курсе, что старые версии суперблока mdadm хранятся в конце раздела и изменение раздела не переживают — но в данном случае версия суперблока изначально 1.2, так что этой проблемы быть не должно.
Разгадка: эта тварь хранит размер каждого устройства в его суперблоке, и отказывается запускаться, когда реальный размер не соответствует сохранённому. Но есть способ его обновить — для этого на последнем этапе надо просто сказать mdadm --assemble -U devicesize /dev/md0 /dev/sda2 /dev/sdb2.
2020-01-14 Про "эффективные" "надёжные" микросервисы
На хайлоад в этом году не ходил, но услышал от коллеги про доклад … про вот этот вот доклад (на хайлоаде был он же):
https://2019.jokerconf.com/2019/talks/4wj9og0tij3wpxe3ourovr/
Вкратце: выходит дядька и говорит, что вот, в типичной веб-архитектуре с БД, memcached и stateless приложением очень большие затраты на маршалинг и демаршалинг [дядя реальный олд, раз сериализация у него маршалинг — но на это забьём]. Конкретно, до 85 % времени на это дело якобы уходит.
Поэтому они взяли Кассандру, засунули её прямо в Java процесс с приложением, и общаются с ней локально. Типа она распределённая, поэтому всё остаётся отказоустойчиво — она синхронизируется с другими нодами. И типа поэтому всё хорошо.
И вот с чего я тут охреневаю — это с 85 % затрат на сериализацию. Ну треш же какой-то! Ладно, ява, ну и что — https://github.com/fabienrenaud/java-json-benchmark - вот бенч разных библиотек JSON для явы. Самая быстрая даёт ~800 тысяч разборов и ~1.5 млн кодирований по 1 КБ в секунду, да и банальный Jackson не сильно отстаёт: ~500к / ~1 м.
Оказывается, 85 % это ссылка на статью: https://research.google/pubs/pub48030/. Статья тоже кривая. Не объясняя, ЧТО они тестировали, они действительно приводят цифры в оверхед сериализации в 45 % CPU и 85 % передачи лишних данных по сети и на основании этого агитируют за написание stateful бэкенда.
Если присмотреться внимательнее, там, правда, есть пометка:
Finally, our experiments in Section 3 show that if only part of the record is needed (10 %), RInK stores incur both extra CPU (46 %) and network (85 %) costs
For example, consider anapplication that caches the address books for all online usersin aRInKstore: for each user, the address book is stored as asingle key-value pair. If a request arrives from Alice to readBob’s phone number from her address book, all of Alice’scontacts must be fetched and unmarshalled, even thoughonly a small portion of the data is needed.
Б**дь! Ну так не надо так писать, чтобы для чтения 1 номера телефона приложение читало всю адресную книгу!!!
А к дядьке этому у меня один вопрос — он сам вообще что-то сравнивал? Или как всегда — «потому что можем»?
Каждый раз немного удивляюсь от их микросервисо-джабба-страданий… они же ими балуются ещё с тех пор, когда их не называли микросервисами. И в страданиях изобретали сначала собственный java-сериализатор, потом собственный кэш, сначала борясь с gc, а потом забив и уйдя куда-то на разделяемую память. Вылысыпыдысты.
Ну ладно. «Ночью через лес», когда файловое хранилище на postgresql изобретал, тоже сначала бодрый был.
2019-02-06 Ночью через лес
Про доклад «Ночью через лес»… https://youtu.be/oMQLR-BhnJU
…по болоту на тандемном велосипеде с крыльями.
Ко мне тут (4.02.2019) однокурсник обратился с вопросом — типа он там щас работает в этой конторе. У них хранилище ФАЙЛОВ (30-50 тб, правда, в основном мелких) в Кассандре. Было то ли на 4 то ли на 8 серверах, диски в RAID-ах и поверх bcache.
Щас они этот кластер — внимание! — переместили в один сервер в докеры, оставив 16 дисков и 16 узлов (но убрав bcache), то есть теперь 16 кассандр в одном сервере (зачем? потому что так дешевле).
И вот короче встал вопрос: извне всего ~137 rps, объекты по <= 64 кб. 64кб*137 = всего где-то ~9 мбайт/с. Но при этом 16 дисков (HDD) загружены по самое не балуйся, на каждом чтение >= 100 мбайт/с. Вопрос: какогохуя?)))
Я его спросил — а на#уя в кассандре? — а он мне скинул ссылку на этот доклад — я открыл, начал смотреть и думаю — б#я! я же помню этого мужика!
И точно — он в 2012 году на highload рассказывал, как пи#дато файлы в postgres-е хранить: Highload-2012: Отчёт Виталия Филиппова#Спасение 6 млн файлов в условиях полного Хецнера / Даниил Подольский, Дмитрий Симонов (Setup.ru)
То есть типа сначала у них всё типа было просто в локальных ФС на двух серверах и синхронизировалось rsync-ом. Потом у них кончилось место на серверах, обход дерева директорий стал занимать очень много времени (8 часов), и они засунули файлы в postgresql с мастер-мастер репликацией.
Потом оказалось, что крупные файлы неудобно хранить просто в поле и они их засунули в блобы. А потом обнаружили, что блобы не попадают в репликацию! Ну и в целом, что всё это грузит постгрю. Тогда они вынули из postgresql всё, что было больше 64к и сунули в LeoFS. LeoFS — это такая попытка сделать Ceph, но очень хреновая.
Потом в leofs кончилось место, они попробовали добавить пару серверов… и leofs развалился на хрен. Они позвонили японцам-авторам, те их час послушали и сказали «простите, у нас кончилось время, до свидания».
Они с помощью видимо такой-то матери убрали добавленные сервера обратно — и оно опять работало, пока в leofs не кончилось место окончательно.
И тут… им пришла свежая мысль — засунуть это всё в aerospike. Засунули, на 8 серверов. И оно вроде опять заработало, да ещё и кластеризация автоматическая появилась. Про это был доклад уже в 2015 году.
Продолжение я знаю уже из вопроса однокурсника: Aerospike их, видимо, тоже не устроил и сейчас у них всё это уже в кассандре!
И вот этот дядя на Highload нам рассказывает, что Ceph, который под это идеален, они пробовали и им было медленно (да ещё и «ребаланс по каждому чиху, при котором кластер вообще нельзя эксплуатировать»)… Жопой чую — у них там и сеть была 1G, конечно, какой уж тут ребаланс…
И это всё на продакшне. Эпично. Там ещё гениальный вопрос в конце доклада есть — типа, а вот когда у вас кончилось место в 2 серверах — почему вы… просто не добавили ещё 2?))))))) — «а чо, так можно было?…»
Просто плотно проработав последние несколько лет с Ceph-ом слушать это мегаржачно! Это вот Ceph значит медленный, а кассандра, которая грузит все диски на 100 % — быстрая? И это у них ещё записи нет. Была бы запись, было бы примерно как с KVStore-ом, когда 80 % i/o занимал compaction (KVStore — это промежуточная попытка апгрейда хранилки в ceph между filestore и bluestore).
Бэкапы он тоже не делает — ну, типа, реплика же есть, да и откуда ещё 30 тб взять.
Третья серия — это второй доклад 2015 года — https://youtu.be/bOqSexPzSIE?t=1702 - в нём он уже не такой весёлый и просто рассказывает, как всё сложно с этими вашими файловыми хранилищами.
