Существует ли дистрибутив Linux, который вместо RPM или DEB использует Zero Install?

Появится, как только вы все скинетесь и профинансируете мне создание такого проекта. :-D

И сколько же денег для этого надо? У тебя уже есть идеи? Например вот это будет единым stage4, или отдельный 0install'чик для каждой библиотеки?

После того как я увидел systemd в Zero Install я подумал что можно создать дистрибутив, полностью основанный на Zero Install, а не RPM и DEB. Попробовал поискать и ничего не нашёл, ни на сайте проекта, ни в Google.

Молитва маленького мальчика перед сном: «Господи, подари мне велосипед!»

Такие вещи должны лежать под управлением традиционного пакетного менеджера.

LSB, система инициализации и т.п. будут в rpm/deb/чем-то-еще.

А вот все приложения и высоуровневые библиотеки пакетировать в 0install.

И в идеале, эти пакеты будут совместимы с любой LSB-совместимой системой.

И сколько же денег для этого надо?

Сейчас понятия не имею. У меня есть только готовность взяться за подобный проект. Но конкретного бизнес-плана я не составлял.

я подумал что можно создать дистрибутив, полностью основанный на Zero Install

Вообще говоря, не стоит инструмент использовать не по назначению. Zero Install разрабатывался для управления прикладным ПО, использовать его для системного нет нужды.

> И в идеале, эти пакеты будут совместимы с любой LSB-совместимой системой.

Ничего себе. Так значит если дистрибутив поможет популяризировать Zero Install, на всех сайтах будет один файл для Linux, а не как сейчас! Сейчас таким образом распространяют только закрытое ПО, а бинарники открытого ПО не запускаются не только между двумя дистрибутивами Linux, но и между двумя релизами одного дистрибутива. Например Wine.

Ага винда называется, только это не линукс.

Релиз Zero Install 2.0

Zero Install не заменяет собой традиционные системы управления пакетами и не пересекается с ними, он дополняет их.

Более того, в дистрибутиве GoboLinux Zero Install используется в качестве основного средства управления пакетами.

GoboLinux

Более того, в дистрибутиве GoboLinux Zero Install используется в качестве основного средства управления пакетами.

4.2.

FatELF - как основной формат плюс GoboLinux как метод построения фс ? Пакетный менеджер будет вообще несущественный…

Обсудите это по первой ссылке.

да нахрена ты нужен, когда есть nixOS?

На сайте 0install подобной дезинформации нет, скажем спасибо анонимусу за неё.

Вы бы уже заканчивали поддрачивать на эту недогенту, серьёзно. Она хоть в юз-флаги уже научилась?

Да и вообще, путать менеджер бинарных пакетов и среду для сборки из сорцов — это пять.

Вы бы уже заканчивали поддрачивать на эту недогенту, серьёзно. Она хоть в юз-флаги уже научилась?

мы про генту и юз-флаги или про бинарный пакетный менеджер nix?

Да и вообще, путать менеджер бинарных пакетов и среду для сборки из сорцов — это пять.

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

FatELF мне нравится, но и без него справляются.

Osmos: Osmos, Osmos.bin32, Osmos.bin64.

#!/bin/sh

# Change to game directory
CANONPATH=`readlink -f "$0"`
cd "`dirname "$CANONPATH"`"

MACHINE=`uname -m`
if [ "$MACHINE" = x86_64 ]
then
	BIN=./Osmos.bin64
else
	BIN=./Osmos.bin32
fi

$BIN $@

e=$?

exit $e

World Of Goo: WorldOfGoo, WorldOfGoo.bin32, WorldOfGoo.bin64.

#!/bin/sh

# Change to game directory
CANONPATH=`readlink -f "$0"`
cd "`dirname "$CANONPATH"`"

if [ ! -e properties ] || [ ! -e res ]
then
	echo "Missing properties/ and res/ directories in `pwd`"
	echo "Your installation is incomplete!"
	exit 1
