Есть ряд алгоритмов над массивами float64 чисел. Эти алгоритмы нужно применять в нескольких проектах на разных языках: JS, Go, Java. Копипастить не очень хочется. Также очень не хочется иметь нетривиальный рантайм.

Пока текущий вариант: написать алгоритмы на С. Для JS скомпилить в wasm, для остального штатными средствами.

В идеале хотелось бы иметь некий язык, с которого кто-то написал трансляторы на вышеперечисленные.

Нет ли такого в природе? Как искать не придумал.

Всегда SUSE проходила мимо меня, а тут мне подсказали, что OpenSUSE Leap это тот же SLES с опциональными доп пакетами.

Выходит, если хочется энтерпрайзной стабильности нахаляву, то это хороший вариант?

Тут про прикольный протокол узнал, graphql называется. Заменяет REST. Почитал про него, пока всё нравится. Хорош в том числе тем, что есть автоматические бэкэнды, в частности hasura (кстати на хаскеле написана) - натравливаешь её на базу, она сама всё делает.

Бэкэндеров можно увольнять? Пускай фронты на этом graphql запросы свои фигачат прямо в базу и всё. Где подвох?

Я вот тут пошёл переименовывать проект frontend на front-end, т.к. это более грамотно с английской точки зрения. И вот думаю - понятно, что оно никому кроме меня не надо, понятно, что на это какое-то время потратится, но с другой стороны если вообще игнорировать всё, скатится же всё в помойку. Или не скатится? Я-то это делаю, чтобы своих тараканов кормить, я иначе не могу, но вообще с объективной точки зрения как считаете - как лучше? Не конкретно по этому вопросу, тут я сам понимаю, что это ерунда, а так, в целом, в комплексе.

В большинстве образов не прописан uid. Соответственно процесс работает от рута. Для дополнительной безопасности требуется запускать контейнер от непривилегированного пользователя.

В связи с чем у меня вопросы:

1. К примеру в образе в /etc/passwd нет пользователя с uid=1000. Но я запускаю от этого uid. Что может пойти не так?

2. Во всех образах (которые я видел) есть пользователь вроде nobody 65534. Кажется, что более безопасно запускать от такого пользователя. Как минимум - у него /home прописан, хоть и прав на этот home нет, но интуитивно кажется, что меньше шансов напороться на неожиданное поведение программы.

В целом вижу, что каждый делает как хочет, но кажется правильней стремиться к единообразному поведению.

Решил написать заметку про kubernetes. Сам работаю с небольшим кластером, делаю всё один, а также в силу характера докапываюсь до всех мелочей, поэтому волей-неволей пришлось разбираться со многими вещами. Может кому полезно будет.

Ничего конкретного писать не буду, буду писать концептуально и про свой опыт. Конкретной информации в интернете хватает. Также многие моменты буду упрощать, просьба не цепляться к мелочам.

Кратко что это вообще такое

Предполагаю, что вы знаете про докер, иначе смысла читать дальше нет. Кубернетес это такая надстройка над докером, которая:

1. Объединяет несколько разных компьютеров в один логический кластер.

2. Позволяет создавать и запускать контейнеры. Сильно похоже на docker-compose, но k8s позволяет не указывать конкретный компьютер, на котором будет запущен контейнер, а сам его выбирает.

3. Обеспечивает виртуальную сеть между всеми контейнерами в пределах кластера, обеспечивает т.н. service discovery, а также обеспечивает балансировку нагрузки междду сервисами внутри этой виртуальной сети. Т.е. я могу во-первых в своей программе по днс-имени postgres-1 узнат IP-адрес первого контейнера с постгресом, а во-вторых по днс-имени postgres-ro получить дважды виртуальный IP-адрес, при соединении на который моё соединение уйдёт на случайный инстанс постгреса.

4. При надлежащей настройке делает это всё высокодоступным и масштабируемым. Т.е. при исчезновении по любым причинам любого сервера из вашего кластера, он продолжает оставаться работоспособным. А также запускает больше контейнеров при повышении нагрузки на сервис.

Таким образом конкретный сервер абстрагируется, для контейнера не важно, где он запущен, он видит весь кластер.

На самом деле современный k8s работает не поверх докера, а поверх легковесной абстракции CRI и её реализации обычно в виде containerd, но это частности

Кому это надо и какие альтернативы

В принципе это надо всем, кому не хватает одного сервера. Хотя не все понимают, что это им надо. В общем-то можно и полуручными способами обходиться довольно долго. Но нужно ли - вопрос открытый.

Альтернативы я знаю следующие:

Hashicorp Nomad. Штука похожая на k8s, но гораздо менее распространённая. По слухам настраивать гораздо проще. Сам не пробовал. Я человек мейнстрима и выбираю то, что выбирает большинство.

Docker Swarm. В принципе очень похоже на следующий шаг после docker compose. Если вам перестало хватать одного сервера, на котором всё было через docker compose, а времени/желания изучать полностью новую платформу у вас нет, наверное это логичный шаг. Его я сам тоже не пробовал.

