The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

LXD будет развиваться компанией Canonical отдельно от проекта Linux Containers

05.07.2023 23:10

Команда проекта Linux Containers, развивающая инструментарий для организации работы изолированных контейнеров LXC, менеджер контейнеров LXD, виртуальную ФС LXCFS, инструментарий сборки образов distrobuilder, библиотеку libresource и runtime lxcri, объявила, что менеджер контейнеров LXD отныне будет отдельно разрабатываться компанией Canonical. Компания Canonical, которая является создателем и основным разработчиком LXD, после 8 лет разработки в составе Linux Containers, решила, что LXD более оптимально развивать как корпоративный проект, а не проект независимого сообщества. Разработка остальных проектов Linux Containers останется без изменений.

Код LXD перенесён из репозитория lxc/lxd в canonical/lxd, а основной страницей проекта стала ubuntu.com/lxd. Инфраструктура непрерывной интеграции для LXD будет переведена на серверы Canonical. При сборке образов для Linux Containers перестанут использоваться системы, предоставляемые Canonical. Сервер сборки образов, ранее используемый для LXC и LXD, сохранится, но число задействованных при сборке архитектур будет сокращено до x86_64 и aarch64.

LXD предоставляет средства для централизованного управления контейнерами, развёрнутыми в кластере из нескольких серверов. Код LXD написан на языке Go и распространяется под лицензией Apache 2.0. В качестве runtime для запуска контейнеров используется инструментарий LXC. LXD реализован в виде фонового процесса, принимающего запросы по сети через REST API и поддерживающего различные бэкенды хранилищ (дерево директорий, ZFS, Btrfs, LVM), снапшоты со срезом состояния, live-миграцию работающих контейнеров с одной машины на другую и средства для хранения образов контейнеров.

  1. Главная ссылка к новости (https://groups.google.com/a/li...)
  2. OpenNews: Выпуск системы управления контейнерами LXC 5.0
  3. OpenNews: Выпуск инструментария управления контейнерами LXC и LXD 4.0
  4. OpenNews: Уязвимость в runc и LXC, затрагивающая Docker и другие системы контейнерной изоляции
  5. OpenNews: Выпуск системы управления контейнерами LXD 5.0
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/59386-lxd
Ключевые слова: lxd, lxc, canonical
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (76) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Chromium (ok), 23:22, 05/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –9 +/
    Там LXD, там Snap, там LXC. Как всю эту дрянь отличать?
     
     
  • 2.19, Аноним (19), 05:07, 06/07/2023 [^] [^^] [^^^] [ответить]  
  • +21 +/
    Очень просто. LXC неплохая контейнерная изоляция, в отличии от докера это полноценная система и исплльзуешь её полноценно, т.е. никаких "один процесс на образ", вот прям как на реальной системе за исключением ограничений контейнеров (они и в докере такие же и в runc). Файловая система просто на диске располагается в /var/lib/lxc, красота в общем. Единственное не забудьте трафик разрешить через бридж lxcbr. Из недостатков что менее популярна докера, исключительно по этой причине настраивается немного тяжелее.
    LXD это корпоративная обёртка над LXC. Что-то вроде openshift или k8s в докуберовскую эпоху. Если вы не просто тестируете/запускаете отдельный софт на lxc, а хотите развернуть инфраструктуру, то можете посмотреть в эту сторону. Особо не пользовался. Дока есть. Рассчитано на корпоратов с соответствующими проблемами от каноникал. В век кубера перспектив у неё не много, нужно все хорошенько взвесить прежде чем на неё перейти.
    Snap это попытка принести контейнеры на десктоп "обычным пользователям"(кто это не уточняется). На самом деле крайне неудачная попытка крайне неудачной идеи пакетирования всего (windows like). Каноникл хотят денег, но не хотят работать и снап должен был решить эту диллему. Но даже среди богомерзких всепакетов снап оказался худшим, поэтому даже извращенные сообщества его не приняли. Но каноникл наплевать: у неё есть база убунты, куда она насильно его пропихивает. Скорее всего не осилит и как и другие поделки каноникл через несколько лет будет признано неудачным, отдадут "сообществу на поддержку" и перейдут на гно^W flatpack.

    tl;dr
    LXC - норм, если нужна околополноценная условно изолированная система без виртуплизации
    LXD - для корпоратов
    Snap - мертворожденный способ "доставки приложений"^W^W бесконечных проблем для пользователей

     
     
  • 3.30, JackONeill (?), 08:29, 06/07/2023 [^] [^^] [^^^] [ответить]  
  • +3 +/
    ... вроде k8s в докуберовскую эпоху... Что?
     
     
  • 4.34, Аноним (34), 10:03, 06/07/2023 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Необходимость разворачивать контейнеры на кластере из МНОЖЕСТВА машин появилась ещё задолго до кубернетеса. Особенно в провайдерской среде, где каждый пилил что-то своё, и я в том числе.
     
  • 3.35, Аноним (35), 10:19, 06/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > LXC неплохая контейнерная изоляция, в отличии от докера это полноценная система и исплльзуешь её полноценно
    > LXC - норм, если нужна околополноценная условно изолированная система
     
     
  • 4.65, rshadow (ok), 20:19, 06/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Все так. LXC это скорее про создать легкую виртуалку с полноценным окружением. k8s это скорее про разворачивание софта, ближе к stateless.
     
  • 3.38, Всем Анонимам Аноним (?), 11:23, 06/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    нет таких ограничений и нет системы в контейнере просто если нужно больше, че... большой текст свёрнут, показать
     
  • 3.46, Аноним (46), 15:03, 06/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > LXD это корпоративная обёртка над LXC. Что-то вроде openshift или k8s в докуберовскую эпоху.

    Поспорил бы. LXD этот как libvirt  для qemu.

     
     
  • 4.54, Аноним (54), 15:43, 06/07/2023 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Обёртка над несколькими разными штуками. Типа - комбайн.

    Ещё есть Vagrant от HashiCorp. Полюбопытнее будет, т.к. в нём на Руби можно докрутить логику конфигурации и провижонинг запускаемой сушности.

     
     
  • 5.61, Аноним (61), 17:48, 06/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Если говорить о практическом применении, то в LXD есть все необходимые механизмы для кастомизации и конфигураций (да хоть через банальный cloud-init), и провижининга. Знаю по собственному опыту, для разных заказчиков делал на LXD сборочные фермы, автоматизацию провижининга k8s кластеров для автоматического тестирования, девелоперских песочниц и для прода, менеджмент виртуальных машин, и так по мелочи для запуска сервисов в контейнерах. Настолько понравилось, что даже дома в LXD гоняю виртуалки и контейнеры со всяким барахлом.
     
  • 3.79, Chromium (ok), 19:30, 07/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    gt оверквотинг удален Спасибо за обратную связь и доступное грамотное объяснен... большой текст свёрнут, показать
     
     
  • 4.82, Аноним2 (?), 20:28, 08/07/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Нет :)
     
     
  • 5.83, Chromium (ok), 20:44, 08/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Нет :)

    Шо опять не так? Всё так было хорошо в моих фантазиях.

     
     
  • 6.88, swarus (?), 00:55, 16/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    lxd это управление lxc (быстрые контейнеры к ним каноктикалы никакого отношения не имеют), snap тормозной запуск-изоляция приложений на тормозных fuse fs, общего между lxc и snap (но не lxd) это использование механизма cgroups
     
  • 2.36, Минона (ok), 10:37, 06/07/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Там чудеса, там леший бродит, русалка на ветвях сидит...
     
  • 2.71, microcoder (ok), 07:40, 07/07/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    LXD (D = daemon) - это демон, сервер
    LXC (С = client) - это клиент к этому серверу контейнеров
     
     
  • 3.73, Аноним (73), 09:28, 07/07/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не вводите людей в заблуждение LXC образован от "LinuX Containers", это более низкий уровень, чем LXD, поэтом LXD скорее клиент к LXC.
     
     
  • 4.87, microcoder (ok), 21:45, 09/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Не вводите людей в заблуждение LXC образован от "LinuX Containers", это более низкий уровень, чем LXD, поэтом LXD скорее клиент к LXC.

    Не вводи сам людей в заблуждение, это так было в первых версиях, уже прошло с того времени много лет и переписали всю концепцию кажется с версии 2.0, а на дворе уже 5-ая версия.

     
  • 2.78, Chromium (ok), 19:11, 07/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Там LXD, там Snap, там LXC. Как всю эту дрянь отличать?

    Чё анальники минусов натыкали? Кто-то должен красноглазием днями заниматься?

     

  • 1.3, Аноним (3), 23:37, 05/07/2023 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • –1 +/
     

     ....ответы скрыты (4)

  • 1.5, Аноним (61), 23:44, 05/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    LXD годнейший проект, жаль будет если сделают убунтуспецифичным или вовсе закроют.
     
     
  • 2.33, Аноним (73), 09:17, 06/07/2023 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Ничего не изменится, Canonical и так всегда пилил LXD в одиночку, просто сейчас решил убрать некоторые лишние цепочки для ускорения разработки. Идея была привлечь сообщество к работе над LXD, но никто из крупных компаний этим так и не заинтересовался.
     

  • 1.6, Аноним (6), 23:46, 05/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    я знаю  L-xde, но я не знаю сабж
     
  • 1.10, Аноним (10), 00:06, 06/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Какой-то парад суверенитетов.
     
     
  • 2.17, Витюшка (?), 03:04, 06/07/2023 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Эпоха open source закончилась.

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

    Базовые бесплатные вещи (Java) теперь требуют конских лицензий по 100к баксов в год.

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

    Привет всем с лицензией Apache 2.0 и MIT.

    Самым надёжным остаётся JavaScript и Web. Но не долог тот час , когда закроют и V8.

     
     
  • 3.21, Аноним (21), 05:12, 06/07/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Тебе никто не мешает наваять форков версий с последней открытой лицензией, а потом стать судебным троллем, отстаивающим права общества в свой личный карман.
     
  • 3.22, Аноним2 (?), 05:14, 06/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ты видимо не понял что такое опенсурс.
    Его нельзя закончить, он вечен как сама вселенная.
    Ну а веб всегда был под крылом wc3 и корпораций. Тем более js и v8.
     
     
  • 4.55, Витюшка (?), 15:44, 06/07/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Всё с точностью до наоборот. А так всё верно.
     
  • 3.59, Kuromi (ok), 16:58, 06/07/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    На самом деле причина очень простая. Инфляция и конец эпохи дешевых денег. Центробанки повсеместно поднимают ключевыеставки, кредиты дорожают, инвесторы начинают требовать выхода на окупаемость, а лучше так прибыль, прием не ХХХ через 10-15 лет, а Х-ХХ, но через год-два.
    Отсюда все эти содрагания Твиттора, Убера и прочих "мы стоим дофига притом что до сих пор убыточны" компаний. Инвесторы сокращают аппетит к риску.
    Вот и IBM закрывают "халяву", бесплатные продукты становятся платными, массовые сокращения в компаниях и так далее.

    Легко рости когда кредиты околохалявные, а при ХХ% в год - совсем иная ситуация.

     
     
  • 4.64, Витюшка (?), 19:50, 06/07/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Очень грамотный комментарий. Прям приятно было почитать. Пожалуй, со всем соглашусь.

    Но меня это больше интересует в контексте свобод ПО. Именно сейчас стала понятна ценность GPL (от поклонника Apache 2.0) - невозможность смены лицензии.

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

    Что с того что есть какой-то Open Source выше Java (в виде библиотек), если сама Java теперь несвободная. Нижние уровни подрывают всю экосистему.

     
  • 4.66, Аноним2 (?), 20:48, 06/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Тоже подтвержду что так и есть. Гигант где я работаю, впервые в двух десятилетиях начал жить на свои деньги. До этого все вкладывал в развитие, за счет этого поднимал новые инвестиции и жил на них.
     
  • 4.67, Аноним (67), 21:00, 06/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >Вот и IBM закрывают "халяву", бесплатные продукты становятся платными, массовые сокращения в компаниях и так далее

    Все верно, кроме IBM и халяву. Никогда ни у ibm, ни у redhat небыло бесплатных продуктов. Всякие centos не есть их продукт. Кто сталкивался с тырпрайзом подтвердят. А кто не сталкивался, тем хоть centos, хоть debian, хоть freebsd одинаково полезны. Кто-то там закрывает debian или *bsd? Вот и нечего ныть.

     

  • 1.15, К.О. (?), 02:58, 06/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Они всё ещё думают составить конкуренцию докеру.

    Если в Редхате поскрипели мозгами и придумали как сделать совместимый продукт с кучей плюшек, то Каноникал пилит очередной самобытный велосипед.

    Будто от их энтерпрайзного шильдика он станет чуть более нужным.

     
     
  • 2.18, Аноним (18), 03:17, 06/07/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Им бы с подманом хотябы сконкурировать. До докера со всеми его минусами ему как до луны
     
     
  • 3.23, Аноним (21), 05:16, 06/07/2023 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Давай в 2023 сравнивать виртуализацию со средством размещения одной приложухи.
     
     
  • 4.69, К.О. (?), 06:06, 07/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Давай в 2023 сравнивать виртуализацию со средством размещения одной приложухи.

    Для виртуализации есть libvirt. Или имеется в виду такая "виртуализация" как у OpenVZ?

     
  • 3.24, Аноним2 (?), 05:17, 06/07/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В смысле до кубера?
    С докером то может lxc конкурировать и то кажется там все поделено: для доставки приложений докер, для доставки "систем" lxc. В разных нишах они.
    Да и корпораты потихоньку от докера в пользу runc и отдельных сборщиков отказываются.
     
  • 2.25, Аноним (25), 05:31, 06/07/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Зачем Canonical пилить очередной Docker?

    LXC, LXD - это не аналог Docker, Podman, k8s. И если поймёшь это, то подобную хрень писать не будешь.

     
     
  • 3.70, К.О. (?), 06:18, 07/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > LXC, LXD - это не аналог Docker, Podman, k8s.

    Не аналог, а велосипед. Контейнеры и libvirt умеет запускать, если надо.

    Или предполагается, что это такой убийца OpenVZ? Так они лет на пятнадцать с этим опоздали.

     
  • 2.27, soarin (ok), 06:23, 06/07/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Это не про Docker.
    Вот LXD не пользовался.
    А Multipass от Canoical прям зашло. Для разработки очень удобно.
     
  • 2.42, Пряник (?), 11:41, 06/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Docker для запуска одиночных процессов, а LXD для запуска множества.
     
     
  • 3.47, Аноним (54), 15:05, 06/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Не. Они KVM/QEmu запускают через LXD тоже.

    А тогда это всего-то обёртка над всеми обёртками. И если обёртка не развита как всё остальное, то лучше брать под конкретную задачу готовые, специально сделанные инструменты оркестровки.

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

     
  • 3.50, Аноним (46), 15:11, 06/07/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    сколько ты задашь процессов, столько и запустятся.
     
     
  • 4.57, Аноним (54), 15:53, 06/07/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Скорее что, не для, а с расчётом на профит от минимума процессов в контейнере.

    Но на это из коробки "все" забили. Да ещё прокидывая снаружи внутрь сокеты для выхода за пределы песочницы. Ну и прочие были недостатки у новомодной придумки.

     
  • 3.68, К.О. (?), 06:03, 07/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Docker для запуска одиночных процессов, а LXD для запуска множества.

    Ничто не мешает в контейнере Docker запустить хоть один процесс, хоть сотню.

    Хоть от одного пользователя, хоть от сотни разных.

    Посмотри как собраны образы Dovecot или FreeIPA, например.

    В Podman сто лет как можно запускать контейнер с systemd, дальше запускай всё, что тебе хочется.

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


     
     
  • 4.72, microcoder (ok), 07:46, 07/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >> Docker для запуска одиночных процессов, а LXD для запуска множества.
    > Ничто не мешает в контейнере Docker запустить хоть один процесс, хоть сотню.
    > Хоть от одного пользователя, хоть от сотни разных.
    > Посмотри как собраны образы Dovecot или FreeIPA, например.
    > В Podman сто лет как можно запускать контейнер с systemd, дальше запускай
    > всё, что тебе хочется.
    > Вопрос только в том, нужно ли использовать контейнеры таким образом.

    1) Докер живёт, пока живёт процесс.
    2) LXD живёт пока запущен контейнер. Процессы могут жить (пользовательские), а могут помереть, но контейнер сохранит своё состояние и продолжит работу

    Вот, основная разница

     
     
  • 5.75, К.О. (?), 14:49, 07/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    >> Ничто не мешает в контейнере Docker запустить хоть один процесс, хоть сотню.
    >> Хоть от одного пользователя, хоть от сотни разных.
    >> Посмотри как собраны образы Dovecot или FreeIPA, например.
    >> В Podman сто лет как можно запускать контейнер с systemd, дальше запускай
    >> всё, что тебе хочется.
    >> Вопрос только в том, нужно ли использовать контейнеры таким образом.
    > 1) Докер живёт, пока живёт процесс.
    > 2) LXD живёт пока запущен контейнер. Процессы могут жить (пользовательские), а могут
    > помереть, но контейнер сохранит своё состояние и продолжит работу
    > Вот, основная разница

    Спасибо, коллега.

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

     
     
  • 6.77, Жордж (?), 15:49, 07/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Да всем хватит простой дедовской виртуальной машины. Придумали эти контейнеры зачем-то.
     
     
  • 7.81, К.О. (?), 12:54, 08/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Да всем хватит простой дедовской виртуальной машины. Придумали эти контейнеры зачем-то.

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

    Запустил, прихлопнул, сохранил только то, что тебе действительно надо.

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

    Контейнер без запущенных процессов в общем случае не нужен.

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

     
  • 4.74, Пряник (?), 10:25, 07/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    То что технически можно выстрелить себе в ногу не означает, что так нужно делать. Docker задумывался под изоляцию сервисов между собой. Например, docker logs выводит только один поток логов. Конечно, nginx/apache/postfix плодят дочерние процессы, но это считается одним сервисом. Но между собой эти программы нужно класть в разные контейнеры Docker.
     
     
  • 5.76, К.О. (?), 15:16, 07/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Nginx и Apache плодят дочек, а процессы Dovecot или, например, Rspamd просто запускают другие сервисы. При этом на несколько контейнеров их распилить невозможно. Я уж не говорю, что упомянутый Postfix сравнительно недавно научился писать логи в стандартный вывод, до этого без rsyslog было не обойтись. А Cyrus до сих пор вот не умеет.

    Понятно, что в идеале в одном контейнере должен работать один процесс. Но полно приложений, которым на это совершенно плевать.

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

     
  • 2.58, Аноним (54), 15:59, 06/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Они всё ещё думают составить конкуренцию докеру.

    Они думают как создать сообществу мягкую и тёплую среду для разраотки исключительно под вендора Каноникл для исклчительно единственного вендор магазина. Ну, может с MS ещё дуржить будут.

    LXD - для запуска и тестов разработок под вендора. Отсюда-то оно и в LXC умеет и в Qemu умеет. И в ком.строке ничего не надо указывать. Просто скачай готовое у папы. Напиши свой код. Опдати папе место в магазине. И продавай.

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

     

  • 1.31, Alex (??), 08:39, 06/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Поэтому они всячески противились завозу LXD в Debian, перед заморозкой сознательно не фиксили проблему, и сходу закрывали issue, сваливая все на Qemu. Еле достучались до спящего deb мейтейнера, состряпали костыль и в stable оно все-таки пролезло.
    Повели Канноникал себя крайне по ред-хатовски, как баги искать, так мы все такие GPL и Apache открытые, а в опенсорс релиз выкатить - сразу игнор перманентный.
     
     
  • 2.40, Аноним (40), 11:33, 06/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А как ещё они себя мягкому софту продадут?
     

  • 1.37, Аноним (37), 11:20, 06/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Контейнеры это тупиковая технология.
     
     
  • 2.39, Аноним (40), 11:31, 06/07/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тупиковая технология это пересборка мира для установки любой новой программы. Контейнер это лучший из существующих костылей.
     
  • 2.43, Пряник (?), 11:46, 06/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Контейнеры это всего лишь эксплуатация фишек ядра Linux: cgroups и namespaces. Как например lvm эксплуатирует подсистему device mapper. А представь скока ещё тайн и нераскрытых фишек таин в себе ядро Linux?
     
  • 2.48, Аноним (54), 15:07, 06/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Контейнеры это тупиковая технология.

    Ведроид хорошо взлетел.

    У Sun когда-то была гениальная идея с Jar и Java. До сих пор идея работает и равивается и развивается в разных видах.

     

  • 1.41, Пряник (?), 11:38, 06/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Печально. В тень уходит удобный аналог virsh для контейнеров, по удобству сравним с docker и может его заменить в большинстве случаев. Одна из причин ждать Debian 12 для меня была (помимо исправления бага с буфером обмена в gnome-terminal 3.38).
     
     
  • 2.49, Аноним (54), 15:10, 06/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Не то что б в тень. Но LXD ж засунут в Snap и заставят жить без ~/.* директорий, без остального сообщества, ограниченно и зажато.

    Узконаправленная, ограниченная среда. Вендор лок.

    Скука. Бесполезность.

     
     
  • 3.51, Аноним (46), 15:12, 06/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Но LXD ж засунут в Snap

    Давно уже.

     
     
  • 4.56, Аноним (54), 15:49, 06/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ещё недавно можно было собрать в Deb. Но опасения, что и это закончится. Если такими темпами.

    Когда люди пишут, что возможность автозапуска при загрузке системы сокрашает время загрузки, то такую ересь не пишут, когда действительно всё хорошо (https://forum.snapcraft.io/t/deploying-robotics-applications/29187). _Такие_ доводы применяют только от безисходности, при чём-то плохом.

     

  • 1.45, Анониссимус (?), 14:57, 06/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Использую proxmox. По-моему, их pct куда удобнее lxd. С pct я разобрался, один раз глянув в man. А lxd - какой-то инопланетный монстр. Впрочем, как и всё у канониклов.
     
     
  • 2.52, Аноним (54), 15:15, 06/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    У них как в скрипты всё не заглянешь, так потом думаешь: надо ли туда к ним или с ними чего-либо.

    Скорее, что нет, чем да. Но в задумчивость нерешетельности точно вгоняет.

     
     
  • 3.63, Анониссимус (?), 19:05, 06/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > У них как в скрипты всё не заглянешь, так потом думаешь: надо
    > ли туда к ним или с ними чего-либо.
    > Скорее, что нет, чем да. Но в задумчивость нерешетельности точно вгоняет.

    Меньше знаешь -- крепче спишь :) Дети, не заглядывайте в скрипты, а то это вгонит вас в задумчивость! :D

     

  • 1.53, Аноним (54), 15:17, 06/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > более оптимально развивать как корпоративный проект, а не проект независимого сообщества

    Кажись, что разумные люди послали их с их подходами и идеями.

    Значит больше с ними не по пути.

     
     
  • 2.60, Аноним (60), 16:59, 06/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    тебе что ли? ты про lxd только на опеннете в новостях и слышал, иксперд
     
     
  • 3.62, Аноним (54), 17:49, 06/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Не поверишь, в код к ним заглядывал.

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

    Дистр уходит в нишу, сходную со смартфонами: интернет вещей. Небольшие устройства, с функционалом для продажи, где не хотят чужого вмешательства. Под себя не поточить, без сложностей и сильных трат времени. О чём у Столмана и была претензия к принтеру, когда "всё началось" про OSS.

     
     
  • 4.80, Аноним (61), 21:17, 07/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Для них - нужно. Они для себя и делают. Для других - нет.

    Отучайся говорить за всех. Мне нужно, и я на LXD неплохо денег заработал. И ещё заработаю, если подвернётся контракт на эту тему.

     
     
  • 5.84, Аноним (54), 00:20, 09/07/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Не говори за всех. Кому-то - нужно, кому-то - нет, вместе уже с дистрибутивом.
     

  • 1.85, Аноним (85), 07:42, 09/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    кто то юзал LXCFS? для чего?
     
  • 1.86, Аноним (85), 07:43, 09/07/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    "live-миграцию работающих контейнеров с одной машины на другую"
    кто-то может подсказать как это сделать?
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру