TrueOffice выпустила ContainerKit для управления LXC-контейнерами в Linux
8Молодая российская Open Source-компания TrueOffice сообщила о завершении разработки набора инструментов ContainerKit для обеспечения легковесной виртуализации в рамках операционной системы GNU/Linux.
Как сообщается в пресс-релизе компании, «ContainerKit — это консольный фронтенд к утилитам легковесной системы виртуализации в ядре Linux (LXC). Он написан на языке PHP и позволяет полноценно управлять контейнерами. Необходимость в его создании возникла из-за того, что использовать утилиты LXC в чистом виде фактически не представляется возможным — разве что в образовательных целях. Одна из особенностей LXC заключается в том, что позволяет организовать виртуализацию без необходимости в наложении сторонних патчей на Linux-ядро, поскольку LXC входит в upstream-ветвь разработки ядра».
С помощью ContainerKit можно создавать, удалять LXC-контейнеры и управлять ими. На текущий момент в качестве хоста поддерживаются GNU/Linux-дистрибутивы Ubuntu и Debian. Тестирование производилось только на последнем стабильном релизе Ubuntu — 10.04 «Lucid Lynx». Для гостевой системы рекомендуется использовать Debian. Для упрощения установки и последующего обновления ContainerKit создан репозиторий с deb-пакетами.
Текущая версия ContainerKit — 1.0-beta, а первый финальный релиз ожидается в течение лета этого года. Инструкцию по установке и использованию ContainerKit (на русском языке) можно найти на www.trueoffice.org.
Постоянная ссылка к новости: http://www.nixp.ru/news/10486.html. Дмитрий Шурупов по материалам TrueOffice.
Rosa Desktop Fresh R10 — обновлённый Linux-дистрибутив из России с KDE 4 и Plasma 5
1
Доступен ALT Linux Engineering — дистрибутив со свободным ПО для промышленности
2
Docker 1.3: подпись образов, параметры безопасности и другие возможности
2 3
Представлено первое обновление Docker в ветке 1.x — 1.1.0
Docker 1.0: Linux-контейнеры готовы для промышленного применения 3
LXC 1.0.0 — первый релиз для production с API для Python, Ruby, Lua и Go 1 1
Последние комментарии
-
OlegL, 17 декабря в 15:00 →
Перекличка
21
-
REDkiy, 8 июня 2023 года в 9:09 →
Как «замокать» файл для юниттеста в Python?
2
-
fhunter, 29 ноября 2022 года в 2:09 →
Проблема с NO_PUBKEY: как получить GPG-ключ и добавить его в базу apt?
6
-
Иванн, 9 апреля 2022 года в 8:31 →
Ассоциация РАСПО провела первое учредительное собрание
1
-
Kiri11.ADV1, 7 марта 2021 года в 12:01 →
Логи catalina.out в TomCat 9 в формате JSON
1
ecobeing.ru
На PHP?! Как-то не очень понимаю как можно такие серьезные вещи написать на скриптовом языке…
Это все стереотипы :)
Мне сложно представить задачу, для которой вообще подходил бы PHP. Это если подходить к выбору инструмента с прагматической точки зрения.
Это больше похоже на фанатизм, а не прагматизм. Чем объективно PHP хуже каких-нибудь Perl и Python для данной конкретной задачи?
Perl я практически не знаю, поэтому эту часть опустим. Что же касается сравнения с Python, то питон просто более серьезный язык со всеми вытекающими. Он более последователен, логичен, ортодоксален, лучше поддерживает ООП стиль, универсальнее, код на питоне гораздо легче воспринимается.
Вообще среди популярных актуальных языков наивно никакого откровенного говна нет — это очевидно. А вот из всяких мелочей и складывается преимещуство одного подобного языка над другим.
на пхп очень просто писать говнокод. В этом его главный недостаток.
Нет, не так формулируешь. На php очень сложно писать не-говнокод. В некотором смысле сложнее чем на C++: для C++ можно найти кучу статей и книг на тему того, что такое хороший код, а что такое плохой. Можно собрать целую библиотеку, прочитать её, потренироваться немного, и писать гарантированно не-говнокод на C++. Для пхп же ничего подобного нету, как хочешь, так изворачивайся.
Я совсем недолго кодил на php. Знаете, когда C++ программисты опасливо говорили «это небезопасный код», мне всегда хотелось посоветовать им кодить в каске, чтобы не бояться своего кода. Но когда я сел писать на php, я пожалел, что у меня нет танка — смеяться мне уже не хотелось.
Perl быстрее и стабильнее (+ CPAN).
Python быстрее, стабильнее и код проще поддерживать (+ import functional).
Что касается трендов, то Python — первый mainstream язык при использовании которого человек думает ЧТО он хочет написать, а не КАК бы это сделать.
(Что касается меня, я бы писал на OCaml, и это фанатизм)
Я ведь специально спросил очень конкретно… Ну, о каком «быстрее» идет речь в данном конкретном случае (в контексте обертки к консольным командам lxc)?
Про стабильность тоже скорее на уровне флейма и стереотипов…
Упс. Словил. Согласен, в данном конкретном случае Perl и Python — overkill, PHP — тоже. :-)
«как можно такие серьезные вещи написать на скриптовом языке» —? Это же интерфейс. Такое на скриптовых языках в наши дни и пишут. В тренде, правда, Python.
Стоп! Как вы уже… надоели стереотипами.
Это же не большой проект, а GUI.
К тому же, PHP более популярен у хостинг-провайдеров и чаще используется в существующих проектах (что позволяет использовать один язык для всех задач). Пусть пишут на том, что знают.
А по поводу ООП: вы поищите в России программистов, которые вообще понимают, что это такое. От инженеров любых пяти софтверных компаний при обсуждении ТЗ вы можете вообще не услышать про такие вещи, как «проектирование»,«тестирование»,«сокрытие данных». Последний товарищ, посетивший мой офис, заявил, что проект объемом в полгода у него в голове, и других мне, как заказчику, не требуется («все заказывали и никто не жаловался»).
Спасибо ТруОфису за GUI к очередной фиче Linux. Хотя лично я за паравиртуализацию (из-за распределения и отказоустойчивости). Думаю, это та контора, где про ООП все-таки что-то знают.
Как это ни удивительно, ваш пост наполнен стереотипами чуть более, чем полностью.
1. Если универсальный инструмент, то нужно учитывать все (хотя я написал еще и о «чаще используется в существующих проектах» — и это более важно).
2. ООП тут при том, что код на PHP как правило не ОО, а код, например, на Java очень часто ОО.
3. ООП хорош при тестировании, при написании, но самое главное — при проектировании, когда всем понятно, кто из программистов отвечает за что.
ООП — это не просто хорошо, это почти идеально, за исключением тех случаев, когда требуется сверхпроизводительность. Но сейчас ресурсы позволяют не экономить на невнятном коде и ассемблерных вставках, и, как правило, высоконагруженные системы поддаются большей оптимизации при денормализации БД, например.
ООП — единственный способ написать читаемый код, который будет поддерживать группа людей. При этом, если всех этих людей уволить и нанять новых, на разбор структуры уйдет в разы меньше времени.
1. PHP — не универсальный инструмент. Частота использования не определяет качество инструмента. Напротив, чаще всего используются некачественные инструменты ввиду их большей доступности.
2. Раз ООП тут ни при чём, то зачем вы вообще его приплели? И причём тут Java? Вы что, просто употребляете все доступные вам buzzwords?
3. Ваш пассаж об ООП говорит мне о том, что вы ничего не понимаете ни в ООП, ни в программировании, ни в проектировании ПО. Поскольку у меня есть некоторое количество свободного времени, давайте остановимся на этом подробнее.
а) во время проектирования совершенно непонятно кто за что будет отвечать и как это вообще будет.
б) вы так и не привели конкретных достоинств ООП. Какие проблемы решает (или должно решать) ООП? Это очень важный вопрос, обязательно на него ответьте.
в) «денормализация БД»?! Что это такое, и зачем это нужно?
г) ООП — ортогонально читаемому коду. Т.е. никак с понятностью кода не кореллирует. Например, на какой вопрос ответить проще: «что делает функция tree_add_node()?» или «что делает метод add()?»
Как я понимаю — это операция обратная нормализации. То есть внесение в реляционную бд избыточности. Зачем это делать, в общем-то тоже понятно: уменьшение числа обращений к разным таблицам, упрощение обработки данных извлекаемых из бд — это, надо думать, может положительно сказаться на производительности, если конечно денормализовывать с умом. Я правда не совсем понял, каким боком это относится к php и/или ООП.