Проприетарные облачные решения. У всех крупных вендоров они есть. К примеру AWS Fargate. Главный минус: ваше приложение будет прибито гвоздями к этому вендору. Съехать с него малой кровью не получится.

Ценность kubernetes вижу в следующем:

1. Независимость от вендора. У каждого облака есть managed kubernetes. И хотя детали у них отличаются, но всё же сам kubernetes один и тот же. Переехать с одного облака на другое не намного сложней, чем переехать с Debian на RHEL.

2. Опция селф-хоста. Если ни одно облако не нравится, всегда есть опция купить ящик с SuperMicro и поставить всё туда.

3. Популярность. По большому счёту альтернативы на сегодня не взлетели. Специалистов по k8s найти проще, чем других. Документации в интернете очень много. Есть и компании, которые будут админить ваш кластер за вас.

Как это использовать

Основных способов два: либо своими силами поднимать кластер, либо использовать управляемое решение от облачного вендора.

Если своими силами поднимать кластер, надо понимать, что для кластера имеются следующие требования:

1. Кластеру нужен балансировщик нагрузки. Это когда у вас есть публичный IP-адрес, и N адресов. И соединения, приходящие на этот публичный адрес будут равномерно распределяться на эти N адресов. Балансировщик нагрузки должен мониторить доступность клиентов и вовремя включать/выключать их.

2. Кластеру нужно сетевое хранилище. Это когда вы можете какой-то сетевой диск подключить к любому (одному) компьютеру и потом в линуксе он должен появиться, как /dev/sdc.

Первый пункт можно сделать самому через haproxy. Но не очень просто, если делать по уму (отказоустойчиво). Ну крутые дядьки, наверное, чем всякие там cisco такое могут делать вообще уровнем ниже, с резервированием на уровне проводов. Впрочем у них и грохается всё круто.

Если у вас гордый кластер из одного компьютера, ему балансировщик нагрузки не нужен.

Также можете тупо дать каждому серверу публичный адрес и все их вбить в DNS с коротким TTL. Не знаю, можно ли считать это балансировкой нагрузки, но с какими-то оговорками работать будет… Ну это так, из разряда дёшево и сердито.

Как сделать второй пункт самому, я не знаю. Есть ceph, есть ещё что-то, но это всё сложно. В принципе второй пункт не абсолютно критичен и если не запускать в кластере никакие сервисы, которым требуется что-то хранить, то без него можно обойтись. Также можно использовать локальный диск сервера, но надо понимать, что ваш контейнер с БД на другом сервере уже запустить не получится, данные магическим образом не переместятся. Ну и в целом использование локального диска в кубернетесе довольно геморное. Рекомендовать я его точно не буду. Есть какие-то решения, которые берут локальные диски всех серверов и автомагическим образом из них делают доступное сетевое хранилище, я такими не пользовался и в магию не верю.

Обе проблемы легко решаются, если вы своими силами поднимаете кластер, используя облачного провайдера, который предоставляет вам вышеописанные сервисы. Я именно так и делаю: мой провайдер использует OpenStack и Ceph и балансировщик нагрузки с сетевыми дисками у него доступен (под капотом балансировщик нагрузки это тупо две виртуалки с haproxy, но для меня это не важно).

Ещё с сетевыми дисками важно, чтобы был CSI-драйвер для них. Для OpenStack такой есть. Т.е. kubernetes должен этому драйверу отдавать команду «подключи мне диск pvc-7672ffed-9ddc-4df4-affd-a717a1c11c79 на сервер 10.160.3.160» а драйвер должен отвечать «смонтировано в /dev/sdg».

Для своего кластера есть следующие подходы:

1. kubeadm. Это набор софта от разработчиков kubernetes, который устанавливает и обновляет компоненты кластера. Я использую этот подход. Под низом стоит обычный линукс. У меня это debian minimal. Проблем с ним я не испытывал. Вообще народ обычно убунту использует, меня от неё воротит. По идее можно и на центоси, есть и более экзотичные варианты вроде CoreOS, я не вижу смысла тут использовать что-то необычное.

2. Talos Linux. Это офигенная штука: ядро линукса плюс необходимый набор софта плюс сам кубернетес. Это всё идёт как один ISO и грузится в память. Ему даже диск не нужен. И сразу работает. Короче это по сути kubernetes как ОС. Я слишком поздно про него узнал, вероятно я бы его предпочёл. Надо понимать, что штука относительно новая и экзотичная, но я от него в восторге. По крайней мере в концептуальном восторге, может на практике вылезут нюансы.

3. kubespray это огромная куча ansible скриптов, которые обещают, что за тебя всё сделают и поставят. Сам не пробовал, меня такая концепция не устраивает. Если я и буду пользоваться кучей ansible скриптов, то только теми, которые пишу сам. Туда же дистрибутив от Flant. Есть, наверное, и менее популярные решения.

4. Kubernetes the hard way. Это когда ты руками всё настраиваешь сам, ставишь каждый компонент и тд. В целом ничего сверхъестественного тут нет, весь kubernetes это несколько сервеных программ плюс кучка настроек для них вроде своего УЦ с сертификатами и прочим. Но это ненужное усложнение и оправдано только для изучения потрохов. Сам я его не делал и страданий от этого не испытываю. В общем что-то вроде Linux From Scratch.