fi

# Uncomment the line below to dump core when the game crashes; useful for
# debugging, but only works if the game directory is user-writable!
#ulimit -c unlimited

MACHINE=`uname -m`
if [ "$MACHINE" = x86_64 ]
then
	LIBS=./libs64
	BIN=./WorldOfGoo.bin64
else
	LIBS=./libs32
	BIN=./WorldOfGoo.bin32
fi

# Run the game:
export LD_LIBRARY_PATH=$LIBS:"$LD_LIBRARY_PATH"
$BIN $@

# Check for errors
e=$?
if [ $e -ne 0 ]
then
	echo ""
	echo "It looks like World of Goo crashed! If you need support, please include the"
	echo "contents of the log file in your problem report."

	LOGPATH="$HOME/.WorldOfGoo/WorldOfGoo.log"
	if [ -f "$LOGPATH" ]
	then
		echo "The log file is stored at: $LOGPATH"

		echo "" >> $LOGPATH
		echo "Libraries used:" >> $LOGPATH
		ldd $BIN >> $LOGPATH 2>&1

		echo "" >> $LOGPATH
		GLXINFO=`which glxinfo`
		if [ -z "$GLXINFO" ]
		then
			echo "glxinfo not found!" >> $LOGPATH
		else
			echo "Output of glxinfo:" >>$LOGPATH
			glxinfo >>$LOGPATH 2>&1
		fi
		
	else
		echo "Unfortunately, no log file has been created!"
	fi
fi

exit $e

VVVVVV: VVVVVV, VVVVVV_32, VVVVVV_64.

#!/bin/sh

# Change to game directory
CANONPATH=`readlink -f "$0"`
cd "`dirname "$CANONPATH"`"

# Check resource folders exist
if [ ! -e data ]
then
	echo "You are missing games resources `pwd`"
	echo "Your installation is incomplete!"
	exit 1
fi


MACHINE=`uname -m`
if [ "$MACHINE" = x86_64 ]
then
	LIBS=./LIB64
	BIN=./VVVVVV_64
else
	LIBS=./LIB32
	BIN=./VVVVVV_32
fi

# Run the game:
export LD_LIBRARY_PATH=$LIBS:"$LD_LIBRARY_PATH"
$BIN $@

И Trine и Amnesia очень похоже, только с Launcher'ом. Но сейчас показать не могу

мы про генту и юз-флаги или про бинарный пакетный менеджер nix?

Source-based model, with binaries

The Nix build language used by NixOS specifies how to build packages from source. This makes it easy to adapt the system — just edit any of the ‘Nix expressions’ for NixOS or Nixpkgs in /etc/nixos, and run nixos-rebuild. However, building from source is also slow. Therefore Nix automatically downloads pre-built binaries from nixos.org if they are available. This gives the flexibility of a source-based package management model with the efficiency of a binary model.

Any questions?

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

Да, тебе не помешает подтянуть матчасть и прочитать мануал по nix package manager. А за одно и по 0install.

Я-то с обоими пакетными системами знаком, а ты тут горбатого лепишь.

Any questions?

т.е. я могу считать apt-get-source (или как там) или арч source-based? Если да - то вопросов нет.

Я-то с обоими пакетными системами знаком, а ты тут горбатого лепишь.

хорошо.

т.е. я могу считать apt-get-source (или как там) или арч source-based? Если да - то вопросов нет.

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

т.е. я могу считать apt-get-source (или как там) или арч source-based?

Нет, ты не можешь считать deb-систему source-based, потому что она рассчитана на распространение и установку ПО в собранном виде. А nix предназначен для вычисления состояния системы по исходному коду. Этого его предназначение, понимаешь? Он для этого спроектирован. Люди, сели, подумали, сформулировали задачу и написали код. Задача всегда первична. И та задача — совсем иная, чем у deb. Как тебе, еще объснить? Если ты изменишь одну букву в спецификации пакета, он будет автоматически пересобран при обновлении мира, а deb — не будет. Ферштейн?

