Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Создан форк системы управления контейнерами LXD"	+/–
Сообщение от opennews (??), 05-Авг-23, 09:04
Алекса Сарай (Alexa Sarai), работающий в компании SUSE и занимающийся сопровождением пакетов с LXD в проекте openSUSE, создал репозиторий Incus, в котором намерен заниматься развитием форка системы управления контейнерами LXD. Форк создан после того, как компания Canonical, которая является создателем и основным разработчиком LXD, решила вывести LXD из разработки в составе сообщества  Linux Containers и развивать LXD в дальнейшем как корпоративный проект... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=59556
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. Скрыто модератором	–1 +/–
Сообщение от Аноним (1), 05-Авг-23, 09:04
Когда форк канонмкал сделают?
Ответить | Правка | Наверх | Cообщить модератору

2. "Создан форк системы управления контейнерами LXD"	–3 +/–
Сообщение от Аноним (2), 05-Авг-23, 09:08
Нужно изменить лицензию форка на несовместимую с родным проектом. И спокойно миром пилить недоступную им же крутотень.
Ответить | Правка | Наверх | Cообщить модератору

	5. "Создан форк системы управления контейнерами LXD"	+4 +/–
	Сообщение от Аноним (5), 05-Авг-23, 09:17
	Ага каждого коммитера спросить согласен ли он на это. План надёжный.
	Ответить | Правка | Наверх | Cообщить модератору

	13. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (13), 05-Авг-23, 10:11
	Не так уж и много там коммитеров.
	Ответить | Правка | Наверх | Cообщить модератору

	30. "Создан форк системы управления контейнерами LXD"	+1 +/–
	Сообщение от YetAnotherOnanym (ok), 05-Авг-23, 12:28
	И все согласятся? Гарантируешь?
	Ответить | Правка | Наверх | Cообщить модератору

	70. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Anon3 (?), 05-Авг-23, 15:54
	А зачем кого-то спрашивать? https://www.gnu.org/licenses/license-compatibility.ru.html Перевел на AGPL3 и все. Apache это ж свободная лицензия
	Ответить | Правка | Наверх | Cообщить модератору

	200. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Vindex (?), 07-Авг-23, 13:36
	"Перевёл - и всё" - это когда ты один. Но не любой разработчик согласится заменить лицензию своего кода. Форкнуть, сменив лицензию, тоже нельзя - это противоречит тексту большинства лицензий
	Ответить | Правка | Наверх | Cообщить модератору

	248. "Создан форк системы управления контейнерами LXD"	–1 +/–
	Сообщение от Anon3 (?), 08-Авг-23, 15:36
	> Форкнуть, сменив лицензию, тоже нельзя - это противоречит тексту большинства лицензий Сейчас мы, конкретно, говорим о смене лицензии Apache 2 на AGPL 3. Что и где, конкретно мне, запрещает форкнуть любой проект под Apache 2 и самостоятельно, единолично, не спрашивая авторов перевести его полностью под лицензию AGPL 3? Я ж не присваиваю авторство кода, а лицензию меняю. > Но не любой разработчик согласится заменить лицензию своего кода. Еще раз, его разрешения никто не обязан спрашивать. Пусть и дальше себе разрабатывает под Apache 2, а я потом буду перебивать лицензии его кода на AGPL 3 и буду extend его под AGPL 3 only. Разработчик, если разрабатывает под Apache 2, очевидно, не против этого, потому, что он за свободу любого использования кода.
	Ответить | Правка | Наверх | Cообщить модератору

	261. "Создан форк системы управления контейнерами LXD"	–1 +/–
	Сообщение от пох. (?), 09-Авг-23, 18:36
	> Сейчас мы, конкретно, говорим о смене лицензии Apache 2 на AGPL 3. Что и где, конкретно мне, > запрещает форкнуть любой проект под Apache 2 и самостоятельно, единолично, не спрашивая авторов > перевести его полностью под лицензию AGPL 3? текст лицензии. Который ты конечно же ниасилил. Единственное что ты мог бы - это _свои_ правки распространять под другой, ограничительной лицензией. Но ты не умеешь кодить, вот в чем заковыка.
	Ответить | Правка | Наверх | Cообщить модератору

	262. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Anon3 (?), 10-Авг-23, 01:55
	> текст лицензии. Который ты конечно же ниасилил. > Единственное что ты мог бы - это _свои_ правки распространять под другой, > ограничительной лицензией. 1. Вы должны предоставить всем другим получателям Работы и Производных работ, копию этой лицензии, и 2. Вы должны снабдить все модифицированные файлы явными уведомлениями, что Вы изменили файлы, и 3. Вы должны сохранить в Исходной форме любых Производных работ, которые вы распространяете, все авторские права, патенты, торговые марки, а также соответствующие атрибуции из Исходной формы Работы, за исключением тех, что не имеют отношения к какой-либо части Производной работы; и 4.... Где? Или вы о том, что необходимо приложить в исходный код саму лицензию Apache 2 и при правках обязательно указывать явно, что файл изменился? Но я ж уже наложил все ограничения AGPL 3, от меня не убудет. Так и представляю, как галера берет, такой код моего форка под AGPL 3 и выпиливает из него мои правки. Побежит искать изначальный проект под Apache 2, конечно же > Но ты не умеешь кодить, вот в чем заковыка. Спасибо, вот тут я понял, что я вообще архитек Если человеку говорят: "Твой код г.вно!" Ответ джуна: "Вы обесцениваете мой труд" Мидла: "Давайте подумаем как это исправить" Сеньера: "Да мой код г.вно" Архитека: "А чего ты туда полез?"
	Ответить | Правка | Наверх | Cообщить модератору

	75. Скрыто модератором	+2 +/–
	Сообщение от C00l_ni66a (ok), 05-Авг-23, 16:50
	Коммитеров спросить забыли.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	139. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от leap42 (ok), 06-Авг-23, 08:26
	> Ага каждого коммитера спросить согласен ли он на это. План надёжный. А это точно нужно делать, если оставить рядом доступной для скачивания старую версию, под старой лицензией? 🤔
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	186. "Создан форк системы управления контейнерами LXD"	+2 +/–
	Сообщение от Аноним (186), 07-Авг-23, 02:08
	Если код этих коммитеров продолжает использоваться в новой версии - да, надо спрашивать. Ну или их код выкидывать.
	Ответить | Правка | Наверх | Cообщить модератору

	265. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от пох. (?), 10-Авг-23, 15:34
	для apache можно не выкидывать а модифицировать. Но все равно надо уметь кодить - перебивка копирайтов в комменте это не модификация _кода_, не прокатит, дениски в пролете.
	Ответить | Правка | Наверх | Cообщить модератору

	20. "Создан форк системы управления контейнерами LXD"	+1 +/–
	Сообщение от Атон (?), 05-Авг-23, 10:41
	кому нужно, тот пусть и меняет.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

