> Создание резервных копий и восстановление из них (в том числе отдельных файлов).

Как? Неужели и отдельных файлов!? Что? Правда и отдельные можно? Что вы говорите! Нет, я до сих пор поверить не могу!

> Да, согласен. Первый абзац слишком уж тенденциозный вставил.

Все абзацы выдержаны в классическом стиле "пафос маркетоида".

Перепишете пожалуста, здесь люди (как уже написали) технической инфой интересуются: версиями, новыми возможностями (хотя бы по сравнению с прошлым *Альтом*, я уж не буду пытаться сравнивать с другими дистрами).

> Это когда пользователь выбирает удаление всего и автоматическое разбиение и у него есть два одинаковых диска.

Вот это -- интересно. Стоит того, чтобы быть помещенным в новость.

А если три одинаковых диска?

> Это когда пользователь выбирает удаление всего и автоматическое разбиение и у него есть два одинаковых диска.

А если три одинаковых диска? Тоже RAID1? RAID1 создавать глупо, надо, очевидно, RAID5.

> Народ, это — Technology Preview! К релизу будет список файлов и прочее.

А почему тогда в новостях? Где "ждём релиза"?

>Удобное администрирование через веб-интерфейс, не требующее глубокого изучения системы обслуживающим персоналом.

Разве это правилбный подход? Администрирование без глубокого изучения (а значит и знания) сиситемы... Простой интерфейс это одно, а глубокое изучение и знание необходимо (имхо) все равно.

Как я понял из описания, внимания на обычных пользователей, которым не нужны никакие RAID'ы и квоты, было уделено мало. Жаль. так хочется нормального, заточенного под эту страну дистрибутива. Четверка уже стара, плюс в ней куча глюков. В Рунту нету драйверов на видеокарточки плюс ужасный Look'n'Feel.

> Как я понял из описания, внимания на обычных пользователей, которым не нужны никакие RAID'ы и квоты, было уделено мало.

Спорное утверждение. Ещё в 4-ке были для пользователей только KDE и Lite (XFCE) дистрибутивы. Сейчас к ним добавился десктоп на основе Gnome (я уже год как сижу на бете под сизифом) + отлаживается minimal для гурманов, кто любит стаить только то, что ему нужно.

респект!

>Как я понял из описания, внимания на обычных пользователей, которым не нужны никакие RAID'ы и квоты, было уделено мало.

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

> Администрирование без глубокого изучения (а значит и знания) сиситемы... Простой интерфейс это одно, а глубокое изучение и знание необходимо (имхо) все равно.

Есть администратор системы, а есть обслуживающий персонал. Есть разница?

> «Пятая Платформа» является новым шагом в развитии разработки и бизнеса СПО, позволяющим создавать комплексные интегрированные решения и привлечь к их разработке, поддержке, внедрению и обучению разработчиков прикладных решений (свободных и проприетарных)

Что это?

Ничо не понял. Какая-то платформа, какой-то клиент, какой-то сервер. Для чего? Что делает? Кому это надо?

> В Рунту нету драйверов на видеокарточки плюс ужасный Look'n'Feel.

Насчёт Look'n'Feel отчасти согласен. Но посмотрите что можно сделать только из того, что было "в коробке", даже не заходя на gnome-look: http://omploader.org/vMXV0Yg Как по мне - то очень даже удобно и красиво.

> Gnome 5.0

Вау! Сегодня же перехожу на альт линукс =)))

Глянец ужасен :)

http://www.altlinux.org/Git.alt

хехе, написали себе гитхаб. правильной дорогой, ага.

ох и перелезу я когда-нибудь на сизиф.

Виртуализация для установки контейнеров c дополнительным ПО.

>Виртуализация для установки контейнеров c дополнительным ПО.

Видел я тут одну дискуссию с aen'ом и эту строчку в анонсе. Складывается впечатление, что неправильной дорогой идут товарищи. Если для каждой софтины сложнее awk'а будет ставиться контейнер для виртуальной машины, я представляю как это всё будет тормозить, какие будут объёмы обновлений, как гиморно будет эту стаю виртуалок админить и какие невероятные приключения будут ждать тех, кто попытается сделать что-то нестандартное с оконтейнерённым софтом. Тревожно мне.

> Есть администратор системы, а есть обслуживающий персонал. Есть разница?

Растолкуй. Начни с того, когда администратор системы перестал быть обслуживающим персоналом.

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

> Ничо не понял.

Зато я прекрасно понял. Просто ты ничего не смыслишь в энтерпрайзе :)

> Видел я тут одну дискуссию с aen'ом

