Все пользователи одной ОС, например винды, попав на мак (или линукс) отчаянно бросаются "осваивать" его, называя почему-то этим словом бесконечную затяжную попытку сделать всё "как привычно", то есть как на другой ОС. Потом пишут огромную статью на хабр о каждой мелочи которую смогли подпилить, подкрутить, подменить, немножко подогнуть и сделать "правильно". И страшно довольны и результатом, и статьёй, столько добра принесли в мир, такой ценный подробный гайд!..
Печальная правда такова, что всё это вода и наносное и особо никому не понадобится никогда... Либо вы через год вернётесь на свою винду, устав бесконечно бороться с тем что по вам "не так" на маке, либо врубитесь что к чему, просто станете пользоваться тем что предлагает мак на маке, потому что это удобно и логично, а на винде тем что предлагает винда, потому что это удобно и логично, и со стыдом и усмешкой будете вспоминать и посматривать на эту длинную простыню, ну уж не удалять же...
У нас есть новая отличная быстрая архитектура aarch64, и куча тулзов которые уже годы её поддерживают, позволяющие использовать её в любых задачах.
Но нет, давайте заколотим костылей по кругу, и запустим эмуляцию x86_64 потому что всё новое очень страшно...
Не надо так. Просто собирайте контейнеры под две архитектуры, это не сложно. Особенно с учётом того что сервера на aarch64 уже вполне себе распространённая вещь, они дешевле и зачастую быстрее.
Надо один раз настроить билдер, чтобы создавались контейнеры под обе архитектуры и multiarch манифест, и никто даже не догадается что у кого-то arm, а у кого-то intel.
увидел кучу макбуков, подумал «вот это дичь», прочитал про 1 айфон - 1 макбук, подумал что «дичь конечно, но теперь понятно почему». потом сразу подумал - а не пробовали виртуализировать macos и пробрасывать usb порты в виртуалки? macos легально запускать в виртуалке на другой макос (хардваре эппл), не пробовали поставить макмини помощнее, запустить на нем пяток виртуалок и пробросить в каждую 1 usb порт?
а в целом нереальный респект за очевидный «колхоз», но без снобизма объяснённый зачем так сделано и почему. нестандартные задачи требуют нестандартных решений!
И это всё так же не имеет смысла для домашнего стенда описанного в статье.
Не представляю что надо делать с кластером чтобы убить его мастер за 4 месяца.
У меня есть тестовый стенд с которым я что только не делал, и сертификаты на нём кончались, и неудачное обновление CNI выводило из строя всю сеть, но мастер это просто пара процессов и файлы в двух директориях на диске. Причём не так много. Пока эти файлы целые - ничего с мастером не случиться.
Все эти мануалы о том как надо бахнуть три мастера обязательно, а то развернуться ворота в ад это безусловно классно, если вы делаете кластер для сбербанка. Но для домашней лаборатории три виртуалки для задачи с которой справляется raspberrypi просто потому что так написано в документациях которые писали люди которые прочли другие документации - это чистый карго культ и шаманизм делания ради делания без понимания что вы делаете.
В статье говорится про тестовый кластер для экспериментов.
И давайте ещё раз, как high-available соотносится с мастерами? мастер это control-plane, если он выключится, high-availability данных не изменится, всё что в кластере запущено так и будет работать и отвечать. Пропадёт возможность управлять кластером, но это всё. На доступность данных это не повлияет.
если .ValueString это "[ var='B0' metric='Zombie' labels={} value=10.85 ]" то скорее всего все эти данные доступны либо как .Value.metric/.Value.value либо .Values.B0.metric/.Values.B0.value и так далее.
Как минимум в алертах это работает (там через $, как {{ $values.B0.value }})
Основная проблема новых алертов в графане не запутанность, а то что это абсолютно новая система, к которой если начать читать документацию, то дойти до раздела где будет описано то что тебе нужно почти нереально (а часто это будет вообще один абзац который можно запросто пропустить) и гугл ещё не набрал достаточное количество людей с такой же проблемой как у тебя. Раскопать что-то быстро чтобы узнать как это выписать практически невозможно сейчас.
по излишнему употреблению нелепого слова «сие» в текстах и комментариях можно всегда отличить человека который читает много всякой чуши претендующей на серьезность. да и сам такую пишет.
Если программист будет излагать свои мысли (и писать код) так, что надо учиться понимать что он имеет ввиду, я сильно скептически отношусь к тому что ему стоит писать критические статьи про других.
А вы точно не перепутали красивый код и рабочий? Потому что проблему которую вы тут так смачно описывали стопудово можно было бы решить бахнув пяток if'ов тут и там. Работало бы прям хорошо. Правда почему-то другие глядя на такое называют это legacy, да ещё и говорят так, как будто это что-то плохое...
Интересно что за люди пишут такие статьи вообще, у меня есть два варианта и оба крайние - это когда люди считают что если всё по PSR, отступы, стиль кодирования, DI, интерфейсы и наследование то такой код в принципе не содержит багов. И другой тип когда считают что если задача выполнена то продукт в принципе готов. Если код работает и проходит все тесты - это уже полный продакшн реди и в комментариях не нуждается.
да вы вполне правильно поняли, что эксперт в области безопасности это наверное максимально тот самый человек который может себе позволить запускать всё что угодно, приняв меры предосторожности которые он в силу своей профессии знает очень хорошо. а то и, просто вдумайтесь, обладает несложным, не находящимся в публичном доступе способом отследить или даже ограничить выход за пределы песочницы любого, в том числе северокорейского эксплоита. а, как вам такой встречный аргумент?
"эксплоитов выходящих из песочниц"? а не подскажете рабочий, а то мне надоели бесплатные тарифы на AWS, хотелось бы захватить весь сервер там выйдя из виртуалки, должно быть несложно вроде как вы описываете.
На arm декдоер видео это отдельный IP, отдельный блок в процессоре. Никакого отношения не имеет ни к видеокарте и ни к процессору. То есть в свой armv8 можно прицепить кусок одного производителя, или другого, как захочется. У rockchip этот блок называется Hantro, у Samsung - MFC, у Amlogic... блин вот взял и забыл. Ну короче не важно. Важно то, что практически для всех этих блоков нужен отдельный драйвер в ядре линукса, писать который страшная, древняя жопоболь. А потом этот драйвер ещё и должен быть корректно использован плеером, который будет в него пихать сжатые кадры, а из другого места читать распакованные. Все вендоры лабают жуткий кусок лапши для андроида который стыкуется с их древним проприетарным ядром и андроидским фреймворком для видео и перекрестившись считают на этом свою задачу выполненной. Единственная плата у которой более-менее поддержка декодирования видео работает - raspberry pi. Для их VideoCore есть драйвер в ядре и его более менее умеет использовать ffmpeg. Что уже делает его на голову продвинутей поддержки в линуксе любого другого кодека. Samsung-овский MFC был в ядре давно, но у него свой особенный интерфейс который с трудом понимает ffmpeg и чтобы его завести надо было писать прослойку для каждого плеера. Hantro от рокчипа в зачаточном состоянии, если вообще принят, а не до сих пор в виде патчей, для Amlogic Baylibre (которые просто энтузиасты которые пытаются сделать апстрим линукс работающим на процах Amlogic нормально) целый отдел создали чтобы написать драйвер который примут в апстрим. Более-менее ни шатко ни валко дело идёт, аж целый h264 вроде как работает. Возможно даже 4к. И вроде даже можно связать его с ffpmeg без особой магии.
Так вот. Для начала я сомневаюсь что Байкал вообще поставил какой-то IP для видео в процессор, зачем? И уж совсем сомнительно чтобы они написали достойный драйвер который стыкуется с ffmpeg который без труда смогут понять плееры видео. Если бы они это сделали, шум бы в чатиках которые занимаются видео на встроенных одноплатниках поднялся бы до небес.
Так что всё это скорее всего просто тупо исполняется на проце. И это настоящая печаль, потому что современный арм может h264, и даже 1080 будет видно, если прикрыть глаза и не смотреть на загрузку и температуру, но вот 4к это уже будет во-первых плохо, 24 кадра если сцена не сильно меняется, во-вторых загрузка уедет в небо сразу и прочно.
Меня одного смутило "Bare-metal" в названии и рассказ о том как запустить всё на виртуалках?..
Ещё конечно бы хотелось услышать обоснование аж трёх мастеров для тестового кластера, тогда как и продакшн справится с одним. Ведь вы же знаете что мастер не критичен для работы кластера, это control-plane. Им кластер управляется, то есть если мастера выключить, то всё мгновенно не исчезент в варпе, просто пропадёт возможность что-то менять и вообще доступ к API. но поды всё так же будут запущены и будут работать и отвечать? Знаете же да? Что в кластере с одним мастером если его перегрузить пока он перегружается особо ничего не произойдёт? Ну так зачем в тестовом кластере ТРИ мастера?
Наверное я каким-то другим алиэекспрессом пользуюсь, но на моём алиэкспрессе у продавцов появились склады в европе. При покупке мелкой электроники (типа одноплатников или всякой мелочевки) достаточно прокликать несколько продавцов и можно без проблем найти продавца с выбором склада отправки, с вариантами "из польши", "из италии", "из украины", "из германии". Те же цены, никакой пошлины, да ещё и доставка за неделю вместо месяца как раньше.
Открывал статью с предвкушением "ща как читну как всё бывает всрато и какие бывают сумашедшие люди! угорю с утреца"...
В итоге прочитал очень адекватную статью о том как люди задизайнили крайне адекватную систему которая кажется странным как раз фрикам от программирования которые считают что скобки не на новой строке в коде это повод отклонить код.
"Одна из небольших странностей «Минервы» заключается в том, что многое в ней использует принцип «главное — данные», а не «главное — код»" - вообще максимально здравая мысль. Проектируя системы достаточно долгое время так или иначе понимаешь что всё что ты делаешь это фильтр над данными которые ты имеешь, все эти слои прекрасно проходящего PSR-7 проверку кода - просто сложный фильтр, который преобразует массу данных которые у тебя есть в зрительные образы, ничего более.
Да и всё остальное - тоже максимально похожий на так любимый теми же цифровыми фашистами (те которые про важности места скобок в коде) моно-репозиторий концепт. Просто эволюционировавший ещё дальше: возьмём вообще всё что только можно, и данные, и код, и среду исполнения, всё в масштабе предприятия - и сунем в одно место где всё это будет доступно всем сразу.
Короче не вышло угореть. Разочарован. Полнейший адекват в статье. =(
Да, причём в ipv6 можно прокидывать айпишник используя роутеры с внутренними айпишниками по пути.
То есть можно дать устройству айпишник типа 2001:x:x:x:x:x:x:x и указать что default gateway fd00::1 какой-нибудь (роутер с wireguard которому не обазательно выдавать внешний адрес) и это совершенно нормальная ситуация. Это как дать устройству ipv4 212.1.1.1/32 и указать гейтом 192.168.1.1 (не получится), а в ipv6 работает.
Правда тут конечно придётся слега уже приколотить роутинг от и до этого айпишника через туннель. но всему же есть предел =D
У вас правильное направление мышления, но всё ещё закостенелое под "ipv4" типа "зачем выделять так много адресов небольшому сегменту?". В парадигме ipv6 имеет значение префикс, всё примерно до /64, все остальные /64 это локальный блок, который выделяют не глядя иногда даже и на одно устройство. Суть в том, что ipv6 адреса уже нереально запоминать, мало того некоторые устройства их рандомно меняют (это тоже часть стандарта направленная на безопасность). В ipv6 сети надо полагаться на DNS, без этого уже никак. И если полагаться на DNS уже всё равно сколько там у кого каких адресов.
В вашем случае если я верно понял описание, что можно было бы сделать - так это например сделать wireguard туннель поддерживающим и ipv6 и выдать внутри вашей сети дома внешние айпишники вход на которые на хостинге кому надо. так можно было бы добиться доступности снаружи по ipv6 без всяких проблем для устройств внутри, раз вы переживаете что для дома не выбить свой ipv4. с ipv6 без проблем.
В моём случае у меня умный дом на две квартиры и загородный дом, это три подсети. Всего в одном месте есть реальный ipv4 (повезло с провайдером) из двух других мест туда wireguard туннели, и внутри всё по ipv6. три сегмента ipv6 /64, общая внутренняя /48 сеть, из любого места видно любое устройство, и что самое главное с ipv6 - это реально просто работает. если с ipv4 мне бы пришлось точно знать где у кого какой адрес в каких подсетях, какие там адреса в туннелях и так далее, настраивать роутинг на всех трёх роутерах чтобы один видел оба, а с двух друхи было видно всё через центральный, с ipv6 достаточно было настроить адреса на трех роутерах, и все устройства внутри получили свои адреса и сразу увидели друг друга, то есть не пришлось заморачиваться со сложным роутингом (он как бы так и остался сложным, но с ipv6 это заработало без проблем, включая то что я описал выше - некоторые интерфейсы имет по три разных айпишника, и всегда правильно выбирают с какого адреса выплёвывать пакеты в зависимости от того куда они идут). Отлично работает локализация трафика, не важно где я со своим айпадом, выплёвывается трафик в интернет из локального мне роутера (в одном месте есть внешний ipv6), мой внутренний трафик до устройств ходит внутри сети, где надо и через два хопа).
Сложность из заморочек с роутингом сместилась в сторону грамотно настроить DNS, так чтобы всех было видно по именам.
её конечно довольно сложно понять чисто теоретически. можно читать статьи, можно пытаться прикинуть что к чему пытаясь провести параллели с тем как всё в твоей лично сети устроено и как бы это было с ipv6, но всё равно самый крупный толчок ты получаешь начав что-то делать.
когда у меня появился ipv6 адрес от провайдера это стало отправной точкой чтобы подумать "так, ну вот адрес как бы уже есть, может попытаться уже сделать что-то?". и всё оказалось довольно просто и понятно и действительно удобно.
что меня больше всего поражает, это то, о чём почему-то никто не пишет во всех этих огромных статьях, но что знакомо каждому сетевику который делал хоть сколько-нибудь сложные сети. это то, как протокол грамотно выбирает исходных адрес при установке связи. каждый, кто пытался настроить сеть, когда на интерфейсе есть глобальный адрес, пара локальных и ещё впн, поймёт о чём я. в ipv4 есть адрес интерфейса с которого он будет выплёвывать все пакеты, и, чтобы заставить его правильно выбрать исходный айпишник, надо понаколотить всяких правил, чтобы пакеты в какой-нибудь туннель уходили откуда надо. в ipv6 это всё работает из коробки само собой. у меня сейчас на интерфейсе глобальный адрес (аналог внешнего айпишника), локальный адрес (что-то среднее между 127.0.0.1 и 192.168.0.0 - адреса которые существуют только между соседями и роутером, и никогда не выходят за роутер) и два немаршрутизируемых адреса (аналог 192.168.0.0 - два впн-а), и всё это работает вообще без всяких дополнительных настроек без всяких проблем. куда бы я ни коннектился, мой исходящих айпишник всегда тот, от которого до цели ближе всего по маске. вот это прямо крутая фишка ради которой я перевёл все свои внутренние соединения на ipv6, это прямо реально делает жизнь легче.
плюс по мелочи типа SLAAC, это такая недо-DHCP технология, когда роутер может объявлять себя роутером, и устройства в сети буду автоматически подхватывать нужные адреса и цепляться к этому роутеру. в сочетании с пунктом выше это делает ipv6 сети прямо практически магически рабочими. достаточно настроить роутер в сети и любое косое кривое неадекватное устройство прицепится и будет работать как надо.
Мы так сделали в первой версии, оказалось что против ботов это не то чтобы супер эффективно, - боты зачастую заточены на решение капчи второй версии, причём делают это как-то через фермы с живыми людьми, то есть где-то живые люди решают капчи по публичным ключам с сайта, и производят коды решения. и в итоге скрипты просто игнорируют третью капчу и херачат сразу запросы к апи с решениями второй капчи (сразу с правильными ключами в параметрах). Я смотрю эти скрипты подвержены той же проблеме - достаточно передать им решение второй капчи и всё будет тип топ.
В итоге наша финальная версия имеет промежуточный стейдж - после того как бэк решает что третья капча так себе была решена, бэк возвращает запрос на рендер второй капчи с nonce и подписью nonce + дата + решение третьей капчи. и решение второй капчи принимается только если вместе с ним поставляется так же решение третьей плюс nonce плюс дата плюс подпись из ответа на третью. И если дата разъезжается минуты на две - машем ручкой. Так удалось логически прицепить не решивших третью капчу к решающим вторую и как показала практика это сильно затруднило жизнь всяким умельцам которые покупают на сайтах "решение второй капчи 1 доллар за 10000", потому что это уже просто так не заинтегрировать туда (хотя и можно конечно).
Конечно боты всё равно регистрируются, но теперь судя по запросам из логов это живые люди которые решают капчи в браузерах. Потому что запрашиваются целиком страницы со стилями и скриптами. Но хотя бы не бесконечный поток запросов прямо к api с корректными решенями второй капчи.
Да, я пересобирал на сервере где делал изначальные тестовые прогоны. Ну там вообще не только для этого ядро кастомное, так что было ок. Потом убедился что достаточно поменять iptables c iptables-legacy на iptables-nft через /etc/alternatives, и старые модули не подгружаются со временем от использования любого софта который у нас в продакшене, и дальше на серверах которые уже ставились с nft не парился. Я думаю можно в /etc/modprobe.d/blacklist.conf перечислить основные модули iptables-legacy:
bpfilter
iptable_filter
iptable_nat
iptable_mangle
и этого будет достаточно чтобы те кто попытаются дёрнуть за старый интерфейс обломились.
Windows по сравнению с MacOS
Все пользователи одной ОС, например винды, попав на мак (или линукс) отчаянно бросаются "осваивать" его, называя почему-то этим словом бесконечную затяжную попытку сделать всё "как привычно", то есть как на другой ОС. Потом пишут огромную статью на хабр о каждой мелочи которую смогли подпилить, подкрутить, подменить, немножко подогнуть и сделать "правильно". И страшно довольны и результатом, и статьёй, столько добра принесли в мир, такой ценный подробный гайд!..
Печальная правда такова, что всё это вода и наносное и особо никому не понадобится никогда... Либо вы через год вернётесь на свою винду, устав бесконечно бороться с тем что по вам "не так" на маке, либо врубитесь что к чему, просто станете пользоваться тем что предлагает мак на маке, потому что это удобно и логично, а на винде тем что предлагает винда, потому что это удобно и логично, и со стыдом и усмешкой будете вспоминать и посматривать на эту длинную простыню, ну уж не удалять же...
Подробный гайд по Docker на M1
У нас есть новая отличная быстрая архитектура aarch64, и куча тулзов которые уже годы её поддерживают, позволяющие использовать её в любых задачах.
Но нет, давайте заколотим костылей по кругу, и запустим эмуляцию x86_64 потому что всё новое очень страшно...
Не надо так. Просто собирайте контейнеры под две архитектуры, это не сложно. Особенно с учётом того что сервера на aarch64 уже вполне себе распространённая вещь, они дешевле и зачастую быстрее.
Надо один раз настроить билдер, чтобы создавались контейнеры под обе архитектуры и multiarch манифест, и никто даже не догадается что у кого-то arm, а у кого-то intel.
Колхоз. Большая история фермы устройств Яндекса
увидел кучу макбуков, подумал «вот это дичь», прочитал про 1 айфон - 1 макбук, подумал что «дичь конечно, но теперь понятно почему». потом сразу подумал - а не пробовали виртуализировать macos и пробрасывать usb порты в виртуалки? macos легально запускать в виртуалке на другой макос (хардваре эппл), не пробовали поставить макмини помощнее, запустить на нем пяток виртуалок и пробросить в каждую 1 usb порт?
а в целом нереальный респект за очевидный «колхоз», но без снобизма объяснённый зачем так сделано и почему. нестандартные задачи требуют нестандартных решений!
Bare-metal kubernetes-кластер на своём локальном компьютере
И это всё так же не имеет смысла для домашнего стенда описанного в статье.
Не представляю что надо делать с кластером чтобы убить его мастер за 4 месяца.
У меня есть тестовый стенд с которым я что только не делал, и сертификаты на нём кончались, и неудачное обновление CNI выводило из строя всю сеть, но мастер это просто пара процессов и файлы в двух директориях на диске. Причём не так много. Пока эти файлы целые - ничего с мастером не случиться.
Все эти мануалы о том как надо бахнуть три мастера обязательно, а то развернуться ворота в ад это безусловно классно, если вы делаете кластер для сбербанка. Но для домашней лаборатории три виртуалки для задачи с которой справляется raspberrypi просто потому что так написано в документациях которые писали люди которые прочли другие документации - это чистый карго культ и шаманизм делания ради делания без понимания что вы делаете.
Bare-metal kubernetes-кластер на своём локальном компьютере
В статье говорится про тестовый кластер для экспериментов.
И давайте ещё раз, как high-available соотносится с мастерами? мастер это control-plane, если он выключится, high-availability данных не изменится, всё что в кластере запущено так и будет работать и отвечать. Пропадёт возможность управлять кластером, но это всё. На доступность данных это не повлияет.
Делаем нотификации графаны снова читаемыми
если .ValueString это "[ var='B0' metric='Zombie' labels={} value=10.85 ]" то скорее всего все эти данные доступны либо как .Value.metric/.Value.value либо .Values.B0.metric/.Values.B0.value и так далее.
Как минимум в алертах это работает (там через $, как {{ $values.B0.value }})
Основная проблема новых алертов в графане не запутанность, а то что это абсолютно новая система, к которой если начать читать документацию, то дойти до раздела где будет описано то что тебе нужно почти нереально (а часто это будет вообще один абзац который можно запросто пропустить) и гугл ещё не набрал достаточное количество людей с такой же проблемой как у тебя. Раскопать что-то быстро чтобы узнать как это выписать практически невозможно сейчас.
«Страна-бензоколонка» и другие распространённые предубеждения о российской экономике
по излишнему употреблению нелепого слова «сие» в текстах и комментариях можно всегда отличить человека который читает много всякой чуши претендующей на серьезность. да и сам такую пишет.
Эпоха красивого кода прошла. Пришло время быдлокода
Если программист будет излагать свои мысли (и писать код) так, что надо учиться понимать что он имеет ввиду, я сильно скептически отношусь к тому что ему стоит писать критические статьи про других.
Эпоха красивого кода прошла. Пришло время быдлокода
А вы точно не перепутали красивый код и рабочий? Потому что проблему которую вы тут так смачно описывали стопудово можно было бы решить бахнув пяток if'ов тут и там. Работало бы прям хорошо. Правда почему-то другие глядя на такое называют это legacy, да ещё и говорят так, как будто это что-то плохое...
Интересно что за люди пишут такие статьи вообще, у меня есть два варианта и оба крайние - это когда люди считают что если всё по PSR, отступы, стиль кодирования, DI, интерфейсы и наследование то такой код в принципе не содержит багов. И другой тип когда считают что если задача выполнена то продукт в принципе готов. Если код работает и проходит все тесты - это уже полный продакшн реди и в комментариях не нуждается.
Оба типа сильно ошибаются...
Разозленный хакер-одиночка отключает Северной Корее интернет
да вы вполне правильно поняли, что эксперт в области безопасности это наверное максимально тот самый человек который может себе позволить запускать всё что угодно, приняв меры предосторожности которые он в силу своей профессии знает очень хорошо. а то и, просто вдумайтесь, обладает несложным, не находящимся в публичном доступе способом отследить или даже ограничить выход за пределы песочницы любого, в том числе северокорейского эксплоита. а, как вам такой встречный аргумент?
Разозленный хакер-одиночка отключает Северной Корее интернет
"эксплоитов выходящих из песочниц"? а не подскажете рабочий, а то мне надоели бесплатные тарифы на AWS, хотелось бы захватить весь сервер там выйдя из виртуалки, должно быть несложно вроде как вы описываете.
К нам приехал моноблок на «Байкале» для офиса — «Ну а чего вы ждали?»
Ни первый ни второй явно не работали с arm.
На arm декдоер видео это отдельный IP, отдельный блок в процессоре. Никакого отношения не имеет ни к видеокарте и ни к процессору. То есть в свой armv8 можно прицепить кусок одного производителя, или другого, как захочется. У rockchip этот блок называется Hantro, у Samsung - MFC, у Amlogic... блин вот взял и забыл. Ну короче не важно. Важно то, что практически для всех этих блоков нужен отдельный драйвер в ядре линукса, писать который страшная, древняя жопоболь. А потом этот драйвер ещё и должен быть корректно использован плеером, который будет в него пихать сжатые кадры, а из другого места читать распакованные. Все вендоры лабают жуткий кусок лапши для андроида который стыкуется с их древним проприетарным ядром и андроидским фреймворком для видео и перекрестившись считают на этом свою задачу выполненной. Единственная плата у которой более-менее поддержка декодирования видео работает - raspberry pi. Для их VideoCore есть драйвер в ядре и его более менее умеет использовать ffmpeg. Что уже делает его на голову продвинутей поддержки в линуксе любого другого кодека. Samsung-овский MFC был в ядре давно, но у него свой особенный интерфейс который с трудом понимает ffmpeg и чтобы его завести надо было писать прослойку для каждого плеера. Hantro от рокчипа в зачаточном состоянии, если вообще принят, а не до сих пор в виде патчей, для Amlogic Baylibre (которые просто энтузиасты которые пытаются сделать апстрим линукс работающим на процах Amlogic нормально) целый отдел создали чтобы написать драйвер который примут в апстрим. Более-менее ни шатко ни валко дело идёт, аж целый h264 вроде как работает. Возможно даже 4к. И вроде даже можно связать его с ffpmeg без особой магии.
Так вот. Для начала я сомневаюсь что Байкал вообще поставил какой-то IP для видео в процессор, зачем? И уж совсем сомнительно чтобы они написали достойный драйвер который стыкуется с ffmpeg который без труда смогут понять плееры видео. Если бы они это сделали, шум бы в чатиках которые занимаются видео на встроенных одноплатниках поднялся бы до небес.
Так что всё это скорее всего просто тупо исполняется на проце. И это настоящая печаль, потому что современный арм может h264, и даже 1080 будет видно, если прикрыть глаза и не смотреть на загрузку и температуру, но вот 4к это уже будет во-первых плохо, 24 кадра если сцена не сильно меняется, во-вторых загрузка уедет в небо сразу и прочно.
Bare-metal kubernetes-кластер на своём локальном компьютере
Меня одного смутило "Bare-metal" в названии и рассказ о том как запустить всё на виртуалках?..
Ещё конечно бы хотелось услышать обоснование аж трёх мастеров для тестового кластера, тогда как и продакшн справится с одним. Ведь вы же знаете что мастер не критичен для работы кластера, это control-plane. Им кластер управляется, то есть если мастера выключить, то всё мгновенно не исчезент в варпе, просто пропадёт возможность что-то менять и вообще доступ к API. но поды всё так же будут запущены и будут работать и отвечать? Знаете же да? Что в кластере с одним мастером если его перегрузить пока он перегружается особо ничего не произойдёт? Ну так зачем в тестовом кластере ТРИ мастера?
Чем новый год нам грозит. Снижение лимита на посылки из-за рубежа
Наверное я каким-то другим алиэекспрессом пользуюсь, но на моём алиэкспрессе у продавцов появились склады в европе. При покупке мелкой электроники (типа одноплатников или всякой мелочевки) достаточно прокликать несколько продавцов и можно без проблем найти продавца с выбором склада отправки, с вариантами "из польши", "из италии", "из украины", "из германии". Те же цены, никакой пошлины, да ещё и доставка за неделю вместо месяца как раньше.
Странный мир Python, используемого крупными инвестиционными банками
Открывал статью с предвкушением "ща как читну как всё бывает всрато и какие бывают сумашедшие люди! угорю с утреца"...
В итоге прочитал очень адекватную статью о том как люди задизайнили крайне адекватную систему которая кажется странным как раз фрикам от программирования которые считают что скобки не на новой строке в коде это повод отклонить код.
"Одна из небольших странностей «Минервы» заключается в том, что многое в ней использует принцип «главное — данные», а не «главное — код»" - вообще максимально здравая мысль. Проектируя системы достаточно долгое время так или иначе понимаешь что всё что ты делаешь это фильтр над данными которые ты имеешь, все эти слои прекрасно проходящего PSR-7 проверку кода - просто сложный фильтр, который преобразует массу данных которые у тебя есть в зрительные образы, ничего более.
Да и всё остальное - тоже максимально похожий на так любимый теми же цифровыми фашистами (те которые про важности места скобок в коде) моно-репозиторий концепт. Просто эволюционировавший ещё дальше: возьмём вообще всё что только можно, и данные, и код, и среду исполнения, всё в масштабе предприятия - и сунем в одно место где всё это будет доступно всем сразу.
Короче не вышло угореть. Разочарован. Полнейший адекват в статье. =(
Сквозь тернии к IPv6
Да, причём в ipv6 можно прокидывать айпишник используя роутеры с внутренними айпишниками по пути.
То есть можно дать устройству айпишник типа 2001:x:x:x:x:x:x:x и указать что default gateway fd00::1 какой-нибудь (роутер с wireguard которому не обазательно выдавать внешний адрес) и это совершенно нормальная ситуация. Это как дать устройству ipv4 212.1.1.1/32 и указать гейтом 192.168.1.1 (не получится), а в ipv6 работает.
Правда тут конечно придётся слега уже приколотить роутинг от и до этого айпишника через туннель. но всему же есть предел =D
Сквозь тернии к IPv6
У вас правильное направление мышления, но всё ещё закостенелое под "ipv4" типа "зачем выделять так много адресов небольшому сегменту?". В парадигме ipv6 имеет значение префикс, всё примерно до /64, все остальные /64 это локальный блок, который выделяют не глядя иногда даже и на одно устройство. Суть в том, что ipv6 адреса уже нереально запоминать, мало того некоторые устройства их рандомно меняют (это тоже часть стандарта направленная на безопасность). В ipv6 сети надо полагаться на DNS, без этого уже никак. И если полагаться на DNS уже всё равно сколько там у кого каких адресов.
В вашем случае если я верно понял описание, что можно было бы сделать - так это например сделать wireguard туннель поддерживающим и ipv6 и выдать внутри вашей сети дома внешние айпишники вход на которые на хостинге кому надо. так можно было бы добиться доступности снаружи по ipv6 без всяких проблем для устройств внутри, раз вы переживаете что для дома не выбить свой ipv4. с ipv6 без проблем.
В моём случае у меня умный дом на две квартиры и загородный дом, это три подсети. Всего в одном месте есть реальный ipv4 (повезло с провайдером) из двух других мест туда wireguard туннели, и внутри всё по ipv6. три сегмента ipv6 /64, общая внутренняя /48 сеть, из любого места видно любое устройство, и что самое главное с ipv6 - это реально просто работает. если с ipv4 мне бы пришлось точно знать где у кого какой адрес в каких подсетях, какие там адреса в туннелях и так далее, настраивать роутинг на всех трёх роутерах чтобы один видел оба, а с двух друхи было видно всё через центральный, с ipv6 достаточно было настроить адреса на трех роутерах, и все устройства внутри получили свои адреса и сразу увидели друг друга, то есть не пришлось заморачиваться со сложным роутингом (он как бы так и остался сложным, но с ipv6 это заработало без проблем, включая то что я описал выше - некоторые интерфейсы имет по три разных айпишника, и всегда правильно выбирают с какого адреса выплёвывать пакеты в зависимости от того куда они идут). Отлично работает локализация трафика, не важно где я со своим айпадом, выплёвывается трафик в интернет из локального мне роутера (в одном месте есть внешний ipv6), мой внутренний трафик до устройств ходит внутри сети, где надо и через два хопа).
Сложность из заморочек с роутингом сместилась в сторону грамотно настроить DNS, так чтобы всех было видно по именам.
Сквозь тернии к IPv6
ipv6 крутая технология.
её конечно довольно сложно понять чисто теоретически. можно читать статьи, можно пытаться прикинуть что к чему пытаясь провести параллели с тем как всё в твоей лично сети устроено и как бы это было с ipv6, но всё равно самый крупный толчок ты получаешь начав что-то делать.
когда у меня появился ipv6 адрес от провайдера это стало отправной точкой чтобы подумать "так, ну вот адрес как бы уже есть, может попытаться уже сделать что-то?". и всё оказалось довольно просто и понятно и действительно удобно.
что меня больше всего поражает, это то, о чём почему-то никто не пишет во всех этих огромных статьях, но что знакомо каждому сетевику который делал хоть сколько-нибудь сложные сети. это то, как протокол грамотно выбирает исходных адрес при установке связи. каждый, кто пытался настроить сеть, когда на интерфейсе есть глобальный адрес, пара локальных и ещё впн, поймёт о чём я. в ipv4 есть адрес интерфейса с которого он будет выплёвывать все пакеты, и, чтобы заставить его правильно выбрать исходный айпишник, надо понаколотить всяких правил, чтобы пакеты в какой-нибудь туннель уходили откуда надо. в ipv6 это всё работает из коробки само собой. у меня сейчас на интерфейсе глобальный адрес (аналог внешнего айпишника), локальный адрес (что-то среднее между 127.0.0.1 и 192.168.0.0 - адреса которые существуют только между соседями и роутером, и никогда не выходят за роутер) и два немаршрутизируемых адреса (аналог 192.168.0.0 - два впн-а), и всё это работает вообще без всяких дополнительных настроек без всяких проблем. куда бы я ни коннектился, мой исходящих айпишник всегда тот, от которого до цели ближе всего по маске. вот это прямо крутая фишка ради которой я перевёл все свои внутренние соединения на ipv6, это прямо реально делает жизнь легче.
плюс по мелочи типа SLAAC, это такая недо-DHCP технология, когда роутер может объявлять себя роутером, и устройства в сети буду автоматически подхватывать нужные адреса и цепляться к этому роутеру. в сочетании с пунктом выше это делает ipv6 сети прямо практически магически рабочими. достаточно настроить роутер в сети и любое косое кривое неадекватное устройство прицепится и будет работать как надо.
Использование Google reCAPTCHA v2 и v3 в одной форме
Мы так сделали в первой версии, оказалось что против ботов это не то чтобы супер эффективно, - боты зачастую заточены на решение капчи второй версии, причём делают это как-то через фермы с живыми людьми, то есть где-то живые люди решают капчи по публичным ключам с сайта, и производят коды решения. и в итоге скрипты просто игнорируют третью капчу и херачат сразу запросы к апи с решениями второй капчи (сразу с правильными ключами в параметрах). Я смотрю эти скрипты подвержены той же проблеме - достаточно передать им решение второй капчи и всё будет тип топ.
В итоге наша финальная версия имеет промежуточный стейдж - после того как бэк решает что третья капча так себе была решена, бэк возвращает запрос на рендер второй капчи с nonce и подписью nonce + дата + решение третьей капчи. и решение второй капчи принимается только если вместе с ним поставляется так же решение третьей плюс nonce плюс дата плюс подпись из ответа на третью. И если дата разъезжается минуты на две - машем ручкой.
Так удалось логически прицепить не решивших третью капчу к решающим вторую и как показала практика это сильно затруднило жизнь всяким умельцам которые покупают на сайтах "решение второй капчи 1 доллар за 10000", потому что это уже просто так не заинтегрировать туда (хотя и можно конечно).
Конечно боты всё равно регистрируются, но теперь судя по запросам из логов это живые люди которые решают капчи в браузерах. Потому что запрашиваются целиком страницы со стилями и скриптами. Но хотя бы не бесконечный поток запросов прямо к api с корректными решенями второй капчи.
Переход с iptables на nftables. Краткий справочник
Да, я пересобирал на сервере где делал изначальные тестовые прогоны. Ну там вообще не только для этого ядро кастомное, так что было ок. Потом убедился что достаточно поменять iptables c iptables-legacy на iptables-nft через /etc/alternatives, и старые модули не подгружаются со временем от использования любого софта который у нас в продакшене, и дальше на серверах которые уже ставились с nft не парился. Я думаю можно в /etc/modprobe.d/blacklist.conf перечислить основные модули iptables-legacy:
bpfilter
iptable_filter
iptable_nat
iptable_mangle
и этого будет достаточно чтобы те кто попытаются дёрнуть за старый интерфейс обломились.