3. "Создан форк системы управления контейнерами LXD"	+/–
Сообщение от Аноним (5), 05-Авг-23, 09:10
Ну и хорошо может сделают вид контейнера, который будет удобно работать и удобно настраиваться. Недоумение вызывает лишь то почему все эти контейнеры не были сделаны ещё в 1995 году на C под эгидой Free Software Foundation. И стандартизованы как единственный правильный путь.
Ответить | Правка | Наверх | Cообщить модератору

	8. "Создан форк системы управления контейнерами LXD"	+2 +/–
	Сообщение от Аноним (8), 05-Авг-23, 09:50
	Контейнеры, вообще-то, стандартизированы.  https://en.m.wikipedia.org/wiki/Open_Container_Initiative В действующей в 1995 году версии ядра 1.х контейнеров не было.
	Ответить | Правка | Наверх | Cообщить модератору

	10. "Создан форк системы управления контейнерами LXD"	–1 +/–
	Сообщение от Аноним (5), 05-Авг-23, 09:54
	> started in June 2015 by Docker В том то и дело что это сбоку прикрученный костыль.
	Ответить | Правка | Наверх | Cообщить модератору

	35. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (35), 05-Авг-23, 13:00
	Докер добился куда большего, чем lxc. Прежде всего, создал единый универсальный формат пакетирования серверного ПО.
	Ответить | Правка | Наверх | Cообщить модератору

	53. "Создан форк системы управления контейнерами LXD"	–4 +/–
	Сообщение от пох. (?), 05-Авг-23, 14:00
	к сожалению. Было бы просто прекрасно если бы этот убогий недоделанный формат сдох вместе с докером. Но увы, рыночек опять порешал в пользу самого уе..щного зато понятного альтернативно-одаренным решения. На деле большую часть этого вашего недо-ПО можно было бы гораздо быстрее и проще завернуть в обычный tar и не тратить гигаватты на соврешенно ненужную чехарду.
	Ответить | Правка | Наверх | Cообщить модератору

	55. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (55), 05-Авг-23, 14:12
	>Но увы, рыночек опять порешал в пользу самого уе..щного зато понятного альтернативно-одаренным решения. Рыночек порешал так, как сказли манагеры. А манагерам сказали другие манагеры. А то ты не помнишь ту оголтелую пропаганду великого докера, лившуюся тогда из какждого утюга. Сейчас так rust пихают. И ведь пропихнут, судя по тому, что нашенские манагеры начинаю спрашивать: а сколько будет стоит на м на это модное перейти, уважаемые люди говорят, что это гуд и сулит прибыли. Так оно все и работает в этой вашей ойти.
	Ответить | Правка | Наверх | Cообщить модератору

	56. "Создан форк системы управления контейнерами LXD"	–6 +/–
	Сообщение от пох. (?), 05-Авг-23, 14:28
	> Рыночек порешал так, как сказли манагеры. ничего страшного, они и исполнителей подобрали себе подстать. Будешь хрустеть! (но кстати нет, или недолго - в долгую не покатит - докер решал проблему как сделать тяп-ляп. Хруст не решает а только создает новые проблемы, и прибыли от него скорее уж  упадут - галерный опоздал с релизом ненужной фичи потому что клиппи.) > Так оно все и работает в этой вашей ойти. если бы только в ойти.
	Ответить | Правка | Наверх | Cообщить модератору

	153. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Прохожий (??), 06-Авг-23, 12:41
	> Хруст не решает а только создает новые проблемы, и прибыли от него скорее уж  упадут Хотелось бы, конечно, более развёрнутое объяснение получить. Дождусь ли?
	Ответить | Правка | Наверх | Cообщить модератору

	156. "Создан форк системы управления контейнерами LXD"	–1 +/–
	Сообщение от пох. (?), 06-Авг-23, 14:24
	Надоело, сто раз вам тут этот бисер уже метали. Просто почитай логи моего любимого escopeta.swf..ой, простите, ruffle.rs - сколько там комитов "appease clippy" и как бы ты с позиции инвестора, который нихрена во всем этом не понимает и не собирается, а понимает только растущие продажи, на это скоморошество смотрел бы. И сравни это с дыркером, который действительно решил проблему "как выкатить релиз если он неспособен запуститься нигде кроме (виндового) локалхоста альтернативно-одаренного разработчика - причем срок исполнения позавчера" (т.е. некогда делать нормально, трясти надо).
	Ответить | Правка | Наверх | Cообщить модератору

	158. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Прохожий (??), 06-Авг-23, 15:24
	Видимо, ты всё-таки не бисер метал, а какую-то другую субстанцию, раз никто так до сих пор ничего не понял. Как я вижу ситуацию. 1. Есть проблема дырявости критического для бизнеса софта, которая дорого обходится всем: начиная от производителя (дырки-то, если хочешь ещё поторговать своим продуктом, латать надо же), заканчивая потребителем. 2. Если решать первую проблему, возникает проблема инфраструктурного плана: дополнительные зависимости, и, как следствие, возросшие расходы на техподдержку. Вопрос, как обычно, упирается, что выгодней: забивать на первое, или возиться со вторым. Если у тебя есть какая-то статистика, которая показывала бы, что вторая проблема дороже первой - давай её уже в студию. Потом что твоё личное мнение (каким бы умным ты ни был), меня не интересует от слова "совсем".
	Ответить | Правка | Наверх | Cообщить модератору

	160. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от пох. (?), 06-Авг-23, 16:20
	> Видимо, ты всё-таки не бисер метал, а какую-то другую субстанцию, раз никто > так до сих пор ничего не понял. да нет, почему никто. Просто они не комментируют, как правило - им-то и так понятно. > 1. Есть проблема дырявости критического для бизнеса софта, которая дорого обходится всем: нету. Ну в смысле бизнес радостно не считает это проблемой. Ни с какой, обрати внимание, стороны от мушки. Дыркер - это вот как эту проблему аккуратно переложить на никого. И - смотри-ка - с успехом зашел. > 2. Если решать первую проблему, возникает проблема инфраструктурного плана: дополнительные нет. Возникает ровно одна проблема - те кто сделал хорошее решение, но на два часа позже - прое...ли рынок. Хрошие решения (_даже_ если на секунду предположить что от переписывания на чудо-языке плохая программа вдруг станет хорошим решением) инвестору (опечатка, читай - финансовому спекулянту, нихрена не понимающему во что он там наинвестировал) не нужны. Ему нужны - прибыльные здесь и сейчас. поэтому на рыночке порешают всегда самые плохие решения.
	Ответить | Правка | Наверх | Cообщить модератору

	168. "Создан форк системы управления контейнерами LXD"	–1 +/–
	Сообщение от Прохожий (??), 06-Авг-23, 23:15
	> Ну в смысле бизнес радостно не считает это проблемой. Расскажи это руководителям фирм, которые пострадали от хакеров, например (понятно, что там дело не только в утечках памяти и прочих побочных эффектах Си). На кого Докер переложил проблему дыр в ОС и прочем софте, написанном на древнющем и морально устаревшем языке? СУБД, например, по-прежнему падают от утечек памяти, в самый неподходящий момент. Во сколько обходятся такие простои, если у тебя в секунду доход от нескольких тысяч зелёных? Наверное, ты мне сейчас про кластеры начнёшь рассказывать и прочие средства по отказоустойчивости. Но нет, они не всегда спасают в таких случаях. > Возникает ровно одна проблема - те кто сделал хорошее решение, но на два часа позже - прое...ли рынок. Что даёт тебе основания утверждать, что на Си можно такие "хорошие" решения сделать гораздо быстрее, чем на том же Rust? Спонсоры Rust считают иначе почему-то. Почему? > Хорошие решения (_даже_ если на секунду предположить что от переписывания на чудо-языке плохая программа вдруг станет хорошим решением) инвестору (опечатка, читай - финансовому спекулянту, нихрена не понимающему во что он там наинвестировал) не нужны. Ему нужны - прибыльные здесь и сейчас. Ты сейчас сам с собою споришь. В предыдущем своём сообщении я и говорил о прибыльности, как об основном критерии хорошести.
	Ответить | Правка | Наверх | Cообщить модератору

	188. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от User (??), 07-Авг-23, 07:08
	>На кого Докер переложил проблему дыр в ОС и прочем софте, написанном на древнющем и морально устаревшем языке? СУБД, например, по-прежнему падают от утечек памяти, в самый неподходящий момент. Во сколько обходятся такие простои, если у тебя в секунду доход от нескольких тысяч зелёных? Наверное, ты мне сейчас про кластеры начнёшь рассказывать и прочие средства по отказоустойчивости. Но нет, они не всегда спасают в таких случаях. Внезапно - на оркестратор, который будет пинать в том числе СУБД. рСУБД не умеет? Ну будет не-р-СУБД. А "другого IT" не будет - по крайней мере до момента выноса из него 95% мешков-с-мясом, которым - вот беда! свойственно ошибаться. Имманентно свойственно - и язык на букву Ры (Ды, Зы-вставить\зачеркнуть) этого никак не изменит.
	Ответить | Правка | Наверх | Cообщить модератору

	242. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Прохожий (??), 08-Авг-23, 12:43
	> Ну будет не-р-СУБД Очень смелое заявление. > Имманентно свойственно - и язык на букву Ры (Ды, Зы-вставить\зачеркнуть) этого никак не изменит. Уже меняет, хотя и не коренным образом. Общее количество ошибок уменьшается. Это ведь тоже своего рода замена мешков-с-мясом на умный компилятор.
	Ответить | Правка | К родителю #188 | Наверх | Cообщить модератору

	245. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от User (??), 08-Авг-23, 14:09
	> Очень смелое заявление. Ну, у меня окрест ни одного проекта без какой-нибудь NoSQL лет несколько уже нет, а то, что есть как правило какими-нибудь "персистирующими слоями", "шинами данных" и разнообразым ETL'ем обмазано. > Уже меняет, хотя и не коренным образом. Общее количество ошибок уменьшается. Это > ведь тоже своего рода замена мешков-с-мясом на умный компилятор. "Софт КОНЦЕПТУАЛЬНО не надежен" - константа бытия, которую "умный компилятор" не меняет ровным счетом "никак" - отказоустойчивость _системы_ обеспечивается НЕ путем переписывания на "более другие" языки и даже не "формальной верификацией"
	Ответить | Правка | К родителю #242 | Наверх | Cообщить модератору

	247. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Прохожий (??), 08-Авг-23, 15:31
	> Ну, у меня окрест ни одного проекта без какой-нибудь NoSQL лет несколько уже нет, а то, что есть как правило какими-нибудь "персистирующими слоями", "шинами данных" и разнообразым ETL'ем обмазано. Это не говорит никак о том, что РСУБД своё отжили, не правда ли? Просто добавился дополнительный инструментарий (можно сказать, ещё один уровень абстракции). > "Софт КОНЦЕПТУАЛЬНО не надежен" - константа бытия, которую "умный компилятор" не меняет ровным счетом "никак" - отказоустойчивость _системы_ обеспечивается НЕ путем переписывания на "более другие" языки и даже не "формальной верификацией" Избавление от всех ошибок никакой компилятор, разумеется, не гарантирует. Однако же предлагаю не заниматься софистикой в духе "Два - это куча или нет". Количество сбоев переписыванием на другой язык всё же существенно уменьшается (Гугл, МС не дадут соврать), как и количество сопутствующих убытков. Разумеется, при этом никто не запрещает/не отговаривает применять параллельно другие средства для обеспечения отказоустойчивости системы (которые, как хорошо известно, тоже не являются серебряной пулей).
	Ответить | Правка | К родителю #245 | Наверх | Cообщить модератору

	260. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от User (??), 09-Авг-23, 08:00
	> Это не говорит никак о том, что РСУБД своё отжили, не правда > ли? Просто добавился дополнительный инструментарий (можно сказать, ещё один уровень абстракции). "Отжили" - такое интересное понятие... скорее "вытесняются в определенную (причем достаточно узкую по сравнению с тем что было лет 20 назад) нишу". > Избавление от всех ошибок никакой компилятор, разумеется, не гарантирует. Однако же предлагаю > не заниматься софистикой в духе "Два - это куча или нет". > Количество сбоев переписыванием на другой язык всё же существенно уменьшается (Гугл, > МС не дадут соврать), как и количество сопутствующих убытков. Разумеется, при > этом никто не запрещает/не отговаривает применять параллельно другие средства для обеспечения > отказоустойчивости системы (которые, как хорошо известно, тоже не являются серебряной > пулей). Архитектура ИС сформирована концептуальной ненадежностью софта и от изменения количества ошибок на 5% это никоим образом не изменится. Предупреждая вопросы - и на 10% тоже.
	Ответить | Правка | К родителю #247 | Наверх | Cообщить модератору

	169. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Прохожий (??), 06-Авг-23, 23:21
	> Ну в смысле бизнес радостно не считает это проблемой. Ещё как считает. Хотя не только это, конечно. Решающими факторами остаются удобство эксплуатации и охват предметной области. Почему, по-твоему, куча фирм платят неплохие вознаграждения белым хакерам, если бизнесу пофиг?
	Ответить | Правка | К родителю #160 | Наверх | Cообщить модератору

	197. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от qrKot (?), 07-Авг-23, 11:34
	>> Есть проблема дырявости критического для бизнеса софта, которая дорого обходится всем: начиная от производителя (дырки-то, если хочешь ещё поторговать своим продуктом, латать надо же), заканчивая потребителем. Нету такой проблемы. Вы ее выдумали. Проблема "если случится сценарий А, нас оштрафуют на сумму Б" - есть. Решение по ней принимается очень просто: если сумма Б значительно больше, чем сумма В, требуемая на рефакторинг - рефачим. Если сумма В больше, чем Б - продолжаем "жить с этим". Там еще миллион других проблем есть, но вашей - не существует.
	Ответить | Правка | К родителю #158 | Наверх | Cообщить модератору

	216. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от пох. (?), 07-Авг-23, 20:23
	Блин, ты хорошо понимаешь что рефакеры и те у кого есть суммы сравнимые с Б - скорее всего даже в пределах одного офиса не находятся? Проблемы действительно не существует. У владельца суммы Б совсем другие проблемы.
	Ответить | Правка | Наверх | Cообщить модератору

	243. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Прохожий (??), 08-Авг-23, 12:46
	> Нету такой проблемы. Вы ее выдумали. Конечно, есть. Многие крупные производители софта платят белым хакерам зачем? Только не надо говорить, что ради рекламы. Кроме того, не забываем об облаках, куда некоторые переезжают, и где облачные провайдеры гарантируют то или иное количество "девяток".
	Ответить | Правка | К родителю #197 | Наверх | Cообщить модератору

	159. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Прохожий (??), 06-Авг-23, 15:32
	Я ещё немного поразмышляю. Если решать постепенно (ключевое слово) решать проблему один, то проблема два в течение некоторого времени исчезнет, как таковая. Таким образом, убиваем двух зайцев сразу (в какой-то отдалённой перспективе). При этом, надеюсь, мы (я и ты), не будем мешать в одну кучу людей и коней в нашей дискуссии, смешивая в одну массу несмешиваемое (ПО, которое работает на голом железе и ПО, которое можно виртуализировать).
	Ответить | Правка | К родителю #156 | Наверх | Cообщить модератору

	62. "Создан форк системы управления контейнерами LXD"	–2 +/–
	Сообщение от Аноним2 (?), 05-Авг-23, 15:14
	Подтверждаю, так и было. Докер был ощутимо хуже по многим параметрам (да и сейчас) но его активно продвигали.
	Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

	80. "Создан форк системы управления контейнерами LXD"	+2 +/–
	Сообщение от Аноним (80), 05-Авг-23, 17:50
	Эта часть истории прошла мимо меня. Можно рассказать какие были альтернативы, чем лучше, от кого и почему их закопали?
	Ответить | Правка | Наверх | Cообщить модератору

	116. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (35), 06-Авг-23, 00:33
	Ну вот выше некий непризнанный гений системного администрирования на полном серьёзе предлагают деплоить софт через tar-файлы.
	Ответить | Правка | Наверх | Cообщить модератору

	123. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Анончик (?), 06-Авг-23, 00:51
	Ощутимо хуже чего? Если вы про сабж то его небыло. Емли вы про формат файлов. Так докер умеет в так.
	Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

	129. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (35), 06-Авг-23, 01:03
	Но _не принуждает_ использовать этот золе*учий tar, как вы не понимаете! Жизнь труЪ админа должна быть полна боли и унижений, иначе он не труЪ, а хипстер в коротких штанишках [табличка: сарказм]
	Ответить | Правка | Наверх | Cообщить модератору

	71. "Создан форк системы управления контейнерами LXD"	+1 +/–
	Сообщение от Аноним (71), 05-Авг-23, 16:07
	А чего ты не сделал как надо? Докер нормальный формат, не кати бочку
	Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

	118. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (35), 06-Авг-23, 00:35
	> А чего ты не сделал как надо? Он и делал как надо. Далее - Далее - Далее - Готово. И никакие контейнеры не нужны.
	Ответить | Правка | Наверх | Cообщить модератору

	73. "Создан форк системы управления контейнерами LXD"	+5 +/–
	Сообщение от Admino (ok), 05-Авг-23, 16:11
	Опять альтернативно одарённые мешают жить непризнанным гениям от системного администрирования.
	Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

	222. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Легивон (?), 07-Авг-23, 20:46
	> На деле большую часть этого вашего недо-ПО можно было бы гораздо быстрее и проще завернуть в обычный tar и не тратить гигаватты на соврешенно ненужную чехарду. Вот это прямо вопиющая некомпитентность. Когда человек рассказывает как нужно сделать правильно, а оказывается, что оно изначально так уже и сделано, только чуть чуть расширено метаданными для юзабилити. На секундочку докер образ = буквально набор tar архивов, где каждый слой - отдельный tar! Каждый из которых можно извлеч отдельно и использовать так же отдельно просто как файлы (overlayfs это позволяет). --- Не думал что необходимо хотя бы немного ознакомиться с предметом, прежде чем его комментировать? Ты случаем не хипстор-вкатун которой нахватался вершков на курсах?
	Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

	228. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от пох. (?), 07-Авг-23, 22:35
	> Вот это прямо вопиющая некомпитентность. в общем, дальше, собственно, мог бы и не продолжать. КомпИтентный ты наш. > На секундочку докер образ = буквально набор tar архивов, где каждый слой - отдельный tar! это и есть ненужная чехарда. Помимо всей прочей.   > Каждый из которых можно извлеч отдельно и использовать извлечь можно, использовать отдельно ни для какой полезной цели нельзя. Это вторая часть ненужного ненужно. Как и ненужно-overlayfs, кстати. Можно назвать оверинжинирингом, но там инженеры и близко не пробегали. Только тяпляперы. > Не думал что необходимо хотя бы немного ознакомиться с предметом, прежде чем его комментировать? А ты не думал что, может это ты чего-то не понимаешь? Ну, разумеется, не думал, было бы - чем.
	Ответить | Правка | Наверх | Cообщить модератору

	253. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Легивон (?), 08-Авг-23, 19:04
	>в общем, дальше, собственно, мог бы и не продолжать. КомпИтентный ты наш. Нечего по существу ответить, да? Решил до правописания докапаться? >это и есть ненужная чехарда. Помимо всей прочей. tar архив - хорошо. несколько так архивов - ненужная чехорда. Хыхыхы. Приятно видеть, что ты осознал какую ерунду написал выше про tar и docker. Как нелепо с горящей 5 точкой пытаешься перекрыть мелочами и глупостями. Самому не смешно?
	Ответить | Правка | Наверх | Cообщить модератору

	254. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от пох. (?), 09-Авг-23, 00:19
	> Нечего по существу ответить да просто на такого интеллигентного собеседника время тратить - бестолку. > tar архив - хорошо. > несколько так архивов - ненужная чехорда. приятно видеть что до тебя хоть что-то начало доходить. тар архив из которого просто распаковывается содержимое - как вон в случае с nextcloud - да, вполне нормально. Речь, специально для д-лов полных - была именно об этом. этажерка таров (еще и именно ТАРОВ, блжд а не любых других типов архивов с произвольным доступом) могла придти в голову только альтернативно-одаренным разработчикам докера (даже автор дебиана был менее долбанутым, хотя инструмент на помойке нашел конечно удивительный). Распаковывать этот хлам вручную незачем и не для чего.
	Ответить | Правка | Наверх | Cообщить модератору

	12. "Создан форк системы управления контейнерами LXD"	+1 +/–
	Сообщение от Аноним (13), 05-Авг-23, 10:00
	Железо того времени не потянуло бы контейнеризацию?
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	16. "Создан форк системы управления контейнерами LXD"	–7 +/–
	Сообщение от Аноним (1), 05-Авг-23, 10:23
	Конечно железо, отсутсвие доступной поддержки виртуализации процессоров. Второй момент это отсутсвие лишних ресурсов, операционных системы, 64 кб не хватало всем. На то время запустить на голом железе систему уже победа была. Апач вышел в 1995, что контейнеризировать, doom запускать в докере? Автор настолько не понимает сути, что очевидно находится на уровне неоконченного среднего образования поворского коледжа
	Ответить | Правка | Наверх | Cообщить модератору

	19. "Создан форк системы управления контейнерами LXD"	+5 +/–
	Сообщение от Аноним (5), 05-Авг-23, 10:38
	Представь себе мой юный друг сервера и датацентры существовали даже в 1995 году. Твои 64кб были в калькуляторе 1985 года. В 1995 году уже была даже Windows 95 прикинь, сынок.
	Ответить | Правка | Наверх | Cообщить модератору

	24. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от пох. (?), 05-Авг-23, 10:57
	СМ1420 (мой любимый калькулятор, но довольно увесистый) выпускался серийно с 84го. 128k слов (двухбайтовых) в процессорной стойке и до двух мегабайт в дополнительной (правда, она наверное попозже появилась) PDP 11/70 с которой ее сдирали, подозреваю лет на десять постарше будет.
	Ответить | Правка | Наверх | Cообщить модератору

	39. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (35), 05-Авг-23, 13:05
	> В 1995 году уже была даже Windows 95 прикинь, сынок. Насколько я помню, у нее в рекомендованных спеках было 4 Мб оперативки.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	40. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (5), 05-Авг-23, 13:07
	Вот вот, а тут товарищ думает что в 1995 все ходили в мамонтовых шкурах и у них было 64 килобайта оперативы.
	Ответить | Правка | Наверх | Cообщить модератору

	42. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (35), 05-Авг-23, 13:09
	Как минимум, он где-то нолик потерял, если вспоминать высказывание Гейтса. Кроме того, оно явно датируется еще эрой MS DOS и Norton Commander.
	Ответить | Правка | Наверх | Cообщить модератору

	45. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (5), 05-Авг-23, 13:14
	Ну всё давай покопаемся в дебрях и вспомним что он такого не говорил и не подразумевал.
	Ответить | Правка | Наверх | Cообщить модератору

	119. "Создан форк системы управления контейнерами LXD"	+1 +/–
	Сообщение от Аноним (35), 06-Авг-23, 00:36
	Ну, так как это местный альтернативно одарённый, то разбор его гениальных высказываний стал доброй традицией.
	Ответить | Правка | Наверх | Cообщить модератору

	94. "Создан форк системы управления контейнерами LXD"	+1 +/–
	Сообщение от Аноним (94), 05-Авг-23, 18:25
	Дорогой друкк. В каком калькуляторе й985 года выпуска было 64 килобайта озу? Заранее благодарен. Ps всегда нравится, когда какое-нито существо вылупившееся в 21-м веке начинает втирать про калькуляторы 1980-х годов, при том что еще не вымерли те, кто в 1980-е годы на них калькулировали.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	113. "Создан форк системы управления контейнерами LXD"	–2 +/–
	Сообщение от пох. (?), 05-Авг-23, 21:33
	> В каком калькуляторе й985 года выпуска было 64 килобайта озу? двк2(м, кажется) - чем не калькулятор. Вполне себе выпускался в 85м. А так на, знакомься с достижениями загнивающего запада: https://en.wikipedia.org/wiki/TI-92_series кто ж вам виноват что для вас это - фантастика была...
	Ответить | Правка | Наверх | Cообщить модератору

	21. "Создан форк системы управления контейнерами LXD"	+1 +/–
	Сообщение от Аноним (5), 05-Авг-23, 10:42
	Ну и контейнер это не виртуализация, учи матчасть.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	32. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (32), 05-Авг-23, 12:57
	> 64 кб не хватало всем Да, 64 как-то маловато. А вот 640 кб, если верить билли нашему гейтсу, должно.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	173. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (173), 07-Авг-23, 00:35
	Ядро UNIX-подобной системы мы конечно же не считаем. И кучу сторонних драйверов из серии "авось хоть с ним заработает" — тоже. Работать будем без GUI, исключительно в командной строке. И, конечно же, каждый пользователь ПК должен уметь пересобирать ядро, чтобы выгадать несколько КБ ОЗУ.
	Ответить | Правка | Наверх | Cообщить модератору

	17. "Создан форк системы управления контейнерами LXD"	–5 +/–
	Сообщение от пох. (?), 05-Авг-23, 10:34
	Железо того времени во всю тянуло полноценную виртуализацию (правда, "почему-то", получалось только виртуализировать дос, но тогдашний "дос" работающий наполовину в protected mode ты еще потрахайся-ка виртуализировать) - именно на нее тогда и был спрос. Это я тебе, голуба, говорю как краевед - у меня оно дожило такое до осени 98го и умерло не своей смертью. А на тяпляпаные контейнеры к великому счастию спроса тогда не было. Считалось что если софт нельзя запустить без прослоек и прокладок и трижды обмотав скотчем по периметру - надо поискать или самому написать нормальный, а это просто выбросить.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	22. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (5), 05-Авг-23, 10:44
	Ну вот мы и имеем что имеем кучу контейнеров чтобы запустить самый простой софт.
	Ответить | Правка | Наверх | Cообщить модератору

	25. "Создан форк системы управления контейнерами LXD"	–4 +/–
	Сообщение от пох. (?), 05-Авг-23, 11:01
	был бы простой - работал бы тот же подход 85го года - если оно такое г-но, надо быстренько написать нормально (или хотя бы г-но попатчить как можешь). Но увы, софт перестал быть простым, а бесконечного времени у тебя нет. Поэтому жрем чодали и стараемся держаться подальше от моднявых трендов на игого и с нескучными rest(fuck) апи.
	Ответить | Правка | Наверх | Cообщить модератору

	43. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (35), 05-Авг-23, 13:11
	Да, пилить SOAP API на перле всяко веселее.
	Ответить | Правка | Наверх | Cообщить модератору

	51. "Создан форк системы управления контейнерами LXD"	+2 +/–
	Сообщение от Аноньимъ (ok), 05-Авг-23, 13:49
	Гошка как раз отличная вещь, можно написать сервис который вещь в себе и работает без сложного окружения. А вот например чтобы что-то на питоне развернуть, нужно тащить сложное и жирное окружение которое не больно то между системами переносится. С джавой всё тоже непросто. Ну и сишный софт завязанный на тысячи зависимостей в каждом пакетном менеджере под каждую систему своих. Сейчас ещё модно стало тащить виртуальную машину, к ней сервер приложений, а в нём уже запускать программы, привет нода и всякие АСП.нет руби на рельсах и прочее.
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

	58. "Создан форк системы управления контейнерами LXD"	+1 +/–
	Сообщение от пох. (?), 05-Авг-23, 14:31
	> Гошка как раз отличная вещь, можно написать сервис который вещь в себе и работает без сложного > окружения. дыркер (не умеющий возвращать коды ошибок) - прекрасная иллюстрация вещей в себе. И от того что ты все окружение слинковал в полгиговый статический бинарник, лучше никому не стало, только вот проблемы очередного лефтапада придется решать теперь снова отдельно в каждом бинаре.
	Ответить | Правка | Наверх | Cообщить модератору

	104. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от _ (??), 05-Авг-23, 19:31
	>> Гошка [...] отличная вещь, можно написать сервис который вещь в себе [...] >дыркер (не умеющий возвращать коды ошибок) - прекрасная иллюстрация вещей в себе. Программу на FORTRAN-е можно написать на любом языке программирования.(С) Дальше мысль расскрывать? Но дыркер да - убер шЫт, всё прогрессивное человечество должно осудить и расстрелять :( >И от того что ты все окружение слинковал в полгиговый статический бинарник, лучше никому не стало, Дык - мне стало луДше! /thread :) Или ты любитель "странных танцев" с Ансиблем и дыркером ? 8-о Как посмотришь "чо-нить на ноде" плэй и мой "игогошный" - сразу станет понятно. >только вот проблемы очередного лефтапада придется решать теперь снова отдельно в каждом бинаре. Ну чинить тупо _всё_ когда очередной пЫонер уберёт лок с апдейта к примеру на openssl и оно в ночь на выходной таки реально обновится! - оно конечно _гораздо_ приятнее ;-DDDD Но тут - каждому - своё, согласен.
	Ответить | Правка | Наверх | Cообщить модератору

	105. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от пох. (?), 05-Авг-23, 19:59
	> Программу на FORTRAN-е можно написать на любом языке программирования.(С) но тут стабильно получается фортран, куды ни глянь. И причину мы все знаем - ЭТИ разработчики сидят под виндой. (В винду они разумеется тоже не умеют, коды ошибок были и там. Они вообще ни во что кроме очередного фреймворка не умеют. Но раньше от них-то и не требовалось.) > Ну чинить тупо _всё_ когда очередной пЫонер уберёт лок с апдейта к примеру на openssl мой лок - пЫoнер не уберет. Ну и я-то выводы про подобных делаю и хотя бы выбираю поделки где это наименее вероятно и свои отдельные локи ставить приходится редко. Это все же лучше чем получить миллион дырявых лефтпадов/log4j разных версий намертво вкомпиленых в прожекты. Так их хотя бы всего четверть миллиона. Причем разгребать это все придется, разумеется, не давно свалившему в туман разработчику.
	Ответить | Правка | Наверх | Cообщить модератору

	115. "Создан форк системы управления контейнерами LXD"	–1 +/–
	Сообщение от Аноним (115), 06-Авг-23, 00:31
	> Гошка как раз отличная вещь, можно написать сервис который вещь в себе и работает без сложного окружения. Без сложного окружения?! Go - это мерзота, которая тащит как попало собранные куски кода внутрь единого бинарника. Все "окружение" у него внутри, потому что снаружи оно вообще не имеет никакого окружения, не имеет логики бинарного модулей, и как следствие не имеет взаимодействия между модулями. А еще они логику сборки меняют чаще чем нижнее бельё. Вот неплохая статья про Go с его "модульностью": https://maelvls.dev/go111module-everywhere/ "Гошка" - это где разрабы не умеют делать релиз и не знают что это такое. Её управление "модулями" и зависимости, привязывающиеся к хэшу коммита на github или еще в какой-то другой системе управления версиями. При этом _релиза_ как такового в Go нету. Есть 100500 модулей, которые в общем случае зафризены по последнему комиту в общей кодовой базе, которая в свою очередь даже тегов может не иметь. Все в кучу свалено. При сборке они выкачивают это барахло по сети и собирают себе в единый бинарь. Проблема отсутствия релизов и проблема отсутствия бинарных модулей - 2 разные проблемы. Отсуствие бинарных модулей делает этот язык весьма ограниченным и нишевым (нет жизни вне микросервисных проектов от слова "совсем"). Отсутсвие концепции релиза на проект, опциональность релиза напрочь меняет ворос управления разработкой проекта на Go. Если в нормальное экосистеме разработчики вынуждены: - делать релиз, - сопровождать релиз -- исправлять ошибки в релизе -- исправлять уязвимости в релизе - следить за обратной совместимостью API внутри релиза (бинарным требуется еще и ABI) То тут абсолютная помойка. КОНЕЧНЫЙ проект грузит в себя код модулей из гитхаба. И все его модули и зависимости это просто 1001 срез текста, который никто не сопровождает. И у каждого такого модуля есть еще модульные зависимости, которые никто толком не сопровождает и так влоть до N вложенных зависимостей. То есть сопровождает это всё погромист на гошке, то есть ТЫ! Допустим твой проект хочет 2 модуля: - mega-lib-2-5-blablahash1, ты выбрал актуальную версию в которой исправлены уязвимости и ошибки - ultra-lib-1-4-blablahash2, ты выбрал актуальную версию И второй модуль гвоздями привязан к mega-lib-2-4-blablahash3, потому что иди нафиг. И всё это сливается в единый бинарь в одну кодовую базу, которую поддерживаешь ТЫ, потому что релиз - не барское дело для гошников. Если npm и pip это формы рака, то модули go - это уже СПИД.
	Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

	131. "Создан форк системы управления контейнерами LXD"	+1 +/–
	Сообщение от Аноньимъ (ok), 06-Авг-23, 02:04
	Хорошо что вам на Си ничего крупного не приходилось собирать.
	Ответить | Правка | Наверх | Cообщить модератору

	133. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (115), 06-Авг-23, 02:47
	GNOME3 это считается за сложно? Собирал и нормально. Сам, а не через всякие Gentoo. Причем собирал в префикс подключался через Xserver Xephyr. Но это было давно, когда я был энтузиастом Linux и много было свободного времени... А что собственно вы хотели сказать?
	Ответить | Правка | Наверх | Cообщить модератору

	137. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноньимъ (ok), 06-Авг-23, 04:09
	> GNOME3 это считается за сложно? Собирал и нормально. Сам, а не через > всякие Gentoo. Причем собирал в префикс подключался через Xserver Xephyr. Но > это было давно, когда я был энтузиастом Linux и много было Серьезно? Расскажите как модулями управляли, систему сборки использовали, или руками в консоль вводили команды? Но самое интересное конкретно про модули и зависимости зависимостей. > свободного времени... А что собственно вы хотели сказать? Хотел проверить понимаете ли вы то, что пишите.
	Ответить | Правка | Наверх | Cообщить модератору

	166. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (115), 06-Авг-23, 20:11
	> Расскажите как модулями управляли, систему сборки использовали, или руками в консоль вводили команды? Раньше GNOME собирался через jhbuild, сейчас не знаю. Это была гномовская управляшка модулями, которая собирала разные куски GNOME. Каждый модуль мог при этом иметь свою систему сборки. jhbuild как раз и выправлял множественные зависимости. У нее там были свои метапакеты/метамодули, не помню. Суть в том, что в Linux для нативной линоковки вам нужны заголовки на С, а в случае с С++ могут потребовать еще и биндинги к С ради переносимости библиотеки, потому что С++ некроссплатформенный язык со всеми вытекающими последствиями. Часть модулей связывается друг с другом через dbus. GNOME как проект следил за всеми своими зависимостями, чтобы не возникало проблем вроде тех, которые я писал выше, когда 2 модуля зависят от разных версий третьего модуля. GNOME это делает, потому что это они авторы своих же модулей. В Go ситуация иная. Там речь не про модули, заголовки и линковку. Там именно что всё сваливается в общий бинарь, код соединяется статически со всеми. И вот вопрос to vendor or not to vendor. Ты либо сам решаешь проблемы совместимости в других проектах, от которых ты зависишь, форкнув их, потому что оно попадёт к тебе в общий бинарь, либо надеешься на апстрим, авось и ходишь к попам на воскресную молитву. Гошники просто кидают сорцы в Git. Из-за отсутствия возможности динамической линковки им незачем заниматься бинарной сборкой модулей, не за чем поддерживать совместимость самих с собой. Учитывая что большая часть разработчиков на Go не имеет даже такой концепции, как "релиз модуля" и распространяют свой код через систему контроля версий в публичном интерене, иногда без тегов и как попало, то те кто занимается сборкой и доставкой Go в дистрибутивах вынуждены городить инфраструктуру релиза своими средствами. Почитайте https://docs.fedoraproject.org/en-US/packaging-guidelines/Go.../ Для сборки программы на Go меинтейнеры должны: 1. Отключить при сборке загрузку сорцов с гитхабов и гитлабов авторов-игогошников, потому что им веры нет 2. Опакетить сорцы каждого модуля приложения, сделав релиз за этих бомжей 3. Самостоятельно решить проблему зависимостей зависимостей внутри сборочной системы Go силами дистрибутива с использованием RPM 4. Самостоятельно сопровождать форки кодовой базы и перепакечивать и обновлять Весь этот язык придумал Google для запуска многопоточных клиент-серверных приложений в форме монолитных блобов внутри Kubernetes. Причем он специально сделан процедурным языком с АЛГОЛ-образным синтаксисом, чтобы людям было привычно и не нужно было использовать erlang. Go - это замена erlang в его нише, ни больше, ни меньше. И вся его простая экосистема создана для этой задачи быть запущенным в контейнере под управлением кубика.
	Ответить | Правка | Наверх | Cообщить модератору

	132. "Создан форк системы управления контейнерами LXD"	+3 +/–
	Сообщение от Аноним (115), 06-Авг-23, 02:40
	А еще давай я помогу разобраться с той кашей, которая у тебя в голове про веб приложения. Обычное веб приложение требует: - сервера приложений, который управляет рабочими процессами, пайплайнами обработки запросов и возможно маршалингом (тогда оно ни разу не микросервисное), если там один модуль подтягивает другой в общую память. - само приложение, которое либо выполняется внутри инегрированного интерпретатора с JIT, вроде JVM (для java), CLR (.NET Framework) либо локальном интерпретаторе, вроде .net 5+, python, php, perl, ruby, либо выполняется нативно через API сервера приложений CGI Популярные сервера приложений: 1) Apache Tomcat, JBoss/Wildfly и прочие сервера приложений полностью или частично реализующие Java EE. Они запускают JVM, внутри которой поднимают приложения-сервлеты. Java EE стандартизирует логику взаимодействия этих веб-приложений друг с другом и логику написания своего сервера приложений для Java. Java полностью изолирована от работы с железом и рулит своими ресурсами на уровне JVM. Рабочие процессы на стороне ОС отсутствуют, но есть сервлеты, их классы и их потоки исполнения. 2) Internet Inforamtion Services (IIS) и другие сервера приложений повторяющие архитектуру UNIX Internet Daemon Этот сервер приложений приложений ровным слоем размазан по ОС. Каждый тип запроса реализует своя подсистема. За HTTP отвечает соответсвующий модуль, отдельный модуль для аутентификации и авторизации, отдельный для шифрования TLS. В случае с Windows - это драйверы ядра. Информация передаётся через сокеты и в общем случае вы можете привязками сделать всё что угодно и сцепить с любым интерпретатором. Странно что inetd не популярен в UNIX-подобных ОС для той самой блин задачи, для которой он был спроектирован... но это лирика. Главное то, что супер-серверы на стороне ОС. Внутри IIS, например, запускаются экземпляры службы публикации, которая кроме обслуживания статики может: - прицепить к себе модуль ISAPI - прицепиться к другому вебсерверу, вроде kestrel ( встроен .NET 5+), Node.JS - использовать интегрированный пайпалайн .NET Framework 2.0/4.0 и .NET 5+ (но там всё равно внутрипроцессный kestrel) - прицепиться к службам ОС, если они написаны по стандарту WCF - прицепиться к отдельному серверу реализации рабочих процессов через CGI и работать как обычный вебсервер, вроде nginx. Из-за того что Windows имеет драйверы ядра под это всё - IIS сейчас это единственный из живых серверов приложений, который реально способен работать с железом напрямую. Он управляем утилизацией процесса и памяти. Фиксирует приложения на разных ядрах если надо. Работает с топологией NUMA и умеет распределять ресурсы между теми рабочими процессами, которыми управляет. 3) Apache HTTPD и другие аналогичные ему с особенным API Это максимально урезанная реализации inetd, чтобы не размазывать из по ОС. Apache HTTPD вообще сейчас не используется почти что как сервер приложений, только разве что в энтерпрайзе для обслуживания старых APR-модулей. Его пайплайны мало соотносятся с нынешним железом, поэтому он почти всегда виртуален и почти всегда веб-сервер (ради например SSI, который хорошо работает, но это не про сервера приложений). Вот тут мы вспомним про Passenger и про то что Ruby on Rails рекомендовано использовать с ним. Логика там +/- такая же. 4) Юзерспейсные сервера приложений такие работающие через FastCGI Есть реализации серверов приложений специально сделанных под интерпретатор, которые отдаются на вебсервер по через CGI. Те же известные php-fpm, uwsgi и прочие PSGI Вообще большая часть интерпретаторов имеет свою логику работы с рабочими процессами и потоками. ASP.NET Core (не Framework), Node.JS, Java. Для доставки приложения перед ними ставят реверспрокси вроде HAproxy или nginx (в роли прокси). Другие же используют отдельно стоящий сервер приложений обычно на базе FastCGI и имеют внутри интерфейсы *GI. Так работают php, python, perl. Перед ними ставят любой вебсервер поддерживающий CGI/FastCGI. nginx или HAproxy (в роли вебсервера) и потом доставлять наружу через реверспрокси. А третьим нужен специальный модуль к специальному вебсерверу. ASP.NET Framework (через IIS), Ruby on Rails (через passenger) и можно пользоваться php, perl, python через Apache mod_*, но лучше не надо. 5) Kubernetes Оно пожрало и уничтожило своих предшественников docker swarm и openstack magnum (для задачи). У этого логика в том, что всё вышесказанное упрощается и мы работаем с воркерами кубернетиса, которые работают с контейнерами. Внутри контейнера находится та самая инфраструктура специяичная для приложения и его интерпретатора/бинарника. Единственное, что кубернетис делает хорошего - позволяет хоть как-то управлять и обслуживать микросервисный проект, который писали мартышки на 5 разных языках в разное время. В остальном он скорее привносит проблемы, нежели их решает. > Сейчас ещё модно стало тащить виртуальную машину, к ней сервер приложений, а в нём уже запускать программы, привет нода и всякие АСП.нет руби на рельсах и прочее. Вот теперь после всего вышесказанного я могу объяснить, как мы до этого докатились. ОС и её ядро умеют работать с железом. ОС умеет работать с сетевой подсистемой сервера. ОС имеет реализацию сервисов, в ядре есть планировщик процессов и много чего еще. ОС пишут для того, чтобы приложения работали на железе. Есть архитектура UNIX Internet Daemon, которая очень успешная и проверенная временем. Ирония в том, что всё это активно применяется только в Windows и это позор. То есть как сервер приложений IIS работает. Java никогда в своей жизни не хотела работать на железе. Она максимально абстрагирует приложение от железа, и JVM выступает в роли ОС. Это тоже работает и Java делает это вполне успешно. Apache HTTPD как сервер приложений скорее мертв, чем жив. Вся его оптимизация под железо и оптимизация его модулей под железо в далёком прошлом. Интегрироваться с ОС он при этом никогда не мог. Это юзерспейсный сервер не способный рулить железом и разделением ресурсов. NGINX Unit и Passenger такие же. Равно как и проекты, которые реализуют на коленке сервера приложений имени одного интепретатора, который потом отдаётся по FastCGI. И вот у нас есть 4-х процессорный сервер с террабайтом RAM. И что по вашему произойдет если одно приложение разорвется по разным процессорам и разным блокам памяти? Правильно, оно будет тупить нищадно. А ничего что на современных процессорах по нескольку контроллеров памяти, которые по разному могут примапится к разным ядрам. А что такое Xeon Scalable? Весь этот зоопарк железа нативно поддерживает сейчас только IIS. Для всех остальных случаев - виртуализация. Сервера приложений имени интерпретатора слишком глупы, чтобы это понять и с этим работать, поэтому мы поставим гипервизор, который часть ОС. Он умный, он нарежет нам виртуальный сервак так, как надо. Пофигу что мы потеряли от 15-50% производительности приложения. А что с SMT/HyperThreading? Там вообще мрак! Вот окажется ваш воркер на псевдо ядре и что дальше? И если вы думаете что Kubernetes и его контейнеры вас спасут от этой проблемы - то вы горько ошибаетесь. Поддержка железа в кубике всё еще в зачаточном состоянии. Ну то есть теоретически если вы: - поставите однопроцессорные блейды на compute - поставить отдельный от них сторадж в отдельной сети - поднимите CLOS eBGP Undelay в топологии Spine Leaf - начнете роутить Overlay-сети кубика через ECMP - поставите сетевки, которые поддерживают Hardware SDN Offloading - внутрь запихаете микросервисные приложения, которые: -- строго-настрого стейтлесс -- либо все однопоточные с одним рабочим процессом, либо вы отключите SMT/HyperThreading на железе То вы получите вменяемую производительность. И если вас мучает вопрос, причем тут сеть, не удивляйтесь. Сами себе контейнеры придумали, будьте любезны правильно сеть настраивать и оффлоадить. Много видели barebone-кубиков? То-то же! Реальность такова, что чтобы пользоваться даже кубиком вам нужно его воркеры виртуализовать и правильно назначить ресурсы через тот же KVM или другой гипервизор. То есть и там виртуалки. Кроме того безопасность ванильного кубика - это такая несмешная шутка, особенно когда нет виртуализации. Сейчас контейнеры на железе массово не используются, потому что со стороны контейнерной оркестрации нет поддержки работы на разномастном железе. Безопасность изоляции не выдерживает никакой критики. При этом внутри контейнеров сервера приложений юзерспейсные и слишком глупые, чтобы реализовать это самим. Любой кто говорит о приросте производительности от использовании докерообразных контейнеров по сравнению с виртуализацией - теоретик, фантазёр и админ локалхоста. Есть попытка у Red Hat сделать OpenShift (OKD) как barebone решение. Они там и kubevirt прикручивают и root запрещают и SELinux вменяют. Даже RHEV (oVirt) выкинули на мороз. Вон cgroups2 развивается тоже. Ну посмотрим как им это поможет, рано пока. Может лет через 10. В общем, что только не придумают, чтобы не юзать inetd-архитектуру. P.S. Кстати LXD сабж из новости старается работать именно на железе в отличии от остальных контейнерных систем. И у него получается сильно лучше. Вот только у него с безопасностью еще большие проблемы, потому что Ubuntu c Apparmor и её тягой запускать всякую бяку от root.
	Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

	135. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноньимъ (ok), 06-Авг-23, 03:55
	> Обычное веб приложение требует: >- сервера приложений Мда. Это конечно отлично что вы с кашей в голове пытаетесь разобраться, но мда. Что там за проблемы с многопроцессорными системами не в хайлоаде непонятно вообще. Запускать приложение в границах NUMA ноды, и будет счастье. Если ваше приложение больше 256 потоков успешно грузит, и вот никак не масштабируется горизонтально вообще, то очень плохо конечно. Нужно делать его тогда с оглядкой на нелокальность ресурсов, но в таком случае странно что не масштабируется. Иначе забить остаётся и строить многопроцессорные системы/кластеры.
	Ответить | Правка | Наверх | Cообщить модератору

	161. "Создан форк системы управления контейнерами LXD"	+1 +/–
	Сообщение от Аноним (115), 06-Авг-23, 16:31
	Вы явно не работали со всей этой гадостью, раз пишете такое... Вы правы в том и только в том, что если ни монолитное приложение не умеет в поддержку многопроцессорного железа, ни сервер приложений, нужно просто всё ограничить в рамках одной нума ноды. Теоретически вы абослютно правы, но на практике это ни разу не тривиальная задача. По факту это сейчас достижимо на сервере приложений IIS или с контейнерами LXD, или у вас там Java EE/Jakarta EE экосистема. Остальные сервера приложений сами не способны на такие привязки от слова "совсем". Для микросервисных веб-приложений, их интерпретаторов и серверов это сложная задача. И даже если хайлоада нет, то вам все равно придется назначать границы, если вы этого не сделаете то работа приложений будет не определена и не стабильна. Для дурацких серверов приложений можно сделать привязку средствами ОС сверху, но тогда теряется вообще всякий смысл пользоваться сервером приложений для разделения физических ресурсов. Весь сервер приложений тогда окажется на одной NUMA-ноде. А если есть N приложений, которые нужно разместить по M нодам NUMA, задача опять нетривиальна. Что тогда делать? Порождать несколько экземпляров серверов приложений. И вот чтобы удобно ими управлять это всё виртуализируют. Получается так: - Есть веб-приложение, обрабатывающее запросы, в доме, который построил Джек. - Есть дурацкий сервер приложений, который порождает экземпляры веб-приложения, обрабатывающее запросы, в доме, который построил Джек. - Есть виртуальная машина с одним узлом NUMA, в которой запущен сервер приложений, который порождает экземпляры веб-приложения, обрабатывающее запросы, в доме, который построил Джек. - Есть гипервизор, который назначает ресурсы железа на виртуальные машины с одним узлом NUMA, в которых запущены сервера приложений, которые порождают экземпляры веб-приложения, обрабатывающее запросы, в доме, который построил Джек. - Есть инфраструктура виртуализации, которая предоставляет API для управления кластерами гипервизоров, которые назначает ресурсы железа на виртуальные машины с одним узлом NUMA, в которых запущены сервера приложений, которые порождают экземпляры веб-приложения, обрабатывающее запросы, в доме, который построил Джек. - Есть сервер оркестрации, который управляет несколькими инфраструктурами виртуализации (тест и прод), которые предоставляет API для управления кластерами гипервизоров, которые назначает ресурсы железа на виртуальные машины с одним узлом NUMA, в которых запущены сервера приложений, которые порождают экземпляры веб-приложения, обрабатывающее запросы, в доме, который построил Джек. Ну как? Тошнит? Это применяется для внутренних корпоративных продуктов какой-нибудь логичтической фирмы. Ничего особенного. И вот вся эта пресловутая контейнеризация призвана, якобы, упростить архитектуру крупных корпоративных веб-проектов. Однако, на 2023-й год она не способна выкинуть виртуализацию. > Если ваше приложение больше 256 потоков успешно грузит, и вот никак не масштабируется горизонтально вообще, то очень плохо конечно. Есть 2 типа приложений микросервисные и остальные. Микросервисное приложение - это стетлесс сервис, который получает запрос и отдает ответ. Они функциональны в том смысле, что на если поступило два запроса, то приложение корректно ответит на оба вне зависимости от порядка обработки запросов. Состояния вынесены в сторадж подсистему, которая отделена от микросервиса. А еще микросервисное приложени не использует маршалинг. Каждый функциональный модуль, к которому хочет обратиться такое приложение оформлен в виде другого микросервисного приложения, а не разделяемой библиотеки/класса/ассембли, которая подгружается в общую кучу этого приложения. Сама идея использования микросервисных приложений заключается в том, что есть: 1. Оркестрация серверов приложений 2. Сервера рабочих процессов управляют экземплярами приложений 3. Приложение "простое", желательно однопоточное, без стейтов на нем, работающее в режиме вопрос-ответ и общением с источником стейтфул-данных на бекенде (база, файловый сторадж, итд) Микросервисные приложения не управляют своими ресурсами и своей многозадачностью. Это вынесено на сервер приложений, который за это отвечает. Другие "остальные" большие приложения по "256 потоков" - это монолитные приложения. И они ничем не хуже микросервисов. Просто они сами управляют своей многопоточностью, потенциально грузят внутрь себя другие куски кода и возможно держат на себе стейты так, что запрос 2 может быть обработан только после запроса 1 и только на том же самом экземпляре мнололитного приложения. Собственно микросервисные приложения хорошо масштабируются, но тратят больше ресурсов на сопровождающую инфраструктуру и имеют издержки на сетевое нелокальное взаимодействие. Монолитные приложения в общем случае быстры, но развитие их кодовой базы проблематично, горизонтальное масштабирование, в общем случае, - нетривиальная задача, решение которой зависит от самого приложения. Диалектика шила и мыла. При этом вопрос виртуализации не снимает ни один подход к написанию веб-приложений. Для микросервисных приложений, которые работают на железе, нужно чтобы _сервер приложений_, который порождает экземпляры (рабочие процессы) и перенаправляет на них поток запросов умел работать с железом и ОС. Для микросервисных приложений, которые работают на железе, нужно чтобы _само приложение_, умело работать с железом и ОС. Сервера приложений устроены так, что могут запускать и микросервисные приложения и монолитные. Просто контроль за ресурсами будет в разных местах. То есть в общем случае все сводится к одному к поддержке железа и ОС. И вот если оно (монолитное приложение  или сервер микросервисных приложений) дурацкое, то вам нужны виртуалки, чтобы правильно решить задачу с размещением этого всего на NUMA. Причем в реальности для "больших" монолитных веб-приложений, например, как вы пишете про "256 потоков", ситуация усугубляется тем, что их интерпретатор должен понимать железо, быть интегрирован в ОС, или это бинарное приложение на С, что по сути даст то же самое. Отсюда и появляется требование к inetd-архитектуре IIS, который предоставляет такую интеграцию средствами ОС. Или Java EE, которая построена на этих принципах, только не в рамках стандартных библиотек ОС, а средствами JVM. Ваши "простые" теоретические решения запускать все в рамках нуманоды понятны и правильны. Я же просто описываю практическую сторону вопроса, развернуто отвечая на вопрос причем тут виртуализация. Я могу дать лаконичный и краткий ответ: "либо используйте виртуализацию, либо ставьте нормальную ОС с нормальной реализацией UNIX Internet Daemon (Windows с IIS)", но такой ответ местной публике не понравится. Начнутся эмоции, ответ сочтут за троллинг, потому что многие тут не видели крупных веб-проектов и не понимают реальную проблематику их написания и дальнейшего сопровождения. Есть 3 многообещающих продукта, которые в перспективе следующих 10 лет способны потеснить гегемонию IIS на поприще высоконагруженных внутрикорпоративных порталов: - NGINX Unit, если они начнут наконец работать с железом. Снйчас оно очередное "дурацкое". - LXD, если у него появится инфраструктура, но судя по новости там форк на форке и запираемся в каноникал. - Потуги Red Hat вокруг Barebone OpenShift.
	Ответить | Правка | Наверх | Cообщить модератору

	249. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноньимъ (ok), 08-Авг-23, 18:15
	Да, не работал. Про микросервисы вы странное пишите, совсем им сервер приложений ненужен, пишут на той-же гошке успешно, и вполне себе сами управляют ресурсами. Про отсутствие стейта то-же неверно, это не то что делает микросервисы микросервисами. Например видел такое как сервис управления транзакциями, потому что использовать для этого реляционную БД(которая есть в виде постгри) это не модно. Ну и конечно сейчас мало кто понимает что это такое вообще и зачем нужно, поэтому зачастую просто жесть получается. Но в целом спасибо, узнал много нового.
	Ответить | Правка | Наверх | Cообщить модератору

	256. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (115), 09-Авг-23, 03:27
	> Про микросервисы вы странное пишите, совсем им сервер приложений ненужен > Про отсутствие стейта то-же неверно, это не то что делает микросервисы микросервисами Я пишу про то, какими они задумывались, как архитектурное решение для замены ESB с их проблемами масштабирования и отказоустойчивости. Причем исключительно для решения Enterprise Master Data Management, то есть работа с НСИ, документами, остатками, деньгами и другими данными, которые по определению считаются бизнес-критичными. У таких приложений всегда есть понятие первоисточника мастердаты, поэтому они избегают хранения данных на разных кусках и модулях приложения и борются с этим ради отказоустойчивости и горизонтального масштабирования. А еще у таких приложений есть отчетность OLAP, чтобы смотреть за динамикой формируя срезы отчетов по кубам. То есть они вручную следят за изменениями данных складывают это в Data Warehouse. И там очень много разных микросервисов, часть отвечает за обработку данных, а часть следит за их изменениями и пишет отчетность. Чтобы всем этим управлять, обновлять, мигрировать и нужны сервера приложений, даже если внутри многопоточный код на Go. > Например видел такое как сервис управления транзакциями, потому что использовать для этого реляционную БД(которая есть в виде постгри) это не модно. Хммм... а это точно те транзакции, которые в базе? Может это транзакции в бизнесс-смысле или это просто была реализация координатора распределенных транзакций, когда один кусок приложения (источник) формирует набор инструкций в транзакцию, а микросервис-получатель должен распределить это на несколько назначений сразу так, чтобы либо все выполнились успешно, либо вся транзакция провалена. Это реализация ACID на программном уровне и такое часто нужно. Я не видел проекта, могу только гадать, но раз вы пишите про PostgreSQL и если кому-то требуется видеть не только нынешние данные, но еще и видеть всю историю их изменений с начала времен в соседней базе, да так, чтобы можно было строить кубы... PostgreSQL не может в OLAP, если я правильно помню, она строго OLTP. Вы не можете просто так взять и построить на ней многомерную аналитику, это не Oracle DB и даже не MSSQL.
	Ответить | Правка | Наверх | Cообщить модератору

	251. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноньимъ (ok), 08-Авг-23, 18:36
	>Ну как? Тошнит? Это применяется для внутренних корпоративных продуктов какой-нибудь логичтической фирмы. Ничего особенного. И вот вся эта пресловутая контейнеризация призвана, якобы, упростить архитектуру крупных корпоративных веб-проектов. Однако, на 2023-й год она не способна выкинуть виртуализацию. Да, абстракции многократно дублирующие друг друга, я довольно давно обратил на это внимание и с тех пор прибываю в некотором недоумении. По идее, ОС - и есть сервер приложений, который как бы ими управляет и, и получается чего-то серьезно не хватает. Ну допустим сделали виртуализацию, должно по идее хватать этого, или не должно? То есть какой смысл в контейнерах если есть нормальная виртуализация и можно приложения по виртуалкам распихать?
	Ответить | Правка | К родителю #161 | Наверх | Cообщить модератору

	257. "Создан форк системы управления контейнерами LXD"	+1 +/–
	Сообщение от Аноним (115), 09-Авг-23, 03:56
	> По идее, ОС - и есть сервер приложений, который как бы ими управляет и, и получается чего-то серьезно не хватает. Да, все так. Что-то чего не хватает - это нормальное реализации суперсервера на стороне ядра популярных UNIX-подобных и не хватает еще тонны модулей реализующих протоколы на стороне ядра и вот, когда данные вынули, нужна еще сервисная модель на стороне ОС, чтобы можно было быстро принять в приложение запросы не запуская их каждый раз заново. И привязки одного к другому нужны и инструментарий для управления этим из пространства пользователя... Много чего нужно, на самом деле. > Ну допустим сделали виртуализацию, должно по идее хватать этого, или не должно? Я писал в одном из своих постов, что не каждая нагрузка легко виртуализируется. На некоторых задачах высочайший оверхед. Если отвлечься от темы веб и поговорить чисто про виртуализацию, то попробуйте взять 4-х ядерный компьютер с частотой хотя бы 2.2 и обычным локальным диском SSD, и поставьте на него какой-нибудь особенно проблемный для виртуализации софт, например asterisk. Измерьте какое количество одновременных звонков он будет держать, а потом на тот же компьютер поставьте виртуалку с такими же параметрами как он сам и оцените деградацию производительности. Так вот на серверах виртуализации еще и оверкоммит CPU почти всегда. Или сравните производительность SQL-сервера, причем абсолютно любого. Там тоже осязаемая деградация от факта применения виртуализации. Так вот, приложение тоже можно так написать. Например, если оно порождает огромное количество параллельных потоков и как следствие переключения контекстов. По моему опыту, если у вас 14000 переключений контекстов в секунду на ядро вашему сервису конец. Уберете виртуализацию и полегчает. Там же еще виртуальные сетевые адаптеры, если они не заведены через SR-IOV они выполняются на том же процессоре. Виртуализация - это гарантированная потеря производительности от 15%. Эта технология нужна только для того, чтобы уплотнить размещение серверов в стойках, сэкономить энергию и деньги. Если есть 10 приложений, которым нужен 4-хядерный сервер 16ГБ RAM и 500ГБ диска то, что вы поставите 1 сервер на 40+ ядер или 10 серверов на 4 ядра? Вопрос риторический. В остальном виртуализация мешает. Контейнеры - это попытка придумать изоляцию для приложений друг от друга без накладных расходов на виртуализацию, причем они популярны только в Linux, потому что они там решают тонну других задач: - используются вместо setup.exe, чтобы была переносимость между 9000-ми несовместимых друг с другом и со своими прошлыми версиями - используются как средство конфигурирования при для автонастройки - для распространения проприетарного софта и особенно его обновления, когда компания покупает услуги подрядчика, а подрядчик выкатывает новые версии и патчи своим корпоративным клиентам Был бы стандартизированный юзерспейс не было бы таких ухищрений. По назначению их используют сравнительно редко.
	Ответить | Правка | Наверх | Cообщить модератору

	268. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Легивон (?), 15-Авг-23, 20:55
	Просто оставлю это здесь https://github.com/kubernetes/enhancements/issues/3545 Пока Вы писали стены текста про **NEMOJET**, поддержка NUMA появилась в 1.28 релизе. Придется теперь перекрывать только неподдержкой tls offload карт, которые используюся в 0.0001% инсталяций. Действительно очень большая проблема. Пойду из-за неё переустановлю k8s на такой хороший Шindoшs, настрою isis и ftp. И буду по последнему туда релизы загружать консольным ftp клиентом, как хакир, а затем автоматизирую это все на cmd и visualbasic сприптах. Как тебе такое Илон Маск?
	Ответить | Правка | К родителю #161 | Наверх | Cообщить модератору

	136. "Создан форк системы управления контейнерами LXD"	+1 +/–
	Сообщение от Аноньимъ (ok), 06-Авг-23, 04:03
	>Безопасность изоляции не выдерживает никакой критики. Контейнеры это не про безопасность вообще. Это способ опакетить ПО с окружением или связку некоего ПО.
	Ответить | Правка | К родителю #132 | Наверх | Cообщить модератору

	162. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (115), 06-Авг-23, 16:32
	Было бы неплохо если бы они ее хотя бы не снижали...
	Ответить | Правка | Наверх | Cообщить модератору

	215. "Создан форк системы управления контейнерами LXD"	–2 +/–
	Сообщение от Легивон (?), 07-Авг-23, 20:21
	>Есть архитектура UNIX Internet Daemon, которая очень успешная и проверенная временем. Дядь, ты что опять таблетки пить перестал? Участковый психиатор заругается! Ты слышал такую вещь как производительность? Где производительность и где inetd запускающий по экземплярую программы на запрос? Какой ужос! Не верится даже что это может оказаться не троллингом. >Поддержка железа в кубике всё еще в зачаточном состоянии. Это концентрированный бред. Поддержка железа кубером = поддержке железа Linux. За исключением тех архитектур на которых не собираются "5 go бинарников". Не понял ваш пример железа. Я использую кубиры на обычных виртуалках без каких бы то ни было аппаратных излишеств. И у меня все работает. >Реальность такова, что чтобы пользоваться даже кубиком вам нужно его воркеры виртуализовать Неправильно. Реальность такова, что на практике аппаратные сервера настолько мощные (100+ ядер, 500+ RAM), что никто не готов выделять под типичные задачи небольшого проекта 7 аппаратных серверов (3 etcd + 2 control plane + 2 worker). Даже самый маленький сервер который имеет смысл приобретать будет иметь ресурсов на порядок (10 раз) больше чем нужно 1 инстансу. Поэтому с кубиром виртуализация и используется практически всегда. Плюс кубер это динамичная система. Надо воркеров - добавил, не надо - убавил. С этом случает удобнее привязываться к инстансам невысокой производительности. >Кроме того безопасность ванильного кубика - это такая несмешная шутка Он гораздо безопаснее за счет какой-никакой изоляции в namespaces, которую на голом хосте, в сравнении с этим, как правило никто не настраивает. >Сейчас контейнеры на железе массово не используются, потому что со стороны контейнерной оркестрации нет поддержки работы на разномастном железе. Чего? Что за бред я читаю? Примеры будут? >Безопасность изоляции не выдерживает никакой критики. На порядки выше изоляции процессов чем на обычном хосте, на котором как правило не настраивают namespaces... Ведь если начать настраивать namespaces - так ведь можно и до докера дойти. А это не true! А по факту уже давно имеется стабильный qemu-kvm runtime реализующий стандарный интерфейс контейнеров - kata-containers называется. Можете использовать его в k8s посредством изменения 1 строчки. >Любой кто говорит о приросте производительности от использовании докерообразных контейнеров по сравнению с виртуализацией - теоретик, фантазёр и админ локалхоста. Рассказывай как ты скейлишь свой highload... Или погодите, на локалхосте же нет хайлоада. >root запрещают и SELinux вменяют Хорошее решение, переспективное, в духе Red Hat. Думаю root можно будет открывать по подписке.
	Ответить | Правка | К родителю #132 | Наверх | Cообщить модератору

	231. "Создан форк системы управления контейнерами LXD"	+1 +/–
	Сообщение от Аноним (115), 08-Авг-23, 03:12
	> Где производительность и где inetd запускающий по экземплярую программы на запрос? > Какой ужос! Не верится даже что это может оказаться не троллингом. Спешу расстроить, это не троллинг. Архитектура UNIX Internet Daemon предполагает наличие суперсервера, который перенаправляет запросы на другие демоны. На примере реализации в IIS: 1. Запросы поступают по сети, которую обслуживает ядро (драйверы адаптеров и сетевой стек) 2. К каждому IP и порту есть привязка HTTPS, HTTP, HTTP2 или QUIC 3. Если соединение предполагает наличие криптографии, то она обслуживается модулем по работе с TLS опять на стороне ядра 4. Аутентификации (Basic, Kerberos, X.509) обслуживается как ядром, так и юзерспейсом, если требуются особые формы делегирования 5. Далее мы получили запросы по HTTP, которые обслуживает HTTP.sys на стороне ядра (кроме запроса PATCH, он в юзерспейсе) 6. Поступившие запросы попадают на сокет службы согласно правилам привязок и определения пулов приложений. 7. Каждый пул — это запущенный с пониженными привилегиями экземпляр службы публикации, который реализует пайплайн по работе с запросами. Пулы и есть многопоточные рабочие процессы для ряда интерпретаторов (.NET, Node.JS) или связываются с дочерними процессами по CGI Реализация этой классической UNIX-архитектуры в Linux — это полное фиаско и несмываемый позор. Учитывая, что во времена ядра 2.6 предпринимались попытки реализовать это средствами ядра, как в Windows, но получилось, как всегда. Проект по реализации обработки HTTP тогда появился в ядре и благополучно сдох. А что с TLS на уровне ядра? Зачатки Kernel TLS появились в районе 4.13, а в 5.1 оно только-только стало экспериментально работоспособным. Но мало кто пользуется им еще, все по-прежнему линкуют всё в дистрибутивах к OpenSSL. Я это всё к тому, что реализация inetd убогая, медленная и мёртвая, работает как попало и чисто в юзерспейсе. В Windows реализация inetd есть очень давно, и она называется IIS. Ей полностью меняли реализацию 3 раза (1995-2000, 2001-2005, 2006-наст. время) из-за того, что она размазана по всей ОС и меняется с мажорным апдейтом. Но пользователи видели только 3 инкарнации. И вот она работает очень быстро. > Поддержка железа кубером = поддержке железа Linux. Нет не равно! Кубик — это планировщик. У него есть назначение приоритетов, но не ресурсов железа. Вы понимаете, как они работают со своими 0.5 CPU? Это веса планировщика. Чем выше цифра, тем выше приоритет контейнера. Но с реальным железом они не мапятся. Linux с железом работает, а кубик нет. Кубик не может назначить такие-то процессоры и ядра с таким-то уровнем утилизации на такой-то ноде NUMA. Есть вот эта бетка, но она все еще экспериментальная: https://kubernetes.io/docs/tasks/administer-cluster/memory-m.../ А еще там нужно шейпить сеть в ядре и много чего еще делать по фильтрации запросов/пакетов в ядре. Вам (контейнерщикам) для этого годами eBPF разрабатывают, а я всё как не гляну, всё равно узко. Динамическая фильтрация пакетов работает в ядре Windows c года так с 2001-го. Говорить надо или сами узнаете что такое WFP и как он соотносится с NDIS. Оно там всё либо не доделано на стороне Linux, либо на стороне Kubernetes, либо брошено всеми, и все забили. > Не понял ваш пример железа. Я использую кубиры на обычных виртуалках без каких бы то ни было аппаратных излишеств. И у меня все работает. Правильно, потому что с физической инфраструктурой не работали. Конечно, у вас все работает на виртуалках. Я же пишу, что оно ТОЛЬКО ТАК работает. А теперь соберите кубик на многопроцессорном железе без грамма виртуализации, я посмотрю на вас. У вас будут несколько проблем: 1. NUMA, её разные формы на разных физических хостах, особенно Xeon Scalable вас удивит своей гибкостью. Так как кубик всё это не умеет пока, то придётся брать однопроцессорные блейды и игнорировать наличие NUMA. При этом у вас все равно по нескольку контроллеров на проц, которые мапятся к разным ядрам, но там не так страшен вариант расползания разных потоков на разные ядра с разными контроллерами RAM, чем если это расползание одного приложения между разными сокетами. 2. Сеть на стороне хоста. Вам нужен DPDK, пойдите еще поднимите его: https://www.dpdk.org/wp-content/uploads/sites/35/2020/11/DPD... Причем, чтобы завести всё это так, чтобы у вас там Overlay оффлоадилась на сетевые карты, вам проще поставить сетевки NVIDIA (Mellanox), потому что только они нормально работают в Linux. А если вам нужен еще и сторадж в контейнерах, то проще перейти на использование S3-образного объектного стораджа, отказавшись от всего остального, потому что там будет тонна проблем либо с производительностью, либо с подбором железа. Если вы попытаетесь подать в контейнеры локальный сторадж, то вы упретесь в геометрическую проблему серверной платформы. Однопроцессорные блейды имеют мало дырок на диски, может не хватить в зависимости от... и тогда хана. Если вы попытаетесь подать сетевой сторадж, то запустить его с поддержкой RDMA и оффлоадить сторадж на сетевой карте та еще задачка. - NFSv4+ в Linux опять частично работает в userspace, Linux вам не Solaris и не FreeBSD, чтобы иметь нормальные драйверы, но кое-как RDMA запустить можно. Вся проблема в NFSv4 ACL, которые в Linux медленные. - SMB, насколько я знаю пока не вышел в прод и находится в состоянии PDF-презентаций разной степени красивости. - iSER (iSCSI over RDMA) вроде бы работает и даже с поддержкой Multipath, но менеджить LUN-ы как контейнерный сторадж... уффф. Ну так вот, когда вы радостно поставили свой Ceph-кластер или купили проприетарную хранилку вам нужно сцепить его с физическими нодами кубика так, чтобы заработал оффлоадинг по RDMA и чтобы сеть была построена так, чтобы multipath работал. Единственный рецепт для Linux - построить это всё исключительно на L3 и вот почему! В ядре Linux просто омерзительный драйвер бондинга и кошмарный драйвер виртуального свитча. Обоим место в музее. Все современные модули ядра Linux и все новые фишки работают только через мосты (Linux Bridge). Для вас (убежденного в том, что Kubernetes нормально работает на железе и в Linux всё хорошо с железом) придется настроить выделенный сегмент сети в топологии Spine-Leaf в режиме L3, который будет выполнять роль Underlay. Забудьте про MLAG, стеки, фабрики и прочий LACP. Вам придётся построить eBGP CLOS, настроить ECMP и настроить Border-свитчи для стыка сегмента с основной сетью датацентра, пусть даже по OSPF, но в отдельной Area. Если вы любите Linux берите NVIDIA (Cumulus Linux), они работают. > Реальность такова, что на практике аппаратные сервера настолько мощные (100+ ядер, 500+ RAM), что никто не готов выделять под типичные задачи небольшого проекта 7 аппаратных серверов (3 etcd + 2 control plane + 2 worker). Даже самый маленький сервер который имеет смысл приобретать будет иметь ресурсов на порядок (10 раз) больше чем нужно 1 инстансу. Поэтому с кубиром виртуализация и используется практически всегда. Ах, эти знаменитые аргументы про "не нужно", какая прелесть =) То, что у тебя нету больших задач и тебя до них не допустили, совсем не значит, что их нет ни у кого вообще и у меня в частности. Я знаю, что я говорю, потому что я это делал и оно работало на стенде так как надо именно с железом, потом поставил поверх OpenStack. Передо мной стояла задача развернуть Kubernetes as a Service быстрее по производительности, чем у некоторых конкурентов. Как раз на серверах с 96 ядер и 1ТБ RAM. Но без виртуализации оно именно что неюзабельно, от слова "совсем". Всё что там необходимо сделать по мультитеннантности, по изоляции по разграничению ресурсов на данном этапе сыро. Это решает Red Hat в OpenShift, который тоже еще сырой для barebone и не особенно то в фаворе у дурачков, которые докеры крутят, там же root нельзя. А без отжима root никакой изоляции в Linux не добиться. А оборудование нужно изолировать от дурачков, оно от них тупеет. Развертывание железного кубика не сложнее чем OpenStack свой собрать... но и не проще. И вот это всё от вас прячет инфраструктура виртуализации в датацентре. Вы пользуетесь виртуалками, потому что изнутри них не знаете сколько очередной VMware ESXi и VMware NSX делает для таких вот пафосных "знатоков" Kubernetes. > Он гораздо безопаснее за счет какой-никакой изоляции в namespaces, которую на голом хосте, в сравнении с этим, как правило никто не настраивает. Во-первых, научись говорить за себя. У меня нет ни одного хоста Linux с выключенным мандатным контролем. Во-вторых, "какая-никакая изоляция в namespaces" это в тебе говорит культ карго и суеверность. Вся эта чешежопица с namespaces и контекстами SELinux существует исключительно потому, что в ядре Linux исторически: - нет нормальных ACL. Вместо них POSIX ACL, которые мусор, они опциональны, и применяются только к ограниченному типу объектов, особенно нет ACL для процессов юзерспейса - нет нормального понимания сессии, вместо этого есть Linux PAM, который ничего ни от кого не изолирует и все запущенные процессы входы в систему считает локальными и равными друг другу - нет способа динамически менять привилегии процесса без его перезапуска - Capability в ядре Linux — это вообще шутка очередная. Вот они годами и правят 1001-у архитектурную ошибку, которая была допущена. Замечаешь, как Linux с каждым годом становится всё больше и больше похож на Windows... хмм... интересно, почему так происходит, не правда ли? > Примеры будут? Мой изначальный тезис в том, что высоконагруженные корпоративные приложения, если нужно избежать виртуализации, сейчас применяются только на Windows с IIS и это суровая реальность. Если же компания реально огромная и их не устраивает Windows и её лицензирования, IIS и сложность его оркестрации, то они радостно форкают BSD. Некоторые типы задач настолько чувствительны к той паразитной нагрузке, которую порождает виртуализация, что там просто выбора нет. Почти всё реалтаймовое, всё что имеет высокий параллелизм, все что работает по принципу "ссылка->данные" (такая задача не кэшируется на процессоре), всё с со сложными многопоточными математическими вычислениями - тонна отраслей и задач. Это ты мне должен привести примеры массового использования докерообразной контейнеризации без грамма виртуалок сразу на железе, раз ты убежден что она активно используется. Сам-то заявляешь, что сидишь с виртуальным кубиком, думая, что те кто покрупнее используют его без виртуалок. А вот нифига! > А по факту уже давно имеется стабильный qemu-kvm runtime реализующий стандарный интерфейс контейнеров - kata-containers называется. > Хорошее решение, переспективное, в духе Red Hat. > Думаю root можно будет открывать по подписке. Ты окончательно запутался, как мне кажется. Именно Red Hat трудится над запихиванием KVM в Kubernetes. Они строят новый OpenShift с поддержкой KVM внутри контейнеров, с поддержкой мультитеннантности с поддержкой изоляции и с возможностью работать на железе. Всё чем ты перечислил — это куски GPL-кода в апстриме, находящиеся под полным контролем Red Hat и выкинутыми наружу частями OpenShift/OKD. Они закрыли oVirt, чтобы разрабатывать это. Я не знаю, за что ты так ополчился на Red Hat, но именно они пытаются решить проблему, о которой я тут распинаюсь и которую ты не видел в виду собственной ограниченности кругозора. Да KVM это ненастоящий (type2) гипервизор. Его виртуальные машины — это процессы в ОС. И весь юзерспейсный инструментарий управления KVM страдает от того, что в нем нет… барабанная дробь… автоматизаций вроде NUMA Spannig для виртуальных машин и гранулярной работой с SMT. И вместо того, чтобы писать и развивать инфраструктуру виртуализации для type2 гипервизора они решили сделать наоборот, сделать уже наконец-то barebone-контейнеризацию, внутри которой можно пихать виртуалки. Вот ты мне говоришь, KVM, будто это что-то хорошее… У него проблемы с уровнем оверкоммита CPU, если его виртуалки слишком разношерстны по ресурсам. Сейчас реальность с KVM такова, что на крупном развертывании KVM можно стабильно жить с overommit 2-4 по CPU. Если нужно выше то нужно: - создавать пресеты виртуалок (понятие flavor в OpenStack) - создавать привязку flavor к образу ОС (в OpenStack Glance) - поставить группу кластеров под каждый flavor<->image - настроить placement api, чтобы оно разносило типы виртуалок по нужным кластерам - использовать только конвергентный сторадж, гиперконвергентные решения не работают от слова "совсем" (Red Hat, конечно, предлагал раньше ставить oVirt на GlusterFS, но там по подписке и они это все закрыли). Вот тогда можно добиться стабильного оверкоммита 4-6. Amazon активно занимается решением этих проблем и по-прежнему продолжает заносить бабло в Citrix, потому что Xen просто работает. Равно как и его младшая сетричка Hyper-V, которая держит оверкоммит 6-8 со стандартными настройками и 8-10 если выключить балунинг и использовать процессоры исключительно одинаковых моделей. VMware близка к этим показателям, и у нее своя специфика. Причем KVM еще и памяти требует больше, чем Hyper-V и VMware, но это уже из-за специфики реализации страничного кэширования в ядре Linux. Я это знаю из опыта работы на хостинг-провайдеров и, да, я работал со всеми кластерами, на высоких провайдерских хайлоадах. Так кот, все эти проблемы на стороне KVM +/- те же самые, что и в кубике, и выражаются они прежде всего в большей степени в косорылых автоматизациях в юзерспейсе, но также и в ущербности самого ядра. KVM-у, как Type2 гипервизору реально место в кубике, потому что нормальную виртуализацию шапка так и не запилила, свой флагманский овирт выкинула. Со стораджем там тоже беда-беда, грозятся новый сторадж писать опять. И всё это опять в OpenShift. > Дядь, ты что опять таблетки пить перестал? Участковый психиатор заругается! Он заругается скорее на то, что я пытаюсь научить очередного хамовитого юнца, как пользоваться компьютером, вместо того чтобы послать его на йух.
	Ответить | Правка | Наверх | Cообщить модератору

	246. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от User (??), 08-Авг-23, 14:16
	Уф. Прям хоть в статью "Метание бисера..." в википедию пиши. Жалко, что все это в недрах комментов пропадет - я процентов 60% описанного цеплял, (не) приятно узнавать, что там еще примерно столько же граблей лежит. До чего ж проще "Моя контейнеромэ таскай, кубера кнопка назимай - все работает, насяльнике! А если плёха работает - твая еще виртуалка нарезай и все-все будит!"
	Ответить | Правка | Наверх | Cообщить модератору

	250. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноньимъ (ok), 08-Авг-23, 18:31
	>А что с TLS на уровне ядра? Зачатки Kernel TLS появились в районе 4.13, а в 5.1 оно только-только стало экспериментально работоспособным. Но мало кто пользуется им еще А как в линуксе с картами типа Chelsio которые могут в TLS оффлоад? Я их немного под фрёй тыкал, там правда свои смешные баги есть...
	Ответить | Правка | К родителю #231 | Наверх | Cообщить модератору

	255. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (115), 09-Авг-23, 03:04
	> А как в линуксе с картами типа Chelsio которые могут в TLS оффлоад? Драйвер тот же самый работает также. Вам потребуется только научить юзерспейсный софт это использовать. Nginx точно может. Ну и вам нужно сравнительно свежее ядро (5.1+). Mellanox работает, значит и эти будут, но я непробовал именно Chelsio, потому что мы их давно не покупаем. Они реализуют iWarp, а не RoCEv2. И это не потому что один хуже другого, они +/- одинаковые, а потому что они не совместимы в рамках одной сторадж-инфраструктуры, и при проектировании сети мы делаем выбор и потом придерживаемся используемого протокола для RDMA. Выбор делается по следующему принципу: - Если нужно спроектировать мультипротокольную сторадж сеть, в которой бизнесу нужно по-разному шейпить разные протоколы, например, нарезать SMB от NFS от iSCSI и прочее, то у вас и так будет много веселья с QoS, и вам придется рулить PAUSE-фреймами в рамках VLAN-ов. Вывод: берите RoCEv2, OFED-прекрасный драйвер и хорошо работает и на Windows и на Linux и на FreeBSD. - Если у вас есть и Infiniband и Ethernet в датацентре, делайте RoCEv2 - Если у вас там что-то маленькое однопротокольное, нет бюджета на нормальные коммутаторы и нужно выдать что-то быстро, и вы готовы потом докупать, исправлять, настраивать, отлаживать. iWarp - ваш выбор. Оно сильно сэкономит время на первичной настройке, но потом придётся настраивать на сетевом железе всё то же самое, что нужно для RoCEv2 изначально. И вот у меня везде RoCEv2.
	Ответить | Правка | Наверх | Cообщить модератору

	252. "Создан форк системы управления контейнерами LXD"	–1 +/–
	Сообщение от Легивон (?), 08-Авг-23, 18:52
	Многа букав, читал по диагонали. Дядь, если Шindoшs такая хорошая, почему на ней не разворачивают сервера? Практика - критерий истины! Весь твой поток недостатков Linux на практике и близко не приближается к недостатком Шindoшs. Именно поэтому она такая "совершенная" (если не забывать переустанавливать раз в неделю) и не нужна никому кроме "домохозяйки". Ну и кроме может быть лютого дремучего кровавого ынтерпрайза с тормозящими монолитами, которым чтобы они чуть меньше тормозили приходится выделять процессоры сокетами, а отсюда и разбираться со всеми нумами, бондингами и большей частью того что ты излил выше. В k8s мирке решили иначе: приложения должны быть маленькими и их нужно запускать сразу на большом количестве ненадежных инстансов и скейлить горизонтально. Даже если ненадежные инстансы падаю - большой проблемы не возникает. Оно и близко не сравнится с проблемой когда дремучий монолит самопроизвольно перезагрузится, потому что ваш господин решил за вас, что ему нужно устанавливать обновления.
	Ответить | Правка | К родителю #231 | Наверх | Cообщить модератору

	258. "Создан форк системы управления контейнерами LXD"	+1 +/–
	Сообщение от Аноним (115), 09-Авг-23, 04:37
	> Дядь, если Шindoшs такая хорошая, почему на ней не разворачивают сервера? Практика - критерий истины! Научись говорить за себя. Разворачивают и много. Взять например: https://stackoverflow.com/ На бекенде у него кластеры с физическим IIS на Windows без виртуализации. И ты не поверишь, но оно микросервисное. Это прекрасно делается и без кубика. Кстати, о кубиках. Если Windows такая никому не нужная, зачем Kubernetes умеет работать поверх Hyper-V и зачем Kubernetes полностью поддерживает работу с контейнерами Windows с IIS внутри: https://kubernetes.io/docs/concepts/windows/intro/ Как ты сказал, "Практика - критерий истины!" > чтобы они чуть меньше тормозили приходится выделять процессоры сокетами, а отсюда и разбираться со всеми нумами, бондингами и большей частью того что ты излил выше Со всем этим разбирается и знаком каждый системный и сетевой администратор, который развернул инфраструктуру виртуализации на предприятии. Это их работа. А тем временем унылые девопсы: 1) не имеют достаточной компетенции, и мозгов чтобы её поднять и научиться работать с железом 2) их контейнеризация не способна жить без виртуализации. Первый тезис доказывают твои же слова: "Многа букав, читал по диагонали." А второй тезис подробно расписан, в том посте, который ты не осилил. Кубик не способен ничего запускать на голом железе, хотя столько крику про то, что контейнеры заменяют виртуализацию. Ложь. Девопсы не способны ничего сделать без бородатого дяденьки админа, который выделил им виртуалку и зарезал права везде, чтобы не лазили. А запускать софт на голом железе без виртуализации всё равно нужно. Виртуализация съедает производительность фактом своего существования. Причем на некоторых типах приложений так сильно, что их обязательно ставят только на железо. И вообще, я не понимаю, почему у тебя так адски бомбит от Windows? Мне кажется, что ты СТАЛ ЖЕРТВОЙ ПОДДЕЛКИ ПРОГРАМНОГО ОБЕСПЕЧЕНИЯ MICROSOFT? Её политика обновлений настраивается на WSUS, а переустанавливать её нужно, только если у тебя полетел системный диск и нет резервной копии. Если ты не понимаешь, как с ней работать, попробуй ОБРАТИТЬСЯ К СИСТЕМНОМУ АДМИНИСТРАТОРУ.
	Ответить | Правка | Наверх | Cообщить модератору

	259. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (259), 09-Авг-23, 07:32
	Спасибо. Нет, серьезно. Если не сложно, можно прояснить тему одну. По поводу недостатков ограничений и прочего понятно. С частью сталкивался либо предполагал что там такие проблемы. И http.sys в своё время удивил в хорошем смысле. А что использовать то? Сейчас и в ближайшем будущем. Какие хранилища вменяемые, что на замену vsan и похожего можно смотреть, какие фс можно применить, что из виртуализации брать, что из контейнеризации вменяемое либо в теории допилят до вменяемого?
	Ответить | Правка | Наверх | Cообщить модератору

	89. "Создан форк системы управления контейнерами LXD"	–2 +/–
	Сообщение от _ (??), 05-Авг-23, 18:12
	>Но увы, софт перестал быть простым, а бесконечного времени у тебя нет. Поэтому жрем чодали и стараемся держаться подальше от моднявых трендов на игого и с нескучными rest(fuck) апи. А мы вот любим "rest(fuck) апи" который реализуется игогой :)  Даже время появилось, хоть и не бесконечное. spoiler Ну нам тут просто KPI сделали насколько мы сасы/пасы/иасы ... Вот теперь жрут на 147% :-D уже сцки думают как бы таких прытких с бонусами кинуть.
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

	96. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от пох. (?), 05-Авг-23, 18:43
	> Ну нам тут просто KPI сделали насколько мы сасы/пасы/иасы ... к счастью нам не грозит уже. При мизерных ресурсах их выделяют чайной ложечкой вручную, чтоб ни одна капля не протекла мимо. А все эти сасы пасы в кривых руках менеджера - это даже не ведро, это труба двухметрового диаметра.
	Ответить | Правка | Наверх | Cообщить модератору

	120. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (35), 06-Авг-23, 00:40
	Нищий туземец, живущий впроголодь, не может понять, зачем белые люди в цивилизованных странах ездят на майбахах. Спойлер: им так нравится.
	Ответить | Правка | Наверх | Cообщить модератору

	150. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от пох. (?), 06-Авг-23, 12:14
	> Нищий туземец, живущий впроголодь, не может понять, зачем белые люди в цивилизованных > странах ездят на майбахах. > Спойлер: им так нравится. так ездит-то не туземец на службе у белых людей (наш '_') - в лучшем случае в багажнике. Ездят белые. Он им просто вместо ковровой дорожки к майбаху - траволатор стелит, чтоб их величества ножкой могли даже и не шевелить. На фсе деньги. Ну и действительно - дорого, красиво, им-так-нравится и KPI растет. А я как копался с другой стороны того же здания в затроившем движке того майбаха, по уши в масле и дерьме, так и копаюсь дальше (он тоже, но - теперь только в свободное от ремонта траволатора время). Только несколько огорчает что в новых сериях чтоб добраться до клапанов надо сначала снять двигатель, что еще бы пол-беды, но почему-то разборка начинается с откручивания левого переднего колеса, казалось бы нахрен не нужного в этом процессе.
	Ответить | Правка | Наверх | Cообщить модератору

	177. "Создан форк системы управления контейнерами LXD"	–1 +/–
	Сообщение от Аноним (35), 07-Авг-23, 01:27
	Судя по вашим представлениям об информационных технологиях (явно отдающими совковым НИИ) - майбахи вы даже за километр не видели. Но, тем не менее, рассуждаете об их ненужности.
	Ответить | Правка | Наверх | Cообщить модератору

	127. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (35), 06-Авг-23, 00:55
	> Ну нам тут просто KPI сделали насколько мы сасы/пасы/иасы ... Вот теперь жрут на 147% :-D уже сцки думают как бы таких прытких с бонусами кинуть. А вы случайно не тот легендарный персонаж, который постоянно пишет про то, что нельзя учить джунов, а то вырастут и работу отнимут?
	Ответить | Правка | К родителю #89 | Наверх | Cообщить модератору

	146. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от пох. (?), 06-Авг-23, 11:10
	>> Ну нам тут просто KPI сделали насколько мы сасы/пасы/иасы ... Вот теперь жрут на 147% :-D уже сцки думают как бы таких прытких с бонусами кинуть. > А вы случайно не тот легендарный персонаж, который постоянно пишет про то, > что нельзя учить джунов, а то вырастут и работу отнимут? даааа, пилить нескучные апи на игогошечке - любой вайтишник с тремя классами образования осилит. (кстати, знаю такую историю успеха. Там не то чтобы совсем вайтишник, но прям совсем-совсем ничего общего с прошлой деятельностью и без в.о., кодить в гугле учился. Сбер-клауд, далее везде.) Правда, такую работу я бы с удовольствием им и отдал. Все равно когда навернется - за мной придут.
	Ответить | Правка | Наверх | Cообщить модератору

	148. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (35), 06-Авг-23, 11:30
	Знаете, такое ощущение, что за вами однажды действительно пришли. Дяди в белых халатах. И теперь вам приходится выходить в интернет тайком, чтобы доктор телефон не отобрал.
	Ответить | Правка | Наверх | Cообщить модератору

	149. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от пох. (?), 06-Авг-23, 11:54
	> Знаете, такое ощущение, что за вами однажды действительно пришли. знаете, такое ощущение что вы проецируете. И дядя в белом халате до вас вовремя не доехал, к большому сожалению. Иначе я ничем не могу объяснить идиотские комментарии под текстами, которые вы, очевидно, даже не понимаете.
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (60), 05-Авг-23, 14:47
	>>Это я тебе, голуба, говорю как краевед Ты от ЧСВ там не лопнешь? Фамильярность вкупе с невежеством вещь жуткая.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	65. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от пох. (?), 05-Авг-23, 15:43
	выросло поколение дол..ов не узнающих цитату. Не, не лопну, глядя на таких вот- разьве что повесишься с тоски.
	Ответить | Правка | Наверх | Cообщить модератору

	110. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (110), 05-Авг-23, 20:18
	Строго говоря, она не такая уж и распространённая. С другой стороны, строго, опять же, говоря: по стилю вполне можно и заподозрить цитату. Сам так и сделал.
	Ответить | Правка | Наверх | Cообщить модератору

	47. "Создан форк системы управления контейнерами LXD"	+1 +/–
	Сообщение от Всем Анонимам Аноним (?), 05-Авг-23, 13:19
	The jail utility appeared in FreeBSD 4.0.    Hierarchical/extensible    jails were introduced in    FreeBSD    8.0. FreeBSD 4. 4.0-RELEASE appeared in March 2000
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	66. "Создан форк системы управления контейнерами LXD"	–4 +/–
	Сообщение от пох. (?), 05-Авг-23, 15:49
	узнаем, узнаем экспертов опеннета, которым приходится цитировать history. Должон тебя разочаровать - тем которое появилось в 4.0 ты и подобные тебе пользоваться бы не сумели - просто ни один привычный параметр не подходит. Оно было для совсем другой цели - для той самой, где S in Docker stands for. Оно не создавало странный аналог виртуальной машины, а просто изолировало от системы ровно настолько, насколько тебе в конкретном случае казалось уместным и без лишних трудозатрат. И увы, история доказала что это был в целом кривой и совсем г-енный подход (потому что опять вместо решения проблемы ее обмотали изоленточкой).
	Ответить | Правка | Наверх | Cообщить модератору

	170. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Neon (??), 06-Авг-23, 23:33
	Майнфреймы бородатых годов (70х) вполне тянули виртуализацию. Порой там гипервизор гипервизором погонял.)))
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	74. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (74), 05-Авг-23, 16:15
	lxd - это не только про контейнеры, с флагом --vm запускаются виртуалки, используя qemu-kvm. Ну и после пары раз использования lxd - Proxmox и Citrix, уже кажутся слишком перегруженными во многих случаях.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	112. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Легивон (?), 05-Авг-23, 21:09
	Потому что во многом тогда не было в них потребности. Писали тогда в подавляющем случае на компилируемых языках, а значит зависимости и так были в достаточной мере обработаны и они медленно менялись. В 2000+ на передний план вылезли интерпритируемые языки с рантайм транзитивными зависимостями. Еще через 10 лет в 2010+ на JS начали писать модули из 1 строчки... Получать хоть сколько-нибудь работоспособное окружение без прибивания программ к фиксированному в докер образе рантайме стало принципиально невозможно. Тогда то и появился докер решивший эту проблему. --- В природке много где так работает. Никто же не может сказать, что facebook был первым сайтиком дли выкладывания фоток. А tinder первый сайтик знакомств... Просто они оказались в нужное время в нужном месте. И закрыли сиюминутные потребности целевой аудитории.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	155. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от mikhailnov (ok), 06-Авг-23, 13:42
	> который будет удобно работать и удобно настраиваться > Си systemd-nspawn
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	174. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (173), 07-Авг-23, 00:39
	А зачем? Контейнеры — это спасение для безответственных программистов и мейнтейнеров, которые не заботятся о совместимости. Если писать код не "тяп-ляп и продакшн", а тщательно прорабатывать, можно и без контейнеров.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	227. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от пох. (?), 07-Авг-23, 22:19
	> А зачем? Контейнеры — это спасение для безответственных программистов и мейнтейнеров, > которые не заботятся о совместимости. "других программистов у меня для вас - нет". > Если писать код не "тяп-ляп и продакшн", а тщательно прорабатывать, можно и начинай.
	Ответить | Правка | Наверх | Cообщить модератору

	211. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (-), 07-Авг-23, 19:51
	> Недоумение вызывает лишь то почему все эти контейнеры не были сделаны ещё в 1995 году на C под эгидой Free Software Foundation. Так они и делались все эти годы под названием hurd.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

