Блог:Виталий Филиппов

Материал из YourcmcWiki
Перейти к: навигация, поиск

Технические вопросы и вменяемые заметки от меня, Виталика.

У меня, конечно, уже есть блог Ljuser.gifsimply_a_man.

2024-04-25 Как покрасить лаком стол!

Внезапное! Для тех, кто давно хотел, но стеснялся спросить, как!

Уроки, вынесенные из покраски лаком стола! Что делать, если хочется получить идеальное гладкое зеркально-глянцевое покрытие. В интернете такой инструкции ни фига не нашёл…

  1. Кисточка должна быть ЧИСТАЯ. На финишный слой — НОВАЯ. Благо цена ей 100 рублей. Ибо каждая пылинка на кисточке — это будущий дефект на лаке.
  2. Лак на водной основе (акриловый) НЕ использовать вообще — зеркального покрытия вы с ним НИКОГДА не получите. Почему? Потому что лак на водной основе — это не раствор, а дисперсия. То есть, это взвесь мелких НЕрастворимых в воде частичек лака (а не отдельных молекул, как в растворе). Когда вода высыхает, частички оседают на окрашиваемую поверхность, как-то склеиваются и создают какое-то покрытие, но очевидно, что оно не может получиться идеально гладким. Для глянцевой зеркальной поверхности нужно использовать либо — самое простое — алкидный лак, либо двухкомпонентный полиуретановый — по принципу действия он подобен эпоксидке, поэтому тоже даёт «настоящий» глянец. Да, алкидный лак воняет, ну и что! Зато идеальный результат получить гораздо легче! Ну и даже вкусно воняет, вообще-то ]:->
  3. Для алкидного лака нужна кисточка с натуральной щетиной, для водной основы или полиуретановых — с искусственной.
  4. Кисточку перед покраской промять и продрать рукой, чтобы все волосины, которые могут легко выпасть, выпали ДО покраски, а не в процессе.
  5. Яхтный лак FARBITEX PROFI WOOD разбавить на 30% уайт спиритом. Он тогда становится более текучим и легче прощает ошибки. Да, красьте именно яхтным лаком — идеал получить гораздо легче. Само собой, для получения глянцевой поверхности лак тоже должен быть глянцевым!
  6. Красить надо не таким уж и тонким слоем, лака на поверхности должно быть ощутимое количество! Чтобы было, чему натягиваться под действием поверхностного натяжения. Но, конечно, и слишком толстым слой быть не должен.
  7. Кисточку до почти сухого состояния в процессе покраски не вымазывать! Кисточка всегда должна быть мокрая. Как только с кисточки перестает «течь» лак на поверхность при движении, её надо мочить снова.
  8. На кисточку не надо давить, практически вообще! Если давить, из неё выдавливаются пузырьки. Если не давить, тоже лезут пузырьки, но только чуть-чуть и почти все сами лопаются.
  9. Красить равными мазками в одном направлении, вдоль волокон древесины, потом в идеале по каждой покрашенной полоске проходиться одним проходом по всей, чтобы выровнять покрытие.
  10. Сразу после покраски проверить на дефекты. В первую очередь — обязательно проверить на предмет отвалившихся от кисточки волосин! Аккуратно убрать их, поддев кисточкой же. Далее, где остались непрокрасы (почти сухие визуально места) — можно аккуратно докапать лака кисточкой, где пузырьки — можно их аккуратно полопать уголком кисточки. Хотя 99% пузырьков в норме лопаются сами, под действием поверхностного натяжения. Также обязательно проверить края, подтёки снять.
  11. Сушить надо ДОЛГО. Лак сохнет быстро, но окончательно застывает и превращается в «стекло» — очень долго (вплоть до месяца), особенно, если его слой толстый. Если в это время на него что-то поставить, это что-то в нём отпечатается. Возможно, есть какие-то способы ускорить процесс (обдувать горячим воздухом?), но это скорее актуально для условий покрасочной камеры, чем для домашних… Также, возможно, быстрее сохнут другие виды лака, например 2-х компонентный полиуретановый, но опять же х-з, надо тестировать.
  12. Как мыть кисточку: берем баночку, наливаем туда чуть-чуть растворителя, моем в нём кисточку, отжимаем об стенку банки и дальше вытираем кисточку насухо об картон, как бы крася его. Растворитель выливаем, наливаем чуть-чуть нового, повторяем. И так раза 4-5. Останавливаемся, когда растворитель уже почти не «пачкается» кисточкой. Итог — абсолютно чистая кисточка.
  13. Красить надо в 3 слоя, перед каждым слоем — обязательно шкурить! Особенно после первого слоя, так как после первой покраски «поднимается ворс» и дерево становится шершавее, чем было! Просто берём брусок и 320-ю наждачную бумагу, и шлифуем весь стол до гладкого матового состояния. Не волнуйтесь, после следующего слоя лак зальёт все микронеровности и стол опять станет зеркально-глянцевым!
  14. Каждый лак уникален! Любой новый лак в идеале сначала нужно запрототипировать — попробовать на ненужной детали. Особенно какой-нибудь «акриловый на водной основе», так как г#на среди них встречается гораздо больше.
  15. В идеале лак брать не прямо из основной банки, а наливать в промежуточную банку и красить из неё. Либо хотя бы использовать небольшие банки лака (по литру). Чтобы в лаке не накапливались пылинки с кисточки. Лайфхак: если вы разбавляете лак, это получится само собой!
  16. Перед покраской лак размешать палочкой, не взбалтывая, чтобы не порождать дополнительные пузырьки воздуха.

И да пребудет с тобой сила, Люк…

2024-04-25 Как покрасить лаком стол! 2024-04-25 00-36-57 image0.png

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. Надо немного уменьшить разделы на диске. Ну, я думаю — что тут сложного:

  1. Перезагружаемся в initramfs (в Debian опция ядра break=mount), прихватив с собой busybox, resize2fs и sfdisk (и нужные им библиотеки), ну или делаем извращение типа такого, но перезагрузиться проще
  2. Уменьшаем ФС — resize2fs /dev/md0 <SIZE>K
  3. Уменьшаем RAID — mdadm --grow --size=<SIZE> /dev/md0
  4. Останавливаем RAID — mdadm --stop /dev/md0
  5. Меняем размеры разделов 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 (он в килобайтах).
  6. Запускаем 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 - в нём он уже не такой весёлый и просто рассказывает, как всё сложно с этими вашими файловыми хранилищами.

« новейшие ‹ 20 более новых старейшие »