А теперь ответь мне, зачем ты приперся со своим функциональным ПМ в тред, где обсуждается 0install и вопросы распространения ПО в бинарном виде?

ладно, у меня к тебе один вопрос остался, ты с nix знаком только по чтению мануала?

а TinyCore случайно не использует что-то похожее на 0-install

Я c nix знаком чтением всех релевантных мануалов и юзанием системы. Но ты дальше живи в мире своих грёз.

спасибо за ответ.

Ну и вот зачем все эти велосипеды если именно для этого есть простой и понятный FatELF ? И да в него же можно и все либы позасовывать если чо.

FatELF мне нравится, я считаю что если бы Icculus закончил в тот раз работу, всем было бы хорошо от этого. «Велосипеды» нужны для того чтобы в одну RPM-ку и DEB-ку положить 32- и 64-битные бинарники, и распространять два бинарника, а не 4, как многие делают.

Что касается засовывания в FatELF всех либ, я здесь вижу два недостатка 1). 64-мегабайтный бинарник вместо двух 1-мегабайтных 2). Иногда выходят обновления безопасности для системных библиотек. В случае если игра с поддержкой мультиплеера использует динамические библиотеки /usr/lib*.so, всё будет хорошо. В случае если используется статическая линковка, всех игроков под Linux'ом будут взламывать.

Появится, как только вы все скинетесь и профинансируете мне создание такого проекта. :-D

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

У этого вашего 0install эталонно бестолковый туториал. Одни скриншоты, епт. В чем суть системы?

У этого вашего 0install эталонно бестолковый туториал. Одни скриншоты, епт. В чем суть системы?

Ну ты даешь! Нормальный у него мануал.

Суть системы в том, что:

• Приложение должно быть собрано так, чтобы запускаться с с произвольным префиксом.
• У приложения есть манифест, лежащий по некоторому URL. Там указано, где брать архив с приложением, какие ему нужны зависимости и как приложению при запуске сообщить, где лежат его зависимости.
• Приложение запускается командой 0launch url. При этом, если его еще нет локально, оно выкачивается, затем рекурсивно выкачиваются зависимости. В указанные в манифесте переменные окружения помещаются пути к зависимостям (например формируется нужный PATH и LD_LIBRARY_PATH) и происходит запуск приложения.
• Логически вся адресация выполняется на основе URL, по которым лежат манифесты, и контрольных сумм. Где физически будет размещен пакет, не важно.

Вот и всё. Плюс есть дополнительные плюшки, такие как размещение приложения в меню путём переноса его *.desktop-файла в ~/.local/share/applications/, или фоновая проверка обновлений.

Также есть интеграция с основным ПМ системы (чтоб не скачивать то, что уже установлено в /usr) и возможность переопределить интерфейсы («вот тот URL на самом деле брать вот по этому URL»).

Нормальный у него мануал.

А туториал бестолковый.

Приложение запускается командой 0launch url. При этом, если его еще нет локально, оно выкачивается

Какой песец.

Вот и всё.

Это куча ненужных деталей, на самом деле. Интересна суть - как он взаимодействует с пакетным менеджером системы (если взаимодействует)? Как описываются требования к системе (если описываются), или ему не нужно ничего, кроме glibc, или молчаливо предполагается какой-то набор библиотек? Есть ли зависимости между 0install-пакетами и, если есть, как они описываются? Есть ли какие-нибудь средства автоматизации сборки?

Это куча ненужных деталей, на самом деле. Интересна суть