26. "Создан форк системы управления контейнерами LXD"	+4 +/–
Сообщение от Ахаха (?), 05-Авг-23, 11:06
> Форки > Нужно изменить лицензию > Срочно переписываем поведение окон в гнум > Добавлена кнопка > Убрана кнопка > Выпуск очередного бравзера, но он ничего не открывает Новости из мира Линукс...
Ответить | Правка | Наверх | Cообщить модератору

	28. "Создан форк системы управления контейнерами LXD"	+7 +/–
	Сообщение от Аноним (28), 05-Авг-23, 11:57
	Новости из мира вантуза: - санкции, срочно ищем замену - майнер в рутрекере - вирусная база успешно обновлена - ваши файлы зашифрованы, для расшифровки отправьте смс
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Создан форк системы управления контейнерами LXD"	–3 +/–
	Сообщение от пох. (?), 05-Авг-23, 15:53
	> - санкции, срочно ищем замену это из другого мира, нижнего. Для rhel вы точно так же ищете замену, как и для ubuntu lts > - майнер в рутрекере майнер в рутрекере, и какое отношение имеет к? > - вирусная база успешно обновлена но remote code exec почему-то в clamav опять > - ваши файлы зашифрованы, для расшифровки отправьте смс redis и mongo не работают (нормально) в windows, это опять из вашего мира новость.
	Ответить | Правка | Наверх | Cообщить модератору

	196. "Создан форк системы управления контейнерами LXD"	–1 +/–
	Сообщение от Вася (??), 07-Авг-23, 11:33
	>майнер в рутрекере Юзаешь свободный от майнеров и рекламы qbittorrent >вирусная база успешно обновлена Для запуска подозрительных ехе есть виртуалки и песочницы, (анти)вирус не нужен >ваши файлы зашифрованы, для расшифровки отправьте смс См. предыдущий пункт. Тащем-та, файлы могут быть и зашифрованы на пингвине, просто <6% десктопа никому не интересно шифровать.
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

	226. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от пох. (?), 07-Авг-23, 22:09
	> См. предыдущий пункт. Тащем-та, файлы могут быть и зашифрованы на пингвине, просто > <6% десктопа никому не интересно шифровать. Поэтому у них шифруют редисы и монги - установленые как раз в виде докера в докере под докером и высунутые голым задом в инет, ведь главное преимущество дыркера - что головой думать не надо, и "есть порты!" (а когда порт надо отфильтровать но не всем - тут-то они и лопаются)
	Ответить | Правка | Наверх | Cообщить модератору