Видел ты наверное дискуссию аена со мной, кхе-кхе :) АЕН прав, это хорошее решение, но решение тактическое. Мы с ним разошлись в стратегических вопросах, в прочем, не очень далеко.

> Растолкуй.

Нам очень не хватает инструмента, который бы позволил оставить на местах мальчика на побегушках, а дорогого крутого специалиста привлекать только в сложных случаях, и то через SSH. Это как раз такой инструмент, чтобы мальчик запомнил и не ходил направо-налево.

Лично мы используем для решения этой задачи Webmin, но количество напильника на одну инструкцию там слегка зашкаливает.

Ну я вообще намекал, что администратор может вообще не быть персоналом и не числиться в штате фирмы :)

>АЕН прав, это хорошее решение

Ничерта не хорошее. Оно простое. Примитивное, можно сказать. Таскать с каждым продуктом операционную систему - это примерно тоже, что таскать mfc42.dll, только грабли больше. Рано или поздно появится legacy-контейнеры, не совместимые с новыми гипервизорами. Рано или поздно будет решение A, поставляющееся в комплекте с контейнером с решением B. И всё это в контейнере. В больших и старых инфраструктурах такие "матрёшки" будут ещё и ветвиться. И тормоза, тормоза. Я не хочу такого, уж лучше скайнет.

> хехе, написали себе гитхаб. правильной дорогой, ага.

"сборка пакетов в Сизиф и другие бранчи из gear-репозиториев, располагающихся на нём самом"

вау, на гит-хабе и пакеты собирать можно? А система настраивается? :)

На самом деле, главная проблема альта - отсутствие технического паблисити.

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

В то время как те же зюзешники и федоро-редхатовцы собирались не пойми как и не пойми на чём, в альте уже работала автоматическая сборочная система ("аналог OpenSUSE buildfactory", ага, только в альте оно официально работало минимум на пару лет раньше).

Проблема в этом всём ровно одна: человеки, которые это пишут и поддерживают, категорически не видят необходимости в согласовании своих действий с другими сторонами, решающими схожие задачи. И не видят потребности в широком освещении своей деятельности. В итоге "улучшения в управлении OpenSuSE build factory" попадают на первую страницу ЛОРа, а gear/girar остаются уделом узкого круга вляпавшихся.

Параллельно. Кажется даже, github появился чуток позже :)

> Если для каждой софтины сложнее awk'а будет ставиться контейнер для виртуальной машины, я представляю как это всё будет тормозить, какие будут объёмы обновлений, как гиморно будет эту стаю виртуалок админить и какие невероятные приключения будут ждать тех, кто попытается сделать что-то нестандартное с оконтейнерённым софтом.

<advertizing mode> Как бывший сотрудник Параллелза, имевший некоторое отношение к созданию темплитов некоторых из их продуктов, могу сказать, что Ваши тревоги напрасны :)

В VZ (в т.ч., благодаря VZFS'у) накладные расходы на поддержание двух одинаковых по набору библиотек виртуалок близки к поддержанию двух разных приложений на этом физ. хосте. Напихать в среднего размера железку сотню виртуалок с апачами, почтовиками и прочей вебхостинговой требухой внутри - это, в общем, рабочий тест на денсити. Правда, разумеется, если виртуалка создаётся для тяжёлых приложений, вроде СУБД или сборочной фермы, то больше двух-трёх контейнеров на железку не лезет, проверено на себе.

В OpenVZ не всё так шоколадно, там для экономии памяти на шаредных либах приходится попрыгать, но тоже, в общем, решается.

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

Ну и, это, OpenVZ'шный контейнер - это, фактически, "настоящая" развёрнутая система, скопированная в нужное место внутри хостовой системы. Никакого "устаревания формата контейнера" в этом случае не предвидится. </advertizing mode>

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

Что будет жрать -- это место на диске и (не так зверски) память. И -- да, если хочется обновлять все контейнеры сразу (ну... хочется!), то лучше иметь ещё один контейнер с зеркалом обновлений, чтобы по десатку раз одно и то же не качать.

> Администрирование без глубокого изучения (а значит и знания) сиситемы... Простой интерфейс это одно, а глубокое изучение и знание необходимо (имхо) все равно.

Да, но нынче модно называть "системными администраторами" тех, кого раньше называли "операторами ЭВМ" -- эникейщиков. И они ещё обижаются, если их не называть сисадминами. А настоящих админов теперь уж и не знаю как называют. Внедренцами, наверное?

>.....В итоге "улучшения в управлении OpenSuSE build factory" попадают на первую страницу ЛОРа, а....


А кто удаляет новости из стана Альта? Злые модераторы? 

>Наоборот: по быстродействию разницы практически нет,

Ну-ну. Вот допустим у меня есть контейнеры A и B. Оба такие независимые-независимые. И вдруг задачи стали требовать научить продукты A и B работать совместно. Шаред мемори бывает между виртуалками?

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

А всё из-за того, что кое-кто ниасилил:

1. написание секурных невалящихся программ, которые не надо от греха прятать в контейнер

2. следование стандартам, позволяющее один и тот же компонент использовать в составе разных систем без допиливания

Задачи, конечно, сложные (особенно вторая), но именно этим и должны заниматься дистростроители.

> А кто удаляет новости из стана Альта? Злые модераторы?

При чём здесь это? Я хотел сказать, что несмотря на все технологические достоинства, альтовые технологии так и остаются междусобойчиком для посвящённых. С тем же успехом можно обсуждать достоинства трубочных табаков, 99% аудитории трубки в зубах не держали :)