Управляемые решения я сам не использовал. В целом они решают некоторые проблемы и добавляют свои. Самый главный плюс управляемого решения: хостер будет сам управлять серверами. К примеру при росте нагрузки хостер сам создаст дополнительные серверы, установит туда k8s и добавит их в кластер. При снижении нагрузки он эти серверы выведет из кластера и уничтожит. Это называется node autoscaling. В моём кластере такого нет. В принципе это можно и самому сварганить, если снизу инфраструктура с каким-то API, которая позволяет создавать и удалять серверы. Но это нетривиально и требует программирования.

В целом моё мнение на текущий момент: лучше использовать управляемый k8s от серьёзного облака. Он не так уж много сил экономит, как они это пытаются показать, но всё же сколько-то - экономит, а денег за него обычно не просят. На втором месте: использовать k8s поверх облака, которое даёт нужные «примитивы»: балансировщик нагрузки и сетевое хранилище. На третьем месте: использовать k8s на своём железе.

Неочевидные преимущества Kubernetes

Первое преимущество Kubernetes похоже на преимущество докера, которое я не сразу осознал. В докере помимо технологии есть ещё и коммьюнити. Это тысячи людей, которые собирают готовые пакеты. Если мне нужен postgres или wordpress или ещё что угодно, скорей всего это кто-то уже собрал. И даже если я решу собирать свой образ, я как минимум смогу посмотреть на чужие докерфайлы, а скорей всего мне хватит чужих. Это экономит много времени и сил. В кубернетесе похожая тема: для него создано куча софта и деплойментов, которые позволяют в пару строк деплоить в кластер довольно сложные конфигурации. К примеру прометей, собирающий метрики, локи, собирающий логи, ещё кучка вспомогательных агентов и графана, уже настроенная на отображение всего этого, ещё и с кучей готовых дашбордов, которые не стыдно директору показать. Почти для любого софта, который я хочу запустить в своём кластере, есть хельм от производителя, в котором всё уже прописано. И даже если я решу писать дескрипторы сам, я в этот хельм смогу посмотреть.

Второе преимущество Kubernetes на самом деле тоже похоже на преимущество докера, которое я тоже не сразу осознал. Это сближение программистов и админов. В классическом древнем подходе программист пишет код, сборщик собирает из этого кода артефакт, а деплоер устанавливает этот артефакт на сервер. Докер позволяет сблизить программиста и сборщика. Когда программист указывает в машинном виде все инструкции для сборки и все «входные» артефакты. Причём не в виде кучи непонятно каких скриптов, а в относительно стандартизованном виде. Вот Kubernetes с его ямлами делает похожую задачу и сближает программиста и деплоера. Когда ты можешь в своём софте написать в машинно-читаемом виде - какие volume-ы нужны твоему софту, какие конфиги, какие переменные окружения, какие порты твой софт выставляет и тд.

Третье преимущество в том, что есть некоторые уникальные софтины. К примеру я пускаю БД в кластере. БД управляется через оператора. Оператор это такая программа (которая тоже запущена в кластере) которая создаёт контейнеры с БД, настраивает их как надо и как бы следит за ними. К примеру я буквально несколькими строчками настроил запуск постгреса в двух копиях с периодическими бэкапами в S3 и постоянными бэкапами wal-логов туда же. В итоге имею high-available СУБД кластер с бэкапом и возможностью откатиться с гранулярностью в 5 минут. Руками такое настраивать я бы наверное несколько дней минимум потратил. Понятно, что если сломается, то в общем случае для починки придётся разбираться что там как устроено. Ну пока не ломалось. Может и не сломается.

Вот эти преимущества позволяют мне рекомендовать использовать Kubernetes даже там, где сегодня нет никакого кластера. Т.е. просто вместо докера, на обычном одном сервере. В таком варианте, кстати, не нужен ни балансировщик нагрузки, ни сетевые диски.

Недостатки Kubernetes

Вот это, наверное, самый важный раздел и то, на что частично отличается от того, что я читаю вокруг.

1. Требования к железу. Для полноценного высокодоступного кластера требуется три сервера по 4GB RAM и 2 CPU, которые будут использоваться исключительно для Kubernetes (мастера). Также на каждом рабочем сервере нужно зарезервировать примерно 20% оперативной памяти. Также Kubernetes до недавнего времени не работал со свапом, а с недавнего начал работать в экспериментальном виде, но про это никто не пишет и не знает. В общем можно считать, что свопа нет. Для крупных проектов эти требования не очень существенны, если же весь ваш проект это 2GB VPS за $5, то kubernetes вам не подойдёт. Нужно свой бюджет расширять хотя бы до 8GB за $20.