29. "Создан форк системы управления контейнерами LXD"	–1 +/–
Сообщение от Аноним (29), 05-Авг-23, 12:26
Debian внутри своей сборочной инфраструктуры использует lxc, который, в свете последних событий, начнет чахнуть. Ждём от Рхонды патчей. Тонкий намек)))
Ответить | Правка | Наверх | Cообщить модератору

	31. "Создан форк системы управления контейнерами LXD"	+1 +/–
	Сообщение от Аноним (35), 05-Авг-23, 12:55
	Учитывая, что LXC - это тонкая обвязка над ядерными фичами cgroups и namespaces, чахнуть там особо нечему. А если оно и сыграет в контейнер, то написать аналог - не космос. systemd-nspawn делает плюс-минус то же. (Про lxd в данном случае речь не идет, это более высокоуровневая штука. lxd по отношению к lxc - как docker по отношению к containerd.)
	Ответить | Правка | Наверх | Cообщить модератору

	46. "Создан форк системы управления контейнерами LXD"	+1 +/–
	Сообщение от Аноним (29), 05-Авг-23, 13:17
	В lxc есть чему чахнуть, да и на текущий момент уже хватает проблем, особенно это видно при его использовании в отличном от "а давай запустим helloworld". Написать аналог...  к-хм... Тут довести до ума lxc не могут, а ты про аналог. Идеи, код между lxc и lxd гулял в командах, состоящими из одних и тех же людей. Да это и видно по коду, сопровождающим и т.д.
	Ответить | Правка | Наверх | Cообщить модератору

	50. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (5), 05-Авг-23, 13:41
	Гугл подхватил упавшее знамя апстарта, подхватит и lxc.
	Ответить | Правка | Наверх | Cообщить модератору

	69. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от пох. (?), 05-Авг-23, 15:54
	А ему оно - зачем?
	Ответить | Правка | Наверх | Cообщить модератору

	117. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Роман (??), 06-Авг-23, 00:34
	stgraber 1 day ago | root | parent | next [–] The majority of LXD users are actually on ChromeOS which is Gentoo based and uses a LXD ebuild package ... It is used for Crostini. Specifically, ChromeOS uses corssvm to run a virtual machine in which it runs LXD and then creates containers inside of that VM through it. Google has sent the occasional bugfix, usually for pretty complex issues (hard to hit race and the like) but weren't involved in project maintenance or even very actively talking to us. We'd usually bump into the Crostini folks at conferences once or twice a year and just talk over dinner.
	Ответить | Правка | Наверх | Cообщить модератору

	144. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от пох. (?), 06-Авг-23, 11:02
	Ну вроде ж ровно наоборот - "на те, Боже, что нам негоже", и даже разговаривать с плебсом не о чем. Заглохнет развитие (или уедет в ненужые гуглю шнапсы) - просто перестанут возвращать патчи, как с ext2.
	Ответить | Правка | Наверх | Cообщить модератору

	122. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (35), 06-Авг-23, 00:49
	Где подхватил? На официальном портале америконского правительства написано > The latest release was version 1.13 on July 11, 2014. Since December 2018 the project website says that Upstart is in maintenance mode only, and recommends other init system, like systemd.[24]
	Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

	145. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от пох. (?), 06-Авг-23, 11:03
	где где - в гугле! Наверняка проблемы устраняются, баги затыкаются, а может и мелкие фичи полезные гуглю допиливаются (хотя чего там пилить... это ж не системдрянь). Без вас. Зачем возвращать улучшения в проект который не развивается и ничего в них в следующей версии не сломает?
	Ответить | Правка | Наверх | Cообщить модератору

	230. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от swarus (?), 08-Авг-23, 02:36
	Ты для чего lxc использовал что такой негатив. Я использовал (как замену VBOX) проблем не было. Практически все дешовые vps работают через lxc. Единственно с чем сложности возникают: внутри контейнера не поменять hostname (снаружи поменять можно), не работает iptable (точнее работает если целиком выделить интефейс, а для дешевого бриджа нет).
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

	38. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от llolik (ok), 05-Авг-23, 13:02
	А lxc с чего чахнуть должна? Ей от того, что там творится с LXD ни жарко ни холодно. Впрочем, с Каноникла станется. Они и на этом захотят поиметь.
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	41. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (35), 05-Авг-23, 13:08
	А lxc без lxd вообще часто используют? (Я вот на своей практике ни разу не видел, поэтому интересно.)
	Ответить | Правка | Наверх | Cообщить модератору

	48. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Анонус (?), 05-Авг-23, 13:21
	Кажется вот у этих собственная надстройка над LXC https://pve.proxmox.com/wiki/Linux_Container
	Ответить | Правка | Наверх | Cообщить модератору

	59. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (59), 05-Авг-23, 14:31
	Учитывая, что lxc появились лет на 5-7 раньше, чем lxd твой вопрос не имеет смысла Конечно использовался и используется, хотя появление lxd сильно упростило использование, без вопросов
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

	85. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (85), 05-Авг-23, 18:03
	Я использую, потому что у LXD нет возможности развернуть кластер с общим хранилищем на iSCSI. До того, как Canonical забрала LXD себе, у разработчиков были планы по реализации этой фичи, но что будет теперь - хз.
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

	88. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (59), 05-Авг-23, 18:09
	LXD изначально разрабатывался Canonical, нельзя забрать себе то, что тебе и так принадлежит Решили избавиться от мешавших разработки присосавшихся паразитов, да Забрали себе чужое? Нет
	Ответить | Правка | Наверх | Cообщить модератору

	181. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (35), 07-Авг-23, 01:40
	> Решили избавиться от мешавших разработки присосавшихся паразитов, да То есть, основной разработчик проекта - "присосавшийся паразит"?
	Ответить | Правка | Наверх | Cообщить модератору

	217. "Создан форк системы управления контейнерами LXD"	–2 +/–
	Сообщение от пох. (?), 07-Авг-23, 20:24
	конечно. Зарплату же, наверное, получал! Присосался к каноникловским бабкам, паразит! Теперь-ка вот пусть забесплатно поишачит!
	Ответить | Правка | Наверх | Cообщить модератору

	225. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (59), 07-Авг-23, 22:07
	Он решил уйти сам Они избавились от паразитов, изменили путь развития, то что решул уйти он это потеря, но тут выбор человека
	Ответить | Правка | К родителю #181 | Наверх | Cообщить модератору

	103. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (103), 05-Авг-23, 19:13
	использую, без lsd, ой, lxd
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

	140. "Создан форк системы управления контейнерами LXD"	–2 +/–
	Сообщение от microcoder (ok), 06-Авг-23, 08:54
	Нет конечно, LXD это REST сервер для LXC LXD - это LX Deamon LXC - это LX Client
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

