The OpenNET Project / Index page

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

Обзор достижений контейнерной изоляции за последние два года

03.07.2014 11:32

Около двух лет назад на страницах OpenNet было опубликовано интервью с Павлом Емельяновым, руководителем группы разработчиков Parallels Server Virtualization, в котором Павел рассказывал о планах компании по включению кодов контейнерной виртуализации в ядро Linux и проект CRIU. Три года назад, когда проект еще был в начальной стадии, он вызвал волну интереса у пользователей Linux и скептический отзыв у Эндрю Мортона. Осенью 2013 года был анонсирован первый крупный релиз проекта – CRIU 1.0. А сегодня он де-факто стал стандартом реализации технологии checkpoint-restore в Linux.

Напомним, Павел Емельянов отвечает не только за проектирование многокомпонентных систем, основанных на серверной виртуализации, но и организует процесс взаимодействия ядерной команды Parallels с сообществом разработчиков ядра Linux. Один из его любимых проектов, который получился из такой совместной работы, – CRIU: приложение, которое умеет снимать состояние выполняющихся в Linux процессов и восстанавливать в другом месте или в другое время эти процессы из полученных данных. Его целью было заменить существующую реализацию технологии сохранения и восстановления состояния контейнеров, которая, в свою очередь, необходима как база для живой миграции контейнеров.

Сегодня мы публикуем некоторые итоги работы команды Павла и ждем вопросов от сообщества, на которые Павел согласился ответить. Вопросы можно отправлять в свободной форме в комментариях к новости. Ответы будут опубликованы в ближайшие недели. Для пояснения сути контейнеров и оценки целесообразности использования таких систем, в качестве дополнения также приводится перевод статьи Джеймса Боттомли (James Bottomley), известного разработчика ядра Linux, входящего в координационный технический комитет Linux Foundation и занимающего должность технического директора по серверной виртуализации в компании Parallels.

Обзор итогов за 2 года от Павла Емельянова

Недавно в жизни проекта произошло знаменательное событие – Parallels стала сотрудничать с инженерами из компаний Google и Canonical. Последняя, как известно, поддерживает дистрибутив Ubuntu. Они уже влились в проект не только как пользователи, но и как участники - в последнем релизе 1.3-rc2 есть патчи, присланные с адресов @google.com и @canonical.com. Более того, разработчики из Google и Canonical принимают активное участие в обсуждении поддержки cgroup в CRIU и успешно используют CRIU с утилитами Docker и LXC.

Кстати, о Docker и LXC. Эти два проекта в своё время завоевали огромную популярность и потеснили с олимпа проект OpenVZ в мире Linux Containers. Долгое время три проекта сосуществовали параллельно, предлагая пользователям одинаковую по сути, но разную в реализации и деталях технологию. Недавно Docker, Parallels, Canonical, Google и RedHat договорились о слиянии центральных частей своих контейнерных проектов в один - libcontainer - и совместном, согласованном его развитии.

Libcontainer - это системная библиотека, предоставляющая гибкий и достаточно абстрактный интерфейс к ядерным контейнерным компонентам. Немного технических подробностей. В ядре не существует такого понятия как "контейнер". Говоря о контейнерах, разработчики ядра подразумевают несколько разных подсистем ядра, которые позволяют, при правильном использовании, изолировать приложения в виртуальных средах. Это, главным образом, cgroups и namespaces. Прямое использование ядерных интерфейсов возможно, но весьма нетривиально.

Библиотека libcontainer призвана облегчить процедуру их использования, предоставив программистам интерфейс, в котором есть более "привычные" и "возвышенные" понятия, такие как "контейнер", "вычислительные ресурсы", "виртуальная сеть" и т.п.

Помимо развития контейнерной технологии, Parallels видит в Libcontainer ещё и способ получить эту технологию в проекте OpenStack. OpenStack - это набор программ, позволяющий разворачивать облачную инфраструктуру и управлять ею. До сих пор OpenStack работал только с виртуальными машинами, но в последнее время, с развитием контейнерной технологии, сообщество разработчиков OpenStack всё чаще и чаще вспоминает о том, что неплохо было бы создавать контейнеры и в облаках, управляемых OpenStack-ом.

Уже было предпринято несколько попыток достичь этого - RackSpace разработал расширение на основе контейнеров OpenVZ, но это решение не было принято сообществом. Docker предоставил расширение, основанное на своей технологии, но и оно не закрепилось в проекте. В качестве дальнейшего развития разработчики Parallels, Docker, Canonical и, возможно, RackSpace попробуют привнести контейнеры в OpenStack через Libcontainer.

Почему все это сейчас так важно? Дело в том, что контейнерная технология становится ключевым компонентом в большинстве дистрибутивов Linux. Более того, мы все чаще замечаем, что она становится востребованной в корпоративной среде, хотя традиционно считалась уделом хостинг-сообщества.

Поскольку рынок постепенно переходит от простых хостинговых услуг к облачным, мы считаем важным, чтобы у заказчиков были все необходимые для этого инструменты, в том числе - OpenStack и Docker. Последний, в частности, пригодится для упаковки ваших приложений в контейнер. Причины, по которым Parallels поддерживает сразу оба проекта, одинаковые: получить технологии Open Source, на основе которых можно построить дифференцированное предложение, соответствующее конкретным нуждам заказчиков. С помощью OpenStack, компонентов открытой технологии для облачных инструментов и инструментов автоматизации, с помощью Linux Foundation (и Linux в целом) в компании уже работает такое решение, как Parallels Cloud Server.

Сегодня разработчики Parallels помогают создать новое поколение docker-программ, таких как контейнеризированные приложения, и за счет этого расширить количество сценариев использования для контейнеров в вычислительной индустрии. А libcontainer как технология open source для потребления контейнерной виртуализации на уровне детализации – это согласованная (между Docker, LXC, Google и Parallels) возможность сделать это.




Джеймс Боттомли, статья "Почему сегодня так много говорят о контейнерной виртуализации?"

Из всех разнообразных технологий виртуализации контейнеры еще недавно рассматривались либо как недорогой вариант создания инфраструктуры для хостинга, либо как редкая диковинка. Но сегодня, благодаря облачной революции и выходу на первый план таких свойств, как эластичность и вычислительная плотность, контейнеры стали предметом повышенного интереса. Прежде всего, потому, что они больше всего подходят для решения этих задач. Почему же о них раньше забывали, и почему вспомнили сегодня?