Ну да фиг с ней, с известностью. У этой [псевдо-]элитарности ровно один технический минус - ввиду того, что девелопментом сюзи, федоры и прочих интересуется на порядки больше народу, технологическое первенство и первопроходчество альта неизбежно оборачивается отставанием. Мэйджоры, даже начав позже и кривее, набирают темп за счёт больших ресурсов.

> Ну-ну. Вот допустим у меня есть контейнеры A и B. Оба такие независимые-независимые. И вдруг задачи стали требовать научить продукты A и B работать совместно. Шаред мемори бывает между виртуалками?

С точки зрения хостовой системы, процессы, запущенные внутри контейнеров, - обычные процессы, и при желании можно обеспечить им совместное использованием одних и тех же shmem'овских сегментов. Так что, всё упирается в реальность потребностей и обеспечение необходимых мер безопасности при реализации решения. На моей памяти так проделывали технологическую дырку из пользовательских VPS'ок к VZagent'у.

> Опять же одни и те-же либы в A и B могут быть пропатчены разными совершенно дикими способами (а что, разработчикам ничто не мешает ломать совместимость с мейнстримом). Посему нестандартная (непредусмотренная авторами контейнеров) настройка может вылиться в программирование.

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

> А всё из-за того, что кое-кто ниасилил ... написание секурных невалящихся программ, которые не надо от греха прятать в контейнер

Хых. Человек слаб и, как учат нас Отцы Церкви, грешен. Реальность, данная нам в ощущениях, говорит, что даже hello world может засветиться на бэктреке :) Контейнеры лишь позволяют уменьшить объем ущерба :)

> следование стандартам, позволяющее один и тот же компонент использовать в составе разных систем без допиливания

Это ненужный максимализм. Вон в соседнем обсуждении некто жалуется, что установка Firefox'а 3 в Debian Lenny требует апгрейда чуть ни всей системы (до НЕ-lenny). Он, конечно, преувеличивает тяжесть проблем, но, факт, решения в рамках дистрибутива всё-таки нет.

Вообще, на самом деле, поймал себя на ощущении, что уже слышал подобные дискуссии. В начале 90х c появлением [на PCшках] первых систем, ориентированных на использование protected mode в процессоре, было довольно много скептиков, говорящих, что-де, играм требуется полный контроль над железом и "надсмотрщики" в лице OS будут только мешать им эффективно использовать железо. Жизнь, хоть и не сразу, всё расставила по своим местам :)

Вот только что поставил в виртуалке. А кто мне ответит, почему в ихнем КДЕ нету кнопки переключения к классическому меню? Везде есть, а у них нет.

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

...и контейнеры поощряют такой стиль. И проблема не в быстродействии, а в том, что ВНЕЗАПНО вместо нескольких приложений нужно администрировать кластер.

И кстати, KVM не имеет той поддержки разделения ресурсов, что OpenVZ.

> В то время как те же зюзешники и федоро-редхатовцы собирались не пойми как и не пойми на чём, в альте уже работала автоматическая сборочная система

Ммм... это типа buildd в Debian? А хранить пакеты в DVCS - это как Убунта (вроде) хранила пакеты в Arch? Что там еще ALT изобрел или первым внедрил? :)

> Проблема в этом всём ровно одна: человеки, которые это пишут и поддерживают, категорически не видят необходимости в согласовании своих действий с другими сторонами, решающими схожие задачи.

Проблема в этом только одна: ALT - локальный дистр, и ресурсы его соответствующие (только не надо про разработчиков из десятков стран, ладно?). Даже Ubuntu, при всех ресурсах Шаттлворта, построена на Debian, не говоря уже о всяких Linspire и Xandros. И ALT таки останется "уделом узкого круга вляпавшихся".

