Представлен (http://blog.verbum.org/2013/08/26/ostree-v2013-6-released/) релиз проекта OSTree 2013.6 (https://wiki.gnome.org/OSTree), в рамках которого развивается альтернативная пакетным менеджерам система, обеспечивающая поддержку параллельной установки и атомарного обновления операционных систем. Идея OSTree заключается в формировании системного образа из Git-подобного хранилища, позволяющего применять методы версионного контроля к компонентам дистрибутива.Подобный подход позволяет легко переходить к произвольному состоянию системы в прошлом, что очень удобно при организации тестирования различных систем. Например, разработчик может выпускать тестовые сборки с достаточно высокой периодичностью, полностью контролируя процесс влияния изменений на работоспособность системы. В случае выявления тестировщиками проблем, для повторения проблемы имеется возможность возврата к состоянию сборки для которой поступило сообщение об ошибке с последующим пошаговым откатом для выявлением изменения, начиная с которого начала проявляться ошибка. В частности, на основе OSTree формируются тестовые сборки GnomeOSTree (https://wiki.gnome.org/GnomeOSTree), развиваемые с использованием процесса непрерывной интеграции.
OSTree не является ни системой управления пакетами, ни инструментом управления дисковыми образами, но берёт на себя часть функций подобных систем, занимая промежуточную нишу. Вместо пакетов и установочных образов OSTree манипулирует готовыми загрузочными деревьями файловой системы и может быть охарактеризован как "Git для бинарных файлов ОС". OSTree имеет многослойную архитектуру и изначально рассчитан на работу с различными наборами деревьев, развёртываемыми поверх базового административного слоя.
Таким образом OSTree предоставляет средства для атомарной параллельной установки различных версий нескольких независимых Unix-подобных систем. Репозиторий OSTree размещается в директории /ostree/repo базовой системы, установка вариантов систем производится в /ostree/deploy/OSNAME/CHECKSUM (системы запускаются с использованием chroot) с использование жестких ссылок на файлы в репозитории, что позволяет физически хранить только одну копию данных. При обновлении вначале по HTTP вносятся дополнения в репозиторий, после чего формируется обновлённое дерево системы, переключение на которое производится атомарно.
OSTree манипулирует только базовым составом системы, который не может быть изменён в процессе работы. В свою очередь, система, может использовать дополнительные механизмы для установки дополнительных приложений в директории, не попадающие в область обновления, такие как /var для общих приложений и /home для установки программ индивидуальными пользователями, подобные директории, наряду с /etc используются совместно всеми окружениями каждой из установленных ОС. Также не исключается вариант использования OSTree совместно с пакетными менеджерами, при котором содержимое /usr формируется динамически из набора обособленных деревьев OSTree (вместо прямой установки пакета в ФС, содержимое пакета преобразуется в дерево OSTree и устанавливается/обновляется с использованием локального репозитория OSTree). Подобный подход уже развивается в рамках проекта fedora-ostree (http://fedorapeople.org/~walters/fedora-ostree/).URL: http://blog.verbum.org/2013/08/26/ostree-v2013-6-released/
Новость: http://www.opennet.me/opennews/art.shtml?num=37750
Интересная задумка. Надо пощупать.
Ну вообще-то бинарники через гит доставлять - не проблема, но вот будет ли тут профит в смысле управления состоянием оси - вопрос еще тот. Что-то мне подсказывает, что "тигриная шкура лучше всего смотрится на тигре", в гит лучше всего управляет сырцами.
конфигами, гит управляет не хуже, инфа 146%
, да, согласен, , , пожалуй, ,
> гит лучше всего управляет сырцами.А это не git, а его адаптированная версия для управления бинарниками.
> Ну вообще-то бинарники через гит доставлять - не проблема,А если взять достаточно тяжелый микроскоп - можно вбить неплохой гвоздь в стену. Но говорят что более специализированным под задачу молотком это получается лучше.
>> Ну вообще-то бинарники через гит доставлять - не проблема,
> А если взять достаточно тяжелый микроскоп - можно вбить неплохой гвоздь в
> стену. Но говорят что более специализированным под задачу молотком это получается
> лучше.Если в основе идеи лежит некорректный принцип, правильный выбор инструмента не поможет.
Молотком микробов не рассмотришь.
> Ну вообще-то бинарники через гит доставлять - не проблема, но вот будет
> ли тут профит в смысле управления состоянием оси - вопрос еще
> тот.Да. У ОС могут быть разные компоненты, которые хотелось бы держать независимыми. Скажем, есть конфиг пакета bind и сам пакет bind. Допустим, конфиг мы изменили во вторник, а в среду накатили новую версию пакета bind.
Теперь, в четверг, мы хотим вернуться к конфигу bind от понедельника. Если git-подобная система реализована наивно, при откате конфига до понедельника произойдёт откат версии пакета. Это нежелательно.
С другой стороны, делать полностью независимые репозитарии для всех программ и конфигов тоже странно.
GitOS?
> сброки GnomeOSTree
> GnomeOSже.
А как быть с изменёнными конфигами в /etc?
git merge
Проблема в том, что о конфигах эта штука не парится вообще. Их нужно держать в отдельной репе, и отдельно ими рулить.
> А как быть с изменёнными конфигами в /etc?Не только конфиги. Ещё желательно иметь возможность независимо откатывать независимые пакеты. Скажем, откатить maxima, но оставить свежую версию WindowMaker.
Сложная задача.
Интересная задумка. Для разработчиков дистрибутивов. И для любителей собирать нестабильное окружение(фаны Gentoo, частично Arch'a). Обычным пользователям традиционных дистрибутивов(их стабильных версий) не особо нужно подобное. А вообще, сабж можно использовать просто для хренения бинарных данных? Я бы xcf-ки хранил так, удобно очень:)
>И для любителей собирать нестабильное окружение(фаны GentooНе надо расписываться за всех, я например 7.5 лет использую только стабильные пакеты в генте, за исключением нескольких мультимедийных.
В убунте некоторые стабильные пакеты свежее стабильных гентовских бывают
Вот да. Гента даёт - при желании - возможность иметь исключительно стабильную систему, при этом оставляя возможность кастомизации USE-флагами. То есть да, кто кто хочет - может и настроек компилятора накрутить, и нестабильных версий натащить - но это всё же по желанию.Это в арче (по слухам, сам не видел) акцент на bleeding edge - а в генте дефолты сравнительно консервативны.
Теперь самый сильный акцент на bleeding edge - в Ubuntu LTS. Тот же арча по сравнению с ними довольно консервативен :)
> Тот же арча по сравнению с ними довольно консервативен :)Русская языка такая сложная :).
ЗЫЖ а еще в арче если не читать ридми к апдейту - система может факапнуться. Он попросту не failsafe. В убунте себе такого не позволяют - для установки свежака в LTS в уже существующей инсталляции юзер должен явно проявить инициативу. В отличие от арчепЫонеров убунтуи все-таки подозревают как выглядит реальная эксплуатация серверов.
> ЗЫЖ а еще в арче если не читать ридми к апдейту - система может факапнуться.В убунте система может факапнуться даже при минорном апдейте, не говоря уже о хтоническом песце с накатыванием bleeding edge. ИЧСХ - никаких readme.
Так что арч, пожалуй, даже лучше готов для сервера - там хотя бы есть шансы соломку подстелить.
> В убунте система может факапнуться даже при минорном апдейте, не говоря уже о хтоническом песце с накатыванием bleeding edge.Не может.
> ИЧСХ - никаких readme.
Ты не поверишь, перед обновлением, что-то меняющем в системе, вылазит окошко с этими изменениями прямо в консоли, где белым по английскому написано, что за изменение и что оно меняет, можно нажать CTRL-C и отказаться от таких обновлений.
> Не может.Диванные теоретики такие диванные.
> Ты не поверишь, перед обновлением, что-то меняющем в системе, вылазит окошко с этими изменениями прямо в консоли, где белым по английскому написано, что за изменение и что оно меняет, можно нажать CTRL-C и отказаться от таких обновлений.
Это если мейнтейнер запарится такое писать. Но это ж не убунту-вей - предупреждать о чем-то! Благо, не арчик какой-нибудь, а серьезный дистрибутив для взрослых мужиков, которые должны быть готовы ко всем.
Блин, ну если ничего вообще не помогает, а своих мыслей отродясь не водилось - НУ ПРОЧТИТЕ ЖЕ УЖЕ НАКОНЕЦ ИНСТРУКЦИЮ.полиси дебиан по changelog-файлам. уточните там, что такое urgency
Почему ещё 10 лет назад говорить о том, о чём понятия не имеешь, считалось моветоном, а сегодня - нормой для всего интернета? Откуда столько злобы, неграмотности, грязи и нетерпимости? Вы ведь понятия не имеете, что говорите, когда и зачем. Вы только на некоторые ключевые слова реагируете, заранее заученными стереотипными фразами. И вы реально думаете, что это и есть общение? "Васин, мне жаль тебя".
>> Тот же арча по сравнению с ними довольно консервативен :)
> Русская языка такая сложная :).
> ЗЫЖ а еще в арче если не читать ридми к апдейту -
> система может факапнуться. Он попросту не failsafe. В убунте себе такого
> не позволяют - для установки свежака в LTS в уже существующей
> инсталляции юзер должен явно проявить инициативу. В отличие от арчепЫонеров убунтуи
> все-таки подозревают как выглядит реальная эксплуатация серверов.То-то ты переполнен просто "русскими" словами, грамотей.
>>> Тот же арча по сравнению с ними довольно консервативен :)
>> Русская языка такая сложная :).
>> ЗЫЖ а еще в арче если не читать ридми к апдейту -
>> система может факапнуться. Он попросту не failsafe. В убунте себе такого
>> не позволяют - для установки свежака в LTS в уже существующей
>> инсталляции юзер должен явно проявить инициативу. В отличие от арчепЫонеров убунтуи
>> все-таки подозревают как выглядит реальная эксплуатация серверов.
> То-то ты переполнен просто "русскими" словами, грамотей.Их маркетологи Canonical специально таким bullshit'ом накачивают.
>Вот да. Гента даёт - при желании - возможность иметь исключительно стабильную системуНе дает так как нет фиксированных релизов. Стабильная система это дебиан, стабильная до крайнего неудобства.
фиксированные релизы перпендикулярны стабильности
> фиксированные релизы перпендикулярны стабильностиНе совсем так. Стабильный релиз - можно взять и получить более-менее предсказуемую систему, проверенную в таком сочетании версий компонентов толпой народа.
А если это самодельная сборная солянка - вот вы на себе как раз и узнаете как вон те компоненты с вот этими взаимодействуют и какие там в процессе лезут баги. Шансы наступить на баг при этом ясен фиг повышаются.
Учитывая, что у меня как раз гента и дебиан - две основные системы - могу сказать, что ни с той, ни с другой проблем не видел, если не пытался использовать нестабильные пакеты (в дебиане - на тестинге раз нарвался на неработающие на моем железе иксы - правда, железо было древнючим матроксом, в генте - на размаскированном черт знает чем - опять же из иксов - поимел проблемы с вайном).В генте другая модель стабильности - не по-релизная, а по-пакетная. Работает вполне уютно.
> В генте другая модель стабильности - не по-релизная, а по-пакетная.При этом есть только одна загвоздочка: при такой схеме никто не проверяет насколько корректно между собой пакеты будут взаимодействовать. Всем по...й.
> При этом есть только одна загвоздочка: при такой схеме никто не проверяет
> насколько корректно между собой пакеты будут взаимодействовать.А такого - никто, нигде и никогда этого не проверяет.
> Всем по...й.
Да, именно поэтому.
> При этом есть только одна загвоздочка: при такой схеме никто не проверяет
> насколько корректно между собой пакеты будут взаимодействовать.прикинь, никто этого не делает. почему? а ты пойди, да посмотри на размер репозитория дебиана, например. глянул? а теперь прикинь возможное количество сочетаний. прикинул? а теперь — время на их проверку. прикинул? а теперь пойми, что никто не проверяет так, как тебе кажется и хочется.
Мне одно непонятно - ну откатили версию. А данные у нас остались от новой. Если все откатывать - так обычный бекап будет рулить. Если по отдельности - то мороки много.С конфигами и кешами в хомяке - те же проблемы. В общем, как по мне - это механика для каких-то экзотических случаев, а в норме - снапшотим/бекапим всё.
> С конфигами и кешами в хомяке - те же проблемы. В общем,
> как по мне - это механика для каких-то экзотических случаев, а
> в норме - снапшотим/бекапим всё.И три терабайта поpнушки тоже? При каждом минорном обновлении?
Не храни порнушку в /
> Не храни порнушку в /Так речь идет о том, что бэкапить _все_, а не только системные раздел.
А где же ещё её хранить?
Скоро в / будут такие извращения, что любой "порнушке" не снилось. Вон в арчеге уже /bin и /sbin выпилили. Раньше изврат был максимум в /usr/local, сейчас добрался до /usr, ну дальше, стараниями всяких гнумов, шапок и поттеров, будет начинаться прямо с /.
> Скоро в / будут такие извращения, что любой "порнушке" не снилось. Вон
> в арчеге уже /bin и /sbin выпилили. Раньше изврат был максимум
> в /usr/local, сейчас добрался до /usr, ну дальше, стараниями всяких гнумов,
> шапок и поттеров, будет начинаться прямо с /.Страдания вчерашних виндyзятников, которые никогда не видели иерархию на олдовых юниксах (к которой сейчас стремится линуксовая наколенка) неизменно создают хорошее настроение :)
> Страдания вчерашних виндyзятников, которые никогда не видели иерархию на олдовых юниксах
> (к которой сейчас стремится линуксовая наколенка) неизменно создают хорошее настроение
> :)шиза некоторых «олдфагов» тоже. с одной стороны — «всё устарело, надо переделать…», с другой «…чтобы было как раньше». ангсоц торжествующий.
Варианты:1) снапшоты, если уж всё на одной FS храните. btrfs та же - благо если так наплевать на сохранность данных значит бояться её глюков нечего.
2) таки разнести по разным разделам как минимум хомяк лучше дежать отдельно, а лучше - еще отдельно иметь файлопомойку (в RO) и торренты.
3) ежели, как сейчас модно, ноуты/планшеты - то медиасервер в помощь. Хоть покупной, хоть самопальный.
Чем оно лучше nixos?
> Выпуск OSTree 2013.6, инструмента для организации обновления системы в стиле GitЗаголовок несколько "желтоват". Почему в стиле Git, а не в стиле Меркуриал ?
> Почему в стиле Git, а не в стиле Меркуриал ?Потому что на официальном сайте OSTree и в документации так и написано "git for operating system binaries"
Ну, значит документация желтовата, с бинарными данными Git работает плохо, а вот Subversion как раз наоборот - хорошо.
Но ведь уже есть снапшоты
"OSTree не является ни системой управления пакетами"А теперь нужно чтобы стала.
Нужно управление как на уровне пакетов так и на уровне файлов.
Нужно отслеживать целостность файлов из которых состоят пакеты и множество пакетов и транзакционно все это откатывать и накатывать
чем это лучше zbackup?
IPS + ZFS ?
ребята изо всех сил изобретают снапшоты и контейнеры.
Для дистроклепателей самое оно :)