1.1. А ещё желательно иметь два кластера. Один тестовый, а один боевой. И тестировать свои эксперименты на тестовом. Лично у меня такой возможности нет, я работаю в компании, которая экономит на всём, и $300 в месяц на тестовый кластер это дораха. Поэтому я написал нужные terraform скрипты и прочее, что позволяет мне поднимать тестовый кластер за 15 минут, а потом опускать его. Но лучше не экономить на спичках и держать два одинаковых кластера.

2. Требования к квалификации. Для того, кто с k8s не работал, там всё будет новое. И хотя ничего особенно сложного там нет, но объём знаний всё же существенный. В целом готовьтесь потратить несколько месяцев на изучение и работу с тестовым кластером. Не вздумайте сходу переводить прод на k8s, если он нужен кому-то кроме вашей мамы. Также надо понимать, что kubernetes очень плотно работает с линуксом. cgroups, iptables, ebpf - эти слова не должны вводить вас в ступор (ebpf меня в ступор вводят, в частности поэтому я отказался от cilium).

3. Он провоцирует к обезяньнему девопсингу. Этим термином я называю деятельность по копипасту непонятных команд с надеждой получить блестящее и пердящее UI. Я уже выше приводил пример с графаной, когда одной командой можно поставить около десятка сложнейшего преднастроенного софта. Вот это слишком провоцирует. А когда этот сложнейший преднастроенный софт сломается, то обезьяна ничего сделать не сможет. Поэтому обезьяньи порывы надо в себе подавлять и пользоваться только тем, в чём ты хорошо разобрался. А если не разобрался - то сидеть и разбираться. А когда уже разберёшься, тогда можно и готовыми комплектами пользоваться, хорошо понимая, что там где или хотя бы где посмотреть можно.

В целом нужно соблюдать баланс между написанием всего самому и использованием всего готового. Тут обе крайности вредны. На первое времени не хватит. Второе чревато последствиями, ты понятия не имеешь, что происходит у тебя в кластере.

4. В нём «из коробки» нет многого, что можно было бы ожидать от него. К примеру есть ингрессы (это описание входных точек для внешних сервисов), но ингресс-контролера нет, нужно выбирать и ставить, а их, между прочим, штук 15 разных. Да что там ингресс-контролер, там даже этой самой вышеописанной виртуальной сети нет, есть только некие интерфейсы, а реализацию, которая будет эту сеть «настраивать» - надо ставить самому (собственно это первое, что вы будете ставить в только что созданный кластер). Причём этих реализаций опять же штук 10 разных. И муки выбора - flannel, calico, а может модный cilium, а вот тут на реддите ещё про что-то писали, ааа, вот это при некотором складе характера может мучить. Меня мучает. Я боюсь сделать неверное решение. Если что, я выбрал ingress-nginx и calico для вышеописанных пунктов, как наиболее понятные и консервативные решения. Не жалею.

5. Он провоцирует ставить и настраивать то, что вам в общем-то не особо и надо. Ну вот жили мы с докер-композом, проставляли реплики в конфиге руками и ладно. А тут вроде есть horizontal pod autoscaler, который будет в зависимости от нагрузки запускать больше или меньше реплик, круто же. А для него метрики нужны, надо ещё компонент для метрик поставить. А вот про istio прочитали, он вообще даёт возможность смотреть все запросы между сервисами, а-а-а, это же просто огонь. В общем вроде и не сказать, что это плохо, т.к. это всё даёт лишние возможности, но всё же тут важно не увлекаться. Может оно вам не так уж и надо, раз жили без этого. Каждая софтина это время на изучение документации, это постоянные затраты времени на чтение ченджлогов, обновления, обновления конфигов. А если это ещё и штука вроде istio, которая не сбоку-припёку, а влезает прям между вашими сервисами, то это ещё и потенциальная причина того, что всё сломается и вам придётся ковыряться в ихних кишках в самое неудачное время. Ну и ресурсы тоже каждая софтина требует, ага. Вроде и всё на го написано, вроде и не ресурсоёмко по большому счёту, но потихоньку набегают гигабайты…

6. Несмотря на то, что я выше написал про докер, на самом деле с самим докером он плохо совместим. И если вам хочется сделать такую простую и понятную штуку, как запуск вашего CI в кластере - типа коммит прошёл, теперь надо docker build сделать, вот это простое желание на самом деле таит в себе столько нюансов, что я в итоге отказался от этого желания и для CI завёл тупо отдельный сервер с докером.

7. Кубернетес из коробки адски небезопасен. Легко создать под, в котором будет подмонтирован корень вашего сервера. И удалить там всё, азаза. При этом, конечно же, есть все возможности закручивать гайки сколько угодно, но это надо делать. Когда пишешь helm install, обычно оно ставится от cluster-admin и в общем случае может делать с кластером что угодно. Если у вас отдел девопсов, которые там каждый ямл обнюхают и будут это делать каждую неделю, ставя новую версию, ну классно. А если весь ваш девопёс это я, занимающийся этим, когда других задач нет, и джуниор, который сам всё поломает, только доступ дай, то не классно. Поэтому см. пункт выше про отдельный тестовый кластер.

