> Для пакетокрошилки вполне подходящее название -- Обычно под хэшированием нынче понимают нечто типа вычислений чексумм.
> "ну так получилось". :)
Во-во, я и говорю: я поначалу думал что у поттера название дyрное. Как то бесполезная приставка systemd- (==дольше печатать) и nspawn - вроде понятно что запускалка, но какое-то n в начале. Но у вас еще веселее: и длинное имя и по нему вообще нельзя догадаться "а что эта программа делает?"
> Так он-то как раз предлагает рабочий и довольно универсальный вариант.
Вот только этот вариант
1) Не обеспечивает старт контейнеров. Это олдскульная утиля из эпохи когда про контейнеры "не, не слышали".
2) Привилегированные пользователи типа рута не утрачивают возможность "что-то делать" с процессами запущенными через sudo.
ИМХО при таких хотелках наиболее близкое это или полные виртуализаторы, или нечто типа контейнеров с маппингом UID-ов. Но root (являющийся частью "других пользователей") на хосте по любому царь горы и все-таки сможет всем рулить. И тут дилемма - чтобы так не было, надо обуть рута хоста на возможность рулить своей копией системы, от которой разветвляется все остальное. Или этот рут сможет и виртуалку прибить, и контейнер застопорить, и прочее. Что нарушает требование по части того что остальные пользователи кроме вдалельца сервиса не должны мочь что-то делать с ним. Единственные "процессы" которые рут не может прибить так сходу - ядерные треды разве что.
> "Прочие", на минуточку, включают ovz -- а эти ребята гораздо более в курсе.
Они более в курсе. Но сватаемый ими по дефолту сценарий подразумевает какое-то левое ядро. Ну и побочные утилиты. Это неудобно и отнюдь не добавляет симпатий окружающих. По факту это годится только для профессиональных хостеров с высокими требованиями. Остальным такой прыг по граблям явно лишний.
Поскольку "дефолты решают", Поттеринг имхо постепенно займет применения с менее сильными требованиями. Если у меня по дефолту есть systemd и майнлайновое ядро в системе, они могут какие-никакие контейнеры. Логично что ими я и буду по дефолту пользоваться.
Замечу что на мое мнение Поттеринг и шапка дали более чем дофига времени и шансов всем остальным слоупокам. Большинство "контейнерных" флагов clone() умеет давно. Новые требования к системе инициализации высветил не Поттеринг, а сапопикал. Им всем таким хорошим никто не запрещал быть на месте Поттеринга. У них были все карты на руках в виде подходящих технологий. А то что разработчики апстарта слоупочили и до запуска контейнеров вообще додумались "too little and too late", лишь когда Поттеринг и ко показали как это надо было делать правильно - извините, а кто разработчикам апстарта виноват что их обошли на повороте на их же "домашней" трассе?! А OVZ неплохая штука, но по ощущениям они всегда видели в основном только свои бизнес-кейсы aka впаривание виртуозо и рынок хостинга. Это, конечно, здорово. Но в этом месте возникает потенциал для нестыковок интересов. Если ушлым хостерам еще нормально ставить кастомные ядра и что там еще, то вот себе на десктоп и т.п. я никакие кастомные ядра эпохи царя гороха вкатывать не буду. И для меня ценность технологии оказывается здорово ниже чем могла бы быть. Можно запустить в урезанном режиме с майнлайном? Ну ок, а Поттеринг что-то такое вообше по дефолту обеспечивает. А ориентация только на хостеров и архаичные ядра имени Красной Шапки (что там насчет вендорлока, кстати?) мне не импонирует. У меня найдется куча юзкейсов для контейнеров и VM и не связанных с хостингом. Из области общего администрирования, тестирования или разработки.
> Ну погоняйте мне сервисы под нагрузкой в этом вашем сустемде, да чтоб
> не вакуумные, а с реальным I/O, потреблением памяти, разведением процессов/тредов по мере надобности.
Я думаю у вас есть большая проблема с пониманием одной базовой истины. Которая звучит так: то что сегодня у разработчика на его машине, завтра будет в продакшне. Потому что это - удобно. Вот лично мне например неудобно когда я не могу на десктопе в экспериментальном/отладочном режиме воспользоваться тем же набором технологий который будет в продакшне. И нет, я не буду себе никакие кастомные ядра имени красной шапки на десктоп заковыривать. В этом плане OVZ - грабли.
> А потом вернёмся к вопросу взаимовоздействия контейнеров и хоста.
Когда докеры-шмокеры, не требующие кастомных ядер и предоставляющие какие-никакие средства деплоя и управления отжмyт большую часть рынка, а потом придет системдец, когда Поттер окончательно допилит все фичи до того же уровня и отжмет большую часть рынка еще раз, потому что "дефолты решают" - вот тогда мы, действительно, "вернемся к вопросу". А если в ядре чего-то будет недоставать - при таком спросе на эти семейства технологий, это, пожалуй, постепенно и без || могут допатчить. И не говорите что вас не предупреждали.
> Если что, под ovz я добивался работы LTSP на полдесятка пользователей, прочей
> офисной инфраструктуры и (при нагрузочном тестировании) трёх одновременно молотящих сборочниц
Ну вот опять начинаются крутые хостерские сценарии. А то что разработчики OVZ, судя по всему, в принципе не рассматривают работу например на машинах разработчиков в полноценном режиме - на это им какие-то скидки? Я таких скидок делать не собираюсь - мне это неудобно. Очень галимо когда технологией нельзя полноцено пользоваться в режиме разработки и отладки на моем компьютере. Все это обрекает технологию стать узконишевой маргинальщиной.
Так что если кому нравится что OpenWRT сватает кастомную сборочницу как докерский контейнер, давая понять что эти нубы обошли на повороте матерых контейнерщиков на еще одной задаче - ну ок, пусть это будет так. Если некто не хочет делать выводов, рынок может объяснить такие вещи весьма популярно.
> смысле когда сборка на сервере практически не мешала работать на терминалах,
> к нему же подключенных.
Это здорово. Но это нишевой юзкейс. Нужный довольно немногим. А вон та толпа будет openwrt билдить и еще дофига всего делать на докеровских контейнерах. Пройдет немного времени. И "завтра" они все притащат докера в свой продакшн там и тут. А просто потому что умеют с ним работать и набили руку уже. Вы можете игнорировать этот фактор, но когда окажется что OVZ стал специализированной маргинальщиной с довольно скромным рынком, а более general purpose рынок контейнеров начали делить между собой докеры и системды - ну ок, такова жизнь.
> По смыслу-то да, а по практичности -- совсем другое.
Юзкейсы разные бывают. Вот лично для меня например ориентация на кастомный кернел и невозможность получить на разработчиковской машине технологию которая работает идентично с продакшном - кусок грабель, а не фича. А у поттеринга вообще есть жирный козырь, которым он всех подвинет в перспективе - "дефолты решают". Если что-то есть по дефолту, смысла ставить "такое же, но банановое" смысла зачастую мало.
> Так lxc давно было. Просто прародитель фичи вместе с соответствующим юзерспейсом
> был ещё раньше и к тому времени прекрасно работал -- к чему, собственно, и подводил...
У них своеобразные понятия о прекрасном. Не стыкующиеся с моими, и, вероятно, еще много чьими. Де факто, за счет политики || вышло так, что я не вижу для себя реалистичных опций как использовать на моем основном компьютере и в продакшне более-менее идентичный набор технологий от ||. А это весьма неудобно. Нельзя "отпрототипить" технологию там где мне это будет удобно и пойти гвоздить этим в продакшн с околонулевыми изменениями. А еще, чисто по человечески, мне не нравится деление на первый, второй и третий сорт. Если OVZ - второй сорт, то OVZ с майнлайновым ядром - аж третий. А вот докер и даже системд подобных проблем не имеют.
А хостеры, как я смотрю, нынче все чаще KVM любят. Плотность набивки, конечно, ниже. Но оно опять же работает с дефолтным системным ядром и VM ценнее для клиентов из-за возможности запуска произвольных ОС, кастомизации ядер и прочего. А по мере развития железа и инфраструктуры - цены падают, и иной KVM нынче дешевле иного OVZ оказывается. Рынок штука нелинейная.
> Хорошо бы параллельсам сделать ещё один рывок да помержить ещё пласт своих
> наработок в основное ядро.
Есть нехорошее ощущение что время возможно упущено. В смысле, на месте докера могли бы быть они. А т.к. докер все-таки левая хреновина на каком-то там побочном go, по дефолту оно в системе не будет. И тут у systemd неслабое поле для деятельности.