В общих чертах виртуализация – это искусство запуска одной операционной системы поверх другой. История ее развития довольно длинная и богатая. Задолго до гипервизоров и UNIX-систем она использовалась в мейнфреймах для разделения различных операционных систем. Широкого признания на рынках UNIX и Linux она добилась лишь где-то в 2001-ом. В этом году компания VMware выпустила серверный продукт для виртуализации на основе гипервизора, привлекший внимание корпоративного рынка. Практически в то же самое время компания Parallels выпустила Virtuozzo, решение для контейнерной виртуализации, получившее большую популярность на рынке хостинга.

Этот барьер сохранялся почти 12 лет: гипервизорная виртуализация не могла отхватить сколько-нибудь значимый кусок хостингового рынка, а контейнеры не могли проникнуть на корпоративный. Такое положение дел продлилось, по крайней мере, до 2013 года – момента появления разработчика Docker и начала роста интереса бизнеса к контейнерной технологии.

Контейнеры против гипервизоров – все дело в плотности

В двух словах, гипервизор работает следующим образом (рис. 1): операционная система хоста эмулирует аппаратное обеспечение, поверх которого уже запускаются гостевые операционные системы. Это означает, что взаимосвязь между гостевой и хостовой операционными системами должна следовать «железной» парадигме (все, что умеет делать оборудование, должно быть доступно гостевой ОС со стороны хостовой).

Напротив, контейнеры (рис. 2) – это виртуализация на уровне операционной системы, а не оборудования. Это означает, что каждая из гостевых ОС использует то же самое ядро (а в некоторых случаях – и другие части ОС), что и хостовая. Это дает контейнерам большое преимущество: они меньше и компактнее гипервизорных гостевых сред, просто потому, что у них с хостом гораздо больше общего. Другой большой плюс: гостевое ядро значительно эффективнее в отношении совместного использования ресурсов контейнерами, так как для него контейнеры представляют собой просто управляемые ресурсы.

К примеру, если Контейнер 1 и Контейнер 2 работают с одним и тем же файлом, то ядро хоста открывает этот файл и размещает страницы из него в страничный кэш ядра. Эти страницы затем передаются Контейнеру 1 и Контейнеру 2: если оба хотят прочитать одни и те же данные, то получают одну и ту же страницу. Если же гипервизорные виртуальные машины VM1 и VM2 выполняют такую же операцию, то сначала сам хост открывает запрашиваемый файл (создавая страницы в своем страничном кэше), а затем еще и каждое из ядер VM1 и VM2 делает то же самое.

Это означает, что при чтении VM1 и VM2 одного и того же файла в памяти существует целых три одинаковых страницы (по одной в страничном кэше хоста и в ядрах VM1 и VM2) – потому, что они не умеют одновременно использовать одну и ту же страницу, как это делают контейнеры. Такое совместное использование ресурсов приводит к тому, что вычислительная плотность (это количество виртуальных сред, которые можно запустить на сервере) почти в 3 раза выше для контейнерной виртуализации, чем для гипервизорной.

Высокая плотность - одна из главных причин, по которым контейнеры стали крайне популярны на рынке хостинга виртуальных выделенных серверов (VPS). Если на одном и том же сервере можно создать в 3 раза больше VPS, то в расчете на один VPS затраты снижаются на 66%. Конечно, не все идеально в мире контейнеров. Например, при «расшаривании» ядра нельзя запускать разные ядра в рамках одного сервера. Поэтому запустить и Windows, и Linux на одном и том же сервере (что для гипервизоров – легкое дело) не получится. Но в Linux, по крайней мере, этот недостаток можно смягчить, используя интерфейсы ABI и библиотеки, что делает возможным запускать на одном сервере контейнеры с различными дистрибутивами Linux. Правда, это достигается ценой уменьшения общей для этих контейнеров части ресурсов. Максимально преимущества контейнеров проявляются в однородной среде.

История контейнеров

В 2005 году компания Google решала проблемы массового предоставления веб-сервисов, а именно - искала способ эластичного масштабирования ресурсов в своем центре обработки данных таким образом, чтобы каждый пользователь получил достаточный уровень сервиса в любой момент, независимо от текущей загрузки, и чтобы использовать оставшиеся ресурсы для служебных фоновых задач.

Сотрудники Google экспериментировали с традиционной виртуализацией для решения этой задачи, но быстро пришли к выводу, что она не подходит. Главной проблемой стало то, что потеря производительности слишком высока (а плотность, соответственно, слишком низка) и отклик недостаточно эластичен для массового предоставления веб-сервисов. Последний пункт очень важен, потому что предсказать, сколько запросов - десятки, сотни или даже миллионы – будут обслуживать веб-сервисы, невозможно. Но пользователи при этом всегда ждут немедленного ответа (а это означает секундную разницу между нажатием кнопки и появлением результата на экране), независимо от того, сколько именно других пользователей в этот же момент работает с сервисом. Учитывая среднее время загрузки гипервизорной ВМ в десятки секунд, такой тип виртуализации не подходит для этой задачи.

В то же самое время группа разработчиков экспериментировала с Linux и концепцией, основанной на механизме cgroups, называющейся «контейнеры процессов». В считанные месяцы Google наняла эту группу для работы над контейнеризацией своих дата-центров в целях решения проблемы эластичности при масштабировании. В январе 2008 года часть технологии cgroup, используемой в Google, перешла в ядро Linux. Так родился проект LXC (LinuX Containers). Приблизительно в это же время компания Parallels выпустила OpenSource-версию своей виртуализации Virtuozzo под названием OpenVZ. В 2011-ом Google и Parallels пришли к соглашению о совместной работе над своими контейнерными технологиями. Результатом стал релиз ядра Linux версии 3.8 в 2013 году, в котором были объединены все актуальные на тот момент контейнерные технологии для Linux, что позволило избежать повторения болезненного разделения ядер KVM и Xen.

Контейнеры и бизнес: почему ажиотаж идет сейчас?

Для хостинг-провайдеров основное преимущество – плотность. При этом корпоративным клиентам она не слишком-то нужна. Виртуализация для них предлагалась как способ решить проблему низкой утилизации серверного оборудования и найти способ использования свободных вычислительных ресурсов. Таким образом, технология, увеличивающая плотность и за счет этого уменьшающая общую утилизацию ресурсов, для этого сегмента не представляла ценности. Из-за этого контейнеры практически игнорировались корпоративным сегментом, представляющим 85% всего рынка виртуализации. Фактически - всем миром, кроме хостинг-провайдеров.