8. Гитопс. Гитопс это круто и здорово, но я так и не впечатлился. В общем не рекомендую. С одной стороны - да, весь ваш кластер должен лежать у вас в гите, а не в голове и при необходимости подниматься несколькими командами (или несколькими десятками команд, не принципиальная разница, у меня второй вариант). С другой стороны внедрять прям 100% гитопс, когда вам реально надо коммитить в гит, чтобы там что-то срабоатло, я долго пытался это делать на flux, я его неплохо изучил, но в итоге отказался. Опять же если у вас отдел девопсов, которые будут там друг друга ревьюить и мерджить, то наверное ок. Если вам нужно держать не один кластер, а сто кластеров, развернутых и обновляемых из одного репозитория, то конечно ок (хотя тогда вы сами меня учить будете, а не читать это). А если вас один-два человека, ну я решил, что оно не надо. У меня весь репозиторий это terraform-шняга, которая просто создаёт серверы, на этих серверах через cloud-init при создании ставится containerd, kubelet и прочая ерунда, потом я туда по ssh захожу и вбиваю kubeadm join и всё. Это инфраструктура. Второй репозиторий это во-первых кучка скриптов (в основном helm update, чтобы не запоминать это всё), во-вторых кучка kustomize-ов, которые уже ставят либо то, что в helm не обернули (или я не захотел этим пользоваться), либо, собственно, тот софт, ради которого весь этот кластер вообще существует.

9. Ямлы-ямлы-ямлы-ямлы. Не, я не особо жалуюсь, но всё же в кубернетесе эти ямлы они как-то совсем уж беспонтовые. И дело не в формате, а в том, что они совсем не добавляют синтаксический сахар. Это не является чем-то адски страшным, но когда пишешь

ports:
  - name: http
    containerPort: 3100

вместо

ports:
  http: 3100

или вся эта копипаста

spec:
  selector:
    matchLabels:
      app: loki
  template:
    metadata:
      labels:
        app: loki
    spec:
      containers:

в которой сути около нуля, то это утомляет слегка. В общем синтаксического сахара не хватает. Да, конечно, это можно всё генерировать, но это лишние усложнения. На мой взгляд это должно было бы быть из коробки. А они какие-то свои внутренние структуры просто замапили в JSON и объявили это стандартом. А то, что это будут писать люди, про это никто точно не думал.

10. Также из коробки поставленный через kubeadm кластер не стабилен и сервер легко роняется одним подом, который решил сожрать всю память (у меня сервер просто перестал отвечать, где там были все эти ваши оом киллеры, я не знаю). Это меня неприятно удивило. А чтобы сделать его стабильным, мне потребовалось потратить не один час на чтение документации и разного рода настройки (в основном резервирование памяти для кублета, системы и тд). Что мешает kubeadm-у прописывать лимиты самому, я не понимаю.

11. Если у вас три сервера, один сервер упал и вы ожидаете, что кубернетес в ту же секунду, радостно повизгивая, побежит перезапускать все поды на других серверах, то вы сильно ошибаетесь. Во-первых он вообще не сразу поймёт, что сервер упал. Во-вторых он ещё минут 5 подождёт. Ну вдруг тот не упал, а просто устал немножко и присел отдохнуть. Про 5 минут не уверен, кстати, может быть даже 15 минут, сорри, лень смотреть. В общем, как говорится, eventually он таки - да, перезапустит поды на других серверах. Но к вам за это время уже успеют прибежать и наорать, что ничего не работает.

Поэтому high availability это все ваши сервисы, запущенные в двух копиях минимум. Иначе это eventual availability. Что тоже неплохо и лучше, чем unavailability.

Вышеописанные таймауты можно настроить, если что. Но, наверное, не нужно. Я не стал.

Из этого, кстати, вытекает 12. Настроек очень много. Туториалов о том, как эти настройки настраивать - ещё больше. И на ютубе и в тексте. А вот какие значения нужно проставлять, какие плюсы, какие проблемы - тут все резко затыкаются.

13. Будьте готовы читать много кода на go, копаться в исходниках и issues. Ну может мне так повезло или у меня такой стиль решения проблем. Но такого, как в традиционном линуксе - когда почитал man iptables или IPTABLES HOWTO и нашёл ответы на все вопросы - тут часто не получается. Какая-то мелкая, но нужная софтинка. В доке ничего не понятно, приходится лезть в исходники и смотреть - что там на самом деле. Или гуглишь - ничего релевантного. Залазишь в гитхаб issues, ищешь там и, таки, находишь ответ на свой вопрос.

Имеется кластер с одним мастером. Хочу пересоздать машину с мастером. Для этого надо добавить ещё 2 мастера, потом можно будет пересоздать. Но как потом уменьшить число мастеров с 3 до 1? Если просто два отключить, оно же подумает, что сеть сломалась и перейдёт в какой-то там аварийный режим. Есть штатная процедура для такой манипуляции?

Сейчас у меня стоит

myhostname = myhost.mydomain.com
mydomain = mydomain.com

mydestination = $myhostname localhost.$mydomain localhost $mydomain