> В начале 90х c появлением [на PCшках] первых систем, ориентированных на использование protected mode в процессоре, было довольно много скептиков, говорящих, что-де, играм требуется полный контроль над железом и "надсмотрщики" в лице OS будут только мешать им эффективно использовать железо.

Вообще-то игры первыми освоили защищенный режим :D И да, посредники в виде ОС им мешают, отсюда и WinG, потом DirectX.

> Шаред мемори бывает между виртуалками?

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

Идея виртуализации состоит как раз в том, чтобы изолировать программы стандартными интерфейсами. Хочешь файлы кидать — используй NFS или WebDAV или ещё что-нибудь стандартное.

> ихнем КДЕ нету кнопки переключения к классическому меню?

правой кнопкой на К-меню, "разблокировать изменение виджетов", далее очевидно ;)

> и при желании можно обеспечить им совместное использованием одних и тех же shmem'овских сегментов.

Какая-то подозрительно обтекаемая фраза.

Дайте ссылку на доки, что конкретно надо сделать

1. программеру на С

2. админу

3. какие у этого limitations.

> на ЛОР надо выкладывать информацию о реальных достижениях

ЛОР хорошая рекламная площадка... Не мешайте. Всегда интересно посмотреть за что бились, и на что потом напоролись.

> В начале 90х c появлением [на PCшках] первых систем, ориентированных на использование protected mode в процессоре, было довольно много скептиков, говорящих, что-де, играм требуется полный контроль над железом и "надсмотрщики" в лице OS будут только мешать им эффективно использовать железо.

И были абсолютно правы.

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

Контейнеры безусловно прогрессивны и полезны. И кстаты было (и будет еще) интересно послушать о технических подробностях VZ-реализации.

И чуть не забыл. Почему я вижу в тексте новости:

> позволяющим создавать комплексные интегрированные решения и привлечь к их разработке, поддержке, внедрению и обучению разработчиков прикладных решений

и не вижу списка поддерживаемых продуктов из категории "инструментарий разработчика", кроме разумеется:

> Готовый к работе комплект ПО для офисной работы

> Разве это правилбный подход?

Для увеличения доли присутствия на рынке -- да, доказано виндой.

А оно умеет (в серверной редакции) по дефолту хранить пользователей в LDAP и аутентифицировать ВСЕ службы по LDAP?

И кому нужен еще один rpm дистрибутив? Что в нем особенного?

>> Нормальные пацыки buildService пилят
> Пусть пилят, у нас уже всё работает: http://www.altlinux.org/Git.alt

хоть бы не позорились таким бредом... (нашли, что сравнивать, при всём моём уважении...)

> хоть бы не позорились таким бредом... (нашли, что сравнивать, при всём моём уважении...)

Очень интересно услышать более полное обоснование. Серьезно.

>>Виртуализация для установки контейнеров c дополнительным ПО.

>Видел я тут одну дискуссию с aen'ом и эту строчку в анонсе. Складывается впечатление, что неправильной дорогой идут товарищи. Если для каждой софтины сложнее awk'а будет ставиться контейнер для виртуальной машины, я представляю как это всё будет тормозить, какие будут объёмы обновлений, как гиморно будет эту стаю виртуалок админить и какие невероятные приключения будут ждать тех, кто попытается сделать что-то нестандартное с оконтейнерённым софтом. Тревожно мне.

Зато замена дисков и перенастройка сервера не будет влиять на работу сервисов - они будут переезжать на соседний сервант. Максимум это "подвисание" пока виртуалка переходит с машины на машину.

Да и HA более простым в реализации будет.

>> Ну да фиг с ней, с известностью. У этой [псевдо-]элитарности ровно один технический минус - ввиду того, что девелопментом сюзи, федоры и прочих интересуется на порядки больше народу, технологическое первенство и первопроходчество альта неизбежно оборачивается отставанием. Мэйджоры, даже начав позже и кривее, набирают темп за счёт больших ресурсов.

абсолютно бездарная и безграмотная точка зрения. девелопмент SUSE, FC/RH - это в первую очередь работа на Сообщество в целом (вы ещё количеством патчей в ядро от Альта блесните...). как результат - OBS (openSUSE Build Service) одобрена/рекомендована "Linux Foundation", прогресс KVM и прочая, прочая. SUSE + FC/RH не замыкаются на своих локальных нуждах, поэтому они и интересны (кроме того, что по сути-то это ещё и корпоративный стандарт). "коммунизм в отдельно взятом государстве"(c) - удел Альта, да и то при условии, что розовые очки мечты не разобьются о бетонную стену реальности.

>> Очень интересно услышать более полное обоснование. Серьезно.

imho - лучше один раз увидеть. добро пожаловать:
https://build.opensuse.org/