После восьми лет разработки увидел свет (http://permalink.gmane.org/gmane.comp.file-systems.zero-inst...) первый релиз децентрализованной, независящей от дистрибутива, системы инсталляции/запуска приложений Zero Install 1.0 (http://0install.net). Новая версия не несет в себе каких-либо серьезных изменений, кроме исправления двух незначительных ошибок, но знаменует собой окончательную стабилизацию метаданных, кода и форматов, используемых для распространения приложений.
Основная идея и отличие Zero Install от других систем инсталляции приложений заключается в том, что он дает пользователям возможность запуска приложений с сайта разработчика/дистрибьютора без их фактический инсталляции. Установив на машину Zero Install пользователю останется только указать адрес файла-описания нужного приложения и оно со всеми зависимостями будет загружено и запущено в полностью автоматическом режиме. Все приложения кэшируются в домашнем каталоге пользователя и проверяются на обновления во...URL: http://permalink.gmane.org/gmane.comp.file-systems.zero-inst...
Новость: https://www.opennet.ru/opennews/art.shtml?num=30640
А говорили, Steam для Linux не будет...
А что, будет?
При чем тут стим?
Круто =))) Может таки сделают единый механизм установки любого Linux приложения в любой Linux )))
Круто, ждём новых троянов.
А есть старые?
А куда б они делись?http://lwn.net/Articles/367874/ - первое, что вспомнил.
а мне казалось, что suse и ещё несоклько других операционок разрабатывают как раз такую, общую для всех систему управления пакетами... нет?
> а мне казалось, что suse и ещё несоклько других операционок разрабатывают как
> раз такую, общую для всех систему управления пакетами... нет?Чем больше общих систем управления пакетами тем лучше! (думаю, печаль и ирония читаются)
Хоть 1 разработчик собрал пакет своей проги для этой штуки?
Напоминаю, в Gobo Linux это основной менеджер пакетов.
Дистр интересный, но не совсем живой :/
И это не оказывает что хоть 1 разработчик (а не мейнтейнер гоболинукса) выложил свою прогу в формате зеро инсталл.
угу, только не такую кривую...
Лозунг дня: "Даешь все в /Program files"
Юзал этот зироинстал для установки ROX, запутанная система на самом деле. Очень легко поддавалась сбою. Хотя это было давно, сейчас может изменили принцип, нужно потестить.
Я юзал Gobo, но про 0install слышу впервые :)) Там есть менеджер пакетов, но он написан на баше (если я правильно ошибаюсь) - ни про какие зероинсталлы там речи не шло. Но идеи у Gobo правильные, жаль что сообщество так тупо его игнорирует.
Гобо - не юникс вэй.
> Гобо - не юникс вэй.Это если очень мягко говоря...
>Гобо - не юникс вэй.Это еще почему?
Мечта. И дистрибутив с правильной организацией файлов - мечта. Я уже давно смотрю, но жаль что он не развивается.Все равно половину приложений приходится из исходников ставить какой дистрибутив не используй. RPM не панацея. Надо что-то именно такое.
> Все равно половину приложений приходится из исходников ставить какой дистрибутив не используй.
> RPM не панацея.Ставить из исходников нам не привыкать, судьба такая, make && make install - наше всё.
Правда, ещё софтинка checkinstall есть, но если нет подключения к инетнету, она свои зависимости не получит и не поставится.
gentoo + overlays
Что- то по описаению PBI из PC-BSD напоминает...
> Каждое приложение размещается в отдельном каталоге, что позволяет одновременно использовать несколько версий одной программы.Да здравствует DLL hell!!1
> Да здравствует DLL hell!!1крайне наивное и поспешное заявление, основанное на полном непонимании механизма работы ZI... как раз при ZI невозможен не только dll hell, но и dependency hell - все это отсутствует как класс
>> Да здравствует DLL hell!!1
> крайне наивное и поспешное заявление, основанное на полном непонимании механизма работы
> ZI... как раз при ZI невозможен не только dll hell, но
> и dependency hell - все это отсутствует как классМинуточку, что именно делаем:
- если два разных бинаря требуют разные soname?
- с очередной дырявой libpng?
1) читаем как работает ZI и вопрос отпадает, создание ситуации "dll hell" невозможно в принципе
2) боюсь что остаемся с дырявой libpng, если пакет для ZI не допускает более новую версию - да, это минус ZI, но это удобно и софт все же работает
То есть слив по обоим пунктам заЩЩитан полностью. ЧИТД.
> То есть слив по обоим пунктам заЩЩитан полностью. ЧИТД.Собака лает - караван идёт. ;)
> если два разных бинаря требуют разные soname?LD_LIBRARY_PATH=.:
> с очередной дырявой libpng?
LD_PRELOAD=/path/to/недыряваяlibpng.so.<что-там-у-неё>
Кстати сказать, вот идея не тянуть, если в системе уже стоит библиотека, не очень хороша именно из-за "дырявых libpng"... :(
> Кстати сказать, вот идея не тянуть, если в системе уже стоит библиотека,
> не очень хороша именно из-за "дырявых libpng"... :(Да нет же. Просто получается _скрытый_ _распределённый_ dll hell. А снаружи -- "зато всё работает", хотя на самом деле это дешёвые понты от неопытных шапкозакидателей. Общался я с ними, труба :(
> Да нет же. Просто получается _скрытый_ _распределённый_ dll hell. АНикто не мешает собирать пакеты с общими зависимостями. Разница с традиционным пакетированием в том, что никто и не заставляет. Только и всего. Кроме того, если вам действительно интересно (а не хочется навесить ярлык на непонятое), посмотрите, как организуется окружение сборки и окружение установленных пакетов в таких системах.
> снаружи -- "зато всё работает", хотя на самом деле это дешёвые
> понты от неопытных шапкозакидателей. Общался я с ними, труба :(Вот чем ещё характерно русскоязычное сообщество: тут прямо-таки царят неконструктивные аргументы вида "да общался я с этими деятелями, они ничего не умеют". Причём как правило аргументатор общался не с этими, а с какими-то другими, которые действительно ничего не умеют. Но обобщать - это же наше всё.
>> Да нет же. Просто получается _скрытый_ _распределённый_ dll hell. А
> Никто не мешает собирать пакеты с общими зависимостями. Разница с
> традиционным пакетированием в том, что никто и не заставляет. Только и всего.Получается несколько более гибкий вариант (semi)static, и какую проблему это решает?
> Кроме того, если вам действительно интересно (а не хочется навесить ярлык на
> непонятое), посмотрите, как организуется окружение сборки и окружение
> установленных пакетов в таких системах.Мне было интересно несколько лет назад -- посмотрел и стало жалко затраченного времени. См., например, http://lists.altlinux.org/pipermail/community/2005-March/569...
> Причём как правило аргументатор общался не с этими, а с какими-то другими,
> которые действительно ничего не умеют. Но обобщать - это же наше всё.(пожимая плечами) Знаете, таких изобретателей суперкрутых серебряных netwosix'ов, что характерно, хватает по всему миру. За одно враньё с попыткой представить своё поделие как чуть ли не универсальное решение проблем (умалчивая или не догадываясь о создаваемых проблемах) -- канделябр сломается всех их выровнять. :(
> Получается несколько более гибкий вариант (semi)static, и какую проблему это решает?Получается более гибкий вариант традиционного пакетирования. В зависимости от ситуации, решается немало проблем.
1. Для установки пакетов не требуются привилегии суперпользователя (ни в каком виде).
2. К вопросу об эффективности. В ZI реализовано безопасное совместное использование файлов (включая либы и экзешники) разными пользователями. Это в отличие от пользовательских RPM-окружений, которые вы предложили в своём письме в качестве аналога.
3. Возможность установки пакетов разных версий (и в смысле номеров, и в смысле опций сборки) без дополнительных усилий по обеспечению их бесконфликтного сосуществования.
4 Возможность мгновенно и без нарушения консистентности окружения (зависимостей, общих файлов) откатываться на предыдущие версии.
5. Каждый пользователь сам выбирает, что и из каких источников ставить и обновлять.
5. Каждый пользователь может создавать пакеты для себя и других, а также совмещать их с пакетами из других источников в личном окружении. Свобода выбора ограничена только рамками стандартных привилегий.
6. В любой системе можно использовать пакеты одних и тех же версий, собранные из одних и тех же исходников, с одними и теми же зависимостями. Если ты разработчик, хостинг, выбранный заказчиком, перестаёт создавать проблемы, а для удобного управления пакетами не требуется их установка на уровне системы. При этом каждый проект имеет строго опренделённый набор зависимостей, не появляется magic deps и не приходится делить одно окружение с менее доверенными зависимостями для других проектов.> Мне было интересно несколько лет назад -- посмотрел и стало жалко затраченного
> времени. См., например, http://lists.altlinux.org/pipermail/community/2005-March/569...
> За одно враньё с попыткойПохоже, ZI и его сайт с той поры значительно доработан. Или вы невнимательно интересовались. В любом случае, ваши представления о ZI (уже) не верны. Допускаю, что автор мог где-то врать в 2005-ом, но скорее всего, просто заблуждался, либо вы недопоняли.
> представить своё поделие как чуть ли не универсальное решение проблем (умалчивая
> или не догадываясь о создаваемых проблемах) -- канделябр сломается всех их
> выровнять. :(По-моему, ZI действительно более универсален. У него есть аналог - Nix - на базе которого построен дистрибутив NixOS, свободный от многих недостатков традиционного управления пакетами. То есть возможность построения более совершенных дистрибутивов на базе децентрализованных пакетных менеджеров, на мой взгляд, продемонстрирована. А ограничения и риски, связанные с компрометацией репозиториев и предоставлением привилегий для запуска ПО с privsep/setuid/chroot там те же, что и в других дистрибутивах.
Миш, ну откуда DLL Hell-то, а?В Юниксе библиотеки версионируются, здесь вам не Windows. К тому же, есть -Wl,-rpath, да и LD_LIBRARY_PATH, как я отмечал.
> Миш, ну откуда DLL Hell-то, а?
> В Юниксе библиотеки версионируются, здесь вам не Windows. К тому же, есть
> -Wl,-rpath, да и LD_LIBRARY_PATH, как я отмечал.Из возможности положить в "одинаковые" libA.so.X немного разным образом собранный код, например. При этом без дополнительного анализа ABI формализация зависимостей вдруг может оказаться на практике неполной: soname не определяет ключи компиляции как минимум, да и вообще ABI (некоторые апстримы не заморачиваются поднимать soname, чуточку поломав ABI).
Алексей Турбин в альте эту проблему анализировал и решил, поскольку централизованных репозиториев она (ессно) тоже касается, но там по крайней мере возможно централизованно же и ловить такие крайние случаи.
> Из возможности положить в "одинаковые" libA.so.X немного разным образом собранный код,
> например. При этом без дополнительного анализа ABI формализация зависимостей вдруг
> может оказаться на практике неполной: soname не определяет ключи компиляции как
> минимум, да и вообще ABI (некоторые апстримы не заморачиваются поднимать soname,
> чуточку поломав ABI).
> Алексей Турбин в альте эту проблему анализировал и решил, поскольку централизованных репозиториев
> она (ессно) тоже касается, но там по крайней мере возможно централизованно
> же и ловить такие крайние случаи.А в Zero Install невозможно? Возможно. Более того, там такие проблемы возникают редко (я, вот, не сталкивался) и уже разрешимы как минимум путём отката на более раннюю версию библиотеки. Причём, версию можно выбрать для каждого приложения, для каждого пользователя.
А как в Альте решена потенциальная проблема с несовместимыми изменениями API библиотек на динамических языках? А с несовместимым изменением поведения кода при сохранении API/ABI (на любых языках)? Возможно ли использовать разные версии библиотек для разных приложений, на выбор, и при каких условиях? Нужно ли вручную закладывать такую возможность при пакетировании изначально? Вопросы риторические.
> Минуточку, что именно делаем:
> - если два разных бинаря требуют разные soname?А что обычно делают в таких случаях? Держат две версии одной библиотеки. В чём проблема?
> - с очередной дырявой libpng?
Обновляем libpng и не раздуваем из мухи слона. Фиксы для замороженных версии выпускаются практически вровень с мейнстримом. Тем и живут бинарные дистры, включая Альт.
>> Минуточку, что именно делаем:
>> - если два разных бинаря требуют разные soname?
> А что обычно делают в таких случаях? Держат две версии одной библиотеки.
> В чём проблема?Не-не, что _обычно_ делают (и как именно) -- я знаю. Только это подразумевает наличие одного общесистемного пакета-провайдера каждого такого сонейма. А вот как с их вариантом bundle'инга это разумным образом сопрячь, сходу не соображу (если рассматривать вкупе со следующим вопросом).
>> - с очередной дырявой libpng?
> Обновляем libpngГде именно?
> Не-не, что _обычно_ делают (и как именно) -- я знаю. Только
> это подразумевает наличие одного общесистемного пакета-провайдера каждого такого сонейма.
> А вот как с их вариантом bundle'инга это разумным образом
> сопрячь, сходу не соображу (если рассматривать вкупе со следующим вопросом).*нудным менторским голосом цитирует FAQ с сайта ZI*
Isn't it wasteful for every program to bundle all its dependencies?
Yes, but Zero Install doesn't do that. Everything is dynamically linked, just as in a traditional Linux system: you can publish a program on your web-site that links against a library on another web-site. When updates are available for a library, they are used by all programs using that library (except for programs which are incompatible with the new library version, which will continue using the older version, without preventing other programs from upgrading).
>> Обновляем libpng
> Где именно?В пакете, который предоставляет эту библиотеку.
Интересно, а теоретически запустить Linux-программу в Windows Zero Install-у под силу?
Теоретически, вы можете построить в гараже космический корабль и слетать на Луну, не то что там какой-то бинарь запустить. Остается только реализовать это на практике :)
Притянет coLinux, cygwin, лысого чёрта с бубном и запустит.
Децентрализованный? А откуда он берет списки сайтов с софтом? Алсо у них есть централизованное зеркало. Вообще, очень странная хреновина. По описанию очень похоже на просто еще 1 менеджер пакетов.В линуксах эти извращения не нужны: если уж не нравится как ведут себя майнтайнеры репов, с таким же успехом можно свой реп поставить. С блекждеком и шлюхами. И чем уже существующие пакетные менеджеры хуже этого, еще одного из? Сторонние репы и там можно подключать. А когда основная масса софта в доверяемом репе дистра с вменяемыми майнтайнерами - это хорошо: малвари нет.
Нет в безопасности понятия "Доверие". Оно есть только в у...дочной концепции PKI. В безопасности есть только "знание". "Доверия" там нет и быть не может. Объясните за доверие любому профессиональному безопаснику. ФСБшнику. ГБшнику. Ну и так далее. Сильно удивитесь.
> Нет в безопасности понятия "Доверие". Оно есть только в у...дочной концепции PKI.
> В безопасности есть только "знание". "Доверия" там нет и быть не
> может. Объясните за доверие любому профессиональному безопаснику. ФСБшнику. ГБшнику.
> Ну и так далее. Сильно удивитесь.Так шта малварь будет по-любому. Другое дело, что ее будет вменяемое количество. Как в венде после Симантека, обновленного только что. :)
По опыту общения с нашими экс-СБшниками, там есть понятие "доверие". Причем понятие очень такое... понятие, из серии "мамой клянусь" и "да я сам видел", так что пример не очень удачный.
> По опыту общения с нашими экс-СБшниками, там есть понятие "доверие".Вот только чтобы такое доверие получить нужно вначале заработать авторитет, потом побыть пару лет помощником коммиттера, потом еще пару лет работать под строгим надзором наставника и уже после этого будет оказано доверие ковыряться в кишках системы.
> По опыту общения с нашими экс-СБшниками, там есть понятие "доверие". Причем понятие
> очень такое... понятие, из серии "мамой клянусь" и "да я сам
> видел", так что пример не очень удачный.По-моему, вбросовый характер "примера" виден уже по "симантеку".
А на доверии очень многое держится. И не только выраженном технически.
> Объясните за доверие любому профессиональному безопаснику.Ну, если безопасник действительно профессиональный, то он понимает, что целиком жить на формально доказанном программном обеспечении не получится в принципе.
А тестирование (например, такое: http://elibrary.ru/item.asp?id=12879171) может дать гарантию только _наличия_ недокументированных возможностей, но не их отсутствия.
> если в системе уже будет присутствовать нужная для работы программы зависимость, ее повторная загрузка не произойдетА если системный пакетный менеджер удалит зависимость, которая из-за этого не была зероинсталлирована? А если обновит её несовместимым с зероинсталлированными программами? А если обновление зероинсталлированной зависимости поломает кучу зераинсталлированных кривых программ (как libc поломал флеш)? Как вообще можно указывать зависимости для разных пакетных менеджеров разных систем, если они по-разному называются, нумеруются и разбиваются на пакеты? Что делать, если системная зависимость собрана с неожиданными для зеропакетировщика опциями? Или если разные зероинсталлированные программы требуют одной и той же версии зависимочти, собранной по-разному? Что делать с подмонтированным noexec домашним разделом?
Не проще ли тогда уж подгружать готовый образ диска для виртуалки, со всем готовым окружением?
> А если системный пакетный менеджер удалит зависимость, которая из-за этого не была
> зероинсталлирована? А если обновит её несовместимым с зероинсталлированными программами?На этот случай есть процедуры проверки и восстановления окружения. Бтв, и как часто в стабильных ветках бинарных дистрибутивах происходят такие "несовместимые" обновления? Чуть менее, чем никогда.
> А если обновление зероинсталлированной зависимости поломает кучу зераинсталлированных
> кривых программ (как libc поломал флеш)? Как вообще можно указывать зависимостиА причём здесь Zero Install? Это за пределами ответсвенности пакетного менеджера. Любого.
> для разных пакетных менеджеров разных систем, если они по-разному называются, нумеруются
> и разбиваются на пакеты? Что делать, если системная зависимость собрана сГде по-разному? Системные зависимости называются известно, как, и при интеграции с ними используются принятая в системе номенклатура.
> неожиданными для зеропакетировщика опциями? Или если разные зероинсталлированные программы
Неожиданными для человека? Какие претензии к Zero Install в этом случае? Или в случае пакетирования системными средствами "неожиданные" опции внезапно становятся "ожиданными" сразу и навсегда?
> требуют одной и той же версии зависимочти, собранной по-разному?
А если не-зероинтсаллированные программы требуют такой зависимости? Она волшебным образом разрешается, да? Кстати, в системах типа ZI это разрешается на уровне путей во время линковки при сборке: две разные версии (и в смысле номера либы, и разные по настройкам или содержанию) живут в разных директориях и называются - ну кто бы мог подумать?1 - по-разному.
> Что делать с подмонтированным noexec домашним разделом?
Монтировать без noexec и перестать делать вид, будто это когда-то что-то значило для безопасности. Либо собирать и ставить софт где-нибудь в /var.
> Не проще ли тогда уж подгружать готовый образ диска для виртуалки, со
> всем готовым окружением?Да, вот только виртуализации нам и не хватало. Легковесно, надёжно, удобно и безопасно, чо.
>> А если системный пакетный менеджер удалит зависимость, которая из-за этого не была
>> зероинсталлирована?
> На этот случай есть процедуры проверки и восстановления окружения. Бтв, и как
> часто в стабильных ветках бинарных дистрибутивах происходят такие "несовместимые"
> обновления? Чуть менее, чем никогда.Даже при неизменности стабильной ветки системный пакет может оказаться невостребованным с точки зрения администратора/aptitude.
>> А если обновление зероинсталлированной зависимости поломает кучу зераинсталлированных
>> кривых программ (как libc поломал флеш)?
> А причём здесь Zero Install? Это за пределами ответсвенности пакетного менеджера.
> Любого.Случай с flash -- пожалуй, да, а вот ряд вариаций на тему съезда ABI конкретно в альте уже ловится (set-versions).
> Где по-разному?
Где-то firefox, где-то iceweasel, где-то mozilla-firefox... тут относительно просто только с библиотеками, если ориентироваться исключительно на soname.
>> Не проще ли тогда уж подгружать готовый образ диска для виртуалки, со
>> всем готовым окружением?
> Да, вот только виртуализации нам и не хватало. Легковесно, надёжно, удобно и
> безопасно, чо.То же самое можно сказать и про 0install с иронией на второй части рожи... (.
(не, какие-то полезные применения а-ля .dmg могут найтись, только повторюсь: за такую наглую саморекламу положено канделябром до получения резонной характеристики, включающей хотя бы известные недостатки)
> Даже при неизменности стабильной ветки системный пакет может оказаться невостребованным
> с точки зрения администратора/aptitude.Это за пределами ответственности ZI. Если системное окружение не согласуется с потребностями пользователей, можно к нему не привязываться изначально, либо привязываться ограниченно - к glibc и другим пакетам, всегда установленным в системе. В теории проблема есть, на практике не сталкивался.
> Случай с flash -- пожалуй, да, а вот ряд вариаций на тему
> съезда ABI конкретно в альте уже ловится (set-versions).Не знаю, есть ли подобное в ZI, не сталкивался опят же. Но там возможен откат на предыдущую версию, и в принципе возможно реализовать аналог set-versions.
> Где-то firefox, где-то iceweasel, где-то mozilla-firefox... тут относительно просто только
> с библиотеками, если ориентироваться исключительно на soname.Всё просто: имя пакета можно указать явно для каждого дистрибутива или группы дистрибутивов, а также ограничить допустимые версии зависимостей. Но зачем вы спрашиваете? Вы же интересовались, должны знать. ;)
>> Да, вот только виртуализации нам и не хватало. Легковесно, надёжно, удобно и
>> безопасно, чо.
> То же самое можно сказать и про 0install с иронией на второй
> части рожи... (.Представьте себе, ZI - это и легковесно, и надёжно, и удобно, и безопасно, и гораздо более универсально, чем традиционные менеджеры или виртуализация. Мне, по факту, на практике. Да и не только мне. А как там у вас в теории - вам виднее.
> (не, какие-то полезные применения а-ля .dmg могут найтись, только повторюсь: за такую
> наглую саморекламу положено канделябром до получения резонной характеристики, включающей
> хотя бы известные недостатки)Эти недостатки, очевидны и известны практически всем, кто хоть что-то понимает в вопросе, и ничтожны на фоне достоинств. Особенно если не теоретизировать о крайних случаях, а пользоваться в конкретных ситуациях.
Алсо, о брёвнах в глазу: из сотен русскоязычных линуксоидов и BSD-шников могу припомнить от силы 5 человек, которые адекватно оценивают уровень защищённости своих систем и осознанно идут на эти риски там, где не используют Grsecurity, PaX и аналоги. Все остальные в голос трубят о безопасности. Включая вас, на сколько я могу судить. По вашей логике, и вас следовало бы канделябром приложить - за наглую саморекламу и "враньё".