63. "Создан форк системы управления контейнерами LXD"	+/–
Сообщение от Alex (??), 05-Авг-23, 15:18
images еще форкните
Ответить | Правка | Наверх | Cообщить модератору

76. "Создан форк системы управления контейнерами LXD"	+1 +/–
Сообщение от Аноним (76), 05-Авг-23, 17:16
Надеюсь в форке таки выпилят SNAP и начнут поставлять бинарями или на худой конец deb. Иначе нафиг этот форк нужен.
Ответить | Правка | Наверх | Cообщить модератору

	189. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Тимофей (??), 07-Авг-23, 09:10
	В debian 12 поставляется https://wiki.debian.org/LXD
	Ответить | Правка | Наверх | Cообщить модератору

77. "Создан форк системы управления контейнерами LXD"	+/–
Сообщение от Аноним (77), 05-Авг-23, 17:20
Я во всем этом пока еще нуб. Объясните мне на пальцах разницу LXC, LXD, Docker и т.д. Что к чему и когда использовать?
Ответить | Правка | Наверх | Cообщить модератору

	79. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Anonimouse (?), 05-Авг-23, 17:43
	LXD - это просто API над LXC. Поэтому нужно искать по запросу LXC vs Docker. Вот тут описание с картинками https://ubuntu.com/blog/lxd-vs-docker
	Ответить | Правка | Наверх | Cообщить модератору

	83. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (85), 05-Авг-23, 17:57
	Docker запускает один процесс в контейнере, LXC - всю ОС (с некоторыми ограничениями). LXD - просто обвязка для LXC для облегчения управления контейнерами. ИМХО, LXC/LXD проще, потому что концептуально это полноценная ОС, не требующая каких-то особых выкрутасов для работы. Но Docker популярнее, поэтому для него есть больше всяких инструментов да и документация гораздо лучше, чем у LXC.
	Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

	91. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (59), 05-Авг-23, 18:15
	https://linuxcontainers.org/lxc/articles/ Прекрасная документация по LXC от Stéphane Graber, еще куча статей обо всем у него в блоге https://stgraber.org/category/lxd/ https://stgraber.org/category/lxс/ В принципе все есть и лучше чем у докера по документации, и напрямую от разработчика, вообще чувак очень толковый, и код пишет, и документацию, и хорошие статьи про то что создал
	Ответить | Правка | Наверх | Cообщить модератору

	100. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (77), 05-Авг-23, 18:59
	Спасибо большое! Уполз читать.
	Ответить | Правка | Наверх | Cообщить модератору

	114. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (59), 05-Авг-23, 21:59
	Не за что Я продвигал lxc в массы с самого его появления и был крайне недоволен тем, что взлетел докер, который в своей идеологии не про то зачем вообще нужны контейнеры И всегда радовало, что у lxc доки от самого основного разработчика, что он столько времени посвящает докам
	Ответить | Правка | Наверх | Cообщить модератору

	128. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (35), 06-Авг-23, 00:59
	> Я продвигал lxc в массы с самого его появления и был крайне недоволен тем, что взлетел докер, который в своей идеологии не про то зачем вообще нужны контейнеры На самом деле, причина проста: lxc объективно жирнее :-3 И по объему, и по степени сложности системы внутри контейнера. Зачем на каждое приложение запускать кучу дополнительных процессов, если они нафиг не нужны для его работы?
	Ответить | Правка | Наверх | Cообщить модератору

	157. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от пох. (?), 06-Авг-23, 15:23
	>> Я продвигал lxc в массы с самого его появления и был крайне недоволен тем, что взлетел докер, который в своей идеологии не про то зачем вообще нужны контейнеры > На самом деле, причина проста: lxc объективно жирнее :-3 в чем именно? > И по объему, и по степени сложности системы внутри контейнера. Зачем на какую ты положил, такая и будет. > каждое приложение запускать кучу дополнительных процессов, если они нафиг не нужны > для его работы? не запускай. lxc совершенно все равно что ты запустишь. А вот когда они нафиг нужны - а это примерно каждый первый дыркерный образ - вся прекрасная концепция летит к чертям. https://pastebin.com/cAiU8SnU - на, наслаждайся. Разница с lxc ровно в том что тут вся система сгнила потому что обновлять ее, естественно, никто не собирался. Ну и в количестве самодельных костылей и подпорок, заменяющих нормальный init и стартовые скрипты. Причем - плохо заменяющих.
	Ответить | Правка | Наверх | Cообщить модератору

	179. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (35), 07-Авг-23, 01:36
	> не запускай. lxc совершенно все равно что ты запустишь. Если запускать в контейнере только одно приложение, то даже запущенный под LXC, он будет иметь отчётливый запашок докера. Разве что жирнообраз корня без дедупликации останется в качестве колорита. > А вот когда они нафиг нужны - а это примерно каждый первый дыркерный образ - вся прекрасная концепция летит к чертям. Да нет, это каждый первый LXC-контейнер. Просто запустить один процесс (и его воркеров, если есть) с ограничениями cgroups, chroot и namespaces - прекрасно справится даже systemd, который есть в каждой первой системе. > Разница с lxc ровно в том что ... её нет. Типичная LXC-система.
	Ответить | Правка | Наверх | Cообщить модератору

	185. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (35), 07-Авг-23, 02:03
	> Просто запустить один процесс (и его воркеров, если есть) с ограничениями cgroups, chroot и namespaces - прекрасно справится даже systemd, который есть в каждой первой системе. Собственно, это к тому, что lxc для этого не нужен. И докер тоже не нужен. Докер - для эффективной и универсальной сборки и поставки серверного ПО. Контейнеризация (изоляция) запущенного процесса - лишь часть картины. А создавать lxc контейнер, чтобы запустить одно приложение, смысла нет. Все фичи и так есть в systemd (ну, или нагородить мини-лапшу из nsenter и cgroup-tools, если хочется овна и юниксвея, всё равно будет проще, чем lxc). Так что lxc нужен как раз для того, чтобы плодить контейнеры для мусора, в которые скидываются ненужные процессы, а также подселяется неприятно пахнущий админ.
	Ответить | Правка | Наверх | Cообщить модератору

	218. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от пох. (?), 07-Авг-23, 20:36
	> Да нет, это каждый первый LXC-контейнер. я тебе показал - вполне себе докерный. Но виновата почему-то lxc. > Просто запустить один процесс (и его воркеров, если есть) с ограничениями cgroups, chroot и > namespaces вообще совершенно не то для чего ставят дыркер. >> Разница с lxc ровно в том что > ... её нет. Типичная LXC-система. Типичная lxc система - полноценная система. В том числе - автоматически обновляющаяся, но с сохранением совместимости. Обновлять систему внутри дыркера - ну это такое... для особо выдающихся.
	Ответить | Правка | К родителю #179 | Наверх | Cообщить модератору

	99. "Создан форк системы управления контейнерами LXD"	+1 +/–
	Сообщение от Аноним (77), 05-Авг-23, 18:58
	О, понятно и доходчиво. Благодарю!
	Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

	106. "Создан форк системы управления контейнерами LXD"	–5 +/–
	Сообщение от пох. (?), 05-Авг-23, 20:03
	> Docker запускает один процесс в контейнере, LXC - всю ОС точно так же - один процесс. Просто это процесс - инит (хотя и необязательно). Что, собственно, хоть и противоречит (никем не читаемому) талмуду докера, но чаще всего в нем тоже и делается. Остальные процессы этот первый процесс запустит сам. Для ОС нужно ядро и драйверы хотя бы паравиртуализованных устройств, контейнер тем и отличается что использует ядро основной системы. > Но Docker популярнее потому что для него есть дыркер-хап. хап-хап-хап и в продакшн.
	Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

	121. "Создан форк системы управления контейнерами LXD"	+2 +/–
	Сообщение от Аноним (35), 06-Авг-23, 00:45
	> точно так же - один процесс. Просто это процесс - инит (хотя и необязательно). Что, собственно, хоть и противоречит (никем не читаемому) талмуду докера, но чаще всего в нем тоже и делается. Чаще всего, героические борцы с докером никогда его не видели.
	Ответить | Правка | Наверх | Cообщить модератору

	126. "Создан форк системы управления контейнерами LXD"	+1 +/–
	Сообщение от Аноним (35), 06-Авг-23, 00:54
	> ИМХО, LXC/LXD проще, потому что концептуально это полноценная ОС, не требующая каких-то особых выкрутасов для работы. То есть, втюхать пользователю 100500 файлов и запустить несколько десятков процессов проще, чем несколько файлов и один процесс?
	Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

	141. "Создан форк системы управления контейнерами LXD"	–2 +/–
	Сообщение от microcoder (ok), 06-Авг-23, 09:01
	LXD это REST сервер, отвечающий на запросы в формате JS LXC это клиент к LXD LXD - LX Deamon LXC - LX Client LXD/LXC работает пока работает главный init процесс в системе/ос/дистрибутиве Docker почти тоже самое, немного управление другое, но смысл тот же, но Docker контейнизирует исключительно пользовательский процесс - запустили Postgres, докер работает. Как только остановили его, весь докер схлопнулся, все процессы системные остановились, всё обнулилось. Можно Докер настроить как LXD, но это авторами не рекомендуется.
	Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

	235. "Создан форк системы управления контейнерами LXD"	+1 +/–
	Сообщение от Аноним (103), 08-Авг-23, 05:54
	"LXC это клиент к LXD" нет, lxc замечательно работает без lxd
	Ответить | Правка | Наверх | Cообщить модератору

