в английском языке нет наших падежей и нелепо выглядит попытка прикрутить изменённые окончания
Не согласен с вами. В английском не склоняются существительные, но в русском языке этому правилу лучше следовать. Пусть многие в техническое среде так не делают, это явление — оно вовсе не о правилах и красоте речи...
«Я купил Tesla»/«Я еду на Tesla» или «Я купил Теслу»/«Я еду на Тесле»? Конечно, второе! Первое звучит не по-русски, а возможны случаи, когда попросту не будет передавать верный смысл/вводить в заблуждение (не зря же слова в русском языке склоняются).
Но от русскоязычного написания англоязычных названий я бы тоже воздержался. Может быть, конкретно с Теслой это ещё и прокатит, потому что уже привыкли, но вот со многими другими названиями будет больше проблем, чем пользы.
Идеальный вариант — добавлять русское существительное перед брендом, которое склонять: «Я купил машину Tesla». Но при частом употреблении может получиться довольно громоздко.
В общем, добавление русских окончаний англоязычным терминам не более нелепо, чем их употребление вовсе без окончаний.
UPD. По беглому анализу свежих данных последнего опроса от CNCF (https://github.com/cncf/surveys/tree/main/cloudnative) у меня получилось, что containerd используют в production 42% опрошенных (+25,5% пробуют), а CRI-O — менее 15% (+17,5% пробуют).
Пришел в комментарии с тем же вопросом. Кажется, что преимущество в сообществе всё-таки у containerd, а это зачастую означает, что остальные плюсы тоже скорее у него (больше юзеров - больше кейсов и исправлений, реализации запросов юзеров и т.п.). Если это не какое-то узкое/нишевое решение, конечно, но в данном случае речи об этом нет.
CRI-O - это видение Red Hat, которое пытаются сделать массовым. А containerd - реальный (действующий) выбор сообщества и индустрии. Ведущие мировые облачные провайдеры используют именно containerd. В этой таблице от Oracle можно наглядно увидеть. А здесь обсуждается вопрос потенциальной поддержки CRI-O в EKS.
$ autossh
Команда «autossh» не найдена, но может быть установлена с помощью:
sudo snap install autossh # version 1.4, or
sudo apt install autossh # version 1.4g-1
See 'snap info autossh' for additional versions.
А в чем вопрос? На комментарии к статьям, которые являются переводами от других авторов... да ещё и к старым таким статьям - отвечают с куда меньшей вероятностью...
Только вот во всем этом многообразии по-настоящему устоявшихся терминов (единых, общепринятых, универсальных) до сих пор скорее нет, чем есть. А в русскоязычном сообществе эта проблема, по моим ощущениям, не особо о(б)суждается.
Calico — хорошее решение! Но нам нужно что-то выбирать. Идея Deckhouse не в том, чтобы собрать в одном месте все возможные реализации каких-то задач, потому что кто-то предпочитает что-то по своим причинам, а предоставить пользователям решение каждой задачи надёжным, проверенным способом, который будет закрывать необходимые потребности, всегда работать, делать это одинаково в разных кейсах (в разных облаках и т.п.), всегда поддерживаться в актуальном состоянии.
Если же «по верхам» сравнивать с Calico, то Cilium:
Технически хорош. И по своей производительности (например), и по своим фичам (observability с Hubble, крутые политики).
Был раньше и очень популярен сегодня. 12,4k vs 3,7k звёзд на GitHub, 438 vs 261 contributors и т.п.
Имеет поддержку индустрии: это выбор крупных провайдеров (AWS и GCP), это проект CNCF.
Поэтому при необходимости что-то выбрать наш выбор пал именно на него.
Давайте рассмотрим фантастический пример, что некто решил отказаться от услуг Фланта и хочет удалить всех фланто-пользователей?
Так ведь отобрать всех пользователей по почте с доменом flant (других мы не добавляем) — это же стандартная операция. Да, это не так изящно, как с отключением отдельного каталога, но и сложности ведь здесь нет.
О какой "привязке" вы говорите? У клиента в любом случае (и с glaball, и без него) полноценный инстанс GitLab со всеми фичами. Никаких "новых" фич решение не приносит, оно использует уже существующие - просто делает это на множестве инсталляций.
Здесь было их сравнение.
Не согласен с вами. В английском не склоняются существительные, но в русском языке этому правилу лучше следовать. Пусть многие в техническое среде так не делают, это явление — оно вовсе не о правилах и красоте речи...
«Я купил Tesla»/«Я еду на Tesla» или «Я купил Теслу»/«Я еду на Тесле»? Конечно, второе! Первое звучит не по-русски, а возможны случаи, когда попросту не будет передавать верный смысл/вводить в заблуждение (не зря же слова в русском языке склоняются).
Но от русскоязычного написания англоязычных названий я бы тоже воздержался. Может быть, конкретно с Теслой это ещё и прокатит, потому что уже привыкли, но вот со многими другими названиями будет больше проблем, чем пользы.
Идеальный вариант — добавлять русское существительное перед брендом, которое склонять: «Я купил машину Tesla». Но при частом употреблении может получиться довольно громоздко.
В общем, добавление русских окончаний англоязычным терминам не более нелепо, чем их употребление вовсе без окончаний.
UPD. По беглому анализу свежих данных последнего опроса от CNCF (https://github.com/cncf/surveys/tree/main/cloudnative) у меня получилось, что containerd используют в production 42% опрошенных (+25,5% пробуют), а CRI-O — менее 15% (+17,5% пробуют).
На всякий случай примечание для тех, кому это может быть важно: Dragonfly — это не Open Source, а BSL (Business Source License).
Пришел в комментарии с тем же вопросом. Кажется, что преимущество в сообществе всё-таки у containerd, а это зачастую означает, что остальные плюсы тоже скорее у него (больше юзеров - больше кейсов и исправлений, реализации запросов юзеров и т.п.). Если это не какое-то узкое/нишевое решение, конечно, но в данном случае речи об этом нет.
CRI-O - это видение Red Hat, которое пытаются сделать массовым. А containerd - реальный (действующий) выбор сообщества и индустрии. Ведущие мировые облачные провайдеры используют именно containerd. В этой таблице от Oracle можно наглядно увидеть. А здесь обсуждается вопрос потенциальной поддержки CRI-O в EKS.
Наконец, containerd - это уже давно (с 2019 года) graduated project в CNCF (https://www.cncf.io/announcements/2019/02/28/cncf-announces-containerd-graduation/), а CRI-O - до сих пор incubating (https://www.cncf.io/projects/cri-o/), что подчеркивает разницу в их зрелости/принятии индустрией.
На фоне этого обоснование вашего выбора выглядит иначе. Каковы были действительные причины? :-)
Да, сильно вырос. Например, есть такая публичная информация.
2006 год указан в описании самого проекта ВсеИнструменты, это момент основания компании. А далее (в следующем абзаце) написано:
Релиз Kubernetes 1.26 отложили до 8 декабря (т.е. будет этой ночью) из-за security updates к Go (вышли версии 1.19.4 и 1.18.9).
(Это про первую часть вопроса.)
Делать SEO-тексты на Хабре прямо с ссылками на ключевых словах, ведущими на сайт компании, — это катастрофа.
А в чем вопрос? На комментарии к статьям, которые являются переводами от других авторов... да ещё и к старым таким статьям - отвечают с куда меньшей вероятностью...
Появился официальный анонс релиза в блоге проекта: Kubernetes v1.25: Combiner.
Отвечали в статье с анонсом поддержки.
Год назад на Хабре уже был обзор Lens.
По терминологии есть куда более широкий диапазон вариантов.
Только вот во всем этом многообразии по-настоящему устоявшихся терминов (единых, общепринятых, универсальных) до сих пор скорее нет, чем есть. А в русскоязычном сообществе эта проблема, по моим ощущениям, не особо о(б)суждается.
Calico — хорошее решение! Но нам нужно что-то выбирать. Идея Deckhouse не в том, чтобы собрать в одном месте все возможные реализации каких-то задач, потому что кто-то предпочитает что-то по своим причинам, а предоставить пользователям решение каждой задачи надёжным, проверенным способом, который будет закрывать необходимые потребности, всегда работать, делать это одинаково в разных кейсах (в разных облаках и т.п.), всегда поддерживаться в актуальном состоянии.
Если же «по верхам» сравнивать с Calico, то Cilium:
Технически хорош. И по своей производительности (например), и по своим фичам (observability с Hubble, крутые политики).
Был раньше и очень популярен сегодня. 12,4k vs 3,7k звёзд на GitHub, 438 vs 261 contributors и т.п.
Имеет поддержку индустрии: это выбор крупных провайдеров (AWS и GCP), это проект CNCF.
Поэтому при необходимости что-то выбрать наш выбор пал именно на него.
Так ведь отобрать всех пользователей по почте с доменом flant (других мы не добавляем) — это же стандартная операция. Да, это не так изящно, как с отключением отдельного каталога, но и сложности ведь здесь нет.
О какой "привязке" вы говорите? У клиента в любом случае (и с glaball, и без него) полноценный инстанс GitLab со всеми фичами. Никаких "новых" фич решение не приносит, оно использует уже существующие - просто делает это на множестве инсталляций.
Отдельная заметка про айсберг из этого доклада (и его успех в сообществе :-)): Kubernetes is an iceberg.