Соответственно postfix принимает из интернета почту на все эти домены. Я хочу, чтобы из интернета он принимал почту только на mydomain.com. Но при этом, когда на локалхосте программы отправляют почту на root или root@myhost.mydomain.com или root@localhost и тд, то эта почта приходила соответствующему пользователю.

Как это настроить?

Или это норма и не надо это настраивать? ChatGPT меня убеждает, что это норма и чтобы я не морочил ему голову, но я сомневаюсь.

Захотелось потрындеть, решил описать свое видение идеального дистрибутива. Сразу скажу, что меня интересует лишь серверная специфика, про полноценный GUI писать не буду, там думать надо.

1. Сборка. Не скажу, что видел всё, но обычно берут исходники софтины с её билд-системой, к ней сверху прикручивают какие-то скрипты, которые вызывают ./configure и тд. Я бы сделал по-другому: берём, собственно, исходники. Выкидываем все билд скрипты и переводим всё на bazel. Считаю его лучшей системой сборки в мире, если есть время на его изучение. Понятно, что надо будет исходные билд-скрипты на самом деле не выкинуть, а изучить, определять нужные дефайны и тд. Сделать процесс перевода не одноразовым, а чем-то вроде скрипта, чтобы следующие версии уже автоматом собирать, а не повторять весь процесс.

Отдельный вопрос с крупными пакетами вроде ядра. Там система сборки, наверное, в каком-то смысле уже часть исходников. Не уверен, что для ядра это вообще возможно. Но если возможно, то надо сделать, однозначно.

bazel даст повторяемые сборки. Это важно. Т.е. вася и петя берут одни исходники и получают идентичные бинарники.

2. Пакетов, как таковых, нет. Весь дистрибутив это что-то вроде debian-minimal. Т.е. ядро + systemd + libc + coreutils + кучка необходимых программ. Всё это идёт единым образом (можно представлять как tar-архив). Образ ОС абсолютно иммутабельный, не просто 644, не просто mount -o ro, а хотелось бы прям на уровне иммутабельной ФС вроде ISO. Чтобы его поменять вообще было бы сложно. Ещё для безопасности было бы неплохо там всё обложить контрольными суммами и подписями, чтобы ядро сразу выпадало в осадок, если на диске что-то поменялось.

3. Каждая следующая версия выпускается кроме того хорошо оптимизированным бинарным diff-ом, что позволит типовым обновлениям быть крохотными, в районе нескольких десятков килобайтов. Обновления постараться сделать не требующими перезагрузки, но в то же время корректными (перезапускать демоны, если поменялась библиотека, через kexec перезапускать ядро). Кроме того сделать возможность очень легко откатиться на предыдущую версию, тоже без перезагрузки. Понятно, что речь идёт об обновлениях безопасности, когда особо ничего не меняется.

4. Используются современные продвинутые файловые системы наподобие bcachefs/zfs/btrfs. Смысл в том, чтобы во-первых использовать дедупликацию, и обновления из пункта 3 не занимали кучу места, во-вторых чтобы максимально упростить откаты на предыдущие версии.

5. Использовать максимально современные и легковесные подходы. Ядро грузить с UEFI, для сервисов systemd, networkd, минимум выбора, максимум интегрированности. Также использовать хорошие подходы к безопасности, ну про иммутабельный root уже упоминал, кроме этого запускать все сервисы по возможности в chroot или вообще отдельных ns, написать хорошие selinux правила. Т.к. базовая система имеет относительно небольшой размер, это не должно быть очень уж сложным.

6. Собственно остаётся главное, для чего нужен дистрибутив - запуск пользовательских программ. И вот это предлагается делать не через опакечивание каждой программы во вселенной, а через контейнеры. Сегодня видимо это podman. Т.е. максимум, что от дистрибутива надо - обеспечить работу этого самого podman-а. А дальше уже практически для всего софта имеются образы либо от самих разработчиков, либо от достаточно компетентных товарищей, которые достаточно часто обновляются.

7. Есть уж говорить про GUI, тут можно применить похожую концепцию. Выбрать один DE, ну очевидно это гном, включить его в базовый образ, а весь софт ставить через контейнерные решения вроде flatpak. Хотя тут, конечно, базовый образ будет куда жирней.

Предположим, у нас отправитель шлёт данные по 20 байтов тысячу раз в секунду. При этом получатель тормоз и не всегда успевает с такой частотой принимать данные (но если бы они где-то буферизовались, то проблем бы не было).

У меня есть девайс, который на компьютере принимает ровнёхонько 20 000 байтов в секунду, вообще без видимых флюктуаций. А вот на смартфоне не успевает и выходит на процентов 10-20 меньше. Я в протоколах этих не разбираюсь и предполагал, что там как-то автоматически будет буферизоваться всё где-то (в разумных пределах), а я там уже буду вычитывать, к примеру 100 раз в секунду по 200 байтов за раз, ну или как получится.

Я посмотрел исходники драйвера на смартфоне и там запускается поток с высоким приоритетом, который просто в цикле читает данные и передаёт их дальше. То бишь если у этого потока цикл будет не такой быстрый (а ведь андроид это не ОС реального времени и совершенно нельзя гарантировать, что поток, даже с высоким приоритетом, будет висеть на процессоре без перерыва) и иногда будут перерывы, то пакеты будут теряться.