86. "Создан форк системы управления контейнерами LXD"	–1 +/–
Сообщение от Всадник Апокалипсиса (?), 05-Авг-23, 18:03
Почему нельзя просто поставить программу в систему и пользоваться ей? Зачем постоянно городить какое-то убожество? Неужели линукс настолько кривая ос, что ей ничего нельзя доверить, не завернув в пять виртуслок и десять контейнеров?
Ответить | Правка | Наверх | Cообщить модератору

	108. "Создан форк системы управления контейнерами LXD"	+1 +/–
	Сообщение от пох. (?), 05-Авг-23, 20:06
	> Почему нельзя просто поставить программу в систему и пользоваться ей? потому что у генитального разработчика была другая система, несовместимая с твоей (она вообще ни с чем несовместима потому что он понатащил туда конгломерат несовместимых версий разных библиотек) И его кот ты и не соберешь у себя не разнеся всю систему в пух и прах. А у тебя, вероятно, она не совсем однозадачная и есть еще вторая программа? Так вот ей нужна - вторая система, снова другая. А других разработчиков у меня для вас уже десять лет как нет. Все пиццей торгуют - оно и прибыльней, и нервы целее, и ты делаешь человечество если не счастливее то хотя бы временно сытее, а не только необратимо ухудшаешь экосистему.
	Ответить | Правка | Наверх | Cообщить модератору

	109. "Создан форк системы управления контейнерами LXD"	+3 +/–
	Сообщение от Аноним (109), 05-Авг-23, 20:08
	> Почему нельзя просто поставить программу в систему и пользоваться ей? Можно. Я разрешаю.
	Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

	134. "Создан форк системы управления контейнерами LXD"	+2 +/–
	Сообщение от Аноним. (?), 06-Авг-23, 03:11
	Запуск в docker сводиться к: docker-compose up или docker run Если мне на один вечер нужен nextcloud, мне нужно тащить php/mariadb, и еще ряд зависимостей в систему?
	Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

	152. "Создан форк системы управления контейнерами LXD"	–3 +/–
	Сообщение от пох. (?), 06-Авг-23, 12:31
	> Запуск в docker сводиться к: > docker-compose up > или docker run что происходит дальше - васяну-с-опеннета знать без надобности. И если тебе дороги настройки и/или это не хеловрот для локалхоста онли - то нет, не сводится, поскольку после run будет еще многа буков и цифров. > Если мне на один вечер нужен nextcloud, мне нужно тащить php/mariadb, и > еще ряд зависимостей в систему? ну ты же не побрезговал притащить цельный дыркер и всю уродливую нахлобучку за ним? The following additional packages will be installed:   golang-docker-credential-helpers libsecret-1-0 libsecret-common   python-backports.ssl-match-hostname python-cached-property python-docker   python-dockerpty python-dockerpycreds python-docopt python-funcsigs   python-functools32 python-jsonschema python-mock python-pbr python-texttable   python-websocket python-yaml - этот мусор только компостер с собой приносит, при уже наличии самого дыркера. Разумеется, ты отлично знаешь что это вот все такое и как работает (а возможно и про историю с первым, совершенно ненужным васяну пакетом, зато ломавшим долгое время docker build). То что авторы нёхклауди ниасилили собрать его ни в какой дистрибутиво-совместимый формат и по прежнему у них там curl | sudo в качестве варианта установки - это просто показатель качества их софта и их собственного умения в системное администрирование. Дыркер они собрали такими же руками, если что.
	Ответить | Правка | Наверх | Cообщить модератору

	167. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним. (?), 06-Авг-23, 20:22
	> что происходит дальше - васяну-с-опеннета знать без надобности. Разумеется необязательно. Если у меня задача - собрать tensorflow с поддержкой работы без avx, я должен: - Пройти курс по нейронкам. - Выучить bazel. - Поставить зависимости. - Глянуть man. - Собрать. - Протестить. Или: - Глянуть man, на флаг для отключения avx. - Запустить докер / собрать. - Протестить. И так с любым приложением, что не поддерживает docker. Сейчас openssl на 3 версию подняли, мне бежать первую искать что-бы ruby/python старые собрать? > ну ты же не побрезговал притащить цельный дыркер и всю уродливую нахлобучку за ним? Ну, я Qemu ставлю, там тоже немало залетает. Как и для inkscape. Да что там говорить, тот же cupsd веб интерфейс поднимает, и бегай его отключай. Вот и как тут понять - это много зависимостей и из-за них софт не ставить или это ок? Так что да, я лучше поставлю один докер. Чем разные версии php/python/ruby/nodejs/библиотек и что там еще может потребоваться для сборки чего-то.
	Ответить | Правка | Наверх | Cообщить модератору

	182. "Создан форк системы управления контейнерами LXD"	+1 +/–
	Сообщение от Аноним (35), 07-Авг-23, 01:49
	> ну ты же не побрезговал притащить цельный дыркер и всю уродливую нахлобучку за ним? Что-то мне лень копипастить сюда содержимое go.mod проекта lxd. Но там всего-то 149 модулей. Минималистично. Впрочем, один фиг это ничего не решает, потому что один раз поставить зависимости, чтобы получить универсальный пакетный менеджер для серверного ПО - не критично.
	Ответить | Правка | К родителю #152 | Наверх | Cообщить модератору

	192. "Создан форк системы управления контейнерами LXD"	+1 +/–
	Сообщение от пох. (?), 07-Авг-23, 10:55
	>> ну ты же не побрезговал притащить цельный дыркер и всю уродливую нахлобучку за ним? > Что-то мне лень копипастить сюда содержимое go.mod проекта lxd. Но там всего-то 149 модулей. экспертиза опеннета пробивает очередное дно... "давайте не будем им мешать и просто понаблюдаем за ними" https://github.com/moby/moby/blob/master/vendor.mod - безусловно, 240 штук только в containerd (у cli, runc и кто там еще - свои) - енто другое! Ну да, ну да - один раз понаставить неведомой хрени (с рутовыми правами и кучей дыр удаленного и не очень управления) о которой ты знаешь ровно ничего кроме единственно вызубренной docker run - это гораздо лучше, чем поставить то что на самом деле требуется сервису которым на самом деле сейчас собираешься воспользоваться. (Собственно, я несколько нечестен наехав на нёхклауд - просто его авторы не совсем полные нули в администрировании и сделали ровно то что и должны были сделать - совершенно независимый от пакетных менеджеров архивчик и простую инструкцию по развертыванию - потому что это, с-ка, код на php, и ему совершенно все равно что у тебя за система и на ней ли самой вообще установлены базы, вебсервер и т д, и вполне вероятно что нет. Хотя пакетик для фатально косоруких могли бы, конечно, положить, а не мини-ос внутри докера с кучей дыр собирать.)
	Ответить | Правка | Наверх | Cообщить модератору

	204. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (204), 07-Авг-23, 16:29
	Тебе не приходило в голову, что может быть просто пофиг? У меня жизнь есть за пределами компьютера, мне нужно чтобы $program_name запустился и работал, в кратчайшие сроки, мне за это платят, а не за то, чтобы я работу у отдела ИБ отнимал. Впрочем, безопасность решений на докере как минимум не хуже, чем поставить пакетик в систему. Как минимум тем, что порты надо явно указывать и обновлять просто. Но чтобы это понять, надо поработать хотя бы эникеем, а не только полы в датацентре мыть.
	Ответить | Правка | Наверх | Cообщить модератору

	208. "Создан форк системы управления контейнерами LXD"	+1 +/–
	Сообщение от пох. (?), 07-Авг-23, 19:15
	> Тебе не приходило в голову, что может быть просто пофиг? тебе настолько пофиг что ты не поленился пересчитать зависимости программы которой ты не пользуешься и не собираешься в принципе. Но квалификация не позволила догадаться что у той которую ты фетишизируешь - то же самое, как у любой игогошной поделки. Только вот я показал ее зависимости которые она тебе в систему тянет, но и это тебе квалификация отличать не позволяет. > жизнь есть за пределами компьютера, мне нужно чтобы $program_name запустился и > работал, в кратчайшие сроки, мне за это платят, а не за Всю остальную свою работу ты тоже делаешь на от...сь? Ну вот это реальная причина существования дерьма подобного докеру. > то, чтобы я работу у отдела ИБ отнимал. Впрочем, безопасность решений > на докере как минимум не хуже, чем поставить пакетик в систему. на порядок хуже. Но тяпляперу бесполезно тратить время это объяснять. > Но чтобы это понять, надо поработать хотя бы эникеем, а не > только полы в датацентре мыть. ну как тебя переведут из поломоев в эникеи - приходи, поговорим. Пока, судя по уровню квалификации и аргументации выбираемых решений - это как раз твой уровень. С зависимостями вот особенно ловко получилось.
	Ответить | Правка | Наверх | Cообщить модератору

	223. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (204), 07-Авг-23, 22:00
	> Но тяпляперу бесполезно тратить время это объяснять. Да даже если бы и было полезно, ты бы всё равно не смог. Твои фантазии ничего общего не имеют с реальностью за пределами твоего локалхоста.
	Ответить | Правка | Наверх | Cообщить модератору

	221. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним. (?), 07-Авг-23, 20:44
	> Ну да, ну да - один раз понаставить неведомой хрени (с рутовыми правами и кучей дыр удаленного и не очень управления) Это проблема мейнтейнеров дистрибутива. А эта команда сколько дерьма поставит? `apt install ffmpeg` И что, теперь видео в онлаин конвертировать? Или на на винду, на Adobe бежать? Ведь Wine, или какая-то vm займет не меньше. > (Собственно, я несколько нечестен наехав на нёхклауд - просто его авторы не совсем полные нули в администрировании) Ну вот и зачем мне php с бд в домашней системе, когда я хочу просто расшарить текстовый файл на семью и иметь возможность грузить фотки с айфонов друзей минуя облака? Ради этой задачи мне нужно провести анализ того, что ставить, что не ставить, засрать систему, а потом вычищать? Или просто: docker run -d -p 8080:80 nextcloud docker system prune -a
	Ответить | Правка | К родителю #192 | Наверх | Cообщить модератору

	229. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от пох. (?), 07-Авг-23, 23:36
	> Это проблема мейнтейнеров дистрибутива. нет, это проблема оверинжиниренной где не надо (и недоделанной где надо) хрени она так написана. > Ну вот и зачем мне php с бд в домашней системе, когда я хочу просто расшарить текстовый файл на > семью затем что выбранный тобой софт, внезапно, пишет в бд (открою тебе тайну - дефолтный контейнер пишет в sqlite и для него ставить ничего не надо, но он явно и сделан на поиграться и выбросить) и написан на php. И в твоей системе для этого все из коробки есть, вообще-то. У меня есть более простые способы расшарить текстовый файл, но тебе они вряд ли подойдут. > Ради этой задачи мне нужно провести анализ того, что ставить, что не ставить, засрать систему, а > потом вычищать? кокой ужос. > docker run -d -p 8080:80 nextcloud и похрен что происходит, ну правильно. Чего вам вот винда не нравилась, не пойму. Кстати, ты скромно пропустил что сам нех надо еще настроить и хотя бы учетки создать (и вот на это и впрямь времени жаль). Или как обычно - admin/admin ?
	Ответить | Правка | Наверх | Cообщить модератору

	232. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним. (?), 08-Авг-23, 03:14
	> У меня есть более простые способы расшарить текстовый файл, но тебе они вряд ли подойдут. Туда еще желательно изменения иметь возможность вносить, так что HTTP файл сервер не вкатит. И тут у нас на выбор SSH/FTP. SSH стоит. Создавать ssh ключ, потом ставить клиенты на телефоны для ssh, форматирования тут не будет. Да и возможность он дает сильно больше. Мне под него новую учетку создавать, если по уму. А там и гляди какой-нибудь lpe появится. С FTP примерно тоже, только у меня его в системе нет. Так что придется еще определится, что ставить. Тогда какой-то HTTP сервер с wysiwyg (привет докер, ну или начинай размазывать говно тонким слоем, по всей системе). Ну я и взял Nextcloud. > кокой ужос. Соглашусь. > и похрен что происходит А что же такого происходит? Скачивается image со всем необходимым, разворачивается контейнер, работает. Ну, может свою сеть создать и свой volume, в зависимости от аргументов. Но чистится это все двумя командами. Если нужно точной такой же другой, например на работе, или в другой компании. Просто дублируем команду. > Или как обычно - admin/admin Ну да. Ровно так и сделал))) У меня в LAN левых устройств нет, да и это комплексный вопрос... А что, я буду создавать свой PKI, сертификат, для выдачи, выпускать сертификат, добавлять всю это шоблу в телефоны, подключать его в клауд, чтобы на завтра снести nextcloud ко всем чертям? Черт... Да я даже не знаю, насколько там сам сервис хорош. Мне редактор текста и возможность грузить файлы подошли, я поставил. И так с любым приложением. Хочешь посмотреть Mattermost, Mastodon, или решить что лучше будет Gitea или Gitlab? Пять секунд, и ты уже смотришь. А дальше ставить нативно, что подошло. Раньше для такого юзал виртуалки, но там еще доставлять что-то приходилось, но зато потом к снимку откатываешься и все, а не вычищаешь все то, что тебе в систему залетело. А тут разработчик уже за тебя сделал. Нужно собрать какой-то устаревший софт. Debian 9 через секунду уже готов. А в CI как docker runner решает. Тут тебе и гугловские приложения собирать можно, и node, и python. Только image меняй.
	Ответить | Правка | Наверх | Cообщить модератору

	233. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним. (?), 08-Авг-23, 03:24
	> Кстати, ты скромно пропустил что сам нех надо еще настроить и хотя > бы учетки создать (и вот на это и впрямь времени жаль). Там говорить нечего. Там учетки, дальше отредактировал конфиг (добавил маску локалки в доверенные), чтобы можно было подключатся. Я даже файлы не монтировал. Просто по id контейнера так и запускаю: docker container start 555e8bf9687a Правда, тут если очистить, как он выключен будет, он слетит. Но как я говорил мне до этого дела нет. Это как транзитный пункт между пользовательскими устройствами и моей ос.
	Ответить | Правка | К родителю #229 | Наверх | Cообщить модератору

	163. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (163), 06-Авг-23, 19:02
	Linux это лебедь рак и щюка (в степени бесконечность). И коперасты регулярно донатят с этой целью в Linux, чтобы это было так.
	Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

	164. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (163), 06-Авг-23, 19:03
	Форк форкнул форк форка, который форком погонял форк.
	Ответить | Правка | Наверх | Cообщить модератору

	165. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (163), 06-Авг-23, 19:04
	Одна надежда на Devuan.
	Ответить | Правка | К родителю #163 | Наверх | Cообщить модератору

	180. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (35), 07-Авг-23, 01:38
	Он ещё не утонул?
	Ответить | Правка | Наверх | Cообщить модератору