Бгг. Я тебе объяснил суть: каждый пакет представлен как URL. Манифест, лежащий по URL-у, описывает свойства пакета, включая и зависимости. Зависимости также представлены как URL. (пример: http://rox.sourceforge.net/2005/interfaces/ROX-Filer)

Фактически, это реализация опенсорсного распределенного Андройд/Эппл/whatever-маркета.

А то, что ты сейчас спрашиваешь, как раз и есть куча деталей.

Есть ли зависимости между 0install-пакетами и, если есть, как они описываются?

Чувак, ты вроде раньше не был замечен в том, что не читаешь то, на что отвечаешь. Я для кого писал, что зависимости резолвятся по URL?

Интересна суть - как он взаимодействует с пакетным менеджером системы (если взаимодействует)?

http://0install.net/distribution-integration.html

Как описываются требования к системе (если описываются), или ему не нужно ничего, кроме glibc, или молчаливо предполагается какой-то набор библиотек?

Я сходу не нашел, какой набор библиотек он считает дефолтным. Скорее всего, LSB.

Есть ли какие-нибудь средства автоматизации сборки?

Где-то было на сайте описание каких-то тулз, лень искать.

Какой песец.

Информативно. :D

Я тебе объяснил суть: каждый пакет представлен как URL. Манифест, лежащий по URL-у, описывает свойства пакета, включая и зависимости.

Я то же самое могу сказать о любом deb или rpm, лежащем на ftp или http.

Я для кого писал, что зависимости резолвятся по URL?

Я спрашивал, есть ли зависимости между пакетами, а не как они резолвятся. Если зависимости есть, то должен быть депсолвер.

http://0install.net/distribution-integration.html

Этот 0install всё больше напоминает ненужную переделку yum+RPM/apt+dpkg, прикрытую слоем для автоматического скачивания пакетов.

Я то же самое могу сказать о любом deb или rpm, лежащем на ftp или http.

Не можешь, потому что для твоего rpm URL не служит идентификатором для разрешения зависимостей.

Я спрашивал, есть ли зависимости между пакетами, а не как они резолвятся. Если зависимости есть, то должен быть депсолвер.

То есть ты допускаешь, что зависимости резолвятся, но при этом их нет? :D Иди проспись.

Этот 0install всё больше напоминает ненужную переделку yum+RPM/apt+dpkg, прикрытую слоем для автоматического скачивания пакетов.

Ну разумеется всё, что позволяет без головной боли ставить пакеты, не надрачивая на «рипазитории», в линуксе объявляется ненужным. :-D Давно dpkg научился ставить пакеты по произвольным префиксам и заставлять их корректно работать в таких условиях, не подскажешь?

для твоего rpm URL не служит идентификатором для разрешения зависимостей.

Правда штоле?

wget $URL | rpm2cpio | cpio --extract

вот тебе и манифест - разрешай зависимости.

Я спрашивал, есть ли зависимости между пакетами, а не как они резолвятся. Если зависимости есть, то должен быть депсолвер.

То есть ты допускаешь, что зависимости резолвятся, но при этом их нет? :D Иди проспись.

То есть депсолвер в нем есть. Ну, молодцы, чо.

Ну разумеется всё, что позволяет без головной боли ставить пакеты, не надрачивая на «рипазитории», в линуксе объявляется ненужным. :-D

Если ты не помнишь времен, когда репозиториев не было, или не видишь репозиториев в 0install - тебе нужен отдых и учебник истории.

Давно dpkg научился ставить пакеты по произвольным префиксам и заставлять их корректно работать в таких условиях, не подскажешь?

dpkg не умеет префиксов. Но я тебе страшную вещь скажу - это только часть функционала пакетного менеджера. И вместо того, чтобы научить этому dpkg (или взять RPM, который умеет в префиксы), разрабы 0install сделали что-то свое. Зачем? Я уверен, что ты это понимаешь - расскажи нам.

Ну ведь ненужно жэж! Есть жэж *.tar.xz

tailgunner емнип этот велосипед появился в районе opensuse версии эдак 10. И там его позиционировали как «альтернативу сложному rpm для еще неопакеченного софта» пытаясь представить все так как будто бы любая домохозяйка которая осилит написать свою мегопрограммку но не осилит её опакетить найдет простое решение в зераынсталле. На словах это выглядело именно так. На деле толку от него было мало.

вот тебе и манифест - разрешай зависимости.

Не придуривайся.

не видишь репозиториев в 0install - тебе нужен отдых и учебник истории.

В 0install нет репозиториев. Для 0install есть каталоги фидов. Это исключительно средство поиска ПО для пользователя. Оно не больше «репозиторий», чем какой-нибудь http://www.alternative.to/

Сам 0launch никакими репозиториями при разрешении зависимостей не пользуется. Можешь считать, что репозиторием для него служит вся глобальная сеть целиком.

dpkg не умеет префиксов. Но я тебе страшную вещь скажу - это только часть функционала пакетного менеджера. И вместо того, чтобы научить этому dpkg (или взять RPM, который умеет в префиксы), разрабы 0install сделали что-то свое. Зачем? Я уверен, что ты это понимаешь - расскажи нам.

Наверное затем, что не стоит переделывать отвертку в инструмент для удобного забивания гвоздей. ПМ, использующий централизованный репозиторий и фиксированные пути установки ПО, отлично подходит для сборки и конфигурации базовых компонентов системы — которые в рамках работы над дистрибутивом централизованно опакечиваются и тестируются. Если ты хочешь ставить и использовать пакеты с glibc или coreutils по произвольным путям в произвольной среде, ты явно что-то делаешь не так.

У ПМ для прикладного ПО совсем другие требования, проистекающие из требований к этому ПО. Оно должно быть «собрано однажды, работает везде». Именно эту задачу решает 0install, и всего фичи на это и нацелены.

Указанная ссылка на фид rox-filer запустит тебе его в любой совместимой системе. В частности, данный фид содержит сборки под платформы: rox-filer-linux-x86_64-2.11.tar.bz2, rox-filer-freebsd-i386-2.11.tar.bz2, rox-filer-linux-i486-2.11.tar.bz2. И теоретически там может лежать сколько угодно сборок: хоть для миникса, хоть для макоси.

В 0install нет репозиториев. Для 0install есть каталоги фидов. Это исключительно средство поиска ПО для пользователя.

Наверное, ты не застал систем, у которых репозиторием был просто каталог с пакетами.

Можешь считать, что репозиторием для него служит вся глобальная сеть целиком.

Круто. Для целей маркетинга - самое то, но у меня другая специальность.

ПМ, использующий централизованный репозиторий и фиксированные пути установки ПО, отлично подходит для сборки и конфигурации базовых компонентов системы

У ПМ для прикладного ПО совсем другие требования, проистекающие из требований к этому ПО

Вот в этом и есть твоя главная ошибка. У «прикладного» ПО требования очень близкие (возможно, просто идентичные). Ты принимаешь за другие _требования_ другое _дерево зависимостей_.

И теоретически там может лежать сколько угодно сборок: хоть для миникса, хоть для макоси.

Еще одна чисто маркетинговая фишка.

Наверное, ты не застал систем, у которых репозиторием был просто каталог с пакетами.

У тебя уже каталог с пакетами научился волшебным образом себя выкачивать из интернета, распаковываться, настраиваться и запускаться? А я ведь еще полсуток назад тебе говорил: выспись.

Круто. Для целей маркетинга - самое то, но у меня другая специальность.

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

Ты принимаешь за другие _требования_ другое _дерево зависимостей_.

Это _дерево зависимостей_ является _децентрализованным_. Нет никакого владельца репозитория, который может разместить или не разместить твой пакет. Нет никакого /etc/apt/sources.list. Нет зависимости алгоритма резолвинга от базы данных с именами пакетов. Повторить по слогам? :}

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

Ну да, поучи меня русскому языку.

Это _дерево зависимостей_ является _децентрализованным_

Это мало что меняет. Я бы объяснил, но мой русский язык недостаточно хорош.

Переход на ЯВУ с ассемблеров тоже мало что меняет, ок.