Как устроен драйвер на компьютере, я не знаю. Поэтому и хочу спросить - есть смысл копать дальше, или на компьютере где-то в ядре ровно такой же цикл и он работает стабильно просто потому, что компьютер быстрей смартфона? Но в теории и на компьютере при нагрузке могут пропадать пакеты и нигде они не будут буферизоваться?

Archlinux, после старта nginx появляется такая ошибка в логе.

May 08 15:10:55 alpine systemd[1]: Starting A high performance web server and a reverse proxy server...
May 08 15:10:56 alpine systemd[1]: nginx.service: Can't open PID file /run/nginx.pid (yet?) after start: Bad file descriptor
May 08 15:10:56 alpine systemd[1]: Started A high performance web server and a reverse proxy server.

systemd юнит:

# systemctl cat nginx
# /usr/lib/systemd/system/nginx.service
[Unit]
Description=A high performance web server and a reverse proxy server
After=network.target network-online.target nss-lookup.target

[Service]
Type=forking
PIDFile=/run/nginx.pid
PrivateDevices=yes
SyslogLevel=err

ExecStart=/usr/bin/nginx -g 'pid /run/nginx.pid; error_log stderr;'
ExecReload=/usr/bin/nginx -s reload
KillMode=mixed

[Install]
WantedBy=multi-user.target

В nginx.conf ничего, относящегося к делу нет.

Файл /run/nginx.pid создаётся, pid в нём присутствует.

Почитал man open, пишут, что

EBADF
(openat()) pathname is relative but dirfd is neither AT_FDCWD nor a valid file descriptor.

и совсем запутался. В исходниках systemd не осилил понять, что происходит, тут и тут если кому интересно.

Версия systemd 253.4-1-arch.

Так в принципе оно вроде работает, но это же неправильно.

/run это tmpfs, никаких симлинков вроде нигде не задействовано.

Перемещено hobbit из general

Разочаровавшись в дебиане решил попробовать сабж первый раз в жизни и приятно удивился. Сходу поставил его в не самой дефолтной конфигурации (шифрование рута, syslinux, systemd в initramfs). Всё прошло прям как по маслу, я приятно удивлён. Особенно порадовало наличие vi, а не этого новомодного vim.

Собственно интересует лишь - насколько он живой? Всё же такой подход, как у него, нынче не слишком популярен, все кажется сейчас угорают по убунте и подобному.

Это сервис типа S3 но без оплаты egress. Не пойму, в чём подвох. Цена за хранение тоже божеская ($15/TB). Что мне мешает сделать клон ютуба и обанкротить клаудфляр?

Я хочу сделать страницу, которая будет выглядеть максимально похоже на разных браузерах. Идеал - попиксельная идентичность. Понимаю, что идеала не достичь, но хочу достичь что могу.

Ширина и высота у страницы фиксированные.

Шрифты я использую свои.

На что ещё нужно обратить внимание, по крайней мере из очевидного?

Я так понимаю, применять что-то вроде font-size: xx-large не стоит, т.к. это не соответствует конкретному кеглю и лучше применять что-то вроде font-size: 30px.

Хочу писать на C для МК, но так, чтобы ни единого байта не было в бинарнике, не от моего кода.

В целом я понимаю, как это всё собрать и слинковать. Вопрос больше в том, что компилятор C в моём понимании генерирует код, рассчитывая на определённый рантайм, который я у него хочу забрать. К примеру я слыхал, что компилятор может генерировать вызовы функций вроде memcpy, если посчитает нужным. Также я не очень хорошо представляю, что происходит до вызова main и насколько это важно.

Также развитие этого вопроса - тот же вопрос про C++.

Хочу написать приложение, которое будет работать на arm девайсе. Документации не нашёл, делаю по крохам информации, которую нашёл, но ничего не получилось.

Во-первых нужно собрать Qt для хоста.

Хост у меня дебиан. Ставлю пакеты cmake gcc g++ mesa-common-dev ninja-build perl. Собираю командами

../qt-everywhere-src-6.4.3/configure -prefix /mnt/data/qt-host -submodules qtbase
cmake --build . --parallel 4
cmake --install .

Это у меня получилось.

Далее нужно собрать Qt для таргета. Таргет у меня это какая-то китайская плата с i.MX8MM. Есть rootfs для неё.

Первая проблема в том, что не понятно, где брать компилятор. Я поставил таким образом:

dpkg --add-architecture arm64
apt-get update
apt-get install gcc-arm-linux-gnueabi g++-arm-linux-gnueabi

Также пробовал вариации с --add-architecture arm и gnueabhf. Не знаю, чем они отличаются и как понять, какой мне надо.

Далее написал файл imx8mm.cmake со следующими строчками:

set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR aarch64)
set(CMAKE_C_COMPILER arm-linux-gnueabi-gcc)
set(CMAKE_CXX_COMPILER arm-linux-gnueabi-g++)
set(CMAKE_SYSROOT ${INPUT_sysroot})
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)