Ситуация начала меняться с 2010 года – с ростом облачного бизнеса. Облака обещали многое, но компании столкнулись ровно с теми же трудностями, что и Google - эластичное масштабирование ресурсов в дата-центрах плюс к необходимости обеспечивать хороший сервис. И здесь у гипервизоров время загрузки оказалось слишком медленным, чтобы обеспечить быстрый отклик системы, что приводило к неспособности адекватно менять объемы ресурсов. И контейнеры наконец-то начали привлекать внимание: потому что, если вы быстро масштабируетесь, то, в конце концов, истощите лимиты своей физической системы, в то время как контейнеры позволяют обслуживать больше (до 3 раз) клиентских запросов без необходимости добавлять оборудование.

Но возникли следующие проблемы: во-первых, все представления вендоров о виртуализации были искажены гипервизорами (многие просто не знали, что есть и другие варианты), во-вторых, большая часть бюджета в центрах обработки данных уже ушла на покупку и управление гипервизорными решениями. В этом случае полный переход на новую технологию – не такая уж хорошая идея.

Так продолжалось до тех пор, пока в 2013 году на рынок не пришел разработчик Docker и не показал, как легко «упаковать» контейнеризированное приложение в Linux и развернуть его в масштабе прямо в dotCloud (сервис PaaS (Platform as a Service) от Docker). Предприятия заинтересовались. Одновременно OpenStack стал обещать объединить системы управления облаками (Cloud Management) в единую платформу, содержащую обе технологии виртуализации. Тогда бизнес наконец-то увидел возможность управлять своими центрами обработки данных на основе гипервизоров с помощью единого инструмента, который может одновременно разворачивать контейнеризированные приложения в масштабе. Вот теперь шумиха вокруг контейнеров началась всерьез.

Контейнеры и Network Function Virtualization (NFV)

Традиционно в NFV берется сетевая функция, экспортированная через коммутационную матрицу и проксируется в гостевое ядро с помощью средств виртуального драйвера, связанного с коммутационной матрицей. Это позволяет гостевой системе обрабатывать сетевой трафик с той же эффективностью, что и в плоскости передачи данных коммутации, но в виртуальной середе эта операция не поддается программному контролю.

Актуальная, переданная через proxy коммутационная функция появляется в гостевой системе благодаря одному (или набору) относительно стандартных сетевых интерфейсов. А можно ли подсоединить контейнеры к проксированной фукнции коммутационной матрицы с помощью средств сетевого интерфейса? Ответ - да. Дело в том, что контейнер включает в себя технологию, которую называют сетевым пространством имен (network namespace), и ее задача – заставить сетевой интерфейс из совместно используемого ядра появиться только в одном контейнере. Поэтому, до тех пор, пока можно внедрить специальный драйвер в расшариваемое ядро, сетевой интерфейс по-прежнему может быть передан через прокси в отдельный контейнер с помощью пространства имен.

Это может дать контейнеру идентичную способность обрабатывать сетевой трафик в виртуальной среде с помощью специального драйвера, хотя сейчас сетевая функция codecan взаимодействует даже с большей плотностью и эффективностью благодаря занимающей меньше объема контейнерной инфраструктуре. Можно даже подумать о будущем этой концепции: поскольку сетевое пространство имен также независимо от остальных видов контроля в контейнере, скоро можно будет взять набор приложений, запущенных в физической системе, и соединить каждое из них по отдельности с проксированной функцией коммутационной матрицы благодаря тому, что каждое приложение запускается в своем собственном пространстве имен. В этом подходе, называемом контейнеризацией приложения, достаточно, чтобы приложение само по себе лишь частично было размещено в контейнере (в зависимости от того, какие лимиты вам нужно установить). Тогда оно сможет взаимодействовать с плотностями почти в 100 раз больше, чем это возможно при традиционной виртуализации.

Ближайшее будущее: контейнеры – это ответ?

Да, контейнеры – это доказанная технология для плотности, гибкости и масштабирования. Они могут помочь с пакетированием и развертыванием веб-приложений в масштабе, а использование их свойств в веб-приложениях и платформах может решить некоторые сегодняшние проблемы в предоставлении облачных услуг, такие, например, как многопользовательский доступ.

Однако контейнеры - не универсальное решение, поскольку бизнес уже проинвестировал в такие ориентированные на гипервизоры технологии, как, например, SR-IOV, VT-D и Network Function Virtualization. Большинство из них разработаны для связи гостевой виртуальной машины напрямую с аппаратной или коммутационной системой с помощью специального драйвера, установленного в гостевом ядре. Так как контейнерная технология работает на уровне операционной системы, она не может говорить на языке «железа». Хотя почти для каждой корпоративной «железной» гипервизорной технологии (например, SR-IOV или NFV) есть решение, которое может быть использовано в контейнере. Но реальность говорит о том, что если думать только в парадигме гипервизоров, то контейнерная технология не сработает. Решение в том, чтобы посмотреть, как выглядит ваш бизнес и ваша виртуализация сегодня, и спросить себя, как это могло бы работать, если бы вы выбрали контейнеры. Результаты могут вас удивить.



  1. OpenNews: Интервью с Павлом Емельяновым, одним из самых активных российских разработчиков ядра Linux
  2. OpenNews: Red Hat представил Atomic, концепцию модульной ОС на базе изолированных контейнеров
  3. OpenNews: Релиз LXC 1.0, системы управления изолированными контейнерами Linux
  4. OpenNews: Компания Google открыла код системы изолированных контейнеров Lmctfy
  5. OpenNews: Выпуск CRIU 1.0, системы для заморозки и восстановления состояния процессов в Linux