111. "Создан форк системы управления контейнерами LXD"	+/–
Сообщение от scriptkiddis (?), 05-Авг-23, 20:27
Все это классно. Но расскажите в чем разница докера/подмана и lxd. В чем lxd лучше/удобнее? Где у него есть большой деплой, посмотреть бы?
Ответить | Правка | Наверх | Cообщить модератору

	125. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Роман (??), 06-Авг-23, 00:53
	Там где ты бы по общей логике выбрал использовать виртуалки, там же почти всегда можно использовать  lxd. Например берёшь сервер в хетцнере,  нарезаешь его через lxd на 100 виртуальных окружений ( VE , облегченные VM) и раздаешь разрабам. Они там внутри если надо уже докеры запускают и прочие непотребства творят.
	Ответить | Правка | Наверх | Cообщить модератору

	142. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от хаха (?), 06-Авг-23, 10:53
	Чем это лучше proxmox ve?
	Ответить | Правка | Наверх | Cообщить модератору

	147. "Создан форк системы управления контейнерами LXD"	+1 +/–
	Сообщение от Роман (??), 06-Авг-23, 11:17
	> Чем это лучше proxmox ve? Работает в моем уютном wsl2 например
	Ответить | Правка | Наверх | Cообщить модератору

	175. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от мнда (?), 07-Авг-23, 01:03
	Так бы и сказал что ничем. А wls2... это многое о тебе говорит.
	Ответить | Правка | Наверх | Cообщить модератору

	190. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (190), 07-Авг-23, 09:23
	не привязано к дебияну
	Ответить | Правка | К родителю #142 | Наверх | Cообщить модератору

	205. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (59), 07-Авг-23, 16:34
	Изначально Proxmox работал только с виртуалками, поддержку контейнеров в нем долго пилили и она была альфой Чем он сейчас лучше? Скорее всего ничем Два инструмента которые можно использовать Тебе привычней Proxmox? Юзай его Привычней LXD? Юзай его Не знаешь ни то, ни то? Посмотри оба и выбери что будет удобней лично тебе
	Ответить | Правка | К родителю #142 | Наверх | Cообщить модератору

	130. "Создан форк системы управления контейнерами LXD"	+1 +/–
	Сообщение от Роман (??), 06-Авг-23, 01:09
	> Все это классно. Но расскажите в чем разница докера/подмана и lxd. В > чем lxd лучше/удобнее? Где у него есть большой деплой, посмотреть бы? Docker is cattle, LXC is pets. Docker packages applications, and should only really have one app inside it. LXC is similar to a vm in it presents itself as a stand-alone machine but uses the host kernel, it’s not like a vm in it’s not as isolated as sharing the host kernel. So with LXC I agree, managing it is like being a sysadmin as that’s what it’s designed to be. I use Docker for things that are stateless, maybe throw away, or just test an app quickly. I use LXC for things I want to run multiple services inside, more statefull, typically where people plumb a bunch of Docker images together in I’ll use LXC
	Ответить | Правка | К родителю #111 | Наверх | Cообщить модератору

	143. "Создан форк системы управления контейнерами LXD"	–2 +/–
	Сообщение от хаха (?), 06-Авг-23, 10:54
	В общем это ничем не лучше proxmox ve или libvirt или virtualbox. И никак не выигрывает у дыркеро поделок. Собсно... ну туда ему и дорога тогда.
	Ответить | Правка | Наверх | Cообщить модератору

	151. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от пох. (?), 06-Авг-23, 12:17
	> В общем это ничем не лучше proxmox ve или libvirt или virtualbox. экспертиза опеннета во всей красе. Ему только что детально разжевали что это вообще перпендикулярно kvm (pve _включает_ в себя lxc) и виртуалшмяксу (хуже которого уже вообще невозможно придумать, но это так, к слову) - но он ни слова не понял. > И никак не выигрывает у дыркеро поделок. Собсно... ну туда ему и к дыркероподелкам это тоже ни малейшего отношения не имеет. Использует те же самые апи ведра, но совсем для другой задачи. Дыркером их решать некошерно и не особо-то и удобно.
	Ответить | Правка | Наверх | Cообщить модератору

	172. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от BrainFucker (ok), 06-Авг-23, 23:35
	> Docker packages applications, and should only really have one app inside it. Не обязательно. Никаких ограничений на это по факту там нет и если очень надо то без проблем.
	Ответить | Правка | К родителю #130 | Наверх | Cообщить модератору

	184. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (35), 07-Авг-23, 01:54
	Ну поставите вы там полноценную систему, ну понапишете внутри контейнера руками конфигов. А потом надо будет пересоздать контейнер (нормальная ситуация на проде), и все ваши правки сотрутся.
	Ответить | Правка | Наверх | Cообщить модератору

	187. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от BrainFucker (ok), 07-Авг-23, 05:41
	Нужную конфигурацию можно описать в dockerfile. А ещё образ докера можно создать на основе существующего контейнера после внесённых изменений в систему.
	Ответить | Правка | Наверх | Cообщить модератору

	193. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от пох. (?), 07-Авг-23, 10:56
	И потом уже никто не сможет распутать этот гадючий клубок. Правильно, всегда так делаем же ж!
	Ответить | Правка | Наверх | Cообщить модератору

	195. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от BrainFucker (ok), 07-Авг-23, 10:59
	А что, документацию по проекту писать уже не модно?
	Ответить | Правка | Наверх | Cообщить модератору

	198. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от пох. (?), 07-Авг-23, 12:41
	ЧЁ?!
	Ответить | Правка | Наверх | Cообщить модератору

	212. Скрыто модератором	+/–
	Сообщение от Аноним (-), 07-Авг-23, 20:06
	Никаких ограничений на шаг вправо-влево нет, но он будет приравниваться к побегу.
	Ответить | Правка | К родителю #172 | Наверх | Cообщить модератору

	240. Скрыто модератором	+/–
	Сообщение от пох. (?), 08-Авг-23, 11:12
	> Никаких ограничений на шаг вправо-влево нет, но он будет приравниваться к побегу. да ну брось, каждый первый образ на дыркерхабе содержит наколеночную из соплей и клея "инициализационную систему" и ведро приложений внутри. Потому что сварм не взлетел, компостер - локалхостовое г-но, а микроархитектура бывает только у фантазеров и псевдо-финтеха (отмывалок и торгашей битками) - у остальных нет столько ненужных данных гонять их туда-сюда без сохранения.
	Ответить | Правка | Наверх | Cообщить модератору