и пытаюсь сконфигурировать Qt командой

/mnt/data/qt-everywhere-src-6.4.3/configure \
  -prefix /opt/qt \
  -extprefix /mnt/data/qt-embedded \
  -qt-host-path /mnt/data/qt-host \
  -sysroot /mnt/data/rootfs-ok8mm \
  -submodules qtbase \
  -nomake examples -nomake tests \
  -- \
  -DCMAKE_TOOLCHAIN_FILE=/home/build/imx8mm.cmake

Это всё кончается ошибкой

ERROR: The OpenGL functionality tests failed! You might need to modify the OpenGL package search path by setting the OpenGL_DIR CMake variable to the OpenGL library's installation directory.

Я не знаю, где посмотреть точно какая ошибка ему помешала.

В файле CMakeError.log есть миллион ошибок, но в том числе одна, которая мне кажется важной и которую я не знаю, как решить:

: && /usr/bin/arm-linux-gnueabi-gcc --sysroot=/mnt/data/rootfs-ok8mm -DCHECK_FUNCTION_EXISTS=XOpenDisplay -fPIE -pie CMakeFiles/cmTC_d6b57.dir/CheckFunctionExists.c.o -o cmTC_d6b57  /mnt/data/rootfs-ok8mm/usr/lib/libX11.so  /mnt/data/rootfs-ok8mm/usr/lib/libXext.so  /mnt/data/rootfs-ok8mm/usr/lib/libGLESv2.so  /mnt/data/rootfs-ok8mm/usr/lib/libEGL.so && :
/mnt/data/rootfs-ok8mm/usr/lib/libX11.so: file not recognized: file format not recognized
collect2: error: ld returned 1 exit status

Как я понимаю, суть ошибки в том, что компилятор не соответствует плате.

Вот вывод readelf -a /mnt/data/rootfs-ok8mm/usr/lib/libX11.so.6.3.0, может быть он чем-то поможет: https://pastebin.com/raw/5t5dQ2qw

Также ещё вижу такие проблемы: в usr/include платы нет заголовков для EGL, но при этом сами библиотеки в usr/lib есть. Пока до ошибок с EGL не дошёл, планировал их решить установкой пакета EGL в хостовую систему и изменением set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) на BOTH, хотя не уверен, что это правильно.

Может быть я зря на Qt 6 это пытаюсь делать и лучше использовать Qt 5? На плате установлена Qt 5 и есть какие-то примеры на Qt 5. Но, как я понимаю, мне всё равно для своей разработки надо собирать локально версию для кросс-компиляции.

Я тут со своей доморощенной виртуализацией экспериментирую. И оказалось, что когда мой ноутбук уснул, в запущенной виртуальной машине время ушло назад на время сна (то бишь не двигалось вперёд). Перезагрузка виртуальной машины проблему решила, но хотелось бы понять, можно ли эту проблему решить другими способами. Я предполагаю, что в запущенном линуксе время отсчитывается средствами процессора, а нужно вероятно вместо этого использовать какие-то аппаратные источники времени (которые, предположительно, в виртуальной машине будут синхронизированы с хостом и будут правильные).

Перемещено hobbit из general

Давно хотел проверить, но никак не доходили руки. Вообще говорят, что и в докер десктопе это есть, я не проверял. В целом запустил федору через Virtualization.Framework на M1 макбуке, в ней поставил докер, а также розетту. И теперь:

% docker run --rm -it --platform linux/amd64 debian:11 uname -a
Linux 3ae5494cbd64 6.1.18-200.fc37.aarch64 #1 SMP PREEMPT_DYNAMIC Sat Mar 11 16:03:54 UTC 2023 x86_64 GNU/Linux

Для меня это важно, мне этого давно не хватало. На qemu эмуляция была, но там такая медленная скорость, что было не юзабельно. А тут ничего так, шустренько.

% time docker run --rm -it --platform linux/amd64 debian:11 bash -c "head -c $((1024 * 1024 * 1024)) /dev/zero | sha256sum"
0.02s user 0.02s system 0% cpu 5.759 total

% time docker run --rm -it --platform linux/arm64 debian:11 bash -c "head -c $((1024 * 1024 * 1024)) /dev/zero | sha256sum"
0.03s user 0.02s system 0% cpu 4.770 total

Если он запускается в виртуалке. Загрузчика вообще нет, сразу ядро и initrd подаётся на вход. Скомпилировать ядро без всего кроме того что надо для виртуалки. Как-то юзерспейс максимально быстро стартануть. Systemd самый быстрый?

У меня сейчас в виртуалке федора с UEFI за несколько секунд грузится. Мне интересно, можно ли это ускорить. Чего она там делает эти несколько секунд - не понятно. dmesg если кому интересно.

Имеется китайская плата на i.mx6ull. Китайцы туда поставили китайский линукс на китайском ядре 4.1.15. Браузера там нет. Я хочу туда засунуть веб приложение. Свое ядро более актуальной версии скомпилять пока не вышло. Посоветуйте как быть.