Лицензия: CC-BY
Тип: Обобщение
Короткая ссылка: https://opennet.ru/40126-container
Ключевые слова: container, openvz
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (87) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, Гость (?), 13:04, 03/07/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Павел, у меня вопрос по вашей же OpenVZ, которая успешно применяется в таком решении, как Proxmox VE.
    Сейчас они поддерживают два варианта виртуализации - KVM и контейнеры OpenVZ.
    Используют ядро от чего-то редхатистого, ибо в мейнстриме нет штатной поддержки OpenVZ (во всяком случае, до определенного времени точно не было).

    Будет ли OpenVZ (пусть и через LXC/cgroups) присутствовать в ванильных ядрах Linux?
    Есть ли какой-либо интерес у создателей Proxmox VE к Libcontainer и CRIU/Docker/LXC (вам такая кухня может быть известна)?

    Есть ли планы по выпуску своего готового решения под лицензией AGPL, вроде Proxmox VE, но умеющего CRIU/Docker/LXC/OpenVZ/Virtuozzo?

    Какие решения для ядер BSD вы разрабатываете и будет ли возможность миграции приложений из одного типа контейнера в другое, с платформы на платформу?

     
     
  • 2.6, Pavel Odintsov (?), 13:16, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я не из Parallels, но тоже Павел и могу ответить Оно есть, vzctl из пакета Op... большой текст свёрнут, показать
     
     
  • 3.69, Аноним (-), 01:57, 04/07/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Оно есть, vzctl из пакета OpenVZ. Можете поставить на ядро 3.14 и
    > все у Вас будет. Такие новые ядра, например, в Fedora.

    А в ubnutn LTS ядро 3.14 нормально для таких развлечений? Какие опции конфига для работы vzctl с ванилью требуются и насколько LTSная убунта нужное поддерживает "из коробки"? Есть какие-то быстрые средства проверки совместимости той или иной системы с vzctl?

     
  • 2.10, ssh (ok), 13:36, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Используют ядро от чего-то редхатистого, ибо в мейнстриме нет штатной поддержки OpenVZ (во всяком случае, до определенного времени точно не было).

    FYI на самом деле уже нет. :) в Debian Squeeze было, а в Wheezy предложили использовать LXC. Ну или как Proxmox ядро от RH.

     
     
  • 3.19, Pavel Odintsov (?), 13:52, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Используют ядро от чего-то редхатистого, ибо в мейнстриме нет штатной поддержки OpenVZ (во всяком случае, до определенного времени точно не было).
    > FYI на самом деле уже нет. :) в Debian Squeeze было, а
    > в Wheezy предложили использовать LXC. Ну или как Proxmox ядро от
    > RH.

    В wheezy/squeeze можно использовать стандартное OpenVZ ядро 2.6.32, все пакеты и юзерспейс давно стабильны.

     
     
  • 4.55, Гость (?), 18:22, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Хочется же какие-нибудь 3.15, или рядом.
    Да еще и не из чужеродной федоры, а прям родное, дебиановское. :)
     
  • 4.67, Аноним (-), 01:40, 04/07/2014 [^] [^^] [^^^] [ответить]  
  • –4 +/
    > В wheezy/squeeze можно использовать стандартное OpenVZ ядро 2.6.32,

    Вы знаете, необходимость использовать столь некрофильское ядро - жирный минус. В нем знаете ли есть куча багов разной степени серьезности и непонятной степени бэкпортированности, нет поддержки свежего оборудования, etc.

     
     
  • 5.88, анонимыч (?), 14:41, 24/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Именно RHEL и поддерживает все серверное оборудование :)
    Проприетарные драйверы в rpm от всяких супермикр, хп, деллов есть всегда именно под RHEL и SLES.
    Какое еще Вам железо нужно на сервере? Свежие ноутбучные вебкамеры )))?
     
     
  • 6.89, Аноним (-), 16:19, 24/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Именно RHEL и поддерживает все серверное оборудование :)

    Рхел вообще гoвняшка редкостная, не зря ее убунта выпирает с большинства хостов в интернете. Вот пусть этим и пользуется полтора энтерпрайза.

    > Проприетарные драйверы в rpm от всяких супермикр, хп, деллов

    Проприетарный драйвер - вообще заявка на залет в будущем. Я себе не враг - сами такое DEPЬMO используйте.

    > Какое еще Вам железо нужно на сервере? Свежие ноутбучные вебкамеры )))?

    А самое разное. В ядро коммитят туеву хучу поддержки всего и вся. От мобилочных SoC до infiniband.

     
  • 2.11, Аноним (-), 13:39, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > OpenVZ

    He's dead, Jim. Продержится по инерции ещё пару лет, а потом или кусками войдёт в ядро, либо помрёт ибо с lxc меньше гемора.

     
     
  • 3.17, Pavel Odintsov (?), 13:48, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >> OpenVZ
    > He's dead, Jim. Продержится по инерции ещё пару лет, а потом или
    > кусками войдёт в ядро, либо помрёт ибо с lxc меньше гемора.

    Не хочу Вас расстраивать, но почти все LXC в ядре - это бывший OpenVZ. Так что умирать он если и будет, то лишь вместе с ядром линукса.

     
     
  • 4.68, Аноним (-), 01:42, 04/07/2014 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Не хочу Вас расстраивать, но почти все LXC в ядре - это
    > бывший OpenVZ.

    Вот было бы замечательно если бы OVZ и его управляторы начали работать с современными ядрами вместо окаменелых гoвен мамонта.  

     

  • 1.3, iZEN (ok), 13:09, 03/07/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    FreeBSD/jail — технологии провидцев.
     
     
  • 2.5, Pavel Odintsov (?), 13:11, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Ага, как было 100 нет назад неюзабильное, так и осталось. OpenVZ намого раньше сделал честную и непробиваемую изоляцию по ресурсам, которую с горем пополам всунули в 9й/10й FreeBSD.
     
     
  • 3.7, iZEN (ok), 13:20, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • –4 +/
    > Ага, как было 100 нет назад неюзабильное, так и осталось.

    Это мышкой счёлкать нельзя что ли, приходиться набивать настройки конфигурации с клавиатуры?

    > OpenVZ намого раньше сделал честную и непробиваемую изоляцию по ресурсам

    Так уже честную? А что делать с общим SWAP и протечкой памяти в одном из контейнеров?

     
     
  • 4.9, avagin (?), 13:33, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >> Так уже честную? А что делать с общим SWAP и протечкой памяти в одном из контейнеров?

    Количество swap-а и памяти лимитируется для каждого контейнера в отдельности. Объясните детальнее проблему, о которой вы говорите.

     
     
  • 5.18, iZEN (ok), 13:51, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    В случае с виртуальным сервером, использовать SWAP смерти подобно. Дело в том, что жёсткий диск - самое медленное устройство на сервере и он делится между всеми VPS. А SWAP очень сильно нагружает диски, поэтому малейшая активность свопа у нескольких VPS приведет к тому, что все виртуальные сервера, размещенные на этом сервере, практически перестанут отвечать на запросы.
     
     
  • 6.21, Pavel Odintsov (?), 13:56, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    В OpenVZ ранее вообще не было swap И юзаться он мог лишь при лютейшем недостатк... большой текст свёрнут, показать
     
     
  • 7.23, iZEN (ok), 14:05, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Вот тут описан способ надувательства контейнерной виртуализации OpenVZ, в процессе которого память всё равно в итоге распределяется неэффективно: http://openhosting.ru/vps/xen-vs-openvz.jsp

    Про эмуляцию SWAP в памяти с полосой пропускания на уровне механики — это из разряда запудрить мозги пользователю, авось обойдётся. Пусть почувствует, что его контейнер начал использовать жёсткий диск. :))

    Вот ещё давнишняя проблема контейнерной виртуализации на Linux: http://www.stableit.ru/2010/03/openvz.html (см. недавние комментарии — проблема так и не решена)

     
     
  • 8.25, Pavel Odintsov (?), 14:22, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Более бездарного обзора как Xen, так и OpenVZ не видел http openhosting ru vp... большой текст свёрнут, показать
     
     
  • 9.26, Pavel Odintsov (?), 14:24, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    gt оверквотинг удален А по поводу http www stableit ru 2010 03 openvz html -... большой текст свёрнут, показать
     
     
  • 10.64, Аноним (-), 01:29, 04/07/2014 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Не тратьте на iZEN время - это фрибсдшный болванчик, который openvz не видел даж... текст свёрнут, показать
     
  • 8.71, Аноним (-), 01:59, 04/07/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ты конечно извини, но сравнивать OpenVZ с Xen - то же самое что сравнивать Теслу... текст свёрнут, показать
     
  • 6.31, avagin (?), 14:49, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я бы на вашем месте сначала ознакомился с технологией. vSwap к реальному swap-у имеет маленькое отношение. Когда контейнер начинает юзать vSwap, то физический своп не используется, а все данные сохраняются в памяти, а скорость этой операции искусственно замедляется. В результате пользователь, вышедший за лимит памяти, не получается отказ в ресурсах, а получает их с меньше скоростью, т е все как на реальной машине.
     
     
  • 7.33, iZEN (ok), 14:58, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • –4 +/
    > Я бы на вашем месте сначала ознакомился с технологией. vSwap к реальному
    > swap-у имеет маленькое отношение. Когда контейнер начинает юзать vSwap, то физический
    > своп не используется, а все данные сохраняются в памяти, а скорость
    > этой операции искусственно замедляется. В результате пользователь, вышедший за лимит памяти,
    > не получается отказ в ресурсах, а получает их с меньше скоростью,
    > т е все как на реальной машине.

    Да это понятно, что мухлёж в памятью, которой выделяется чуть больше, чем пользователь реально оплатил. В итоге-то держать какой-то объём дорогой оперативной памяти в резерве для каждого контейнера, а при его использовании будет эмулироваться дисковая механика — очень забавно со стороны и смотрится, и чувствуется. Ж))


     
     
  • 8.35, Pavel Odintsov (?), 15:02, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    gt оверквотинг удален Предложите лучше, реализуйте лучше Пришлите патчи на LW... большой текст свёрнут, показать
     
     
  • 9.51, Аноним (-), 16:29, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    gt оверквотинг удален Zones ... текст свёрнут, показать
     
     
  • 10.52, Pavel Odintsov (?), 16:41, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    А разве в зонах swap был не на обычных ZFS пулах Насколько я вижу, можно было л... текст свёрнут, показать
     
  • 10.65, Аноним (-), 01:30, 04/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Желающих иметь с солярой дело нынче что-то весьма немного ... текст свёрнут, показать
     
  • 4.14, Pavel Odintsov (?), 13:42, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    SWAP в OpenVZ изолированный лет 7 как. Также там есть виртульный vSWAP, который вообще в озу. И протечки памяти.... поверю лишь в случае багрепорта на bugzilla.openvz.org
     
  • 3.8, iZEN (ok), 13:22, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > которую с горем пополам всунули в 9й/10й FreeBSD.

    Отчего же с "горем"? Вполне себе бесшовно и прозрачно.


     
     
  • 4.22, Pavel Odintsov (?), 14:03, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >> которую с горем пополам всунули в 9й/10й FreeBSD.
    > Отчего же с "горем"? Вполне себе бесшовно и прозрачно.

    С горем потому, что изолируется от силы половина вещей, которые нужно изолировать. Jails по уровню с трудом дотягивают до Linux Upstream Containers, которые в свою очередь где-то в годах 5 разработки от уровня изоляции в OpenVZ.

     
  • 2.12, Аноним (-), 13:41, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    И vimage уже перестал ядро ронять? Ладно сказки-то травить.
     
     
  • 3.36, iZEN (ok), 15:04, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > И vimage уже перестал ядро ронять? Ладно сказки-то травить.

    wiki.polymorf.fr/index.php/Howto:FreeBSD_jail_vnet

     
  • 2.13, Andrey Mitrofanov (?), 13:41, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > FreeBSD/jail — технологии провидцев.

    Какие из
        * Kernel namespaces (ipc, uts, mount, pid, network and user)
    Ваши провидцы _реализовали _раньше? Реализовали вообще?

     
     
  • 3.15, Pavel Odintsov (?), 13:43, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> FreeBSD/jail — технологии провидцев.
    > Какие из
    >     * Kernel namespaces (ipc, uts, mount, pid, network
    > and user)
    > Ваши провидцы _реализовали _раньше? Реализовали вообще?

    Потрясный список! Я бы еще добавил blkio cgroup и tc для шейпинга :)

     
     
  • 4.24, Andrey Mitrofanov (?), 14:12, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >> Какие из
    >>     * Kernel namespaces (ipc, uts, mount, pid, network and user)
    >> Ваши провидцы _реализовали _раньше? Реализовали вообще?

    2iZEN: Не утруждайтесь, на википедию сам сходил. И половины нет.

    > Потрясный список! Я бы еще добавил blkio cgroup и tc для шейпинга
    > :)

    Это ровно 1 строка из Features с linuxcontainers.org/.

    И дополнить ещё обратным списком "FreeBSD jails are limited in the following ways:" с wikipedia.org/wiki/FreeBSD_jail.

     
     
  • 5.72, Аноним (-), 02:01, 04/07/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > 2iZEN: Не утруждайтесь, на википедию сам сходил. И половины нет.

    Бесшовно работает - язык у изена без костей.

     
  • 3.38, iZEN (ok), 15:11, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • –3 +/
    >> FreeBSD/jail — технологии провидцев.
    > Какие из
    >     * Kernel namespaces (ipc, uts, mount, pid, network
    > and user)
    > Ваши провидцы _реализовали _раньше? Реализовали вообще?

    Что за странный список? К чему он?

    Контенеры jail на площадках хостинг-провайдеров работали уже тогда, когда IBM ещё не выделила на развитие GNU/Linux своего первого миллиарда долларов. Когда в Linux не было никаких способов изоляции приложений кроме дырявого chroot.


     
     
  • 4.39, Andrey Mitrofanov (?), 15:13, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >>> FreeBSD/jail — технологии провидцев.
    >> Какие из
    >> Ваши провидцы _реализовали _раньше? Реализовали вообще?
    > Что за странный список? К чему он?

    Очевидно же, для демнстрации Вашей некомпетентности. Спасибо!

     
     
  • 5.45, iZEN (ok), 15:21, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Концепция FreeBSD/jail доказала право на жизнь ещё тогда, когда Linux путался в пелёнках. Linux до сих пор не имеет 100% работающую собственную контейнерную изоляцию (LXC) — http://habrahabr.ru/post/208746/


     
     
  • 6.47, Andrey Mitrofanov (?), 15:25, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >доказала право на жизнь

    Я же сказал, спасибо, достаточно.

     
  • 6.73, Аноним (-), 02:04, 04/07/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Концепция FreeBSD/jail доказала право

    А теперь вот у хостеров фря пошла в пешее эротическое. Такая вот правда жизни.

     
  • 4.66, Аноним (-), 01:32, 04/07/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Контенеры jail на площадках хостинг-провайдеров работали уже тогда, когда IBM ещё не
    > выделила на развитие GNU/Linux своего первого миллиарда долларов.

    А деревянные бипланы летали раньше Боингов и Эйрбасов. Но почему-то теперь летают в основном на них, а не на деревянных бипланах. Хоть они и раньше были, etc.

     

  • 1.4, Pavel Odintsov (?), 13:10, 03/07/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Основной вопрос/просьба - пожалуйста, не забивайте/забывайте про OpenVZ! criu, docker, libcontainer и прочие они про апстримные контейнеры, которым до продакшена еще лет 5-7 разработки. А на OpenVZ все забили, хотя он в не меньшей степени нуждается в доделках и улучшениях юзерспейса.

     
     
  • 2.16, Аноним (-), 13:44, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    У вас взаимоисключающие параграфы.
     
     
  • 3.20, Pavel Odintsov (?), 13:53, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > У вас взаимоисключающие параграфы.

    Почему они взаимо исключающие? Что мешает прикрутить Докер к OpenVZ? Да никто.

     
     
  • 4.40, iZEN (ok), 15:13, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> У вас взаимоисключающие параграфы.
    > Почему они взаимо исключающие? Что мешает прикрутить Докер к OpenVZ? Да никто.

    OpenVZ — это просто куча патчей для определённой версии ядра. Докеры, скорее всего, не хотят привязываться к определённой проприетарной (хоть и открытой) технологии и версии, вот и всё.


     
     
  • 5.43, Pavel Odintsov (?), 15:20, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >>> У вас взаимоисключающие параграфы.
    >> Почему они взаимо исключающие? Что мешает прикрутить Докер к OpenVZ? Да никто.
    > OpenVZ — это просто куча патчей для определённой версии ядра. Докеры, скорее
    > всего, не хотят привязываться к определённой проприетарной (хоть и открытой) технологии
    > и версии, вот и всё.

    Они вполне хотят - я им писал на GitHub - они с радостью примут патчи для OpenVZ.


     
  • 2.29, Пиони (?), 14:38, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    5-7 это вечность для сегодняшнего мира software. Docker уже релиз, год или максимум два, и он будет повсеместно
     
     
  • 3.30, Pavel Odintsov (?), 14:45, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    В том и дело, что нужно начинать сейчас. Аналогов OpenVZ в любом случае не будет по меньшей мере года 3-4. Все это время будет использоваться стабильное ядро RHEL 6 2.6.32, о котором все забыли в общем-то.

    Если знаете C, присоединяйтесь к допилке libct для OpenVZ :)

     
  • 3.41, iZEN (ok), 15:14, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > 5-7 это вечность для сегодняшнего мира software. Docker уже релиз, год или
    > максимум два, и он будет повсеместно

    В Bhyve тоже будет Докер? Как интересно. Ж))


     
     
  • 4.42, Pavel Odintsov (?), 15:17, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> 5-7 это вечность для сегодняшнего мира software. Docker уже релиз, год или
    >> максимум два, и он будет повсеместно
    > В Bhyve тоже будет Докер? Как интересно. Ж))

    FreeBSD в виртуализации места нету в текущем виде.  Исправятся - тоже сделают Докер =) Хотя он гадость, да.

     
     
  • 5.46, iZEN (ok), 15:24, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • –3 +/
    >>> 5-7 это вечность для сегодняшнего мира software. Docker уже релиз, год или
    >>> максимум два, и он будет повсеместно
    >> В Bhyve тоже будет Докер? Как интересно. Ж))
    > FreeBSD в виртуализации места нету в текущем виде.

    ПОЧЕМУ?! Мышкой нельзя настроить что ли, в этом всё "нет места"?

    > Исправятся - тоже сделают Докер =) Хотя он гадость, да.

    Доделаете LXC до юзабельного состояния — сравнивайте с jail в продакшене. А пока исправляйтесь сами.

     
     
  • 6.50, Pavel Odintsov (?), 15:39, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >>>> 5-7 это вечность для сегодняшнего мира software. Docker уже релиз, год или
    >>>> максимум два, и он будет повсеместно
    >>> В Bhyve тоже будет Докер? Как интересно. Ж))
    >> FreeBSD в виртуализации места нету в текущем виде.
    > ПОЧЕМУ?! Мышкой нельзя настроить что ли, в этом всё "нет места"?
    >> Исправятся - тоже сделают Докер =) Хотя он гадость, да.
    > Доделаете LXC до юзабельного состояния — сравнивайте с jail в продакшене. А
    > пока исправляйтесь сами.

    Вы уже доказали свою квалификацию в познаниях OpenVZ, повторять про LXC тоже самое, честно, смысла не вижу.

     
     
  • 7.74, Аноним (-), 02:06, 04/07/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > честно, смысла не вижу.

    У него везде такая квалификация, увы.

     

  • 1.27, cccc (?), 14:32, 03/07/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    > присланные с адресов @google.com и @canonical.com

    С этих адресов кто угодно может написать. Причем тут разрабы Гугла и Каноникла?

     
     
  • 2.28, Pavel Odintsov (?), 14:36, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >> присланные с адресов @google.com и @canonical.com
    > С этих адресов кто угодно может написать. Причем тут разрабы Гугла и
    > Каноникла?

    Адреса @google.com используются только сотрудниками, публичный - gmail.com.

     

  • 1.32, qqq (??), 14:57, 03/07/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Если мощности процов еще растут и сокращается время компиляции, то сборка пакета и/или дистрибутива может дойти до 1-3 минут. Соответственно любая система виртуализации может быть контейнером для пакета
     
     
  • 2.34, Pavel Odintsov (?), 15:00, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Даже такое уже было в OpenVZ: https://openvz.org/Using_vzpkg_and_vzyum_on_x86_64

    Кратко - была возможность собрать контейнер целиком очень быстро из набора rpm пакетов. Во многом похоже на debootstrap, только быстрее и более унифицирвоанно.

     
     
  • 3.53, qqq (??), 17:18, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    надо научиться как минимум аккумулировать и "консервировать" вычисления, а не просто примитивный ccache
     
     
  • 4.54, Pavel Odintsov (?), 17:56, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Да, тут работы еще ну очень много....
     
  • 2.56, iZEN (ok), 19:01, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Если мощности процов еще растут и сокращается время компиляции, то сборка пакета
    > и/или дистрибутива может дойти до 1-3 минут. Соответственно любая система виртуализации
    > может быть контейнером для пакета

    Можно просто использовать JVM с AOT, писать приложения на обычной Java и других языках для JVM — скорость разработки (а также отладки, исправления ошибок, выпуска новых версий) увеличится в разы по сравнению с протекающим C/C++ крапом. НО ЗАЧЕМ?


     
     
  • 3.57, Pavel Odintsov (?), 20:24, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    iZEN, Вы правда хотите, чтобы Вас еще и в незнании С++/С/Java тыкнули и предметно распяли по полочкам - почему это неверно? =)
     
     
  • 4.61, iZEN (ok), 22:02, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > iZEN, Вы правда хотите, чтобы Вас еще и в незнании С++/С/Java тыкнули
    > и предметно распяли по полочкам - почему это неверно? =)

    Я этого не хочу — это моя ЕЖЕДНЕВНАЯ боль на FreeBSD, так как от малейшего "чиха" в одной из ключевых библиотек на С++ должны быть перекомпилированы все от неё зависимые библиотеки и приложения (а это ВРЕМЯ), а иначе будут глюки, видимые невооружённым глазом. Для Java я такого бедлама не встречал — новое работает со старыми JAR'ками, старое — с новыми JAR'ками. То есть программные "модули" из-за малейшего изменения минорной версии библиотеки в Java не отваливаются и не начинают жить своей жизнью.

    Из недавнего:

    20140611:
      AFFECTS: users of devel/icu
      AUTHOR: bapt@FreeBSD.org

      icu has been updated to 53.1. Please rebuild all ports that depend on it

      If you use portmaster:
            portmaster -w -r icu
      If you use portupgrade:
            portupgrade -fr devel/icu
      If you use pkgng with binary packages:
            pkg install -fR devel/icu

    — стабильно раз в полгода надо делать.

    А ещё есть libjpeg, libpng...

     
     
  • 5.75, Аноним (-), 02:33, 04/07/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > должны быть перекомпилированы все от неё зависимые библиотеки и приложения (а
    > это ВРЕМЯ), а иначе будут глюки, видимые невооружённым глазом.

    Теперь ты понимаешь почему фрибздя повылетела из продакшнов, подчистую проcpaв системам с пакетными менеджерами. Где это время конечно кем-то когда-то тратится, но ты его как правило не тратишь, кроме сильно эксклюзивных случаев.

    > Для Java я такого бедлама не встречал

    Я понял. Изе кто-то сказал что фрибзда - круто. Изя поставил. И обнаружил что управление софтом в фряхе - ужоснax. Поэтому он любит яву. Вот оно что!

    > А ещё есть libjpeg, libpng...

    А в линухе с пакетным манагером такая либа заменяется за 10 секунд, вкатыванием 1 пакета. Приколись? :)

     
     
  • 6.80, iZEN (ok), 22:09, 04/07/2014 [^] [^^] [^^^] [ответить]  
  • –3 +/
    >> А ещё есть libjpeg, libpng...
    > А в линухе с пакетным манагером такая либа заменяется за 10 секунд, вкатыванием 1 пакета. Приколись? :)

    Это потому что ты не видишь дальше собственного носа и не знаешь, как всё работает изнутри. Есть такая возможность: оставлять в системе устаревшие версии библиотек, пока приложения не обновятся и не заработают с новыми версиями. Так вот, в линухах ключевые старые (бажные) версии библиотек, если от них зависят установленные приложения, которые ещё не обновились в репозиториях, резервируются (preserve), хотя с виду всё хорошо: основная библиотека обновилась пакетом с новой версией, да. Вот только она будет использована в новых минорных версиях приложений, а установленные приложения её заигнорят. Полностью обновлённый и исправленный "стек приложений" пользователь получит спустя некоторое время — когда в системе не останется устаревших версий приложений, зависимых от данной библиотеки.

     
     
  • 7.83, pavlinux (ok), 16:06, 05/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    > Это потому что ты не видишь дальше собственного носа и не знаешь,
    > как всё работает изнутри. Есть такая возможность: оставлять в системе устаревшие
    > версии библиотек, пока приложения не обновятся и не заработают с новыми
    > версиями. Так вот, в линухах ключевые старые (бажные) версии библиотек, если
    > от них зависят установленные приложения, которые ещё не обновились в репозиториях,
    > резервируются (preserve), хотя с виду всё хорошо: основная библиотека обновилась пакетом
    > с новой версией, да. Вот только она будет использована в новых
    > минорных версиях приложений, а установленные приложения её заигнорят. Полностью обновлённый
    > и исправленный "стек приложений" пользователь получит спустя некоторое время — когда
    > в системе не останется устаревших версий приложений, зависимых от данной библиотеки.

    Изик, ты в какой-то другой вселенной живешь!

    1. У библиотек есть API.
    2. Библиотеки в дистрибутиве не меняют если изменился API, поэтому он и называется дистрибутив.
    3. Исправления багов не должны затрагивать изменения API
    4. Если в библиотеку добавили фичу, API от этого не меняется или расширяется.
    5. Старая программа не знает о новой фиче, в силу отсутствия у программеров машины времени.
    6. Дистрибутив Gentoo - это несвязанное предложение.  

     
  • 7.90, Аноним (-), 16:51, 24/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Болван ты, изя Я по природе своей - что-то типа системщика И в отличие от тебя... большой текст свёрнут, показать
     
  • 3.87, Аноним (-), 18:26, 07/07/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Изя ты дурак
     
  • 2.60, Аноним (-), 21:48, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    не сокращается. Всякие Страуструпы и его последователи до..юы упорно гогнокодят на шаблонах и убивают весь этот прирост с запасом.
     

  • 1.58, Mirraz (ok), 20:38, 03/07/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    libvirt, libcontainer, Docker, LXC, cgroups & namespaces, ...
    Прослойка на абстракции и библиотекой погоняет.
     
     
  • 2.59, Pavel Odintsov (?), 20:51, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > libvirt, libcontainer, Docker, LXC, cgroups & namespaces, ...
    > Прослойка на абстракции и библиотекой погоняет.

    Да, тут целый ворох сущностей. Но libvirt в стороне от этого, его работа с LXC/OpenVZ стремится к 0.

     

  • 1.62, F (?), 22:23, 03/07/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Эмм, да, до линукса все идеи доходят реально как до жирафа FreeBSD получила ко... большой текст свёрнут, показать
     
     
  • 2.63, F (?), 22:31, 03/07/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > И да, jail от
    > рождения (в четвертой ветке, подверсию не помню) был глюковат - но
    > свои задачи выполнял. В отличие от ...

    Собственно, 4.0, март 2000-го. В продакшен у нас пошла почти сразу по релизу - вместе с новым сервером и Cronyx Sigma на канал к аплинку :)

     
  • 2.70, Аноним (-), 01:57, 04/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Тебя так послушать, так во всём "идейной новизны - ноль". сама бзд - это переизобретение коммерческих юниксов. Не самая удачная попытка, причём.
     
     
  • 3.76, Аноним (-), 02:35, 04/07/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > - это переизобретение коммерческих юниксов. Не самая удачная попытка, причём.

    При том настолько не самая удачная что корпорасы пошли инвестировать в пингвин. Невзирая на то что он вылупился на 10 лет позже, да еще под GPL и (вы только подумайте!) - там делиться надо.

     
     
  • 4.81, pavlinux (ok), 15:59, 05/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> - это переизобретение коммерческих юниксов. Не самая удачная попытка, причём.
    > При том настолько не самая удачная что корпорасы пошли инвестировать в пингвин.
    > Невзирая на то что он вылупился на 10 лет позже,

    ФриБЗДя в 93 появилась, в виде студенческого зародыша. Slakware уже в 92 был.  

     
     
  • 5.82, iZEN (ok), 16:04, 05/07/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >>> - это переизобретение коммерческих юниксов. Не самая удачная попытка, причём.
    >> При том настолько не самая удачная что корпорасы пошли инвестировать в пингвин.
    >> Невзирая на то что он вылупился на 10 лет позже,
    > ФриБЗДя в 93 появилась, в виде студенческого зародыша.

    Ага — с взятым у Novell кодом AT&T Unix и оставленным по обоюдному соглашению.

    "Первая официальная версия FreeBSD 1.0 вышла в декабре 1993 года.", — Wiki.
    А до неё ничего не было.

    > Slakware уже в 92 был.

    Врёшь и не краснеешь.

    "Первая версия этого дистрибутива была выпущена Патриком Фолькердингом — также известным как Mr. Slackware и The Man — 17 июля 1993. Эта версия базировалась на дистрибутиве SLS и представляла собой копию 3,5" дискеты, которую можно было скачать по FTP.", — Wiki.

    "
    From: Patrick J. Volkerding (bf703@cleveland.Freenet.Edu)
    Subject: ANNOUNCE: Slackware Linux 1.00
    Newsgroups: comp.os.linux
    Date: 1993-07-16 17:21:20 PST
    "
    http://www.slackware.com/announce/1.0.php

     
     
  • 6.85, pavlinux (ok), 16:12, 05/07/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > А до неё ничего не было.

    Ты это видел? Что там было у AT&T. Оно вообще работало?

    > Subject: ANNOUNCE: Slackware Linux 1.00
    > Newsgroups: comp.os.linux
    > Date: 1993-07-16 17:21:20 PST

    Это называется вижу только то, что хочу увидеть.

    ---
    В общем пох...й на прошлое.
    В настоящем - BSD в жопе, из TOP500 выброшена как устаревшая.
    Даже нищеброды в деревнях на свои роутеры уже не ставят!

    RIP и Аминь!

     
     
  • 7.86, iZEN (ok), 16:47, 05/07/2014 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Не видел Нам на первом курсе университета Паскаль преподавали и занимались мы н... большой текст свёрнут, показать
     
     
  • 8.92, Аноним (-), 16:55, 24/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    На мух в этой схеме больше всего похожи кадры типа тебя ... текст свёрнут, показать
     
  • 5.91, Аноним (-), 16:52, 24/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > ФриБЗДя в 93 появилась, в виде студенческого зародыша.

    Только ее не с ноля писали. А на основе кода других бздей. А Торвальдс код ни у кого не копипастил.

     
  • 4.84, iZEN (ok), 16:10, 05/07/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > да еще под GPL и (вы только подумайте!) - там делиться надо.

    http://www.youtube.com/watch?v=9GmipSGx5r8


     
  • 2.77, Аноним (-), 02:36, 04/07/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > а приоритет. Пусть и не вылившийся в стратегическое преимущество.

    Проcpaные полимеры - это не приоритет, это хреновое управление проектом, чувак.

     
  • 2.78, angra (ok), 05:52, 04/07/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    virtuozzo и vserver появились тоже на рубеже столетия и предлагали более высокий уровень изоляции.
     
     
  • 3.79, Неадекват (?), 18:20, 04/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Linux-vserver - Октябрь 2001, если быть точным.

    http://www.paul.sladen.org/vserver/archives/200110/

     

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



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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