171. "Создан форк системы управления контейнерами LXD"	–1 +/–
Сообщение от BrainFucker (ok), 06-Авг-23, 23:33
Пользовался когда-то LXD, пока не начали форсировать snap, тогда и перешёл на докер. Как раз к тому времени докер допилили и он стал просто работать из коробки. Помню они ещё и в LXD что-то сильно меняли что приходилось маны заново читать, ну их с таким подходом.
Ответить | Правка | Наверх | Cообщить модератору

191. "Создан форк системы управления контейнерами LXD"	–1 +/–
Сообщение от Пряник (?), 07-Авг-23, 09:36
Сначала увидел в трендах (300 звёзд и 600 контрибюторов было). LXD реально крутая штука, наконец-то virsh здорового человека. А вообще побольше libvirt обвязок, его тема реально нераскрыта. Из всех проектов что нарыл в основном старьё и шляпа какая-то (https://www.linux-kvm.org/page/Management_Tools). Не зря Каноникал ухватились за алмаз, они же пытаются себя коммерциализировать, чему я даже рад немного, это подбавит огонька в разработку. Многие open source намного круче проприетарщины. Это лишь потому что open source делают для себя, а проприетарщину, чтобы продать. А продать можно и песок в пустыне и кал медвежий, вокруг этого целая экосистема маркетинга.
Ответить | Правка | Наверх | Cообщить модератору

	194. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от пох. (?), 07-Авг-23, 10:58
	расскажите ему кто-нибудь, что его нае...обманули и lxc не имеет отношения к виртуализации?
	Ответить | Правка | Наверх | Cообщить модератору

	199. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Пряник (?), 07-Авг-23, 12:44
	> Powerful system container and virtual machine manager
	Ответить | Правка | Наверх | Cообщить модератору

	202. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (204), 07-Авг-23, 16:14
	Да ладно? А что тогда вот эта команда ниже делает не подскажешь? > lxc launch images:debian/12 --vm На моём локалхосте запускает виртуалку с двенадцатым дебианом. Попробуй на своём, может у тебя что-то другое делает?
	Ответить | Правка | К родителю #194 | Наверх | Cообщить модератору

	210. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от пох. (?), 07-Авг-23, 19:18
	> Да ладно? А что тогда вот эта команда ниже делает не подскажешь? оберточку для запуска qemu-kvm вызывает. Если это "virsh здорового человека" - ну доктора звать уже поздно.
	Ответить | Правка | Наверх | Cообщить модератору

	213. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (-), 07-Авг-23, 20:08
	Я, конечно, извиняюсь, но qemu можно и без virsh вызвать. Достаточно один раз собрать типовой конфиг и копипастить, меняя параметры.
	Ответить | Правка | Наверх | Cообщить модератору

	219. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от пох. (?), 07-Авг-23, 20:40
	можно, и без lxc тоже. Но в массовых масштабах несколько неудобненько. И несколько странно заменять нормальные инструменты - lxc, где это затычка на случай если с контейнером что-то не задается - нужно еще и ведро специфической версии, например, а менять ради одного раза подход неохота.
	Ответить | Правка | Наверх | Cообщить модератору

	267. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от пох. (?), 11-Авг-23, 18:10
	б-ть, я рад за твой локалхост. А теперь представь что у тебя ентих xyему штук так под пару тыщ только для начала, и это не ненужн0-псевдофинтех, а они все немного разные - все еще хочется чего-то там копипастить? А вот про историю с lxc как враппер для запуска куемы - да, это оно, тут бы ты был прав. В смысле - никакого смысла не имеет, синтаксический сахарок.
	Ответить | Правка | К родителю #213 | Наверх | Cообщить модератору

	224. "Создан форк системы управления контейнерами LXD"	–1 +/–
	Сообщение от Аноним (204), 07-Авг-23, 22:01
	А libvirt — это не обёрточка для qemu-kvm, это другое, понимать надо! Себе доктора вызови, горлопан.
	Ответить | Правка | К родителю #210 | Наверх | Cообщить модератору

	234. "Создан форк системы управления контейнерами LXD"	+1 +/–
	Сообщение от Аноним (115), 08-Авг-23, 04:05
	Это бесполезно, слишком много неграмотных в этом ITT треде =( Но вообще в Linux это сейчас мажорный тренд запихивать процессы виртуалок KVM внутрь контейнеров lxc и в kubernetes. Я сначала подумал, ну что за дичь, а потом подумал еще раз и понял, что им там и место, это же KVM. https://www.redhat.com/en/blog/openshift-virtualization-not-... https://www.redhat.com/en/technologies/cloud-computing/opens... Red Hat активно поднимает хайп вокруг этого, вот бараны и ведутся. А на самом деле разгадка проста: libvirt в целом и virsh в частности Мерзкая дрянь настолько убога, что её не спасти. И вместо того, чтобы хоть как-то автоматизировать управление, было принято решение собирать контейнеры с libvirt, потому что в противном случае нужно было бы написать нормальное API, которое должно быть еще и стабильным. От такой задачи у линуксоидов сразу учащается сердцебиение, повышается артериальное давление и открывается понос. И действительно: - вендоры отраслевого софта не желают работать с KVM, нет API - крупные решения для бекапа то же самое, ну разве что кроме Commvault, вот только те кто могут себе позволить его купить, купят нормальный гипервизор - поддержка виртуальных рабочих столов, опять же... В общем, в Red Hat решили, чтобы не писать по нормальному, взять у Google Kubernetes и использовать его как стабильное API, чтобы потом можно было заключить соглашение с вендорами другого софта. А бомжарам-девляпсам они рассказывают, что виртуалки сами по себе мертвы, а всякое "легаси", которое не поддерживает божественную контейнеризацию и должно быть виртуализировано, можно пихнуть в кубик контейнером. Ты это... будь в тренде, что ли... скоро местные будут тебе это всё рассказывать, когда им это переведут на русский в форме статей на хабре и роликов на ютюбе. Года 2 назад Red Hat уже снимал ролики на эту тему. Актеры сидели в видеочате разговаривали про контейнеры, а когда один чувак заговорил про виртуалки, они поставили его на мьют и продолжали говорить про контейнеры. Не могу найти этот стыд, грохнули наверное, там дизлайков было 90%.
	Ответить | Правка | К родителю #194 | Наверх | Cообщить модератору

	236. "Создан форк системы управления контейнерами LXD"	–1 +/–
	Сообщение от Пряник (?), 08-Авг-23, 09:38
	Если перед сном не дать мозгам отдохнуть 15 минут, а сидеть в телефоне или смотреть телевизор, то на следующий день будет ментальный понос - масли будут лезть сами по себе.
	Ответить | Правка | Наверх | Cообщить модератору

	237. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от пох. (?), 08-Авг-23, 09:59
	> Но вообще в Linux это сейчас мажорный тренд запихивать процессы виртуалок KVM внутрь контейнеров > lxc и в kubernetes. ну, а чо нетак  то? Вот и каноникалы туда же. Только что-то пошло не так и они выбрали свой любимый формат контейнера (вероятно, не вполне осилив k8s... или резонно предположив что этот рыночек уже занят rhbm) > И вместо того, чтобы хоть как-то автоматизировать управление oVirt же ж... был... Ну да, ну да - кто ж даст девляпсу туда доступ, они ж сразу тебе все разнесут. Собственно, и вмварь облажалась со своими cloud containers (там тоже управление через морду сферы...чта?! депляпса пускать в сферу? Да вы ... Ну собственно они тоже тут же все поняли и переделали как надо - нате вам k8s наружу и к управлению самой системой даже близко не подходите.) > - поддержка виртуальных рабочих столов, опять же... SPICE же предан анафеме и его велено забыть? А больше у rhbm ничего в запасе нет.
	Ответить | Правка | К родителю #234 | Наверх | Cообщить модератору

	241. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (115), 08-Авг-23, 12:32
	> oVirt же ж... был... Так всё что было с ним связано не взлетело из-за того как и на чем он был построен. Мы же не говорим про установки по 5-10 хостов, правда. Когда дело касается CSP и крупных контрактов, нужно было предоставлять полноценный продукт и с этим продуктам заключать договоры с другими разработчиками софта и железа. Заявлять о совместимости гарантировать её. Взять например провайдеров. oVirt не поддерживает мультитеннантность и прикрутить её там попросту нельзя и некуда. Нужно полностью переписать. Как они решали вопрос? Ставили поверх него свой OpenStack и продавали саппорт. А зачем тогда oVirt? Kebernetes для провайдеров тоже также. k8saas-решения поверх OpenStack они не предлагали, они предлагали OpenShift, внутри которого есть мультитеннантность из коробки. Но предлагали ставить его поверх oVirt. А API для управления oVirt без OpenStack существует? Нет не существует, если мы конечно не считаем за такое API Ansible (лол). У нормального сервис-провайдера нет религий имени Linux, у него куча разных сервисов по запросам от клиентов. Интеграция с биллингом и с финансовыми системами как с процессингом, так и с обычной бухгалтерией. И что способен сделать oVirt по предоставлению информации об использовании таким-то клиентом таких-то ресурсов за такой-то промежуток времени? Правильно, опять OpenStack. OpenStack у RedHat мягко говоря не самой первой свежести. Сейчас кроме Mirantis (KVM) и CloudBase (Hyper-V) осталась только VMware, которая вещь в себе. Red Hat в полном пролёте. Бомжи открыли "программу CSP" в которой нет ни одного вменяемого и полностью рабочего продукта для CSP, причем спрашивают, типа давайте вы нам скажете что вам надо, а мы вам что-то сделаем. Ну вот вся эта программа и закрылась и "реформировалась". Зоопарк закрывается и провайдерам они готовы предоставить только OpenShift, потому что только способны тянуть разработку только одного инфраструктурного продукта. Тут дело даже не в девляпсах в абсолютной рудиментарности oVirt для решения сколь бы то ни было прибыльное для RH задачи. > SPICE же предан анафеме и его велено забыть? Ну не будьте строгими уж настолько. Протокол обмена данными для _сессионных_ терминалов и VMware не осилила и закрыла свой такой же аналог, забыл как называется. В итоге у них Horizon для Virtual Desktop, а для сессионных терминалов у них MS RDS =) Та же самая логика и у редхата. Это просто не их направление бизнеса. Им хватает VNC, а в GNOME они пихают RDP. С NoMachines NX они работать не хотят, кстати. А конкурент у них по сессионным терминалам всего один - Citrix с его ICA и MS с его RDP, который изначально кусок выкупленный кусок (проприетарный форк) кодовой базы Citrix. А что если я вам скажу, что гильотина уже и над Ceph поднялась: https://www.redhat.com/en/blog/red-hat-storage-strategy-update Мне лично его не жаль. Среди админов сервис провайдеров по СНГ я знаю 2 типа людей: те кто не работает с Ceph и те кто УЖЕ не работает с Ceph после очередного факапа. Он капризный (гибкий, но плохо документированный), там легко можно неправильно задеплоить и отстрелить себе ногу, а клиентам данные. Мониторить и чинить его - адище. А по сравнению с конурнетными решениями по объектным хранилищам вроде тех же VMware VSAN или Microsoft S2D на нем нет возможности использовать виртуализацию и сделать систему гиперконвергентной. Оно просто ломается, оно не понимает, как разделять ресурсы в такой среде. И вот поэтому на протяжении долгих лет гиперконвергентным решением было ставить oVirt прямо поверх кластера GlusterFS, причем его саппорт и даже готовые ISO только по подписочке, потому что там такой костылинг... В общем ждем очередных новостей про то как никто не ждал, не гадал и внезапно Ceph отправляется на... поддержку сообщества, туда же где oVirt и SPICE. Но вы в рунете это не прочитаете, тут активно импортозамещаются на аналоговнетные продукты, которые подбирают с кладбища проектов Red Hat и приносят начальнику в новой маркировке как отечественные и просят грант.
	Ответить | Правка | Наверх | Cообщить модератору

	244. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от пох. (?), 08-Авг-23, 12:58
	> Тут дело даже не в девляпсах в абсолютной рудиментарности oVirt для решения сколь бы то ни было > прибыльное для RH задачи. ну то есть мелкие клиенты нам не нужны потому что (причем мелкие это по-видимому даже не 5-10, а все что меньше пары тыщ хостов) а большим нечего предложить и вообще у них и так все хорошо... ну типичный ibm (не редхат) > А что если я вам скажу, что гильотина уже и над Ceph поднялась: https://www.redhat.com/en/blog/red-hat-storage-strategy-update вроде ж пока "стратегично поапдейтят" непонятно на что? У ебеме есть что-то взамен? Насколько я вижу - стратегично обещают что-то поразработать, а пока сменили аватарку. Не то чтоб этот п-ц было особенно жалко (хотя... а где я буду харчеваться?) но что взамен - предложат побыстренькому прикупить себе ресурсов в S3 и отвалить от ебеме? > И вот поэтому на протяжении долгих лет гиперконвергентным решением было ставить oVirt прямо > поверх кластера GlusterFS Но теперь и gluster все, поплыл по гангу кверху жёппой в индийский океан: https://access.redhat.com/support/policy/updates/rhs (вероятно, вместе с хвостатым коллективом разработчиков, а так же их чады и домочадцы, поскольку жрать им теперь т-по нечего, а содить рис больше негде) Опять же не то чтоб его в его нынешнем виде было особо жаль (умение поймать сплитбрейн на ровном месте и все поудалять так и осталось непревзойденным свойством этого чудо-решения) но что-то я приуныл что вообще халявного sds больше не осталось. И чем я буду импортозамещаться?! Блин, да что ж я винду-то так и не научился админить...
	Ответить | Правка | Наверх | Cообщить модератору

	239. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от Аноним (-), 08-Авг-23, 10:44
	>Но вообще в Linux это сейчас мажорный тренд запихивать процессы виртуалок KVM внутрь контейнеров lxc и в kubernetes. Я так пару лет назад совал статический qemu в докер. Докер сам не любил, но нашёл задачу, на которой мог научиться автоматом перепаковывать образа vm и делать им provisioning. И так я на тот момент стал продавцом докеров, даже типичную докерпропаганду задвигать начал. Сработало.
	Ответить | Правка | К родителю #234 | Наверх | Cообщить модератору

201. "Создан форк системы управления контейнерами LXD"	+/–
Сообщение от Аноним (201), 07-Авг-23, 15:17
Я ничего не понял... Кто кого? Поясните кто-нибудь
Ответить | Правка | Наверх | Cообщить модератору

	206. "Создан форк системы управления контейнерами LXD"	+/–
	Сообщение от yet not so another (?), 07-Авг-23, 18:11
	тоже, очень интересно
	Ответить | Правка | Наверх | Cообщить модератору

238. "Создан форк системы управления контейнерами LXD"	+/–
Сообщение от Аноним (238), 08-Авг-23, 10:09
Постоянно паникуют раньше времени, форки делают, а потом оказывается что основной проект как жил так и живет. Зато столько движухи создали.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема