Как стать автором
Обновить

Комментарии 9

Встроенный Kubernetes в Debian не нужен, как не нужен и встроенный Docker. Debian замораживает версии пакетов перед релизом, через год он будет устаревшим, через два — неактуальным, а через пять — потребуется бэкпортировать обновления безопасности на эту версию. Или «специальный» статус как раз подразумевает поднятие мажорных версий и быстрый отказ от поддержки? Но зависимость от старого runtime (docker/containerd) это всё равно не устранит.

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

Debian и k8s стоят на вершине горы, а внизу пасётся код.


k8s предлагает Debian:


  • Слушай, давай быстренько-быстренько завендорим всё, релизнем новую версию и быстренько-быстренько объявим её устаревшей!
  • Не-ет !
  • Ну, тогда давай быстренько-быстренько завендорим 200 пакетов, релизнем две версии и быстренько-быстренько объявим их устаревшими!
  • Не-ет !
  • Ну, а что же тогда ты предлагаешь ?
  • Мы медленно-медленно запакетируем все библиотеки, всё протестируем, и будем поддерживать дистрибутив стабильным даже после того, как k8s объявят obsolete.

такими действиями они открывают дверку в мир того, что дебиан станет помойкой и для всего остального и его сами пользователи прикопают… М-да. Пойду-ка я получше почитаю оригинальную новость, потому что парадокс в том, что сам куб — это несколько бинарников и конфигов БЕЗ внешних зависимостей, следовательно, проблема с пакетированием возможна только для исходников.


amarao что скажешь?

Debian действует в рамках общественной пользы (public interest). Вендоринг полезен для ускорения конкретного проекта, но вреден в целом для дистрибутива (если у вас каждый бинарь будет вендорить всё, то у вас на каждый ls будет по своей libc) — у вас будут толстые бинари с неизвестными библиотеками внутри и произвольной полисей.


Задачи, которые решает Дебиан весьма обширны. Например, они решили проблему переезда с python2 на python3 таким образом, чтобы всё продолжало работать. Даже то, что не должно было работать в условиях переезда.


Проект про reproducible builds уже практически завершён, и сейчас команда энтузиастов работает на bootstrap seed (trusting the trust problem).


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


Раньше особыми источниками боли были php'шные софтинки (которые хотели config.php иметь в каталоге с кодом, да ещё и с правом записи в него из index.php), была боль с многими erlang'овыми приложениями, которые хотели вендорить свой beam.smp. Теперь к ним добавился ещё и k8s.


Но куб — микроскопическая часть всего того, что есть в дебиане, и хипстеры, которые считают, что "или куб, или смерть" — посмотрите на докер.
March 20, 2013 — Docker initial release.
May 2013 — Дебиан релизит Wheezy с поддержкой multiarch'а.
Jul 2019 — Дебиан релизит Buster, в котором примерно 90% reproducible build
Nov 2019 — Мирантис покупает осмысленную часть докера, а его свармы почти мертвы из-за k8s, да и сам докер доедают runc и containerd.
2021 (наверное) — Debian релизит Bullseye


Докер пришёл и ушёл а Дебиан остался. Почему в отношении k8s надо предполагать что-то другое?

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

проблема не в том, что куб вендорит — ЛЮБОЙ ПРОДУКТ НАПИСАННЫЙ на ГОЛАНГ — вендорит. И ничего — никто не умер.


Я уж не говорю о том, что нефиг кубернетес тащить на дебиан. Никакой ценности ставить дебиан, чтобы сделать из него платформу для куба — нет. Хочешь куб — тащи любой специализированный дистрибутив линукса (с минимальным footprint), либо бери куб как коробку (=openshift)

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


apt search  ^golang-|wc -l
4511

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


В этом смысле модель debian вполне может жить с гошной. Это не отменяет того, что авторы могут захотеть странного и от них будет боль, но в общем случае — вполне.

Я в принципе не понимаю зачем упаковывать гошные библиотеки в отдельные dpkg пакеты, это же не питон с его глобальным site packages (да, есть и user site packages но софт из apt его не использует).

Люди перешли на go modules и го сам подтянет пакеты при сборке, а старые проекты полагаются на gopath который уникален для каждого пользователя.

В результате репа Debian забита ненужными пакетами с странными длинными именами в духе golang-github-com-username-libname

потому что есть src пакеты и их тоже надо как-то дистрибьютить?

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